January 2009

New ispLEVER 7.2 Design Tool Includes Clock Domain Analysis Report

The new Clock Domains Analysis section of the TRACE report is just one of the handy new features included with the recently-released ispLEVER 7.2 design software. This tool can be a great help to understand a design’s clock domains, the datapaths which cross between the clock domains, and how each of the paths is constrained. It also highlights where paths are not constrained. Are there clock domains with no timing constraint? Are paths between related clock domains properly constrained? Are there unexpected paths between clock domains? This information can be critical to verifying that the design is correctly constrained.

Examples

The diagram below shows a simple circuit with three clock domains, followed by the new Clock Domains Analysis section of the TRACE report for this circuit.

The report provides the following information:

• There are three clock domains in the circuit. Each is identified by the label “Clock Domain:”
  • clkfast_in_c
  • clk2_inferred_clock
  • clkfast_inferred_clock
• clkfast_in_c has only one load (which is the CLKDIV component). No transfers exist within this clock domain or between it and another clock domain.
• clk2_inferred_clock:
  • is sourced from the port CDIV2 of the (CLKDIV) instance named “cd”
  • drives 74 loads
  • is covered under the preference FREQUENCY NET "clk2_inferred_clock" 100.000000 MHz ;
  • has paths terminating in this clock domain which originated from the domain: clkfast_inferred_clock. These paths are also covered by the preference FREQUENCY NET "clk2_inferred_clock" 100.000000 MHz ; There are 33 synchronous elements in clkfast_inferred_clock which originate these transfer paths.
• clkfast_inferred_clock:
  • is sourced from the port CDIV1 of the (CLKDIV) instance named “cd”
  • drives 155 loads
  • is covered under the preference FREQUENCY NET "clkfast_inferred_clock" 200.000000 MHz ;
  • has paths terminating in this clock domain which originated from the domain: clk2_inferred_clock. These paths are also covered by the preference FREQUENCY NET "clkfast_inferred_clock" 200.000000 MHz ; There is one synchronous element in clk2_inferred_clock which originates these transfer paths.

If a clock domain is not covered by a timing preference, this will be noted in that clock domain’s report. 

In the above example, the clocks are related through the CLKDIV component. 

If the two clocks originated from the device pins, and there was no user-defined relationship defined between them (a relationship can be defined using the CLKSKEWDIFF preference), these clock domains are considered unrelated. The following example shows how the report would change if these clocks were made unrelated. Note that there are only two clock domains now.

To Learn More

For more information about the ispLEVER design tool and what's new in ispLEVER 7.2, visit the Lattice website, or contact your local Lattice sales representative.