8. Assertion Based Design and Assertion Languages Verification - - PowerPoint PPT Presentation

▶
8 assertion based design and assertion languages
SMART_READER_LITE
LIVE PREVIEW

8. Assertion Based Design and Assertion Languages Verification - - PowerPoint PPT Presentation

Sep 20, 2023 334 likes •861 views

8. Assertion-Based Design and Assertion Languages 1 Fachgebiet Rechnersysteme 8. Assertion Based Design and Assertion Languages Verification Technology Content 8.1 Assertion-Based Design 8.2 Introduction to ITL 8.3 Introduction to SVA

slide-1
SLIDE 1
  • 8. Assertion-Based Design and Assertion Languages

1

  • 8. Assertion Based Design and

Fachgebiet Rechnersysteme

Assertion Languages

Verification Technology

Content

8.1 Assertion-Based Design 8.2 Introduction to ITL 8.3 Introduction to SVA Appendix: Regular expressions

slide-2
SLIDE 2
  • 8. Assertion-Based Design and Assertion Languages

2

8.1 Assertion-Based Design

Assertions properties 8.1 Assertion Based Design

Assertions, properties

Software:  Mainly state-based  Only one time-point involved

HDL assertions  VHDL  VHDL

Temporal Logic Assertions  May involve many (all) time-points  May involve many (all) time points  Safety/liveness properties  CTL (state-formulas)  LTL (path-formulas)

Verification Languages  PSL (P t S ifi ti L )  PSL (Property Specification Language)  SystemVerilog Assertions (SVA)

slide-3
SLIDE 3
  • 8. Assertion-Based Design and Assertion Languages

3 8.1 Assertion-based design

Assertions Type Time-points referenced Proof procedure Examples State-based referenced 1 Simulation/ M d l h ki Software assertions Finite-window 1-20 (200) Model-checking Bounded assertions Timing Infinite-window ( ) all model-checking Model g diagrams Temporal Infinite-window all Model- checking Temporal logic formulas

slide-4
SLIDE 4
  • 8. Assertion-Based Design and Assertion Languages

4 8.1 Assertion-based design

Example of property-based verification (Winkelmann, Infineon)  UMTS base-band station chip, 1024 parallel processes, configuration changes every 10 ms, Pipelining, 100 MHz, 2M gates, 70k lines of VHDL  ~ 40k lines of assertions (properties) (560)  Regression run 2 – 80 h  200 bugs found, 50 likely to escape simulation

slide-5
SLIDE 5
  • 8. Assertion-Based Design and Assertion Languages

5 8.1 Assertion-based design

Assertion-(Property)-Based Design

Assertions in VHDL

Assertions in VHDL  Assertions are checked during simulation  Violated assertions lead to messages  Violated assertions lead to messages  Syntax: assert CONDITION report "TEXT" severity LEVEL; assert CONDITION report TEXT severity LEVEL;  TEXT appears if CONDITION=false  Severity: note warning error failure  Severity: note, warning, error, failure – Example: assert (S(1) and S(2)) /= ´1´ report "state 11" ( ( ) ( )) p severity note; if state 11 is reached then the message "state 11" is reported state 11 is reported

slide-6
SLIDE 6
  • 8. Assertion-Based Design and Assertion Languages

6 8.1 Assertion-based design

4 types of applications of assertions (2 soft, 2 hard)  Cosimulation after translation into HDL ("monitors")  Cosimulation after translation into HDL ( monitors ) – e.g., FOCS tool (IBM) for complex assertions

S t Simulator Assertions

 Formal verification

System Description

 Formal verification – e.g., (Bounded) Model-checker

System Formal Verification Tool Assertions y Description Tool

slide-7
SLIDE 7
  • 8. Assertion-Based Design and Assertion Languages

7 8.1 Assertion-based design

4 types of applications of assertions (2 soft, 2 hard)  Generation of hardware run-time monitors and  Generation of hardware run time monitors and integration on-chip, e.g., FPGA

S t Assertions Monitor- circuits System Description

Circuit

Hardware

 Synthesis of hardware

Assertions

HDL Circuit

slide-8
SLIDE 8
  • 8. Assertion-Based Design and Assertion Languages

8 8.1 Assertion-based design

Monitors  Transform assertions into executable VHDL  Transform assertions into executable VHDL  Co-simulate assertions and monitor truth-value

  • r:

 Generate hardware-monitors + integrate on FPGA – Commercial solutions available Commercial solutions available

slide-9
SLIDE 9
  • 8. Assertion-Based Design and Assertion Languages

9 8.1 Assertion-based design

Hardware run-time monitors:  Generate hardware monitors and integrate on e g  Generate hardware monitors and integrate on, e.g., FPGA f4 f2 f4 f2 i f1

A hardware

f3 f5

A hardware monitor

1 f1'' f1' f1t  f4t+2

slide-10
SLIDE 10
  • 8. Assertion-Based Design and Assertion Languages

10

8.2 Introduction to ITL 8.2 Introduction to ITL

ITL: Interval Temporal Logic  Proprietary temporal language of the MV360 formal property checker of OneSpin Solutions  Specifically tailored to the needs of incomplete BMC  Provides only references in a finite time-window

slide-11
SLIDE 11
  • 8. Assertion-Based Design and Assertion Languages

11 8.2 Introduction to ITL

Properties are specified as propertys with an assume-part (the assumption) and a prove-part (the commitment) ( p ) p p ( ) property myproperty is assume: <assumptions>; prove: <commitments>; prove: <commitments>; end property;

slide-12
SLIDE 12
  • 8. Assertion-Based Design and Assertion Languages

12 8.2 Introduction to ITL

Each of the assumptions/commitments states a number of signal-values at some time-points by means of references g p y to the time-variable t – Example: property myproperty is assume: assume: at t: x = '0'; at t+2: y = '1'; prove: at t+4: enable = '1'; at t+7: ack = y; at t+7: ack = y; end property;

The time-intervals of assumption and

commitment may overlap !

slide-13
SLIDE 13
  • 8. Assertion-Based Design and Assertion Languages

13 8.2 Introduction to ITL

VHDL or Verilog syntax is allowed for signals, constants, and functions

NEXT and PREV are used to refer to next or previous time- points, respectively  The default values are 1 – Example: property myproperty is ass me assume: at t: x = '0'; prove: p at t+2: NEXT(y) = PREV(x); at t+3: y = PREV(x,2); end property; end property;

slide-14
SLIDE 14
  • 8. Assertion-Based Design and Assertion Languages

14 8.2 Introduction to ITL

during and within specify relationships that have to hold for all time-points or for at least one time-point in a p p reference time-interval, respectively – Example: property myproperty is property myproperty is assume: at t: x = '0'; prove: during[t+1,t+4]: enable = PREV(y 2); enable = PREV(y,2); end property;

slide-15
SLIDE 15
  • 8. Assertion-Based Design and Assertion Languages

15 8.2 Introduction to ITL

The freeze construct introduces a new alias for the value

  • f a signal at a certain time-point; the alias can be

g p ; referenced arbitrarily – Example: property myproperty is property myproperty is freeze: y_t = y@t; assume: at t: x = '0'; prove: within[t+1 t+4]: y = y t; within[t+1,t+4]: y = y_t; end property;

slide-16
SLIDE 16
  • 8. Assertion-Based Design and Assertion Languages

16 8.2 Introduction to ITL

ITL provides much more constructs like macros, index loops, etc. p ,

Semantics: "Implications between observed and expected behaviors at arbitrarily selectable time-points in a finite time-window"

slide-17
SLIDE 17
  • 8. Assertion-Based Design and Assertion Languages

17

8.3 Introduction to SVA

SVA: SystemVerilog Assertions 8.3 Introduction to SVA

SVA: SystemVerilog Assertions  Rich and expressive property language  Compatible with SystemVerilog y g  Part of SystemVerilog IEEE Standard 1800  "Similar" approaches: OVL O V ifi ti Lib – OVL: Open Verification Library – Property Specification Language (PSL)

Common idea: have a common and standardized

Common idea: have a common and standardized language to express properties of a design

SVA resources:  1800 2009 IEEE St d d f S t V il  1800-2009 IEEE Standard for SystemVerilog— Unified Hardware Design, Specification, and Verification Language F t /K l ik/L A ti B d D i  Foster/Krolnik/Lacey: Assertion-Based Design, Kluwer 2003 (also for OVL and PSL)

slide-18
SLIDE 18
  • 8. Assertion-Based Design and Assertion Languages

18 8.3 Introduction to SVA

SVA is an assertion language based on SystemVerilog  Developed at Accellera as verification extension of  Developed at Accellera as verification extension of SystemVerilog (IEEE1800-2005)  Used for formal verification as well as for the generation of simulation checkers (monitors)

slide-19
SLIDE 19
  • 8. Assertion-Based Design and Assertion Languages

19 8.3 Introduction to SVA

Example 1: req ##1 ack ##1 ~halt |-> grant ##1 grant q ## ## | g ## g  "After the sequence req=1; ack=1; halt=0, grant should be 1 for two time steps": 1 2 3 4 1 2 3 4 req 1

  • ack
  • 1
  • halt -
  • grant-
  • 1

1

  • req ##1 ack ##1 ~halt

grant ##1 grant

slide-20
SLIDE 20
  • 8. Assertion-Based Design and Assertion Languages

20 8.3 Introduction to SVA

Example 2:  The ack-signal must occur within 2 cycles after a  The ack-signal must occur within 2 cycles after a req-signal (including reaction at the same step as req) req |-> ##[*0:2] ack

slide-21
SLIDE 21
  • 8. Assertion-Based Design and Assertion Languages

21 8.3 Introduction to SVA

SVA is organized in four layers:  Boolean expression layer  Boolean expression layer – Just HDL-compatible Boolean expressions and or etc – and, or, etc.  Sequence layer Adds timing relationships – Adds timing relationships  Property layer Definition of Property – Definition of Property  Assertion directive layer D fi f t – Defines usage of property

slide-22
SLIDE 22
  • 8. Assertion-Based Design and Assertion Languages

22 8.3 Introduction to SVA

The semantics of SVA is defined over legal execution paths (see Section 5.8)  of a transition system T ( ) y

We use the notation z0, z1, ... for a (legal) path 

We follow the notational convention that i denotes the i-th We follow the notational convention that  denotes the i th suffix zi, zi+1, ... of a path

In addition, i,j with i ≤ j denotes the fragment from state zi to state zj of 

|  | denotes the length of a path

The empty path of length 0 is formally denoted by 

slide-23
SLIDE 23
  • 8. Assertion-Based Design and Assertion Languages

23 8.3 Introduction to SVA

Boolean expressions  Some syntactic conventions:  Some syntactic conventions: – &,&& and – |,||

  • r

|,|| – ~ negation – =,== equality, equivalence – 0, 1 the Boolean constants

Semantics:

Semantics: A Boolean expression b characterizes a path  = z0, z1, ..., T, |= b, iff the state z0 is characterized by b

slide-24
SLIDE 24
  • 8. Assertion-Based Design and Assertion Languages

24 8.3 Introduction to SVA

Sequences  Attempt to reflect the world of timing diagrams  Attempt to reflect the world of timing diagrams  Describe sequences of events  Not a property but sort of a "filter"  Not a property, but sort of a filter  Encapsulate behavior  Can be built from other sequences  Can be built from other sequences  Can be defined or used standalone Syntax: sequence NAME(args); < > <sequenceexpr> endsequence;

slide-25
SLIDE 25
  • 8. Assertion-Based Design and Assertion Languages

25 8.3 Introduction to SVA

Sequences may be described using additional sequence

  • perators

p

Syntax definition (r1,r2 sequences; b Boolean expression):  Boolean expressions are sequences Boolean expressions are sequences  r1 ##1 r2 (Sequence concatenation)  r1 ##0 r2 (Sequence fusion) r1 ##0 r2 (Sequence fusion)  r1[*0:$] (Consecutive repetition)  r1 or r2 (Sequence or)  r1 or r2 (Sequence or)  r1 and r2 (Sequence and)  r1 within r2 (Sequence within)  r1 within r2 (Sequence within)  b throughout r2 (Expression during sequence)

The semantics is defined over finite paths (see the

The semantics is defined over finite paths (see the Reference Manual for the following)

slide-26
SLIDE 26
  • 8. Assertion-Based Design and Assertion Languages

26 8.3 Introduction to SVA

Sequence concatenation: "r1 ##1 r2"  Example: a b Boolean expressions:  Example: a, b Boolean expressions: a ##1 b means that b holds at t and a holds at t-1  Semantics: Semantics: T, |= {r1 ##1 r2} iff there exist paths  and  such that  =  , T, |= r1 and T, |= r2

slide-27
SLIDE 27
  • 8. Assertion-Based Design and Assertion Languages

27 8.3 Introduction to SVA

 More examples: a ##1 ~b holds for t=4,6 ## , a ##1 ~b ##1 c holds for t=5 1 2 3 4 5 6 1 2 3 4 5 6 a 1 1 1 1 b 1 1 1 c 1 1 1

slide-28
SLIDE 28
  • 8. Assertion-Based Design and Assertion Languages

28 8.3 Introduction to SVA

Sequence fusion: "r1 ##0 r2"  r and r overlap by one cycle  r1 and r2 overlap by one cycle – Example: (a ##1 b) ##0 (c ##1 d) holds if a holds in the first cycle, b and c in the second, d in y , , the third  Semantics: T, |= {r1 ##0 r2} iff there exists paths  and  and state z such that  = z  , T,z |= r1 and T, z |= r2

slide-29
SLIDE 29
  • 8. Assertion-Based Design and Assertion Languages

29 8.3 Introduction to SVA

Sequence operators and and or  Semantics:  Semantics: T, |= r1 and r2 iff T, |= r1 and T, |= r2

 r1 and r2 are not required to be of the

same length  T, |= r1 or r2 iff T, |= r1 or T, |= r2  T, | r1 or r2 iff T, | r1 or T, | r2

slide-30
SLIDE 30
  • 8. Assertion-Based Design and Assertion Languages

30 8.3 Introduction to SVA

Consecutive repetition operator "s[*0:$]"  Means zero or more repetitions of s  Means zero or more repetitions of s  "s" arbitrary sequence  Semantics:  Semantics: T, |= s[*] iff either  =  or there exists paths , , ..., j such that  = ...j and for all i, 1 ≤ i ≤ j, T,i |= s

j

The "*" operator is originally the Kleene The "*" operator is originally the Kleene-

  • perator for ordinary regular expressions; "a*"

means "any sequence of a's including the empty y q g p y sequence"; regular expressions are sequences

  • f literals that can be constructed from

concatenation and the *-operator concatenation and the -operator

see Appendix of this Chapter

slide-31
SLIDE 31
  • 8. Assertion-Based Design and Assertion Languages

31 8.3 Introduction to SVA

Sequence declaration  Declared sequences have names and optional formal  Declared sequences have names and optional formal parameters – Example: Example: sequence b_after_a (a, b); a ##[*0:2] b; endsequence; endsequence; b_after_a(req, ack) |-> x is identical to _ _ req ##[*0:2] ack |-> x

slide-32
SLIDE 32
  • 8. Assertion-Based Design and Assertion Languages

32 8.3 Introduction to SVA

Property Layer  Two types of properties: concurrent and immediate  Two types of properties: concurrent and immediate

Immediate Assertion:

Immediate Assertion: – Direct test, whether expression true or false Execution during simulation of behavioral code – Execution during simulation of behavioral code – Can only be used in procedures and functions Limited instruction set – Limited instruction set If ( >b) th If (a>b) then assert(x) $display("PASS"); l $di l ("FAIL") else $display("FAIL");

slide-33
SLIDE 33
  • 8. Assertion-Based Design and Assertion Languages

33 8.3 Introduction to SVA

Property Layer  Two types of properties: concurrent and immediate  Two types of properties: concurrent and immediate

Concurrent Assertion:

Concurrent Assertion: – (Usually clocked) property check Complete instruction set available – Complete instruction set available – Can be used only at distinct places in the code Can be used outside of procedures – Can be used outside of procedures P t d fi iti li k d t SV M d l Property definition, linked to SV-Module

slide-34
SLIDE 34
  • 8. Assertion-Based Design and Assertion Languages

34 8.3 Introduction to SVA

Property Layer  Can be defined parametrically:  Can be defined parametrically: Syntax: property NAME(ARGS); Syntax: property NAME(ARGS); <property_definition> endproperty; endproperty;  Basic operation is implication:  Basic operation is implication: – A |-> B A implies B, B starts in the last cycle

  • f A
  • f A

– A |=> B A implies B, B starts 1 cycle after the last cycle of A y

slide-35
SLIDE 35
  • 8. Assertion-Based Design and Assertion Languages

35 8.3 Introduction to SVA

Suffix implication operator "r1 |-> r2"  r begins in the cycle when r ends (overlapping by one  r2 begins in the cycle when r1 ends (overlapping by one cycle) – Example: req ##1 ack ##1 ~halt |-> p q ## ## | grant ##1 grant  Semantics:

0 j

T, |= r1 |-> r2 iff for all j, 0 ≤ j < ||, such that T,0,j |= r1 there exists k, j ≤ k ≤ ||, and T,j,k |= r2 1 2 3 4 1 2 3 4 req 1

  • ack
  • 1
  • halt -
  • grant-
  • 1

1

  • T,0,2 |= req ##1 ack ##1 ~halt T,2,3 |= grant ##1 grant
slide-36
SLIDE 36
  • 8. Assertion-Based Design and Assertion Languages

36 8.3 Introduction to SVA

Suffix next implication operator "s1 |=> s2"  Same as the suffix implication operator but s2 begins  Same as the suffix implication operator, but s2 begins in the cycle after the left sequence ends  r1 |=> r2 = r1 |-> 1 ##1 r2

1 | 2 1 |

##

2

 Example: req ##1 ack ##1 ~halt |=> grant[*2] 1 2 3 4 1 2 3 4 req 1

  • ack
  • 1
  • halt -
  • grant-
  • 1

1

slide-37
SLIDE 37
  • 8. Assertion-Based Design and Assertion Languages

37 8.3 Introduction to SVA Semantics: Property satisfaction:

Holds strongly:

Holds strongly:  no bad states have been seen  all future obligations have been met  the property will hold on any extension of the path

Holds (but not strongly):  no bad states have been seen  all future obligations have been met  all future obligations have been met  the property may or may not hold on any extension of the path

Pending (Holds weakly):  no bad states have been seen  future obligations have not been met  (the property may or may not hold on any extension of the path)

Fails:  a bad state has been seen  (future obligations may or may not have been met)  (the property may or may not hold on any extension of the path)

slide-38
SLIDE 38
  • 8. Assertion-Based Design and Assertion Languages

38 8.3 Introduction to SVA

Clocked sequences and properties

SVA provides constructs to restrict the evaluation of paths

SVA provides constructs to restrict the evaluation of paths to reference signals (clocks) "@clk"  Examples: Examples: (@clk)(a ##1 ~b) holds for t=3,6 (@clk)(a ##1 ~b ##1 c) holds for t=6 1 2 3 4 5 6 1 2 3 4 5 6 clk 1 1 1 1 a 1 1 1 1 b 1 1 1 c 1 1

slide-39
SLIDE 39
  • 8. Assertion-Based Design and Assertion Languages

39 8.3 Introduction to SVA

The posedge and negedge functions can be used to specify rising and falling edges of clock-signals, respectively g g g g , p y  (@ posedge clk)

slide-40
SLIDE 40
  • 8. Assertion-Based Design and Assertion Languages

40 8.3 Introduction to SVA

Properties define temporal relationships among Boolean expressions, sequences or properties itself p , q p p

Temporal property operators  The past-operator "$past(p)" p p $p (p) – Takes us backward one clock cycle  The always-operator "always p" The always operator always p – States that p always holds ( ~ LTL G) – Implicit operator for concurrent properties Implicit operator for concurrent properties  Property implication operators "p1 |-> p2" and "p1 |=> p2" p p  And many more ...

The arguments may be either sequences or properties g y q p p

slide-41
SLIDE 41
  • 8. Assertion-Based Design and Assertion Languages

41 8.3 Introduction to SVA

Property declaration  Declared properties have names and optional formal  Declared properties have names and optional formal parameters – Example: Example: property mutex (boolean clk, a, b); always @(posedge clk) ~(a & b); endproperty; endproperty;

slide-42
SLIDE 42
  • 8. Assertion-Based Design and Assertion Languages

42 8.3 Introduction to SVA

Reset signals  Properties only useful if special conditions excluded.  Properties only useful if special conditions excluded.  "disable iff(c)" interrupts evaluation of property if c becomes true Example: property mutex (boolean clk a b c); property mutex (boolean clk, a, b,c); disable iff (c) always @(posedge clk) ~(a & b); endproperty; endproperty;

slide-43
SLIDE 43
  • 8. Assertion-Based Design and Assertion Languages

43 8.3 Introduction to SVA

 Assertion Layer

F d d h t i t Four codewords characterize a property:

 Codeword ASSERT: Property to be proven  Codeword ASSUMPTION: Property is assumed  Codeword COVER: Property is coverage-trigger  Codeword EXPECT: Like ASSERT, but blocks execution

Examples: P1: assert property (@posedge CLK) disable iff (COND) EXPR (COND) EXPR; P2: cover property Prop6(sig1,sig2,sig3); P3 (EXPR) P3: assert (EXPR);

slide-44
SLIDE 44
  • 8. Assertion-Based Design and Assertion Languages

44 8.3 Introduction to SVA

Summary

SVA :

SVA :  Rich and (quite) complex language  Idea: support "assertion based design"  Idea: support assertion-based design  Automatic proof-tools for the full language do not exist currently (2010) currently (2010)  Automatic simulation checker generation for a large SVA-subset available  Sets of properties can not be simulated (in contrast to specifications in executable languages like SpecC, S t C t ) SystemC, etc.)

slide-45
SLIDE 45
  • 8. Assertion-Based Design and Assertion Languages

45 Appendix: Automata and regular expressions

Modern assertion-languages include regular expressions for the specification of properties A b i f i f th l ti hi b t t t d

A brief review of the relationship between automata and regular expressions …

A Mealy-machine: y

0/0 i/o 1/1 0/0 i

  • 1/0
slide-46
SLIDE 46
  • 8. Assertion-Based Design and Assertion Languages

46 Appendix: Automata and regular expressions

We consider the observable (legal, possible) sequences of input and output values (traces)  "00" means i=0 and o=0, etc.  An example trace is 00.00.11.10.10.10.00.11 …  Formally, we consider the values 00, … as the "letters"

  • f the alphabet A = {00,10,11}

A " d" i f d b t ti " " l tt f th  A "word" is formed by concatenating "." letters of the alphabet  A language is a set of words formed according to some

00

 A language is a set of words formed according to some rules 0/0

i/o 1/1 0/0 i

  • 1/0
slide-47
SLIDE 47
  • 8. Assertion-Based Design and Assertion Languages

47 Appendix: Automata and regular expressions

Not all words (e.g., 00.01) are observable in the example machine

Regular expressions can be used to characterize the

  • bservable words of a machine

 For instance the regular expression [00* 11 10* 00]*  For instance, the regular expression [00 .11.10 .00] denotes all observable traces of the Mealy automaton

00

0/0 i/o 1/1 0/0 i

  • [00*.11.10*.00]*

1/0

slide-48
SLIDE 48
  • 8. Assertion-Based Design and Assertion Languages

48 Appendix: Automata and regular expressions

Constructs of regular expressions  . Concatenation  * Kleene‘s repetition operator (zero or arbitrary number

  • f times)

 | Alternative  | Alternative – Example: letter = {a, ..., z}, cipher = {0, ..., 9}, symbol = {-, _}, ampersand = {@} dot = { } ampersand = {@}, dot = {.}, name = {letter}.{letter | cipher | symbol}* simple e-mail address = name ampersand name {dot name}* name.ampersand.name.{dot.name} eveking@rs.tu-darmstadt.de

The regular expression distinguishes between the

  • bservable and non-observable traces of a system

 It h t i th th l t b h i f th  It characterizes, thus, the complete behaviour of the automaton

slide-49
SLIDE 49
  • 8. Assertion-Based Design and Assertion Languages

49 Appendix: Automata and regular expressions

Based on a regular expression, we can also construct a device (monitor) which checks the correct behavior of the Mealy automaton Mealy automaton

The device is called a Deterministic Finite Acceptor (DFA)

00 01 10 11 00

  • 01

DFA

io 0/0 10 01 11 i/o 1/1 0/0 i

  • 1/0
slide-50
SLIDE 50
  • 8. Assertion-Based Design and Assertion Languages

50 Appendix: Automata and regular expressions

A Determinstic Finite Acceptor (DFA):  Has a starting state  Has a starting state  Has no outputs!  Has two disjoint classes of (externally visible) states: accepting (green) and non accepting (pink) states accepting (green) and non-accepting (pink) states  Receives letters of some alphabet A as input (e.g., A = {00,10,11} in our example)  "Accepts" a finite word W over A iff the DFA is started with the first letter of W and the DFA is in an accepting state at the last letter of W  For instance, the word 00.00.11.10.10.10.00.11 is accepted by the DFA above  The word 00 01 is not accepted  The word 00.01 is not accepted  For every regular expression, a DFA can be constructed so that the the DFA is in an accepting state iff the word is characterized by the regular expression is characterized by the regular expression

slide-51
SLIDE 51
  • 8. Assertion-Based Design and Assertion Languages

51 Appendix: Automata and regular expressions

The DFA associated with a Mealy-machine is particularly easy to construct  All t t f th M l hi h di  All states of the Mealy-machine have corresponding accepting states in the DFA  There is a unique non-accepting state q p g  All "wrong" (illegal, impossible) behaviours lead to this "sink" state

00 01 11 00 01 10

  • DFA

io 0/0 00 01 11 i/o

DFA

1/1 0/0 10 i

  • 1/0