Socionext paper presented at 2016 DAC reports significant time savings using Excellicon products.

2.2 – IP Timing Constraints Promotion Challenges (A method to automatically generate SoC Timing Constraints)

65.11 – An Effectual Approach of Timing Constraints Promotion and Demotion

Checkout how Excellicon is changing the way the timing constraints are done, as show cased in Chip Design Magazine

 

excellicon_article_chipdesign_2016-1

Or click on the link to Chip Design magazine

http://eecatalog.com/chipdesign/2016/06/09/migrating-from-manual-and-validation-based-timing-constraints-development-to-automated-synthesis-model-extracted-from-design/

 

 

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.

www.excellicon.com

contact: [email protected]

 

__________________________________________________

 

Todays SOC designs are architected top-down and designed bottom-up, meaning that the design specifications are dictated from the top level requirements and budgeted downwards to lower level blocks. Once lower level blocks are designed and completed the resulting block level characteristics are integrated upwards, or bottom-up for final SOC assembly.

Much attention has been devoted to functional aspect of the top-down to bottom-up design approach. Many tools are available in designers’ arsenal to validate the functional aspect of the design from simulators, linters, to formal equivalency checkers, etc. As a result functional design specification are propagated to lower level blocks and once block level design is complete, the performance metrics are propagated back to the top for functional validation. Such metrics however are missing when it comes to timing data, which for the most part are ignored from the functional simulation and it is left to the designer to “later” specify and capture them in the form of timing constraints. The process of the timing constraints definition as well as downward or upward propagation of such information is basically manual and solely relies on designer memory, skill, and intelligence with little automation aid to help in validating the information once captured.

The result of the gap in timing data propagation and validation has significant impact on tape-out schedules and accuracy of static timing analysis which if it does not result in a failed chip it will certainly result in much delay in schedules. Today Once the design architecture is finalized and the timing data is communicated to the designers it is up to the designer to captured timing metrics of a block correctly in a SDC “file”. The task of designers for all subsequent levels of hierarchy is to translate and propagate the timing information from the lower level SDC “file” to a higher level “file”. This error prone process if for the most part manual and very time consuming.

Excellicon has fully automated the timing constraints propagation process, while addressing transformation of timing data at all layers of hierarchy in the context of the overall design. Whether designer is starting with existing timing constraints or wishes to automatically generate the timing constraints, he will be able to seamlessly propagated timing information from architectural specification stage to the lower level blocks and back to the top level for final chip integration with out much manual work or need for user intervention. Once the tools initially analyze the design then the timing information is propagated throughout the entire design at any layer of hierarchy and for any mode of operation designated by the design architecture.

The impact is significant. First the manual and error prone work is eliminated, adding to the efficiency and accuracy of the process. Second the time it takes to complete such tasks has been shrunk down to minutes as opposed to weeks. Finally the timing information for any layer and all layers of hierarchy is updated instantaneously as lower level design information is updated for every rev of the lower level blocks or any intermediate layer of hierarchy. There is no need for the designer to “redo” all the work over and over every time a block changes its timing metrics. Taking such degree of automation into account, users are the enabled to generate and manage as many timing constraints files as necessary for their design in accordance to the process node requirements form manufacturer.

www.excellicon.com

Done Once! Done Right!