A transaction class randomizes reliably in directed tests, but constrained-random regressions start failing with no-solution messages after incremental feature constraints are added.
The signal you would look at: Sharp increase in randomize failure percentage for specific scenario knobs and seed ranges.
Whether you treat constraints as one declarative system that must have a solution, not as lines executed in order.
Whether you can shrink a failing constraint set to the smallest conflicting group instead of reading all of it.
Whether you fix the intent (which rule is wrong) instead of switching constraints off.
Follow these steps in order. The order matters: each step narrows the search so that the next one is cheap.
Confirm the failure is a randomize() return of 0 and note the knob values at the failure: which mode, which inline with, which constraints are enabled.
Reproduce with one fixed set of knobs. A failure that depends on knobs points to a conflict between a knob-dependent implication and another constraint.
Bisect: turn constraint blocks off one at a time with constraint_mode(0) and see when the call starts passing. The last block whose removal fixes it is part of the conflict.
Check the quiet sources of conflict: an inline with that is ANDed with the class constraints, a variable frozen by rand_mode(0), a value set in pre_randomize that the solver overwrites, and width wrap in a sum or comparison.
Prove the diagnosis by writing down one tuple that should be legal and showing which constraint rejects it.
Fix the contradictory rule, keep the others, and add a check that the randomize result is tested and the knobs are printed on failure.
A model transcript of the first part of the round. Do not memorise the words; copy the order of the moves.
Interviewer: Randomization worked until last week. Now some seeds report no solution. How do you debug it?
Candidate: First I check what is common to the failing runs: which knob values or inline constraints are in play. Failures that depend on a knob usually mean an implication that only bites in that mode.
Interviewer: They all use the secure mode with an address range from the test.
Candidate: So the inline with is ANDed with the class constraints. If the secure branch forces the address into one region and the test asks for another, the intersection is empty and randomize returns 0.
Interviewer: How do you prove that without reading the solver output?
Candidate: I would turn the secure constraint off with constraint_mode(0) and see the call pass. Then I write down one address that should be legal and show which rule rejects it.
Interviewer: The team wants to keep the constraint off, since it makes the tests pass.
Candidate: That removes a rule the design needs. I would fix the test range, or make the class rule match the real requirement, and check the randomize result so a future conflict fails loudly with the knobs printed.
Interviewer: What else could produce the same symptom?
Candidate: A variable frozen with rand_mode(0) at a value the branch cannot accept, or a value assigned in pre_randomize that the solver overwrites, or an arithmetic constraint where the width wraps the sum. I would check those three next.Debugging solver internals before checking contradictory implication constraints.
Using broad soft constraints that silently mask intent until override order changes.
Disabling failing constraints globally instead of minimizing and proving satisfiability.
Ignoring the return value of randomize(), so a failure shows up later as stale values.
Work these cold, with the timer, before you rehearse the conversation.
randomize-with-02-inline-if-else: Constraint Override by Name in a Derived Class (M)
randomize-with-04-constraint-mode-toggle: constraint_mode Changes Pass/Fail (E)
randomize-with-05-rand-mode-freeze: rand_mode(0) Freezes Value and Can Overconstrain (M)
constraint-order-05-relational-counting: Width Wrap in a Sum Constraint (H)