OpenVINOTM,给你看得见的未来!>>
电子产品世界 » 论坛首页 » 嵌入式开发 » FPGA » CPLD设计故障异步时钟域处理案例分析

共1条 1/1 1 跳转至

CPLD设计故障异步时钟域处理案例分析

工程师
2020-11-03 22:53:50    评分

麻雀虽小,五脏俱全。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的手段是不能作为解决措施的。




共1条 1/1 1 跳转至

回复

匿名不能发帖!请先 [ 登陆 注册 ]