Successfully pushing words back into RAM from the write stream coming from 1130 CPU - in simulation

BUILDING WORDS PROPERLY AND FORMING THE RIGHT RAM REQUEST

Using the edges of the 720 KHz write oscillator phases emitted by the drive, my state machine properly scans for pulses during the phase B intervals and uses that to differentiate a 1 data bit from a 0. It shifts those into an accumulated word as it records the number of 1 bits seen in this word. 

The final four bits, the error checking ones, are also recorded into the count of 1 bits so that at the end of the word we can do an error check. The final counter must be b00, thus the count of 1 bits must be evenly divisible by four. If this fails we lock up with a Write Select error setting the drive Not Ready and informing the software on the 1130. 

After the word is accumulated, the data and address must be combined along with a command indication of 'write' to push into the RAM request FIFO. A trigger pulse is emitted which causes the request to push into the FIFO then we wait for the indication from the memory controller that our RAM write is complete. Once that indication arrives, we bump the word address and go back unless we have captured the 321st word. If at any time WriteGate is de-asserted we go back to idle immediately. 

MEMORY CONTROLLER WRITE CYCLE SET UP PER SPEC

I observed that the signals are properly set up with enough hold time before clock edges, that the control signals are asserted at the correct time and for the appropriate number of cycles and that we wait for the memory controller to inform us when the write has completed to the memory chip. 

FAKE MEMORY CONTROLLER MODELING SIGNAL INTERLOCK

My logic for controlling the RAM interlocks on the app_rdy signal from the memory controller. This goes not ready after we request the write, while the controller is putting away the data into the DDR3 chips. Once the physical writing is complete the memory controller will reassert app_rdy. My fake memory controller module is emitting the app_rdy signal to complete the interlocked transaction with the fpga logic. I could see this working properly in the simulation traces.

CHECKING ERRONEOUS CHECK BITS

Once I had the logic working as it should to capture words when the CPU is writing to the disk drive, given perfect data, I set up one of the words with an incorrect set of check bits to verify that the error is detected and the drive is stopped from further writes. It stopped at the end of the word as I expected.

CHECKING FIRST/LAST BIT CAPTURE AND WRITE OF ENTIRE SECTOR

The data patterns I created allow me to see the edge cases of the first and the last data bits of the incoming word. Having patterns where those bits are 1 and others where they are 0 gave me confidence that I the logic captures the word correctly.  The simulation showed this working as intended.

As an additional test, I had the testbench produce more than 321 words of data, allowing me to validate that I ignore the extraneous data. As an acid test on this, I wrote bad error checking bits for the 322nd word, which were ignored - I didn't want to trigger a write select error spuriously that turned off the drive ready status. 

SHUTTING DOWN WHEN WRITEGATE IS DEASSERTED

It is legitimate to write less than the full 321 words of a sector and this does occur in software that runs on IBM 1130 systems. When the word count of the XIO Initiate Write command in the CPU is exhausted, the device controller drops WriteGate which should turn off the erase and write head operation. 

My logic has to handle this gracefully, in other words it has to stop looking for 720KHz clock pulses and the write data bits. I set up my simulation testbench with a short count so that I knew this works properly.  

shutdown after word 321

NEXT STEPS

Onward to finishing up the SPI link protocol logic and debugging it from this side.