Understand the design hierarchy:
Know from which block to which block you want to analyze
See report and check the clock group or capture clock of your interest
Analyzing paths:
report_timing -from
startpoint -to endpoint -pba_mode path -path_type full_clock_expanded -nets -input_pins -significant_digits 4
if slack is -ve (violating); then follow below techniques.
Order of fixing the setup violations:
Use Pba mode with path (during early eco) and exhaustive (during final eco stage)
1. Reducing data path delay:
-----------------------------------------------------
report_timing with below options (derate, trans, cap, and net):
- see whether derates are applied properly or not
a) Sizing of data path cells (increasing the drive): Sizing would be first choice as buffering needs extra space comparatively.
Example:
U1/z (ref_name) 0.06 H 28.38 f
get_alternative_lib_cells -current_library U1
size_cell instance_name Upsized_lib_cell
a) Buffering to reduce delay
insert_buffer Instance_name/pin buf_lib_cell
E.g.: insert_buffer U1/z buf_v20_12
c) VT swap:
- Change to LVT (generally, 20% LVT and 80% SVT+HVT)
size_cell HVT_instance_name LVT_lib_cell
d) cross talk
e) derate check
f) Jog to higher layer (check with P&R guys; not in PT domain)
2. Check the insertion delays of launch and capture clocks and try to balance them.
http://tech.tdzire.com/timing-eco-flow-with-examples/
At the early stage of the design,
1. See whether the skew of the launch and the capture clocks are balanced.
If launch clock is having more latency, the data will come late to the capture flop,
and thus result in setup violations.
For setup violations:
- increase the capture clock latency
- decrease the launch clock latency with set_anootated_delay command
and see whether it is not resulting in any additional violations and viceversa
for HOLD violations.
At matured stage of the design:
1. Try not to touch clock tree.
2. Decrease data path delay.
- size up, change to lower vt,
2. Clock path tweaking (push/pulling the clock path): Recommended this at the initial timing ECO changes.
-----------------------------------------------------
Pusing is prefered to pull clock because adding delay on net is fine and can be done easily but reducing delay is tough.
2a)Pushing the clock going to FF2/CP2:
insert_buffer in the clock path
before clock pin.
while inserting do -path_type full_clock_expanded then insert before clock pin
insert_buffer U2/z buf_3x_ref_name
For exampale, setup slack = -30ps
and adding 3 buffers of 10ps each in
SS corner (note that FF corner it is 5ps each).
Since we are fixing setup violation of FF2/CP2 by adding some delay in the clock path (required time increases), so potentially -> there is a chance of hold violation as it is (AT-RT).
i)Checking setup @next stage: (+30ps)
report_timing -from FF2/clk -pba_mode path
i.e., report_timing -from FF2
/clk -pba_mode path
This is checking for those particular paths. But, clock pin is connected to so many flops (parallel branches of capture FF). so we need to consider all flops which are connected to clk pin which we are going to push.
Getting all flops which are connected to clk pin:
all_fanout -from path_till_FF2/clk -flat -endpoints_only -only_cells
Check setup to all these flops:
report_timing -from [ above_cmd] -pba_mode path
Getting the margins from next flops:
If slack is -ve, then use -exclude {failed_slack_end_point full_path} and try again. After doing this, if slack is positive then fix above failed path; then you can push the clock.
ii) hold check violation to FF2/D in
FF corner: at the same stage: (+15ps)
report_timing -delay_type min -to FF2/D -pba_mode path
and see whether 3*5ps = 15ps margin is available or not.
Same logic applies to hold as well:
Getting all flops which are connected to clk pin:
all_fanout -from /clk -flat -endpoints_only -only_cells
Check hold to all these flops:
report_timing -delay_type min -to [ above_cmd] -pba_mode path
2b) Pulling the clock going to FF1/CP1:
Reduce 30ps delay in the launch clock path in SS corner (-30ps).
i) Since AT is reduced to fix setup here, check hold at the same stage first in FF corner (+15ps).
report_timing -delay_type min -from FF1/CP -pba_mode path
ii) setup violation from previous stage in SS corner (+30ps ):
report_timing -to FF1/D
------------------------------------
The above examples w.r.t report looks as shown below:
################
finalopt_SIZE_ONLY_BUF_INST_31/z (buf_8x_ref_name)
0.10 H 28.32 f
U1/z (
) 0.05 H 28.37 f
#################
##Getting slack margins to startpoint to pull the clock:
# Get list of cells to which you want to know the slack margin
set cells [get_cells { \
start_point ##put start_point path in the report; remove clk pin \
}]
# get input pin (data pin) of those cells and get slack, sp using get_timing_path command
set f [open fanin.txt w]
foreach_in_collection cell $cells {
set ipin [get_pins -of_objects [get_cell $cell] -filter "direction==in"]
foreach_in_collection pin $ipin {
set p1 [get_timing_path -through $pin ]
set slack1 [get_attribute $p1 slack]
set s1 [get_attribute $p1 startpoint]
puts $f "[get_attribute $pin full_name] [get_attribute $s1 full_name] $slack1"
}
}
close $f
II) Fixing Hold violations:
i) pba mode (path/exhaustive) should resolve most of the violations.
ii) End point buffering
- It won't affect prev and next stages.
iii) Downsize in the data path:
- Make sure that max_transition violations don't occur as tool might have put it for transition purpose and not for delay pov.
iv) LVT -> HVT
3) Net optimization:
If setup violation is very less and there is no scope in data path then check whether nets can be optimized by promoting the critical nets to top metal layers. Since top metal layers are thicker, capacitance is lesser and thus net delay will be less. So usually clocks and critical nets are routed at the top metal layers.
Before giving fix to Physical design team, make sure there are no new violations introduced due to the fix. if setup is not fixable at all, check whether it is within the uncertainity range. If not we may have to reduce the frequency. But keep in mind that this is the final choice.
For fixing hold violations, follow reverse procedure.
#########
TIPS:
#########
1. Check whether the launch and capture clocks are same or different.
If different, check whether they are synchronous.
If asynchronous and can be set as false path, then add the missed false path in your exceptions.
2. Check whether spef is annotated properly
3. Now check whether the launch and capture clock edges are as intended. That is to check whether some multicycle path is missed in the exceptions or not.
4. Next thing is to check with the clock path in launch and capture path, whether they are traced properly as intended.
Sometimes even if launch and capture clocks are the same they will be traced through different paths to make the analysis pessimistic. These can happen if you have muxes in the clock path.
5. If the clock is not traced properly, CRPR may not be removed properly.
6. Check whether the deration and uncertainity values applied properly.
7. Once you figured our that the path is valid, and if it is a setup violation, just see whether one cell is giving big delay. If yes check with the physical design team whether this is placed far away or not.
8. Check with the RTL team to confirm whether the clock freq is same if it a setup violation.
###############
If there are a lot of violations and power is not critical:
report_timing -slack_lesser_than 0 -max_paths 200000 -nworst 100 -delay max > max_paths.rpt
DMSA setup can check ECO across modes and corners in one shot. During final stage, do VT swap only as it will not disturb DRC.
