An assistant can explain unfamiliar RTL, draft modules and testbenches, and review for common bugs. Check its claims against approved requirements, actual source, and relevant results. The illustrative testbenches below investigate specific behaviors; their expected PASS messages are not reports of executed checks or proof of overall correctness.
Task | Give the assistant | Demand back |
|---|---|---|
Explain code | Interface, parameters, clock and reset, neighbors | A signal table plus a list of assumptions |
Draft RTL | Written spec, constraints, coding rules | Code plus stated assumptions and corner behavior |
Draft a testbench | DUT interface and the corner list | Self-checking checks with expected values |
Review | The code and the rules it should follow | Named findings with line references and a fix |
Assert | The property in plain words plus timing | An assertion plus the case that would fail it |
Lesson | What it covers |
|---|---|
Pasting the boundary first, chunking, and checking every claim. | |
Interface spec, constraints, coding rules, and a width-bug catch. | |
Corner lists, signedness traps, and self-checking structure. | |
Checklists for latches and widths, plus asking for assertions. | |
Trace assumptions to requirements and evidence, then record remaining gaps. |
Typical values may miss boundary behavior, and the checker may encode the wrong requirement. Compare expectations with the approved specification and identify missing cases. A passing run supports only the behavior and conditions actually checked.