1 |
3 |
dgisselq |
# SD-Card controller, using a shared SPI interface
|
2 |
|
|
|
3 |
|
|
This Verilog core exports an SD card controller interface from internal to an
|
4 |
|
|
FPGA to the rest of the FPGA core, while taking care of the lower level details
|
5 |
|
|
internal to the interface. Unlike the [other OpenCores SD Card controller](http://www.opencores.org/project,sdcard_mass_storage_controller) which offers a full SD interface, this controller focuses on the SPI interface of the SD Card.
|
6 |
|
|
While this is a slower interface, the SPI interface is
|
7 |
|
|
necessary to access the card when using a [XuLA2 board](http://www.xess.com/shop/product/xula2-lx25/), or
|
8 |
|
|
in general any time the full 9--bit, bi--directional interface to the SD card
|
9 |
|
|
has not been implemented.
|
10 |
|
|
Further, for those who are die--hard Verilog authors, this core is written in
|
11 |
|
|
Verilog as opposed to the [XESS provided demonstration SD Card controller
|
12 |
|
|
found on GitHub](https://github.com/xesscorp/VHDL\_Lib/SDCard.vhd), which was
|
13 |
|
|
written
|
14 |
|
|
in VHDL. For those who are not such die--hard Verilog authors, this controller
|
15 |
|
|
provides a lower level interface to the card than these other controllers.
|
16 |
|
|
Whereas the XESS controller will automatically start up the card and interact
|
17 |
|
|
with it, this controller requires external software to be used when interacting
|
18 |
|
|
with the card. This makes this SDSPI controller both more versatile, in the
|
19 |
|
|
face of potential changes to the card interface, but also less turn-key.
|
20 |
|
|
|
21 |
|
|
While this core was written for the purpose of being used with the [ZipCPU](https://github.com/ZipCPU/zipcpu),
|
22 |
|
|
as enhanced by the Wishbone DMA controller used by the ZipCPU, nothing in this
|
23 |
|
|
core prevents it from being used with any other architecture that supports
|
24 |
|
|
the 32-bit Wishbone interface of this core.
|
25 |
|
|
|
26 |
|
|
This core has been written as a wishbone slave, not a master. Using the core
|
27 |
|
|
together with a separate master, such as a CPU or a DMA controller, only makes
|
28 |
|
|
sense. This design choice, however, also restricts the core from being able to
|
29 |
|
|
use the multiple block write or multiple block read commands, restricting us to
|
30 |
|
|
single block read and write commands alone.
|
31 |
|
|
|
32 |
|
|
For more information, please consult the specification document.
|
33 |
|
|
|
34 |
|
|
# Next Steps
|
35 |
|
|
|
36 |
|
|
Now that I have an initial SD Card controller working over the SPI port, I've
|
37 |
|
|
kind of fallen in love with the simple interface it uses. I'm wondering if I
|
38 |
|
|
can use the same control interface for the full SD protocol. To that end, I
|
39 |
|
|
intend to build a version of this controller that works with the full SD
|
40 |
|
|
protocol--even integrating a card detect bit into the control register.
|
41 |
|
|
|
42 |
|
|
# Commercial Applications
|
43 |
|
|
|
44 |
|
|
Should you find the GPLv3 license insufficient for your needs, other licenses
|
45 |
|
|
can be purchased from Gisselquist Technology, LLC.
|