bind Debug & Limitations

Elaboration errors

Bind problems surface at elaboration, and the messages point at the bind file even when the root cause is an RTL change. The three classic failures:

1. Port/signal not found — the bind maps .count(count) but the RTL renamed count to occ_q. The fix is in the bind file; treat it as routine maintenance after RTL drops.

2. Width or parameter mismatch — the checker's parameter default no longer matches the target (DEPTH grew, count gained a bit). Forward the target's parameters instead of hardcoding.

3. Target not found — the bind names a module or instance path that no longer exists (renamed module, refactored hierarchy). Instance-path binds are the usual victims.

TRIAGE FLOW [DV]

  elaboration error in <subsys>_binds.sv
        │
        ├─ "signal not found"  → diff the RTL module's signals
        │                         vs the bind's port map; update map
        ├─ "width mismatch"    → check parameter forwarding
        │                         #(.DEPTH(DEPTH)) not #(.DEPTH(16))
        └─ "module/instance    → module renamed? hierarchy moved?
            not found"            convert instance binds → module
                                  binds where the check is generic

Waves, generate scopes, and performance

Finding bound instances in waves

The bound instance lives under the target's hierarchy path — not under the testbench. To watch the fifo checker inside the DMA command fifo, expand top.u_dma.u_cmd_fifo.chk. Assertion results, the checker's local bookkeeping signals, and its ports all appear there. Teams new to bind routinely hunt the TB tree and conclude the checker 'is not there'.

WAVE BROWSER VIEW

  top
   ├─ tb_env            ← TB classes are NOT here either way
   └─ u_dma
       └─ u_cmd_fifo            [RTL]
           ├─ count[4:0]
           ├─ ...rtl signals...
           └─ chk                [DV]  ← bound checker lives HERE
               ├─ a_no_push_full      ← assertion status signal
               ├─ a_count_range
               └─ ports (clk, push, count...)

Binds and generate scopes

Binding to a module hits instances created inside generate loops too — each generated instance gets its own checker, which is usually exactly right. Binding into a specific generate block by path is where portability ends: the path includes the generate block label and index (u_top.g_lanes[3].u_lane), labels are easy to change, and unlabeled generate blocks get tool-assigned names that differ across simulators. Prefer module binds; when an instance bind into a generate scope is unavoidable, label every generate block explicitly.

Performance of massive bind farms

• Assertions are cheap individually; thousands of bound instances each evaluating multi-cycle properties every clock are not. Profile before assuming binds are free.

• Liveness properties with long bounds (##[1:4096]) keep many in-flight attempt threads per instance — the usual hotspot in a bind farm.

• Per-subsystem SVA_ON macros let regressions disable whole checker families to isolate a slowdown in minutes.

• Heavy covergroups bound per-instance multiply fast: 500 fifo instances times a per-instance covergroup is a memory problem, not just CPU.

Interview angle: bind vs inline assertions

A favorite senior-interview discussion: why not just write assertions inside the RTL? The honest answer is a tradeoff, not a slogan.

BIND vs INLINE — THE TRADEOFF

                      inline (in RTL)         bind (DV-owned)
  ─────────────────────────────────────────────────────────────
  ownership           RTL team                DV team
  RTL edits needed    yes                     no
  designer intent     captured at write       reconstructed later
  internal access     trivial                 via port map
  synthesis           needs pragmas/guards    naturally excluded
  reuse               none (design-specific)  library, bind anywhere
  survives refactor   moves with the code     bind file maintenance
  review path         RTL review              DV review
  best for            design invariants the   protocol/interface
                      designer knows          checks, whitebox DV,
                      (FSM, corner cases)     anything reusable

Strong answer in an interview: designer-written inline assertions capture intent nobody else has, and belong in the RTL; everything reusable, protocol-level, or DV-initiated goes through bind so ownership and synthesis cleanliness stay intact. Most mature flows use both.

Key takeaways

• Bind failures appear at elaboration: signal-not-found, parameter mismatch, target-not-found — all routine maintenance after RTL drops.

• Bound checkers live under the target's wave path, not the TB tree — top.dut...chk, every instance.

• Module binds reach into generate loops correctly; instance binds into generate scopes are fragile — label blocks or avoid.

• bind vs inline is an ownership question: designer intent inline, reusable/protocol checks via bind — use both.

Common pitfalls

• Hunting for the checker under the testbench hierarchy — it elaborates under the DUT path.

• Instance-path binds into unlabeled generate blocks — tool-assigned names differ across simulators; non-portable.

• Blaming the simulator for a slow regression before profiling thousands of long-bound liveness properties in a bind farm.

• Framing bind vs inline as either/or in interviews — the expected answer is the ownership-based split.