日韩一区二区在线激情,亚洲无码久久中文不卡字幕

[導讀]目錄IPlevel驗證中斷信號生成符合預期status/mask/clear中斷信息查詢SoClevel驗證集成連線成功進入對應的interrupthandler接反異步脈沖中斷集成中斷仲裁CPU自身的中斷中斷從角色上分為生成端和接收端，從驗證角度上可以理解為IP級驗證和SoC級...

IP level驗證

中斷信號生成符合預期
status/mask/clear
中斷信息查詢

SoC level驗證

集成連線
成功進入對應的interrupt handler
接反
異步脈沖中斷集成
中斷仲裁
CPU自身的中斷

中斷從角色上分為生成端和接收端，從驗證角度上可以理解為IP級驗證和SoC級別驗證。處理中斷的接收端一般都為CPU，而CPU內部也可以生成中斷，比如計時器中斷，或者軟件中斷。這個時候CPU即是發(fā)起端也是接收端。

IP level驗證

1、中斷信號生成符合預期

一般CPU會接收到所有的中斷信號，從軟件角度進入中斷處理程序(interrupt handler)來處理這些中斷，需要注意表明中斷觸發(fā)的信號形式可以有多種，主要的有兩種：高電平觸發(fā)和脈沖觸發(fā)。需要保證給出中斷線的各個模塊按specification要求給出高電平或脈沖。有些公司把這種形式用interrupt mode來描述。

2、status/mask/clear

主流的中斷設計都會涵蓋3中類型的寄存器:status,mask,clear

mask驗證分為mask和unmask，mask掉的即使有中斷也發(fā)不出來，unmask如實把中斷發(fā)出去。

clear驗證，中斷產(chǎn)生后可以被清掉，同時要保證清掉后中斷仍然可以再次生成。

status驗證，一般存的都是經(jīng)過mask/unmask處理后的中斷，看是否符合預期。一旦中斷被清掉，看是否跟著變化。

3、中斷信息查詢

從軟件的角度講，一旦有中斷，就會進入中斷處理程序。中斷處理程序一般會訪問一堆寄存器了解情況，這個時候從驗證角度來看，一旦有中斷產(chǎn)生，需要驗證所有的相關的寄存器是否正確，一般主要是狀態(tài)寄存器。

SoC level驗證

1、集成連線

主要查看是否有漏接或者接錯的情況。一般需要有人整理出發(fā)起端和接收端對應的信號。然后以獨熱碼的方式force發(fā)起端的信號，查看所有的接收端信號，理應只有一個對應的信號拉起。一般中斷的對應關系有interrupt id來做映射?？梢猿橄蟪梢粋€bus function model去替換CPU，方便每個集成的人員去使用和檢查。

2、成功進入對應的interrupt handler

在soc level一旦發(fā)起端生成了正確的中斷，接收端/CPU需要進入對應的中斷處理程序(interrupt handler)。這個需要從軟件的角度做end to end的測試。

3、接反

由于發(fā)起端和接受端針對中斷信號形式不一定一樣。比如發(fā)起端認為中斷產(chǎn)生時信號為低電平，而接收端認為是高電平。這個時候在soc集成的時候需要給發(fā)起端的中斷信號加上取反的邏輯。一旦取反沒有做，整個SoC一上電，CPU剛使能中斷控制器，就會不斷進入中斷處理程序，陷入死循環(huán)。

具體驗證方法挺簡單的，需要有一條軟件的程序，使能所有的中斷源，看是否會陷入死循環(huán)。

4、異步脈沖中斷集成

從設計的角度來看，如果接收端的頻率比發(fā)起端慢，發(fā)起端就不應該用脈沖的形式，一旦發(fā)起端和接收端的時鐘不是同步的，必然會產(chǎn)生接收端采樣不到發(fā)起端中斷的情況。這個需要在收集中斷信息的時候就提出來進行修改。

而且即使接收端的頻率比發(fā)起端快，在項目后期，后端為了收斂時序的時候，很有可能會出現(xiàn)降低接收端頻率的操作。異步脈沖存在相當大的風險。

5、中斷仲裁

當有多個中斷同時觸發(fā)，為了區(qū)分到底優(yōu)先處理哪個中斷。一般會給每個中斷源分配一個優(yōu)先級，然后硬件依次處理所有的中斷。更加復雜的IP甚至會有各種工作模式，工作模式有各自的中斷，工作模式本身也有優(yōu)先級的區(qū)分。比如armA系列的exception level 0~3，或者risc-v的機器模式和超級用戶模式。

所有的仲裁結果需要驗證人員來檢查是否符合預期?？梢栽赾ycle級別的同時force所有中斷，如果有工作模式的區(qū)別還需要軟件先配置好具體的工作模式。這里需要驗證人員在軟件程序和驗證環(huán)境之間構造通信機制，軟件告訴驗證環(huán)境什么時候可以force相關信號。

如果force所有中斷，其實潛在了還測試了接收端是否有能力pending那么多中斷，依次處理。

不過實現(xiàn)中斷仲裁的一般是作為發(fā)起端的CPU，而CPU一般是第三方給的，所以其實可以默認沒有問題。