Timing Constraint files are one of the best timing and clock data containers available to the designers, yet they are under utilized today and their value is not fully exploited in the design flow.
The timing information captured in timing constraints files often hold very valuable timing and clocking information. This valuable source of timing data can help the design teams to shorten the design cycles, improve verification quality, and increase analysis accuracy by providing timing information from early design stages to many downstream tools saving valuable time trying to extract timing information manually. The timing and clocking information can not only improve analysis capability and accuracy of downstream tools, but also save a great deal of unnecessary manual setup process which invariably reduces the verification burden and expands the coverage of any such verification work by allowing automated setup of static verification tools such as various flavors of linting tools.
Perhaps one of the reasons for such underutilization is because the timing constraints are often lacking complete timing information and/or are not in sync, or behind actual RTL development. Other reason for their underutilization is perhaps because at the early stages of the design the timing constraints files are not complete and reliable. The underlying fact is that the front-end engineers are not always familiar with the syntax of the timing constraints and view capturing of such information as an extra step.
The emergence of various types of static verification tools from linters of various types and flavors to more complex formal tools in the past decade is a clear indication of the need for enhancing analysis capabilities and/or validation capacity of ever increasing design sizes. We now have static analysis tools for Clock Domain Crossing analysis, Static Power analysis, Test, Place and Route, FPGA Prototyping, Static Timing Analysis, etc, which all in one form or another require setup which is related to the timing and clocking scheme of the design.
The static tools often require setup work; however, to this date the setup is mostly done manually and one has to intuitively extract necessary timing information from variety of sources such as specs, simulation data, or even design knowledge in order to setup these tools for proper operation and to maximize the value of such tools; otherwise the outcome is garbage in garbage out. As an example a CDC setup for an average size chip may take up to 2 weeks or more, done manually. Or trying to define the proper timing window for vector-less power analysis has to be done in the absence of timing data based on designer knowledge and memory.
Another area where quality and up to date timing constraints can help in shortening deign and verification cycles, is keeping FPGA info in sync with the ASIC side. Today they are done independent of one another, partly due to syntactical issues, but mainly because of the design considerations for each type of constraints. Keeping the ASIC side in sync with FPGA is always a challenge. The two can certainly impact one another but there is not a good method currently in place to automate the process for designers on either side, while maintaining a unified timing data source. As a result the designers on each side do their work independent of the others with minimal interaction. Hence delays, inconsistencies and error prone flows.
The timing information are often interwoven and buried into the functional design within the RTL code. However unlike the functional side of the design today, there is no forward propagation of the timing information to the post synthesis and implementation stages of the design. The timing data often generated and driven from the design during RTL coding stage are often left behind at the front-end stage. Additionally, there is currently no method of correlating the timing data between frontend and backend; pre and post synthesis, until gate level simulation is performed late in the implementation stage. Most of such knowledge is transferred only through designer knowledge thus causing multiple iterations.
The timing constraints files are defacto standard for getting such timing information propagated given that they contain reliable information. One way to improve the reliability of such information is to ensure that the timing constraints files are indeed in sync and true representation of the actual HDL through automation as opposed to block by block checks between a manually written timing constraints files and a perceived representation of HDL.
Excellicon automation of clock and mode extraction/analysis directly from HDL achieves the automated generation of necessary timing constraints files for use with downstream design steps. Accurate extraction and analysis of clocking and timing information allows for seamless propagation of timing data from early stages of the design all the way to the final tapeout. Additionally automating the propagation of timing constraints throughout the entire hierarchy allows the designers to instantly see the impact of any changes made to underlying constraints information buried anywhere in the design. The biggest impact perhaps is the fact that the front end designer does not need to learn the timing constraints file syntax.