A design does not have timing errors in 4.1i, but fails timing in 3.1i and/or fails in the lab. Why?
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.