在之前的教程中，我們已經(jīng)看到我們可以從AI引擎模擬中獲得循環(huán)信息，這是循環(huán)近似，因此它給出了我們將在實際硬件上得到的非常接近的估計。我認(rèn)為從AI引擎模擬器生成的軌跡中測量延遲會很有趣。

注意：本教程是使用AMD Vitis 2025.1創(chuàng)建的。工具流程在其他版本的工具中可能會有所不同。

測量AI引擎圖的延遲

在之前的教程中，在運(yùn)行AIE模擬器之后，我們在模擬生成的輸出文件(output.txt)中得到以下輸出：

以T開頭的行給出了示例的時間戳，如下所示。

第一個，1510400ps意味著第一個樣本在1.5104 us之后出現(xiàn)在AI引擎陣列的輸出中。因此這大概就是AI引擎數(shù)組的初始延遲(從第一個樣本輸入到第一個樣本輸出)。

如果我們檢查兩個連續(xù)線路之間的時間戳，我們可以看到每個連續(xù)的樣本在6.4 ns或156.25 MHz之后到達(dá)。

我們可以在查看平臺屬性時找到類似的數(shù)字(打開AI引擎組件設(shè)置文件vis -comp)。(點擊平臺信息)

我們可以看到這個頻率與我們平臺上的PL時鐘的頻率相匹配

然后查看從模擬(output.txt)生成的輸出文件的第63-65行，我們可以看到以下內(nèi)容：

TLAST表示下面的樣本是圖迭代的最后一個樣本。這意味著我們的圖(帶有2個核)需要1.70個函數(shù)來完成第一次圖迭代。這個時間包括填充輸入緩沖區(qū)、運(yùn)行兩個內(nèi)核和輸出輸出緩沖區(qū)的時間。

然后查看output.txt文件的第128-130行：

這顯示了圖迭代的最后一個樣本的時間戳。這意味著第二次迭代在0.9536秒內(nèi)完成。這比第一次迭代要快得多。其原因是乒乓緩沖區(qū)作為圖的輸入，正如我們在上一教程中看到的那樣。

雖然要開始圖的第一次迭代，我們必須等待ping緩沖區(qū)填滿輸入數(shù)據(jù)，但第二次迭代的情況并非如此，因為當(dāng)內(nèi)核處理ping緩沖區(qū)時，pong緩沖區(qū)已經(jīng)填滿了。

為了更好地了解不同階段引入的延遲，一個好方法是查看可以從模擬中生成的跟蹤。

默認(rèn)情況下不啟用跟蹤。我們需要在仿真設(shè)置文件(launch.json)中啟用EnableTraces選項，從而在仿真選項中啟用它們。

如果我們再次運(yùn)行模擬，我們將能夠在REPORTS > Trace下看到跟蹤。

這是我們從跟蹤報告中得到的視圖

我們可以看到，AI Engine Tiles組織了各種信息，如功能運(yùn)行，鎖或dma。

淺綠色和淺藍(lán)色的方框表示內(nèi)核執(zhí)行。正如我們在之前的文章中看到的那樣，圖(以及內(nèi)核)運(yùn)行了4次，并且在同一個AI引擎貼圖上執(zhí)行的內(nèi)核一個接一個地執(zhí)行。

如果我們將游標(biāo)放在第二個內(nèi)核第一次運(yùn)行的末尾，我們可以看到它表示1.460 us，這與我們從模擬文件中的第一個時間戳中獲得的初始延遲非常接近。

然后，我們可以首先在內(nèi)核的第一次和第二次執(zhí)行開始時添加游標(biāo)。

兩個核(1475 - 524 ns)之間的時間差為951 ns。這也接近我們在測量第二次圖執(zhí)行的時間減去從輸出文本文件的時間戳中得到的第一次迭代的最后一個樣本的時間時得到的值。

這基本上是我們的圖在數(shù)據(jù)流水線(圖不等待數(shù)據(jù)運(yùn)行處理)時完成迭代(包括2個內(nèi)核的執(zhí)行)所需的時間。

總結(jié)

在本文中，我們看到了如何測量AI Engine模擬輸出文本文件中的延遲，以及如何啟用和分析模擬中的跟蹤，以獲得更細(xì)粒度的圖延遲測量。

本文編譯自hackster.io