Timing: Where Microcode Meets Hardware
The timing diagram below shows the relationship between the clock,
ø, and the signals that feedback to control the microcontroller,
or that are sent from the microcontroller to control the datapath.
Clock Generator
The system clock provides the "heartbeat" of the microcontroller.
The clock speed is determined by the time required for data to
flow through the longest path in the CPU, or by the time required
to execute the the most time-consuming ALU operation. This kind of
design is called "synchronous" because all functions are governed
by a central clock. Many instructions are slowed down because the
clock cycle is the maximum necessary in the worst case. Another
type of design called "asynchronous" permits the CPU to operate as
fast as possible for each operation. Asynchronous operation is
similar to dataflow processing, but like it, adds complexity to
the CPU.
Generating the Next MicroPC
First we will examine the operation of the microcontroller. The
most significant function it performs is selecting the start of a
sequence of microinstructions that implement the function of a
machine instruction, then sequencing through the microinstructions
until the machine instruction is complete.
Instruction Register (IR)
The instruction register (IR) is the source of the starting
address for a sequence of microinstructions. However, since there
are only three bits in the machine instruction's opcode to specify
the µaddress, it is necessary to translate the 1-of-8 opcodes to
one of the 256 µcode addresses.
MicroPC Map Table
The microPC map table translates the opcode in the IR to a
µinstruction address. Note on the timing diagram that the IR,
whose output is always enabled, is translated as soon as the data
is followed by the latch, but is only guaranteed to be valid after
the data is latched. This is still more than enough time for the
next microinstruction to be enabled out of the µcode, and be
present at the current µinst latch when the rising edge of the
clock, ø, signals the end of the executing microinstruction by
latching the next one.
Action of Carry Flag
The BRC machine instruction uses the technique of "bit forcing" or
"bit jamming" to select between one of two µinstruction addresses
depending on the state of the carry. This is accomplished by
wiring the carry into the least significant bit of the microPC map
table, but ONLY for the entry that translates the BRC opcode into
the BRC microinstruction address. Thus, when the carry is zero
the first of two adjacent microinstructions is executed. When the
carry is one, the second of the two adjacent microinstructions is
executed. Since every microinstruction includes the address of the
next µinstruction to be executed, it is easy for the
microprogrammer to vector one of the microinstructions to the
appropriate sequence to cause the machine program to branch or to
fall through to the next instruction.
Selecting the Next µAddress from the µInstruction
As just mentioned, each microinstruction contains the address of
the next microinstruction to execute. This is equivalent to
having a counter register hardwired into the microcontroller.
While it is space-inefficient, this is also a very fast technique.
Where the program space is small, as it is in a microprogram, and
speed is necessary, this is a good design choice. Larger µcode
and more complex sequencing in µcode may require a microPC
implemented as a register, with its own set of µcontroller status
flags.
Current Microinstruction Latch
The current µinstruction is held in an edge-triggered latch so
that all control bits are stable throughout the clock cycle. This
is necessary so that the next microinstruction address will be
valid when the clock rises at the end of the cycle, latching the
next microinstruction (see the timing diagram shown earlier).
Generating Control Signals
Most control signals are "and"ed with the clock, ø, to produce
output/follow and latch signals (see the timing diagram). Some
signals are unconditioned, such as the µPC.sel, which is thus
given as much time as possible to "steer" the correct
microinstruction address into the microcode ROM.
ALU Timing
The ALU is one of the critical paths in Gemini, determining the
maximum clock rate by the sum of the time needed to output and
latch the second input (usually to the B register), compute the
function of the B register and the previously latched A register,
and latch the output in the accumulator. If the ALU operates too
slowly, then a single operation that performs all these actions
can be split into two, and the clock rate increased, perhaps even
doubled. Since there are many more data transfer operations than
ALU operations, the overall result is a much faster CPU.
Register and Memory Timing
External memory is up to ten times slower than internal memory,
largely due to the resistance and capacitance of the I/O pads on a
VLSI circuit. The Gemini architecture, as used in this
assignment, ignores differences in register and memory timing,
assuming that both are not only connected to the same bus, but are
also on the same chip.
- one byte (NOTA)
The reserved field in the first byte of the instruction would
typically be used to extend the Gemini architecture with more
instructions and/or addressing modes. The temptation of an
architect to use these bits for unsupported instructions, and the
ingenuity of users who hunted for and used the unsupported
instructions, was the bane of early architects, who would drop the
unsupported instructions only to have the users complain bitterly.
The format of the Gemini microinstruction is called "horizontal
microcode" because all control signals are represented by a bit in
the microinstruction. "Vertical microcode" decodes all control
signals from a microinstruction (useful if many microinstructions
are repeated in machine instructions). "Diagonal microcode"
encodes some fields in the microinstruction but not others, a
compromise between space and time. In the Gemini microinstruction
the ALU functions could be encoded as a pair of bits.
A microinstruction specifies a limited form of parallelism. As
many events can occur in parallel as there are functional units
and buses to process and transmit data without conflict. A good
microprogrammer searches for ways to reorganize the machine
instruction's microcode so as to extract as much parallelism as
possible from the microprogrammer's model. Experience in
microprogramming can identify the bottlenecks in instruction
execution that can be overcome by hardware. Pipelining is the
easiest of these to see.
It is possible to output data from two sources simultaneously, but
because some of the same data bits will be zero and one, damaging
short circuits will almost certainly occur. Sending data to two
destinations at the same time is permissible if the source of the
data is powerful enough (i.e., its "fan-out" is large enough).
The "LDA m" machine-instruction
specific µcode starts here.
