The Elektor Forum will close. See also this link. From Friday March 15st it is no longer possible to log in to the forum. However, the content of the forum will remain visible until the end of March. As of April 1st the forum will definitely go off the air.

Anything I can do in my clocking to improve skew and jitter?

The topic on number crunching

Anything I can do in my clocking to improve skew and jitter?

Postby Joshua_S » Mon Apr 09, 2018 4:01 am

I have the following path failing timing, and I would really appreciate some advice in understanding what I'm seeing here and how to fix it.
First some observations:
1. The clock speed is 500 MHz, my device is speed grade -2.  I know that I'm pushing my luck with this speed, but I usually meet timing with this design.
The only change since the last synthesis was to increase an address bus in an unrelated component some distance away from 9 to 10 bits!  However, synthesis on that occasion was tight (+5ps slack, not a good sign).
2. The failing path is hard-wired internal path between two DSP48E1 units, specifically the MULTSIGN and PC paths; I'm astonished to see a failure here!
3. Placement has decided on this occasion to place the two DSP units on separate clocking tiles (X0Y3 and X0Y4) to my misfortune.

My build options are default except for these settings:
set_property strategy Flow_PerfOptimized_high [get_runs synth_1]
set_property STEPS.SYNTH_DESIGN.ARGS.ASSERT true [get_runs synth_1]
set_property STEPS.PHYS_OPT_DESIGN.IS_ENABLED true [get_runs impl_1]


I am quite unfamiliar with how to read the clock path here, and I have to admit to being completely baffled by the fact that although the source and destination paths are identical up to BUFGCTRL_X0Y16 there is already a huge skew (2.541 - 2 - 0.930 = -0.389 if I'm reading this right) -- does this make sense?  I think I understand that there is a -0.306 (1.162-1.468?) routing skew ... but very little else makes much sense to me.  Clearly the signal routing delay itself is tiny (0.383), so my problem is entirely clock skew across clock tiles.
So two questions:
1.How can I usefully understand the path report I'm seeing here?  Which documentation should I be reading?
2.How can I get more information about *why* this problem has arisen and how to resolve it?

I checked out the possible influencing factors of clock (, and at the moment my best guess is that my register control interface doesn't have enough relaxation in it -- large parts of my design do seem to be pulled towards the centre of the die, causing unnecessary crowding, and these tight timings are definitely down to crowding.
Unfortunately when faced with a global problem like this, the timing reports seem to be almost useless, and it's incredibly difficult to figure out which forces are actually causing the trouble.  At the moment *all* my tight paths are logic free routings which cross clock tiles!  Very annoying...
One idea I might try is to block the offending sub-system some distance away from the centre and see exactly which paths break.  I'm certainly not ready to tie parts down for production, but think I'm going to sleep on this problem for now.

In addition, i have to confess that I'm still quite baffled when trying to read the timing report.  I'm guessing my best way to get any further details is to look at UG472?  Am I correct in understanding the edge-to-edge propagation time in my case to be 0.383+1.276 (path delay plus logic and setup time)? 

This now seems to add up:

Logic+routing delay = 1.659
Clock skew = 0.293
Clock uncertainty = 0.053
Total edge to edge delay = 2.005 (5ps too late)
So I presume that 293ps is the clock skew between my two regions, and the 53ps uncertainty is jitter.  Do I have any influence whatsoever on these numbers, or are they intrinsic to my device?  Indeed, it is a Virtex-7, a 690 in my case, so I am swimming in DSP slices!
In this particular corner of my design my DSPs are in pairs, so I'm dismayed the placing has split this.  In another part of the design I have four separate chains which are 8 units long, so I will keep an eye on them.  

I'm not ready to start pinning parts down, except for debugging, but I'll resort to that when I need to...

Sorry for so many and messy questions here, any comments would be much appreciated.
Thanks guys.
Posts: 2
Joined: Fri Mar 23, 2018 9:50 am

Return to Microcontrollers & Embedded

Who is online

Users browsing this forum: No registered users and 1 guest