随着数字化设计和SoC的日益复杂，复位架构也变得非常复杂。在实施如此复杂的架构时，设计人员往往会犯一些低级错误，这些错误可能会导致亚稳态、干扰或其他系统功能故障。本文讨论了一些复位设计的基本的结构性问题。在每个问题的最后，都提出了一些解决方案。
设计中的同步复位问题
1. 问题(I)
在许多地方，设计人员在时钟方面喜欢同步复位设计。原因可能是为了节省一些芯片面积(带有异步复位输入的触发器比任何不可复位触发器都大)或让系统与时钟完全同步，也可能有一些其他原因。对于此类设计，当复位源被断言时需要向设计的触发器提供时钟，否则，这些触发器可能会在一段时间内都不进行初始化。但当该模块被插入一个系统时，系统设计人员可能选择在复位阶段禁用其时钟(如果在一开始不需要激活该模块)，以节省整个系统的动态功耗。因此，该模块甚至在复位去断言后一段时间内都不进行初始化。如果该模块的任何输出直接在系统中使用，那么将捕获未初始化和未知的值(X)，这可能会导致系统功能故障。
图9:同步复位问题时序图
2. 解决方案
在复位阶段启用该模块的时钟且持续最短的时间，使该模块内的所有触发器都在复位过程中被初始化。 当系统复位被去断言时，模块输出不会有任何未初始化的值。
图10:同步复位问题已解决
3. 问题(II)
在时钟域交叉路径使用两个触发同步器是常见做法。然而，有时设计人员对这些触发器使用同步复位。相同的RTL代码是
always @(posedge clk )
if(!sync_rst_b) begin
sync1 <= 1'b0; sync2 <= 1'b0 ;
end
else begin
sync1 <= async_in; sync2 <= sync1
end
在硬件中进行了RTL合成后，上面的代码会在双触发器同步器的同步链中引入组合逻辑，这会带来风险，并缩短sync2触发器输入进入亚稳态的时间。
图11:同步复位问题2
2. 解决方案
可用以下方式编写RTL代码，以避免同步链的组合逻辑。
always @(posedge clk )
if(!sync_rst_b) begin
sync1 <= 1'b0;
end
else begin
sync1 <= async_in; sync2 <= sync1
end
在上面的代码中，对sync2触发器不使用复位，因此在同步链中不会实现组合信元。然而，需要注意sync2需要一个额外的周期才能复位，这不应导致设计出现任何问题。
