Force, Deposit & Bisecting a Failure

Chapter 12 · Section 12.4 · GLS Debug Methodology

Project thread — after backward-tracing to a suspected source (12.3), force is how you confirm it. This lesson adds that confirmation step; 12.5 compares RTL vs GLS to isolate a mismatch.

1. Why Should I Learn This?

A backward-trace gives you a hypothesis; force/deposit let you prove it — fast.

• Force the suspected X source to a known value → failure clears → root cause confirmed.
• Bisect spatially — force half known, narrow which half injects the problem.
• Debug aids, not fixes — remove them; they can mask the real bug.

This closes the loop from trace (12.3) to a confirmed root cause.

2. Real Silicon Story — the "fix" that was a forgotten force

A team's gate-level failure disappeared after some debugging — and they nearly signed it off. But the failure was gone only because a force left in the testbench was overriding the offending signal to a known value.

The force was masking the bug, not fixing it. The real X source was still there, hidden behind the force. Removing the force brought the failure back — and pointed them (correctly) at the real source to fix in the design. A forgotten debug force had almost shipped a real bug.

Lesson: force/deposit are debug aids, not fixes. A left-in force masks the bug (it looks fixed but isn't). Use them to confirm, then remove them and fix the source.

3. Concept — force, deposit, confirm, bisect

Force vs deposit:

• Force — override a signal to a value continuously, overpowering its driver, until released. (Signal is pinned.)
• Deposit — set a value once; the signal then evolves normally from that value. (A one-time nudge.)

Confirm a root cause (the key use):

• You've backward-traced to a suspected X source (12.3).
• Force it to a known value and re-run:
  • Failure clears → the hypothesis is confirmed (that signal was the source/root).
  • Failure persists → not the (whole) source — keep tracing.

Bisect spatially:

• Force half the design (e.g. one block's outputs) to known values.
• If the failure clears, the source is in the forced half's inputs / that region; if it persists, it's in the other half — halve again.
• Complements 12.2's temporal bisection (narrow when) with spatial (narrow where).

Deposit uses:

• Initialize a suspected uninitialized flop once to test an init hypothesis (does the failure vanish if this flop starts known?).

The caveat (critical):

• Force/deposit are debug aids, not fixes. A forced signal masks the real bug or creates false behavior. Remove them after confirming; fix at the source (design/setup).

Scope (accuracy):

• Force/deposit confirm/localize — they don't change the design. GLS stays dynamic (0.3).

4. Mental Model — a clamp to test a theory, not a repair

Force is a clamp you put on a wire to test a theory, not a repair.

• Suspect a wire is injecting a fault? Clamp it to a known voltage (force) and see if the machine runs right — if it does, you've confirmed the wire was the culprit.
• To narrow which section is faulty, clamp a whole section's outputs known (bisect) — does the fault vanish? Then it's in or upstream of that section.
• But a clamp is not a repair — leave it on and you've just hidden the fault behind a wire that can't move. The machine looks fixed but the broken part is still there.
• Remove the clamp, then actually fix the faulty part (at the source).

Clamp to diagnose, then un-clamp and repair — never ship with the clamp on.

5. Working Example — confirm a source, then remove the force

Force to confirm a root cause (tool-neutral):

# Force to CONFIRM the traced X-source — REPRESENTATIVE (tool-neutral)
# backward-trace (12.3) -> suspected source: u_q1 (state[1]) unreset -> X
force  tb.u_dut.u_q1.Q = 1'b0      # override the suspected source to a KNOWN value
run
# result: busy/done clear (no more X downstream) -> HYPOTHESIS CONFIRMED (u_q1 was the source)
release tb.u_dut.u_q1.Q            # REMOVE the force (it is a debug aid, not a fix)
# now FIX AT SOURCE: give u_q1 a proper reset (Ch7) -- do NOT leave the force in.

# Deposit to test an init hypothesis; bisect to localize (tool-neutral):
deposit tb.u_dut.u_mem = '{default:0}   # initialize once -> does the failure vanish? (init issue?)
force   tb.u_dut.u_blkA.* = <known>     # bisect: force block A's outputs known
#   failure clears -> source in/upstream of block A ; persists -> other block. Halve again.
# REMOVE all forces/deposits after confirming. Fix at source.

Practical context (representative, tool-neutral):

# Force/deposit workflow (tool-neutral):
#   1) backward-trace to a suspected source (12.3)
#   2) FORCE it to a known value -> failure clears? -> CONFIRMED (else keep tracing / bisect)
#   3) BISECT spatially: force half the design known to narrow the region
#   4) DEPOSIT once to test init hypotheses (uninitialized flop/memory)
#   5) RELEASE all forces/deposits; FIX AT SOURCE (design/setup) -- never leave them in
#   WARNING: a left-in force MASKS the bug (looks fixed, isn't).

Force confirming the source (failure clears), as a real waveform:

6. Debugging Session — a failure "fixed" by a forgotten force

7. Common Mistakes

• Leaving a force in — it masks the bug (looks fixed, isn't).
• Treating force/deposit as a fix. They confirm/localize; fix at the source.
• Signing off with forces active. Verify the failure is gone without them.
• Confusing force and deposit. Force pins continuously; deposit nudges once.
• Not removing debug forces before regression.

8. Industry Best Practices

• Use force to confirm a traced source (force known → failure clears → confirmed).
• Bisect spatially (force half known) to narrow the region.
• Deposit to test init hypotheses (uninitialized flop/memory).
• Always remove forces/deposits after confirming; fix at the source.
• Verify the failure is gone with no forces active before sign-off.

Senior Engineer Thinking

• Beginner: "I forced the signal and the failure went away — fixed!"
• Senior: "That confirms the source — it doesn't fix it. The force is masking the X. I remove the force, fix the source (reset the flop), and verify the failure's gone with no forces active."

The senior uses force to confirm, then removes it and fixes the source — never ships with a force.

Silicon Impact

Force and deposit are hypothesis-testing tools that make a backward-trace conclusive — force the traced source known, and if the failure clears you've proven the root cause in seconds, saving hours of uncertainty. But the caveat is a real, dangerous silicon risk: a forgotten force that masks a failure can let a real bug reach silicon while the simulation looked clean (the opening story, a near-miss). The discipline — use them to confirm and bisect, then remove them and fix at the source, and never sign off with a force active — is what keeps them a debugging accelerant rather than a bug-masking hazard. In the funnel, force/deposit are how the trace (12.3) becomes a confirmed root cause — and the removal step is what keeps that confirmation honest.

Engineering Checklist

• Used force to confirm the traced source (force known → failure clears).
• Bisected spatially (force half known) to localize the region.
• Used deposit to test init hypotheses where relevant.
• Removed all forces/deposits after confirming.
• Verified the failure is gone with no forces active; fixed at the source.

Try Yourself

1. Backward-trace a failure to a suspected X source (12.3).
2. Observe: force that source to a known value and re-run — the downstream failure clears → confirmed.
3. Change: release the force and fix the source (e.g. add the reset).
4. Expect: the failure is gone without the force — a real fix. Then re-add the force and leave it in to see how it would mask an unfixed bug (then remove it).

Force/deposit are standard simulator commands in any tool. No paid tool required.

Interview Perspective

• Weak: "I force the signal to make the failure go away."
• Good: "I force the suspected source to a known value to confirm it's the root cause, then fix the source."
• Senior: "Force overrides continuously, deposit sets once. I force the traced source known — if the failure clears, the root cause is confirmed — and I bisect spatially by forcing half the design known. But they're debug aids, not fixes: a left-in force masks the bug, so I remove them and fix at the source, and I never sign off with a force active."

9. Interview / Review Questions

10. Key Takeaways

• Force overrides a signal to a value continuously (until released); deposit sets a value once and lets it evolve — the debugger's way to test hypotheses.
• Confirm a root cause: force the suspected X source (from the backward-trace, 12.3) to a known value — if the failure clears, the hypothesis is confirmed; if not, keep tracing.
• Bisect spatially: force half the design to known values to narrow which half injects the problem (the spatial complement to 12.2's temporal bisection); deposit to test init hypotheses.
• Force/deposit are debug aids, not fixes — a left-in force masks the bug (looks fixed, isn't), so remove them and fix at the source; never sign off with a force active.
• They confirm/localize, not change the design — the step that turns a trace (12.3) into a confirmed root cause; GLS stays dynamic (0.3). Next: 12.5 — RTL-vs-GLS comparison & mismatch isolation.

Quick Revision

Force = override a signal continuously (until released); deposit = set once, then evolve. Confirm root cause: force the traced source known → failure clears → CONFIRMED (else keep tracing). Bisect spatially (force half known). CAVEAT: debug aids, NOT fixes — a left-in force MASKS the bug; remove them, fix at source, never sign off with a force active. Next: 12.5 — RTL-vs-GLS comparison.