TLM驅(qū)動式新方案探討

　　引言

　　Cadence設(shè)計系統(tǒng)公司提供一種全面的SystemC TLM驅(qū)動式IP設(shè)計與驗證解決方案，包括方法學(xué)指南、高階綜合、有TLM感知的驗證以及客戶服務(wù)，推動用戶向TLM驅(qū)動設(shè)計與驗證流程轉(zhuǎn)變。

??????? 下一個抽象級別建立在事務(wù)級建模(TLM)基礎(chǔ)之上。創(chuàng)建TLM IP作為黃金源碼后，設(shè)計團隊可簡化IP創(chuàng)建和復(fù)用，在功能驗證上節(jié)省人力物力，并減少bug。設(shè)計迭代減少，原因是TLM驗證比RTL驗證快得多，且架構(gòu)選擇在RTL驗證進行之前就能得到確定。此外，事務(wù)級模型可用于軟硬件協(xié)同驗證，并可組成用于早期軟件開發(fā)的虛擬平臺的一部分。所有這些優(yōu)勢將大幅提升設(shè)計效率。

　　TLM通過函數(shù)調(diào)用而非信號或線路進行模塊間通信。它允許用戶分析讀或?qū)戇@些事務(wù)，而不用擔(dān)心底層邏輯的實現(xiàn)和時序。SystemC是開發(fā)可復(fù)用、可互用TLM IP的最佳語言標(biāo)準(zhǔn)。此外，因為SystemC建立在C++基礎(chǔ)上，它還允許對C語言算術(shù)函數(shù)的完全復(fù)用。開放SystemC行動(OSCI)為TLM模型定義了若干抽象層，分別是程序員視角(無定時)模型、寬松定時模型和近似定時模型。

　　要求對RTL進行改變的關(guān)鍵難題

　　在RTL中，有限狀態(tài)機的結(jié)構(gòu)要進行充分描述。這意味著，在編寫RTL時需關(guān)注微架構(gòu)詳情，如存儲器結(jié)構(gòu)、流水線、控制狀態(tài)或最終實現(xiàn)中使用的ALU等。 這一要求導(dǎo)致更長、可復(fù)用性更低的設(shè)計與驗證流程。

　　有時當(dāng)TLM用于當(dāng)前流程時，現(xiàn)有的基于RTL的流程需要進行兩次設(shè)計意圖手工輸入——一次在系統(tǒng)級、一次在RTL級。這種過程粗笨低效且易出錯。架構(gòu)直至產(chǎn)生RTL后才能確定，而重新確定IP目標(biāo)成本很高。一個真正的TLM驅(qū)動式設(shè)計與驗證流程將只需要一次設(shè)計意圖簡單的表達，并提供一條自動化的轉(zhuǎn)換方法。

　　從RTL開始查找和解決架構(gòu)問題過程長，代價高

　　RTL驅(qū)動式設(shè)計方法學(xué)的一大問題是，一種架構(gòu)是否能實現(xiàn)，直到建立了RTL并對其進行驗證后才能確認。由于RTL是架構(gòu)的直接表示，大部分RTL設(shè)計師不得不同時探究功能正確性、架構(gòu)和設(shè)計目標(biāo)。這導(dǎo)致很長的周期，始于做出架構(gòu)決定，終止于驗證功能性。通常，設(shè)計與驗證團隊會發(fā)現(xiàn)需要修改架構(gòu)的功能性bug，每次發(fā)現(xiàn)這樣的bug就需要重新開始整個周期。

　　在RTL上復(fù)用IP設(shè)計限制了架構(gòu)靈活性

　　當(dāng)今SoC中，可能有高達90%的IP模塊來自以前項目的復(fù)用。但是，當(dāng)IP的黃金源碼為微架構(gòu)級別時，復(fù)用是很困難的。重定RTL IP的微架構(gòu)目標(biāo)費力且容易出錯。目標(biāo)系統(tǒng)應(yīng)用可能差別很大，意味著不通過重新架構(gòu)，僅通過簡單復(fù)用，新的SoC設(shè)計目標(biāo)是不能達到的。例如，RTL設(shè)計師可能需要將設(shè)計重新分割成RTL塊、改變流水線級數(shù)、或創(chuàng)建新的存儲器架構(gòu)，因為在原有IP中，這些微架構(gòu)詳情都是固定和預(yù)先決定的。

　　RTL功能驗證時間比當(dāng)前技術(shù)的最高吞吐量增加得更快

　　在很多SoC項目中，功能驗證已成為主要瓶頸。RTL功能驗證開始時，在系統(tǒng)級的大量驗證投入已然損失。雖然驗證規(guī)劃、指標(biāo)驅(qū)動式驗證等方法使設(shè)計團隊尚能應(yīng)付當(dāng)前的大部分驗證難題，但時間限制和日益增多的門數(shù)正在使驗證變得難以為繼。RTL功能驗證所需時間可能隨設(shè)計的增大而呈指數(shù)式增長，因為相互作用的各種模式及該IP需要測試的許多軟硬件配置導(dǎo)致了各種極端情形，它們也需要進行驗證。

　　RTL是有精確時鐘周期的，涉及的代碼行遠多于TLM邏輯。對RTL模型進行仿真時，仿真器檢查所有事件或時鐘周期，即使在協(xié)議級上并未發(fā)生任何重大情況。仿真器要在微架構(gòu)詳情上浪費大量機器周期，而這些需要在架構(gòu)確定后才能確認。TLM仿真在更高抽象級別進行，能更早完成，并提供更高性能。

　　TLM正是需要的解決方案

　　TLM驅(qū)動的設(shè)計和驗證流程可實現(xiàn)在功能級別上描述IP，然后在快速仿真中驗證事務(wù)的功能行為。TLM流程的主要優(yōu)點包括能更快創(chuàng)建設(shè)計;減少了黃金源碼中的代碼行;bug更少;表達設(shè)計意圖更容易，且僅需一次;更快的仿真和調(diào)試;功耗預(yù)估可更早進行;支持軟硬件協(xié)同驗證;可將模型納入虛擬平臺;RTL生成前可進行架構(gòu)驗證;在RTL驗證中可復(fù)用TLM驗證IP;無需微架構(gòu)重新設(shè)計即可進行IP復(fù)用;ECO模式下產(chǎn)生的RTL變化很小。

　　基于TLM的流程與高層次綜合(HLS)配合，可將抽象級別提高。這是大約15年前設(shè)計師轉(zhuǎn)向RTL后的又一次重大轉(zhuǎn)變，根據(jù)之前的經(jīng)驗，這次轉(zhuǎn)變有可能使設(shè)計效率呈現(xiàn)數(shù)量級的提升(見圖1)。

?

　　下面幾部分描述了TLM驅(qū)動式設(shè)計和驗證流程的具體屬性和優(yōu)勢。

　　創(chuàng)建TLM作為黃金源碼

　　——更快的IP創(chuàng)建與設(shè)計IP復(fù)用

　　與RTL不同的是，TLM不描述最終實現(xiàn)的微架構(gòu)詳情。不描述微架構(gòu)詳情大幅提高了TLM設(shè)計在要求各不相同的多個項目間的可復(fù)用性，因為相同的TLM IP可重新定為不同微架構(gòu)的RTL代碼。而且，得益于更高的抽象程度，正確地創(chuàng)建功能要容易得多。TLM模型具有的代碼行比對應(yīng)的RTL模型要少得多，從而在最終設(shè)計中實現(xiàn)了編碼效率和品質(zhì)的同步提高。

　　開發(fā)與維護作為IP模塊黃金源碼的TLM所需的綜合和驗證解決方案，需要產(chǎn)生有品質(zhì)保證的結(jié)果并驗證其正確性，且無須編輯RTL或門級設(shè)計。這使設(shè)計團隊在TLM環(huán)境內(nèi)就能做出所有決定，并可通過將TLM源碼復(fù)用于系統(tǒng)來約束完全不同的其他設(shè)計。

　　SystemC是描述事務(wù)級設(shè)計的最佳標(biāo)準(zhǔn)，并連接到實現(xiàn)，提供了最好的可復(fù)用機會。它可對硬件的并發(fā)特性進行建模，并針對進程、管腳、線程和控制邏輯描述定時或非定時的行為。TLM 1.0和2.0標(biāo)準(zhǔn)提供了創(chuàng)建可互用IP模型的能力。最終，需要有一個合格的可綜合TLM IP庫，及可綜合TLM標(biāo)準(zhǔn)(或事實上的)子集。