about how to fix hold timing violations, one new idea

Hi , all:
I put forward a new idea about how to fix hold timing violations, anyone
intresting in this field pls give some points, thanks.

OK,in normal case , we synthesis the RTL code in DC, in the synthesis envirnment , we don't care hold time violations. then we do place & route in
backend tools, and fix setup time violations , after fix setup time violations, we
begin fix hold timing violations, but i found , when fix hold timing violations, the backend tools basicly insert buffer in the front of the end_point DFF in one path,
so , the buffers inserted by backend tools are very much, this will result in some
disadvantages:
a. extra power waste;
b. more area waste;
c. maybe destroy setup timing path
d. if uitilization of die is high, will induce fail place&route

Then how to reduce the inserted buffers is critical!
Typically, if one path exists hold timing violation, the data path level will
not be too deep. but we should not insert the buffer too closely to the end point DFF, if we can find one common cell, which induce hold timing violation, it's bottle
neck cell, then we insert buffer after the bottleneck cell, this will fix all hold timing violations after the bottleneck cell, and this way will save many buffer.
I think we can do it in primetime , by script , we search the bottleneck cell, and try to insert buffer, if the changes can fix hold violations , tell backend tools where to insert buffer.
The remaining work is how to write script to search the bottleck cell.

yes it will reduce the holdfix buffers a lot.The only issue is,when we put a buffer the endpoints flip-flop we check the setup slack at that flop wrt to all the possible start-points.now if we go one level up the logic we have to check all the setup slack impact through that path

hi,

One thing i want to point out here .... or you can say that i need some clerification before I will comment over this approach.

As you know that setup slew = required time - arrival time
and hold slew = arrival time - required time.

now for calculating the required time and arrival time for the hold .. we usually follow the following approach.
shortest arrival time
longest required time.

Now arrival time is other sense is only the path contain the clock tree. means clk-> some buffers -> then clk pin of end FF. Now here most important thing is "some buffer". till u will not do the clock tree synthesis (CTS), clock tree is not present and the clock path is consider as ideal. so in one way I can say that worst(longest required time ) is not possible to calculate before CTS. and if that is not possible then fixing of hold check doesn't make sence.

this is my understanding .. and I hope this is the reason ..
"during synthesis the RTL code in DC, in the synthesis envirnment , we don't care hold time violations. then we do place & route in backend tools, and fix setup time violations , after fix setup time violations, we begin fix hold timing violations,".


let me know if your intension is something else. Or I misunderstood your idea.

It's not a new idea, though. In fact, it is widely used method. You always need to do a bottleneck analysis before inserting the buffers and add buffers at the proper locations.
And yes, you can do it with Prime Time. I had a tcl script that does a similar thing.
Search the command, report_bottleneck.

Hi,

Your idea works very fine. In my last project there are some hold violations , if we observe those violations, the start and end point are diffrent but there are some common cells in all hold violating paths.

So ,at that time , I put buffer at that bottle neck cell ,it helped to reduce hold violations very a lot.

Generally some scripts are there to put buffers end end points.

But ur idea works very fine....

Just need of sorting all hold reports and in that finding common cell in that report is needed to write script.

I have checked manually that bottle neck cell ,due to very less timing paths(around 25).

But we need to check the setup margin is there or not. Then we can proceed.

It works very fine...