(57)【要約】  複数のイニシエータから同時あるいは交互に複数のコマンド発行要求（即ち、要求信号の送信）がなされても、各イニシエータからのコマンド発行要求（即ち、要求信号）のタイミングを乱すことで、コマンドの発行周期が一定になることを防ぎ、ターゲットからいつもリトライの応答がなされるという状況を回避することを目的とする。バス制御部１２０は、所定の優先順位に従い、要求信号を送信したイニシエータ１０２に対して許可信号を送信することで、当該イニシエータ１０２に対してバス１０４の使用を許可する。マスク生成部１１０は、少なくとも１つのイニシエータ１０２へマスク信号を送信して当該イニシエータ１０２に要求信号をマスクさせることで、バス制御部１２０が当該イニシエータ１０２に対してバス１０４の使用を許可するタイミングを非周期となるように制御する。
2010021054.tif 000002
【特許請求の範囲】
【請求項１】
バスに接続された複数のイニシエータの各々が、バスの使用を許可されたときにバスに接続されたターゲットへ所定の処理の実行を指令するコマンド信号を送信し、当該ターゲットで当該処理が実行されないと判断した場合、再度バスの使用を許可されたときに当該ターゲットへコマンド信号を送信するバス通信システムを制御するバスコントローラであって、
所定の優先順位に従い、各イニシエータに対してバスの使用を許可するバス制御部と、
前記バス制御部が少なくとも１つのイニシエータに対してバスの使用を許可するタイミングを非周期となるように制御するマスク生成部とを備えることを特徴とするバスコントローラ。
【請求項２】
各イニシエータは、前記バス制御部に対してバスの使用を要求する要求信号を所定の周期で生成して送信し、
前記マスク生成部は、各イニシエータから要求信号が送信されるタイミングが非周期となるように各イニシエータで生成される要求信号をマスク制御することを特徴とする請求項１に記載のバスコントローラ。
【請求項３】
前記マスク生成部は、
各イニシエータで生成される要求信号をマスク制御する周期をマスク周期として設定するマスク周期設定部を備えることを特徴とする請求項２に記載のバスコントローラ。
【請求項４】
前記マスク生成部は、さらに、
前記マスク周期設定部が設定したマスク周期ごとにマスク制御の対象とするイニシエータをマスク条件として設定するマスク条件設定部を備えることを特徴とする請求項３に記載のバスコントローラ。
【請求項５】
前記マスク生成部は、さらに、
前記マスク周期設定部が設定したマスク周期ごとに前記マスク条件設定部が設定したマスク条件を変更するイニシエータマスクＩＤ（識別子）カウンタを備えることを特徴とする請求項４に記載のバスコントローラ。
【請求項６】
前記マスク条件設定部は、コマンド信号の種別ごとにマスク制御の対象とするイニシエータをマスク条件として設定することを特徴とする請求項４に記載のバスコントローラ。
【請求項７】
前記マスク生成部は、さらに、
前記マスク周期設定部が設定したマスク周期ごとにマスク制御する時間をマスク期間として設定するマスク期間設定部を備えることを特徴とする請求項３に記載のバスコントローラ。
【請求項８】
前記マスク生成部は、さらに、
イニシエータごとにマスク制御の対象とするか否かを設定するマスク対象指定フラグ設定部を備えることを特徴とする請求項３に記載のバスコントローラ。
【請求項９】
複数のイニシエータと少なくとも１つのターゲットとをバスに接続しているバス通信システムであって、
各イニシエータは、バスの使用を許可されたときにターゲットへ所定の処理の実行を指令するコマンド信号を送信し、当該ターゲットで当該処理が実行されないと判断した場合、再度バスの使用を許可されたときに当該ターゲットへコマンド信号を送信し、
前記バス通信システムは、さらに、
所定の優先順位に従い、各イニシエータに対してバスの使用を許可するバス制御部と、前記バス制御部が少なくとも１つのイニシエータに対してバスの使用を許可するタイミングを非周期となるように制御するマスク生成部とを備えるバスコントローラをバスに接続していることを特徴とするバス通信システム。
【請求項１０】
バスに接続された複数のイニシエータの各々が、バスの使用を許可されたときにバスに接続されたターゲットへ所定の処理の実行を指令するコマンド信号を送信し、当該ターゲットで当該処理が実行されないと判断した場合、再度バスの使用を許可されたときに当該ターゲットへコマンド信号を送信するバス通信システムを制御するバス制御方法であって、
所定の優先順位に従い、各イニシエータに対してバスの使用を許可し、
前記許可で少なくとも１つのイニシエータに対してバスの使用を許可するタイミングを非周期となるように制御することを特徴とするバス制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、バスコントローラ及びバス通信システム及びバス制御方法に関するものである。本発明は、特に、データバス通信方式に関するものである。
【背景技術】
【０００２】
近年、バス通信システムの高機能化、及び、バス通信システムに接続されるデバイスの数の増加や高性能化によって、システムバスへの負荷が増えつつあり、このような状況においてシステムバスやメモリバスの性能を超えたリクエストが発行されると、優先度の高いイニシエータしかサービスを受けられず、優先度の低いイニシエータがハングするというケースが発生していた。そのため、低い優先度のイニシエータでもサービスが受けられるように、各イニシエータにサービスを均等に提供するための、ラウンドロビンやＬＲＵ（Ｌｅａｓｔ・Ｒｅｃｅｎｔｌｙ・Ｕｓｅｄ）などの方式が採用されている。しかし、ラウンドロビンやＬＲＵを採用したシステムにおいても、各イニシエータが同時あるいは交互に複数のリクエストを発行し、各イニシエータがバス権を交互に与えられ、均一にコマンドを発行するようなケースが発生すると、イニシエータによっては、アクセスしたいターゲットが、いつも別のイニシエータからのコマンドの処理中で毎回アクセスが拒否され、リトライすることになり、いつまでもコマンドが受け付けられないという状態が続いてハングするという課題がある。【０００３】
特許文献１では、アクセス周期が決まっている高優先のイニシエータとアクセス周期の規定がない低優先のイニシエータが同一ターゲットにアクセスするシステムにおいて、低優先のイニシエータのバス解放期間に閾値を設けることで、使用中のバスの解放が中断され、バス権が高優先のイニシエータに割り当てられるので、高優先のアクセスが保証されることが開示されている。
【特許文献１】特開２００３−２８１０８３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
特許文献１では、各イニシエータが同時あるいは交互に複数のリクエストを発行し、各イニシエータがバス権を交互に与えられ、均一にコマンドを発行するようなケースが発生した場合に、イニシエータによっては、アクセスしたいターゲットが、いつも別のイニシエータからのコマンドの処理中で毎回リトライすることになり、コマンドが受け付けられない状態を回避する方式については開示されていない。【０００５】
一般的なデータバスシステムを図１１に示す。図１１に示したシステムは、複数のイニシエータとイニシエータからのコマンドを処理する１つ以上のターゲットと複数のイニシエータからのリクエストに対して、ラウンドロビンやＬＲＵなどの優先順位制御方式により均等又は固定優先順位にサービス提供を行うバスコントローラと、コマンドを１つ選んで駆動するバスからなる。優先順位制御を行うバスコントローラは、イニシエータがバスにアドレスとコマンドをのせる前にコマンド発行要求（即ち、要求信号（ｒｅｑｕｅｓｔ））を受けて、許可する場合はイニシエータに対して許可（即ち、許可信号（ｇｒａｎｔ））を返す。許可を受けたイニシエータは、ターゲットに対してアドレスとコマンド（ｃｍｄ）を発行する。イニシエータからのコマンドを処理するターゲットは、アドレスとコマンドを見て、アクセプト（ａｃｃｅｐｔ）かリトライ（ｒｅｔｒｙ）をイニシエータに返すようになっている。しかし、このような構成のシステムでは、複数のイニシエータからのコマンド発行に対してターゲットのサービス能力が十分でないときに、イニシエータによってはコマンド発行の度にリトライ応答しか行われないことがあり、そのイニシエータがアクセプトされるまで他のイニシエータの動作が変わらない場合にはバス全体でハングアップするという課題がある。【０００６】
特許文献１で開示されている方式では、バス権を高優先のイニシエータに確実に割り当てることはできても、バス権が割り当てられた後にイニシエータが発行したコマンドに対し、ターゲットから毎回リトライの応答がなされるケースを回避できない。複数のイニシエータから同時あるいは交互に複数のコマンド発行が要求されている状況で、毎回同じイニシエータから発行されたコマンドに対し、ターゲットからリトライの応答がなされ、そのイニシエータがハングするケースは、発生頻度が低くても、必ず回避しなければならないものである。【０００７】
本発明は、例えば、複数のイニシエータから同時あるいは交互に複数のコマンド発行要求（即ち、要求信号の送信）がなされても、各イニシエータからのコマンド発行要求（即ち、要求信号）のタイミングを乱すことで、コマンドの発行周期が一定になることを防ぎ、ターゲットからいつもリトライの応答がなされるという状況を回避することを目的とする。
【課題を解決するための手段】
【０００８】
本発明の一の態様に係るバスコントローラは、
バスに接続された複数のイニシエータの各々が、バスの使用を許可されたときにバスに接続されたターゲットへ所定の処理の実行を指令するコマンド信号を送信し、当該ターゲットで当該処理が実行されないと判断した場合、再度バスの使用を許可されたときに当該ターゲットへコマンド信号を送信するバス通信システムを制御するバスコントローラであって、
所定の優先順位に従い、各イニシエータに対してバスの使用を許可するバス制御部と、
前記バス制御部が少なくとも１つのイニシエータに対してバスの使用を許可するタイミングを非周期となるように制御するマスク生成部とを備えることを特徴とする。【０００９】
各イニシエータは、前記バス制御部に対してバスの使用を要求する要求信号を所定の周期で生成して送信し、
前記マスク生成部は、各イニシエータから要求信号が送信されるタイミングが非周期となるように各イニシエータで生成される要求信号をマスク制御することを特徴とする。【００１０】
前記マスク生成部は、
各イニシエータで生成される要求信号をマスク制御する周期をマスク周期として設定するマスク周期設定部を備えることを特徴とする。【００１１】
前記マスク生成部は、さらに、
前記マスク周期設定部が設定したマスク周期ごとにマスク制御の対象とするイニシエータをマスク条件として設定するマスク条件設定部を備えることを特徴とする。【００１２】
前記マスク生成部は、さらに、
前記マスク周期設定部が設定したマスク周期ごとに前記マスク条件設定部が設定したマスク条件を変更するイニシエータマスクＩＤ（識別子）カウンタを備えることを特徴とする。【００１３】
前記マスク条件設定部は、コマンド信号の種別ごとにマスク制御の対象とするイニシエータをマスク条件として設定することを特徴とする。【００１４】
前記マスク生成部は、さらに、
前記マスク周期設定部が設定したマスク周期ごとにマスク制御する時間をマスク期間として設定するマスク期間設定部を備えることを特徴とする。【００１５】
前記マスク生成部は、さらに、
イニシエータごとにマスク制御の対象とするか否かを設定するマスク対象指定フラグ設定部を備えることを特徴とする。【００１６】
本発明の一の態様に係るバス通信システムは、
複数のイニシエータと少なくとも１つのターゲットとをバスに接続しているバス通信システムであって、
各イニシエータは、バスの使用を許可されたときにターゲットへ所定の処理の実行を指令するコマンド信号を送信し、当該ターゲットで当該処理が実行されないと判断した場合、再度バスの使用を許可されたときに当該ターゲットへコマンド信号を送信し、
前記バス通信システムは、さらに、
所定の優先順位に従い、各イニシエータに対してバスの使用を許可するバス制御部と、前記バス制御部が少なくとも１つのイニシエータに対してバスの使用を許可するタイミングを非周期となるように制御するマスク生成部とを備えるバスコントローラをバスに接続していることを特徴とする。【００１７】
本発明の一の態様に係るバス制御方法は、
バスに接続された複数のイニシエータの各々が、バスの使用を許可されたときにバスに接続されたターゲットへ所定の処理の実行を指令するコマンド信号を送信し、当該ターゲットで当該処理が実行されないと判断した場合、再度バスの使用を許可されたときに当該ターゲットへコマンド信号を送信するバス通信システムを制御するバス制御方法であって、
所定の優先順位に従い、各イニシエータに対してバスの使用を許可し、
前記許可で少なくとも１つのイニシエータに対してバスの使用を許可するタイミングを非周期となるように制御することを特徴とする。
【発明の効果】
【００１８】
本発明の一の態様によれば、バスコントローラにおいて、マスク生成部が、バス制御部が少なくとも１つのイニシエータに対してバスの使用を許可するタイミングを非周期となるように制御することにより、コマンドの発行周期が一定になることを防ぎ、ターゲットからいつもリトライの応答がなされるという状況を回避することが可能となる。
【発明を実施するための最良の形態】
【００１９】
以下、本発明の実施の形態について、図を用いて説明する。【００２０】
実施の形態１．
本実施の形態では、コマンド発行の許可をするタイミングや間隔の乱れを作るために（バスに対するアクセス周期を乱すために）、リクエストを受け付けさせたいイニシエータ以外を、ある期間マスクすることによって不規則性を与えるデータバス通信システムについて、図面を参照して説明する。【００２１】
図１は、リクエストを受け付けさせたいイニシエータ１０２以外をある期間マスクすることを可能とするバス通信システム１００の構成を示すブロック図である。【００２２】
図１において、バス通信システム１００は、バスコントローラ１０１、複数のイニシエータ１０２、少なくとも１つのターゲット１０３を備える。バスコントローラ１０１、イニシエータ１０２、ターゲット１０３は、バス１０４に接続されている。【００２３】
バスコントローラ１０１は、図１１に示したバスコントローラにマスク信号を生成するマスク生成部１１０を付加したものであり、バス通信システム１００を制御する。各イニシエータ１０２は、バスコントローラ１０１にコマンド発行要求（即ち、要求信号の送信）を行い、ターゲット１０３に対してコマンドを発行する。ターゲット１０３は、イニシエータ１０２からのコマンドを処理する。バス１０４は、イニシエータ１０２からのコマンドを１つ選んで駆動する。【００２４】
具体的には、イニシエータ１０２は、コマンドを発行するためにバス１０４の使用を要求する要求信号（ｒｅｑｕｅｓｔ）を所定の周期で生成してバスコントローラ１０１へ送信する。バスコントローラ１０１は、イニシエータ１０２から要求信号（ｒｅｑｕｅｓｔ）を受信すると、当該イニシエータ１０２に対してコマンドの発行を許可するか否か、即ち、バス１０４の使用を許可するか否かを判断する。バスコントローラ１０１は、当該イニシエータ１０２に対してバス１０４の使用を許可すると判断した場合、当該イニシエータ１０２へ許可信号（ｇｒａｎｔ）を送信する。イニシエータ１０２は、ある周期でバスコントローラ１０１から許可信号（ｇｒａｎｔ）を受信したとき、即ち、バス１０４の使用を許可されたときに、ターゲット１０３へ所定の処理の実行を指令するコマンド信号（ｃｍｄ）を送信する。ターゲット１０３は、イニシエータ１０２からコマンド信号（ｃｍｄ）を受信すると、当該イニシエータ１０２からのコマンドを処理するか否か、即ち、指令された処理を実行できるか否かを判断する。ターゲット１０３は、当該イニシエータ１０２から指令された処理を実行できると判断した場合、当該イニシエータ１０２へアクセプト信号（ａｃｃｅｐｔ）を送信する。一方、ターゲット１０３は、当該イニシエータ１０２から指令された処理を実行できないと判断した場合、当該イニシエータ１０２へリトライ信号（ｒｅｔｒｙ）を送信する。なお、バスコントローラ１０１が、イニシエータ１０２から指令された処理をターゲット１０３に実行させるか否かを判断し、当該処理を実行させないと判断した場合、当該イニシエータ１０２へリトライ信号（ｒｅｔｒｙ）を送信してもよい。イニシエータ１０２は、リトライ信号（ｒｅｔｒｙ）を受信した場合、即ち、当該ターゲット１０３で当該処理が実行されないと判断した（認識した）場合、次以降の周期でバスコントローラ１０１から許可信号（ｇｒａｎｔ）を受信したとき、即ち、再度バス１０４の使用を許可されたときに、当該ターゲット１０３へコマンド信号（ｃｍｄ）を送信する。以降、同様の通信が繰り返される。【００２５】
バスコントローラ１０１は、マスク生成部１１０、バス制御部１２０を備える。【００２６】
マスク生成部１１０は、アクセス周期の間隔や、アクセス周期を乱すために、あるアクセス周期で、リクエストを受け付けさせたいイニシエータ１０２以外を、ある期間マスクする信号（マスク信号）を生成する。バス制御部１２０は、各イニシエータ１０２からのリクエストの優先順位制御を行う。つまり、バス制御部１２０は、所定の優先順位に従い、要求信号（ｒｅｑｕｅｓｔ）を送信したイニシエータ１０２に対して許可信号（ｇｒａｎｔ）を送信することで、当該イニシエータ１０２に対してバス１０４の使用を許可する。マスク生成部１１０は、少なくとも１つのイニシエータ１０２へマスク信号を送信して当該イニシエータ１０２に要求信号（ｒｅｑｕｅｓｔ）をマスクさせる（例えば、要求信号を送信させないようにしたり、要求信号として意味のない信号を送信させたりする）ことで、バス制御部１２０が当該イニシエータ１０２に対してバス１０４の使用を許可するタイミングを非周期となるように制御する。即ち、マスク生成部１１０は、各イニシエータ１０２から要求信号（ｒｅｑｕｅｓｔ）が送信されるタイミングが非周期となるように各イニシエータ１０２で生成される要求信号（ｒｅｑｕｅｓｔ）をマスク制御する。なお、マスク生成部１１０は、バス制御部１２０へマスク信号を送信してバス制御部１２０に少なくとも１つのイニシエータ１０２からの要求信号（ｒｅｑｕｅｓｔ）をマスクさせる（例えば、受信した要求信号を無視させたり、受信した要求信号を意味のない信号に変換させたりする）ことで、バス制御部１２０が当該イニシエータ１０２に対してバス１０４の使用を許可するタイミングを非周期となるように制御してもよい。即ち、マスク生成部１１０は、バス制御部１２０の内部で要求信号（ｒｅｑｕｅｓｔ）が処理（又は検出）されるタイミングが非周期となるようにバス制御部１２０で各イニシエータ１０２から受信される要求信号（ｒｅｑｕｅｓｔ）をマスク制御してもよい。あるいは、マスク生成部１１０は、バス制御部１２０へマスク信号を送信してバス制御部１２０に少なくとも１つのイニシエータ１０２への許可信号（ｇｒａｎｔ）をマスクさせる（例えば、許可信号を送信させないようにしたり、許可信号として意味のない信号を送信させたりする）ことで、バス制御部１２０が当該イニシエータ１０２に対してバス１０４の使用を許可するタイミングを非周期となるように制御してもよい。即ち、マスク生成部１１０は、バス制御部１２０から許可信号（ｇｒａｎｔ）が送信されるタイミングが非周期となるようにバス制御部１２０で生成される許可信号（ｇｒａｎｔ）をマスク制御してもよい。【００２７】
マスク生成部１１０は、マスク周期設定部１１１、イニシエータマスクＩＤ（識別子）カウンタ１１２、マスク期間設定部１１３、マスク条件設定部１１４、マスク対象指定フラグ設定部１１５を備える。【００２８】
マスク周期設定部１１１は、マスクを行うタイミング（周期）を任意に設定する。具体的には、マスク周期設定部１１１は、各イニシエータ１０２で生成される要求信号（ｒｅｑｕｅｓｔ）をマスク制御する周期をマスク周期として設定する。イニシエータマスクＩＤカウンタ１１２は、マスク周期ごとに変更するマスク対象となるイニシエータ１０２を任意に設定する。具体的には、イニシエータマスクＩＤカウンタ１１２は、マスク周期設定部１１１が設定したマスク周期ごとに、後述するマスク条件設定部１１４が設定したマスク条件を変更する。マスク期間設定部１１３は、マスク対象となったイニシエータ１０２のマスク期間を任意に設定する。つまり、マスク期間設定部１１３は、マスク周期設定部１１１が設定したマスク周期ごとにマスク制御する時間をマスク期間として設定する。マスク条件設定部１１４は、マスク周期設定部１１１が設定したマスク周期ごとにマスク制御の対象とするイニシエータ１０２をマスク条件として設定する。そして、マスク条件設定部１１４は、イニシエータマスクＩＤカウンタ１１２に対応したイニシエータ１０２に対して、マスク期間設定部１１３で設定された期間マスク信号の出力を行う。マスク対象指定フラグ設定部１１５は、各イニシエータ１０２のマスクを有効にするか無効にするかを任意に設定する。つまり、マスク対象指定フラグ設定部１１５は、イニシエータ１０２ごとにマスク制御の対象とするか否かを設定する。【００２９】
ここで、マスク条件の設定例を図２に示す。図２は、イニシエータ１０２が５つで、マスク条件として、各イニシエータ１０２が必ず１度は許可されるケース、全てが許可されないケース、イニシエータ１０２が３つずつ許可されるケースを作るためにイニシエータマスクＩＤを０から９まで用意した例であり、イニシエータマスクＩＤとマスクを行うイニシエータ１０２の対応を表わしている。マスク条件は任意に設定可能なものであり、バス通信システム１００の構成に合わせて適宜設定することが望ましいが、本例においてイニシエータマスクＩＤ＝０〜５に該当するものを設定しておけば様々な構成に対応できると考えられる。特に、イニシエータマスクＩＤ＝０〜４に該当するものを設定しておけば汎用性が高いバス通信システム１００を提供できると考えられる。【００３０】
バス通信システム１００は、例えばコンピュータに搭載されるものであり、バス通信システム１００のバスコントローラ１０１は、コンピュータが備えるＣＰＵ２０１（Ｃｅｎｔｒａｌ・Ｐｒｏｃｅｓｓｉｎｇ・Ｕｎｉｔ）により制御される。ＣＰＵ２０１は、コンピュータが備えるＲＯＭ（Ｒｅａｄ・Ｏｎｌｙ・Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ・Ａｃｃｅｓｓ・Ｍｅｍｏｒｙ）などのメモリ２０２を用いてプログラムを実行し、例えばマスク生成部１１０のマスク周期設定部１１１、マスク期間設定部１１３、マスク対象指定フラグ設定部１１５の設定を行う。後述するようにマスク条件設定部１１４を回路として実装した場合、マスク周期設定部１１１、マスク期間設定部１１３、マスク対象指定フラグ設定部１１５の設定をプログラムにより任意に行うことができるようにすることで、バス通信システム１００の構成に適したマスク制御を行うことが容易となる。【００３１】
なお、本実施の形態の説明において「〜部」として説明するものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜工程」、「〜手順」、「〜処理」であってもよい。「〜部」として説明するものは、メモリ２０２に記憶されたファームウェアで実現されていても構わない。あるいは、ソフトウェアのみ、あるいは、素子・デバイス・基板・配線などのハードウェアのみ、あるいは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実現されていても構わない。ファームウェアとソフトウェアは、プログラムとして、メモリ２０２に記憶される。このプログラムはＣＰＵ２０１により読み出され、ＣＰＵ２０１により実行される。即ち、プログラムは、本実施の形態の説明で述べる「〜部」としてコンピュータを機能させるものである。あるいは、本実施の形態の説明で述べる「〜部」の手順や方法をコンピュータに実行させるものである。【００３２】
次に、図２に例示したマスク条件の設定の下で、マスク周期がＴａ、イニシエータマスクＩＤが２、マスク期間がＴｍ、マスク対象指定フラグがイニシエータＡとイニシエータＣを有効にしているときの動作について、図３、図４、図５を用いて説明する。【００３３】
図３は、マスク生成部１１０の動作原理図である。図３において、イニシエータマスクＩＤは２で、マスク対象指定フラグがイニシエータＡとイニシエータＣを有効にしているから、マスク生成部１１０は、イニシエータＡに対してのみマスク信号を出力している。【００３４】
図４は、マスク周期とマスク期間とイニシエータマスクＩＤカウンタ１１２の関係を表した図である。図４において、イニシエータマスクＩＤは２であるから、これに対応したイニシエータ１０２は、図２のマスク条件よりイニシエータＣ以外の全てのイニシエータ１０２である。一方、マスク対象指定フラグが、イニシエータＡとイニシエータＣのみを有効としているため、イニシエータマスクＩＤが２のとき、イニシエータＡのみがマスク対象になる。【００３５】
図５は、マスク対象指定フラグで指定されたイニシエータＡとイニシエータＣについてのタイミングチャートである。図５において、（１）マスク前（マスクを行わなかった場合）では、イニシエータＣがターゲットからリトライ応答を受け続けている。（２）マスク後（マスクを行った場合）で、マスク期間ＴｍがイニシエータＡのリクエスト周期ＴｒｅｑＡより長い場合は、イニシエータＡがマスク期間Ｔｍマスクされることにより、リトライ応答を受け続けてきたイニシエータＣがアクセプトされている。（３）マスク後（マスクを行った場合）で、マスク期間ＴｍがイニシエータＡのリクエスト周期ＴｒｅｑＡより短い場合も、イニシエータＡのリクエスト周期ＴｒｅｑＡの開始時点にマスク期間Ｔｍが重なったとき、イニシエータＡがマスク期間Ｔｍマスクされることにより、リトライ応答を受け続けてきたイニシエータＣがアクセプトされている。なお、（２）や（３）のタイミングチャートは、バス１０４上で計測される信号値を示したものであってもよいし、バスコントローラ１０１内部で計測される信号値を示したものであってもよい。マスク生成部１１０が、各イニシエータ１０２から要求信号（ｒｅｑｕｅｓｔ）が送信されるタイミングが非周期となるように各イニシエータ１０２で生成される要求信号（ｒｅｑｕｅｓｔ）をマスク制御する場合、バス１０４上で計測される信号値もバスコントローラ１０１内部で計測される信号値も（２）や（３）に示したもののようになる。一方、マスク生成部１１０が、バス制御部１２０の内部で要求信号（ｒｅｑｕｅｓｔ）が処理（又は検出）されるタイミングが非周期となるようにバス制御部１２０で各イニシエータ１０２から受信される要求信号（ｒｅｑｕｅｓｔ）をマスク制御する場合、バス１０４上で計測される信号値は（１）に示したもののようになってもバスコントローラ１０１内部で計測される信号値は（２）や（３）に示したもののようになる。【００３６】
以下、バスコントローラ１０１に付加したマスク生成部１１０が、各イニシエータ１０２からのリクエストの発行タイミングを乱すためのマスク信号を生成し、出力する動作について説明する。【００３７】
図６は、バスコントローラ１０１のマスク生成部１１０がマスク信号を出力する一連の動作を表すフローチャートである。【００３８】
ステップＳ１０１では、マスク生成部１１０は、マスク周期を検出するためのマスク周期カウンタと、マスクを行うイニシエータ１０２をマスク周期ごとに変更するイニシエータマスクＩＤカウンタ１１２をリセットし、ステップＳ１０２に進む。ステップＳ１０２では、マスク生成部１１０は、マスク周期カウンタのカウントを開始しステップＳ１０３に進む。ステップＳ１０３では、マスク生成部１１０は、マスク周期カウンタがマスク周期と一致した場合は、ステップＳ１０４に進む。マスク生成部１１０は、マスク周期カウンタがマスク周期と一致しない場合は、マスク周期カウンタをカウントアップする。ステップＳ１０４では、マスク生成部１１０は、イニシエータマスクＩＤカウンタ１１２を１カウントアップし、イニシエータマスクＩＤに対応したイニシエータ１０２の選択信号を出力し、マスク周期カウンタをクリアして再カウントを開始し、ステップＳ１０５に進む。ステップＳ１０５では、マスク生成部１１０は、マスク対象指定フラグが有効でなおかつ、イニシエータマスクＩＤに対応したマスク対象として選択されたイニシエータ１０２のマスクを開始し、マスク期間カウンタによるカウント開始し、ステップＳ１０６に進む。ステップＳ１０６では、マスク生成部１１０は、マスク期間カウンタがマスク期間までカウントしたらマスクを解除し、マスク期間までカウントされていなければマスク期間カウンタを１カウントアップしステップＳ１０７に進む。ステップＳ１０７では、マスク生成部１１０は、マスクを解除し、再びステップＳ１０３に進む。【００３９】
以上のように、本実施の形態によれば、バスコントローラ１０１にマスク生成部１１０を付加し、マスク生成部１１０が、ある周期ごとにマスク対象となるイニシエータ１０２をある期間マスクすることで、複数のイニシエータ１０２から同時あるいは交互に複数のコマンド発行要求（即ち、要求信号（ｒｅｑｕｅｓｔ）の送信）がなされても、各イニシエータ１０２からのコマンド発行要求（即ち、要求信号（ｒｅｑｕｅｓｔ））のタイミングが乱れて、コマンド（ｃｍｄ）の発行周期が一定になることを防ぎ、ターゲット１０３からいつもリトライ応答（ｒｅｔｒｙ）がなされるという状況を回避することが可能となる。【００４０】
以上説明したように、本実施の形態では、複数のイニシエータ１０２とイニシエータ１０２からのコマンドを処理する１つ以上のターゲット１０３と複数のイニシエータ１０２からのリクエストの優先順位制御を行うバスコントローラ１０１を備えるバス通信システム１００において、バスコントローラ１０１が、各イニシエータ１０２からのリクエストの発行タイミングを乱すマスク生成部１１０を有することを特徴とする。マスク生成部１１０が、イニシエータ１０２からのコマンド発行要求（即ち、要求信号（ｒｅｑｕｅｓｔ））をマスクすることによって、イニシエータ１０２からのコマンド発行要求（即ち、要求信号（ｒｅｑｕｅｓｔ））のタイミングが乱れて、ターゲットからのリトライ（ｒｅｔｒｙ）に起因するデッドロックなどを回避することができる。【００４１】
バスコントローラ１０１は、マスク生成部１１０において、マスクを行うタイミングを任意に設定できるマスク周期設定部１１１を有することを特徴とする。これにより、システムに応じたマスク周期を任意に設定できる。【００４２】
バスコントローラ１０１は、マスク生成部１１０において、マスク周期ごとにマスクを行うイニシエータ１０２を決定するマスク条件設定部１１４を有することを特徴とする。これにより、システムに応じてアクセス周期ごとにマスク対象のイニシエータ１０２を任意に設定できる。【００４３】
バスコントローラ１０１は、マスク生成部１１０において、マスク周期ごとにマスク期間を任意に決定するマスク期間設定部１１３を有することを特徴とする。これにより、システムに応じてマスク対象となったイニシエータ１０２のマスク期間を任意に設定できる。【００４４】
バスコントローラ１０１は、マスク生成部１１０において、マスク制御を有効にするか無効にするかを決定するマスク対象指定フラグ設定部１１５を有することを特徴とする。これにより、システムに応じて各イニシエータ１０２のマスクを有効にするか無効にするかを任意に設定できる。【００４５】
バスコントローラ１０１は、マスク生成部１１０において、マスク条件設定部１１４におけるマスク条件をマスク周期ごとに変更するイニシエータマスクＩＤカウンタ１１２を有することを特徴とする。これにより、マスク周期ごとに変更するマスク対象となるイニシエータ１０２を任意に設定できる。【００４６】
このように、本実施の形態によれば、各イニシエータ１０２が同時あるいは交互に複数のリクエストを発行し、各イニシエータ１０２がバス権を交互に与えられ、均一にコマンドを発行するようなケースが発生した場合に、イニシエータ１０２によっては、アクセスしたいターゲットが、いつも別のイニシエータ１０２からのコマンドの処理中で毎回リトライすることになり、コマンドが受け付けられない状態でも、リクエストの発行タイミングを乱すことによって、コマンド要求が受け付けられるようになる。【００４７】
実施の形態２．
本実施の形態について、主に実施の形態１との差異を説明する。【００４８】
実施の形態１では、マスク条件設定部１１４は、単にマスク制御の対象とするイニシエータ１０２の組み合わせをマスク条件として設定していたが、本実施の形態では、マスク条件設定部１１４は、コマンド信号（ｃｍｄ）の種別ごとにマスク制御の対象とするイニシエータ１０２をマスク条件として設定する。具体的には、マスク条件設定部１１４は、コマンド信号（ｃｍｄ）がデータバスにおけるリード動作を伴う処理の実行を指令するものである場合と、コマンド信号（ｃｍｄ）がデータバスにおけるライト動作を伴う処理の実行を指令するものである場合とに分けて、マスク制御の対象とするイニシエータ１０２の組み合わせをマスク条件として設定する。なお、コマンド信号（ｃｍｄ）の種別としては、リード／ライト以外の分け方を用いてもよい。例えば、マスク条件設定部１１４は、コマンド信号（ｃｍｄ）がデータバスにおけるシングル転送動作を伴う処理の実行を指令するものである場合と、コマンド信号（ｃｍｄ）がデータバスにおけるバースト転送動作を伴う処理の実行を指令するものである場合とに分けて、マスク制御の対象とするイニシエータ１０２の組み合わせをマスク条件として設定してもよい。【００４９】
ここで、マスク条件の設定例を図７に示す。図７は、リード系とライト系のコマンド発行要求（即ち、要求信号（ｒｅｑｕｅｓｔ））を個別にマスクするためのマスク条件設定を表している。イニシエータマスクＩＤの０から９までがリード系、イニシエータマスクＩＤの１０から１９までがライト系のコマンド発行要求（即ち、要求信号（ｒｅｑｕｅｓｔ））をマスクするマスク条件である。【００５０】
本実施の形態において、マスク生成部１１０の構成や動作については、実施の形態１と同様であるため、説明を省略する。【００５１】
以上のように、本実施の形態によれば、マスク条件によってマスク対象をイニシエータ１０２のリード及びライトのいずれか一方に限定することで（さらに、リード及びライトの両方を対象とするマスク条件を加えてもよい）、マスク制御が細かく行えるようになり、無駄なマスクを減らしながら各イニシエータ１０２からのコマンド発行要求（即ち、要求信号（ｒｅｑｕｅｓｔ））のタイミングを乱して、コマンド（ｃｍｄ）の発行周期が一定になることを防ぎ、ターゲット１０３からいつもリトライ応答（ｒｅｔｒｙ）がなされるという状況を回避することが可能となる。【００５２】
以上説明したように、本実施の形態では、マスク条件設定部１１４において、マスク条件をリード又はライト（又はリードとライト両方）について指定したものを別々に用意し、それらのマスク条件を順番に切り替えて使用することを特徴とする。これにより、マスク対象を細かく変化させることができるため、必要以上にマスクを行ってしまうという事態を避けることができる。【００５３】
実施の形態３．
本実施の形態について、主に実施の形態１との差異を説明する。【００５４】
実施の形態１では、マスク期間設定部１１３で設定するマスク期間はマスク条件によらず共通であったが、本実施の形態では、イニシエータマスクＩＤごとにマスク期間を設定する。【００５５】
図８は、イニシエータマスクＩＤに対応したマスク期間Ｔｍ０からＴｍ９までのいずれかが設定されるマスク生成部１１０の動作原理図である。図８において、イニシエータマスクＩＤは２であるから、マスク期間設定部１１３ではマスク期間Ｔｍ２が設定される。【００５６】
図９は、イニシエータマスクＩＤごとにマスク期間が設定される場合の、マスク周期とマスク期間とイニシエータマスクＩＤカウンタ１１２の関係を表した図である。図９において、イニシエータマスクＩＤが２のとき、マスク期間はＴｍ２となる。このように、マスク周期ごとに、イニシエータマスクＩＤによってマスク期間が変化する。【００５７】
以下、バスコントローラ１０１に付加したマスク生成部１１０が、各イニシエータ１０２からのリクエストの発行タイミングを乱すためのマスク信号を生成し、出力する動作について説明する。【００５８】
図１０は、バスコントローラ１０１のマスク生成部１１０がマスク信号を出力する一連の動作を表すフローチャートである。【００５９】
ステップＳ２０１からステップＳ２０４までは図６のステップＳ１０１からステップＳ１０４と同じであるため説明を省略する。ステップＳ２０５では、マスク生成部１１０は、マスク対象指定フラグが有効でなおかつ、イニシエータマスクＩＤに対応したマスク対象として選択されたイニシエータ１０２のマスクを開始し、イニシエータマスクＩＤごとに用意されたマスク期間をマスク期間カウンタに設定してカウント開始し、ステップＳ２０６に進む。ステップＳ２０６とステップＳ２０７は、図６のステップＳ１０６とステップＳ１０７と同じであるため説明を省略する。【００６０】
以上のように、本実施の形態によれば、イニシエータマスクＩＤごとに、マスク期間を設定することで、マスク制御が細かく行えるようになり、無駄なマスクを減らしながら各イニシエータ１０２からのコマンド発行要求（即ち、要求信号（ｒｅｑｕｅｓｔ））のタイミングを乱して、コマンド（ｃｍｄ）の発行周期が一定になることを防ぎ、ターゲット１０３からいつもリトライ応答（ｒｅｔｒｙ）がなされるという状況を回避することが可能となる。【００６１】
以上、本発明の実施の形態について説明したが、これらのうち、２つ以上の実施の形態を組み合わせて実施しても構わない。あるいは、これらのうち、１つの実施の形態を部分的に実施しても構わない。あるいは、これらのうち、２つ以上の実施の形態を部分的に組み合わせて実施しても構わない。
【図面の簡単な説明】
【００６２】
【図１】実施の形態１に係るバス通信システムの構成を示すブロック図である。
【図２】実施の形態１に係るマスク条件の設定例を示す表である。
【図３】実施の形態１に係るマスク生成部の動作原理図である。
【図４】実施の形態１に係るマスク周期とマスク期間とイニシエータマスクＩＤカウンタの関係を表した図である。
【図５】実施の形態１に係るマスク対象指定フラグで指定されたイニシエータについてのタイミングチャートである。
【図６】実施の形態１に係るマスク生成部の動作を示すフローチャートである。
【図７】実施の形態２に係るマスク条件の設定例を示す表である。
【図８】実施の形態３に係るマスク生成部の動作原理図である。
【図９】実施の形態３に係るマスク周期とマスク期間とイニシエータマスクＩＤカウンタの関係を表した図である。
【図１０】実施の形態３に係るマスク生成部の動作を示すフローチャートである。
【図１１】一般的なデータバスシステムの構成を示すブロック図である。
【符号の説明】
【００６３】
１００  バス通信システム、１０１  バスコントローラ、１０２  イニシエータ、１０３  ターゲット、１０４  バス、１１０  マスク生成部、１１１  マスク周期設定部、１１２  イニシエータマスクＩＤカウンタ、１１３  マスク期間設定部、１１４  マスク条件設定部、１１５  マスク対象指定フラグ設定部、１２０  バス制御部、２０１  ＣＰＵ、２０２  メモリ。
【図１】
2010021054.tif 000003
【図２】
2010021054.tif 000004
【図３】
2010021054.tif 000005
【図４】
2010021054.tif 000006
【図５】
2010021054.tif 000007
【図６】
2010021054.tif 000008
【図７】
2010021054.tif 000009
【図８】
2010021054.tif 000010
【図９】
2010021054.tif 000011
【図１０】
2010021054.tif 000012
【図１１】
2010021054.tif 000013
【国際調査報告】
2010021054.tif 000014
2010021054.tif 000015