一个亚稳态设计案例分析

麻雀虽小，五脏俱全。CPLD规模虽小，其原理和设计方法和FPGA确是一样的。轻视在CPLD上的投入，就有可能存在设计隐患，导致客户使用产品时出现故障，从而给公司带来不可挽回的信誉损失。

近一段时间，我遇到了两个CPLD设计故障，这两个故障的根因(root cause)是一样的。其中的一个故障发生在实验室测试阶段，另一个发生在运营商的网络上，造成了非常不好的负面影响，因此引起了高度重视，必须彻底找出原因并消除。虽然可以很容易让故障不复现，但是要想找到根因，并给相关人员解释清楚, 却并不是一件容易的事情。

问题代码

图 1. 问题代码截图

这段代码的功能是统计 输入信号’status_in’ 的高电平持续时间。CPU写相应的寄存器产生’clr_cnt’把”cnt”清零。同时,也会把”cnt”的值给回读到CPU。实际上就是一个读清操作。

很明显，这里有一个问题，就是异步时钟域处理的问题。’clr_cnt’的时钟为’clk_sys’，而”cnt”的时钟为’clk_io’， ‘clk_sys’和’clk_io’是异步的，没有确定的相位关系。

测试方法

测试中，CPU循环执行以下四步：

1. 清零: CPU通过Local Bus写寄存器，产生’clr_cnt’脉冲，把”cnt”清零；
2. 计数: CPU等待一段时间。“cnt” 开始对外部输入 ‘status_in’ 计数；
3. 回读: CPU通过Local Bus读取 ”cnt” 值；
4. 循环: goto 1.

实际实现可能略有不同，CPLD逻辑在执行清零1.的同时会把”cnt”的值锁存下来,供CPU回读，也就是1.和3.也可以是一个步骤。这样表述是为了突出问题代码。

问题描述

如果’status_in’ 恒为低电平’0’输入, 那么”cnt”应该恒为零值。可是，客户发现一个非常奇怪的现象。测试中，让 ‘status_in’ 恒为低电平’0’输入时，客户发现CPU会低概率的回读到非零的”cnt”值。朋友们，你们能解释这种现象吗？

初步分析

‘status_in’恒为零，不可能引起”cnt”变化。

‘clr_cnt’在测试中是翻转变化的。’clr_cnt’是从’clk_sys’时钟域来的信号。而时钟’clk_sys’和时钟’clk_io’是异步关系，没有固定的相位关系。也就是说’clr_cnt’是可能违反触发器”cnt”的建立/保持时间要求的，进而出现亚稳态。

但是有人认为, “cnt”的值原来是零，“clr_cnt”只是把”cnt”的值清零, 这样来说触发器“cnt”的输入根本没有发生过变化，怎么可能有亚稳态事件? 而且故障出现的概率很高，远比亚稳态的概率高，好像也不能用亚稳态来解释。

问题根因

解释问题的真正原因，必须要知道 ”cnt” 对应的电路网表是什么样的。”cnt”电路网表由综合工具(synthesis)生成,可以在综合工具中查看电路图, 图2是网表的局部放大。

*** 图 2. “cnt”的Technology View电路***

图2中调用了进位链模块，看起来很乱，整理一下, 手工简化一下如图3。

图 3. 手工简化的“cnt”的电路图

图3中,可以看到，’clr_cnt’和’status_in’相或的结果控制触发器的使能端(‘CE’)。另外，’clr_cnt’还决定了触发器输入(‘D’)是”cnt+1”还是”0”。真值表如下。

也许和你想象中的不一样，电路使用了触发器的两个输入端’D’和’CE’，而不是单单一个’D’端。于是，’clr_cnt’的跳变引起了’D’/’CE’的跳变。

为了说明问题方便，定义 ‘clr_cnt’ 跳变的时刻为t0，这个跳变事件传播到触发器’CE’端的时刻为t1, 传播到触发器’D’端的时刻为t2。见图4。

图4. “cnt”触发器时序违反的演示

图4中的场景， t2>t1>t0。 最初的时候，”cnt”的值为hex”0000”，”cnt+1”的值为hex”0001”。 由于’clk_io’的上升沿落在t1和t2之间， 因此”cnt”错误地跳变为hex”0001”。

一个布局布线后的设计，一般情况下CE的传播延时(t1-t0)不会等于D的传播延时(t2-t0)。由于’clk_io’和’clk_sys’之间的相位关系是随机的, 肯定会出现’clk_io’的上升沿刚好位于t1和t2之间的情况。这种情况下，触发器CNT[15:0]就会错误的采样到”cnt+1”，而不是期望的hex”0000”值。

忽略次要参数和亚稳态事件，故障出现的概率可以被估算为 (t2-t1)/TCLK_IO 。(t2-t1)越大，故障概率越高。这就是为什么故障出现的概率这么高的原因。

对于t2=t1的情况(应该没有可能)，只有当’clk_io’采样到’D’/’CE’的边沿附近时，引起亚稳态事件，CNT才会出错，当然这种故障的概率会低的多。

*** 图5. “cnt”触发器的后仿真时序违反演示***

解决措施

通过以上的分析，问题是由于信号跨异步时钟域而产生了模糊的时序关系，布局布线工具无法也不可能分析出这种时序要求，只能从代码上加以处理。

1. 同步化

一个很成熟的异步信号同步化方法就是多拍处理。见图6。

*** 图6. 优化过后的代码***

‘clr_cnt’经过同步化后，’clr_cnt_sync’会在’clk_io’上升沿之后很短的时间内稳定下来。布局布线工具通过利用’clk_io’的时钟周期，去约束’clr_cnt_sync’到’D’和’CE’的路径。从而不会出现”cnt”非零的错误。

如果’status_in’也是异步的信号，原理是一样的，会引起计数的不准确，只是故障更隐蔽，同样需要同步化。如果’status_in’是同步的引脚输入，必须通过时序约束告知布局布线工具，’status_in’相对于’clk_io’的建立时间和保持时间。

2. 禁止CE

有人提出过一种伪方案，我们来讨论一下。就是约束综合工具,禁止使用触发器的’CE’功能。这样，触发器只有D端口, 且D = ( clr_cnt ) ? “0000” : ( status_in ) ? cnt+1 : cnt 。

当’status_in’==0且”cnt”=”0000”时，D = ( clr_cnt ) ? “0000” : cnt = ”0000”，此时，’clr_cnt’的跳变不会引起D端口上出现跳变，也就不会出现错误的采样。

这样做局限性很大，首先限制了”cnt”=”0000”的状态才适用， 如果”cnt”的当前状态非零，一样会有问题，只是错误会更隐蔽。再者，使用CE端口可以降低逻辑级数，改善时序，节省面积，实际上可能的情况下应该尽量使用。

因此禁止CE的手段是不能作为解决措施的。