最近加班都是因?yàn)橹弊鲞@玩意，更不動(dòng)了

為什么加班呢，因?yàn)橹白鯟PU驗(yàn)證的checker現(xiàn)在都得重構(gòu)了

首先講一下CPU到GPU在處理并行指令流的區(qū)別：

?CPU?傾向于利用core_id這一物理信息進(jìn)行拆分；這里是一個(gè)簡(jiǎn)單的雙核CPU利用分支跳轉(zhuǎn)實(shí)現(xiàn)多線程并行的偽代碼

core0和core1同時(shí)收到了這樣一段指令流，在PC=2時(shí)觸發(fā)了分支跳轉(zhuǎn)的場(chǎng)景，從而計(jì)算出了不同的 r2。

這么做的缺陷在于：

1. 所有的分支都需要出現(xiàn)在匯編指令流內(nèi)顯示控制，多核多線程數(shù)量上去以后，過(guò)于占用cache；

2. 在多線程場(chǎng)景下，需要頻繁地進(jìn)行分支預(yù)測(cè)，預(yù)測(cè)失敗的成本很高，效率受影響；

3. 可并行度受限于core的數(shù)量，超出core_num的并行分支就需要軟件層面重新調(diào)度下一輪的branch判斷。

GPU的多線程并行并不會(huì)考慮執(zhí)行單元數(shù)量（CPU和GPU的執(zhí)行單元數(shù)量級(jí)也不一樣），執(zhí)行指令流會(huì)被拆分成線程束，選取有空閑的執(zhí)行單元輪詢下發(fā)

以上是背景，這里不詳細(xì)講解了

那么對(duì)于驗(yàn)證過(guò)程中的checker添加會(huì)有什么影響？

可以參考下面這個(gè)圖，由于我們的項(xiàng)目中，理想模型來(lái)自于功能模擬器，而非性能模擬器（實(shí)現(xiàn)成本太高了，沒(méi)錢沒(méi)人做），因此模擬器和電路的執(zhí)行順序可能出現(xiàn)偏差：因?yàn)槟M器并不感知“時(shí)間”這個(gè)概念，對(duì)于模擬器來(lái)說(shuō)，所有線程都是瞬間執(zhí)行完成的，并不存在“輪詢”這個(gè)說(shuō)法。

由此帶來(lái)的問(wèn)題就很多了，這里只舉例share memory。

由于share memory以線程塊為單位進(jìn)行隔離，每個(gè)block的結(jié)果都會(huì)殘存在share memory當(dāng)中。以往CPU驗(yàn)證中，會(huì)在每個(gè)kernel執(zhí)行完后，進(jìn)行share memory的結(jié)果比對(duì)（當(dāng)然也可以在每一筆讀寫操作時(shí)進(jìn)行比對(duì)，會(huì)更細(xì)致）

前面說(shuō)到，模擬器是不會(huì)輪詢的，就是單純按順序下發(fā)；而RTL則會(huì)考慮每個(gè)block執(zhí)行時(shí)間長(zhǎng)短，選取空閑處理單元執(zhí)行下一個(gè)block，這就導(dǎo)致RTL和模擬器的執(zhí)行順序、以及block和執(zhí)行單元對(duì)應(yīng)關(guān)系是不一致的。

以上圖為例，針對(duì)于某個(gè)執(zhí)行單元，其share memory的操作流是不一樣的，結(jié)果也不一樣

那么checker該怎么加？

一種思路是，在每個(gè)block結(jié)束時(shí)，記錄當(dāng)前的block_id，從模擬器中讀取對(duì)應(yīng)block_id的golden數(shù)據(jù)。這里需要模擬器或者RTL提供當(dāng)前block操作改寫過(guò)的地址段信息，或者驗(yàn)證環(huán)境自己記錄；隨后針對(duì)改寫過(guò)的地址進(jìn)行比對(duì)，避免模擬器未操作過(guò)的空地址進(jìn)行比對(duì)。

隨后golden隊(duì)列中記錄改寫過(guò)的地址數(shù)據(jù)，作為下一次比對(duì)的“初始狀態(tài)”。

以此方式按block為單位進(jìn)行循環(huán)比對(duì)即可。

同樣的，這種比對(duì)方式也可以蔓延到寄存器級(jí)別，且寄存器級(jí)別的比對(duì)時(shí)間節(jié)點(diǎn)可以更細(xì)致，以線程束為單位進(jìn)行。

目前還沒(méi)想好的一個(gè)問(wèn)題是，原子指令該怎么處理，因?yàn)閾屾i這個(gè)行為也是不可控的。