TAP (TEST ACCESS PORT) CONTROLER STATE MACHINE IMPLEMENTATION

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.

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.

1. Moore machine :

Figure1: Moore Type Machine In a Moore machine the outputs depend only on the present state as shown in Figure 1.

A combinational logic block maps the inputs and the current state into the necessary flip-flop inputs to store the appropriate next state just like Mealy machine. However, the outputs are computed by a combinational logic block whose inputs are only the flip-flops state outputs.

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

2. Mealy machine:

Figure2: Mealy Type Machine

In a Mealy machine, the outputs are a function of the present state and the present input. Accordingly, the outputs may change asynchronously in response to any change in the inputs.

Comparison of the Two Machine Types Consider a finite state machine that checks for a pattern of 10 and asserts logic high when it is detected. The state diagram representations for the Mealy and Moore machines are shown in Figure 3. The state diagram of the Mealy machine lists the inputs with their associated outputs on state transitions arcs. The value stated on the arrows for Mealy machine is of the form Zi/Xi where Zi represents input value and Xi represents output value. A Moore machine produces a unique output for every state irrespective of inputs. Accordingly the state diagram of the Moore machine associates the output with the state in the form state-notation/output-value. The state transition arrows of Moore machine are labeled with the input value that triggers such transition. Since a Mealy machine associates outputs with transitions, an output sequence can 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

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 flipflops 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 of binary 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).

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 0 State2= 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 flipflops 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 are fewer 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.

Figure4: Binary-encoding FSM

2. Gray Code Assignment:

Gray code assignment is a state assignment in which consecutive states codes only differ 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

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 gates and 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

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. Using one-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-floprich 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 a particular 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 state table. 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

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 S0 S1 S2 S3 S4

One-Hot code 00001 00010 00100 01000 10000

Binary code 000 001 010 011 100

Gray code 000 001 011 010 110

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

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 delay constraints 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 <= IDLE; else state <= next; always @(state or dly or done or req) begin next = 2'bx;

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 always @(posedge clk or negedge rst_n) if (!rst_n) gnt <= 1'b0; else begin gnt <= 1'b0; case (next) IDLE, BFREE: ; // default outputs BBUSY, BWAIT: gnt <= 1'b1; endcase end endmodule

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 been identified, 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 code combinational logic functionality and are strictly coded using blocking assignments. 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 or sequential logic and are always coded using nonblocking assignments. A sequential always block has an edge-based sensitivy list.

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 for state 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.

 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; always @(posedge clk or negedge rst_n) if (!rst_n) state <= IDLE; else state <= next; always @(state or dly or done or req) begin next = 2'bx; gnt = 1'b0; case (state) IDLE : if (req) next = BBUSY; else next = IDLE; BBUSY: begin gnt = 1'b1; if (!done) next = BBUSY; else if ( dly) next = BWAIT; else next = BFREE; end BWAIT: begin

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.

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. For most 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.

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 <= IDLE; gnt <= 1'b0; end else begin state <= 2'bx; gnt <= 1'b0; case (state) IDLE : if (req) begin state <= BBUSY; gnt <= 1'b1; end else state <= IDLE; BBUSY: if (!done) begin state <= BBUSY; gnt <= 1'b1; end

else if ( dly) begin state <= BWAIT; gnt <= 1'b1; end else state <= BFREE; BWAIT: if ( dly) begin state <= BWAIT; gnt <= 1'b1; end else state <= BFREE; BFREE: if (req) begin state <= BBUSY; gnt <= 1'b1; end else state <= IDLE; endcase end endmodule Example 4 - fsm design - one always block style

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.

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 rising edge of TCK. b) The design of the circuitry fed from TMS shall be such that an undriven input produces a logical response identical to the application of logic 1. c) Since the TMS inputs for many components may be controlled from a single driver, 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 rising edge of TCK. b) The design of the circuitry fed from TDI shall be such that an undriven input produces 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 TDI shall 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 register selected.

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 the falling edge of TCK. b) The TDO driver shall be set to its inactive drive state except when the scanning of 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 asynchronously reset 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-Reset controller state. b) If TRST* is included in the TAP, the design of the circuitry fed from that input shall 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.

TAP controller state diagram:

Figure8: TAP controller state diagram A) The value shown adjacent to each state transition in this figure represents the signal 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 of TMS at the time of a rising edge of TCK. c) Actions of the test logic (instruction register, test data registers, etc.) shall occur on either the rising or the falling edge of TCK in each controller state.

Timing Actions:

Figure 9: Timing of actions in a controller state

RTL Implementation:
The RTL Implementation of TAP controller is done in Three-types; 1. Binary-encoding 2. Gray-encoding 3. Onehot-encoding

The libraries used;

C32_SC_12_CLK_LL (File:/sw/unicad/C32_SC_12_CLK_LL_C28/1.1@20111019.0/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/1.1@20111020.2/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/1.1@20111024.0/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/1.1@20111019.0/libs/C32_SC_12_CLK _LR_ ss28_0.90V_125C.db)

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 0.55 Start point tms End point state_reg[1] 60.0575600

Onehot-encoding 0.31 Start point state_reg[12] End point update_ir 173.481604 power- Dynamic power-219.58

Clock period values (Period where the slack 0.53 is violating) Start and end points Start point tms Of the module (Critical End point path) state_reg[3] Area of the modules (Total cell area in m) 64.46400 Power consumed (using DC (Design compiler) applying same constraints on all three modules) in w. Dynamic 45.962 Cell leakage power1.3197

Dynamic power- 41.684

Cell leakage powerCell leakage power- 2.7656 1.09

Note: The path in which the analysis done is, /data/ccore_scratch1/COMMON/MADHU/GENERATOR/OTHER_WORK/*

The Area, timing and power reports calculate using DC (Design compiler); Ex: Onehot-encoding reports are shown here;
**************************************** Report: area Desig : fsm Version: E-2010.12-SP4 Date : Mon Mar 26 18:52:01 2012 **************************************** Library(s) Used: C32_SC_12_CLK_LL (File: /sw/unicad/C32_SC_12_CLK_LL_C28/1.1@20111019.0/libs/C32_SC_12_CLK_LL_ss 28_0.90V_125C.db) C32_SC_12_CORE_LL (File: /sw/unicad/C32_SC_12_CORE_LL_C28/1.1@20111020.2/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/1.1@20111024.0/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/1.1@20111019.0/libs/C32_SC_12_CLK_LR_ss 28_0.90V_125C.db) Number Number Number Number Number Number Number Number of of of of of of of of ports: nets: cells: combinational cells: sequential cells: macros: buf/inv: references: 41 166 147 115 32 0 49 36

Combinational area: Noncombinational area: Net Interconnect area: Total cell area: Total area: 1

79.315202 94.166402 undefined (Wire load has zero net area) 173.481604 undefined

Timing report:
**************************************** Report: timing -path full -delay max -max_paths 1 Design: fsm Version: E-2010.12-SP4 Date : Mon Mar 26 18:52:01 2012 **************************************** Operating Conditions: ss28_0.90V_125C Wire Load Model Mode: enclosed Library: C32_SC_12_CORE_LL

Startpoint: state_reg[12] (rising edge-triggered flip-flop clocked by clk) Endpoint: update_ir (output port clocked by clk_v) Path Group: clk_v Path 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.00 clock network delay (ideal) 0.01 0.01 state_reg[12]/CP (C12T32_LL_SDFPRQX8) 0.00 0.01 r state_reg[12]/Q (C12T32_LL_SDFPRQX8) 0.06 0.07 f U224/Z (C12T32_LL_CNNOR2X14) 0.02 0.10 r U217/Z (C12T32_LLBR0D8_NAND2X14) 0.01 0.11 f U222/Z (C12T32_LL_CNIVX16) 0.01 0.12 r U190/Z (C12T32_LL_NOR3AX25) 0.04 0.17 r U187/Z (C12T32_LL_NAND4ABX6) 0.03 0.19 f U267/Z (C12T32_LL_CNIVX8) 0.02 0.21 r update_ir (out) 0.00 0.21 r data arrival time 0.21 clock clk_v (rise edge) 0.31 0.31 clock network delay (ideal) 0.01 0.32 inter-clock uncertainty 0.00 0.32 output external delay -0.12 0.20 data required time 0.20 ------------------------------------------------------------------------data required time 0.20 data arrival time -0.21 ------------------------------------------------------------------------slack (VIOLATED) -0.01 1

Power report:
**************************************** Report : power -analysis_effort low Design : fsm Version: E-2010.12-SP4 Date : Mon Mar 26 18:52:01 2012 **************************************** Library(s) Used: C32_SC_12_CLK_LL (File: /sw/unicad/C32_SC_12_CLK_LL_C28/1.1@20111019.0/libs/C32_SC_12_CLK_LL_ss 28_0.90V_125C.db) C32_SC_12_CORE_LL (File: /sw/unicad/C32_SC_12_CORE_LL_C28/1.1@20111020.2/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/1.1@20111024.0/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/1.1@20111019.0/libs/C32_SC_12_CLK_LR_ss 28_0.90V_125C.db) Operating Conditions: ss28_0.90V_125C Wire Load Model Mode: enclosed Library: C32_SC_12_CORE_LL

Design Wire Load Model Library -----------------------------------------------fsm wl_zero C32_SC_12_CORE_LL Global Operating Voltage = 0.9 Power-specific unit information: Voltage Units = 1V Capacitance Units = 1.000000pf Time Units = 1ns Dynamic 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 1 = 2.7656 uW

Power Analysis (calculation) using Prime Time:

Library(s) Used: C32_SC_12_CORE_LL (File:/ssw/unicad/C32_SC_12_CORE_LL_C28/1.1@20111020.2/libs/C32_SC_12_C ORE_LL_ss28_0.90V_125C.db)

FSM coding styles Clock period Total power in w

Binary-encoding 0.6 3.716

Gray-encoding 0.6 3.408

Onehot-encoding 0.6 7.910

The power reports of three FSMs are given below, Binary-Encoding:

**************************************** Report: Time Based Power -verbose Design: fsm Version: F-2011.06-SP3 Date : 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/1.1@20111020.2/libs/C32_SC_12_CORE_LL_ ss28_0.90V_125C.db) Operating Conditions: ss28_0.90V_125C Wire Load Model Mode: enclosed Library: C32_SC_12_CORE_LL

Cell Design Wire_model Library Selection_type ------------------------------------------------------------------------------fsm wl_zero C32_SC_12_CORE_LL library default Power-specific unit information: Voltage Units = 1 V Capacitance Units = 1 pf Time Units = 1 ns Dynamic Power Units = 1 W Leakage Power Units = 1 W

Attributes ---------i - Including register clock pin internal power u - User defined power group Internal switching Leakage Total Power 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 Glitching Power Peak Power Peak Time 1 = = 0.0000 0.0000

= 3.411e-03 = 200.000

Gray-encoding:
**************************************** Report: Time Based Power -verbose Design: fsm Version: F-2011.06-SP3 Date : Mon Mar 26 15:00:53 2012 **************************************** Simulation Periods: 10 ns - 420 ns Sampling Interval: 0.001 ns Library(s) Used: C32_SC_12_CORE_LL (File: /sw/unicad/C32_SC_12_CORE_LL_C28/1.1@20111020.2/libs/C32_SC_12_CORE_LL_ ss28_0.90V_125C.db) Operating Conditions: ss28_0.90V_125C Wire Load Model Mode: enclosed Library: C32_SC_12_CORE_LL

Cell Design Wire_model Library Selection_type ------------------------------------------------------------------------------fsm wl_zero C32_SC_12_CORE_LL library default Power-specific unit information : Voltage Units = 1 V Capacitance Units = 1 pf Time Units = 1 ns Dynamic Power Units = 1 W Leakage Power Units = 1 W

Attributes ---------i - Including register clock pin internal power u - User defined power group Internal Switching Leakage Total Power 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 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%)

Net Switching Power = 5.953e-07 (17.78%) Cell Internal Power = 1.807e-06 (53.97%) Cell Leakage Power = 9.463e-07 (28.26%) --------Total Power = 3.349e-06 (100.00%) X Transition Power Glitching Power Peak Power Peak Time 1 = = 0.0000 0.0000

= 3.408e-03 = 220.000

Onehot-encoding:
**************************************** Report: Time Based Power -verbose Design: fsm Version: F-2011.06-SP3 Date : Mon Mar 26 15:14:59 2012 **************************************** Simulation Periods: 10 ns - 420 ns Sampling Interval: 0.001 ns Library(s) Used: C32_SC_12_CORE_LL (File: /sw/unicad/C32_SC_12_CORE_LL_C28/1.1@20111020.2/libs/C32_SC_12_CORE_LL_ ss28_0.90V_125C.db) Operating Conditions: ss28_0.90V_125C Wire Load Model Mode: enclosed Library: C32_SC_12_CORE_LL

Cell Design Wire_model Library Selection_type ------------------------------------------------------------------------------fsm wl_zero C32_SC_12_CORE_LL library default Power-specific unit information: Voltage Units = 1 V Capacitance Units = 1 pf Time Units = 1 ns

Dynamic Power Units = 1 W Leakage Power Units = 1 W

Attributes ---------i - Including register clock pin internal power u - User defined power group Internal Switching Leakage Total Power 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%) Net Switching Power = 1.472e-06 (14.85%) Cell Internal Power = 6.154e-06 (62.10%) Cell Leakage Power = 2.284e-06 (23.05%) --------Total Power = 9.910e-06 (100.00%) X Transition Power Glitching Power Peak Power Peak Time 1 = 5.383e-08 = 2.387e-07 = = 0.0124 60.000

Comparison between the three coding styles:

FSM coding styles Speed power Area

Binary-encoding Slower Low Low

Gray-encoding Slower (slower than Binary encoding) Low (Better than Binary encoding) Low ( lower than Binary-encoding)

Onehot-encoding Faster High Large

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 that are 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.

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.sunburstdesign.com/papers). IEEE Standard Test Access Port and Boundary-Scan Architecture IEEE Std 1149.1-2001 (R2008). Synchronous Finite State Machines; Design and Behavior by Prof. Dr. J. Reichardt Prof. Dr. B. Schwarz, University of applied sciences Hamburg DEPARTEMENT OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE. VCS MX/VCS MXi User Guide Version F-2011.12 December 2011 and Power compiler User Guide-SNUG.