HOT TOPIX

 
SIEMENS
s2c
 

次世代プロトタイピングSoC検証プラットフォーム SpringSoft社

次世代プロトタイピングSoC検証プラットフォーム

汎用及びカスタムのFPGAプロトタイプ・ボードが、Co-EmulationやCo-Simulation機能で強化されることにより、迅速な早期SoC検証を可能にする、高速性と高い可視性を備えた検証プラットフォームへと進化します。

システム・オンチップ(SoC)デザインの回路規模と複雑さは増加し続けています。同時に、製品投入期間は短期化しており、今日の電子市場は市場投入時期のプレッシャーに大きな影響を受けています。この市場投入時期を実現するために、SoC設計チームやSoC検証チームに対して膨大な要求が課せられています。事実、現在、検証工程に費やす時間は全体的なSoC開発期間の約70パーセントであるのが一般的です。それ故に、検証コストの削減や、検証実行速度を高速化するために、開発工程の早い段階から利用できる様々な検証手法が多くの注目を集めています。

本稿では、まず典型的なSoCの設計、検証環境で構成する主な内容をご紹介します。また、ソフトウェア・シミュレーション、ハードウェアによるアクセラレーション及びエミュレーション、FPGAプロトタイプ・ボードの使用等、従来の検証ソリューションの長所と短所を考察します。その後、スタンダードなFPGAプロトタイプ・ボードを本格的なデスクトップ・エミュレータ化する革新的かつ低価格な手法についてご説明いたします。ここでご提案するアプローチは、既存のインサーキットエミュレーション機能を自動化し、新たにCo-Emulation機能とCo-Simulation機能を加えることで、汎用及びカスタムのFPGAプロトタイプ・ボードの検証効率を劇的に向上するパラダイム・シフトを実現します。

典型的なSoC設計、検証環境

はじめに、典型的なSoC設計、検証環境のフロントエンド部分について考えて見ましょう。フロントエンド部分は、図1で示すとおり、少なくともデザイン描写(HDL作成)、ソフトウェア・シミュレーションベースの機能検証、ロジック・シンセシスで構成されています。さらに、現在のこのような設計環境の多くで、SpringSoft社のVerdi自動デバッグシステムが採用されています。Verdiシステムを使用することにより、ユーザは既存のソフトウェア・シミュレータ の結果を解析、デバッグし、自動的に全てのゲートレベル結果をレジスタ・トランスファ・レベル(RTL)ソースコードに関連付けることができます。

spring2011-01-01.jpg図1. 必要最低限のSoCフロントエンド設計、検証環境


機能検証による問題の1つに、収集、保存しなければならないデータ量の肥大化があります。例えば、ソフトウェア・シミュレーションの場合、膨大な信号のモニタリングがシミュレーション速度を大幅に減速させ、長時間に渡るシミュレーションによるデータ量は非常に大きくなります。このため、多くの設計、検証環境にはSpringSoft社のSiloti 自動可視化システムが採用されており、設計の全信号に関するデータを記録する際のオーバーヘッドを削減しています。Silotiシステムは、シミュレーションを実行する際に記録すべき最小限の信号を特定するために用いられます。 その後 Silotiシステムは、これらの信号を利用して、必要に応じて記録されていない信号データを「オンザフライ」方式で自動的に生成します。

※本稿で後ほど触れますが、ハードウェア・アクセラレータ、エミュレータ、FPGAプロトタイプ・ボード の結果もVerdiシステムを用いて、解析、デバッグすることが可能です。

ソフトウェア・シミュレーションの主な長所は、デザインに対する総合的な可視性にあります。逆に短所は、Siloti自動可視化技術を採用し、強力かつ高性能なワークステーションで駆動したとしても、今日の大規模SoCデザインでは、ソフトウェア・シミュレーションで数ヘルツ以上という適切なシミュレーション速度を実現することは難しくなっている点です(リアルタイムで毎秒、デザインのメインシステムクロックが数サイクル動作することを指します)。つまり、ソフトウェア・シミュレーションは通常、デザインの小さな範囲、もしくは数十サイクルのフルチップ設計にのみ有効です。しかし、現代のSoCを完全に検証するには、数十万、数百万のクロックサイクルが必要であり、この場合、図2で示すとおりハードウェアを使用する検証が必要になります。

spring2011-01-02.jpg図2. ハードウェア検証で拡張された最低限のSoCフロントエンド設計、検証環境


■従来ハードウェアを使用した検証ソリューション

様々なハードウェアを使用した検証ソリューションがあり、それぞれが異なる機能、長所、短所を持っています。また、異なる問題を解決するために異なるシステムを使用する様々な手法があります。これには、インサーキットエミュレーション、トランザクション・ベースのCo-Emulation、HDLでのCo-Simulation等があります。

一般的に、従来のハードウェアを使用する検証ソリューションは、ハードウェア・アクセラレータやエミュレータが考えられていました。FPGAプロトタイプ・ボードは、ワークステーションとのリンク機能が足りず、デバッグに求められる十分なデザインの可視性が得られないため、通常ハードウェアを使用する検証ソリューションとして考えられていません。

従来のハードウェア・アクセラレーション、エミュレーション・システムは、特殊目的や特殊目的を持ったカスタム・デザイン・チップやスタンダードFPGA、カスタム・デザイン・システム専用のものです。これらのシステムの目的は、できるだけソフトウェア・シミュレータと同じ操作で可視化やデバッグ機能等を実行させることです。これらのカスタム・アーキテクチャの長所を十分に生かすことができる専用ソフトウェアを使用することで、これらのシステムは比較的高速なコンパイル時間で大容量のデザインをハードウェアにマッピングできます。さらに、これらのシステムは適切なデザインの可視性(観測性と制御性)も提供します。しかし、これらのシステムは非常に高額で、複数のユーザ、プロジェクト、サイトに対して広く提供することは困難です。また、このようなシステムを一度採用した場合、次世代システムへのアップグレードが難しく、さらにカスタム・チップやシステムの新バージョン開発には非常に時間がかかる上、移行コスト等考慮すべき要因が発生してしまいます。


■FPGAプロトタイプボードへの変更

ハードウェア・アクセラレータやエミュレータの代わりとして、多くのデザインハウスが、市販製品やSoC検証チームがカスタム設計をしたFPGAプロトタイプ・ボードを使用しています。下記に示した例では、デザインはワークステーションでコンパイル(合成)、マッピング、配置、配線され、その後得られたFPGAコンフィグレーションファイルをプロトタイプ・ボードにダウンロードしています。典型的な使用形態はSoC設計(もしくはブロックレベル検証の場合は設計の一部)で使用され、図3で示すとおり、インサーキットモードで実際の入出力(I/O)信号を使用してドライブされます。外付けシステムでドライブし、ロジック・アナライザのようなツールを使用して、実際の入出力信号から後工程の解析で使用するデータを取得します。

spring2011-01-03.jpg
図3. インサーキットモードで操作する従来のFPGAプロトタイプ・ボード環境の高位表記

従来のFPGAプロトタイプ・ボードの主な長所は、高い性能と比較的低コストである点です。従って、複数のユーザやプロジェクトに割り当てることができ、複数のサイトで使用することも可能です。さらに、プロトタイプ・ボードは最新のFPGA技術を利用することができ、次世代ボードに迅速かつ容易に移行することが可能です。このソリューションの主な短所は、セットアップが難しく、Co-EmulationやCo-Simulationをサポートするためのワークステーションとのリンクが無い点です。また、デザインの視認性が非常に限定されており、デバッグ機能が充実していません。


■従来のFPGAプロトタイプ・ボードを強化する

従来のFPGAプロトタイプ・ボードは通常、プロトタイプ・ボードと外部機器を接続する汎用的なコネクタを装備しています。ご提案するアプローチでは、図4のように、この汎用コネクタにプラグインし、ホスト・ワークステーションとFPGAプロトタイプ・ボード間を繋ぐ特殊なインターフェイス・カードを提供します。

spring2011-01-04.jpg
図4. インターフェイス・カードとソフトIPを追加

FPGAプロトタイプ・ボードとワークステーション間の全ての通信は、エミュレーション、Co-Emulation、Co-Simulationに必要な高い処理性能を提供する専用バスを使用して行うことができます。このインターコネクト技術により、ユーザは柔軟に設定を行い、同じ汎用Connectorを持つ異なるプロトタイプ・ボードを使用することが可能です。また、この機能により、ユーザは迅速かつ容易に高速かつ大規模なFPGAプロトタイプ・ボードで処理を行い、従来のハードウェアを使用する検証ソリューションの限界を完全に排除することができます。

図4で示すソフトIPブロックをご覧下さい。このIPブロックは、プロトタイプの各FPGAにダウンロードされ、FPGAプロトタイプ・ボードとワークステーション間のデータフローを制御、観測するために使用します。動作モード(インサーキットエミュレーション、Co-Emulation、Co-Simulation)に応じて、必要な場合には適切な特性のIPブロックを自動的に挿入します。このIPブロックは、デザイン中にコンパイルされ、ユーザによって指定された全ての信号を観測するために使用されます。このように、数千もの信号や数百万のシミュレーションサイクルのデータを取得、解析することが可能です。

インターコネクト技術に加えて、複数のFPGAを搭載したプロトタイプ・ボードの設定の自動化等、多くの機能を実行するためには、図5で示すようなワークステーション上で動作する専用ソフトウェアが必要になります。セットアップ工程では、デザインのRTL記述(VHDL、Verilog、SystemVerilog、これら言語の混合)の読み込み、FPGA内蔵、外付けメモリに対するデザインの解析、FPGAで使用するホールドタイムエラーから解放されたSoCクロックの取得と生成、複数のFPGAにインプリメントするためのSoCデザインの分割、RTLに対する観測用のソフトIPブロックと信号の追加があります。

spring2011-01-05.jpg
図5. ワークステーション上で動作する専用ソフトウェアの追加

ソフトウェアは、検証を実行する段階で、セットアップ工程(インサーキットエミュレーション、Co-Emulation、Co-Simulation)で指定した動作モードを基にFPGAプロトタイプ・ボードとワークステーション間の通信やデータフローを制御、管理します。また、デザイン全体を再コンパイルすることなく、迅速かつ簡単に複数の信号を追加するといった、取得する信号を修正できる機能も重要です。最後に、これも重要な機能として、スナップショットやサイクルベースで、レジスタやメモリの出力等のプロトタイプ・ボード上のFPGAの内部状態を可視化する機能があり、最先端デバッグに有効です。 


■プロトタイプデザインの「デスクトップ」検証

様々な機能をさらに深く理解し、本稿に挙げられたインターコネクト、ソフトウェア自動化技術によって実現可能なモードを使用するために、いくつかシナリオ例を見てみましょう。もっとも単純な事例は、図6で示されているようなインサーキットエミュレーションのみのアプリケーションです。デスクトップ・ワークステーションで動作するソフトウェアは、自動的にデザインを分割し、プロトタイプ・ボードのデータを準備します。このセットアップ工程で、動作中に指定した信号データを取得するために、必要なプローブはすべてデザインに組み込まれます。

spring2011-01-06.jpg
図6. インサーキットエミュレーション・シナリオ例

オプションとして、観測するために必要な最低限の信号を定義するために、Siloti自動可視化システムを使用することも可能です。また、FPGAプロトタイプ・ボードを解析、デバッグするために、Verdi自動デバッグシステム を使用することもできます。セットアップ用のソフトウェアは自動的に全てのゲートレベルの信号をRTLに変換し、VerdiシステムはこのRTLソースコードを使用して高速デバッグ処理を行います。

Co-Emulationの場合、ソフトウェアのみのシミュレーションと比較して、検証工程を数百倍?数千倍高速化され、共通のシナリオにはワークステーション上にテストベンチ(および場合によっては設計の一部)があり、設計の大半(もしくは全て)はプロトタイプ・ボードにロードされます。ワークステーションで動作するソフトウェアは自動的にデザインを分割し、プロトタイプ・ボードの設定を自動的に行い、適切なCo-Emulation用の回路を(SCEMIベースのトランザクタ等)を挿入します。それ以前のシナリオでは、セットアップ工程で全てのプローブがデザインに組み込まれ、実行中に特定信号を取得することができます。オプションとして、図7のように、必要に応じてCo-Emulationを一時停止し、ソフトウェアを使用してスナップショットやサイクルベースでFPGAの内部状態を確認することも可能です。

spring2011-01-07.jpg
図7. Co-Emulation・シナリオ例

次に、ソフトウェアのみを使用したシミュレーションと比較して検証工程を10倍高速化するCo-Simulationを使用した例を見てみます。この場合も、テストベンチ(および場合によってはデザインの一部)はワークステーション内に存在し、デザインの大部分(もしくは全て)がプロトタイプ・ボードにロードされます。このシナリオでは、ワークステーションで動作するソフトウェアが自動的にデザインを分割し、プロトタイプ・ボードを設定し、ソフトウェア・シミュレータがリンクするラッパーを生成します。ソフトウェアは実行中にプロトタイプ・ボードと、ModelSim、NC、VCSシミュレータ等の業界スタンダードのソフトウェア・シミュレータとのCo-Simulationの協調動作を調整します。他のシナリオのご説明で述べたように、スナップショットやサイクルベースでレジスタやメモリ出力等、プロトタイプ・ボード上のFPGAの内部状態の確認が、図8で示すとおりソフトウェアや内蔵FPGA技術によって可能です。

spring2011-01-08.jpg
 図8. Co-Simulation・シナリオ例


■次世代プロトタイプ検証プラットフォームのメリット

縮小するマーケットと厳しい納期により、今日のSoC設計チームや検証チームに対する要求は膨大になっています。ソフトウェア・シミュレーションは、デザインを100%可視化できますが、利用できるのは対象デザインのほんの一部分、もしくはデザイン全体で数10クロックサイクルの場合です。しかし、現在のSoCを完全に検証するには、クロックサイクルは数十万もしくは数百万になり、ハードウェアを使用した検証が求められています。異なる機能、長所、短所を持った様々なハードウェア検証ソリューションがあります。ハードウェアを使用する検証技術の比較を表1で示します。

従来のハードウェア・アクセラレータやエミュレータは、容量が大きく、コンパイル時間は比較的速く、適切なデザインの可視化機能があります。しかし、このようなシステムは幅広く導入するには非常に高額で、移行するにも非常にコストがかかるため、適切な時期に次世代版へ移行することが困難です。比較して、従来のFPGAプロトタイプ・ボードは、性能が高く、比較的低コストです。しかし、従来のFPGAプロトタイプ・ボードにはデザインの可視化機能や今日のSoCの複雑さに対応するために必要な優れたデバッグ機能がなく、通常インサーキットエミュレーション・モードでのみ使用されます。

spring2011-01-09.jpg
表1. ハードウェアを使用する検証技術の比較

これらの問題に対応するために、当社は従来のFPGAプロトタイプ・ボードをデスクトップ・アクセラレータやデスクトップ・エミュレータに変えるSoC検証のパラダイム・シフトをご提案しています。このパラダイム・シフトには、汎用ボード、カスタム仕様ボード双方に対して接続が可能な革新的なインターコネクト技術と、高い可視性を持ったインサーキットエミュレーション・モード、Co-Emulation・モード、Co-Simulation・モードを、ワークステーション上で実行する専用のソフトウェアによる自動化が必要です。

このような機能で拡張されたFPGAプロトタイプ・ボードを使用することにより、SoC開発者はSoCデザイン全体における個々のブロック(内製、サードパーティIPブロックを含む)を迅速に検証し、正確にデザイン・モジュールに機能を与えることができます。この次世代プロトタイプ検証プラットフォームは、FPGAプロトタイプ・ボードの投資効果や生産性を最大化し、優れた検証効率と最先端FPGA技術を搭載したボードへの柔軟かつ迅速な移行を実現します。

 

ページの先頭へ