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.
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.
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.
The UART has a receive buffer which will fill up when it receives bytes.
Once the buffer is full, it raises the RX flag until the value is read
by the cpu.
Currently an interrupt is triggered any time there is any activity on
the UART_RXD line, but later it will only trigger once there is data
ready to be read.
Upon receiving an interrupt, the corresponding bit in the interrupt
status register will be set and an IRQ will be raised for the CPU. The
cpu can then respond to the interrupt and clear the interrupt by writing
back to the interrupt status register.
