plain CS/EE 5750/6750: Asynchronous Circuit Design

CS/EE 5750/6750: Asynchronous Circuit Design

Chris J. Myers
Lecture 8: Verification
Chapter 8

Circuit Verification

Protocol Verification

  • Specification for circuit usually trys to accomplish certain goals.
  • Examples:

    • Protocol never deadlocks.
    • Whenever there is a request, it is followed by an acknowledgement possibly in a bounded amount of time.

  • Simulation can again be used, but has the same problem.
  • Verification can also be used to check if a specification meets its goals under all permissable delay behaviors.


  • To verify a circuit conforms to a specification, it is necessary to check that all its behaviors are allowed by the specification.
  • Define using traces of events on signals.
  • A trace is similar to an allowed sequence, but tracks signal changes rather than states.

State Graph for a C-element

Traces Structures

  • Set of all possible traces is represented using a trace structure.
  • To verify hazard-freedom, use prefix-closed trace structures.
  • Described using a four-tuple I,O,S,F :

    • I is the set of input signals.
    • O is the set of output signals.
    • S is all traces which are considered successful.
    • F is all traces which are considered a failure.

  • A = I O and P = S F.


  • A trace structure must be receptive.
  • It is receptive when the state of a circuit cannot prevent an input from happening (i.e., PI P).

Receptive State Graph for a C-element

Inverse Delete

  • Before composition of circuits must make their signal sets match.
  • T1 = I1, O1, S1, F1 and T2 = I2, O2, S2, F2 .
  • If N is signals in A2 and not in A1, then add N to I1 and extend S1 and F1 to allow events on signals in N at any time.
  • Must also extend T2 with those signals in A1 but not in A2.
  • This is done by inverse delete function, denoted del(N)-1(x) where N is a set of signals and x is a set of traces.
  • Function inserts elements of N* between consecutive signals in x.
  • This function can be extended to a trace structure as follows:
    I N, O, del(N)-1(S), del(N)-1(F)


  • Given two trace structures with consistent signal sets (i.e., A1 = A2 and O1 O2 = ):
    T1 T2
    I1 I2, O1 O2, S1 S2, (F1 P2) (F2 P1)
  • Trace is success in composite when a success in both circuits.
  • Trace is a failure when it is a failure in either circuit.
  • Set of possible traces may be reduced (P1 P2).
  • Composition is defined as follows:
    T1 || T2
    del(A2 - A1)-1(T1) del(A1 - A2)-1(T2)

Composition Example

Figure Figure

Inverter After Renaming and Inverse Deletion


Composition of One Inverter and C-element

Complete Circuit


  • To verify that a circuit correctly implements a specification, we must show that TI conforms to TS (denoted TI \preceq TS).
  • Must show that in any environment, TE, where the specification is failure-free, the circuit is also failure-free.
  • TE is any trace structure with complementary inputs and outputs (i.e., IE = OI = OS and OE = II = IS).
  • To check conformance, must show that for every possible TE that if TE TS is failure-free then so is TE TI.

Conformation Equivalence

  • Two trace structures T1 and T2 are conformation equivalent (denoted T1 ~ C T2) when T1 \preceq T2 and T2 \preceq T1.
  • If T1 ~ C T2, it does not imply that T1 = T2.
  • To make this true, use canonical prefix-closed trace structures.

Figure Figure

Autofailure Manifestation

  • An autofailure is a trace x which if extended by a signal y O then xy F.
  • Also denoted F/O F where F/O is defined to be { x | $y O . xy F }.
  • If S then any failure trace has a prefix that is a success, and an input causes it to become a failure.
  • If the environment sends a signal change which the circuit is not prepared for, we say that the circuit chokes.
  • We must also add to the failure set any trace that has a failure as a prefix (i.e., FA F).

Failure Exclusion

  • Failure exclusion makes the success and failure sets disjoint.
  • When trace occurs in both, circuit may or may not fail.
  • Remove from success set any trace which is also a failure (S = S - F).

Two Inverters after Simplification


Canonical Prefix-Closed Trace Structures

  • In a canonical prefix-closed trace structure:

    1. Autofailures are failures (i.e., F/O F).
    2. Once a trace fails, it remains a failure (i.e., FA F).
    3. No trace is both a success and failure (i.e., S F = ).

  • Failure set is not necessary (i.e., T = I,O,S ).
  • Determine the failure set as follows:
    [(SI { e}) - S]A*
  • Any successful trace when extended with an input signal transition and is no longer found in the success set is a failure.
  • Any such failure trace can be extended indefinitely and will always be a failure.


  • To check TI \preceq TS, must check that in all environments that TS is failure-free that TI is also failure-free.
  • Construct a unique worst-case environment called a mirror of T (denoted TM).
  • Mirror can be constructed by simply swapping the inputs and outputs (i.e., IM = O, OM = I, and SM = S).
  • If TI || TSM is failure-free, then TI \preceq TS.

Example: Merge Element

Figure Figure

Can we replace alternating with general merge?


Can we replace general with alternating merge?



  • Only checks safety properties.
  • If a circuit verifies, it means it does nothing bad.
  • It does not mean, however, it does anything good.
  • A ``block of wood'' accepts any input, but it never produces any output (i.e., T = I,O,I* ).
  • Assuming inputs and outputs are made to match, a block of wood would comform to any specification.

Timed Trace Theory

  • A timed trace is a sequence of x = (x1, x2, ) where each xi is an event/time pair of the form (ei,ti) such that:

    • ei A, the set of signals.
    • ti Q, the set of nonnegative rational numbers.

  • A timed trace must satisfy the following two properties:

    • Monotonicity: for all i, ti ti+1.
    • Progress: if x is infinite, then for every t Q there exists an index i such that ti > t.

Model Checking

  • Model checking is the process of verifying whether a protocol, circuit, or other type of system has certain desired properties.
  • To specify desired behavior of a combinational circuit, one can use propositional logic.
  • For sequential circuits, it is necessary to describe behavior of a circuit over time, so one must use a propositional temporal logic.
  • Describe computation tree logic (CTL) and a timed variant, TCTL, used to specify timing properties.

Computation Tree Logic (CTL)

  • A temporal logic is a propositional logic which has been extended with operators to reason about future states of a system.
  • CTL is a branching-time temporal logic which has been devised in such a way as to lend itself to efficient analysis procedures.
  • The set of CTL formulas can be described recursively as follows:

    1. Any atomic proposition p AP is a CTL formula.
    2. If f and g are CTL formulas then so are:

      1. f (not)
      2. f g (and)
      3. "\bigcirc f (universal next state operator)
      4. $\bigcirc f (existential next state operator)
      5. "[f U g] (universal until operator)
      6. $[f U g] (existential until operator)

CTL Semantics

  • Truth of formula f is defined with respect to a state si (si \models f).
  • f is true in a state si when f is false in that state.
  • f g is true when both f and g are true in si.
  • "\bigcirc f is true in state si when f is true in all next states sj reachable in one transition.
  • $\bigcirc f is true in state si when f is true in any next state sj.
  • "[f U g] is true in a state si when in all allowed sequences starting with si, f is true until g becomes true.
  • $[f U g] is true in a state si when there exists an allowed sequence starting with si in which f is true until g becomes true.

Formal CTL Semantics

si \models p
p P(si)
si \models f
si \not\models f
si \models f g
si \models f and si \models g
si \models "\bigcirc f
for all sj  such that (si,t,sj) d . sj \models f
si \models $\bigcirc f
there exists sj  such that (si,t,sj) d . sj \models f
si \models "[f U g]
for all allowed sequences (si,si+1,),
$j [ j i sj \models g "k [i k < j sk \models f]]
si \models $[f U g]
for some allowed sequence (si,si+1,),
$j [ j i sj \models g "k [i k < j sk \models f]]

CTL Abbreviations

  • "\Diamond f means f will eventually become true in all allowed sequences starting in the current state.
    "\Diamond f
    "[true U f] 
  • $\Diamond f means f will become true in some allowed sequence.
    $\Diamond f
    $[true U f] 
  • "[¯] f means f is always true in all allowed sequences.
    "[¯] f
  • $[¯] f means f is always true in some allowed sequence.
    $[¯] f

Desired Properties for a Passive/Active Wine Shop

  • Should not raise ack_wine until req_wine goes high:
    "[¯] (ack_wine  "( ack_wine U  req_wine))
  • Once ack_wine is high, it must stay high until req_wine goes low:
    "[¯] (ack_wine  "( ack_wine U  req_wine))
  • Once the shop has set req_patron high, it must hold it high until ack_patron goes high:
    "[¯] (req_patron  "( req_patron U  ack_patron))
  • Once the shop sets req_patron low, it must hold it low until ack_patron goes low:
    "[¯] (req_patron  "( req_patron U  ack_patron))

Desired Properties for a Passive/Active Wine Shop

  • Once the request and acknowledge wires on either side go high, they must be reset again:

    "[¯] ((req_wine  ack_wine)   "\Diamond (req_wine   ack_wine))
    "[¯] ((req_patron  ack_patron)   "\Diamond (req_patron   ack_patron))
  • The wine should not stay on the shelf forever, so after each bottle arrives, the patron should be called.
    "[¯] (ack_wine  "\Diamond req_patron)
  • The patron should not arrive expecting wine in the shop before the wine has actually arrived.
    "[¯] (ack_patron  "( ack_patron U  ack_wine))

"[¯] (ack_wine  "( ack_wine U  req_wine))

"[¯] (ack_wine  "( ack_wine U  req_wine))

"[¯] (req_patron  "( req_patron U  ack_patron))

"[¯] (req_patron  "( req_patron U  ack_patron))

"[¯] ((req_wine  ack_wine)   "\Diamond (req_wine   ack_wine))

"[¯] ((req_patron  ack_patron)   "\Diamond (req_patron   ack_patron))

"[¯] (ack_wine  "\Diamond req_patron)

"[¯] (ack_patron  "( ack_patron U  ack_wine))

"[¯] (ack_patron  "( ack_patron U  ack_wine))

Timed CTL

  • "\Diamond f states that eventually f becomes true, but it puts no guarantee on how long before f will become true.
  • To express bounded response time, it is necessary to extend the temporal logic that we use to specify timing bounds.
  • In timed CTL, each temporal operator is annotated with a timing constraint.
  • "\Diamond < 5 f states that f becomes true in less than 5 time units.

Timed CTL Formulas

  • Timed CTL formulas can be described recursively as follows:

    1. Any atomic proposition p AP is a CTL formula.
    2. If f and g are CTL formulas then so are:

      1. f (not)
      2. f g (and)
      3. "[f U ~ c g]
      4. $[f U ~ c g]

    where ~ is < , , = , , > .
  • There is no next time operator, since when time is dense, there can be no unique next time.

Timed CTL Abbreviations

"\Diamond ~ c f
"[true U ~ c f]
$\Diamond ~ c f
$[true U ~ c f]
"[¯] ~ c f
$\Diamond ~ c(f)
$[¯] ~ c f
"\Diamond ~ c(f)

  • Using the basic TCTL primitives, we can also define temporal operators subscripted with time intervals.
    "\Diamond(a,b) f
    "\Diamond = a "\Diamond < (b-a) f

Some Bounded Response Time Properties

  • Once the request and acknowledge wires on either side go high, they must be reset again within 10 minutes:
    "[¯] ((req_wine  ack_wine)
    "\Diamond 10 (req_wine   ack_wine))
    "[¯] ((req_patron  ack_patron)
    "\Diamond 10 (req_patron   ack_patron))
  • We also don't want the wine to age too long on the shelf, so after each bottle arrives, the patron should be called within 5 minutes:
    "[¯] (ack_wine  "\Diamond 5  req_patron)


  • Circuit verification:

    • Trace structures
    • Conformance checking
    • Timed trace theory

  • Protocol verification:

    • Computation tree logic (CTL)
    • Timed CTL

File translated from TEX by TTH, version 2.22.
On 24 Apr 2000, 18:35.