Dram Controller module verified by simulation. Memory controller not working on real hardware

MANY ASPECTS HAD TO BE REVIEWED IN SIMULATION

The user interface of the DDR3 memory controller can be busy with activities such as refreshing memory locations, thus it has some ready signals that the caller must obey. I had to validate the correct behavior of my logic with varying lengths of delay as well as no delay in the ready signals. 

Writing to RAM involves two separate actions - loading the data word and address is one, requesting the actual write is another. Each of those actions has its own ready signal - app_wdf_rdy and app_rdy - with the need to build in permutations of the two having delays or not. 

Even the address used for the RAM write has a complication. It is built from the current cylinder address, current head, current sector address and current word address within the sector. However, the sector address as used by the IBM 1130 disk controller and as modeled in my design shows the address of the sector coming up. Thus, once a sector begins (due to a Sector pulse), the sector address will advance to indicate the upcoming next sector. 

While we are reading the sectors into RAM, we have to use the sector appropriate to the data words, not the next sector to arrive. Thus, when the design sees a read request, it latches in the sector address as the Sector pulse arrives and maintains that regardless of the changing sector address afterwards. This saved sector address is what is used to write the data into RAM.

The uploader module that reads the RAM back and writes it out the serial port generates its own sector address, but this is the true one for the sector we want to read and upload. Thus, the dram controller module selects whether to use the saved or generated sector address based on write versus read activity. 

I was able to watch every signal flowing to the two FIFOs, to and from the user interface of the memory generator, and the behavior of the dram controller as I set up various cylinder/head/sector/word addresses and requested writes or reads. Once everything worked as it should, I concluded that this module is finished, subject only to actual hardware level debugging when we are connected to the Diablo disk drive. 

POSSIBLE ALL UP SIMULATION BUT SHOWSTOPPERS OF MEMORY AND CLOCK IP 

I could build a testbench to simulate the Diablo drive and respond appropriately. It would take a good deal of work to produce decent output, using external text files for the data words needed to simulate the bit stream coming from the disk head. If the memory controller and clock modules would simulate correctly, I would have attempted this. However, in their current nonworking state my design couldn't even start working as it will be waiting forever for the initial calibration of memory to complete. 

SIMPLE HARDWARE FIRST LEVEL TEST

I will instead build a version of this with one LED indicating successful initial calibration. It should at least come up with those two lit, on real hardware, before waiting for me to push a button to start the archiving. Once the button is pushed the design will stall as it is waiting for the Diablo drive to respond. 

HARDWARE STARTS BUT MEMORY DOES NOT COMPLETE INITIAL CALIBRATION

My design comes up on the board, as I can see from a signal that reflects the state of a slide switch on led2. However, led1 with the state of the calibration remains dark, just as it does in simulation. The overall reset signal for the design is released once calibration completes, so we have a mostly inert board. 

I began routing different signals to the leds in the hope that I could at least narrow down where things are going wrong, although the memory controller is a prime suspect. In addition it was time to pour over the detailed messages from Vivado to see if I could spot any issue.