abstraction
Models Before RTL
2026 · 6 min read
The classical modeling flow has a quiet assumption baked in: first there is RTL, and then there is a model of the RTL. New silicon roadmaps are breaking that assumption — and with it, most of the standard answers for how you trust a model.
When a new interconnect standard publishes, the customer teams who adopt it face a sequencing problem. Firmware needs a platform months before the first RTL drop of the new block stabilizes. Architecture teams need to evaluate the protocol before committing to silicon choices. Everyone needs a model — and the golden reference implementation the whole verification ecosystem assumes doesn't exist yet.
The correlation vacuum
The textbook answer to "is this model right?" is: correlate it against RTL. What do you correlate against when the RTL hasn't been written? This is not an edge case anymore. It's the schedule.
The failure mode is predictable: teams fall back on correlating against themselves. The model is tested by the same understanding that built it, passes, and ships. The comfort of that green checkmark is exactly proportional to how little it proves.
Building pillars instead of a mirror
The way out is not a cleverer model. It's refusing to have a single point of derivation. You need multiple independent reasons to believe, each of which can fail without the others:
- Answers the spec already contains. Every serious spec has worked numeric examples — a read that crosses a boundary, an operation that spans two beats. Those examples are free ground truth. A model that can't reproduce the spec's own arithmetic is wrong by definition, no RTL required.
- Rules stated as prohibitions. The spec says what may never happen. Turn every "shall not" into a check that runs continuously, on every cycle of every test. A model that never violates the prohibitions is not proven — but a model that violates one is proven wrong.
- Levels that share nothing but the spec. Build the functional core once. Build two or three wrappers around it at different timing fidelity, each written against the spec independently. When they disagree with each other, the bug is in a wrapper — one place, not everywhere. When they agree, they agree because the spec forced it.
What the RTL owes the model
Here's the part nobody schedules for: when the RTL finally lands, the model's job changes. The model was the only game in town for months — firmware bring-up, architecture analysis, maybe a found bug or two in the spec itself, all before the first line of implementation existed. Now it becomes the reference the RTL is judged against.
Teams that have lived this once describe the same reversal: correlation stops being "does the model match the RTL" and becomes "when they disagree, which one is wrong?" A model built from the spec — with its ambiguities surfaced as questions, not buried as guesses — is the only artifact in the building that can even ask that question honestly.
The old flow used models to shadow implementation. The new flow uses implementation to audit models that earned their trust first. That inversion is not a small process change. It changes who finds the bugs, and how early, and at whose desk the question lands when silicon is late.