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
Explorer
Explorer
925 Views
Registered: ‎10-12-2018

timing of path between generated clocks

Jump to solution

Hi All,

I have two clock domains. One 100MHz, other 400MHz.

(Intro: First, the 400MHz is generated from the 100MHz by a MMCM/PLL, but I had a failure path which goes from the 100MHz to 400MHz domain. I said that the majority of the delay increments comes from the differences of the two (100 & 400) clock path.)

So I tried to generate another 100MHz using the same MMCM/PLL (which generates the 400MHz) to reduce this differences, but I got the same timing issues, the path failed, because the timing analisys cannot handle these new clocks togehter. How can I tell the tool that clocks which has generated by the same PLL/MMCM has smaller worst case delay?

Here is a simple illustration of the clock structure.

timingOnZynq.png

And here is a snuppet from the path details. Note that (because of the fact that the source and destination clock generated by the same PLL) the difference of following delays are DONT CARE, and the Vivado calculate the difference of these nets.

Src ClockDelay TypeIncr (ns)Path (ns)LocationNetlist Resource(s)
(clock clk_out2_pll_400 rise edge)(r) 0.0000.000  
PS7(r) 0.0000.000Site: PS7_X0Y0inst_ps7_subsystem/ps7_zynq/inst/PS7_i/FCLKCLK[0]
net (fo=1, routed)0.8360.836 inst_ps7_subsystem/ps7_zynq/inst/FCLK_CLK_unbuffered[0]
BUFG (Prop_bufg_I_O)(r) 0.0930.929Site: BUFGCTRL_X0Y19inst_ps7_subsystem/ps7_zynq/inst/buffer_fclk_clk_0.FCLK_CLK_0_BUFG/O
      
Dst ClockDelay TypeIncr (ns)Path (ns)LocationNetlist Resource(s)
(clock clk_out1_pll_400 rise edge)(r) 2.5002.500  
PS7(r) 0.0002.500Site: PS7_X0Y0inst_ps7_subsystem/ps7_zynq/inst/PS7_i/FCLKCLK[0]
net (fo=1, routed)0.7883.288 inst_ps7_subsystem/ps7_zynq/inst/FCLK_CLK_unbuffered[0]
BUFG (Prop_bufg_I_O)(r) 0.0833.371Site: BUFGCTRL_X0Y19inst_ps7_subsystem/ps7_zynq/inst/buffer_fclk_clk_0.FCLK_CLK_0_BUFG/O

 

I have attached the detailed report of the failed path.

Q:

  • Am I right that these delay differences are dont care in my case?
  • How can I instruct the tool to ignore these delays?

I use:

  • Vivado 2017.4
  • 7series Zynq (xc7z030sbg485-2)
0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
898 Views
Registered: ‎01-23-2009

Re: timing of path between generated clocks

Jump to solution

There's nothing wrong with those delay differences - this is what is called "On Chip Variation (OCV)". You are right that it is ascribing different delays to the same components in the source and destination clock delay, which creates "pessimism", but this pessimism is then removed in the "clock pessimism" line of the timing report. So while they look different, they have no effect on the actual timing analysis.

What is causing the problem is the "FIFO18E1 (Recov_fifo18e1_RDCLK_RST)" - the magnitude of the reset recovery time. A reset recovery check is like a setup time on the reset pin. In this case, though, it is saying that the RST must be set up a whopping 1.752ns before the clock edge. This is a pretty unreasonable number...

Now, that being said, the RST input of the FIFO18/FIFO36 is a funny thing. The RST input clears all the FIFO internal address and flag generation - both the read and the write side, even when the FIFO is using different clocks on the read and write side. So the RST is internally synchronized. In the documentation, it describes the RST as "Asynchronous reset of all FIFO functions, flags, and pointers." (UG473 Table 2-3). As a result, this path is false, and probably needs a timing exception (either a set_false_path or a set_max_delay -datapath_only - preferably the latter). That would fix the problem.

My concern is "why is this needed in the first place". If the RST input is really asynchronous (i.e. it is synchronized internally), then it makes no sense that there is a reset recovery arc described in the static timing analysis model of the cell (but, as I mentioned before, the RST input is a funny thing...)

Avrum

0 Kudos
3 Replies
Historian
Historian
899 Views
Registered: ‎01-23-2009

Re: timing of path between generated clocks

Jump to solution

There's nothing wrong with those delay differences - this is what is called "On Chip Variation (OCV)". You are right that it is ascribing different delays to the same components in the source and destination clock delay, which creates "pessimism", but this pessimism is then removed in the "clock pessimism" line of the timing report. So while they look different, they have no effect on the actual timing analysis.

What is causing the problem is the "FIFO18E1 (Recov_fifo18e1_RDCLK_RST)" - the magnitude of the reset recovery time. A reset recovery check is like a setup time on the reset pin. In this case, though, it is saying that the RST must be set up a whopping 1.752ns before the clock edge. This is a pretty unreasonable number...

Now, that being said, the RST input of the FIFO18/FIFO36 is a funny thing. The RST input clears all the FIFO internal address and flag generation - both the read and the write side, even when the FIFO is using different clocks on the read and write side. So the RST is internally synchronized. In the documentation, it describes the RST as "Asynchronous reset of all FIFO functions, flags, and pointers." (UG473 Table 2-3). As a result, this path is false, and probably needs a timing exception (either a set_false_path or a set_max_delay -datapath_only - preferably the latter). That would fix the problem.

My concern is "why is this needed in the first place". If the RST input is really asynchronous (i.e. it is synchronized internally), then it makes no sense that there is a reset recovery arc described in the static timing analysis model of the cell (but, as I mentioned before, the RST input is a funny thing...)

Avrum

0 Kudos
Explorer
Explorer
887 Views
Registered: ‎10-12-2018

Re: timing of path between generated clocks

Jump to solution

Hi @avrumw 

Thanks for your response.

And you are right, I forget to check that this reset input is asynchronous, and this path can be a false path.

However, I afraid that there are some mistake in your post.

  1. "but this pessimism is then removed in the "clock pessimism" line of the timing report"
    Yes there is a clock pessimism inrement, but this doesn't ease the timing of the path. (Note that the timing calculation includes two sub-results. First the Arrival Time, second is the Required Time. ((The path fails if the Required is less than the Arrival Time.)) The Source Clock and the Data section affect on the Arrival Time. The Destination Clock affects on the Requied Time) The clock pessimism line is in the Destination Clock section and it decrease the Requied Time, which results harder timing.
  2. I still posit, that "On Chip Variation (OCV)" is "dont-care" in this case. These OCV delays are important only if we use different path, but in this case the source and destination clock use the same path from the FCLK_buffer to the PLL. So the source and the destination clock (partly) uses totaly same route. A given edge of a given signal cannot propagate with two delay. So I say that 0.836-0.788+0.93-0.83=0.058ns can be removed.

 

But, again, as you wrote, the solution is the asynchronous input.

 

0 Kudos
Historian
Historian
854 Views
Registered: ‎01-23-2009

Re: timing of path between generated clocks

Jump to solution

Destination Clock section and it decrease the Requied Time, which results harder timing

The "common portion" of the source and destination clock paths start at the PS7 clock port, but end "inside" the PLL - just before the O dividers in the PLL (since the paths diverge here, with one goint on CLKOUT0 and the other on CLKOUT1). Therfore the vast majority of the PLL is part of the common portion of the design.

As you can see, the propagation delays in the common portion of the path (the BUFG and and the nets before and after it) are larger in the source clock delay (SCD) than in the destination clock delay (DCD). However, the delay though the PLL is "more negative" in the SCD than in the DCD - so if you look at the entire path - from the PS7 clock to the output of the PLL, the SCD (-0.954) is actually earlier than the DCD (1.617-2.5=-0.883). This is essentially "reverse pessimism" or (in other words) optimism. This optimism is cancelled out by the clock pessimism - in fact, optimism up to the PLL is exactly 0.071ns (0.954-0.883), which is completely removed by the clock pesimism of 0.071.

"On Chip Variation (OCV)" is "dont-care" in this case

You are right - and that's why the "clock pessimism" exists - to remove the OCV from the portions of the SCD and DCD that are common.

You can take a look at this technical blog post on reverse pessimism.

Avrum

0 Kudos