Reading an EDA log instead of looking for PASS
Most people open a verification log and search for the word PASS. That habit is understandable. It is also incomplete.
A useful log exists to show what was attempted, observed, classified and left unknown. PASS is only the last line of that story.
The last article ran one FIFO through four engines and they disagreed. This one is about the skill underneath that: reading the output itself. The goal is not any tool's flags. It is to make the evidence readable, so a green checkmark turns back into engineering. We use the WIOWIZ engines because they write the log this way, but the four questions at the end work on any log.
The compile and elaboration record
Before any simulation, CDC analysis, formal proof or coverage can begin, the design has to compile and elaborate. A clean compile is quiet. A useful one is exact about what failed and where.
$ fsxrun wz_fsm.sv -top wz_fsm bad_enum.sv:3:30: error: FSX-E1104: expected ',' or '}' after enum member 'IDLE' before 'RUN'; enum members must be comma-separated (IEEE 1800-2017 6.19) 3 | typedef enum logic[1:0]{IDLE RUN DONE}state_e;
FSimX diagnostic, from a run. File, line and column, a rule id (FSX-E1104), the reason, and the language clause it comes from.
That is what you want from a compile error: the exact file, line and column, the rule, and the standard clause behind it. You do not go hunting; the engine points at the token.
Elaboration is the next gate, and it is where the log earns trust. When a design compiles but cannot be built into a model, the engine must not pretend the later stages ran.
$ fsxrun wz_ctr.sv -top wz_ctr ERROR: [ELAB] undeclared identifier 'step' in module 'wz_ctr' ** ELABORATION ERROR: 1 error(s), simulation skipped ** (soundness gate)
Elaboration failed on an undeclared signal, so simulation is skipped, not passed.
When elaboration does succeed, the record tells you what was built, and it states what it did and did not analyze along the way.
$ fsxrun wz_async_fifo.sv tb_wz_async_fifo.sv -top tb_wz_async_fifo -lint 2 file(s), 5 design unit(s), 0 error(s), 0 warning(s) ---------------- ELABORATION ---------------- [CDC] wz_async_fifo: found 2 clock domains: wclk (3 signals), rclk (3 signals) [CDC] wz_async_fifo: 2 local domains, 0 crossings extracted UNPROVEN (module-local analysis; no clean claim)
The clean FIFO elaborates. The built-in CDC scan labels its own module-local view UNPROVEN rather than claiming zero crossings is clean.
The simulation log
A simulation log answers one narrow question: under the stimulus that was applied, did the design behave as the test expected. The useful parts are the exact command, the top and testbench, the assertion outcomes, and the final verdict.
$ fsxrun wz_async_fifo.sv tb_wz_async_fifo.sv -top tb_wz_async_fifo -vcd dump.vcd [FIFO] streamed 512 words across two clock domains, errors=0 WZ_ASYNC_FIFO_PASS - 512 words crossed in order, no loss/corruption Result: PASS Checks: 1237 passed, 0 failed Assertions: 1237 passed, 0 failed *I,FSX-S1006: 2 concurrent SVA assertion(s) lowered and EVALUATED every clock edge
The design carries two concurrent SVA assertions; FSimX evaluates them on every clock edge, and the 1237 count is those passing evaluations plus the scoreboard checks.
Read the last line carefully. PASS here means the applied stimulus did not violate the checks that were present. It does not say the stimulus was thorough, the checks were complete, or that a clock-domain or power problem is absent. Treat a simulation log as evidence of what was exercised, never as a certificate of correctness.
The CDC report is a classification, not a pass
Clock-domain and reset-domain analysis produces a different kind of log. It is not pass or fail of behavior. It is a classification of structure, and it says so.
Truti signoff report on the same FIFO. The scope reads DIRTY, each finding carries a rule, a source and destination domain, and a file and line.
Read the classification, not the count. The scope is one of CLEAN, REVIEW, DIRTY or SETUP_BLOCKED, and every finding names its rule, its domains and its file and line. A report that said SETUP_BLOCKED would be telling you the analysis could not finish because constraints were missing, which is more useful than a silent clean produced by ignoring them.
The formal result: what was and was not established
A formal log is the clearest example of why PASS is the wrong thing to search for. It does not hand back a single word. It states the status of what it was asked to prove, and it refuses to guess.
$ hetu-formal fpv -rtl wz_async_fifo.sv -top wz_async_fifo -all-properties {"verdict":"BLOCKER","rule_id":"FV-ELAB-002", "message":"multi-clock W6 transition system requires explicit -clock-intent; lowered domains: posedge wclk, posedge rclk"}
Hetu-Formal on the dual-clock FIFO. It will not proceed on a multi-clock design until you declare the clock relationship.
That is not a failure to read past. It is the engine telling you exactly what it needs before it will make a claim. A useful formal log makes each property PROVEN, a counterexample, or UNKNOWN when the solver could not decide within its bound, and it shows the bound and the assumptions. A run that reports only "all proven" without the bound, the assumptions and the list of properties is incomplete evidence. The deep dive in Article 05 takes one FIFO property all the way to a verdict.
Coverage: relative to what ran
Coverage answers what the stimulus exercised, and its value is in what it refuses to score.
The coverage dashboard on the FIFO. Toggle is 28.02%, and the banner states that seven of eight metric families are ABSENT, not zero.
A coverage number only means something against the stimulus that produced it and the model that was written. A family the run did not collect is carried as not-applicable, never a false zero, and each untoggled bit is a MISS with an UNKNOWN formal state. A high percentage over a weak model is not strong evidence.
A reading habit that works on any log
When a run finishes, resist searching only for PASS, FAIL or PROVEN. Ask the log four questions instead:
- Did the design elaborate into a model?
- What stimulus or analysis was applied?
- What concrete evidence supports the final classification?
- What was left unexamined or marked unresolved?
Those four work across simulation, CDC, formal, low-power and coverage. They turn the log from a status light into a piece of engineering evidence. The WIOWIZ engines are written to produce the log in a form that can be read this way, whether the run happened on a desk or on a remote worker. Article 03 is about that second case: what happens to the run, and the log, after you press Run.