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: 
Highlighted
Visitor mgulotta
Visitor
201 Views
Registered: ‎07-11-2018

Where is 'actual clock period' derived from?

I'm getting the following warning during synthesis (Vivado 2018.2) that I'd like to understand:

WARNING: [Timing 38-316] Clock period '3.200' specified during out-of-context synthesis of instance 'i_xilinx_32bit_10g_phymac/ten_gig_eth_pcs_pma_i' at clock pin 'txusrclk' is different from the actual clock period '3.089', this can lead to different synthesis results. 

Another post (WARNING: [Timing 38-316]touches on this but doesn't go deep enough to explain in this case where the 'actual clock period' is being derived from.  In the above warning the actual clock period reported is '3.089'.  In this next warning it's 3.185.

WARNING: [Timing 38-316] Clock period '3.200' specified during out-of-context synthesis of instance 'i_xilinx_32bit_10g_phymac/i_MMCM_rx' at clock pin 'clk_in1' is different from the actual clock period '3.185', this can lead to different synthesis results.

These are two examples but there're more, one for each OOC IP in the design that gets it's clock from the Xilinx 10Gig Ethernet PCS/PMA core.  For 10Gig the actual period should be 3.2 ns so why are these warning showing something different?  Is jitter or uncertainty being subtracted?

Thanks in advance for any quick explanations.

Mike 

 

0 Kudos
4 Replies
171 Views
Registered: ‎01-22-2015

Re: Where is 'actual clock period' derived from?

Mike,

     Where is 'actual clock period' derived from?
In short, it is often a guess.

The warnings you are seeing are common for IP that is synthesized out-of-context (OOC).  

During setup of some IP, we are not given the option of specifying a target clock frequency for OOC synthesis. So, the IP simply guesses (UG896, pg41) a clock frequency for OOC synthesis (because OOC synthesis cannot yet see the clocks you have used in the rest of your design).

Why does Vivado synthesis need a target clock frequency?   Because Vivado synthesis is “timing aware”, which means that it uses the target clock frequency to produce results(circuits) that are likely to pass timing analysis.

So, when you run synthesis for the entire project, synthesis warns you that the target clock frequency does not match the frequency of the clock that you are actually sending to the IP.

Are these warnings a problem?  No, if your project passes timing analysis. However, if your project fails timing analysis, then (sometimes) you can make the project pass timing analysis by turning off OOC synthesis for the IP and again running synthesis and implementation for the entire project.

Cheers,
Mark

 

0 Kudos
Xilinx Employee
Xilinx Employee
156 Views
Registered: ‎05-14-2008

Re: Where is 'actual clock period' derived from?

In the warning message, the first period number is the one used for the IP OOC synthesis run, which is defined in the IP ooc XDC. The second is the one that is actually given in the user XDC or derived from a clock defined in the user XDC.

If the two are supposed to be the same, you should take care of this and see why they are different.

According to your description, the clock is supposed to be 3.2ns for 10G. Then you should check why the clock is defined as 3.089 in the user XDC.

-vivian

0 Kudos
Visitor mgulotta
Visitor
136 Views
Registered: ‎07-11-2018

Re: Where is 'actual clock period' derived from?

Thanks for the responses however in this case they don't answer the question, Where is 'actual clock period' derived from.   I'll restate the question with some additional info, and also ask if this question might belong in another category (if so, please advise).

A primary clock of 156.25Mhz is created on a port that drives the refclk to Xilinx's 10G Ethernet PCS/PMA core.  The output clocks of that core such as 'rxoutclk' and 'txoutclk' get reported via report_clocks with 3.2 ns period. So far so good, that's what's expected, 3.2ns. 

'rxoutclk', from the core (reported to have a 3.2ns period), drives 'clk_in1' of an MMCM (which was generated with a 3.2ns period).  That's it.  Now look at the following warning again closely.  It states 3.200 from OOC MMCM which makes sense because that's what I plugged in when generating it.  This matches the 3.2ns clock period of 'rxoutclk'.  However 'the actual clock period' in the warning reports '3.185'

WARNING: [Timing 38-316] Clock period '3.200' specified during out-of-context synthesis of instance 'i_xilinx_32bit_10g_phymac/i_MMCM_rx' at clock pin 'clk_in1' is different from the actual clock period '3.185', this can lead to different synthesis results.

Why is it 15ps off?  Where is it being derived from?  Is jitter or uncertainty being introduced somewhere along the line?  

 

 

Here're all the warnings I'm seeing but if I can get a precise answer to the above it should explain these as well.

 

WARNING: [Timing 38-316] Clock period '20.000' specified during out-of-context synthesis of instance 'i_user_top/i_hash_top/i_meta_dpram_blk_1024dx64w_0' at clock pin 'clkb' is different from the actual clock period '3.185', this can lead to different synthesis results.
WARNING: [Timing 38-316] Clock period '20.000' specified during out-of-context synthesis of instance 'i_user_top/i_hash_top/i_meta_dpram_blk_1024dx64w_1' at clock pin 'clkb' is different from the actual clock period '3.185', this can lead to different synthesis results.
WARNING: [Timing 38-316] Clock period '10.000' specified during out-of-context synthesis of instance 'i_user_top/i_rx_mac/i_rx_bytelgth_fifo_128dx11w' at clock pin 'wr_clk' is different from the actual clock period '3.185', this can lead to different synthesis results.
WARNING: [Timing 38-316] Clock period '10.000' specified during out-of-context synthesis of instance 'i_user_top/i_rx_mac/i_rx_data_fifo_512dx32w_0' at clock pin 'wr_clk' is different from the actual clock period '3.185', this can lead to different synthesis results.
WARNING: [Timing 38-316] Clock period '10.000' specified during out-of-context synthesis of instance 'i_user_top/i_rx_mac/i_rx_data_fifo_512dx32w_1' at clock pin 'wr_clk' is different from the actual clock period '3.185', this can lead to different synthesis results.
WARNING: [Timing 38-316] Clock period '10.000' specified during out-of-context synthesis of instance 'i_user_top/i_rx_toe/i_rx_bytelgth_fifo_128dx11w' at clock pin 'wr_clk' is different from the actual clock period '6.178', this can lead to different synthesis results.
WARNING: [Timing 38-316] Clock period '10.000' specified during out-of-context synthesis of instance 'i_user_top/i_rx_toe/i_rx_data_fifo_512dx64w' at clock pin 'wr_clk' is different from the actual clock period '6.178', this can lead to different synthesis results.
WARNING: [Timing 38-316] Clock period '20.000' specified during out-of-context synthesis of instance 'i_user_top/i_tx/i_tx2_dpram_blk_256dx64w' at clock pin 'clkb' is different from the actual clock period '6.178', this can lead to different synthesis results.
WARNING: [Timing 38-316] Clock period '20.000' specified during out-of-context synthesis of instance 'i_user_top/i_tx/i_tx_tdpram_blk_256dx64w' at clock pin 'clkb' is different from the actual clock period '6.178', this can lead to different synthesis results.
WARNING: [Timing 38-316] Clock period '3.200' specified during out-of-context synthesis of instance 'i_xilinx_32bit_10g_phymac/i_10G_mac' at clock pin 'rx_clk0' is different from the actual clock period '3.185', this can lead to different synthesis results.
WARNING: [Timing 38-316] Clock period '3.200' specified during out-of-context synthesis of instance 'i_xilinx_32bit_10g_phymac/ten_gig_eth_pcs_pma_i' at clock pin 'txusrclk' is different from the actual clock period '3.089', this can lead to different synthesis results.

 

0 Kudos
125 Views
Registered: ‎01-22-2015

Re: Where is 'actual clock period' derived from?

Mike,

    the actual clock period '3.185'… Where is it being derived from?
AR# 71679 (Generated clock referencing the wrong master clock) might apply to your design. It says to check: “Clocking Wizard where the input clock source option is set to "Single ended clock capable pin (default)" or "Differential clock capable pin" while the IP clock input is not connected to a top-level input port.”.   The AR also suggests running report_methodology, which may give clues to the source of 3.185.

Mark

0 Kudos