开发者分享 | 使用方法论报告4: 罕见的比特翻转
本篇博文中的分析是根据真实客户问题撰写的，该客户发现在现场出现罕见的比特翻转, 本篇博文旨在演示用于缩小根本原因范围以及修复此问题的部分调试技巧。
最终发现，此问题是由于时钟域交汇 (CDC) 处理不当所导致的，在 report_methodology 和 report_cdc 报告中高亮显示了相关处理错误。
这是使用方法论报告系列博文的第 4 部分。如需阅读整个系列中的所有博文,请点击如下标题查看。
问题说明：
此客户在现场部署了数万个基于 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 分析和最新的方法论检查，这些都是进行原始设计所没有的。
点击阅读原文可查看
赛灵思答复记录 62181
赛灵思中文论坛
欢迎在赛灵思中文论坛中留言讨论开发过程中遇到的问题与启发！
赛灵思开发者社区将持续推出一系列视频教程，来介绍赛灵思中文论坛的板块和内容，任何技术问题，欢迎进入赛灵思中文论坛进行提问和互动。
https://fourms.xilinx.com/cn
