TAP-FSM

7/28/2019 TAP-FSM

1/39

TAP (TEST ACCESS PORT) CONTROLER STATEMACHINE IMPLEMENTATION

7/28/2019 TAP-FSM

2/39

FSM

INTRODUCTION

At a low level of abstraction, a protocol is often most easily understood as a state

machine. Design criteria can also easily be expressed in terms of desirable or

undesirable protocol states and state transitions. In a way, the protocol state

symbolizes the assumptions that each process in the system makes about the others. It

defines what actions a process is allowed to take, which events it expects to happen,

and how it will respond to those events. The formal model of a communicating finite

state machine plays an important role in three different areas of protocol design:

formal validation, protocol synthesis, and conformance testing. This chapter

introduces the main concepts. First the basic finite state machine model is discussed.

There are several, equally valid, ways of extending this basic model into a model for

communicating finite state machines. There exist many variations of the basic finite

state machine model. Binary encoding, Gray encoding and Gray encoding.

7/28/2019 TAP-FSM

3/39

Mealy and Moore models are the basic models of state machines.

1. Moore machine :A state machine which uses only Entry Actions, so that its output depends on

the state, is called a Moore model.

2. Mealy machine:A state machine which uses only Input Actions, so that the output depends on

the state and also on inputs, is called a Mealy model.

The models selected will influence a design but there are no general indications

as to which model is better. Choice of a model depends on the application, execution

means (for instance, hardware systems are usually best realized as Moore models) and

personal preferences of a designer or programmer.

7/28/2019 TAP-FSM

4/39

1. Moore machine :

Figure1: Moore Type Machine

In a Moore machine the outputs depend only on the present state as shown inFigure 1.

A combinational logic block maps the inputs and the current state into thenecessary flip-flop inputs to store the appropriate next state just like Mealy

machine.

However, the outputs are computed by a combinational logic block whoseinputs are only the flip-flops state outputs.

The outputs change synchronously with the state transition triggered by theactive clock edge.

7/28/2019 TAP-FSM

5/39

2. Mealy machine:

Figure2: Mealy Type Machine

In a Mealy machine, the outputs are a function of the present state and thepresent input.

Accordingly, the outputs may change asynchronously in response to anychange in the inputs.

7/28/2019 TAP-FSM

6/39

Comparison of the Two Machine Types

Consider a finite state machine that checks for a pattern of 10 and assertslogic high when it is detected.

The state diagram representations for the Mealy and Moore machines areshown in Figure 3.

The state diagram of the Mealy machine lists the inputs with their associatedoutputs on state transitions arcs.

The value stated on the arrows for Mealy machine is of the form Zi/Xi whereZi represents input value and Xi represents output value.

A Moore machine produces a unique output for every state irrespective ofinputs.

Accordingly the state diagram of the Moore machine associates the output withthe state in the form state-notation/output-value.

The state transition arrows of Moore machine are labeled with the input valuethat triggers such transition.

Since a Mealy machine associates outputs with transitions, an output sequencecan be generated in fewer states using Mealy machine as compared to Moore

machine. This was illustrated in the previous example.

Figure 3: Mealy and Moore State Diagrams for '10' Sequence Detector

7/28/2019 TAP-FSM

7/39

Binary Encoded, Gray Encoded or Onehot Encoded:

Common classifications used to describe the state encoding of an FSM are Binary (or

highly encoded), Gray and Onehot.

A binary-encoded FSM design only requires as many flip-flops as are needed to

uniquely encode the number of states in the state machine. The actual number of flip-

flops required is equal to the ceiling of the log-base-2 of the number of states in the

FSM.

A Gray- encoded FSM design requires as many numbers of flip-flops required by the

Binary-encoding. But the state transitions in the Gray-encoding differ from that ofbinary encoding. The state variation between consecutive flip-flops differs.

An onehot FSM design requires a flip-flop for each state in the design and only one

flip-flop (the flip-flop representing the current or "hot" state) is set at a time in a

onehot FSM design. For a state machine with 9-16 states, a binary FSM only requires

4 flip-flops while a onehot FSM requires a flip-flop for each state in the design (9-16

flip-flops).

7/28/2019 TAP-FSM

8/39

1. Binary Encoding :In a binary encoding scheme, the relationship between the number of state variables

(q) and number of states (n) is given by the equation:

q=log 2 (n)

With this formula, one can easily determine the minimum number of state variables

required for a binary-encoded state machine. Clearly, the number of flip-flops used is

equal to the number of state variables (q). In this technique, the states are assigned in

binary sequence where the states are numbered starting from binary 0 and up.

For example, in a 4-state machine, the state assignment is done as shown below;

Y1 Y0

State1= 0 0State2= 0 1

State3= 1 0

State4= 1 1

Why binary encoding?

Binary encoding uses fewer flip-flops/registers than one-hot encoding. For example,

binary encoding requires only seven (flip-flops) registers to implement a 100-state

machine while a one-hot encoding needs 100 flip-flops. Binary encoding uses the

minimum number of state variables (flip-flops) to encode a machine since the flip-

flops are maximally utilized. As a result, it generally increases the amount of

combinatorial logic because more combinatorial logic is required to decode each state.

Therefore, binary encoding is implemented more efficiently when using PLAs and

CPLDs. These devices have wider gates and a large amount of combinatorial logic per

register. It is usually the preferred method when implementing machines that arefewer than 8 states. Their wide AND-architecture allows any number of state

variable (bits) to be included in each product term with no speed (or area) penalty.

The disadvantages of using a binary encoded FSM include the fact that more than one

bit can flip at any time and can result in a glitch (hazard) especially in design of

counters. It also requires a more complex decoding logic to determine the present

state. If power consumption is an issue, then this technique may not be suitable since

the more registers/flip-flop changes, the more power the device consumes.

7/28/2019 TAP-FSM

9/39

Figure4: Binary-encoding FSM

2. Gray Code Assignment:Gray code assignment is a state assignment in which consecutive states codes onlydiffer by one bit (adjacent). In other words, only one flip-flop changes at a time when

changing consecutive states. In this encoding, the number of flip-flops (register) used

is also determined by:

Number of state variables = number of flip-flops = log 2 (number of states)

An example of a 3-bit gray code:

Y3 Y2 Y1

State1= 0 0 0

State2= 0 0 1

State3= 0 1 1

State4= 0 1 0

State5= 1 1 0

7/28/2019 TAP-FSM

10/39

Why gray code?

Gray code uses the same number of register (flip-flops) as the binary coding technique

and the decoding logic can also be as complex if not more. Therefore, gray code

assignment is also ideal for PLA and CPLD applications since they have wide gatesand a large amount of combinatorial logic per register. Gray code is highly

recommended in PLA and CPLD applications when designing for low power

requirement. One approach to low power design is to choose a state assignment that

diminishes (minimizes) the switching activity of state transitions. The ideal case

would be if only one state variable changes in each possible transition. Gray encoding

has minimal switching between consecutive states. After choosing the gray state

(assignment) encoding, then further improvements can be done in order to reduce the

area of the combinatorial logic involved and thus minimizing power consumption. The

resulting code determines the register configuration as well as size and structure of the

combinational circuit.

In general, the performance of a highly encoded state machine (e.g. Gray or Binary

encoded) implemented in an FPGA device drops as the number of states grows

because of the wider and deeper decoding that is required for each additional state.

CPLDs are less sensitive to this problem because they allow a higher fan-in.

Figure5: gray-encoding FSM

7/28/2019 TAP-FSM

11/39

3. One-Hot Encoding :In the one-hot encoding (OHE) only one bit of the state variable is 1 or hot for

any given state. All other state bits are zero. (See Table 1) Therefore, one flip-flop

(register) is used for every state in the machine i.e. n states uses n flip-flops. Usingone-hot encoding, the next-state equations can be derived easily from state diagrams.

State decoding is simplified, since the state bits themselves can be used directly to

indicate whether the machine is in a particular state. In addition, with a one-hot

encoded state machine, the inputs to the state bits are often simply the functions of

other state bits. Often times, no state decoding is necessary, and state encoding can

only require the OR-ing of state bits.

Why use One Hot Code?

One-hot encoding (OHE) is better suited for use with the fan-in limited and flip-flop-

rich architectures of the higher gate count field-programmable gate arrays (FPGAs),

such as offered by Xilinx, Actel, and others. OHE (One-hot encoding) maps very

easily in these architectures. This is because OHE (One-hot encoding) requires a

larger number of flip-flops. It offers a simple and easy-to-use method of generating

performance optimized state-machine designs because there are few levels of logic

between flip-flops. One-hot state machines are typically faster. Speed is independent

of the number of states, and instead depends only on the number of transitions into aparticular state. A highly encoded machine may slow dramatically as more states are

added. In such cases, one does not have to necessarily worry about finding an

optimal state (assignment) encoding.

This is particularly beneficial as the machine design is modified. What is optimal

for one design may no longer be best (optimal) if a few states are added and some

states are changed. One-hot is equally optimal for all machines. One-hot coded

machines are easy to design. Schematics can be captured and HDL code can be

written directly from the state diagram without first requiring the generation of a statetable. Finally, they are easily synthesize-able using VHDL or Verilog.

In some cases, the one-hot method may not be the best encoding technique for a state

machine implemented in an FPGA. For example, if the number of states is small, the

speed advantages of using the minimum amount of combinatorial logic may be offset

by delays resulting from inefficient CLB (configurable logic blocks) use, e.g. a Xilinx

device. This assignment allows the designer to create state machine implementations

that are more efficient in FPGA architectures in terms of area and logic depth (speed).

FPGA have plenty of registers but the LUTs are limited to few bits wide. One-hot

7/28/2019 TAP-FSM

12/39

increases the flip-flop usage (one per state) and decreases the width of combinatorial

logic. It makes it easy to decode the next state, resulting in large FSMs. [5] And

finally, since one hot code state assignment reduces the area (area optimization) by

using less logic gates, it consumes less power.

Figure6: Onehot-encoding FSM

State One-Hot code Binary code Gray code

S0 00001 000 000

S1 00010 001 001

S2 00100 010 011S3 01000 011 010

S4 10000 100 110

Table1.An example of state Encoding for a 4 state Machine

7/28/2019 TAP-FSM

13/39

Registered FSM Outputs (Good Style):

Registering the outputs of an FSM design insures that the outputs are glitch-free and

frequently improves synthesis results by standardizing the output and input delayconstraints of synthesized modules.

FSM outputs are easily registered by adding a third always sequential block to an

FSM module where output assignments are generated in a case statement with case

items corresponding to the next state that will be active when the output is clocked.

Figure7: Registered FSM outputs.

Example:

module fsm_cc4_2r

(output reg gnt,

input dly, done, req, clk, rst_n);parameter [1:0] IDLE = 2'b00,

BBUSY = 2'b01,

BWAIT = 2'b10,

BFREE = 2'b11;

reg [1:0] state, next;

always @(posedge clk or negedge rst_n)

if (!rst_n) state

7/28/2019 TAP-FSM

14/39

case (state)

IDLE : if (req) next = BBUSY;

else next = IDLE;

BBUSY: if (!done) next = BBUSY;

else if ( dly) next = BWAIT;else next = BFREE;

BWAIT: if (!dly) next = BFREE;

else next = BWAIT;

BFREE: if (req) next = BBUSY;

else next = IDLE;

endcase

end


if (!rst_n) gnt

7/28/2019 TAP-FSM

15/39

FSM Coding Goals:

To determine what constitutes an efficient FSM coding style, we first need to identify

HDL coding goals and why they are important. After the HDL coding goals have beenidentified, we can then quantify the capabilities of various FSM coding styles.

The following HDL coding goals as important when doing HDL-based FSM design:

The FSM coding style should be easily modified to change state encodings and FSM

styles.

The coding style should be compact.

The coding style should be easy to code and understand.

The coding style should facilitate debugging.

The coding style should yield efficient synthesis results.

There are many ways to code FSMs including many very poor ways to code

FSMs.

Combinational always blocks are always blocks that are used to codecombinational logic functionality and are strictly coded using blockingassignments. A combinational always block has a combinational sensitivity list,

a sensitivity list without "posedge"or"negedge"Verilog keywords.

Sequential always blocks are always blocks that are used to code clocked orsequential logic and are always coded using nonblocking assignments. A

sequential always block has an edge-based sensitivy list.

7/28/2019 TAP-FSM

16/39

Two Always Block FSM Style (Good Style):

One of the best Verilog coding styles is to code the FSM design using two always

blocks, one for the sequential state register and one for the combinational next-state

and combinational output logic.

Important coding style notes:

Parameters are used to define state encodings instead of the Verilog `define macro

definition construct [3]. After parameter definitions are created, the parameters are

used throughout the rest of the design, not the state encodings. This means that if an

engineer wants to experiment with different state encodings, only the parameter values

need to be modified while the rest of the Verilog code remains unchanged.

Declarations are made forstate and next (next state) after the parameter assignments.

The sequential always block is coded using nonblocking assignments.

The combinational always block sensitivity list is sensitive to changes on the state

variable and all of the inputs referenced in the combinational always block.

Assignments within the combinational always block are made using Verilog

blocking assignments.

The combinational always block has a default next state assignment at the top of the

always block.

Default output assignments are made before coding the case statement (this

eliminates latches and reduces the amount of code required to code the rest of the

outputs in the case statement and highlights in the case statement exactly in which

states the individual output(s) change).

In the states where the output assignment is not the default value assigned at the top

of the always block, the output assignment is only made once for each state.

There is an if-statement, an else-if-statement or an else statement for each transition

arc in the FSM state diagram. The number of transition arcs between states in the FSM

state diagram should equal the number of if-else-type statements in the combinational

always block.

7/28/2019 TAP-FSM

17/39

For ease of scanning and debug, all of the next assignments have been placed in a

single column, as opposed to finding next assignments following the contour of the

RTL code.

Example:module fsm_4states

(output reg gnt,

input dly, done, req, clk, rst_n);

parameter [1:0] IDLE = 2'b00,

BBUSY = 2'b01,

BWAIT = 2'b10,BFREE = 2'b11;

reg [1:0] state, next;


if (!rst_n) state

7/28/2019 TAP-FSM

18/39

gnt = 1'b1;

if (!dly) next = BFREE;

else next = BWAIT;

end

BFREE: if (req) next = BBUSY;

else next = IDLE;

endcase end endmodule

Making default next equal all X's assignment:

Placing a default next state assignment on the line immediately following the always

block sensitivity list is a very efficient coding style. This default assignment is

updated by next-state assignments inside the case statement. There are three types of

default next-state assignments that are commonly used:

(1) Next is set to all X's,

(2) Next is set to a predetermined recovery state such as IDLE or

(3) Next is just set to the value of the state register.

By making a default next state assignment of X's, pre-synthesis simulation models

will cause the state machine outputs to go unknown if not all state transitions have

been explicitly assigned in the case statement. This is a useful technique to debug state

machine designs, plus the X's will be treated as "don't cares" by the synthesis tool.

Some designs require an assignment to a known state as opposed to assigning X's.

Examples include: satellite applications, medical applications, designs that use the

FSM flip-flops as part of a diagnostic scan chain and some designs that are

equivalence checked with formal verification tools. Making a default next state

assignment of either IDLE or all 0's typically satisfies these design requirements and

making the initial default assignment might be easier than coding all of the explicit

next-state transition assignments in the case statement.

7/28/2019 TAP-FSM

19/39

One Always Block FSM Style (Avoid This Style!):

One of the most common FSM coding styles in use today is the one sequential always

block FSM coding style. This coding style is very similar to coding styles that were

popularized by PLD programming languages of the mid-1980s, such as ABEL. Formost FSM designs, the one always block FSM coding style is more verbose, more

confusing and more error prone than a comparable two always block coding style.

Important coding style notes:

Parameters are used to define state encodings, the same as the two always

block coding style.

A declaration is made for state. Not for next.

There is just one sequential always block, coded using nonblocking

assignments.

The there is still a default state assignment before the case statement, and then

the case statement tests the state variable. Will this be a problem? No, because

the default state assignment is made with a nonblocking assignment, so the

update to the state variable will happen at the end of the simulation time step.

Default output assignments are made before coding the case statement (this

reduces the amount of code required to code the rest of the outputs in the case

statement).

A state assignment must be made for each transition arc that transition to a state

where the output will be different than the default assigned value. For multiple

outputs and for multiple transition arcs Into a state where the outputs change,

multiple state assignments will be required.

The state assignments do not correspond to the current state of the case

statement, but the state that case statement is transitioning to. This is error

prone (but it does work if coded correctly).

Again, for ease of scanning and debug, the all of the state assignments have

been placed in a single column, as opposed to finding state assignments

following the contour of the RTL code.

7/28/2019 TAP-FSM

20/39

All outputs will be registered (unless the outputs are placed into a separate

combinational always block or assigned using continuous assignments). No

asynchronous Mealy outputs can be generated from a Single synchronous

always block.

Note: some misinformed engineers fear that making multiple assignments to

the same variable, in the same always block, using nonblocking assignments, is

undefined and can cause race conditions. This is not true. Making multiple

nonblocking assignments to the same variable in the same always block is defined by

the Verilog Standard. The last nonblocking assignment to the same variable wins!.

Example:

module fsm

(output reg gnt,

input dly, done, req, clk, rst_n);

parameter [1:0] IDLE = 2'd0,

BBUSY = 2'd1,

BWAIT = 2'd2,

BFREE = 2'd3;

reg [1:0] state;always @(posedge clk or negedge rst_n)

if (!rst_n) begin

state

7/28/2019 TAP-FSM

21/39

else if ( dly) begin

state

7/28/2019 TAP-FSM

22/39

Test access port (TAP):

The TAP is a general-purpose port that can provide access to many test support

functions built into a component, including the test logic defined by this standard. It is

composed as a minimum of the three input connections and one output connection

required by the test logic defined by this standard. An optional fourth input connection

provides for asynchronous initialization of the test logic defined by this standard.

The TAP shall include the following connections TCK, TMS, TDI, and TDO.

Where the TAP controller is not reset at power-up as a result of features built

into the test logic, a TRST* input shall be provided.

All TAP inputs and outputs shall be dedicated connections to the component

(i.e., the pins used shall not be used for any other purpose).

Description

Dedicated TAP connections are required to allow access to the full range of

mandatory features of this standard.

Test clock input (TCK):

The test clock input (TCK) provides the clock for the test logic defined by this

standard.

Rules

a) Stored-state devices contained in the test logic shall retain their state indefinitely

when the signal applied to TCK is stopped at 0.

b) Since TCK inputs for many components may be controlled from a single driver,

care should be taken to ensure that the load presented by TCK is as small as possible.

c) Stored-state devices contained in the test logic may retain their state indefinitely

when the signal applied to TCK is stopped at 1.

7/28/2019 TAP-FSM

23/39

Test mode select input (TMS):

The signal received at TMS is decoded by the TAP controller to control test

operations.

a) The signal presented at TMS shall be sampled by the test logic on the risingedge of TCK.

b) The design of the circuitry fed from TMS shall be such that an undriven inputproduces a logical response identical to the application of logic 1.

c) Since the TMS inputs for many components may be controlled from a singledriver, care should be taken to ensure that the load presented by TMS is as

small as possible.

Test data input (TDI):

Serial test instructions and data are received by the test logic at TDI.

a) The signal presented at TDI shall be sampled into the test logic on the risingedge of TCK.

b) The design of the circuitry fed from TDI shall be such that an undriven inputproduces a logical response identical to the application of a logic 1.

c) When data is being shifted from TDI toward TDO, test data received at TDIshall appear without inversion at TDO after a number of rising and falling

edges of TCK determined by the length of the instruction or test data registerselected.

7/28/2019 TAP-FSM

24/39

Test data output (TDO):

TDO is the serial output for test instructions and data from the test logic defined in

this standard.

a) Changes in the state of the signal driven through TDO shall occur only on thefalling edge of TCK.

b) The TDO driver shall be set to its inactive drive state except when the scanningof data is in progress.

Test reset input (TRST*):

The optional TRST* input provides for asynchronous initialization of the TAP

controller.

a) If TRST* is included in the TAP, the TAP controller shall be asynchronouslyreset to the Test-Logic-Reset controller state when a logic 0 is applied to

TRST*.

NOTEAs a result of this event, all other test logic in the component is

asynchronously reset to the state required in the Test-Logic-Resetcontroller state.

b) If TRST* is included in the TAP, the design of the circuitry fed from that inputshall be such that an undriven input produces a logical response identical to the

application of a logic 1.

c) TRST* shall not be used to initialize any system logic within the component.d) To ensure deterministic operation of the test logic, TMS should be held at 1

while the signal applied at TRST* changes from 0 to 1.

7/28/2019 TAP-FSM

25/39

TAP controller state diagram:

Figure8: TAP controller state diagram

A)The value shown adjacent to each state transition in this figure represents thesignal present at TMS at the time of a rising edge at TCK.

B)All state transitions of the TAP controller shall occur based on the value ofTMS at the time of a rising edge of TCK.

c) Actions of the test logic (instruction register, test data registers, etc.) shalloccur on either the rising or the falling edge of TCK in each controller state.

7/28/2019 TAP-FSM

26/39

Timing Actions:

Figure 9: Timing of actions in a controller state

7/28/2019 TAP-FSM

27/39

RTL Implementation:

The RTL Implementation of TAP controller is done in Three-types;

1. Binary-encoding2. Gray-encoding3. Onehot-encoding

The libraries used;

C32_SC_12_CLK_LL

(File:/sw/unicad/C32_SC_12_CLK_LL_C28/[email protected]/libs/C32_SC_12_CLK

_LL_ ss28_0.90V_125C.db)

C32_SC_12_CORE_LL

(File:/sw/unicad/C32_SC_12_CORE_LL_C28/[email protected]/libs/C32_SC_12_CO

RE_LL_ss28_0.90V_125C.db)

C32_SC_12_CORE_LR

(File:/sw/unicad/C32_SC_12_CORE_LR_C28/[email protected]/libs/C32_SC_12_C

ORE_LR_ss28_0.90V_125C.db)

C32_SC_12_CLK_LR

(File:/sw/unicad/C32_SC_12_CLK_LR_C28/[email protected]/libs/C32_SC_12_CLK

_LR_ ss28_0.90V_125C.db)

7/28/2019 TAP-FSM

28/39

For the Area, Timing and power calculations using Design compiler the Clock_period

values are those where the slack is violating.

FSM coding styles Binary-encoding Gray-encoding Onehot-encoding

Clock period values

(Period where the slack

is violating)

0.53 0.55 0.31

Start and end points

Of the module (Critical

path)

Start pointtms

End point

state_reg[3]

Start pointtms

End point

state_reg[1]

Start point

state_reg[12]

End pointupdate_ir

Area of the modules

(Total cell area in m) 64.46400 60.0575600 173.481604

Power consumed

(using DC (Design

compiler) applyingsame constraints on all

three modules) in w.

Dynamic power-

45.962Cell leakage power-

1.3197

Dynamic power-

41.684

Cell leakage power-

1.09

Dynamic power-219.58

Cell leakage power-2.7656

Note: The path in which the analysis done is,

/data/ccore_scratch1/COMMON/MADHU/GENERATOR/OTHER_WORK/*

7/28/2019 TAP-FSM

29/39

The Area, timing and power reports calculate using DC (Design compiler);

Ex: Onehot-encoding reports are shown here;

****************************************Report: area

Desig : fsmVersion: E-2010.12-SP4Date : Mon Mar 26 18:52:01 2012****************************************

Library(s) Used:

C32_SC_12_CLK_LL (File:/sw/unicad/C32_SC_12_CLK_LL_C28/[email protected]/libs/C32_SC_12_CLK_LL_ss28_0.90V_125C.db)

C32_SC_12_CORE_LL (File:/sw/unicad/C32_SC_12_CORE_LL_C28/[email protected]/libs/C32_SC_12_CORE_LL_ss28_0.90V_125C.db)

C32_SC_12_CORE_LR (File:/sw/unicad/C32_SC_12_CORE_LR_C28/[email protected]/libs/C32_SC_12_CORE_LR_ss28_0.90V_125C.db)

C32_SC_12_CLK_LR (File:/sw/unicad/C32_SC_12_CLK_LR_C28/[email protected]/libs/C32_SC_12_CLK_LR_ss28_0.90V_125C.db)

Number of ports: 41Number of nets: 166Number of cells: 147Number of combinational cells: 115Number of sequential cells: 32

Number of macros: 0Number of buf/inv: 49Number of references: 36

Combinational area: 79.315202Noncombinational area: 94.166402Net Interconnect area: undefined (Wire load has zero net area)

Total cell area: 173.481604Total area: undefined1

7/28/2019 TAP-FSM

30/39

Timing report:

****************************************Report: timing

-path full

-delay max-max_paths 1

Design: fsmVersion: E-2010.12-SP4Date : Mon Mar 26 18:52:01 2012****************************************

Operating Conditions: ss28_0.90V_125C Library: C32_SC_12_CORE_LLWire Load Model Mode: enclosed

Startpoint: state_reg[12](rising edge-triggered flip-flop clocked by clk)

Endpoint: update_ir (output port clocked by clk_v)Path Group: clk_vPath Type: max

Des/Clust/Port Wire Load Model Library------------------------------------------------fsm wl_zero C32_SC_12_CORE_LL

Point Incr Path---------------------------------------------------------------------

-----clock clk (rise edge) 0.00 0.00clock network delay (ideal) 0.01 0.01

state_reg[12]/CP (C12T32_LL_SDFPRQX8) 0.00 0.01 rstate_reg[12]/Q (C12T32_LL_SDFPRQX8) 0.06 0.07 fU224/Z (C12T32_LL_CNNOR2X14) 0.02 0.10 rU217/Z (C12T32_LLBR0D8_NAND2X14) 0.01 0.11 fU222/Z (C12T32_LL_CNIVX16) 0.01 0.12 rU190/Z (C12T32_LL_NOR3AX25) 0.04 0.17 rU187/Z (C12T32_LL_NAND4ABX6) 0.03 0.19 fU267/Z (C12T32_LL_CNIVX8) 0.02 0.21 rupdate_ir (out) 0.00 0.21 rdata arrival time 0.21

clock clk_v (rise edge) 0.31 0.31

clock network delay (ideal) 0.01 0.32inter-clock uncertainty 0.00 0.32output external delay -0.12 0.20data required time 0.20---------------------------------------------------------------------

-----data required time 0.20data arrival time -0.21---------------------------------------------------------------------

-----slack (VIOLATED) -0.01

1

7/28/2019 TAP-FSM

31/39

Power report:

****************************************Report : power

-analysis_effort low

Design : fsmVersion: E-2010.12-SP4Date : Mon Mar 26 18:52:01 2012****************************************

Library(s) Used:

C32_SC_12_CLK_LL (File:/sw/unicad/C32_SC_12_CLK_LL_C28/[email protected]/libs/C32_SC_12_CLK_LL_ss28_0.90V_125C.db)

C32_SC_12_CORE_LL (File:/sw/unicad/C32_SC_12_CORE_LL_C28/[email protected]/libs/C32_SC_12_CORE_LL_

ss28_0.90V_125C.db)C32_SC_12_CORE_LR (File:

/sw/unicad/C32_SC_12_CORE_LR_C28/[email protected]/libs/C32_SC_12_CORE_LR_ss28_0.90V_125C.db)

C32_SC_12_CLK_LR (File:/sw/unicad/C32_SC_12_CLK_LR_C28/[email protected]/libs/C32_SC_12_CLK_LR_ss28_0.90V_125C.db)


Design Wire Load Model Library------------------------------------------------fsm wl_zero C32_SC_12_CORE_LL

Global Operating Voltage = 0.9Power-specific unit information:

Voltage Units = 1VCapacitance Units = 1.000000pfTime Units = 1nsDynamic Power Units = 1mW (derived from V,C,T units)Leakage Power Units = 1mW

Cell Internal Power = 250.2178 uW (96%)Net Switching Power = 9.3660 uW (4%)

---------Total Dynamic Power = 259.5839 uW (100%)

Cell Leakage Power = 2.7656 uW

1

7/28/2019 TAP-FSM

32/39

Power Analysis (calculation) using Prime Time:

Library(s) Used: C32_SC_12_CORE_LL

(File:/ssw/unicad/C32_SC_12_CORE_LL_C28/[email protected]/libs/C32_SC_12_C

ORE_LL_ss28_0.90V_125C.db)


Clock period 0.6 0.6 0.6

Total power in w 3.716 3.408 7.910

The power reports of three FSMs are given below,

Binary-Encoding:

****************************************Report: Time Based Power

-verboseDesign: fsmVersion: F-2011.06-SP3Date : Mon Mar 26 14:42:38 2012****************************************

Simulation Periods: 10 ns - 460 ns

Sampling Interval: 0.001 ns

Library(s) Used:

C32_SC_12_CORE_LL (File:

/sw/unicad/C32_SC_12_CORE_LL_C28/[email protected]/libs/C32_SC_12_CORE_LL_ss28_0.90V_125C.db)


7/28/2019 TAP-FSM

33/39

Cell Design Wire_model LibrarySelection_type--------------------------------------------------------------------------------

fsm wl_zero C32_SC_12_CORE_LLlibrary

default

Power-specific unit information:Voltage Units = 1 VCapacitance Units = 1 pfTime Units = 1 nsDynamic Power Units = 1 WLeakage Power Units = 1 W

Attributes

----------i - Including register clock pin internal poweru - User defined power group

Internal switching Leakage TotalPower Group Power Power Power Power (%) Attrs--------------------------------------------------------------------------------io_pad 0.0000 0.0000 0.0000 0.0000 ( 0.00%)memory 0.0000 0.0000 0.0000 0.0000 ( 0.00%)black_box 0.0000 0.0000 0.0000 0.0000 ( 0.00%)clock_network 0.0000 0.0000 0.0000 0.0000 ( 0.00%) i

register 0.0000 0.0000 0.0000 0.0000 ( 0.00%)combinational 8.164e-07 5.539e-07 6.516e-07 2.022e-06 (54.41%)sequential 1.217e-06 2.420e-07 2.345e-07 1.694e-06 (45.59%)

Net Switching Power = 7.959e-07 (21.42%)Cell Internal Power = 2.034e-06 (54.73%)Cell Leakage Power = 8.860e-07 (23.85%)

---------Total Power = 3.716e-06 (100.00%)

X Transition Power = 0.0000Glitching Power = 0.0000

Peak Power = 3.411e-03Peak Time = 200.000

1

7/28/2019 TAP-FSM

34/39

Gray-encoding:


-verbose

Design: fsmVersion: F-2011.06-SP3Date : Mon Mar 26 15:00:53 2012****************************************



Library(s) Used:





default

Power-specific unit information :Voltage Units = 1 VCapacitance Units = 1 pfTime Units = 1 nsDynamic Power Units = 1 WLeakage Power Units = 1 W

Attributes----------

i - Including register clock pin internal poweru - User defined power group

Internal Switching Leakage TotalPower Group Power Power Power Power ( %) Attrs--------------------------------------------------------------------------------io_pad 0.0000 0.0000 0.0000 0.0000 ( 0.00%)memory 0.0000 0.0000 0.0000 0.0000 ( 0.00%)black_box 0.0000 0.0000 0.0000 0.0000 ( 0.00%)clock_network 0.0000 0.0000 0.0000 0.0000 ( 0.00%) iregister 0.0000 0.0000 0.0000 0.0000 ( 0.00%)

combinational 6.725e-07 4.310e-07 7.370e-07 1.840e-06 (54.96%)sequential 1.135e-06 1.643e-07 2.093e-07 1.508e-06 (45.04%)

7/28/2019 TAP-FSM

35/39


---------Total Power = 3.349e-06 (100.00%)

X Transition Power = 0.0000Glitching Power = 0.0000

Peak Power = 3.408e-03Peak Time = 220.000

1

Onehot-encoding:


-verboseDesign: fsmVersion: F-2011.06-SP3Date : Mon Mar 26 15:14:59 2012****************************************



Library(s) Used:





default

Power-specific unit information:Voltage Units = 1 VCapacitance Units = 1 pfTime Units = 1 ns

7/28/2019 TAP-FSM

36/39

Dynamic Power Units = 1 WLeakage Power Units = 1 W

Attributes

----------i - Including register clock pin internal poweru - User defined power group

Internal Switching Leakage TotalPower Group Power Power Power Power ( %) Attrs--------------------------------------------------------------------------------io_pad 0.0000 0.0000 0.0000 0.0000 (0.00%)memory 0.0000 0.0000 0.0000 0.0000 (0.00%)black_box 0.0000 0.0000 0.0000 0.0000 (0.00%)clock_network 0.0000 0.0000 0.0000 0.0000 (0.00%) i

register 0.0000 0.0000 0.0000 0.0000 (0.00%)combinational 1.335e-06 1.294e-06 1.153e-06 3.782e-06 (38.16%)sequential 4.819e-06 1.775e-07 1.131e-06 6.128e-06 (61.84%)


---------Total Power = 9.910e-06 (100.00%)

X Transition Power = 5.383e-08Glitching Power = 2.387e-07

Peak Power = 0.0124Peak Time = 60.000

1

7/28/2019 TAP-FSM

37/39

Comparison between the three coding styles:


Speed Slower Slower (slower than Binary encoding) Faster

power Low Low (Better than Binary encoding) High

Area Low Low ( lower than Binary-encoding) Large

7/28/2019 TAP-FSM

38/39

Conclusion:

There are many ways to code FSM designs. There are many inefficient ways to code

FSM designs! Use parameters to define state encodings. Parameters are constants thatare local to a module. After defining the state encodings at the top of the FSM module,

never use the state encodings again in the RTL code. This makes it possible to easily

change the state encodings in just one place, the parameter definitions, without having

to touch the rest of the FSM RTL code. This makes state-encoding experimentation

easy to do.Use a two always blocks coding style to code FSM designs with

combinational outputs. This style is efficient and easy to code and can also easily

handle Mealy FSM designs. Use a three always block coding style to code FSM

designs with registered outputs. This style is efficient and easy to code. Avoid the one

always block FSM coding style. It is generally more verbose than an equivalent two

always block coding style, output assignments are more error prone to coding

mistakes and one cannot code asynchronous Mealy outputs without making the output

assignments with separate continuous assign statements.

7/28/2019 TAP-FSM

39/39

References:

Finite State Machines in Verilog: UC Berkeley College of Engineering-Document Department of Electrical Engineering and Computer Science -Document Clifford E. Cummings, "Nonblocking Assignments in Verilog Synthesis, Coding

Styles That Kill!," SNUG'2000 Boston (Synopsys Users Group San Jose, CA, 2000)

Proceedings, March 2000. (Also available online at www.sunburst-

design.com/papers).

IEEE Standard Test Access Port and Boundary-Scan Architecture IEEE Std1149.1-2001 (R2008).

Synchronous Finite State Machines; Design and Behavior by Prof. Dr. J. ReichardtProf. Dr. B. Schwarz, University of applied sciences Hamburg DEPARTEMENT OFELECTRICAL ENGINEERING AND COMPUTER SCIENCE.

VCS MX/VCS MXi User Guide Version F-2011.12 December 2011 and Powercompiler User Guide-SNUG.
http://www.sunburst-design.com/papershttp://www.sunburst-design.com/papershttp://www.sunburst-design.com/papershttp://www.sunburst-design.com/papers

TAP-FSM

Documents