Finished the debugging of the Arduino link on the FPGA side using Vivado simulation

LOAD COMMAND TESTED AND EXAMINED

Just as I had yesterday with the unload transaction, I closely examined the behavior of my logic when a simulated SPI link stream gave it a properly formatted transaction with a stream of data to be loaded into RAM. After chasing some issues, I was satisfied that it was performing as designed. 

FINAL EXHAUSTIVE EXAMINATION OF LOAD AND UNLOAD TRANSACTIONS

Sector load

The trace above shows the start of a load transaction, which addresses a given sector on the virtual disk cartridge and then passes in the new content, 321 words of 16 bits, to be loaded into RAM at the addresses assigned to those words in that sector. It accumulates a checkpoint value which is tested against the checkpoint transmitted in the transaction, then returns a flag indicating all error checking was passed. 

One word of the transaction

Above is a smaller section of the transaction, with one word shown being shifted in from the SPI link and stored away in RAM. SPI is always bidirectional, we are shifting out bits of an outgoing word while simultaneously shifting in bits from the remote end to form an inbound word. The load transaction sends words of x0000 to the other end but receives back the contents to be written into RAM, except that during the checksum word, the penultimate word in the transaction, we ship our calculated checksum at the same time that we receive the checksum which will come from the Arduino.

RAM activity during load

Further zooming shows us the action after we have acquired the inbound word, where we trigger this being pushed into the FIFO to the RAM engine, see the signal to the memory controller which write the data into RAM, then see what is pushed into the response FIFO to indicate the memory activity is complete.

I moved on to the unload transaction. This one will read all the words from RAM for a given cylinder, head and sector location, passing them back to the Arduino one by one. My fake memory module which was substituted for the actual memory controller in order to simulate, provided a known sequence of 8 words that repeated to permit me to validate that the logic sent those up to the Arduino correctly.

A sector unload transaction begins

The unload transaction above involves fetching words from memory before each word is exchanged on the SPI link, whereas the load transaction above first grabbed a word and then sent it to memory. The relative timing is visible in the above and the following traces.

A word being unloaded

Narrowing the focus lets us see one word which is fetched from RAM on the left then toggled out on the SPI link. The checksum at the bottom is updated based on this word, giving us a running checksum that covers the entire 321 words of the sector. 

RAM during unload

Our command sequence for the memory access is appropriate for a read, where we pass along the addresses of the 8 byte grouping that are read as a burst by the DDR3 memory controller, then wait for the data valid signal from the controller which indicates we can now grab the contents off the app_rd_data bus. For simplicity of my design, I put the same data in all four words (8 bytes) and pick off just one of the duplicated words on a read. 

I then simulated a sequence of two transactions, one each unload and load, to verify that the state machines restore properly to handle multiple transactions from the Arduino. 

Two transactions serially

At this granularity, you can't see the individual words but the start and end of the successive transactions is evident. This ends my simulation testing of the FPGA unless I discover issues once I am connecting it to the Arduino over SPI and to the disk drive electronics in the IBM 1130. 

HARDWARE MODIFICATION TO ARDUINO NECESSARY

The Arduino Mega 2560 has a chip with a primary SPI channel which can be either a master or a slave. However, the chip itself has four serial port channels which are capable of being operated as SPI masters, but not slaves. It is a simple matter to set up the port for this mode and to exchange words using it, except for one minor issue.

The designers of the Arduino board did NOT bring the clock pin of any of those serial channels to any pins on the board. Thus, while the port can be made into an SPI channel it can't be used as the wire can't be connected to the Sclk pin. 

I worked out a way to tack a wire onto the pin on the chip that carries Sclk for one of the serial ports, the hook the other end to a connector pin on the board. In order to do this, I need to disconnect the original signal line for the pin I choose, then tack on the wire from the Sclk signal. I have worked out a candidate but haven't yet implemented this.

When I am next in the shop I will use the microscope to break the sacrificial connection, then tack on the jumper wire to bring Sclk to that external connector pin. This will allow me to use one of the other serial port channels for an SPI link to the FPGA, reserving the primary SPI link for its connection to the SD card shield where I host the virtual cartridge images.

The software to access the SD card shield assumes it is the only device on the SPI link and does not play well if a second device is sharing the channel. This in spite of the use of individual Slave Select lines for each of the multiple devices sharing an SPI channel, since it is the software that gets confused not the hardware.