Functional Verification Interview Question: Simulator or More Compute

This functional verification interview question asks you to choose between keeping both a functional and a timing simulator, or dropping one of them to buy more compute. A strong answer keeps functional simulation, because it is where most bugs are found and fixed cheaply, and treats timing simulation and the FPGA board as complementary ways to catch timing problems. In practice most candidates should choose FTB, consider FCB, and reject TCB, but the interviewer cares far more about the reasoning than the letters.

Key takeaways

• Functional (zero-delay or RTL) simulation is the fastest and easiest place to debug, so it carries most of the verification load.
• Timing simulation checks the netlist with real delays, but it is slow, needs a synthesisable and placed design, and is hard to debug.
• An FPGA board runs the design at or near real speed, giving huge cycle counts but very little visibility.
• Ten times more simulation throughput does not mean ten times more confidence: coverage grows far more slowly than cycle count.
• There is no single right answer. You are marked on how you weigh coverage, debug effort, risk and cost.

The question

One day at the lunch table in the cafeteria, your manager says that she recently learned that X-SIM, the VHDL simulator that you have been using, has split their simulator into two products: one for functional simulation and one for timing simulation. She is considering buying either just the functional simulator or just the timing simulator, and using the money that she saves to buy more compute to speed up simulation.

Your current functional verification methodology uses a mixture of functional simulation, timing simulation, and running on an FPGA board. Your manager describes three options: FTB, FCB and TCB, where F means functional simulation, T means timing simulation, C means new computers, and B means FPGA board. All three options cost the same.

• FTB: Buy both the functional simulator and timing simulator, and continue with the current methodology.
• FCB: Do not buy the timing simulator; use functional simulation and FPGA boards for functional verification. Use the money saved by not buying the timing simulator to buy more computers, which will allow you to run functional simulation 10 times faster than you do now.
• TCB: Do not buy the functional simulator; use timing simulation and FPGA boards for functional verification. Use the money saved by not buying the functional simulator to buy more computers, which will allow you to run timing simulation at the same speed as you currently run functional simulation.

For each option, answer whether you think it should be chosen as the best option, considered as a possibility, or rejected. If you recommend that an option be chosen, then you must reject the other two options. For each option, briefly justify your recommendation in terms of its advantages and disadvantages.

Hint: There is no single right or wrong answer. Please try to argue through analysis.

Points to think through

The original hints for this question are still the right starting points:

• FTB allows the current methodology to be continued: the methodology is trusted and reliable, and there is no need for additional training.
• Functional simulation is insufficient on its own; you need timing simulation or running on the board to detect timing errors.
• Running functional simulation faster provides a minimal increase in actual coverage, because the fraction of the design's behaviour that simulation covers is so low.
• Debugging is much easier with functional simulation than with timing simulation, and debugging with timing simulation is much easier than debugging on the board.
• You could use the board as an alternative to timing simulation.
• Without functional simulation, the design would need to be synthesisable before it could be simulated.

How the three verification methods compare

Property	Functional simulation	Timing simulation	FPGA board
What it runs	RTL or zero-delay model	Post-synthesis or post-route netlist with delays (SDF)	The implemented design in hardware
When it can start	As soon as RTL compiles	After synthesis, and for full accuracy after place and route	After a full FPGA build
Relative speed	Fast	Much slower than functional, often by an order of magnitude or more	Many orders of magnitude faster than either simulator
Visibility for debug	Every signal, waveforms, assertions	Every net, but names are mangled by synthesis	Only what you route to pins or capture in an on-chip logic analyser
Finds timing bugs	No	Yes, for the delays and corners modelled	Yes, for that board, device and temperature
Iteration time per fix	Minutes	Hours (rebuild netlist)	Hours (rebuild bitstream)

A model answer

FTB: choose

FTB keeps a methodology the team already trusts. Functional simulation finds the bulk of the logic bugs early, while the design is still changing, and gives the best debug visibility. Timing simulation then checks the netlist, catching problems that functional simulation cannot see, such as glitches on asynchronous paths, wrong reset behaviour after synthesis, and mismatches between RTL and gates. The board adds long real-time runs, such as booting software or streaming real data. No retraining, no new risk. The cost is that throughput does not improve, so regressions stay as slow as today.

FCB: consider

FCB is a reasonable option for a design that is mostly synchronous with good static timing analysis (STA) and equivalence checking in the flow. In a modern flow, STA proves timing far more completely than timing simulation does, and a logic equivalence checker confirms the netlist matches the RTL. The board then acts as a final check on real hardware. The weakness is that ten times more functional simulation is not ten times more coverage: most random tests revisit states already covered, so the gain is real but modest. And if a timing-related bug escapes to the board, it is slow and painful to localise without a timing simulator.

TCB: reject

TCB removes the cheapest and most visible debug environment. Every simulation would need a synthesisable design, so nothing can be tested until the RTL is clean enough to synthesise, and every bug fix means re-running synthesis before the next test. Debugging in a gate netlist is harder because signal names change and logic is restructured. The extra computers only bring timing simulation up to today's functional speed, so there is no net throughput gain, just a harder workflow. Most teams would reject this option.

A worked example with numbers

The figures below are illustrative, chosen to show the reasoning rather than taken from a real project.

Suppose the nightly regression today runs 1,000 functional tests and reaches 80 percent of the functional coverage goals. Coverage typically rises quickly at first and then flattens, because each new random test is less likely to hit something new. If the gap closes by about a fifth for every doubling of tests, then:

• 2,000 tests: about 84 percent
• 4,000 tests: about 87 percent
• 8,000 tests: about 90 percent
• 10,000 tests (the FCB option): about 90 to 91 percent

A tenfold increase in compute buys roughly ten points of coverage in this model. That is valuable, but the last ten points usually need new directed tests or better constraints, not more cycles. This is what the hint about coverage being low means: raw speed does not fix holes in the test plan.

Now compare cycle counts. If functional simulation runs at a few thousand clock cycles per second for a large design, and the FPGA board runs at 50 MHz, one second on the board equals many hours of simulation. That is why the board is so good at finding rare corner cases, and so poor at explaining them.

How interviewers probe this question

• Do you know what timing simulation catches that STA does not? Expect to mention asynchronous logic, clock domain crossings, X propagation in gates, reset sequencing and RTL to gate mismatches.
• Can you quantify? Interviewers like candidates who talk about coverage curves, debug time per bug and the cost of a late bug, rather than just listing pros and cons.
• Do you follow the rules of the question? If you choose one option, you must reject the other two. Many candidates forget this.
• Do you consider the team? Retraining, tool trust and schedule risk are legitimate engineering arguments.

Common mistakes

• Assuming ten times faster simulation means ten times better verification.
• Forgetting that timing-only simulation forces the design to be synthesisable before any test can run.
• Treating the FPGA board as a full substitute for timing simulation without mentioning how hard board debug is.
• Ignoring STA and equivalence checking, which in many modern flows reduce the need for full timing simulation.

FAQ

Is timing simulation still used today?

Yes, but usually in a targeted way: gate-level simulation of reset, power-up, scan and asynchronous paths, with STA doing most of the timing sign-off.

What is the difference between functional and timing simulation?

Functional simulation checks behaviour with zero or unit delays. Timing simulation back-annotates real gate and wire delays, usually from an SDF file, onto the netlist.

Can an FPGA board replace simulation?

No. It complements simulation with very long runs, but its limited visibility makes it a poor first place to debug.

Which option would you pick if the design had many asynchronous interfaces?

FTB, because timing simulation is the main pre-silicon way to see how those paths behave with real delays.