實時計算機系統結構綜述

龔小航 蔣濱澤 陳香蘭 高銀康 李曦

（中國科學技術大學計算機科學與技術學院 合肥 230027）

（中國科學技術大學蘇州高等研究院 江蘇蘇州 215123）

實時嵌入式系統幾乎存在于任何環境中，諸如汽車、航空電子設備和電信等領域都可以找到大量的實時嵌入式系統.在實時系統中，系統的正確性不僅取決于其邏輯行為，還取決于執行計算的時間.

任務對時間的敏感程度不同，可區分為軟實時（soft real-time，SRT）任務和 硬實時（hard real-time，HRT）任務.在軟實時系統和硬實時系統中，應用通常實現為與時間約束相關的實時任務的集合，并根據選定的調度算法調度.但是，在硬實時應用（如緊急救援行動）中，違背時間限制或錯失最后期限可能會造成不可估量的災難性損失；而在軟實時應用中，錯失最后期限只會導致系統提供的服務質量（quality of service，QoS）下降.因此，為了提供正確的行為和良好的QoS，實時嵌入式應用程序的設計必須始終滿足其最后期限.

對實時系統的研究與對通用計算機系統的研究幾乎同時開始[1]，但與通用系統基于圖靈完備性迅速發展相反的是，實時系統研究發展緩慢.主流通用計算到目前為止還沒有充分認識到與時間可預測性相關的挑戰[2].在通用計算快速發展的影響下，實時系統的研究者往往直接采用通用計算機系統各個層次（體系結構、編譯器、編程語言等）的技術來完成設計.在通用系統中設計可預測的分析是具有挑戰性的，因為時間需求在系統層次結構中向下傳遞，意味著必須預見系統所有部分的時間屬性：處理器和指令集架構、語言和編譯器支持、軟件設計、運行時系統和調度、通信基礎設施等.隨著現代處理器性能提高的趨勢，為了提高通用計算系統的性能、生產力和提高程序吞吐量或執行效率，引入的體系結構元素，如流水線、無序執行、片上內存系統等，導致了系統執行中很大程度的不確定性，這些因素都讓提供時間保證變得更加困難.現代通用處理器引入了大量的體系結構優化和多個軟件抽象層，以時序的巨大可變性為代價來提供高性能的系統.如果保證最后期限是一個關鍵目標，時間的不可預測性就使部署這些系統變得非常麻煩.以此方法設計的系統的時序軟硬件緊密相關，無法進行層次化設計，部署前需要進行大量的驗證和測試工作，且一點微小的改動或升級都將影響系統的安全性.

學界對實時系統的許多基礎概念、定義都沒有共識.例如在對實時系統的理解上，Roop[3]認為實時系統即為反應式系統，實時性體現為系統確定的響應能力，希望通過在指令集中增加同步語義來直接支持執行同步語言程序，并提出基于C 語言擴展的PRET-C 同步語言，及支持PRET-C 同步語義的微體系結構ARPRET[4]；Lee 等人[5]認為實時性體現在操作的定時執行上，提出了精確計時（precision timed，PRET）機并在ISA 層面擴展了時間操作指令，以DU（delay until）原語控制過早問題，并采用EE（exception on expired）原語通過異常處理而響應過晚錯誤.

典型的嵌入式系統結構如圖1 所示.最上層為實現嵌入式系統功能的應用程序，由實時操作系統（RTOS）等軟件層應用提供實時性支持；中間層位于軟硬件之間，為軟件層提供硬件抽象；硬件層包括嵌入式微處理器、I/O、通用接口、人機交互接口等.

Fig.1 Architecture of real-time embedded system圖 1 實時嵌入式系統架構

實時應用程序提出對時間屬性、時間語義的要求.我們可以在軟件層、中間層或硬件層支持這些需求.表1 列出了在不同層次實現時間語義的對比.

圖2 展示了實時系統各個方面的研究工作.傳統實時系統設計方法存在脆弱性、冗余和平臺依賴3個問題（將在第2 節討論）.實時領域的研究工作大多針對單一軟硬件平臺，研究成果難以整合，導致對實時系統的研究在工業界與學術界脫鉤，不同研究者也難以復現彼此工作，因此難以深刻認識各自工作的價值.實時系統的研究相較于其他領域需要更深的積累、更長的周期，需要自行搭建自編程語言到硬件的研究平臺.

Table 1 Comparison of Time Semantics Supported by Each Layer of Embedded System表 1 嵌入式系統各層支持時間語義對比

更有甚者，由于實時系統面臨安全關鍵的問題，而軟硬件平臺又沒有很好的抽象，導致系統即使需要微小的升級，也需要重新開始整個設計周期，導致大量的人力物力浪費.

Fig.2 Research work on various aspects of real-time systems圖 2 實時系統各方面的研究工作

本文介紹了實時系統在系統結構方面發展遇到的主要問題，著重比較了PRET 機[5]和我們之前提出的實時處理單元（real-time processing unit，RPU）[6]及在其基礎上擴展的實時計算系統（real-time system，RTS）.本文的主要內容包括3 方面：

1）簡要介紹了實時系統的相關概念、需求、發展現狀以及挑戰.

2）實時系統在應用層、指令集架構（instruction set architecture，ISA）層、硬件層的需求，遇到的問題以及現有的解決方法，并著重比較了PRET 和RPU這2 套解決方案.

3）實時系統的未來發展方向與主要挑戰.

1 研究背景與問題描述

本節闡述實時計算的相關概念、發展中遇到的問題并簡述現有的解決思路.

1.1 實時計算與時間屬性

實時計算系統的設計是為了滿足實時的最后期限要求.實時系統對時間敏感，一般應用在特定的應用領域，如航空設備、汽車部件和宇航領域等.

對實時系統的研究幾乎與對通用計算系統的研究同時開始.早在1947 年，MIT 在 Whirlwind[1]中引入了當時先進的實時系統概念，用于控制飛行模擬器.與基于圖靈完備性理論和馮·諾依曼體系結構定義而迅速發展的通用計算系統相比，對實時系統的研究卻進展緩慢.目前學術界和工業界對于實時系統最基礎的概念、定義都還未有規范統一的定論.例如“什么是實時？”都還未有一致的共識.一方面，實時系統屬于多學科交叉領域，來自不同領域的研究者很自然地對同樣的系統有不同的觀察視角.另一方面，實時系統囊括內容廣泛，常有人用其表示某一類具體的實時系統.因此，在不同的上下文中，實時系統常有不同的含義.1988 年，Stankovic[7]指出，很多人認為實時計算僅僅是指對速度要求快一點的計算.而直到 2018 年，Lee[8]仍然強調，在實踐中，當工程師談到“實時”時，他們可能會想表達：1）高速計算；2）優先級調度；3）流數據上的實時計算；4）有界執行時間；5）程序的時間語義；6）網絡的時間語義.

一般情況下，研究者從系統的邏輯正確性和時間正確性這2 個方面定義實時系統[5,9-10]，實時系統定義為系統的正確性不僅取決于系統產生的結果（邏輯正確性），而且取決于這些結果產生的時間（時間正確性）.

本文認為，實時性體現在計算系統的多個方面，從軟件應用層到ISA，再到底層硬件，實時性無處不在.為了清楚地說明什么是實時性，必須對這一概念進行詳細地描述與定義.因此，本文從軟件和硬件2個方面描述當前學術界對于實時性的研究背景.

在軟件方面，實時性體現在實時計算程序的時間屬性上，Lee[8]總結了多種對實時性的定義：快速計算、優先調度、對流數據的計算、有界執行時間、程序的時間語義等.本文認為，根據實時計算的應用場景，實時性是一種來自軟件應用層的對時間屬性的需求，這種需求即為應用程序的時間語義.

硬件上對實時性的概念也來自于應用軟件對時間語義的需求.因為超標量等技術在處理器平均性能上的過度開發，單獨一條指令的執行時間變得難以預測，從而硬件難以表達來自程序的時間語義.鑒于此，硬件上對實時性的描述聚焦于對硬件執行程序時間的可預測性.

值得注意的是，“可預測性”是一個很容易混淆的概念：一方面，它可以代表對一個硬件的時間屬性分析（如最壞情況執行時間（worst case execution time，WCET）分析）結果的準確程度（即理論分析得到的執行時間界限與實際執行時間界限的差距）.另一方面，“可預測性”也可以代表著程序實際執行時間的變化程度，相對應地，越小的變化程度對應著越好的可預測性.這2 種概念在學術界均被廣泛地采用，如Thiele等人[11]和Kirner 等人[12]分別使用了形式化的方法來描述這2 種時間可預測性.

1.2 實時計算系統發展面臨的問題

隨著實時嵌入式應用程序對處理能力的要求更高，多核架構，如對稱多處理（SMP），也被用于實時嵌入式系統領域.因為多核平臺的低成本以及其特性的發展和集成便于滿足實時計算系統的需求.例如，在汽車環境中，“自動緊急斷開”和“夜視輔助”等新的安全功能必須讀取和融合來自傳感器的數據，處理視頻流，并在實時約束條件下檢測到道路上的障礙物時發出警告.這是一個典型的場景，對高級特性的需求不斷增加，導致對額外計算能力的需求成比例地增加.此外，系統功能的增加決定了電力消耗、散熱和空間占用（如布線）方面的額外成本[13].因此，多核處理器是降低上述成本的一種經濟有效的解決方案，因為額外的計算需求可以分配到單個處理單元，而不是分散在車輛上的多個處理單元.

然而，在不斷引入新技術提高性能的同時，處理器等硬件設備的執行時間逐漸地缺少時間可預測性，抑或是變得難以分析.這導致現代實時計算系統開發往往需要耗費大量的人力物力在硬件的“驗證—糾錯—重新設計”流程上.因為硬件設計上一個微小的變化經常會導致時序的巨大改變，為了保證設計出的硬件系統能夠滿足實時系統的時間與要求，需要通過對硬件的時序進行嚴格的建模與分析，但這一過程的代價是巨大的.為了解決這一困境，提高生產效率，業界也提出了許多解決方案，如：采用有大量冗余性能的硬件、使用傳統的簡單而易于驗證的設計、執行時間分析、實時操作系統等.本文接下來會簡要介紹其中幾種解決方案并將它們進行對比，著重介紹現代工業界常用的WCET 分析方法，進一步指出導致實時系統設計困難的關鍵問題.

1.3 現有的解決思路及其優劣

一種最簡單的平衡實時計算系統對實時性和性能需求的方式就是采用高性能的硬件，但是這樣做的效果并不好，原因很簡單：這樣做大大增加了生產所需的成本，即使采用高性能硬件，也無法驗證程序運行時所需的時間語義是否可以滿足，因為傳統高性能硬件從未考慮過程序的時間語義.

另一個極端就是使用傳統且簡單的硬件設計，因為它們的硬件結構足夠簡單，在其基礎上的驗證與分析變得非常容易.然而，這樣做只能滿足一些小型工業設備的生產設計要求，對于同時需要高性能與時間語義的復雜實時計算系統，過于簡單的硬件無法勝任.

執行時間分析是一種相較而言成熟的解決方案，一般來說，實時系統滿足其最后期限的能力是通過可調度性分析來驗證的[14].所有此類可調度性分析技術都有一個基本的假設，即每個任務的WCET 的上限是已知的.然而，在任務WCET 上導出安全而嚴格的邊界正變得越來越困難.在多核架構上尤其如此，因為處理器或核心共享硬件資源，例如緩存內存層次結構、總線、DRAM 和I/O 外設.因此，由一個處理單元執行的操作可能導致在任何共享資源級別上不受管制的爭用，從而不可預測地延遲在不同核心上運行任務的執行.

實時系統緩存管理方案的主要目標是簡化任務的WCET 估計.WCET 估計通常遵循2 種主要方法之一：靜態分析或經驗測量.在靜態分析方法中，分析工具試圖通過分析應用程序二進制代碼來提供WCET，而不直接在硬件上執行它.一般來說，WCET估計工具只適用于簡單的處理器，這是由于復雜的硬件特性，如緩存、分支預測器和流水線等，使得靜態分析極其困難或過于悲觀[15].在后一種方法中，應用程序二進制代碼在硬件平臺上執行多次，并從這些執行中提取具有可調置信值的WCET 估計.此外，在基于度量的方法中，為了考慮可能由于延遲執行的未觀察到的條件，WCET 的結果值通常會進一步增加一個誤差范圍（觀測值的20%～30%）.因此，基于度量的方法也可能導致高估WCET.緩存的使用使得靜態和基于測量的WCET 估計更加復雜，因為指令的執行時間可能會根據：

1）數據/指令在內存層次結構中的位置；

2）存儲器的存取導致任何緩存層的缺失或命中；

3）正在使用的緩存一致性協議；

4）緩存控制器上實現的緩存替換策略而變化[16].

雖然已經有人為單核系統提出了多種實時緩存分析框架[15]，但目前的靜態分析方法對共享緩存的失效提供了悲觀的上界.此外，據我們所知，沒有現有的靜態分析技術能夠解釋一致性協議的影響.總而言之，硬件設計上的復雜性會導致WCET 分析結果不緊致，從而根據WCET 分析得出的硬件性能需求往往會比實際高得多.

在軟件層面，RTOS 提供計時功能，但RTOS 提供的計時行為不精確，且在復雜系統中不可控.軟件抽象時間屬性將在計時精度上損失若干個數量級.硬件的中斷行為一般需要納秒級的計時精度，而軟件實現在用戶級可能只能達到毫秒級，對于部分實時程序，這一量級遠遠超出了可接受的范圍.

目前實時系統的挑戰在于兼顧性能和實時性.如果愿意放棄性能，那么精確的計時可以很容易實現.相反地，如果注重性能，那么很難在現有的高性能設計基礎上繼續保證硬件有良好的時間可預測性.現代處理器架構使WCET 分析變得相當困難，即使是分析簡單的程序也需要付出巨大的努力.從根本上說，通用處理器的中間層ISA 和硬件層未能提供足夠的抽象，即計算機體系結構的ISA 層缺乏對時間語義的描述，硬件層缺少對時間語義的支持.

1.4 基于ISA 層引入時間語義的解決方案

相較于在軟件層面實現實時性產生的巨大開銷和挑戰，以及使用時間可預測、可重復的硬件帶來的設計、應用成本花費，在中間層ISA 引入時間屬性、設計時間語義是有潛力的研究方向.

針對ISA 層缺乏時間語義的問題，目前已經有若干解決方案.通常，這類工作依賴于系統中子組件之間的強制時間隔離：1 個子組件的執行時間不應該依賴于其他子組件的行為.這種隔離可以：

1）在單個任務級別實現，其中子組件是任務代碼中的功能或基本塊；

2）在核心一級，其子組成部分是任務；

3）在多核系統級別，子組件是單獨的核心或運行在每個核心上的軟件分區.

具體工作將在本文第3 節闡述.目前現有的解決方案主要有2007 年始由Lee 等人[5]提出精確計時機PRET，和我們實驗室提出的實時處理單元RPU 及在其基礎上擴展的實時計算系統RTS.本文著重介紹與比較PRET 和RPU 這2 種解決方案，它們均在ISA 層引入時間語義來嘗試解決性能和實時性之間產生的沖突.

1.4.1 精確計時機PRET

來自UC Berkley 的Lee 等人提出的精確時序機器PRET 共包含3 個版本.其中，第1 個版本僅僅是一個基于SPARC 的處理器模型[17]，該模型用來在前期論證硬件多線程、scratchpad memory 以及對主存的調度訪問在PRET 中實現的可行性.第2 個版本，又稱之為PTARM[18]，是一個在FPGA 上實現的基于ARM 指令集擴展的硬件多線程處理器，對該處理器的測試表明，其在應用程序中具有足夠的并發性，實現可重復的時序行為并不需要以過多的性能為代價.在該版處理器的實現中，Reineke 等人[19]同時證明了DRAM 存儲的訪問延遲的不確定性可以通過按照DRAM 設備的內部結構劃分物理地址空間，并交錯訪問分區中的塊來解決.第3 代PRET 機器，又名FlexPRET[20]，是一個基于開源RISC-V 指令集的硬件多線程處理器.相較于第2 版，FlexPRET 的特別之處在于它的硬件線程數是可變的.FlexPRET 既可以只配置一個硬件線程，像一個普通的RISC-V 處理器一樣執行，也可以配置數個硬實時線程來保證任務執行時有確定的時序.除此之外，FlexPRET 還支持混合優先級任務調度，通過調度硬實時線程以及軟實時線程，FlexPRET 可以最大化利用處理器的資源.

所有PRET 機器都是細粒度多線程處理器，其中PTARM 和FlexPRET 均使用多線程在流水線中交錯執行的方式來實現線程之間的硬件隔離，從而每個線程的執行時序都獨立于其他線程而不會受影響.為了精確表達與控制任務的時間屬性，PRET 機器都在各自的指令集上進行了指令擴展，在指令集架構層引入時間語義，實現從軟件到硬件的時間語義表達的一致性這樣一種自上而下的解決方案.

1.4.2 實時處理單元RPU

RPU[6]是中國科學技術大學高能效智能計算實驗室所提出的一個實時硬件多線程處理器項目.其中第1 版RPU（RPU1.0）是一個基于RISC-V 整形指令集的粗粒度硬件多線程處理器，并額外支持時間語義指令集（time triggered instruction，TTI）擴 展.RPU1.0 通過粗粒度多線程切換的方式隱藏處理器運行時的長時延問題（如DRAM 訪存等），從而提高處理器資源利用率，間接地提高性能.除此之外，RPU1.0 針對LET 應用模型的要求，通過TTI 中的線程控制指令來嚴格控制線程的執行時間，并通過定時I/O 指令來實現精確的輸入輸出控制.

RPU2.0 是在RPU1.0 基礎之上實現的一個細粒度硬件多線程處理器，與RPU1.0 不同的是，RPU2.0為每個硬件線程都配置了一套寄存器、PC、流水段間寄存器等部件，從而實現每個硬件線程之間的隔離以及線程之間的無縫切換.通過這種方式，RPU2.0可以獨立地對每個線程進行時序分析，減少線程之間的干擾.線程調度采用可動態配置的循環調度方式，每個線程可以自由配置執行時長等參數，處理器嚴格按照調度執行各個線程，從而保證線程執行的時序，在每個線程內，線程還可以使用TTI 來實現精確定時的I/O 操作.

2 應用、軟件層級的實時性

本節介紹實時應用在通用的傳統體系結構上實現的方法技術.

2.1 應用的時間需求

實時計算系統所面向的應用場景相當廣泛，從航空航天到汽車控制系統、醫用設備，以及高精度工業控制設備方面都有廣泛的應用.這些應用都需要實時地與外界物理環境進行交互，這不僅需要實時計算系統的操作邏輯正確，還需要其操作能夠滿足一定的時間約束，即應用的時間語義.顯然，為了盡可能地滿足應用的時間需求，需要明確在這些應用場景下有哪些時間語義需要表達.

在響應式系統（reactive systems）[21]中，系統需要在有限的時間內根據外界的輸入進行快速計算并輸出結果.這類系統在實際生產中的常見應用往往是一些安全攸關（safety critical）的應用，如汽車剎車系統、醫療電子控制系統、核電站控制系統等.這些系統需要保證程序能夠在給定的時間內完成執行，否則會帶來災難性的后果.從這點來說，它們的時間需求聚焦于程序的WCET 是可分析的，且往往要求WCET 的變化范圍小于某一特定的值.

在交互式系統（interactive system）[22]中，系統以一定的頻率和外界環境進行交互（通常按照環境的步調持續地與其進行交互），這一交互往往需要和其他組件同步（synchronize）.比如在時分復用的實時通信系統中，計算結果的輸入和輸出需要和通信時對應的時間片同步.在這種情況下，系統的時間需求注重系統輸入/輸出的時刻需要和外界精確同步，更進一步地來說，這一過程可能還具有周期性.

此外，在現代的工業生產設計中，一種系統可能具有多種不同優先級的任務，即混合關鍵系統（mixed criticality systems，MCS）[22]，在這種系統中，有著不同優先級的任務在同一個硬件平臺上共享執行資源.在實時系統中，高優先級任務往往有較強的時間語義，低優先級任務可能有較弱甚至不具備時間語義.在這種情況下，實時系統往往需要進行合理的調度來保證高優先級任務的時間語義被優先保證.

2.2 實時操作系統

實時應用程序在軟件層面通用的解決方法是在傳統結構上運行實時操作系統（real time operating system，RTOS）.傳統計算機系統的層次結構中，體系結構層次以“指令”作為最基礎的單元，而操作系統通過外部中斷的協助對“指令”流進行管理和封裝，為上層提供豐富的服務.在實時領域的研究過程中，出現一批實時操作系統，如μCOS[23]，FreeRTOS[24]，RTEMS[25]等.它們基于傳統的操作系統和實時調度算法，提供具有一定時間語義的任務模型接口.然而，在這種方式下，操作系統更像是編程語言配套的實時庫，既要保證實時應用的時間屬性，仍然需要用戶結合實時應用和體系結構進行設計和調整.這些“實時操作系統”仍未突破傳統計算機系統的層次結構，其實際效果也具有一定的局限性.

在時間精度方面，實時操作系統基于內核服務提供時間延遲和超時.如FreeRTOS 用32 位寄存器保存定時器中斷的計數值，在常見的嵌入式設備（例如STM32F429 開發板）上時鐘精度約為50 μs，比硬件運行的納秒級別的時鐘周期高約3 個數量級.另一方面，RTOS 按預定的調度策略調度任務執行.RTOS 通常支持優先級搶占或時間片輪轉（round-robin，RR）這2種基本任務調度機制，由于在軟件層面切換任務帶來的大量開銷，RTOS 提供的快速任務搶占耗時一般達到毫秒級（相較于通用系統的非搶占內核，最壞情況為秒級）[26].

在提供的服務方面，典型的RTOS 采用微內核（micro kernel）體系結構[27]，其內核只提供最基本的系統服務（如任務調度和管理），其他服務位于內核外，需要根據應用需求單獨裁剪配置；且由于狀態切換帶來的大量開銷，對時間敏感的嵌入式系統可能不區分用戶態和內核態，應用程序之間的隔離性較弱.

2.3 最壞情況執行時間（WCET）分析

WCET 分析始終是一項富有挑戰性的工作[15].因為程序流分析是一個不可判定問題，需要描述清楚，對一個在某個系統上運行的程序進行WCET 分析，需要對這個系統的每個細節，包括流水線、存儲系統以及執行結構進行建模.現有的先進WCET 工具有AbsInt 的aiT 工具，該工具曾被用在空客A380 的安全攸關的軟件系統的分析中[17].除此之外，還有Otawa 以及Chronos 等工具.

此外，說明WCET 工具的有效性也是件困難的工作，W?gemann 等人[28]提出GenE 工具來評估WCET分析器的有效性，GenE 可以生成一系列已知流圖的程序測試用例，從而通過對比WCET 分析工具在其上的分析結果與已知流圖的分析結果可以判斷WCET 分析結果的有效性.令人遺憾的是，GenE 發現了aiT 工具在ARM Cortex-M4 處理器的建模下分析出的WCET 并不正確[17]：aiT 分析出的WCET 結果小于程序的實際執行時間.這說明針對復雜的系統設計，建模必須格外小心，否則WCET 結果難以和實際的系統設計保持一致.更進一步地，正如W?gemann等人[28]提到的：“最精確的執行時間模型就是處理器設計本身”，因為建模的過程不可避免地會發生錯誤.

WCET 分析的經驗表明單單依靠分析工具來保證實時性并不可靠.針對這種困境，目前有一種觀點認為應當通過在程序執行的更低層次引入時間語義來提供程序執行時間的抽象表述，從而簡化WCET分析，保證應用的實時性.

2.4 編譯器保證的代碼段執行時間上界

傳統編譯器只聚焦于提高代碼的平均性能，且無需知曉程序執行的硬件架構是怎么樣的.在實時程序的設計中，這2 點都發生了很大的改變.編譯器層面變為著重于對程序WCET 的優化[29]，且這一過程是架構相關的，即編譯器至少需要底層硬件執行指令時的時序相關的信息才能進行有效的WCET分析.

Broman 等人[30]在PRET 的設計過程中為這些問題提出了一種解決方案.針對編譯器過于依賴底層硬件實現的問題，Broman 等人[30]認為，編譯器對于底層硬件的信息需求是必不可少的，但是可以通過參數化描述底層硬件架構的方式來增強編譯出的目標代碼的可移植性.因此，可以使用體系結構描述語言（architecture description language，ADL），比如EXPRESSION[31]，來參數化描述硬件架構，從而為編譯器增加對硬件的時間行為的描述，減少對硬件架構的依賴，增強目標代碼的可移植性.

編譯器為了保證代碼執行時間的上界，除了需要硬件架構的時序信息之外，還需要對程序本身進行WCET 分析，PRET 小組使用MTFD 指令來對程序塊的執行時間進行約束[18]，并將這一約束信息傳遞給PRET 編譯器.編譯器通過對程序中被MTFD 約束的代碼塊進行WCET 分析，來判斷約束是否被滿足.

PRET 小組在設計的過程中還提到了編譯器的一個額外任務，即程序內存空間分配的工作.在PRET 機器中，實時程序的代碼和數據被放在一塊名為便簽存儲器（scratchpad memory，SPM）[32]的部件中執行，SPM 可以快速地響應數據請求且其響應時間是可預測的，因為實時程序不能忍受訪問如DDR 主存時的抖動巨大的響應時間.但SPM 必須顯式管理、手動分配，這就需要編譯器知曉SPM 在內存中的位置，并主動將實時程序的代碼與數據分配到SPM 中.

總而言之，實時程序的編譯器相較于傳統的編譯器（如C 編譯器），承擔了許多額外的工作來保證代碼段執行時的時間屬性，包括WCET 分析、硬件時序分析、內存空間管理等，對支持實時程序的編譯器的開發仍將會是一項富有挑戰性的工作.

2.5 本節小結

傳統的實時系統設計方法基于通用計算系統，關注計算過程的時序可預測性，通過設計階段進行時序分析來滿足系統的時間約束.

很久以來，程序的“正確”執行從未考慮時間.計算的所有抽象層次都未曾提供時間屬性.指令集體系結構不能保證時間屬性；沒有通用的語言有時間語義的表示；實時操作系統由于并發等因素不能保證時間語義屬性；現有的網絡架構也沒有時間語義屬性[5].這導致實時系統設計方法始終無法擺脫3 個問題：

1）脆弱性.表現為在實時系統中即使是一個微小的改變或“改進”也可能會導致嚴重的時序紊亂，需要重新驗證實時性是否得到保證，甚至重新設計.

2）冗余.體現在實時系統的設計往往需要預留多余的時間或計算資源以保證系統的正確性.

3）平臺依賴.體現在實時系統設計依賴其使用的軟硬件平臺、系統時序與平臺綁定.

傳統的實時系統設計方法往往通過投入大量的人力物力來解決這些問題.然而，當今社會的實時需求日益復雜，對敏捷設計的要求也在逐步凸顯，實時系統急需新的高可用、高易用的設計方法.

3 ISA 級的系統實時性

計算機科學領域的時間概念相當原始.圖靈機和馮·諾依曼機模型基于順序控制抽象，指令一條接一條地執行，時間先后關系（temporal succession）是當前機器語言級唯一可用的時序關系.雖然定義馮·諾依曼機的程序邏輯行為無需顯式地引用量化時間概念，但無法滿足實時系統的時間約束.

由于傳統的計算機體系結構模型缺乏時間語義，早期的實時系統設計者不得不把具有時間語義的程序運行在不具有時間語義的體系結構上.萊斯定理[33]指出，程序所有非平凡的語義屬性都是不確定的.這意味著在基于缺乏時間語義的體系結構模型設計的處理器上，難以確定性地運行時間語義程序.只有在體系結構模型中加入時間語義，結合具有時間語義的指令集設計實時處理器，才能保證時間關鍵應用的運行時確定性（PRET 研究組將這個特性稱為時間可重復性）.

3.1 將時間作為關鍵因素編程

雖然一些實時系統建模語言（Timed C 等）中包含了時間概念，但實現語言，如C 語言、通用RiscV匯編語言等缺乏時態語義.因此，程序的執行時間受其自身特性和軟硬件執行環境的影響，分析復雜、脆弱易變.時序僅僅是特定硬件平臺上軟件實現的一種附帶效果.硬實時程序測試、驗證和認證時需要仔細考慮軟硬件交互的細微之處，但任何微小的軟硬件設計變化都可能導致不可預測的時序變化，成本高昂.實時系統的建模和實現既沒有可移植性，也無法保證在實際系統中執行的正確性.在系統的設計階段，設計者對所設計系統的時序行為進行了仔細定義和分析，但現有的實現技術基本上忽略了這些工作，迫使設計者通過測試對所實現系統的時序行為進行重新確認.

時序指令僅僅建立一種指定時序約束的方法，并不強制執行時間行為，它們僅僅用于對軟件中的時序變量進行監測、檢查和交互.PRET 和RPU 的目標都是在ISA 中引入時序語義，但不過度約束ISA 的時態屬性.時序指令只需要滿足其時序屬性完全實現，不限制其他指令的性能優化.基于這些時序指令，程序員可以分析和控制程序的時態屬性，獨立于體系結構.同時，時序指令自身并不保證程序的執行時間.靜態分析為了可以得到緊致的WCET 界，需要下層體系結構提供可預測的執行時間.

目前，實時ISA 的研究工作主要有2 個方向：

1）基于傳統的ISA，以輔助WCET 分析為目標設計時間可預測的體系結構.

2）定義帶有時間語義的ISA，為上層提供精確的時間語義，并為目標設計時間可預測的體系結構.

3.2 基于傳統ISA 的工作

傳統ISA 缺乏時間語義，Kopetz 最早提出采用時間觸發（time-triggered，TT）范式代替事件觸發（eventtriggered，ET）范式進行體系結構的設計，并采用時間觸發體系結構（time-triggered architecture，TTA）以解決分布式實時系統中多節點間缺乏時間語義的問題[34-36].隨后，越來越多的學者認識到處理器缺乏時間語義的問題，并在傳統ISA 上改進設計時間可預測的體系結構.

Table 2 Comparison of ET System and TT System表 2 ET 系統和TT 系統的比較

Pont[37]認為了解硬件的每一個細節，就可以基于現代處理器構建滿足所有實時要求的軟件，這對硬件、系統設計者提出了較高的要求.Pont 研究團隊提出了時間可預測的PH Core[38]，它使用硬件多線程來處理由中斷引起的延遲，并且有一個硬件調度器以更好地支持TT 模式.

Schoeberl[39]希望使用Java 進行實時系統的開發，并為Java 環境設計了一套硬件體系結構——JOP（Java optimized processor），從架構的角度增加系統的可預測性.JOP 架構中更簡單、更準確的 WCET 分析比平均情況性能更重要.JOP 是Java 虛擬機在硬件上的實現，它采用了3 級流水線，沒有使用分支預測.JOP 主要應用于需要Java 環境的嵌入式實時系統，其微指令長度一定且執行時間相同.

我們認為基于傳統的ISA 設計可預測的體系結構沒有明確在ISA 層抽象出時間觸發、時間控制的概念，復雜度高、泛用性較低.

3.3 重定義ISA 的相關工作及時間語義

ISA 層在實時系統中對上層提供時間接口、抽象時間屬性和時間語義（對時間相關操作的表達能力），對下層硬件提出需要滿足的抽象要求.

Roop[3]對支持同步語義的反應式處理器進行研究，希望通過在指令集中增加同步語義來直接支持執行同步語言程序；以Esterel[40]為代表的同步編程語言基于同步假設，通過信號管理，如輪詢（polling）、發射（emission）和搶占（preemption）等同步程序，保證并發行為的確定性，易于程序驗證；HiDRA[41]是一個實時系統的軟硬件協同設計方案，使用多個反應式核REMIC[42]構造全局異步局部同步（globally asynchronous locally synchronous，GALS）的體系結構，提供類Esterel 語言的同步語義.STARPro[43]與HiDRA 思想一致，但HiDRA 支持類Esterel 的同步語義，而STARPro 旨在直接支持 Esterel 程序執行.另外，Roop等人[4]提出基于C 語言擴展的PRET-C 同步語言，并提出支持PRET-C 同步語義的微體系結構ARPRET.ARPRET 分為2 部分，GPP 實現通用計算，PFU 負責調度和保證功能的時間屬性正確.

據本文調查所知，目前僅PRET 項目和RPU 完整地抽象了時間語義，向上層提供了ISA 級的時間接口，擴展了時間語義指令集.

3.3.1 PRET 基于delay 的延時語義

PRET 擴展的時間語義主要約束了程序段執行時間長度.DU（delay until）指令保證了程序段的執行時間下界，mtfd 結構在編譯階段靜態檢查代碼段是否滿足設定的執行時間上界，并采用EE（exception on expired）指令通過異常處理響應過晚錯誤.PRET 基于代碼塊進行時序控制，我們認為PRET 在功能上，邏輯與時序控制分離；在時序上，“過早”與“過晚”分離.

此方案添加時序語義，可以約束指令序列執行時間的上下界，然而其缺少對定時語義的支持，無法直接表達操作發生在某個時刻的語義.正如Zimmer 等人[20]闡述的那樣，如果系統中存在中斷，PRET 基于delay+load/store 的結構實現定時I/O 就存在實現與語義不一致的問題，操作缺少原子性.

Wan 等人[44]提出構建時間語義指令集的思想，擬添加時間語義和操作語義綁定的指令，但該想法處于較早期階段.

3.3.2 時間觸發指令集TTI 的語義

TTI 指令集所描述的時間語義主要包括2 個方面：1）對程序執行時間長度的約束；2）對程序執行操作時刻的約束.在對程序執行時間長度的約束方面，TTI 并沒有特別定義針對某個程序設置執行時長的指令，對程序執行時長的控制體現在TTI 的多線程指令方面.TTI 中有一個線程調度表，該表負責為每個線程分配執行的時間片大小.通過對多線程的調度，可以控制每個線程在處理器中運行的時間長度.

值得注意的是，相較于PRET，TTI 對程序執行時間的控制方式是不一樣的.在執行超時的情況下，PRET 機器通過超時觸發定時中斷的方式實現對程序執行時間長度的控制.在執行時間短于規定時間的情況下，PRET 機器通過DU 指令來延長程序的執行時間.而TTI 在這2 種情況下都使用線程切換的方式來實現，在程序超時后，時間語義指令將異常狀態代碼寫入特定的控制與狀態寄存器（control and status register，CSR）中，并切換至其他線程，原有線程的程序被中止執行.而在一個線程被分配到的執行時間片內，即使程序已經完成了執行，處理器仍只會運行該線程而不會跳轉至其他線程，直到該線程被分配的時間片用完.

針對同步式實時控制系統的需求，TTI 還支持針對I/O 的定時語義，TTI 可以將程序的I/O 與執行時刻綁定，在處理器運行的離散時間中指定某一時刻執行操作.

3.3.3 時間指令集擴展及對比

為實現ISA 定義的時間語義抽象，需要向通用指令集中擴展時間操作指令.PRET 系列機和TTI 的時間擴展指令集對比如表3 所示.

PRET 和TTI 時間擴展指令集對于過早的操作都采取等待的方式，對超時錯誤拋出異常.不同的擴展時間指令集對實時性的影響差異體現在指令集可描述的時間語義上，如3.3.1 節和3.3.2 節所述.在時鐘精度方面，PRET 的時鐘精度由微處理器運行的周期長度決定，而TTI 基于時間觸發范式TT[34]和時間觸發自動機TTA[34-36]設計，完整地抽象了時間觸發、時間控制的概念，時鐘可以由外部接入（例如網絡時間），支持的時間精度與微處理器運行的時鐘周期同數量級[6].TTI 針對RISC 結構的微處理器使用的load/store 結構，定義了定時I/O 指令ttiao/ttoat，原子性地保證了I/O 操作的時間點（time point）[26]，符合LET 編程模型[45]的規范.

RPU 實現TTI 指令集，基于LET 編程模型.目前在Xilnx FPGA 開發板（xc7a100t-csg324-1）上實現 了智能小車跟車系統[26]和ABS 防抱死應用系統[46]的驗證，結果符合預期.

Table 3 Comparison of PRET and TTI on the Extended Time Instruction Set表 3 PRET 與TTI 在擴展的時間指令集的對比

3.4 本節小結

實時系統在中間層ISA 實現實時性，相較于軟件層實現實時性，利用了微處理器一般達到納秒級的運行時鐘，為上層直接提供時間語義指令.

目前指令集架構層面引入時間語義指令的工作主要有PRET 研究組的系列工作[20,47-48]和TTI 指令集.PRET 研究組提出了指令集架構在時序控制方面需要具備的能力[47]，基于這一想法，文獻[20,48]分別基于ARM 指令集和RISC-V 指令集擴展，加入了控制代碼段執行時間的指令，并依據擴展后的指令集構建了可以執行時間語義指令的處理器PTARM 和FlexPRET；文獻[6]在PRET 研究組工作的基礎上提出了時間和操作相結合的定時指令，定義了TTI 指令集，并實現了RPU.文獻 [6,20,48]所述的工作，重點在于時間語義指令集的定義，以及處理器硬件架構的實現.文獻[47]雖然給出了指令集架構在時序控制方面需要具有的語義，但是沒有說明從上層模型到底層指令的映射關系，沒有給出相應的設計范式.

現有的時間語義指令集工作對指令集可以表達的時間語義沒有給出明確說明，同時缺乏相應的時間語義程序設計范式，導致上層控制模型或編程模型映射至底層時間語義程序時依舊缺乏相關理論指導.

4 硬件層級的實時性支持

4.1 實時系統對硬件性能的需求

現今實時計算系統面臨的挑戰在于同時兼顧系統的性能以及實時性，因此，對性能的需求也是必不可少的.一個單周期處理器顯然有很優秀的實時性，但是它的性能遠遠滿足不了現代應用的需求.

一個常見的誤區在于高性能等于更好的實時性，導致許多工業系統設計錯誤地估計了實時系統的性能需求，Stankovic[7]也曾在1988 年提出過，高性能的硬件有助于對系統實時性的提升，但是卻不能保證系統的實時性，這和實時計算系統的設計初衷是相違背的.若使用軟件來取代通常由硬件提供的功能或與其他硬件設備交互的應用程序需要精確計時的輸入/輸出（I/O），其所需的計時精度在納秒級，這是處理器時鐘周期的粒度.目前，盡管對于許多應用程序來說毫秒級的計時精度已經足夠了，但對于某些特定的應用程序來說還不夠精確.

4.2 實現時間屬性的硬件支持與計時精度

PRET[5]和RPU[6]都基于經典5 段流水線，在EX段執行擴展的時間指令，采用寄存器寄存當前計時時間.在PRET 系列最新的FlexPRET 實現中，系統上電時刻計時時鐘寄存器歸0，隨后每個CPU 運行時鐘上升沿到來時，計時時鐘值加1.由于最終運行頻率為100 MHz，FlexPRET 認為其計時精度為10 ns.我們認為，在PRET 中計時時鐘和運行時鐘只是同一個晶振源的不同視角，且馮·諾依曼結構并未指明硬件實現必須要使用時鐘同步的各個部件，因此PRET 未對計時時鐘和時間語義有足夠的抽象.

實現TTI[6,22]的RPU 提出了實時機（real-time machine，RTM）的概念，在馮·諾依曼機5 大組成部件的基礎上顯式引入計時時鐘，直接提供給上層針對程序的時間行為予以控制約束的接口，為RTM 賦以時間語義.RPU 基于RTM 模型，引入計時時鐘（稱為標準時鐘），明確了時間觸發、時間控制的概念.

標準時鐘和CPU 運行時鐘之間顯然有2 種關系：同步與異步.在實際應用中，如果需要從外部接入標準時鐘（例如網絡時間），則運行時鐘和標準時鐘之間是異步關系.在之前的研究中，我們說明了在異步情況下TTI 的時間觸發指令抖動小于一個CPU cycle[6].

4.3 硬件多線程流水線結構

實時系統標準的傳統方法是在單線程處理器上進行軟件調度，而不需要為每個任務使用整個處理器或核心，并承受相關的效率損失.調度算法選擇在不同時間段執行某個任務，因為只能有一個任務在執行.使用傳統方法已經越來越不能滿足實時系統對性能日漸增長的需求，在單核系統上引入硬件多線程可以在保證實時性的基礎上以較小的開銷提升處理器的吞吐量，減少stall 或是等待線程代碼段執行時間下界的空閑周期.

我們的調查得出的一個主要結論是，一定程度的硬件支持對于在實時系統中為并發執行任務提供可靠的隔離保證是必要的.即使可以只用軟件實現，但與硬件解決方案相比，軟件的解決方案通常更麻煩、更難以認證且增加更多的開銷.

粗粒度多線程（coarse-grain multi-threading，CGMT）描述了一種硬件多線程結構，CGMT 在同一時間只能執行1 個線程，但又可以使用硬件切換為執行另一個線程，無需軟件干預.為此，它必須在處理器中使用硬件存儲多個線程的狀態，該狀態稱為硬件上下文（context）.切換2 個存儲在硬件上下文中的線程，包括清空正在運行的線程狀態并將另一個線程狀態加載到流水線中.與操作系統使用的軟件上下文切換相比，這通常需要少量的周期.相應地，軟件上下文切換只能用于隱藏長延遲（例如磁盤和其他 I/O 延遲），但粗粒度多線程處理器可以隱藏更短時間的延遲，例如高速緩存未命中帶來的延遲.

細粒度多線程（fine-grain multi-threading，FGMT）相較于粗粒度多線程，將若干個CPU 時鐘組織成時間片，在每個時間片按線程調度表切換線程.線程之間交錯執行，實現了“時間觸發”而不是“事件觸發”切換線程[6,17,20].PRET 實現細粒度多線程，采用線程交錯的流水線來避免同一線程中的數據依賴，在PTARM[18]和FlexPRET[20]實現中，每個CPU 時鐘上升沿選擇一個線程取指.PTARM 中，多線程以嚴格輪詢的方式調度，流水線的每一段交錯地執行若干個線程.而2015 年提出的FlexPRET 改進型結構，使用細粒度多線程和靈活的調度與定時指令來實現每個任務在基于硬件的隔離和有效的處理器利用率之間進行權衡，多個線程不必嚴格輪轉，每個周期可以由設定好的線程調度表選擇線程取指進入流水線.每個線程中程序相鄰的2 條指令取指之間的時間間隔（以CPU cycle 計量）稱之為一個thread cycle.Flex-PRET 同時調度HRT 任務和SRT 任務時，對HRT 線程采用時分復用（time division multiplexing，TDM）的調度，消除線程間干擾.

RPU1.0 實現粗粒度多線程，RPU2.0 版本實現了細粒度多線程.RPU1.0 采用和預設最大線程數相等套數的段間寄存器、PC 寄存器、Regfile，增加了一定的硬件消耗，確保了切換線程的時序.多線程由專用的時間觸發（TT）線程控制器管理，TT 線程控制器根據TT 表控制切換線程，TT 表的抽象結構為隊列.在RPU1.0 版本中，TT 表記錄了若干線程編號-標準時間數據對，每當隊頭指定的時刻（在EX 段判斷）到來時，花費4 個CPU cycle 切換至指定線程[6].TT 表由0號線程維護，通過addtk 指令不斷向TT 表中添加表項，0 號線程需要經過特定設計以滿足調度需要.在RPU2.0 版本中，多線程按時間片輪轉調度，TT 表記錄了各個線程編號及其分配到的時間片個數.相較于RPU1.0 版本，RPU2.0 損失了一定的靈活性，但在保證可預測性的同時降低了0 號線程的設計難度.

4.4 存儲系統的實時性

存儲層次結構設計影響功能、可預測性和性能，根據應用程序領域的不同，需要做出不同的權衡.

目前對實時存儲系統的研究主要有2 個方向：

1）在通用的傳統Cache-Bus-Memory 結構上改進以令存儲系統具有時間可預測性和時間可重復性.

2）使用新的存儲組織結構.

在通用結構上改進的主要挑戰來自于Cache 訪問時的不確定性、總線/存儲器訪問調度策略等，以及擴展至多核系統時保證時間可預測的緩存一致性；使用新的存儲組織結構能保證較好的實時性，但現有的實時應用和硬件都需要重新設計.

4.4.1 傳統Cache-Bus-Memory 結構

CPU Cache 對程序員來說是透明的，并且其依賴于內存訪問的時間和空間局部性來減少應用程序的平均執行時間.因此，CPU Cache 使用一組啟發式方法來保存在不久的將來更有可能被訪問的數據，并替換舊的、未引用的條目.在較高的層次上，Cache 的啟發式行為意味著在整個任務執行過程中對同一位置的內存訪問可能會導致Cache 命中，也可能不會命中，這取決于系統的歷史記錄.事實上，任務本身的執行模式、同一核上的不同任務的執行模式，甚至是不同核上的一組任務的執行模式都會影響給定內存訪問模式的Cache 命中率.這意味著復雜功能的系統歷史可以直接影響任務從內存層次檢索數據所需的時間，這也解釋了為什么Cache 是不可預測性的主要來源之一.此外，實時應用程序的內存訪問行為是由其功能驅動的.例如，簡單的HRT 控制循環不需要高的內存帶寬，而視頻處理應用程序需要內存帶寬和延遲.Cache Line 分配中的沖突稱為空間爭用；由多個核同時訪問同一個級別的Cache，稱為時間域的爭用.

解決基于Cache 的傳統存儲結構可預測性的2種最常用的方法都是在Cache 上強制執行更確定的行為.

第1 種實現時間隔離的方法是Cache 分區，它將Cache 劃分為若干分區，并將特定的分區分配給任務或核心.基于組相聯Cache 的結構，這些方法可以進一步分類為：

1）基于index 的緩存分區，每個index 指示的Cache Line 被劃分一個分區（水平切片）；

2）基于way 的緩存分區，每一個可用的Cache Way 都被專門劃分為一個分區（垂直切片）.

第2 種常用技術是Cache 鎖定.Cache 鎖定依賴于許多嵌入式平臺中存在的硬件特性.具體來說，可以將給定的Cache Line 或方式標記為鎖定，從而防止其內容在連續執行解鎖操作之前被替換[36,49].應用程序可以通過操作系統（OS）內存分配器使用Cache 分區和鎖定.

單核情況下只有一對指令和數據Cache，時序較為確定，可分析性強.在多核情況下，保持各個核心的Cache 一致是保證邏輯正確性的必然要求.在通用計算機系統中，應用較為廣泛的Cache 一致性協議是MSI 協議，它定義了Cache 的3 個狀態：Modified（已修改）、Shared（共享）、Invalid（無效）[50]，可以保持多核情況下各個Cache 數據的一致性.但分析表明，仲裁延遲隨核數的增加呈線性增長，而一致性延遲隨核數的增加呈二次增長，這強調了考慮緩存一致性對延遲范圍影響的重要性[51].

University of Waterloo 的研究人員在 2017 年基于MSI 協議設計了可預測的PMSI Cache 一致性協議，通過引入一組暫態來實現MSI 上提出的不變量，同時僅對緩存控制器進行最小的架構更改.在維持可預測性的同時，PMSI 協議在4 核系統上比競爭總線的調度方法實現4 倍的性能提升[51].隨后不久，又提出了新的緩存通信機制CARP[52]，CARP 在SPLASH2基準測試中比PMSI 協議性能提高4%.University of Waterloo 的研究人員在可預測一致性協議的基礎上實現了實例MapleBoard[53]，并支持 MSI，MESI，PMSI[51]，PMESI[54]，CARP[52]一致性協議.

在總線層次，Bus 一端承接了多個Cache，接收多個核心的訪存請求；另一端連通多個存儲器或外設（也可以看作特定地址的存儲器）.需要解決的問題是設計可預測的總線架構和仲裁算法.目前通用的總線結構解決方案是使用2 級調度器，將每個核心的訪存請求按可調度算法排成隊列，在外界看來僅有一個被核內時間可預測調度器選擇的訪存請求，而多核間的請求由高一級的調度器選擇一個核心的請求并給予總線控制權.目前通用的可預測的調度方法為TDMA 的輪詢型調度，它保證了每個請求的最長響應時間和最長結束時間.作為實例，Barcelona Supercomputing 的研究人員提出的可預測性架構[55]就使用了2 級調度結構，以ICBA（intra-core bus arbiters）調度核內請求，以XCBA（inter-core bus arbiters）調度核間請求，并給出了可預測的調度算法和仲裁方法.

存儲器方面，實時嵌入式系統一般采用動態RAM（DRAM），以應對現代設計中不斷增加的數據量和代碼大小.然而，到目前為止，內存控制器的設計主要集中在提高平均性能上[19].因此，內存訪問的延遲是不可預測的，這使得硬實時嵌入式系統所需的WCET 分析變得復雜.Hassan 等人[56]提出了一種可預測的內存請求調度方法，該方法能在大量的請求中保持局部性，最小化最壞情況的延遲，同時保證了平均延時沒有明顯增長.這種方法引入了一種新穎的緊湊的時分多路復用調度器和一種新的框架，用于構造多核混合關鍵系統的最優片外DRAM 存儲器控制器調度.這些調度計劃在引導階段加載到內存控制器.

RPU 擴展而成的實時系統RTS 采用傳統經典的Cache-Bus-Memory 結構，利用TDMA 的輪詢調度保證總線和Cache 訪問的可預測性[57]，相較于PRET，能更簡單地移植基于Cache 存儲系統編寫的程序.

4.4.2 便簽存儲器

便簽存儲器（scratchpad memory，SPM）被認為是一種比Cache 更可預測的選擇.SPM 是一種特殊的靜態RAM 存儲器，放置在靠近處理器的地方，類似于L1-Cache.SPM 的地址空間被映射到處理器預定義的內存地址上.與Cache 不同，SPM 必須顯式管理.即某個數據在使用之前，其所在內存塊必須在軟件中從主存中移動并復制到SPM 中.因此，SPM 是高度可預測的，因為它們只有一個CPU 運行時鐘周期的訪問延遲，而Cache 有2 個不同的Cache 命中延遲和未命中延遲.然而，SPM 顯式程序管理的需求意味著基于Cache 的系統編寫的程序不能輕松地移植到基于SPM 的系統上執行，而且在可用的商業系統中，對便簽存儲器的支持是有限的[58].

PRET 機采用SPM 較為簡單地處理存儲系統的可預測性問題.以FlexPRET 為例，FlexPRET 有單獨的指令和數據存儲器，使用軟件管理的SPM 而不是Cache，并且程序只允許訪問SPM 允許的區域.因此，所有有效的內存訪問總是成功的，并且單周期返回結果.FlexPRET 每個周期只能發生一次存儲器操作；在加載或存儲操作期間，不會獲取新指令，從而使用SPM 降低了處理器的總吞吐量.在常見的通用設計中，通常使用指令和數據Cache 而不是SPM 來構建存儲系統，但對于具有類似或更高復雜性的處理器來說，PRET 認為這是合理的設計決策.其理由是，如果代碼和數據之間只共享一個SPM，那么硬件線程的內存操作只能發生在一個預定的周期內，這個周期可能與內存階段不一致，它需要更多的控制邏輯和數據存儲.例如，每個硬件線程將需要為一個內存操作存儲地址和數據，直到下一個預定周期，然后阻止讀取.FlexPRET 可選地允許對指令內存而不是數據內存進行內存操作.

4.5 本節小結

在硬件層實現實時性的支持，設計自由度最大，但必須考慮從成熟的通用系統遷移實時應用的成本.實時領域的研究工作大多針對單一軟硬件平臺，為特定應用環境開發專用的成套軟硬件是可行的做法，但研究成果難以整合，導致在實時系統研究方面工業界與學術界脫鉤，不同研究者也難以復現彼此工作，因此難以深刻認識各自工作的價值.實時系統的研究相較于其他領域需要更深的積累、更長的周期，需要自行搭建自編程語言到硬件的研究平臺.更有甚者，由于實時系統面臨安全關鍵問題，而軟硬件平臺又沒有很好的抽象，導致系統即使需要微小的升級，也需要重新開始整個設計周期，導致大量的人力物力浪費.

5 總結

本文針對實時計算系統的發展情況，從計算機系統結構的各個層次分別對實時計算系統的需求、問題以及解決方案進行了論述.在對現有的實時系統設計研究的過程中，本文注意到實時系統設計問題的關鍵在于上層應用的時間語義難以與底層實現保持一致，為此，需要在ISA 層以及硬件設計時引入時間語義.針對在ISA 層引入時間語義的方法，本文著重描述了現有的2 種解決方案，分別是來自UC 伯克利大學設計的PRET 項目以及本文實驗室所設計的RPU 項目，并從ISA 層的時間語義方面分別介紹了2 種解決方案的異同.在硬件層面上，本文針對現有硬件設計總結了在實現時間可預測性方面的問題與挑戰，從多線程和存儲系統的實時性方面入手，分別對比了傳統設計和實時系統的設計，論述了如何在硬件層面取得更好的時間可預測性.

并行性和實時性是目前安全關鍵實時系統的核心要求和特征，傳統計算平臺對此支持不足，導致系統設計、實現和驗證成本高昂，必須從3 個基礎設施入手加以解決.

1）多核與多線程實時系統

向多核架構的遷移對硬實時系統的發展提出了極大的挑戰.這是因為共享硬件資源（如內存、互 連、I/O 等）的存在會在核心之間造成不必要的干擾.反過來，這種干擾使得我們很難得出安全且準確的任務執行時間的最差情況界限，而這是保證時間限制所必需的.

一個重要的問題是如何處理多核情況下的CPU運行時鐘和時間語義需要的計時時鐘的同步性.一方面，研究表明分析多核系統上并行程序的存儲器一致性需要顯式的全局時鐘[59].對于沒有顯式全局時鐘的片上多核處理器系統，Lamport[60]證明了在分布式系統中，如果各個進程使用不同的分布時鐘，則使用一定的算法可以把不同的時鐘換算成一個近似的全局時鐘，并且保證這個全局時鐘的誤差足夠小.另一方面，為了保證時間語義并利于驗證，每個核心上的計時時鐘也需要同步，一種簡單的實現是為每個核心接入同一個外部晶振作為計時時鐘.

2）時間可預測ISA

實時系統的ISA 應該提供給上層應用足夠的時間抽象.對于未來的時間增強ISA，我們認為其應該：

①提供時間管理接口，從用戶需求出發抽象出秒、毫秒、納秒等計時單位，并設置時間粒度.

②滿足用戶對于定時執行的需求.時間需求可以抽象為絕對點時間、相對點時間、絕對段時間、相對段時間，ISA 應該具有能滿足這些需求的語義.

③提供程序隔離能力，為新一代的混合關鍵系統提供執行環境.

④能夠提高處理器的利用率，改善長期以來實時系統因預留資源導致計算能力大量浪費的現狀.

3）時間可預測存儲系統

向多核方向發展需要重新設計可預測的存儲系統.基于傳統Cache 的存儲系統和基于SPM 的存儲系統存在較大的差異性，SPM 可預測性更好，但需要顯式管理，目前流行的基于Cache 的存儲系統編寫的程序都不能很方便地在使用SPM 的系統中運行.在基于經典的Cache-Bus-Memory 結構的實時系統方面，很多研究者都提出了不同的解決方案.在Cache 層次，多核之間需要時間可預測的一致性通信算法，目前這方面的工作主要有University of Waterloo 的研究人員提出的可預測MSI 方法PMSI，以及PMESI，CARP等方法；而多核Cache 內部同一處理器的訪問需要具備時間可預測性，目前流行的解決方法是采用TDMA的調度方式消除時間不確定性.未來這方面的工作主要集中在提高一致性方法的性能并減少消耗上.總線結構和調度方法上，需要著重考慮實時性和性能之間的權衡.嚴格輪詢的調度具有很好的可預測性，但會嚴重損失性能.TDMA 的調度方法是目前性能和實時性之間綜合考慮的選擇.未來的實時系統使用怎樣的總線結構和調度方法仍然有一定的挑戰.存儲器控制器和總線面臨的情況類似.與總線系統相比，存儲器控制器僅需要調度一側的請求.未來對實時系統中存儲系統的創新更有可能是整體結構的重新設計，在保證實時性的基礎上能以較小的開銷實現、遷移基于經典存儲系統編寫的程序.

作者貢獻聲明：龔小航、蔣濱澤共同調研并撰寫論文；陳香蘭、高銀康、李曦提供論文指導和修改意見.