pcie是匯流排協議的一種，具體可見
本文主要根據多核tilera的pcie驅動程式，說明pcie資料傳輸的初始化步驟及分配資源，並說明如何定位driver的故障。
有了pcie，兩個相同的晶元可以互相傳輸資料、流量等。pcie規定，兩個互聯的晶元，必須有乙個是root-complex裝置，另乙個是end-point裝置；其對應關係可通過讀取特定檔案獲得。
pcie發展至今可以無障礙支援全雙工模式。為簡單起見，本文首先以單工模式為例。設乙個裝置上允許c2c_sender程式，另乙個裝置上允許c2c_receiver程式，這兩個程式基於pcie傳輸資料。
限於時間關係，不再一一繪製流程圖，直接在之前做的ppt上截圖。
pcie在初始化的過程中，做了多次位址對映，很明顯，應用程式的虛擬位址空間需要對映到pcie位址空間；同時pcie的位址空間也要對映回應用程式的虛擬位址空間。
通讀pcie的驅動**之後可以看出，pcie的傳輸原理很清晰，其實現過程有清晰的位址對映，這保證了傳送者傳送資料的起始位址和接受者接收資料的起始位址是一致的，反之也是。當然，pcie驅動的複雜度並未完全在此體現出來。
有了如此清晰的驅動邏輯及流程，距離定位驅動故障的原因也就不遠了。另一篇部落格介紹了基於pcie驅動的晶元互聯設計。方案設計完成之後，兩個晶元間總是只能連通很短的時間。讓我們先看看此問題的前提：
條件之一：晶元互聯程式（雙工）只能連通很短時間，但是**邏輯經過檢查無問題，雙線程無死鎖；
條件之二：原廠提供的程式（單工）可一直連通。
條件之四：本人編譯、執行原廠提供的例子（動態、靜態），均只能連通很短的時間。和晶元互聯程式問題一樣。
於是可以得出結論：原廠提供的可用程式，其靜態連線的pcie庫檔案，和公司機器上的pcie庫檔案不一致，後來結果的確如此，只是在猜測的情況下，不敢確定。
問題反饋發過去，遲遲沒有回應。公司這邊也在緊鑼密鼓的「要求」我盡快定位故障。
在通讀了晶元附帶提供的pdf文件、驅動**的同時，本人也讀了不少這方面的**。一位老師曾不經意間說：他有一段時間對數碼訊號的本質不太理解，就跑到圖書館找了10多本這方面的書籍，對比翻閱，直到理解。在遇到問題的時候，不妨多找幾個相關知識的講解**，這是捷徑。
在pcee文件裡有這樣一段描述，dma的暫存器有個g標誌位，置為該標誌，則dma傳輸立即進行。因為是立即進行，那麼該置位語句應該是所有的初始化**之後。對比驅動**，並非如此，該置位語句之後依然有兩句**是用來初始化pcie資源。調整置位語句的位置，重現編譯庫檔案，問題立即得到解決。將近5g/s的吞吐量保持穩定。
過程的繁瑣的，迷茫的。結果是極好的。
編譯原理初探
編譯的第乙個過程是詞法分析，目的就是在連續的字元中識別出乙個乙個的符號，並盡可能的識別出符號的屬性，再詞法分析階段，能夠識別出一些符號的意義，它們包括關鍵字，數字字串，分隔符等，它們不需要其他符號的輔助就能確定本身的意義，如int代表整型 但是有一些符號需要通過前後的其它符號才能確定，更多的資訊需要...
Spark 原理初探
driver 執行main方法並建立sparkcontext的程序 sparkcontext 是spark執行時的上下文環境,其實就是幫助客戶端和clustermanager集群管理器進行互動的,如通訊,資源申請,任務分配,任務監控 executor 是執行在worker工作節點上的jvm程序 負責...
Robotium原理初探
本文 於 測試框架圖 android的instrumentation對某個監控程式進行互動時 1.啟動時將專案配置檔案androidmanifest.xml檔案中的instrumentation標籤中的內容進行初始化 標明了所使用的測試執行類，目標專案包名 2.執行測試時 可用adb命令觸發 將啟動...