cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
6,392 Views
Registered: ‎07-29-2009

Best practice defining derived clock that will be overridden in IP

Jump to solution

I have an IP block I'm designing.  In order to ensure my coding style meets what I think will be the clock speed I need to define clocks using create_clock on two ports in an xdc.  This allows me to synthesize the IP and check timing. Now, when the IP is instantiated, I get a warning that I'm redefining a clock (which those ports are now connected to).  What's the RIGHT way to do what I describe so that I'm not "redefining" the clock once the IP is instantiated and uses the clock speed of the larger design?

 

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
10,753 Views
Registered: ‎01-23-2009

I see this: "Do not define clocks in the block-level constraints if they are expected to be created at
the top level of the design.
Instead they can be queried inside the block using the get_clocks -of_objects
command. This command returns all the clocks that traverse a particular object in the
design.
Example:
set blockClock [get_clocks -of_objects [get_ports clkIn]]"

But have NO idea what "blockClock" is other than a tcl variable...  how would one use that in the block to set a block-level minimum clock period?

 

This is specifically recommended because the clocks are different when doing OOC synthesis and top level implementation. The names and properties of the clocks are different. As a result, rather than using the names of the clocks (which aren't the same in both environments), we ask for "whatever clock is currently defined on this port". During OOC synthesis, this will be the clock defined in the <filename>_ooc.xdc. During top level implementation, this will be the clock that propagates from the top level.

 

The blockClock is a Tcl variable which is given the value of the clock that is attached to the port clkin. This allows you to write a single XDC file for the constraints other than the clock definition that need access to the clock being used in the module.

 

For example if your OOC module has a clock crossing circuit that needs to know the period of the clock, it can get it by

 

get_property PERIOD $blockClock

 

When synthesized OOC, this will be the period of the clock defined in the _ooc.xdc. When implemented at the top level, it will be the period of the top level clock.

 

These constraints will be put in a different constraint file (not the _ooc.xdc). During OOC synthesis, this constraint file will be included without the out_of_context flag (as opposed to the clock definitions that will use the out_of_context flag). Since it doesn't have the out_of_context flag it will be used when the sub-module is included in the top level design, and will use the clocks defined by the top level design.

 

Avrum

View solution in original post

Tags (2)
0 Kudos
10 Replies
Highlighted
Guide
Guide
6,384 Views
Registered: ‎01-23-2009

I'm not completely up to date on all the IP packaging techniques, but you probably want to look into "Out-of-context" constraints.

 

When you read in constraints as "out-of-context", these constraints are only used for the synthesis (or implementation) when the module is synthesized/implemented on its own. However, when the module is used as a child module of some other design, the out-of-context (OOC) constraints are not used (I have heard conflicting information as to whether the OOC constraints are not written into the .dcp file, or whether they are written, but are not used at the top level). In either case, the net results are the same; these constraints do not show up at the top level, and hence will not be overridden by your top level clock propagation.

 

In non-project mode, you can read in a constraint file with OOC constraints by doing

 

read_xdc -mode out_of_context <filename>.xdc

 

In project mode, it seems to be done by adding the word "out_of_context" to the "USED_IN" property. However, the support is somewhat odd - for example, if you declare a sub-module to be synthesized out-of-context, it automatically creates the <module>_ooc.xdc, adds it to the file list, and set the USED_IN properly, but the file doesn't show up in the hierarchy browser (anywhere), but it is part of the newly created fileset for the OOC module... (I think there may still be some "oddities" with the OOC mechanism in project mode...)

 

Avrum

Tags (2)
0 Kudos
Highlighted
Explorer
Explorer
6,357 Views
Registered: ‎07-29-2009

is readxdc compatible with:

add_files -fileset constrs_1 -norecurse ./top.xdc

???

0 Kudos
Highlighted
Explorer
Explorer
6,355 Views
Registered: ‎07-29-2009

By the way in UG903 it says "Timing clocks are defined by create_clock or create_generated_clock. They
are visible throughout the design regardless of the current instance setting."  So, i'm not sure your solution would work?

Tags (2)
0 Kudos
Highlighted
Explorer
Explorer
6,354 Views
Registered: ‎07-29-2009

I see this: "Do not define clocks in the block-level constraints if they are expected to be created at
the top level of the design.
Instead they can be queried inside the block using the get_clocks -of_objects
command. This command returns all the clocks that traverse a particular object in the
design.
Example:
set blockClock [get_clocks -of_objects [get_ports clkIn]]"

But have NO idea what "blockClock" is other than a tcl variable...  how would one use that in the block to set a block-level minimum clock period?

0 Kudos
Highlighted
Guide
Guide
6,341 Views
Registered: ‎01-23-2009

is readxdc compatible with:

add_files -fileset constrs_1 -norecurse ./top.xdc

???

 

No (or at least not really).

 

read_xdc is the non-project batch mode command

add_files is the project mode command

 

However, pre-synthesis, there really isn't such thing as non-project mode; synthesis always uses a project; either an explicit one (in project mode) or an "in memory" one in non-project batch mode. Given that, the read_xdc command may (or may not) work in project mode (but it isn't technically supported).

 

So, in project mode you would do

 

add_files -fileset constrs_1 -norecurse ./top.xdc

 

set_property USED_IN "out_of_context" top.xdc

 

This should set up a constraint file to be used OOC.

 

Avrum

 

Tags (1)
0 Kudos
Highlighted
Guide
Guide
6,341 Views
Registered: ‎01-23-2009

By the way in UG903 it says "Timing clocks are defined by create_clock or create_generated_clock. They
are visible throughout the design regardless of the current instance setting."  So, i'm not sure your solution would work?

 

Don't confuse scoping (which has to do with design hierarchy) with project flow.

 

The above is talking about scoping, and it is true.

 

What we are discussing is separating constraints so that they are only used at some stages of project implementation (OOC synthesis) and not others (top level implementation).

 

Avrum

0 Kudos
Highlighted
Guide
Guide
10,754 Views
Registered: ‎01-23-2009

I see this: "Do not define clocks in the block-level constraints if they are expected to be created at
the top level of the design.
Instead they can be queried inside the block using the get_clocks -of_objects
command. This command returns all the clocks that traverse a particular object in the
design.
Example:
set blockClock [get_clocks -of_objects [get_ports clkIn]]"

But have NO idea what "blockClock" is other than a tcl variable...  how would one use that in the block to set a block-level minimum clock period?

 

This is specifically recommended because the clocks are different when doing OOC synthesis and top level implementation. The names and properties of the clocks are different. As a result, rather than using the names of the clocks (which aren't the same in both environments), we ask for "whatever clock is currently defined on this port". During OOC synthesis, this will be the clock defined in the <filename>_ooc.xdc. During top level implementation, this will be the clock that propagates from the top level.

 

The blockClock is a Tcl variable which is given the value of the clock that is attached to the port clkin. This allows you to write a single XDC file for the constraints other than the clock definition that need access to the clock being used in the module.

 

For example if your OOC module has a clock crossing circuit that needs to know the period of the clock, it can get it by

 

get_property PERIOD $blockClock

 

When synthesized OOC, this will be the period of the clock defined in the _ooc.xdc. When implemented at the top level, it will be the period of the top level clock.

 

These constraints will be put in a different constraint file (not the _ooc.xdc). During OOC synthesis, this constraint file will be included without the out_of_context flag (as opposed to the clock definitions that will use the out_of_context flag). Since it doesn't have the out_of_context flag it will be used when the sub-module is included in the top level design, and will use the clocks defined by the top level design.

 

Avrum

View solution in original post

Tags (2)
0 Kudos
Highlighted
Explorer
Explorer
6,333 Views
Registered: ‎07-29-2009

So, what would be the best solution?  Here's my guess based on our conversation:

1) create a <something>_ooc.xdc with clock definitions in it

2) use: set_property USED_IN "out_of_context" <something>_ooc.xdc    on the file in "1"

3) if needed, create a second xdc with no clock definitions, but use: set blockClock [get_clocks -of_objects [get_ports <wherever the ooc clock comes from>]]" if anything in that file possibly needs the period of the clock with get_property PERIOD $blockClock.  But, from what I'm reading, this second XDC might not ever be needed.?

 

 

Any directions on what the "right" solution is?

 

Tags (2)
0 Kudos
Explorer
Explorer
6,255 Views
Registered: ‎07-29-2009

I get this error:

# add_files -fileset constrs_1 -norecurse ./grizzly_hdl/top.xdc
# set_property USED_IN "out_of_context" top.xdc
ERROR: [Common 17-161] Invalid option value 'top.xdc' specified for 'objects'.

   I found this in UG1119 and will give that a try:

UG1119 (v2015.3) September 30, 2015
Close the two open XDC files.
With the OOC and IP XDC files defined, you must set the
USED_IN and PROCESSING_ORDER
properties on the XDC files so that the Vivado Design Suite correctly processes the constraint files for the IP. 
You can adjust the USED_IN property in the Tcl console. To set the
USED_IN property of the OOC XDC file to include the “out_of_context” using the following Tcl command:
set_property USED_IN {synthesis implementation out_of_context}\
[get_files uart_top_ooc.xdc]
 
0 Kudos
Highlighted
Guide
Guide
3,690 Views
Registered: ‎01-23-2009

set_property USED_IN "out_of_context" top.xdc

 

Sorry - my mistake, it needs to be

 

set_property USED_IN "out_of_context" [get_files top.xdc]

 

Avrum

Tags (1)