EEPW论坛

麻雀虽小，五脏俱全。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

对于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的手段是不能作为解决措施的。