Formal Interviews and Formal Careers
Know what a formal interview asks at each level, which lesson prepares each stage, what postings ask for, and do the drill on five real counterexamples.
- Lesson
- F9.4
- Time
- 30 min
- Runs on
- SymbiYosys
- Check
- 4 questions
A strong DV engineer interviewed for a formal role. Asked what PASS at depth 20 means, the candidate said the property holds; asked for two causes of an unreachable cover, the candidate gave one, dead code. Asked for the FIFO order property, the candidate wrote a scoreboard with a queue. Each answer was half right, because the interviewer was testing whether the candidate had ever read a counterexample.
The Questions, by Level
Read the diagram as text
- Entry: what formal is: rows 1-8: proves vs samples, no testbench, assert / assume / cover, PASS at depth N
- Entry: the bench: rows 21-26: master rule, over- and under-constraint, vacuity, triage
- Mid: the engines: rows 9-20: BMC, k-induction, helpers, IC3/PDR, why several engines
- Mid: making proofs finish: rows 27-46: covers, modelling code, liveness, cutpoints, case splits, symbolic scoreboards
- Senior: apps and equivalence: rows 47-59: CSR, connectivity, CDC, security, LEC, SEC, mutation
- Senior: sign-off and the team: rows 60-69: coverage, sign-off, plans, design for formal, the 4 Cs
- Entry: what formal is → Mid: the engines
- Entry: the bench → Mid: making proofs finish
- Mid: the engines → Senior: apps and equivalence
- Mid: making proofs finish → Senior: sign-off and the team
Row numbers are the track's question map; every row names the lesson that settles it.
Entry questions check the vocabulary of results: PASS at depth 20 is no failure in 20 steps, not a proof (F1.5). Mid questions check that you have fought a proof: what UNKNOWN means and what you add (F2.4). Senior questions check that you can say what a proof covers and sign it (F7.3).
The Loop, Stage by Stage
| Stage of the loop | What it tests | Lessons that prepare it |
|---|---|---|
| Screen | assert / assume / cover, PASS at depth N, safety and liveness | F1.3, F1.5 |
| Write a property | a FIFO order rule, an arbiter bound, a handshake rule, live | F4.4, F3.7 |
| Debug a trace | name the cause and the step: RTL, assumption, property, reset | F1.4, F3.3 |
| Convergence | what you do with UNKNOWN or a time-out | F2.4, F4.6, F4.1 |
| Bench design | assumptions, covers and abstractions for a block they describe | F3.1, F3.5, F9.1 |
| Methodology (senior) | plans, sign-off, apps, working with design and DV | F7.5, F7.3, F9.3 |
A typical loop, assembled from interview reports people post publicly. Loops vary; the stages recur.
The trace stage decides most loops. You get a waveform and two minutes. Say the step, the cause and the fix, in that order, and say which of the four causes you ruled out.
In the bench-design stage the interviewer describes a block and asks what you would assume, assert and cover. Start from the spec rows, and name who checks each assumption.
Half an Answer, and a Whole One
Half
Q: My assertion passed in simulation and
failed in formal. Why?
A: The simulation did not have the right test.
Follow-up: "Which test? How would you find it?" No answer.
Whole
A: Formal drives every input freely. Either
the tests never reached the antecedent (a
vacuous pass), or the solver found an input
no legal driver makes: then I add an assumption.
Follow-up: "How do you tell which?" Read the trace.
The whole answer names both causes and the next step, so the follow-up is one the candidate wants (F1.2, F3.3).
What Postings Ask For
| What postings ask for | Where this track teaches it |
|---|---|
| SVA, and environment assumptions that are neither too loose nor too tight | F3.1, F3.2, F3.3 |
| Abstraction for full or bounded proofs | F4, with F7.3 for the bounded argument |
| Formal test plans and reusable property files | F7.5, F9.1 |
| Experience with one of the commercial formal tools | F5.1 maps the apps those tools sell; the methods are the same on any engine |
| Scripting: Python, Tcl or Perl | regressions and run management, outside this track |
| Connectivity, SEC, post-silicon support in some roles | F5.1, F6.2, F5.9 |
Requirement lines that recur across formal verification postings, in this page's words. Postings name a tool; this page does not, because the skill is the method.
Formal roles sit mostly in CPU, GPU, networking and IP teams, and at a few formal consultancies. They are not a way around DV: the bench, the spec and the trace come first. This page prints no salary or demand figure: none we could trace to a named, dated source.
Getting started looks the same everywhere: pick a block, run covers before any assert, and show a designer a trace on their own RTL. A first result a designer can read builds more trust than any tool demo.
The Drill: Five Traces
Measured: FAIL at reported step 7, bmc depth 20, reset assumed in step 0 unless the cause is the reset.
Measured: FAIL at reported step 1, bmc depth 20, reset assumed in step 0 unless the cause is the reset.
Measured: FAIL at reported step 5, bmc depth 20, reset assumed in step 0 unless the cause is the reset.
Measured: FAIL at reported step 3, bmc depth 20, reset assumed in step 0 unless the cause is the reset.
Measured: FAIL at reported step 4, bmc depth 20, reset assumed in step 0 unless the cause is the reset.
For each trace, name the cause (RTL, assumption, property or reset) and the step, in under two minutes. Then write five properties from one-line specs and check them against the model answers; your spelling may differ.
| Trace | Cause | The tell | Lesson |
|---|---|---|---|
| A | RTL | legal inputs from reset; an abort on the last busy cycle leaves ack with nothing pending | F1.4 |
| B | reset | step 0 already holds a state no reset produces | F1.6 |
| C | assumption | the shaded araddr changes while the read waits: no legal manager does that | F3.3 |
| D | property | |-> asks for !rvalid in the handshake cycle itself; the RTL is the correct one | F1.2 |
| E | RTL | a legal write of 0 to IRQ_STAT clears a set bit: the field is plain read/write | F5.4 |
The answer key. Read it only after you have named all five.
Asked in Interviews
| Question | Answer |
|---|---|
| What do formal interviews ask? | Entry: vocabulary of results and the bench. Mid: engines, convergence, symbolic scoreboards. Senior: apps, equivalence, sign-off, plans. |
| How do you prepare? | Read traces until you can name the cause in two minutes; write the classic properties (FIFO order, arbiter bound, handshake) from memory; know one sign-off end to end. |
| What does the market look like? | Fewer roles than DV, concentrated at CPU, GPU, networking and IP teams; figures only from a source you can name. |
Try It
The lab is the drill. Each run reproduces one trace from its own lesson; read it before you look at the key.
Traces
Run A to E. For each, write the cause and the failing sample before the timer reaches two minutes.
Properties
FIFO: the next read returns the oldest write. Arbiter: a held request is granted within four cycles. Handshake: VALID holds until READY. W1C: a 1 clears, a 0 keeps. Timer: no bark without a full count.
Out loud
Answer five entry questions from the wheel in one minute each, then compare with the lessons the rows name.
design.sv
props.sv
Use assert property (@(posedge clk) ...);. Leave blank for immediate assertions in the design.
Inputs are free unless constrained. Run to find a counterexample or check a proof.
Model: one positive-edge clock, binary data. Sampled history requires declaration-initialized variables; primary-input history is unsupported.
SBY summary and log
Check Yourself
Remember
- Entry, mid and senior questions test results vocabulary, proof convergence and sign-off.
- The trace stage decides most loops: say the step, the cause and the fix, and which causes you ruled out.
- Postings ask for assumptions, abstraction, plans and a tool; the tool is the smallest part.
- Print no market figure you cannot cite.