cancel
Showing results for 
Search instead for 
Did you mean: 
Observer
Observer
9,766 Views
Registered: ‎03-12-2014

Edges in clock interaction report

Jump to solution

Hi,

 

I have two questions:

 

1. In the attached clock interaction report it can be observed that for ID 4 i.e source and destination clock both are clk_out2_clk_core, for setup time analysis, the edges considered are rise - fall. But in hold analysis for the same source and destination clock (clk_out2_clk_core), the edges considered for timing analysis are rise - rise. 

 

Can anyone explain why the clock edges considered for setup and hold time analysis are different and what is the significance of such analysis ?

 

2. In the same timing report in the last column Inter-Clock Constraints are all "Yes". What we can derive from this and what it is its importance ?

 

Thanks and regards,

Amitra

 

 

Clock_Inetraction.jpg
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
17,326 Views
Registered: ‎01-23-2009

Re: Edges in clock interaction report

Jump to solution

The requirements on a path are determined by the edges of the clocks that drive the startpoints and endpoints of the path.

 

For a setup check, the requirement is from an edge at the startpoint to the next edge that follows it at the endpoint. In the case where there are paths between the rising edge and the falling edge of the same clock, clearly the requirements on those paths will be tighter than on any paths between the rising and rising edge (or the falling and falling edge); they will end up with a requirement of 1/2 clock period. So your rise->fall path comes from the fact that there is (at least) one path that starts on a rising edge of the clock and ends on the falling edge of the clock. This is either due to an internal falling edge flip-flop (which is generally considered a bad design practice), or a path from an internal FF to an ODDR, or from an IDDR to an internal FF (if the IDDR/ODDR are in "OPPOSITE_EDGE" mode).

 

The hold check is done between a clock edge and the clock edge coincident with it, or the nearest earlier one. Thus for a single clock system, where there is at least one path that starts and end on the rising edge, the tightest requirement will be from the rising edge to the same rising edge. If you also have a path from rising to falling edge, the hold time check is virtually impossible to violate on that path; the clock skew would have to be close to 1/2 of your clock period.

 

So, (summing it up), for a system that has

  - some paths from rising edge to rising edge and

  - some other paths from rising edge to falling edge

the worst setup path will be on the rising->falling path and the worst hold on the rising->rising path. Note - the worst result for each check is on a different path.

 

The Inter-Clock Constraints (which says Timed) means that the clocks are considered synchronous. This is the default in Vivado. However the default can be overridden with a set_clock_groups or set_false_path -from <clock> -to <clock> command, in which case the clocks are no longer considered synchronous and hence will not show up as "Timed" in this report.

 

Avrum

View solution in original post

0 Kudos
2 Replies
Highlighted
Guide
Guide
17,327 Views
Registered: ‎01-23-2009

Re: Edges in clock interaction report

Jump to solution

The requirements on a path are determined by the edges of the clocks that drive the startpoints and endpoints of the path.

 

For a setup check, the requirement is from an edge at the startpoint to the next edge that follows it at the endpoint. In the case where there are paths between the rising edge and the falling edge of the same clock, clearly the requirements on those paths will be tighter than on any paths between the rising and rising edge (or the falling and falling edge); they will end up with a requirement of 1/2 clock period. So your rise->fall path comes from the fact that there is (at least) one path that starts on a rising edge of the clock and ends on the falling edge of the clock. This is either due to an internal falling edge flip-flop (which is generally considered a bad design practice), or a path from an internal FF to an ODDR, or from an IDDR to an internal FF (if the IDDR/ODDR are in "OPPOSITE_EDGE" mode).

 

The hold check is done between a clock edge and the clock edge coincident with it, or the nearest earlier one. Thus for a single clock system, where there is at least one path that starts and end on the rising edge, the tightest requirement will be from the rising edge to the same rising edge. If you also have a path from rising to falling edge, the hold time check is virtually impossible to violate on that path; the clock skew would have to be close to 1/2 of your clock period.

 

So, (summing it up), for a system that has

  - some paths from rising edge to rising edge and

  - some other paths from rising edge to falling edge

the worst setup path will be on the rising->falling path and the worst hold on the rising->rising path. Note - the worst result for each check is on a different path.

 

The Inter-Clock Constraints (which says Timed) means that the clocks are considered synchronous. This is the default in Vivado. However the default can be overridden with a set_clock_groups or set_false_path -from <clock> -to <clock> command, in which case the clocks are no longer considered synchronous and hence will not show up as "Timed" in this report.

 

Avrum

View solution in original post

0 Kudos
Highlighted
Observer
Observer
9,741 Views
Registered: ‎03-12-2014

Re: Edges in clock interaction report

Jump to solution

Thank you Avrumw. I learn so much from every reply of yours !!

 

Regards,

Amitra

0 Kudos