隨著半導(dǎo)體行業(yè)朝著更先進的制程節(jié)點方向發(fā)展，靜態(tài)功耗已成為主要的設(shè)計限制因素。為此，亟需開發(fā)各種電源管理技術(shù)。例如，讓開發(fā)者可以創(chuàng)建多個電壓域，或者使用隔離單元將關(guān)斷的電源域與上電的電源域隔離。開發(fā)者可以在將信號電壓從一個域傳播到另一個域時，應(yīng)用電平轉(zhuǎn)換器來放大或縮小信號電壓，或者可以使用保留單元來更快地將寄存器恢復(fù)到關(guān)斷前的狀態(tài)。就像在指定功能設(shè)計意圖時需要用到硬件描述語言（HDL）一樣，這些電源管理技術(shù)也需要一種通用語言來指定功耗設(shè)計意圖，那就是統(tǒng)一電源格式（UPF）。

考慮到當今的SoC非常復(fù)雜且通常針對特定的應(yīng)用，為了設(shè)計和實現(xiàn)所需的功能并滿足時序和功耗要求，需要付出巨大的努力。但是，僅僅做到這些還是不夠。終端用戶總是渴望在最短的時間內(nèi)獲得最新的功能，這給IP開發(fā)團隊帶來了壓力。為了滿足產(chǎn)品上市時間目標，芯片設(shè)計公司通常采用并行開發(fā)方法，由不同的團隊分別編寫寄存器傳輸級（RTL）、新思科技設(shè)計約束（SDC）文件、UPF文件等。

盡管設(shè)計和UPF的開發(fā)是齊頭并進的，但它們的時間表可能會有所不同，而這可能會帶來一些挑戰(zhàn)。本文將介紹如何使用新思科技獨立于設(shè)計的VC LP UPF檢查器（VC UPF）來應(yīng)對這些挑戰(zhàn)。本文還將討論VC UPF如何幫助開發(fā)者在RTL準備好之前清理UPF文件中獨立于設(shè)計的各種問題。

優(yōu)化SoC設(shè)計的功耗

設(shè)計SoC時，UPF的第一個版本可能在RTL最終確定之前就已經(jīng)準備好了。但只有在設(shè)計就緒后，才能驗證UPF的準確性和完整性。因此，通常會有一個“等待期”，負責編寫UPF的開發(fā)者需要等待第一版RTL敲定，才能繼續(xù)后面的工作。在設(shè)計就緒后，開發(fā)者會運行一個靜態(tài)檢查器工具來驗證UPF與設(shè)計的一致性，往往在這時，開發(fā)者會發(fā)現(xiàn)UPF中存在的一些基本問題，其實這類問題本可以在不讀取設(shè)計的情況下就能找出。之前的等待實際上已經(jīng)浪費了一些時間。而反復(fù)多次的UPF修復(fù)和檢查會導(dǎo)致周轉(zhuǎn)時間變得很長。

這就是VC UPF的用武之地。

顧名思義，VC UPF讓負責功耗設(shè)計意圖的開發(fā)者能夠在RTL就緒之前開始清理UPF文件中獨立于設(shè)計的問題。該解決方案包括：

我們來看幾個例子，了解一下該解決方案能提供哪些幫助。

一種情況是UPF電源網(wǎng)絡(luò)未定義任何電源狀態(tài)。只有在閱讀設(shè)計、加載UPF并完成UPF檢查之后，用戶才會意識到：由于缺少狀態(tài)，有一些路徑無法進行分析。有了VC UPF，開發(fā)者將會在幾分鐘內(nèi)獲得這些信息。

在另一種情況下，用于隔離策略的隔離電源網(wǎng)絡(luò)在所需的域中可能不可用。

再來看另一個例子，比如從PD3到PD2的路徑。由于OFF–>ON交越得到了隔離單元的正確保護，因此不存在電氣問題。于是，傳統(tǒng)的電氣檢查不會標記任何違例。但在同一情況下，還存在一個功能問題，即來自PD1的信號會被PD3（電源處于OFF狀態(tài)）中的組合邏輯電路阻擋。

VC LP中全新的預(yù)檢查功能可以正確地標記該問題，并提醒開發(fā)者：盡管該路徑被正確隔離，但來自PD1的信號會被OFF域中的組合邏輯電路阻擋，只有鉗位值會到達PD2。

鑒于這一違例，開發(fā)者應(yīng)驗證該路徑是否要在指示的電源狀態(tài)期間攜帶功能信息。如果它在給定的電源狀態(tài)下不攜帶功能信息，則無需進一步的操作。但如果該路徑需要攜帶功能信息，則需要為所示的緩沖器/反相器/組合邏輯電路通電，并且需要修復(fù)組合邏輯電路的電源連接。通過仿真來識別這些問題非常耗時，而借助VC LP，開發(fā)者現(xiàn)在可以在設(shè)計周期的早期階段發(fā)現(xiàn)這些問題，從而節(jié)省仿真時間。

盡管VC UPF的主要用途是早期清理UPF，但它也可以用于SoC的UPF管理。復(fù)雜的SoC具有來自不同供應(yīng)商/設(shè)計團隊的IP模塊UPF文件，這通常會導(dǎo)致UPF修改推遲、時間表延誤，甚至要重新驗證。為了避免這些情況，CAD團隊可能會強制執(zhí)行一些GuideWare規(guī)則，以符合IP供應(yīng)商的UPF交付要求，從而確保SoC集成順利完成。VC UPF可以使用disallow_*命令或allow_*命令來協(xié)助執(zhí)行此類GuideWare UPF架構(gòu)檢查。

類似地，在SoC集成期間，開發(fā)者可能不希望某個特定的IP級UPF TCL變量被頂層覆蓋。帶有設(shè)計檢查工具的標準UPF不會將這種情況識別為問題。但是，利用VC UPF，開發(fā)者可以指定此類受保護變量的列表，并快速發(fā)現(xiàn)其中是否有任何變量已被頂層UPF所覆蓋。此外，開發(fā)者還可以驗證IP的UPF版本與SoC UPF的兼容性。根據(jù)用戶指南中關(guān)于允許和禁止的UPF版本組合，VC UPF可以執(zhí)行IP與SoC的一致性檢查。請注意，除此以外，VC LP不考慮UPF版本，使用“upf_version”不會產(chǎn)生任何影響。

經(jīng)認證的功耗感知靜態(tài)檢查簽核

新思科技的VC LP解決方案為UPF提供了準確且經(jīng)過認證的支持，它與以下工具緊密集成，可用于靜態(tài)低功耗檢查和調(diào)試：

總結(jié)

毋庸置疑，要設(shè)計出滿足所需功能、時序和功耗要求的低功耗SoC，需要付出大量精力，而且還面臨著產(chǎn)品上市時間緊迫的壓力。通常，芯片設(shè)計公司選擇并行開發(fā)方法，由不同的團隊分別編寫RTL、設(shè)計約束文件、UPF文件等。但是，盡管設(shè)計和UPF的開發(fā)可以齊頭并進，但它們的時間表會有所不同。

VC LP解決方案讓負責功耗設(shè)計意圖的開發(fā)者能夠在RTL就緒之前開始清理UPF文件中獨立于設(shè)計的問題。該解決方案也可用于SoC的UPF管理，因為復(fù)雜的SoC通常具有來自不同供應(yīng)商的IP UPF文件，而這可能會導(dǎo)致UPF修改推遲、時間表延誤，甚至要重新驗證。通過在早期階段清理UPF，開發(fā)者可以在低功耗SoC設(shè)計周期中節(jié)省時間和精力。