● Techniques to apply:
1. Symbolic model checking with ROBDDs (BDD-based reachability) — good
to attempt full (unbounded) safety proofs if the state space is manageable or after
applying abstractions.
2. SAT/CNF-based Bounded Model Checking (BMC) and SAT-based engines
(plus IC3/PDR) — fast at finding counterexamples; modern PDR/IC3 gives good
chance of proving safety without full BDD blow-up.
● How to use them: model the FIFO as a finite-state transition system (state = memory
contents, head/tail pointers or occupancy counter), formalize the listed specs as safety
properties (and some liveness/ordering properties), run BMC (SAT/CNF) to find bugs
quickly; if no bug, run an inductive prover (IC3/PDR) or BDD reachability to attempt a full
proof. Use abstractions (abstract data, tokenization) where needed.
1) Model the FIFO as a transition system
State variables (examples; choose actual names to match RTL):
● mem[DEPTH-1:0][15:0] — FIFO memory (or treat memory symbolically / abstractly).
● head_ptr, tail_ptr — read/write pointers (log2(DEPTH)-bit).
● count — occupancy (0..DEPTH) — if easier, you can use count instead of both pointers
for some checks.
● control/status signals driven by logic: IS_EMPTY, IS_FULL, LDETECT, IS_VALID.
● Inputs: CLK, RESET, WR_EN, RD_EN, DATA_IN[15:0], IS_ACTIVE (as given).
● Outputs: DATA_OUT[15:0], IS_EMPTY, IS_FULL, LDETECT, IS_VALID.
Transition relation (on posedge CLK unless RESET):
● If RESET ⇒ initialize pointers, count = 0, IS_EMPTY=1, IS_FULL=0, etc.
● If WR_EN and IS_ACTIVE and not full: write DATA_IN at mem[tail_ptr];
tail_ptr++, count++.
● If RD_EN and IS_ACTIVE and not empty: output mem[head_ptr] as next DATA_OUT,
head_ptr++, count--, set IS_VALID.
● If both WR and RD asserted simultaneous semantics must be specified (read and write
same cycle allowed? net effect on count?). Decide and encode unambiguously.
Important: explicitly encode the logic used in the RTL for IS_EMPTY, IS_FULL, LDETECT,
IS_VALID so you can check whether they conform to the formal specs.
2) Formalize the specifications (safety/assertion forms)
Below are the safety properties (SVA-like / plain logic). I’ll also comment on ambiguous wording
and the right interpretation.
A. Operation gating by IS_ACTIVE
Specification text: “Either read or write can happen iff IS_ACTIVE is high.”
Interpretation (safe) that operations may only occur when IS_ACTIVE is high (i.e., not allowed
when IS_ACTIVE=0). We do not force an operation to occur whenever IS_ACTIVE=1 (that
would be stronger).
SVA-style assertions:
// no operation when not active:
assert property @(posedge CLK) disable iff RESET
((WR_EN | RD_EN) -> IS_ACTIVE);
If the spec truly meant exactly when (i.e., ops happen iff IS_ACTIVE), you’d also add
IS_ACTIVE -> (WR_EN | RD_EN) — but that forces an op whenever IS_ACTIVE, which is
likely wrong.
B. IS_EMPTY iff FIFO empty
Assuming count encodes occupancy:
assert property @(posedge CLK) disable iff RESET
(IS_EMPTY == (count == 0));
C. IS_FULL iff FIFO full
assert property @(posedge CLK) disable iff RESET
(IS_FULL == (count == DEPTH));
D. LDETECT high iff FIFO contains exactly BLOCK_SIZE items
assert property @(posedge CLK) disable iff RESET
(LDETECT == (count == BLOCK_SIZE));
E. IS_VALID becomes high as soon as valid output data are available on DATA_OUT
Interpretation: after a successful read (RD_EN && not empty && IS_ACTIVE), IS_VALID
should be asserted at some well-defined cycle when DATA_OUT contains valid data. Usually
single-cycle: IS_VALID asserted the same cycle DATA_OUT is driven or next cycle depending
on design; you must check RTL to align semantics. Example assuming DATA_OUT valid same
cycle as read:
// If read performed, then next cycle IS_VALID = 1 and DATA_OUT equals
the data at head
assert property @(posedge CLK) disable iff RESET
( (RD_EN && !IS_EMPTY && IS_ACTIVE) |-> ##1 IS_VALID );
And check data value (ordering):
// we need a monitor to record the value expected to be output.
// Example pattern approach (pseudo): when we write, tag data with
sequence id
// and when read occurs, assert that output sequence id increments
properly.
// (Concrete implementation below)
F. FIFO ordering (true FIFO behavior)
This is the key functional property: data are returned in the same order they were written
(first-in-first-out). The robust way to verify ordering is to tag every write with a monotonically
increasing token (a write sequence number) and then assert that the sequence numbers
observed on reads are strictly increasing and match the write order. You can do this in a
verification harness / monitor (not necessarily modifying the design).
Example monitor approach:
● Maintain an external model queue model_q where, on a write (WR_EN && IS_ACTIVE
&& not full) you enqueue(DATA_IN, seq++).
● On read (RD_EN && IS_ACTIVE && not empty) dequeue and compare dequeued data
with DATA_OUT when IS_VALID asserted.
● Assertion: dequeued data == DATA_OUT when IS_VALID asserted.
This is the standard refinement / synchronous monitor approach.
If you must express purely as property, you can formalize with sequences—but it’s clearer to
use a monitor or a reference model.
G. No overflow/no underflow
● No overflow: !(WR_EN && IS_FULL) (or if WR asserted when full must be ignored,
verify behavior)
● No underflow: !(RD_EN && IS_EMPTY)
SVA:
assert property @(posedge CLK) disable iff RESET
!(WR_EN && IS_FULL);
assert property @(posedge CLK) disable iff RESET
!(RD_EN && IS_EMPTY);
3) ROBDD (BDD-based symbolic model checking)
approach — how to apply
When to choose: small-to-medium FIFO depth, or after applying abstractions; BDD can provide
full reachability proofs (unbounded) and produce invariants.
Steps:
1. Build transition relation T(s, s') symbolically from RTL: encode next-state functions
for head_ptr, tail_ptr, mem, count, and combinational definitions of status outputs.
Use ROBDDs to represent sets of states and transition relation.
2. Environment constraints: If inputs such as IS_ACTIVE, WR_EN, RD_EN, DATA_IN are
unconstrained, the state space includes all possible behaviors; often you must assume
WR_EN and RD_EN are application-driven (or synchronous) — encode any needed
assumption as constraints on allowed input sequences. Example: assume IS_ACTIVE
is stable during a clock edge or synchronized to CLK.
3. Reachability fixpoint: iteratively compute Reach_{i+1} = Reach_i ∪
Post(Reach_i) using BDD operations until fixpoint. Check that no bad states
(violations of assertions) are reachable. For each safety property (e.g., IS_EMPTY ==
(count==0)), build the bad-state formula ¬(property) and check Reach ∧ bad ≠ ∅.
If empty for all bad states, you have a full proof.
4. Invariants and partitioning: If BDD blow-up occurs, try:
○ Reduce state encoding (use count instead of entire memory when checking
IS_FULL/IS_EMPTY).
○ Abstract data contents (e.g., treat data words as uninterpreted or use small tags)
to reduce width.
○ Use partitioned transition relations or dynamic variable reordering.
Outputs: either a full proof (no reachable bad state) or a counterexample trace from Reach
operations.
Pros: can give complete proofs; gives symbolic invariants.
Cons: memory blow-up for large memory widths (16-bit × depth) and many pointers; must
abstract data for practical sizes.
4) CNF / SAT-based BMC + IC3/induction approach — how
to apply
When to choose: find bugs quickly, scale to larger bitwidths; use modern IC3/PDR for proofs
where possible.
Steps:
1. Bounded Model Checking (BMC, CNF):
○ Unroll the transition relation for k cycles: produce formula Init(s0) ∧
T(s0,s1) ∧ … ∧ T(s_{k-1}, s_k) ∧ bad(s_i) where bad = negation
of the safety property at some time i ≤ k.
○ Translate the boolean circuit/RTL to CNF (bit-blast arithmetic operations,
memories either unrolled or use memory encodings).
○ Run a SAT solver on the CNF. If SAT ⇒ counterexample trace of length ≤ k. If
UNSAT ⇒ no counterexample of length ≤ k.
2. Increment k until you either find a counterexample or reach resource limits. BMC is
great for quickly finding off-by-one or sequencing bugs.
3. Induction / k-induction: To attempt a (complete) proof, use k-induction (or base case +
inductive step). Base: no counterexample up to k. Inductive: assume property holds for k
consecutive states; show it holds in next state. If inductive step proves, you have a full
proof. But induction often needs strengthenable invariants.
4. IC3 / PDR (preferred modern technique):
○ Run IC3/PDR on the transition relation and the bad state. It searches for
inductive invariants (frames) that block bad states and often succeeds where
naive induction fails. IC3 uses SAT internally (CNF encoding) and can produce
proofs or find counterexamples.
5. Memory modeling: For FIFO memory, BMC can either:
○ Unroll memory writes/reads into the CNF, tracking concrete mem elements for
each time; or
○ Use an uninterpreted/memory abstraction: for ordering checks, tag writes with
sequence numbers and only handle tags rather than full 16-bit words.
Outputs: counterexample traces (very useful), or an inductive invariant / proof when IC3
succeeds.
Pros: very scalable for finding bugs; IC3/PDR often produces full proofs without BDD blowup.
Cons: pure BMC without induction cannot prove unbounded safety.
5) Practical verification plan (step-by-step)
1. Clarify ambiguous semantics (e.g., whether IS_ACTIVE must force operations or only
allow them; simultaneous read/write semantics). Document assumptions.
2. Create formal harness / reference model:
○ A concise reference FIFO model (queue with enqueue/dequeue) in the same
clock domain.
○ A monitor that enqueues written data with sequence tags and checks outputs
when IS_VALID.
3. Initial checks with SAT/BMC (CNF):
○ Encode basic safety checks: no overflow/underflow, IS_EMPTY/IS_FULL
correspond to count values, LDETECT detection.
○ Run BMC for small k (e.g., 1..depth+2) to find obvious bugs.
4. Ordering and functional correctness:
○ Use monitor-based checks (reference model) to validate FIFO ordering and data
equality. BMC can find ordering bugs quickly for short traces.
5. Try IC3/PDR for proofs:
○ For properties that survived BMC, run IC3/PDR to attempt inductive proof of
safety (no bad state reachable).
6. If IC3 fails and BDD feasible, run ROBDD reachability:
○ Use BDD-based model checking for residual properties if the state size is low
(small depth, abstracted data).
7. Abstraction & refinement:
○ Abstract away 16-bit data contents (use uninterpreted tags) if data values cause
blowup; refine if counterexamples are spurious.
○ For LDETECT, you only need occupancy count; do not model full memory
contents.
8. Report results:
○ For each property: COUNTEREXAMPLE (trace) or PROVEN (with proof
certificate / invariant) or UNKNOWN (resource/time out).
○ For proofs, export inductive invariants / unsat cores if supported.
6) Example property encodings (concise recap)
● assert ( (WR_EN | RD_EN) -> IS_ACTIVE ); // ops only when active
● assert (IS_EMPTY == (count == 0));
● assert (IS_FULL == (count == DEPTH));
● assert (LDETECT == (count == BLOCK_SIZE));
● Monitor-based: on write, enqueue tag; on read with IS_VALID, assert DATA_OUT ==
model_dequeue().
7) Extra notes, pitfalls & tips
● Environment constraints: If inputs are arbitrary, you may get counterexamples that are
unrealistic. Use assume properties for environment behavior (e.g., IS_ACTIVE stable
around edges, WR_EN/RD_EN not asserted in the same cycle in some designs).
● Simultaneous read & write: Specify semantics: many FIFOs allow simultaneous read &
write with count unchanged — encode that.
● Memory handling: For large depth × data width, do not fully bit-blast memory contents
for full-state proofs; instead track count/pointers and use tags for functional checks.
● Which engine first: use SAT/BMC to find bugs quickly; then IC3/PDR to try to prove;
then BDD only if necessary and manageable.
Final recommended workflow for your exam answer
1. State the techniques: ROBDD symbolic model checking and CNF/SAT-based
BMC/IC3.
2. Show how to model FIFO: list state variables (head/tail/count/mem), inputs, outputs,
and transition relation.
3. Give the key properties in a formal/assertion form (examples above).
4. Explain process: run BMC (CNF) to find bugs; run IC3/PDR to prove safety; use
ROBDD for full-state reachability if state space small or after abstraction.
5. Mention abstraction & monitors for ordering: tag writes and check read order to
prove FIFO ordering.
