为了最大程度的缩短SoC的设计验证周期，在现在的SoC设计中集成了大量的IP模块，每个IP模块都有自己的Reset,这样就使得整个SoC层面上的Reset的结构变得比较复杂。例如:电源的Reset,硬件的Reset,软件的Rest,Debug的Reset等等，这些Reset一旦不能正常工作，将会使得SoC变得不稳定，甚至是功能上的失效，这对于我们来说是绝对不可接受的。这使得让这些错综复杂的Reset在各种情况下都可以正常工作变为一个不小的挑战。

另外，更为复杂的情况是许多Reset domain和Clock domain,Power domain的交叠，这将会产生一个比Clock tree更为复杂的Reset tree,这使得在Clock tree上考虑的负载平衡问题在这里也变得不可忽视。

总而言之，随着SoC集成度越来越高，必须正确解决Reset tree验证的问题。下面我们将一起来看看可能出现的Reset tree的问题以及解决办法。

常见问题

一个Reset时而同步时而异步

一般情况下，对于一个Reset我们会给它一个同步或者异步的属性，而不会像下面一样在一个触发器上它是同步的，另一个触发器上它是异步的，这样会使我们的电路变得不稳定。

异步Set和Reset同时使用

在同一个触发器如果通过同时使用了异步的Set和Reset，如果在仿真的时候异步的Set和Reset同时有效，那么我们的仿真会丢失Set或Reset的信息，使得我们的仿真情况与综合后的情况很可能不一致，因为实际这个寄存器的行为会依赖于它的具体物理实现而不是我们的代码。

异步Reset的Clock同步

对于异步Reset在连接到触发器之前要进行Clock domain的同步，如果没有被同步，那当这个Reset 在紧挨着Clock沿释放的时候触发器会有一个不定态，这会违反当前触发器的setup和hold时间，并且导致后面的许多load触发器状态发生错误。对于异步Reset的Clock同步，下图是一个比较典型的同步方式，目的在于在Reset释放的时候，保证输出Q并不会马上变化，而是等到下一个Clock的沿来时才会变化。

异步Reset domain的交叠

异步Clock domain的交叠很容易造成设计状态的不稳定，同样对于同一个Clock domain的data path，如果存在异步的Reset domain的交叠，仍然会使得设计变得不稳定，如下图中，如果在CLK的沿附近RST1有效，而RST2无效，那么DFF2就会采到来自DFF1的异步Reset的数据，如果这个数据变化在DFF2的setup和hold时间窗口内，那么DFF2的输出就会变为不定态，如下图波形所示:

Reset domain中不合适的延时

一般情况下，在我们的设计文件中会在不同阶段利用一些延时来避免所有的信号一起变化对芯片造成的能量冲击烧毁芯片，但对于下图中相邻触发器DFF1到DFF2之间的不当延时如果超过一个Clock，那么DFF2极有可能会在setup或hold窗口内采到不定态，这会导致DFF2以及DFF2的load触发器功能失效。

解决方案

静态分析

对于设计代码开始验证的第一步就是静态分析，利用静态分析工具可以综合设计代码并找出一些明显的设计缺陷，它的优点是我们不需要准备任何仿真环境，只需要design文件，它会把为我们的design文件建立一个Reset tree,在这个Reset tree中，每一个Reset信号都有它的属性，包括:异步or同步;高有效or低有效;set信号or reset 信号，一旦Reset tree建立成功，我们就可以把一些design信息如Clock,power,delay反标上去，进行分析。利用工具的静态分析我们可以很容易的找出一些潜在的设计问题:

1. 同一个Reset既被用作同步Reset，又被用作异步Reset

2. Reset被用作数据进行传输

3. 同一个Reset有时高有效有时低有效

4. 异步Reset domain的交叠

5. Glitch检测

利用仿真工具的X-propagation特性

在VCS或Questa等仿真工具中都支持X-propagation的功能，它会强制性把我们在仿真过程中产生的X进行放大传播，让我们能够在仿真窗口中看到X的产生，找到产生X并将X传播的源头进行分析。

形式验证

尽管RTL的仿真我们可以发现很多问题，但它需要我们的激励文件，而我们的激励并不能完全覆盖所有的情况，这就使得我们的验证存在一种不充分性，而形式验证会根据电路结构穷举所有的可能性进行综合前后的对比，它可以帮助我们检测所有Reset的连接正确性，避免这些X状态成为我们芯片中的bug。

数据结果

下图是一些针对上述可能存在的Reset问题进行实验的结果，采用三个design文件进行比较验证，包括Design1 标准模块，Design2功能控制器，Design3总线设计模块，仿真过程中上述的Reset问题均有出现，在进行静态分析和带X-propagation的仿真过程工具也都给出了错误警告，下面是仿真design和出现问题的总结，具体实验更详细的过程及数据请参考原文。

这些实验结果证明，这些Reset的问题我们很难用仅仅依赖仿真或者传统的验证技术发现，为了使Reset问题彻底得到解决，我们需要引入静态分析和形式验证等更全面的验证形式来解决可能出现的Reset问题，不让它成为我们芯片的拦路虎。

您可以在手机移动端同步关注订阅号“路科验证”。

如需转载请联系路科验证，并注明出处“路科验证”。