Common RTL Issues Causing Functional Failures - Part#2

Lets discuss the first category of RTL Coding issues.

1) FSMs and Related Issues : The FSM impacts on designs are mainly in two different ways.

A) Correctness

B) Implementation Considerations

A) Correctness : State machines typically contain many states and a high number of transitions, inputs, and outputs. While writing RTL code, the user may not get a good picture of all states and their interconnections. This can lead to functional problems and consequently a chip failure. Although intent verification of the state machines requires knowledge of the design, many correctness aspects can be automatically verified. Common issues in state machines are:

- Unreachable state: An unreachable state is a state in RTL code where the user has not created any transitions to reach it, or created transitions that cannot be exercised by the logic controlling it. An unreachable state indicates a functional problem or design redundancy.

- Deadlock state: A deadlock state is a state from which no outgoing transitions exist or outgoing transitions are not exercisable due to control logic. When a state machine reaches such a state, it cannot transition to a different state.

- Dead transition: A dead transition is a state machine transition that is present in RTL code but cannot be exercised. Dead transitions may cause deadlock or unreachable states.

Designers must ensure that state machines present in their RTL are free of such bugs.

B) Implementation Considerations : Several FSM attributes can be used to measure the quality of implementation in RTL. Examples of these attributes are:

- the number of states, transitions, inputs and outputs

- the depth

- the encoding style

- presence or absence of an initial state

Designers must tune their design using these metrics to achieve the desired design objectives such as area, timing, and power goals.

Since FSM are mostly implemented using case statements, many issues around the correct usage of these constructs. In fact, their usage entails pitfalls that can cause chip failures.

Two problems that may arise in case statements: incompletely specified case statements and overlapping case statements.

//Not all conditions are included 
always @(posedge clk2) begin
case (bs)
4'b0000: out <= 0;
4'b1000: out <= 0;
4'b1010: out <= 1;
4'b0101: out <= 1;
4'b1111: out <= 1;
endcase

// Overlapping case statements 
always @(posedge clk2) begin
casex (bs)
4'b0000: out <= 0;
4'b10x0: out <= 0;
4'b1010: out <= 1; // Overlaps with 10x0
4'b0101: out <= 1;
4'b1111: out <= 1;
endcase

Thank !