[SOLVED] Timing analysis different between SOC Encounter and PrimeTime

Hi,

At post-Route stage, using SoC Encounter, I verified that there is no hold and setup violation. So I saved the netlist, extract SPEF file and do timing analysis in PrimeTime. But I'm confuse why Primetime shows some timing violations for both hold and setup, about 0.2 ns to 0.4 ns.

My question is why the values is different?

Thanks in advance.

This tools is from different vendors and have different static timing analysis engines.
Check that you specified the same settings (operating conditions, SDC, false pathes, modes...).
PrimeTime is a standard for STA so I think you need to reply P&R until PT passes all timing checks.

Ok thanks.

But that is quite time consuming task because assuming a large design, we need to repeat many times the CTS and routing and feed in to Primetime for STA.

Thanks again.

Hi hairo,

you can as well choose the back annotation technique.
you can let your STA engine (primetime) to do the analysis on ur design and make the FE read those values while optimization.

Dump sdf (Standard delay format) from PT and load the SDF in encounter.

That saves your iteration time, but for final verification, make sure u load the DB back to PT and verify if it has served your purpose.

Good luck

Dear Hairo,

These types of mismatches occurss when (maybe there are others but these are the common ones);
1. There are extraction differences between P&R tool & the 3rd party extraction tool (e.g. Synopsys Star RC Extractor)
2. Derating factor difference between P&R & Prime Time (cell derating, wire derating, net derating, etc...)

In your case, most probably the derating factors used in P&R tool and Prime Time are different.

What is normally done through P&R flows is as below:

1. Dump all endpoints from SOC Encounter routed database
2. Dump all endpoints from Prime Time

Graph these 2 datas on a graphic, and then try to adjust derating factors in P&R tool until you reach a certain point where these 2 data sets provide ~aligned graphics.

This is normally done 1 time for a P&R tool and technology, therefore you can use these derating factors for many design until the P&R tool and technology nodes changes.

This method will prevent a lot of time when fixing timing violations.

I hope it helps,
BR,
Gökhan
---

Hi Gökhan,
Well said. When you migrate to a new technology, usually the CAD Team does the work of finding the scaling factors ( pre-route & post-route ).

I've done this work for few technologies.

Finally, The Implementation tool & the sign-off tool core engines are different. To reduce this different, we use the scaling factor values. Even though you match the parasitic correlation between the tools, the techfile used in the implementation tool is different from the Sign-off Extraction techfile.

Because of the above issues, there will be a difference in timing analysis. That's the reason why we stick to the sign-off checks.

Rgds,
Kumar