LOGIC ANALYZER SHOWS SHORT GLITCHES THAT CAN AFFECT STATE MACHINE
When looking at the logic analyzer traces I collected while doing seeks with the Virtual 2315 Cartridge Facility (V2315CF), where the internal 2310 disk drive of the IBM 1130 was used in concert with the virtual disk cartridge contents, I saw brief glitches. These were 10 nanoseconds or less in duration, thus completely ignored by the Solid Logic Technology (SLT) of the IBM 1130 and the disk drive. However, they are enough to cause problems in the FPGA logic due to the high speed electronics.
The 1130 requests a movement of the disk arm to move one or two cylinders at a time either towards the home cylinder 0 or out towards cylinder 203 which is the highest location where data is stored on a 2315 disk cartridge. A seek command issued by a program specifies a relative number of cylinders to move; the disk controller converts this into a set of 1 or 2 cylinder steps until the desired total movement is achieved.
The -Access Go signal drops low to request a step, with the drive responding with a feedback signal +Access Ready that goes low 5 milliseconds after the seek request and remains low for another 10 milliseconds before returning to high to indicate that the movement is complete. The originating -Access Go line is returned to high when the 1130 sees the +Access Ready line drop low 5 ms into the seek.
I captured a seek command where the program requested a movement of 40 cylinders, which the 1130 drive controller electronics converts into 20 movements of two cylinders each. The seek shadowing function in the FPGA only counted 38 cylinders while the 2310 disk itself moved the full 40 cylinders. There are two glitches on the -Access Go line that were the cause of the state machine in the FPGA going awry.
![]() |
| top is -Access Go, next is +Access Ready |
When I zoom in on the glitches, they are all shown as 10 nanoseconds long, which is the sampling interval so the actual glitch is likely even shorter. None of the cabling in the 1130 is designed to eliminate very short glitches like this because the logic family, called 30 ns SLT, is impervious to short duration perturbations. If I were to try to eliminate all of that, it would involve considerable work to change parts of the 1130 such as altering the type of cable used in the machine. Instead, making the FPGA ignore these is the better direction to take.
WORKING ON FPGA LOGIC THAT IS IMPERVIOUS TO SHORT DURATION GLITCHES
I worked on the state machine that shadows the seek movement by watching the signals between the 1130 and the 2310 disk drive, working to ensure that it produces the correct results with brief glitches in the signals. In order to test that, I had to develop a good testbench for simulation that would introduce glitches of every type so that I could watch the behavior of my logic. Building the testbench was more work than the state machine itself, but it did help me achieve the performance I need from the seek shadowing.
I introduced glitches of several types and in different places during a sequence of simulated movements. Glitches of 100 nanoseconds, far longer than I was observing with the V2315CF, were introduced. First was a brief drop of -Access Go when the 1130 was not actually trying to move the arm. Next was a brief return of -Access Go to high before the drive has responded with a low level on +Access Ready. Third was a brief drop of -Access Go during the final 10 ms of a step, when +Access Ready is low. I also sprinkled a short glitch in between successsful step movements.
This had to work in both modes of the V2315CF - real and virtual. Virtual mode is when the 2310 disk drive is not switched on. The FPGA simulates the sector and index marker pulses that indicate the rotation of the drive and it simulates the feedback signals such as +Access Ready. In real mode, the drive itself generates the marker pulses and responds to the step requests with feedback signals.
OUT OF ROOM ON FPGA CHIP WAS NEXT SNAG
With the functionality validated using simulation, I moved to the Lattice IceCube2 tool to generate the bitstream to load onto the V2315CF. Unfortunately, the changes I made expanded the required number of elements like Look Up Tables (LUTs) and D Flip Flops (DFFs) beyond the capacity of the chip installed in the V2315CF.
I have to find ways of trimming this down without impacting the functionality I just tightened up. I suspect that the big issue was the need to add a second 19 bit register to hold the value of a timer so that I could continue a countdown across a glitch - that register and all the comparisons to certain values that will be contained in it require a lot of DFFs and combinatorial LUT logic.
I looked over the logic to see if I could find clever optimizations that might reduce the count of DFFs and LUTs while maintaining the working logic. I had to go back to simulation to be certain that these changes had no adverse impact. I also had to hope that I could trim it enough to fit. I have had issues trying to fit in the past, requiring me to strip out what I could from the FPGA code.
SUCCESSFULLY REMOVED NEED FOR SECOND REGISTER AND ALL THE COMPARISONS
The code was tightened further and works just as well. The result fits in the existing FPGA chip! The final counts of parts are:
- 1,209 Look Up Tables
- 622 D Flip Flops
- 181 Carrys
- 1 Global Buffer
- 3 Global Buffer I/O blocks
- 86 Input Output buffers
IMPLEMENTED THE CARTRIDGE ICON TO DISPLAY ON V2315CF MAIN PANEL
I converted the image of the 2315 cartridge into a pixel array that is written to the LED panel of the V2315CF main box when a virtual cartridge has been loaded into the RAM and is ready to use with the 1130 system.
The refresh rate of the LED conflicted with the iPhone camera a bit, so the image doesn't look as good as it does in person.













