左移需要軟硬件怎樣協同?
(本文編譯自Semiconductor Engineering)
硬件與軟件協同開發一直是我們一直追求的目標,然而,這一進程仍面臨重重障礙。這兩大領域在關鍵時間節點上,往往無法精準匹配對方的需求。
在開發流程中越早處理問題,之後發生的故障就越少,一旦錯過最佳解決時機,修復將變得更加困難,修復成本也將急劇攀升。因此,我們亟需革新現有的工具與方法,確保流程中的每一步都能儘早獲取關鍵信息,並配備預測潛在變更影響的先進工具。這一過程,常被形象地稱爲“左移”,在硬件與軟件的協同設計或集成領域,它無疑是一項艱鉅的挑戰。
傳統上,軟件集成工作往往在首個芯片完成後才得以啓動,但業界正力求在此之前便完成這一步驟。若在芯片之後進行集成,雖有可能遭遇意外狀況,但屆時硬件的修改已幾乎不可能。這一滯後導致的後果,便是軟件修改的代價高昂,進而嚴重影響產品的上市時間、性能表現及功耗。
然而,這並不意味着在硬件開發階段必須提供完整的成品軟件。我們或許可以定義實際的軟件工作負載,以便對硬件架構進行優化。儘管可能存在來自以往產品的軟件或原型軟件,它們或許並非最終會部署於硬件上,但對於衆多硬件設計任務而言,仍能提供寶貴的參考與幫助。例如,通過分析這些軟件,我們可以識別出潛在的交通擁堵點或峰值功率需求,從而設計出更加合理的供電網絡。
在其他特定場景下,成熟的軟件已經存在,而硬件則是爲了專門加速該軟件而進行設計。例如,視頻編碼對於流媒體服務來說是一項極爲重要的任務。在執行這項任務時節省功耗能夠帶來顯著的能效提升。對於AI/ML(人工智能/機器學習)硬件而言,不僅軟件在硬件開發之前就已具備可用性,而且幾乎可以預見,當硬件最終就緒時,軟件也已經取得顯著的進展。
這些情況促使企業不得不重新評估與硬件及軟件開發與集成相關的方法。儘管市面上涌現了越來越多的工具來幫助解決這一問題,但工具開發領域本身也面臨着類似的挑戰。硬件工具開發者與軟件工具開發者往往分屬不同企業,他們尚未形成合力,共同攻克這些交叉領域的難題。
無論硬件還是軟件先行,都需要有辦法在虛擬層面上將它們整合到一起。“實現早期集成的關鍵在於抽象,”新思科技產品管理與應用工程副總裁Marc Serughetti強調,“這與衆多領域的做法並無二致。抽象之所以必要,是因爲它允許我們在尚未掌握全部細節的情況下,提前獲取關鍵信息。然而,抽象也有其侷限性——它會篩除部分信息,若這些信息最終證明至關重要,則可能導致這部分信息丟失。因此,這些方法的成功實施,有賴於將其視爲一個迭代過程,並在其中設立明確的里程碑,以確保信息的完整性和準確性。”
軟件的可用性
軟件種類多樣,每一類別均需個別考量。“SoC中內置了微代碼,”Cadence產品管理和營銷的總監Jeff Roane解釋道,“它們由半導體供應商開發,終端用戶通常不會對其進行改動。除了終端用戶的應用程序代碼外,在SoC設計出來之前,應用程序代碼鮮有已經存在。以安卓和蘋果iOS軟件開發工具包(SDK)爲例,全球都在基於它們開發應用程序。供應商們致力於確保SoC與既有項目、遺留系統及新開發內容實現百分之百的兼容。而對於新一代SoC而言,應用程序代碼的開發面臨着一個類似於‘先有雞還是先有蛋’的難題。”
這時,通常需要採取多管齊下的策略。Arteris產品管理和營銷副總裁Andy Nightingale指出:“我們通常採用軟硬件協同設計的模式,兩者均進行了持續迭代。軟硬件團隊間的緊密合作確保了硬件定型時,軟件已具備就緒性或適應性。很多時候,我們會提供聚焦核心功能的早期代碼庫,或者設計測試軟件來模擬真實的工作負載和基準。”
部分行業正探索其他路徑。“在汽車行業,他們正努力將軟件與硬件分離,”新思科技的Serughetti說道,“儘管總有些軟件需依賴硬件,但可以開始對這些部分進行分離。左移策略的首要任務是探討如何在硬件獨立的情況下啓動應用軟件的開發。至於更低級別的軟件,則是如何在缺乏硬件支持的情況下着手開發。這正是虛擬原型概念大顯身手之處。左移策略的核心理念之一,是避免軟硬件結合的瞬間發生大規模集成的情況。隨着軟件開發、驗證以及確認朝不斷迭代的過程發展,你將圍繞多個維度進行驗證與確認。”
集成開始得越早,其價值越大。是德科技射頻/微波、電力電子及設備建模EDA業務高級總監兼產品組合經理Nilesh Kamdar強調:“左移,並使相關事物能在軟件環境中可用,可以讓系統設計師或架構師提前預判問題。雖然仍會有一些問題被遺漏,到很晚才被發現,但許多問題都有機會在早期得到解決和識別。對於無線通信而言,硬件與代碼開發並行不悖。雖然並非總能完全同步,部分代碼開發或許會在後續繼續,但多數工作都會提前展開。”
在其他領域,這種協同尚未達成。“設計階段軟件的可用性仍是主要挑戰,”Fraunhofer IIS自適應系統工程部門高效電子負責人Andy Heinig表示,“數字孿生的目標就是讓設計與製造並行,同時開發軟件。然而,通常只有適用於舊一代硬件的軟件可用,這僅作爲起點,未能充分考慮新功能與需求。”
最終是讓硬件與軟件相互影響,以共同部署最優解決方案。這意味着需儘早爲軟件開發提供硬件抽象,並建立軟件開發實踐,確保軟件的關鍵部分能在硬件開發初期即投入使用。
軟件開發所用硬件
沒有一種解決方案是完美的,正如所有形式的抽象都伴隨着取捨:或是準確性,或是可見性,或是性能。西門子EDA高級產品經理Jeff Hancock指出:“我們需要結合雲原生模擬、豐富的模型庫、集成化的工具鏈以及混合(虛擬/RTL)環境,以構建一個高效的生態系統,滿足現代硬件與軟件開發的需求。”他進一步表示:“這一生態系統將虛擬與混合模型相融合,不僅加速了開發流程,還提升了最終產品的質量和性能,使得軟件團隊能提前數月乃至數年着手工作,助力客戶更快,並以更好的產品質量進入市場。”
虛擬化能夠提供最高性能。Arm北美汽車市場總監Robert Day表示,“在汽車行業中,SOAFEE是一個由超過140家汽車和軟件生態系統成員組成的合作組織,致力於定義一種架構,以支持採用現代虛擬化技術進行雲端開發,並能無縫部署至車輛。這一方法使得汽車製造商能夠在不同的硬件平臺上移植相同的軟件,並確保在硬件可用之前即對軟件進行測試。”
許多硬件開發團隊從定義高級模型入手。Cadence的Roane表示:“如果你擁有一個虛擬模型(數字孿生),即一個用C++編寫的高速模型,你可以在其基礎上進行一定程度的軟件開發。然而,這受限於你能夠多快地模擬出足夠多的模式以進行有意義的工作。處理圖像或音頻流的應用可能需要數百萬個週期。即便你正在開發C模型,也存在侷限性。這些模型的速度不足以支持有意義的軟件開發。”
這僅能讓你對功能正確性充滿信心。Roane補充道:“另一個方案是將設計映射到FPGA上,它能以兆赫茲以上的速度運行。但挑戰在於,如果你的設計原本是針對ASIC或IC工藝節點的,那麼將其映射到FPGA將是一個全新的不同設計,因爲你要映射到不同的結構上——複雜的邏輯塊,而非基本單元。時間成本完全不同。你必須對整個設計進行重構,才能將其映射入FPGA。”
此外,映射到FPGA可能會犧牲可見性。Serughetti指出:“爲了增強可見性或獲取性能和功耗的準確數據,你需要在模擬器上運行實際的RTL代碼。這可能會非常慢。於是你會問,我真的需要在模擬器中安裝Arm處理器嗎?我可以將其放在虛擬平臺上。混合世界讓我們將開發過程視爲一個隨着軟件增長而不斷迭代的過程。它還允許我們將問題分解爲幾個部分。當人們談論左移時,包含兩個要素:一是更早開始;二是逐步進行。要啓動操作系統,你不需要完整的SoC。爲GPU開發驅動程序,你只需要GPU和一些主機核心。”
另一方面,硬件爲軟件提供了更深入地瞭解性能和功耗等因素的能力。Roane表示:“我不知道這是否已經實現。在哪個階段,軟件開發人員會收到關於他們正在開發軟件的設備的功耗特性的反饋?軟件開發人員與提供純功能視圖的調試器交互,他們不習慣查看硬件結構,也不習慣查看這些硬件結構的功耗配置文件。在解決問題時,需要團隊合作。軟件開發人員仍然專注於功能及其性能。但在優化功耗方面,仍然是硬件團隊的職責。”
這正是持續集成和持續部署(CI/CD)等服務的價值所在。Arm的Day表示:“它們使開發人員能夠管理不斷髮展的軟件工作負載。CI/CD管道有助於跟蹤軟件變化,並確保它們不會對性能或功耗產生負面影響。這些服務提供自動化測試和部署,在軟件和車輛的整個生命週期內保持軟件的完整性。”
CI/CD提供了寶貴的反饋循環。Arteris的Nightingale指出:“通過定期將軟件更改集成到測試環境中,你可以評估其對性能和功耗的影響。迴歸測試可以識別與既定基線相比的變化。這爲軟件開發提供了重要指導,確保其符合硬件約束條件。”
重要的是,要清楚每個解決方案的目標。“沒有萬能的解決方案,讓你可以模擬一切,創建一個以千兆赫速度運行的虛擬孿生,然後讓你完全瞭解一切,”Roane強調。“這些都是幫助你朝正確方向前進的解決方案。但你設計硅片總有原因。它纔是提供足夠動力來運行一切的原因。”
硬件開發所用軟件
在每個硬件的開發任務中,都需要使用不同層級的軟件。Serughetti表示:“在架構探索初期,可以採用前代產品所使用的軟件。或者,也可藉助任務圖來描繪軟件,這並非軟件的實際功能行爲,而是對軟件內部事件的表達。你試圖要做的是優化互連和存儲器。而爲此你並不需要用到所有的軟件。”
當設計功耗優化時,則需要對軟件有更精確的呈現。“若想要實現功耗優化,必須針對實際或真實的工作負載進行優化,這要求我們與軟件團隊緊密合作,”Roane強調。“以往,人們嘗試開發一些代表有意義工作負載的向量,但鑑於軟件的數量及其重要性,直接從源頭找到這些工作負載更爲理想。這比SoC設計師爲測試設計而虛構的負載場景要真實得多。”
對於團隊來說,持續評估其流程以確定是否存在更好的解決方案非常重要。Keysight 的 Kamdar 表示:“如果回溯到 10 年前,電磁模擬在計算時間方面非常昂貴。你只能在一臺計算機上運行它們,並佔用所有內存。這影響了硬件決策的速度,也影響了設計師必須接受的準確性。後來出現了多線程 CPU 和超線程選項,然後出現了大規模並行計算選項。你能夠立即更快地獲得答案。現在,你有了更多預測性的方式來進行硬件設計。它讓你意識到,以前你正在將問題縮小到你可以管理的程度。現在你可以處理更大的問題。”
團隊持續評估自身流程以確定是否可能存在更好的解決方案,這一點很重要。Keysight的Kamdar表示:“若回顧十年前,電磁模擬在計算時間成本上極爲高昂,因爲只能在單臺計算機上運行它們,而且會佔用全部內存。這不僅延緩了硬件決策的速度,也限制了設計精度的提升。隨後,多線程CPU、超線程技術以及大規模並行計算的出現,極大地加速了求解過程。如今,我們已能採用更具預測性的方法進行硬件設計,這讓我們意識到,過去我們是在簡化問題以適應處理能力,而現在,我們有能力應對更復雜的問題。”
如今,很多問題仍需簡化才能便於處理。“如果你有一項工作負載,它可能涉及數十億個週期,”Roane表示,“你不會把數十億個週期的數據都投入到優化引擎中,然後針對這個工作負載進行優化,時間根本不夠用。挑戰就在於如何選擇該軟件中的一個有意義的子集,並利用它來推動優化。你要做的就是說,‘我要專門針對這種最糟糕的情況來設計我的電源和電網。只有利用該子集纔有可能做到這一點。’”
流程優先
顯然,這主要是一個方法問題。以往軟硬件融合時那種一次性大規模集成的做法已不再適用。現在需要一種迭代式的方法,要求硬件與軟件團隊必須相互協作,以確保雙方需求都能得以滿足。
一切均源自規範的確立。“虛擬原型是對某些事物的呈現,”Serughetti表示,“就在幾年前,多數企業都沒有書面規範。啓動虛擬原型的工作異常艱難。倘若僅在一切都完成後才着手編寫規範,這顯然是個流程上的問題。許多企業已意識到,預先制定更完善的規範勢在必行。當然,這並不意味着規範能夠完全正確。但虛擬原型的優勢在於,它允許我們驗證規範的準確性。規範中難免包含若干假設性內容,而虛擬原型的第一階段,實質上就是對規範進行澄清,確保硬件與軟件團隊,以及規範編寫者之間達成共識。”
這是一個非常現實的問題,也是一個需要解決的問題。解決方案涉及一種方法,以及可用解決問題的工具和技術。對於那些工具的製造商來說,與對口公司開展更緊密的合作也是很有必要的,因爲目前提供的解決方案並不能完全解決這些問題。