アーキテクチャ検証

ハードウェアとソフトウェアの検証を設計サイクル早期に

システム検証の課題はRTLで対応できる範囲を超えています。ハードウェアモデリングを抽象化し、開発プロセスのより早い段階に移行させることで、ハードウェアコンポーネントとソフトウェアコンポーネントの両方を素早く検証し、デバッグできるようになります。SystemCおよびトランザクションレベルモデリング(TLM)2.0により、設計サイクルの早期段階でシステム全体の検証とハードウェア/ソフトウェアの統合が可能です。

主な課題

  • 複雑でヘテロジニアスなSoCとシステムの検証
  • ソフトウェア観点からのハードウェア検証
  • ハードウェアに依存するソフトウェアの早期検証
  • システム内のデータフローやイベントシーケンスのトレース

特長と利点

  • TLMのデバッグとデータトレース用の直観的なトランザクションレベルビューア
  • 複雑なシステム内のデータおよび制御フローの理解
  • 設計階層とクラス階層の表示
  • ランタイム中のユニークなプロセス動作追跡処理
  • C/C++データオブジェクトのデルタサイクル解像度による波形トレース
  • イベントシーケンスの包括的デバッグ
  • ハードウェアビューとC/C++ビュー間を切り替え可能なSystemCデバッグ
  • 実行時のLTモードとATモードの動的な切り替え
  • データのトレースや解析にインスツルメンテーションが不要

詳細

ハードウェア検証

トランザクションレベルのハードウェア検証は、高い抽象度の動作とデータフローが中心です。システム設計者と検証エンジニアは、システムのシミュレーションを通じて、多数のブロックが正しく統合され、ハードウェアとソフトウェアが適切に連携していることを検証します。これらの検証作業は、従来RTL検証で行われていた作業とは異なり、新しいデバッグやトレースの概念を必要とします。このため、データの処理内容と設計フロー、さまざまな機能ブロックによるリソースの共有について理解するメカニズムが求められます。

TLM/SystemCに移行する際、C++ソフトウェア統合開発環境(IDE)を使ってSystemCモデルの開発とデバッグを進めることもありますが、このIDEは、タイミングやコンカレント設計といったハードウェアの設計概念に対応していません。ハードウェアを表現するトランザクションレベルのモデルは、システム全体でトランザクションおよびデータをトレースし、イベントシーケンス、プロセススケジュールを理解して、LT(Loosely-Timed)システムのシミュレーション時にデルタサイクルを参照するなど、標準C/C++ソフトウェアデバッガよりも高度なデバッグ機能を必要とします。Vistaは、TLM抽象度に対応したデバッグ機能を備えた完全な検証ソリューションです。

TLM/RTL検証

ESLとRTLは、(例えば、一方がSystemC、もう一方がSystemVerilogのように)設計言語も違えば、その用途も異なることがあります。しかし、TLMインフラストラクチャを統一して、両方のドメインの要素をリンクさせて再利用できるようにすることは重要であり、これにより広範かつ完全な検証ソリューションの構築が可能となります。システムレベルで作成されたTLMモデルは、RTLサブシステムをシームレスに駆動したり、実行可能な仕様(リファレンスモデル)としてRTLモデルの自動検証に使用したりすることもできます。このための手法とフローを定義したものがUVM/OVMであり、UVM/OVMメソドロジではESL設計向けに作成されたTLMモデルを効果的に利用しています。

TLM2.0

統合に最適なTLM2.0インタフェースを使用すると、インタフェース裏側の実装詳細を気にすることなく、ESLモデルとRTLモデルを互換運用できます。つまり、RTL記述とTLM記述が混在した環境でTLMを再利用し、RTLのレガシーIPをシステムレベルの観点から検証することができます。

UVM/OVMリファレンスモデル

システム仕様とは、トランザクションレベルの抽象度を持つリファレンスプラットフォームを用いてシステムレベルの機能をモデリングしたものです。トランザクションレベルのTLMはそれぞれ1つの機能と対応しており、その機能はハードウェアブロックを表現するRTL、またはプロセッサ上で実行するプログラムとして実装される場合もあります。RTL設計段階では、TLMをUVM/OVMテストベンチに挿入することで、RTLがTLM機能を正しく実装し、アーキテクチャ要件を満たしているかを検証します。

 
 
 
製品情報リクエスト