SDC file-HOLD and Setup Time

ideally, the sdc for encounter & rtl compiler should be the same except the set_clock_uncertainly (bigger for rtl compiler and smaller for encounter after the real clock tree is built)

li siang

Hi,

In my sdc, there are "if { [info exist some_variable_name] } { ... #for RTL ...} else { ... # for gate level ... }

The different can be due to many reasons, like uncertainty, different in clk pin name (e.g. for RC, in RTL it is called clk, but in gate it can be other names), negative hold check for set_clock_gating_check (RC or primetime might not support negative clock gating check), constraint related to compression logic for ATPG, or mbist (does not exist in RTL), generated clock for RTL (RC does not support generated clock appear in the dotlib, but FE is able to support) etc etc.

I usually load in another SDC constrain file during P&R (loadTimingCon -incr). What is in this file has to do with the strategy you want to due with timing closure etc. For example, I will tune some clocks during physical synthesis, or force keep some cells, or disable some timing arc (e.g. due to FE does not support rise/fall_{from/to/through} yet. Just be careful that what should not be in the additional SDC when performing sign-off STA.

For your other question on connect a block to the memory, I think it is related to "set_output_delay -min/max" and "set_input_delay -min/max". Consider adding a virtual clock to the I/O.

Regards,
Eng Han

Thanks,

I could setup the sdc file with hold and setup time information.
Regards,

Houman

Hi,
Hi,

Thanks fo rthe information.
Now my setup time is fine. But I still have problem with hold time.
The problem is that the encounter tool disregard the hodl time I define for specific port in the sdc file using the command below:

set_output_delay -clock [get_clocks {clk}] -min 0.4 [get_ports {mem_d}]

where I want to have a 400ps hold time.
when I look at the encounter log file it said that:
"No hold time constrain read in"
and even when I change the -min value and increase it close to the clock period I still have hold wns same as before!

Do you have any idea about this?
Thanks.

Houman

Hi Houman,

Could you clarify whether you see the "No hold time constraint read in" message during timing analysis -or- optimization? Perhaps posting the sequence of TCL commands you used would shed some light on what the problem might be.

Thanks,
Bob

Hi Bob,
Interentingly when I introduce the hold time to the tool with a negative value it works fine and it does the hold fix!
so I guess in set_output_delay -min (hold_time)  , hold time should be added as a negative value!  is this true?
Thanks so much,

Houman

and here is the tcl file I use:
set design bist_collar
loadConfig ${design}.conf
loadIoFile  io.io -noAdjustDieSize
setCteReport
setMaxRouteLayer 4
set dbgLefDefOutVersion 5.5
timeDesign -prePlace
loadFPlan ${design}.fp
source power.tcl
setPlaceMode -timingdriven -reorderScan -mediumEffort -noCongOpt
placeDesign -inPlaceOpt -prePlaceOpt
optDesign -preCts    
setCTSMode -topPreferredLayer 3 -bottomPreferredLayer 2 -routeClkNet \
 -useCTSRouteGuide -postOpt
clockDesign
loadTimingCon -incr design.sdc
set step postCts
saveDesign $step.enc
optDesign -postCts -hold
getNanoRouteMode -quiet
getNanoRouteMode -quiet envSuperThreading
setNanoRouteMode -quiet -drouteFixAntenna true
setNanoRouteMode -quiet -routeInsertAntennaDiode true
setNanoRouteMode -quiet -routeAntennaCellName ANTENNA
setNanoRouteMode -quiet -timingEngine CTE
setNanoRouteMode -quiet -routeWithTimingDriven true
setNanoRouteMode -quiet -routeWithEco false
setNanoRouteMode -quiet -routeWithSiDriven true
setNanoRouteMode -quiet -routeTdrEffort 0
setNanoRouteMode -quiet -routeSiEffort high
setNanoRouteMode -quiet -routeWithSiPostRouteFix false
setNanoRouteMode -quiet -drouteAutoStop true
setNanoRouteMode -quiet -routeSelectedNetOnly false
setNanoRouteMode -quiet -drouteStartIteration default
setNanoRouteMode -quiet -envNumberProcessor 1
setNanoRouteMode -quiet -drouteEndIteration default
generateTracks
globalDetailRoute
optDesign -postRoute -setup -hold
optDesign -postRoute
setFillerMode -corePrefix FILL -core "FILL64 FILL32 FILL16 FILL8 FILL4 FILL2 FILL1"
addFiller
addMetalFill
set step postRoute
saveDesign $step.enc -def
verifyGeometry
verifyConnectivity -type regular -error 1000 -warning 50
verifyConnectivity -type special -noAntenna -noUnConnPin -error 1000 -warning 50
verifyProcessAntenna
extractRC
rcOut -spef $step.enc.dat/$design.spef.gz
delayCal -sdf $step.enc.dat/$design.sdf



# Final timing report after metal fill
timeDesign -postRoute -hold
timeDesign -postRoute

exit

Whether a positive or a negative min set_output_delay creates a hold violation depends on the clock period, the clock uncertainty, and the logic that exists between the startpoint register and the output port. With a -min set_output_delay, we're trying to model the minimum time it will take to go from the output port, through combinational logic, to a capturing sequential element (a ram in your case if I recall correctly).

If you're seeking to automate the process of deriving set_input/output_delay values for your block, you might want to consider using First Encounter's Timing Budgeting capabilities. If you have a top-level view of the design with the block you're working on as a partition, and the RAM your block talks to instantiated as a hard macro, First Encounter can derive timing budgets (set_input/output_delay values and more) for your block.

Thanks,
Bob

Hi Bob,
Thanks for your reply, but I still didn't figur out how to introduce the encounter my memory hold time.
so basically I have a block to be synthesized and be connected to memory port. The memory port has hold time of M. so My question is that in (the set_output_delay -min M) shoudld M be a negative value? (with its absolute value equal to memory hold time?)

Thanks,

Houman

Hi Houman,

It is dangerous to try negative or positive value and pick the one that work. I suggest you study the timing report carefully to understand what has happened. If possible, you can paste the old timing report here so that we can explain the reason.

Note that the "-min" has different meaning when you run in bcwc (best case worst case) mode or single mode.

Regards,
Eng Han

The semantics to  set_output_delay -min   are   (IMHO) inverse from what
one might expect .

If you were to picture the set_output_delay -min contraint as as the hold check on
a flip-flop in the fanout of the output port, you would assume that a positive value
would make the check more conservative - this is  not the case.

The value specified for set_output_delay -min is subtracted from the clock
edge. If the value is positive, then the required time is earlier, and
hence the slack is increased.

A negative set_output_delay min means that the data is required to stick
around past the reference clock - which decreases the slack.

The polarity of hold check values in .lib and those specified in set_output_delay -min
are not the same.