Constraint Architecture for Transactions

Overview

Writing one constraint is syntax; organizing hundreds of constraints across a transaction family, a dozen tests, and a two-year project is architecture . The recurring failure of constrained-random testbenches is not a wrong constraint — it is constraints in the wrong place: legality baked into tests (so every test re-states the spec), test intent baked into base classes (so no test can escape it), and error injection bolted on with copy-paste. This topic covers the structural patterns that keep a constraint codebase composable: layering, knobs, policy objects, legality encoding, error-injection architecture, and scenario-level randomization.

The organizing principle throughout is the three-layer separation : the legality layer (what the protocol permits — lives in the base transaction, never disabled casually), the typicality layer (what realistic traffic looks like — soft defaults and dist weights, overridable), and the test-intent layer (what this test wants to stress — subclasses, inline constraints, policies, knobs). Interviews probe this constantly because it predicts whether your testbench scales past the third test.

Sub-topics

1. Layered Constraint Architecture — legality / typicality / test-intent layers and why base classes must not over-constrain.

2. The Knobs Pattern — control variables gating constraints and feeding dist weights, set from config.

3. Constraint Policy Classes — composable constraint objects referencing the transaction; mix-in per test.

4. Encoding Protocol Legality — translating a spec table into constraints; AXI-lite-style worked example.

5. Error Injection Architecture — error knobs, selective constraint disable, error subclasses, scoreboard handshake.

6. Randomizing Scenarios, Not Just Items — rand object arrays, inter-transaction relationships, scenario classes.

CONSTRAINT ARCHITECTURE TOPIC MAP

                 +---------------------------+
                 |   TEST INTENT (top layer) |
                 |  subclasses - inline with |
                 |  policies - knob settings |
                 +-------------+-------------+
                               | composes onto
                 +-------------v-------------+
                 |  TYPICALITY (middle)      |
                 |  soft defaults - dist     |
                 |  weights - knob defaults  |
                 +-------------+-------------+
                               | never violates
                 +-------------v-------------+
                 |  LEGALITY (base layer)    |
                 |  spec tables as           |
                 |  constraints - valid_c    |
                 +---------------------------+

  mechanisms that implement the layers:
    [Layering]    subclass adds constraints (AND semantics)
    [Knobs]       state vars gate/weight constraints
    [Policies]    external constraint objects, mixed per test
    [Legality]    spec table -> valid_c, one place only
    [Errors]      named-block disable + error subclass
    [Scenarios]   rand arrays of txns + inter-item constraints

Key takeaways

• Separate legality (base, permanent) from typicality (soft, default) from test intent (subclass/inline/policy).

• Inheritance ANDs constraints — a subclass can narrow but never widen; design base classes accordingly.

• Knobs and policies move stimulus shaping from code edits to configuration — the scaling mechanism.

• Randomize scenarios (relationships between transactions), not just isolated items — that is where cross-transaction bugs live.