Home > THE SOUND OF CADENCE > SOC70 > TLM（Transaction Level Modeling）再び。「今こそ設計抽象度の向上を」
TLM（Transaction Level Modeling）再び。「今こそ設計抽象度の向上を」
| なぜ、今、TLMか？ |
| 高集積化・微細化・高性能化を実現するために、SoC/ASICの一製品あたりの設計費用は年々上昇してきています。設計費用の大幅な増大を抑えるためには、効率的な設計・検証手法により、より短い工数で設計を完成させることや、設計・検証の高品質化を進めてシリコン・リスピンを削減することが重要です。 工数とリスピンの削減の両立は、一見矛盾した要求でもあります。そのような難しい要求に対して、ケイデンスは機能検証の見地から、検証プランと検証メトリクスを活用するプラン･ドリブン検証（THE SOUND OF CADENCE Vol.64）、テストベンチ再利用性を向上するOVM（THE SOUND OF CADENCE Vol.67）、検証IPの活用手法（THE SOUND OF CADENCE Vol.69）などのソリューションを提案してきました。これらのソリューションによって、RTL設計・検証の工数とRTL記述に起因するリスピンの削減が可能となりますが、より一層の改善を目指すお客様が増えています。そのようなお客様の着目する技術が設計・検証抽象度のTLM（Transaction Level Modeling）への引き上げです。 |
| 現状の設計・検証における問題点 |
| 以下に従来のRTL設計・検証フローにおける問題点を列挙します。 |
| １． | アーキテクチャ上の問題を発見し修正することをRTLで行うことは、費用対効果が悪いこと |
| RTL記述はアーキテクチャの直接的な記述です。すなわち、RTLを記述する時点では、ある機能を実装し、遅延や消費電力のような各種設計ゴールを満たすアーキテクチャが確定していなくてはならず、その確定のためのアーキテクチャ探索には、それなりの工数が、そして多くの場合、経験と熟練が必要です。一方、このようにしてアーキテクチャを決定した後、RTLの機能検証と設計ゴールの見積もりを行いますが、ここでなんらかの不具合を検出したとき、その修正には往々にしてアーキテクチャを改変する必要があり、再度、アーキテクチャ探索からやり直す必要があります。 |
| ２． | RTL設計IPの再利用では、必ずしも最適なアーキテクチャを選択できないこと |
| 近年のSoC設計では、最大90%にもおよぶ再利用部品（IP）を使用します。このような再利用化を進めることで、設計工数の削減を進めることが可能になり、多くの設計で再利用部品が使用されるのが現状です。 それらの再利用部品は、あるSoCの設計において作成された部品かもしれませんし、IPとして最初から独立に作成された部品かもしれません。いずれにせよ、何らかの前提条件のもとに作られています。しかし、それら再利用部品を使用するSoCは、それぞれ異なる要求・特性で設計されます。そのため、場合によっては、機能としては満たしているが、遅延などの設計ゴールが必ずしも合致しない場合がでてきます。その場合、その再利用部品は、そのままでは使用できず、アーキテクチャから改変する必要も出てきます。そのようなアーキテクチャ改変が必要な状況では、RTL IPはそのまま再利用できないため、IPとしてのメリットは大きく減じられてしまいます。 RTLベースの設計では、このようなことは本質的に不可避です。RTLは状態遷移機械として定義されている必要があり、メモリ構造やパイプライン、制御状態やALUは、ある制約条件下で動作するように明確に記述されます。これは制約条件が変化したとき、新しいRTLが必要になることがあるからです。 |
| ３． | RTL検証に必要な工数が増大しているが、現在のRTL検証テクノロジでは必ずしもその増大に追従できないこと |
| 再利用は設計工数の大幅な増加を防ぐ上で有用な手法ですが、RTL機能検証は、SoCの規模拡大に歩調を合わせて増大しています。RTL機能検証は、各部品間の組み合わせを検証しなくてはならないため、デザイン規模に対して指数オーダーで増大すると言われています。大規模な開発プロジェクトでは、検証カバレッジを向上しながらリソースを最適に使用するために、検証プランの作成と管理の手法を有効に活用しているものもありますが、それでも、機能検証に必要な工数が増大することを完全に防ぐには至りません。 |
| 必要とされるソリューション | |
| １． | ゴールデンな記述としてのTLMの開発環境 |
| TLMドリブンIP設計フローでは、より少ない工数とバグ発生数で設計を行えるようになります。TLMでは、RTLと異なり、アーキテクチャの詳細な実装については定義されません。従って、制約条件が異なるプロジェクト間であっても再利用性が可能となります。抽象度がRTLに比べて高いこともあり、コードの量も少なくなり、より短時間で、機能をより正しく作りこむことが可能となります。 TLMをゴールデン記述として利用するには、TLMの検証およびTLMからの合成のためのツールが必要です。これにより、RTLやゲート・レベルの記述を設計者が扱う必要がなくなり、TLMを活用することで再利用性の向上が可能となります。 |
|
| ２． | TLMでの機能検証環境 |
| TLMのような抽象度の高い記述での機能検証は、イベント数に律速されるイベント・ドリブン・シミュレータでは、低抽象度記述での検証に比べて高速に実行でき、単位時間あたりではより多くのテストケースを実行することができます。TLMとRTLで使用可能な検証プランの作成と管理の手法は、各抽象度での検証品質の向上だけでなく、異なる抽象度間での検証による全体としての検証品質向上が期待できます。 SoCのレベルでは、既存RTL部品が多数あることから、TLMとRTLの混在検証は必須です。新規部品についてはTLMで、既存部品はRTLということも多いでしょう。既存RTL部品については、シミュレーション・アクセラレーションができることも、プロジェクトのスケジュールを達成させる目的において重要な技術です。 |
| ３． | SoCレベルでのデバッグ、アーキテクチャ解析、機能検証およびソフトウェア開発環境 |
| TLMでの開発を行う場合、デバッガの品質、生産性、使いやすさはより重要になります。SoCレベルのアーキテクチャ解析や最適化も含む機能検証環境も必要となります。TLMSoCモデルは、ソフトウェア開発プラットフォームとしても使用可能です。一方、現在、RTLで行っている多くのタスクはTLMで実行されますが、メモリ・アクセスのシーケンスや、状態遷移カバレッジなどのマイクロ・アーキテクチャの構造的検証については、RTLで継続して行われると思われるため、従来環境との整合性・接続性も重要となります。 |
| ４． | TLM-RTL間での検証IPの再利用 |
| 検証環境の作成は、往々にして設計そのものより多くの工数を必要とするため、検証IPの再利用はRTLにおいて広く行われています。特に、標準プロトコル検証のための検証IPは広く使用されています。同様のことがTLMでも必要となると考えられます。さらに、TLMとRTL双方で使用できる検証IPが求められます。 |
| ５． | ダイレクト・テストと制約付きランダム・テストのメトリクス・ドリブン検証としての組み合わせ |
| システムの検証では、ユース・ケースに基づくテストが多用されます。それらのテストは、ダイレクト・テストとして、例えばそのシステムで使用するソフトウェアをテスト・パターンとして、作成することができます。一方、コーナー・ケースの自動生成として、制約付きランダム・テスト生成もシステムの機能を正しく作りこむには重要です。TLMドリブン検証IPは、TLM、RTLおよびTLM/RTL混在のデザインに対して、ダイレクト・テストを行える必要があります。また、同様にTLM、RTLおよびTLM/RTL混在のデザインに対して、制約付きランダム・テスト生成、カバレッジモニタ、チェッカなどのメトリクス・ドリブン検証に必要な機能を提供しなくてはなりません。 |
| ケイデンスのソリューション | |
| １． | 統合されたTLMドリブンIP設計/検証/再利用メソドロジとコーディング・ガイドライン |
| ケイデンスは、TMLドリブンIPの設計・検証のためのメソドロジ・ガイドラインを提供します。このガイドラインを活用することで、TLMのプロジェクトを短工期かつ高品質に立ち上げることが可能となります。TLM IPコーディング・スタイル、モデリング・ガイドライン、合成サブセット定義に準拠することで、高位合成が可能で、シミュレーションのパフォーマンスが良好なTLM IPを作成することができます。TLM設計IP、およびTLM検証IPの両者をどのように再利用するかについては、TLMドリブンIPメソドロジの中で指針が与えられます。 | |
| ２． | ゴールデンTLMから、高品質RTLを自動生成するC-to-Silicon Compiler高位合成エンジン |
| C-to-Silicon Compiler（CtoS）は、TLM SystemC設計IPと設計制約から、合成可能・検証可能なRTLの記述を作成するテクノロジです。内部でRTL Compilerのテクノロジを使用してタイミングや消費電力の見積もりを行うことで、高QoR（Quality of Result）のRTL記述を作成することができます。また、入力となるSystemCと出力のRTLの対応関係の情報を出力することで、RTLの機能が正しいかどうかを調べることが容易になります。さらに、Engineering Change Order（ECO）の機能をサポートし、インクリメンタル合成が可能となります。 |
| ３． | TLMとその混在検証をサポートするIncisiveメトリクス・ドリブン機能検証環境 |
| Incisive機能検証プラットフォームは多言語・多抽象度に対応した統合検証環境です。Incisive Enterprise Simulatorでは、OSCI TLM2.0準拠の設計IPをOVM-ML（Open Verification Language、Multi Language）でのメトリクス・ドリブン検証メソドロジ、既存ソフトウェアの再利用を含めたダイレクト・テスト、ハードウェア/ソフトウェア協調検証などの場面で検証することができます。トランザクション解析機能と統一デバッグ環境により、TLMでの設計・検証をサポートします。Incisive Enterprise ManagerによりTLM、RTL、およびその混在環境での検証プランの作成と管理を行えます。もし、SoCの検証においてRTL部分が多いTLM設計の場合でも、RTL部分をIncisive XtremeおよびPalladiumを使ってアクセラレーションを行い、TLM部分との高速インタフェースを用いることで、大規模回路であっても高速な検証が可能となります。 |
| TLMの重要性 |
| より高い生産性、品質、スケジュール見積もり精度が必要とされる今、TLMドリブン設計・検証の重要性はますます高まってきています。TLMドリブン設計・検証は、一ブロックから順次適用することが可能です。TLM IPを既存のRTL IPと組み合わせながら設計・検証を進めていくには、いくつもの課題が立ちはだかるかもしれません。しかし、工数とリスピンの両方を 削減するには、設計・検証のTLM化は避けては通れません。 ケイデンスは、そのソリューションを通じて、お客様の課題の解決を支援します。 |
| カスタマ・プラットフォーム・マーケティング部 後藤 謙治 |
お問い合わせ
