I was exhaustively debugging the new version of the 1130 built to ensure clock synchronous operation of flip flops and other state changes because fpga behavior is just too challenging to tame otherwise. Everything was going well, with excellent repeatibility and control of processor operation coming from the shift, but from time to time I would find signals that were arriving a bit late due to the fpga 20ns clock cycle delay imposed each time I forced clock sync behavior.
The 1130 is a much more asynchronous machine at heart, using edge triggered gates that would activate some state change as soon as a designated input signal changed state - instantly and directly change. As such, some logic will have a set of edge triggered gates, which in the real machine impose a small gate switching delay but that doesn't matter, even if you pass a signal through several of them, because when it eventually gets to a place where it needs to act, that destination is also asynchronously edge triggered. The delays are not as quantized as with my clock sync design, which in some cases shifted a signal far enough that it began to overlap some operation that depends on our signal's actions already being completed.
When these happen, I would find ways to shorten the path, beginning with the anticipatory pulses I produce that lead the actual '1130 clock' phases by one fpga clock cycle. This gives me the ability to form a pulse right at the start of a cycle, or anywhere inside that I wish, although only on intervals of 1/14 of the 1130 cycle time.
The SLT logic module used to create the pulses that drive the async action are called single shots - SS types - that fire a pulse for a certain duration that is set for the module type, then recharge for a similar interval before they are ready for another triggering signal to arrive.
The shift logic puts the shifting count into the CCC register by a gating action during T3 then accomplishes the shift in cycles T4 and higher, extending T7 as necessary until the CCC goes to zero. However, I found that the logic that counts down the CCC register was active in T3, right after I set the value from the instruction.
I looked closely at the logic that caused this and didn't see how it could work properly, given that it counted if the shift control was active and it wasn't the SP pulse in T3. Now, SP pulses are quite short, therefore once that pulse finished in T3, the logic would see that Shift Control was active and do the incorrect countdown action.
The SP pulse would have to be blocking ShiftControl duirng T3, I realized. It had to be much longer than a normal SP pulse. I went to the ALD page that produced the SP and found what appeared to be the same circuit segment as any of the other SP pulse producers. However, I noticed that the code for the SLT module being used as the SS was different from the code on all the other SS modules in the processor.
Once I extended the duration of that single shot to cover the entirety of T3, not just the first sliver, I got correct operation of the shift instructions! Nothing on the ALD lists the duration of the SS pulses and none of the timing diagrams included in the documentation had that particular pulse displayed. I now have to be cognizant of even the module code for logic gates, to spot differences that might be meaningful.
No comments:
Post a Comment