Bulletproofing FSM Verification Automated Approach to Detect Corner Case Issues in an FSM Design

Bulletproofing FSM Verification Automated Approach to Detect Corner Case Issues in an FSM Design Lisa Piper Technical Marketing Real Intent Inc., Sunnyvale, CA Comprehensive verification of Finite State Machines (FSMs) is essential because they control most aspects of the functionality of a design. While simulation is irreplaceable for verifying functionality, it is only as good as its stimulus. This paper discusses how to automate formal verification of corner case chip killers of an FSM design namely that the FSM will not lock up, is not subject to metastability on reset deassertion, and that synthesis directives hold true. 1

Introduction Today s complex SoCs are constructed from blocks that come from many different sources, including legacy IP, third-party IP, library components from an ASIC or FPGA vendor, and new design blocks developed by geographically distributed teams. The verification task has become daunting. FSM verification is so critical to the success of an SoC that it is often a focal point of the verification plan. Traditionally FSM verification is graded by coverage metrics, but total coverage can be difficult to achieve in simulation and does not even guarantee that all scenarios and corner cases have been verified. Static analysis is recommended both to speed simulation verification by catching issues early and to bullet proof the verification of the corner cases. Lint enables quickly weeding out many issues prior to the start of simulation. While simulation is great for verification of normal operation, only formal verification can ensure that all the corner cases are verified. Ascent AutoFormal explores the sequential behavior of an FSM to ensure it will never lock up, detects reset metastability issues on reset deassertion, and determines with 100% confidence whether synthesis directives always hold true. It also verifies that all FSM transitions can be reached, which is important for achieving those simulation coverage goals. This paper describes how to automate the formal verification of FSM-related chip-killer issues such as deadlocks. The paper discusses various FSM checks, including highlights of features that facilitate debug. It also discusses why it is advantageous to use Ascent Lint early in the design process, before simulation even begins, to weed out the simple, though non-obvious, FSM issues. Ascent Lint is very fast and easy to learn and use, and the types of issues it uncovers are generally much simpler to debug statically than in simulation. Automating FSM Verification with Ascent AutoFormal Ascent AutoFormal uses exhaustive formal analysis to verify functional properties implied in the RTL. FSM-based control-oriented designs have complex execution paths that are hard to enumerate explicitly in simulation. As a result, efficient exhaustive analysis, as provided by state-of-art formal analysis algorithms, is a must for FSMs that control design functionality. Ascent AutoFormal is not dependent on simulation stimulus to expose the error. It performs deep sequential state-space analysis of automatically generated properties. Because the analysis is sequentially deep, AutoFormal is not as fast as Ascent Lint, but the analysis is exhaustive, and the results more accurate. The true benchmark of performance is the overall time it takes to configure the analysis, run the analysis, and resolve the issues, with all aspects being automated to the extent possible. Ascent AutoFormal was architected to provide the best overall user experience, from start to finish. Ascent AutoFormal does the following: Automatically creates a design-specific environment file that defines the clocks and resets. Automatically identifies and reports key characteristics of FSMs in the design. Automatically creates and formally verifies FSM-specific checks. There is no need to know any assertion languages. Does root-cause analysis to minimize debug time. Ascent AutoFormal performs additional checks that complement FSM verification. Some of these other checks aid in the debug of FSM issues. This section describes how Ascent AutoFormal can find bugs in the corners of your FSM design, as well as report other RTL characteristics. Ascent AutoFormal also provides additional non-fsm checks that are not described in this paper. 2

FSM RTL Characteristics Reporting FSM designs should employ a consistent state-encoding style for an FSM. Styles are often chosen for the FSM error detection and recovery scheme for the operating environment. Enumerated-state types are recommended because they are more readable and easier to tune for synthesis. Also, an FSM should have a properly defined reset state for testability and predictability. Ascent AutoFormal reports warnings when Enums, clocked Enums, and FSMs are not resettable. It also reports the details of all FSMs and related Enums. An example of FSM reporting is shown below. You can easily review the FSM s state enumerations, the state encodings, clocks, and resets.. In addition to FSM information, other information such as the existence of latches is reported. This is important because latches can prevent the detection of FSMs. The RTL information presented is structural and not formally derived, however it is a convenience feature. FSM Checks Ascent AutoFormal provides a variety of essential FSM checks based on the RTL. It automatically identifies FSMs in a design and then creates checks based on the states of the FSM and the state transitions of the FSM. The checks are then formally verified. There is a variety of very useful FSM checks in AutoFormal: One of the most valuable checks for catching corner case FSM chip-killers is the deadlock test. Deadlock is the situation when a state, once entered, is never exited. This check ensures that for any standalone FSM, there is no individual state that results in FSM deadlock. A violation indicates that the state variable can enter the indicated state, but cannot exit from it. Ascent AutoFormal verifies that for every transition into a state there is not deadlock. Debug information provides a link to the transition whereby when the state is entered it cannot be exited. Note that because each transition is tested independently of other transitions, maximal coverage is obtained. The state deadlock check can potentially cause the design to enter suspended operations due to a hung control flow. In the example below, when state 010 is entered, it cannot be exited, so a deadlock violation occurs. This is a violation that would not be report by a linter because sequential analysis is required to determine that the exit transition will never evaluate to true. Moreover, Ascent AutoFormal will report when any one of multiple incoming transitions can results in a deadlock. 3

Figure 1 State deadlock detection Ascent AutoFormal checks that all states of an FSM can be entered from all existing input transitions. It is more than simple state reachability in that every transition is verified. The exception is that the Verilog default and VHDL others case branches are not reported when they cannot be reached. A violation indicates that the state machine cannot enter the state from a particular transition. A violation will provide a link to the FSM transition assignment that will never complete. In the example below, a state reachability violation is reported on state 10 because while there exists a state transition into the state, that transition can never evaluate to true. This is a case that a linter would not detect because sequential analysis is required to see that the transition conditions cannot evaluate to true. Had there been multiple possible transitions into the state, only one of which cannot be reached, AutoFormal would not report an unreachable state, but would still report the unreachable state transition. Unreachable state transitions are dead code that should be fixed or eliminated to improve coverage analysis metrics. Figure 2 Unreachable state identification 4

Ascent AutoFormal checks that for any FSM state variable, all bits are capable of changing their value. A violation indicates that the state variable has bits that are stuck at the indicated values. This could mean the enabling condition for certain state transitions cannot occur within the design. For a onehot-style state encoding this will directly indicate unreachable states. By detecting the individually stuck bits, the driving logic should be easier to identify and debug. Ascent AutoFormal ensures that for any pair of states in two detected finite state machines, the two FSMs can be in that pair of states concurrently. Reachability checks validate that the two state machines can interact. Another situation has to do with deadlock involving two FSMs. A violation indicates that the two state machines are most likely awaiting handshaking signals from one another before proceeding to their respective states. Pairwise deadlock is a frustrating problem to detect during RTL coding due to the high level of interactions that can occur between different state machines within a design. An example is shown below, where there is a master state machine and a slave state machine, and a handshake between them. In this machine, the states shown in red below are the S_REQUEST (on left) and the M_REQUEST (on right). The handshake works as long as they don t both request at the same time. When they request at the same time, a lockup occurs. Figure 3 FSM Pairwise state deadlock 5

Ascent AutoFormal also has FSM Fault Tolerance checks that are useful for checking unpredictable state changes. All unused (illegal or undefined) states should transition to a defined state, whereupon this error condition can be processed accordingly. Ascent AutoFormal verifies that an illegal state is not reachable, where an illegal state is one where the state vector has an implicit or explicit X-value. Violations report all the transitions that go to the illegal state when the transition is reachable from reset. In the example below, reg [1:0] state, next_state; // sequential state/next_state logic always @(posedge frm_clk or negedge reset) begin if (!reset) state <= 2'b00; else state <= next_state; end // combinational next_state logic always @(state) begin case (state) // synopsys full_case 2'b00: next_state = 2'b01; 2'b01: next_state = 2'b10; 2'b10: next_state = 2'b11; endcase end The state 11 is an implicit illegal state due to the full case pragma. Since it is assigned to, it is a recognized state that assigns the next state value to xx, the illegal state. A VCD is provided that shows the sequence that leads to the failure. Figure 4 Illegal State Transition shows the path to the illegal state from reset 6

The above FSM checks are key to bulletproofing an FSM against corner-case chip killers. Safe Synthesis of FSMs It is important to verify that FSMs synthesize in a predictable manner, consistent with simulation. FSMs are implemented using if-else statements and case statements, though mostly case statements. The synthesis of case statements can be optimized with the use of synthesis directives parallel case and full case pragmas, or with SystemVerilog unique and priority constructs. If-statements can also be specified as being unique and priority. It is important to ensure that these synthesis directives always hold true. Simulators are only as good as the stimulus. Ascent AutoFormal uses the full-case pragma or SV "unique" keyword to determine where the full-case checks should exist and uses formal analysis to determine that only the specified case items can be reached. Ascent AutoFormal uses the parallel-case pragma or SV "priority" keyword to determine where the checks should exist and uses formal analysis to verify that there are no duplicate or overlapping case items. For debug, a VCD is provided that shows the sequence of events that can lead to the violation. As an example, for the code shown below, a check is done to verify the unique0-if synthesis directive that says there is no overlap in a series of if-else-if conditions (i.e. all conditions are mutually exclusive): wire [1:0] sel; assign sel = {up,down}; always_ff @ ( posedge clk ) begin unique0 if (sel == 2'b00) u02 <= m n; else if (sel[1] == 'b0) // violation because it is not unique u02 <= p q; else if (sel == 2'b10) u02 <= m p; else if (sel == 2'b11) u02 <= m q; else u02 <= m & q; A VCD is generated that shows the violation occurs when sel is 1 b00 (i.e. when {up,down} are {0,0}) This was a very simple example for demonstration purposes, but for complex scenarios, the VCD always shows the sequence of events that lead to the failure. Figure 5 VCD that shows the value that matches multiple conditions of an unique0-if construct 7

FSM Reset Metastability Few would argue against the claim that FSM s require a reset to put them into a known state, but just having a reset is not good enough. You have to ensure that metastability does not occur when reset is released. Metastability can occur when the significant edge of the clock occurs at the same time as when reset is released. Logic may or may not see the reset as asserted and oscillation can occur. So in the example shown below, when the clock rises at the same time that the reset is deasserted, it is not clear whether out will be assigned a 1 or a 0, and the output can oscillate. always @(posedge clk or negedge reset) if (!reset ) out <= 1 b0; else out <= 1 b1; Ascent Autoformal reports a FSM Reset Metastability violation when the FSM reset is not synchronous to the FSM clock and the FSM transitions immediately after reset release. More comprehensive reset tests are available in a companion tool from Real Intent called Meridian RDC. Meridian RDC also reports when there can be other causes of metastability on the resets, reconvergence issues, and glitches on resets. Refer to the white paper Making Sure Resets Don t Kill Your SoC 1 for more details. FSM Analysis using Linters Discussion of FSM static verification would not be complete without mention of linters to verify FSMs. Linters use structural analysis, not sequential analysis, so the tool runtimes are very fast. Size limitations are not an issue - a million gate design can run in minutes with Ascent Lint. Linters such as Ascent Lint do enable eliminating some issues and they can check different aspects of your FSM that are complementary to formal analysis techniques. Ascent Lint should be used before simulation and before Ascent AutoFormal to eliminate the simple issues and ensure coding conventions are used. Real Intent s Ascent Lint offers a broad selection of FSM rules, including but not limited to: Calculated next state (which can be costly in synthesis) FSM state a literal constant Naming conventions of present state/next state variables Limit FSMs to N states Mealy or Moore FSM coding style Assignment to undefined next state One hot encoding Require FSM reset FSM state never reached FSM terminal state Ascent Lint can check for many things related to FSMs, though linters can never be as precise as Ascent AutoFormal, which is required to bulletproof an FSM. For example, Ascent Lint can miss reporting a terminal state or unreachable state because it assumes everything is reachable. Only the sequential analysis of AutoFormal can determine if the transition can occur. A linter can also be noisy because it cannot determine when the conditions for reaching a state cannot occur. For example, a linter would report a full case violation for any case statement that does not specify all possible case items and does not have a default, even when the missing case items are not reachable. Refer to the whitepaper Setting a New Lint Benchmark 2 for more details on Ascent Lint. 8

Summary FSM verification is so critical to the success of an SoC that it is often a focal point of the verification plan. Traditionally FSM verification is graded by coverage metrics, but total coverage can be difficult to achieve in simulation and does not even guarantee that all scenarios and corner cases have been verified. Static analysis is recommended both to speed simulation verification by catching issues early and to bullet proof the verification of corner cases. Many companies have found value in Ascent Lint as an early verification tool, deploying it throughout RTL and circuit-level design, to enforce coding standards and to detect coding anomalies, including FSM design verification. It can run a million-gate design in minutes, and also provides a great debug environment. Ascent Lint is ideal for eliminating simple, though not always obvious, issues before simulation and AutoFormal. Ascent AutoFormal builds on the structural analysis of Ascent Lint by automating the use of formal sequential analysis to verify the integrity of FSM designs. Ascent AutoFormal is enabling the widespread adoption of formal technology for FSM verification by promoting a use model that is almost as simple as that of a linter. Ascent AutoFormal goes beyond all other tools in its category by also providing root cause analysis to minimize debug, thus setting a new benchmark in minimizing the overall verification effort from start to finish. Some of the most important reasons for using Ascent AutoFormal for FSM verification are: Reports the characteristics of identified FSMs, including warnings on non-resettable FSMs. This information can be useful for verification of design practices. Verifies that an FSM will never lock up Verifies that all FSM transitions can occur and all states can be reached Verifies absence of reset metastability of FSMs, and that the FSM does have a reset Identifies areas where simulation may not match the behavior of an FSM design in hardware. Managing the results and tracking status is made easy through a database-driven graphical user interface. AutoFormal works with the idebug debugger that includes a source browser, RTL-based schematics, and waveform viewer. AutoFormal is the only AutoFormal tool on the market that does root-cause analysis. This provides magnitudes of reduction in debug time. Only primary issues are reported as Errors. Secondary, structurally detected issues, and duplicates, are reported as Warnings. 9

References (you can obtain these references from www.realintent.com/white-papers ): 1. Making Sure Resets Don t Kill Your SoC, Vikas Sachdeva, June 2017. 2. Setting a New Lint Benchmark, Lisa Piper, November 2016. Copyright 2017 Real Intent Inc. Real Intent, Inc. 932 Hamlin Court Sunnyvale, CA 94089 support@realintent.com Phone: 408-830-0700 Fax: 408-737-1962 realintent.com 10