congestion发生在IP的上面而不是边界处 是怎么造成的

place之后查看congestion，其中一个congestion发生在IP上面，而不是边界；
这是为什么呢，工具在place时候会把IP当做blockages的啊！
莫非是因为他们做的IP本来就是congestion的吗?
补充：上图中的congestion不是很大，是overflow为0的grc；

place时把IP当做blockages不代表不在上面走线。
看看具体是哪层金属的congestion,然后看看IP内部走线使用的哪几层金属，基本上就明白原因了。不想在上面走线加个route guide
如果不是很严重可以跑一次无CTS的route看看工具能否解决。
good luck

恩，多谢！
再请问下，查看是哪层金属的congestion如何查看，是通过命令还是图形界面呢?又如何查看IP内部走线使用的哪几层，因为跑的lab，没有相应的IP的信息，只有IP的db库

看你是用的ICC吧。
查看各层金属congestion:
global route congestion显示界面右侧的控制面板，默认是所有层都显示(小方框全部check)，不想看哪层点一下小方框就可以
查看macro内（ram内）使用金属：
左侧控制面板（view settings）右上角有个level按钮，调到1可以看macro内部的金属
另外提一句，ICC上cell的lib一般有两种，一种是db,包含延迟，transition，power等各种参数的，另一种是milkyway reference，包含形状，layer之类的信息。内部金属的信息是在milkyway reference lib里面的。

刚看了一下 macro上的congestion发生在metal6 ，macro内部最高用的是metal5
这个为什么会导致congestion呢 不是很解

macro内 最高是metal4刚刚写错了

个人感觉这个交给工具没啥问题。
原因主要是跨过macro的走线过多，M6无法布开，想换层到下层同方向的M4已经被macro占用，上层同方向的估计是电源布线，自然M6就congestion了。
主要还是place的问题，macro上下（或左右）的cell之间连线有点多。
想弄好一点的话，在macro上加route guide控制一下M6的utilization，或者干脆禁止macro上布线（布线资源充裕情况下），重跑place就可以了。

恩 多谢详细解答！
跑完cts之后再查看一下，这部分的congestion就没了！

我一会再试试你说的方法，设一个guide，在place一下看看

多谢！

蓝色congestion你也看?黄色以后的再看还行?

呵呵，搞懂了，这里的congestion是因为绕线资源不够的；
工具在global route和track assign的时候 给net指定layer，但是macro已经占用了4层layer，工具只能给net分配剩下的两层layer，那么
很可能会造成资源紧张，从而引起congestion。

对，看多了就习惯了