DenseChip

RISC-V Design ยท All levels

Hazard Detection Basics in Decode: Debug Playbook

Debug Playbook for Hazard Detection Basics in Decode.

Debug playbook

Debug Playbook for Hazard Detection Basics in Decode is anchored on RAW stall cycles per kilo-instruction and percentage of avoidable stalls removed by forwarding.. Convert observations into mechanism-backed decisions with explicit ownership.

  1. Freeze workload seed, binary, compiler, firmware, and platform setup.

  2. Find earliest persistent mechanism failure in the timeline.

  3. Build one reduced reproducer for dominant hypothesis.

  4. Patch minimal fix with explicit rollback gate.

  5. Rerun correctness + performance + power matrix.

Decision tree

diagram
ROOT CAUSE TREE - Hazard Detection Basics in Decode

RAW stall cycles per kilo-instruction and percentage of avoidable stalls removed by forwarding. regressed
          |
   reproducible on fixed seed?
      /                 \
    no                   yes
    |                     |
env/tool drift       first failing domain?
                     /        |         \
                  decode    execute    memory/MMU
                    |         |            |
               control map  bypass/FU   TLB/walk/perm
                    |
         privilege/CSR side effects checked?

Stop at first confirmed mechanism, then assign explicit owner + fix proof.

Review memo template

diagram
RISC-V REVIEW MEMO - Instruction Decode & Control / Hazard Detection Basics in Decode

1. Symptom
   - Failing metric: RAW stall cycles per kilo-instruction and percentage of avoidable stalls removed by forwarding.
   - Failing workload slice: <name>
   - Triggering mode: <privilege/virtualization/interrupt/cache/boot>
   - Build and runtime tags: <toolchain/firmware/RTL revision>

2. Mechanism hypothesis
   - Primary mechanism: Decode is the first stage that can compare source register indices against destination registers already in flight, so it becomes the anchor point for hazard classification. Basic logic catches read-after-write hazards for operations whose results are not yet available, plus structural conflicts such as a busy multiplier or a blocked memory pipeline. The hazard unit then chooses between stalling decode, inserting bubbles, or allowing issue with forwarding assumptions. Even in simple in-order cores, edge cases matter: x0 dependencies must be ignored, CSR reads and writes can serialize unexpectedly, and load-use latency usually requires a one-cycle interlock unless the data path supports same-cycle bypass. Reliable behavior depends on synchronizing hazard state with flush events so stale dependencies do not survive control redirects.
   - Competing hypotheses: <decode control / hazard / MMU / privilege / integration>
   - Missing evidence: <trace/counter/proof/report>

3. Proposed action
   - Smallest reversible change: <RTL/compiler/runtime/config>
   - Expected movement: <throughput/latency/tail/perf-per-watt>
   - Regression risk: correctness, security, power, timing, software compatibility

4. Signoff
   - Required artifact: Hazard matrix covering producer-consumer distance, bypass eligibility, and required interlock action for each instruction class.
   - Required owners: pipeline control owner, scoreboard and hazard RTL owner, verification owner, performance analysis owner, post-silicon debug owner
   - Final decision: ship, bounded rollout, rollback, or escalate
Practice this lesson