Silicon verification builds evidence that a chip design satisfies its requirements. A useful plan connects each requirement to a stimulus, an independent check and a coverage goal. The result should explain what was tested or proved, under which assumptions, and what remains unresolved.
Choose methods for specific questions
Before fabrication, engineers can investigate design models through simulation, formal analysis and hardware-assisted execution. Cadence’s functional-verification overview describes these complementary approaches. Each offers evidence with a scope.
On narrow screens, focus the table and use the arrow keys or swipe to see every column.
| Method | Useful evidence | Boundary to record |
|---|---|---|
| Simulation | Observed responses to selected tests, checked against expectations. | Tests, random seeds, model fidelity and checks enabled. |
| Formal analysis | A property proved under stated assumptions, or a counterexample. | Assumptions, proof scope, bounds and inconclusive properties. |
| Emulation or prototyping | Longer hardware/software scenarios on a mapped design. | Mapping differences, observability and supported behavior. |
| Post-silicon validation | Behavior of fabricated devices in a real system. | Board revision, firmware, operating conditions and sample coverage. |
After fabrication, bring-up establishes enough working behavior to investigate the real device and its software. Cadence’s hardware/software co-verification explanation shows why focused tests and software workloads can span models, prototypes and silicon. Manufacturing defect tests answer another question: whether an individual manufactured part contains targeted faults. See embedded-memory testing and MBIST for that distinction.
Turn a requirement into a check
Start with observable behavior. Replace “the queue works” with a statement identifying accepted operations, data order, reset behavior and boundary conditions. Assign an identifier so the test, checker, coverage and issue tracker can refer to the same requirement.
A monitor observes what the design actually accepted. A scoreboard compares those observations with an independently maintained expected result. Coverage records which intended situations occurred. Accellera’s UVM 1.2 user guide, sections 4.9–4.10, illustrates scoreboard and coverage construction. This is a methodology reference; use the UVM release page to match library and simulator versions for an implementation.
Keep checks independent enough to expose design errors. A scoreboard that copies the same faulty algorithm can agree with the design while both violate the requirement. Review the expected behavior directly against the specification.
Work through an eight-entry FIFO
Illustrative specification: one clock controls an eight-entry, first-in-first-out queue. Operations are sampled on its rising edge. Reset has priority and empties the queue. A write is accepted only when occupancy before the edge is below eight; a read is accepted only when that occupancy is above zero. There is no empty-queue bypass. If both operations are accepted, the read returns the oldest item and the write appends the new item.
On narrow screens, focus the table and use the arrow keys or swipe to see every column.
| Starting state | Requests at the edge | Expected result |
|---|---|---|
| Empty | Write A | Accept write; occupancy 1. |
| One item: A | Read and write B | Return A; retain B; occupancy 1. |
| One item: B | Read | Return B; occupancy 0. |
| Empty | Read and write C | Accept only write; occupancy 1; no valid read result. |
| Full: eight items | Read and write D | Accept only read; occupancy 7; D is not stored. |
For each edge without reset, expected occupancy is previous occupancy + accepted writes − accepted reads. Check the count stays between zero and eight, and check data ordering separately. Add reset while occupied, long stalls, repeated full/empty transitions and pointer wraparound. The full-queue rule is a deliberate choice in this example; a design that allows a simultaneous replacement when full needs a different specification and checker.
Record coverage for both ordinary and boundary cases. Merely executing a source-code line says little about whether the queue was full, whether reset interrupted a transaction, or whether returned data was checked. A passing test with a disabled checker supplies weak evidence.
Make a reviewable completion record
- Identify the exact design, testbench and tool revisions, configuration and reproducible commands.
- Link each requirement to its checks and coverage results. Investigate uncovered cases instead of declaring success from a percentage alone.
- Separate proved properties, passing simulations, bounded results, waived items and unresolved failures.
- Review assumptions and waivers with an owner and reason. Confirm that excluded behavior is also excluded by the intended operating contract.
- Retain regression results and a small reproducible case for every fixed bug. Re-run the affected checks after relevant changes.
Use the verification evidence record (plain text) to document this chain for one requirement. Sign-off is a review of accumulated evidence and remaining risk; its meaning comes from the recorded scope.