The bind Construct

Module 17 · Page 17.2

bind lets you instantiate one module inside another module's scope from a completely separate file — without editing the target. Its overwhelming use in industry is attaching an SVA/coverage checker to an RTL block: the checker sees the RTL's internal signals as if the assertions were written inside it, yet the RTL file is never touched. That separation is what makes bind essential when the RTL is encrypted, owned by another team, or simply must stay clean of verification code. This lesson covers both bind forms (to a module type vs a single instance), the port-connection rules including .*, passing parameters through, the canonical three-file FIFO-checker example, and the decision between bind and direct instantiation.

1. Engineering Problem — Verifying RTL You Cannot Edit

You want to add assertions to a FIFO: "never write when full," "never read when empty," "full and empty are never both high." The obvious move is to write assert property blocks inside fifo.sv. But on a real project that file is off-limits:

• It is owned by the RTL team; verification edits cause merge conflicts and review friction.
• It may be encrypted or read-only IP — you physically cannot add lines to it.
• Even when you can edit it, mixing testbench-only assertions into synthesizable RTL pollutes the design and risks the assertions reaching synthesis.

The naive alternative — pull the internal signals up to the testbench through hierarchical references and assert there — is fragile, verbose, and breaks the moment the hierarchy changes. bind solves the problem at the language level: you write the checker as a normal module in your directory, write one bind statement in your filelist, and the elaborator injects the checker into the target's scope with full access to its internal signals. The RTL stays byte-for-byte unchanged.

2. Mental Model — Inject a Checker Into the Target's Scope

The picture every engineer carries:

bind is a non-intrusive instantiation. At elaboration the simulator inserts an instance of your checker module inside the target module's scope — exactly as if someone had typed fifo_chk u_chk(...); at the bottom of fifo.sv, but without anyone touching fifo.sv. Because the checker lives inside the target's scope, its port connections reference the target's own internal signals, and any assertion it contains fires with the target's time and signal context. The bind statement itself lives in a separate file that goes on the testbench/verification filelist, never the RTL list.

Four invariants this picture preserves:

• The RTL is never modified. The checker and the bind statement are separate files. This is the whole point — zero merge risk, works on encrypted IP.
• Port connections see the target's internals. The right-hand side of .port(signal) refers to a signal inside the target module, not a testbench signal. A bound checker cannot reach testbench-scope signals.
• Bind to a type hits every instance; bind to a path hits one. bind fifo … attaches the checker to every fifo in the design; bind top.u_dut.u_tx_fifo … attaches it to that one instance only.
• bind is verification-only. Use it for assertions, covergroups, $display/$monitor, and DPI calls — never to add synthesizable logic. Synthesis ignores or rejects bound modules.

3. Visual Explanation — What Elaboration Produces

Three files, one result: the checker ends up inside the RTL's scope, wired to the RTL's own signals, with the RTL untouched.

In three steps: (1) write the checker as a normal SV module whose ports match the signals you want to observe; (2) write bind target_module checker_name instance_name (connections); in a separate file; (3) add the checker and the bind file to the simulation filelist — the RTL list stays unchanged.

4. Syntax — Both Forms

There are two targets a bind can name: a module type (every instance) or a hierarchical instance path (exactly one).

// ── FORM 1 — bind to all instances of a module TYPE ─────────────────
// Every `fifo` instantiated anywhere in the design gets a `fifo_chk` inside it.
bind fifo  fifo_chk u_chk (
    .clk   (clk),
    .rst_n (rst_n),
    .wr_en (wr_en),
    .rd_en (rd_en),
    .full  (full),
    .empty (empty)
);
 
// ── FORM 2 — bind to one specific INSTANCE in the hierarchy ─────────
// Only the fifo at this exact path gets the checker.
bind top.u_dut.u_tx_fifo  fifo_chk u_chk (
    .clk (clk), .rst_n (rst_n), .wr_en (wr_en),
    .rd_en (rd_en), .full (full), .empty (empty)
);
 
// ── SHORTHAND — implicit connections when port names match signals ──
bind fifo  fifo_chk u_chk (.*);

Reading the anatomy of bind fifo fifo_chk u_chk (.clk(clk), …); left to right: bind (the keyword) · fifo (the target — a module-type name, or a hierarchical path like top.u_dut.u_fifo) · fifo_chk (the checker module you wrote, which must be compiled and visible) · u_chk (the instance name for the bound checker — usable as a hierarchy path in waveform tools) · .clk(clk) (a port connection — left is the checker's port, right is the signal inside the target) · ; terminates the statement, which lives in any file except the target module itself.

5. bind with SVA — The #1 Use Case

The dominant industrial use is attaching an SVA/coverage module to an RTL block. The checker holds every assert property, assume property, and cover property; the RTL has no awareness of it. Here is the complete three-file pattern.

// ── File 1 of 3 — fifo.sv (RTL — the verification team never edits this) ──
module fifo #(parameter int DEPTH = 8, WIDTH = 8) (
    input  logic            clk, rst_n,
    input  logic            wr_en, rd_en,
    input  logic [WIDTH-1:0] din,
    output logic [WIDTH-1:0] dout,
    output logic            full, empty
);
    logic [WIDTH-1:0]      mem [0:DEPTH-1];
    logic [$clog2(DEPTH):0] wr_ptr, rd_ptr, count;
 
    always_ff @(posedge clk or negedge rst_n) begin
        if (!rst_n) begin
            wr_ptr <= 0; rd_ptr <= 0; count <= 0;
            full <= 0; empty <= 1;
        end else begin
            if (wr_en && !full)  begin mem[wr_ptr] <= din;  wr_ptr <= wr_ptr + 1; end
            if (rd_en && !empty) begin dout       <= mem[rd_ptr]; rd_ptr <= rd_ptr + 1; end
            count <= count + (wr_en && !full) - (rd_en && !empty);
            full  <= (count == DEPTH - 1);
            empty <= (count == 0);
        end
    end
endmodule

// ── File 2 of 3 — fifo_chk.sv (the checker — your file) ─────────────
module fifo_chk (
    input logic clk, rst_n,
    input logic wr_en, rd_en,
    input logic full, empty
);
    // One default clocking + reset disable for every property below
    default clocking cb @(posedge clk); endclocking
    default disable iff (!rst_n);
 
    // 1 — never write a full FIFO
    no_overflow_chk: assert property (!($past(full) && wr_en))
        else $error("FIFO OVERFLOW: wr_en asserted when full!");
 
    // 2 — never read an empty FIFO
    no_underflow_chk: assert property (!($past(empty) && rd_en))
        else $error("FIFO UNDERFLOW: rd_en asserted when empty!");
 
    // 3 — full and empty are mutually exclusive
    mutual_excl_chk: assert property (!(full && empty))
        else $fatal(1, "FIFO ERROR: full and empty both high — impossible state!");
 
    // Coverage — did we ever exercise these conditions?
    cov_fifo_full:  cover property (full);
    cov_fifo_empty: cover property (empty);
    cov_simult_rw:  cover property (wr_en && rd_en);
endmodule

// ── File 3 of 3 — bind_fifo.sv (glue — goes on the TB filelist, not the RTL list) ──
// Binds fifo_chk into EVERY instance of `fifo` in the design at once.
bind fifo  fifo_chk u_fifo_chk (
    .clk (clk), .rst_n (rst_n),
    .wr_en (wr_en), .rd_en (rd_en),
    .full (full), .empty (empty)
);
 
// To target a single instance instead, name its path:
// bind top.u_dut.u_tx_fifo  fifo_chk u_fifo_chk (.*);

$ vcs fifo.sv fifo_chk.sv bind_fifo.sv tb_fifo.sv -o sim && ./sim
Elaboration completed. Bound instance: top.u_dut.u_fifo.u_fifo_chk
...
ERROR: FIFO OVERFLOW: wr_en asserted when full!
       File: fifo_chk.sv  Time: 340ns  Assertion: no_overflow_chk
Coverage: cov_fifo_full  — hit at 260ns
Coverage: cov_fifo_empty — hit at 10ns

6. Bind to a Type vs a Specific Instance

This is the decision that most often bites: bind to a type and one statement covers every instance; bind to an instance path and you control each one individually.

// Design has two FIFOs — u_tx_fifo and u_rx_fifo, both of type `fifo`.
 
// Type bind — ONE statement covers BOTH:
bind fifo  fifo_chk u_chk (.*);
//  → top.u_dut.u_tx_fifo.u_chk AND top.u_dut.u_rx_fifo.u_chk both exist.
 
// Instance bind — different checker per instance:
bind top.u_dut.u_tx_fifo  fifo_chk    u_chk (.*);
bind top.u_dut.u_rx_fifo  fifo_chk_rx u_chk (.*);   // RX gets a different checker

7. Passing Parameters Through bind

A parameterised checker takes parameters via the #( ) syntax, exactly like a normal instantiation. The clean trick: connect them to the target's own parameters, and each target gets the right values automatically.

module fifo_chk #(parameter int DEPTH = 8, WIDTH = 8) (
    input logic            clk, rst_n, wr_en, rd_en, full, empty,
    input logic [WIDTH-1:0] din
);
    // Depth-aware property — a write (when not full) is followed by a non-empty FIFO
    assert property (@(posedge clk) disable iff (!rst_n)
        (wr_en && !full) |-> ##1 !empty)
        else $error("FIFO[depth=%0d] write-then-read failed", DEPTH);
endmodule
 
// DEPTH/WIDTH on the right resolve in the TARGET's scope → its own parameter values
bind fifo  fifo_chk #(.DEPTH(DEPTH), .WIDTH(WIDTH)) u_chk (
    .clk (clk), .rst_n (rst_n), .wr_en (wr_en), .rd_en (rd_en),
    .full (full), .empty (empty), .din (din)
);

8. bind vs Direct Instantiation

bind is not always right. Direct instantiation (writing the checker instance in a file you control) wins when the checker needs testbench-scope signals.

The rule: bind for non-intrusive, verification-only content attached to the DUT; direct instantiation when the checker must see signals that live in the testbench, or when the logic is genuinely part of the synthesizable design.

9. Industry Usage — Where bind Shows Up

• Assertion/coverage decks on third-party or RTL-team IP — the canonical case; ship a checker library, bind it, never touch the RTL.
• Protocol monitors — bind an AXI/APB/SPI protocol checker to every bus interface instance with one type-bind statement.
• Formal verification harnesses — bind property modules onto the DUT so the formal tool proves them in the RTL's own context.
• UVM environments — bind an interface or assertion module into the DUT, then reach it from the testbench (e.g. a bound interface whose virtual handle is published to the uvm_config_db).
• Coverage closure — bind covergroups onto internal RTL state without editing the design, keeping coverage code in the verification tree.

10. Debugging Guide — The Mistakes Everyone Makes Once

// ❌ inside fifo.sv — wrong
module fifo(...);
  bind fifo fifo_chk u_chk(.*);   // illegal / pointless
endmodule

module fifo_chk(input logic write_enable, ...);   // name ≠ wr_en
bind fifo fifo_chk u_chk (.*);                     // write_enable left undriven

bind fifo fifo_overflow_chk  u_chk (.*);   // u_chk
bind fifo fifo_underflow_chk u_chk (.*);   // ❌ same name → collision

bind fifo fifo_overflow_chk  u_ovf (.*);
bind fifo fifo_underflow_chk u_unf (.*);

11. Q & A

12. Cross-References & What's Next

This lesson covered bind — its two target forms, port-connection rules, parameter passing, the SVA-checker pattern, and the choice against direct instantiation.

• Previous: 17.1 — Direct Programming Interface (DPI-C) — the other Module 17 mechanism for attaching external behaviour; a bound module can itself contain DPI calls.
• Module index: Module 17 — Advanced Topics — the advanced-feature arc.

Related material elsewhere in the curriculum:

• Concurrent Assertions — the SVA properties that a bound checker module carries.
• Intro to SVA — assertion fundamentals; bind is how those assertions reach RTL you don't own.

13. Quick Reference

// ── Bind to ALL instances of a module type ──────────────────────────
bind target_module  checker_module instance_name (.port(signal), ...);
 
// ── Bind to ONE specific hierarchical instance ──────────────────────
bind top.u_dut.u_fifo  checker_module instance_name (.port(signal), ...);
 
// ── Implicit connections when port names match signal names ─────────
bind target_module  checker_module instance_name (.*);
 
// ── With parameter overrides (resolve in the target's scope) ────────
bind fifo  fifo_chk #(.DEPTH(DEPTH), .WIDTH(WIDTH)) u_chk (.clk(clk), ...);
 
// ── Multiple checkers on one target — UNIQUE instance names ─────────
bind fifo  fifo_overflow_chk  u_ovf (.*);
bind fifo  fifo_underflow_chk u_unf (.*);
 
// ── Conditionally disable a bound deck at elaboration ───────────────
// simulator command: +define+DISABLE_FIFO_CHK
`ifndef DISABLE_FIFO_CHK
  bind fifo  fifo_chk u_chk (.*);
`endif
 
// Rules: bind file lives OUTSIDE the target (TB filelist); ports see the
// target's OWN signals; verification-only (no synthesizable logic).

14. Summary

bind instantiates a module inside another module's scope from a separate file, so verification code attaches to RTL without editing the RTL — the answer when the design is encrypted, owned by another team, or must stay clean of testbench logic. The checker is a normal SV module; the bind statement lives on the verification filelist; at elaboration the simulator injects the checker into the target, wired to the target's own internal signals.

The mechanics: bind to a module type to cover every instance with one statement, or to a hierarchical instance path to target exactly one; connect ports explicitly or with .* (names must match), and never leave a checker port undriven; pass parameters with #( ), connecting to the target's own parameters so each instance specialises automatically. Reach for direct instantiation instead only when the checker needs testbench-scope signals or the logic is synthesizable. By far the most common use is an SVA/coverage deck bound onto an RTL block — the FIFO example — where assertions fire with the RTL's own time and signal context while the RTL file stays untouched. bind is verification-only: assertions, coverage, $display, and DPI — never gates.