User interface test verification part 4

LOAD OPERATION NOT WORKING

I instrumented the FPGA side using the LEDs on the board to indicate what stage we were at in handling the H2F bridge during a load operation. I need to see why we are stalling the Linux side rather than taking each block of four words and writing it up to the SDRAM last megabyte. 

We were stalling issuing a write on the FPGA2SDRAM bridge, which is where we can read or write the contents of the DDR3 memory directly. Since we reserved the high MB (actually got 256MB reserved because of a restriction in the Linux kernel I am using), we write and read from that area as our own dedicated RAM buffer for a virtual disk cartridge image. 

Doing a bit of digging, it appears that while the other bridges are enabled and working (H2F and H2FLW where I transmit data and command/status respectively between Linux and the FPGA side), I have to take explicit action to turn on the SDRAM bridge. This involves writing bits into a memory location which is the control register to take that bridge out of its default reset condition. 

I added the code into my initialization module to make this happen and went back to test some more. Unfortunately the results were no different. The SDRAM controller is holding wait request high which blocks my first attempt to write to the memory. 

When I look to the control registers - of which there are quite a few - I see a myriad of configuration settings. Decoding which address bits select row versus column versus bank versus chip, as just one example. Once again the wholly inadequate level of documentation that comes with the Altera/Intel System on a Chip, in spite of tens of thousands of pages written, provides yet another challenge. 

This seemed so easy. There is a demonstration that implements a processor in the FPGA side which makes use of half the RAM using the F2SDRAM bridge, just like I want, while the ARM HPS system is running code using the other half of the RAM. Sadly it is not a regular Linux running on HPS but instead the standalone stuff they provide. Therefore there are some big gaps between what is clearly possible from the demonstration code and what I will need while running an actual Linux system on HPS.