MORE OBSERVATIONS OF SIGNAL FOR A SEEK WITH AN ODD COUNT
I used my hand programmed code to make several seeks of different lengths in order to watch what the disk drive itself as well as the V2315CF logic saw. For example, when I requested a seek of 161 tracks, it should have stopped the disk arm at 161 and reported 161 on the V2315CF log. What I saw instead was the arm stopped at 141 and the log was also not reporting 161.
I then set up a longer seek to 193 from the home cylinder, with the drive appearing to be at 167. Requesting 81 from the home cylinder left the arm at 77 but the V2315CF believed it was at 76. A seek from home to 41 put the arm at 37 and the V2315CF reporting 36. A seek of 21 put the arm at 17 physically and the V2315CF believed it was 16.
ANALYSIS OF THE OBSERVATIONS
There are three entities that could be defective - the 1130 disk controller logic, the V2315CF logic and the disk drive. I am still not certain which is wrong, but the discrepancy between the drive position and the V2315CF position tells me that I have a problem in my logic in addition to whatever is happening elsewhere.
I could have problems with the interface signal integrity since the V23215CF sits between the disk controller logic and the disk. While the design intends to pass the signals through between the two, if there are signal issues that might throw off the way the two sides interact.
The interface between the two sides is very simple. The controller logic sends three signals to the drive and the drive responds with two signals. Only those five signal wires are involved in seek operations. The outbound signals are:
- -10/+20 Mil Step is a signal that requests moving 1 or two tracks
- -Rev/+Fwd is the direction of the movement relative to track zero
- -Access Go is the request for a seek movement
The return signals from the disk drive are:
- +Access Ready is the feedback, goes low 5 ms after a seek request and returns high by 15ms
- -Home reports low when the arm is at track 0 (home)
The details matter in terms of timing and behavior both inside the disk drive electronics and in the 1130 disk controller logic.
Timing inside the disk drive
When -Access Go drops to low, the falling edge sets a go latch inside the disk drive which begins some timed operations. The state of the -10 Mil and -Rev signals determine the movement direction and size and are held steady during this part of the seek.
A timer of 2.6 milliseconds expires before it begins actual movement. The detents are removed from the rack teeth during this time, which would allow the arm to move freely. If the -Access Go edge is at T-0, this runs to T-2.6 ms.
Depending on whether it is a 10 Mil or a 20 Mil step, a timer then runs for 2.4 ms or 3.8 ms. It runs twice, first accelerating the arm and then decelerating it to a stop. That is, the acceleration is from T-2.6 to T-5 ms or T-6.4 ms depending on step size.
At the end of the first 2.4 or 3.8 ms interval (acceleration) the signal +Access Ready drops to low. This resets the go latch. The signal drops at T-5 ms or T-6.4 ms. It also flips the active detent at this time, toggling between even and odd if the step size was 10 mil or not changing if the step was 20 mil.
During the second 2.4 or 3.8 ms interval the detent begins to engage and the arm stabilizes its position, coming to a stop by the time the tooth engages the rack to hold the position. Thus by T-7.4 ms or T-10.2 ms, the arm is stopped.
At the time that +Access Ready dropped, at the end of the acceleration, the drive also begins an approximately 10 us timer at the end of which it restores +Access Ready to high. The entire seek timeline runs from T-0 to T-15 or T-16.4 depending on the step size.
Timing in the disk controller
The disk controller begins a seek during an XIO instruction, setting the counter of how many tracks to move and the direction of movement, asserting -Access Busy for the duration of the entire seek. It then repetitively issues seeks of 10 or 20 mils until it has counted out the total movement. At the same time as -Access Busy goes low, the access drive latch turns on.
At the completion of the full number of tracks from the XIO instruction, it pauses for an additional stabilizing interval of 22.5 ms then turns off -Access Busy and turns on Operation Complete to request an interrupt on level 2.
Once the -Access Busy in the controller goes low and turns on the access drive latch, the logic asserts -Access Go to the disk drive. The direction is held steady for the entire duration that -Access Busy is low. However, the step size -10 Mil signal is determined by the value in the count register in the controller and thus may change between the first step and the remainder.
The low bit of the count, which is inverted in ones-complement from the seek quantity of the XIO instruction, determines the step size of the first step. If the count is odd, then the inverted low bit will be a 0 which makes the -10 Mil Step signal request a 10 mil step. After the first step, the low bit is forced to a 1 thus every other step is going to be 20 mils. Each time the access drive latch is turned on, it adds to the count register in the controller, adding two except for the first step of an odd count which effectively adds one.
When the signal +Access Ready from the disk drive goes low, it turns off the access drive latch and returns -Access Go to high. We wait until the disk drive completes the seek step, which it signals by returning +Access Ready to high.
The rising edge of +Access Ready will turn on the access drive latch again unless the value in the count register has reached all 1s, meaning we completed the full count requested by the XIO. Turning on the access drive latch means we assert -Access Go again for the next step. Thus, this logic iterates steps of the drive.
Glitches may confuse the interlocked logic of the drive and controller
If the +Access Ready bounces back high right after it goes low when a seek step is active, the controller might turn on the access drive latch incorrectly, also incrementing the count register incorrectly. The drive won't move because it ignores a falling edge on -Access Go if +Access Ready is not high. Since +Access Ready is generated internally to the disk drive it has it low during the seek when the signal bounced as seen by the controller. Thus the drive ignores one of the movement requests because it is sent at the wrong time, while the drive is actually still busy moving.
The rate of glitches on that line, if that is what is going wrong, has to be relatively low since most of the movement is completed successfully as far as the V2315CF and the disk drive is concerned. Short total counts are close, the discrepancies grown with long counts.
HARDENING V2315CF TO BE ABSOLUTELY CONSISTENT WITH THE DISK DRIVE
I am concerned that the V2315CF is off by one when the controller is moving an odd number of tracks. I suspected that it is the timing of when I capture the step size, since the -10 Mil Step signal comes from the count register and that is incremented just as the -Access Go signal is asserted low. Since I wait to grab it until +Access Ready drops, it has already changed and will always be seen as a 20 mil step size. That means I am also missing one step entirely since the count is low not high by one.
I had previously added a kind of Schmitt trigger as a debouncer for the signal that drives my seek shadowing. My logic tried to minimize the risk of bounces/glitches on the +Access Ready signal by requiring 10 cycles of a steady signal level before I acted on it. However, that gives the counter time to be incremented in the disk controller and for the -10 Mil Step signal to rise so that I no longer captured the signal state when the seek step started. I removed that from the logic so that I grab the step size immediately on the falling edge of -Access Go.
TIMING RACE CONDITION POSSIBILITY TO CONSIDER
Because the V2315CF must operate in two modes - real and virtual - I was passing the seek signals through the V2315CF. This means that I had to eliminate metastability risks on the input to the FPGA for each of those signals. That adds four FPGA clock cycles before a signal is passed along, 40 nanoseconds of delay.
The interlocked behaviors from the two sides would typically occur much closer together, but a sequence where one side sees a signal change (e.g. +Access Ready drops) and then changes an outgoing signal (e.g -Access Go rises) will take 80 nanoseconds longer or more than the direct wiring without V2315CF.
At this time, I can't imagine how that would cause a problem. Therefore I am left with two broad categories where the cause may lie. First is some hardware failure in the 1130 controller logic, the other is a signal integrity issue over the wiring between the 1130, V2315CF and disk drive.
NEXT DIAGNOSTIC STEPS
I want to identify which of the categories is our problem. I will start by wiring up the logic analyzer to the signal pins on the IBM 1130 gate A compartment C1 where the controller logic lives. I am practically limited to capturing 16 signals at a time.
I will try to record a long seek and capture all the -Access Go and +Access Ready signal interchanges. I should see if there are the correct number of seek steps commanded and perhaps spot anomalies that might be triggering errors. Another set of signals I will record are the nine bits of the counter, so that I can watch it count off the seek.
If I see the count change at the wrong time, or see it miscount, it can steer me closer to the root cause.
No comments:
Post a Comment