The SDIO data transmit sequence appears to have a problem. The active low "start" bit is asserted simultaneously with the rising edge of the SD Clock. Since data is clocked in on that edge by the SD card, this should be asserted on the previous falling edge in order to ensure that it is seen as low.
You can see this in the capture we did on the actual SD signals on a Genesys 2 board. The first data transition (start bit) occurs on a rising clock edge, while all subsequent transitions occur on falling edge. The SD card misses this transition, so sees a CRC error, and doesn't write the data.
The problem occurs in the file "sdio_txrx_data.sv". Output data is enabled with the signal "s_ddata_oen", which changes on the rising edge of clock. This needs to be asserted one clock earlier, and then registered on the clock's falling edge. We made this change and now have a successful file system running. I can post a pull request if appropriate.
Since the CORE-V MCU has already been taped out, a workaround for the dev board is to add a delay element to the SD Clock signal to ensure the required 3 nsec setup time of data to clock is met (unless of course the chip's propagation delays ensure this)
Is there an existing core-v-mcu bug for this?
Bug Description
The SDIO data transmit sequence appears to have a problem. The active low "start" bit is asserted simultaneously with the rising edge of the SD Clock. Since data is clocked in on that edge by the SD card, this should be asserted on the previous falling edge in order to ensure that it is seen as low.
You can see this in the capture we did on the actual SD signals on a Genesys 2 board. The first data transition (start bit) occurs on a rising clock edge, while all subsequent transitions occur on falling edge. The SD card misses this transition, so sees a CRC error, and doesn't write the data.
The problem occurs in the file "sdio_txrx_data.sv". Output data is enabled with the signal "s_ddata_oen", which changes on the rising edge of clock. This needs to be asserted one clock earlier, and then registered on the clock's falling edge. We made this change and now have a successful file system running. I can post a pull request if appropriate.
Since the CORE-V MCU has already been taped out, a workaround for the dev board is to add a delay element to the SD Clock signal to ensure the required 3 nsec setup time of data to clock is met (unless of course the chip's propagation delays ensure this)