When hardware teams need to prove that a pipelined divider never produces a wrong answer or that a TLB replacement policy can’t deadlock, the work usually pivots on one thing: a SAT/SMT solver installed on someone’s machine. Prove that bit-flips in the exponent path can’t propagate to the mantissa sign. That sentence travels from a design review straight into a shell session: install cvc5 or Z3, write a constraint script, run a script, parse the output, repeat for the next lemma. The browser tab on that engineer’s laptop has nothing to do with any of it. The SMT-LIB 2.7 / AIGER / BTOR2 Formal Verification Orchestrator changes that. It’s a complete formal-verification stack that runs in the browser — no cvc5 binary, no Z3 binary, no Boolector — built from scratch on top of a hand-written CDCL SAT engine. You paste a bit-vector script, point it at an AIGER or BTOR2 model, and the orchestrator picks an algorithm: bounded model checking, k-induction, Craig interpolation, or IC3/PDR-lite. For the hardware engineers reviewing a design before tape-out, that moves formal from a build dependency to a static page they can open during a standup.
The four input formats one orchestrator has to speak
Hardware verification has not converged on a single interchange format, and any tool that claims to be “general-purpose” ends up reading at least three. The orchestrator reads all of them:
- SMT-LIB 2.7 — the QF_BV (quantifier-free bit-vector) subset and the Bool core. The parser handles the operator set that bit-blasts cleanly:
add,sub,mul,udiv,urem, the shifts, the comparators,concat,extract,extend, andite. Each operator goes through Tseitin bit-blasting into CNF before reaching the SAT engine. - AIGER — both ASCII (
.aag) and binary (.aig) variants. The binary reader does the delta-encoding dance for the literal table; the orchestrator then surfaces the bad-state properties as the negation of an invariant the model has to satisfy. - BTOR2 — the word-level format that came out of the Boolector lineage. The reader expands each operator into bit-level constraints so the underlying SAT solver can consume them; you don’t have to know the BTOR2 internals to use it.
- Plain propositional — for the small examples that don’t justify a hardware-model format, the CDCL SAT engine also accepts DIMACS CNF directly.
The practical consequence is that the same orchestrator verifies an out-of-order execution unit (via BTOR2 with k-induction) and a small protocol checker (via AIGER with BMC) without leaving the page. The Elysia Tools Formal Verification Orchestrator has all four readers wired into one engine.
Why a hand-written SAT engine, not a WebAssembly solver
Most “formal-verification in the browser” tools shell out to a WebAssembly build of Z3 or cvc5. That works, but the binary stays the bottleneck — the WASM blob is megabytes, the parse-and-link time dominates small proofs, and the verification logic is opaque to anyone who wants to understand why a counterexample came back.
The orchestrator takes a different approach. The CDCL SAT engine is hand-written:
- Two-watched literals on every clause so unit propagation visits only the changed neighborhoods.
- VSIDS-style activity bumping on every conflict, with periodic decay so the heuristic doesn’t get stuck on a stale branch.
- 1-UIP learning on every conflict graph, the same first-unique-implication-point scheme cvc5 and Z3 use.
- Restarts triggered by the learned-clause count, not by a wall-clock interval, so the engine doesn’t churn on hard unsatisfiable cores.
The four mechanics that make a CDCL engine handle 500,000 clauses
Each of those four mechanics is the difference between a SAT engine that handles a 5,000-clause decision procedure and one that handles 500,000. When k-induction needs to check a 30-step unrolling of a multiplier, the SAT engine is what’s actually doing the work.
Bounded model checking and the counterexample-witness trace
For sequential hardware, the orchestrator’s bounded model checking path is the first thing you reach for. It unrolls the transition relation up to depth k, asks the SAT engine whether an initial state can reach a bad property in k steps, and if the answer is yes, returns a counterexample.
The orchestrator’s counterexample isn’t just “the assertion failed at step 7.” It’s a witness trace: the register values and the signal values at every step, including the inputs that drove the divergence. For a pipelined divider, that means you see exactly which input pair produced the rounding error and on which cycle the sticky bit flipped incorrectly. The witness is what makes the BMC useful — without it, BMC reduces to “unsound” or “sound” with no actionable information.
k-induction catches what BMC misses
Bounded model checking is incomplete: it can only prove that no bad state is reachable in k steps, not that no bad state is reachable ever. k-induction closes the gap. The orchestrator runs k-induction with unique-state strengthening, so two different paths to the same state count as one, and a custom inductive-step proof that prunes trivially-symmetric candidates before they reach the SAT engine.
The practical recipe is:
- Start with k = 1 and let BMC produce counterexamples that pinpoint a step where the inductive hypothesis breaks.
- For each counterexample, extract a strengthened inductive invariant that the SAT engine certifies (not just claims).
- Increase k and re-run; the unique-state set means the inductive step usually tightens faster than the raw BMC bound.
For a 16-bit Booth multiplier, the orchestrator reaches a stable inductive invariant around k = 12 — short enough to debug by hand if the invariant looks suspicious.
Craig interpolation, independently re-certified
Craig interpolation is the trick that turns “is the conjunction of A and B satisfiable” into “is there a formula I such that A implies I and I-and-not-B is unsatisfiable.” The interpolant I is usually a strong candidate for an inductive invariant. The orchestrator computes McMillan-style Craig interpolation from the refutation — that is, it walks the resolution proof that the SAT engine produced and harvests the interpolant from the partial assignments.
The non-obvious step is the re-certification. The interpolant isn’t trusted just because the SAT engine produced a refutation; the orchestrator feeds the interpolant back into a fresh SAT call and confirms that A ∧ ¬I is unsatisfiable independently. That second call is what makes the invariant trustworthy — it’s the same logic an external proof checker would run, except it happens inside the orchestrator’s engine before the invariant is shown to the user.
IC3 / PDR-lite for the invariants BMC can’t find
Bounded model checking and k-induction both rely on bounded-depth reasoning. IC3 / PDR — Property Directed Reachability — doesn’t. IC3 builds a sequence of frames, each representing an over-approximation of the set of states reachable in up to i steps, and refines the frames with predecessor cubes until either the property is proved or a counterexample surfaces.
The orchestrator runs an IC3/PDR-lite variant with predecessor-cube blocking: each cube that blocks a frame is checked against the transition relation, and the cubes that generalize are kept, while the cubes that don’t are dropped rather than allowed to inflate the frame. The “lite” suffix is honest — this is not the full IC3 that handles deep pipelined superscalar processors on its own. It is, however, strong enough to find invariants that BMC and k-induction miss on FIFO buffers, small cache coherence protocols, and instruction decoders, which is where most hardware bugs actually hide.
When the orchestrator is the right tool
The orchestrator is not a replacement for cvc5 or Z3 on industrial-scale verification. A 100,000-gate out-of-order core will overrun the in-browser SAT engine’s time and memory budget. Where it shines:
- Instruction decoders — small, well-bounded state machines where IC3 finds the invariant quickly.
- FIFO and queue controllers — k-induction with unique-state strengthening closes in a handful of steps.
- Fixed-point arithmetic units — multipliers, dividers, and accumulators where BMC with a counterexample trace is the deliverable.
- Protocol checkers — small cache coherence and bus arbitration models where the witness trace is the artifact.
- Teaching and review — the engineer who wants to understand what a Craig interpolant actually looks like, not just trust that cvc5 computed one.
For each of those, see the live orchestrator at Elysia Tools.
Explore more tools at elysiatools.com. Paste a bit-vector script or upload an AIGER model, choose an algorithm — BMC for a quick counterexample, k-induction for a stable invariant, Craig interpolation for a certified lemma, IC3/PDR-lite for the cases the bounded methods can’t see — and the orchestrator runs the same CDCL-based reasoning cvc5 and Z3 run, in your tab, without installing anything. For the hardware engineer reviewing a divider before tape-out or the protocol designer tracing a coherence bug to its source, that moves formal verification from a build step to a tab.
