解決六個低功耗調試陷阱
06-08
解決六個低功耗調試陷阱
推薦閱讀：
在從前端設計階段到後端實施階段驗證功耗管理SoC的行為時，會出現基於模擬的調試挑戰。
我們還想表彰本文的第四位合著者Gabriel Chidolue，他是西門子公司Mentor的Questa功能驗證小組的解決方案架構師。低功耗驗證的調試挑戰由於低功耗設計中使用的複雜電源管理架構和技術而變得複雜。設計人員使用複雜的功耗感知技術，如電源門控，電壓調節和體偏置來節省功耗並最大限度地減少散熱。因此，晶元的功耗感知驗證是一個相當複雜的過程。統一功率格式（UPF）標準提供了許多新功能，這些功能已經放寬了功率意圖規範流程，並啟用了新的功率管理驗證流程，以滿足當今基於IP的SoC設計的需求。不幸的是，UPF標準的發展並沒有降低電源管理驗證任務的複雜性。此外，傳統的調試技術和方法假定設計是「始終開啟」的，因此無法解決與功耗相關的新問題。
讓我們來看看六個低功耗調試挑戰和常見陷阱，以及如何讓它們更容易解決或完全避免的一些想法。雖然這些調試挑戰對於那些參與電源管理驗證的用戶來說都不是什麼新鮮事，但我們的意圖是根據實際用戶體驗為非入門用戶提供實用指南。1.不需要的X值
低功耗模擬中的主要調試問題是未知（X）值的根本原因分析。 X值在低功耗模擬中出現在信號上可能有幾個原因。這些原因可能是不正確的UPF規範（缺少隔離/電平轉換保留單元或不正確的電源域分區）或UPF 1.0到UPF 2.0模擬語義差異（由於初始塊的使用）（信號初始化和域加電）。為了區分信號的正常未知值，大多數模擬工具都能夠突出顯示波窗中功率域損壞引起的未知值。在正常模擬中，未知X信號值通常使用波形窗口中未知值區域周圍的單個中高紅線或紅色輪廓框來顯示。在低功耗模擬中，整個低 - 高區域使用紅色，粗粒或細粒交叉影線填充，表明X值是直接功率域腐蝕的結果（圖1）。
在非功耗感知模擬中，信號的驅動通常是一些RTL邏輯。但是，在功耗感知模擬的情況下，它可以是從RTL邏輯到UPF插入單元的任何範圍。對於信號出現意外值的情況，可能是該信號的功率感知活動的影響，或者它可能是功率感知活動對其某些驅動信號/邏輯的傳播效應。在這些情況下，驅動程序跟蹤是查找驅動程序信號及其值的有用方法。
另一個有用的功能是信號的數據流/原理圖調試。這有助於追蹤遠處邏輯驅動的信號的值。在功耗感知調試中，它還在數據流路徑中顯示UPF插入的單元。圖2是來自模擬器的數據流示例，示出了信號「/ tb / out1」的數據流路徑中遇到的隔離單元和電平移位器。
禁用設計元素的模擬語義意味著該工具不會在該元素上傳遞任何電源切斷/損壞。該工具會禁用功耗感知模擬語義，因此不會有工具注入損壞。所有這些區域都可以使用驗證工具報告的消息輕鬆識別，例如：
注意：（vopt-9693）針對chip_top / u_hm_top_0 / u_ip_1禁用了Power Aware模擬語義。3.非法權力和轉軌
當今的低功耗設計有許多操作模式。低功耗設計的主要調試任務之一是驗證設計的運行功耗狀態。這需要驗證每個電源域的每個定義的電源狀態已被覆蓋並正常工作。它還要求驗證組成每個運行電源狀態的所有域的所有電源狀態組合。隨著電源域數量和運行電源狀態的設計不斷增加，驗證過程的複雜性會增加多倍。UPF通過提供add_power_state和describe_state_transition命令來解決這些挑戰。不僅add_power_state支持偏置狀態，分層電源狀態創建和增量更新功能，還允許將任何命名電源狀態聲明為合法或非法。使用這兩個命令需要低功耗模擬器在發生非法電源狀態或發生任何非法電源狀態轉換時發布運行時錯誤消息。UPF還規定，未命名或未定義的電源狀態是非法的。如果在從一個定義狀態轉換到另一個定義狀態時出現意外功率狀態，則未定義功率狀態的檢測特別有用。在合法電源狀態轉換期間發生未定義的電源狀態可能是由於通過UPF封裝supply_on / supply_off函數更改UPF電源與同時切換電源控制邏輯信號之間的競爭造成的。比賽引起的未定義功率狀態可能表示電壓上升/下降時間與邏輯開關時間必須考慮的區域，以確保設計的正確操作。但是，有時候，知識產權的所有基本權力狀態都沒有確定;這可能會導致模擬期間發生意外的非法狀態消息。用戶可以使用UPF 3.0語法，該語法允許將給定對象的一組功率狀態的指定標記為完整，這表明該對象的所有基本狀態已被定義為命名功率狀態。如果一個對象的電源狀態集已經完成，那麼UNDEFINED電源狀態應該是該對象的當前電源狀態的錯誤。如果在電源狀態標記完成後定義新的基本電源狀態，那也是一個錯誤。如果給定對象的功率狀態未標記為完整，則假定所有基本狀態尚未定義，並且不會被標記為錯誤行為。類似地，describe_state_transition（UPF 2.0 / 2.1）和add_state_transition（UPF 3.0）命令可以使兩個電源狀態之間的任何轉換被聲明為合法或非法。 UPF 3.0還允許定義一組相關的電源狀態，然後可以在add_power_state命令中使用這些狀態。權力狀態組的合法權力狀態定義該範圍內的其他對象或子孫樹的權力狀態的合法組合;即在設計的操作期間可以同時活動的對象的狀態的那些組合。這個命令可以用來定義非法的電源狀態組合。4.電源意向規格的複雜性UPF已經解決了低功耗設計電源管理的功率意圖規範。但是，UPF標準仍在不斷發展，新版本中增加了新功能，概念和說明。它往往會帶來與向後兼容性，差異和遷移問題有關的問題，這些問題很難調試。
在UPF 1.0中，UPF默認提供ON狀態。參與基於UPF 1.0的功率感知模擬的許多驗證和設計工程師在不知不覺中依賴於這一事實，因此，有一種趨勢是不使用UPF封裝定義的supply_on函數明確地打開它們。因此，在用戶切換到基於UPF 2.0的功率感知模擬語義之後，以前通過基於UPF 1.0的模擬可能會失敗。許多這些故障的常見原因是，在UPF 2.0中，UPF將默認設置為OFF狀態，導致所有電源域都處於CORRUPT狀態。通過使用UPF封裝定義的supply_on函數明確設置所有創建的UPF電源的UPF狀態和電壓值，可以輕鬆避免此常見遷移問題。低邊界電源域埠的隔離是另一個遷移問題。在UPF 1.0中，set_isolation -applies_to輸入/輸出埠過濾器僅考慮在模塊邊界上對齊的電源域埠。換句話說，只有模塊的輸入和輸出埠是隔離的。在UPF 2.0中，這些隔離埠過濾器已經擴展到還包括下邊界（不同電源域中的子模塊實例）輸入和輸出電源域埠。下邊界電源域埠隔離的概念可能會由於工具推斷的意外背靠背隔離單元而導致模擬失敗，特別是如果隔離策略包含在任何較低級別的電源域中。Power-intent規範中的另一個調試挑戰是由於在各種UPF命令中使用列表/通配符擴展而產生的。通常會發生一個不正確的信號列表，作為在通配符中使用錯誤模式的副作用。如果用戶依賴UPF命令find_objects創建信號列表並使用tcl命令放置列印元素列表的內容，則可避免此問題。獲取擴展信號列表的另一種方法是使用save_upf命令。使用save_upf UPF命令，驗證工具會將解釋的命令轉儲到新的UPF文件中，該文件將包含擴展元素列表。另一個安全的選擇是避免使用非LRM通配符使用，並依賴UPF命令find_objects。在設計中的宏模型的情況下，電源以及功率感知功能存在於模型本身內部。將此宏模型集成到SoC中時，集成商必須將這些HDL電源連接到UPF網路。由於UPF電源是具有狀態和電壓值的supply_net_type類型，並且HDL中定義的電源屬於線型，因此UPF和HDL網路之間的連接需要一個值轉換表（VCT）。 VCT定義UPF網路的狀態與HDL埠/網路的值之間的映射。用戶可以依靠驗證工具來應用默認VCT，或者使用UPF命令connect_supply_net -vct明確指定要使用哪個VCT。請注意，當相同的VCT用於電源/接地/電源/電源網路時會出現問題。這會導致上電失敗，因為地面/井口供電網線處於低電平並期望地面特定的電壓。5.提供網路問題在實施階段，電力感知設計中的供電網路往往龐大而複雜。有時，它會變得越來越多，並且難以調試供應網路中的不正確連接或任何其他問題（或者僅存在於UPF文件中或已經在設計中實現）。您可以使用靜態或動態調試方法調試電源連接。這是一個來自EDA工具的良好用戶界面和連接報告幫助很大的問題。6.通電失敗
當低功耗設計在斷電期後無法啟動時，會出現常見的調試場景。由於丟失或不正確的隔離/電平移位器，不正確的保留行為以及宏單元損壞，可能會出現此問題。通過在編譯時執行靜態驗證，使用工具生成的斷言以及使用UPF綁定檢查器，可以調試丟失或不正確的隔離/電平移位器。許多工具靜態地確定隔離和電平移位器單元在PST和UPF中描述的功率狀態的域邊界處的需要。
推薦閱讀：