Congestion + timing violations. How to approach this?

 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 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