cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
pslawinski
Visitor
Visitor
1,898 Views
Registered: ‎08-09-2018

How do I scope a constraint file to a particular module within a *single* IP?

I have a project that uses multiple instances of a few different IPs which have constraints in them which have their SCOPE_TO_REF property set to target a particular module. Here's an example of one such constraint file.

#Must be scoped to Ref PulseCDC. Must be run after clocks are declared (run late).
set_max_delay -from [get_pins -hierarchical *req_srcClk*/C] -through [get_pins -hierarchical *pipeReq_destClk*] [get_property PERIOD [get_clocks -of_objects [get_ports -scoped_to_current_instance src_clk]]] -datapath_only

set_max_delay -from [get_pins -hierarchical *ack_destClk*/C] -through [get_pins -hierarchical *pipeAck_srcClk*] [get_property PERIOD [get_clocks -of_objects [get_ports -scoped_to_current_instance dest_clk}]]] -datapath_only

What I expect to happen is that this constraint will be scoped to all instances of "PulseCDC" in the IP module. This happens. Unfortunately, the constraint also ends up being scoped to other references of "PulseCDC" that are contained within other IP modules in the design. So when I load up the synthesized design there are over 20000 "Set Max Delay" constraints. It appears that for each copy of "PulseCDC.xdc" it's targeting all the instances of PulseCDC throughout the entire design. I might have been inclined to believe this was just a bug in Vivado, but looking at the synthesis / implementation log I see tons of messages related to the application of constraint files, and implementation crashes.

 

This cross-ip application of constraints isn't limited to a specific kind of constraint e.g. set_max_delay. It happens with all the constraints 

0 Kudos
5 Replies
chrisz
Xilinx Employee
Xilinx Employee
1,877 Views
Registered: ‎05-06-2008

Hello @pslawinski,

 

You will need to make the constraints more specific to the given IP or cells within the IP.  The XDC language is very aggressive, so you need to be more specific in order to limits the number of these constraints.  If you can add more hierarchy to the cell names or add a specific list of 'to' objects, may help the situation.

 

Good Luck,
Chris

0 Kudos
hongh
Moderator
Moderator
1,875 Views
Registered: ‎11-04-2010

Hi, @pslawinski ,
Could you try to add SCOPE_TO_CELLS property for the XDC?

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
pslawinski
Visitor
Visitor
1,851 Views
Registered: ‎08-09-2018


@chrisz wrote:

Hello @pslawinski,

 

You will need to make the constraints more specific to the given IP or cells within the IP.  The XDC language is very aggressive, so you need to be more specific in order to limits the number of these constraints.  If you can add more hierarchy to the cell names or add a specific list of 'to' objects, may help the situation.

 

Good Luck,
Chris


So I certainly *could* scope to every cell in the IP, but even then, how does that guarantee that constraints won't be applied across different IPs? Will the SCOPE_TO_REF be set with the top level instance name of the IP module (the name that is generated by the IP integrator) Do I have to put the full hierarchy in the SCOPE_TO_CELL property? e.g. MemMap/rxGen.uRX/sampRst_CDC

0 Kudos
hongh
Moderator
Moderator
1,846 Views
Registered: ‎11-04-2010

Hi, @pslawinski ,

If you use SCOPE_TO_CELLS, you have to put the full hierarchy in the SCOPE_TO_CELL property.
You can also put the XDC into the top level XDC as Chris suggest:
Ex:
set_max_delay -from [get_pins -hier -filter {NAME =~ */IP_name/your_instance_name/*req_srcClk*/C}] -through [get_pins -hierarchical -filter {NAME =~ */IP_name/your_instance_name/*pipeReq_destClk*}] [get_property PERIOD [get_clocks -of_objects [get_pins -hier -filter {NAME =~ */IP_name/your_instance_name/src_clk]]] -datapath_only

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
avrumw
Guide
Guide
1,807 Views
Registered: ‎01-23-2009

If I understand what you are saying, you have multiple different IPs that each have a PulseCDC in it (an IP within an IP). From your description it seems that each of these IPs (that contain a PulseCDC) is including a NEW copy of the PulseCDC.xdc which each are SCOPED_TO_REF of PulseCDC. Therefore if you have N top level IPs that have PulseCDC in it, you get N copies of PulseCDC.xdc, each of which end up covering the PulseCDC in all IPs, and hence you end up N^2 constraints (one copy of PulseCDC is constrained by all N PulseCDC.xdc).

 

This shouldn't happen...

 

When an IP is "created/customized", each block that it needs is added to the project with a unique name. So if MODA uses a PulseXDC, it should add a module to the design named MODA_PulseXDC, with a scoped XDC file that is scoped to MODA_PulseCDC. This is certainly true for all Xilinx IP that includes other Xilinx IP...

 

If this is your own IP, I wonder if there is some option used during the creation of the IP that is suppressing the "uniquification" of sub-modules...

 

Also (and this is probably unrelated) when you write a scoped XDC, it should be written as if the scoped module is the top of the design. In most cases there is no need for wildcarding and in even more cases, there is no need for the -hierarchical flag. If you IP has a signal/reg/logic named req_srcClk that is used to infer a flip-flop, then in your scoped XDC file you should get the clock pin of that using simply

 

[get_pins req_srcClk_reg/C]

 

no wildcards, no -hierarchical flag... This is the point of scoped XDC files - to reduce the use of wildcards (that can get out of control).

 

Avrum