correlation
How to Correlate a C Model Against RTL
2026 · 8 min read
"The model matches the RTL" is the most expensive sentence in transaction-level modeling. Correlation done seriously is not a pass rate — it's a classified list of disagreements, with a judgment attached to every entry. Here's what that actually looks like as a working definition.
Step zero: agree on what "matches" means
Before a single trace is compared, the two sides have to agree on the comparison itself. A correlation effort that skips this step produces a report nobody can act on. The agreement covers:
- The golden source. What is the reference — RTL simulation, the spec, or silicon? Each choice anchors a different kind of claim, and mixing them silently is how reports end up proving nothing.
- The observation points. Which signals and which events get compared? A model and an RTL block don't have natural "outputs" to compare — someone decides where the measurement boundary is, and that decision determines what the comparison can detect.
- The tolerance. Cycle-exact? Off-by-one on handshake boundaries? Within N cycles on average? "Matches" is a contract with a number in it, or it's a vibe.
This is also where the abstraction level from the LT/AT decision catches up with you: a loosely-timed model cannot match cycle-for-cycle by construction, so the contract has to say what it can match — transaction order, data integrity, protocol compliance — and explicitly waive the rest. A correlation report that doesn't state its own boundaries is claiming more than it measured.
The mechanics: traces, not vibes
The comparison itself is unglamorous and should stay that way. Both sides run the same stimulus — the same test vectors, the same register sequences, the same memory patterns — and both emit a machine-readable record of what happened: a transaction trace, a cycle log, whatever the observation points dictate. Then a diff tool, not a human eyeball, produces the list of disagreements.
The discipline that matters: the same stimulus, run the same way, every time. Correlation results that can't be reproduced on demand aren't results — they're anecdotes. And the stimulus has to be adversarial on purpose: back-to-back transactions, error responses, reset in the middle of a burst, the collisions and corner cases the directed tests skipped. The happy path correlates on the first try. Everything the correlation effort is for lives in the parts that don't.
The triage: three buckets, no shortcuts
The diff list is where the real work starts. Every mismatch gets classified into exactly one of three buckets:
- Model bug. The model is wrong, the RTL is right. Fix the model, rerun, watch the mismatch disappear. Cheap in isolation; dangerous in aggregate, because a model with too many of these was guessing where it should have been reading.
- RTL bug. The RTL is wrong, the model is right — or more precisely, the RTL disagrees with the spec the model was built from. This is the bucket clients remember. It's also the reason the model should be built from the spec and correlated against the implementation, never extracted from it: a model extracted from the RTL copies its bugs, and the second bucket stays empty forever.
- Ambiguous spec. Two defensible readings, and the model took one while the RTL took the other. The hardest bucket and the most valuable one — because this mismatch isn't a defect at all, it's a question the team gets to answer before silicon, with the answer written into firmware expectations instead of discovered by field returns.
The rule that keeps this honest: no mismatch is closed without a classification, and no classification is made without evidence. "Probably fine" is not a bucket. A mismatch list that ends the project unclassified isn't 99% correlated — it's 100% unexamined.
What the report owes its reader
A correlation report that's worth the paper it's printed on says four things, in this order:
- Everything we ran — stimulus, configuration, versions of both sides.
- What agreed, and under what comparison contract.
- What disagreed, classified, with the evidence for each classification.
- Our judgment on every open item — including the ones we couldn't close.
Note what's absent: a headline percentage. Pass rates compress all of the above into a number that can't be acted on. The classified mismatch list is the deliverable — it's the review the design never had, arriving before the design exists in silicon.
The stance
There's a version of this work where correlation is a formality at the end — a checkbox that says the model is "validated." We don't do that version. In our experience the mismatches are never noise: each one is either a bug someone gets to fix cheaply, or a question someone gets to answer early. Grinding the list to zero without understanding it wastes every one of those.
So the claim we make at the end of a correlation effort is deliberately narrow: here is what we ran, here is what agreed, here is the classified list of what didn't, and here is our judgment on each entry. That's a report an engineer can trust — because it's a report that could have said otherwise.