ENCOUNTER布局布线有可能增减FF的数目吗？

应该不会吧！如果少了FF lec的时候怎么会过。 FF是一个map&compare point哇。这个点没有怎么比对。

不会的， all_register 出来的肯定是一样的，状态机数目怎么可能改变

谢谢你的回复。我又看了一下设计，确实是APR之后FF的数目不一样了，但是formality里的检查是可以过，显示没有unmatch point以及Verification succeeded。
如果是以下这样的情况，你觉得会不会产生FF数目的差异?
假设我调用库里的寄存器直接搭建了一个状态机的状态寄存器，以独热码编码。然后，我用RTL编写状态逻辑和输出逻辑，并且把这两个逻辑模块放在和状态寄存器不同的模块里。在综合的时候，不选择ungroup并强制工具保留所有的状态寄存器。这样的话，对于一个8个状态的状态机，综合出来的结果就有8个状态寄存器。然后，把这个综合得到的网表再在DC里打散一次，但不做其他任何优化。接着，把这个打散的代码送给ENCOUNTER。在APR的时候，不再强制工具保留那些状态寄存器，这样的话，ENCOUNTER是不是有可能会优化状态寄存器的数目以及相关的逻辑，从而达到缩小面积的目的呢?比如ENCOUNTER是不是有可能把状态寄存器的数目缩减到3个呢?

这个不清楚哎！~正在学习当中。

小编 瞧瞧4楼吧。

按你的说法是flipflop数目少了，是不是single bit变成multi bit了（multi bit banking）?
能否按footprint summary一下各种flipflop的数目?

优化的时候，有一个simpfy netlist 的选项，如果开启，有可能改变register的数目。关掉就不会了

我想应该不是因为FF的类型变化了。在我们的设计流程中，只有一种FF被允许使用。

其实我在之前的设计中看到过APR后FF数目变化的情况，但当时是因为我们故意使用了冗余，所以ENCOUNTER删掉一些实际上不影响功能的FF，这在我们看来也是合理的。这一次应该没有使用冗余。当然，我只负责后端，对于代码本身基本一无所知。

setOptMode 里边两个参数，不知道有没有用

如果开启了multi bit的registers, 当然会变化了. 如果没有开启不会变化.

ICC 有没有类似simplifyNetlist 的设定?