SPI based SD card controller

Description

The SDSPI controller offered here exports an high level SD card interface to the rest of an FPGA core via a wishbone bus. Interaction at the lower level is accomplished via SPI. Unlike the other SD card controller available here on Open Cores which operates using the full bi-directional SD interface, this core uses the SPI interface to the core. While this is a slower interface, the SPI interface is necessary when accessing the card on a XuLA2 board (for example), or in general any time the full 9-bit, bi-directional interface has not been implemented. Further, for those who are die-hard Verilog authors, this core is written in Verilog as opposed to the XESS provided demonstration SD card controller found on GitHub, which was written in VHDL. For those who are not such die-hard Verilog authors, this controller provides a lower level interface to the card than these other controllers. Whereas the XESS controller, and other controllers I have come across, will automatically start up the card and interact with it, this controller requires external software to be used when interfacing with the card. This makes this SDSPI controller both more versatile, in the face of potential changes to the card interface, but also less turn-key.

While this core was written for the purpose of being used with the ZipCPU, as enhanced by the Wishbnone DMA bus controller used by the ZipCPU, nothing in this core prevents it from being used with any other architecture that supports the 32-bit wishbone interface of this core. Further, since the core has been designed as a wishbone slave, it has no ability to do multiple block reads or multiple block writes.

Next Steps

Now that I have an initial SD Card controller working over the SPI port, I've kind of fallen in love with the simple interface it uses. I'm wondering if I can't use the same control interface for the full SD protocol. To that end, I intend to build a version of this controller that works with the full SD protocol--even integrating a card detect bit to the control register. Further, I intend to demonstrate this new interface using the peripheral module found here and the Arty board (running at 200MHz). The controller will be the ZipCPU (not yet up to 200MHz), and some form of (to be determined) O/S that provides full file access via this board. Certainly, if this controller can run at a 200MHz clock, it should never slow anything down that uses it, right?