《電子技術(shù)應(yīng)用》
您所在的位置:首頁 > 可編程邏輯 > 業(yè)界動態(tài) > 一種基于總線的可重用驗證平臺研究

一種基于總線的可重用驗證平臺研究

2008-05-29
作者:詹文法1, 李 麗2, 程作

  摘 要: 提出了一種基于總線的可重用驗證平臺" title="驗證平臺">驗證平臺結(jié)構(gòu),。該結(jié)構(gòu)在傳統(tǒng)的模塊化和抽象技術(shù)的基礎(chǔ)上,,采用了層次化的片上總線結(jié)構(gòu),同時引入了參數(shù)化" title="參數(shù)化">參數(shù)化的設(shè)計方法,,使可重用性" title="可重用性">可重用性進(jìn)一步提高,。實驗結(jié)果表明,,使用此方法構(gòu)建的驗證平臺,,可重用率至少可達(dá)60%,驗證效率提高約35%,。
  關(guān)鍵詞: 驗證平臺 可重用性 待驗證模塊 功能驗證


  隨著集成電路設(shè)計規(guī)模和設(shè)計復(fù)雜度的不斷增加,,傳統(tǒng)的功能驗證(Functional Verification)方法由于存在測試集(Test Suite)過于龐大、執(zhí)行時間過長等缺點,,已經(jīng)無法提供足夠的性能來檢查系統(tǒng)所有功能的正確性,。同時,基于IP重用的系統(tǒng)芯片SoC(System on a Chip)設(shè)計方法學(xué)的出現(xiàn),,也對傳統(tǒng)驗證方法提出了新的挑戰(zhàn),。在缺乏足夠相關(guān)專業(yè)知識的情況下如何有效驗證第三方提供的IP;如何對單個IP以及系統(tǒng)集成后的SoC進(jìn)行驗證并提高驗證效率等,,都是SoC驗證工程師所面臨的難題[1~2],。
  傳統(tǒng)的方法是設(shè)計者提供待驗證元件DUV(Design Under Verification)的驗證平臺,輸入測試向量,,驗證測試結(jié)果是否正確,。這種方法的缺陷在于,對于不同的DUV需要開發(fā)不同的驗證平臺,。SoC設(shè)計是一種面向集成的設(shè)計,,包含模塊(即IP)設(shè)計和系統(tǒng)集成兩個部分。因此,,傳統(tǒng)的SoC驗證需要開發(fā)兩個驗證平臺:IP單獨驗證平臺和SoC系統(tǒng)集成驗證平臺。驗證平臺的開發(fā)本身需要時間,,不利于產(chǎn)品的快速面市,,而且也很難保證設(shè)計的驗證平臺本身100%的正確。如何提高這兩個驗證平臺的開發(fā)效率也就成了驗證的難點,。
  關(guān)于驗證平臺的研究,,目前主要集中在三個方面:提高驗證元件的抽象層次[2][3][5];提高驗證元件的可重用性[3~6]和提高驗證過程的自動化實現(xiàn)[5~7],。提高驗證元件的抽象層次,,可以更早地發(fā)現(xiàn)設(shè)計錯誤,減少系統(tǒng)的開發(fā)時間,;提高驗證元件的可重用性,,可以減少驗證平臺的開發(fā)時間;提高驗證過程的自動化實現(xiàn),,可以加大驗證過程的運行效率,。以上三種方法都可以有不同程度的提高驗證效率,然而其開發(fā)過程都是針對特定的DUV的,。同一種DUV或其衍生系統(tǒng),,可以用上述方法開發(fā),。但對于不同的DUV,就需要重新設(shè)計驗證平臺,。例如對ROM和CPU的驗證,,就需要設(shè)計兩種不同的驗證平臺,對不同的系統(tǒng)芯片更是如此,。
  本文正是在傳統(tǒng)方法的基礎(chǔ)上,,提出了一種基于總線的可重用驗證平臺結(jié)構(gòu),在傳統(tǒng)的抽象和模塊化方法的基礎(chǔ)上,,采用層次化的片上總線結(jié)構(gòu),,使驗證元件的開發(fā)基于特定的總線,只要總線不同,,驗證元件就不需要修改,。同時,為了進(jìn)一步提高可重用性,,采用了參數(shù)化的思想,。使用該方法構(gòu)建的驗證平臺,可以同時適用于IP單獨驗證和SoC系統(tǒng)集成驗證,,即不僅可以在不同的IP之間實現(xiàn)可重用,,而且在IP到SoC的集成也可以實現(xiàn)可重用。該驗證平臺極大地提高了驗證平臺的開發(fā)效率,。對于IP單獨驗證,,如果IP基于同一總線,驗證平臺開發(fā)時元件的重用率可以達(dá)到100%,,如果IP不是基于同一總線,,僅僅需要修改部分驗證元件。該驗證平臺同時還具有可擴(kuò)展性,、自動化,、可升級性和可維護(hù)性等特點。
1 基于總線的可重用驗證平臺結(jié)構(gòu)
  隨著IP標(biāo)準(zhǔn)化工作的進(jìn)行,,SoC的結(jié)構(gòu)趨于統(tǒng)一,,采用層次化的片上總線結(jié)構(gòu),SoC包括處理器總線,、系統(tǒng)總線和外設(shè)" title="外設(shè)">外設(shè)總線,,所有的IP組成SoC時,都是掛接在這三條總線上[8]的,。其結(jié)構(gòu)如圖1所示,。由圖可見,存儲器管理單元(CPU、MMU),、高速緩存,、主存儲器、仲裁器和IP分別接在處理器總線,、系統(tǒng)總線和外設(shè)總線上,,集成為SoC。
  基于特定的總線不同的IP可以實現(xiàn)重用,,IP可以集成為SoC,,是因為采用了層次化的片上總線結(jié)構(gòu),可以根據(jù)IP的種類將其分別掛接在處理器總線,、系統(tǒng)總線和外設(shè)總線上,。基于這種思想,,驗證平臺也可以采用層次化的片上總線結(jié)構(gòu),,如圖2所示。將驗證平臺分解成監(jiān)視器,、總線報告器(Bus Reporter),、驅(qū)動、系統(tǒng)服務(wù)等,,并分別掛接在處理器總線,、系統(tǒng)總線和外設(shè)總線上。本文介紹的驗證平臺是建立在VSIA IPBUS 2.0規(guī)范[8]的基礎(chǔ)上的,。只要參與驗證的模塊符合VSIA 的IP設(shè)計規(guī)范,,就可以直接使用該驗證平臺來驗證。對于不符合VSIA規(guī)范的IP,,在驗證前需要增加一層接口來封裝這個IP,,這層接口實現(xiàn)IP與VSIA協(xié)議的轉(zhuǎn)換。該驗證平臺在SOLARIS 8操作系統(tǒng)下開發(fā),,用BOURN shell腳本、RERL腳本和Verilog編寫,,仿真器采用Cadence公司的Verilog-XL,。

?


  驗證模塊可以根據(jù)需要加入驗證平臺。每次的驗證過程就是相應(yīng)的激勵作用于驗證平臺的過程,。驗證結(jié)果由驗證平臺產(chǎn)生,、檢驗和輸出。其中,,監(jiān)視器,、總線報告器、驅(qū)動、系統(tǒng)服務(wù)和激勵文件的開發(fā)采用抽象和模塊化原則,,具體可見參考文獻(xiàn)[2],、[4]中介紹的方法。
  監(jiān)視器用于檢查總線上的數(shù)據(jù)傳輸,,報告接口上關(guān)鍵信號的變化,。驗證平臺提供的標(biāo)準(zhǔn)監(jiān)視器模板有:處理器總線監(jiān)視器模板、系統(tǒng)總線監(jiān)視器模板和外設(shè)總線監(jiān)視器模板,??偩€報告器用于報告總線上協(xié)議的錯誤和特定信號;同時也提供了相應(yīng)的標(biāo)準(zhǔn)模板,。監(jiān)視器和總線報告器可以根據(jù)需要打開或關(guān)閉,,可以通過控制參數(shù)值來實現(xiàn)。為了方便,,驗證平臺在設(shè)計時將該參數(shù)放到了驗證時的系統(tǒng)配置文件中,。
  激勵系列是由Verilog和C語言編寫的測試向量。嚴(yán)格來說,,激勵并不是驗證平臺的一部分,,因為激勵與要驗證的元件密切相關(guān),隨驗證元件的不同而不同,,但激勵是調(diào)用驅(qū)動來實現(xiàn)的,。驅(qū)動就如同軟件設(shè)計中調(diào)用系統(tǒng)API的應(yīng)用程序,所以激勵是進(jìn)行驗證不可缺少的部分,。
  為了方便操作,,驗證平臺在設(shè)計時,將一些經(jīng)常需要配置的部分設(shè)為參數(shù),,然后將這些參數(shù)放在配置文件中來設(shè)置,。通過配置文件可以配置驅(qū)動、監(jiān)視器和驗證選項,。配置文件和激勵文件都由驗證平臺的使用者編輯,。
  驗證平臺的另一個特點是靈活性。利用Cadence公司的Verilog-XL仿真器,,各待驗證元件的模型可以是多種形式的描述,。該驗證平臺可以進(jìn)行C/C++、Verilog和VHDL協(xié)同驗證,,支持的模型包括C/C++的PLI,、VPI或OMI模型、Verilog/VHDL行為級模型,、Verilog/VHDL RTL級模型或Verilog/VHDL門級模型以及管腳模型,。該驗證平臺還可以根據(jù)配置文件來調(diào)取同一IP的不同版本,實現(xiàn)版本控制。對于不同的描述,,激勵大都需要重寫,。使用該驗證平臺,使得同一激勵文件可以應(yīng)用設(shè)計的各個階段,,避免了重復(fù)編輯激勵文件,,從而在驗證環(huán)節(jié)上節(jié)省了大量時間。
  上述基于總線的可重用驗證平臺可以同時作為IP單獨驗證平臺和SoC系統(tǒng)驗證平臺使用,。驗證單個IP時,,為了提高驗證速度,只需將該IP所對應(yīng)的總線上的監(jiān)視器和總線報告器保留,,而將其他總線上的監(jiān)視器和總線報告器關(guān)閉,,以免消耗系統(tǒng)資源,影響驗證速度,。例如,,驗證主存儲器時,只需要保留系統(tǒng)總線上的監(jiān)視器和總線報告器,,將處理器總線和外設(shè)總線上的監(jiān)視器和總線報告器都關(guān)閉,。驗證SoC時,其系統(tǒng)驗證平臺的連接見圖2,。
  監(jiān)視器和總線報告器不驅(qū)動信號,,僅完成對信號的監(jiān)視,包括檢查協(xié)議的連續(xù)性,、時序和期望的響應(yīng)等,。從圖2中可以看出,監(jiān)視器和總線報告器的設(shè)計是基于特定總線的,,在構(gòu)成另一個SoC驗證平臺時,,只要特定的總線不變(如其處理器總線),若兩個SoC都使用M*Core CPU時,,處理器總線上對應(yīng)的監(jiān)視器和總線報告器就可以直接使用,,因此有很高的可重用性??紤]到監(jiān)視器可能會監(jiān)視內(nèi)部信號,,因此在邏輯綜合時,需要將這些要監(jiān)視的內(nèi)部信號保留,。驅(qū)動和系統(tǒng)服務(wù)都是基于外設(shè)總線的,為了進(jìn)一步提高可重用性,,將驅(qū)動和系統(tǒng)服務(wù)分解成一個個子任務(wù)來實現(xiàn),,任務(wù)之間互相獨立,當(dāng)修改一個任務(wù)時不會影響其他任務(wù),所有的任務(wù)合在一起就構(gòu)成了任務(wù)庫,。驅(qū)動所對應(yīng)的任務(wù)庫是基于外設(shè)總線的,。系統(tǒng)服務(wù)所對應(yīng)的任務(wù)包括驗證平臺的配置、驗證的自動化實現(xiàn)及驗證工具的調(diào)用等,。此時激勵文件的編寫就變成了調(diào)用任務(wù)庫中的任務(wù),,使激勵文件的編寫更簡單易行。
2 驗證平臺的數(shù)據(jù)結(jié)構(gòu)
  驗證平臺所涉及的文件和工具非常多,,采取合理高效的目錄管理有利于項目管理和設(shè)計數(shù)據(jù)的更新,,方便腳本的調(diào)用和配置,從而實現(xiàn)驗證過程的自動化,。為此將驗證平臺分為:工具目錄,、整體目錄(也稱系列目錄,F(xiàn)amily Directory),、模塊目錄和工作目錄四個子目錄,。
2.1 工具目錄
  該目錄下存儲驗證平臺運行時所需要使用的驗證工具以及與整體目錄的鏈接。該目錄下主要有兩個腳本文件:family_mapping和sim_env,。family_mapping文件指定芯片系統(tǒng)數(shù)據(jù)映射路徑,,sim_env文件提供驗證平臺的入口,文件包含對Verilog-XL仿真器工具,、代碼覆蓋率工具等調(diào)用接口,,并通過shell語言的文本過濾命令sed和awk,提取目錄和文件,,以便構(gòu)建完整的驗證平臺,。其工作原理是:從模塊目錄中提取驗證所需的模塊文件(.v)和從模板產(chǎn)生測試文件(test.v),并將這些文件名和驗證時所需要的工具和相應(yīng)參數(shù)全部輸出到一個文件中,,即驗證所需要的所有元件全部在該文件中,,用腳本調(diào)用該文件就可以完成驗證過程。驗證平臺的可重用性主要體現(xiàn)在本目錄,。在該目錄中,,使用了參數(shù)化的思想來達(dá)到重用的目的。使用者可以通過配置參數(shù)來建立所需要的驗證平臺,。這是該驗證平臺的特點之一,,也是其與傳統(tǒng)驗證平臺的不同之處。
2.2 整體目錄
  建立當(dāng)前驗證平臺所需的信息存儲在整體目錄中,,包括可重用的代碼信息(如監(jiān)視器和總線報告器等),、系統(tǒng)服務(wù)、輔助文件,、內(nèi)部鏈接等,。驗證平臺的可升級性主要體現(xiàn)在這個目錄中,,當(dāng)SoC升級或做部分修改時,其相應(yīng)的驗證平臺就需要調(diào)整,,如在SoC升級為后續(xù)衍生產(chǎn)品的驗證中,,系統(tǒng)服務(wù)就需要修改,而此時系統(tǒng)服務(wù)可以與原來有不同的實現(xiàn),,但必須有相同或相似的接口和參數(shù),。這樣,激勵文件和腳本文件就可以不用修改,,從而實現(xiàn)修改程度最小化,。
2.3 模塊目錄
  該目錄包括當(dāng)前需要驗證的設(shè)計的源代碼" title="源代碼">源代碼及相關(guān)信息。對于集成電路來說,,按照設(shè)計流程可以劃分為系統(tǒng)級設(shè)計,、RTL級設(shè)計、門級設(shè)計,、布局布線設(shè)計,,因此模塊目錄可以相應(yīng)地劃分為以下子目錄:系統(tǒng)級源代碼、RTL級源代碼,、門級源代碼和布局布線級源代碼等,,每一個子目錄中存儲相應(yīng)設(shè)計階段的代碼,如RTL級源代碼存儲在RTL級源代碼目錄下,。需要做某個階段的驗證時,,只需要將驗證參數(shù)設(shè)置成該階段,就可以調(diào)用該階段的代碼,。
2.4 工作目錄
  該目錄是驗證工程師的操作目錄,,是驗證平臺和驗證工程師的接口。在驗證過程中,,驗證工程師編寫的激勵文件,、運行仿真以及最后的錯誤分析等都在該目錄下進(jìn)行。對驗證工程師來說,,該目錄是惟一可寫的目錄,。工作目錄又可以進(jìn)一步分為驗證配置文件、文本信息及波形文件,、驗證代碼和驗證腳本等四個子目錄,。驗證配置文件目錄存儲配置文件,驗證工程師配置驗證平臺只需在該文件中配置相應(yīng)參數(shù)即可,。驗證代碼的編寫存儲在驗證代碼目錄中,,對應(yīng)于不同階段的設(shè)計,驗證也可以分為相應(yīng)階段的驗證:系統(tǒng)級驗證,、RTL級驗證,、門級驗證和布局布線后驗證,。類似地,不同階段的驗證也可以通過設(shè)置參數(shù)來實現(xiàn),。文本信息及波形文件目錄存儲驗證時產(chǎn)生的文本文件和波形文件,用于分析驗證情況和追查錯誤信息等,。驗證腳本目錄用于存儲驗證平臺的腳本,,該腳本用于自動化地完成驗證過程。
  從平面結(jié)構(gòu)上看,,驗證平臺的目錄是由如上所述四種類型的目錄組成的,。而從立體結(jié)構(gòu)上看,它們之間又是有層次的,,這種層次結(jié)構(gòu)能比較直觀地反映設(shè)計版本信息和驗證階段信息,,從而有利于項目管理者推進(jìn)驗證進(jìn)度。驗證平臺建立好后,,模塊目錄和驗證目錄都通過鏈接集成在系統(tǒng)中,。整個驗證平臺的系統(tǒng)結(jié)構(gòu)如圖3所示,其中,,庫文件目錄中存放基本可重用模塊,,頂層目錄是一個項目的根目錄,基本配置文件中存儲可參數(shù)化測試平臺的配置信息,。雖然在文件的存儲結(jié)構(gòu)上,,模塊目錄和工作目錄等都在同一層次上,但各目錄以圖3的方式鏈接,,形成樹狀結(jié)構(gòu),。


3 可重用性的實現(xiàn)與可重用性分析
3.1 可重用性的實現(xiàn)

  可重用性的實現(xiàn)主要體現(xiàn)在以下幾個方面:采用驗證平臺配置文件、采用參數(shù)化的設(shè)計思想和基于總線的驗證平臺結(jié)構(gòu),。分述如下:
  (1)所謂驗證平臺配置文件,,是指用來對驗證平臺進(jìn)行配置的文件。在驗證平臺中需要使用哪些模塊(包括源碼和驗證文件等)和驗證工具等,,可以直接由驗證平臺配置文件來指定,。這樣做的好處是驗證工程師在構(gòu)建另一個新的驗證環(huán)境時,只需要修改驗證平臺的配置文件,,而不需修改其他部分,,提高了驗證平臺的建立時間,縮短了驗證周期,。
  類似于DOS操作系統(tǒng)中的配置文件,,當(dāng)驗證工程師不對配置文件進(jìn)行配置時,自動使用默認(rèn)配置,,使修改的程度最小化,。因為驗證平臺之間許多配置是一樣的,,只要將這些相同的部分作為默認(rèn)值,需要修改的部分就很少了,。配置文件中的配置信息至少包含所使用的驗證工具,、驗證工具的配置、需要驗證的設(shè)計源碼,、用來驗證的測試代碼,、驗證結(jié)果的輸出配置、驗證時的出錯處理和環(huán)境變量的配置等,。由于需要配置的參數(shù)比較多,,可以將上述配置文件分為幾個,需要經(jīng)常改動的放在一個文件,,不需要經(jīng)常改動的放在另一個文件,。例如,可以將配置文件分成configuration和directory兩個文件,。configuration文件用于說明當(dāng)前驗證平臺的構(gòu)成情況,;directory文件主要用于說明構(gòu)成平臺的模塊信息。
  同時,,為了實現(xiàn)驗證過程的快速配置,,可以對上述兩個配置文件提供一個模板。一方面,,當(dāng)驗證一個設(shè)計時,,只需要修改該模板中的部分變量,就可以進(jìn)一步加速驗證平臺的建立,;另一方面就使用模板為腳本提供了一個標(biāo)準(zhǔn)的接口,,使驗證過程的自動化實現(xiàn)成為可能。
  (2)該驗證平臺的另一個特點是使用了參數(shù)化的設(shè)計思想,,具體實現(xiàn)包括驗證平臺建立的參數(shù)化和驗證過程的參數(shù)化,。驗證平臺建立的參數(shù)化為建立驗證平臺提供了方便,如驗證工程師可以通過配置參數(shù)很容易實現(xiàn)驗證平臺中各元件的增加和刪除,,也可以通過配置參數(shù)實現(xiàn)不同驗證工具之間的切換等,。驗證過程的參數(shù)化是指驗證工程師可以通過配置參數(shù)很容易地控制驗證流程,進(jìn)行各階段的驗證,,從而提高驗證速度,。如通過配置參數(shù)實現(xiàn)RTL級源代碼和RTL級驗證代碼的調(diào)用。對于驗證平臺中的環(huán)境變量,、接口參數(shù)等需要經(jīng)常使用而且又經(jīng)常需要修改的變量,,采用參數(shù)化的設(shè)計思想,其具體取值由驗證工程師在配置文件中指定,。
  (3)基于總線的驗證平臺結(jié)構(gòu)能夠進(jìn)一步提高該驗證平臺的可重用性,。首先,,在不同的IP單獨驗證時有很好的可重用性。如果兩個不同的IP是基于同一總線的,,第二個IP可以直接放在該驗證平臺中驗證,,而不需要修改驅(qū)動、系統(tǒng)服務(wù),、激勵文件和腳本等,。其次,這種基于總線的驗證平臺在驗證SoC衍生產(chǎn)品時有很好的可重用性,。因為這種系列產(chǎn)品所對應(yīng)的總線是不變的,因此,,監(jiān)視器和總線報告器可以直接重用,,如果設(shè)計得當(dāng),即使衍生產(chǎn)品的系統(tǒng)服務(wù)和驅(qū)動實現(xiàn)過程不一樣,,有同樣或相似的接口和參數(shù),,激勵和腳本也可以重用。
3.2 驗證平臺的可重用性分析
  (1)在不同IP模塊單獨驗證平臺間可以有很高的可重用性,。兩個不同的IP塊驗證時,,如果它們是基于同一總線的,驗證第二塊IP時,,可以放在第一塊IP的驗證平臺中直接驗證,。此時,是完全可重用的,,而且可重用率達(dá)到100%,;如果兩塊IP是基于不同的總線的,驗證第二塊IP時,,只需修改總線功能模型,,而對其中的激勵、系統(tǒng)服務(wù),、驅(qū)動和監(jiān)視器都不需做任何修改,,五種基本元件只需修改一種,而可重用率仍可達(dá)到80%,。如果將SoC中的處理器總線,、系統(tǒng)總線和外設(shè)總線的總線功能模型全部設(shè)計好,以后的IP單獨驗證平臺的設(shè)計就變成了僅僅是選擇不同總線功能模型的過程,。
  (2)從IP模塊單獨驗證平臺到SoC系統(tǒng)驗證平臺的設(shè)計過程中具有很高的可重用性,,監(jiān)視器可以完全重用,但這需要在芯片邏輯綜合時,,將監(jiān)視器所監(jiān)視的內(nèi)部信號保留,。如果驅(qū)動的功能是產(chǎn)生芯片級管腳信號,,驅(qū)動也可以重用。系統(tǒng)服務(wù)也可以被重用,,兩個驗證自動化的過程不一定要同樣地實現(xiàn),,但必須要有統(tǒng)一的接口。IP單獨驗證平臺的激勵可以完全重用于SoC系統(tǒng)驗證平臺的激勵文件中,。即只要設(shè)計合適,,IP模塊單獨驗證平臺中的監(jiān)視器、系統(tǒng)服務(wù),、激勵可以被完全重用,,驅(qū)動的可重用性則需要根據(jù)IP模塊在SoC中所處的位置和所起的作用來決定,總線功能模型會被實際的總線所代替,,五種基本元件中,,至少有三種可被完全重用,可重用率至少可達(dá)60%,。
  (3)在不同的SoC系統(tǒng)驗證平臺中有很高的可重用性,。本文所提出的驗證平臺結(jié)構(gòu)是基于總線的。因此不同的SoC系統(tǒng)驗證平臺中的可重用性也取決于SoC本身所采用的總線,。如果兩個不同的SoC采用完全相同的總線,,即它們具有完全相同的處理器總線、系統(tǒng)總線和外設(shè)總線,,若設(shè)計和該設(shè)計的派生設(shè)計的驗證平臺,,此時可達(dá)到驗證平臺的完全可重用,即可重用率為100%,;如果兩個不同的SoC采用完全不同的總線,、在第二個SoC系統(tǒng)驗證平臺中則可以重用第一個SoC系統(tǒng)驗證平臺中的監(jiān)視器、系統(tǒng)服務(wù)和激勵,,可重用率仍可達(dá)到60%,。
4 實 驗
  實驗元件選自合肥工業(yè)大學(xué)微電子設(shè)計研究所自主開發(fā)的系統(tǒng)芯片HGD2112和HGD3118,實驗環(huán)境:Sun Solaris 8 操作系統(tǒng),,Pentium IV 1.7處理器,,256MB內(nèi)存,gcc編輯器,,B shell腳本語言,。該驗證平臺成功地驗證了上述兩個系統(tǒng)芯片。兩個項目驗證的實際開銷和節(jié)約開銷如表1所示,。 由于HGD3118和HGD2112是兩種不同的系統(tǒng)芯片,,其驗證平臺相似性較少,但如果使用該驗證平臺來驗證這兩種系統(tǒng)芯片的衍生產(chǎn)品,其驗證效率可以進(jìn)一步提高,。如果設(shè)計合理,,驗證平臺的構(gòu)建所占時間基本可以忽略,驗證時間也僅為運行驗證過程的時間,。


  本文討論的基于總線的可重用性驗證平臺已經(jīng)實現(xiàn),。由于該結(jié)構(gòu)在很大程度上實現(xiàn)了高可重用、可升級,、可維護(hù)和自動化的設(shè)計思想,,為設(shè)計的規(guī)范化和標(biāo)準(zhǔn)化提供了一種可資借鑒的方法,已經(jīng)被設(shè)計公司借鑒,。使用該驗證平臺,,可以極大地提高驗證平臺的開發(fā)效率,從而最終提高集成電路的驗證效率,。
參考文獻(xiàn)
1 Anderson T. Your core-my problem? integration and verifi-cation of IP[J]. IEEE Design & Test, 2001,;18(5):170~171
2 Rashinkar P, Paterson P, Singh L. System-on-a-chip veri-fication methodology and techniques[M]. New York: Kluwer Academic Publishers,2002:45~87
3 Hawana M,Schutten R. Testbench design. A systematic app-roach, http://www.synopsys.com/sps/pdf/paper2.pdf,2003-12
4 Chang H, Cooke L. Surviving the SOC revolution-a guide to platform-based design[M]. Boston: Kluwer Academic Publishers, 2002:51~60
5 Bergeron J. Writing testbench-function verification of HDL models[M]. New York: Kluwer Academic Publishers, 2000:155~268
6 陸思安.面向系統(tǒng)芯片的驗證策略[J]. 微電子學(xué), 2002;3(4):265~268
7 韓俊剛. 系統(tǒng)芯片的混合驗證方法[J]. 西安郵電學(xué)院學(xué)報, 2002;7(1):12~17
8 On-chip bus development working group specification 1 ver-sion 1.0 (OCE 1 1.0) [S].VSI Alliance,1998

本站內(nèi)容除特別聲明的原創(chuàng)文章之外,轉(zhuǎn)載內(nèi)容只為傳遞更多信息,,并不代表本網(wǎng)站贊同其觀點。轉(zhuǎn)載的所有的文章,、圖片,、音/視頻文件等資料的版權(quán)歸版權(quán)所有權(quán)人所有。本站采用的非本站原創(chuàng)文章及圖片等內(nèi)容無法一一聯(lián)系確認(rèn)版權(quán)者,。如涉及作品內(nèi)容,、版權(quán)和其它問題,請及時通過電子郵件或電話通知我們,,以便迅速采取適當(dāng)措施,,避免給雙方造成不必要的經(jīng)濟(jì)損失。聯(lián)系電話:010-82306118,;郵箱:[email protected],。