Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
10 years ago

Timing failure: different clock delay for launch and latch clock

Hi all

I am working on fixing multi-corner timing failures in my design. I am left with sub nano second failures that I am having a tough time with.

My clock period is 6.2 ns and the worst negative slack that I have is -0.547.

I have noticed that there is a skew between my latch and launch clock which is quite big and greater than the slack. Please see the screen shot.

So the launch clock has a Clock Delay = 9.52 and the latch clock has a Clock Delay = 8.657. This is clearly eating in to my permissible logic delay.

Why is this? What can I do to fix this?

If there is nothing that I can do than does it mean that timing failures which are comparable to the skew cannot be fixed?

Thanks

2 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    Can't tell from the screenshot. Go to the Details tab, and make sure you run report_timing with "-detail full_path", then look at the clock path and make sure it is on a global, and the same global. Assuming it's the same clock on a global, there is nothing you can do about it. There will be skew on globals, mainly due to on-die variation. Note that two nodes near each other can be at very different ends of the global H tree, and the less commonality they have resulting in more skew. Within a timing model, delays have a +/- delay. So for example, a section of the clock tree might have a delay of 1ns-1.2ns. During setup analysis the larger delay will be used for the launch clock and the slower delay for the latch clock. Common Clock Path Pessimism removal will remove this from any common portions of the clock tree since it can't be both slow and fast at the same time, but any non-common portions will not be removed.

    Now, 900ps of skew seems large. I usually think over 500ps is where it gets suspicious. If they are not on the same global, then there could be multiple reasons for skew and it's hard to say without more details.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    Hi Rysc

    I can see CLKCTRL_G6 and CLKCTRL_G4 under the location column in my clock path. After running report_timing with -show_routing I can also see some GCLK_CLUSTER*. The clock path for both Data arrival and Data Required is same up to the very last SPINE_CLK* location.

    Can you explain the term Clock Pessimism? I understand that when calculating setup time we take the max delays to account for the worst case. And Clock Uncertainty is a kind of a margin within which the clock can arrive.

    I see at the bottom of Data Required Path 'clock pessimism removed' which is about 700ps? What is the tool doing here?

    A point to note is that we are using a hard IP for a serial interface. We use the clock generated by that IP as our application clock. The reason for this was that we wanted to avoid any clock crossing between the interface and our application. I am not sure if this is the right practice but this is making our clock path really long.

    Is it worth trying to generate a same clock in the application using a new pll? Is it safe and will the 2 clocks match exactly?

    Please see the attached report_timing output with routing(sorry *.xlsx file was not supported).

    Thanks