Simulation of the load/unload logic completed

TESTBENCH MECHANISMS TO PROVE OUT THE ENTIRE LOAD/UNLOAD PROCESS

Having written the loopcart module, I put it into a testbench to simulate the operation of entire load and unload processes. Loopcart will start with the low address of the last megabyte of SDRAM and step through the space as we read or write blocks of four 1130 words per cycle, 130,326 times. 

For load, it will wait for the Linux application in the Hard Processor System (HPS) side to write the first block of four words over the H2F bridge, then write that block to the SDRAM over the F2SDRAM bridge. We are in the FPGA side and thus are the controlled party in the H2F bridge, with the timing of the write or read over that bridge totally decided by the HPS with no voice from the FPGA. The F2SDRAM bridge is controlled by us as the master side, thus we determine the timing for those read or write operations.

Loopcart will make use of the waitrequest signal of the H2F bridge, a control that the subservient side (us) can assert that tells the master side to hold off on its write or read. We keep that signal asserted, opening a window when we want the read or write from the HPS to actually take place. 

My testbench has to model all the signals of the H2F and F2SDRAM bridges which come from the HPS side, in addition to kicking off the major operation with a trigger to loopcart to perform the unload or load. I wrote the testbench signal timing to test out all the relative timing cases:

• H2F attempts write or read before loopcart is ready
• H2F starts the read or write exactly as loopcart is ready
• loopcart has to wait for a delayed write or read from H2F
• SDRAM read and write take place in one cycle
• SDRAM read and write are delayed
• SDRAM write and read are at the exact time loopcart is at the next state

RESULTS OF THE SIMULATION

I uncovered a few aspects of the logic that warranted making more tolerant of timing variations, leading to a potentially more reliable design. I spent about as much time fixing or refining the testbench as I did working on the logic of the design. 

Eventually when I had separated out the testbench driver for the F2SDRAM link from the driver for the H2F link, allowing them to be truly asynchronous of each other, I achieved the timing relationships to shake out the logic. 

I was able to see it cycle through the entire 1MB of SDRAM, although I only need 99.43% of that to hold the entire cartridge. Realizing that, I adjusted the loop end so that I stopped after the 130, 326 iterations and not the 131,072 that would fit into one megabyte.