Footprint Collector

Question:

I have a complex clocking scheme in which my two clocks have a frequency ratio of 3:2 and only certain edges can be used for launching or capturing data on cross-domain paths. Using the set_multicycle_path command is not adequate to model the launching and capturing edges in my case.

Specifically, I have a 333 MHz clock called clk_333 and a 222 MHz clock called clk_222. These clocks are synchronous to each other, and all data transfers between the two domains occur on the rising edges of each clock (that is, a rising launch edge and a rising capture edge). Data is transferred from the clk_333 domain to the clk_222 domain as well as from the clk_222 domain to the clk_333 domain.

Clock clk_222 launches data and captures data on every cycle, while clock clk_333 skips one launch edge (M2) and one capture edge (M4) every three cycles to match the clk_222 data rate, as shown in the waveform diagram below. Therefore, data transfers occur from M0 to B2 (green arrow), M4 to B0 (purple arrow), B0 to M2 (orange arrow), and B2 to M0 (blue arrow). No data transfers occur from M2 to B2 or from B2 to M4 (red arrows).

How do I model such a complex clocking scheme?

Answer:

The set_multicycle_path command cannot be used to model the clock relationships described above. Instead, generated clocks must be used to implement separate launch and capture edges for each clock domain, and transfers which cannot occur must be treated as false paths. The following set of constraints will model the arrangement described in the waveform diagram above.

create_clock [get_ports CLK1] -name clk_333 -period 3 -waveform {0 1.5}

create_clock [get_ports CLK2] -name clk_222 -period 4.5 -waveform {0 2.25}

create_generated_clock [get_ports CLK1] -name clk_333_launch -source [get_ports CLK1] -edges {1 2 5 6 7} -add

create_generated_clock [get_ports CLK1] -name clk_333_capture -source [get_ports CLK1] -edges {1 2 3 4 7} -add

set_false_path -from [get_clocks clk_333] -to [get_clocks clk_222]

set_false_path -from [get_clocks clk_222] -to [get_clocks clk_333]

set_false_path -to [get_clocks clk_333_launch]

set_false_path -from [get_clocks clk_333_capture]

foreach_in_collection this_design [get_designs *] {
set this_design_name [get_object_name $this_design]
if { ![regexp {foo_} $this_design_name] } {
rename_design $this_design -prefix “foo_” -update_links
}
}

My design looks like the above picture. Clocks clk_A and clk_B are asynchronous. So we set,

set_clock_groups -asynchronous -group clk_A -group clk_B

Or,

set_clock_groups -logically_exclusive -group clk_A -group clk_B

Or,

set_false_path -from clk_A -to clk_B
set_false_path -from clk_B -to clk_A

If you don’t set any other constraints, Primetime will probably report timing path from clk_A -> FF1/Q -> Domain B -> FF2/D -> clk_A. The path should be false because clk_mux and data_mux are selected differently. So we also need to set,

set_case_analysis 0 sel #check timing for clk_A domain
set_case_analysis 1 sel #check timing for clk_B domain

An alternative way to prevent PT from reporting the false path, we can set,

set_false_path -from clk_A -through data_mux/B
set_false_path -from clk_B -through data_mux/A

We succeeded in TD phone call test on live network for its first silicon today on June 5, 2009, which happened in only 10 days after the chip arrived at the lab. This is marvelous and memorable milestone of the project. Cheers!!

芯片回来有一周了，目前Lab测试情况良好，和modem相关的基本都pass了，就差打电话了。

不过还是发生了一些小状况，比如昨天的小数分频器，从312MHz时钟分出10.24MHz，分频比为312/10.24=30.46875倍。默认的参数配置是错误的，大概有268ppm的频率误差。经过昨晚上仔细计算，重新得到了配置寄存器的值，现在可以得到精准的10.24MHz时钟了，当然前提是312M是精准的。幸亏参数没有做死，DSP还是有机会在初始化的时候通过配置寄存器来改变分频参数，不然真死翘翘了。