(57)【要約】【課題】  パッケージの正当性の確認を自動的にかつ最小限のテストで行う。【解決手段】  複数の異なる抽象度で記述されたハードウエアのモジュールであり、異なる抽象度間において包含する機能が等価であるハードウエアのモジュールと当該モジュールの機能を検証するためのテストをハードウエアのモジュールごとにひとつのパッケージとして格納するデータ記憶手段と、パッケージを新たに更新する際、更新されるハードウエアの抽象度モジュール、および、更新されるテストを検出する更新モジュールテスト検出手段と、更新モジュールテスト検出手段により得た更新される抽象度モジュールおよびテストから、更新するパッケージの正当性を確認するに最低限必要なテストのみを抽出するテスト抽出手段と、テスト抽出手段により得たテストを実行し更新するパッケージの正当性を確認するテスト実行手段を備る。【選択図】  図１
2007040892.tif 000002
【特許請求の範囲】
【請求項１】
下位の抽象度で記述されたモジュールは上位の抽象度で記述されたモジュールの機能を包含する複数の異なる抽象度で記述されたハードウエアのモジュールを用いたシステムLSIの開発において、
前記複数の異なる抽象度で記述されたハードウエアのモジュールであり、異なる抽象度間において包含する機能が等価であるハードウエアのモジュールと当該モジュールの機能を検証するためのテストをハードウエアのモジュールごとにひとつのパッケージとして格納するデータ記憶手段と、
前記パッケージを新たに更新する際、更新されるハードウエアの抽象度モジュール、および、更新されるテストを検出する更新モジュールテスト検出手段と、
前記更新モジュールテスト検出手段により得た更新される抽象度モジュールおよびテストから、更新するパッケージの正当性を確認するに最低限必要なテストのみを抽出するテスト抽出手段と、
前記テスト抽出手段により得たテストを実行し更新するパッケージの正当性を確認するテスト実行手段
を備えたことを特徴とするデータ管理装置。
【請求項２】
前記モジュールの機能を検証するための各々のテストは、当該ハードウエアモジュールの仕様に対してテストアイテムおよびテストカテゴリが明確であることを特徴とする請求項1記載のデータ管理装置。
【請求項３】
前記テスト抽出手段は、機能がどの抽象度から実装されるかを示すテーブルを格納し、当該テーブルと前記テストのテストアイテムおよびテストカテゴリからテストがどの抽象度で実行可能であるかを判定する機能を持つことを特徴とする請求項1記載のデータ管理装置。
【請求項４】
前記テスト実行手段は、入力制約条件に対する出力状態を論理的に検証する動的検証、もしくは、論理的等価性を演算により検証する静的検証であることを特徴とする請求項1記載のデータ管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の異なる抽象で記述されたハードウエアのモジュールを用いたシステムLSI開発に係わる。
【背景技術】
【０００２】
プロセス技術の進歩によりLSIの集積度が増大し、これまでボードで実現していたシステムをシステムLSIとして１チップ上に搭載することが可能となった。チップ上に搭載する機能モジュールも多様化し、回路規模が増大している。これに伴い、システムLSIを効率的に設計する手法として、従来のVerilog-HDLやVHDLといったハードウエア記述言語を使用した設計から、SystemCやSpecCといったシステム記述言語による設計が普及してきた。
【０００３】
システム記述言語により記述したモジュールを、ブロック図入力画面で入力し、システムLSIの設計を行うことが可能になっている。また、シミュレータを起動してシステムシミュレーションを行いシステムLSIの機能や性能を確認できるものである。
【０００４】
システム記述言語によるモジュール記述には、記述の抽象度により以下の３種類の記述レベルが一般に知られている。
【０００５】
トランザクションレベル（TL）：
モジュール間の通信を捉えて機能を記述する抽象度レベルである。通信の開始および終了の時間、通信データにより動作するため、クロックに対する精度は非常に低い。イベントにより機能をシミュレートするため、シミュレーション速度は非常に速い。
【０００６】
バスサイクルアキュレート（BCA）：
モジュールの入力と出力のイベントとして機能を記述する抽象度レベルである。動作クロックに対し、入力および出力部で正確にシミュレートすることができる。
【０００７】
レジスタトランスファレベル（RTL）：
レジスタファイル間の同期転送を捉えて、回路を記述する抽象度レベルである。動作クロックに対し、正確に機能動作をシミュレートすることができ精度が非常に高い。１クロックごとに機能をシミュレートするため、シミュレーション速度は非常に遅い。
【０００８】
3種類の中で、一番抽象度が高いのはTLであり、一番抽象度が低いのはRTLである。下位の抽象度で記述されたモジュールは、上位の抽象度で記述されたモジュールの機能を包含する。即ち、BCAで記述されたモジュールの機能は、TLで記述されたモジュールの機能を持ち、RTLで記述されたモジュールの機能は、BCAで記述されたモジュールの機能を持つ。抽象度が高いほど、シミュレーション速度は速く、抽象度が低いほどシミュレーション精度は高くなる。
【０００９】
システムLSIの設計では、抽象度の高い記述から徐々に抽象度の低い記述へと、モジュールの機能が詳細化されていく。従って、設計者は、各種抽象度で記述されたモジュールを選択し切り替えながら、システムLSIの設計を行うのが一般的である。同一の抽象度で記述されたモジュールでシステムLSIを構成し、高い抽象度から低い抽象度へ落とし込んでいく場合と、異なる抽象度で記述されたモジュールが混在する場合がある。
【００１０】
上記のような異なる抽象度で記述されたモジュールを切り替えながらシステムLSIを設計する場合、異なる抽象度間において包含する機能が等価であることが重要である。例えば、ひとつのハードウエアモジュールにおいて、TLで記述されたモジュールをRTLに記述されたモジュールに切り替えるとき、RTLのモジュールは、TLのモジュールの機能を包含しているので、RTLモジュールに含まれるTLに相当する機能と、実際のTLのモジュールとの機能が等価であること。また、RTLのモジュールをBCAのモジュールに切り替えるとき、RTLモジュールに含まれるBCAに相当する機能と、実際のBCAモジュールとの機能が等価であること。
【００１１】
そのために、各抽象度で記述されたモジュールを個別にバージョン管理するだけではなく、異なる抽象度間において包含する機能が等価である異なる抽象度で記述されたモジュールをハードウエアのモジュールごとにひとつのパッケージとして管理している。
【００１２】
設計者は、抽象度を切り替える場合、パッケージに登録されているモジュールから選択し切り替えればよい。
【００１３】
又、従来例としては、例えば特許文献１と特許文献２をあげることが出来る。
【特許文献１】特開平11-2665号公報
【特許文献２】特開2000-348076号公報
【発明の開示】
【発明が解決しようとする課題】
【００１４】
しかしながら、パッケージの正当性の管理、即ち、パッケージに登録される異なる抽象度で記述されたモジュール間での包含する機能の等価性の確認は、人手によりテストを実行し検証を行うことで行われている。もしくは、モジュールを検証するためのあらかじめ用意されたテストを網羅的に実行し検証を行うことで確認を行っている。
【００１５】
システムLSIは、今後ますます複雑化・大規模化し、システムLSIが持つモジュールも増大する。即ち、正当性を確認するパッケージ数が増大する。また、モジュールを記述する抽象度がより細分化されることも考えられる。即ち、ひとつのパッケージの正当性を確認する工数が増加する。従って、人手による確認は、正確さにおいて非常に困難になり、また、網羅的に検証を行う場合、検証に膨大な時間がかかることになる。
【００１６】
本発明は、上記課題を解決するためになされたもので、パッケージの正当性の確認を自動的にかつ最小限のテストで行うことを目的としている。
【課題を解決するための手段】
【００１７】
上記課題を解決するために、下位の抽象度で記述されたモジュールは上位の抽象度で記述されたモジュールの機能を包含する複数の異なる抽象度で記述されたハードウエアのモジュールを用いたシステムLSIの開発において、前記複数の異なる抽象度で記述されたハードウエアのモジュールであり、異なる抽象度間において包含する機能が等価であるハードウエアのモジュールと当該モジュールの機能を検証するためのテストをハードウエアのモジュールごとにひとつのパッケージとして格納するデータ記憶手段と、前記パッケージを新たに更新する際、更新されるハードウエアの抽象度モジュール、および、更新されるテストを検出する更新モジュールテスト検出手段と、前記更新モジュールテスト検出手段により得た更新される抽象度モジュールおよびテストから、更新するパッケージの正当性を確認するに最低限必要なテストのみを抽出するテスト抽出手段と、前記テスト抽出手段により得たテストを実行し更新するパッケージの正当性を確認するテスト実行手段を備えたことを特徴とするデータ管理装置を適用する。
【発明の効果】
【００１８】
以上説明したように、本発明によれば、複数の異なる抽象度で記述されたハードウエアのモジュールを持つパッケージを更新する際に、自動的にかつ最低限の時間でパッケージの正当性を確認することが可能となる。また、今後予想されるシステムLSIの複雑化・大規模化によるパッケージ数の増大、抽象度の増加にも対応することが可能となる。
【００１９】
よって、本発明によれば、複数の抽象度で記述されたモジュールを切り替えながら行うシステムLSIの設計において、開発効率の向上が図れ、その結果、市場が欲するときに製品を投入することが可能となる。
【発明を実施するための最良の形態】
【００２０】
以下に、図1から図5を参照しながら本発明の実施形態を説明する。
【００２１】
図1は、本発明におけるデータ管理装置の一実施例である構成を示した図である。
【００２２】
(100)は、データ管理装置である。データ管理装置は、パッケージを記憶する(101)データ記憶手段、(102)更新モジュールテスト検出手段、(103)テスト抽出手段、(104)テスト実行手段を持つ。
【００２３】
複数の異なる抽象度で記述されたハードウエアのモジュールであり、異なる抽象度間において包含する機能が等価であるハードウエアのモジュールとモジュールの機能を検証するためのテスト情報であるテストテーブルをハードウエアのモジュールごとにひとつのパッケージとして、(101)データ記憶手段に登録する。(105)は、データ記憶手段が保持するハードウエアモジュールであるモジュールAに関するパッケージである。パッケージの更新順にパッケージバージョン１から４までリストとして登録してある。パッケージには、テストテーブル、TLモジュール、BCAモジュール、RTLモジュールがセットとして含まれており、それらも各々バージョン管理されている。テストテーブルには、テスト名、テストカテゴリ、テストアイテムを登録する。
【００２４】
例えば、(105)モジュールAのパッケージリストにおいて、パッケージバージョン3には、テストテーブルはバージョン3、TLモジュールはバージョン2、BCAモジュールはバージョン２、RTLモジュールはバージョン1がセットとして登録されている。TLモジュールバージョン2とBCAモジュールバージョン2とRTLモジュールバージョン1は、テストテーブルバージョン3において、異なる抽象度間において包含する機能は等価である。また、(105)モジュールAのパッケージリストにおいて、パッケージバージョン1には、テストテーブルバージョン1とTLモジュールバージョン1のみが登録されている。これは、パッケージバージョン1の時点では、BCAとRTLで記述したモジュールが提供されていなかったことを示している。同様に、(106)モジュールBに関するパッケージのリストおよびモジュールCに関するパッケージのリストが、データ記憶手段に登録されている。
【００２５】
モジュールの抽象度を切り替えながらシステムLSIの設計を行う際、データ管理装置のデータ記憶手段に登録されているパッケージ情報を元に、モジュールのバージョンを選択し使用する。
【００２６】
新たにパッケージを(101)データ記憶手段に登録する場合、(102)更新モジュールテスト検出手段、(103)テスト抽出手段、(104)テスト実行手段により、登録するパッケージの正当性を自動的に確認し、確認の後にデータ記憶手段に登録する。
【００２７】
(107)は、新たにデータ記憶装置に登録し更新しようとしているモジュールAのパッケージである。パッケージバージョンは5であり、テストテーブルバージョン5、TLバージョン2、BCAバージョン2、RTLバージョン5である。
【００２８】
(102)更新モジュールテスト検出手段は、更新されるハードウエアの抽象度モジュール、および、更新されるテストを検出する。(105)のモジュールAのパッケージバージョン4と(107)のモジュールAのパッケージバージョン５を比較する。RTLモジュール及びテストテーブルのバージョンが上がっていることから、更新されるモジュールは、RTLモジュールであり、また、更新されるテストがあることが分かる。
【００２９】
(103)テスト抽出手段は、各機能がどの抽象度レベルで実装されるかを示した(108)実装抽象度マップを持ち、実装抽象度マップと更新するパッケージのテストテーブルの情報から、各テストがどの抽象度のモジュールで実行可能かを示すテスト実行可能テーブルを作成する。その後、(102)更新モジュールテスト検出手段により得た更新される抽象度モジュールおよびテストとテスト実行可能テーブルから、正当性を確認するに最低限必要なテストのみを抽出する。
【００３０】
(104)テスト実行手段は、テスト抽出手段により得たテストを(109)検証ツールを用いて実際に実行し、更新するパッケージの正当性の検証を行う。抽出したテストが全てパスしたなら、(107)のパッケージは正当であると判定し、(101)データ記憶手段に登録する。テストで不一致が起こったならば、パッケージは正当でないと判定し、ユーザーに通知する。
【００３１】
検証の方法としては、シミュレータを用いた動的検証方法でもよいし、論理的等価性を演算により検証する静的検証方法のどちらでもよい。パッケージに登録されているテストが、モジュールの入出力に対する波形パターンであれば動的検証を、モジュールの性質を示したプロパティであれば静的検証を適用する。
【００３２】
以降に、詳細なテストテーブル、実装抽象度マップ、テスト実行可能テーブル、および、動作フローを説明する。
【００３３】
図2は、テストテーブルの一部を示している。
【００３４】
テストテーブルには、当該モジュールを検証する全てのテストを、テスト名、テストカテゴリ、テストアイテムとともに登録する。テストテーブルもハードウエアモジュールと同様にバージョンごとにパッケージで管理する。テストアイテムは、当該テストが検証を行う詳細な検証項目である。テストカテゴリは、レジスタ、アルゴリズム、FIFOといった当該テストが検証行うテストアイテムに必要なモジュールの実装カテゴリである。
【００３５】
例えば、(200)のテストテーブルには、テスト名“レジスタテスト”は、テストアイテムからレジスタAに対するアクセスの機能を検証するテストであり、テストカテゴリからモジュールに必要な実装は、レジスタであることを示している。同様に、テスト名“アルゴリズムテスト1”は、テストアイテムから画像圧縮モード1の機能を検証するテストであり、テストカテゴリからモジュールに必要な実装は、アルゴリズムであることを示している。
【００３６】
図3は、実装抽象度マップの一部を示している。
【００３７】
実装抽象度マップは、各抽象度においてモジュールは何を実装しておかなければならないかを示すものである。実装抽象度マップは、(103)テスト抽出手段が持つ。実装カテゴリでは、実装する機能を示す。実装抽象度レイヤーでは、実装すべきモジュールの抽象度を示す。
【００３８】
例えば、(300)の実装抽象度マップでは、レジスタの機能は、TLレベルで実装する必要がある。BCAはTLの機能を、RTLはBCAの機能を持つことから、レジスタ機能は、TL、BCA、RTL全てに実装されることを示している。同様に、バスプロトコルは、BCAとRTLで実装されることを示している。
【００３９】
また、記述の抽象度が、より細分化するなど変化した場合、この実装抽象度マップを変更することで、データ管理装置における抽象度の定義を変更することが可能となる。
【００４０】
図4は、テスト実行可能テーブルの一部を示している。
【００４１】
テスト実行可能テーブルは、(103)テスト抽出手段が、パッケージの正当性を確認する必要最低限のテストを抽出するに先立ち、テストテーブルと実装抽象度マップから各テストがどの抽象度で実行することが可能かどうかを判断するために作成するものである。
【００４２】
(400)テスト実行可能テーブルでは、テスト名ごとにTL、BCA、RTLで実行可能かどうかを示している。○が付いているものは、実行が可能である事を示す。
【００４３】
(400)のテスト実行可能テーブルは、テスト抽出手段が、(200)テストテーブルと(300)実装抽象度マップから、作成した例である。(200)のテスト名“レジスタテスト”のテストカテゴリは、“レジスタ”であり、(300)の実装カテゴリ“レジスタ”の実装抽象度レイヤーはTLであるので、(400)のテスト実行可能テーブルにおいて、テスト名“レジスタテスト”は、TL、BCA、RTLともに実行可能であることから○となる。(200)のテスト名“バスプロトコルテスト”のテストカテゴリは、“バスプロトコル”であり、(300)の実装カテゴリ“バスプロトコル”の実装抽象度レイヤーはBCAであるので、(400)のテスト実行可能テーブルにおいて、テスト名“バスプロトコル”は、BCA、RTLにおいて実行可能であることから、BCAとRTLのみに○となる。
【００４４】
記述の抽象度が、より細分化するなど変化した場合でも、(300)の実装抽象度マップを変更するのみで、(400)テスト実行可能テーブルにも対応可能である。
【００４５】
図5を用いて、詳細な動作フローの例を説明する。
【００４６】
ステップ(S500)：
パッケージの登録スタート
ステップ(S501)：
更新するパッケージのテストテーブルと実装抽象度マップから、テスト実行可能テーブルを作成する。
【００４７】
ステップ(S502)：
登録するパッケージは、はじめての登録かどうかを判定。YESの場合、ステップ(S503)に進む。NOの場合、ステップ(S508)に進む。
【００４８】
はじめての登録の場合：はじめての登録の場合、登録されているパッケージがないため、すべてのテストを実行し、パッケージの正当性を確認する。
【００４９】
ステップ(S503)：
初めての登録なので、テスト実行可能テーブルに従って、テスト可能な全てのテストを実行し全ての抽象度のモジュールを検証する。(400)をテスト実行可能テーブルとした場合、○の付いている全ての検証を実行する。
【００５０】
ステップ(S504)：
テストが全てパスしたかどうかをチェックする。YESの場合、ステップ(S505)に進む。NOの場合、ステップ(S506)に進む。
【００５１】
ステップ(S505)：
全てのテストがパスしたので、パッケージは正当であると判断し、データ記憶手段に登録をする。
【００５２】
ステップ(S506)：
テストがパスしなかったため、パッケージに問題があると判定し、更新をキャンセルし、ユーザーに通知する。
【００５３】
ステップ(S507)：
終了。
【００５４】
2回目以降の更新の場合：既に登録されているパッケージがあり、その正当性は確認されている。従って、登録されている最新のパッケージと更新予定のパッケージにおいて、差分を調べ、差分のみを検証するテストを抽出し検証する。
【００５５】
ステップ(S508)：
更新予定のパッケージと現在の登録されている最新パッケージをチェックし、更新もしくは追加された抽象度モジュール及びテストをすべて検出する。
【００５６】
ステップ(S509)：
テストが追加もしくは更新されたかどうかを判定。YESの場合、(S512)へ進む。NOの場合、(S510)へ進む。
【００５７】
ステップ(S510)：
テストの追加・更新はないので、抽象度モジュールの追加・更新のみである。
【００５８】
ステップ(S511)：
追加もしくは更新したモジュールに対して、テスト実行可能テーブルに従って対応する全てのテストを実行し検証する。(400)のテスト実行可能テーブルにおいて、RTLモジュールが、追加もしくは更新された場合、(401)で示すRTLモジュールで実行可能な検証のみを行う。他の検証は、既に登録されている前のパッケージで確認されている。また、異なる抽象度間において包含する機能の等価についても、テストが変更されていないので、変更されたRTLモジュールにおいてのみ、テストを実行し検証が行われれば、TL、BCA、RTLが等価であると言う事が出来る。
【００５９】
ステップ(S504)：
テストが全てパスしたかどうかをチェックする。YESの場合、ステップ(S505)に進む。NOの場合、ステップ(S506)に進む。
【００６０】
ステップ(S505)：
全てのテストがパスしたので、パッケージは正当であると判断し、データ記憶手段に登録をする。
【００６１】
ステップ(S506)：
テストがパスしなかったため、パッケージに問題があると判定し、更新をキャンセルし、ユーザーに通知する。
【００６２】
ステップ(S507)：
終了。
【００６３】
ステップ(S512)：
抽象度モジュールが追加もしくは更新されたかどうかを判定。YESの場合、(S516)へ進む。NOの場合、(S513)へ進む。
【００６４】
ステップ(S513)：
テストの追加・更新のみである。
【００６５】
ステップ(S514)：
追加もしくは更新したテストをテスト実行可能テーブルに従って該当する抽象度のモジュールに対して実行し検証する。(400)のテスト実行可能テーブルにおいて、テスト名“バスプロトコルテスト”が、追加もしくは更新された場合、(402)で示すBCAとRTLモジュールでテストを実行し検証を行う。他の検証は、既に登録されている前のパッケージで確認されている。従って、異なる抽象度間において包含する機能の等価については、(402)で示すテストを実行し検証が行われれば、TL、BCA、RTLが等価であると言う事が出来る。
【００６６】
ステップ(S504)：
テストが全てパスしたかどうかをチェックする。YESの場合、ステップ(S505)に進む。NOの場合、ステップ(S506)に進む。
【００６７】
ステップ(S505)：
全てのテストがパスしたので、パッケージは正当であると判断し、データ記憶手段に登録をする。
【００６８】
ステップ(S506)：
テストがパスしなかったため、パッケージに問題があると判定し、更新をキャンセルし、ユーザーに通知する。
【００６９】
ステップ(S507)：
終了。
【００７０】
ステップ(S515)：
テストおよび抽象度モジュールの追加もしくは更新である。
【００７１】
ステップ(S516)、ステップ(S517)：
追加もしくは更新したモジュールに対して、テスト実行可能テーブルに従って対応する全てのテストを実行し検証する。かつ、追加もしくは更新したテストをテスト実行可能テーブルに従って該当する抽象度のモジュールに対して実行し検証する。
【００７２】
(400)のテスト実行可能テーブルにおいて、RTLモジュールとテスト名“アルゴリズムテスト2”が、追加・更新された場合、(402)と(403)で示すテストを実行し検証を行う。
【００７３】
ステップ(S504)：
テストが全てパスしたかどうかをチェックする。YESの場合、ステップ(S505)に進む。NOの場合、ステップ(S506)に進む。
【００７４】
ステップ(S505)：
全てのテストがパスしたので、パッケージは正当であると判断し、データ記憶手段に登録をする。
【００７５】
ステップ(S506)：
テストがパスしなかったため、パッケージに問題があると判定し、更新をキャンセルし、ユーザーに通知する。
【００７６】
ステップ(S507)：
終了。
【００７７】
以上説明したフローにより、パッケージの正当性の確認を自動的にかつ最低限のテストで行うことが出来る。
【図面の簡単な説明】
【００７８】
【図１】本発明におけるデータ管理装置の一実施例である構成を示した図である。
【図２】本実施例におけるパッケージが持つテストテーブルを示した図である。
【図３】本実施例におけるテスト抽出手段が持つ実装抽象度マップを示した図である。
【図４】本実施例におけるテスト抽出手段が作成したテスト実行可能テーブルを示した図である。
【図５】本実施例におけるデータ管理装置の動作フローを示した図である。
【符号の説明】
【００７９】
(100)  データ管理装置
(101)  データ管理装置におけるパッケージを記憶するデータ記憶手段
(102)  データ管理装置における更新モジュールテスト検出手段
(103)  データ管理装置におけるテスト抽出手段
(104)  データ管理装置におけるテスト実行手段
(105)  データ記憶手段に格納されたパッケージの正当性が確認されているモジュールAのパッケージのリスト
(106)  データ記憶手段に格納されたパッケージの正当性が確認されているモジュールBおよびモジュールCのパッケージのリスト
(107)  新たに更新しようとしているモジュールAのパッケージ
(108)  機能がどの抽象度から実装されるかを示した実装抽象度マップ
(109)  テストを実行するための動的検証もしくは静的検証ツール
(200)  パッケージに登録されているテストの詳細を示したテストテーブル
(300)  詳細な実装抽象度マップ
(400)  (200)テストテーブルと(300)実装抽象度マップから作成した詳細なテスト実行可能テーブル
(S503),(S504),(S505)  テストおよびモジュールの追加もしくは更新時のテスト抽出フロー
(S512),(S513)  モジュールのみ追加もしくは更新時のテスト抽出フロー
(S515),(S516)  テストのみ追加もしくは更新時のテスト抽出フロー
【図１】
2007040892.tif 000003
【図２】
2007040892.tif 000004
【図３】
2007040892.tif 000005
【図４】
2007040892.tif 000006
【図５】
2007040892.tif 000007