How to identify the point which is to be skewed for tile to tile interface from timing reports

 Need for skewing. Skewing need to be done in the following cases 

• High skew would increase the number of buffers getting added in the lowsvs corners 
• Lowsvs setup is critical and each buffer added in lowsvs would add 200ps and same would only give 18ps or less in high vt corners. 
• Memory paths which need to be balanced would be critical and they mostly need to be skewed 

How to identify the point which need to be skewed. 

• Most likely these would be mux outputs. 
• We can identify this by a crude way by filtering without a design knowledge by using the following simple command 

Steps 

• The below command would give you the common pins which are repeated n number of times. 
• Pick up the points from below and check if the skewing can be done at the below points. 
• Identify if these are outside the block A and block B where they can be skewed at the top interface 
• This would reduce the analysis time. 
• If you have design knowledge you can directly identify the points which can be skewed based on design knowledge

debugging high latency during CTS

 During CTS we often see multiple clocks getting balanced. Sometimes we also find clocks which are not be balanced getting balanced by the CTS engine. 

CTS engine tries to balance the clocks based upon all the clocks reaching the end point or sink pin

Step1 : Get all the clocks reaching the path with high latency sink pin using the following sink pin. 

Step2: identify muxes in the clock path 

Step3:  check clocks on b pin 

Step4: check clocks on a pin 

step5: check the case value on the mux sel pin

If there is no definition of the case_value on the sel pin. Then ideally there should have been two generated clocks defined on the output of the z pin and defined logically asynchronous to resolve the issue.

 Check all clocks on the sink pin 

pt_shell> get_attribute [get_pins  {module/u_cmux2_SIZE_ONLY/z} ] clocks

{"CLKM1_long_latency_clk", "CLKM1_main_clk"}

report the clock path using the below clock and identify mux in the path by reporting the problematic clock 

report_clock_timing  -to  {mux/reg[1]/clk} -type latency -clock  main_clock -verbose

Check the clocks on b pin of mux 

pt_shell> get_attribute [get_pins  {module/u_cmux2_SIZE_ONLY/b} ] clocks

{"CLKM1_main_clk"}

Check clocks on a pin of the mux 

pt_shell> get_attribute [get_pins  {module/u_cmux2_SIZE_ONLY/a} ] clocks

{"CLKM1_long_latency_clk"}

Check case value on the mux ( If the case value is not defined then both clocks get propagated 

pt_shell> get_attribute [get_pins  {module/u_cmux2_SIZE_ONLY/sel} ] case_value

==> no case value defined

create the generated clocks at the mux output with the two clocks on A pin and B pin 

create_generated_clock -name CLKM1_main_clk_DIV1 -source [get_ports \

 {main_port}] 

  -divide_by 1  -add -master_clock [get_clocks {CLKM1_main_clk}] 

 [get_pins -hsc module/u_cmux2_SIZE_ONLY/z}] 

create_generated_clock -name long_latency_clk_DIV1 -source [get_ports \

 {main_port}] 

  -divide_by 1  -add -master_clock [get_clocks {CLKM1_long_latency_clk}] 

 [get_pins -hsc module/u_cmux2_SIZE_ONLY/z}] 

set_clock_groups -logically_exclusive -group [get_clocks CLKM1_main_clk_DIV1 ] -group [get_clocks CLKM1_long_latency_clk ] 

Issue fixed ? Share your thoughts on how else can we fix this issue and ways of debugging. Pros and cons of those ways of fixing.