Figure 1 Crosstalk in data and clock paths 1. Setup analysis Launch clock path sees positive crosstalk delay so that data is launched late. Data path sees positive crosstalk delay so that it takes longer for data to reach destination (D pin in capture FF). Capture clock path sees negative crosstalk delay so that data… read more »
Two primary checks are setup and hold checks. Once a clock is defined at clock pin of a flip-flop (FF), setup and hold checks are automatically inferred for the FF. Timing checks are generally performed at multiple conditions including worst-case slow condition and best-case fast condition. Typically, worst-case slow condition is critical for setup check… read more »
What’s STA environment? Specifying Clocks. Clock uncertainty and Clock latency Generated clocks Input paths constraint Output paths constraint Timing path groups External attributes modeling Check design rules Refine timing analysis Point-to-point specification Set up environment for static timing analysis. Specification of correct constraints is important in analyzing STA results. Design environment should be specified accurately… read more »
Sometimes, for cross clock domain timing analysis, incorrect timing report from mistake Path Delay due to big source clock paths latency/skew or target paths latency/skew would lead tool report and fix timing violation wrongly. Designer analysis launch clock paths latency/skew and capture clock paths latency/skew, find out which path(s) is/are too long, for example, it… read more »
Clock to a SoC/chip is like blood to a dog body. If you want the pet smart and strong, hematological system would be healthy. Just the way blood flows to each and every part of the body and regulates metabolism, clock reaches each and every sequential device and controls the digital events inside the chip…. read more »
Turbodebug check Design netlist about clk div timing path: Fig. 1 Design/inst_clk_div Fig. 2, 3 Design/inst_clk_div/inst_clk_div_mux/inst_mux_nand2/hic_dnt_nand2/ZN Fig. 4 Design/inst_clk_div/inst_clk_div_dff/hic_dnt_out_reg/Q (constraint below create_generated_clock set it as RootPin, but design inst_clk_div/inst_clk_div_mux/inst_mux_nand2/hic_dnt_nand2/ZN as RootPin in CTS Spec file, as Fig. 4 Q pin (out_p) connects to Fig. 2 in0 actually) #Constraint create_clock [get_ports clk4x ] -name dummy_clk4x -period 0.5*0.833 -waveform… read more »
In ECO period, there might be so-called ‘no-margin’ timing situation which means setup margin is not enough for fixing hold violation/add_buffer in the same reg2reg timing path, because besides OCV derating, check setup violation under slow corners and hold violation under fast corners, ratio of delay between SS and FF might be (2.5~3.5):1.
Simplify a general design flow post-floorplan should be: 1st timing driven placement according to constraints, skew/latency was considered as ‘ideal’ zero, optDesign –preCTS. 2nd CTS, optDesign –postCTS. Clock tree have insertion or propagation delay after CTS. 3rd routing, optDesign –postRoute, optDesign –hold -postRoute. Usually, fix setup violation first, then hold violation in order to obtain… read more »
In clock tree synthesis, do ONE thing only, insert CLK INV (NOT CKBUFF !) which could fix rising and falling transition/duty, to min clock tree latency and skew, balance sink/leaf pins which should be balanced, don’t balance pins which should not be balanced. CTS Macro Model Let tool know the segment of clock path latency which… read more »
Sometimes, it is necessary to add constraint, such as set_disable_timing to let tool ignore timing path which should not be checked, critical path would be fixed by tool correctly. set_disable_timing -from in1 -to pass [get_cells dll/dll_delay_line_master/delay_0] set_disable_timing -from in1 -to pass [get_cells dll/dll_delay_line_clk_wr/delay_0] #ezp set_disable_timing -from in1 -to pass [get_cells dll_delay_line/delay_0] #ezp set_disable_timing -from in1… read more »