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

Veriart

ENCOUNTER APR之后的FF数目和读入设计的不一致，这个有可能吗？
谢谢

Lover_Momo

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

icfbicfb

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

Veriart

回复 2# Lover_Momo


   谢谢你的回复。我又看了一下设计，确实是APR之后FF的数目不一样了，但是formality里的检查是可以过，显示没有unmatch point以及Verification succeeded。
如果是以下这样的情况，你觉得会不会产生FF数目的差异？

假设我调用库里的寄存器直接搭建了一个状态机的状态寄存器，以独热码编码。然后，我用RTL编写状态逻辑和输出逻辑，并且把这两个逻辑模块放在和状态寄存器不同的模块里。在综合的时候，不选择ungroup并强制工具保留所有的状态寄存器。这样的话，对于一个8个状态的状态机，综合出来的结果就有8个状态寄存器。然后，把这个综合得到的网表再在DC里打散一次，但不做其他任何优化。接着，把这个打散的代码送给ENCOUNTER。在APR的时候，不再强制工具保留那些状态寄存器，这样的话，ENCOUNTER是不是有可能会优化状态寄存器的数目以及相关的逻辑，从而达到缩小面积的目的呢？比如ENCOUNTER是不是有可能把状态寄存器的数目缩减到3个呢？

Lover_Momo

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

Lover_Momo

回复 3# icfbicfb
斑竹 瞧瞧4楼吧。。

zero_0

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

bsbs525

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

Veriart

回复 7# zero_0


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

Veriart

回复 8# bsbs525


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