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: 
Contributor
Contributor
373 Views
Registered: ‎05-17-2018

clock skew between SLRs

Hello,

 

I have problems to close timing for signals crossing an SLR boundary. I am aware of Laguna registers, but I'm wondering if the clock skew I'm between SLR's that I'm seeing is not prohibitive and if if can/should be resolved first?

  • The clock period is 2ns.
  • Total signal delay = 0.078 ns (logic) + 1.893 ns (net) = 1.971ns; 
  • WNS: -0.596ns

The biggest problem seems to be in the large clock skew between source ( 3.459 ns) and destination (3.052 ns) flipflop, which basically eats away 20% of the time period.

Is this skew in the normal/expected range? 

I am not yet doing anything special to use laguna flipflops. Maybe this clock skew should be addressed first? If so, how?

NamePath 1
Slack-0.596ns
Sourcei_Static/rSampleIn_reg[4][81][2]/C   (rising edge-triggered cell FDRE clocked by ap_clk  {rise@0.000ns fall@1.000ns period=2.000ns})
Destinationi_Static/rSampleIn_3_reg[0][81][2]/D   (rising edge-triggered cell FDRE clocked by ap_clk  {rise@0.000ns fall@1.000ns period=2.000ns})
Path Groupap_clk
Path TypeSetup (Max at Slow Process Corner)
Requirement2.000ns (ap_clk rise@2.000ns - ap_clk rise@0.000ns)
Inter-SLR Compensation0.306ns
Data Path Delay1.971ns (logic 0.078ns (3.957%)  route 1.893ns (96.043%))
Logic Levels0  
Clock Path Skew-0.309ns
Clock Uncertainty0.035ns
Clock Net Delay (Source)3.459ns (routing 1.110ns, distribution 2.349ns)
Clock Net Delay (Destination)3.052ns (routing 1.012ns, distribution 2.040ns)

 

 

 

 

 

Tags (2)
0 Kudos
1 Reply
Guide avrumw
Guide
272 Views
Registered: ‎01-23-2009

Re: clock skew between SLRs

This doesn't seem unreasonable.

You have to remember that the different SLRs are different dice (plural of die) - they are not necessarily at the same "process" - one SLR may be faster/slower than the other. Therefore the portion of the clock distribution/routing tree on one SLR could be faster/slower than the one on the other die.

Considering that the skew on one die can approach 200ps, a skew of 310ps between two SLRs doesn't seem excessive (and you have to look at the reported skew rather than the difference between the source clock and destination clock - some of that difference is compensated by the "clock pessimism")

At 500MHz, it is not surprising that it is difficult going SLR to SLR without using the Laguna registers...

Avrum

0 Kudos