The use of timing-exception constraints is increasing in lockstep with designer requirements to get the most out of a given silicon device. Without proper verification, however, systems can fail in subtle ways. In addition, chip respins can be necessary and products can miss their market windows. Some companies forgo the use of exceptions due to the risk of errors. Reliable, accurate verification frees designers to get the most out of their silicon. It also puts them ahead of the competition.
Often, hardware engineering comes down to a balancing act between optimizing the design and making simplifying assumptions that can increase designer productivity. In synthesis tools, one of the simplifying assumptions that are used is that every timing path should meet default timing of one cycle (e.g., settle in one clock cycle). This aspect frees the engineer from having to specify every path in a design. At the same time, it makes sure that the paths that aren't explicitly constrained won't cause a chip timing failure. In this way, default timing has always been a useful safety net--one that has served its purpose well for many years.
As is true for most simplifying assumptions, however, utilizing default timing has a real cost in the ultimate resulting hardware design. By optimizing every path--whether it's required or not-- the design's quality of results (QOR) suffers. At the leading edge of design, every square millimeter of area, nanosecond of delay, and milliwatt of power matter. Clearly, design teams have become increasingly unwilling to suffer any QOR penalty. This trend has led to a need for a way of specifying those cases that are exceptions to default timing.
Exceptions to the default-timing requirement come in two forms. They're referred to as false or multicycle paths. In a false path, there is a logical connection from one point to another. Because of the way the logic is designed, though, this path can never control the design's timing. For example, a small piece of a design might look like the one in Figure 1.
Figure 1: This is an illustrative example of a False Path.
When select is 0, there's a path from ff1 to ff2 through both multiplexer inputs. Because both selects can never be 0 concurrently (perhaps they are 1 hot signals), this circuit topology will prevent the path from occurring. As a result, this path doesn't need to be optimized to meet the clock cycle timing from the first to the second flip flop. This path is a false one because it can never occur. Even though it is false, however, a static-timing tool would flag it as a path. If the delay on the path misses its target, it would flag it as a failing signal. Placing a false-path constraint on this path will allow the synthesis tool to forgo optimizing this path for speed, thereby generating a smaller, lower-power implementation. In addition, the static-timing tool will be happy. The command at the bottom of the figure shows how this false path is expressed in Synopsys Design Constraints (SDC) notation.
Multi-cycle paths occur when there's a valid path from one place to another, but the control logic that sequences the data through the path uses multiple clock cycles for each data item. Typically, this happens when the receiving logic only needs a valid piece of data every few clocks. Defining the path as multi-cycle allows the synthesis tool to optimize for area rather than speed. An example design is shown in Figure 2.
Figure 2: This is an Illustrative example of a Multi_cycle path.
Two multiplexers are controlled by a finite state machine. Flip flop ff1 will hold its value on every clock when multiplexer input 0 is selected. When the finite state machine selects multiplexer input 1, a new value will be loaded into flip flop ff1. This value will propagate through the logic cloud, the second multiplexer, and finally to flip flop ff2. The state machine that controls the two multiplexers only selects input 1 of the multiplexer every two cycles. The paths through the logic are therefore multi-cycle paths, as the new value from flip flop ff1 will take at least two cycles to propagate through to flip flop ff2. The SDC notation to declare this as multi-cycle is shown in Figure 3.
Figure 3: A proposed flow which only uses exceptions which are proven correct is what we call a "Reliable Exception Flow".
A RELIABLE FLOW USING EXCEPTIONS
Once a design team has made the decision to use exceptions to increase the QOR of its designs, there is an issue. What verification method will ensure that the exceptions are correct? Functional simulation will not. Nor will any of the functional-verification methods that are commonly used, such as emulation, prototyping, or equivalence checking. Although static-timing tools can check for the sensitizability of the signals, this is not sufficient.
The solution may be found in a new flow, which uses exceptions throughout the design process for maximum benefit. The exceptions are classed into two groups. The first group comprises those that aren't known to be correct either because they came along with purchased IP, are handwritten by designers, or come from tools. These are called possible exceptions because they shouldn't be used until they're proven correct. In contrast, the verified exceptions are those that can be algorithmically proven correct. These are the output of a formal timing-exception verifying tool, such as PureTime from Real Intent.
The designer starts with the register transfer level (RTL) and an initial synthesis design constraints file--the possible exceptions. PureTime is run on these inputs. It creates a set of proven exceptions in the verified exceptions file.
The synthesis process is run and a netlist is generated. The designer can now use the synthesis static-timing analyzer or a separate static-timing analyzer to report paths that didn't meet timing. If a path was a real violation, the designer has to fix the RTL or timing constraints in order to fix the error. The designer specifies false paths and multi-cycle paths by creating exceptions in the SDC file and adding them to the pool of possible exceptions. Previously, the designer would iterate through this process until all of the timing errors were removed. Now, the exceptions can be used to optimize the QOR of the design without fear of a design failure.
In order for analysis to be meaningful, setup needs to be correct. Fortunately, the process of extracting clocks, their relationships, and the parts of circuitry that don't need to be processed (blackboxes) is straightforward. Once the control file is populated with this information, the SDC and control file are fed into PureTime.
WHAT EXCEPTIONS ARE PROCESSED
One class of exceptions seen in designs is false paths, which are declared on signals that cross clock-domain boundaries. They are used to silence the static-timing analyzer for these signals. PureTime understands these clock-crossing signals and marks them as acceptable false paths.
The rest of the population of false and multicycle paths is expanded due to wildcarding. These paths are matched with logic in the design. Even in this earliest phase, the designer gets quite a bit of information about paths with errors. Once all of the paths that match real logic are partitioned, the formal engine is invoked to determine whether these statements are correct. PureTime uses the Convergence engine to process exceptions. In addition, the Convergence algorithms are enhanced to understand gate-level constructs and the possibility of glitches.
RTL VS. GATE
It's important to run the exceptions early in the design flow at RTL. In addition, the same exceptions need to be run at gate level. Transformations to the circuit due to synthesis can invalidate paths that were valid exceptions. Notably, paths that can create glitches must be invalidated as exceptions even if they would otherwise have been false or multi-cycle.
The most obvious verification is to ensure that the exception won't create a nonfunctional design from a timing point of view. While this is the most important task, some more subtle checks also need to be done to truly ensure that the exceptions are valid.
To go into more detail for glitch analysis, an example is needed. The design in Figure 4, which is a small piece of a larger design, illustrates what can happen if the behavior of actual hardware isn't taken into account when checking exceptions. At first glance, it looks as if signal d is always low. In a static sense, flip flop u3 will therefore clock in a 0 value. If no exceptions were assigned to any of the signals between flip flops u1, u2, and u3, the synthesis tool would optimize the design so that signal d was stable before the setup time required for flip flop u3. If path a=>d or b=>d or both had false path exceptions attached, however, the synthesis tool might not guarantee the timing to meet the clock constraint. In addition, the glitch might be clocked into flip flop u3. While this is a small, non-functional piece of logic, real examples might have logic like this embedded deeply inside a larger design. Such logic would be extremely difficult to find with any form of verification.
Figure 4: Glitch Analysis is important because of transformations that synthesis makes to the original RTL.
Another difficult problem to manually verify is exception interaction. When a design contains exceptions with common endpoints, it's important to take a global view of the exceptions. One can then make sure that there are no interaction issues with these exceptions. If the exceptions interact improperly, the result can be an invalid exception. Figure 5 shows a design that demonstrates this behavior.
Figure 4: Glitch Analysis is important because of transformations that synthesis makes to the original RTL.
Looking at the state machine driving the three flip flops, it's clear that signal c, being 0, effectively masks the 0=>1 transitions on signals a and b. Signals a and b transitioning 1=>0 effectively mask out signal c transitioning from 0=>1. The designer might therefore conclude that path x=>d and y=>d are both multi-cycle paths. The problem is that each exception assumes that the other signal is going to meet the default timing. As a result, it won't affect the current exception. If the synthesis tool relaxes the timing on both x=>d and y=>d, there's a possibility that one or both of the paths might be too slow. They could then cause a glitch to be clocked into the flip flop and cause errant behavior.
This type of problem can occur if a designer is trying to fix that last problem and decides that all that needs to be done is to add one more exception. The designer may not realize that the added exception interacts with one that's 100 or 200 lines up in the SDC file because the interaction may not be very obvious. It is therefore very important that the designer verify all timing exceptions-- whether manually or automatically generated--to verify that they are indeed valid exceptions.
With the rapidly increasing use of timing-exception constraints, a reliable solution to verification is needed at both the registertransfer and netlist levels. A hybrid formal technology is needed- -one that ensures that subtle issues like glitches and exception interaction are handled properly. The technology should support both RTL and gate-level views of the design. With an automatic solution, subtle errors won't slip through. It also can save days and weeks over manual review.