Is verification the same as testing?

Testing is part of broader assurance; formal verification uses mathematical reasoning over an explicit model.

Does a counterexample always describe a possible physical failure?

It describes a modeled behavior. Engineers must check whether the model and assumptions match the intended environment.

Does a failed proof mean the circuit is wrong?

Not necessarily. The tool may have exhausted resources or the model may need correction.

AI Glossary / Graphs and symbolic AI / Intermediate

Circuit verification

Definition

Circuit verification checks whether a circuit design satisfies a stated specification. In symbolic AI and formal reasoning, it commonly involves representing a digital circuit with logical rules and proving a required property, or finding an input that violates it. The result concerns the modeled design and assumptions, not an unrestricted guarantee about a physical device.

What it means

A circuit may look plausible and still produce the wrong output for an overlooked combination of inputs. Verification turns the intended behavior into a precise question: does the implementation always match this reference function, or can a prohibited state be reached?
Simulation examines selected executions. Formal verification reasons about all behaviors covered by its model, when the proof succeeds. These approaches can complement each other. Equivalence checking is one form of verification: it compares a candidate design with a reference. Property checking asks whether an explicitly written condition holds, without necessarily requiring a complete reference circuit.

How it works

For a simple combinational circuit, describe each gate as a Boolean relation and connect the gate variables according to the design. Express the required output relation separately. Then ask whether the circuit rules and a violation of that relation can both be true. A satisfying assignment supplies a counterexample; unsatisfiability establishes that no such violation exists within the encoded assumptions.
Sequential circuits also contain state, so the model needs initial conditions and transition behavior. Properties may concern sequences of inputs rather than one input combination. Verification engines can use satisfiability solving, symbolic representations, or other reasoning methods. A timeout or an unresolved result is different from a proof that the circuit is correct.

Three practical examples

A hardware team checks that a refactored arithmetic unit has the same specified behavior as its reference design.
A controller designer checks that a modeled state machine never asserts two mutually exclusive control outputs together.
An AI-assisted design workflow treats generated hardware code as a candidate and checks its behavior against independently written requirements.

Think of it this way

Think of checking a lock against an exact list of permitted keys and forbidden keys. Trying a few keys resembles testing; reasoning about the lock's full modeled mechanism resembles formal verification. The analogy has limits: a proof about the design does not establish that the manufactured lock has no damage, and the permitted-key specification itself could be wrong.

Worked example

Suppose the requirement is a two-input exclusive-or output: the output must be 1 when exactly one of A and B is 1. A candidate implementation mistakenly uses ordinary OR.
There are four input combinations. For 00, both required and implemented outputs are 0. For 01, both are 1. For 10, both are 1. For 11, the required exclusive-or output is 0, while the OR implementation produces 1. Thus A = 1 and B = 1 is a counterexample. Passing the first three tests would not establish equivalence.
Replace the implementation with (A AND NOT B) OR (NOT A AND B). Evaluating the same four combinations gives 0, 1, 1, and 0, respectively. That exhausts the two-valued input space for this memoryless example. The result does not address propagation delays, electrical noise, unknown signal values, or any sequential state; those would require a richer model and different checks.

Illustrative case study

At fictional Juniper Devices, an assistant proposes a shorter expression for a control output. The team compares it with the existing behavior under the documented input assumptions. A counterexample reveals that the new expression handles simultaneous requests differently.
The engineer reviews the requirement before changing either design, because the old implementation is not automatically the correct specification. The team then repeats the relevant checks for the chosen behavior. This fictional case illustrates how a counterexample can focus review; it does not claim that a particular product was verified or that shorter generated code is inherently safer.

Common misconceptions and mistakes

Equivalence to a reference does not prove that the reference meets the customer's needs. Likewise, a property can pass because assumptions accidentally exclude the difficult situations. Review the assumptions as carefully as the assertion.
Checking only a fixed number of steps in a sequential circuit is not automatically an unbounded proof. Uninitialized state and don't-care values also affect what equivalence means; tools can use different semantics. Finally, functional correctness is not the same as timing closure, power suitability, manufacturing quality, or resistance to every physical fault. A useful verification report states precisely which claim was established.

Business use

Businesses developing hardware or embedded products can use verification evidence to make design changes more reviewable. Preserve the specification, model version, assumptions, tool settings, and result together. For AI-generated changes, independent requirements are especially valuable: asking the same assistant to write both the implementation and an equally mistaken expectation can conceal a defect. Counterexamples should become understandable engineering records, not merely red indicators in a dashboard.

Check your understanding

Why did testing 00, 01, and 10 miss the defect in the worked example?

Answer: OR and exclusive-or agree on those three inputs. They differ on 11, so the selected tests omitted the distinguishing case.

Related terms

Satisfiability
Model checking
Formal verification
Boolean logic
equivalence checking
counterexample
specification
digital circuit

Learn next

Learn satisfiability next. Encode a tiny gate network and ask for an input where its output differs from the specification. Then study sequential verification to understand why initial states and time make the problem more demanding.

Satisfiability

Sources

Primary sources: Russell and Norvig, circuit knowledge-engineering example, https://aima.cs.berkeley.edu/4th-ed/pdfs/newchap08.pdf ; YosysHQ equivalence semantics, https://yosyshq.readthedocs.io/projects/eqy/en/latest/xprop.html ; original processor-verification research, https://arxiv.org/abs/cs/9910014 . The truth table and fictional case are original illustrations.

Previous: Circuit (neural network) Next: Circular analysis