Deglitching the write output of the 1130 for Virtual 2315 Cartridge Facility - part 1

EVALUATING STRATEGY FOR DETERMINING BIT VALUE

The IBM 1130 writes to disk alternating values on the -Write Clock and Data signal line, with a 0 always written to -Write Clock and Data during the first half which represents a self clocking pulse and then writing the inverse of the bit value during the second half. The two halves are 1.38 microsecond intervals driven by the 720KHz clock produced by the internal disk drive. That self clocking signal, delivered on the -Write Clock Phase B signal line, is 0 during the clock (first) half and then 1 during the second half when the data bit value is written.

The logic in the IBM 1130 that produces the -Write Clock and Data line is combinatorial, driving a 0 value while the -Write Clock Phase B is 0 and then outputing the current bit value, inverted, while the -Write Clock Phase B is 1. However, there are glitches produced because this is not generated by clocked logic, so time delays in signal propagation produce some glitches that are too fast for the internal disk drive circuitry to react to. 

During the low phase of -Write Clock Phase B the output of -Write Clock and Data is low. In the high phase of the clock, we drive -Write Clock and Data low during a write in one of two cases, represented by the two A (and) gates on the left. The bottom one takes the bit being shifted out of the data register during the first 16 clock cycles of a word. 

The top one is used during the last four cycles, those that will produce the error checking code. As long as the total count of 1 data bit values sent is not an even multiple of four, -Zero Check Count is high causing the -Write Clock and Data value to be low producing a 1 bit. As soon as the total count becomes 0 modulo 4, -Zero Check Count is low which blocks the upper gate from emitting any further 1 bits. The remaining ECC bits are therefore seen as 0. 

Other factors contribute to glitches as well during the data (second) half. Any glitch in the -Write Clock Phase B signal as received by the 1130 will falsely flip the gates to pass through a 1 as if it were the clock half instead of part of the data half. A signal flaw in -Write Clock Phase B produces a spurious 1 bit value if it happens when we are evaluating the signal -Write Clock and Data as the data bit value. 

To bolster the reliability even further, I introduced a method that could block the effect of most short term glitches. When the -Write Clock Phase B rising edge occurs, we begin counting all the FPGA clock cycles (one per 25 ns) where -Write Clock and Data is low, that is has a bit value of 1. When we get to the end of the data phase and -Write Clock Phase B has dropped to low, we judge if we saw a 1 by whether the count of cycles with a 1 detected is more than 15 out of the 29 cycles during which the data value is being transmitted. 

I found a theoretical vulnerability in how I implemented the detection algorithm. If we have a glitch in the -Write Clock Phase B such that it drops low for a cycle or two when we should be in the data phase, this can interfere with the counter mechanism I used. I reset the count when I see a rising edge of the clock; if we had a glitch that dropped the clock and then it goes back to its correct high value during the data phase, the counter gets reset to 0. If the glitch happens later in the data phase, even with zero glitches during data we can't count high enough to meet the bar for detecting that the data bit value was 1. 

Late glitch guarantees bit value seen as 0

The graphic above shows the -Write Clock Phase B signal, where the high portions are when we should be looking for a low value on -Write Clock and Data to count it as a possible data bit of 1. When a glitch happens relatively late in the high portion of the clock, the count is reset and cannot count high enough to achieve the minimum of 15 detections even if the data signal -Write Clock and Data is low for the entire time of the clock phase. 

The reality for this project is that I generate the -Write Clock Phase B inside my FPGA, thus I do have a perfect internal clock that I can use to drive the decoding. This reduces the impact of glitches, as they are only seen on the incoming -Write Clock and Data line. These can be induced by glitches in the -Write Clock Phase B as it is used inside the IBM 1130 disk controller circuitry, but that is the purpose of my counter and threshold logic. 

EXAMINING LOGIC ANALYZER OUTPUT TO EVALUATE METHODOLOGY

My current design looks at the value of the -Write Clock and Data signal at the time that the -Write Clock Phase B signal has a falling edge. If -Write Clock and Data is low, I record it as a bit value of 1, inversely a high signal denotes a bit value of 0. 

I converted the logic analyzer data to a spreadsheet,  hiding all captures except when the -Write Clock Phase B signal changed from 1 to 0. I took the inverse of the -Write Clock and Data signal as the bit value. After the correct interval for a string of all zero bits, I saw the proper sync pattern which is a 1 bit followed by the four ECC bits of 1 1 1 0 and thus could interpret all the following data bits as words. 

I recorded the bit values as they would be interpreted by my logic, counted the number of bits in each block of 20 that had a value of 1, and checked that this count was 0 modulo 4 which is the error checking algorithm. I also verified that the data that would be captured was exactly what was in memory when I issued the XIO Start Write command on the IBM 1130 to do the write. 

It all looked as if it would be perfectly recorded using the algorithm, in spite of the fact that the V2315CF was flagging an ECC error on the read. The timing was correct as well - the entire sector of 321 words took 9.311 milliseconds from the beginning of the first word until the end of the final word (321). With 10 ms available for a sector, this was exactly what I would expect. I also checked the time between words.

To help evaluate what is taking place, I temporarily blocked the ECC error flag from triggering a disk fault. That will allow me to read back what we wrote and compare it. If I see any words that don't match what I had in memory for the write, that may suggest where to look further. I also brought the ECC error detection signal out on the main V2315CF box on connector B pin V2 so that I can spot it on the scope and logic analyzer as it is turned on. Next session I will make use of this modified logic to test how well my logic does the job and whether there are any further subtleties I need to address.