1964 - Diamond: How can users disable irrelevant clock domain crossings during the device implementation?<br>

1964 - Diamond: How can users disable irrelevant clock domain crossings during the device implementation?<br>

Timing paths that contain clock domain crossings are paths between two registers that are clocked with two clocks. After performing timing analysis using Place and Route TRACE, such timing paths usually have the following source and destination report form: 

  Source:         FF         Q              U_my_reg_1_1/q  (from CLK_A +)
  Destination:    FF         Data in        U_my_reg_3_2/q  (to CLK_B +)

Note that the clocks for source and destination not only have different names but are also known to be different (i.e. do not share the same clock net). They can, however, be synchronous or asynchronous clocks.

In some cases, it is critical for the TRACE to take the clock domain crossing paths into consideration, while in some other cases it is not. It is at the user's discretion to decide whether such paths are relevant.

When it is not critical (i.e. irrelevant clock domain crossing paths), in some cases the clock domain crossing path's timing score negatively affects the overall designs timing score. This scenario creates a situation in which the timing report indicates that the design has not met timing, when in fact, the absence of these paths would result in a design that has met timing. Knowing this, user can conclude that his or her timing failure is due to false paths.

Another side effect of including irrelevant clock domain crossing paths is a possible longer implementation run time. During implementation these paths are taken into account, and these paths could result in long run time as, sometimes, it is difficult to achieve the timing requirements for these paths.

After determining whether a clock domain crossing path is irrelevant, users can disable analysis on this path by using the BLOCK constraint. The BLOCK constraint is available in both ispLEVER Design Software and Lattice Diamond.

One way to add the the BLOCK constraint, user will need to edit his/her Lattice Preference File (.lpf file). Below is example syntax of the BLOCK constraint, specifically blocking paths that crosses from CLK_A to CLK_B.


BLOCK PATH FROM CLKNET "CLK_A" TO CLKNET "CLK_B" ;

Note that the constraint above only affects path from CLK_A to CLK_B. To enable blocking paths from CLK_B to CLK_A, another constraint entry is needed:

BLOCK PATH FROM CLKNET "CLK_B" TO CLKNET "CLK_A" ;


Full documentation and other methods of entering the BLOCK constraint can be found in the help files of both ispLEVER and Lattice Diamond. To access the help file(s):

Diamond:

Click on "Help" -> "Lattice Diamond Help" and a webpage will appear. In the webpage, click on the "Search" Tab and enter "Setting BLOCK Preferences". Find the result with the exact keywords entered in the search tab, and click on that link.

ispLEVER:

Click on "Help" -> "Project Navigator Help" and a webpage will appear. In the webpage, click on the "Search" Tab and enter "Setting BLOCK Preferences". Find the result with the exact keywords entered in the search tab, and click on that link.