Timing Mismatch in Cadence Genus and Innovus

[Dedong]

Hi,

During synthesis using Genus, timing is met with around 1ns positive slack while before placement in Innovus, timing is violated with around 10ps negative slack. Could I ask what's the possible reason for this?

I'm using GF22nm technology and the SDC file is as following:

#==================================Env Vars===================================
#time unit is ps for GF22nm technology
set TIME_UNIT 1
set CYCLE1000G  [expr 1 * $TIME_UNIT]
set CYCLE500G   [expr 2 * $TIME_UNIT]
set CYCLE200G   [expr 5 * $TIME_UNIT]
set CYCLE8G     [expr 125 * $TIME_UNIT]
set CYCLE4G     [expr 250 * $TIME_UNIT]
set CYCLE2G     [expr 500 * $TIME_UNIT]
set CYCLE1G     [expr 1000 * $TIME_UNIT]
set CYCLE500M   [expr 2000 * $TIME_UNIT]
set CYCLE400M   [expr 2500 * $TIME_UNIT]
set CYCLE333M   [expr 3000 * $TIME_UNIT]
set CYCLE303M   [expr 3300 * $TIME_UNIT]
set CYCLE250M   [expr 4000 * $TIME_UNIT]
set CYCLE200M   [expr 5000 * $TIME_UNIT]
set CYCLE100M   [expr 10000 * $TIME_UNIT]

#==================================Design Env=================================
# for clocks, set infinite drive strength to avoid automatic buffer insertion
set_drive 0 [get_ports [list clk]]

# 1/resistance as drive, proportional to cell size
# should be small enough
# AND2 SC8T_AN2X0P5_CSC20R in GF22FDX
set_driving_cell -lib_cell SC8T_AN2X0P5_CSC20R [remove_from_collection [all_inputs] [all_clocks]]

# capacitance as load, proportional to cell size
# should be large enough
# D pin cap of SDFF SC8T_SDFFX1_CSC20R in GF22FDX
set_load -pin_load 0.48356 [all_outputs]

#==============================Design Optimiz Constr=========================

#--------------------------------Clock Definition------------------------------
create_clock -name clk -period $CYCLE303M [get_ports [list clk]]

#jitter + skew + extra margin
#skew is removed after CTS
#if timing violation within the uncertainty range, ignorable.
set_clock_uncertainty -setup [expr 0.1*$CYCLE303M] [all_clocks]

#skew + extra margin
#skew is removed after CTS
set_clock_uncertainty -hold [expr 0.05*$CYCLE303M] [all_clocks]

#removed after CTS
set_clock_transition [expr 0.01*$CYCLE303M] [all_clocks]

#--------------------------------I/O Constraint-----------------------------
#rst_ports
set rst_inputs [get_ports [list \
    rst_n \
]]
set_ideal_network $rst_inputs

#ports in clk0 domain
set clk0_ports [get_ports [list \
    spk_pre \
    spk_post \
    plas \
]]

set clk0_inputs [get_ports $clk0_ports -filter "port_direction == in"]
set clk0_outputs [get_ports $clk0_ports -filter "port_direction == out"]

set_input_delay -max [expr $CYCLE303M * 0.6] -clock [get_clocks clk] $clk0_inputs -add_delay
set_output_delay -max [expr $CYCLE303M * 0.3] -clock [get_clocks clk] $clk0_outputs -add_delay

#---------------------------------Timing Exceptions-----------------------------
# configurable signals from another clock domain

set false_ports [get_ports [list \
    inter_mod \
    ltp_wnd \
    ltd_wnd \
    lrn_intnsty_arr \
]]

set false_inputs [get_ports $false_ports -filter "port_direction == in"]
# set false_outputs [get_ports $false_ports -filter "port_direction == out"]

set_false_path -from [get_ports $false_inputs]
# set_false_path -to [get_ports $false_outputs]

Thanks!

Best Wishes,
Dedong

 

[ThisIsNotSam]

Innovus will always try to barely meet the timing, so in many cases 10ps negative is good enough. If you are wondering where the extra 1ns went, it could be due to routing, clock tree, pessimism, a lot of things that genus is not equipped to handle.

 

[Dedong]

Innovus will always try to barely meet the timing, so in many cases 10ps negative is good enough. If you are wondering where the extra 1ns went, it could be due to routing, clock tree, pessimism, a lot of things that genus is not equipped to handle.

Hi,

Thanks for the useful information!

I tried to rewrite my sdc file with different clock frequencies and found that whatever the clock frequency is, the negative timing slack is always -19ps at the first timing arc. It's really interesting. The timing reports in Genus and Innovus are as attached.

If you like, could you please talk a little more about the timing issue?

Thanks!

Best Wishes,
Dedong Zhao

 

[ThisIsNotSam]

it is easy to compare the paths and see the differences between logic synthesis and physical synthesis.

in genus, your clk->q delay is 173ps. in innovus it is 183ps. this is likely because now you have real wires that are capacitive and slow down the propagation.

 

[Dedong]

it is easy to compare the paths and see the differences between logic synthesis and physical synthesis.

in genus, your clk->q delay is 173ps. in innovus it is 183ps. this is likely because now you have real wires that are capacitive and slow down the propagation.

Thanks for the reply.

Could I ask where the -19ns of required time in the Innovus timing report come from?

 

[ThisIsNotSam]

the clock tree synthesis determined that the clock pin of this specific flip-flop is reached at -19ps.

the use of negative numbers is confusing, but it only means there is another flop for which the clock arrive at time 0ps and that is the reference. the clock arrives at this one 19ps faster/earlier.

 

[Dedong]

the clock tree synthesis determined that the clock pin of this specific flip-flop is reached at -19ps.

the use of negative numbers is confusing, but it only means there is another flop for which the clock arrive at time 0ps and that is the reference. the clock arrives at this one 19ps faster/earlier.

Thanks for the reply. As I said, the Innovus timing report is generated before placement which means that CTS hasn't been done.

 

[ThisIsNotSam]

Now I am confused. Are you sure this is before placement? The critical path you get from genus should match the critical path from innovus at the time you load the design in innovus. Yet this one is different.

If this is indeed before placement, then my explanation about clock tree relative delay is not applicable.

 

[oratie]

Well, in Genius you have
Uncertainty:- 330

In Innovus
Uncertainty 350.000

Is it 20ps difference?

 

[ThisIsNotSam]

good observation, but I am not sure that is the answer -- I noticed the clock period is also different.

I am still confused whether the reports really are from pre-place.