Part of the cause is the timescale for the disk drive itself, which must be modeled accurately in order to verify the correct behavior of my design. One rotation of the disk takes 40 milliseconds, with a sector pulse occurring once per 5 milliseconds and the sector which will be read spread over 10 milliseconds. With an approximately 500,000 to 1 ratio for simulation, this means that the sector itself runs for 1 hour and 24 minutes on my laptop.
My logic begins reading sector 0 thus the time it takes spinning the disk until sector zero begins might be as much as five hours and thirty three minutes if the simulated disk rotation is just inside the start of sector 0 when my logic starts looking.
In addition to all of this, there is a delay of about 120 microseconds for the RAM controller to initialize and calibrate (at its "fast" setting to decrease simulation delay), which means one minute of wall clock time before my logic comes out of reset and begins looking. In comparison to the other delays, this isn't very significant however it means that if the simulated disk sector signals began with sector 0 at the start of simulation, it would be 1.2% through the sector by the time my logic starts up.
The logic for identifying the sector which is under the read/write head is to reset the upcoming sector count to zero when the index pulse occurs, once per 40 milliseconds, then advance the upcoming sector count on every second sector pulse (two sector pulses per 10 ms sector). The sector begins with the first sector pulse after the index pulse and on every second sector pulse afterwards.
On the actual disk controller logic, it requires one full rotation of the disk before the sector counter becomes accurate, having seen the index pulse. My logic starts with the upcoming sector count set to zero by design, but that will give a wrong sector number if the index pulse I generate in the testbench is not synchronized to happen with the proper sector pulse.
METHODS TO SHORTEN DELAY BEFORE WE START READING A SECTOR
One method of shortening the delay would be to start up with faster sector and index pulses to step the upcoming sector count to that it was back to 0 before my logic starts watching for the next proper speed sector pulse. I worked out a set of pulses at 100x speed, thus shortening the wall clock time for a disk rotation to three minutes and 20 seconds. That would allow a reasonable wait to have the disk come around to where sector 0 starts when my logic is watching to begin the read.
An even better method is to set the sector and index pulse generators so that the index pulse is assumed to have happened before the RAM controller finishes initialization and the sector pulse begins shortly thereafter. If I have the pushbutton simulated to start the archiving just before the sector pulse above, then the logic will see sector 0 arriving and start the read with minimal delay. The sector and index pulses occur at normal speeds, with the first index pulse at around 40,720 us into the simulation.
COMPLICATIONS ON FIRST FEW TRIES
I had to get the logic to trigger on the first sector pulse, which involved logic in the design that was in a starting state and expecting some sequence of changes before it began the read operation. First I drove a very short index pulse to set the upcoming sector number to 0. However, it still didn't start.
Next I looked into the archiver module logic and see that I have to detect a change of sector number signal, where the upcoming sector number matches the target sector for our read, before we begin the read operation. The starting state of my logic has the prior sector number set to 0, which is also the starting state for the target sector, thus no new sector signal.
After one complete rotation of the disk platter, the prior sector number would have been 3 and the change to 0 would trigger my code. This would work in actual practice, allowing the logic to really sync with the sector coming under the read/write head having seen an index pulse and a chain of eight sector pulses. In simulation that process would be more than five hours of wall clock, a penalty I don't want to incur.
I modified the code temporarily to set the prior sector number at startup to 3, thus triggering the new sector state and the start of the read as soon as the first sector pulse completes. This was my intent in order to watch how a sector read behaves.
GOOD START TIME FOR SECTOR READ ALLOWING ME TO STUDY LOGIC BEHAVIOR
Expecting a tolerable duration per simulation run, I watched an entire sector read take place, expecting it to take about an hour and a half of wall clock time. Apparently the simulation ratio depends on how rapidly signals change and the number of signals being monitored, as this instead took more than three hours to complete.
The simulation run proved the correct operation of all the logic involved in writing the detected words from the read head into the DRAM. It let me examine the addresses used with DRAM to be certain the data is stored where I expected it to be, the data flowing into the DDR3 chip signal lines, and verify the behavior of all other signals during this time.
When I was satisfied that the first sector was read properly, I temporarily modified the archiver to begin by requesting sector 1 instead of zero. That required me to wait a few hours to see the read begin at the start of the second sector, but it was a one time test I could do near the end of my simulation testing campaign
No comments:
Post a Comment