AR# 11850

|

4.1i Trace(TRCE)/Timing Analyzer - Period constraint handles related clocks correctly.

Description

Urgency: Normal

General Description:

A design does not have timing errors in 4.1i, but fails timing in 3.1i and/or fails in the lab. Why?

Solution

This is caused by a discrepancy between 3.1i and 4.1i regarding how the PERIOD constraints are handled. In 3.1i, a period would analyze the paths that cross clock domains, even if these clocks were not related. This gives an incorrect analysis of these paths. Because of this inconsistency, cross-clock domain paths are no longer automatically covered in all forms of the 4.1i PERIOD constraint.

Since the cross-clock domain paths are no longer covered by a PERIOD in 4.1i, these paths will not be analyzed, which can cause timing problems. This can be avoided by explicitly constraining the paths.

A FROM TO example:

NET clka TNM = CLKA_GRP ;

NET clkb TNM = CLKB_GRP ;

TIMESPEC TS_FASTCLK = PERIOD CLKA_GRP 10;

TIMESPEC TS_SLOWCLK = PERIOD CLKB_GRP 20;

TIMESPEC TS_CLKA2CLKB = FROM CLKA_GRP TO CLKB_GRP 10;

TIMESPEC TS_CLKB2CLKA = FROM CLKB_GRP TO CLKA_GRP 10;

The paths can be included in the PERIOD constraints by relating the clocks to one another in their PERIOD constraints. For example, suppose you are using the following two constraints:

TIMESPEC TS_FASTCLK = PERIOD NET "clka" 10 ;

TIMESPEC TS_SLOWCLK = PERIOD NET "clkb" TS_FASTCLK * 2 ;

This will relate "clka" to "clkb" by a factor of 2. The timing analysis tools will now analyze these paths as it did in 3.1i -- with the destination flip-flop controlling the paths between them.

Any phase differences between the two clocks should be included in this analysis with a PHASE keyword.

AR# 11850
Date 01/18/2010
Status Archive
Type General Article
People Also Viewed