0

Imagine a design has 2 input clocks. They have the "same" nominal frequency but originate from 2 different sources and therefore are asynchronous to each other. The clocks are defined as follows:

create_clock -name {clock_a} -period 10.000 -waveform { 0.000 5.000 } [get_ports {i_clock_a}]
create_clock -name {clock_b} -period 10.000 -waveform { 0.000 5.000 } [get_ports {i_clock_b}]

In the design, data synchronous to clock_a crosses to the domain of clock_b and the user forgot to implement a CDC mechanism. As far as I understand STA tools calculate the worst slack over a high number of clock cycles to try and find a timing violation. But in this - the clocks are "seemingly" in sync having the same phase and frequency.

What constrains should be added to model the frequency and phase uncertainties between the clocks to "discover" the timing violations (that obviously exist in real life) ?

shaiko
  • 159
  • 6

1 Answers1

2

I usually add a slight difference on clock period. For example, there are three clocks with periods of 5.0, 5.0, and 10.0. I will create them with these period values:

create_clock -name clk1 -period 4.99 [get_ports ...]
create_clock -name clk2 -period 4.98 [get_ports ...]
create_clock -name clk3 -period 9.97 [get_ports ...]

Because these clock periods make clock relations more complicated, it's not easy to meet timing if I forget to set_clock_groups -asynchronous. Then I can find the problems from timing report.

sharvian
  • 549
  • 1
  • 4