header

即刻开启适合您的开发平台

一个全面的机器学习开发平台,旨在在Xilinx平台上提供世界领先的AI推理性能,与CPU/GPU解决方案相比,实现高达10倍的性能提升。
一种设计方法和编程模型,使所有开发人员(包括没有硬件设计专业知识的软件和算法工程师)都能够利用Xilinx自适应平台的强大功能进行边缘到云的部署。
一个为解决系统级集成和实现过程中的生产力瓶颈而从头开始构建的具有 SoC 优势,且以 IP 和系统为中心的新一代开发环境。

课程学习

推荐文章

一周热贴

开发者分享 | 使用方法论报告6: 设计无法连贯布线
  • 2021年09月24日 19:09
赛灵思开发者



本篇博文中的分析是根据真实客户问题撰写的,该客户的 DFX 设计无法连贯布线,存在布线重叠。本篇博文旨在演示用于缩小根本原因范围以及修复此问题的部分调试技巧。 


这是“使用方法论报告”系列博文的第 6 部分。

如需阅读整个系列中的所有博文,请点击下方标题查看。


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

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

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

第4部分:罕见的比特翻转

第5部分:DDR4 IP 校准后硬件故障,指示存在时序问题,但时序报告中无任何违例


问题说明:


在此示例中,用户的 DFX 设计遇到 1 个奇怪的问题,它无法连贯布线,部分信号线保持处于未布线状态。


运行 Tcl 命令 report_route_status 显示如下结果,有 165 条信号线未布线:



根本原因分析:


通过观察设计发现,时钟间路径存在超大保持时间违例,约 - 4.6 ns,如下所示。


但在已布线的检查点上未出现这些违例。route_design 开始处的日志中可以看到这些违例。


注: 要详细分析含估算的布线延迟的时序,请在 Vivado GUI 的“时序汇总 (Timing Summary)”报告中针对互连 (interconnect) 使用“估算 (estimated)”选项。


您可使用以下选项来检查自己的设计的“Timing Summary”:


  • 在 Vivado GUI 中,转至“报告 (Reports)”选项卡 ->“时序 (Timing)”->“时序汇总报告 (Report Timing Summary)”

  • 运行以下 Tcl 命令:


report_timing_summary -file/timingreport.txt


互连设置用于控制信号线延迟计算方式:根据估算的叶节点单元管脚间布线距离来计算,或者根据实际布线的信号线来计算,或者从时序分析中排除信号线延迟。请扫码参阅 (UG906) 以获取更多信息。




或者,也可以使用以下 Tcl 命令来分析含估算的布线延迟的时序。


set_delay_mode -interconnect estimated



借助时钟交互报告 (Report Clock Interaction),即可在所有特定时钟域中发现这些时钟间路径违例,如下所示。


如需在 Vivado GUI 中查看时钟交互报告,请依次选择“报告 (Reports)”->“时序 (Timing)”->“时钟交互报告 (Report Clock Interaction)”。



通过观察这些严重的保持时间违例,可以得出如下结论:时钟拓扑结构存在问题,或者设计未正确约束。


而这两种可能性都需要加以详细分析。 


通过观察发现,此时钟间路径存在保持时间违例(如下所示),且其时钟路径偏差非常高,看上去很可疑。



默认情况下,Vivado 将所有时钟都视作为同步时钟来处理。因此,这些 CDC 异步时钟路径同样被视为同步,因此导致在路径中此处添加错误的时钟偏差。在此示例中,偏差约为 4 ns。


那么我们是如何发现这些异步 CDC 未正确约束的呢?


我们是从时钟对分类 (Clock Pair Classification) 和时钟间约束 (Inter clock Constraints) 列中得到此信息的(如下所示)。


请参阅以下"如何正确地约束时钟交互"博客,以便获取详细信息。




这导致出现严重的保持时间违例,因而导致布线器执行大量保持时间修复,从而导致布线拥塞。


布线器始终优先修复保持时间违例,而后才是修复建立时间违例,因为存在保持时间违例的设计无法正常运行,而存在建立时间违例的设计则仍能按较低频率运行。


由于布线绕行导致的布线拥塞可能导致时序违例,也可能导致无法布线。


拥塞严重会导致布线器无法找到任何资源用于布线。此处示例的问题正来自于此。


您可以观察到由于欠约束 CDC 路径,会导致布线器花费大量的布线资源用于修复保持时间违例。


最终,它导致了在此例中所发生的信号线拥塞/未布线问题。


以下截屏显示的保持时间违例中,时钟偏差为 4 ns。



下图显示了发生保持时间违例的非安全 CDC 路径中所使用的布线资源总量。



并且,分析还发现利用率在可控范围内,并未超出阈值。而根本原因同样源于约束不正确。


要在 Vivado GUI 中查看资源利用率,请转至“报告 (Reports)”选项卡 ->“报告利用率 (Report Utilization)”。


或者,您可在 Tcl 控制台内运行 report_utilization 命令。



那么在此情况下,方法论报告又如何发挥作用呢?


通过观察此报告可以发现,在设计中存在大量方法警告。


以下列出了影响设计 QoR 且需要优先解决的主要警告。


要在 Vivado GUI 中打开方法论报告,请转至“报告 (Report)”选项卡 ->“方法论报告 (Report Methodology)”,或者在 Tcl 控制台中,使用 report_methodology。


以下截屏显示的方法论报告包含有关 TIMING-6、7、8、15 和 35 的警告消息。



根据 TIMING-6、TIMING-7、TIMING-8 和 TIMING-35 警告,可以得出结论,即设计未正确约束,并且必须对其加以正确约束。


因此,用户需参阅时钟交互报告以了解时钟间路径的时序是否安全。如需获取有关“时钟交互报告 (Clock Interaction Report)”的更多信息,请参阅 (UG906)。


TIMING-15 警告显示在时钟间路径上存在严重的保持时间违例,必须先加以解决,然后才能生成比特流。 


由于布线器始终会尝试解决保持时间违例,并且这也会影响布线,因此建议正确约束设计,并清除上述警告消息中提及的时钟间路径中的错误。


通过检查时序汇总可以发现,时钟间路径的保持时间违例非常高,达到约 -3 ns。


如需获取有关这 5 条警告消息及其解决方案的更多信息,请参阅 (UG906) 附录 A。



结论:


通过观察分析可以发现,如果在调试初始阶段,客户遵循方法论报告中的警告将其逐一解决,那么即可大幅缩短调试此信号线未布线问题的时间。


添加如下约束后,即可解决这些幽灵时序违例:


set_max_delay -datapath_only -from [] -to []


如需获取有关添加正确的时序例外的更多信息,可参阅 (UG903) 和“如何正确地约束时钟交互”博文,其中均提供了诸多实用信息。

UG903:


“如何正确地约束时钟交互” 博文:


最后,完成上述修改后,用户得以成功将可重配置模块的利用率提升到 55% FF 利用率。



赛灵思中文论坛

欢迎在赛灵思中文论坛中留言讨论开发过程中遇到的问题与启发!

赛灵思开发者社区将持续推出一系列视频教程,来介绍赛灵思中文论坛的板块和内容,任何技术问题,欢迎进入赛灵思中文论坛进行提问和互动。

https://fourms.xilinx.com/cn





  • 2021年09月23日 19:09
赛灵思开发者
  • 2021年09月22日 19:09
xilinx_developer
  • 2021年09月16日 19:09
XILINX开发者社区
  • 2021年09月15日 19:09
赛灵思开发者
  • 2021年09月09日 19:09
赛灵思开发者

月度项目

赛灵思开发者的一项重要权益,每月向广大开发者征集具有创新性和创造力的项目。丰厚奖金等你来! 了解更多

硬件租借

是赛灵思开发者计划的一项重要权益,旨在提供必要的资源帮助有独立开发能力的成员更快的构建应用程序。 了解更多

开发者项目

加入赛灵思开发者计划 可以让您获得所有赛灵思平台 成功构建应用所需的资源

杰出作者

关于赛灵思开发者社区

  • 加入赛灵思开发者计划可以让您获得在所有赛灵思平台上成功构建应用所需的资源。

    当您加入我们的免费计划时,您将可以使用最新的赛灵思开发工具来加速您在各个领域的应用,例如加速计算、人工智能和机器学习。这些核心技术正在引领包括高性能计算、5G、自动驾驶、机器人技术、智慧城市、工业、医疗在内的众多行业发生根本性变革。

    此外,该计划还使您能够与赛灵思社区分享您的技术见解和项目!

  • 联系邮箱

    developer@xilinx.com

  • 赛灵思开发者社区: