Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • Start Here6
  • SystemVerilog Language Foundations28
  • Object-Oriented SystemVerilog for Verification30
  • Constraint Randomization — Interview-Critical Deep Dive36
  • SystemVerilog Assertions — Interview-Critical Deep Dive40
  • Functional Coverage in SystemVerilog22
  • Testbench Architecture in SystemVerilog23
  • Advanced Language & Integration25
    • DPI-C: Calling C from SystemVerilog
    • bind: Attaching Verification to RTL
      • Bind Fundamentals
      • Writing Assertion Modules for bind
      • Bind File Organization
      • Reusable Checker Libraries
      • bind Debug & Limitations
    • Macros, Defines & Compilation
    • Plusargs, Files & Runtime Configuration
    • Simulation Performance & TB Memory
    • RTL/TB Boundaries, Races & Timing
  • Senior & Interview Preparation21
  • Principal-Level Verification28
Loading lesson

‹bind: Attaching Verification to RTL
  1. Topics
  2. SystemVerilog
  3. Advanced Language & Integration
  4. bind: Attaching Verification to RTL
  5. Bind File Organization

Part 7 · Advanced & Integration · Intermediate

Bind File Organization

One bind file per subsystem, file-list order, synthesis guards, and DV ownership.

On this page

    One bind file per subsystem

    Bind statements scattered through testbench files become unfindable. The convention that scales is a single <subsystem>_binds.sv file per subsystem, owned by DV, holding every bind that targets that subsystem's RTL.

    That file is the one place to look when asking what is attached to a design. The listing below is a build file, not compiled in this course's checks: bind files are guarded out of synthesis and never appear in synthesis file lists.

    design.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    // dma_binds.sv — ALL verification attached to the DMA subsystem
    `ifndef SYNTHESIS
    `ifdef DMA_SVA_ON
    
    // protocol checkers on external interfaces
    bind dma_top vr_checker #(.WIDTH(DATA_W)) chk_m_axis (
      .clk(clk), .rst_n(rst_n),
      .valid(m_axis_tvalid), .ready(m_axis_tready), .data(m_axis_tdata));
    
    // whitebox checks on internal blocks (every instance)
    bind dma_fifo fifo_bound_checks #(.DEPTH(DEPTH)) chk_fifo (.*);
    bind dma_arb  arb_checker        #(.N(REQ_N))    chk_arb  (.*);
    
    `endif
    `endif
    • One file covers one subsystem. Never mix subsystems; the file name says what it covers.

    • Instance names start with `chk_`. Bound instances are instantly recognizable in hierarchy browsers and wave paths.

    • Group by kind. External protocol checks first, whitebox module binds next, instance-specific binds last.

    File order and guards

    Order file lists so RTL comes first, checker modules next, and bind files last. This is tool-robust ordering advice for joint elaboration, not a language compilation-order rule: units elaborate together, but some tools resolve bind targets better in this order.

    Diagram
    COMPILE ORDER
    
      dma.f (file list)
      ──────────────────────────────
      1.  rtl/dma_top.sv            ┐
          rtl/dma_fifo.sv           │  RTL: the bind TARGETS
          rtl/dma_arb.sv            ┘
      2.  dv/checkers/vr_checker.sv ┐
          dv/checkers/arb_checker.sv│  checker MODULES
                                    ┘
      3.  dv/binds/dma_binds.sv     ← BINDS last
    
      +define+DMA_SVA_ON            ← enable knob on the sim command line
      Synthesis file list: item 1 only. Binds are never listed.

    Two guards serve two purposes. ifndef SYNTHESIS is defensive: even if a bind file leaks into a synthesis list, the tool sees nothing. ifdef DMA_SVA_ON is the operational knob: one minus-define disables a subsystem's checkers during bring-up or a slowdown hunt, with no file-list surgery.

    Who owns the binds

    Bind files and checker modules live in the DV tree and go through DV review. RTL reviews never see assertion churn, and the bind file is the contract surface RTL engineers read to learn what is watched.

    Diagram
    REPO LAYOUT
    
      rtl/                         <- RTL ownership, synthesis-clean
        dma_top.sv  dma_fifo.sv  dma_arb.sv
      dv/
        checkers/                  <- reusable, bind-safe modules
          vr_checker.sv  arb_checker.sv
        binds/                     <- one file per subsystem
          dma_binds.sv  eth_binds.sv  pcie_binds.sv
        flists/
          dma_sim.f                <- RTL + checkers + binds
          dma_syn.f                <- RTL only

    Common pitfall

    A bind whose checker module is missing from the file list (or library) fails at elaboration with a missing-module error. Keeping the RTL, checkers, binds order in every file list makes such omissions easy to spot.

    Check yourself Bring-up is failing inside checker logic, not the RTL. How do you get a clean signal today without editing file lists?

    Drop DMA_SVA_ON from the command line. The ifdef guard compiles the subsystem out in one step, and the same knob re-enables it later.

    Check yourself RTL renames a signal that a bind maps. Who fixes it, and where?

    DV fixes it in the subsystem bind file. The elaboration error points at the bind line, and RTL keeps no legacy names for verification.

    Related topics

    • Bind Fundamentals

    • bind Debug & Limitations

    Previous

    192 / 259

    Next: Reusable Checker Libraries

    Up next

    Up nextReusable Checker Libraries

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Bind Fundamentals
    • bind Debug & Limitations