應(yīng)對百萬門級系統(tǒng)級芯片驗證挑戰(zhàn)的可擴展解決方案

功能驗證是電子設(shè)計人員目前面臨的主要挑戰(zhàn)，無論是設(shè)計團隊還是驗證團隊，都將超過50%的時間用在糾錯上，因此這一領(lǐng)域的技術(shù)進展將對縮短產(chǎn)品上市時間產(chǎn)生重大影響。本文探討基于斷言的技術(shù)和改進的糾錯方法，以及為什么它們能夠以及如何應(yīng)對設(shè)計團隊面臨的重大挑戰(zhàn)，其目的是提高設(shè)計生產(chǎn)力、改進設(shè)計質(zhì)量、加快產(chǎn)品上市時間以及增加投資回報(ROI)。

目前的設(shè)計和驗證方法面臨的問題是驗證工作必須屈從于設(shè)計。出于幾項相關(guān)原因，現(xiàn)狀必須加以改變，特別是我們正在面對一個巨 大和復(fù)雜的電子系統(tǒng)。功能性錯誤是造成設(shè)計重復(fù)修改的首要原因。用于查找這些錯誤的功能驗證流程是設(shè)計流中目前面臨的最大瓶頸。一般而言，驗證工作在所有 設(shè)計活動中一般至少占有50%的份額。然而，驗證技術(shù)的發(fā)展步伐已經(jīng)遠遠落后于設(shè)計和制造能力，驗證鴻溝在進一步擴大(圖1)。這一驗證鴻溝是限制設(shè)計人 員充分發(fā)揮其生產(chǎn)力和設(shè)計能力的因素。為了彌合這一驗證鴻溝，驗證必須成為整體設(shè)計方法的一個內(nèi)在組成部分。

整個設(shè)計和驗證流必須實現(xiàn)結(jié)構(gòu)化，其基礎(chǔ)不僅是如何有利于設(shè)計工程師，而且還要考慮如何有利于驗證工程師，這對設(shè)計分工、模塊大小、設(shè)計規(guī)則以及其它許多我們目前想當(dāng)然的事情都提出了新的要求。

在成功開展系統(tǒng)驗證方面面臨的另一挑戰(zhàn)仍然是測試基準。隨著設(shè)計規(guī)模的擴大，驗證復(fù)雜性正以指數(shù)級速度提高。盡管仿真能力總 是伴隨設(shè)計規(guī)模不斷提高的，但測試基準的復(fù)雜性則不然。其中部分原因是設(shè)計規(guī)模對設(shè)計的可觀察性和可控制性所產(chǎn)生的戲劇性效果，它增加了需要運行測試的次 數(shù)，而且這些測試的持續(xù)時間可能延長，如果哪個地方出了差錯，那么查找和發(fā)現(xiàn)原因的難度就會大大增加。

為了解決驗證鴻溝和測試基準問題，我們需要采用可擴展驗證解決方案，一方面它基于斷言的技術(shù)，另一方面，它覆蓋了驗證中的 多種抽象層次以及整個流程各個階段的驗證工具，功能驗證策略必須在每個設(shè)計層次以及開發(fā)流程的每個階段將驗證目標對準整個系統(tǒng)――其中包括數(shù)字邏輯、嵌入 式軟件以及混合信號內(nèi)容。

功能驗證危機

功能驗證的重要性日益提高，其根本原因就是設(shè)計規(guī)模和復(fù)雜性的不斷增長，其中包括設(shè)計中的軟件和模擬電路比例日益提高。規(guī)模 的擴大指的是數(shù)量巨大的晶體管以及系統(tǒng)級芯片上的門數(shù)?！秶H半導(dǎo)體技術(shù)線路圖》預(yù)測，系統(tǒng)級芯片到2006年將包含10億個晶體管。一片系統(tǒng)級芯片可能 包含數(shù)千萬門，那么出錯的可能性以及驗證任務(wù)的復(fù)雜程度相應(yīng)也會增加。

復(fù)雜性提高意味著更多性能多樣性，在單個芯片上實現(xiàn)更多的性能。元器件的多樣性包括高性能RISC CPU、數(shù)千兆位高速I/O、塊RAM、系統(tǒng)時鐘管理、模擬混合信號、嵌入式軟件、專用數(shù)字信號處理器(DSP)等。因此，這些元器件之間的接口對確保整 體功能和性能的重要性就變得日趨重要。

片上軟件和模擬器件的不斷增加不僅使系統(tǒng)復(fù)雜性日益加劇，而且也向傳統(tǒng)操作方式發(fā)出了挑戰(zhàn)。數(shù)字工程師必須遭遇并不熟悉的 模擬事項。許多硬件設(shè)計都需要通過固件和低層次軟件來驗證RTL功能性。這要求固件設(shè)計人員在硬件設(shè)計中發(fā)揮重要作用，并對硬件和軟件之間的相互影響作出詳細解釋。

我們對Collett國際研究公司2001-2003年間的研究數(shù)據(jù)進行了考察，結(jié)果顯示：2001年在所有故障和失敗 中，47%的故障與邏輯或功能錯誤相關(guān)。然而，在前10位故障原因中，只有一項屬于接口問題：混合信號接口，在整個芯片故障中只占4%。反觀2003年數(shù) 據(jù)，邏輯和功能故障的比例已經(jīng)攀升到67%，并且出現(xiàn)了另外三種故障范疇。模擬故障在芯片故障中占35%的份額，排名第二。混合信號接口故障所占比例則從 4%升至21%，硬件/軟件接口故障比例則占13%。

除了復(fù)雜性問題，我們必須解決原有系統(tǒng)和知識產(chǎn)權(quán)的重用問題，因為超過50%的設(shè)計和測試平臺都在重復(fù)使用，因此，任何有 意義的解決方案都必須支持所有主要語言――包括Verilog、VHDL、C++以及SystemC――這樣它才能在所有抽象層次上工作。開放標準確保舊 有設(shè)計和測試平臺得到重復(fù)使用，可以根據(jù)其絕對屬性選擇驗證工具，而并不是因為它們適合某家供應(yīng)商的工具環(huán)境。此外，由于可觀察和可控制難度伴隨設(shè)計復(fù)雜 性提高，糾錯方法必須能夠克服測試基準的復(fù)雜性。例如，設(shè)計規(guī)模擴大一倍，可觀察性將減半，可控制性也將減半，那么驗證難度大約提高4倍。

如上所述，為了應(yīng)對日益龐大的設(shè)計規(guī)模、復(fù)雜性和性能問題，驗證方法必須在不同工具和設(shè)計層級之間實現(xiàn)可擴展。它必須在不同驗證域之間實現(xiàn)擴展，能夠在模擬、協(xié)同驗證、仿真以及模數(shù)仿真之間實現(xiàn)通信。它不必局限于動態(tài)空間，但必須在靜態(tài)空間中實現(xiàn)自動移動。

例如，如果大型設(shè)計需要在門層次上開展大量修改工作，那么等效性檢查就是一項必須的要求。最后，只有采用更好的測試基準方法，才能夠創(chuàng)建更為有效的、更為充分的測試。

各工具之間的可擴展性

必備的解決方案應(yīng)包含一套工具，它們能夠協(xié)同工作形成一個從HDL模擬到電路內(nèi)仿真的完整路徑。這意味著我們需要更好的模擬 器和仿真器，才能在所有集成層次上加速驗證流程。工具之間的可擴展性也是必需的，因為不同驗證類型在不同的性能范圍提供不同的解決方案(圖2)。每套解決 方案都會在許多不同屬性之間交替使用，比如反復(fù)時間、性能、能力、糾錯可見性以及成本。

甚至連HDL執(zhí)行引擎也需要一整套解決方案。有些在塊層次上表現(xiàn)良好，有些則在芯片或系統(tǒng)層次上表現(xiàn)更好。例如，設(shè)計人員需 要使用高水平驗證工具對系統(tǒng)級DSP算法開展驗證，HDL軟件仿真器顯然無法完成這項工作。反過來說，在線仿真在芯片設(shè)計中并非是驗證相對較小子模塊的合 適解決方案，而HDL軟件仿真器則可能迅速輕松地完成同一任務(wù)。認識到哪些工具是處理手邊驗證任務(wù)的最優(yōu)選擇，繼而獲得這些工具，將有助于設(shè)計人員實現(xiàn)最 佳生產(chǎn)力。以下舉例介紹在設(shè)計的數(shù)字驗證過程中可以使用的各種技術(shù)。軟件和模擬混合信號驗證也存在類似連續(xù)體。

軟件模擬是模塊級驗證的理想選擇，因為其周轉(zhuǎn)速度非常迅速，糾錯能力較強。硬件/軟件協(xié)同驗證能夠?qū)⑶度胧杰浖腧炞C流程之中，為加速處理器、記憶體以及總線運算提供途徑。它也可以作為測試平臺開展硬件驗證。

基于處理程序的協(xié)同建模提供了大量多樣化解決方案，使系統(tǒng)驗證成為可能。協(xié)同建模適用于在高級、抽象測試平臺與載入仿真器的 整個芯片的RTL實施之間建立鏈接。在線仿真在真實系統(tǒng)中提供高能力和高性能驗證。仿真為設(shè)計人員帶來自信，確保他們的芯片將在實際系統(tǒng)中正確發(fā)揮功能。

形式驗證(等效性檢查)的能力和速度能夠確保在設(shè)計流后續(xù)階段作出的修改不會改變其意圖行為。有必要指出的是，高性能、硬件協(xié)助或軟件導(dǎo)向解決方案對在系統(tǒng)級環(huán)境中實現(xiàn)驗證完整性具有關(guān)鍵性作用。

各抽象層次之間的可擴展性

我們非常有必要推動某些方面的功能驗證工作向前發(fā)展，使其成為設(shè)計流程初步階段的一部分。為了實現(xiàn)這一點，我們必須利用更高層次模型和處理程序(圖3)使驗證工作變得更為抽象。

在設(shè)計流中前移驗證的好處在于：處于這個階段的模型的編寫速度較快，具有較大生產(chǎn)能力，因此可以通過建設(shè)性方式影響設(shè)計決策。抽象工作可以加速驗證進行，它能夠剔除無關(guān)信息，縮短開發(fā)時間，加快糾錯進程，并使得測試平臺更易重復(fù)使用。

就復(fù)雜的系統(tǒng)級芯片而言，如果所有事情都在RTL或門層次上完成則太過費時和困難，我們在這兒絕對有必要在設(shè)計中使用更為抽象的表示方法。這并不僅僅是針對設(shè)計的，也同樣有益于測試平臺。

這種多層次抽象戰(zhàn)略要想行之有效，不僅需要必要的工具支持，知識產(chǎn)權(quán)(IP)因素也同等重要。如果設(shè)計人員無法通過模型在各 個抽象層次之間切換并建立聯(lián)系的話，那么多抽象模擬就無用武之地。多抽象解決方案將技術(shù)與知識產(chǎn)權(quán)組合在一起。針對設(shè)計的主要接口使用一系列處理程序時， 分層次驗證才變得可能。它允許在各種抽象層次上混合各種設(shè)計說明。處理程序可以組合為一個測試平臺或環(huán)境，用于檢查某項實施是否符合高層次模型。

本策略的優(yōu)勢是它無需在一個抽象層次上包含所有模型。這種靈活性允許設(shè)計團隊混合并匹配在規(guī)定時間內(nèi)所能獲得的一切，提供相對于執(zhí)行時間的必要層次解析。

基于處理程序的接口可以將所有抽象系統(tǒng)模型鏈接至設(shè)計，提供一個理想的系統(tǒng)層次測試平臺。例如，運用基于處理程序的模擬，某 團隊可以在高抽象層次上作出系統(tǒng)定義。然后，它們將在高層次系統(tǒng)定義中提取某個層次或某個模塊，運用處理程序投入工作所必需的知識產(chǎn)權(quán)，替代它們進入更為 詳細的實施模型中。

他們可以在系統(tǒng)原位置處將模型作為即時測試平臺運行。該團隊就可以立即將現(xiàn)有測試平臺投入實際使用，從而向該模塊提供自然的刺激。其結(jié)果是，驗證生產(chǎn)力提高，設(shè)計信心提高。

抽象層次

系統(tǒng)級驗證所必需的可擴展解決方案應(yīng)在整個電子系統(tǒng)中支持抽象：模塊、子系統(tǒng)、完整芯片以及系統(tǒng)層次。

模塊層次：在模塊層次上，設(shè)計人員的關(guān)注重點是功能和時序的細節(jié)情況，這樣他們就能夠保證這些模塊符合技術(shù)規(guī)范，不存在明顯 問題。其目標是盡可能多地查找錯誤，因為這在設(shè)計流程中是查找這些錯誤的最廉價和最快速階段。模擬和數(shù)字交互作用在模塊層次上進行驗證。功能和代碼得到全 面演練，驗證移交應(yīng)考慮在這一階段進行。由于HDL仿真技術(shù)易于使用且具糾錯能力，因而成為理想的工具。

模擬/混合信號模 塊：系統(tǒng)級芯片設(shè)計的能力在不斷提升，模擬和混合信號元器件不斷加入其中，因此要求模擬環(huán)境能夠具備與數(shù)字邏輯相同的、必需的驗證功能。與模擬HDL行為 模擬以及模擬原始模塊的Spice模擬順利實現(xiàn)接口，允許數(shù)字和模擬元器件的模擬工作實現(xiàn)同步，并能夠在相同的糾錯環(huán)境中查看。

子系統(tǒng)層次：所有模塊均已驗證后，隨后進行模塊集成，涉及對各模塊組或整個芯片進行集成。在子系統(tǒng)階段，模塊間通信、控 制、時序和協(xié)議對功能而言具有重要意義；因此，檢查協(xié)議或應(yīng)用斷言以驗證總線處理程序的工具就能發(fā)揮作用。硬件斷言或仿真可以運用HDL、C或 SystemC 以及Verisity等其它高層次測試平臺語言布署在這一階段。

系統(tǒng)級芯片層次：系統(tǒng)級芯片層次驗證涉及各模塊與后端流程的其余部分進一步集成，其中包括設(shè)計的物理實現(xiàn)。在設(shè)計人員將較小模塊集成進入越來越大模塊的過程中，需要模擬的內(nèi)容日益增多，測試時間日益延長，并且需要開展更多模擬來驗證設(shè)計。

這對多種驗證方法提出了要求，比如芯片和系統(tǒng)功能測試。它還要求驗證布圖、時鐘樹或DFT插入會否引入意外更改。等效性檢查工具可以驗證整個大規(guī)模設(shè)計，并在每次修改設(shè)計后迅速糾錯，無需再運行眾多漫長的模擬。

除了等效性檢查之外，我們還可能在這一流程中使用硬件加速仿真器和多CPU并行仿真，以確保更改設(shè)計期間沒有造成任何破壞。 多CPU并行仿真將會縮短測試時間，獲得非常高的吞吐能力。就較長時間測試而言，出于驗證大規(guī)模芯片設(shè)計的能力考慮，硬件仿真是我們的首選方法。硬件加速 仿真器和多CPU并行仿真是互為補充的解決方案，可以在不同的環(huán)境中得到有效使用。

絕大多數(shù)系統(tǒng)級芯片器件都包含必須驗證的嵌入式軟件，其中包括應(yīng)用代碼、實時操作系統(tǒng)(RTOS)、器件驅(qū)動程序、硬件診斷以及啟動ROM代碼。功能仍然重要，但吞吐能力以及其它系統(tǒng)級事宜可能也需要獲得驗證。運行大量軟件通常意味著長時間模擬作業(yè)。

硬件/軟件協(xié)同仿真解決方案提供降低總體負擔(dān)的途徑，同時也提供高效能糾錯和分析環(huán)境。即便就較長運行時間而言，該設(shè)計可能也需要部分或全部移入硬件解決方案之中，但應(yīng)該保留相同或相當(dāng)?shù)募m錯環(huán)境，這樣就可以最大限度減少上述執(zhí)行環(huán)境中的遷移。

改進的糾錯解決方案

為支持可擴展驗證解決方案，糾錯工具必須實現(xiàn)集成，在各個抽象層次上保持前后一致，在各個可擴展性工具之間保持一致。其目標 是加快速度發(fā)現(xiàn)錯誤、跟蹤捕獲故障原因、修復(fù)故障，并最大限度縮短反饋時間，將反復(fù)回路減少到最低限度。目前，無論是設(shè)計團隊還是驗證團隊，都將超過 50%的時間用在糾錯上，因此這一領(lǐng)域的改進可能對縮短產(chǎn)品上市時間產(chǎn)生重大影響。

在系統(tǒng)層次上，由于抽象層次混雜，系統(tǒng)內(nèi)部存在的不同語義，因此糾錯工作變得更加復(fù)雜。在異類環(huán)境，比如硬件和軟件或數(shù)字 和模擬環(huán)境中，挑戰(zhàn)就會更為嚴峻。因此，信息不僅必須可用，而且必須在正確的語義背景下可用。同樣，利用多層次抽象，信息也必須在必需的抽象層次上可用。

例如，對軟件糾錯時，有關(guān)軟件程序執(zhí)行的所有信息都包含在硬件記憶體中，但沒有任何東西是隨時可用的。了解變量放置在何處 正是解決方案的發(fā)端。它還必須確定信息保存在哪個芯片之中以及芯片中的相對位置，假定它并非緩存或寄存器。在許多情況下，即使在這種時候，數(shù)據(jù)還可能因為 數(shù)據(jù)或地址交叉原因而未按邏輯排序。因此，獲得變量值就可能非常復(fù)雜。

為了化解這些挑戰(zhàn)，新的糾錯方法正在不斷推廣。例如斷言或檢查器，盡管其用途并未得到完全理解。另一個容易引起混淆的問題 則涉及覆蓋率問題。許多工程師并未認識到，滿足代碼覆蓋率標準并不意味著系統(tǒng)已經(jīng)得到適當(dāng)驗證。同樣，我們還必須使用功能覆蓋率或斷言覆蓋率等其它標準來 確認該設(shè)計已經(jīng)得到完全驗證。

今天，絕大多數(shù)工程師都在創(chuàng)建激勵源，并將其饋送進入執(zhí)行引擎之中，這樣他們就可以對產(chǎn)生的響應(yīng)進行分析(圖4)。在許多 情況下，他們對照參照模型對該設(shè)計的某項實施的波形進行比較，尋找不同之處。這是一種單調(diào)乏味且毫無把握的糾錯途徑，也正是眾多錯誤不被發(fā)現(xiàn)的原因所在。 我們很容易將注意力集中在手邊的問題，同時錯過這樣一個事實，即有些地方已經(jīng)出錯，或目前的測試平臺無法反映新的問題。

設(shè)計人員必須擺脫當(dāng)前的絕大多數(shù)糾錯方法，因為就本質(zhì)而言它們都是單調(diào)的、重復(fù)的且不可能行得通。在設(shè)計流程的稍后階段，等效性檢查可能是一項非常強大的工具。等效性檢查可用于對照參考模型測試實施情況，但它采用形式驗證的方法，而不是試圖通過模擬比較兩套波形。

最近，其它一些測試平臺組件已經(jīng)臻于成熟達到可用程度，比如生成器、預(yù)測器和檢查器等。它們允許自動生成測試預(yù)案，并對照期 望行為檢查響應(yīng)成果。其中最成熟的當(dāng)屬檢查器，也即斷言。現(xiàn)有兩種類型斷言，即依賴測試內(nèi)容的斷言和不依賴測試內(nèi)容的斷言。依賴測試內(nèi)容可以輕松插入現(xiàn)有 驗證方法中，無需其它工具支持；不依賴測試內(nèi)容的斷言則與生成器聯(lián)系，需要其它工具并改進驗證方法。

故事并不止于此，因為目前還有一些尚未精確定義的測試平臺組件，比如功能覆蓋率、測試計劃以及驗證管理等。盡管這種測試平 臺轉(zhuǎn)換尚需幾年時間才能完成，但一旦完成，人們夢寐以求的可執(zhí)行計劃規(guī)范就將實現(xiàn)，不過其方式已經(jīng)迥異于業(yè)界最初的預(yù)測。它不會用于自動執(zhí)行設(shè)計流程，但 將應(yīng)用于自動執(zhí)行驗證流程。

基于斷言的驗證

如前所述，測試平臺受到兩大獨立因素的制約：可控制性和可觀察性?？煽刂菩钥傻韧诩钤床迦牒鬁y試平臺激活設(shè)計中存在問題的能力。它與代碼覆蓋率存在非常密切的關(guān)系，也正是我們在運用代碼覆蓋率時必須小心謹慎的原因所在，因為它并未考慮測試平臺的其它方面因素。

問題的另一半則是可觀察性。故障一旦出現(xiàn)，兩件事情必須發(fā)生。首先是這一故障所產(chǎn)生的效應(yīng)必須傳播至主要輸出，隨后故障必須 被發(fā)現(xiàn)。對大多數(shù)測試平臺來說，接受驗證的主要輸出的數(shù)量非常少，因此我們會對許多問題視而不見。這正是斷言之所以強大的原因所在。斷言對可觀察性造成積 極影響，提供多項好處。它們能夠明確除錯的主要原因――而非次要或第三位原因――糾錯工作變得更為輕松和快速。這是因為它們能夠分散在整個設(shè)計之中，產(chǎn)生 實際的主要輸出，后者則自動檢查驗證對象的行為好壞。

這樣，測試平臺就不必再將這些錯誤效應(yīng)傳播至實際的主要輸出，使得測試平臺的開發(fā)變得更加容易。另外，我們還可以對大量數(shù) 據(jù)進行驗證，否則的話它們將被忽略。斷言還開展數(shù)據(jù)檢查，使得測試平臺更加有效。某項斷言一旦設(shè)計完成并被置入設(shè)計中，那么它就總是處在運行狀態(tài)。在許多 情況下，斷言檢查的東西并非測試的主要內(nèi)容，因此它們將會發(fā)現(xiàn)非預(yù)期故障。例如，在模塊測試階段插入的斷言在集成階段乃至系統(tǒng)層次測試中都會執(zhí)行其檢查功 能，這樣就可以提供更為廣闊的驗證覆蓋面。

最后，斷言使得測試的范圍更為寬廣。運用基于斷言的驗證技術(shù)的工程師經(jīng)常發(fā)現(xiàn)，其檢錯速度遠遠超過非斷言技術(shù)。這樣就可以 抵消編寫和放置斷言造成的總體開銷――約占3%總開銷時間以及10%總運行開銷時間。運用斷言的公司報告稱，在其所有程序錯誤中，大部分是通過斷言來發(fā)現(xiàn) 的，其糾錯時間也縮短了80%之多。

斷言可以嵌入設(shè)計之中，或者其規(guī)定內(nèi)容可以獨立于設(shè)計，并附加在設(shè)計中的各個點。是內(nèi)部還是外部則部分取決于誰在創(chuàng)建這一 斷言，比方說創(chuàng)建人員是設(shè)計人員還是獨立的驗證工程師。如果它們被嵌入設(shè)計之中，則主要驗證技術(shù)規(guī)范的實施。如果屬于外部開發(fā)，則將驗證技術(shù)規(guī)范的解釋， 或在某些情況下對技術(shù)規(guī)范本身進行驗證。因為嵌入式斷言實際上都是可執(zhí)行的注釋，因此它們可能放置在任何可以放置注釋的地方。

好處是注解現(xiàn)在變得更有價值，因為它們在發(fā)揮作用。注解包括期望行為的說明、設(shè)計人員作出的假設(shè)或針對期望用途作出的限制。它支持再利用，它提供有關(guān)設(shè)計的預(yù)期行為的所有各類信息，提供原設(shè)計人員的意圖。至少所有的第三方知識產(chǎn)權(quán)IP就應(yīng)該內(nèi)建接口上和用途方面的斷言。

目前，人們對斷言的主要興趣是如何進行模擬斷言，但這并非斷言的所有功能。斷言的基礎(chǔ)是一些名為屬性的更為基礎(chǔ)的東西。屬性 可以用于斷言、功能覆蓋標準、形式檢查器以及用于偽隨機刺激生成的約束生成器。屬性既可為模擬器也可為形式分析工具所用，它能夠?qū)㈧o態(tài)和動態(tài)驗證技術(shù)融入 一種方法中。隨著這一領(lǐng)域中標準的來臨，在今后數(shù)年中，運用屬性的工具預(yù)計將會迅速增長。

本文小結(jié)

設(shè)計團隊需要運用那些能夠在設(shè)計復(fù)雜性和多層次抽象之間擴展的工具改進現(xiàn)有方法?？蓴U展解決方案能夠幫助工程師開展他們目前能夠開展的工作，而且在相同時間范圍內(nèi)只會變得更好、更快且效率更高。它使得驗證工具對用戶更為友好，并能夠在設(shè)計過程中推入更多測試向量。

任何有效的系統(tǒng)驗證策略都必須提出這樣的前提條件，即系統(tǒng)實際上指的是整套系統(tǒng)，它包含的遠非數(shù)字邏輯那么局限。換而言之， 一套有意義的解決方案必須能夠解決數(shù)模信號混合問題，必須能夠提供為軟件、RTOS的驗證運行所必須依賴的環(huán)境，并將其聯(lián)系在一套統(tǒng)一的解決方案之中。

新的測試平臺組件正在進入今天的驗證方法之中，斷言的使用可能對質(zhì)量和速度產(chǎn)生戲劇性的影響，因為驗證工作可以利用斷言來 開展。此外，某些更新的測試平臺組件正在出現(xiàn)。所有這些新的組件都將受到屬性的驅(qū)動，既而操控和利用屬性。這是未來的發(fā)展方向，現(xiàn)在開始已經(jīng)變得異常光 明。這種自動化、基于屬性的驗證方法將推動驗證性能的提高，這也是縮短驗證鴻溝的必要條件。這事實上相當(dāng)于10年之前設(shè)計路徑曾經(jīng)享受過的綜合的好處。驗 證綜合還在發(fā)展之中，并將從根本上改變探討和處理驗證問題的方式。