cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
ps2729
Visitor
Visitor
846 Views
Registered: ‎12-16-2019

Using create_generated_clock in vivado 2019.2 to re-name output of bufg_gt

Hi,

 

Until and before vivado 2019.1, I was able to use the following create_generated_clock command in an xdc file:

 

create_generated_clock -name <name_of_clock> [get_pins <output_pin_of_bufg_gt>]

 

to name the output of a bufg_gt where the input clock was divided by 2 like in the instance below:

 

BUFG_GT bufg_gt_inst (

.CE ( 1'b1 ),

.CEMASK ( 1'b0 ),

.CLR ( rst ),

.CLRMASK ( 1'b0 ),

.DIV (2 ),

.I ( input_clk ),

.O ( output_clk )

);

 

In this case, given the right path of the output pin of the bufg_gt, the tool was able to figure out the relationship between the input and the output of the bufg_gt. 

 

With Vivado 2019.2, the same command throws the following ctritical warning only during implementation phase and not during synthesis:

 

[Constraints 18-851] Could not find an automatically derived clock matching the supplied criteria for renaming. [“<name_of_constraint_file>”]

This causes the the constraints post this definition to not be recognized.

In order to solve this, I had to re-write the command more explicity, defining the source and and the relationship between the input and the output of the bufg_gt like below:

 

create_generated_clock -source [get_pins <input_pin_of_bufg_gt>] -add -master_clock [get_clocks <name_of_master_clock>] -divide_by 2 -name <name_of_clock> [get_pins <output_pin_of_bufg_gt>]

Here are my questions:

1. Is this change expected?

2. Is there a more elegant/efficient way to write this in order to get vivado 2019.2 to recognize the output clock of the bufg_gt?

3. Is there a way to write this where I dont have to explicity mention the relationsip between the input and the output clock of the bufg_gt (i.e the -divide_by 2 in this case) and have the tool recognize this? I would prefer that becasue the value I pass in to the DIV parameter of the bufg_gt might differ in certain setups of my design and I would prefer not having to keep changing my constraints setup for it.

 

 

Thanks in advance!

0 Kudos
Reply
8 Replies
takayos
Xilinx Employee
Xilinx Employee
803 Views
Registered: ‎04-12-2012

Hello,

 

Thanks for reporting this. I don`t think this is expected change.

Re-naming can work on automatically derived clock, so I doubt if there is really such clock on there.

Can you confirm it?

  1. Open implemented design (original/error design)
  2. report_clocks
  3. check result if automatically derived clock exist on target pin

 

Thanks,

Takayoshi

-------------------------------------------------------------------------
Don`t forget to reply, kudo, and accept as solution
-------------------------------------------------------------------------
0 Kudos
Reply
ps2729
Visitor
Visitor
787 Views
Registered: ‎12-16-2019

Hi Takayoshi, 

I do see an "automatically derived clock" on that target pin when I run "report_clocks" but the intention here is to rename the clock to something that makes more sense in our design. 

Thanks

0 Kudos
Reply
takayos
Xilinx Employee
Xilinx Employee
753 Views
Registered: ‎04-12-2012

Thanks for confirming. Yes, I understood.

You see such warnings when you try to re-name on pin where automatically derived clock not exist.

You actually see clock, then this might be SW issue.

Another possibility is order constraint, but the truth your work around was working denied it.

I test it in 2019.2, and was not able to reproduce the issue.

Can you share reproduce design with me?

-------------------------------------------------------------------------
Don`t forget to reply, kudo, and accept as solution
-------------------------------------------------------------------------
0 Kudos
Reply
709 Views
Registered: ‎01-22-2015

@ps2729 

Is there a way to write this where I dont have to explicity mention the relationsip between the input and the output clock of the bufg_gt (i.e the -divide_by 2 in this case)

When using create_generated_clock to rename a clock, you cannot use the -divide_by option (and other options) as described on pg 92 of UG903(v2019.1).

The following post may help with using create_generated_clock to rename a clock.
https://forums.xilinx.com/t5/Timing-Analysis/BUFGMUX-constraints-and-Vivado/td-p/1052538

Mark

0 Kudos
Reply
ps2729
Visitor
Visitor
705 Views
Registered: ‎12-16-2019

Unfortunately, I cannot share the design but I will try to reproduce this is more contained setup and share that 

0 Kudos
Reply
takayos
Xilinx Employee
Xilinx Employee
690 Views
Registered: ‎04-12-2012

Hi,

 

If you can provide reproduce design, I will address it so that we can fix it in future release.

In the meantime, how about this ?

 

set IN_PERIOD [get_property PERIOD [get_clocks -of [get_pins <input_pin_of_bufg_gt>]]]

set OUT_PERIOD [get_property PERIOD [get_clocks -of [get_pins <output_pin_of_bufg_gt>]]]

set DIV [expr $OUT_PERIOD/$IN_PERIOD]

create_generated_clock -source [get_pins <input_pin_of_bufg_gt>] -add -master_clock [get_clocks <name_of_master_clock>] -divide_by $DIV -name <name_of_clock> [get_pins <output_pin_of_bufg_gt>]

 

Thanks,

 

-------------------------------------------------------------------------
Don`t forget to reply, kudo, and accept as solution
-------------------------------------------------------------------------
0 Kudos
Reply
ps2729
Visitor
Visitor
636 Views
Registered: ‎12-16-2019

Hi Mark, 

I am now using create_generated_clock with -divide_by and it seems to be working fine -- vivado 2019.2 picks it and replaces the auto generated clock names with it. I did refer to UG903 for it.  I think what happens is a new clock is created (I also use the -add argument) with the specified name since divide_by is used and replaces the vivado generated name, I am not sure though. When running "report_clocks" after this, I do not see the vivado generated names for these clocks, I only see the names that I passed using create_generated_clock (when -divide_by was used)

I do agree this is a bit unexpected especially since constraints that were working until 2019.1 do not work on 2019.2.

Thanks

0 Kudos
Reply
ps2729
Visitor
Visitor
627 Views
Registered: ‎12-16-2019

Hi Takayos,

 

Thanks this worked. 

0 Kudos
Reply