(57)【要約】【課題】  調停回路の論理検証の効率化、精度向上、及び期間短縮を実現する論理検証方法提供する。【解決手段】  テスト記述より起動を受け付ける起動トリガと、起動よりオフセット期間待つことができるオフセットタイマーと、バスプロトコルに従ってバスアクセスをおこすシーケンサーと、これらを制御するパラメータ群からなる複数のバスマスターモデルと、これらが接続される双方向バスと、このバスに接続される１、ないしは複数のバススレーブと、バスマスターのバスアクセス権を調停する調停回路（検証対象）からなる。【選択図】  図１
2006127381.tif 000002
【特許請求の範囲】
【請求項１】
バス調停回路（ａｒｂｉｔｅｒ）を論理検証するためのテストベンチにおいて、バスプロトコルに従ったバスアクセスを行うことができるバスマスターモデルを使用することを特徴とした検証手法。
【請求項２】
バスマスターモデルに、任意のタイミングで起動させることができる機能を持たせたことを特徴とした、請求項１に記載した検証手法。
【請求項３】
バスマスターモデルが調停回路に対し、バスアクセス権要求を出力する疎密を変えることが出来る機能を持たせたことを特徴とした、請求項１に記載した検証手法。
【請求項４】
バスマスターモデルが入力データを必要としないことを特徴とした、請求項１に記載した検証手法。
【請求項５】
バスマスターモデルに一時停止する機能を持たせることを特徴とした、請求項１に記載した検証手法。
【請求項６】
バスマスターモデルに実回路と同等の頻度でバスアクセス権要求信号を出力できる機能を持たせたこと、及び実回路では起こせない頻度で、バスアクセス権要求信号を出力できる機能を持たせたことを特徴とした、請求項１に記載した検証手法。
【請求項７】
複数のバスマスターモデルの動作条件を独立して設定、動作させることができることを特徴とした、請求項１に記載した検証手法。
【請求項８】
バス調停回路（ａｒｂｉｔｅｒ）を論理検証するためのテストベンチにおいて、バスプロトコルに従ったバスアクセスができるバスマスターモデルと実回路のバスマスターを合わせて使用することを特徴とした請求項１に記載した検証手法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、論理検証の容易化、精度向上、効率化（短期化）に関するものである。
【背景技術】
【０００２】
１つのあるバスに接続される複数のバスマスター回路が、このバスに接続される１つ、もしくは複数のバススレーブ回路にアクセスする場合、バスマスター同士のバス上での衝突を防ぐために、始めにバスのアクセス権を獲得しなければならない。このバスアクセス権を調停するのが調停回路（Ａｒｂｉｔｅｒ）である。従来、調停回路を検証する場合、実際にバスマスターとなる論理回路を接続して行っていた。調停回路は、接続される複数のマスターの要求を、要求順序、要求待ち状態、アクセス権利獲得状態、またそれらの組み合わせ等を考慮して次に権利を獲得できるマスターを決定する様に設計されている。この調停回路を論理検証するには、前記複数のマスターが起こしうる、バスアクセス権要求タイミングについて、全ての組み合わせをテスト項目として挙げて、検証する必要がある（特許文献１参照）。
【特許文献１】特開２００２−７３５２８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかし、各バスマスター回路がバスアクセス権要求を出力するタイミングは、バスマスター回路内の処理状態によるため、簡単にコントロールできたり、予想がついたりするものではない。従って、例えばある２つのバスマスターのバスアクセス権要求信号が、調停回路に対して同時に出力された場合の調停回路の振る舞いについて論理検証をするためには、２つのバスマスターに複数回のバスアクセス権要求を出させて、要求タイミングが同時になるまで行うということが必要であった。これは一例であるが、すなわち、バス調停回路を十分に検証するためには、複数のバスマスター回路を実際に動かし、前述のテスト項目を全てカバーする必要があり、膨大なシミュレーション時間がかかるという問題があった。
【０００４】
さらに、検証開始時期について述べれば、調停回路の検証は各バスマスター回路の完成（検証完了）を待たなければならない。もしも検証が完全でないバスマスター回路を使用して調停回路の検証を行えば、不具合が出た場合にその不具合の原因がバスマスター回路にあるのか調停回路にあるのかの特定が難しく、検証に長い時間がかかるという問題があった。
【課題を解決するための手段】
【０００５】
上記問題を解決するための本発明の検証方法は、調停回路（ａｒｂｉｔｅｒ）の論理検証のためのテストベンチにおいて、実際のバスマスター回路を使用せず、バスプロトコルに従ったバスアクセスを行うことができるバスマスターモデルを使用することを特徴としたものである。
【０００６】
（作用）
バスマスターモデルに、バスプロトコルに従ったバスアクセスができる機能を持たせると共に、起動タイミング、バスアクセス権要求出力の疎密を自由に設定できる様にし、これらを複数使用することによって、前述のテスト項目を、容易に、より短時間で起こすことが出来る。
【０００７】
また、マスターモデルは実際の回路と同等の動作はもちろんのこと、更に実際の回路では起こせないようなタイミングで動作や機能を実行させることができるため、調停回路を固定のシステム（バスマスター）を想定したものでなく、ＩＰコアとしての再利用性も考えた広い意味での検証を行うことが出来る。
【０００８】
また、各バスマスター回路の完成を待たずに、調停回路単独で検証を行うことができ、各バスマスター回路の検証と並行して検証が進められるため、全体としての検証時間を短縮することが出来る。
【発明の効果】
【０００９】
以上のように本発明によれば、調停回路の論理検証を行うにあたり、複雑な事象（各マスターモデルの要求信号の組み合わせ）を容易に実現することが出来、また、これらを起こす時間を短縮することができ、調停回路の論理検証の容易化、精度向上、効率化を図ることが出来る。
【発明を実施するための最良の形態】
【００１０】
（実施例１）
以下、本発明の検証手法の実施例について、図１を参照しながら説明する。
【００１１】
図３は調停回路の検証手法を示す従来例である。まず、この従来例を説明する。Ｍａｓｔｅｒ＿Ａ  ２０、Ｍａｓｔｅｒ＿Ｂ  ２１、Ｍａｓｔｅｒ＿Ｃ  ２２はバス４０のマスターとなるブロックである。Ｓｌａｖｅ＿Ｄ  ３０はバス４０のスレーブとなるブロックである。この例では１つのスレーブしかバス４０に接続されていないが、複数接続されていても構わない。Ａｒｂｉｔｅｒ  １０はバス４０のアクセス権を調停するブロックである。このＡｒｂｉｔｅｒ  １０が論理検証の対象である。マスターブロックはスレーブブロックにアクセス（データを送ったり、データを要求したり）する場合、他のマスターとの衝突を避けるため、まずＡｒｂｉｔｅｒ  １０に対してバス４０のアクセス権を要求する。Ａｒｂｉｔｅｒ  １０は各マスターからのバスアクセス要求を調停し、１つのマスターに対してバスアクセス許可信号を発行する。マスターブロックはこの許可信号を得て、初めてバス４０を介してＳｌａｖｅ＿Ｄ  ３０にアクセスすることができる。
【００１２】
図３の例で示したように、バスマスターとしては様々な機能を持つものが考えられる。例えばＭａｓｔｅｒ＿Ａ  ２０はバス４０ではない経路、バス５０を介してデータを受け取り、所定の処理をした後にＳｌａｖｅ＿Ｄ  ３０にデータを送信する。また、Ｍａｓｔｅｒ＿Ｂ  ２１はＭａｓｔｅｒ＿Ａ  ２０と同様の機能に加え、Ｓｌａｖｅ＿Ｄ  ３０に対してデータを要求し、得られたデータを所定の処理をした後にバス５１を介して出力する機能を持つ。また、Ｍａｓｔｅｒ＿Ｃ  ２２はバス４０以外にデータをやり取りするインターフェースを持たず、Ｓｌａｖｅ＿Ｄ  ３０に対してデータを要求し、得られたデータを所定の処理をした後にＳｌａｖｅ＿Ｄ  ３０に戻す機能を持つ。
【００１３】
アクセス要求、調停、アクセスの様子を示したタイミングチャートを図２に示す。
【００１４】
この例においてはＡｒｂｉｔｅｒ  １０の機能として、Ｍａｓｔｅｒ＿Ａ  ２０、Ｍａｓｔｅｒ＿Ｂ  ２１、Ｍａｓｔｅｒ＿Ｃ  ２２のバスアクセス権のプライオリティを「Ｍａｓｔｅｒ＿Ａ  ＞  Ｍａｓｔｅｒ＿Ｂ  ＞  Ｍａｓｔｅｒ＿Ｃ」としている。また、この図ではＳｌａｖｅ  ３０に対して、どのバスマスターもデータ送信のみを行っており、データの要求は行っていない。また、データ送信のバースト長は４バースト固定としている。
【００１５】
図２において、タイミングａにてＭａｓｔｅｒ＿Ａ  ２０はバスアクセス権要求ｒｅｑ＿ａを出しており、Ａｒｂｉｔｏｒ  １０はタイミングｂにて許可信号ａｃｋ＿ａを返している。これを受けＭａｓｔｅｒ＿Ａ  ２０はタイミングｃよりデータ送信を開始している。この間、Ｍａｓｔｅｒ＿Ｂ  ２１はタイミングｃで、また、Ｍａｓｔｅｒ＿Ｃ  ２２はタイミングｄでバスアクセス権要求ｒｅｑ＿ｂ、ｒｅｑ＿ｃをそれぞれ出しているが、待たされている様子がわかる。Ｍａｓｔｅｒ＿Ａ  ２０のデータ送信が終わると、Ａｒｂｉｔｅｒ  １０はタイミングｇにてＭａｓｔｅｒ＿Ｂ  ２１に対して許可信号ａｃｋ＿ｂを返している。このタイミングｇではＭａｓｔｅｒ＿Ｂ  ２１とＭａｓｔｅｒ＿Ｃ  ２２のバスアクセス権要求が競合しているが、Ｍａｓｔｅｒ＿Ｂ  ２１の方がプライオリティが高いため、Ｍａｓｔｅｒ＿Ｂ  ２１に許可が与えられている。Ａｒｂｉｔｅｒ  １０はこの様にバスアクセス権を調停し、バス４０で衝突が起きないようにしている。図２のＢｕｓ  ４０がこれを示している。
【００１６】
このようなバス調停において、バス調停回路の検証すべきテスト項目は、例えばＭａｓｔｅｒ＿Ａ  ２０とＭａｓｔｅｒ＿Ｂ  ２１が競合した場合のみを考えた場合、  （１）ｒｅｑ＿ａのみが立っている場合、（２）ｒｅｑ＿ｂのみが立っている場合、（３）ｒｅｑ＿ａ，ｒｅｑ＿ｂの両方が立っていて、ｒｅｑ＿ａの方が先に立った場合、（４）  ｒｅｑ＿ｂが先に立った場合、（５）同時に立った場合、（６）現在Ｍａｓｔｅｒ＿Ａが承認信号ａｃｋ＿ａを受けていてｒｅｑ＿ａ，ｒｅｑ＿ｂが同時に立っている場合、（７）またその逆などが考えられる。これらすべての事象を起こさなければならないが、例えば「（５）同時にバスアクセス要求が出た場合」の事象を起こさせたいとしても、実回路であるＭａｓｔｅｒ＿Ａ  ２０及びＭａｓｔｅｒ＿Ｂ  ２１は、ある所定の処理の後要求信号を出すものであり、バスアクセス要求が出るタイミングをコントロールすることはできない。従って、２つのマスターにバスアクセス要求をする動作を行わせ、両者のアクセス要求が同時になるまで行う必要がある。
【００１７】
バスマスター回路の数が更に多くなると、その組み合わせはさらに複雑になり、テスト項目は多くなる。従ってテスト項目を全て行うには非常に長い時間、非常に多くのテスト記述が必要となる。
【００１８】
図１に示す本発明による検証方法では、このバスマスター回路の代わりにバスプロトコルに従ったバスアクセスを行うことができるバスマスターモデルを接続した。バスマスターモデルの構成を図４に示す。
【００１９】
図４において、１００はマスターモデルの全体図。１１０はテスト記述より起動を受け付ける起動トリガ。１４０は各種パラメータでテスト記述より直接指定することも、起動を受けてからマスターモデル内で動的に生成することもできるものとした。パラメータの種類としては、起動を受けてからバスアクセスを起こすまでのオフセット時間を規定する「オフセットタイム」、バスアクセス終了から次のバスアクセスを起こすまでのインターバルを規定する「コマンド・インターバル」、データを送るアクセスなのかデータを要求するアクセスなのかを規定する「Ｗｒｉｔｅ／Ｒｅａｄ」、転送データの値を規定する「転送データ」、転送データ数を規定する「転送データ数」を定義した。１２０はオフセット・タイマーで、パラメータ１４０のオフセットタイムを参照し、この値分のクロックサイクル期間、バスアクセス開始を待たせるためのものである。１３０はバスプロトコルに従ったバスアクセスを起こすシーケンサーである。オフセットタイマーによりオフセット期間待たされたあとに起動する。アクセスの詳細はパラメータ１４０によって決定される。転送回数は「転送データ数」パラメータによって決定される。アクセスの種類がデータを送るアクセスであった場合、送るデータの値は「転送データ」パラメータを参照する。１つのアクセスが終了すると「コマンド・インターバル」パラメータ分のクロックサイクルを待った後、次のアクセスを行う。ここで、「転送データ」パラメータはテスト記述から直接リストとして与えてもいいし、マスターモデル１００がバスアクセスを行う度に動的に作成しても構わない。このマスターモデルの詳細動作のフローチャートを図５に示した。
【００２０】
図４におけるマスターモデル１００で、図３における各バスマスターを置き換えた図が図１である。図１は、本発明によるバス調停回路を検証する検証手法を示している。図３におけるＭａｓｔｅｒ＿Ａ  ２０に対してＭａｓｔｅｒ＿Ａ  Ｍｏｄｅｌ  ２００が、図３におけるＭａｓｔｅｒ＿Ｂ  ２１に対してＭａｓｔｅｒ＿Ｂ  Ｍｏｄｅｌ  ２０１が、図３におけるＭａｓｔｅｒ＿Ｃ  ２２に対してＭａｓｔｅｒ＿Ｃ  Ｍｏｄｅｌ  ２０２がそれぞれ置き換わっている。
【００２１】
この図で示す検証手法によれば、例えば調停回路１０の検証項目として挙げた前述の「Ｍａｓｔｅｒ＿ＡとＭａｓｔｅｒ＿Ｂが同時にバスアクセス権を要求した状況」を起こしたいとき、Ｍａｓｅｒ＿Ａ  Ｍｏｄｅｌ  ２００とＭａｓｔｅｒ＿Ｂ  Ｍｏｄｅｌ  ２０１の「オフセット・タイム」パラメータを同じにすればよく、容易にコントロールできる。また、その他の組み合わせについても、Ｍａｓｔｅｒ  Ｍｏｄｅｌの「オフセット・タイム」パラメータ及び、「コマンド・インターバル」パラメータを制御することにより容易に起こすことができる。
また、テスト項目として挙げた全ての項目を、これらＭａｓｔｅｒ  Ｍｏｄｅｌをコントロールして起こしたとしても、テスト記述をするのに非常に多くの工数がかかるが、図５に示したフローチャート図の３１１、３３１の様に「オフセット・タイム」パラメータや、「コマンド・インターバル」パラメータを、Ｍａｓｔｅｒ  Ｍｏｄｅｌの動作中に動的に作成できるため、ある程度のテスト項目までは自動的に起こさせ、残りのテスト項目だけを人間がコントロールしてテスト記述をするということもでき、検証期間を短縮することができる。
【００２２】
また、図３では様々な機能を持ったバスマスター回路がバス調停回路に接続されていたが、本検証手法では全てこの同じマスターモデルで置き換えた。このマスターモデルは、「ｗｒｉｔｅ／ｒｅａｄ」パラメータをｗｒｉｔｅに固定することにより、図３におけるＭａｓｔｅｒ＿Ａの様に、データの転送アクセスのみをスレーブに対して行うようにすることができる。このため、実回路に忠実に動作させてバス調停回路の検証を行うことはもちろんのこと、実回路以上の機能を備えているため、調停回路をより汎用性のあるものとして検証し、機能を保障することができる。
【００２３】
（実施例２）
実施例１ではバス調停回路に接続される全てのバスマスター回路を、バスマスターモデルに置き換えたが、本実施例では、従来例を示す図３のＭａｓｔｅｒ＿Ｂ  ２１とＭａｓｔｅｒ＿Ｃ  ２２のみをマスターモデルに置き換え、実回路のバスマスターとバスマスターモデルを混合した。図６にこの様子を示す。
【００２４】
この例ではＭａｓｔｅｒ＿Ａ  ２０のバスアクセスに対して、Ｍａｓｔｅｒ＿Ｂ  Ｍｏｄｅｌ  ２０１、Ｍａｓｔｅｒ＿Ｃ  Ｍｏｄｅｌ  ２０２が様々なバスアクセスを起こすことができる。前述の様にバスマスターモデルは意図的にも、また、無作為にもバスアクセスを行うことができるため、効率的にＭａｓｔｅｒ＿Ａ  ２０のバスアクセス機能の検証を行うことができる。また、Ｍａｓｔｅｒ＿Ｂ、Ｍａｓｔｅｒ＿Ｃの設計進捗に関わらず論理検証を行えるというメリットがある。
【図面の簡単な説明】
【００２５】
【図１】本発明の検証手法の実施例の構成図。
【図２】バス調停の様子を示すタイミング図。
【図３】従来の検証手法の例の構成図。
【図４】本発明の検証手法におけるバスマスターモデルの構成を示すブロック図。
【図５】本発明の検証手法におけるバスマスターモデルの動作手順を示すフロー図。
【図６】本発明の検証手法の別の実施例である。
【図１】
2006127381.tif 000003
【図２】
2006127381.tif 000004
【図３】
2006127381.tif 000005
【図４】
2006127381.tif 000006
【図５】
2006127381.tif 000007
【図６】
2006127381.tif 000008