Step one in tightening up the WriteSector process is to draw up a precise timeline of the timing of each word to be written, relative to the sector mark at the beginning. I sat down with that timing and the test bed to capture and check everything against the list.
Anywhere there is a discrepancy, I can sort out the cause and correct for it. The objective is to have the sector end 3.120 us after the SM, which gives a comfortable margin within the 3.333 us sector duration.
I worked through the process, trimming excess cycles and ensuring I got the data lined up as close as reasonble to the ideal times. First step was to ensure that the header record was correct, a preamble of 34 word times of zero, a sync word of 0001, two header words of 0000, a checksum word of 0151, and five postamble words of 0000.
Early on, I had the data complete within the sector, but at this point I am checking even more rigorously, ensuring that the transitions match what should go out at all key points. The 1 bit that forms the sync word is occuring just a few hundred nanoseconds late compared to the ideal time, essentially spot on.
I decided that I need a status warning if the WriteSector ever does span past the end of the sector, putting bit 3 of Reg0001 to that purpose. I also set up the WriteField FSM to restore itself if the SM occurs, making this error recover the logic to accept subsequent transactions.
However, when verifying the timing, I was looking at the data coming out and see that I am misaddressing memory, essentially reading the wrong words from RAM. I spotted the flaw and corrected it.
After lunchtime, my testing had verified the timing all the way through the end of the second (label) record of the sector, to the tenth of a microsecond of what was expected. At this point, I brushed against the button to trigger a read of a sector, which gave me the data but triggered a powerdown of the disk drive.
Thinking about this, I may be causing it by modulating the WriteData&Clock signal without WriteGate active, particularly if after the final transition I leave the line at 1 instead of zero. The rest state of that signal should always be 0, but there was a condition where the WriteGate gets turned off and the transition state engine didn't stop with a 0. I corrected that.
After the obligatory 30 minute idle time while the toolchain worked, I fired up the testbed with the corrected logic and resumed testing, this time verifying the postamble and preamble between the label and data records.
All is perfect - timing within a tenth of a microsecond, data looks perfect, time to allow WriteGate to switch on the write electronics and try writing the contents of sector 0 from the disk archive file. Taking the mandatory 30 minute timeout then will attempt to write the sector and read it back to see if it appears good.
I performed the WriteSector transaction with the WriteData&Clock signal modulated and WriteGate turned on, but it didn't appear to do anything. Time to check on the delivered signals on the drive, ensuring that it did see the WriteGate activate and see the incoming transitions. I will have to find an appropriate place to hook up the scope.
There is an option on some Diablo drives where the EraseGate is an independent signal, instead of tied to the WriteGate in the standard models. Diablo does not mark which options are installed, thus the only way to tell is to examine circuit boards and wiring - quite annoying.
If it is separate, then I am not energizing it with the prototype board although the production board I built will drive it. I will hold off to test this until tomorrow, since I have to study schematics and find test points inside the drive to verify whether erase current is flowing and whether the write signal is passed to the heads.
No comments:
Post a Comment