The SD card controller handles the low-level details of reading and writing data on the DE2-115's SD card. The SD controller is implemented in sd.v.
sd_command and sd_response implement the standard I/O protocol. The command parameters are sd_write, sd_address, and sd_data_write. sd_address specifies the address that the E100 is asking to access.
If sd_write=1, this signifies that the program wants to write the value contained in sd_data_write to the specified location on the SD card.
If sd_write=0, this signifies that the program wants to read the specified location on the SD card. In this case, the data read from the SD card will be returned in the response parameter sd_data_read.
To initialize the contents of an SD card, create a file with the desired contents, then carry out the following steps at a computer in 2322 or 2331 EECS:
ls -l /dev/sd*Usually, the computers in 2322 EECS use /dev/sdd (or /dev/sdg if you're using the SanDisk MobileMate SD card writer), and the computers in 2331 EECS use /dev/sda. E.g., the following shows that /dev/sdd is owned by pmchen.
eecs2322p10% ls -l /dev/sd* brw-r----- 1 root disk 8, 0 Feb 23 19:32 /dev/sda brw-r----- 1 root disk 8, 48 Feb 23 19:32 /dev/sdb brw-r----- 1 root disk 8, 32 Feb 23 19:32 /dev/sdc brw-r----- 1 pmchen disk 8, 16 Feb 23 19:32 /dev/sdd brw-r----- 1 root disk 8, 64 Feb 23 19:32 /dev/sde
dd if=FILE of=DEVICE
ase100 simulates the SD card controller accurately enough for you to test your device driver and to run assembly-language programs. ase100 simulates the SD card by reading data from a file, which you select when your program runs.
Many of you will use the SD card to store the sound samples and image data needed by your E100 program. The best way to store this data on the SD card is as a binary data file; see the handout on manipulating binary data files for how to create such files.
SD cards are slower than other forms of memory on the DE2-115 board because they must be read and written in sector-sized units (a sector is 128 words). The SD controller enables programs to read and write individual words by maintaining a sector-sized buffer and by translating word-level accesses into sector-level reads and writes to the SD card. When the E100 program reads or writes a word, the SD controller must first ensure that the sector containing that word is in its buffer. If the sector is not in the buffer, the SD controller will first read that sector from the SD card; this incurs a delay of about 0.5-1 ms.
When an E100 program writes a word, the SD controller stores this word in the buffer. It does not immediately write this word to the SD card, as this would incur a delay on each write. Later, when the SD controller needs to use the buffer to hold another sector, it will write the modified data stored in the buffer back to the SD card; this incurs a delay of about 1-5 ms. If an E100 program wants to force the modified buffer to be written back to the SD card, it should read a different sector than the last sector accessed.
Thus, when an E100 program accesses a sector other than the one it last accessed, the SD controller may take about 0.5-6 ms to satisfy the request.
If you are playing audio by reading samples directly from the SD card, you will need to buffer about four audio samples to hide the 0.5 ms delay you will encounter when crossing sector boundaries.
Write a device driver for the SD card controller that a program can call to read a value from the SD card. Then, write a program that reads a sequence of values from the SD card and displays each value on LED_RED. Initialize the SD card with the contents of this data file; it has a slowly changing sequence of numbers that will generate a recognizable pattern on the LEDs (the first 8192 numbers are 1, the second 8192 numbers are 2, the third 8192 numbers are 4, the fourth 8192 numbers are 8, and so forth).