Introduction to Common Timing Constraints Based on ISE UCF Syntax

In This Article -> Basic Concept Introduction -> Factors Affecting Delay -> Three Conditions, we introduced the impact of environmental factors on timing analysis. By default, the timing analysis tool that comes with ISE usually adopts the maximum condition for analysis, but we can also define our desired environmental factors through timing environmental constraints, for example:

TEMPERATURE = 85 C;

VOLTAGE = 0.95 V;

Before introducing the timing constraints that describe specific situations, let’s first briefly understand some basic grouped timing constraint syntax provided by ISE. Because even if your FPGA design is very simple, you cannot simply add timing constraints element by element, right? If we can establish groups first, grouping common elements together, and then uniformly adding timing constraints, it will greatly simplify our workload.

TNM is the most basic grouping constraint syntax, and its syntax definition is as follows:

{NET|INST|PIN} “net_or_pin_or_inst_name” TNM = [predefined_group] identifier;

1

As can be seen, the starting keyword for TNM can be one of three—NET (network), INST (instance), PIN (port). The NET keyword is used to indicate a network grouping, which automatically includes all elements connected to the network name specified in “net_or_pin_or_inst_name”; the INST keyword indicates an instance, limiting the search scope for this group; PIN refers to a port, indicating a specific pin of a primitive.

The predefined_group is an optional parameter; when not specified, the group includes all possible elements; if specified, the group only includes elements of the [predefined_group] type. For ISE software, the predefined groups are approximately as follows:

FFS: Flip-flop group;

RAMs: Memory group;

LATCHES: Latch group;

PADS: Pad group;

CPUS: Processor group;

HSIOS: High-speed IO group;

MULTS: Multiplier group.

Finally, the identifier specifies the name of the group for later syntax calls.

TNM_NET is also a basic grouping constraint syntax, and its syntax definition is as follows:

{NET|INST} “net_name” TNM_NET = [predefined_group] identifier;

1

The TNM_NET grouping definition syntax is almost the same as TNM, with two differences:

1. TNM_NET can only define groups based on networks;

2. The network name specified by TNM_NET can spread downstream through primitives such as IBUF and BUFG when selecting group members, while TNM cannot. Therefore, TNM_NET is usually used to specify groups for the pad section of FPGA chips.

TIMEGRP

TIMEGRP is a syntax keyword for operating on groups. We can use this keyword to union, difference, or specify clock edges for groups, for example:

TIMEGRP “ffs123” = “ffs1” “ffs2” “ffs3”; # Merge three groups into one group

TIMEGRP “G1D2” = “G1” EXCEPT “G2”; # Define a group containing all elements belonging to “G1” but not belonging to “G2”

TIMEGRP “group1″=RISING FFS; # Define a group sensitive to the rising edge of the FFS group

TIMEGRP “group2″=FALLING FFS; # Define a group sensitive to the falling edge of the FFS group

Note that for the timing analysis tool in ISE, it is okay to use or not use double quotes for group names or signal names in timing constraint information. Additionally, the comment symbol in UCF files is “#”.

For FPGA designs, commonly used timing constraints can basically be divided into four types, which are introduced as follows:

Period Constraints

Period constraints, also known as clock constraints, are mainly used to specify relevant constraints for clock signals, using the keyword PERIOD. Its basic syntax is defined as follows:

TIMESPEC “TS_name” = PERIOD “TNM_name”{HIGH|LOW} [high_or_low_time] [INPUT_JITTER value];

1

Where,

TIMESPEC “TS_name” defines an identifier for this period constraint that can be called elsewhere.

“TNM_name” specifies the timing group covered by this period constraint.

Specifies the clock cycle value for this period constraint.

{HIGH|LOW} indicates whether the corresponding clock signal starts at a high level (or rising edge) or at a low level (or falling edge) at time 0.

[high_or_low_time] is for {HIGH|LOW}, indicating the duration of the starting level of the clock signal, similar to the concept of duty cycle, so it can also be expressed as a percentage, meaning the proportion of the starting level in the entire cycle.

[INPUT_JITTER value] specifies that the corresponding clock signal has a certain input jitter.

Input Clock Cycle Constraints

To perform timing analysis on a clock domain driven by an input clock, you first need to define a group to be analyzed, and then use the TIMESPEC syntax to specify and name a period constraint, for example:

NET “clk50MHz” TNM_NET = “clkIn”;

TIMESPEC “TS_clkIn” = PERIOD “clkIn” 20.0 ns HIGH 50%;

In the above example, the first statement adds all elements connected to the clk50MHz port network to the clkIn group. The second statement specifies the clock information for this clock domain, indicating that a period constraint named TS_clkIn has been defined, with a period of 20ns, starting at a high level, and a duty cycle of 50%.

Of course, in addition to using percentages to indicate the level duty cycle parameter, you can also directly specify the level duration. For example, the second statement above can also be rewritten as:

TIMESPEC “TS_clkIn” = PERIOD “clkIn” 20.0 ns HIGH 10.0 ns;

If the clock signal in this clock domain has 2ns of jitter, then the second statement can be rewritten as:

TIMESPEC “TS_clkIn” = PERIOD “clkIn” 20 ns HIGH 50% INPUT_JITTER 2 ns;

Internal Clock Cycle Constraints

Internal clock cycle constraints are essentially no different from input clock cycle constraints; they both add period constraints to the corresponding clock network. However, one thing needs special attention:

Input clock cycle constraints target input clock signals that are introduced into the FPGA through an input pin. If we bind this pin to the input port clk of the FPGA top-level entity, then regardless of synthesis, layout, or routing, using the name clk can always find the corresponding clock network because there is nothing to optimize or rename about this clock input port.

However, if you want to constrain an internal clock signal, and if the name of that signal in the HDL file is clk25MHz, and you define the following group constraint:

NET “clk25MHz” TNM_NET = “innerClk”;

The timing analysis tool will almost 100% report that it cannot find a network named clk25MHz because it is almost certain to be optimized or renamed. For such cases, there are usually three solutions:

1. Use the timing constraint creation tool of the built-in timing analysis tool in ISE to create the constraint for this clock. Typically, ISE will analyze which clock signals it has internally and provide the source network name for each clock signal. You can use this name to speculate whether this network corresponds to the clock network with a similar name clk25MHz in your HDL code, and then create a group constraint using that network name.

2. Use the keep syntax in synthesis constraints to prevent the clk25MHz network name from being optimized away.

3. Check the netlist file of the FPGA design after synthesis and conversion, find the network name that may correspond to clk25MHz, and then create a group constraint using that network name. (Reading the netlist process can be painful!)

Of course, for a verification team, to add pure timing analysis constraints for internal clocks, the only solution might be to adopt solution 3.

Related Clock Cycle Constraints

Related clock cycle constraints are mainly used to handle two situations: first, if there is information passing between two clock domains, and we want to perform timing analysis on this; second, if one clock signal is generated by another clock signal, there is a strong correlation between the two.

For example, for a DCM module, its input comes from a pin called clk50MHz. We can define the period constraint for this clock network as follows:

NET “clk50MHz” TNM_NET = “clkIn”;

TIMESPEC “TS_clkIn” = PERIOD “clkIn” 20 ns HIGH 50%;

If it has a same-phase 2x frequency output clock, with the corresponding network name clk2x, we can define the timing constraint for the network driven by this output clock as follows:

NET “clk2x” TNM_NET = DCM2xOut;

TIMESPEC TS_DCM2xOut = PERIOD “DCM2xOut” TS_clkIn / 2 HIGH 50%;

For the DCM’s 180-degree phase-shifted 2x frequency output clock, if its corresponding network name is clk2x180, we can define the timing constraint for the network driven by this output clock as follows:

NET “clk2x180” TNM_NET = DCM2x180Out;

TIMESPEC TS_DCM2x180Out = PERIOD “DCM2x180Out” TS_clkIn / 2 PHASE 5 ns HIGH 50%;

Differential Clock Cycle Constraints

If the input clock signal is differential, you only need to add a period constraint to one of the ports in the differential pair. To make it easier to understand, you should add a period constraint to the p port network of the differential clock.

Input Constraints

Input constraints mainly target synchronous input interfaces or virtual synchronous input interfaces, using the “OFFSET = IN” keyword to describe the relationship between input data and clock. Its basic syntax is defined as follows:

[{TIMEGRP|NET} “iobgroup_or_padnet_name”] OFFSET = IN[units] [VALID] {BEFORE|AFTER} “clk_name” [TIMEGRP “group_name”] {HIGH|LOW};

1

Where,

[{TIMEGRP|NET} “iobgroup_or_padnet_name”] can specify a network or a group for this input constraint (note that the network must be connected to the pad, and the group must be related to the IO block); if omitted, the scope of this constraint is global (applies to all input ports related to the clock “clk_name”).

It is an offset of the data arrival time relative to the initial edge of the dependent clock. Of course, the specific initial edge of this clock is determined by the period constraint related to that clock, based on which of the HIGH or LOW keywords is used in that period constraint.

[VALID] specifies the stable period of the data signal, i.e., the time for which the signal remains stable.

{BEFORE|AFTER} indicates whether the valid data described in this constraint should be sampled by the current clock event or by subsequent clock events. If the BEFORE keyword is used, it indicates that the valid data starts based on the clock event that samples it, providing an advance; if the AFTER keyword is used, it indicates that the valid data starts based on the previous clock event, providing a delay. Of course, it can also be negative, and which keyword to use depends entirely on personal description habits; there is no essential difference between them.

“clk_name” specifies which clock event’s initial edge this input constraint is relative to.

[TIMEGRP “group_name”] specifies a necessary internal group for analysis; if omitted, it indicates all elements related to the current clock sampling.

{HIGH|LOW} is used to rewrite the initial edge of “clk_name”; it can change the period constraint’s setting of the initial edge of the clock related to “clk_name”. HIGH and LOW indicate setting the rising edge and falling edge of the clock as the initial edge at time 0, respectively.

SDR Input Constraints

Please refer to Programming Chapter -> Programming Ideas -> Programming Ideas for External Interfaces -> Classified by Clock Characteristics -> Synchronous Interface -> SDR for the concept of SDR.

Since it is a synchronous interface, we must first define a period constraint for the synchronous clock, for example:

NET “clk” TNM_NET = clk50MHz;

TIMESPEC TS_clk = PERIOD “clk50MHz” 20 ns HIGH 50%;

Then, we can use the “OFFSET = IN” syntax to indicate the relationship between the data and the clock when the SDR interface is input, for example:

OFFSET = IN 10 ns VALID 20 ns BEFORE clk;

Since this statement does not specify a specific input port, its effect is global, meaning it applies to all input ports related to the clk clock sampling. However, if different data ports have different relationships with the clock, it is necessary to specify input constraints individually for each input port, for example:

NET “dIn<0>” OFFSET = IN 20 ns VALID 20 ns BEFORE “clk”;

NET “dIn<1>” OFFSET = IN 10 ns VALID 20 ns BEFORE “clk”;

If multiple input ports have the same relationship with the clock signal, you can define input constraints in a grouped manner, for example:

NET “dIn<0>” TNM = dInG;

NET “dIn<1>” TNM = dInG;

TIMEGRP “dInG” OFFSET = IN 20 ns VALID 20 ns BEFORE “clk”;

DDR Input Constraints

Please refer to Programming Chapter -> Programming Ideas -> Programming Ideas for External Interfaces -> Classified by Clock Characteristics -> Synchronous Interface -> DDR for the concept of DDR.

Similarly, since it is a synchronous interface, we must first define a period constraint for the synchronous clock, for example:

NET “clk” TNM_NET = clk50MHz;

TIMESPEC TS_clk = PERIOD “clk50MHz” 20 ns HIGH 50%;

Then, we can use the “OFFSET = IN” syntax to indicate the relationship between the data and the clock for the DDR interface when inputting, for example:

OFFSET = IN 5 ns VALID 10 ns BEFORE “clk” RISING;

OFFSET = IN 5 ns VALID 10 ns BEFORE “clk” FALLING;

These two lines of syntax indicate that both clock edges correspond to the required sampled data in the middle. Note that in the above example, the keywords RISING and FALLING are added; they can not only indicate that the offset time is 5ns but also specify whether it is relative to the rising edge or falling edge of the clock network clk. More importantly, they can indicate the scope of this input constraint—RISING represents analyzing all input groups sampled at the rising edge, while FALLING represents analyzing all input groups sampled at the falling edge. For this reason, even though these two statements target the same input ports, they do not overwrite each other. For example, if we mistakenly replace the RISING and FALLING keywords with the HIGH and LOW keywords as follows:

OFFSET = IN 5 ns VALID 10 ns BEFORE “clk” HIGH; #Wrong for DDR

OFFSET = IN 5 ns VALID 10 ns BEFORE “clk” LOW; #Wrong for DDR

Since the above two statements target the same group (all input elements related to clk), the one written first will be overwritten by the latter.

Because of the group characteristics of RISING and FALLING, if in the SDR interface, the internal logic itself is sensitive to the rising edge, but if you specify the position relationship between data and clock using FALLING, the timing analysis tool will tell you that 0 paths, 0 ports, etc., were analyzed. At this point, if you insist on using the falling edge as the reference edge, please use the LOW keyword.

Another method for adding timing constraints for DDR interfaces is to use internal groups. For example, to achieve the same constraints as the first method, you can first define two groups corresponding to the rising edge sensitive elements and the falling edge sensitive elements, and then specify input constraints for them, described as follows:

TIMEGRP “ClkIn_Rising” = RISING “clk50MHz”;

TIMEGRP “ClkIn_Falling” = FALLING “clk50MHz”;

OFFSET = IN 5 ns VALID 10 ns BEFORE clk TIMEGRP ClkIn_Rising;

OFFSET = IN -5 ns VALID 10 ns BEFORE clk TIMEGRP ClkIn_Falling;

MDR Input Constraints

Please refer to Programming Chapter -> Programming Ideas -> Programming Ideas for External Interfaces -> Classified by Clock Characteristics -> Synchronous Interface -> MDR for the concept of MDR.

Similarly, since it is a synchronous interface, we must first define a period constraint for the synchronous clock, for example:

NET “clk” TNM_NET = clk50MHz;

TIMESPEC TS_clk = PERIOD “clk50MHz” 20 ns HIGH 50%;

Since MDR is often received in SDR or DDR mode, if SDR mode is actually used, we only need to sample one data to continuously collect all data; if DDR mode is actually used, we only need to sample two consecutive data to continuously collect all data.

Next, let’s take an example of an MDR with a clock data ratio of 1:4, where the data change edge is aligned with the clock change edge, to see how to describe its input constraints:

First, let’s see how to implement MDR sampling in SDR mode. If we internally use DCM (or PLL) to generate a 4x frequency, same-phase clock signal, with the network name clk4x, we should first add the period constraint for the generated clock as follows:

NET “clk4x” TNM_NET = DCM4xOut;

TIMESPEC TS_ DCM4xOut = PERIOD “DCM4xOut” TS_clk / 4 HIGH 50%;

Since clk4x is a related clock to clk, the timing analysis tool will automatically analyze the cross-clock domain issues, so we only need to provide a data sampling input constraint based on clk as follows:

OFFSET = IN 5 ns VALID 5 ns BEFORE clk;

In fact, since UCF files are added to ISE before layout and routing, ISE will automatically generate associated period constraints for the outputs of DCM or PLL during compilation, so the period constraint for clk4x can be omitted.

Next, let’s see how to implement MDR sampling in DDR mode. At this time, since the specific sampling clock is not clk, we cannot use the method one described in DDR Input Constraints. However, if we want to use method two, we must establish two edge groups for the specific sampling clock. Therefore, we first add the associated clock constraint for the output pin of the DCM as follows:

PIN “instance_name/DCM_ADV_INST.CLK2X” TNM_NET = clk100MHz;

TIMESPEC TS_clk100MHz = PERIOD “clk100MHz” TS_clk / 2 HIGH 50%;

Then, we can define the two edge groups for the DDR sampling clock as follows:

TIMEGRP “Clk2x_Rising” = RISING “clk100MHz”;

TIMEGRP “Clk2x_Falling” = FALLING “clk100MHz”;

Finally, based on the clk signal, we describe the two consecutive samples and associate them with the above two groups as follows:

OFFSET = IN 5 ns VALID 5 ns BEFORE clk TIMEGRP Clk2x_Rising;

OFFSET = IN -5 ns VALID 5 ns BEFORE clk TIMEGRP Clk2x_Falling;

In fact, since UCF files are added to ISE before layout and routing, ISE will automatically generate associated period constraints for the outputs of DCM or PLL during compilation, so the following statement can be omitted:

TIMESPEC TS_clk100MHz = PERIOD “clk100MHz” TS_clk / 2 HIGH 50%;

Differential Input Constraints

If the input data for the interface is in differential form, then when creating the input group, you need to add them all in and then add input constraints together.

Inter-group Constraints

Inter-group constraints use the “FROM…TO” keyword to describe the delay between two timing groups. Its basic syntax is defined as follows:

TIMESPEC “TS_name”=FROM “group1” TO “group2” [DATAPATHONLY];

Where,

TIMESPEC “TS_name” defines an identifier for this path constraint that can be called elsewhere.

group1 is the starting group of the path.

group2 is the destination group of the path.

Indicates the maximum allowable range of delay between groups. You do not need to specify the minimum allowable range, as the timing analysis tool will automatically report the maximum and minimum time differences between the starting group and the destination group.

[DATAPATHONLY] is an optional parameter; if given, it indicates that the current inter-group constraint will not consider the effects of clock skew, phase difference, etc., but only the data path delay between groups.

Pad-to-Pad Path Constraints

When there are irreducible pure combinational logic interfaces in the FPGA design, there will be timing paths from pad to pad, at which point the pad-to-pad path constraints will take effect. You can directly use the predefined group PADS to impose timing constraints on all pad-to-pad paths, described as follows:

TIMESPEC “TS_P2P” = FROM “PADS” TO “PADS” 20 ns;

At this point, the DATAPATHONLY keyword does not matter, as pad-to-pad is inherently a pure data path delay. If you want to add different pad-to-pad path constraints between different pads, you need to create custom starting pad groups and destination pad groups first, and then add constraints, for example:

TIMEGRP “dInG” = PADS(“a” “b”);

TIMEGRP “dOutG” = PADS(“c”);

TIMESPEC “TS_AB2C” = FROM “dInG” TO “dOutG” 20 ns;

Multi-Cycle Path Constraints

Under the effect of periodic constraints, the timing analysis tool will assume that the outputs of registers in the same clock domain change with each clock event. Therefore, ideally, the hold time for each register is one clock cycle. However, sometimes the functional characteristics of the FPGA design determine that the preceding register needs to undergo several clock cycles before changing. In this case, if only periodic constraints are added to this clock domain, it would obviously over-constrain this part of the circuit. If the logic of this part of the circuit is relatively simple, over-constraining may not cause major issues; but if the logic is relatively complex, over-constraining may lead to timing analysis failures. Therefore, to correctly add timing constraints to this part of the logic, multi-cycle path constraints need to be used, for example:

NET “clk” TNM_NET = clk50MHz;

TIMESPEC TS_clk50MHz = PERIOD “clk50MHz” 20 ns HIGH 50%;

INST “b1” TNM = gb1;

INST “b2” TNM = gb2;

TIMESPEC TS_MultiPath = FROM gb1 TO gb2 TS_clk50MHz * 2;

In timing constraints, more specific constraints take precedence over broader constraints; therefore, although the above example initially adds periodic constraints to all clk50MHz groups, the subsequent multi-cycle path constraint changes the period constraint between b1 and b2 to a multi-cycle path constraint of 2 times.

Cross-Clock Domain Path Constraints

If two clocks are not related, by default, the timing analysis tool will not analyze such cross-clock domain situations. However, when there is indeed information passing between them, and you care about some time delays, you can use cross-clock domain path constraints. For example:

NET “clk1” TNM_NET = clkA1;

TIMESPEC TS_clkA1 = PERIOD “clkA1” 20 ns HIGH 50%;

NET “clk2” TNM_NET = clkA2;

TIMESPEC TS_clkA2 = PERIOD “clkA2” 15 ns HIGH 50%;

TIMESPEC TS_CCR = FROM clkA1 TO clkA2 10 ns;

The two periodic constraint descriptions in the above example can be omitted, as they are written only to indicate that these two clocks are indeed unrelated. If you only care about the data path delay between the two clock domains, you can change the cross-clock domain path constraints in the above example to:

TIMESPEC TS_CCR = FROM clkA1 TO clkA2 10 ns DATAPATHONLY;

In this case, the timing analysis tool will not consider clock skew and other factors during analysis, even if clk1 and clk2 are related clocks.

Cross-Clock Domain Ignore Constraints

If two clocks are indeed related, such as multiple outputs of DCM or PLL and their inputs, or the rising and falling edges of a clock signal, but we do not want the timing analysis tool to analyze the cross-clock domain between them, we can use cross-clock domain ignore constraints. For example:

NET “clk1” TNM_NET = clkA1;

TIMESPEC TS_clkA1 = PERIOD “clkA1” 20 ns HIGH 50%;

NET “clk2” TNM_NET = clkA2;

TIMESPEC TS_clkA2 = PERIOD “clkA2” TS_clkA1/2 HIGH 50%;

TIMESPEC TS_FastPath = FROM clkA1 TO clkA2 TIG;

In the above example, by using the TIG keyword in the inter-group constraint, the timing analysis tool will not analyze the delay from clkA1 to clkA2. If you also want to avoid analyzing the delay from clkA2 to clkA1, you need to add another description as follows:

TIMESPEC TS_FastPath = FROM clkA2 TO clkA1 TIG;

If you only want to ignore a portion of the signal transmission between two clock domains, you can first define groups and then use cross-clock domain ignore constraints. Continuing from the above example, if you want to ignore the analysis of the cross-clock domain from aLock in the clk1 clock domain to c in the clk2 clock domain, you can describe it as follows:

INST “aLock” TNM = ta;

INST “c” TNM = tc;

TIMESPEC TS_FastPath = FROM ta TO tc TIG;

Path Intermediate Point Constraints

Sometimes, what you care about may not just be the maximum and minimum cases of the total path delay between two timing groups, but rather the maximum and minimum cases of the path delay between two timing groups through a certain relay point or group. In this case, you can use the THRU keyword to specify that relay group. For example:

NET “a_3_IBUF” TPTHRU = “ta”;

TIMESPEC “TS_P2P” = FROM “PADS” THRU “ta” TO “PADS” 20 ns;

The above example only analyzes the path delay between pads that pass through the ta group.

Output Constraints

Output constraints mainly target output interfaces, using the “OFFSET = OUT” keyword to describe some basic timing requirements for output interfaces. Its basic syntax is defined as follows:

[{TIMEGRP|NET} “iobgroup_or_padnet_name”] OFFSET = OUT[units] {BEFORE|AFTER} “clk_name” [TIMEGRP “group_name”] {HIGH|LOW};

Where,

[{TIMEGRP|NET} “iobgroup_or_padnet_name”] can specify a network or a group for this output constraint (note that the network must be connected to the pad, and the group must be related to the IO block); if omitted, the scope of this constraint is global (applies to all output ports related to the clock “clk_name”).

“clk_name” specifies which clock event’s initial edge this output constraint is relative to; note that “clk_name” is the name of an input clock, not an output clock; more accurately, it is the driving clock for the register connected to the output port inside the FPGA.

{BEFORE|AFTER}, [TIMEGRP “group_name”], {HIGH|LOW} have the same explanation as in input constraints.

It can be seen that the output constraints in ISE are not very intelligent; by using the “OFFSET = OUT” keyword, they can only describe whether the timing delay of the output port relative to its driving clock can meet some basic requirements. Therefore, for synchronous output interfaces, the built-in timing analysis tool in ISE cannot directly provide analysis results. Next, we will introduce how to indirectly obtain the timing report for synchronous output ports using the timing analysis tool.

Direct Synchronous Output Constraints

Direct synchronous output corresponds to the situation described in This Article -> Timing Analysis Principles -> Other Common Logical Situations -> Pure Output Interface -> Pure Synchronous Output Interface. It can be seen that for such interfaces, ISE can only adopt the third method described in that section. That is, first obtain the relationship between clk and D signals under ideal conditions through functional simulation, and then obtain the maximum and minimum delays of clk and D signals during actual output, and then manually calculate the timing analysis results for that synchronous output interface.

If the internal clock’s period constraint is as follows:

NET “innerClk” TNM_NET = innerClk;

TIMESPEC TS_innerClk = PERIOD “innerClk” 20 ns HIGH 50%;

Then, for that synchronous output interface, we need to first define the output constraint for data D, similar to the following:

NET “D<0>” TNM = gDout;

NET “D<1>” TNM = gDout;

NET “D<2>” TNM = gDout;

NET “D<3>” TNM = gDout;

NET “D<4>” TNM = gDout;

NET “D<5>” TNM = gDout;

NET “D<6>” TNM = gDout;

NET “D<7>” TNM = gDout;

TIMEGRP “gDout” OFFSET = OUT 20 ns AFTER “innerClk”;

Then, referring to the method in Inter-group Constraints -> Pad-to-Pad Path Constraints, impose constraints between innerClk and clk, similar to:

TIMEGRP “gClkIn” = PADS(“innerClk”);

TIMEGRP “gClkOut” = PADS(“clk”);

TIMESPEC “TS_C2C” = FROM “gClkIn” TO “gClkOut” 20 ns;

In this way, the timing analysis tool will report the maximum and minimum delays of D and clk relative to the initial edge of innerClk at time 0, and finally combine the results of functional simulation to manually obtain the timing analysis report for that direct synchronous output interface.

Indirect Synchronous Output Constraints

Indirect synchronous output corresponds to the situation described in This Article -> Timing Analysis Principles -> Other Common Logical Situations -> Pure Output Interface -> Asynchronous Generation of Synchronous Output. Indirect synchronous output and direct synchronous output are similar in response methods; the only difference is that the output clock clk is also a data relative to innerClk. Therefore, we only need to change the inter-group constraint between innerClk and clk described in the Direct Synchronous Output Constraints section to an output constraint. Similar to:

NET “clk” TNM = gCout;

TIMEGRP “gCout” OFFSET = OUT 20 ns AFTER “innerClk”;

In this way, the timing analysis tool will report the maximum and minimum delays of D and clk relative to the initial edge of innerClk at time 0, and finally combine the results of functional simulation to manually obtain the timing analysis report for that indirect synchronous output interface.

Differential Output Constraints

If the output data for the interface is in differential form, then when creating the output group, you need to add them all in and then add output constraints together.