パワーを考慮したデバッグの実現に向けて SpringSoft社
SpringSoft社‐Bindesh Pate著
設計検証を行うにあたって、1つだけ否定できない事実がある。それは、設計検証が設計期間に大きく影響し、依然として、今日の洗練されたシステム・オン・チップ（SoC）を開発する上で重要な問題点になっているということだ。しかし、今日のエンジニアが対峙する課題は、それだけではない。消費電力はもちろん、電力が設計/検証/実装プロセス全体にどのような影響を与えるかについても考えなければならない。このような懸念の要因として、搭載機能が増加し、バッテリー寿命をより長く保つために低消費電力で操作しなければならないアプリケーションが増えていることが挙げられる。また、クロック・スピードの高速化とプロセス・ジオメトリの微細化により、電力密度が増大していることも要因になっている。さらに、今日のSoC設計は、様々な電力条件で複数のアプリケーションを実行する複数のブロックで構成されているということも重要な事実だ。
電力に関するこれらの課題に対処するため、パワー・マネージメント技術が導入されて久しいが、このようなパワー・マネージメント技術は、ゲートレベルのネットリストに直接導入されるのが一般的だった。しかし、そこで問題が見つかった場合、大抵再設計するには手遅れであったり、コストがかかりすぎてしまう。パワー・マネージメントをRTLコードでモデリングすることにより、設計工程の早期段階でパワー・ビヘイビアを検証することができる。しかし、より多くのモジュールでパワー・マネージメントを行う必要があり、また、必要な電源モードや遷移が急速に増えているため、このアプローチは非実用的になっている。Common Power Format （CPF）やUnified Power Format （UPF）のようなパワー・フォーマット規格が、設計工程を通じて電力課題に対処する構造的な手段として登場してきた。どちらの標準フォーマットも、TCLのシンタックスをサポートしている。このファイルを使用することにより、エンジニアは、例えば、パワードメインを作成/管理し、アイソレーションとリテンションを指定し、レベルシフタを設定し、電力関連のルールを定義することによって、電力の「設計」を記述することができる。
パワー・フォーマットの規格化により、電力の定義や意図をシミュレーションへの入力の一つとして使用することができ、それにより、設計の電力関連事項を早い段階で検証できるようになる。これは確かに理想的だが、一方でパワーを考慮したデザインのデバッグが複雑になる。このように複雑さが増すことにより、消費電力を考慮したデザインをデバッグする際に生じる検証課題だけでなく、この課題に対処するために必要なソリューションにも影響が出てくる。以下で、より詳しく検討してみよう。
■検証課題の把握
検証課題の深刻さを把握するため、今日の主要エレクトロニクス製品の一つである携帯電話を例に考察してみる。一般的な携帯電話には、電子メールやカメラ機能、ゲーム、GPS、ミュージックプレーヤーといった多種多様な機能が多く搭載されている。消費電力を最小限に抑えるために、携帯電話の設計には、様々な節電方法が取り入れられている。例えば、電子メールのような相対的に電圧が低いアプリケーションには低い電圧が供給され、ゲームのような電圧が高いアプリケーションにはり高い電圧が供給されるようになっている。設計に取り入れられているレベルシフタは、電圧レベルを適宜シフトさせるために使用される。その他の一般的な節電方法として、ゲームが電話の呼び出しによって遮られた場合、ゲームブロックへの電力供給を遮断するというものがある。電力は、電話が終わってからゲームブロックへ供給されるようになっている。
どの方法でも、設計に取り入れられた節電機能が適切に動作しているかどうかを検証エンジニアが検証する必要が出てくる。ここで、エンジニアは、アプリケーションを切り替えた時の電圧レベルが正しく機能しているかどうか、また、ゲームブロックの状態値が、電力供給が遮断される前に保存されているかどうかを検証しなければならない。しかし、デザインの検証中に電力関連のエラーが見つかった場合は、どうなるのだろうか？次にデザインのデバッグを行わなければならないのは明白だ。しかし残念ながら、これはそんなに単純なものではない。というのも、エンジニアは次に挙げる2つの大きな問題に直面するからだ。一つは不慣れなUPFやCPFに指定されたパワー・インテント（低消費電力化の意図）を包括的に理解すること。もう一つは電力関連のエラー原因の検出である。
■パワー・インテントの理解
UPFやCPFの仕様は、システムエンジニアやチップレベルのエンジニアによって記述されることが多い。したがって、パワー・インテント・ファイルがブロックレベルのデザインに与える影響を、常に、RTLエンジニアが把握できるとは限らない。例えば、階層的なRTLデザインのサブブロックに複数のパワードメインがあり、各ドメインには電源のオン・オフを切り替えるための異なるルールがある可能性がある。この場合、各パワードメインには、リテンションセル/レベルシフタ/アイソレーションセルに対する異なるルールが必要となる。その結果、RTLエンジニアが慣れている「All-on」機能が、パワーを考慮してシミュレーションを行う際に異なる動作をする可能性があり、ブロックに関連する「パワー・インテント」を包括的に理解するのが一層難しくなる。
例えば、RTLエンジニアが、図１に示すCPUブロックに取り組んでおり、どのパワードメインにCPUブロックやそのサブブロックが属しているかを知る必要があるとする。この場合、エンジニアは、CCUサブブロックがPD_CCUドメインに、ALUBサブブロックがPD_ALUB ドメインに、PCUサブブロックがPD_PCUドメインに属すると判断する。次にエンジニアは、「pram」ブロックの電源モードが「オン」の時、その他のブロックは「オフ」モード状態にある（図２）というように、パワードメインのモードがどのような設定になっているかを知る必要がある。
・ブロックには、いくつパワードメインがあるか？
・このドメインのモード設定はどのようになっているか？
図１ RTLエンジニアは、どのパワードメインがデザイン内にあるのか知る必要がある。
パワードメインは「オン」か「オフ」か？
図2 RTLエンジニアは、「オン」か「オフ」かといった現在のパワーモードを知る必要がある。
また、「pram」ブロックが「オン」で、その駆動ブロック（CPU）が「オフ」であるため、エンジニアは「pram」ブロックの入力値が破損しないことを保証するために、アイソレーションセルが二つのドメイン間に挿入されているかどうかを把握する必要がある。このように、それぞれのパワードメインとパワーモードがある複数のブロック/サブブロックに対して、同様の工程をくりかえさなければならないこの作業は、今日のRTLエンジニアにとって、膨大な時間がかかる大きな問題である。
■根本原因を探る
パワーを考慮した設計をデバッグするにあたり、最初の課題はバグの根本原因の発見である。なぜなら、この原因がRTL機能である可能性と、電源仕様コードに定義されたビヘイビアである可能性の二つが考えられるからだ。例として、パワーを考慮した設計のシミュレーションにおける波形内のX値を考えてみる。この値は、「電源オフ」を意味する可能性もあるが、アイソレーションセルの欠如といった構造的エラーや、誤ったセーブ/リストアのシーケンスといったコントロール・シーケンスのエラーによるバグである可能性もある。従って、波形内のX値を見ただけでは、そのX値がどこで発生したのか、また、何を原因とするのかを知ることはできない。根本原因を突き止めるために、RTLソース及びパワー・インテント・ファイルの両方をトレースバックしなければならない。
■パワーを考慮したデバッグを行う条件
パワー・フォーマットの規格を使用することによって生じる複雑性に起因する検証課題への対処は、決して容易ではない。それには、パワー・インテントを理解し、自動的にパワー関連のエラー原因をトレース/可視化/解析できるパワーを考慮したデバッグ・ソリューションが必要になる。RTLエンジニアが、パワー・インテント・コードを完全に理解するために、少なくともこのソリューションによって、エンジニアは検証中のブロックに関連するパワードメインのモードを確認しなくてはならない。さらに、このソリューションには、以下の機能が必要になる。
・スイッチ・ルール/リテンション/アイソレーション/レベルシフタ・ルールといったパワー・インテントを容易に確認できるUPF/CPFビューワ。
・パワー・インテントをデザインブロックに関連づけることができるRTLソース/スケマティック/波形ビューワ上のパワー・インテント・アノテーション。これにより、どのブロックがどのパワードメインに属しているか、また、どの信号にリテンションが定義されているのか、もしくは、レベルシフタが定義されているのかを把握できる。
・UPF/CPFのパワービューワとRTLソース/スケマティック/波形ビューワとのクロスプローブ機能により、デザイン・オブジェクトやパワー・オブジェクトがどのビューワ上でも特定できること。例えば、クロスプローブを行うことにより、UPF/CPF内のリテンション信号をスケマティック・ビューワで見ることができ、その結果、信号の接続を確認することができる。
・パワー・モードやステートの動作を簡単に把握できるパワーステート/モードを視覚的に確認できる機能（図3）。
図３ SpringSoft社のVerdi自動デバッグシステムのようなパワーを考慮したデバッグ・プラットフォームは、UPF/CPF双方のパワー・フォーマットをサポートし、設計のパワー・インテントを確認できるパワービューワを提供する。また、特別な可視化技術を使用して、アイソレーション/リテンション・ルールのようなパワー・インテントを持つ信号を容易に特定することができる。信号は、異なる色でハイライトされるか、もしくは注釈が付けられる。
RTLとパワー・インテント・ファイルの両方からバグの根本原因をトレースするため、パワーを考慮したデバッグ・ソリューションには、様々な自動化機能が必要になる。
・ドライバ/ロードを自動的に特定するため、RTLとCPF/UPFの両方を考慮して処理を実行
・バグの原因がCPF/UPFで定義された電源制御にある可能性があるため、CPF/UPFで駆動する信号を可視化。これにより、CPF/UPFに対するデバックが可能
・異なるパワードメイン間に跨るパスを追跡することにより、リテンション/アイソレーション/レベルシフタの信号を容易に特定可能。より詳細なデバッグのために、このトレースされたパスがパワードメインやパワーに関連する論理を適切に表現できること。（図４）。
・RTLソース、波形、スケマティック、UPF/CPFパワー・ビューワ上にパワー・モードをアノテートすることにより、どのビューワでもダイナミックなパワー・モードやパワーステートを容易に調査可能。この機能により、次ぎのデバッグを正確に行うことができる。
・RTLやCPF/UPFコードのエラーの根本原因を自動的に特定。RTL、CPF/UPF間をシームレスにトレースできる。
図4 Verdiシステムは、パワー・インテントを可視化するために、自動トレース機能"Temporal Flow View"を使用してパスのトレースを実行。この機能を使用することにより、"Trace this Value"や"Trace Unknown Value"の結果が、パスとともにパワードメインやパワー・オブジェクトがハイライトして表示される。パスが"X"に対する"Trace Unknown Value"の結果であった場合、原因となっている論理が、パワードメインの状態に影響されているかどうかを容易に判断することができる。
パワーを考慮したデバッグ・ソリューションには、パワーを考慮できる高度なデバッグ機能が必要になる。この機能には、CPF/UPFやRTLコードといった境界を越えたドライバ/ロードの自動特定、任意のシミュレーション時刻のパワー・モードのアノテーション、パワー・インテント・ルールにより生じた値やパワーステートをすべてのビューワ上で視覚的に確認できるための機能が挙げられる。さらに、リテンション・レジスタ等の電力回路を、セーブ／リストアする信号と共に見ることができ、テンポラル・フロービュー上で電源制御信号を自動的にトレースできる機能も考えられる。
■まとめ
CPFやUPFといったパワー・フォーマットが登場し、新たに生じた様々な電力課題に対する効果的な手段が提供されてきた。同時に、既に複雑で時間のかかる検証工程を、さらに複雑にしている。この工程を簡易化するには、設計のパワー・インテントを明確に理解し、検出された全てのバグの根本原因をトレースできる、パワーを考慮したデバッグ・プラットフォームを利用することが重要になる。このようなソリューションは、一般的なプラットフォームに新しいパワーを考慮した革新技術を取り入れることで、HDLやUPF/CPF双方を考慮して、複雑なパワー・インテントの動作をトレース/可視化/解析するといった独自の要求に対処することができる。最終的には、このパワー・フォーマットとパワーを考慮したデバッグ・ソリューションを組み合わせることにより、低消費電力チップの設計における貴重な検証時間を節約することが可能になる。
■著者について
Bindesh Patelは、米国SpringSoft社の検証グループのテクニカル・マーケティング・マネージャで、次世代検証製品開発の決定を行っている。SpringSoft社に入社する以前は、LSI Logic社、Zycad社、Atrenta社の各社で設計及び応用エンジニアリング部門に従事していた。カリフォルニア大学サンタ・クルーズ校でコンピュータ・エンジニアリングの学位を取得している。
電話：408.467.7888、電子メール：bindesh_patel＠springsoft.com ※＠マークを小文字に置き換えて下さい。
お問い合わせ：株式会社スプリングソフト