Finishing the drive modeling and simulating as I go

ARM MOVEMENT MODELING FULLY TESTED

I put the logic through its paces with simulation to ensure that I will properly capture the position of the arm (cylinder number) at all times. During the course of this work I discovered a signal I need to capture that I had not built into the original plan. This is +Access Ready which goes low then back high for each arm movement. With that signal I can properly interlock my logic to ensure I capture exactly the right number of moves. 

BUILDING LOGIC TO PULL WORDS FROM RAM AND EMIT BITS TO THE DRIVE

As the rotational model reaches the time when each word of the 321 words in a sector is complete, it bumps the word counter and that serves as my signal to fetch the next word from RAM so that it can be fed bit by bit to the drive circuits that process the read head signals. 

From the time I see the bump occur to the next word, I emit the 16 bits of the data word, with the low order bit output first and moving sequentially up to the high order bit 0. Each bit of the data word is sent with a 1 pulse during the first 700ns and then the value of the bit as a pulse in the second 700ns interval. Together the 1.4us represents one bit cell on disk as either a pair of bits or a bit plus an absence of a bit. 

In addition to the 16 bits of data I am writing in the 16 bit cells, there are four check bits sent at the end of each word. The error checking scheme is to have the number of 1 bits be evenly divisible by four. Thus, depending on the count of 1 bits in the word itself, we write 0000, 1000, 1100 or 1110 as the last four bit cells. 

SKETCHING OUT CAPTURE OF WRITTEN DATA

Capturing the data involves detecting when the CPU believes it is emitting a clock bit and when it is sending a data bit, so that I can assemble these into a word then push it into RAM. To do this, I realized I may need both clock signals the drive is generating for writing - phase A for the clock bit and phase B for the data bit. I added the phase A which was not in my original plans.  When WriteGate is activated, the drive begins to emit the clock signals and writes the clock pulse and the data 1 bits to the surface immediately. The scheme for encoding bit cells is to have the two phases, A and B. A flip of the magnetic field is always written during the A phase,  but a flip is only done in the B phase if the data value is a 1. If the data value is 0, nothing happens on the disk surface. 

This makes it impossible to recognize when zero bits are being written other than to see the clock bits (A phase) and note the absence of a pulse for data. Having the two clock phases in my circuit ensures I will know for certain what pattern of bits is being written onto the disk surface.

Since, however, the heads are not loaded on the disk surface, we have to capture the bits and update RAM to keep our virtual cartridge reflecting what input-output has taken place. Writing the word to RAM will take place after the 20 bits have been captured coming from the CPU, whereas my reading logic reads the word from RAM before it begins streaming the 20 bits to the CPU. 

This implies that my state machines must issue RAM access requests at different times for read versus write. There is a similar duality with the SPI link between this FPGA and the Arduino - data downloaded from the SD card file to the RAM is captured at the end of a word transaction on SPI, while uploading changed content from the RAM back to the Arduino has to set up the word before the word transaction begins.