Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[SOLVED] Hold time violations in post layout simulation (Although STA is fine)

Status
Not open for further replies.

ranaya

Advanced Member level 4
Joined
Jan 22, 2012
Messages
101
Helped
4
Reputation
8
Reaction score
9
Trophy points
1,298
Location
Kelaniya
Activity points
2,164
Dear All,

I have a pipelined design that was placed and routed in Innovus in MMC view. So the setup and hold views are based on worst and best corner libraries respectively. Starting from bc_wv view, the design was incrementally optimized (pre/post CTS) and the final post route optimization was done in the mode called OCV. Both postRoute timeDesign (Innovus) and Primetime STA have validated that the design is free of setup (WC .sdf) / hold (BC .sdf) violations.

But the post route simulation in NVSIM with annotated typical.sdf (extracted from Innovus after setting the design to typical view) and the post layout netlist gives me hold time violations. I've checked the clock constraints in testbench and they seem to be okay. Design does not have multiple clock domains, nor cross clocking. The simulation over the typical conditions is intended for the power analysis. Any possible explanation for this behavior ? Or am I missing a switch in simulator ?

PS: However I had the same clock uncertainty defined in both synthesis and P&R and clock propagated mode on. i.e. Could this be a reason ?

Thanks and BR

Anuradha
 

this is not normal. the most common mistake is that folks don't know how to setup the simulation environment with the `timescale directive. make sure your simulation has the right clock period.

if that is fine, make sure your simulated netlist has a clock tree and that the clock is propagating with different delays to different elements. backtrace from there and try to debug.
 
  • Like
Reactions: ranaya

    ranaya

    Points: 2
    Helpful Answer Positive Rating
Hi, yes the timescale was correctly set in the environment and test bench. Before going into the debugging, I want to clarify the constraints I've set in synthesis and P&R.

1. For the synthesis, the propagated clock is used to estimate the latency in the clock network and therefore we have a realistic slack time, am I right ?
2. Can we use the same "propagated clock mode" at the beginning of P&R (as was in synthesis) and perform the optimizations ? or should the clock mode be always ideal in the constraint file at the beginning of the P&R and then after the CTS, P&R calculates the real network delay ?
3. Should the clock uncertainty defined in P&R constraints be always smaller than the uncertainty in synthesis ?

Thanks
ranaya
 

Hi, yes the timescale was correctly set in the environment and test bench. Before going into the debugging, I want to clarify the constraints I've set in synthesis and P&R.

1. For the synthesis, the propagated clock is used to estimate the latency in the clock network and therefore we have a realistic slack time, am I right ?
2. Can we use the same "propagated clock mode" at the beginning of P&R (as was in synthesis) and perform the optimizations ? or should the clock mode be always ideal in the constraint file at the beginning of the P&R and then after the CTS, P&R calculates the real network delay ?
3. Should the clock uncertainty defined in P&R constraints be always smaller than the uncertainty in synthesis ?

Thanks
ranaya

You are not using clock uncertainty correctly, but that is another problem. It has no bearing on the simulation issue.
 

You are not using clock uncertainty correctly, but that is another problem. It has no bearing on the simulation issue.

Yeh, I doubt so. But could you please kindly tell me how it should be used correctly ?

ranaya
 

@ThisIsNotSam :

Hi, this was resolved. The issue was in the .sdf annotation. I hadn't specified the MTM spec correctly in sdf annotation (wheres by default typical value is used) which also leads to the wrong clk -> Q delays.

ranaya
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top