Repository files navigation

This repository contains two Verilog hardware RTL controllers for handlingSD cards from an FPGA. Thefirst and older controller handlesSD cards via their (optional) SPI interface. Thesecond and newercontroller works using the SDIO interface. Thissecondcontroller has also been demonstrated to handle eMMC cards as well.

The SDSPI controller exports an SD card controller interfacefrom internal to an FPGA to the rest of the FPGA core, while taking care of thelower level details internal to the interface. Unlike theSDIOcontroller in this respository, this controller focuses on the SPIinterface of the SD Card. While this is a slower interface, the SPI interfaceis necessary to access the card when using aXuLA2board (for which it wasoriginally written), or in general any time the full 7--bit, bi--directionalinterface to the SD card has not been implemented. Further, for those who aredie--hard Verilog authors, this core is written in Verilog as opposed to theXESS provided demonstration SD Card controller found onGitHub, which was writtenin VHDL. For those who are not such die--hard Verilog authors, this controllerprovides a lower level interface to the card than other controllers.Whereas theXESS controllerwill automatically start up the card and interact with it, this controllerrequiresexternal software to be used when interacting withthe card. This makes this SDSPI controller both more versatile, in the faceof potential changes to the card interface, but also less turn-key.

While this core was written for the purpose of being used with theZipCPU, as enhanced by the Wishbone DMAcontroller used by the ZipCPU, nothing in this core prevents it from beingused with any other architecture that supports the 32-bit Wishbone interfaceof this core.

This core has been written as a wishbone slave, not a master. Using the coretogether with a separate master, such as a CPU or a DMA controller, only makessense. This design choice, however, also restricts the core from being able touse the multiple block write or multiple block read commands, restricting it tosingle block read and write commands alone.

Status: The SDSPI IP issilicon proven. It is no longer under activedevelopment. It has been used successfully in several FPGA projects. Thecomponents of this IP have formal proofs, which they are known to pass. AVerilatorC++ model also exists which can fairlyfaithfully represent an SD card's SPI interface. Asoftwarelibrary also exists which can act as a back end when usingtheFATFS library.

• AXI Support: TheSDSPI controller has no support foran AXI environment. The RTL modifications required to provide AXI-Litesupport to this controller would be minor. Testbench modifications wouldbe more significant.

• All-Verilog Test bench: TheSDSPI controller has aC++ model only for simulation based testing.There is no all Verilog test bench at present, nor do I have any plans todevelop one.

For more information, please consult theSDSPI user guide.

This repository also contains asecond and newer SD cardcontroller, designed to exploit both the full SDIO protocol andthe 8b EMMC protocol--either with or without data strobes. This controllerhas been tested against both SDIO and eMMC chips, with the differences betweenthe two types of chips handled by software.

The interface to this controller is roughly the same as that of theSDSPIcontroller, although there are enough significant differencesto warrant aseparate user guide.

The controller is designed to support IO modes all the way up to the HS400mode used by eMMC. HS400 is an eMMC DDR mode based off of a 200MHz IO clock,using a data strobe pin on return. Also supported are an SDR mode using a200MHz clock, DDR and SDR modes using a 100MHz clock, as well as both DDR andSDR support for integer divisions of the 100MHz clock, starting with a 50MHzclock and going all the way down to 100kHz. This is all based upon a nominal100MHz system clock, together with a 400MHz clock for SERDES support. Fordesigns without 8:1 and 1:8 SERDES IO components, 100MHz and slower clocks arestill supported, depending upon whether or not DDR I/O components are available.Both open-drain and push-pull IOs are supported, and the front end can switchbetween the two as necessary based upon options within a PHY configurationregister. No support is planned for any of the UHS-II protocols.

Both Wishbone and AXI interfaces are supported.

Status: The SDIO controller has now beensilicon proven. It iscurrently working successfully inits first FPGAproject, where it is being used to controlboth an SD card as well as an eMMC chip. It is also now working successfullyin asecond project. Many of thecomponents of this IP have formal proofs, which they are known to pass.

Notably missing among the formal component proofs is a proof of thefrontend. Thefront end's verificationdepends upon integrated simulation testing.

BothVerilog andC++models have been built which can be used to test this controller insimulation. Unlike theVerilog SDIO model, theC++ SDIO supports a file-backed memory, allowingfull software testing with filesystem(s) present. All three simulationcomponents have been now been tested successfully: the VerilogSDIO andeMMCmodels, as well as theSDIO C++ model.

Features include:

• Multi-block: Multiple block commands have been demonstrated insimulation when using both the VerilogSDIO modelandeMMC models.

  Multiblock commands form the basis for the DMA's operation.

• OPT_DMA: An optional DMA is now available, and passing tests in silicon.

  Both Wishbone and AXI versions of the DMA controller exist and pass allsimulation based testing.

• STREAM DMA: At customer request, hooks now exist for an (optional)stream DMA interface. This interface will accept an AXI stream input,and/or an AXI stream output. Data present on the AXI stream input maythen be written directly to the device. Reads from the device may alsoproduce data at the output stream.

  This interface is now supported andtested viasimulation. No known issues exist. It doeshave some software quirks:

  • When using the stream interface, the DMA address should be set to -1. Thisselects the stream interface as either source or destination. (The actualcontroller command will indicate the direction of the transfer.)
  • Any memory source (MM2S)should be configured for the full transfer length--potentially many blocks.
  • There is no TLAST stream input (slave).
  • When the external (SD or eMMC) device is the data source (S2MM),the TLAST signal will be set at the end of each 512B block. This mayrequire the external DMA to be configured to transfer data one block at atime, or perhaps to ignore the TLAST signal.
  • Transfer errors (failing CRCs, non-responsive cards, etc.) may cause the streams to lose synchronization. To fix, the design may be given a soft reset (if necessary), and the externalMM2S/S2MM DMAs may also need to be given similar resets.

• C++ Model: AVerilator C++ model of an SDIOcomponent is now a part of the repository. Thismodel has demonstrated tremendous utility when doing software testing.

  No C++ eMMC model exists at present.

• SW Testing:Control software has been written, and has beenused to demonstrate bothSDIO andEMMCperformance. This software is designed to work with theFATFSlibrary.

  Software testing is currently taking place as part of the integrated testbenches associated with separate repositories, such as theVideoZip repository that contains boththis component and theZipCPU.

• AXI Support: This design has also been demonstrated in AXI environments.The control interface has an AXI-Lite port which can be used to interactwith the IP. A flag exists to swap endianness, so that the design will beproperly little endian when using this interface. The design now includesan integrated AXI DMA.

• CRC Tokens: CRC token's are 5b response values, indicating whetheror not a page has transferred successfully.Thefrontend can successfully recognize those CRC tokensfollowing block write transfers.

  Failure to receive a CRC token when one is expected will (now) generate anerror condition, as will receiving a negative CRC acknowledgment.

For more information, please consult theSDIO user guide.

Now that the RTL has been fully drafted and successfully tested in hardware,it's moving from its development to application phase. Further improvementscould still be made, as listed below:

• C++ Model: The design is missing a C++ model for testing the eMMCinterface.

• eMMC Boot mode: No plan exists to support eMMC boot mode (at present).This decision will likely be revisited in the future.

  Some (untested, preliminary) support exists for boot mode in the VerilogeMMC model.

• eMMC Collision Detection:Collision detection remains an ongoing issuewith eMMC support. This issueis limited to theGO_IRQ_STATE command, and specifically to the case whereboth controller and device attempt to leave the IRQ state at the same time.Without collision support, the message to leave the IRQ state may becorrupted on return. This should be detectable via a bad CRC on the commandline.

Current logic usage is being tracked for iCE40 and Xilinx 6-LUT devicesin theusage.txt file in theRTL/ directory.

Should you find the GPLv3 license insufficient for your needs, other licensesmay be purchased from Gisselquist Technology, LLC.