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

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

測(cè)量AI引擎圖的延遲

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

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

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

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

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

我們可以看到這個(gè)頻率與我們平臺(tái)上的PL時(shí)鐘的頻率相匹配

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

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

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

這顯示了圖迭代的最后一個(gè)樣本的時(shí)間戳。這意味著第二次迭代在0.9536秒內(nèi)完成。這比第一次迭代要快得多。其原因是乒乓緩沖區(qū)作為圖的輸入，正如我們?cè)谏弦唤坛讨锌吹降哪菢印?

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

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

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

如果我們?cè)俅芜\(yùn)行模擬，我們將能夠在REPORTS > Trace下看到跟蹤。

這是我們從跟蹤報(bào)告中得到的視圖

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

淺綠色和淺藍(lán)色的方框表示內(nèi)核執(zhí)行。正如我們?cè)谥暗奈恼轮锌吹降哪菢?，圖(以及內(nèi)核)運(yùn)行了4次，并且在同一個(gè)AI引擎貼圖上執(zhí)行的內(nèi)核一個(gè)接一個(gè)地執(zhí)行。

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

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

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

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

總結(jié)

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

本文編譯自hackster.io