In this lesson, you will learn how to use mathematical solvers to prove that your hardware implementation remains functionally identical to your high-level interface specification.
Moving Beyond Simulation
While we have used Assertion-Based Verification (Concept 23) and SystemVerilog Assertions (Concept 24) to check for bugs during simulation, these methods only test the scenarios you explicitly write as test vectors. In complex interface logic, like an AXI-lite bridge or a custom peripheral bus, it is impossible to stimulate every possible state. Formal Equivalence Checking (FEC) uses automated mathematical solvers (like SAT or SMT solvers) to exhaustively compare two designs: the "Golden Model" (the specification) and the "Implementation" (your RTL code).
The Logic of Equivalence
FEC treats the interface as a mathematical function. It creates a state-space representation of both designs and looks for a counter-example—a specific sequence of inputs where the outputs of the specification and the implementation differ.
For instance, consider a simple register-access interface. You define the specification as a set of logical requirements (e.g., "writing to Address 0x04 must update the status flag within 2 clock cycles"). The solver then mathematically verifies that for all possible sequences of inputs, your RTL logic behaves exactly as the specification dictates.
// Specification: When 'write_en' is high,
// 'data_out' must reflect 'data_in' on the next clock cycle.
assert property (@(posedge clk) write_en |=> (data_out == $past(data_in)));
Instead of running a testbench for hours, the solver performs a "logical proof." If the solver finds a path where the implementation allows a transient glitch or fails to update the register correctly, it provides the exact trace leading to that state. This is far more powerful than random testing because it doesn't just show that your code works for the cases you thought of—it proves that no hidden state transition can cause a violation of your interface contract.
By applying these solvers, you eliminate the risk of "corner-case" bugs that often hide in complex handshaking protocols, ensuring your hardware is robust by design rather than by luck.
Key Takeaway: Formal Equivalence Checking uses mathematical solvers to exhaustively prove that your implementation logic perfectly matches your interface specification, eliminating the need to test every possible input scenario manually.