After a data read (e.g. CMD17) the data received from the SD card is
stored into a buffer which can be read back one byte at a time by the
CPU through address 5.
There is also a flag which is set when data is received. This can be
checked by reading the CMD register, which doubles as the status
register.
Polls the sd controller until the read flag is set, at which point it
reads 32 bits of data from the controller.
long response codes (such as CID) are not supported in hw or sw.
Read flag is set when the sd controller reads response data in from the
sd card. When the cpu reads from the controller, the flag is reset.
This flag does not trigger an interrupt, it mmust be polled.
These series of commands are enough to read the first 512b block off of
the sd card. The RCA is hard coded to the sd card that I have on hand,
since response codes are not supported
The SD card expects data to transition on falling edges and be stable on
rising edges.
Additionally, writes from the CPU were not handled with correct timing.
Now, there is an extra state when writing to the command register so
that the command is properly latched before the CRC is calculated.
Adds the start of the SD card controller which is capable of sending
commands using the SD protocol.
It is accessed by writing the arguments first and triggered by writing
the command number.
Previously the crc would be reset after 1 clock cycle while the valid
signal was still high. Now the data is preserved in the valid state
until the load signal is asserted.
This module takes in a 40 bit word and generates the 7 bit crc7
appropriate for an SD card.
It does not use any fancy parallel algorithm, it does it 1 bit at a
time.
This code creates a shared mapping in high ram, makes sure that that
works, and also makes sure that the memory which is mapped over is left
unchanged.
address decoding is now performed on the translated address which comes
from the memory mapper, instead of the address coming directly from the
cpu.
This means that you can access the full amount of ram at any address
that it is mapped to.
This testbench simply creates the memory mapper, adds a mapping to the
first entry, and then makes sure the addresses are correct after
enabling and disabling the memory mapper.
Based on the 74ls610 but with some slight changes.
The memory mapper works by having a 16x12 ram array. The top 4 bits of
the address are used to index into this array, and the resulting word
replaces those top 4 bits. In this way, a 16 bit address is replaced
with a 24 bit address.
As of now there is no way to write 12 bit values though, so currently
we are using 20 bit addresses.
There is a chip select line that allows you to write into the ram array,
and another chip select that allows you to write to the control word.
Currently the control word is just a single bit, the enable bit.
When not enabled, the 4 index bits are passed straight through, and the higher
bits of the address are replaced with 0, a sort of identity map. Once
enabled, it operates as described above.
Since the bottom 12 bits are left unchanged, the page size is 4kb.
There are no protections so far, but might be added later, as well as
the ability to actually use all 12 bits.
Replace RAM section with SDRAM.
Really this makes no difference than before we added SDRAM except the
name is different. In hardware, the SDRAM acts the same way and is
located in the same space as the RAM was previously.
This removes the ram from inside the FPGA. All RAM is now located in the
external SDRAM instead.
The ROM is still in the FPGA to allow easier programming.
Turns out there are some issues with holding the chip select for the
SDRAM controller high for too long, so there is a simple 2-state fsm
which ensures that the chip select is only held for 1 clock cycle for
writes and for as long as it takes to read the data from sdram for
reads.
