How FPV differs from simulation in practice
| Question | Simulation answer | FPV answer |
|---|---|---|
| What drives the inputs? | Your testbench | The tool: any value on any cycle, unless an assumption forbids it |
| Which values are checked? | Those that occur in your tests | All values allowed by assumptions — including the "weird" ones |
| How big can the model be? | Whole chips | Typically blocks of thousands to low hundreds of thousands of flops; more with abstraction |
| How do you reach a scenario? | Write a directed or constrained-random test | Write a cover; the tool finds the shortest path |
| What does debug look like? | Long logs and waveforms | Short, minimal traces of a few to a few dozen cycles |
| When are you done? | Coverage closure | All assertions proven (or justified bounded), covers hit, quality checks passed |
Choosing how deep to go
You do not have to aim for full signoff on every block. Chapter 1 introduced the usage models; the following chapters show two of them in depth:
- Design exploration (Chapter 5): fast feedback for designers, mostly covers, little rigour required.
- Bug hunting and signoff (Chapter 6): complete property sets, quality checks and exit criteria.