STA multiple clock domains

[rogger123]

clock domain check sta

hi,
i have a few doubts with regards to primetime when used for designs having multiple clock domains
please correct me if i am wrong..
PT analyzes a timing arc which has the same clock for the startpoint(launch) and end point(capture)... am i right ?
now consider f/f1 frm clk domain CLK1 driving ff2 which is clocked by clock doamin CLK2.
now both these clocks are different .. would PT analyze this path frm ff1(launch/startpoint) to ff2(capture/endpoint)?
if yes how would it perform its analysis.. and are there any specific constraints that need to be added to tell PT about the various signals that pass from one clock domain to another?

regards
rogger

 

[eda_wiz]

multiple clock domains

you should disable PT tming analysis between 2 diff clock domains using set_false_path or set_disable_timing commands

for crossing clock domains u need a synchroniser ckt or async fifo.

 

[rogger123]

cross clock path for sta

hi,
for synchrinisation i am using double hardened flip flops..
if pt follows the concept mentioned above why doi need to go an disable the timing on each of the path that cross clock domains.. doesn't pt ignore them for the basic reason that the startpoint and end point are controlled by diff clocks..???
rgds
rogger

 

[bg21359]

primetime clock domains

I think when you give the setup time/hold time of receiver flipflops/latchs, you need to include the skews between different clock domains; or you may add these skews separately into this path;
But I'm not so familiar with PT, so can't give you specific ideas

 

[bianguyen]

prime time and multiple clock domains

By default, Primetime does not care that the two flops are clocked by different clocks. It will
happily do timing checks on those paths. You should disable those paths and/or analyze
them separately. One way to do this is with the following PT commands:

# Report timing paths which starts in one clock domain and ends in a different
# clock domain. Also false_path them.
set clock_list [all_clocks]
foreach_in_collection from_clk $clock_list {
   foreach_in_collection to_clk $clock_list {
        if { [get_object_name $from_clk] != [get_object_name $to_clk] } {
            report_timing -from [get_clocks $from_clk] -to [get_clocks $to_clk] -path end
            set_false_path -from [get_clocks $from_clk] -to [get_clocks $to_clk]
        }
    }
}

It is a good idea to check the results of the above reports for any unintentional
clock crossings.

Note that you normally synchronize a control signal and use that to validate the
accompanying data. So the data path has an extra 2 (or more) cycles in the target
clock domain to meet setup. Therefore, the data path usually isn't a problem unless
you have lots of combinatorial logic on that path. But you'd want to verify the
timing reports for those paths anyway.

A good paper to check out is "Complex Clocking Situations Using PrimeTime".
Just google that title.