HOLD FIX FLOW IN ENCOUNTER

I have not had too much luck with hold fixing. It adds a lot of buffers and our designs are quite tight as far as utilization is concerned. So I have had congestion problems created by hold fixing.

After CTS I usually go through clock reports in detail to see why skews didn't get fixed properly. Usually the culprits are one of the following -
a) Floorplan needs to be revisited. Too many routes, density issues.
b) Is shielding turned on? In smaller technologies I have seen that 2x spacing is better than shielding. Also allocate enough layers for clock routing.
c) Remove the larger buffers from the CTS buffer list
d) Adding the inverting CT cells to the buffer list sometimes helps with skew issues.
e) Do you have generated clocks - If this is the case, make sure that the "through pins" are coming out correctly in your clock spec file. Make sure that the root pin and the source pin are defined correctly in the SDC. If this doesnt work try doing a 2 step CTS - you can find an article on this in the cadence website.
f) See if there are reconvergent paths in your clock tree. Use -forceReconvergent option in CTS.


Thx,

Sanjay

If utilization looks like it will be a problem, we use specifyCellPad on our flops to leave room for an eventual hold-fix buffer. We've had good success with that method. Also, if FE is adding tons of buffers, you may want to revisit your hold margin and make sure it's not too unrealistic.

- Kari

if the hold violations are at the Si pin of the flop, you mgiht want to re-order the scan chan using
scanReorder -clkAware after CTS.  It will help to reduce # of hold violation to the si pin if your design has a lot of gated clock trees.

li siang

Hold fixing can be a pain. does the log file tell you anything as why its using dont use cells. I didnt see this issue so far. But i think this is a soft constraint.
FE can only fix hold on paths if they dont violate setup or transition  or if they are not declared to be critical nets by user.
It does delay or buffer insertion only. I have seen sometimes it quits without fixing few paths even if these paths are not setup critical. they have to be fixed by hand. use ver 6 and above

Kari, How does one judge what a realistic hold margin is?

I have also had good results with scanReorder -clkAware post CTS.

Ed

Hi Ed,

That's a difficult question to answer. It's really just a feel you get after working in a certain process for a while. We had a customer that was doing their first 90nm design, and they were very paranoid about hold margin and picked a large number. We knew from doing many 90 nm designs that what he picked was unrealistic, and we were able to suggest something more reasonable. Some folks base it on a percentage of the clock period. Also, it's usually a combination of time to account for clock jitter, and some extra padding. But depending on whether you're using OCV or not, you can adjust the extra padding part. Also, you don't want to pick a hold uncertainty number that makes your design blow up (so many buffers get added that your utilization goes through the roof). Sorry I can't give a more concrete answer.

- Kari