JP2013020425A

JP2013020425A - オープンソースソフトウェアを利用したハードウェア・ソフトウェア協調検証方法

Info

Publication number: JP2013020425A
Application number: JP2011152879A
Authority: JP
Inventors: Takashi Kinjo; 隆志金城
Original assignee: Hitachi Solutions Ltd
Current assignee: Hitachi Solutions Ltd
Priority date: 2011-07-11
Filing date: 2011-07-11
Publication date: 2013-01-31

Abstract

【課題】初期導入コストを安く抑えたハードウェアエミュレータを提供し、ハードウェアモデルとハードウェアエミュレータとを容易に接続する技術を提供することを目的とする。
【解決手段】オープンソースソフトウェアを利用したハードウェア・ソフトウェア協調検証方法であって、オープンソースソフトウェアであるＱｅｍｕを改変することにより、Ｑｅｍｕとハードウェアモデルの接続するＴＬＭインターフェースを介して、ハードウェアモデルに対してデータＩ／Ｏを行う手段と、ハードウェアモデルをＱｅｍｕ上でエミュレートしているＰＣＩバスに接続されているＰＣＩデバイスとして見せる手段と、ＳｙｓｔｅｍＣシミュレータからＱｅｍｕを起動する手段とを備えたオープンソースソフトウェアのＰＣエミュレータを実現する。
【選択図】図１

Description

本発明は、ハードウェア・ソフトウェア協調検証の技術に関し、特にハードウェア・ソフトウェア協調検証にて使用するハードウェアエミュレータに関するものである。

ハードウェア・ソフトウェア協調検証とは、組み込みシステム実機完成前の設計段階から組み込みシステムで稼動するソフトウェアとハードウェアであるＬＳＩとを含むシステム全体の検証を行う技術である。現在、ＳｏＣ（System on Chip）あるいはＡＳＩＣ（Application Specific Integrated Circuit）などのＬＳＩ設計では、ソフトウェア開発とハードウェア開発とを分離して実施し、ＬＳＩ試作機の完成後、ソフトウェアをシステムへ統合した上で、ＬＳＩの動作を検証している。この場合、ＬＳＩの不良は、試作機完成後の統合試験を実施している際に発覚する場合が多く、開発工程終盤での工程の手戻り、特にＬＳＩの作り直しが発生した場合、開発コストや開発期間が大幅に増大してしまう。ハードウェア・ソフトウェア協調検証の目的は、組み込みシステム実機完成前からソフトウェアとハードウェアであるＬＳＩとを含むシステム全体の検証を行い、実機完成前の早い段階でシステムの不良を摘出し、開発工程の手戻り、特にＬＳＩの作り直しを回避することにある（例えば、非特許文献１参照）。

ハードウェア・ソフトウェア協調検証方法としては、一般的には、ＳｙｓｔｅｍＣやＳｐｅｃＣ等のシステムレベル設計言語で実装されたハードウェアモデルと組み込みソフトウェアとをハードウェアエミュレータ上で一緒に動作させ、システム全体の検証を行う方法が知られている。そのような検証を行うための商用の複数のハードウェアエミュレータが存在するが、その初期導入コストは、一般的に非常に高価なのが現状である。一方、オープンソースソフトウェアのＰＣエミュレータとしてＱｅｍｕが知られているが、ＱｅｍｕはＰＣのエミュレータ機能を備えるだけのものであり、そのままではハードウェア・ソフトウェア協調検証に利用することはできない。

ＳｙｓｔｅｍＣとは、一般的に普及しているシステムレベル設計言語のひとつである。ＳｙｓｔｅｍＣとは、厳密には言語ではなく、Ｃ＋＋言語で定義されたクラスライブラリのことであり、ハードウェアモデルはＳｙｓｔｅｍＣクラスライブラリ（以下、ＳｙｓｔｅｍＣライブラリと称する）を用いたＣ＋＋言語で記述される。ＳｙｓｔｅｍＣライブラリを用いて記述されたハードウェアモデルは、一般的に用いられているｇｃｃ等のコンパイラによりコンパイルすることができる。コンパイルした結果、生成されたオブジェクトファイルは、ＳｙｓｔｅｍＣライブラリとリンクすることにより、ハードウェアのシミュレータ（以降、ＳｙｓｔｅｍＣシミュレータと称する）として実行することができる。ＳｙｓｔｅｍＣは、いわゆるオープンソースソフトウェアであり、無償で手に入れ利用することができる。

ＳｙｓｔｅｍＣによるハードウェアモデル記述の構造にて基本となるブロックをモジュールという。モジュール間の相互接続には、一般的にＴＬＭ（Transaction Level Modeling）インターフェースが広く用いられている。ＳｙｓｔｅｍＣおよびＴＬＭインターフェースを使用するためには、ＯＳＣＩ（Open SystemC Initiative）が提供するＳｙｓｔｅｍＣライブラリおよびＴＬＭライブラリを使用する。これらライブラリは、ハードウェア・ソフトウェア協調検証の中核技術であり、ハードウェア・ソフトウェア協調設計やハードウェアの性能評価などに広く適用される。

http://techon.nikkeibp.co.jp/article/WORD/20090107/163726/

上述したとおり、ハードウェア・ソフトウェア協調検証に使用するハードウェアエミュレータの初期導入コストは一般的に非常に高価であり、システムの開発規模と比較して、十分な数のハードウェア・ソフトウェア協調検証環境を揃えにくいという問題がある。また、ハードウェアエミュレータとハードウェアモデル（例えば、ＳｙｓｔｅｍＣで記述したハードウェアモデル）を接続する方法はハードウェアエミュレータにより異なり、ハードウェア・ソフトウェア協調検証を行う際にハードウェアモデルの一部を書き換える必要がある。

本発明の目的は、初期導入コストを安く抑えたハードウェアエミュレータを提供し、ハードウェアモデルとハードウェアエミュレータとを容易に接続する技術を提供することにある。

上記目的を達成するため、本発明では、一般に広く用いられているＴＬＭ（Transaction Level Modeling）インターフェースを備えたオープンソースソフトウェアをベースとしたハードウェアエミュレータを提供する。

すなわち、本発明は、オープンソースソフトウェアを利用したハードウェア・ソフトウェア協調検証方法であって、オープンソースソフトウェアであるＱｅｍｕを改変することにより、Ｑｅｍｕとハードウェアモデルの接続するＴＬＭインターフェースを介して、ハードウェアモデルに対してデータＩ／Ｏを行う手段と、ハードウェアモデルをＱｅｍｕ上でエミュレートしているＰＣＩバスに接続されているＰＣＩデバイスとして見せる手段と、ＳｙｓｔｅｍＣシミュレータからＱｅｍｕを起動する手段とを備えたオープンソースソフトウェアのＰＣエミュレータを実現することを特徴とする。

本発明によれば、オープンソースソフトウェアのＰＣエミュレータを改造して使用するので、従来と比較して初期導入コストを低く抑えてハードウェア・ソフトウェア協調検証環境を構築することができる。ＴＬＭライブラリを使用したハードウェアモデルは、そのまま修正を加えること無く、ハードウェアエミュレータに接続可能となる。ＴＬＭライブラリを使用したハードウェアモデルは、そのままＰＣＩデバイスとしてＯＳから認識できるようになる。それにより、組み込みソフトウェアからは、実機と同様に、ＬＳＩ（ハードウェモデル）に対してMemory Mapped I/O, Port Mapped I/Oが可能となる。ハードウェアエミュレータとハードウェアモデルとの接続は、数〜十数ステップのコードを記述し、コンパイルを実行することにより容易に接続可能である。

本実施形態で実現するハードウェア・ソフトウェア協調検証環境の全体概要図中継モジュールのクラス定義実装例ハードウェア・ソフトウェア協調検証環境の動作開始時の処理の流れを示すフローチャートＱｅｍｕメインループ処理の流れを示すフローチャート仮想マシンのインスタンス化の流れを示すフローチャートＱｅｍｕの初期化処理の流れを示すフローチャート各種テーブルの一部領域設定例

以下、図面を用いて、本発明の実施の形態を説明する。

本実施形態では、オープンソースソフトウェアのＰＣエミュレータであるＱｅｍｕを基として、そのＱｅｍｕのソースコードの変更を行い、Ｑｅｍｕと検証対象であるハードウェアモデルとを接続するＴＬＭインターフェースを介して、ハードウェアモデルに対してデータＩ／Ｏを行う手段を追加する。また、Ｑｅｍｕのソースコードの変更を行うことにより、ハードウェアモデルを、Ｑｅｍｕ上でエミュレートしているＰＣＩバスに接続されているＰＣＩデバイスとして見せる手段を追加し、さらに、ＳｙｓｔｅｍＣシミュレータからＱｅｍｕを起動する手段を追加する。

図１は、本実施形態で実現するハードウェア・ソフトウェア協調検証環境の全体概要図である。図１の各ブロックは、コンピュータ上でソフトウェアを実行することで実現される。すなわち、これらの各ブロックは、ＨＤＤ等の記憶装置からメモリ等の主記憶装置に読み出され、ＣＰＵ等の演算部により実行されることで実現される。

本実施形態のハードウェア・ソフトウェア協調検証環境は、オープンソースソフトウェアのＰＣエミュレータであるＱｅｍｕ部分１００と、Ｑｅｍｕ上でエミュレートしているＰＣＩバス部分１０１と、ＰＣＩバス部分１０１上に接続したＰＣＩデバイス部分１０２と、Ｑｅｍｕとハードウェアモデルの中継ぎを行う中継モジュール部分１０３と、ハードウェア・ソフトウェア協調検証対象となるハードウェアモデル部分１０４と、ハードウェア・ソフトウェア協調検証対象となるソフトウェア部分１０５と、ソフトウェア部分１０５の動作プラットフォームとなるＯＳ部分１０６とを備える。１０７はＱｅｍｕ上でエミュレートしているＣＰＵ部分であり、１０８はＱｅｍｕ上でエミュレートしているＭＣＨ（Memory Control Hub）部分であり、１０９はＱｅｍｕ上でエミュレートしているメモリ部分を示す。

１０７〜１０９は、Ｑｅｍｕ１００が従来より備えているＣＰＵとＭＣＨとメモリをエミュレートする機能を利用して実現する。ＰＣＩバスとＰＣＩデバイスに関し、汎用のＰＣが持つ幾つかの基本的なＰＣＩデバイスとそれらを接続するＰＣＩバスについては従前よりＱｅｍｕ１００が持つ機能で実現している。図１ではそのような基本的なＰＣＩデバイスについては不図示とした。本実施形態では、検証対象のハードウェアモデル１０４を接続するためのＰＣＩデバイス１０２に相当する部分をＱｅｍｕ１００に追加する必要がある。また、このＰＣＩデバイス１０２をＰＣＩバスに接続するため、Ｑｅｍｕ１００のＰＣＩバス１０１に相当する部分を改変する必要がある。これらＰＣＩデバイス１０２とＰＣＩバス１０１は、Ｃ言語で記載されているＱｅｍｕを改変することで実現する。

Ｑｅｍｕ１００とハードウェアモデル１０４とは、中継モジュール１０３を介して接続する。中継モジュール１０３は、ＳｙｓｔｅｍＣで記述したＳｙｓｔｅｍＣモジュール（すなわちＣ＋＋レイヤ）であり、ハードウェアモデル１０４に対してはＴＬＭインターフェースにて接続する。また、中継モジュール１０３とＰＣＩデバイス１０２との接続は、コールバック用の関数ポインタをＰＣＩデバイス１０２に渡しておく方式により実現する。Ｑｅｍｕ１００で実現されるＰＣＩデバイス１０２はＣ言語レイヤで、中継モジュール１０３はＣ＋＋レイヤであるので、そのままではＰＣＩデバイス１０２から中継モジュール１０３のメソッドを呼び出すことができず、ＰＣＩデバイス１０２から中継モジュール１０３経由でのハードウェアモデル１０４に対するデータの書き込みや読み出しを行うことができない。そこで、ＰＣＩデバイス１０２から中継モジュール１０３へデータ転送を行うときは、コールバック用の関数ポインタにて関数を発行し、データ渡しを行う。中継モジュール１０３からＰＣＩデバイス１０２へのデータ転送も同様の方式である。これらの実装は、実際のハードウェア構成でいうと、ＰＣＩデバイス部分１０２はＰＣＩカードに相当し、ハードウェアモデル１０４はそのＰＣＩカード上に実装されたＬＳＩに相当する。

検証対象のハードウェアモデル１０４は、ＳｙｓｔｅｍＣおよびＴＬＭインターフェースを使用して記述したものを使用する。ＳｙｓｔｅｍＣおよびＴＬＭインターフェースは、従来より知られている数多くのハードウェアシミュレータで使用されている形式であるので、既にそのようなハードウェアモデルを作成済みであればそれをそのまま使い回すことができる。

図２は、中継モジュール１０３のクラス定義実装例である。中継モジュール１０３は、予めユーザが、ＳｙｓｔｅｍＣで作成しておく。図２の２０１はハードウェアモデル１０４との接続ソケットであり、２０２はＰＣＩデバイス１０２からコールバックされるデータ書き込みメソッドであり、２０３はＰＣＩデバイス１０２からコールバックされるデータ読み込みメソッドであり、２０５は中継モジュール１０３のコンストラクタであり、図２の２０６はデータ書き込みメソッド２０２の実装から発行されるメソッドであり、２０７はデータ読み込みメソッド２０３の実装から発行されるメソッドである。

図２の中継モジュール１０３のクラスからオブジェクトを作成する際にコンストラクタ２０５が実行され、これにより各種のテーブル領域の確保や初期設定が行われる。コンストラクタ２０５の実装例はここでは省略するが、後述する図５のステップ５０２以降の初期設定処理はコンストラクタ２０５の実装により実現されるものである。

図３は、図１のハードウェア・ソフトウェア協調検証環境の動作開始時の処理の流れを示すフローチャートである。Ｑｅｍｕによるエミュレーションの処理は、後述する図４のＱｅｍｕのメインループ処理により実行されるが、そのメインループ処理が開始される前に、図３の３１０と３２０の処理が実行される。

前処理３１０は、ハードウェアモデル１０４をＯＳ１０６からＱｅｍｕ上でエミュレートしているＰＣＩバス１０１に接続されているＰＣＩデバイス１０２として見せる手段を実現するための処理である。この処理は、ＧＮＵｇｃｃ拡張機能_attribute_((constructor))により、main()発行前に発行される処理である。

ステップ３１１で、ＤｅｖｉｃｅＩｎｆｏテーブルの領域を確保し属性を設定する。ＤｅｖｉｃｅＩｎｆｏテーブルは、ＰＣＩデバイス１０２をエミュレートするために利用する構造体である。

図７（ｃ）に、ＤｅｖｉｃｅＩｎｆｏテーブル（テーブル３）の構造体の一部領域の設定例を示す。「ＰＣＩデバイス識別名文字列」は、ハードウェアモデル１０４を接続するためのＰＣＩデバイス１０２を特定する識別名の文字列である。「ＰＣＩデバイス説明文字列」は、ＰＣＩデバイス１０２を説明する文字列である。「ＰＣＩＤｅｖｉｃｅテーブルサイズ」は、本ＰＣＩデバイス１０２に対応するＰＣＩＤｅｖｉｃｅテーブル（図７（ｄ）で後述する）のサイズ（バイト数）である。「ＰＣＩデバイス初期化関数ポインタ」は、ＰＣＩデバイス１０２の初期化を実行する関数を指すポインタである。

図７（ｃ）に示すＤｅｖｉｃｅＩｎｆｏテーブルはＰＣＩデバイス１０２に対応するテーブルであるが、ＰＣＩデバイス１０２以外にも汎用のＰＣが基本的に備えているＰＣＩデバイスが存在し、Ｑｅｍｕでエミュレートする全てのＰＣＩデバイスのそれぞれにはそのＰＣＩデバイスに対応するＤｅｖｉｃｅＩｎｆｏテーブルが確保される。それら全てのＤｅｖｉｃｅＩｎｆｏテーブルはチェインでつながれ、このチェインを辿ることで、各ＰＣＩデバイスに対応するＤｅｖｉｃｅＩｎｆｏテーブルへのアクセスを実現できる。このチェインをＤｅｖｉｃｅＩｎｆｏテーブルチェインと呼ぶ。「ＤｅｖｉｃｅＩｎｆｏテーブルチェインポインタ」は、そのＤｅｖｉｃｅＩｎｆｏテーブルチェインで繋がれている次のＤｅｖｉｃｅＩｎｆｏテーブルを指すポインタである。

図３に戻って、ステップ３１１の後、ステップ３１２〜３１５で、ＤｅｖｉｃｅＩｎｆｏテーブルに、ＰＣＩデバイス１０２のＰＣＩデバイス識別名文字列とＰＣＩデバイス説明文文字列とＰＣＩＤｅｖｉｃｅテーブルサイズ（バイト数）とＰＣＩデバイス初期化関数ポインタを設定する。次に、ステップ３１６で、当該ＤｅｖｉｃｅＩｎｆｏテーブルをＤｅｖｉｃｅＩｎｆｏテーブルチェインに追加する。

次の前処理３２０は、ＳｙｓｔｅｍＣシミュレータからＱｅｍｕ１００を起動する手段を実現するための処理である。前述したとおり、ハードウェアモデル１０４のオブジェクトファイルとＳｙｓｔｅｍＣライブラリをリンクしたものはＳｙｓｔｅｍＣシミュレータとして動作する。そのため、ＳｙｓｔｅｍＣライブラリには、予め、プログラムのエントリポイントであるmain関数が実装されている。一方、Ｑｅｍｕもエントリポイントであるmain関数を持つ。そこで、Ｑｅｍｕのソースを改造し、元々のＱｅｍｕのエントリーポイントであるmain関数をコメントアウトし、図３の３２０に示すようにＳｙｓｔｅｍＣシミュレータからＱｅｍｕを起動するように改変する。

この仕組みではＳｙｓｔｅｍＣライブラリには予めプログラムのエントリポイントであるmain関数が実装されているので、ステップ３２１で、このmain関数が起動される。ステップ３２２で、このmain関数から、同じくＳｙｓｔｅｍＣライブラリに実装されているsc_elab_and_sim関数が発行される。さらに、ステップ３２３で、このsc_elab_and_sim関数から、sc_mainという名前の関数が発行される。ＳｙｓｔｅｍＣシミュレータのエントリポイントはＳｙｓｔｅｍＣの記述規則によりsc_main関数と定められており、sc_main関数の実装はＳｙｓｔｅｍＣシミュレータの利用者が行う。本実施形態においては、このsc_main関数からＱｅｍｕ１００の起動を行う。

Ｑｅｍｕ１００の起動のため、ステップ３２４で、仮想マシンのインスタンス化を行う。この処理については、図５で詳しく説明する。

次に、ステップ３２５で、ハードウェアモデル（ＬＳＩハードウェア設計記述）１０４のインスタンス化を行う。ステップ３２６で、Ｑｅｍｕ１００による仮想マシンとハードウェアモデル１０４との相互接続を行う。次に、ステップ３２７で、ＳｙｓｔｅｍＣライブラリに実装されているSC_START関数を発行する。これにより、センシビティリスト（SC_THREAD）に登録した処理が開始される。センシビティリスト（SC_THREAD）は、ハードウェアモデルをエミュレートするための各プロセスの実行を制御するのに利用するリストである。後述するが、Ｑｅｍｕメインループ処理もセンシビティリスト（SC_THREAD）に登録されるので、ステップ３２７によりセンシビティリスト（SC_THREAD）に登録した処理が開始されることで、図１のハードウェア・ソフトウェア協調検証環境の動作が開始される。

図４は、ステップ３２７により開始されるＱｅｍｕメインループ処理（ステップ４０１）を示す。ステップ４０２のＱｅｍｕメインループの処理では、SC_THREADに登録した各処理が実行され、それがループ処理であれば繰り返し実行される。終了が指示されると、ステップ４０３でＱｅｍｕ終了処理を実行する。

図５は、図３のステップ３２４の仮想マシンのインスタンス化（ステップ５０１）の処理の流れを示す。ステップ５０２では、中継モジュール１０３のインスタンス化を行う。これは、図２で説明した中継モジュール１０３のクラスのインスタンス化であり、これにより中継モジュール１０３のエミュレートが実現される。

処理５０３は、Ｑｅｍｕ１００とハードウェアモデル１０４とを接続するＴＬＭインターフェースを介してハードウェアモデル１０４に対してデータＩ／Ｏを行う手段を実現するための処理である。ステップ５１１では、データＩ／Ｏハンドラテーブル領域を確保する。

図７（ａ）に、データＩ／Ｏハンドラテーブル（テーブル１）の構造体の一部領域の設定例を示す。データＩ／Ｏハンドラテーブルには、中継モジュール１０３のクラスのインスタンスアドレスが設定される。また、ハードウェアモデル１０４へのメモリ・マップド・ライト関数ポインタ、メモリ・マップド・リード関数ポインタ、ポート・マップド・ライト関数ポインタ、および、ポート・マップド・リード関数ポインタが設定される。これらの関数ポインタは、Ｃ＋＋レイヤからＣ言語レイヤへのコールバック関数ポインタであり、Ｉ／Ｏハンドラに相当する。

図５の処理に戻って、ステップ５１１でデータＩ／Ｏハンドラテーブル（テーブル１）の領域を確保したら、ステップ５１２で、メモリマップドＩ／ＯハンドラをデータＩ／Ｏハンドラテーブルへ設定し、ステップ５１３で、ポートマップドＩ／ＯハンドラをデータＩ／Ｏハンドラテーブルへ設定する。これにより図７（ａ）のデータＩ／Ｏハンドラテーブルの各Ｉ／Ｏハンドラ関数ポインタ等のデータが設定される。

ステップ５０４では、Ｑｅｍｕ１００の初期化処理として、Ｑｅｍｕメインループ直前までの処理を実行する。この処理については、図６で詳しく説明する。ステップ５０５では、Ｑｅｍｕメインループ処理を、センシビティリスト（SC_THREAD）へ登録する。

図６は、図５のステップ５０４のＱｅｍｕ１００の初期化処理（ステップ６０１）の流れを示す。処理６０２は、ハードウェアモデル１０４をＯＳ１０６からＱｅｍｕ１００上でエミュレートしているＰＣＩバス１０１に接続されているＰＣＩデバイス１０２として見せる手段を実現するための処理である。

まずステップ６１１で、ＰＣＩバスモデルを作成する。これは、Ｑｅｍｕのオリジナルな処理であり、ＰＣＩバステーブルを作成する処理である。

図７（ｂ）に、ＰＣＩバステーブル（テーブル２）の一部領域の設定例を示す。ＰＣＩバステーブルには、ＰＣＩバス１０１に接続している全てのＰＣＩデバイスに対応するＰＣＩＤｅｖｉｃｅテーブルをチェインしたチェインリスト（ＰＣＩＤｅｖｉｃｅチェインリスト）の先頭アドレスを設定する。これにより、図７（ｂ）のＰＣＩバステーブルからＰＣＩＤｅｖｉｃｅチェインリストを辿って各ＰＣＩデバイスに対応するＰＣＩＤｅｖｉｃｅテーブルにアクセスできる。上述したように、ＤｅｖｉｃｅＩｎｆｏテーブルチェインを辿ることにより、各ＰＣＩデバイスに対応するＤｅｖｉｃｅＩｎｆｏテーブルにアクセスできる。各ＰＣＩデバイスに対応するＤｅｖｉｃｅＩｎｆｏテーブルとＰＣＩＤｅｖｉｃｅテーブルを利用することによって、それら各ＰＣＩデバイスの動作のエミュレートが実現できる。

図７（ｄ）に、ＰＣＩＤｅｖｉｃｅテーブル（テーブル４）の一部領域の設定例を示す。ＰＣＩＤｅｖｉｃｅテーブルには、各種ＰＣＩコンフィギュレーションレジスタ情報格納領域先頭アドレスと、ポートマップドＩ／Ｏハンドラ関数ポインタ（ｗｒｉｔｅ）と、ポートマップドＩ／Ｏハンドラ関数ポインタ（ｒｅａｄ）と、メモリマップドＩ／Ｏハンドラ関数ポインタ（ｗｒｉｔｅ）と、メモリマップドＩ／Ｏハンドラ関数ポインタ（ｒｅａｄ）とが設定される。

図６に戻って、ステップ６１１で図７（ｂ）のＰＣＩバステーブルを作成した後、ステップ６１２では、ＰＣＩデバイス１０２に対応するＰＣＩＤｅｖｉｃｅテーブルの領域を確保する。他のＰＣＩデバイスについても同様である。これは、ＤｅｖｉｃｅＩｎｆｏテーブルチェインの先頭から順に辿って各ＰＣＩデバイスに対応するＤｅｖｉｃｅＩｎｆｏテーブルにアクセスし、そのＰＣＩデバイスに対応するＰＣＩＤｅｖｉｃｅテーブルの領域を順に確保していく処理である。ステップ６１３では、ＰＣＩバスモデルの接続するＰＣＩデバイスチェインリストへＰＣＩＤｅｖｉｃｅテーブルアドレスを設定する。この処理は、ステップ６１２で確保した各ＰＣＩデバイスに対応するＰＣＩＤｅｖｉｃｅテーブルのアドレスをＰＣＩデバイスチェインリストに設定して、各ＰＣＩデバイスに対応するＰＣＩＤｅｖｉｃｅテーブルをチェインで繋ぐ処理である。チェインで繋ぐ順番は、ＤｅｖｉｃｅＩｎｆｏテーブルチェインで繋がれたＰＣＩデバイスの順と同じである。

次に、ステップ６１４で、ＤｅｖｉｃｅＩｎｆｏテーブルチェインの先頭から順に、各ＰＣＩデバイスに対応するＤｅｖｉｃｅＩｎｆｏテーブル（図７（ｃ））のＰＣＩデバイス初期化関数ポインタを読み込み、各種ＰＣＩデバイスの初期化関数を発行する。これにより、ＰＣＩデバイス１０２についても初期化関数が発行される。ステップ６１５では、ＰＣＩデバイス１０２のベンダＩＤ、デバイスＩＤ、レビジョンＩＤ、クラスコードなどの各種ＰＣＩコンフィグレーションレジスタ情報を、所定のＰＣＩコンフィグレーションレジスタ情報格納領域に格納し、その領域のアドレスをＰＣＩＤｅｖｉｃｅテーブル（図７（ｄ））の各種ＰＣＩコンフィギュレーションレジスタ情報格納領域先頭アドレスに設定する。ステップ６１６では、ポートマップドＩ／ＯハンドラをＰＣＩＤｅｖｉｃｅテーブルのポートマップドＩ／Ｏハンドラ関数ポインタ（ｗｒｉｔｅ）およびポートマップドＩ／Ｏハンドラ関数ポインタ（ｒｅａｄ）に設定する。ステップ６１７では、メモリマップドＩ／ＯハンドラをＰＣＩＤｅｖｉｃｅテーブルのメモリマップドＩ／Ｏハンドラ関数ポインタ（ｗｒｉｔｅ）およびメモリマップドＩ／Ｏハンドラ関数ポインタ（ｒｅａｄ）に設定する。

以上のように初期設定が為された後、例えば、検証対象のソフトウェア１０５からハードウェアモデル１０４に対してメモリ書き込みを行う場合、Ｑｅｍｕ１００はその書き込み命令を受けて、図７（ａ）のコールバック関数ポインタ（ハードウェアモデル１０４へのメモリ・マップド・ライト関数ポインタ）を利用してデータ書き込みメソッドを発行する。そのデータ書き込みメソッドの実装例は省略するが、そのデータ書き込みメソッドの実装によりメモリ書き込みがエミュレートされる。ハードウェアモデル１０４に対するメモリ読み出し、ポート書き込み、および、ポート読み出しも同様の方式でエミュレートしている。これにより、Ｑｅｍｕ１００からハードウェアモデル１０４に対してデータ書き込みおよびデータ読み込みを行う手段が実現される。

また、図７（ｂ）〜図７（ｄ）で説明した構造体を用意し、図３の３１０および図６の６０２の初期化処理を行っており、これによりハードウェアモデル１０４をＰＣＩバス１０１に接続されているＰＣＩデバイス１０２として見せる手段が実現される。

１００：Ｑｅｍｕ部分、１０１：Ｑｅｍｕ上でエミュレートしているＰＣＩバス部分、１０２：ＰＣＩバス部分１０１上に接続したＰＣＩデバイス部分、１０３：Ｑｅｍｕとハードウェアモデルの中継ぎを行う中継モジュール部分、１０４：ハードウェア・ソフトウェア協調検証対象となるハードウェアモデル部分、１０５：ハードウェア・ソフトウェア協調検証対象となるソフトウェア部分、１０６：ソフトウェア部分１０５の動作プラットフォームとなるＯＳ部分、１０７：Ｑｅｍｕ上でエミュレートしているＣＰＵ部分、１０８：Ｑｅｍｕ上でエミュレートしているＭＣＨ（Memory Control Hub）部分、１０９：Ｑｅｍｕ上でエミュレートしているメモリ部分。

Claims

オープンソースソフトウェアを利用したハードウェア・ソフトウェア協調検証方法であって、
オープンソースソフトウェアであるＱｅｍｕを改変することにより、
Ｑｅｍｕとハードウェアモデルの接続するＴＬＭインターフェースを介して、ハードウェアモデルに対してデータＩ／Ｏを行う手段と、
ハードウェアモデルをＱｅｍｕ上でエミュレートしているＰＣＩバスに接続されているＰＣＩデバイスとして見せる手段と、
ＳｙｓｔｅｍＣシミュレータからＱｅｍｕを起動する手段と
を備えたオープンソースソフトウェアのＰＣエミュレータを実現することを特徴とするオープンソースソフトウェアを利用したハードウェア・ソフトウェア協調検証方法。