Abstract

The ability to analyze a finite state machine (fsm) hasalways been desired by hardware designers, since an un-analyzed fsm is clearly prone to design bugs. Unfortu-nately, there are too many ways to represent (code) anfsm. It is almost impossible for a tool to identify all possi-ble fsm coding styles. In our department, at Cisco, wehave a standardized fsm coding style. The standard fsmcoding style allows us to easily extract an fsm. Theextracted fsm is then fed to various tools for analysis: fsmreachability property, fsm coverage, and automatic fsmbubble diagram drawing. This paper will show our stan-dard fsm coding style, how fsms are extracted, and a wellknown algorithm that is used to study the reachabilityproperty. Then we will show how to monitor the fsm tran-sition coverage and also introduce a tool to automati-cally draw an fsm bubble diagram from the extracted fsm.

Introduction

The ability to analyze a finite state machine (fsm) hasalways been desired by hardware designers, since an un-analyzed fsm is clearly prone to design bugs. Extractingan fsm from Verilog code is one of the hardest tasks.There are too many ways to represent (code) an fsm. It isalmost impossible for a tool to identify all possible fsmcoding styles.

Once an fsm is identified, the commonly asked questionsare:

• Is there a way to reach some states from a state?• Is a state a terminal state?• Have I tested every fsm transition?• Is it possible to draw an fsm bubble diagram auto-

matically?

The above questions are easy to answer once a finite state

machine is extracted from the Verilog code. The fsm canthen be fed to various tools (including some commercialCAE tools) to conduct analysis.

It is impractical for anyone to specify the fsm in morethan one format, i.e. in Verilog code and a tool recogniz-able format. This method is prone to mistakes. Further-more, engineers do not have the time and patience tocode the same fsm multiple times. In an attempt toaddress this problem, our department has adopted a Ver-ilog fsm coding style.

Section 2 discusses the Verilog fsm coding style we useand how we extract fsms. Section 3 presents a wellknown reachability algorithm which is used for static verification. Section 4 discusses fsm coverage: dynamic ver-ification. Section 5 discusses a tool that is used to drawan fsm bubble diagram: visual verification. Appendix Adescribes the fsm analysis tool commands. Appendix Bshows a real example.

Coding Style and fsm Extraction

To overcome the fsm extraction problem, we have stan-dardized our fsm coding style. After careful evaluation,we have decided to usecase Verilog construct to repre-sent the fsm transitions. All states must be declared in aparameter construct before they can be used. Statevariables must be declared as current and/or next statevariables.

The following shows a simple finite state machine [5]. Itdetects whether theserial input signal has a 101sequence. If a 101 sequence is detected, it setsfound_101output signal to 1.

module FSM(found_101, serial, clk,reset);

output found_101;

Practical FSM Analysis for Verilog

Tsu-Hua WangCisco Systems, Inc.

170 West Tasman DriveSan Jose, CA 95134-1706

tsuhua@cisco.com

Thomas EdsallCisco Systems, Inc.

170 West Tasman DriveSan Jose, CA 95134-1706

edsall@cisco.com

input serial, clk, reset;reg found_101;parameter [1:0]

//cisco_fsm FSM declareS0 = 0,S1 = 1,S2 = 2;

reg [1:0] nextState;//cisco_fsm FSM next_state

reg [1:0] currentState;//cisco_fsm FSM current_state

always @(reset or serial orcurrentState)

beginfound_101 = 0;nextState = currentState;

if (reset)nextState = S0;

else begincase (currentState)

S0: if (serial == 1) begin

nextState = S2; endS2:

if (serial == 0) beginnextState = S1;

end else beginnextState = S0;

endS1: begin

nextState = S0;if (serial == 1) begin

found_101 = 1;end

endendcase

endend

always @(posedge clk)currentState <= nextState;

endmodule

The//cisco_fsmfsmNamedeclare must be used to spec-ify state definitions since there can be manyparame-ter declarations. This directive is required immediatelyafter the key wordparameter and before the state def-initions. (Note, there is no space between// andcisco_fsm.) Similarly, //cisco_fsmfsmName [next_stateandcurrent_state] are required to specify the current and

next state variables.ThefsmExtract extracts the following fsm from the FSMVerilog module and creates the fileFSM_FSM.fsm.

>module: FSM 884759194l>fsm: FSM>current_state: currentState>next_state: nextState>states: 3

S0 0S1 1S2 2

>transitions* S0 Cond labels: 1S0 S2 Cond labels: 2S0 S0 Cond labels:S2 S1 Cond labels: 3S2 S0 Cond labels: 4S1 S0 Cond labels: 5

>end: FSM FSM

The file name is composed of the module name and thefsm name. The file contains: the module name, the timestamp, the fsm name, the current and next state variablenames, (stateName, value) tuples, and a list of state tran-sitions associated with condition labels.

The state transition conditions are stored in the conditionfile. The contents ofFSM_FSM.cond is as follows:

>module: FSM>conditions

1. (reset)2. !(reset) && (serial == 1)3. !(reset) && (serial == 0)4. !(reset) && !(serial == 0)5. !(reset)

Static Verification: Reachability andTerminal State

The reachability property is used to study whether a setof states can be reached from a given state by traversingsome state transition arcs. For FSM, it is obvious thatevery state is reachable from every other state. However,with a complex finite state machine (say 10s of states), itis not so obvious to observe the fsm reachability prop-erty.

Fortunately, there is a remarkably simple way to studythe reachability property. First, we transform the statetransitions into an adjacency matrix. Table 1 shows an

adjacency matrix.

An entry is set to 1 if there is a transition (e.g. S1->S0,i.e. <row 2, column 1>). The entry is set to 0 if there is notransition. Note, an Si->Sj transition does not automati-cally imply the Sj->Si is a valid transition. In otherwords, the matrix is not a symmetry matrix.

With an adjacency matrix, the reachability property canbe easily studied by computing the transitive closure ofthe adjacency matrix. The transitive closure is computedas follows:

for (y = 0; y < V; ++y)for (x = 0; x < V; ++x)

if (m[x, y] == 1)for (j = 0; j < V; ++j)

if (m[y, j] == 1)m[x, j] = 1;

where V is the number of states, and the size of the adja-cency matrix, m, is VxV. Table 2 shows the transitive clo-sure matrix of Table 1.

It says that S3 (column 4) is reachable from S0 (row 1)via S0->S2->S3. S0 (column 1) is not reachable from S3(row 4) since the (S3, S0) is 0.

The transitive closure matrix [8] also allows us to iden-tify the terminal states. A state, S, is aterminal state ifthere is no state transition from S or the only transition isto itself (S->S). Once an fsm enters aterminal state, thefsm will stay in that state until areset or some extraordi-nary events occur. For the following adjacency matrix:

the transitive closure matrix is showing in Table 4. It

shows that S3 (row 4) is aterminal state since there is notransition from S3 to any other state.

Dynamic Verification: fsm Coverage

Verilog code coverage [7] has become a standard verifi-cation tool. There are several commercial tools on themarket [4]. However, the existing coverage tools are stillin an infant stage. They are only able to check whether aparticular block has been executed and whether expres-sions are executed.

The cisco_fsm coverage is a first step towards functionalcoverage. It monitors the fsm transitions and generatesthe report. To monitor the fsm transitions, the cisco_fsmmonitor code (Verilog PLI [1,2,6]) must be tied togetherwith a Verilog simulator core. Figure 1 shows a simula-tion environment.

S0 S1 S2 S3

S0 0 1 1 0

S1 1 0 0 0

S2 0 0 0 1

S3 0 0 0 1

Table 1: An adjacency matrix.

S0 S1 S2 S3

S0 1 1 1 1

S1 1 1 1 1

S2 0 0 1 1

S3 0 0 1 1

Table 2: Transitive closure matrix of Table 1.

S0 S1 S2 S3

S0 0 1 0 0

S1 0 0 1 1

S2 1 0 0 1

S3 0 0 0 0

Table 3: 4x4 adjacency matrix.

S0 S1 S2 S3

S0 1 1 1 1

S1 1 1 1 1

S2 1 1 1 1

S3 0 0 0 0

Table 4: 4x4 transitive closure matrix.

Verilogsimulator

core

cisco_fsmmonitor

PLI

fsmSim

design.v

simulationoutput

newfsm

coverage

fsmcoverage

Figure 1. fsmSim simulation

The extra inputs to the newly createdfsmSim are fsm filesthat are either created byfsmExtract or the previous fsmcoverage runs. Upon the$finish event,fsmSim createsnew (cumulative) coverage files by overwriting the previ-ous ones.

During the simulation,fsmSim keeps track of everyinstance’s fsm transitions. ThefsmSim displays a warn-ing message if the fsm takes an illegal transition. Theillegal transitions are transitions which are not specifiedin the fsm file.

On$finish event,fsmSim appends instance coveragecounts to the fsm files. The following shows a sample ofthe coverage file:

1. >module: anFsm2 >current_state: p_st3. >next_state: n_st4. >states: 45. IDLE 06. EBRX 17. ...8. >transitions9. IDLE EBRX10. EBRX DATRX11. ...12. * IDLE13. >end: anFsm14. >instance: top.l1_1.l2_0.l3_0.anFsm_inst15. 0 28 4 0 24 24 0 0 0 0 016. >instance: top.l1_2.l2_0.l3_1.anFsm_inst17. 0 0 0 0 0 0 0 0 0 0 0

Two >instance lines (14 and 16) say that there are twoinstances of the moduleanFsm. The coverage counts linefollows each>instance. On line 15, the numbers 28, 4,and 24 mean that some state transitions have occurred 28,4, and 24 times. The coverage counts can be accumulatedover the multiple simulation sessions.

ThefsmRpt takes the above coverage file as input andgenerates a coverage report file,module_fsm.rpt .Figure 2. shows a coverage report file’s contents.

The transition coverage table shows the state transitioncounts for every instance. The self loop transition is notmonitored since the simulator is unable to capture suchan event. Furthermore, *->S (any state to S) is notreported. For example, *->S occurs ifreset occurs.

Visual Verification: fsm Bubble Diagram

There is a wonderful tool calleddot [3] from AT&T BellLaboratories which can be used to automatically draw asophisticated fsm bubble diagram. The authors encour-age readers to download this tool from http://www.research.att.com/sw/tools/graphviz

To draw an fsm bubble diagram, one would have to trans-form the extracted fsm todot’s input format. The utilityfsm2dot convertsfsmFile.fsm to dot input format asshown in Figure 3. The following AT&Tdot command is

>module: anFsm>current_state: p_st>next_state: n_st>states: 4

IDLE = 0, EBRX = 1, DATRX = 2,PAUSE = 3

>transition coverage:i0 i1---------

IDLE -> EBRX 28 0EBRX -> IDLE 4 0EBRX -> DATRX 24 0

...>NOTE:

1. Instances:i0: top.l1_1.l2_0.l3_0.anFsm_insti1: top.l1_2.l2_0.l3_1.anFsm_inst

2. Loops (e.g. S->S) are not monitored. A simu-lator cannot trigger this kind of event.

3. Any state to S (* -> S) is not monitored(reported).

Figure 2. An fsm coverage report.

digraph anFsm {node [shape = circle];size = “8,7”;IDLE -> IDLE;IDLE -> EBRX;EBRX -> EBRX;EBRX -> IDLE;EBRX -> DATRX;DATRX -> DATRX;DATRX -> IDLE;DATRX -> PAUSE;PAUSE -> PAUSE;PAUSE -> IDLE;PAUSE -> DATRX;“*” -> IDLE;

}

Figure 3. fsm todot format.

invoked

dot -Tps FSM_FSM.dot -o fsm.ps

to produce FSM’s bubble diagram in Postscript. Figure 4shows the FSM bubble diagram.

Conclusion

Without too much trouble, an fsm can be extracted if adesign conforms to a standard Verilog coding style. Theextracted fsm is represented in a simple textual formatwhich can be easily read by many fsm analysis tools.

This paper has presented how to perform an fsm reach-ability study. We also presented the notion of terminalstates and how to detect them:static verification. Weshowed an fsm coverage technique:dynamic verification.The coverage report can be used to measure the qualityof tests and designs. An fsm bubble diagram drawing toolis introduced:visual verification. The fsm bubble dia-gram is an important vehicle in our design cycle. It is apart of our documentation and review process. We visu-ally verify the bubble diagram to ensure the correctnessof the fsm.

Acknowledgments

The authors would like to thank Cisco Systems’ manage-ment for their support, and the Cisco engineering teamswho have supplied many fsm test cases. Finally, thanksto Tooru Ozeki (SUN Microsystems) who introduced usto dot!

References

1. Cadence Reference Manuals.

2. IEEE 1364, Verilog Hardware Description LanguageReference Manual.

3. Koutsofios, E. and North, S.,Drawing graphs withdot, AT&T Bell Laboratories.http://www.research.att.com/sw/tools/graphviz

4. Maniwa, R.T.,Focus Report: Design Verification,integrated system design, November 1997, p. 48.

5. Synopsys Reference Manuals.

6. Viewlogic VCS Reference Manuals.

7. Wang, T.-H. and Tan, C. G.,Practical Code Cover-age for Verilog, 4th International Verilog HDL Con-ference, 1995, 99-104.

8. Warshall, S.,A Theorem on Boolean Matrices, J.ACM, Vol. 9, Jan. 1962, 11-12.

A. Appendix: Tools.

Readers can obtaincisco_fsm on a limited basis. One canrequest a copy by email to tsuhua@cisco.com with thesubject line “cisco_fsm request”.

A.1. fsmExtract.

The parserfsmExtract extracts the finite state machinesfrom Verilog files. The fsms must conform to the codingstyle as discussed in Section 2. Furthermore, an fsm mustbe completely defined within a module. The command isas follows

$FSM_HOME/bin/fsmExtract [-dirdirName] verilog_fsm_file_list

It createsmoduleName_fsmName.fsm file for everyfsm that is defined in the module. It will overwrite anyexistingmoduleName_fsmName.fsm . With -dirdirName , the fsm files are written to the directorydirName . Otherwise, the fsm files are written to thecurrent directory.

*

S0

1

S2

2 4

S1

3

5

Figure 4. FSM bubble diagram.

A.2. fsmReach.

ThefsmReach analyzes the finite state machines and dis-plays the adjacency and transitive closure matrices. Thecommand is as follows:

$FSM_HOME/bin/fsmReach -dir dirName$FSM_HOME/bin/fsmReach fsmFile.fsm

The first command will analyze every finite statemachine, i.e files with the suffix .fsm , in the directory.The second command only analyzes the given finite statemachine.

A.3 fsm Coverage.

Two steps are required: create the simulator and simu-late. For the VCS simulator, the following command isrequired:

vcs -P $FSM_HOME/lib/fsmVCS.plitab$FSM_HOME/lib/fsmCiscoVCS.o ...

For the Cadence Verilog-XL simulator, you have to runvconfig , thencr_vlog and so on. In thecr_vlogfile, you have to includefsmCiscoXL.o to be linkedinto the Verilog simulator. One also has to modifyver-iuser.c to include

extern int cisco_fsmCoverageCalltf();extern int cisco_fsmCoverageMisctf();

and

{usertask, 0,0,0,cisco_fsmCoverageCalltf,cisco_fsmCoverageMisctf,“$cisco_fsmCoverage”, 1},

For simulation, one must call the fsm coverage task,$cisco_fsmCoverage . It is advised that one places$cisco_fsmCoverage in the beginning of the Ver-ilog source code. The following shows an example:

module cisco_fsm;initial $cisco_fsmCoverage;

endmodule... all other modules ...

Assume we have builtfsmSim, one can invoke it as fol-lows:

fsmSim +cisco_fsm+dir+fsmDir ...

fsmSim +cisco_fsm+file+fsmF.fsm ...With +cisco_fsm+dir+fsmDir , fsmSim preparesevery fsm, i.e files with the suffix .fsm, in thefsmDirdirectory to conduct coverage.FsmSim only conductscoverage onfsmF.fsm if +cisco_fsm+file+fsmF.fsm is specified.

A.4. fsm Report.

The commands are

$FSM_HOME/bin/fsmRpt -dir fsmDir$FSM_HOME/bin/fsmRpt fsmFile.fsm

with -dir fsmDir , fsmRpt generates report files withthe suffix.rpt for every fsm in thefsmDir directory.On the other hand, onefsmFile.rpt is generated ifonly onefsmFile.fsm is supplied.

A.5 fsm Bubble Diagram.

The command

$FSM_HOME/bin/fsm2dot -dir fsmDir$FSM_HOME/bin/fsm2dot fsmFile.fsm

with -dir fsmDir , fsm2dot generatesdot files forevery fsm in thefsmDir directory. Otherwise,fsm-File.dot is generated if only onefsmFile.fsm issupplied.Dot files are then supplied to AT&T’sdotcommand to produce diagrams. For example, to generatea Postscript bubble diagram file, one issues the followingcommand:

$ATT_HOME/bin/dot -Tps fsmFile.dot-o fsm.ps

B. A Real Example.

Figure 5 and Figure 6 show an example which has beenprocessed by cisco_fsm tools. The size of the Verilog fsmmodule is about 1000 lines. There are 15 states and 44transitions. There are 74 transition conditions.

S0 2,3,4

S12

1

S11

5,6,7,8,9

S1

13,14

53

54,55,56,57

58,59

S13

66,67

51

50

52

17

S2

15

S3

1618

19

S4

2022

21

23,24,25

32,33

S5

30

S8

31

36

S6

34

S7

35

44

S9

42

S10

43

39

37

38

40

4147

45

46

48

49

69

S14

68

72

73

70,71

*

74

Figure 5. A real fsm example.

1. (cond1) 2. !(cond1) && (!send_en) 3. !(cond1) && !(!send_en) && (<{c1,c2,c3,c4,c5} is 5’b00001>) && !(curr) 4. !(cond1) && !(!send_en) && (<{c1,c2,c3,c4,c5} is 5’b00000>) && !(crises) .... 73. !(!int_gnt_l) 74. (!irst50_l)

Figure 6. A real fsm example: conditions.