馬 盼,林子明
(1.北京全路通信信號(hào)研究設(shè)計(jì)院集團(tuán)有限公司,北京 100070;2.北京市高速鐵路運(yùn)行控制系統(tǒng)工程技術(shù)研究中心,北京 100070)
國內(nèi)對(duì)軌道交通列控系統(tǒng)的研究起步較晚,前期的研究工作主要是引進(jìn)并消化國外成熟的技術(shù),后期研究工作的主要目標(biāo)是在借鑒外國技術(shù)的基礎(chǔ)上形成符合國內(nèi)列車特點(diǎn)的具有自主知識(shí)產(chǎn)權(quán)的軌道交通列控系統(tǒng)[1]。經(jīng)多年技術(shù)積累,已經(jīng)實(shí)現(xiàn)了軌道交通控制系統(tǒng)從系統(tǒng)級(jí)到硬件板卡級(jí)的自主化,并實(shí)現(xiàn)軟件系統(tǒng)自主化,但在底層核心芯片,尤其是專用芯片領(lǐng)域,仍嚴(yán)重依賴進(jìn)口。當(dāng)前,國內(nèi)軌道交通列控系統(tǒng)底層芯片受國外“卡脖子”問題突出,實(shí)現(xiàn)高速鐵路核心技術(shù)體系自主創(chuàng)新成為鐵路人的首要目標(biāo)。
一枚芯片從設(shè)計(jì)開發(fā)到封裝成片會(huì)經(jīng)過一系列的仿真制造流程,傳統(tǒng)的產(chǎn)品“試錯(cuò)式”開發(fā)和“迭代式”開發(fā)不適用于芯片開發(fā)[2],設(shè)計(jì)過程中的設(shè)計(jì)漏洞造成的設(shè)計(jì)缺陷以及后期流片出現(xiàn)的工藝缺陷會(huì)直接影響開發(fā)效率和成本。鐵路專用芯片一般以標(biāo)準(zhǔn)協(xié)議控制芯片或定制數(shù)字芯片為主,隨著芯片規(guī)模和復(fù)雜度的提高,PC 機(jī)在性能和存儲(chǔ)上已不能滿足芯片前端設(shè)計(jì)仿真需求,越來越多的項(xiàng)目會(huì)采用Linux 操作系統(tǒng)服務(wù)器進(jìn)行開發(fā)。為解決以上問題,本文分別從數(shù)字芯片前端設(shè)計(jì)與仿真驗(yàn)證兩個(gè)方面分析開發(fā)環(huán)境的需求,并提出了基于linux 服務(wù)器端構(gòu)建的穩(wěn)定可重用開發(fā)環(huán)境。
為保證芯片功能的正確性,在鐵路專用芯片研發(fā)過程中采用研發(fā)人員異構(gòu)機(jī)制[3],芯片前端設(shè)計(jì)與仿真驗(yàn)證流程如圖1 所示[4]。研發(fā)人員根據(jù)芯片功能需求書共同劃分出功能列表。設(shè)計(jì)人員根據(jù)功能列表確定芯片的目的、效能,進(jìn)行規(guī)格制定后,設(shè)計(jì)芯片細(xì)節(jié),使用硬件描述語言(Verilog,VHDL)將電路描述出來。測試人員則根據(jù)功能列表確定測試目標(biāo)、測試平臺(tái)及工具和測試方法,制定測試規(guī)格后,使用驗(yàn)證語言(SystemVerilog)搭建測試平臺(tái)和測試用例。當(dāng)設(shè)計(jì)代碼完成后,測試人員對(duì)這些代碼進(jìn)行功能仿真驗(yàn)證,檢驗(yàn)代碼實(shí)現(xiàn)與產(chǎn)品需求和設(shè)計(jì)規(guī)格的正確性、完備性和一致性[5]。

圖1 芯片前端設(shè)計(jì)與仿真驗(yàn)證流程Fig.1 IC Chip front-end design and simulation verification process
通常,數(shù)字芯片前端功能設(shè)計(jì)開發(fā)與傳統(tǒng)的數(shù)字系統(tǒng)設(shè)計(jì)不同,是按照自頂向下(top-to-down)設(shè)計(jì)思路規(guī)劃芯片的層次結(jié)構(gòu),再分模塊、分層次地進(jìn)行設(shè)計(jì)描述[6]。首先確定頂層模塊的設(shè)計(jì),然后進(jìn)行子模塊的詳細(xì)設(shè)計(jì),而在子模塊中可以調(diào)用庫中已有的模塊或設(shè)計(jì)過程保留下來的知識(shí)產(chǎn)權(quán)(IP)實(shí)例,最后通過電子設(shè)計(jì)自動(dòng)化(Electronics Design Automation,EDA)工具配合相應(yīng)測試平臺(tái)進(jìn)行層級(jí)編譯和仿真。設(shè)計(jì)開發(fā)過程中代碼文件主要分為3 類,分別為設(shè)計(jì)文件、庫文件和IP 核文件。其中設(shè)計(jì)文件隨仿真驗(yàn)證動(dòng)態(tài)變化,需進(jìn)行代碼版本管理。仿真調(diào)試時(shí)設(shè)計(jì)人員側(cè)重關(guān)注于設(shè)計(jì)代碼的功能邏輯,對(duì)開發(fā)環(huán)境的需求更傾向于簡單的仿真命令、簡便的工具調(diào)用和直觀的仿真結(jié)果。
在數(shù)字芯片前端功能仿真驗(yàn)證中可先對(duì)設(shè)計(jì)代碼進(jìn)行靜態(tài)測試,初步檢查代碼是否符合設(shè)計(jì)規(guī)則,隨后采用動(dòng)態(tài)測試,檢驗(yàn)設(shè)計(jì)邏輯功能是否符合設(shè)計(jì)需求[7]。動(dòng)態(tài)測試是采用不同測試方法(如創(chuàng)建定向測試用例或隨機(jī)測試用例[8])在不同層級(jí)實(shí)現(xiàn)相同的測試目標(biāo),該測試由一系列測試用例驅(qū)動(dòng),這些測試用例通常是面向某些場景的一組約束,為了實(shí)現(xiàn)測試平臺(tái)可重用性,在構(gòu)建測試平臺(tái)時(shí),可將專用測試用例與承載測試用例的通用組件分組管理。仿真調(diào)試后經(jīng)過修改更新的代碼為避免出現(xiàn)已測試通過的用例在當(dāng)前版本不能通過的問題,需要進(jìn)行回歸測試來保證代碼功能的一致性。為提高仿真效率,開發(fā)環(huán)境在滿足設(shè)計(jì)需求的同時(shí)還需滿足從單測試用例到測試用例集的批量仿真。
本文提出的linux 服務(wù)器端可重用開發(fā)環(huán)境,利用目錄與文件樹結(jié)構(gòu)助力研發(fā)人員快速建立設(shè)計(jì)仿真通路,并采用高效的自動(dòng)化腳本實(shí)現(xiàn)啟動(dòng)設(shè)計(jì)仿真中所需要的一系列工具,并對(duì)設(shè)計(jì)的仿真結(jié)果進(jìn)行歸納管理。
如圖2 所示,該環(huán)境中的文件采用目錄樹形結(jié)構(gòu)實(shí)現(xiàn)管理,開發(fā)環(huán)境內(nèi)所有進(jìn)行中的工作及最終交付內(nèi)容位于目錄與文件樹的項(xiàng)目根中,項(xiàng)目主干為當(dāng)前開發(fā)路徑,而設(shè)計(jì)仿真過程的階段性結(jié)點(diǎn)可將代碼版本打標(biāo)簽存于版本管理中。左子樹項(xiàng)目主干下的分支目錄根據(jù)代碼種類和實(shí)現(xiàn)功能的不同,對(duì)代碼文件進(jìn)行了初步分類,其中設(shè)計(jì)組件目錄存放設(shè)計(jì)文件,庫目錄下用來存儲(chǔ)工程所需的庫文件,IP 核目錄下主要存放IP 核生成后綴為.v 文件、.vhd 文件和IP 核生成的網(wǎng)表等文件,設(shè)計(jì)人員可根據(jù)芯片規(guī)格和計(jì)劃存放相應(yīng)文件。

圖2 目錄與文件樹結(jié)構(gòu)Fig.2 Directory and file tree structure
驗(yàn)證組件目錄、測試用例目錄和文件列表目錄組織結(jié)構(gòu)相似,在各自分支下存放著基于模塊級(jí)或芯片級(jí)命名的結(jié)點(diǎn)。驗(yàn)證組件目錄的葉結(jié)點(diǎn)為不隨測試用例變化而變化的通用測試平臺(tái)文件。對(duì)于設(shè)計(jì)人員,測試平臺(tái)文件至少包括頂層文件,對(duì)于驗(yàn)證人員,測試平臺(tái)文件除了頂層文件,還包括驗(yàn)證平臺(tái)中的組件,如接口、驅(qū)動(dòng)和計(jì)分板等。測試用例目錄在結(jié)點(diǎn)模塊級(jí)或芯片級(jí)路徑下存放該級(jí)所有測試用例,每個(gè)測試用例再單獨(dú)建立結(jié)點(diǎn),存放自己的用例文件。文件列表目錄的葉結(jié)點(diǎn)為測試平臺(tái)文件列表、設(shè)計(jì)文件列表、庫列表以及覆蓋率配置列表4 種文件,分別存放著開發(fā)環(huán)境中所有代碼的相對(duì)路徑。
開發(fā)環(huán)境的核心腳本獨(dú)立存于腳本目錄中,用于自動(dòng)加載文件并調(diào)動(dòng)EDA 工具進(jìn)行仿真。仿真執(zhí)行目錄存放著測試用例配置文件和生成文件(Makefile),同時(shí)還存放編譯仿真運(yùn)行工程生成的過程文件以及波形文件等。考慮到芯片后仿真,開發(fā)環(huán)境中增加后端目錄用于建立后端工程。
不同的目錄存放不同代碼,如何將這些代碼調(diào)動(dòng)起來,主要依靠仿真執(zhí)行目錄中的Makefile 和測試用例配置文件及核心腳本。開發(fā)環(huán)境啟動(dòng)流程如圖3 所示,當(dāng)在仿真執(zhí)行目錄輸入make 相關(guān)命令時(shí),開發(fā)環(huán)境啟動(dòng)核心腳本自動(dòng)讀取配置文件,并根據(jù)相應(yīng)測試用例或測試用例集的配置參數(shù)組織好相關(guān)文件進(jìn)行編譯、仿真和調(diào)試,并將生成的日志、波形和覆蓋率等結(jié)果存在仿真目錄下。

圖3 開發(fā)環(huán)境啟動(dòng)流程Fig.3 Development environment start-up process
其中,通過Makefile 命令可以為所有的目標(biāo)文件創(chuàng)建依賴關(guān)系鏈[9],將命令和參數(shù)編號(hào)傳遞給核心腳本,在本文提出的開發(fā)環(huán)境中主要有單測試用例仿真命令、單測試用例調(diào)試命令、測試用例集批量仿真命令和清理文件命令。
開發(fā)環(huán)境中所有層級(jí)的測試用例使用測試用例配置文件來管理,如表1 所示。在配置文件中可對(duì)每一個(gè)測試用例進(jìn)行編號(hào),并指定不同的配置,配置項(xiàng)包括模塊或芯片層級(jí)命名、庫文件包命名、種子類別和相關(guān)編譯參數(shù)等。如表1 中所列測試編號(hào)1 為對(duì)芯片S 輸入測試用例1 的仿真配置,該芯片S 采用55 nm 工藝庫,測試平臺(tái)采用UVM 方法學(xué)自動(dòng)隨機(jī)化測試,并在仿真過程中開啟仿真波形下載和覆蓋率統(tǒng)計(jì)。

表1 測試用例配置文件Tab.1 Test case conf iguration f ile
仿真命令輸入后,核心腳本首先根據(jù)參數(shù)編號(hào)尋找測試用例配置文件中相應(yīng)測試用例或測試用例集,再通過相應(yīng)配置行模塊或芯片層級(jí)命名和庫文件包命名檢測相應(yīng)文件列表是否存在,最后基于命令和編譯參數(shù)調(diào)用EDA 工具,并在仿真目錄中創(chuàng)建所屬測試用例子目錄存儲(chǔ)過程文件。過程文件主要有編譯日志、波形文件、覆蓋率文件及仿真分析記錄。
以SM4 算法模塊[10]在開發(fā)環(huán)境中的設(shè)計(jì)仿真為例,將設(shè)計(jì)與測試相關(guān)文件準(zhǔn)備完畢,并存放于相應(yīng)的目錄位置后,先通過單測試用例仿真命令運(yùn)行測試,得到仿真分析記錄報(bào)告和波形文件,再通過單測試用例調(diào)試命令可調(diào)用如圖4(a)所示的EDA 工具進(jìn)行代碼和波形的調(diào)試。待設(shè)計(jì)進(jìn)入穩(wěn)定階段后,可通過測試用例集批量仿真命令,對(duì)所有測試用例進(jìn)行并行回歸測試后,可以查看如圖4(b)所示的覆蓋率報(bào)告。

圖4 調(diào)試工具與覆蓋率報(bào)告Fig.4 Debugging tools and coverage reports
鐵路專用芯片設(shè)計(jì)開發(fā)過程中存在大量仿真測試尋找漏洞,測試數(shù)據(jù)重復(fù)性高且工作量大,在設(shè)計(jì)進(jìn)入穩(wěn)定階段后,存在大量回歸仿真測試。從仿真測試運(yùn)行時(shí)間來看,如一個(gè)小型的鐵路專用芯片,10 條測試用例串行運(yùn)行時(shí)間可達(dá)252 720.1 s,采用本文開發(fā)環(huán)境并行回歸測試時(shí)間,可降到串行運(yùn)行時(shí)間的10%,大大縮短了仿真測試周期。本文的服務(wù)器端可重用開發(fā)環(huán)境滿足大部分專用鐵路芯片設(shè)計(jì)開發(fā)需求,便于使用、管理和協(xié)同工作,支持從模塊級(jí)到芯片級(jí)、RTL 級(jí)到門級(jí)網(wǎng)表、單測試用例到測試用例集的設(shè)計(jì)與仿真,并在列控、軌道電路、點(diǎn)式設(shè)備、安全計(jì)算機(jī)等多個(gè)系統(tǒng)專用芯片項(xiàng)目中得到驗(yàn)證。該開發(fā)環(huán)境的重用性大大減少了測試環(huán)境的構(gòu)建工作和維護(hù)成本,在保證芯片可靠性同時(shí)提升了開發(fā)效率。