Verification Of Multi-Cycle Paths And False Paths

All chip designers know that they must take special care to avoid metastability problems when they have multiple, asynchronous clock domains. In contrast, a design in which all clocks are synchronous may appear simple. Logic synthesis ensures that the shortest paths between registers don’t have races and that the longest paths fit within the target cycle time. However, single-clock design is not always as easy as it seems. Multi-cycle paths and false paths add complexity to the design process and synthesis must handle them properly. In addition, both types of paths must be verified early in the development process with static analysis.

A multi-cycle path (MCP) occurs when a designer intentionally includes logic functions that cannot be completed within a single clock cycle. Figure 1 shows an MCP involving two synchronous clocks. The logic between the source and destination requires three cycles of the destination clock to produce a valid result, so the destination register must load this result three clock cycles after new data is loaded into the source register.

Fig. 1: Example of a multi-cycle path.

A false path (FP) occurs when there is a traceable path through a design that is never enabled. Either the design itself or the way the design is used ensures that the path will not be exercised. Figure 2 shows a design in which all valid paths go through a section of slow logic and a section of fast logic. The path that goes through both slow sections would take too long to complete, so it is an FP. The path through both fast sections might result in a hold time violation, so it is also false.

Fig. 2: Example of a design with false paths.

A logic synthesis tool needs to know about MCPs and FPs so that, for example, it does not waste time trying to fit the three-cycle path in figure 1 or the slow-to-slow path in figure 2 into a single clock cycle. In the earliest days of the Design Compiler family, Synopsys introduced design constraints to specify clocks, timing, setup and hold checks, MCPs, FPs, and other useful guidance. The three-cycle path in figure 1 and the false paths in figure 2 can be expressed using the following Synopsys Design Constraints (SDCs):

set_multicycle_path 3 -from top/SRC -to top/DST -end

set_false_path -through S1 -through S2
set_false_path -through F1 -through F2

Correct synthesis results depend on accurate SDCs. Design Compiler NXT can detect some types of SDC errors, such as referencing signals and modules not in the design. But a specification error such as specifying that figure 1 contains a four-cycle path will result in a design that does not work as intended. Traditionally, the only way to catch these problems was to run a full-timing gate-level simulation (GLS). Such simulations are slow and hard to debug. They also occur much too late in the development process, with a long loop time required to fix issues.

MCP and FP SDCs are architectural features that ideally should be specified along with the functional intent and verified at the RTL stage, long before any back-annotated GLS is even considered. The SpyGlass Constraints solution provides linting capabilities for SDCs, including those related to timing. It catches several classes of MCP and FP errors that might otherwise not be detected until logic synthesis. It can also compare two sets of constraints to check incremental revisions, valuable since constraints often change as the design evolves.

SpyGlass Constraints also extracts MCP and FP properties that can be verified by its internal formal engines. Formal analysis tries to either prove each property correct or provide a counterexample showing how it can be violated. Unlike simulation, formal verification is exhaustive, so these results are definitive. It provides thorough analysis for block-level designs. However, formal algorithms are sensitive to design size and complexity and may not scale to MCPs and FPs traversing a large system-on-chip (SoC) design.

For any inconclusive results, neither a full proof nor a counterexample, SpyGlass Constraints can export the extracted MCP and FP database to VCS to be verified using RTL simulation. This simulation can include embedded software running on processor models, thus reflecting SoC behavior that is not part of the formal model.

Correct specification of false paths and multi-cycle paths is critical for proper synthesis results on complex chip designs. Early analysis with SpyGlass Constraints, leveraging its internal formal engines and backed by VCS simulation, provides high confidence in the correctness of SDCs early in a project timeline. This is a significant “shift left” in MCP and FP verification that results in better chips developed faster with fewer resources.

VCS also provides a new and unique solution to verify MCP and FP in dynamic simulation at RTL. More information, including a detailed example, is available in a white paper.