Identifying false paths

If only FPGA and/or ASIC designs would meet timing requirements the first time around, life would be simpler for a lot of engineers. Unfortunately, it is not as simple as that. The time and effort spent on timing are reaching unparalleled levels. Designers resort to constraining their synthesis and place-and-route (P&R) tools to achieve the required performance. However, generating the proper constraints is a hit-and-miss game for the designers, and verifying them becomes someone else's nightmare.

Designers typically load the implementation tools with the design constraints and hope the tools give the results they need (i.e., zero timing violations). In most cases, however, after the first pass, the timing reports give hundreds or thousands of violations. When diving into the timing report and looking at specific paths, designers ask, "Is this a real path that can occur?" Static timing engines in the synthesis and P&R tools just trace through all paths in the design to find the longest one. They do not evaluate whether a path can functionally occur.

If the implementation tool can meet the timing challenge, designers do not even worry about the question of false paths. But if the timing fails, designers need to be able to determine which critical timing paths are false, so they can be eliminated from the timing report or—even better—from the optimisation run. If the optimisation tool can work on fewer paths, it has a better chance at meeting timing on other critical paths.

Creating constraints to meet timing
Before making significant changes to their RTL descriptions, designers try to meet timing by constraining their synthesis and P&R tools. The initial constraints are somewhat easy and based on the designers' specific knowledge of the design. These include specifying those paths that most probably will not be exercised during circuit operation. False and multi-cycle paths are the most effective constraints for finding the optimal implementation solution. If it takes multiple iterations to close timing, designers start guessing which constraints to use. In the end, it becomes very difficult to determine which constraints are necessary and which are the most effective.

Chip designers try different tactics to attempt to solve their timing problems. They may change tool switches or overconstrain the tools. They may evaluate the constraints to determine what errors or incorrect assumptions may exist. However, this may result in increased runtimes, and there may be limited improvement. The next phase is determining if the critical path is false. Some false paths are dependent on the functionality of the input pins; this determination may require functional knowledge of the design and may be validated via a simulation assertion. This can be a time-consuming task, and if the design changes, paths may have to be re-evaluated. The amount of engineering effort required could be greatly reduced if there were a way to find structural false paths automatically and generate an assertion to validate. This way, if RTL changes were required, the false path generation could simply be rerun.

Focus on fixed obstacles first
For a particular RTL description, false and multi-cycle paths are like fixed barriers on the timing obstacle course. In effect, the critical paths of a design are moving targets that change as the designers modify the setup options for their synthesis and P&R tools. Focusing on the critical paths from the start may not be the right thing to do. It is more advisable to focus first on the fixed obstacles, a.k.a. the false paths and multi-cycle paths. Using its proprietary technology, Blue Pearl Software has built intelligence into its tools to detect and report false paths and multi-cycle paths automatically in an RTL description.

Obviously, there are some paths that the designers (with their proprietary knowledge) can easily specify. What types of false paths can the software find automatically? We will discuss some of them in the rest of this column.