Laguna Hills, CA - Excellicon's patented timing constraints methodology provides a unique and accurate methodology to promote timing constraints for hierarchical designs accurately in minutes.
When dealing with bottom-up methodology integrating lower blocks and sub-systems into the SOC design, there is a need to take advantage of existing timing constraints which may accompany the IP-block or previous versions of a sub-system design. When it comes down to definition of timing constraints, in such instances the designer is faced with the challenge of promoting existing timing constraints to higher level blocks and eventually the SOC.
The designer has several choices to promote the timing constraints. First, he/she has the option of rewriting timing constraints for the top level from scratch, which may not be practical as it requires a great deal of knowledge of the design, the interface protocols of the IP’s, not to mention the time it takes to take on such task, perhaps months.
A more simplistic and semi-automated method is often used by reading all lower-level block constraints and essentially manipulating the hierarchy delimiters using any existing STA. Once the higher-level constraints are created, this option still requires a great deal of manual manipulation and corrections and in the interest of comprehensive verification one must still perform extensive equivalency checks to ensure the eventual top level timing constraints is the true representation of underlying timing constraints of the lower-level blocks. This method assumes that the timing constraints are available for all lower-level blocks. Absence of which, this method cannot be used or if used leads to missing timing definitions and manual mistakes which will certainly take weeks to clean up iteratively.
Promotion with either of the above two options can lead to paths which may not be timed due to issues in promoting the timing constraints. Such misses can eventually result in timing closure issues and unnecessary iterations to resolve such paths and more verification work. In addition, several flavors of the timing constraints are also needed to accommodate the hierarchical STA flow. This manual work is prone to mistakes and missed timing definitions.
Excellicon’s Constraints Manager patented solution provides a third and more comprehensive approach to promotion performed in minutes. The goal of the tool is to provide a comprehensive methodology-based approach to constraints promotion as part of Excellicon’s commitment to providing an end-to-end timing constraints closure methodology as opposed to one off feature performing an isolated point task.
In order to achieve a comprehensive and methodology-based solution to promotion there is a need for a timing constraints generation engine where the provided timing constraints or legacy timing constraints can be augmented, corrected, and consolidated as the information is promoted through various layers of hierarchy. If the timing constraints is not available for a particular lower-level block or IP, the Constraints Manager as part of the promotion, automatically generates the required timing constraints for that block.
Figure 1
For example, in figure 1, the green boxes represent the IP blocks with NO timing constraints, while the orange boxes represent IP’s with the timing constraints. During constraints promotion, the tool promotes the orange box SDC’s to any level of the hierarchy specified by the user. The timing constraints for the green IP boxes are automatically extracted such that a complete promoted SDC file for the top level is generated. Had there been SDC’s associated with the green boxes, the tool would have promoted all the IP SDC’s to the top level.
The generation engine ensures that there are no gaps in definition of the timing constraints, and it will provide 100% coverage based on actual HDL code eliminating the possibility of any missing timing info. In order to achieve this goal, Excellicon’s Constraints Manager products provides a detailed clock extraction (also visualized through clock map, shown in figure 1) which can then be used to ensure all paths in the design are considered and timed when running STA analysis.
Basics
Block level constraints can be promoted to the top level in several ways. For example, in Figure 2, the Block for which the constraints are to be promoted is shown in blue outlined box. The symbol C denotes the create_clock while the G represents the create_generated_clock constraint. In order to promote the original gray C clock to the top level, a green colored G and C clock must be created at the appropriate location at the Top level. The gray C clock must be eliminated so that the green G clock is not blocked. The red arrow shows the associated master relationship.
Figure 2
However, this method has potential of altering the original timing intent of the Block. If there were any timing constraints referring to the C clock in the original block-level SDC file, they also need to be modified such that they now refer to the G clock instead of the gray C clock.
Instead of eliminating the original C clock, a better approach is to replace the gray C clock with another G clock, shown as a yellow G (with the same name as the C clock) as shown in Figure 3.
Figure 3
With this patented approach, the original timing intent of the Block IP is maintained since any timing constraints which previously referred to the C clock, now refers to the replaced G clock. This approach also has the benefit of isolating the original timing intent of the block from the rest of the SoC.
Isolating the Original Timing Intent
In figure 4, the original clocks again are shown in green, while the replacement clocks are shown in yellow. Here, at the IP1 level, the C1 and G1 clocks are synchronous (G1 is divide-by-2 of C1) and are clocking the synchronous timing path from FFA to FFB. However, these two clocks are also entering the IP2 block where they are driving two separate clusters for flops, FF1 and FF2 that do not have any connectivity between them, thus defined as asynchronous in IP2’s SDC, through:
set_clock_groups -asynchronous -group {C_FF1} -group {C_FF2}
After promotion, the top level promoted SDC will contain C1, G1, G_FF1 and G_FF2 clocks, and the clock relationship for IP2 clocks is maintained through:
set_clock_groups -asynchronous -group {G_FF1} -group {G_FF2}
This ensures that the replacement G_FF1 and G_FF2 clocks remain asynchronous (keeping with the original intent of the IP2 SDC), while C1 and G1 clocks continue to be synchronous.
Figure 4
The replacement G clocks are only created if there is a need to preserve the timing intent. If the IP2 clocks were also synchronous, the tool would have eliminated the C_FF1 and C_FF2 clocks and not create the replacement G_* clocks. Also, if IP1 clocks were not defined, the tool would have automatically extracted the IP1 clocks and stitched it to the IP2 clocks in the promoted top level SDC.
Exception Leakage
In order to prevent unintended constraints leakage from the IP block that is being promoted, Excellicon’s Constraints Manager, exhaustively analyzes the all the constraints present in the block level SDC such that there is no leak (mainly timing exceptions) from the block to the top.
