I have some Sparkfun bidirectional level shifters that claim to support high frequency signals, which I decided to check before I tested the simpler resistor voltage divider network. I drove them with a 2MHz signal from the Digilent Analog Discovery module, using +5 and +3.3 power supplies.
|Using the AD to generate the square wave signals for testing|
The output waveshape followed the input very closely up to 2MHz, but did round off unacceptably up at 5Mhz which is far beyond the 1.6MHz operating rate of the disk drive interface. The artifacts I saw were ringing at the upper and lower flats of the signal, but very sharp rise and fall times with essentially no change in pulse width.
Just to be certain they work properly as uplevelers, I swapped the input and output, set up the Analog Discovery to produce a lower voltage swing and looked at the high level output. My first attempt, providing a 2V input swing with 3V low power produced just a 2V high side swing, with 5V supply, which is wrong.
|Four channel up/down level shifting board from Sparkfun|
I discovered that the +5V reference voltage was not connected properly. Retesting, I found that the signal did not get higher than the input value when running at 2MHz, but at substantially slower speeds, for example 100KHz, the signal pulled all the way up to 5V. The capacitance in the leads, MOSFET and the relatively high 10K pullup resistance results in this frequency limiting behavior.
I wired in a 1K resistor in parallel with the onboard 10K, thus increasing the draw on the power supplies but also hopefully hastening the pullup effect. I turned it all on and tested again. At 1MHz, this gave me very nice 5V signals with full pulse width. Still, at 2MHz, the rise from 4 to 5V was slower and the effect was a shorter on pulse.
I learned a bit more about the Analog Discovery, including the fact that I could set up the waveform much more granularly, so I then did my final testing with 5V or 3.3V swings on the signal and a frequency of just over 1.6MHz.
I believe I can drop the resistance further to get acceptable operation at 1.6MHz, with the circuit pulling 10ma from the rails. If this is in spec for the devices on the board, and safe for connected disk drive circuits, then I can ensure good high speed pull-up by adding parallel 500 ohm resistors.
Using a 500 ohm parallel resistor does produce exactly what I want - essentially identical input and output waveforms, if you ignore a bit of ringing caused by the rough breadboard testbed I set up. I tried it for both up and down shifting of levels with excellent results both ways.
|Uplevel - yellow is 3.3V input at 1.6MHz, blue is 5V output|
|downlevel - yellow is 5V input at 1.6MHz, blue is 3.3V output|
I did more work on the new FSMs - 'update data record of sector' and 'update label and data records of sector' - including better integration of these multiple FSMs sharing the Read Field and Write Field FSMs that do the work on the individual records of a sector.
Once all the coding work is complete, it will be time to test it all out including regression testing of the read sector and write sector machines. Since the update machines involve a mix of reading and writing, depending on the record in the sector,
I will make use of the data I set up in the testbench where I originally tested by read field and read sector logic. This way, I can see that it is properly reading the records before the write gate switches on and I begin 'writing' transitions to the disk.
I would need to build only two more major FSMs - 'read a cylinder' and 'write a cylinder' that will step through all 12 sectors of the current cylinder for each of the two heads. These will take at least 80 ms to complete, two disk rotations, plus the need to wait for sector 0 to arrive at the start.
Since on average we wait 20ms for our intended sector to come under the head, for a randomly issued read or write, it would take an average of 566 ms to read a cylinder in 24 separate IO commands, versus just 103 ms average to do this with the full cylinder FSM.
That comes to just 21 seconds for all 204 cylinders, ignoring the seek time to step 203 times. A seek of one track takes 15ms, so about 25 seconds would capture or write an entire cartridge. Reading an entire cartridge using individual read sector commands (4,896 invocations) would take about two minutes.
I am not convinced that this is a priority, since an entire cartridge can be read in 2 minutes without this work, only a 5.7x speedup on an already acceptable time. Thus, I will instead work on the final linkage of the read, write, seek and update machines to the transactional registers coming from the PC, so that this will be ready for use on the Diablo drive.
I picked up two components that fit together to allow me to hook my 136 channel logic analyzer onto a SCSI bus and capture the signals during use. I have a couple of SCSI based 9 track tape drives that I would like to interface to my fpga based unit that adds peripherals to my IBM 1130 system.
However, I don't have any logic to drive a SCSI interface and I couldn't find any open source, no cost logic that I could leverage. This tooling will help me design my own SCSI driver for the tape drives.