說在前面1：
作爲CPU接口的一種，localbus相比於PCI、PCIe開發簡單很多，只需要完成CPU內存地址與硬件寄存器/RAM地址的映射以及讀/寫信號，片選信號的時序，此次localbus的開發是硬件側建立一個localbus工程輔助調試localbus驅動。
說在前面2：
硬件平臺：AX7103；CPU平臺：CT-p2020；驅動操作平臺：vxworks
說在前面3：
硬件側沒有開發板與p2020 localbus的50pins直接相對接，而驅動側需要開發、測試localbus驅動，因此需要創造調試環境，利用AX7103開發板的68個引腳，將localbus總線相關的關鍵引腳（37pins=16pins_addr+16pins_data+3pins_csn+1pin_oen+1pin_wen）以及中斷信號定義到EX_IO1和EX_IO2上，再根據p2020原理圖與接插件J5、J4相匹配，調試環境如下圖1所示（略醜，只做原型功能驗證）。圖示J5爲p2020接插件（localbus總線相關信號）；J4爲p2020接插件（硬線中斷、GND信號）；EX_IO1爲localbus總線地址、片選和讀寫使能管腳；EX_IO2爲數據、中斷管腳。注意：兩塊開發板的電平標準要一致，否則不能通過杜邦線直連；另外建議兩塊開發板杜邦線共地相連。
理論簡介：
關於localbus的簡介網上有參考價值的就是這個鏈接：https://wenku.baidu.com/view/aeca83593b3567ec102d8a80.html?from=search 因爲局部總線簡單，也沒有什麼可介紹的，理論部分就見鏈接，我這裏就附上關鍵信號的讀寫時序圖，如下圖2，圖3所示。同樣的localbus接口在不同的CPU處理器地址和數據位寬不一致，信號也會有一些不一致，具體來說：BM3803中地址數據線未複用，數據位寬32bit（雙字操作）；p2020中數據線LAD複用（通過LALE信號鎖存高11bit的地址，如果只用16bit的地址時可以不接LALE），數據位寬16bit（雙字節操作）。
|
信號 |
位寬 |
方向 |
說明 |
|
CE# |
1 |
input |
片選信號 |
|
OE# |
1 |
input |
讀使能，低有效 |
|
WE# |
1 |
input |
寫使能，低有效 |
|
Addr |
27 |
input |
尋址寄存器地址 |
|
Data |
16 |
inout |
CPU寫入或讀出FPGA的數據 |
調試歷程：
調試伊始，通過p2020的原理圖可以看出CS0和CS1分別給了內部的nand_flash以及nor_flash使用，另外輸出3位的片選信號（CS2,CS3和CS4），說明最多可以掛8片局部總線外設，，這些外設（含*_flash）共用數據線、地址線以及讀寫使能。第一步就得先知道驅動使用了哪個片選信號，驅動也是摸索，驅動代碼寫着只使用了CS4，屏蔽了原來例程中的CS2，通過硬件側抓cpu_csn[2:0]發現，cpu_csn[0]也會存在低片選狀態，後經驅動修改，先保留使用CS2，這樣驅動每次讀寫操作時都能觸發“cpu_csn[2:0]==3‘b110”。CPU板將對地址區間0xf1000_0000~0xf1000_ffff（128KB）進行讀寫操作時會拉低CS2，映射到硬件側就是對寄存器/RAM的讀寫了。
測試寫功能，在CPU啓動後，驅動會給內存地址0xf100_0118處寫16‘h5555，如下圖4所示，先給出寫地址，然後拉低片選信號，幾乎同時拉低了寫使能信號，這樣數據就從CPU寫入到FPGA了。
與寫操作的簡單相比，問題都出在了讀操作，我們也同樣地將AX7103和p2020的讀使能線接好（地址、數據和片選信號先接好了），發現此時CPU不能啓動了，但是將此信號接到未使用的EX_IO上時CPU可以正常啓動，說明讀使能信號干擾了CPU的啓動，可是，cpu_oen和cpu_wen屬性是一樣的，input到FPGA內部，不存在輸出到CPU導致不能啓動，，，查看p2020的datasheet發現p2020上的LGPL2信號有兩重定義：1.localbus的讀使能cpu_oen；2.配合LBCTL、LALE信號配置e500核pll時鐘佔空比。懷疑是系統啓動後短時間內FPGA側的cpu_oen電平影響到CPU側的LGPL2，爲此，我們將讀使能改爲inout信號，在CPU啓動後的10s內爲高阻態，起着隔離作用，而10s後p2020的bootrom也加載差不多可以bootup了，然而實際測試下來的結果是CPU依舊不能正常啓動。
我們把所有的杜邦線完全拔掉，只保留讀使能線的連接，發現CPU可以正常啓動，此時說明FPGA側的讀使能電平並沒有影響到CPU側的啓動，爲了具體定位到哪一個信號，我們再次基礎上，把線一點一點接上去，最後接完了讀使能線、寫使能線，片選線以及地址線後，CPU板可以正常bootup而且FPGA能抓到正常的讀寫（只是看不到讀寫數據）時序，插上了數據線後發現CPU就不能啓動了，至此，總算定位到問題出在哪了，爲此，FPGA側做了一個延遲處理，數據線一直處於20s的高阻態（此時CPU可以進行localbus寫操作），等到bootup後，才使能數據的讀出，這樣處理其實很笨拙，但是確實能解決CPU不能正常啓動的問題，可治標不治本/允悲/，畢竟刻意的延遲不靠譜。
//rst_done只有20s後才爲1，在此之前cpu_data處於高阻
assign cpu_data = ((cpu_oen==1'b0)&&(rst_done==1'b1)) ? cpu_rdata : 16'bz;
assign cpu_wdata = cpu_data ;
靈感一現。。。FPGA側在“assign cpu_data = (cpu_oen==1'b0) ? cpu_rdata : 16'bz;”只是多加了一條約束條件“(rst_done==1'b1)”就能讓CPU啓動，說明在CPU啓動之初，cpu_oen滿足低使能導致cpu_data有輸出干擾到CPU側的數據線，，，博客之初提及p2020內部還有nand_flash和nor_flash，在p2020啓動的時候要從這些flash裏讀寫數據，也拉低了cpu_oen，此時localbus讀出的是默認值16‘h0，而本應該從*_flash裏讀出一些有用的值被16‘h0覆蓋。爲了驗證這種猜想，我將數據信號的代碼改爲
//CPU只有片選了localbus後FPGA纔會將cpu_rdata輸出，否則高阻
assign cpu_data = ((cpu_oen==1'b0)&&(cpu_csn[0]==1'b0)) ? cpu_rdata : 16'bz;
assign cpu_wdata = cpu_data ;
這樣修改後CPU正常啓動，因爲p2020啓動之初，會讀*_flash，雖然拉低了cpu_oen，但是選通並非CS2，故此時FPGA的cpu_data保持高阻，直到片選成功且讀使能低有效纔將讀數據輸出。
調試總結：
耗時半周，終於調試完畢。定位問題比解決問題更耗時，有感。
排除法，一步一步定位問題。不排除還有點運氣成分，hahah
/*************** ver 2.0 about interrupt added by LIUWF ***************/
在調試完基本的數據讀寫功能後，需要調試硬線中斷，FPGA開發板需要上傳數據時通過中斷告知CPU，由p2020原理圖可以知道，除了irq3被佔用，另外6箇中斷（irq0/1/2/4/5/6）可供外設使用，均在J4接插件位置處，，p2020內部中斷有64類，外部中斷有12類，我們調試中使用到的是外部中斷irq1。
硬線中斷這塊的調試主要是驅動修改內容，硬件配合抓信號。
需要注意的是，下圖是p2020 datasheet關於中斷irq的描述爲高時置中斷，爲低時不產生中斷，，然而實際板級測試發現，irq爲低時有效，產生硬線中斷。
當驅動收到中斷後，需要對硬線中斷進行復位，參考PCIe總線中INTa中斷操作，我們定義0x110寄存器爲中斷寄存器，驅動往0x110寫1在寫0時硬件將硬線中斷信號重新拉回高電平復位狀態。
/**************************end for ver 2.0*********************************/