SystemVerilog Constraint Interview Questions: Randomization Failures and Coverage Gaps

SystemVerilog constraint interview questions test whether you can describe legal stimulus, recognize when the legal set is empty, and explain why successful randomization still leaves functional coverage holes. The solver finds values satisfying active constraints. It does not know which scenario your verification plan still needs unless you model that intent.

Three separate events matter: a transaction is generated, the driver successfully presents it to the DUT, and coverage samples the behavior you intended to observe. Confusing these stages can make a testbench report progress while important cases remain untested.

This guide uses a small packet transaction as a running exercise. Treat every code fragment here as a focused experiment to run in your supported simulator, not as a promise of identical random sequences across tools.

What does a constraint block describe?

A constraint restricts the set of assignments that a randomized object may take. Several active constraints apply together. Unless the language construct explicitly describes a different relationship, one constraint does not simply run after another and overwrite its answer like procedural assignment.

class packet;
  rand bit [3:0] length;
  rand bit       is_control;

  constraint legal_length { length inside {[1:8]}; }
  constraint control_size { is_control -> length <= 2; }
endclass

For a control packet, length must satisfy both the general range and the implication. For a non-control packet, the implication imposes no additional length restriction. Explain the resulting legal sets before talking about how frequently each value should appear.

This is already a useful interview test: can you distinguish an implication from an equivalence? The constraint says control packets are short. It does not say every short packet must be a control packet. Add that reverse condition only if the specification requires it.

Why does randomize return zero?

One possible reason is that the active constraint system has no legal solution. Always check the return value. Continuing with old or otherwise unintended values after failure can create a misleading test trace.

packet p = new;
if (!p.randomize() with { length > 12; })
  $fatal(1, "Packet constraints have no solution");

The class restricts length to 1 through 8, while the inline constraint demands a value above 12. Their intersection is empty. An inline constraint is added to the active class constraints; it does not ordinarily erase them.

Diagnose the smallest contradictory subset. Start with variable widths, signedness, active modes, inline constraints, and any fixed state referenced by the constraints. A four-bit variable cannot represent arbitrary integers, so even a plausible-looking range can become impossible because of representation.

How should you debug a randomization failure?

Record the seed, simulator version, active test configuration, and relevant non-random state. Reduce the transaction to the variables and constraints involved in the failure. Use the simulator's constraint-debugging facilities when available, but still explain the contradiction in terms of the modeled legal set.

Temporarily disabling a constraint can help isolate the cause. It is a diagnostic step, not an automatic final repair. If the disabled constraint represents a real protocol rule, removing it can make the test pass by generating illegal traffic.

Distinguish an impossible specification from an incorrectly encoded one. For example, a packet type may allow lengths 1 to 8, but a test asks specifically for length 12. Either the test's requested scenario is invalid or the model's allowed range does not match the design. The solver cannot decide which requirement the team intended.

After fixing the issue, keep a small regression for the exact conflicting configuration. A broad random test may not revisit the same setup soon, especially when the conflict depends on a rare mode combination.

What is the difference between rand_mode and constraint_mode?

rand_mode controls whether a randomized variable participates as a variable to be randomized. constraint_mode controls whether a constraint block is active. Turning off randomization of a variable does not necessarily remove constraints that refer to it; its current value can still affect satisfiability.

Suppose is_control is held at one while a test requires length eight. With the control-size constraint active, the combination remains illegal. Disabling randomization of is_control does not tell the solver to ignore the relationship.

Change	What to reason about
Disable a constraint block	The legal set may become larger
Disable randomization of a field	Its current value may constrain the remaining solution
Add an inline constraint	The legal set is narrowed by another requirement
Change a non-random mode	Referencing constraints may allow a different set

In an interview, state the current field values as well as the enabled modes. Otherwise, two apparently identical calls can be operating on different constraint problems.

How do hard and soft constraints differ?

A hard constraint must be satisfied. A soft constraint expresses a preference that can be discarded when stronger applicable requirements conflict with it under the language rules. This can make reusable transaction defaults easier to specialize for a test.

For example, a default preferred packet length may be soft while protocol legality stays hard. A directed test can ask for a different legal length without fighting the default. It should not override a genuine protocol limit merely because that would be convenient.

Keep defaults and invariants separate in the model. Labeling every condition soft can silently weaken the contract and make failures harder to diagnose. A good answer explains which rule comes from the design specification and which is only the generator's usual choice.

Test both the ordinary default and an intentional override. Then test an actually illegal request and confirm that it still fails. These three cases show that flexibility did not erase the safety boundary of the stimulus model.

What does dist change?

Distribution constraints influence how legal values are weighted. They do not make contradictory values legal or guarantee that every run will hit a rare bin. Small samples can vary even when the distribution is configured correctly.

For ranges, understand the difference between assigning weight to each value and assigning a total weight across the range. In dist syntax, := and :/ express different weighting behavior. A range with many values can therefore receive very different total probability depending on the operator.

In an interview exercise, compare a single value with a four-value range. Write the intended relative probability for the whole range first, then choose the syntax. This avoids accidentally making a broad range far more common than intended.

Verify with a histogram over enough trials for the purpose, while recognizing that empirical counts do not prove every detail of a solver implementation. Keep the legality checks independent of the distribution checks so a desirable histogram cannot hide invalid traffic.

Does solve before execute assignments in order?

No. solve ... before ... influences solution distribution for certain variables; it is not a procedural program that assigns the first variable and then ignores the rest of the constraint system. The values still must satisfy the active constraints together.

A classic exercise uses a mode bit and a payload field where one mode permits only a few payload values and another permits many. Without an ordering constraint, reasoning about probability by counting only the modes can be misleading. Ordering can change how the solver selects among legal combinations.

Explain legality and distribution separately. Ask first whether a pair is allowed. Ask second how the generator is intended to distribute trials among allowed pairs. If a proposed ordering is supposed to fix an empty legal set, the explanation is wrong: distribution choices cannot create a legal solution where none exists.

Why can coverage stay low when randomize succeeds?

Successful randomization proves only that this generation step found a legal assignment. Coverage may describe combinations that are rare, unreachable, blocked by driver behavior, or sampled at the wrong time.

Suppose the generator creates a long packet, but backpressure causes the driver to abort before the DUT accepts it. Sampling the generated object can count an attempted scenario that never occurred. Sampling only accepted transactions may correctly show that the long-packet bin is still empty.

Alternatively, the coverage model may include an impossible combination, such as a control packet with a length prohibited by the protocol. Repeatedly increasing test duration cannot reach a truly illegal combination. Review the bin against the specification before spending compute on more random seeds.

A third possibility is a plain connection bug: the monitor sees the transaction, but the covergroup never samples or samples stale values. Add a small directed case with a known expected bin and trace the observation path end to end.

How do you investigate a missing cross bin?

Take the exact pair of values defining the empty bin. Ask whether the design permits it, whether the generator can produce it, whether the driver can deliver it, and whether the monitor samples it correctly. That sequence narrows the problem without assuming the solver is at fault.

Finding	Next action
Legal but very rare	Add targeted constraints or appropriate weighting
Generator cannot produce it	Inspect conflicting constraints and fixed modes
Generated but not accepted	Inspect handshake, reset, and protocol prerequisites
Accepted but not sampled	Inspect monitor timing and coverage connections
Impossible by specification	Document a justified coverage exclusion

An exclusion needs evidence. Do not use ignore bins to make a percentage look better when the case is merely difficult to generate. Conversely, do not leave impossible bins in the goal and call every run incomplete forever.

How should seeds and reproducibility be discussed?

Record enough context to reproduce the actual failing test, not just a single integer seed. Testbench changes, object creation, tool version, and configuration can affect random behavior. Reproducibility is a property of the environment and sequence of operations as well as the seed.

When reducing a failure, preserve the constraint relationship that matters even if the exact random sequence changes. A small deterministic contradiction is more useful for understanding a solver failure than a large test that occasionally returns zero without diagnostic context.

For coverage work, report what was exercised and under which constraints. A seed count alone says little about meaningful coverage if every run generates nearly identical traffic. Keep legal-space exploration tied to the verification plan's scenarios.

A focused practice exercise

Build the packet class above, check every randomize result, and add three tests: an ordinary legal packet, a directed legal boundary length, and an impossible inline constraint. Then add a monitor-side coverage model that samples accepted transactions rather than generation attempts.

Introduce backpressure deliberately and show why generated counts and accepted counts differ. Finally target a legal cross bin and explain how your change improves its chance without breaking protocol legality. This gives you a complete interview story: model, diagnose, observe, and justify coverage.

Sources and Further Reading

• Accellera SystemVerilog resources
• Accellera UVM standards and reference material
• Verification Academy discussions on constraints

Research checked September 24, 2026. Verify syntax and solver diagnostics against the SystemVerilog standard and simulator version used for the exercise. Examples are original practice scenarios.