鐵路專用芯片服務器端可重用開發環境的研究

馬 盼，林子明

（1.北京全路通信信號研究設計院集團有限公司，北京 100070；2.北京市高速鐵路運行控制系統工程技術研究中心，北京 100070）

1 概述

國內對軌道交通列控系統的研究起步較晚，前期的研究工作主要是引進并消化國外成熟的技術，后期研究工作的主要目標是在借鑒外國技術的基礎上形成符合國內列車特點的具有自主知識產權的軌道交通列控系統[1]。經多年技術積累，已經實現了軌道交通控制系統從系統級到硬件板卡級的自主化，并實現軟件系統自主化，但在底層核心芯片，尤其是專用芯片領域，仍嚴重依賴進口。當前，國內軌道交通列控系統底層芯片受國外“卡脖子”問題突出，實現高速鐵路核心技術體系自主創新成為鐵路人的首要目標。

一枚芯片從設計開發到封裝成片會經過一系列的仿真制造流程，傳統的產品“試錯式”開發和“迭代式”開發不適用于芯片開發[2]，設計過程中的設計漏洞造成的設計缺陷以及后期流片出現的工藝缺陷會直接影響開發效率和成本。鐵路專用芯片一般以標準協議控制芯片或定制數字芯片為主，隨著芯片規模和復雜度的提高，PC 機在性能和存儲上已不能滿足芯片前端設計仿真需求，越來越多的項目會采用Linux 操作系統服務器進行開發。為解決以上問題，本文分別從數字芯片前端設計與仿真驗證兩個方面分析開發環境的需求，并提出了基于linux 服務器端構建的穩定可重用開發環境。

2 芯片設計與仿真測試對開發環境的需求

為保證芯片功能的正確性，在鐵路專用芯片研發過程中采用研發人員異構機制[3]，芯片前端設計與仿真驗證流程如圖1 所示[4]。研發人員根據芯片功能需求書共同劃分出功能列表。設計人員根據功能列表確定芯片的目的、效能，進行規格制定后，設計芯片細節，使用硬件描述語言(Verilog，VHDL)將電路描述出來。測試人員則根據功能列表確定測試目標、測試平臺及工具和測試方法，制定測試規格后，使用驗證語言(SystemVerilog)搭建測試平臺和測試用例。當設計代碼完成后，測試人員對這些代碼進行功能仿真驗證，檢驗代碼實現與產品需求和設計規格的正確性、完備性和一致性[5]。

圖1 芯片前端設計與仿真驗證流程Fig.1 IC Chip front-end design and simulation verification process

2.1 設計環境需求

通常，數字芯片前端功能設計開發與傳統的數字系統設計不同，是按照自頂向下（top-to-down）設計思路規劃芯片的層次結構，再分模塊、分層次地進行設計描述[6]。首先確定頂層模塊的設計，然后進行子模塊的詳細設計，而在子模塊中可以調用庫中已有的模塊或設計過程保留下來的知識產權（IP）實例，最后通過電子設計自動化（Electronics Design Automation，EDA）工具配合相應測試平臺進行層級編譯和仿真。設計開發過程中代碼文件主要分為3 類，分別為設計文件、庫文件和IP 核文件。其中設計文件隨仿真驗證動態變化，需進行代碼版本管理。仿真調試時設計人員側重關注于設計代碼的功能邏輯，對開發環境的需求更傾向于簡單的仿真命令、簡便的工具調用和直觀的仿真結果。

2.2 仿真環境需求

在數字芯片前端功能仿真驗證中可先對設計代碼進行靜態測試，初步檢查代碼是否符合設計規則，隨后采用動態測試，檢驗設計邏輯功能是否符合設計需求[7]。動態測試是采用不同測試方法（如創建定向測試用例或隨機測試用例[8]）在不同層級實現相同的測試目標，該測試由一系列測試用例驅動，這些測試用例通常是面向某些場景的一組約束，為了實現測試平臺可重用性，在構建測試平臺時，可將專用測試用例與承載測試用例的通用組件分組管理。仿真調試后經過修改更新的代碼為避免出現已測試通過的用例在當前版本不能通過的問題，需要進行回歸測試來保證代碼功能的一致性。為提高仿真效率，開發環境在滿足設計需求的同時還需滿足從單測試用例到測試用例集的批量仿真。

3 開發環境設計結構

本文提出的linux 服務器端可重用開發環境，利用目錄與文件樹結構助力研發人員快速建立設計仿真通路，并采用高效的自動化腳本實現啟動設計仿真中所需要的一系列工具，并對設計的仿真結果進行歸納管理。

如圖2 所示，該環境中的文件采用目錄樹形結構實現管理，開發環境內所有進行中的工作及最終交付內容位于目錄與文件樹的項目根中，項目主干為當前開發路徑，而設計仿真過程的階段性結點可將代碼版本打標簽存于版本管理中。左子樹項目主干下的分支目錄根據代碼種類和實現功能的不同，對代碼文件進行了初步分類，其中設計組件目錄存放設計文件，庫目錄下用來存儲工程所需的庫文件，IP 核目錄下主要存放IP 核生成后綴為.v 文件、.vhd 文件和IP 核生成的網表等文件，設計人員可根據芯片規格和計劃存放相應文件。

圖2 目錄與文件樹結構Fig.2 Directory and file tree structure

驗證組件目錄、測試用例目錄和文件列表目錄組織結構相似，在各自分支下存放著基于模塊級或芯片級命名的結點。驗證組件目錄的葉結點為不隨測試用例變化而變化的通用測試平臺文件。對于設計人員，測試平臺文件至少包括頂層文件，對于驗證人員，測試平臺文件除了頂層文件，還包括驗證平臺中的組件，如接口、驅動和計分板等。測試用例目錄在結點模塊級或芯片級路徑下存放該級所有測試用例，每個測試用例再單獨建立結點，存放自己的用例文件。文件列表目錄的葉結點為測試平臺文件列表、設計文件列表、庫列表以及覆蓋率配置列表4 種文件，分別存放著開發環境中所有代碼的相對路徑。

開發環境的核心腳本獨立存于腳本目錄中，用于自動加載文件并調動EDA 工具進行仿真。仿真執行目錄存放著測試用例配置文件和生成文件（Makefile)，同時還存放編譯仿真運行工程生成的過程文件以及波形文件等。考慮到芯片后仿真，開發環境中增加后端目錄用于建立后端工程。

4 開發環境啟動與應用

不同的目錄存放不同代碼，如何將這些代碼調動起來，主要依靠仿真執行目錄中的Makefile 和測試用例配置文件及核心腳本。開發環境啟動流程如圖3 所示，當在仿真執行目錄輸入make 相關命令時，開發環境啟動核心腳本自動讀取配置文件，并根據相應測試用例或測試用例集的配置參數組織好相關文件進行編譯、仿真和調試，并將生成的日志、波形和覆蓋率等結果存在仿真目錄下。

圖3 開發環境啟動流程Fig.3 Development environment start-up process

其中，通過Makefile 命令可以為所有的目標文件創建依賴關系鏈[9],將命令和參數編號傳遞給核心腳本，在本文提出的開發環境中主要有單測試用例仿真命令、單測試用例調試命令、測試用例集批量仿真命令和清理文件命令。

開發環境中所有層級的測試用例使用測試用例配置文件來管理，如表1 所示。在配置文件中可對每一個測試用例進行編號，并指定不同的配置，配置項包括模塊或芯片層級命名、庫文件包命名、種子類別和相關編譯參數等。如表1 中所列測試編號1 為對芯片S 輸入測試用例1 的仿真配置，該芯片S 采用55 nm 工藝庫，測試平臺采用UVM 方法學自動隨機化測試，并在仿真過程中開啟仿真波形下載和覆蓋率統計。

表1 測試用例配置文件Tab.1 Test case conf iguration f ile

仿真命令輸入后，核心腳本首先根據參數編號尋找測試用例配置文件中相應測試用例或測試用例集，再通過相應配置行模塊或芯片層級命名和庫文件包命名檢測相應文件列表是否存在，最后基于命令和編譯參數調用EDA 工具，并在仿真目錄中創建所屬測試用例子目錄存儲過程文件。過程文件主要有編譯日志、波形文件、覆蓋率文件及仿真分析記錄。

以SM4 算法模塊[10]在開發環境中的設計仿真為例，將設計與測試相關文件準備完畢，并存放于相應的目錄位置后，先通過單測試用例仿真命令運行測試，得到仿真分析記錄報告和波形文件，再通過單測試用例調試命令可調用如圖4(a)所示的EDA 工具進行代碼和波形的調試。待設計進入穩定階段后，可通過測試用例集批量仿真命令，對所有測試用例進行并行回歸測試后，可以查看如圖4(b)所示的覆蓋率報告。

圖4 調試工具與覆蓋率報告Fig.4 Debugging tools and coverage reports

5 總結

鐵路專用芯片設計開發過程中存在大量仿真測試尋找漏洞，測試數據重復性高且工作量大，在設計進入穩定階段后，存在大量回歸仿真測試。從仿真測試運行時間來看，如一個小型的鐵路專用芯片，10 條測試用例串行運行時間可達252 720.1 s，采用本文開發環境并行回歸測試時間，可降到串行運行時間的10%，大大縮短了仿真測試周期。本文的服務器端可重用開發環境滿足大部分專用鐵路芯片設計開發需求，便于使用、管理和協同工作，支持從模塊級到芯片級、RTL 級到門級網表、單測試用例到測試用例集的設計與仿真，并在列控、軌道電路、點式設備、安全計算機等多個系統專用芯片項目中得到驗證。該開發環境的重用性大大減少了測試環境的構建工作和維護成本，在保證芯片可靠性同時提升了開發效率。