Debugging 1130 disk controller logic concerning -write gate malfunction part 2

WHAT I OBSERVED MONITORING THE SIGNALS INVOLVED IN -WRITE GATE

In my last post I discussed the circuits that generate the -Write Gate signal from the IBM 1130 disk controller logic that is continually triggering my Virtual 2315 Cartridge Facility (V2315CF) to perform a write. I can see the signal is at logic low level but it should not be until the short time when the 1130 has executed an XIO Start Write instruction and the virtual disk rotates to the sector that is requested in the instruction. Otherwise it should be high. 

This turned out to be an issue with a cable not fully plugged in. Once I discovered this and monitored the write select latch, I saw it correctly turn on when the virtual disk platter entered the requested sector and it turned off at the end of the write operation, simultaneous with it raising a request for a interrupt on level 2 to indicate the completion of the operation to the 1130. 

TESTING A WRITE RAISED A DISK FAULT ERROR

My logic captures each word of the sector as it is 'written' by the IBM 1130 disk controller logic. Each word from the 1130 is followed by four error checking bits. The error checking bits are used to validate that the number of bits with a 1 value are an even multiple of four after counting all 20 bits - 16 for the data in the word and the 4 error bits. If this check fails, I report an ECC error on the write and turn on the disk fault latch. 

The V2315CF lights the FAULT indicator and locks out any further operations on the virtual 2315 disk cartridge when that happens. I have to unload and restart the virtual disk drive to clear the lockout. 

I put the logic analyzer on the signals coming into the 1130 disk controller to see what was coming out of the 1130 that my logic will have to decode to capture the data being 'written' to the sector on the virtual disk. Based on that I was able to figure out a better way to grab the bit values, based on what was actually emitted by the 1130. 

I updated the logic of the V2315CF and changed the simulation to match the relative timing of the signals that I observed coming out of the 1130. When it was all working as intended I created a new bitmap to load into the V2315CF. Next session will see how it works. It does appear that read and seek are solid, thus this is the last bit of the functionality to iron out.

RESTRUCTURED FPGA CODE FOR V2315CF

When external signals are used in a clock synchronous circuit such as an FPGA, the risk of a signal transition almost exactly at the same time as a clock edge must be managed. When an input to a logic gate changes too close to the clock, the flipflop can assume an intermediate metastable state which is not valid for use by the following logic elements. 

To combat this, a chain of several clocked flipflops is used to reduce the chance of a metastable output to near zero. In most of my designs, this is a series of four in a row, using only the output of the fourth to drive my subsequent logic. This synchronizes the input to the clock domain of the FPGA. 

The IBM 1130 and 2310 internal disk drive signals are unsynchronized with respect to the FPGA clock thus they need this processing. There are 17 input signals to the V2315CF of this type. I had scattered the synchronization chain for the input signals among the various functional modules in my FPGA code. In a couple of cases, I noticed that this would take a signal already processed by one chain and pass it through a second chain of four clocked flipflops. 

I decided that I would create a serializer module to implement the four clocked flipflops and instantiate that for each input signal in my top level verilog code, rather than embedding it througout the various lower level modules. The 15 serializer instances ensure that any signal that is used by any logic in my code is properly synchronized and has the risk of metastability properly managed. 

A chain of flipflops to synchronize a signal like this is coded in verilog as a four bit vector, e.g metasignal[3:0],  inside a clocked loop. On each cycle, the vector is shifted left one bit and the input signal is added to the end. The first position is therefore the fourth flipflop in the chain and that is the output to safely use. This does create code that refers to the signal after synchronization as something like metasignal[3] which is less intelligible than if a simple signal name were used. My serializer produces a simple name for the output, hiding the four bit signal vector inside the serializer, thus making my code easier to read. 

The logic had done edge detection of signals by comparing the value of metasignal[3] to metasignal[2], but that takes away one flipflop from the synchronization when looking at metasignal[2]. After my restructuring, any logic that needed to detect an edge would be saving the output of the serializer on each pass through a clock loop and comparing the current serializer output to the saved output of the last pass. This means that both signals had at least four passes through the flipflops. 

I ran all my simulation testbenches against the code to ensure that I didn't make any errors when coding edge detection. Once everything was meeting my requirements and working properly, I put the restructured logic bitstream into the V2315CF FPGAs.