第一阶段的目标是判定设计功能是否正确以及是否能在硬件中成功运行。您也可以分析结果并继续执行下一阶段,进行进一步调试和分析。
下图显示了此阶段中可用的任务和技巧。
此阶段可帮助您判定设计和主机应用能否在硬件中成功运行。在此阶段中,您可在自己的主机应用内使用 API 对硬件上正在运行的设计进行剖析,并判定设计是否满足吞吐量、时延和带宽目标。此外,您也可以使用在硬件中运行设计时所生成的报告,对 AI 引擎停滞和死锁进行故障排除。
以下章节列出了此阶段可用的技巧。
硬件中的主机代码中的错误处理和报告
在 Linux 上,XRT 可提供错误报告 API。在主机应用中,这些 API 可用于捕获和报告这些错误,以查明问题的根本原因。如需了解有关 XRT 错误报告 API 的详细信息,请参阅 通过 XRT API 报告错误。要检验由 AI 引擎阵列报告的错误消息,请启用并检验 dmesg
log 日志。如需了解有关 AI 引擎阵列专用的错误处理技巧的详细信息,请参阅 AI 引擎错误事件。
下一阶段:如果判定主机应用需要进一步调试,请继续执行阶段 5。
分析硬件中的设计停滞
在硬件中,如果在 Linux 上遇到设计停滞,请使用 Linux 上的 XRT Xbutil 实用工具来跟踪设计中的 AI 引擎和 PL 内核的状态。如需了解有关如何使用该实用工具来生成当前设计状态和在 Vitis 分析器中直观显示结果的更多信息,请参阅 分析硬件中的 AI 引擎状态。
您也可以在 XSDB 中手动生成报告并在 Vitis 分析器中直观显示结果。欲知详情,请参阅 生成 AI 引擎状态。在 图 1 和 图 2 中提供了 Vitis 分析器中的死锁的可视化示例。
下一阶段:如果您判定设计已停滞并且需要进一步获取详细信息才能查明停滞的根本原因,请继续执行阶段 2。
报告硬件中的设计吞吐量、时延和带宽
您也可以在主机应用中通过 API 来剖析 graph 输入和输出,以判定 AI 引擎 graph 吞吐量、时延和带宽。在主机中开始和停止剖析 API 时,请谨慎处理。如需了解有关在主机应用中如何使用 API 的详细信息,请参阅 用于 graph 输入和输出的事件剖析 API。
下一阶段:如果您判定设计的吞吐量或时延不达标,或者设计不满足性能目标,请继续执行阶段 2。在阶段 2 中,您可以确定可能造成性能下降的内核或 I/O。