Hardwired Control: Meaning, Design Methods, and an Example

Hardwired control refers to the implementation of a processor’s control unit using fixed logic networks (combinational and, when needed, state-holding elements). In a typical CPU, the control unit coordinates datapath actions (register transfers, ALU operations, memory reads/writes) by producing timing-accurate control signals derived from the current instruction’s opcode and the controller’s current state in the execution cycle. Hardwired control contrasts with microprogrammed control where sequencing and signal generation are driven by a microinstruction store.

Conceptually, hardwired control is implemented as:

• a sequencer (often a finite-state machine) to decide “which step comes next,” and
• decoding / logic that maps “(opcode, flags, state)” to the required control signals for that step.

Key learning terms you’ll see throughout this section:

• Finite State Machine (FSM)
• Decoding
• Status flags
• Timing (clocked control)

Various methods to design a hardwired control unit

Hardwired control designs typically follow one of these implementation approaches (they can also be combined):

1) FSM-based hardwired control (state machine with output decoding)

• Model the controller as an FSM:
  • State register holds the current step.
  • Next-state logic decides the subsequent state.
  • Output logic generates control signals from (state, opcode, flags).
• Advantages: clean structure; widely taught; supports conditional branching in control flow.

2) PLA / combinational logic realization of control signals

• Derive Boolean expressions for each control signal (e.g., RegWrite, MemRead, ALUSrc) as functions of:
  • opcode bits,
  • FSM state bits,
  • status flags.
• Implement these expressions using:
  • Programmable Logic Array (PLA) or
  • gate-level networks (AND/OR/NOT), sometimes with standard decoders.

3) Decoder + control-signal generators

• Use a hierarchical structure:
  • Decode opcode to generate one-hot or partially one-hot instruction lines.
  • Combine these with timing/state signals to assert the needed control outputs.
• Useful when instructions share common micro-operations across multiple steps.

4) ROM-like combinational implementation (fixed truth table / mask logic)

• While not microprogrammed (no sequencing store of microinstructions), some designs use:
  • fixed combinational tables (effectively a “mask”) mapping (state, opcode, flags) → control vector.
• Practically realized with PLA or large combinational logic.

5) Synchronous controller with explicit timing states

• Use time-step states like T0, T1, T2, ... (common in classic textbook CPU examples).
• Control outputs are asserted for specific time states; transitions are governed by conditions.

6) Hybrid: FSM for sequencing + PLA for signal synthesis

• Most practical “hardwired” designs:
  • FSM provides the sequencing,
  • PLA/gate logic generates all control signals from a small set of inputs.

Describe any one method with a suitable example

I’ll describe FSM-based hardwired control with output decoding and demonstrate it with a simple instruction (ADD: Reg[rd] ← Reg[rs] + Reg[rt]) example.

Example instruction: ADD R[rd] ← R[rs] + R[rt]

Assume:

• Datapath supports: register read, ALU add, register write.
• Controller uses states:
  • S0 = Fetch
  • S1 = Decode
  • S2 = Execute/ALU
  • S3 = Write-back
• Let:
  • opcode selects the instruction type (ADD selected when opcode matches ADD)
  • no flags are required for this simple ADD write-back (ignoring overflow/condition updates for now)

Controller states and control vectors

We’ll define a control vector (conceptually) with signals such as:

• IRLoad (load instruction register)
• PCInc (increment PC)
• RegRead (enable register file read)
• ALUOp=ADD (ALU operation select)
• ALUSrc (ALU input source select; e.g., register operands)
• MemRead / MemWrite (not used for this ADD)
• RegWrite (write result back to rd)
• WriteRegSel (select rd as destination)

FSM next-state idea (high-level)

• From S0 → S1
• From S1:
  • if opcode is ADD → S2
  • (other opcodes would branch to their own execute states)
• From S2 → S3
• From S3 → S0

Output decoding (hardwired) logic

In hardwired control, each control signal is asserted in specific states for a given opcode. For ADD, the core assertions are:

• In S0 (Fetch):
  • IRLoad=1, PCInc=1
• In S1 (Decode):
  • RegRead=1 (or prepare operands)
• In S2 (Execute):
  • ALUOp=ADD=1, ALUSrc=registers
• In S3 (Write-back):
  • RegWrite=1, WriteRegSel=rd

Mathematically, for any control signal $X$, a typical hardwired output expression looks like:

$$X = \sum (\text{minterms where } X \text{ must be 1})$$

where each minterm is a conjunction of:

• FSM state bits (e.g., $S2$),
• opcode match lines (e.g., $\text{ADDop}$),
• optional flags (for conditional instruction classes).

That Boolean form is then implemented using gate networks or PLA product terms—fully fixed hardware.

Putting it together: “hardwired control unit” as combinational + sequential logic

A robust way to think about hardwired control hardware is:

1. Sequencer (sequential): state register + next-state logic
   • Inputs: opcode bits, flags, current state bits
   • Output: next state bits
2. Control generator (combinational): decode logic
   • Inputs: current state bits + opcode/fields + flags
   • Output: control signals to datapath multiplexers, registers, ALU control, and memory interface

Key design artifacts you would produce

• State transition diagram / state table
• Output control signal truth table (state × opcode × flags → control vector)
• Boolean simplification (minterm grouping) for each control output
• Implementation mapping into gates/PLA/decoder blocks