Clocks - retrotruestory/M1DEV GitHub Wiki

Clocks

There is one master clock, CLK_S which is generated on the front panel logic card and travels to the control card. There, it is combined with microcode bits to generate edge-sensitive signals and drive the microcode sequencer state machine. In essence, the second half of each clock cycle (starting with CLK_S going high) is devoted to generating control signals. The first half of the following cycle is devoted to marshalling data based on the control signals, which are clocked on the rising edge of the various edge-sensitive signals.

In retrospect, this design was too simple. As a software guy, I had a tendency to think of the clock pulse causing everything to happen at the same time. In fact, propogation delays mean that the clock edge wave reaches different parts of the system at very different times. As a result, there are places in Magic-1 where I had to specifically select fast (74Fxx) vs slow (74LSxx) parts to sidestep timing issues. In general, this is not a good thing - and could have been avoided if I had a series of overlapping clocks to select from.

It’s been a long time since I thought in detail about the timing of an instruction cycle so it’s possible I’ll get some minor details wrong, but here’s an overview.

CLKS is the system clock and CLKM is the microcode clock. CLKM is essentially the inverse of CLKS. I did this because I wanted things to happen on both the rising edge of the system clock, and the falling edge of the system clock.

In short, on the falling edge of CLKS (or the rising edge of CLKM), the microcode control signals flow out into the system to select registers, alu ops, etc. On the control card schematic page, see U6..U10. Note also that the address of the next microinstruction to execute is also clocked in and the muxes U15..U18 begin addressing the microcode ROM to prepare for the next microinstruction. There is some extra logic in there to handle microcode conditionals and traps/interrupts.

Then, on the rising edge of CLKS those new results are clocked in. For example, if we are writing to PC, the “LATCH” microcode bits would be 0x3. During the high phase of CLKM (low phase of CLKS), those bits would flow through the various decoders and muxes on the “Field Decode” sheet (U36, U27, U29), eventually combining with CLKS to generate the L_PC control signal.

When I was designing Magic-1, my simplified mental model was:

    Rising edge of CLKS: latch results based on current control signals
    High period of CLKS: fetch next microinstruction
    Falling edge of CLKS: latch microinstruction
    Low period of CLKS: decode microinstruction to generate proper control signals

However, because many of the TTL devices wanted to operate on rising clock edges, I added CKLM, the inverse of CLKS, to give me a rising edge to do things on CLKS’s falling edge.

In retrospect, this was probably a bad idea. I think it might have been better to instead have a single clock, CLKS, that ran at double speed. Rising edge #1 (T state 1) would latch results and rising edge #2 (T state 2) would latch microinstruction. I suspect such a clocking scheme would have been cleaner, but in the end what I did worked.

⚠️ **GitHub.com Fallback** ⚠️