It is important that certain timing endpoints on a design are safe from glitches. For example, it is necessary that an asynchronous reset never have a glitch that momentarily resets a flop. It is also necessary that multi-cycle paths are safe from glitches, i.e., it should not be the case that while a cycle accurate simulation of the RTL shows correct multi-cycle behavior, once delays are accounted for a glitch can propagate along the path resulting in a single-cycle path.
Traditionally, engineers have verified that a design is safe from glitches with delay-annotated gate-level simulation. There are several issues with this approach – it only confirms that there is no glitch for specific delay values and it happens late in the design cycle, i.e., it is late and incomplete. What engineers want is to establish, once their RTL is frozen, that it is impossible for certain timing endpoints to glitch regardless of the final gate-level implementation and circuit delays. They want to make sure that they have ensured safety from glitches by design.
In this article we present an approach to establish that a design is glitch-safe using the same collateral that is provided as input to logic synthesis – RTL and SDC constraints – no other input is required by the flow. Where possible, formal techniques are used to establish that an endpoint is glitch safe. When formal techniques do not prove that an endpoint is glitch-safe, assertions are automatically generated and provided as input to RTL simulation. Engineers review simulation assertion failures and resolve issues by fixing their RTL. If an assertion fails then an endpoint is at risk of glitching and an RTL change is required. The benefit of this approach is that it is complete (assuming simulation coverage is reasonable), happens early in the design cycle (not close to tapeout) and there is no noise (bogus problems are not reviewed by designers). We present results from the application of this approach on real designs.
GLITCHES
Consider the simple two-input and gate shown in Figure 1. If, at the rising edge of a clock, A rises and B falls then the final value on the output Z stays low. A cycle-accurate simulation would show the value of Z remaining unchanged (it was low in the previous clock-cycle and stays low in the current clock-cycle). If, however, once circuit delays are accounted for, B falls after A rises then the output Z will momentarily glitch high.
 |
Figure 1 - Glitch on an And-Gate:
An and-gate can create a glitch-high and an or-gate can similarly create a glitch-low. Further, an and-gate can propagate a glitch (either glitch-high or glitch-low) on one of its inputs, if its other inputs are high. Similarly, an or-gate can propagate a glitch on one of its inputs if its other inputs are low. In general, any multi-input gate (MIG) can, based on circuit delay, create a glitch and this glitch can then propagate forward through a design. In this article we focus on two situations where glitches can cause silicon failure:
- Glitches that momentarily assert asynchronous resets
- Glitches that invalidate multi-cycle path specifications
Glitches on Asynchronous Resets
Consider the circuit shown in Figure 2. The clrz pin is an asynchronous reset on a flop. When this pin is low the flop is reset. It is critical that the clrz pin never glitch-low – if it were to do so then the flop would momentarily reset and this would result in circuit failure. The clrz pin, however, is driven by multiple MIGs that could all create a glitch and so closer inspection is required to establish that the pin is safe from a glitch-low situation. The MIGs that are shaded green in the figure can never create a glitch of the required polarity and so they are not an issue. For example, the nand-gate U13 would need to glitch-high for a glitch-low to propagate to clrz and nand-gates can only create a glitch-low. So, U13 cannot cause an issue. The gates shown in red, however, could create a glitch of the appropriate polarity and this glitch could propagate to the clrz pin.
 |
Figure 2 - Glitches on Asynchronous Resets:
For example, as shown in Figure 3, U246/Z will glitch low if POK10_1P8 is low and if the falling transition on POK10_OUT_1P8 happens after the rising transition on POKEN10_1P8. This glitch will then propagate through to U243/Z if the other side-inputs to this gate are both high, through U33/Z if the other side-input to this gate is low, through U13/Z if the other side-input of this gate is high, eventually causing the clrz pin to glitch low. For this circuit to be safe from silicon failure the situation just described must never happen.
 |
Figure 3 - Waveform Showing Glitch Creation and Propagation to an Asynchronous Reset:
Glitches on Multi-Cycle Paths
Consider the circuit shown in Figure 4 where an engineer has specified a two-cycle hold multi-cycle path (MCP) through data. This MCP specification requires that data not transition immediately after the rising edge of cclk – instead any transition on data must happen a clock cycle after cclk rises. The data net is driven by an or-gate and a cycle accurate simulation, shown in Figure 5, shows that the output of the or-gate stays stable for a clock-cycle after cclk rises. However, at the time that cclk rises both the flops (start_input_write and write_inflight) that drive the or-gate transition. If the write_inflight falling transition happens after the start_input_write rising transition then data will glitch, as shown in Figure 6, and this glitch invalidates the single-cycle MCP specification (data does not, after all, stay stable for a clock-cycle after the cclk rises). As STA will time the path with the MCP specification in place this glitch could easily cause a silicon issue.
 |
Figure 4 - Glitch on Multi-Cycle Path:
 |
Figure 5 - Cycle Accurate Simulation Shows No Glitch:
 |
Figure 6 - Delay-Annotated Simulation Shows Glitch:
DELAY ANNOTATED GATE-LEVEL SIMULATION CANNOT RELIABLY CATCH GLITCH ISSUES
Engineers address the issue of glitches by relying on delay-annotated gate-level simulation. There are several issues with this approach. Gate-level simulation happens late in the design cycle, close to tape-out. That is far too late to be catching an issue whose fix almost always requires an RTL change. It is also well acknowledged that given the long runtimes of gate-level simulation, regression coverage is much worse as compared to RTL simulation. So, it is easily possible that the simulation vector required to create a glitch and have it propagate to the endpoint is not covered by gate-level simulation. Finally, the most fundamental flaw with gate-level simulation is that it is testing a circuit under a specific delay assignment (minimum, nominal, or maximum). However, circuit delays vary within the minimum/maximum range and it is trivially possible for gate-level simulation to not see a glitch because it did not simulate the range of possible delay values, just specific values within this range. For example, consider that the delays for the transitions at the input of the and-gate in Figure 1 are such that A has delays of (2:4:6) for (min:typ:max) and B has delays of (1:3:5). If the design is simulated at min, typ and max corners B always falls before A rises and no glitch is generated at the output of the and-gate. However, it is possible for the delay on B to be 4, while the delay on A is 2 (these delay assignments are within the specified range of delays for A and B) and the output of the and-gate could glitch.
Simulating a design at specific delay values to catch glitches is seriously flawed. A small perturbation in the implementation can easily change the delay characteristics of a design resulting in a glitch. It’s not realistic to repeatedly run gate-level simulation every time there is a small change in place and route. Fundamentally, there is no guarantee that a glitch issue will be caught by gate-level simulations because of how incomplete this approach is and even if the issue is caught it is painful to make RTL changes when a project is close to tapeout.
FishTail’s Glitch Verification Methodology
FishTail’s approach to glitch verification is focused on answering the following question: is my design safe from glitches regardless of the final gate-level implementation and its circuit delays, i.e., as long my gate-level netlist is logically equivalent to the RTL can I, at the RTL, establish that the design is safe from glitches and not revisit this analysis as implementation progresses.
The FishTail glitch verification flow, shown in Figure 7, takes as input synthesizable RTL and the SDC constraints for a design – the same collateral that is provided as input to logic synthesis. The tool identifies all the timing endpoints on the design that need to be glitch-safe. These are the asynchronous resets on flops and any timing exceptions (false and multi-cycle paths) whose endpoints need to be checked for glitches. A user can manually add to the list of endpoints that will be checked for glitches. For each endpoint the tool establishes whether a glitch of a certain polarity is not permitted (asynchronous resets for example should not glitch at the reset assertion level) or whether both glitch-low and glitch-high are not permitted (endpoints associated with timing exceptions).
 |
Figure 7 - FishTail Glitch Verification Flow:
For each timing endpoint that needs to be glitch safe the tool establishes all the MIGs that drive this endpoint. For the circuits in Figures 2 and 4, the MIGs are shown in either red or green. At each MIG the tool establishes whether a glitch of the desired polarity can be generated. Depending on the cell-type some MIGs cannot create a glitch of the desired polarity. Nothing more needs to be done with these MIGs. For the MIGs for which a glitch can be created the tool establishes if the condition required to propagate the glitch to the endpoint can ever be satisfied. This is done by formally computing the Boolean condition for a transition on the MIG output to propagate to the endpoint. If the propagation condition evaluates to 0, then the glitch cannot propagate.
After weeding out the MIGs that cannot create a glitch of the required polarity (the ones shown in green in Figure 2) and those that are unable to propagate the glitch to the endpoint the tool is left with MIGs that could potentially cause a silicon issue depending on the sequential behavior of the design. Whether or not there is an issue is a function of the cone of logic that drives the MIG and whether this logic can cause the appropriate transitions at the input of the MIG and then allow these transitions to propagate to the endpoint. Formal closure of the verification process for such MIGs typically requires an engineer to provide additional input to the tool that constrains how the logic cones are driven. Providing such input takes time, requires the RTL owner to review formal verification results and is a painful, cumbersome and error-prone process. Typically, this is where any momentum established from using a tool comes to a grinding halt.
FishTail’s glitch verification methodology, on the other hand, does not require any additional input from an engineer, nor does it require an RTL designer to spend time reviewing formal failures, constraining the formal tool, etc. For any MIG that does not pass formal proof the tool generates an assertion that states the property that must hold for the MIG to not cause a glitch at the endpoint. This is a functional property that the design must satisfy to be safe from glitches for any and all delay values. An example assertion, for U246/Z in Figure 2, is shown below in Figure 8.
 |
Figure 8 - Example Assertion Generated to Test Glitch Safety:
The FishTail formal tool does not synthesize RTL to gates – it does not perform its formal analysis on the synthesized gate-level representation of the design. Instead, formal verification is performed at the RTL level and so the assertions generated by the tool refer to RTL nets. This allows compact assertions to be generated that are easily integrated into an RTL simulator – the tool is working on the same model of the design as a simulator. Bind statements accompany the assertion so that integrating the assertions into an RTL simulation environment simply requires compiling the assertion file generated by FishTail along with the rest of the RTL for the design. No delay information is required when performing RTL simulation with FishTail generated assertions to verify if a design is glitch-safe. A cycle accurate simulation is sufficient. The assertions test whether it is possible for a glitch to be generated (highlighted in yellow in Figure 8), and then for the glitch to propagate to the endpoint (highlighted in blue in Figure 8). If both are possible then the assertion fails and an engineer reviews the failing assertion using debug strategies that he is already familiar with. If the assertions pass and the testbench coverage for the design is reasonable then the engineers can be confident that their design is safe from glitches regardless of how the RTL is implemented. The impact of synthesis transformations (on mux structures for example) is automatically handled by the tool so that there is no need to revisit this verification on the synthesized netlist.
Summary
Glitches that propagate to points on the design where they should not can cause silicon failure. Identifying that a design is safe from such glitches is an essential aspect of pre-silicon validation. The dominant approach to glitch verification in the industry today relies on gate-level simulation. This approach is woefully inadequate because it happens late in the design flow, gate-level simulation coverage is poor and simulating the design with specific delay values in the hope that it will throw up a glitch is naïve. FishTail’s solution to the problem requires an input collateral that is readily available (RTL and SDC) and establishes if a design is safe from glitches for any and all circuit delay. Most importantly, this approach leverages RTL simulation, so that RTL designers are not required to constrain a formal tool, or learn the debug environment that accompanies a formal tool. Instead, they simply review simulation assertion failures using techniques they are already familiar with.
Back to Top
