ExpertQuestion 3 of 20Source PDF page 59

How do you model and verify timing across multiple clock domains with different frequencies (e.g., a 2:1 frequency crossing)?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

Technical Explanation

A frequency-divided clock relationship is modeled with a generated clock definition that ties the derived clock's edges to a divide ratio off the source clock, letting the tool compute the correct synchronous relationship between the two domains.

Timing-path Reasoning

For a synchronous 2:1 crossing, you declare the divided clock as generated from the source port/pin using the divide_by option, so PrimeTime understands the exact edge alignment rather than treating the two clocks as unrelated. This lets timing analysis correctly determine common periods, valid launch/capture edge pairings, and skew between domains rather than falling back to false-path or asynchronous assumptions that would blind the tool to real timing risk.

Command

create_generated_clock -source [get_ports CKP1] -divide_by 2 [get_pins U1/ Q]

Switch-by-switch

-source specifies the reference/master clock point (CKP1 port). -divide_by 2 specifies that the generated clock at U1/Q toggles at half the frequency of the source, establishing the synchronous divide relationship used for edge alignment during analysis.

Expected Result

The tool correctly computes the synchronous timing relationship between the full-rate and divided clock domains, including proper launch/capture edge pairing for the 2:1 crossing, without needing manual multicycle or false-path workarounds for the domain crossing itself.

Failure Symptoms

Omitting or mis-declaring the generated clock relationship leads to the tool either finding no valid clock relationship (forcing false conservative assumptions) or mispairing edges, producing incorrect setup/hold results across the domain boundary.

Root Cause

Failure to declare the actual divide/gating relationship between related clocks, leaving the tool without the information needed to determine correct edge alignment.

Mentor Note — Debugging Procedure

Verify the generated clock definition matches the actual hardware divider behavior (source, divide ratio, edge polarity) and confirm the clock relationship is synchronous as intended rather than defaulting to asynchronous. Frequency-crossing domains are only correctly analyzed once the generated clock's divide relationship is explicitly declared — get the create_generated_clock -divide_by definition right, and PrimeTime resolves the true synchronous cross-domain edge pairing on its own.

Visual explanationSTA context: How do you model and verify timing across multiple clock domains with…
STA context: How do you model and verify timing across multiple clock domains with…A three-step concept map summarizes the focus, core answer, and practical verification for How do you model and verify timing across multiple clock domains with different frequencies (e.g., a 2:1 frequency crossing)?Question focusHow do you model andverify timing acrossmultiple clock domainswith…Core answerA frequency-dividedclock relationship ismodeled with a generatedclock definition that…Verify in practicecreate_generated_clock-source [get_ports CKP1]-divide_by 2 [get_pinsU1/ Q]Understand → explain the mechanism → verify the assumptions

Continue learning free

Get a practical low-power chapter

Receive the existing “Low Power and Multivoltage Fundamentals” PDF chapter and its download link by email.

Continue practising

Related STA questions

IntermediateWhat's the difference between clock source latency and clock network latency, and why model them separately before CTS?IntermediateHow do you define a generated clock correctly, and what goes wrong if you use create_clock instead on a divided clock?ExpertWalk through a full setup check including clock reconvergence pessimism (CRPR) — why does OCV derating create artificial pessimism on shared clock paths, and how is it removed?IntermediateWhat is clock propagation, and what does set_propagated_clock actually change?