This will have to be changed, some things like the VGA connector will
not work because they will interfere with the cpu adapter.
It may be worth thinking about making these smaller and not including
the ethernet for example, since that will not come for a while.
The only things we really need to start are the SD card and serial port.
Don't have the FPGA on the shield, just have it be a board that plugs
into the FPGA.
Don't mind the component and footprint choices yet, I still need to
figure out exactly which parts to use.
Split the project into two parts, the adapter will connect the cpu
directly to the FPGA, and the shield will house all of the peripherals.
I will get the adapter first so that I can get things like sdram
working first, and then make the shield with things like SD card, USB,
maybe even ethernet and VGA. Basically anthing since it's connected to
an FPGA.
I think that previously, I had not actually commited any of this to git.
This adds all of the new effinix stuff that I had been working on for
months.
The gist of all of this is that the intel fpga is expensive and does not
exist, whereas the effinix ones are not as expensive and more existant.
This redoes the project to use the dev board, as well as a custom board
that I may or may not make.
Now that the ROM is just a bootloader and the kernel is stored on the SD
card, we do not need to be constantly changing the ROM.
Disabling the memory editor dramatically reduces compilation time which
will be useful when implementing FPGA features in the future.
The but count should be set to 7 when entering RXDATA. previously it was
not reset or left at 0, which caused the first byte to only have the lsb
set and all other bits to be read incorrectly.
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.
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.
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.
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.
