时钟域交汇相关处理错误的根本原因分析

电子说

1.3w人已加入

描述

最终发现,此问题是由于时钟域交汇 (CDC) 处理不当所导致的,在 report_methodology 和 report_cdc 报告中高亮显示了相关处理错误。

这是使用方法论报告系列博文的第 4 部分。如需阅读整个系列中的所有博文,请点击如下标题查看。

第1部分:时序以满足,但硬件功能出现错误

第2部分:方法违例对于QoR的影响

第3部分:时序已满足,但硬件中存在 DDR4 校准失败

说明:

此客户在现场部署了数万个基于 Zynq-7000 系列的产品,这些产品都是使用 Vivado 2013.4 开发的,其最终客户报告称大量卡上出现数据包损坏,调查显示在所有数据包损坏案例中,设计中的相同位置都发生了比特翻转。

根本原因分析:

为了缩小范围,我们首先要求客户提供网表中这些寄存器的位置:

我们要求客户提供 DCP 以便我们使用各项报告来审查设计。

虽然通常随机问题是由电源问题所导致的,但我们同时还要求客户提供操作期间的 VCCINT/VCCAUX/VCCIO 测量方法,以便测量电平和噪声,如(赛灵思答复记录 62181)中的硬件调试最佳实践中所述。

我们还要求其提供板级原理图 (schematic) 以复查使用的去耦电容是否足够。

很快我们就把电源问题排除在原因之外。

收到 DCP 后,我们首先使用最新版本的 Vivado 运行

report_timing_summary、report_methodology、report_drc 和 report_cdc。 

有多个问题马上显现了出来。

最重要的发现与可疑 FF 相关,report_methodology LUTAR-1 检查标记出了这些可疑 FF:LUT 驱动异步复位警告

FF 具有异步复位,由逻辑级数深度为 2 的路径驱动:

时钟域

其危险性在于 LUT(红色箭头)可出现毛刺并触发意外复位。

第二项最严重的发现与时钟域交汇和约束有关。

Report_cdc 发现约有 40000 条路径采用非推荐 CDC 架构:

时钟域

不安全的时钟域交汇可能导致翻转 FF 下游或上游出现问题,并且可能成为所观测到的行为的真正根源。

就约束而言,report_methodology 的“TIMING-24:仅最大延迟数据路径已被覆盖”检查发现多项严重违例。

在移除 set_clock_groups -asynchronous 约束并将其替换为 set_max_delay -datapath_only 和时钟对的最小时钟周期后,发现出现了非常严重的时序违例:-5.8ns,原因是异步时钟之间的逻辑级数达到 11。

第二轮审查发现设计中几乎所有复位上都存在伪路径约束,这些约束是为了帮助达成时序收敛而添加的,根据经验,我们知道这是非常危险的:如果状态机的各个位在不同时间脱离复位,则可能进入非法状态、无法恢复并且导致设计运行错误。

即使复位为异步,取消复位仍需达成时序收敛,因此永远不能忽略复位上的时序收敛,您应该尽可能明确自己实际是否需要复位,因为不使用复位可节省宝贵的布线资源,并且使 SR 管脚可用于控制置位的重映射,从而减小设计规模,因为逻辑函数可部分映射到这些 SR 管脚。

修复所报告的问题(LUT 驱动异步复位、CDC、CDC 约束)并在现场部署一些新固件后,这些罕见的比特翻转就没有再出现。

结论:

Vivado 报告功能(方法论、CDC)的进步使我们得以成功调试并解决罕见的比特翻转问题。

无论何时遇到任何疑问,都应该首先考虑使用最新版本的 Vivado 来重新审查设计,最新版本的 Vivado 中包含 CDC 分析和最新的方法论检查,这些都是进行原始设计所没有的。

  审核编辑:汤梓红

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分