Schematics & Description
Heaven and Earth Subsystems
When we began designing for a one-state-per-clock-cycle implementation for the microprocessor,
we soon came to the realization that the main portion of the microprocessor could
ignore the complex task of computing the program counter, the next instruction, and the clock massaging. It just looks at the current instruction and acts on it.
It has "faith" that the instruction is correct. In theological terms, the instruction
comes straight from "Heaven." Heaven also contributes the Divine Clock; this is
the clock signal that drives "Earth"--the rest of the circuit.
There are two situations when Earth needs to give information to Heaven. These are
called Prayers, and are discussed in detail below.
Heaven is the subsystem that magically generates the inputs to Earth. These inputs
include the Divine Clock and the eight Instruction lines. Heaven also deals with
"prayers"--lines from the Earth subsystem. There are two prayers--the Halt Prayer
and the Branch Prayer
While Earth is conditioned primarily by the rising edge of the Divine Clock, much
of Heaven is conditioned on the falling edge of the Divine Clock. This offset means
that the eight lines for the instruction are being processed a half-cycle ahead of
the time they are actually used. This is to guarantee that valid instructions exist by
the time they're needed.
Heaven has two major subsystems:
- The Clock Guidance Subsystem controls the Divine Clock signal sent to the rest of
- The Instruction Sovereignty Subsystem ensures that the eight Instruction lines Earth
sees are valid.
The Clock Guidance Subsystem reconciles the clock input, the Go button, the Single-Step
button, the Halt button, and the Halt Prayer into a single Divine Clock signal sent
to the rest of the system.
The Halt Prayer Fulfillment Subsystem reconciles the Go button, the Halt button, and
the Halt Prayer into a Halt Bit.
Finally, the Reduced Clock Circuitry reduces the clock input, the Single-Step button,
and the Halt Bit into the Divine Clock signal.
A little explanation is in order here. Single-Step, if Halt is on, has its frequency
divided by two (this will be explained later), then has inputs to two D FF's. The
two D FF's are clocked by the clock input and the inverted clock input, respectively.
The output of the two D FF's go into an XOR gate. What this means is that whenever
the input to the D FF's changes, the output of the XOR gate goes high for half a
clock cycle. Since our design is a one-state-per-instruction design, this performs
a single step.
Now, the Single-Step frequency is divided by two because a clock pulse is output on
each change of Single-Step; we only want a pulse on each rising edge of Single-Step.
The Instruction Sovereignty Subsystem ensures that valid, timely instructions are
available for Earth by the time Earth expects them. This subsystem consists of two
- Program Counter Logic
- Instruction Memory
For input, the Program Counter Logic subsystem has the Divine Clock, the Reset button,
the Branch Prayer, and the low four Instruction bits. The output is four lines for
the Program Counter, and a Latch signal to catch the program counter.
If Reset is asserted, the Program Counter is set to zero.
If Branch Prayer is asserted, then the Program Counter is set to the low four bytes
of the current instruction.
If neither Reset nor Branch Prayer are asserted, the Program Counter simply increments
from its old value.
The Program Counter is latched on the falling edge of the Divine Clock. This is
for two reasons:
It guarantees that the Instructions will be valid and stabilized by the rising edge
of the clock (which is when the Instruction lines are latched for analysis by Earth).
It guarantees that the Program Counter logic only takes place once and there are
no dependancies on propogation delays.
The Instruction Memory is a GAL with four inputs from the Program Counter. There
are eight outputs which form the Instruction. Implementing Instruction Memory on
a GAL enabled us to have the programs in a permanent form. Thus we didn't have to
enter the programs each time we powered up the system. To enter another program we simply
need to insert a different GAL. To program the GAL, we wrote a K-Map for each instruction
line. Then we put the resulting logic into Orcad and programmed the GAL. It is
likely that we could use bitmap notation to program Orcad. Furthermore, with a little
work, we could write a precompiler that translates the
assembly language into an Orcad file.
The components of Earth include:
- The Instruction Latch holds the Instruction from Heaven on the rising edge of the
- The Earth Controller is the chip with the combinational logic to control the rest
of the Earth subsystem.
- The Registers hold the values of the four four-bit registers.
- The Carry Bit is used in various ALU and Branch instructions.
- The Transparent Latch guarantees that stabilized, valid data is being input to the
- The ALU performs all the mathematical operations of the instruction.
- The Switch Logic decides whether to pass through ALU output or Switch output to
The Instruction Latch catches the Instruction from Heaven and holds it conditioned
on the rising edge of the Divine Clock. The two facts of (1) latching the Instruction
and (2) a one-state machine implies that a physical Finite State Machine is redundant: rather than a state machine with controller outputs based on state variables, we
can base controller outputs directly on the Instruction lines. Thus our Finite State
Machine reduced to combinational logic.
The Earth Controller includes the combinational logic to control the rest of the circuit
based on the Instruction. It controls the Switch Logic, the ALU, the Registers'
Write Enable, the Carry Write Enable, and the Halt Prayer and Branch Prayer.
The Registers hold four separate four-bit registers. Read is always enabled. The
Transparent Latch determines when the output from the Registers is passed through
to the ALU.
The Carry Bit is used as input in various ALU and Branch instructions; it is set or
reset as a result of all ALU commands.
The Transparent Latch connects the output of the Registers to the input of the ALU.
While the Divine Clock is high, the Registers' output is passed directly to the
input of the ALU. When the Divine Clock signal falls to zero volts, the current
value of the Registers is latched. This is so new values coming into the Registers (which happens
when the Divine Clock is low) don't get passed through into the ALU and thence to
the Registers again, and again, and again...
The ALU performs all mathematical operations of the instruction. This includes addition
of two Registers, subtraction of two Registers, and addition of one Register to Carry.
A look-ahead carry is implemented for improved performance.
The Switch Logic determines what is passed through to the Registers: ALU output or
Toggle Switches. If the current Instruction is a Load instruction, the Switches
are written into the Registers; if the current Instruction is an ALU instruction,
the ALU output is written into the Registers.
Nuggets of knowledge gleaned along the way:
We noticed that the go button had a limitation: if the program was halted but the
currently-executing command was not halt (ie, one or more Single-Steps had been process
since the program halted), Go worked fine. However, if the currently-executing command
was halt, Go did not work unless Single Step was pressed while Go was pressed.
We did some analysis of the circuit to try to find out why this behavior occurred.
It turned out that the Halt Prayer turned on the Halt Bit; when the Go button was
pressed, the Halt Bit was turned off, but since the Halt command was still being executed,
the Halt Prayer was still asserted and the Halt Bit was continually being set. We
came to the conclusion that faking out the circuit was easier than fixing the problem.
We set it up so if Go was pressed, it also faked a Single Step. This fixed the problem.
We found a ShareWare Mac program called DigSim while sightseeing on the Information
Highway (Internet) that let us simulate simple combinational circuits and analyze
intermediate values. It also let us do some rudimentary timing analysis and logic
analysis. We tested our Reduced Clock Circuitry using DigSim and could work out the kinks
much faster than plugging wires--even faster than working it out on paper.
Here is a sample picture of the use of DigSim: