复位设计中出现的结构性缺陷及解决方案

　 图11:同步复位问题2

4. 解决方案

可用以下方式编写RTL代码，以避免同步链的组合逻辑。

　　always @（posedge clk ）

　　if（！sync_rst_b） begin

　　sync1 <= 1'b0;

　　end

　　else begin

　　sync1 <= async_in; sync2 <= sync1

　　end

　　在上面的代码中，对sync2触发器不使用复位，因此在同步链中不会实现组合信元。然而，需要注意sync2需要一个额外的周期才能复位，这不应导致设计出现任何问题。

　　冗余复位同步器引起的问题

　　1. 问题

　　在使用多个异步时钟的设计中，设计人员需要确保在目标寄存器使用的时钟方面，异步复位的同步去断言，否则可能导致目标触发器发生时序违反，从而产生亚稳态。复位同步器被用来复位去断言，与目标时钟域同步。然而，只有在系统复位去断言过程中有目标时钟时才会发生复位去断言时序违反。如果在复位去断言时没有时钟，那么便不会有任何时序违反。因此，在设计多时钟域模块时，设计人员可以让编译时间选项绕过该模块中的那些复位同步器，并让系统集成商根据对该模块的时钟可用性决定是否需要使用复位同步器。

　　此外，如果系统时钟和异步时钟比非常高，冗余同步器甚至会造成设计功能性问题。下面描述了这个问题。

　　 图12:冗余同步器的问题

　　在上面的设计中，去断言与sys clk同步的系统复位被馈送到（mod_clk域）的复位同步器，然后在mod_clk域逻辑中使用该复位。让我们假定sys clk : mod_clk的时钟频率比大于6:1.默认不启用mod_clk,以节省动态功率。当用户想要启用mod_clk域逻辑的功能时，便启用该时钟。在启用了该时钟后，有两个mod_clk周期的延迟，其中，由于复位同步器导致整个mod_clk域逻辑都处于复位状态。在该阶段，如果一些数据交易从sys clk域开始，将在mod_clk域丢失。

　　2. 解决方案

　　虽然这不是大问题，但有时会在客户一端造成混淆，因为该延迟对客户不可见。 因此消除混淆的更好的方式是：

　　* 如果在全局复位去断言过程中没有时钟，则在设计中绕过/删除冗余复位同步器。 这当然会节省一定的门控数。

　　* 如果动态功耗不是问题，用户可以在mod_clk域逻辑开始运作之前很长时间在启动代码选择启用mod_clk. 因此，复位去断言将有足够的时间传播。

　　* 这也可以在软件中处理，在任何有效操作之前启用了mod_clk后，设置两三个mod_clk周期的延迟。

　　由于罕见的时钟路径导致复位去断言时序问题

　　1. 问题

　　设计的复位架构根据系统而不同。在一些安全关键设备中，整个复位状态机在安全时钟上工作，安全时钟默认启用。 该时钟也被用作设备的默认系统时钟。

　图13:罕见时钟路径的问题

　　在上图中，复位状态机（R触发器）在default_clk上工作。此外，在复位去断言过程中，default_clk是sys clk的源。因此，在逻辑上，这两个时钟（clk1和clk2）在复位去断言过程中同步。但是，由于clk1和clk2之间存在巨大的罕见路径，因此很难平衡这两个时钟并视其为同步。 因此，满足A触发器的复位去断言变得具有挑战性。

　　2. 解决方案

　　异步对待clk1和clk2,并在A触发器中使用复位之前放置复位同步器。现在需要从S2--》A满足复位去断言时序（见图14）。这不应是个问题。

　图14:解决方案

结束语

本文主要专注于复位设计中的故障以及克服这些问题的可能的解决方案，然而，上述解决方案并非唯一的解决方案，也不普遍适用于所有设计。这些是一些通用的解决方案和建议的指导方针，在特殊情况下可能需要进行修改。