Memory mapped SPI Dual port Ram

[ali_asadzadeh]

Hi,
I'm in the middle of implementing a SPI controller inside a Gowin FPGA to communicate with a STM32H device, I want to do DMA communication with the FPGA and read and write two separate dual port block rams, so the settings and calculated registers can be read/write  as fast as possible with the lowest over head into STM32, I want to know if there is some open source code that can handle this kind of job, so I can use it and just save some time on my side.

[ali_asadzadeh]

I have managed to make a working Verilog module, it's format is like this


The STM32 act as SPI master and FPGA act as SPI slave, The first two bytes are Address low and high bytes, the third one is CMD, basically it can be used to tell if we are writing or reading the Block RAM, CMD[0] 0 means write and 1 means reading, also the rest of the bits can be used to concoct to a MUX so different Memories can be attached to this core,

I have tested this code with STM32H and Gowin FPGA with 100MHz clock for the FPGA,

The SPI mode is 0, and you can use STM32 DMA to do the job, something like this

Code: [Select]

//the address is 0 and the command LSB is 0, and some arbitrary values to write
uint8_t tx[30]={0,0,2,0x11,0x22,0x33,0x44,0x55,0x66,0x77,0x88},rx[30];
HAL_SPI_TransmitReceive_DMA(&hspi2,tx,rx,20);
The maximum clock of the SPI from the MCU side is 15Mhz with this setting, If I go higher, the receive or read part do read and write garbage, so the question in here is What's wrong with this code so the STM32 SPI clock can be higher, can we reach 50MHz SPI clock to transfer correct DATA? do you have any Idea what's wrong with this code?

[KrudyZ]

I have implemented something similar for a Lattice FPGA.
I found the tightest timing constraint is for the first read byte, so I used a slightly different protocol.
I am accessing a smaller memory, but the principle is the same.
First byte is read / write bit in MSB and seven bits of address (kinda like I2C).
For the writes this is just followed by the bytes to be written. This should be no problem since you can add pipeline delays for clock domain crossings if that's needed in your design.
For reads the second byte is a byte count that tells how many bytes are to be read. In my case reads can have side effects, such as clearing a register, so they should not be read speculatively.
The byte count is actually byte count - 1, so you always can read one byte and then know how many are needed early enough to pipeline the reads.
This should allow you to get to much higher clock frequencies.
Rudy
p.s. sorry, but I don't have time to look at your code ATM, and I also can't give you mine, since I don't own the rights (contract work...)

[KrudyZ]

I just had a quick look at your code.
You are synchronizing everything to the FPGA clock right away, which requires a significantly higher FPGA clock frequency to allow you to meet the timing margins on your SPI bus.
What you should do instead is to clock the SPI shift register from the SPI clock itself and do the clock domain crossing on the byte level.
That will make bit timing compliance with the ST Micro a lot easier.

[ali_asadzadeh]

I just had a quick look at your code.
You are synchronizing everything to the FPGA clock right away, which requires a significantly higher FPGA clock frequency to allow you to meet the timing margins on your SPI bus.
What you should do instead is to clock the SPI shift register from the SPI clock itself and do the clock domain crossing on the byte level.
That will make bit timing compliance with the ST Micro a lot easier.

Thanks for the hint KrudyZ, would you please give me some hints on how to do it? I do not get fully what you mean I should do.

[ale500]

You implement the receiver of the spi using the spi clock, when a byte has been received you transfer it to the other domain polling on a byte received flag, you wait for the address bytes and when all is there you read/write the memory and return the information in a similar way clocking the byte to be transmitted on the neg flank of the spi clock. you may need a dummy byte too.

[ali_asadzadeh]

Thanks ale500, It would be very helpful if I could see some codes