JP2004164056A - 検証環境構築方法および検証環境構築システム - Google Patents

Abstract

【課題】論理回路を検証するシステムを構築するに際し、テスト用データの入出力インタフェース数の適正化を簡易かつ低コストで実現できるようにする。
【解決手段】インタフェース数決定装置１００ として、データ方向性情報Ｊ２、システム動作の周波数を示すクロック情報Ｊ４、検証項目ごとの検証モード情報Ｊ６、データの入出力が行なわれている時刻に関するアクセス情報Ｊ８をそれそれ取得する情報取得部１１２ 〜１１８ を設ける。また、各情報取得部１１２ 〜１１８ にて取得された各情報Ｊ２〜Ｊ８を用いて、システム検証に必要かつ適正なインタフェース数を決定するインタフェース数決定部１２０ を設ける。インタフェース数決定部１２０ は、複数の異なったデータが同一インタフェース上で入出力可能か否かを判定することで、競合が起きない範囲でインタフェースを共用し、データ用Ｉ／Ｆ部９６ａ ，９６ｂ にて使用される必要最低限のデータ入出力数を決定する。
【選択図】 図２

Description

【０００１】
【発明の属する技術分野】
本発明は、半導体装置の論理検証を行なうための検証システム（エミュレータシステム）を構築する方法およびシステムに関する。
【０００２】
【従来の技術】
半導体技術の進歩により、論理ＩＣの集積度は益々向上し、大規模システムを１チップに集積することが可能となり、また１チップまたは複数のＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ：大規模集積回路）で電子機器などのシステムを構築することが可能になりつつある。
【０００３】
１チップＬＳＩやＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ ＩＣ ：特定用途向け集積回路）などの半導体装置を開発する場合、一般的には、半導体装置（ターゲット回路）の内部の論理回路の論理動作を検証（デバッグ）した後に、実際のデバイス（チップ）を製造することが行なわれている。
【０００４】
この論理検証の手法としては、たとえば、論理シミュレーション（ソフトウェアシミュレーション）がある。これは、論理検証の対象となる論理回路の動作を電子計算機（たとえばワークステーションなどのコンピュータ）で実現し、所定の入力パターンに対する出力を予想して解析する（ソフトウェア的に波形解析をする）の仕組みのものである。
【０００５】
しかし、この論理シミュレーションでは、実際の論理回路に比べて動作速度が遅く、論理回路の規模が大きくなるとステップ数が非常に膨大となり論理検証時間が長時間に亘るという問題や、回路部材のソフトウェアモデリングが困難で、必ずしも実回路の動作と等価にはならず、システム全体を忠実にシミュレーションすることは難しいという問題がある。このため、論理シミュレーションのみでシステム全体の論理回路検証を行なうことは事実上不可能である。
【０００６】
また、論理検証の他の手法として、ターゲット回路に対応するハードウェア要素としての試作ＬＳＩや基板による試作品を用いて検証を行なう手法もある。この手法では、たとえば試作ＬＳＩのパターンニングなどを要するため試作品を得るために数週間を要するので、繰り返して試作品を作り検証を行なうことは難しい。
【０００７】
上記の検証手法の問題を解消するものとして、今日では、論理エミュレーション（ハードウェアエミュレーション／ロジックエミュレーション）による論理検証が注目されている（たとえば、特許文献１参照）。
【０００８】
【特許文献１】
特開２００２−２２９８１３号公報
【０００９】
この論理エミュレーションは、ターゲット回路についての論理動作を、ターゲット回路とは別種のハードウェア要素を使用して論理検証するもので、たとえば、ＬＳＩや電子計算機などの論理回路と等価な動作をプリント基板上に搭載した複数の電子部品（ターゲット回路に対応する別種のハードウェア要素）で実現し、実際の論理回路に近い動作速度で回路を動作させて論理回路を検証するものである。
【００１０】
たとえば、ＬＳＩ設計データを読込みＬＳＩと等価な動作を行なうプログラマブルに構成可能な半導体集積回路（ＦＰＧＡ；Ｆｉｌｅｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｌｌｅｙ：フィールドプログラマブルゲートアレイ）などで構成されたエミュレータによって実現され、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ ；中央演算処理装置）やメモリなどの汎用部品を外部のプリント基板に実装し、エミュレータとプリント基板を接続し、実際の論理回路に近い動作速度で回路を動作させて論理回路を検証する。
【００１１】
この論理エミュレーションの手法によれば、数１００万ゲート規模のシステムを構成することができ、システム全体として実速度に近い動作速度での検証が可能であり、コンピュータを用いたソフトウェアシミュレーションよりも数千分の１程度の時間で検証結果が得られる。また、ＦＰＧＡは回路構成が可変であるので、検証中にＦＰＧＡの回路構成を変更して機能確認を行ない最終の回路を決定した後、システム全体の論理回路検証（評価）を実回路に近い動作速度で行なうこともできる。このとき、ＦＰＧＡを用いて回路構成を変更しながら論理回路検証することによって、新規に設計する特定機能の論理回路やユーザ個別の論理回路を確定することもできる。これによって、特定用途向け集積回路ＡＳＩＣを比較的短期間に提供することも可能となる。
【００１２】
【発明が解決しようとする課題】
一方、近年の半導体装置は、回路が複雑化し、プロセッサやメモリを内蔵することが可能となり、またシステムも大規模になっており、ＣＰＵ、論理回路、記憶装置などの機能をそれぞれ単体で有するだけではなく、それらを１つのチップ上に搭載して所望のシステムを実現するＳＯＣ（Ｓｙｓｔｅｍ Ｏｎ Ｃｈｉｐ：システムオンチップ）化が進んでいる。
【００１３】
このため、ＳＯＣを検証対象とした場合、検証項目も急激に増加している。この場合、当然、ソフトウェアシミュレーションでは検証時間が長期に亘るため検証できない項目も出てくる。よって、試作チップなどを搭載する試作基板を用いてシステム検証を行なうことや、さらに好ましくは、論理エミュレーションを用いてシステム検証を行なうことが必要となる。
【００１４】
ここで、ソフトウェアシミュレーションの検証環境を試作基板や論理エミュレーションを用いた検証環境に適応した場合、ソフトウェアシミュレーションのデータ入出力の仕様はそれぞれ異なるため、従来の検証手法では、仕様に合わせて専用のインタフェースを構築していた。
【００１５】
しかし、異なる仕様に合わせて別々に専用のインタフェースを用意する場合、そのボードを開発する工数が増大する。また、過去に作成したインタフェースボードを活用することができない。つまり、共有できるインタフェースボードがあり得るにも関わらず、常に専用のインタフェースを構築してしまいコスト増加が問題となってくる。また、検証環境の大規模化は、開発期間を長期化させ、意図しない問題を発生させる要因ともなる。
【００１６】
さらに、設計者は経験的に独自の条件でインタフェースの数（ボードの場合はボード数）を決定しているため、決定したデータ入出力数が適切な数（好ましくは必要最低数）になるとは限らない。また、適正数（好ましくは必要最低限の数）のインタフェース数を決定する処理手順や条件が明確でないため、経験の少ない設計者は、適正数を決定することができないという問題もある。
【００１７】
このように、ソフトウェアシミュレーションの検証環境を試作基板や論理エミュレーションを用いた検証環境に適応させる場合、従来の手法では、開発工数とコストの点で難がある。
【００１８】
なお、エミュレーションに関する技術として特許文献２に記載のものがある。特許文献２に記載の技術は、たとえば、比較的簡易なプログラムを実行する１チップマイクロコンピュータなどのターゲットシステムによるシステム運用開始後のプログラムのバグに対し、パッチを当てるためのエミュレーションを実行するターゲットデバッグ支援に関するものである。
【００１９】
【特許文献２】
特開２００１−３０６３５７号公報
【００２０】
この特許文献２の手法では、エミュレーションを実行時に、ターゲットシステムにおける演算制御装置が、エミュレータ用インタフェースとメモリとの通信を行なうための比較的簡易プログラムを、エミュレータがターゲットシステムのワーキング用メモリの空き記憶エリアにロードさせることで、ターゲットシステムの中央演算処理装置がメモリとの通信を行なうようにし、これにより、エミュレータ用インタフェースを簡易化し、効率的なプログラム修正を可能にしている。
【００２１】
しかしながら、特許文献２の手法は、ソフトウェアデバッグに関わるもので、ソフトウェアシミュレーションの検証環境を試作基板や論理エミュレーションを用いた検証環境に適応させる場合に、特許文献２に記載の技術を適用してエミュレータ用インタフェースを簡易化する仕組みを講じることは難しい。
【００２２】
本発明は、上記事情に鑑みてなされたものであり、ターゲット回路についての論理動作をこのターゲット回路に対応するハードウェア要素を使用して論理検証する際に必要かつ適正なインタフェース数を簡易に決定することのできる方法およびシステムを提供することを目的とする。
【００２３】
【課題を解決するための手段】
すなわち、本発明に係る検証環境構築方法は、ターゲット回路についての論理動作を当該ターゲット回路に対応するハードウェア要素を使用してターゲット回路と略同様の動作速度で検証する環境を構築するための検証環境構築方法であって、検証システム本体への検証データの入出力に関する情報に基づいて、検証に必要かつ適正な検証データ用のインタフェース数を決定することとした。
【００２４】
ターゲット回路に対応するハードウェア要素は、半導体などのターゲット回路に相当する試作品であってもよいし、半導体の回路を回路基板上に構成したものであってもよい。また、半導体などのターゲット回路そのものとは別種のハードウェア要素（ＦＰＧＡやメモリなど）にて構成したものであってもよい。
【００２５】
本発明に係る検証環境構築システムは、本発明に係る検証環境構築方法を実施するのに好適なシステムであって、ターゲット回路についての論理動作を検証する際に使用される検証データを検証システム本体へインタフェースするインタフェース部と、検証システム本体へインタフェースされる検証データに関する情報を取得する検証情報取得部と、検証情報取得部により取得された検証データに関する情報に基づいて、インタフェース部における、検証に必要かつ適正な検証データ用のインタフェース数を決定するインタフェース数決定部とを備えるものとした。
【００２６】
また、従属項に記載された発明は、本発明に係る検証環境構築システムのさらなる有利な具体例を規定する。
【００２７】
たとえば、インタフェース数決定部は、複数の異なった検証データが同一インタフェース上で入出力可能か否かに基づいてインタフェース数を決定するものとすることが望ましい。
【００２８】
また、検証情報取得部は、それぞれ検証データに関する情報の一例である、検証項目ごとの検証データの使用状況を示す情報である検証モード情報、検証データの入出力が行なわれる時刻に関する情報であるアクセス情報、および検証動作中の検証データの周波数を示すクロック情報、のうちの少なくとも１つの情報を取得する機能要素を備えているものとするとよい。さらに好ましくは、検証データに関する情報の一例である、検証システム本体への検証データの方向に関するデータ方向性情報を取得する機能要素を備えているものとするとよい。
【００２９】
また、インタフェース部は、ＩＳＡバスやＰＣＩバス、あるいはＵＳＢやＩＥＥＥ１３９４などのように、ある一定の規格を満足する標準インタフェースの機構を持つものであることが望ましい。
【００３０】
なお、本発明に係る検証環境構築方法およびシステムを、電子計算機（コンピュータ）を用いてソフトウェアで実現するために好適なプログラムあるいはこのプログラムを格納したコンピュータ読取可能な記憶媒体を発明として抽出することもできる。なお、プログラムは、コンピュータ読取り可能な記憶媒体に格納されて提供されてもよいし、有線あるいは無線による通信手段を介して配信されてもよい。
【００３１】
【作用】
上記構成においては、先ず、検証システム本体への検証データの入出力に関する情報を入手する。たとえば、ソフトウェアシミュレーションにて用いられていた検証データに関する情報を入手する。そして、この情報に基づいて、競合（データの衝突）が起きないように、システム検証に必要かつ適正なインタフェース数を決定する。たとえば、希望するインタフェース数になるまで、インタフェース数を削減するための条件設定にしたがって、複数ある入出力データのインタフェースが、同一インタフェースを使用可能かどうかを判定する。あるいは、必要最小限のインタフェース数を求める。
【００３２】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態について詳細に説明する。
【００３３】
図１は、論理エミュレーションを行なうための検証システム（論理エミュレーションシステム）の概略構成を示す図である。
【００３４】
検証システム１は、エミュレータ本体１０、ＳＯＣに内蔵するＣＰＵやテストチップ２２を搭載したＣＰＵボード２０、ＳＯＣに内蔵する大規模メモリや高性能メモリ３２を搭載した外部メモリボード３０を備える。
【００３５】
エミュレータ本体（検証システム本体）１０には、ＬＳＩ設計データを読込みＬＳＩと等価な動作を行なうプログラマブルに構成可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ ）１２で構成されたロジック回路１４、メモリ１６、テストベンチ回路１８などで構成されている。
【００３６】
メモリ１６としては、たとえば、ＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ ）やＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などの、随時書込みおよび随時読出しが可能な記憶保持動作をするメモリを使用するとよい。なお、ＦＰＧＡ１２やメモリ１６は、検証対象となるターゲット回路のシステム規模が小さければ１個でもよいが、システム規模が大きくなれば各々複数個が使用される。
【００３７】
ＣＰＵボード２０や外部メモリボード３０は、必要に応じて複数枚が用意されるようになっている。エミュレータ本体１０と、これらＣＰＵボード２０および外部メモリボード３０との間は、インタフェース（Ｉ／Ｆ）部９０を構成する外部ボード接続用Ｉ／Ｆ部９２にて接続されるようになっている。
【００３８】
また、検証システム１は、エミュレータ本体１０の周辺に、ＦＰＧＡ１２の論理機能を決定する論理機能定義データをＦＰＧＡ１２にロード（供給）したり、あるいは検証システム全体を監視若しくは制御したりするためのコントローラＰＣ（ＰＣ；Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ ）８０、論理設計データを生成するワークステーション８２、検証用のテストデータ（入力データ）をエミュレータ本体１０にロードしたり検証結果のデータ（出力データ）を読み込み保持したりするためのデータ入出力用ＰＣ８４，８６、および検証中のロジックデータを監視するためのロジックアナライザ（以下ロジアナという）８８を備える。
【００３９】
なお、検証用のテストデータ（入力データ）は、ソフトウェアシミュレーションにおいて使用するものと同様のものを使用すればよい。この検証用のテストデータは、エミュレータ本体１０のテストベンチ回路１８を介してＦＰＧＡ１２に供給されることで、ソフトウェアシミュレーションの検証環境を論理エミュレーションを用いたシステム検証装置（すなわち検証システム１）で実現するようになる。また、その検証結果のデータ（出力データ）がテストベンチ回路１８を介してデータ入出力用ＰＣ８４，８６に出力され、所定の記憶媒体（たとえばハードディスク装置など）に格納される。なお、この場合の検証用のテストデータ（入力データ）と検証結果のデータ（出力データ）とを纏めて、以下「ソフトウェアシミュレーション用入出力データ」という。
【００４０】
コントローラＰＣ８０はコントローラ用Ｉ／Ｆ部９４にて専用ケーブルで、データ入出力用ＰＣ８４，８６はデータ用Ｉ／Ｆ部９６ａ，９６ｂにてＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ ）バス若しくはＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バスで、ロジアナ８８はロジアナ用Ｉ／Ｆ部９８にて専用プローブで、それぞれエミュレータ本体１０と接続されるようになっている。
【００４１】
検証データのエミュレータ本体１０へのインタフェースをなすデータ用Ｉ／Ｆ部９６ａ，９６ｂとして、ＰＣＩバスやＩＳＡバスなど共通のインタフェース機構を持たせることで、複数の異なったデータが同一インタフェース上で入出力可能となる。
【００４２】
なお、データ用Ｉ／Ｆ部９６ａ，９６ｂとしては、ＰＣＩバスやＩＳＡバス以外のパラレルの標準インタフェースを使用してもよい。また、パラレルバスインタフェースに限らず、たとえばＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ， Ｉｎｃ． ；米国電気電子学会）１３９４規格やＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）１．０／２．０規格、もしくはＰＣＩ規格の一例である“ＰＣＩＥｘｐｒｅｓｓ（商標）”（ピーシーアイエクスプレス）などのシリアルインタフェースであってもよい。標準インタフェースを使用すれば、汎用のパソコンなどをデータ入出力装置として利用することができ、データインタフェースの共通化や汎用化を進めることが可能となる。
【００４３】
ＰＣＩバスやＩＳＡバスなどのパラレルバスインタフェースやＵＳＢやＩＥＥＥ１３９４などのシリアルインタフェースをはじめとする標準インタフェースは、ＩＥＥＥやＪＩＳ（日本工業規格）などの非商業的組織または政府組織（公的な規格団体）によって認められた正当な（法律上の）技術的ガイドラインに従った、ハードウェア開発またはソフトウェア開発の領域において均一性を確立するために使用される公的なインタフェースであるのがよい。
【００４４】
また、このような公的なインタフェースに限らず、民間団体や単一の会社にて取り纏められた私的な標準インタフェース、いわゆる業界標準インタフェース（工業標準インタフェース）であってもかまわない。何れにしても、標準インタフェースは、ある一定の規格を満足する接続インタフェースであればよい。
【００４５】
たとえば、ある会社によって製品または理念が開発され、成功と模倣を通じて標準からの逸脱が互換性の問題を引き起こすか、または市場性を制限する程広く使用されるようになる場合に生じるハードウェア開発またはソフトウェア開発に関する事実上の（ｄｅ ｆａｃｔｏ）技術的ガイドライン（非公式な規格）が、本実施形態の標準インタフェースとして採用されてもよい。
【００４６】
コントローラＰＣ８０とワークステーション８２とは、ネットワークＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）で接続されている。ワークステーション８２は、たとえばＲＴＬ（Ｒｅｇｉｓｔｅｒ Ｔｒａｎｓｆｅｒ Ｌｅｖｅｌ ）若しくはＨＤＬ（Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ ）といわれる形式で論理記述された論理設計データを生成する。また、ワークステーション８２は、その論理設計データの対応回路部分の記述データまたはその記述データを所定のデータフォーマットに変換したデータをコントローラＰＣ８０に渡す。コントローラＰＣ８０は、このデータを解読して、ＦＰＧＡ１２に論理機能を設定するのに必要な論理機能定義データを生成し、これをＦＰＧＡ１２にロードすることで、ＡＳＩＣやＳＯＣなどに対応するターゲット回路を実装（インプリメント）する。
【００４７】
また、ワークステーション８２は、ターゲット回路評価のために生成したロードモジュールをコントローラＰＣ８０に渡す。このロードモジュールは、ＦＰＧＡ１２を有するエミュレータ本体１０やエミュレータ本体１０に接続されたＣＰＵボード２０などに供給され、インサーキットエミュレーションのように、開発対象とされるターゲット回路上でＦＰＧＡ１２を実際の論理回路（ターゲット回路に対応するＡＳＩＣやＳＯＣなど）に近い動作速度で動作させることで、システムデバッグやソフトウェアデバッグなどの検証あるいはテストを行なうために利用される。
【００４８】
この検証システム１の周辺システムとして、システム検証に必要かつ適正なインタフェース数を決定するための検証環境構築システム３が用意される。この検証環境構築システム３は、それぞれネットワークＬＡＮで接続されたインタフェース数決定装置１００と、ワークステーション８２と、データ入出力用ＰＣ８４，８６とで構成される。なお、たとえば、ワークステーション８２にインタフェース数決定装置１００の機能を持たせてもよい。
【００４９】
図２は、インタフェース数決定装置１００の機能ブロック図の一例である。図示するように、インタフェース数決定装置１００は、エミュレータ本体１０とデータ入出力用ＰＣ８４，８６との間の検証データの方向に関するデータ方向性情報Ｊ２を取得するデータ方向性情報取得部１１２、エミュレータ本体１０の検証動作中の検証データの周波数を示すクロック情報Ｊ４を取得するクロック情報取得部１１４、検証項目ごとの検証データの使用状況を示す情報（以下検証モード情報という）Ｊ６を取得する検証モード情報取得部１１６、およびデータの入出力が行なわれている時刻に関する情報（以下アクセス情報という）Ｊ８を取得するアクセス情報取得部１１８を備える。
【００５０】
また、インタフェース数決定装置１００は、各情報取得部１１２，１１４，１１６，１１８（纏めて検証情報取得部１１０ともいう）にて取得された各情報（ソフトウェアシミュレーション用入出力データに関する情報）Ｊ２〜Ｊ８を用いて、データ競合が生じることなくシステム検証に必要かつ適正なインタフェース数を決定するインタフェース数決定部１２０を備える。インタフェース数決定部１２０は、検証情報取得部１１０にて取得された各情報に基づき、複数の異なったデータが同一インタフェース上で入出力可能か否かを判定することで、データ用Ｉ／Ｆ部９６ａ，９６ｂにて使用される適切なインタフェース数を決定する。たとえば、競合が起きない範囲で、できるだけインタフェースを共用するようにすることで、必要最低限のデータ入出力数（インタフェース数）を決定する。
【００５１】
図３は、ソフトウェアシミュレーションの検証環境の一例を示す図である。図示した例では、回路情報Ｄ２００に対して、異なる８種類のテストデータＤ２１０（具体的には、Ｄ２１２，Ｄ２１４，Ｄ２１６，Ｄ２１８，Ｄ２２０，Ｄ２２２，Ｄ２２４，Ｄ２２６）が存在し、それぞれ異なるデータ入出力（テストデータＡ〜Ｈ）の仕様がある。仕様に合わせた専用インタフェースを作製するのではなく、たとえば、ＰＣＩバスを利用したＩ／ＦボードやＩＳＡバスを利用したＩ／Ｆボードなどの共通のインタフェース機構を有したボードを作製する。これにより、データ入出力のフォーマットを共通化することができ、複数のデータ入出力を同一インタフェースで実現が可能となる。
【００５２】
図４は、インタフェース数決定装置１００におけるインタフェース数決定の処理手順の第１例の概要を示すフローチャートである。この第１例は、データ用Ｉ／Ｆ部９６ａ，９６ｂが双方向のデータ入出力が可能である場合の例である。
【００５３】
始めに、検証情報取得部１１０内の各部は、データ入出力用ＰＣ８４，８６からソフトウェアシミュレーションのデータに関する情報の入力を受けて、それぞれ所定の情報（Ｊ４，Ｊ６，Ｊ８）を取得し、インタフェース数決定部１２０に通知する。
【００５４】
これを受けて、インタフェース数決定部１２０は、ソフトウェアシミュレーションのデータ入出力数をインタフェース数の暫定数とする（Ｓ１００）。なお、この第１例では、データ用Ｉ／Ｆ部９６ａ，９６ｂが双方向性を有することがはじめから分かっているので、データ方向性情報取得部１１２を介したデータ方向性情報Ｊ２の取得は不要である。
【００５５】
次に、インタフェース数決定部１２０は、各情報取得部１１４，１１６，１１８を介して取得したクロック情報Ｊ４，検証モード情報Ｊ６，アクセス情報Ｊ８を参照して、データ入出力の実現方法を決定する（Ｓ１１０）。そして、最後にデータ入出力の仕様から必要な転送レートやプロトコルに適応したインタフェースを採用する（Ｓ１４０）。
【００５６】
図５は、インタフェース数決定部１２０に通知されるクロック情報Ｊ４の一例を示す図表である。この図表は、ソフトウェアシミュレーションに対応した論理シミュレーションを行なう際、すべての検証項目に対して各々が使用すべきクロック周波数を明示し、リスト化したものを示している。この図表例では、クロック周波数として、Ａ−ＩＦおよびＢ−ＩＦ用の３３ＭＨｚ，Ｃ−ＩＦおよびＤ−ＩＦ用の５０ＭＨｚ，Ｅ−ＩＦおよびＦ−ＩＦ用の１００ＭＨｚ，Ｇ−ＩＦおよびＦ−ＩＦ用の１３３ＭＨｚの４種類が存在している。
【００５７】
図６は、インタフェース数決定部１２０に通知される検証モード情報Ｊ６の一例を示す図表である。この図表では、検証項目がＭｏｄｅ１からＭｏｄｅ６まであり、データ入出力数は、Ａ−ＩＦ（テストデータＤ２１２）からＨ−ＩＦ（テストデータＤ２２６）まで８つ存在する。この図表は、ソフトウェアシミュレーションを行なう際、すべての検証項目に対して使用しているデータと使用していないデータがどれであるかを明示し、リスト化したものを示している。
【００５８】
図７は、インタフェース数決定部１２０に通知されるデータアクセス情報Ｊ８の一例を示す図表である。この図表では、検証項目Ｍｏｄｅ１のソフトウェアシミュレーションの結果などから各データの入出力が連続で行なわれている開始時刻と終了時刻の情報を算出し、リスト化したものを示している。
【００５９】
図８は、図４に示したデータ入出力の実現方法を決定するステップＳ１１０（インタフェース数決定処理）の詳細例を示すフローチャートである。インタフェース数決定部１２０は、先ず、ソフトウェアシミュレーション用テストデータ（テストデータＤ２１２〜Ｄ２２６）をクロック周波数ごとに分類する（Ｓ１１２）。
【００６０】
検証データ入出力用のインタフェース部であるデータ用Ｉ／Ｆ部９６ａ，９６ｂとして、検証データのクロック周波数に適応した回路を使用するようにするためである。より具体的には、複数ある検証データのうちの最大周波数に合わせて全てのインタフェース回路を構成することも考えられるが、この場合、低周波数で十分な検証データ用に高周波数対応可能なインタフェース回路を用いることはコストの点で不利となるので、個々の検証データのクロック周波数に適応したインタフェース回路を使用するようにするためである。
【００６１】
次に、インタフェース数決定部１２０は、検証モード情報Ｊ６から分類されたデータが同一検証モードで使用するかどうかを判定する（Ｓ１１４）。分類されたデータが異なる検証モードで使用する場合は（Ｓ１１４−ＮＯ）、同一インタフェースで入出力が可能となり、インタフェースを同一ボードで実現することでインタフェース数を削減することができる（Ｓ１２４）。
【００６２】
一方、分類されたデータが同一検証モードで使用する場合は（Ｓ１１４−ＹＥＳ）、インタフェース数決定部１２０は、アクセス情報Ｊ８から分類されたデータが同時刻にアクセスがあるか否かを判定する（Ｓ１１８）。同時刻にアクセスが存在しなければ（Ｓ１１８−ＮＯ）、分類されたデータは同一インタフェースでデータ入出力が可能となり、インタフェースを同一ボードで実現可能となる（Ｓ１２０）。分類されたデータが同時刻にアクセスが存在する場合は（Ｓ１１８−ＹＥＳ）、データ入出力は別々のインタフェースで実現することになるので、インタフェースを別ＩＦボードで実現する（Ｓ１２２）。
【００６３】
このように、第１例のインタフェース数決定処理では、データ入出力が双方向に対応しているインタフェースの場合、検証項目に応じたクロック情報Ｊ４と検証項目ごとのデータの情報である検証モード情報Ｊ６とデータの入出力が行なわれている時刻情報であるアクセス情報Ｊ８とを用いて、複数の異なったデータが同一インタフェース上で入出力可能か否かを決定することで、システム検証用に適正なインタフェース数を決定する。
【００６４】
図９は、インタフェース数決定装置１００におけるインタフェース数決定の処理手順の第２例の概要を示すフローチャートである。第２例は、データ用Ｉ／Ｆ部９６ａ，９６ｂが単方向のみのデータ入出力が可能である場合の例である。
【００６５】
始めに、検証情報取得部１１０内の各部は、データ入出力用ＰＣ８４，８６からソフトウェアシミュレーションのデータに関する情報の入力を受けて、それぞれ所定の情報（Ｊ２，Ｊ４，Ｊ６，Ｊ８）を取得し、インタフェース数決定部１２０に通知する。これを受けて、インタフェース数決定部１２０は、ソフトウェアシミュレーションのデータ入出力数をインタフェース数の暫定数とする（Ｓ２００）。
【００６６】
次に、インタフェース数決定部１２０は、各情報取得部１１２，１１４，１１６，１１８を介して取得したデータ方向性情報Ｊ２，クロック情報Ｊ４，検証モード情報Ｊ６，アクセス情報Ｊ８を参照して、データ入出力の実現方法を決定する（Ｓ２１０）。そして、最後にデータ入出力の仕様から必要な転送レートやプロトコルに適応したインタフェースを採用する（Ｓ２４０）。
【００６７】
図１０は、インタフェース数決定部１２０に通知されるデータ方向性情報Ｊ２の一例を示す図表である。この図表では、検証項目がＭｏｄｅ１からＭｏｄｅ６まで６モードあり、データ数はＡ−ＩＦからＨ−ＩＦまで８つ存在する。すべての検証項目に対して、ソフトウェアシミュレーションを行なう際、データ入出力がＩＮＰＵＴおよびＯＵＴＰＵＴの何れであるかを明示し、リスト化したものを示している。
【００６８】
図１１は、図９に示したデータ入出力の実現方法を決定するステップＳ２１０（インタフェース数決定処理）の詳細例を示すフローチャートである。このステップＳ２１０の処理は第１例におけるステップＳ１１０の処理に対応するものである。
【００６９】
インタフェース数決定部１２０は、先ず、ソフトウェアシミュレーション用テストデータ（テストデータＤ２１２〜Ｄ２２６）をクロック周波数ごとに分類する（Ｓ２１２）。次に、インタフェース数決定部１２０は、検証モード情報Ｊ６から分類されたデータが同一検証モードで使用するか否かを判定する（Ｓ２１４）。分類されたデータが同一検証モードで使用しない場合（異なる検証モードで使用する場合）は（Ｓ２１４−ＮＯ）、同一インタフェースで入出力が可能となり、インタフェースを同一ボードで実現することでインタフェース数を削減することができる（Ｓ２２４）。
【００７０】
一方、分類されたデータが同一検証モードで使用する場合は（Ｓ２１４−ＹＥＳ）、インタフェース数決定部１２０は、データ方向性情報Ｊ２から分類されたデータが同一方向であるか否かを判定する（Ｓ２１６）。データが同一方向である場合（Ｓ２１６−ＹＥＳ）、インタフェース数決定部１２０は、アクセス情報Ｊ８から分類されたデータが同時刻にアクセスがあるか否かを判定する（Ｓ２１８）。同時刻にアクセスが存在しなければ（Ｓ２１８−ＮＯ）、分類されたデータは同一インタフェースでデータ入出力が可能となり、インタフェースを同一ボードで実現することでインタフェース数を削減することができる（Ｓ２２０）。
【００７１】
データが同一方向でない場合や（Ｓ２１６−ＮＯ）、分類されたデータが同時刻にアクセスが存在する場合は（Ｓ２１８−ＹＥＳ）、データ入出力は別々のインタフェースで実現することになるので、インタフェースを別ＩＦボードで実現する（Ｓ２２２）。
【００７２】
このように、第２例のインタフェース数決定処理では、データ入出力が単方向のみに対応しているインタフェースの場合、検証項目に応じたクロック情報Ｊ４と検証項目ごとのデータの情報である検証モード情報Ｊ６とデータの入出力が行なわれている時刻情報であるアクセス情報Ｊ８とに加えて、検証モードごとの各データの向き（ＩＮＰＵＴとＯＵＴＰＵＴ）をリスト化したデータ方向性情報Ｊ２も用いて、複数の異なったデータが同一インタフェース上で入出力可能か否かを決定することで、システム検証用に適正なインタフェース数を決定する。つまり、データ方向性情報Ｊ２から分類されたデータが同一方向であるか否かを判定するステップＳ２１６の処理が追加されている点で第１例と異なる。
【００７３】
上記のように、第１例および第２例の何れの手法によっても、論理シミュレーションを構築する際のインタフェース数やインタフェースボードの数を適切かつ容易に決定することができる。たとえば、検証環境を最小限で構築することができる。この結果、検証環境の構築に要する開発工数を最小限に抑えることや、短期間で検証環境を構築することも可能となる。加えて、検証環境を最小限で構築することができるので、開発費を低減することも可能となる。
【００７４】
さらに、データ入出力のインタフェース機構をＰＣＩバスやＩＳＡバスなどの標準バスを利用して共通化すれば、インタフェースの再利用が可能となり、開発すべきインタフェース機構の種類を減らし、開発工数を削減でき、コストダウンが可能となる。
【００７５】
このように、上記実施形態で示したインタフェース数決定処理の手法を適用することで、試作基板やロジックエミュレータの検証環境を簡易かつ効率的かつ低コストで構築することができるようになる。
【００７６】
図１２は、図３に示したソフトウェアシミュレーションの検証環境に対して、図６に示した検証モード情報Ｊ６および図７に示したアクセス情報Ｊ８を用いて、図４および図８で示したデータインタフェース数を決定する処理手順を実行した結果による論理回路エミュレータの検証システムの一例を示す図である。
【００７７】
この検証システム５を構築した事例におけるインタフェース数決定処理の手順を具体的に説明する。試作基板ロジックエミュレータ１３０（エミュレータ本体１０に相当）には、ソフトウェアシミュレーション用テストデータＡ〜Ｈが入出力される。
【００７８】
先ず、インタフェース数決定部１２０は、ソフトウェアシミュレーションのデータ入出力数が８つ存在するため、暫定数を“８”とする（Ｓ１００）。そして、データインタフェースの実現方法の決定するステップＳ１１０に進む。
【００７９】
ステップＳ１１０（インタフェース数決定処理）にて、インタフェース数決定部１２０は、各データをクロック周波数ごとに分類する（Ｓ１１２）。たとえば、Ａ−ＩＦとＢ−ＩＦ、Ｃ−ＩＦとＤ−ＩＦ、Ｅ−ＩＦとＦ−ＩＦ、Ｇ−ＩＦとＨ−ＩＦの４グループに分かれるとする。
【００８０】
インタフェース数決定部１２０は、図６に示した検証モード情報Ｊ６から、Ａ−ＩＦとＢ−ＩＦが、同一検証モードで使用することを検出する（Ｓ１１４−ＹＥＳ）。また、図７に示したアクセス情報Ｊ８から、Ａ−ＩＦとＢ−ＩＦは、同時刻にデータアクセスがないことを検出する（Ｓ１１８−ＮＯ）。よって、この２つのデータは、同一インタフェース（ＡＢ−ＩＦ）で入出力が実現可能となる（Ｓ１２０）。この結果、Ａ−ＩＦとＢ−ＩＦを共通のデータ格納部２４２に用意することができる。
【００８１】
インタフェース数決定部１２０は、Ｃ−ＩＦとＤ−ＩＦについても同様な処理を実行する。Ｃ−ＩＦとＤ−ＩＦは異なる検証モードで使用するため（Ｓ１１４−ＮＯ）、同一インタフェース（ＣＤ−ＩＦ）で実現可能となる（Ｓ１２４）。この結果、Ｃ−ＩＦとＤ−ＩＦを共通のデータ格納部２４４に用意することができる。
【００８２】
次に、インタフェース数決定部１２０は、Ｅ−ＩＦとＦ−ＩＦについても同様な処理を実行する。ここで、Ｅ−ＩＦとＦ−ＩＦでは、同一検証モードで使用するが（Ｓ１１４−ＹＥＳ）、データアクセス情報から同時刻のアクセスがあるため（Ｓ１１８−ＹＥＳ）、別々のインタフェース（Ｅ−ＩＦとＦ−ＩＦ）を用いて実現する。この結果、Ｅ−ＩＦとＦ−ＩＦを別のデータ格納部２４６，２４８に用意することになる。
【００８３】
最後に、インタフェース数決定部１２０は、Ｇ−ＩＦとＨ−ＩＦについても同様な処理を実行する。ここで、Ｇ−ＩＦとＨ−ＩＦでは、Ｃ−ＩＦとＤ−ＩＦと同様、異なる検証モードで使用するため（Ｓ１１４−ＮＯ）、同一インタフェース（ＧＨ−ＩＦ）で実現可能となる（Ｓ１２４）。この結果、Ｇ−ＩＦとＨ−ＩＦを共通のデータ格納部２５０に用意することができる。
【００８４】
これらの結果より、試作ボードや論理エミュレーション（６００）を用いたシステム検証を行なうために必要最低限のインタフェース数は“５”となる。このような処理を用いることで、インタフェース数を暫定数の“８”から“５”に削減することが可能であり、たとえばインタフェースボードを５枚にするなど、容易にインタフェース数を決定することが可能である。
【００８５】
なお、上述した一連の処理は、ハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、たとえば汎用のパーソナルコンピュータなどに、記録媒体からインストールされる。
【００８６】
この記録媒体は、コンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク（フレキシブルディスクを含む）、光ディスク（ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）を含む）、光磁気ディスク（ＭＤ（Ｍｉｎｉ Ｄｉｓｃ ）を含む）、もしくは半導体メモリなどよりなるパッケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供されてもよいし、プログラムが記録されているＲＯＭやハードディスクなどで構成されてもよい。あるいは、ソフトウェアを構成するプログラムが、通信網を介して提供されてもよい。
【００８７】
たとえば、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、上記実施形態で述べた効果は達成される。この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行ない、その処理によって前述した実施形態の機能が実現される場合であってもよい。
【００８８】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によって前述の実施形態の機能が実現される場合であってもよい。
【００８９】
以上、本発明を実施形態を用いて説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されない。発明の要旨を逸脱しない範囲で上記実施形態に多様な変更または改良を加えることができ、そのような変更または改良を加えた形態も本発明の技術的範囲に含まれる。
【００９０】
また、上記の実施形態は、クレーム（請求項）にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組合せの全てが発明の解決手段に必須であるとは限らない。前述した実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜の組合せにより種々の発明を抽出できる。実施形態に示される全構成要件から幾つかの構成要件が削除されても、効果が得られる限りにおいて、この幾つかの構成要件が削除された構成が発明として抽出され得る。
【００９１】
たとえば、上述した実施形態では、論理エミュレータシステムを構築する際のデータ入出力用のインタフェース数の削減決定処理の手法について説明したが、実チップなどを搭載する試作基板を用いてシステム検証を行なうシステムにおける、データ入出力用のインタフェース数を決定する際に、上述した処理手順を利用することも可能である。
【００９２】
また、上述した２つのインタフェース数決定処理手順では、エミュレータ本体に入出力される複数のデータについて、インタフェース数が最も少なくなるインタフェースを決定するようにしていたが、必ずしも最低数を求めるものでなくてもよい。たとえば、事前に削減希望のインタフェース数を設定し、順に上述した判定処理を進めて、その設定数に達した段階で、決定処理を停止してもよい。これにより、試作基板やロジックエミュレータの検証環境を効率的に構築することができるとともに、その決定処理の処理時間を短縮することができる。
【００９３】
また、上記実施形態では、先ず、クロック情報Ｊ４を参照して検証データをクロック周波数ごとに分類した後に、検証モード情報Ｊ６やアクセス情報Ｊ８を参照して、データの衝突（競合）が起きない範囲で、できるだけインタフェースを共用するように、インタフェース数を決定していたが、たとえば、全てのインタフェース回路を高周波数対応可能なものとすることで、クロック周波数も含めて、データの衝突が起きない範囲で、できるだけインタフェースを共用するように、インタフェース数を決定してもよい。こうすることで、インタフェース数をさらに削減可能となる。
【００９４】
【発明の効果】
以上のように、本発明によれば、検証システム本体への検証データの入出力に関する情報（たとえば、ソフトウェアシミュレーション用入出力データに関する情報）に基づいて、ターゲット回路に対応するハードウェア要素を利用した論理検証に必要な検証データのインタフェース数を決定するようにしたので、インタフェース数の適正化が簡易な手法で実現可能となる。そしてこれにより、試作基板やロジックエミュレータの検証環境を簡易かつ効率的かつ低コストで構築することができるようになる。
【図面の簡単な説明】
【図１】論理エミュレーションシステムの概略構成を示す図である。
【図２】インタフェース数決定装置の機能ブロック図の一例である。
【図３】ソフトウェアシミュレーションの検証環境の一例を示す図である。
【図４】インタフェース数決定装置におけるインタフェース数決定の処理手順の第１例の概要を示すフローチャートである。
【図５】インタフェース数決定部に通知されるクロック情報の一例を示す図表である。
【図６】インタフェース数決定部に通知される検証モード情報の一例を示す図表である。
【図７】インタフェース数決定部に通知されるデータアクセス情報の一例を示す図表である。
【図８】第１例のインタフェース数決定処理の詳細例を示すフローチャートである。
【図９】インタフェース数決定装置におけるインタフェース数決定の処理手順の第２例の概要を示すフローチャートである。
【図１０】インタフェース数決定部に通知されるデータ方向性情報の一例を示す図表である。
【図１１】第２例のインタフェース数決定処理の詳細例を示すフローチャートである。
【図１２】第１例のインタフェース数決定処理を実行した結果による論理回路エミュレータの検証システムの一例を示す図である。
【符号の説明】
１，５…検証システム、３…検証環境構築システム、１０…エミュレータ本体、１２…ＦＰＧＡ、１４…ロジック回路、１６…メモリ、１８…テストベンチ回路、２０…ＣＰＵボード、２２…ＣＰＵ、３０…外部メモリボード、３２…メモリ３２、８０…コントローラＰＣ、８２…ワークステーション、８４…データ入出力用ＰＣ、８６…データ入出力用ＰＣ、８８…ロジアナ、９０…インタフェース部、９２…外部ボード接続用Ｉ／Ｆ部、９４…コントローラ用Ｉ／Ｆ部、９６ａ，９６ｂ…データ用Ｉ／Ｆ部、９８…ロジアナ用Ｉ／Ｆ部、１００…インタフェース数決定装置、１１０…検証情報取得部、１１２…データ方向性情報取得部、１１４…クロック情報取得部、１１６…検証モード情報取得部、１１８…アクセス情報取得部、１２０…インタフェース数決定部、１３０…試作基板ロジックエミュレータ、Ｊ２…データ方向性情報、Ｊ４…クロック情報、Ｊ６…検証モード情報、Ｊ８…アクセス情報

Claims (9)

1. ターゲット回路についての論理動作を当該ターゲット回路に対応する所定のハードウェア要素を使用して前記ターゲット回路と略同様の動作速度で検証する環境を構築するための検証環境構築方法であって、
   検証システム本体への検証データの入出力に関する情報に基づいて、前記検証に必要かつ適正な前記検証データ用のインタフェース数を決定することを特徴とする検証環境構築方法。
2. ターゲット回路についての論理動作を当該ターゲット回路に対応する所定のハードウェア要素を使用して前記ターゲット回路と略同様の動作速度で検証する環境を構築するための検証環境構築システムであって、
   前記ターゲット回路についての論理動作を検証する際に使用される検証データを検証システム本体へインタフェースするインタフェース部と、
   前記検証システム本体へインタフェースされる前記検証データに関する情報を取得する検証情報取得部と、
   前記検証情報取得部により取得された前記検証データに関する情報に基づいて、前記インタフェース部における、前記検証に必要かつ適正な前記検証データ用のインタフェース数を決定するインタフェース数決定部と
   を備えたことを特徴とする検証環境構築システム。
3. 前記インタフェース数決定部は、複数の異なった前記検証データが同一インタフェース上で入出力可能か否かに基づいて前記インタフェース数を決定することを特徴とする請求項２に記載の検証環境構築システム。
4. 前記検証情報取得部は、それぞれ前記検証データに関する情報の一例である、検証項目ごとの前記検証データの使用状況を示す情報である検証モード情報、および前記検証データの入出力が行なわれる時刻に関する情報であるアクセス情報、のうちの少なくとも１つの情報を取得する機能要素を備えていることを特徴とする請求項３に記載の検証環境構築システム。
5. 前記検証情報取得部は、前記検証データに関する情報の一例である、前記検証システム本体への前記検証データの方向に関するデータ方向性情報を取得する機能要素を備えていることを特徴とする請求項４に記載の検証環境構築システム。
6. 前記検証情報取得部は、前記検証データに関する情報の一例である、検証動作中の前記検証データの周波数を示すクロック情報を取得する機能要素を備えていることを特徴とする請求項３に記載の検証環境構築システム。
7. 前記インタフェース部は、ある一定の規格を満足する標準インタフェースであることを特徴とする請求項２に記載の検証環境構築システム。
8. 前記標準インタフェースは、ＩＳＡバスおよびＰＣＩバスのうちの少なくとも一方であることを特徴とする請求項７に記載の検証環境構築システム。
9. 前記標準インタフェースは、ＵＳＢインタフェースおよびＩＥＥＥ１３９４インタフェースのうちの少なくとも一方である
   ことを特徴とする請求項７に記載の検証環境構築システム。

Images