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: 
6,264 Views
Registered: ‎01-22-2015

create_generated_clock thru MMCM

Jump to solution

Working in Vivado 2016.4, I use the following circuit for source-synchronous SDR input to the FPGA.

 

SSI2_FPGA_IO_B.jpg

 

To inform timing analysis that MMCM2 is inverting the forwarded-clock, SSI2_CLK, I tried using the following constraint:

 

create_generated_clock -name SSI2_CLKI -source [get_pins MMCM2/inst/mmcm_adv_inst/CLKIN1] -invert -divide_by 1 [get_pins MMCM2/inst/mmcm_adv_inst/CLKOUT0]

 

However, I get the following critical warning:

 

[Constraints 18-1056] Clock 'SSI2_CLKI' completely overrides clock 'CLK_OUT1_CLK_GEN2'. New: create_generated_clock -name SSI2_CLKI -source [get_pins MMCM2/inst/mmcm_adv_inst/CLKIN1] -divide_by 1 -invert [get_pins MMCM2/inst/mmcm_adv_inst/CLKOUT0], ["C:/Vivado_projects/my_proj1/my_proj1.srcs/constrs_1/new/constraints1.xdc": and 131] Previous: [unsaved constraint] , and create_generated_clock -name CLK_OUT1_CLK_GEN2 -source [get_pins MMCM2/inst/mmcm_adv_inst/CLKIN1] -edges {1 2 3} -edge_shift {5.000 5.000 5.000} -add -master_clock SSI2_CLK [get_pins MMCM2/inst/mmcm_adv_inst/CLKOUT0]

 

This warning suggests (I think) that another create_generated_clock exists. However, my search of the Vivado project cannot find another create_generated_clock constraint.

 

Please explain the critical warning and what I should do about writing a create_generated_clock constraint for this FPGA I/O interface.

0 Kudos
1 Solution

Accepted Solutions
Voyager
Voyager
9,679 Views
Registered: ‎06-24-2013

Re: create_generated_clock thru MMCM

Jump to solution

Hey markg@prosensing.com

 

Both the PLL and MMCM are smart enough to create constraints for derived clocks for you, so there is no need to do it yourself.

 

Hope that clarifies,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
7 Replies
Voyager
Voyager
9,680 Views
Registered: ‎06-24-2013

Re: create_generated_clock thru MMCM

Jump to solution

Hey markg@prosensing.com

 

Both the PLL and MMCM are smart enough to create constraints for derived clocks for you, so there is no need to do it yourself.

 

Hope that clarifies,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
Moderator
Moderator
6,254 Views
Registered: ‎09-15-2016

Re: create_generated_clock thru MMCM

Jump to solution

Hi markg@prosensing.com

 

In addition check this AR:

https://www.xilinx.com/support/answers/62488.html

 

Hope this helps.

 

Regards

Rohit

Regards
Rohit
----------------------------------------------------------------------------------------------
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.
----------------------------------------------------------------------------------------------

Historian
Historian
6,233 Views
Registered: ‎01-23-2009

Re: create_generated_clock thru MMCM

Jump to solution

As others have mentioned, when a clock goes to a clock modifying block (MMCM, PLL, BUFR), the tools automatically create generated clocks for the outputs of that block based on the clock propagating to the input of the block, and the properties of the block.

 

So, if the input to the MMCM has a create_clock upstream of it (on the input port) then the tool will automatically create generated clocks on the outputs of the MMCM. These clocks are "effectively" created with a create_generated_clock command, but the command itself does not appear in any XDC file.

 

However, you can see the effect by doing a report_clocks command

 

Here is a report from an example design.

 

Clock              Period(ns)  Waveform(ns)    Attributes  Sources
clk_pin_p          5.000       {0.000 2.500}   P           {clk_pin_p}
clkfbout_clk_core  5.000       {0.000 2.500}   P,G,A       {clk_gen_i0/clk_core_i0/inst/mmcm_adv_inst/CLKFBOUT}
clk_out1_clk_core  5.000       {0.000 2.500}   P,G,A       {clk_gen_i0/clk_core_i0/inst/mmcm_adv_inst/CLKOUT0}
clk_out2_clk_core  5.161       {0.000 2.581}   P,G,A       {clk_gen_i0/clk_core_i0/inst/mmcm_adv_inst/CLKOUT1}

The only clock command here is the create_clock on clk_pin_p. The other three clocks are generated (G) automatically (A) by the tools as the constraints are processed. Scrolling down, the tool will even tell you the relationship between the generated clocks and the source clock. In your case, you will see the inversion (assuming the inversion is done in the MMCM) through either an (I) attribute, or via a different mechanism in specification of the relationship.

 

By the way, it is cool that they added the (A), and Renamed (R) attributes to the report_clocks command in 2017.1!

 

Here is the same report after renaming two of the clocks using the commands

create_generated_clock -name clk_rx [get_pins clk_gen_i0/clk_core_i0/inst/mmcm_adv_inst/CLKOUT0]

create_generated_clock -name clk_tx [get_pins clk_gen_i0/clk_core_i0/inst/mmcm_adv_inst/CLKOUT1]

 

Clock              Period(ns)  Waveform(ns)    Attributes  Sources
clk_pin_p          5.000       {0.000 2.500}   P           {clk_pin_p}
clkfbout_clk_core  5.000       {0.000 2.500}   P,G,A       {clk_gen_i0/clk_core_i0/inst/mmcm_adv_inst/CLKFBOUT}
clk_rx             5.000       {0.000 2.500}   P,G,A,R     {clk_gen_i0/clk_core_i0/inst/mmcm_adv_inst/CLKOUT0}
clk_tx             5.161       {0.000 2.581}   P,G,A,R     {clk_gen_i0/clk_core_i0/inst/mmcm_adv_inst/CLKOUT1}

Avrum

Moderator
Moderator
6,226 Views
Registered: ‎11-04-2010

Re: create_generated_clock thru MMCM

Jump to solution
Hi, @markg@prosensing.com, In Vivado the clock of MMCM's output will be derived automatically and you can use the clock directly without creating it again. To get the derived clock information, you can use the below command after opening the synth/implemented design: %report_clocks %report_property -all [get_clocks -of [get_pins MMCM2/inst/mmcm_adv_inst/CLKOUT0]] Regards Hong
-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
6,211 Views
Registered: ‎01-22-2015

Re: create_generated_clock thru MMCM

Jump to solution

To All: - so many kind replies to my silly question.   Thanks!  I now see from ug903 and AR62488 that CMBs (eg. MMCM) auto-generate clocks and auto-generate the needed constraints for these clocks.  The fact that some of these constraints do not actually appear in any XDC file (as explained by Avrum), had me confused.

 

Avrum and Hong: The report_clocks command is very cool – clearly showing and describing all the clocks in my project.  I particularly like the report’s use of “Edge Shifts(ns)” for describing clock period and phase. 

 

Avrum: Thanks for reminding me about the special-formatted create_generated_clock that is used to rename clocks.  Sometimes the clock names get pretty long.  So, renaming them simplifies my typing. Any other reason to rename clocks?

 

-another question please.

 

For this interface, data comes into the FPGA edge-aligned. As mentioned above, MMCM2 inverts the forwarded clock to put the latch-edge of the forwarded clock in the middle of the “data eye”.  After writing simple set_input_delay constraints for the interface, I was able to run timing analysis.  Results show that the interface passes timing analysis, having positive and equal(!) slack for both setup and hold.  I did not expect the two slack values to be equal – because I thought that the interface-clock-path going thru the MMCM would accumulate much more delay than the interface-data-path (which only goes thru an IBUF). Is the MMCM automatically doing something to ensure equal length inside the FPGA for the interface-clock-path and the interface-data-path?

0 Kudos
Highlighted
Historian
Historian
6,201 Views
Registered: ‎01-23-2009

Re: create_generated_clock thru MMCM

Jump to solution

For this interface, data comes into the FPGA edge-aligned. As mentioned above, MMCM2 inverts the forwarded clock to put the latch-edge of the forwarded clock in the middle of the “data eye”.  After writing simple set_input_delay constraints for the interface, I was able to run timing analysis.  Results show that the interface passes timing analysis, having positive and equal(!) slack for both setup and hold.  I did not expect the two slack values to be equal – because I thought that the interface-clock-path going thru the MMCM would accumulate much more delay than the interface-data-path (which only goes thru an IBUF). Is the MMCM automatically doing something to ensure equal length inside the FPGA for the interface-clock-path and the interface-data-path?

 

So, this is odd... When you say equal, do you mean "exactly equal" - i.e. to 3 significant digits. If so, this is puzzling. There is certainly no "by design" reason for this - if it is happening, it is purely coincidence.

 

But it shouldn't happen. (It would help to see both the constraints and the setup and hold check timing report, but...)

 

If the input is perfectly "edge aligned", then the falling edge of the input clock would be right in the center of the data eye; thus providing equal setup and hold times. However, the setup/hold requirement of a pin of the FPGA is not expected to have a symmetrical setup/hold requirement. When the capture flip-flops are forced into the IOB, the timing of this interface (in this case around the falling edge of the clock due to the inversion) would be Tpsmmcmcc/Tphmmcmcc (see the datasheet for your device - i.e. DS182 Table 49 for the Kintex-7). These requirements are definitely not symmetrical.

 

However, not for the reason you describe - the reality is that the data insertion time can actually be longer than the clock insertion time! One of the main functions of the MMCM is to perform "clock deskew". In reality, the MMCM generates an output clock that is "just enough" out of phase with its input clock so that the CLKIN and CLKFBIN are phase aligned - the PLL within the MMCM is continually adjusting its output phase to keep these two in phase - it is "compensating" the delay of the BUFG and the global clock tree on the feedback path. In certain circumstances (including this one), it modifies this so that CLKIN and CLKFBIN  have a "specific" phase (rather than an equal phase) in order to compensate for (in this case) the IBUFG on the clock input. It does further tweaking to ensure that an IOB flip-flop clocked with this clock requires "zero hold" (or negative hold) - this greatly facilitates the design of system synchronous interfaces.

 

So, the required setup/hold window of an IOB flip-flop clocked with an MMCM that uses a BUFG (or the same buffer as the output clock) in its feedback path is expected to have a significantly asymmetrical setup/hold requirement; with the entire valid window being before the edge of the clock (positive setup, negative hold - see Table 49 to see that this is true).

 

So, given this, if your input data window was symmetrical, and the required data window is not, you should not end up with symmetrical setup and hold margins.

 

Of course, if your capture flip-flop is in the fabric (as opposed to the IOB), almost anything is possible...

 

Avrum

Tags (2)
6,186 Views
Registered: ‎01-22-2015

Re: create_generated_clock thru MMCM

Jump to solution

         There is certainly no "by design" reason for this - if it is happening, it is purely coincidence.  .....  Of course,

         if your capture flip-flop is in the fabric (as opposed to the IOB), almost anything is possible...

 

You are correct, the capture flop was in the fabric.  After moving this flop to the IOB, slacks now differ by 25%. 

 

Thanks Avrum!!

0 Kudos