Sunday, June 25, 2017

Refactoring and ruggedizing my fpga logic for the disk tool

IBM 1130 LIGHT PANEL UPGRADE

My shipment of 200 miniature incandescent bulbs from China arrived yesterday and are waiting for me to begin soldering them onto 2-pin headers for use in the 1130. I think it best if I make a jig that will hold the header and the bulb in place for quick soldering of the wire leads onto the pins. It will give me consistency of results and some speed in preparing the 160 bulbs needed to populate the light panel. 

ALTO DISK TOOL

My disk tool design is suffering from glitches driving state machines into undefined states. The state machine (FSM) then will stall in that invalid state. The state of an FSM is defined in a register using some encoding (examples are binary, one-hot and gray code).

In the simple case of a binary encoding, if the FSM doesn't have a number of states that match the number of total states, some values in the register are invalid. For example, a three bit register encodes 8 possible binary values, but if the state machine has five valid states, coded 0 to 4, then if the register becomes 5, 6 or 7 the FSM will stall.

One-hot encoding uses a string of bits as long as the number of states, with one and only one bit set at any time. Thus, for the five state machine discussed above, the register is five bits long and has valid values 00001, 00010, 00100, 01000, and 10000. If the register ever has more than one active bits, or none are active, the FSM will stall.

The next value of the state register is determined in the FSM as a combination of the current state value and some input signals. If an input signal changes very close to the clock edge, it might produce a glitch where the next state register attains one of the invalid values and stalls.

Developing reliable operation of the FSMs requires careful attention to details. Particularly with externally generated asynchronous signals, such as the Sector Mark value, the value may be changing too close to the clock edge and lead to stalling.

One solution is to have every input signal that generates the next state value be itself registered so that it cannot change near the clock edge. Other techniques include methods to detect invalid states and force the FSM back to some valid state. For example, a parity test of one-hot values might detect an error.

Even with auto correction to recover an FSM from a stall, the result may be an FSM at idle when it was supposed to generate some triggering output. Another FSM may be waiting for that missing output, producing a deadlock. The result is still a stalled system. This can get quite tricky.

My first task is to ensure that I force all the external signals to become aligned to the clock boundary, passing each through a chain of a few registers in a row. This is the classic cure for preventing meta-stable states but also forces signal states to only change on the clock edge.

I completed a set of two-stage D flipflops to pass each outside signal through, getting them aligned to clock boundaries. I used the schematic approach, placing 54 D FF symbols and routing the signals graphically. Previously, I inverted the signals using combinatorial logic from the input pin, but now I invert combinatorially then pass through the two stage D flipflops to get it properly aligned with the clock.

I will then look to see if any of my input signals to important FSMs are passing through combinatorial logic where they might be in transition around a clock edge. As much as possible I will remove such logic leaving all inputs clean, and if I still need the logic then the outputs will be registered so they only change on clock boundaries.

While doing this, I will strip out some logic that had been in place for functions which I will eventually implement, but am not dependent on for the near term archiving and cartridge writing roles. This includes sector update transactions, disk drive emulation and some display functionality.

As part of stripping this down, I am also reviewing several hundred warning messages from the toolchain to look for any that are truly relevant and act upon them. In most cases, these will be leftover signal declarations that are not being used any more, which I can strip out.

I spent about one day in total doing all of this, then set it up for initial testing at home with a wrap-around board of some signals. Full testing will require the disk drive and cartridges  Done for today.

No comments:

Post a Comment