摘 要: 介紹了一種基于XILINX FPGA的在線程序升級(jí)方案,該方案不需要額外增加器件,在不改變硬件狀態(tài)的前提下,實(shí)現(xiàn)產(chǎn)品的軟件功能升級(jí)。由于對(duì)配置芯片(PROM)的所有操作均由FPGA的內(nèi)部邏輯實(shí)現(xiàn),故此方案具有良好的移植性和擴(kuò)展性。
?
0 引言
本文的研究課題是基于一種已應(yīng)用在某型號(hào)上的彈載測(cè)試設(shè)備,因總體要求有變,需要對(duì)出廠后的產(chǎn)品功能進(jìn)行升級(jí)。由于此類(lèi)產(chǎn)品在出廠前都需要進(jìn)行特殊的工藝處理,產(chǎn)品交付后不具備開(kāi)蓋重復(fù)燒錄程序的條件,且根據(jù)型號(hào)研制要求,彈上設(shè)備在完成系統(tǒng)匹配試驗(yàn)和綜合試驗(yàn)后禁止拆卸維修,因?yàn)樵O(shè)備拆卸后,狀態(tài)遭到破壞,前期進(jìn)行的各項(xiàng)試驗(yàn)需要重新評(píng)估,影響到型號(hào)研制進(jìn)度。為解決這個(gè)難題,本文提出了一種在線程序升級(jí)方案,在不破壞產(chǎn)品硬件狀態(tài)的前提下,利用FPGA靈活的內(nèi)部邏輯資源實(shí)現(xiàn)自身的軟件功能升級(jí)。
1 應(yīng)用背景
隨著內(nèi)部資源的日趨豐富以及可重復(fù)配置的優(yōu)勢(shì),F(xiàn)PGA在測(cè)試設(shè)備中擔(dān)任了重要的角色,實(shí)現(xiàn)的功能也日趨復(fù)雜化和多樣化,對(duì)產(chǎn)品功能實(shí)現(xiàn)重配置的應(yīng)用需求也在日益加大。產(chǎn)品功能重配置是在不改動(dòng)設(shè)備硬件狀態(tài)的前提下,通過(guò)更新FPGA的程序文件,達(dá)到產(chǎn)品功能更改及升級(jí)的方法。目前主流的應(yīng)用方案是使用MCU(或DSP)+存儲(chǔ)芯片的架構(gòu)[1],MCU負(fù)責(zé)存儲(chǔ)芯片的讀寫(xiě),存儲(chǔ)芯片作為FPGA的程序代碼存儲(chǔ)器,產(chǎn)品上電后,MCU將存儲(chǔ)芯片中的數(shù)據(jù)讀出,并按照特定時(shí)序(FPGA加載時(shí)序)發(fā)送到FPGA,此過(guò)程即為FPGA的數(shù)據(jù)加載流程[2]。此方案不適用于本文的研究課題,原因有二:首先,此方案需額外增加MCU和存儲(chǔ)芯片兩個(gè)芯片,印制板的布局難度加大,尤其對(duì)于本設(shè)備印制板上器件已經(jīng)很多并無(wú)多余空間的情況更加明顯;其次,軟件的數(shù)量增多,增加了MCU軟件后,出故障的概率也隨之加大,由于MCU不僅需要對(duì)存儲(chǔ)芯片進(jìn)行讀寫(xiě)操作,還需要對(duì)FPGA的上電加載過(guò)程進(jìn)行模擬,如果加載不成功,不僅產(chǎn)品的升級(jí)功能失敗,產(chǎn)品的基本功能也隨之失效,考慮到本產(chǎn)品的特殊應(yīng)用場(chǎng)合,此方案風(fēng)險(xiǎn)較大,不宜采用。
本文采用的方案是在FPGA的內(nèi)部構(gòu)建功能模塊,由該模塊完成PROM芯片燒寫(xiě)所需要的相關(guān)操作。在對(duì)產(chǎn)品進(jìn)行軟件升級(jí)時(shí),該模塊執(zhí)行升級(jí)工作,不需要進(jìn)行升級(jí)時(shí),模塊閑置,不發(fā)揮作用。該模塊與產(chǎn)品的原功能模塊獨(dú)立運(yùn)行,互不干涉。設(shè)備上電時(shí),F(xiàn)PGA的程序加載流程仍由自帶的PROM配置芯片自動(dòng)完成。該方案既沒(méi)有額外增加芯片,也沒(méi)有額外增加軟件個(gè)數(shù),大大降低了出錯(cuò)的風(fēng)險(xiǎn)。
2 功能實(shí)現(xiàn)
設(shè)備的系統(tǒng)連接框圖如圖1所示,設(shè)備通過(guò)RS-422接口與地面測(cè)控臺(tái)連接,地面測(cè)控臺(tái)通過(guò)網(wǎng)絡(luò)通信接口與計(jì)算機(jī)連接。測(cè)試設(shè)備的主控芯片F(xiàn)PGA為XILINX公司的Virtex-4系列XC4VSX35芯片,PROM配置芯片型號(hào)為XCF32PFSG48C,存儲(chǔ)容量32 Mbit[3]。
計(jì)算機(jī)通過(guò)網(wǎng)絡(luò)接口將燒寫(xiě)文件發(fā)送到測(cè)控臺(tái),測(cè)控臺(tái)通過(guò)RS-422接口將燒寫(xiě)數(shù)據(jù)發(fā)送到設(shè)備,設(shè)備通過(guò)RS-422接口向測(cè)控臺(tái)反饋狀態(tài)信息。下面分別從燒寫(xiě)文件的生成、測(cè)控臺(tái)與設(shè)備的通信協(xié)議、FPGA與PROM的連接、FPGA軟件設(shè)計(jì)4個(gè)方面進(jìn)行闡述。
2.1 燒寫(xiě)文件生成
XILINX設(shè)計(jì)工具(PROMGen)可生成多種格式的配置數(shù)據(jù)文件,這些數(shù)據(jù)文件可以存儲(chǔ)在PROM中,也可以存儲(chǔ)在其他非易失性存儲(chǔ)芯片中[4]。配置文件的常用格式見(jiàn)表1。
FPGA程序編寫(xiě)完成,經(jīng)過(guò)ISE(ISE Design Suite 14.2)開(kāi)發(fā)環(huán)境綜合實(shí)現(xiàn)后直接生成.bit編程文件,該文件可由IMPACT工具通過(guò)編程器燒寫(xiě)到PROM中。.bit格式文件是二級(jí)制配置數(shù)據(jù)文件,包含了頭文件數(shù)據(jù),頭文件數(shù)據(jù)中包含PROM的相關(guān)信息,用于控制PROM燒寫(xiě)過(guò)程,該格式文件適用于使用編程器燒寫(xiě)。.hex文件為ASCII碼PROM文件格式,僅包含配置數(shù)據(jù),不包含頭文件等信息,可使用PROMGen或iMPACT工具生成,.hex文件為本文采用的文件格式。
2.2 設(shè)備通信協(xié)議
測(cè)控臺(tái)與設(shè)備通過(guò)RS-422連接,采用異步串行通信,波特率為921.6 kb/s,8 bit數(shù)據(jù)位,1 bit奇校驗(yàn),1 bit停止位。對(duì)于RS-422的物理層通信,采用無(wú)校驗(yàn)的方式。發(fā)送與接收采取數(shù)據(jù)幀傳輸,表2以測(cè)控臺(tái)發(fā)送的數(shù)據(jù)幀為例說(shuō)明。
表2中,0xFD、0x55為幀頭;指令類(lèi)型0x02表示該指令為數(shù)據(jù)傳送指令,其他指令類(lèi)型在此不贅述;數(shù)據(jù)長(zhǎng)度表示該幀數(shù)據(jù)的數(shù)據(jù)區(qū)中包含的數(shù)據(jù)字節(jié)個(gè)數(shù),數(shù)據(jù)區(qū)字節(jié)個(gè)數(shù)可變,數(shù)據(jù)長(zhǎng)度0x00~0xFF表示數(shù)據(jù)區(qū)中實(shí)際數(shù)據(jù)個(gè)數(shù)0~255個(gè);校驗(yàn)和為數(shù)據(jù)區(qū)中所有數(shù)據(jù)(0~255個(gè))的累加和。
由于傳送的文件為“.hex”純數(shù)據(jù)文件,文件中僅包含A~F、a~f、0~9等三類(lèi)字符,對(duì)應(yīng)十六進(jìn)制數(shù)據(jù)分別為0x41~0x46,0x61~0x66,0x30~0x39,可確保幀頭數(shù)據(jù)0xFD、0x55在整個(gè)數(shù)據(jù)幀中的唯一性,接收方可依此作為判斷每幀數(shù)據(jù)起始的依據(jù)。
2.3 接口實(shí)現(xiàn)
FPGA和PROM、JTAG的具體連接關(guān)系見(jiàn)圖2。
圖2中,JTAG1下載口用于對(duì)FPGA進(jìn)行在線調(diào)試和仿真,JTAG2下載口用于對(duì)PROM進(jìn)行程序燒寫(xiě)。 FPGA的4個(gè)I/O口連接到JTAG2鏈,在對(duì)PROM芯片進(jìn)行程序燒寫(xiě)時(shí),I/O 1~I/O 4為高阻態(tài),編程器通過(guò)JTAG2口對(duì)PROM進(jìn)行程序燒寫(xiě)。燒寫(xiě)完成后,F(xiàn)PGA執(zhí)行程序,此程序中嵌入了對(duì)PROM的在線升級(jí)功能,在需要對(duì)PROM芯片進(jìn)行在線升級(jí)時(shí),I/O 1~I/O 4則分別模擬TCK、TMS、TDI、TDO管腳,由FPGA內(nèi)部邏輯實(shí)現(xiàn)JTAG時(shí)序控制功能,對(duì)PROM進(jìn)行擦除、編程、校驗(yàn)等操作,完成PROM的程序升級(jí)。
2.4 模塊組成
FPGA內(nèi)部由3個(gè)模塊組成,分別為422通信模塊、中心控制模塊、JTAG時(shí)序控制模塊,組成圖見(jiàn)圖3。
422模塊與測(cè)控臺(tái)進(jìn)行數(shù)據(jù)交互,接收測(cè)控臺(tái)發(fā)送的程序數(shù)據(jù),并回復(fù)相應(yīng)的狀態(tài)信息到測(cè)控臺(tái)。JTAG模塊用于生成邊界掃描控制時(shí)序,對(duì)PROM進(jìn)行擦除、編程和校驗(yàn)等相關(guān)操作。控制模塊用于對(duì)422模塊和JTAG模塊進(jìn)行協(xié)調(diào)控制,對(duì)422模塊接收到的數(shù)據(jù)進(jìn)行校驗(yàn),并判斷JTAG模塊當(dāng)前的運(yùn)行狀態(tài)后,按照自定義的握手協(xié)議將數(shù)據(jù)發(fā)送到JTAG模塊,同時(shí)將JTAG模塊回復(fù)的信息反饋到422模塊。
2.5 模塊通信時(shí)序設(shè)計(jì)
控制模塊與JTAG模塊的連接見(jiàn)圖4。
圖4中,重要信號(hào)說(shuō)明如下:
EPV_CTRL:?jiǎn)?dòng)擦除、編程、校驗(yàn)操作;
RDY:準(zhǔn)備好信號(hào),JTAG模塊準(zhǔn)備好接收數(shù)據(jù);
LOAD:握手信號(hào),收到RDY為高將LOAD置高表示數(shù)據(jù)已就緒。
以上信號(hào)均為高有效,通信時(shí)序見(jiàn)圖5。
圖5中,控制模塊將EPV_CTRL信號(hào)置高,等待RDY信號(hào)有效,當(dāng)檢測(cè)到RDY信號(hào)為高后,將LOAD信號(hào)置高,同時(shí)將數(shù)據(jù)放在DATA線上,下一個(gè)CLK周期檢測(cè)到RDY變?yōu)榈停瑒t延遲一個(gè)周期,在下下個(gè)周期將LOAD信號(hào)置低,LOAD信號(hào)和DATA線上數(shù)據(jù)至少保持2個(gè)CLK周期(注:DATA數(shù)據(jù)線上傳送的第一個(gè)字節(jié)為CRC校驗(yàn)值,相關(guān)說(shuō)明見(jiàn)2.8節(jié))。
2.6 JTAG模塊設(shè)計(jì)
下面重點(diǎn)介紹JTAG模塊的實(shí)現(xiàn)原理。
該模塊的主要功能是對(duì)PROM器件進(jìn)行擦除、編程和校驗(yàn)操作,每個(gè)步驟都是一些必要的指令序列去控制PROM執(zhí)行相應(yīng)的動(dòng)作。例如對(duì)PROM進(jìn)行擦除操作,需要首先發(fā)送指令將PROM置為ISP模式,然后發(fā)送擦除指令,指定需要擦除的塊(BLOCK),擦除開(kāi)始后,監(jiān)測(cè)是否有錯(cuò)誤發(fā)生,直到擦除結(jié)束。
JTAG模塊發(fā)送特定的指令去控制PROM,實(shí)現(xiàn)不同的操作。指令的發(fā)送時(shí)序遵循IEEE1194.1邊界掃描協(xié)議。邊界掃描協(xié)議最初是用于對(duì)芯片進(jìn)行測(cè)試的,通過(guò)在芯片內(nèi)部定義一個(gè)測(cè)試訪問(wèn)口(Test Access Port,TAP),以及專(zhuān)用的JTAG測(cè)試工具對(duì)內(nèi)部節(jié)點(diǎn)進(jìn)行測(cè)試,JTAG測(cè)試允許將多個(gè)器件串聯(lián)在一起,形成一個(gè)JTAG鏈,實(shí)現(xiàn)對(duì)各個(gè)器件的分別測(cè)試。現(xiàn)今,JTAG接口也常用于實(shí)現(xiàn)在線編程(In-System Programming,ISP),對(duì)Flash等器件進(jìn)行編程。
完整的JTAG處理鏈由JTAG寄存器和TAP控制器組成[5]。JTAG寄存器包含了邊界掃描需要的所有指令。TAP控制器主要包含一個(gè)狀態(tài)機(jī),對(duì)控制PROM編程需要的每個(gè)必要的步驟進(jìn)行編碼, TCK上升沿時(shí)刻TMS的狀態(tài)值決定狀態(tài)機(jī)的跳轉(zhuǎn)流程,包括數(shù)據(jù)入數(shù)據(jù)寄存器的流程和指令入指令寄存器的流程。相關(guān)的狀態(tài)轉(zhuǎn)換原理可參閱參考文獻(xiàn)[5],此不贅述。
2.7 編程操作
對(duì)PROM的編程包含擦除、編程、校驗(yàn)3個(gè)步驟。
(1)擦除: 控制模塊將EPV_CTRL置高, JTAG模塊擦除整片PROM,并讀取PROM的狀態(tài),檢查完成狀態(tài)或錯(cuò)誤狀態(tài),完成擦除后,在下一個(gè)CLK時(shí)鐘上升沿將RDY置高,并進(jìn)入編程流程。如擦除過(guò)程中有錯(cuò)誤發(fā)生,ERROR被置高,控制模塊必須通過(guò)RST復(fù)位JTAG模塊,并將EPV_CTRL置高,再次嘗試擦除操作。
(2)編程:擦除操作成功后,JTAG模塊將RDY置高,表示該模塊已經(jīng)準(zhǔn)備好接收編程數(shù)據(jù),控制模塊將LOAD置高,同時(shí)把數(shù)據(jù)送到DATA線上,同一個(gè)時(shí)鐘的下降沿,JTAG模塊鎖存數(shù)據(jù),下一個(gè)時(shí)鐘上升沿,JTAG模塊將RDY置低,再下一個(gè)時(shí)鐘上升沿,控制模塊將LOAD置低。因JTAG模塊需要將數(shù)據(jù)按位串行移到PROM,所以控制模塊發(fā)完數(shù)據(jù)后,至少需要等8個(gè)周期才能發(fā)送下一字節(jié)數(shù)據(jù),發(fā)送新的數(shù)據(jù)前需要首先監(jiān)控RDY信號(hào)的狀態(tài)。
控制模塊每發(fā)送完256 bit的數(shù)據(jù)后,PROM對(duì)這些數(shù)據(jù)進(jìn)行Flash編程,約需15 μs,控制模塊需要延遲等待。在編程期間,模塊監(jiān)測(cè)PROM的狀態(tài)查看是否有問(wèn)題發(fā)生,控制模塊發(fā)送完所有的數(shù)據(jù)到JTAG模塊后,將EPV_CTRL置低,JTAG模塊將最后256 bit的數(shù)據(jù)傳送到PROM,若沒(méi)有錯(cuò)誤,進(jìn)入校驗(yàn)操作。
(3)校驗(yàn):控制模塊將EPV_CTRL置低后,JTAG模塊將最后一批數(shù)據(jù)發(fā)送到PROM,開(kāi)始進(jìn)入校驗(yàn)流程,JTAG模塊讀取PROM中的所有數(shù)據(jù)對(duì)數(shù)據(jù)進(jìn)行8 bit CRC校驗(yàn),并與.hex文件的CRC校驗(yàn)值進(jìn)行比較,如果不相等,將ERROR置高,DONE保持低,如果相等,則DONE置高,所有連接到JTAG口的I/O管腳高阻態(tài),校驗(yàn)結(jié)束。
2.8 數(shù)據(jù)校驗(yàn)
為保證燒寫(xiě)過(guò)程的可靠性及抗干擾性,必須對(duì)燒寫(xiě)數(shù)據(jù)進(jìn)行校驗(yàn),校驗(yàn)措施如下:
(1)在設(shè)備與地面測(cè)控臺(tái)的422通信幀尾加入校驗(yàn)字,對(duì)每幀數(shù)據(jù)進(jìn)行累加和校驗(yàn),保證幀數(shù)據(jù)的完整性及正確性;
(2)由于生成的.hex文件為純配置數(shù)據(jù),不包含文件的校驗(yàn)信息,為保證燒寫(xiě)過(guò)程的完整性,對(duì)整個(gè)文件進(jìn)行數(shù)據(jù)校驗(yàn),在.hex文件頭插入該數(shù)據(jù)文件所有字節(jié)的CRC8校驗(yàn)值,在燒寫(xiě)完成后,將PROM中的數(shù)據(jù)全部讀出并進(jìn)行CRC8校驗(yàn)運(yùn)算,若與文件頭的CRC8校驗(yàn)值相等,則表明燒寫(xiě)操作成功。
3 設(shè)計(jì)注意要點(diǎn)
圖2中FPGA的I/O口與PROM在同一個(gè)JTAG鏈,在進(jìn)行程序升級(jí)時(shí),此JTAG鏈(JTAG2)不能連接編程器。
本方案中對(duì)PROM的內(nèi)容進(jìn)行更新是從地址0順序進(jìn)行的,此更新并不改變PROM內(nèi)部的設(shè)置寄存器(setup registers)的值,僅改變PROM中數(shù)據(jù)區(qū)的內(nèi)容。
4 結(jié)論
本文基于FPGA靈活的重配置功能,提出了一種對(duì)PROM進(jìn)行程序升級(jí)的方案,該方案簡(jiǎn)單高效,所有功能均在FPGA內(nèi)部實(shí)現(xiàn),硬件上僅需要使用FPGA的4個(gè)I/O口去模擬JTAG接口時(shí)序,實(shí)現(xiàn)對(duì)PROM內(nèi)部的數(shù)據(jù)更新。另外,通信過(guò)程中的幀校驗(yàn)及CRC校驗(yàn),確保了數(shù)據(jù)的正確性及高可靠性。目前該方案已成功應(yīng)用到系列產(chǎn)品上。
評(píng)論
查看更多