SIMULATION SHOWED FIFO BEGIN FULL
When I begin my debugging of the RAM access mechanisms that would be driven by the disk modeling to fetch words of cartridge data, I saw that the FIFO is marked full at startup, which blocks me from pushing in any requests for RAM access.
The reset of the FIFO should result in the flag being off so that I can write a request into the queue. I began monitoring all the signals involved in the FIFO and the reset logic, where I saw the flag sitting at full. Some investigation shows that the reset of the FIFO must occur after its clocks are operating in order to properly reset. Perhaps when my power on reset is asserted the clocks weren't running, so I planned for a FIFO reset signal that would blip on for a few cycles well after my reset is complete.
IMPLEMENTED RESET LOGIC FOR FIFO BUT STILL BLOCKED
The FIFO reset was generated as I expected but I still didn't see the full flag go off. Tracking the clock produced by the memory interface circuits that is used to empty the request FIFO and feed the response FIFO was illuminating - no clock coming out of the memory interface.
A bit of reading highlighted the need for the interface to complete calibration before the DDR3 memory is ready for access, said completion to be signaled by a calibration complete signal out of the memory interface. I set up a run to watch for the completion signal and the appearance of my FIFO clock.
DDR MEMORY INTERFACE CALIBRATION WAIT
I ran the simulation for almost half a second but never saw the calibration complete nor the clock begin operating. This led me to look closer at the reset for the memory interface generator. It was active low - thus I had to invert my usual power on reset signal to cause the memory to be properly reset.
Once the memory interface was properly initialized and the FIFOs were ready, the number of changing signals that had to be simulated shot way way up. The speed of simulation slowed to a crawl, from its already pokey rate. A quick estimate was .2 milliseconds of simulation for each elapsed minute.
To see the signals I care about I think I need to get to around 25 milliseconds total time in the simulation. That means something in the vicinity of 125 minutes to reach that point. Yikes - the investigations are going to be painful if every small insight requires 2 or more hours to check out once the issue is resolved.
EXAMINATION OF RAM REQUEST PERFORMANCE DURING SIMULATION
After waiting several hours I was able to see that at least my front end of the RAM access mechanism is working. I saw the trigger cause the request to be pushed into the FIFO, it was then pulled by the RAM engine and that engine advanced to the next step of its state machine. Unfortunately, it did not proceed any further and that meant we would not generate the ram_done signal to push a response into the second FIFO.
Looking at the logic it was immediately apparent that the problem was that the memory interface was not activating its interface app_rdy signal to indicate it was ready to accept commands. This was consistent with the initial calibration completion signal remaining off.
I need to look very closely at how to get the memory to simulate through to a completion of calibration as that is an essential prerequisite to the interface becoming ready for operation. Since each attempt to verify a fix will take more than two hours, I have to be more careful and complete in my studying to avoid wasting huge portions of a day.
One way I can shorten the wait is to fast track the disk rotational model - right now it starts with a SM, then a SM + IM, after which it takes two more SM before it can begin to request data. Each SM interval is 5 milliseconds, so that burns 20 milliseconds when no useful information is being collected. I will start the testbench for simulation at the index mark, this should cut the delay about in half.
I will also be looking at a parameter for the memory interface which will produce a fast calibration during simulation - hopefully that will make the memory interface happy.