2006.3

SoC検証時間を短縮する 各種ハードウエアの選択 デジタルLSIの設計が複雑になるにつれ、検証作業の複雑化も進んでいる。設計できるゲートサイズと、限られた時間で検証できるゲートサイズの溝は広がるばかりだ。それはEDAベンダーの努力だけでは、とても埋められるものではない。 Michael Santarini

Advertisement 　今日、LSI設計に費やす時間の6割から8割を検証が占めることは珍しいことではなく、その割合はさらに増加しつつある。試作品を作ってハードウエア支援の検証手法を採用する設計グループも多い。ハードウエアの試作として最初に登場したのがブレッドボードであり、その機能が向上するにつれて広く普及するようになった。米Collett International社（http://www.collett.com）とDeepchip.com（http://www.deepchip.com）の調査によれば、このような試作は全ASICプロジェクトの30％〜40％で行われているという。今では市販のFPGAを使って数100万ゲートの回路を試作できるが、大規模で複雑な設計になれば、既に設計された試作品を購入したいと思うだろうし、それだけの予算がなければ、シミュレーションアクセラレータやインサーキットエミュレータのレンタルや購入を考えるだろう。自分で作成するか、レンタルするか、あるいか購入するかの判断は、必要とするクロック速度、容量、機能、コスト、システム設計スキル、そして設計の検証に費やせる時間を含めた、さまざまな要因に左右される＊1）。 システムを試作する 　設計者とベンダーにとって、ASICやSoC（system on chip）の試作品を作成するということは基本的に後戻りのステップだ。SoCをSOB（system on board）にするのだから、と冗談交じりに言う者もいる。システムの試作においては、自ら設計するASICの機能を再現するために、別の機能をもつ部品や既存のASIC、FPGAを利用する設計者もいれば、マザーボードにプログラムされた高速なシステムを試作する者や、購入する者さえいる。マザーボードには、固有の機能や大規模なシステムを実現するFPGAとドーターボードがいくつも搭載されている。 　現在、250MHz近い速度で動作するASICの試作システムの設計や購入が可能だ。この動作速度は最終チップと変わらない。このような試作システムは、動作速度がせいぜい2MHz程度の市販エミュレータよりもずっと速く、RTLシミュレータと比べても110倍速い。高速ASIC試作システムを使えば、システム環境で機能テストを行えるし、組み込みソフトウエアの開発に早く着手できる。 　このようなASICの試作には、デバッグが困難であるという欠点がある。バグの発生個所を正確に突き止めるのが難しい。検証では、詳細なシミュレーションが行なわれる。米MIPS Technologies社は、新しいマイクロプロセッサコア設計の検証にハードウエアベースのほぼ全てのアクセラレーション手法を使用し、コアの統合を進める設計者を支援している（別掲記事「MIPS社が推し進める、試作環境の整備」を参照）。 自作の道 　システムの試作を一から行なうことは、今日、ある意味では簡単であるといえるし、ある意味では昔より難しいともいえる。今日のFPGAの容量とスピードをもってすれば、数100万ゲートのASICの試作も可能だ。近年、米Synplicity社や米Synopsys社のようなEDAベンダーは、ASICを分割して、分割ブロックごとにFPGAにプログラムできるようなツールを提供することで、試作の作業を軽減しようとしている。今日、ASICの試作ソフトが普及してきたことで高速試作ビジネスが活気を帯び、米Cadence Design Systems社や米Mentor Graphics社といった伝統あるエミュレータベンダーにすら対抗しうる手ごわい企業が出現している。特に既製の試作システムを販売するベンダーは、システムを構築するか購入するか迷っている設計者にまずこう質問するという。「自分達でシステムを試作するだけの十分な時間や、基板ボード/システム設計のスキルをもったスタッフ、それに予算を用意できますか？」 　ASICの試作システムを販売する米The Dini Group社の社長を務めるMike Dini氏は、高速試作システムは一から構築するよりも買った方が断然安くつくと語る。10年前までASICとFPGAの設計コンサルタントだったDini氏は、検証ツールへの不満から試作ボードの製作を始めた。今では設計サービス事業から手を引き、ASIC試作という急成長事業に注力している。現在は複数のベンダーがこのような試作システムを販売している（表1）。「エミュレーション分野の競合企業は、我々が単にFPGAの束を売っているにすぎないと言っているが、特に気にしていない。なぜならそれはある意味正しいからだ。当社が進めているビジネスは、最も容量の大きいFPGAをいくつもボードに搭載して、デバッグして、一から作るよりも安くお客様に提供する、ということである」とDini氏は言う。試作は重要なことかもしれないが、プロジェクト終了後には捨てられてしまうようなアプリケーションに特化したボードを組み立てるのは無駄だというのが同氏の意見だ。特別な機能をもったドーターボードは自作して、FPGAの部分は高速プロトタイピングシステムのベンダーから購入することをDini氏は勧めている（別掲記事「購入の検討」を参照）。 表1　現在提供されている、高速試作システム、アクセラレータ、エミュレータ 　Dini氏をはじめとする人々は、たとえSynplicityやSynopsysなどの自動パーティショニングソフトウエアを使用したとしても、4個以上のFPGAを必要とするシステムを自作しようとすればたちまち壁にぶつかると考えている。特にプリント基板の設計に詳しくなければ、EDAベンダーが何と言おうとその作業は非常に困難になるだろうという。「作るか買うか。試作はそのいずれかだ。1個のVirtex FPGAがあれば端子数700といった大きなパッケージでも大丈夫だが、それが2個、3個、あるいは16個にもなると、設計、構築、テストの困難度は増していく。たとえば、プリント基板のオートルータで700端子のFPGAを2個処理するのは無理があり、多くの手作業が必要となる。3個になるとASIC試作が複雑になってくる。2個ならまだしも、3個のFPGAを実装するのならば、配線層数やプリント基板内の接続への配慮も必要だ」とDini氏は言う。最近のFPGAは自動パーティショニングソフトウエアとの適合性もよく、高速試作システムのほとんどのベンダーが、自社のシステムをSynplicity社の「Certify」などに対応させていると彼は述べている。 　最新のFPGAの特徴は、スピードやロジックではなくI/O構造にあるとDini氏は言う。シリアライザとデシリアライザで一対の差動信号を出力するため、1個のFPGAを別のFPGAに接続する場合には、10：1の多重化によって約350MHzで動作する差動信号線が必要となる。35MHzで動作する設計ならば、108対の信号線を10：1で多重化し、1800の信号を2個のFPGAで分割することができる。「この方法であれば、自作システムでは非常に厄介なパーティション作業がずっと楽になる」とDini氏は語る。ASIC試作を設計に取り入れるときの取り組みの一つとして、設計プロジェクトが始まる前に、ASIC開発者が試作を念頭に置いて設計することが挙げられる。ASIC内のブロックをパーティショニングに合わせて配置するのもいいだろう。ASIC設計者にこの方法を取らせるのは難しいことが多い。「一般にASIC設計者はピラミッドの頂点にいるが、検証と試作はピラミッドの一番下に位置づけられることが多い。それが望ましい姿かは別として」（Dini氏）。 　Synplicity社でASICツールのマーケティングディレクターを務めるJohn Gallagher氏は、ASIC設計の知識が豊富なほどパーティション作業は容易になると言う。Synplicity社が450人の設計者を対象に実施したアンケートでは、RTL設計者の55％がASICを試作システムにパーティショニングする作業を担当していると回答し、25％は独立した検証チームが試作を行うと回答している（図1、図2）。 図1　ASIC設計に慣れていない検証チームは試作品を用いることが多い。 （出典：Synplicity社） 図2　自動パーティショニングソフトウエアを使用しても、ASIC試作システムのプログラミングにはある程度のマニュアルパーティショニングが必要である。 （出典：Synplicity社） アクセラレーションとエミュレーション 　シミュレーションによる検証の可視性を維持したまま、検証速度を上げたい場合は、シミュレーションのアクセラレーションまたはエミュレーションが有効だ。アクセラレーションでは設計の一部がコンパイルされ、ハードウエアアクセラレータ上で実行される。エミュレーションでは設計全体がハードウエア上で実行される。アクセラレーションによって、ワークステーション上で実行される純粋なシミュレーションの数100倍、あるいは数1000倍もの速さでコードを実行できるが、システムの他の部分に接続するインサーキットの設計を実行するには遅すぎる。一方エミュレーションは、RTLシミュレーションの数100倍または数1000倍も速く、約2MHzで実行できるためインサーキットにも使用可能であり、機能検証を加速させることができる。Cadenceの「Palladium」エミュレータなど、システムによっては数10MHzで動作するよう調整できる場合もある。 　ベンダーは、試作システムと同じように大規模な汎用FPGAを使用したり、あるいはカスタムプロセッサを使用して、アクセラレーションまたはエミュレーションシステムを構築している。カスタムプロセッサを搭載しているシステムのベンダーは、既製のFPGAを使用しているシステムとは異なり、アーキテクチャがアクセラレーションとエミュレーションを目的に設計されているのだから、自分達のシステムの方が速く、効率的だと主張する。カナダATI社シニア検証エンジニアのArt Stamness氏は、エミュレーションではなくアクセラレーションを支持する一人だ。彼のグループは、自社のグラフィックプロセッサに組み込む3Dグラフィックコアを開発しており、米Tharas Systems社のアクセラレータを使用して設計を検証している。「シミュレーションテストベンチの一部を、カスタムプロセッサを使用するハードウエアアクセラレータ上にマッピングしている。その方が速いからだ。FPGAネットリストを実行する代わりに、バイナリをコンパイルして実行した方が、エミュレーションを行うよりもずっと速い」とArt氏は言う。エミュレータを使用してネットリストをコンパイルするだけで1日かかることもある。「バグを見つけたら再コンパイルして翌日まで待って、また別のバグを見つけたら、また1日待つことになる」（Stamness氏）。一方のアクセラレーションなら、バグを見つけることもできるし、他のテストのための別のネットリストを1時間以内で準備することもできる。 　アクセラレーションはシミュレーション環境に近く、エミュレーションでは使用しないような大量のコードが必要になることもある。また、アクセラレーションによってシミュレーションのパフォーマンスは劇的に向上するものの、エミュレータのような5000倍のパフォーマンスは得られない。 　Stamness氏のグループは、Cadence社のNC-SimとTharasアクセラレータをコ・シミュレーションモードで実行する、150〜250台のPCサーバーファームを利用している。Tharasのコンパイラはコードの塊を抽出して、その設計の「スタブ」を作成する。NC-Simは、ハードウエアアクセラレータと通信するホストマシン上で動作する。Stamness氏は、エミュレーションを行う場合には初期費用だけでなくサポート費用もかかると言う。「必要なハードウエア、人、電力、ラボスペースといったサポートインフラにかかる費用は、シミュレータボックスのようなラックに納まり、かつパフォーマンスに優れたアクセラレータに比べると断然高くつく。エミュレーションの使用をためらう設計者はまだ多く、ハイエンド向けと言えるが、アクセラレーションであればそこそこの費用、そこそこの速度でシミュレーションを実行できる」（Stamness氏）。 　エミュレーションに対するStamness氏の意見は、数100万ドルをエミュレータに投資した結果、数年後には時代遅れのゴミしか残らないことを悟った人々の多くと一致する。初期のエミュレータはプログラムが難しく、ICの設計と同じくらいの時間をエミュレータのデバッグに費やすことも少なくなかった。しかしEDAベンダーは、エミュレータを動かすソフトウエアが今では洗練されて使いやすくなっており、その使いやすさがシステムの価格に反映されていると主張している。 　米QLogic社の検証エンジニア、Tom Paulson氏も、エミュレーションに転向した一人だ。Fibre ChannelスイッチASICを構築している彼のチームでは、Cadence社の「Palladium PD II」エミュレータを使用している。同社は3年以上にわたり、5個のASICの検証に「Palladium」エミュレータを使っている。QLogicチームは米Quickturn社のQuickCyclesレンタルプログラムを利用したエミュレーションでスピードを上げ、最終的にそのシステムを購入した。「確かに高価だったが、今では片時も休めずに使用している」とPaulson氏は言う。彼の部門ではVHDLを使用しており、初期検証に米Mentor社の子会社である米MTIの「ModelSim」を利用している。「業務において同様の作業の繰り返しが多い会社の通例にたがわず、我々もプロセスの自動化を進めている。当社はROMを生産しているが、検証ごとに異なるROMを使用するため、チップの処理も各々若干異なる。1つのROMに対して4〜5回のテストを行うこともある。設定にはTCL（tool control language）スクリプトを使用している。これらすべてのチェックを行う目的はシンプルだ。光ファイバーチップで、すべてがしかるべきところにあるかをチェックし、すべてのFibre Channelフレームが正しく到達することを確認するのだ。内部チェックも行い、チップ内のステータスレジスタもチェックしている。ここまでくると、合格/不合格を判定するだけだ」（Paulson氏）。 　バグを発見すると、チームはそのテストを戻し、データベースをワークステーションにアップロードする。そしてデバッグツールをオフラインで使用する。「最初からかなりの範囲をトレースで見られるし、かなりの数の信号を確認できる」とPaulson氏は言う。彼のチームでは、ソフトウエアで設計を再構築するCadence社の「IXE 3.0」の使用も開始した。「信号の確認に費やせる時間が大幅に増えるだろう。Novas Debussyの波形が採用されているため、シミュレータを使っているような感覚だ。欠陥を見つけたら、その波形を取り出して、設計者を呼んで来て問題の個所を修正し、エミュレータを再合成して戻せばいい。1〜2時間で済んでしまうこともあるだろう」とPaulson氏は語った。

MIPS社が進める、試作環境の整備 　マイクロプロセッサコアベンダーの米MIPS Technologies社は、コアの開発にいくつかのハードウエア支援検証方法を用いている。MIPS社でCADと情報システムのディレクタを務めているDonald Ramsey氏のグループでは米Mentor Graphics社のVStationエミュレータを使用しているが、検証のため、そして顧客のために、自分達でも試作ボードを製作している。同社のプロセッサコアのゲート数は50万〜100万の規模であるため、エミュレーションボードとシングルFPGA試作ボードのどちらでコアを実行するにしても、容量に問題はない。 「問題はゲート数ではなく、複雑さだ。汎用プロセッサのコーナーケースは深く、設計の実動作テストと擬似ランダムテストを何度も繰り返したうえで、検証とデバッグの手段として、そしてソフトウエア検証のために試作設計とエミュレーションを実行する必要がある。我々はコアを設計する際には、ソフトウエアツールが機能することも期待しているのだ」（Ramsey氏）。 　マイクロプロセッサコアの設計は、コンピュータファームでのRTLシミュレーションから始まる。MIPS社はこのプロセスで、まずエミュレーションを実施する。2台のVStationエミュレータのうち1台は機能検証に使用し、システムに接続するもう1台はデバッグを目的としたインサーキットエミュレーションに使用している。検証用のエミュレータは、高速で局所的、かつランダムな検証を行うためのシミュレーションアクセラレータとして使用する。「我々のエミュレータは1日に約10億サイクルを処理している。高速なシミュレーションエンジンのようなものだ」とRamsey氏は言う。 　別のVStationはシステムレベルのシミュレーションに使用する。「アプリケーションをRTLシミュレータ上で実行することはできない。遅すぎるということもあるが、システム環境にはコアだけでなく、システムコントローラやメモリーなどが必要であり、抽象化する必要があるからだ。ゲート数の問題に取り組むのはその後だ」（Ramsey氏）。 　MIPS社では、インシステムテストでRTL記述されたコアをテストするのではなく、設計をエミュレータにロードする。エミュレータを使用するまでは、設計グループは社内のソフトウエア開発者が組み込みソフトウエアの開発に早く着手できるよう、以前に開発された試作ボードを使用していた。「基本的には、ディスクドライブやキーボードなどを接続できるPCIスロットを備えたAT仕様のプリント基板だった。このシステムでは、プロセッサの代わりに、2つのスロットを搭載したドーターカードを使用していた。スロットの一つは、システムコントローラをプログラムするFPGA用で、もう一つはMIPSプロセッサを搭載するためのもの」（Ramsey氏）。 　MIPS社はその後、エミュレータをFPGA試作システムに接続し、詳細なシステムデバッグを実施するための新しいドーターカードを作成した。また、プロセッサの設計をこのドーターカード上のFPGAに直接プログラムしている。FPGA試作品はインサーキットのものよりも速く動作でき、バグも識別できるが、コードの深い部分にあるバグを見つけることは困難だ。FPGA試作品が25MHz〜40MHzで動作するのに対し、エミュレータを使用するシステムの動作速度は1MHz〜3MHzである。このスピードだと、メモリー内や、オペレーティングシステムにハードコーディングされているインターバルタイマー内で自然に発生するウェイト状態を見越して、大量のクロックバッファリングを行わねばならないとRamsey氏は言う。FPGA試作品は実プロセッサの1/8〜1/12の速度で実行されるため、デバッグにより適したものといえる。 　多くのメモリーサブシステムは、速度が1/8〜1/12に低下しても問題なく動作する。「FPGAは、少し遅いというだけで、通常のシステムのすべての特性を備えているといえる。しかし、25MHzから1MHzに落とすと、実システムとはかけ離れた動作になってしまう。ボード上に遅いメモリーが搭載されている場合でさえ、次のサイクルでデータが返されるようなことが発生する。メモリーやその他のペリフェラルを常に使用できるからといって、実システム内のすべてのウェイト状態をモデリングしているわけではないことには注意が必要だ」（Ramsey氏）。 　同氏によれば、設計者はOSにハードコーディングされたインターバルタイマーの問題に直面することもあるという。「ある程度のタイムスケーリングも必要である」と同氏は語る。開発サイクルが短くなっているため、MIPSでは最終設計のハードウエアデバッグにエミュレータとFPGA試作品を使用している。「私達はエミュレータ上で動作させることで多くの問題点を早く見つけ出そうとしたが、現実の開発スケジュールに合わせるにはもっと速いプラットフォームが必要なことがわかった。そこで、FPGA試作品を使用することにした。これで数時間ではなく数分でOSのバグを発見できるようになった」（Ramsey氏）。 　バグが見つかっても、その発生源を特定するのも難しかったと同氏は言う。「エミュレータでは、リアルタイムの可視性は100％だが、このエミュレーションシステムでは完全な履歴が残らないため、イベントが捕捉されそうなところの寸前でトリガーする必要がある。エミュレーションでは、実行を繰り返してトリガーポイントを見つけ出すことに終始することになる。そして異常が見つかれば、決定的証拠をつかんだことになる。FPGAによる検証では、その反対である。トリガーポイントがどこにあるのかは分かっていても、正しい信号群が得られるまで実行し続ける必要がある。その後、検証レポートを書いて、シミュレータ上で実行して、自分の理論を検証する」（Ramsey氏）。 　検証レポートを書けないこともある。複雑なプロセッサ内の割り込み、メモリー速度、プロセッサ速度と、数多くの特殊な動作とのずれがあるために、問題をピンポイントで特定することが難しくなってきたからだ。エミュレーションシステムに従来からある問題の一つは、ユーザーが設計のデバッグにかける時間と同じくらいの時間を、エミュレータのデバッグに費やさねばならないことである。 　EDAベンダーはエミュレーションシステムの容易化を進めているが、Ramsey氏のグループはエミュレータの欠点をなくす作業も行ってきたのだ。 ▲本文へ戻る 購入の検討 Mike Dini 　試作用のカスタムハードウエアを設計する場合、開発にかかるコストは条件次第で大きく違ってくる。設計に必要なデバイスの数もコストを決める大きな要因と言える。エンジニアリングチームが最初から正しい回路基板に行き着いたとしよう。プロトタイプの「製作」に関連する開発コストの範囲は、定義フェーズ（約2週間）、設計フェーズ（4〜6週間）、回路基板のレイアウト（4〜12週間）に及ぶ。設計者はこのほか、部品調達に2週間、組み立てに2週間、テストに4〜6週間を見ておかねばならない。これらすべてのフェーズを合わせると、全体で18〜30週間の期間を要する。さらに、回路基板の一般的なNRE（nonrecurring engineering）費として3000〜5000米ドル、マスク費約1000米ドル、小ロットの初期組み立て費2500米ドルを考慮に入れておく必要がある。 　部品調達と一部のテスト機能は設計プロセスの過程で同時に検討できるが、試作の定義、回路図の作成、回路基板のレイアウト、組み立ては順番に行われなくてはならない。最初の組み立て品を入手してから2週間を必要とする場合は、自作品を動かせるまでに少なくとも16週間がかかることを意味する。エンジニアの単位料金が1時間100米ドルだとすると、6万4000米ドル分のエンジニアリング時間と最低5500米ドルのNRE費が必要だ。 　上記の数字はベストケースのシナリオに基づいている。一般に試作品を設計する場合は、少なくとも4〜6カ月間の時間と10万米ドルのコストがかかる。3個以上の大規模FPGAを使用するならば、レイアウトだけで12週間近くかかる。BOM（部品）コストの大半はFPGAのコストによって決定される。また、LVDSやギガビット単位のシリアルインターフェースを必要とする場合は、設計に要する時間は劇的に増加する。 ▲本文へ戻る 用語解説 / 会社情報 ＊1） Moretti,Gabe,"Hardware tools aid engineers in design verification," EDN, Aug 30, 2001, pg 77, http://www.edn.com/article/CA152890.html ▲本文へ戻る