Verification desk

Verification is an allocation of evidence against risk

The central question is not how many tests ran. It is whether the project gathered convincing evidence around the behaviors most likely to fail and most costly to miss.

Begin with failure, not stimulus

A verification plan should start from the design's responsibilities and credible failure modes. Interfaces can violate ordering or backpressure. State machines can enter an illegal or deadlocked state. Arithmetic can overflow or mishandle sign and width. Resets can leave blocks inconsistent. Clock-domain crossings can lose pulses or propagate unstable data. Configuration combinations can activate logic that ordinary directed tests never reach.

Turn each risk into an observable claim. Some claims become assertions: a request eventually receives a response, a queue never underflows, mutually exclusive grants never overlap. Some become scoreboard checks against a reference model. Some require structural analysis, formal proof, lint, or clock-domain checks. Simulation is a powerful evidence generator, but it should not be asked to establish properties that another technique can cover more directly.

Coverage is a question, not a percentage

Code coverage asks which implemented structures executed. Functional coverage asks which intended scenarios occurred. Assertion coverage asks which properties were exercised and whether they held. Bug trends and mutation-style experiments can ask whether the environment is capable of noticing realistic errors. A high number in one category cannot close a gap in another.

Every coverage item needs a reason. If a cross is too large to interpret, refine it around risk. If a line is unreachable by design, justify and exclude it explicitly. If a feature is safety-critical or expensive to repair, demand multiple independent forms of evidence. Coverage closure is the process of explaining holes, adding the right stimulus or checker, and recording intentional exclusions—not simply pushing a dashboard toward one hundred.

Debug speed belongs in the plan as well. Failures need deterministic seeds, concise messages, useful transaction logs, and waveforms that can be enabled without changing behavior. A regression that produces thousands of duplicate failures has less information than one that identifies the first violated assumption. Triage should connect a symptom to the requirement, checker, stimulus, design owner, and known-risk category.

Management questions are technical questions

Schedule and staffing choices determine what evidence can be produced. Managers need visibility into unverified features, unstable environments, recurring bug classes, long-running tests, and assumptions that only one person understands. “Good enough” is therefore an explicit risk decision: what remains unproven, why the remaining exposure is acceptable, and who owns the consequence.

Resource allocation should follow the design's risk profile. More random tests may help a mature environment explore combinations, while a weak checker merely allows more failures to pass unnoticed. A formal specialist may close a control property faster than a simulation campaign. Investing in reference models and observability early can shorten every later debug cycle.

Five papers and presentations in the directory

These entries identify works attributed in the period directory to Ira Chayut. No downloadable copies are offered here.