Article Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Email to a Friend
- Printer Friendly Page
- Report Inappropriate Content
Following along the forum traffic, it has come to may attention that timing constraints are often a mystery to new users. In order to help those who have never had to constrain their timing, I offer the following part one, of five parts, on timing constraints.
Some Basics
Timing constraints apply to nets or networks, the path or paths taken from one element to all of the inputs of subsequent elements. One can also call out a specific path that is part of a net or network.
Every design should have at least one period constraint that specifies the clock and the duty cycle of the clock. A clock is always required for synchronous design, and so the period constraint is the most basic and is always a required constraint for any design. If there is more than one clock, each requires its own period constraint.
The period constraint will define how all nets must be routed in order to meet the timing requirements for proper operation.
A group may be defined to generically refer to many nets or paths of a selected set, such as a bus or control group.
Priority
When it comes to having many constraints for a design the following applies: the more general the constraint, the lower its priority, and, conversely, the more specific a constraint, the higher the priority. For example, a period constraint on a clock net or network is very general and will be over-ruled by a from:to constraint on a specific net or network.
The specific constraint for the from:to (or from:thru:to) is deemed more important than the more general constraint for any net within a clock domain.
There is a timing specification interaction report (the .tsi report) that details how the constraints interact. Select this option in the timing analyzer for reporting if you have a set of constraints, and you need to know how they are interacting and which priorities have been set.
One can override the assumed priorities and manually set the priority of any timing constraint. The use of the priority command allows setting a very low priority, such as 0, or even a negative priority, such as -10, which will be evaluated with an even higher priority than 0.
Example 1
The PERIOD constraint only covers nets from Synchronous Elements to Synchronous Elements, such as FFS to FFS, as shown in blue below:
NET "clk20" TNM_NET = “tnm_clk20";
TIMESPEC "TS_clk20" = PERIOD “tnm_clk20" 20 ns HIGH 50 %;
A TIMEGRP (timing group) is created called tnm_clk20 which contains all of the downstream synchronous components that net clk20 drives. All of the paths between these synchronous elements are then constrained with the timing specification TS_clk20, which specifies a 20 ns requirement from synchronous element to synchronous element and a HIGH 50% (clk20 has a 50/50 duty cycle).
Example 2
FROM:TO constraints are used to define a requirement for paths that go between two groups.
TIMESPEC TS_my_fromto = FROM my_from_grp TO my_to_grp 40 ns;
tells the tools that you need to ensure that data makes it from the components in the timing group ‘my_from_grp’ to ‘my_to_grp’ in 40 ns. Timing Analyzer will still calculate the clock skew from source group to destination group, but at a lower priority (if the clocks are related). Predefined groups can be used, for example:
TIMESPEC TS_F2F = FROM FFS TO FFS 40 ns;
If we need leave out the time unit (ns, ps, etc…), then the tools presume ns:
TIMESPEC TS_P2P = FROM PADS TO PADS 30;
You can leave FROM or TO off of the constraint and make it more generic:
TIMESPEC TS_2P = TO PADS 40;
All of the FROM:TO constraints in the examples above would be of higher priority than the PERIOD constraint.
TSI Report
The TSI report is generated with the ‘-tsi design.tsi’ switch in the TRCE command line, or by specifying the option in the timing analyzer. If a user does not see a path under the correct constraint, this is the best place to start. This report will also make suggestions on ways to improve constraints in the universal constraints file (UCF). This report will also notify the user of any paths that are constrained by multiple clock domains:
Example 3
Constraint Interaction Report
=============================
Constraint interactions for TS_clk0_1 = PERIOD TIMEGRP "clk0_1" TS_clk HIGH 50%;
1 paths removed by TS_my_fromto = MAXDELAY FROM TIMEGRP "my_to_grp" TO TIMEGRP "FFS" 40 ns;
Analysis of Example 3
In other words, the FROM:TO constraint (just one) was applied ahead (higher priority) of the PERIOD constraint.
Next time we will discuss setup and hold.
Austin Lesea
References
Constraints Guide: Constraint Syntax for UCF, PCF, and HDL:
http://www.xilinx.com/support/documentation/sw_man
Timing Constraints User Guide: Conceptual information on how to constrain a design:
http://www.xilinx.com/support/documentation/sw_man
Timing Analyzer Help: General information on how to use timing analyzer:
http://www.xilinx.com/support/documentation/sw_man
Some Basics
Timing constraints apply to nets or networks, the path or paths taken from one element to all of the inputs of subsequent elements. One can also call out a specific path that is part of a net or network.
Every design should have at least one period constraint that specifies the clock and the duty cycle of the clock. A clock is always required for synchronous design, and so the period constraint is the most basic and is always a required constraint for any design. If there is more than one clock, each requires its own period constraint.
The period constraint will define how all nets must be routed in order to meet the timing requirements for proper operation.
A group may be defined to generically refer to many nets or paths of a selected set, such as a bus or control group.
Priority
When it comes to having many constraints for a design the following applies: the more general the constraint, the lower its priority, and, conversely, the more specific a constraint, the higher the priority. For example, a period constraint on a clock net or network is very general and will be over-ruled by a from:to constraint on a specific net or network.
The specific constraint for the from:to (or from:thru:to) is deemed more important than the more general constraint for any net within a clock domain.
There is a timing specification interaction report (the .tsi report) that details how the constraints interact. Select this option in the timing analyzer for reporting if you have a set of constraints, and you need to know how they are interacting and which priorities have been set.
One can override the assumed priorities and manually set the priority of any timing constraint. The use of the priority command allows setting a very low priority, such as 0, or even a negative priority, such as -10, which will be evaluated with an even higher priority than 0.
Example 1
The PERIOD constraint only covers nets from Synchronous Elements to Synchronous Elements, such as FFS to FFS, as shown in blue below:
NET "clk20" TNM_NET = “tnm_clk20";
TIMESPEC "TS_clk20" = PERIOD “tnm_clk20" 20 ns HIGH 50 %;
A TIMEGRP (timing group) is created called tnm_clk20 which contains all of the downstream synchronous components that net clk20 drives. All of the paths between these synchronous elements are then constrained with the timing specification TS_clk20, which specifies a 20 ns requirement from synchronous element to synchronous element and a HIGH 50% (clk20 has a 50/50 duty cycle).
Example 2
FROM:TO constraints are used to define a requirement for paths that go between two groups.
TIMESPEC TS_my_fromto = FROM my_from_grp TO my_to_grp 40 ns;
tells the tools that you need to ensure that data makes it from the components in the timing group ‘my_from_grp’ to ‘my_to_grp’ in 40 ns. Timing Analyzer will still calculate the clock skew from source group to destination group, but at a lower priority (if the clocks are related). Predefined groups can be used, for example:
TIMESPEC TS_F2F = FROM FFS TO FFS 40 ns;
If we need leave out the time unit (ns, ps, etc…), then the tools presume ns:
TIMESPEC TS_P2P = FROM PADS TO PADS 30;
You can leave FROM or TO off of the constraint and make it more generic:
TIMESPEC TS_2P = TO PADS 40;
All of the FROM:TO constraints in the examples above would be of higher priority than the PERIOD constraint.
TSI Report
The TSI report is generated with the ‘-tsi design.tsi’ switch in the TRCE command line, or by specifying the option in the timing analyzer. If a user does not see a path under the correct constraint, this is the best place to start. This report will also make suggestions on ways to improve constraints in the universal constraints file (UCF). This report will also notify the user of any paths that are constrained by multiple clock domains:
Example 3
Constraint Interaction Report
=============================
Constraint interactions for TS_clk0_1 = PERIOD TIMEGRP "clk0_1" TS_clk HIGH 50%;
1 paths removed by TS_my_fromto = MAXDELAY FROM TIMEGRP "my_to_grp" TO TIMEGRP "FFS" 40 ns;
Analysis of Example 3
In other words, the FROM:TO constraint (just one) was applied ahead (higher priority) of the PERIOD constraint.
Next time we will discuss setup and hold.
Austin Lesea
References
Constraints Guide: Constraint Syntax for UCF, PCF, and HDL:
http://www.xilinx.com/support/documentation/sw_man
Timing Constraints User Guide: Conceptual information on how to constrain a design:
http://www.xilinx.com/support/documentation/sw_man
Timing Analyzer Help: General information on how to use timing analyzer:
http://www.xilinx.com/support/documentation/sw_man
Message Edited by austin.lesea on 12-22-2009 09:48 AM
Comments
You must be a registered user to add a comment here. If you've already registered, please log in. If you haven't registered yet, please register and log in.
