= Solution
Execute this <MIPS instruction> fragment twice, once with equal operands and once with unequal operands, and observe whether its conditional branch is taken:
``
beq $t0, $t1, hit
sll $zero, $zero, 0
sll $zero, $zero, 0
hit:
sll $zero, $zero, 0
``
Use `$t0=7,$t1=7` for the first test and `$t0=7,$t1=8` for the second. All padding instructions are explicit harmless <MIPS instructions>. In the pictured single-cycle model, the next <program counter> after `beq` is either `hit` or the sequential address. The branch target is deliberately different from the next sequential instruction. The extra padding also keeps a <branch delay slot> harmless if a test fixture uses an implementation with one, although the pictured model itself has none.
A healthy `zero` line reports the first subtraction as zero and the second as nonzero. A line stuck at zero prevents both branches, while a line stuck at one forces both branches. Therefore
$$
\boxed{\begin{array}{c|c}
\text{zero state}&(\text{equal test taken},\text{unequal test taken})\\\hline
\text{normal}&(\text{yes},\text{no})\\
\text{stuck at 0}&(\text{no},\text{no})\\
\text{stuck at 1}&(\text{yes},\text{yes})
\end{array}}
$$
Observe the branch decision or execution trace itself; an alleged unconditional `beq` used to skip result-recording code would also be affected by the fault.
Back to article page
