encounter时钟树综合fanout的处理

本人使用encounter9.1进行0.18um物理设计，设计大小为30k门，时钟周期1ns，CTS后时钟21级，造成时钟tree延迟4ns，多周期路径直接就违反啦。
但是同一个设计使用ASTRO，CTS只有14级，CTS延迟1.8ns。
为了降低CTS级数，采用floorplan调整，CTS的specFile中max_delay设置为2ns（设1ns时级数有29级），skew为100ps，transition为400ps，只用4x-12x的单元，这样级数下降至18级，但时钟延迟依然高达3.8ns，我发现有的12xbuf竟然驱动64个x1的DFF，是不是fanout过大造成时钟树级数过多?
我尝试了许多方法，依然没有把CTS的级数降下来，请大家帮忙指点一下。多谢。

可能astro确实比encounter略胜一筹啊

You can provide the user CTS configuration to reduce the level of Tree.

用Clock Tree Analysis分析一下

在ctstch文件中添加maxFanout 16对clock-tree的buffer进行约束.这样不会出现大的fanout违反.

控制transition也可以

5# jiazhuliang
16也太狠了吧

30k门的设计，居然会18级，还最多64个?
把报告仔细看看，这不大可能。

推64太多，48个差不多

DAFASDFASDFASDFASDFASDF

.18um设计的transition 一般都是1~2ns， 400ps有点小了
而且clock period 是 1ns ， 是不是太快了，跑一个G啊?
一般clock transition 过小会造成 插入buffer过多的，
100ps skew 是不是也小了些，有时候做不到的，
maxfanout是可以改下，64好像大了些，
cts算是edi的强项，以为clock spec可以改，比较方便，不会输给Astro的，

小编强大

学习路过……

频率太高，高频的模块是否放得紧凑点。skew 设得太紧。

学习，受教了

问题解决了?我现在也碰到这个问题 T=2ns 级数有34

学习啦 谢谢

0.18工艺要跑到400MHz，那么ckock transition设置多少啊我把skew限制在400ps，fanout限制在20，合适吗?设计规模大概在不到10K的样子