Control Signal Sequencing Under a Stuck Flag
A microcoded control unit drives an ALU with signals ALUop[2:0], a register-file write enable RegWr, and a branch-taken signal BrTaken. The ALU sets a zero flag Z and a carry flag C. A conditional branch instruction 'BLT' is specified as: take the branch if the last comparison set the 'less than' condition, where less-than for signed operands is defined as (N XOR V) = 1 using the sign flag N and overflow flag V. The current microcode only latches Z and C and computes BrTaken = Z for BEQ. During bring-up, BLT branches incorrectly whenever the comparison overflows (e.g. comparing -128 with +127). The microcode engineer proposes to 'just use the carry flag' as a quick fix.
1. Explain why using the carry flag for signed less-than is wrong, and construct a concrete comparison that exposes the error.
Read the worked answer
Carry out of a subtraction reflects unsigned borrow, not signed order. For A - B, C=1 (no borrow) means A >= B unsigned; C=0 means A < B unsigned. Signed comparison depends on the sign and overflow, not on the raw carry.
Counterexample: compare A = -128 (0x80) and B = +127 (0x7F). Signed truth: -128 < 127, so BLT should be taken. Compute A - B = -128 - 127 = -255, which overflows 8-bit signed. Bit pattern: 0x80 - 0x7F = 0x01, with a borrow out (C=0) and overflow V=1, result sign N=0. If we use C as 'less than', C=0 would say 'not less', wrong. The correct signed test: N XOR V = 0 XOR 1 = 1 → less than, branch taken. So the carry shortcut gives the opposite answer exactly in the overflow case.
Another: A = +127, B = -128. Signed: 127 > -128, no branch. A - B = 255 → 0xFF, N=1, V=1, C=1. N XOR V = 0 → not less, correct. Carry (C=1) would say 'not less' too here, coincidentally, showing carry sometimes agrees and sometimes not - which is the worst kind of bug.
2. Specify the minimal microcode/control changes to implement BLT correctly, including which flags must be latched and how BrTaken is formed.
Read the worked answer
Changes:
- Latch N and V in addition to Z (and C if needed for unsigned). The ALU must produce N (result MSB) and V (signed overflow = carry-in to MSB XOR carry-out of MSB).
- For the compare/subtract microinstruction, store N and V into the condition register.
- Form BrTaken for BLT as N XOR V (combinational), then AND with the branch-enable control bit so only branch instructions use it.
- Keep BEQ as BrTaken = Z. Do not overload one flag for both signed and unsigned comparisons.
Minimal: add N and V latches (2 bits), a single XOR gate, and a mux selecting Z or (N XOR V) based on the branch type field. No change to the ALUop sequencing is required.
3. The team also needs an unsigned 'below' branch (BLO). Show how to derive it from the same flags and explain the design principle that keeps signed and unsigned conditions from being confused.
Read the worked answer
Unsigned below for A - B: BLO is taken when A < B unsigned, which is C=0 (borrow occurred). So BrTaken_BLO = NOT C.
Summary of conditions from A - B:
- BEQ: Z
- BNE: NOT Z
- BLT (signed): N XOR V
- BGE (signed): NOT (N XOR V)
- BLO (unsigned): NOT C
- BHS/BGEU (unsigned): C
Design principle: the flag set is fixed (Z, N, V, C) and each branch type selects a specific boolean combination via a small decode table in the control unit. Signed conditions use N and V; unsigned conditions use C (and Z for equality). Never reuse C for signed order or N/V for unsigned order. Encoding the branch type explicitly in the instruction and decoding it to the correct flag combination is what prevents the class of bug seen at bring-up.