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
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
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
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:
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 (
#################
##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
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.
hai
ReplyDeletewhat happend in tapout stage if not fixing hold voilation and setup voilations