支持SystemC的電子系統級(ESL)設計和驗證環境旨在設計,分析,優化和驗證片上系統(SoC)平臺模型。這樣的環境構成了已建立的RTL實現流程的前端。
現在,您為什么要關心?
根據Gartner DataQuest的說法,SystemC設計和驗證環境被用作設計流程前端用于約2003年的約100個SoC設計。其中許多設計是世界領先的SoC設計公司的旗艦產品。
根據最近發布的材料,德州儀器使用SystemC ESL設計方法設計和開發其OMAP處理器和調制解調器平臺,STMicroelectronics使用它來設計其Nomadik應用處理器。此外,諾基亞和高通等領先的系統設計公司正在建立面向SystemC的設計流程。
但為什么所有這些領先的公司都采用SystemC方法?是什么促使公司使用SystemC ESL設計增強其現有的設計方法?換句話說,您如何決定是否需要SystemC ESL設計方法?
當您遇到以下任何問題時,應考慮使用SystemC ESL設計:
1。當您的SoC部署采用多個嵌入式微處理器和DSP來實現融合功能時,例如通信和/或多媒體?復雜的體系結構,功能和協議的設計陷入了大量耗時的RTL細節。
SystemC ESL設計方法可以將架構設計時間從幾個月縮短到幾周。如何?
優化SoC架構需要探索和分析多個候選硬件/軟件分區方案和硬件架構,每個方案都有不同的性能和經濟權衡。在這個階段,SoC架構師關注的是開發和優化系統行為和架構。
但RTL的引腳精確連接和納秒精確的時序細節模糊了系統范圍的視圖,并大大減慢了設計速度。使用這種低生產率的方法,設計師偶爾會選擇“無論什么工作”,而不是設計“什么效果最好”?并冒險推出一項缺乏競爭力的產品。國際商業戰略(IBS)對領先的SoC公司進行的一項調查預測,SoC架構開發工作將很快超過物理設計工作,因此這種生產力問題有望變得更加糟糕。
SystemC ESL設計速度復雜硬件/軟件分區和硬件架構開發通過執行比RTL更高的抽象級別,僅使用與系統設計相關的那些設計屬性。這是“設計意圖”被最有意義地捕獲的水平?為SoC架構師提供直接和清晰的系統行為視圖的水平。
SoC架構采用SystemC IP模塊設計,通過應用程序接口(API)連接到與實現無關的高級總線模型。使用事務級建模(TLM),該體系結構在功能方面進行設計和驗證,其特征在于高級塊輸入和輸出事件以及塊間數據傳輸。
系統IP組件和總線可以比RTL更容易修改或更換,模擬速度提高1000多倍。因此,設計人員可以快速優化設計,以實現“最佳效果”。
最終優化架構的TLM模型構成了一個“可執行規范”,可驅動整個后續RTL實現。
2。當完整的系統,功能驗證消耗了更大的設計時間和預算?你仍然對第一次通過成功沒有信心。
設計師報告說,SystemC ESL設計可以減少驗證時間,使整體設計和驗證工作減少50% ,并確保第一次是正確的。事實上,當設計團隊首次使用SystemC ESL設計來設計和開發SoC時,這是投資回報率中的最大因素。 SystemC ESL設計如何提供這一價值?
RTL驗證始于設計人員對系統級行為的全面解釋,包括大量的塊內電路狀態和納秒精確的轉換,以及相關的比特精確的總線行為。然后,需要定義執行這些行為的大量詳細場景,并為這些場景創建眾多刺激/預期響應,然后進行模擬,通常以實際芯片速度的百萬分之一執行。
這就是為什么隨著SoC復雜性的增加,驗證會消耗不斷增加的設計時間。然后將驗證的RTL設計轉移到合成。但是如果全面的解釋不夠全面呢?
SystemC ESL設計自動化SoC架構的開發,并根據高級塊輸入和輸出事件以及塊間數據傳輸來驗證行為,交易級別。這種系統級行為的直接視圖消除了手動RTL到系統行為的解釋,這種解釋太容易不夠全面,并且顯著減少了所需場景的數量和測試它們所需的刺激/響應。
消除如此多的任務大大簡化了驗證工作和時間。此外,周期精確的TLM仿真執行速度比RTL快1000倍。
最終的系統級功能測試平臺構成了“黃金”驗證套件,可確保RTL設計符合規范。此外,SystemC與RTL的協同仿真功能使驗證團隊能夠將SoC的TLM模型用作測試平臺,以便在RTL塊可用時對其進行驗證。
3.當市場生存需要你以類似消費者的速度旋轉原始SoC設計的多個衍生物?并且你迫切希望提高設計效率。
設計師報告說,SystemC ESL設計可以將衍生物的旋轉時間減少多達75%。實際上,衍生設計是SystemC ESL設計的生產力對ROI影響最大的地方。如何?
衍生設計旨在維護SoC平臺的基本架構和行為,同時增強或添加所選功能。傳統方法是圍繞第一個SoC選擇的處理器建立基線RTL平臺,然后通過“混合和匹配”適當的RTL IP來設計衍生產品,以實現所需的新功能。
問題在于“混合搭配”意味著RTL IP模型從未實現的“即插即用”程度,因為它們過于復雜。通常,衍生設計幾乎與“干凈”設計一樣困難。
同樣,SystemC ESL設計解決了這個問題。 IP模型實際上可以在SoC平臺的SystemC TLM中“混合和匹配”。使用SoC設計的其余部分快速模擬新的SystemC IP,并且經過驗證的衍生SoC的TLM模型可以用作測試平臺,其中可以共同驗證新IP的RTL視圖。
4.當SoC性能和/或低功耗可以決定你的市場地位?并且調整RTL設計無法提供所需的改進。
SystemC ESL設計可以提供更高的性能,并且比RTL優化所實現的功耗節省10倍至20倍。怎么樣?
SoC性能主要由硬件/軟件分區,處理器,總線和存儲器的速度以及它們的通信協議決定。這些系統組件和屬性無法在RTL中進行調整。 SystemC ESL設計使設計人員能夠設計出最佳的硬件/軟件分區,硬件架構和協議,從而最大限度地提高SoC性能。
處理器,存儲器和相關總線活動消耗高達80%的SoC功率,以及因此,硬件/軟件分區以及軟件算法和數據存儲的效率受到很大影響。同樣,這些系統組件和屬性無法在RTL中進行調整,因此RTL調整最多可以在剩余的20%中進行漸進式改進。
功耗優化內存包括最小化內存訪問次數和定制給定應用程序的內存架構。將高使用率的內存訪問集群到一個單獨的優化緩存中可以簡化內存事務,從而降低功耗(并且通常可以提高SoC性能),因此緩存內存架構對功耗至關重要。
SystemC ESL設計直接和即時查看內存訪問以及與之相關的活動,可以實現緩存命中率與緩存大小之間的直接關聯,以及用于確定最佳內存大小的軟件甘特圖。從函數調用與內存訪問頻率的相關性中識別算法優化候選。
5.當您的系統客戶需要早期SoC模型以使他們能夠完成他們的設計并贏得設計時??他們不能等到RTL設計完成。
在無線通信中經常出現這種情況,這也是全球最大的寓言半導體公司之一Qualcomm的原因之一已經在SystemC上實現了標準化。
系統設計人員在芯片可用性之前通常需要SoC模型來驗證整個系統設計的進展情況,并贏得客戶的早期批準。此階段的驗證使系統設計人員能夠在完成原型硬件之前檢測并糾正系統不合格或徹底的故障,從而消除昂貴且耗時的硬件重制。
以及“遲到”,RTL模型并不是特別適合這個目的,因為它的實際芯片速度的百萬分之一的驗證速度減慢了系統模擬的速度。并且系統設計人員不一定知道如何調試RTL。
SystemL TLM模型在RTL實現之前幾個月就可用,它封裝了系統感興趣的所有系統級行為和屬性。設計師,執行速度比RTL快1000倍。因此,它不僅滿足系統設計人員對早期SoC模型的需求,而且還在系統設計者最熟悉的抽象層次上執行。
6.當您僅開始軟件開發時原型可用?產品發布的軟件和軟件完成。
在嵌入式軟件中實現了超過50%的SoC功能,這正成為SoC設計的起搏項目。 IBS調查預測嵌入式軟件開發工作將很快超過SoC硬件設計工作,因此問題變得更加嚴重。軟件開發人員必須在RTL設計完成之前開始有效工作。
使用外設“存根”的先前軟件開發方法不再能夠充分代表現代的多處理器,多總線架構。如果沒有早期的SystemC TLM原型,該軟件的開發完全獨立于硬件團隊設計,從而產生了顯著的集成風險。在設計過程的尾端進行集成使得上市時間變得非常難以預測。
使用FPGA原型來實現早期的軟件和系統硬件集成只能適度地改善計劃,因為這樣的原型仍然來得太晚。在這個階段,RTL設計發生了變化?甚至是次要的?整合所遇到的問題需要非常耗時。
同樣,SystemC TLM原型可以在幾個月前開始有效的軟件開發。可以將與硬件相關的軟件(例如RTOS)移植到模型中,而無需連接各個引腳。應用軟件 ??這與硬件無關?可以使用TLM作為數據流模型開發和移植。
7.當使用RTL原型協同驗證軟件太慢時,您無法驗證是否有足夠的信心確保沒有錯誤。
Qualcomm舉了一個這個問題的例子。維特比解碼器在20ms內執行一個數據包,但需要6個小時來模擬C/RTL級別。 Qualcomm估計必須模擬1,000個數據包以達到合理的置信水平,但認為必要的6000小時的模擬時間是不切實際的。
SystemC ESL設計可以與硬件相關的軟件共同驗證硬件架構比RTL快1000倍以上,具有周期精度。維特比解碼器可在不到6小時內驗證,而不是6,000小時。通過使用定時和協議無關的仿真,可以更快地共同驗證與硬件無關的軟件,例如應用軟件。
8.當您的團隊想要建立或已經維護時這是一個本土化的系統級設計環境,它將重要的工程資源和預算從創收設計中轉移出來。
構建和維護自行開發的ESL設計環境既昂貴又不提供戰略分化。自行開發的ESL設計環境與本土邏輯綜合或布局布線工具一樣具有經濟意義?
此外,許多歷史悠久的ESL設計環境利用C或C ++方言,與SystemC不同,它們不具備描述真實所需的時間,位精度和并發性概念。 RTL設計人員和嵌入式軟件開發人員所需的世界行為和性能。更糟糕的是,沒有標準的C/C ++建模方法,導致缺乏可用的模型,難以共享和重新使用那些可用的模型。
這兩個問題的解決方案是部署商用的SystemC ESL設計環境。提供商確保該工具和您始終處于SoC設計自動化的前沿。
9.當您在日程安排上失眠,第一次成功,設計和掩蓋成本超過跑?你想知道如何繼續與其他領先的SoC公司競爭。
解決方案很簡單。采用與領先的SoC設計人員已經使用的相同的SystemC ESL方法。
電子系統級設計和驗證方法的采用正在加速。 ESL設計工具的需求受復雜多處理器設計的挑戰驅動,其中一半以上的功能在嵌入式軟件中實現,而SystemC則使ESL設計得以快速采用。
今年將遠遠超過使用ESL設計方法的100個SoC設計。這種方法最終超越了它的采用鴻溝,因為SoC設計遇到了自己的鴻溝?系統級設計生產力鴻溝。
Mark Creamer是CoWare公司的副總裁。
-
soc
+關注
關注
38文章
4212瀏覽量
219179 -
ESL
+關注
關注
1文章
74瀏覽量
21421 -
systemc
+關注
關注
2文章
25瀏覽量
14594
發布評論請先 登錄
相關推薦
如何在ModelSim下用SystemC的做驗證?
ARM RealView ESL API v2.0開發人員指南
Systemc From The Ground Up
![<b class='flag-5'>Systemc</b> From The Ground Up](https://file.elecfans.com/web2/M00/48/AD/pYYBAGKhtBaAZfaMAABB-oHQizE494.jpg)
基于SystemC事務級的建模仿真研究
在SoC設計中采用ESL設計和驗證方法
片上網絡的SystemC建模研究
![片上網絡的<b class='flag-5'>SystemC</b>建模研究](https://file.elecfans.com/web2/M00/49/77/pYYBAGKhtFKAAg-qAAAPJQ-7Yyk335.jpg)
ESL設計的流程是什么
ESL設計的特點有哪些
SystemC中的模塊與進程
SystemC中的數據類型概念
![<b class='flag-5'>SystemC</b>中的數據類型概念](https://file1.elecfans.com/web2/M00/AD/E3/wKgZomVDUMCAESmeAACLV_CLDJM584.jpg)
評論