原因是多方面的，這些原因導致出現了各種各樣的系統模型，如圖1所示。有時候，僅僅是因為軟件團隊希望盡早開始設計工作。原理上，規劃人員可以把軟件分成與硬件無關規模較大的部分，以及與硬件功能相關而規模要小很多的部分。(Android等平臺強化了這種不同，應用程序完全與硬件無關)。然后，設計人員能夠在服務器自帶工具上開發硬件相關代碼，使用服務器功能替代目標系統的應用程序接口(API)。這種API替代本身就是一種系統建模。

 

圖1.系統模型中的抽象層

 

    但是，隨著系統設計的集成度越來越高，他們需要把詳細的硬件行為放到應用層中，包括延時和能耗等。這種發展趨勢導致一些經驗豐富的設計人員開始懷疑硬件無關軟件這種觀念。Mike Dini是FPGA設計公司Dini集團的創始人，在今年的設計自動化大會(DAC)原型開發討論組中闡述了“軟件設計人員如果沒有實際硬件就無法取得真正進步”這一令人注目的觀點。相似的，Tensilica的資深產品專家Andrea Kroll在系統建模DAC討論組中發表了自己的看法，“在華為，我們嘗試了軟件驅動的系統開發。但是，軟件團隊在沒有硬件時，并不知道怎樣開始工作。”這些懷疑觀點導致設計團隊在設計早期便構建詳細的硬件模型，以便軟件團隊能夠開始工作。

 

系統研究

 

    由于系統越來越復雜，規劃人員很難預測最終產品會怎樣工作。傳統的表格模型甚至最好的SoC數據表都不足以回答關鍵問題：數據包吞吐量實際是多少?應用程序性能會滿足用戶的預期嗎?能接受電池壽命或者散熱嗎?有時候，回答這類問題的唯一方法是開發非常詳細的系統模型，利用模型來研究用戶案例和體系結構替代方案。

 

    系統建模的第三種應用是系統驗證，這種應用可能看起來不太引人注意。軟件的優勢是明顯的。Xilinx研究實驗室的Austin Lesea在DAC系統建模組中發表評論說：“您可以在C語言中進行大量的軟件驗證。當您需要周期精確標準時，問題就來了。”軟件驗證需要精確的可執行硬件模型。

 

    但是，需求已經超出了軟件調試。Cadence資深設計師Stuart Swan在討論組對此發表不同看法：“我們需要改變我們的觀念。我們應該把更多的系統驗證提高到更高的抽象級，重新使用更抽象的模型來生成底層模型。”這一方法要求在開發原型之前，在各種抽象級上驗證系統模型功能，很多情況下，甚至是某些IC涉及到的寄存器傳送級(RTL)。

 

    有些專家說，早期驗證不僅僅是盡早找到設計錯誤，還有很重要的結果。測試臺是會話發起器和校驗器，進行隨機測試，可以重用驗證事物級模型開發的基本工具，將其應用于更詳細的模型上，甚至是物理原型。通過這種方式，系統設計團隊不僅避免了在設計期間多次重新開發相同的測試臺，而且還可以在設計過程中盡早開始調試測試臺。此時，團隊進行詳細的系統驗證，測試臺應該非常穩定。

但是，我并沒有進行SoC開發

 

    您會說，所有這一切聽起來很合理。但是，如果我們的設計團隊購買了專用標準產品(ASSP)，而不是設計自己的SoC，情況會怎樣?我們要使用模型，應該怎么辦?這里有幾種回答。

 

    對于系統設計團隊，最直觀的方法是編寫非常抽象的事物級模型，他們只需要在數據表級理解ASSP及其周圍的芯片。在這一等級足以理解系統的工作，并與系統進行通信，研究使用案例。對于以后更復雜的建模工作，這可以用作工作臺。

 

    理想情況下，如果可以使用ASSP，很明顯的下一步是硬件原型設計，采用芯片供應商已經設計好并調試過的開發套件來進行開發。如果沒有開發套件，甚至連硅片也沒有，或者系統設計還沒準備好支持部分原型，那么，還有別的選擇。

 

    正如ARM設計技術副總裁John Goodenough在建模討論組中所建議的，一種選擇是，在您的前一代SoC上使用開發套件，仔細的實現各種不同應用。取決于這些不同應用的差異程度，例如，從功能和用戶案例研究到性能建模，甚至是某些驅動程序的開發等，可以一直使用這些原型。這有助于幾代ASSP共享存儲器和總線體系結構，只需要進行很小的改動，就能夠加速設計實現。

 

虛擬原型

 

    那么，如果既沒有您計劃使用的ASSP，也沒有非常相近的器件，該怎么辦呢?當您已經快完成了硬件原型開發，但是需要提高對系統內部的可視化程度，您應該怎么辦呢?芯片供應商通過系統級虛擬原型來回答這些問題，如圖2所示。

圖2.虛擬原型工具將不同級別的模型連接至統一的調試工作臺中

 

    理想情況下，系統虛擬原型會是一組模型，在幾種抽象級上精確的表示系統(請參考工具條：每一目標模型)。原型會提供已經開發好的調試和軟件執行接口，提供很好的方法將組件加入到系統模型中。

 

    這一想法并非不切實際。Frank Schirrmeister是Cadence系統開發產品市場資深總監，他認為，越來越多的IC供應商構建了復雜SoC的虛擬模型，幫助客戶圍繞芯片模型開發全系統虛擬模型。在某些情況下，這些模型實際上成為IC數據表。Schirrmeister評論說，我們將模型提供給客戶，這些模型通常包括事物級和加密RTL視圖，硅片供應商的現場應用工程師還為客戶提供幫助。芯片模型成為系統開發人員完整系統模型的一部分，也是硅片和系統設計團隊之間的通信手段。實際上，當FPGA供應商Altera和Xilinx最近推出集成了CPU群的FPGA后，他們出于這一目的，都為新芯片提供了虛擬模型。

 

設計人員實際使用什么

 

     在DAC系統模型建模討論組中，EDN的EDA編輯、主持人Brian Bailey詢問小組成員，他們的系統建模實際是什么情況。答案反映了不同設計團隊的各種需求，以及他們的各種觀點。

 

     運動研究(RIM)公司的資深建模專家Frederic Risacher描述了大部分開發人員通常會面臨的環境。我們不設計IC。Risacher解釋說：“我們購買硅片，然后通過軟件來突出我們的產品優勢。”

 

     Risacher說，RIM不設計自己的硅片這一事實使得設計團隊的建模策略比較復雜，但是基本上不會改變。工作不是從硬件建模開始，而是從軟件開始。Risacher說：“至少在我們得到硅片之前的九個月，甚至是在得到虛擬原型之前，我們就開始開發過程和線程模型。然后，盡快開發功能精確、周期近似的硬件模型。”

 

      Risacher繼續解釋了RIM在這些模型上依靠其IC供應商。但是在這種關系上存在一個基本問題。芯片設計人員把他們的可綜合RTL代碼作為其IC的定義模型。但是，不能直接從RTL獲得RIM需要的更抽象的模型。Risacher解釋說：“因此，所有的都來自規范，而不是RTL。”

 

    RIM出于幾種不同的目的來使用這些模型。在設計早期階段，重點是理解軟件對硬件的要求。Risacher提醒說：“硅片和用戶需求之間的不同要求對硬件進行改動。您會嘗試預測這些問題。”當系統設計整合到一起時，RIM團隊轉到更詳細的模型，用于系統調整——例如，設置緩沖深度，還用于研究新想法。結果是功能強大的工具組，但是，存在管理難題。Risacher說：“我們在三種不同的領域中有四種不同的模型。這些模型的每一個都可以分別進行提取、驗證和維持。

 

     Qualcomm的首席工程師Richard Higgins從硅片供應商的角度講述了一個相似的案例。Higgins說；“我們使用系統模型來預測硬件的行為，盡早開始軟件開發。”問題是，要實現這兩個目標需要很多不同抽象級。Higgins解釋說：“我們使用完整的系列模型，包括，結構、功能、行為和接口級抽象。此外，我們會有一些可執行SysML，還涉及到一些可綜合SystemC。”

 

     和RIM相似，Qualcomm面臨保持模型連續性這一難題，與硅片團隊在RTL上有相同的看法。Higgins建議說，這方面最重要的最佳實踐是，為所有不同的模型維持一個公共驗證途徑。但這很難。他說：“目前，還沒有真正的體系結構和軟件模型公共驗證途徑。”

 

    Tensilica的Kroll說，甚至IP開發人員也面臨相似的問題。她說：“在開發IP子系統時，對于多核設計，我們在早期軟件開發、互聯分析和性能驗證中使用系統模型。”這一工作需要從指令集仿真器到數據流發生器的所有一切，以便采用注釋時序對硬件模塊進行建模。Kroll建議說：“您應該知道使用模型的目的，確定各種抽象級的組合，以及您所需要的精度。”

總結

 

    幾個不同設計團隊的經驗表明，即使是使用商用ASSP的系統設計團隊，系統級建模都有很大的優勢。使用模型，軟件開發團隊在能夠使用硬件原型之前，盡早開始工作。這樣，系統團隊盡早查看系統行為、性能，以及能耗等，從而降低風險。使用系統模型，初步規劃怎樣構建系統測試臺，可以盡早開始系統驗證。

 

    “但玫瑰都有刺”。一些不知名的系統設計團隊很難甚至不可能從ASSP供應商那里得到模型和支持。這些團隊可能不得不從數據表描述中獲得他們自己的IC模型。系統模型需要進行驗證，正如系統本身自己那樣。所有不同的系統模型應保持一致性，這非常重要。但這是很大的挑戰，因為，不同的模型一般由不同的工程師手動得到，有時候還有不同的來源。不同的模型還存在于不同的工具環境中，一般不具有互操作性，可以由不同的團隊使用。考慮到這些問題，建模工作不應受限于資源，本身也不應成為完整的設計工程，這一點非常重要。

 

    既能夠發揮優點，又解決了難點問題，全面的系統建模計劃并不是每一設計的最佳解決方案。但是，由于系統越來越復雜，更多的設計都會需要模型。盡早熟悉該技術是很明智的，而不應該等到您確定“我們應該對此進行建模”時才想起這一技術。