Mentor Graphics仿真部門的產品營銷經(jīng)理VijayChobisa表示：“如果你設計了芯片并具有一些功能，但功能可能不能達到100％，你如今有一些選擇來解決這個問題。比如軟件，你可以在軟件中隱藏該硬件錯誤，以便你的芯片可以適用于某特定的應用程序?；蛘咝酒赡軣o法按照既定高速頻率運行，也許速度放慢，功能仍然有可能正常。然而，有了功耗，我們假設你設計的芯片具有一定的功耗，而你的芯片在特定的設備（無論是平板電腦還是智能手機）上都占用了兩倍或三倍的平均功耗，你就不能使用該芯片了，因為它不是為該設備的功耗設計的，它不適合該應用程序。我的理解是，在未來功耗驗證將比功能驗證更重要。”

Ansys-Apache的RTL電力業(yè)務高級副總裁兼總經(jīng)理VicKulkarni認同并指出，這就是為什么功耗驗證技術相繼出現(xiàn)在多域島（multi-domain islands），DVFS技術，或是像在電視領域依靠對像素進行功耗控制的技術?！皩τ谛酒?，封裝收斂成為一個問題，不幸的是，它產生的熱量是再生效應，會導致更多的動態(tài)電壓問題?！?/span>

由于有了功耗驗證，我們很少會錯過市場窗口。功耗在上市時間方面是一個相對較新的點，因為過去功耗經(jīng)常是在后續(xù)的芯片迭代中處理。如今這不可能了。

Chobisa說：“對于功能問題，您可能有一個軟件來修復。但對于功耗，你并沒有軟件來修復。你必須回到計劃階段，也許會因此錯過整個市場窗口。這就是主要問題所在?！?/span>

對于高級設計，特別是在移動市場中，從過去的幾個節(jié)點來看，功耗已經(jīng)成為一個急切需要考慮的問題。

Synopsys低功耗驗證研發(fā)部門總監(jiān)SrikanthJadcherla表示：“我還沒有看到有人長時間不去做低功耗設計或功耗驗證的工作。幾乎所有的芯片目前都在運用低功耗驗證方法，除了由外部管理功耗的小型ASIC。他們仍然需要對外部功耗事件做出反應，但是他們本身可能太小了而不能很好地自己管理功耗，這種情況也逐漸在減少。通用SoC則是另外一回事兒，它必須進行功耗驗證?！?/span>

早在20世紀90年代中期，設計師就專注于經(jīng)典的低功耗設計，大概有像乘法器和各種長度的指令解碼器這樣的功能。 Jadcherla說：“一個功能需要X瓦功耗，你想要減少到一半的功耗。這基本上就是所謂的電容下降了?！痹僬務勛詣訒r鐘門控技術，這幫助很多工具的電容大幅降低。Jadcherla指出“我們也從結構轉移到時間限制或時間依賴的功耗降低上。”

二十一世紀初，情況發(fā)生了轉變。Jadcherla創(chuàng)立的ArchPro等公司曾經(jīng)訪問了一些工程團隊，并建議他們驗證自己的低功耗芯片，包括硬件和軟件?！笆聦嵣?，當時很少有人相信我們。后來我們一直在提及它。我在2008年寫了一本關于如何構建低功耗驗證，如何量化覆蓋率的書。在2015年，我們看到功耗管理驗證的處理已經(jīng)相當成熟了。再次強調，你必須把低功耗從功耗管理中分離來看。如今，功耗管理主要涉及需要驗證的復雜的軟硬件交互。大多數(shù)SoC遵循兩個或三個原則。首先，最重要的是，在硬件/軟件/電壓的所有交互中實現(xiàn)的任何低功耗特性，都必須被證明在系統(tǒng)級別是有益的。相信我，這比聽起來要難得多，因為低功耗設計容易產生事與愿違的結果。其次，布爾代數(shù)是不同的。你在學校學到的，與實際上發(fā)生的常常相對。我們盡管花了大約10年的時間，才形成了UPF標準和成熟的設計方法，但我們也一直在取得進展。”

Cadence的產品驗證管理總監(jiān)AdamSherer指出，驗證的挑戰(zhàn)之一，是在設計的不同操作條件下測量動態(tài)功耗。“我們一直倡導以度量為導向的驗證，從功耗角度來生成驗證計劃。例如，我們的一個客戶，進行著功耗測量，在運行所有的回歸，針對給定的SoC進行了7000多次仿真。它不是一個單獨的測試或一組特定的測試，而是客戶希望在所有功能驗證中始終測量功耗?！?/span>

他補充說，功耗日漸成為功能驗證中不可或缺的要素，不能是事后才有的想法?！八仨毷羌傻模悄愕墓δ茯炞C程序的一部分。我上面給出的例子，他們的整個回歸測試都包括了功能驗證和功耗驗證，因為他們的設計依賴于功耗。如果你有一個依賴功耗的設計，那么你必須進行功耗驗證，而不是當作一個事后的考慮或只占有5％的測試，尤其是當你在使用一個UVM隨機化的環(huán)境。當你有機會觸發(fā)功耗的狀態(tài)跳轉，例如上電或者掉電，你最好在低功耗驗證的條件下進行，否則你無法模擬設計的實際運行，這是至關重要的地方。這意味著它同樣屬于正常的功能驗證流程，并保證低功耗驗證計劃。你必須能夠對其進行規(guī)劃，以涵蓋設計中適當?shù)臓顟B(tài)更改，你也需要確保它是完整的。我們有客戶，將功耗驗證流程從RTL仿真一致貫穿到后端仿真（包括pad功耗信息），即使在純數(shù)字芯片中，我們仍然需要模擬電源信號參與到管腳選通，這也需要功耗驗證的考慮”

雖然這些問題看似已經(jīng)很好理解，但這并不意味著在頂級半導體公司以外的每個設計團隊都會使用低功耗功能驗證。

Cadence低功耗產品營銷總監(jiān)KrishnaBalachandran說:“很多驗證團隊只在一些大型公司中可以建立起來。如果你談到方法論，即使是中國的一些新興小公司，或是亞洲很多地區(qū)，他們都不遵循驗證方法。他們做基本的功能驗證，總是會忘記功耗。所以他們并不會做一個徹底的工作，試圖弄清楚如何用功耗來驗證它，即使他們在實施方面采取了功耗驅動的設計實現(xiàn)流程。在采用低功耗設計方面，可行性考慮在前。為了能夠實施，他們必須滿足功耗。如今，某些情況下，一些小公司的驗證是由設計師而不是驗證工程師完成的，所以他們沒有方法論。但是他們意識到如果他們不這樣做，他們會有一些錯誤，那些錯誤可以直接對設計造成惡劣影響。因此，即使是較小的公司，也開始考慮采用包含功耗的驗證方法?！?/span>

Balachandran指出，在更高層次上，考慮到芯片驗證在設計的功能和功耗方面已經(jīng)變得非常復雜，一些與功耗相關的錯誤真的很難找到，這使得事情更具挑戰(zhàn)性。他接著說到：“這些與功耗相關的設計缺陷往往是一些邊界情況，即使驗證工程師在驗證時已經(jīng)有意考慮到功耗驗證的問題，這些缺陷還是很難捕捉到，這是一個很難解決的難題。許多很聰明的公司都表示，我們不能只用一把“錘子”來干活。那個錘子往往是仿真手段?，F(xiàn)在他們正在嘗試用更多的“錘子”，譬如形式驗證。這也是為什么一些低功耗的形式化技術變得非常重要了。形式化工具會掃描狀態(tài)機的功耗和設計，理解這些信號之間的相互作用，然后去自動生成斷言，并嘗試形式驗證。事實證明，信號與功耗狀態(tài)是相互對應的，設計也會處在對應的特定狀態(tài)。否則，根據(jù)設計描述和功耗要求，你的設計實現(xiàn)就是有缺陷的。這樣的事情越來越多，聰明的公司正在應用這種工具?！?/span>

他表示，有趣的是，在過去的兩三年里，至少在較大的公司，模擬技術（emulation）越來越多地用于功耗驗證?！澳氵€有一個可怕的工具——軟件，通過軟件可以控制一些功耗。所以，為了趕得上工期和項目要求，已經(jīng)無法單獨依靠仿真來完成功耗驗證了?！?/span>