SETUP and HOLD Violations on same path in same corner

[chevuturi]

Hello Everyone !

is there any possibility of getting setup/hold violations in same path and same corner ? if yes could you please explain cases and fixes ?

 

[oratie]

The simplest case:
you have a huge crosstalk delta-delay. For setup analaysis delta-delay is added to net delay. For hold analysis delta-delay is deducted from net delay.

 

[ThisIsNotSam]

you can have the same FF involved in the worst setup path and the worst hold path. but the paths themselves are different. this happens sometimes and is likely what you are asking about. Yes?

otherwise we are talking about really unusual cases like what oratie is alluding to above.

 

[chevuturi]

I understood , How do we fix if the FF is involved in the worst setup path and the worst hold path ?

--- Updated Jan 18, 2024 ---

The simplest case:
you have a huge crosstalk delta-delay. For setup analaysis delta-delay is added to net delay. For hold analysis delta-delay is deducted from net delay.

So in this case first we need fix crosstalk delay right ? apart from applying NDR rules do we have anything else to take care of this particular issue ?

 

[ThisIsNotSam]

That depends. Assuming you already asked the physical synthesis tool to optimize for setup/hold, then you might be looking at redesign. Perhaps allowing for less timing borrow fixes the problem. Perhaps reducing the target frequency solves the setup and gives hold some margin to be fixed. Perhaps reducing pessimism margins if they are too extreme. It becomes an engineering problem at this point. There might be many solutions, some simple, some complicated.

 

[chevuturi]

Thanks Understood !

 

[oratie]

I understood , How do we fix if the FF is involved in the worst setup path and the worst hold path ?

--- Updated Jan 18, 2024 ---

So in this case first we need fix crosstalk delay right ? apart from applying NDR rules do we have anything else to take care of this particular issue ?

NDR (and/or shielding) is a good decision for this. Also, you can decrease driver of agressor or increase driver of victim.

 

[ThisIsNotSam]

If it really is coming from net to net crosstalk, then NDR can help, shielding can help, floorplanning changes can help (say, you have a weak signal next to a gigantic bus, you can them prevent placement next to it using fences/screens), via jogging can help (go up/down one metal layer).

 

[glennramalho]

If you think of it, the conditions of setup and hold are not quite the same. The hold is done with best case timing, setup with worst case timings. So we could think of a situation where data between two flops can take a very short path, where it sees only one OR gate and data through a very long path with several levels of logic. So we could imagine a case where the shorter path is taken for the hold check and the longer path for the setup check.

Besides that...

If you are messing with the clock. For example the FPGA synthesis can tweak the phase of a PLL to improve timing on a domain. On a very tight design this winds up eliminating setup violations but creating hold violations.
Also if you are doing some nasty stuff with the clock tree. The tree itself should only have clock gates or buffers. If you have ripple clocks especially if not properly constrained you could have some hold violations showing up.
And sometimes I have seen when the clock is too fast for the design and the tool gives up on fixing the setup and then leaves violations setup and hold violations.

Usually then what I do is:
- run a linting checker to see if there is something odd
- check the warnings in synthesis. Perhaps one gives a hint of something unusual
- make sure the clock is clean, constrained just right
- if all looks ok, then examine carefully the setup violations. Make sure it is legitimate. If it is, fix it, one at a time. The hold violations often go away by themselves when the setup violations get fixed.