我们经常遇到formality Fail，但却无从下手。根据多年的debug经验，总结了一些排除和debug formality fail的步骤和要点，供大家参考。
确认map是否正确，是否有unmapped的点
确认是否读了svf，是否有多个svf，并注意svf的顺序。是否有reject，如果reject过多，要确认svf是否用错了文件。
确认是否有svf没指示的phase inversion或者multibit rebank
dft bypass是否已设置
clock gating是否已设置
DW root是否已设置
对failing point进行analyze和diagnose，看看是否有有用的提示
对比failing point的logic cone的输入，是否一致
对logic cone施加pattten，从电路图上追踪不一致的地方
debug时，优先确认时钟path和复位path是否等价，最后确认data path。这是因为时钟和复位path通常结构更简单，如果有问题要优先解决。如果时钟和复位不一致，就会导致一大片Fail。
ref与imp弄反了。一般来说，rtl作为ref，综合网表作为imp。也可以是综合网表作为ref，apr网表作为imp。反过来不行，会出错。这是为什么呢？好像与我们的认知相矛盾，我们一般认为两个设计（或网表）一致，A与B比，B与A比，都行。然而事实不是这样的，因为svf记录的是从ref到imp的变化，如果反了，svf就没办法反标了。
寄存器改名了。在做ECO时，前端设计可能为了醒目，有变化的地方（模块名、变量名、寄存器名等），加个版本的前缀或者后缀，比如xxx_a1或者b2_xxx或者xxx_20241105。这些变化看似没啥，但却会造成formality大面积fail。因为formality在关键点映射时主要是根据名字来match，寄存器addr[7:0]与addr_a1[7:0]会被认为完全没有关系。同时，也会造成以addr[7:0]为起点的fanout endpoint出错。
formality的版本比dc老。这是有可能的，因为新版本的dc在综合时可能会做一些优化，这些优化和新版本的svf就可能不能完全被老版本的formality识别。
第三方工具（如，Cadence APR工具、手工ECO、自动ECO工具）做了一些优化，这些优化没有记录在svf里，导致formality fail。这时我们需要增加formality command或者手工修改svf增加svf guide命令来指导formality pass。
综合工具dc没退出。是的，遇好几次了，dc_shell不退出导致svf还缓存在内存里，没有写到硬盘上，导致最终svf不完整。formality读入不完整的svf，部分重要指导信息缺失，所以fail了。
