Congestion + timing violations. How to approach this?

I think there are several things you should look at.

- Now that you know what your multicycle paths are, rerun from the beginning with the corrected constraints. The optimizer may have spent a lot of time and area trying to fix these paths, which could have contributed to congestion.

- For the hold fixing, are your margins reasonable? If you have an unrealistically large uncertainty, then lots of buffers will be added. Also take a look at your clocks. Sometimes a small clock adjustment can fix many holds, without buffers being added.

- For the local congestion, you could try using density screens (partial placement blockages) or cell padding. This may help the hold fixing as well; we typically use cell padding around flops so that there is always room later for buffers to fix hold. If the congestion is more serious, you may need to take another look at your floorplan. Do you have a lot of macros/rams? Give Masterplan a try! See BobD's blog entry "Demo: Automatic Floorplan Synthesis in Encounter".

- Kari

Hi Kari: 

As you said 

>Sometimes a small clock adjustment can fix many holds, without buffers being added.

 Can you give a clock adjustment example to elaborate it more clearly? thank you!

 I just watch the demo about auto-floorplan, it is really mighty!

 What I mean by adjusting the clock is this:

First, you need to look at your hold violations and see if they are all on the same clock branch. If they are, then it's possible you can adjust that branch of the clock to fix a lot of your holds.

If the cause of your holds is a fast data path, then you could potentially slow down that branch of the clock tree by adding a clk buffer in that part of the tree. However, this is not as simple as it sounds because you have to be aware of the consequences. First, you need to see how much setup margin you have on this clock branch (you don't want to cause a whole bunch of setup violations by trying to fix holds this way). Let's say  the clock branch in question is coming off a clk buffer called CLK_BUF_2. You can do the following to check your hold violations and setup margins on the branch:

report_timing -through CLK_BUF_2/A > setups.txt
report_timing -early -through CLK_BUF_2/A > holds.txt

Let's say your holds are failing by 50ps, but your setups only have 10ps margin. If you try to fix these holds, you will break setups. But if the hold margin is something like 200ps, then you should have just enough margin to fix the holds without breaking setups. The trick is finding just the right buffer so that the delay you add fixes the holds in bc timing but doesn't break the setups in wc timing (the delay through the buffer in bc may be 75 ps, but in wc it's 150ps, for example).

In addition to worrying about breaking setups, if you do delay the tree branch, you then may have to worry if you have now caused holds in paths where this branch is the capturing clock. (Yes, it can get complicated!)

If the cause of your holds is a slow capture clock, then you could potentially speed up that branch of the clock tree to fix a lot of your holds. Speeding up is more difficult than slowing down. You could upsize the clk buffer, but you could be messing things up for logic downstream of your current hold violations. Also, if you upsize the clock buffer, that increases the input cap, which slows down the previous level of the clock tree and can also cause problems! A different way would be to clone the clk buffer in question, that way you are only affecting the branch that you want. 

The moral of the story is, any time you mess with the clock tree, there is the potential for causing lots of other problems! That's why the best thing is to have the most balanced clock tree you can from the beginning.

I also thought of something else you could try: have you tried using delay cells to fix your holds instead of buffers? You get more delay time for less area. Just something else to look into.

- Kari

What you have said is very meaningful to me! Thank you very much!

I got much from your reply! Thank you!

Best regards,

Robert Lee