UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
208 Views
Registered: ‎03-31-2019

xdc propagation

Jump to solution

Hi... i have question about propgating method XDC constraint in vivado.

 

Here is some example. I have user defined IP which have two clock domain.

 

One is I_CLK250 and the others is I_CLK390.

 

When i make this IP, i creates timing.xdc and timing_occ.xdc file.

 

Only timing_occ.xdc have contents, timing.xdc is empty.

 

In timing_occ.xdc, create_clock and set_clock_groups properties are defiend like below


-------------------------------------------------------------------------------

create_clock -name I_CLK250 -period 4 [get_ports I_CLK250]
create_clock -name I_CLK390 -period 2.56 [get_ports I_CLK390]

set_clock_groups -asynchronous -group {I_CLK250} -group {I_CLK390}

-------------------------------------------------------------------------------

When another project uses this packaged IP(user defined IP) by delivering I_CLK250 and I_CLK390, is the constraint properties in timing_occ.xdc ignored?

 

If so, how can i deliver the fact CLK250 and I_CLK390 are asynchronous clock group to compiler?

 

If there is some document guding constraint setting or describing constraint propagation mechanism, please let me know.

 

Thanks.

 

 

 

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
183 Views
Registered: ‎01-23-2009

Re: xdc propagation

Jump to solution

This has nothing to do with "propagation", but about how IP is supposed to interact with the system.

Most IP is synthesized "out-of-context (OOC)" which means that it is synthesized in its own synthesis run - separate from any design that the IP may eventually be integrated into. Since synthesis is timing driven, this OOC synthesis run needs constraints that tell it something about the environment in which the IP is going to be used. The most obvious examples of this are clocks - the clocks are simply input ports to the IP - without a "create_clock" attached to these ports, the OOC synthesis run has no information with which to perform synthesis optimization.

So, for OOC synthesis, you have the *_ooc.xdc file. This would contain both external clocks, and, if necessary, set_input_delay/set_output_delay commands for the data inputs and outputs of the IP.

When an IP block is integrated into a system (for example for top level place and route), then the IP is now part of the overall system. The clock ports of the IP are now connected to wires at the top level. These wires are what bring the clock into the IP, and hence the ports should not have clock constraints attached to them - that would override the clocks coming in from the system. If the system (outside the IP) is properly constrained, then these wires will carry clocks into the IP.

In addition to the OOC constraints, an IP may require "real" constraints - constraints that apply both to the IP when it is synthesized OOC as well as to the IP when it is integrated into the top level system. These would not be placed in the _ooc.xdc, but in the <block>.xdc file. These would typically include internal timing exceptions (set_multicycle_path, set_max_delay, set_false_path, set_clock_groups).

For constraints in this file, they need to be written carefully so that that they work both when the IP is synthesized OOC and when the IP is integrated in the top level system. For example (and see below for my warnings!) if you wanted to indicate that two clocks in the IP are asynchronous via a set_clock_groups command (again, I do not recommend this) then you would have to write them in a way that doesn't use anything specific to either of the two environments. For example, in your case, your OOC constraints would create primary clocks named I_CLK250 and I_CLK390, but in the real system, the clocks that are coming in on the I_CLK250 and I_CLK390 ports could/would have different names - therefore you couldn't just use the name of the clocks in the set_clock_groups command.

So, the only thing you know about the clocks in the two environments is that they exist on the ports I_CLK250 and I_CLK390 - we don't necessarily know what they are named (well, we do in the OOC case, but not when the IP is integrated). Fortunately, this is enough - we can tell the tool that the clocks connected to these ports no matter how they got there are asynchronous using the command

set_clock_groups -asynchronous -group [get_clocks -of_objects [get_ports I_CLK250]] -group [get_clocks -of_objects [get_ports I_CLK390]]

BUT!!!!

This is a very dangerous command - it is telling the tool that the two clocks connected to these ports (however they are created) are asynchronous - this means that all paths between them are false. The clocks in question are global to the design - this means that all paths between these clocks anywhere in the design are false paths. This may or may not be true, and it is certainly not safe to assume that it is. Furthermore, since the set_clock_groups command has the highest constraint priority, this means that it is impossible to put any constraints on paths between these two clocks anywhere in the design. So even if the top level design has proper clock domain crossing circuits (CDCCs) between these two clocks, these CDCCs will now be unconstrained because this command will override the constraints associated with this CDCC, and hence it may fail.

Take a look at this post on constraints, constraint priority and on underconstraining CDCCs (and the posts that are referenced therein).

Avrum

0 Kudos
2 Replies
Historian
Historian
184 Views
Registered: ‎01-23-2009

Re: xdc propagation

Jump to solution

This has nothing to do with "propagation", but about how IP is supposed to interact with the system.

Most IP is synthesized "out-of-context (OOC)" which means that it is synthesized in its own synthesis run - separate from any design that the IP may eventually be integrated into. Since synthesis is timing driven, this OOC synthesis run needs constraints that tell it something about the environment in which the IP is going to be used. The most obvious examples of this are clocks - the clocks are simply input ports to the IP - without a "create_clock" attached to these ports, the OOC synthesis run has no information with which to perform synthesis optimization.

So, for OOC synthesis, you have the *_ooc.xdc file. This would contain both external clocks, and, if necessary, set_input_delay/set_output_delay commands for the data inputs and outputs of the IP.

When an IP block is integrated into a system (for example for top level place and route), then the IP is now part of the overall system. The clock ports of the IP are now connected to wires at the top level. These wires are what bring the clock into the IP, and hence the ports should not have clock constraints attached to them - that would override the clocks coming in from the system. If the system (outside the IP) is properly constrained, then these wires will carry clocks into the IP.

In addition to the OOC constraints, an IP may require "real" constraints - constraints that apply both to the IP when it is synthesized OOC as well as to the IP when it is integrated into the top level system. These would not be placed in the _ooc.xdc, but in the <block>.xdc file. These would typically include internal timing exceptions (set_multicycle_path, set_max_delay, set_false_path, set_clock_groups).

For constraints in this file, they need to be written carefully so that that they work both when the IP is synthesized OOC and when the IP is integrated in the top level system. For example (and see below for my warnings!) if you wanted to indicate that two clocks in the IP are asynchronous via a set_clock_groups command (again, I do not recommend this) then you would have to write them in a way that doesn't use anything specific to either of the two environments. For example, in your case, your OOC constraints would create primary clocks named I_CLK250 and I_CLK390, but in the real system, the clocks that are coming in on the I_CLK250 and I_CLK390 ports could/would have different names - therefore you couldn't just use the name of the clocks in the set_clock_groups command.

So, the only thing you know about the clocks in the two environments is that they exist on the ports I_CLK250 and I_CLK390 - we don't necessarily know what they are named (well, we do in the OOC case, but not when the IP is integrated). Fortunately, this is enough - we can tell the tool that the clocks connected to these ports no matter how they got there are asynchronous using the command

set_clock_groups -asynchronous -group [get_clocks -of_objects [get_ports I_CLK250]] -group [get_clocks -of_objects [get_ports I_CLK390]]

BUT!!!!

This is a very dangerous command - it is telling the tool that the two clocks connected to these ports (however they are created) are asynchronous - this means that all paths between them are false. The clocks in question are global to the design - this means that all paths between these clocks anywhere in the design are false paths. This may or may not be true, and it is certainly not safe to assume that it is. Furthermore, since the set_clock_groups command has the highest constraint priority, this means that it is impossible to put any constraints on paths between these two clocks anywhere in the design. So even if the top level design has proper clock domain crossing circuits (CDCCs) between these two clocks, these CDCCs will now be unconstrained because this command will override the constraints associated with this CDCC, and hence it may fail.

Take a look at this post on constraints, constraint priority and on underconstraining CDCCs (and the posts that are referenced therein).

Avrum

0 Kudos
152 Views
Registered: ‎03-31-2019

Re: xdc propagation

Jump to solution

Thanks for your reply.

 

It is very useful contents.

 

Due to your reply, I can cover what i wonder.

 

Thanks

0 Kudos