cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
baf2099
Adventurer
Adventurer
1,281 Views
Registered: ‎03-17-2017

PCIe bridge sys_clk constraints issue

The DMA/Bridge Subsystem for PCI Express is failing to apply constraints that is generates for the sys_clk relative to other clocks within the core. After elaboration I receive the following critical warnings...

[Vivado 12-4739] set_clock_groups:No valid object(s) found for '-group [get_clocks -of_objects [get_pins pcie_root_block_i/pcie_bridge/inst/pcie4_ip_i/inst/sys_clk]]'. ["ssd_man/bd/pcie_root_block/ip/pcie_root_block_pcie_bridge_0/ip_0/synth/pcie_root_block_pcie_bridge_0_pcie4_ip_late.xdc":63]

[Vivado 12-4739] set_clock_groups:No valid object(s) found for '-group [get_clocks -of_objects [get_pins pcie_root_block_i/pcie_bridge/inst/pcie4_ip_i/inst/sys_clk]]'. ["ssd_man/bd/pcie_root_block/ip/pcie_root_block_pcie_bridge_0/ip_0/synth/pcie_root_block_pcie_bridge_0_pcie4_ip_late.xdc":64]

[Vivado 12-4739] set_clock_groups:No valid object(s) found for '-group [get_clocks -of_objects [get_pins pcie_root_block_i/pcie_bridge/inst/pcie4_ip_i/inst/sys_clk]]'. ["ssd_man/bd/pcie_root_block/ip/pcie_root_block_pcie_bridge_0/ip_0/synth/pcie_root_block_pcie_bridge_0_pcie4_ip_late.xdc":67]

[Vivado 12-4739] set_clock_groups:No valid object(s) found for '-group [get_clocks -of_objects [get_pins pcie_root_block_i/pcie_bridge/inst/pcie4_ip_i/inst/sys_clk]]'. ["ssd_man/bd/pcie_root_block/ip/pcie_root_block_pcie_bridge_0/ip_0/synth/pcie_root_block_pcie_bridge_0_pcie4_ip_late.xdc":68]

[Vivado 12-4739] set_clock_groups:No valid object(s) found for '-group [get_clocks -of_objects [get_pins pcie_root_block_i/pcie_bridge/inst/pcie4_ip_i/inst/sys_clk]]'. ["ssd_man/bd/pcie_root_block/ip/pcie_root_block_pcie_bridge_0/ip_0/synth/pcie_root_block_pcie_bridge_0_pcie4_ip_late.xdc":75]

[Vivado 12-4739] set_clock_groups:No valid object(s) found for '-group [get_clocks -of_objects [get_pins pcie_root_block_i/pcie_bridge/inst/pcie4_ip_i/inst/sys_clk]]'. ["ssd_man/bd/pcie_root_block/ip/pcie_root_block_pcie_bridge_0/ip_0/synth/pcie_root_block_pcie_bridge_0_pcie4_ip_late.xdc":76]

...and after synthesis I receive those critical warnings again in addition to these...

[Vivado 12-5201] set_clock_groups: cannot set the clock group when only one non-empty group remains. ["ssd_man/bd/pcie_root_block/ip/pcie_root_block_pcie_bridge_0/ip_0/synth/pcie_root_block_pcie_bridge_0_pcie4_ip_late.xdc":63]

[Vivado 12-5201] set_clock_groups: cannot set the clock group when only one non-empty group remains. ["ssd_man/bd/pcie_root_block/ip/pcie_root_block_pcie_bridge_0/ip_0/synth/pcie_root_block_pcie_bridge_0_pcie4_ip_late.xdc":64]

[Vivado 12-5201] set_clock_groups: cannot set the clock group when only one non-empty group remains. ["ssd_man/bd/pcie_root_block/ip/pcie_root_block_pcie_bridge_0/ip_0/synth/pcie_root_block_pcie_bridge_0_pcie4_ip_late.xdc":67]

[Vivado 12-5201] set_clock_groups: cannot set the clock group when only one non-empty group remains. ["ssd_man/bd/pcie_root_block/ip/pcie_root_block_pcie_bridge_0/ip_0/synth/pcie_root_block_pcie_bridge_0_pcie4_ip_late.xdc":68]

[Vivado 12-5201] set_clock_groups: cannot set the clock group when only one non-empty group remains. ["ssd_man/bd/pcie_root_block/ip/pcie_root_block_pcie_bridge_0/ip_0/synth/pcie_root_block_pcie_bridge_0_pcie4_ip_late.xdc":75]

[Vivado 12-5201] set_clock_groups: cannot set the clock group when only one non-empty group remains. ["ssd_man/bd/pcie_root_block/ip/pcie_root_block_pcie_bridge_0/ip_0/synth/pcie_root_block_pcie_bridge_0_pcie4_ip_late.xdc":76]

Here is my setup...

1. I'm running Vivado 2019.2

2. Building for a Zynq Ultrascale+ part

3. This is a Root Port Bridge design

4. sys_clk_buf is an IBUFDSGTE as required

pcie_block_design.pngpcie_bridge_config.png

I've looked through the known issues for this core but I didn't find anything that addresses these constraints failing to be applied. It would seem these are very important constraints since they are setting up the relationship between all the clocks in this core to be explicitly async from each other as seen in the constraint file here...

###############################################################################
# ASYNC CLOCK GROUPINGS
###############################################################################
# sys_clk vs TXOUTCLK
set_clock_groups -asynchronous -group [get_clocks -of_objects [get_ports sys_clk]] -group [get_clocks -of_objects [get_pins -hierarchical -filter {NAME =~ *gen_channel_container[*].*gen_gthe4_channel_inst[*].GTHE4_CHANNEL_PRIM_INST/TXOUTCLK}]]
set_clock_groups -asynchronous -group [get_clocks -of_objects [get_pins -hierarchical -filter {NAME =~ *gen_channel_container[*].*gen_gthe4_channel_inst[*].GTHE4_CHANNEL_PRIM_INST/TXOUTCLK}]] -group [get_clocks -of_objects [get_ports sys_clk]]
#
# sys_clk vs intclk
set_clock_groups -asynchronous -group [get_clocks -of_objects [get_pins gt_top_i/diablo_gt.diablo_gt_phy_wrapper/phy_clk_i/bufg_gt_intclk/O]] -group [get_clocks -of_objects [get_ports sys_clk]]
set_clock_groups -asynchronous -group [get_clocks -of_objects [get_ports sys_clk]] -group [get_clocks -of_objects [get_pins gt_top_i/diablo_gt.diablo_gt_phy_wrapper/phy_clk_i/bufg_gt_intclk/O]]
#
# intclk vs pclk
set_clock_groups -asynchronous -group [get_clocks -of_objects [get_pins gt_top_i/diablo_gt.diablo_gt_phy_wrapper/phy_clk_i/bufg_gt_intclk/O]] -group [get_clocks -of_objects [get_pins gt_top_i/diablo_gt.diablo_gt_phy_wrapper/phy_clk_i/bufg_gt_pclk/O]]
set_clock_groups -asynchronous -group [get_clocks -of_objects [get_pins gt_top_i/diablo_gt.diablo_gt_phy_wrapper/phy_clk_i/bufg_gt_pclk/O]] -group [get_clocks -of_objects [get_pins gt_top_i/diablo_gt.diablo_gt_phy_wrapper/phy_clk_i/bufg_gt_intclk/O]]
#
# sys_clk vs pclk
set_clock_groups -asynchronous -group [get_clocks -of_objects [get_ports sys_clk]] -group [get_clocks -of_objects [get_pins gt_top_i/diablo_gt.diablo_gt_phy_wrapper/phy_clk_i/bufg_gt_pclk/O]]
set_clock_groups -asynchronous -group [get_clocks -of_objects [get_pins gt_top_i/diablo_gt.diablo_gt_phy_wrapper/phy_clk_i/bufg_gt_pclk/O]] -group [get_clocks -of_objects [get_ports sys_clk]]
#

 

How can I correct this issue? Is this a bug?

0 Kudos
9 Replies
venkata
Moderator
Moderator
1,173 Views
Registered: ‎02-16-2010

Hi @baf2099 

Have you set up period constraint on sys_clk input in your design top .xdc file?

------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
baf2099
Adventurer
Adventurer
1,144 Views
Registered: ‎03-17-2017

Some additional info first. This project is intended to be packaged for use in a higher level design. The block design automatically creates an out of context constraints file with the following line in it...

create_clock -name pcie_ref_clk_clk_p -period 10 [get_ports pcie_ref_clk_clk_p]

...so the constraint exists. This project has the added synth setting "mode -out_of_context" so it should be using the block designs ooc constraints as well as an additional constraints I have that are marked for used_in out of context. 

venkata
Moderator
Moderator
1,133 Views
Registered: ‎02-16-2010

Hi @baf2099 

Can you export the block design as .tcl and share it? 

------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
venkata
Moderator
Moderator
1,114 Views
Registered: ‎02-16-2010

Hi @baf2099 

I could recreate the critical warnings you reported. 

If you open the synthesized design and run "report_clocks" command, you can find pcie_ref_clk_clk_p will not be present in the list of clocks. This is because the constraint on pcie_ref_clk_clk_p is only used in out of context synthesis. The critical warnings are reported because the constraint on pcie_ref_clk_clk_p port is not visible during synthesis/implementation phases.

I added the following constraint in design top .xdc file and found the critical warnings are resolved. Can you try it?

create_clock -name pcie_clk -period 10 [get_ports pcie_ref_clk_clk_p]

------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
baf2099
Adventurer
Adventurer
1,093 Views
Registered: ‎03-17-2017

As I mentioned earlier I actually package this project to be used in a higher level project and there I have a clock constraint defined which allows the design to pass without these critical warnings. This top level design is building all ip as out_of_context and doesn't even produce the errors in those synth logs. 

That being said, I've been under the impression, maybe incorrectly, that the point of running synthesis with the "-mode out_of_context" flags is to emulate what the project will do once used in a higher level design. It's important to have well defined out of context constraints for this design flow, and this method has always been my check that the constraints are valid. Am I wrong about this methodology?

Can you try adding the "-mode out_of_context" setting to synthesis and see if you get the critical warnings as I do?

0 Kudos
Yobuwen_
Visitor
Visitor
984 Views
Registered: ‎05-18-2020

I am also suffering the same problem, so if you have solved the problem

0 Kudos
baf2099
Adventurer
Adventurer
962 Views
Registered: ‎03-17-2017

@venkata did you get a chance to try adding the "-mode out_of_context" setting to synthesis and see if you get the critical warnings as I do?

0 Kudos
ashishd
Xilinx Employee
Xilinx Employee
920 Views
Registered: ‎02-14-2014

Hi @baf2099 ,

In order to recreate this scenario, I am using Vivado 2019.2, ZCU106 Evaluation Platform and below block design -

 

pcie.PNG

 

 

 

 

 

 

 

When I launched synthesis for this project with and without "-mode out_of_context" synthesis option, I didn't observe critical warning, so I believe this is not correct way to replicate what you are observing. Can you please mention what's different here compared to your design ?

If there is no custom IP in your project, then you can type below commands and share the output script and text file  -

write_bd_tcl myDesign 

write_xdc constraints.xdc (you need to open synthesized design in order to run this command)

Both myDesign.tcl and constraints.xdc will be created in your current working directory.

Regards,
Ashish
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
Yobuwen_
Visitor
Visitor
905 Views
Registered: ‎05-18-2020

No,it is not a critical warning based on the ZCU106 board. However, you can try to change the platform such as the ZU5EV device, and then the critical warning will be observed.

I have solved the problem by write constraint file follow as:

create_clock -name sys_clk -period 10 [get_ports <your input clock name>]