A security conclusion must say what is protected, which faults are assumed, which boundaries were tested, which counterexamples remain, and what is unknown. An evidence package is not a pile of reports; it lets another engineer reproduce the result and see its limits.
From claim to evidence
A building inspection cannot end with a “passed” sticker; the reader needs the inspected floors, date, and inaccessible rooms. Hardware review likewise starts from a falsifiable claim, such as: “Under at most one transient upset to the saved flag, with checker, clock, reset, and acceptance endpoint trusted, no unauthorized transaction commits.” The analogy does not replace a product threat model or certification.
A claim lists asset and acceptance boundary, attacker capabilities, fault target/effect/timing/budget, trusted components, environment, design revision, and exclusions. Label evidence as requirement, RTL review, simulation, formal, netlist, physical measurement, or product test. These levels are not interchangeable.
Coverage is more than one percentage. List denominators and gaps across target × effect × time × lifecycle × reset/domain bins; include fault-free/authorized controls, counterexamples, and replay hashes. Link each counterexample to root cause, fix commit, and retest. Unsupported or unobservable cases are unknown, not covered.
Separate conclusions into “no counterexample found in scope,” “counterexample exists,” “evidence missing,” and “assumption unverified.” The first does not mean zero risk. A product owner must accept residual risk; a model summary cannot do so.
Make review reproducible
Include claim ID, revision and source, tool/command, inputs and seeds, hashes, classification rules, coverage matrix, failing traces, limits, unknowns, owner, and date. Let the reviewer choose one likely challenge to the claim, then replay both a counterexample and a control case.
Offline interactive lab
RTL / SVA review direction
These are property sketches: define the harness transaction, reset and oracle, then confirm sampling boundaries before binding to the design. They have not been compiled or proven.
assert property (@(posedge clk) disable iff (!rst_n)
accepted_commit |-> reference_authorized);cover property (@(posedge clk) disable iff (!rst_n)
accepted_commit && reference_authorized);If accepted_commit never occurs, the implication can pass vacuously because its antecedent is false. Use a cover property to show that a legitimate acceptance path is reachable. This does not prove the fault path is available; record failures to activate separately as availability cases.
This snippet does not prove CDC, timing, side-channel, or physical injection behavior; each requires its own tool evidence or measurement.
Check your reasoning
- Recognition — What is the difference between a security claim and its evidence? Reasoning: A claim states what should hold under stated assumptions. Evidence records the artifact, method, inputs, and observations used to assess it.
- Contrast — How does an independent test oracle differ from a chip defense? Reasoning: The oracle supplies expected outcomes to the testbench. It does not stop the DUT from accepting an unauthorized operation.
- Scenario — A reviewer receives a counterexample screenshot without a seed or input trace. Can it be replayed? Reasoning: Not reliably. Provide the source/DUT hash, tool and version, configuration, seed, input, expected result, and replay command.
- Failure diagnosis — A report says 95% coverage but gives no denominator or untouched bins. What remains unknown? Reasoning: The reviewer cannot tell which target/time cases were covered or what the percentage counts. Report the denominator and empty bins.
- Design risk / transfer — Physical validation is outside this campaign. What belongs in the release packet? Reasoning: Name it as an open unknown, state the consequence and owner, and define the evidence needed. Do not turn an incomplete packet into product assurance.
References
MY ACADEMY · LESSON FILM
Lesson video
The film explains this lesson’s data path. After a section, return to the interactive exercise and change the input or fault conditions. The animation presents a teaching model; it does not replace RTL simulation.
Swipe the film horizontally, or use the arrow keys to inspect the diagrams.
Diagram scope
Teaching model · Not RTL simulation or silicon testing
Replayable evidence supports stated scope; not product validation, certification or risk acceptance
Narration uses a synthetic voice. Both the interaction and animation have model boundaries; interpret results using this lesson’s sources and validation scope.
Wrap-up: take this lesson into a design review
- Threat model and assumptions
A claim bounds the asset, acceptance boundary, fault capability, trusted components, revision, and exclusions.
- Why the design fails
A single pass rate, tool PASS, or lack of counterexamples is treated as universal security despite gaps and unverified assumptions.
- Defenses
Link each claim to replayable evidence, coverage denominators, counterexamples, fixes, and the residual-risk owner.
- Validation and checks to perform
Check revision/hash/commands/seeds/coverage bins/controls/counterexamples/limits/unknowns; a second reviewer can replay samples.
- Limits and unverified claims
Documentation and model evidence support only their stated scope; they do not replace product validation, certification scope, or risk decisions.
Try a changed assumption
Choose an unverified CDC assumption. Add minimum acceptable evidence and an owner; which gaps must block release?
This wrap-up summarizes the lesson’s teaching cases, references and experiment scope. Checks not reported as completed remain future work.