中斷是外部事件通知操作系統的最常用手段。中斷處理機制是計算機多任務環境運行的基礎，是系統實時性的保證;VxWorks是美國Wind River公司于1983年設計開發的一種嵌入式實時操作系統。內核wind在任務調度、中斷處理及網絡處理等方面與其它嵌入式實時操作系統相比具有一定的優勢。特別是其提供的微秒級的中斷處理為VxWorks在嵌入式實時操作系統領域的旗艦地位奠定了基礎。本文通過帶有PCIe接口的FPGA開發板，在VxWorks6.8版本的操作系統環境下，實測一下VxWorks操作系統中斷處理的最小時間間隔是否是傳說中的微秒級。

準備工作

硬件平臺環境如下圖所示，采用兩臺帶有以太網口的設備相連，一端是PC機插有PCIe的FPGA開發板，運行Windows操作系統；另一端是嵌入式設備，運行VxWorks操作系統。

1、嵌入式設備

母板為P2020開發板，PCIe板卡為黑金Xilinx Artix-7 PCIE AX7103 FPGA開發板，運行VxWorks操作系統。

2、PC端

電腦主機一臺，拆開（機箱比較臟，見諒），通過PCIe連線連到黑金Xilinx Artix-7 PCIE AX7103 FPGA開發板上，運行Win7操作系統。

兩臺設備之間通過雙冗余的網線連接。

中斷處理流程

在上面的環境中，按照以太網幀傳遞過程中的需求，任何一端的中斷處理都包含三個不同的主體，首先是CPU內核的中斷響應機制，然后是加上操作系統之后對中斷響應的處理又有操作系統的要求，之后是PCIe硬件設備也有一套向CPU操作系統發送中斷的規范。任何一方的中斷處理機制都可以寫很長很長的文字去描述，本文在此不再贅述。

PCIe總線支持兩種中斷方式，傳統的INTx中斷和基于存儲器寫請求的中斷請求機制即消息中斷。本文的設計方案中使用的是傳統的INTx中斷。為了敘述上的方便，我們從FPGA的時序圖的角度去描述中斷的處理流程，具體分為主機（PCIe發給主機的中斷信號）、PCIe硬核、驅動來配置的中斷使能信號、FPGA側的中斷源。下圖是具體的主機操作系統為VxWorks時FPGA開發板與主機的中斷交互流程。

1）FPGA側有三個中斷源可以觸發中斷，分別是DMA寫開始、DMA寫完成和DMA讀完成中斷，其中，寫開始中斷源是FPGA告知主機此時有數據要通過DMA寫操作進行上傳；寫完成中斷是FPGA將所有的數據封裝成DMA寫請求包；讀完成中斷是FPGA收齊了所有來自主機的DMA讀完成包。上圖中“1”處是中斷源mwr_start_interrupt拉高了。

2）任意一個中斷源拉高，FPGA側給PCIe IP核配置“置中斷”時序，在cfg_interrupt和cfg_interrupt_rdy握手成功后，cfg_interrupt_assert為高則為置中斷。（cfg_interrupt為PCIe硬核發給主機的中斷請求，cfg_interrupt_rdy為主機接收到中斷請求后的回應，此時需要看cfg_interrupt_assert的狀態，cfg_interrupt_assert為高，則為置中斷，如上圖中“2”處所示；cfg_interrupt_assert為低電平，則為清中斷請求，如上圖中“5”處所示。）

3）“置中斷”后一段時間（此處約為17個時鐘），主機側硬中斷電平INTA拉高，此時才是FPGA板卡真正的向主機發出了一個中斷。如上圖中“3”。

4）驅動檢測到中斷電平拉高后，以PIO寫操作的方式往PCIe的BAR空間中控制狀態寄存器04H的第[31]位寫1，關閉接收中斷功能，此時中斷使能信號線int_dis_o拉高，如上圖中“4”位置。int_dis_o為高電平期間，CPU不再響應FPGA板卡的中斷請求，此處非常重要。之后CPU則以PIO讀的形式讀FPGA的中斷狀態寄存器。

5）FPGA將中斷狀態寄存器的值以PIO讀完成包形式發送給CPU，告知CPU該中斷具體為何種中斷，同時配置“清中斷”時序。如上圖中“5”處所示。

6）CPU驅動記錄中斷源后復位相應中斷標志位，如上圖中“6”處所示。（此處也可由FPGA自己完成）

7）FPGA拉低相應中斷源信號，如上圖中“7”處所示。

8）CPU驅動通過PIO寫操作往控制狀態寄存器04H第[31]位寫0，重新開啟接收中斷功能。如上圖中“8”處所示。

9）重復步驟1）啟動下一次中斷；10）下一次置中斷時序；11）硬中斷電平再次拉高。

下圖為一次完整的DMA讀操作時CPU與FPGA板卡之間的交互流程，最后會涉及到DMA讀完成中斷，詳細過程的描述略。

VxWork響應PCIe中斷的最小間隔

為了得到VxWorks響應PCIe中斷的最小間隔，我們在FPGA側對兩次“置中斷”間隔，即上圖步驟2）與步驟10）進行了時鐘計數，在“置中斷”時序(cfg_interrupt_rdy & cfg_interrupt_assert)下將間隔時間寄存器inter_intr_clk_cnt[31:0]計數復位，否則計數加一，直到下一次“置中斷”進行計數復位，這樣就能計算出中斷信號兩次拉高的時間間隔。

在測試的過程中，我們用Vivado抓取了實際數據傳輸時兩種不同的中斷場景。

1、場景1：寫開始中斷和讀完成中斷一起處理

有了上面中斷處理流程的介紹，就可以很方便的分析具體工作狀態下的波形圖。從上圖可以看到，讀完成中斷mrd_done_interrupt觸發置中斷時序，主機的硬中斷電平拉高，驅動往控制與狀態寄存器04H的最高位（圖示int_dis_o信號） PIO操作寫“1”，關閉中斷功能，此時硬件這邊不再產生置中斷時序，直到驅動跳出中斷復位程序，往04H的int_dis_o寫“0”，使能中斷；驅動PIO讀中斷狀態寄存器（圖示藍線）“采樣”到讀完成（圖示mrd_done_interrupt信號）和寫開始（圖示mwr_start_interrupt信號）兩個中斷標志位為高，此時，驅動會記錄下來并同時對這兩個中斷標志位進行復位操作，然后驅動分別執行讀完成中斷和寫開始中斷狀態機。

場景2：寫開始中斷和讀完成中斷先后處理

從上圖可以看到，讀完成中斷mrd_done_interrupt觸發置中斷時序，主機的硬中斷電平拉高，驅動往控制與狀態寄存器04H的最高位（圖示int_dis_o信號） PIO操作寫“1”，關閉中斷功能，此時硬件這邊不在產生置中斷時序，直到驅動跳出中斷復位程序，往04H的int_dis_o寫“0”，使能中斷；驅動PIO讀中斷狀態寄存器（圖示藍線1）采樣到讀完成（圖示mrd_done_interrupt信號）中斷標志位為1，硬件產生清中斷時序，將主機側的硬中斷電平拉低，注意，此刻寫開始中斷（圖示mwr_start_interrupt信號）剛好拉高，驅動只記錄讀完成中斷并對讀完成中斷標志位進行復位操作（圖示藍線2），然后驅動執行讀完成中斷狀態機，驅動跳出讀完成中斷狀態機后重新使能中斷（圖示藍線3），此時硬件側因為寫開始中斷才被允許產生置中斷時序，驅動再次檢測到硬中斷電平信號為高，驅動PIO讀中斷狀態寄存器（圖示藍線4）采樣到寫開始中斷標志位為1，硬件產生清中斷時序，將主機側的硬中斷電平拉低，驅動記錄寫開始中斷并對寫開始中斷標志位進行復位操作（圖示藍線5），然后驅動執行寫開始中斷狀態機。

在第二個測試場景中，我們可以通過計數得知兩個相鄰中斷的最小時間間隔，，硬件側產生第一次中斷段時序（圖示藍線1），在執行完第一次中斷后，驅動側將int_dis_o拉低，重新使能中斷，硬件側立即產生置中斷時序進行第二次中斷操作（圖示藍線2），如下圖所示：

我們將圖示藍線2處進行放大得到下圖：

通過相鄰中斷時鐘計數信號inter_intr_clk_cnt[31:0]可以知道相鄰兩中斷的最小間隔是365個鐘，后邊測試過多次，測試結果有368，364，，我們取365，時鐘周期為16ns，由此可以計算得知VxWorks下最小中斷間隔是365*16=5.84us。

結論：VxWorks操作系統中斷處理的最小時間間隔確實是傳說中的微秒級！

Windows操作系統下PCIe中斷響應間隔測試

出于好奇，我們也嘗試測了一下Windows 操作系統下PCIe中斷響應的時間間隔。在Windows平臺下的驅動暫未使用開/關中斷使能的功能，所以只是測試在點播視頻以及拷貝視頻文件兩種場景下的中斷間隔。

1、場景1：點播視頻，速率為10Mbps左右

從上圖可以看到，上一次置中斷時序復位后計數12417491個clk（16ns）再次產生置中斷時序，此時中斷間隔約為198.7ms，后面統計到一些計數值：19026416（304.4ms）,6486433（103.8ms）,9981793（159.7ms）。在點播視頻時，帶寬并未達到上限，驅動處理兩個相鄰中斷的時間間隔＞100ms。為了在高帶寬情況下測試，我們進行了場景2的測試。

場景2：拷貝視頻，速率為幾百兆bps

從上圖可以看到，上一次置中斷時序復位后計數4175個clk（16ns）再次產生置中斷時序，此時中斷間隔約為66.8us，后面統計到一些計數值：3595（57.5us）、7456（119.3us）、3582（57.3us）、4159（66.5us）。在帶寬提升后，win32驅動處理中斷的頻率有了顯著地提高。

遇到的問題

在剛開始的時候，中斷處理流程中CPU操作時并沒有開啟或關閉接收中斷的操作，結果，在Windows平臺下，沒有任何的問題，生成PCIe IP核時，設置傳輸帶寬上限為2Gbps，在1G以太網口測試各種業務時都很穩定，沒有出現操作系統崩潰的情況；但在VxWorks系統測試時，由于VxWorks系統實時性非常好，響應中斷也比較及時，就會出現操作系統正在執行一個中斷服務程序時，硬件又來了一個中斷，直接導致VxWorks系統死掉，如下圖所示。當然，這也是中斷處理流程不規范造成的。后續會在Windows驅動中也添加上開關中斷使能的步驟，測試一下Windows相應PCIe中斷的最小間隔。不過從目前測試數據看，Windows相應PCIe中斷的速度肯定會比VxWorks慢很多。

全文完。