Debugging work on the seek issue with Virtual 2315 Cartridge Facility in real mode

NEED TO NARROW DOWN POSSIBLE DEFECT LOCATIONS

It is possible that something in the signal returning from the 2310 (13SD) disk drive inside the IBM 1130 is inducing the errors. The drive modulates the signal +Access Ready to indicate when it can accept seek commands, dropping the signal to low for part of the actual arm movement. If this behaves weirdly, it might cause the 1130 disk controller logic to malfunction. 

The seek is begun when an XIO instruction is issued pointing to an IOCC with a type of Control for the unit address of the internal disk drive. Bit 13 of the IOCC second word determines the direction of the arm movement, with a 0 moving the arm towards higher cylinder numbers. The first word of the IOCC is the count of the number of cylinders to move. From when the XIO instruction is received until the end of the entire seek operation, -Access Busy is asserted by the 1130 disk controller logic. 

The disk controller logic issues +Access Go to the 2310 drive asking it to move the arm in the direction we set from bit 13 and for a step size of either 1 or 2 cylinders - 10 or 20 mils. The drive begins the movement. It drops +Access Ready about 5ms after it begins and keeps it low until a total of 15ms has elapsed. 

When +Access Ready becomes low, the +Access Go signal is removed. When +Access Ready again goes high at the end of the step, if the Word Count (WC) register is not all ones, +Access Go is again asserted to make the next step.

The WC register is loaded with the 1s complement of the seek count from the IOCC. It is incremented as each +Access Go is raised, increasing by 2 in all cases except the first step for an odd seek count. Bit 15 of the WC register is the step size signal, choosing either 10mil or 20mil. If the low order bit of the seek count is 1, Bit 15 is off but it is forced to 1 by the next assertion of +Access Go so that all subsequent steps are 20mil. 

When the WC register gets to all ones, the arm has been moved the number of cylinders requested by the IOCC. This blocks the assertion of +Access Go thus no more steps are taken. As +Access Ready goes high after the final step, it turns off  -Access Busy and turns on Operation Complete. 

This condition requests interrupt level 2 and when the software subsequently senses the device status (XIO instruction for disk unit number with type of Sense and reset bit turned on), Operation Complete is presented to the 1130 and simultaneously reset in the disk controller logic. Operation Complete also resets the WC and other registers since the seek operation is over. 

The WC register logic is where the value is incremented, where the step size is determined and what tells the logic that our seek operation is complete. All of this is implemented on a single SLT card, 6220, which also handles some other disk related functions. Thus my first suspect for the defect is within the 6220 card, but if the +Access Ready signal is wonky that might induce misbehavior inside the 1130 disk controller logic, so the disk drive is an alternate suspect. 

ADDING CHAIN OF FF TO AVOID METASTABILITY ON INCOMING SIGNALS

I had previously assumed that the pure multiplexers used to assign signals coming in from the 1130 or 2310 to outputs wouldn't suffer from metastability problems, but these are external signals that could be changing unrelated to the clock edges in the FPGA. Even though the multiplexer controls are switched before startup and not dynamically, if IceCube2 somehow introduces any clocked element in the implementation an issue could arise.

I set up chains of four flipflops per incoming signal in the switching module bus_outputs.v and passed along the output of the chain to the next destination. This will delay the signal by 50 nanoseconds but that shouldn't cause any problems. 

OBSERVATIONS WITH NEW VERSION OF FPGA BITSTREAM

I loaded the new bitstream that implemented the metastability protections for incoming signals into both Virtual 2315 Cartridge Facility (V2315CF) main boxes. I used the scope to watch various signals coming from and going to the 2310 disk drive and/or the IBM 1130 disk controller logic. I did this for a simple seek of 1 cylinder forward from home.

I can see that bit 15 of the WC is dropping as soon as  +Access Ready goes low not at the end of the seek operation. This is why my code is getting fouled up - it sees a changing or changed value, not the one that would command the 10 mil step. 

The purple trace is bit 15 - when low, it requests a 10 mil step. The yellow trace is +Access Go triggering the seek. Green is +Access Ready, which we see dropping just as bit 15 flips to 1. Bit 15 is also called -10 20 Mil to reflect its role as the step size. 

RESOLUTION

I changed the design so that it holds the value of the step size (and direction of motion) right at the moment that + Access Go is asserted, so that it uses the saved value when +Access Ready goes low and then returns to high at the end of the movement. After loading the new bitstream into the FGPA, the tests worked well. I can begin to run the disk function diagnostic (309).