JP4410270B2 - バス制御装置 - Google Patents

Description

本発明は、バス制御装置に関し、特に、バスを介して、メモリに対してデータを書き込むためのライトコマンド信号を出力する１以上のブロックを含むバス制御装置に関する。

従来より、バスを介して機能ブロック間でデータの送受信を行う装置が知られている。最近では、例えば、SoC（システムオンチップ）上の複数のブロックが、システムバスを経由して、そのチップに接続された共有メモリを介して、データの送受信が行われている。

例えば、あるブロックAが、他のブロックBにデータを転送する場合、そのブロックAは、共有メモリにデータを転送して書き込みを行い、データ転送が終了すると、ブロックBにデータ転送の終了を通知する。ブロックBは、共有メモリの、そのデータが書き込まれた記憶領域からデータを転送することによって、ブロックAからのデータを読み出すことができる。

そして、データの一貫性の必要性から、これらのデータ転送の各段階の動作が終了してから、次の段階の処理が行われることが、このような共有メモリの構造におけるデータ転送の前提となっている。なお、データの送受信が行われるバスは、共有型のバスでもポインツ・トゥ・ポインツ（point-to-point）型のバスでもよい。

一方、近年のバスアーキテクチャにおいては、バスの効率を向上させるためにバスへのライトとしてポステドライト（posted write）方式を標準のライトとするバスプロトコルが主流となっている。すなわち、ポステドライト（posted write）方式により、各ブロックが共有メモリにライトをする際には、各ブロックは、バスに対してライトのコマンドとライトのデータを渡し終わった時点で、書き込み処理の終了とする。そのデータが実際にメモリにライトされるのは、バスおよびメモリ(コントローラ含む)がライト可能な時点である。

しかし、ポステドライト（posted write）方式を使用するようなバスにおいて、上述のような手順によるデータのやり取りをする際には注意を要する。すなわちポストされたライトが共有メモリにまで到達した後に、他のブロックBによるリードを実施しないと正しいリードデータが得られないという、メモリの一貫性、コヒーレンシ(Coherency)の問題がある。

一般に、データのコヒーレンシを保つ手段としては、バスプロトコルによる方法、ハードウエア(以下、HWとも略す)実装による方法、及びソフトウエア(以下、SWとも略す)実装による方法、あるいはSWとHWの両面の実装による方法が既に実現されている。

バスプロトコルによる方法の場合、他ブロックとの共有に使用されるライトにはノンポステドライト（Non-posted）型のライトを使用する方法がある。
しかし、バスプロトコルによる方法の場合、そのプロトコルを実行するためのHWの実装が複雑になるという問題がある。一般に、ポステドライト（Non-posted）型のライトの実装は、ポステドライト（posted write）方式の実装より複雑になる。さらに、HWの性能、特にスループット及び動作周波数の点におけるオーバーヘッドが問題になる場合もある。

また、ハードウエア実装による方法の場合、すべてのライト／リードのアドレスの依存関係を検出して必要に応じてリードを待たせるアドレスインタロック技術がある。例えば、データの書き込まれたアドレスとは関係のないアドレスに対するリードであれば、リードを待たせる必要はないが、データの書き込まれたアドレスとは関係のあるアドレスに対するリードであれば、リードを待たせる必要がある。そこで、アドレスインタロック技術によれば、ライト／リードのアドレスの依存関係を検出して、リードを待たせるか否かが決定される。

しかし、HW実装による方法の場合、その実装が複雑になるという問題がある。さらに、一般的な共有バスにおいて、異なるブロック間のトランザクションは通常は関係がない部分がほとんどである。従って、すべてのトランザクションでアドレスインタロックをかけると、性能、特にスループット及び動作周波数の面で問題もある。

また、ソフトウエア実装による方法の場合、ライトを確定させるために、データをライトしたデータ供給側のブロックがダミーのリードを発行する技術が提案されている（例えば、特許文献１参照）。その提案に係る技術は、ポステドライト（posted write）方式を使用するバスプロトコルにおいては、同一のブロックによるリードが発行された場合にはその発行以前のライトは必ず終了するという制約があるものを、前提とするものである。

しかし、ソフトウエア実装による方法の場合、一般に極めて複雑な処理になる場合があるという問題がある。そのため、例えば、SoCのチップを提供するベンダが、ソフトウエアの実装を顧客に委ねる場合、顧客に、そのような複雑な処理となるソフトウエアの実装が受け入れられない可能性もある。
特開2002-82901号公報

そこで、本発明は、ポステドライト（posted write）方式を使用した場合であっても、ハードウエア実装の面で複雑な回路を用いず、かつソフトウエアの面でも簡単な処理で、書き込みデータのコヒーレンシを保つことができるバス制御装置を提供することを目的とする。

本発明の一態様によれば、バスを介して、メモリに対してデータを書き込むためのライトコマンド信号を出力する１以上のブロックと、前記ブロックに対応して設けられ、前記バスと前記ブロックとの間の信号線の信号を監視して、前記ブロックの所定のレジスタのデータを読み出すためのリードコマンド信号を検出すると前記ブロックと前記バスとの間の信号線の接続を遮断し、前記メモリへのダミーリードコマンド信号を出力し、かつ、前記ダミーリードコマンド信号に対するレスポンス信号を受信すると前記遮断を解除するバス接続制御部とを有するバス制御装置を提供することができる。

本発明によれば、ポステドライト（posted write）方式を使用した場合であっても、ハードウエア実装の面で複雑な回路を用いず、かつソフトウエアの面でも簡単な処理で、書き込みデータのコヒーレンシを保つことができる。

以下、図面を参照して本発明の実施の形態を説明する。
まず図１に基づき、本実施の形態に係わるバス制御装置の構成を説明する。図１は、本実施の形態に係わるバス制御装置の構成を示すブロック図である。
図１に示すように、バス制御装置１は、バス制御用の中央処理装置（以下、制御CPUという）１１と、割込コントローラ１２と、それぞれが所定の処理を行う機能ブロックである複数のブロック１３と、システムバスであるバス１４と、共有メモリ１５と、複数のブロック１３のそれぞれとバス１４との間に設けられたバス接続制御部１６とを有して構成される。ブロック１３は、ｎ個（ｎは正の整数）あり、それぞれがバス接続制御部１６を介して、バス１４に接続されている。図１のバス制御装置１は、例えば、半導体装置である半導体チップ上に半導体回路として形成される。

また、複数のブロック１３は、割込コントローラ１２とは、専用の信号線１８によって接続されている。制御CPU１１と割込コントローラ１２は、それぞれバス１４と接続されており、かつ制御CPU１１と割込コントローラ１２も、別途信号線１９によって接続されている。そして、制御CPU１１と割込コントローラ１２も、バス１４を介して、互いにデータの送受信を行うことができる。後述するように、各ブロック１３は、共有メモリ１５にデータの書き込み（以下、ライトともいう）を行うと、信号線１８を介して割込コントローラ１２に割込信号を出力する。割込コントローラ１２は、割込信号を受信すると、制御CPU１１に割込発生を通知するための信号を、信号線１９を介して出力する。

複数のブロック１３は、それぞれ所定の処理を行う機能ブロックであるが、例えば、コアCPU、ROM、ハードディスク駆動装置（HDD）、DMAC、ネットワークコントローラ、各種インターフェース等の機能を有するものである。なお、ブロックの機能によっては、バス接続制御部１６を介さずに、ブロック１３とバス１４が直接接続されていてもよい。例えば、ハードウエアタイマ等の機能ブロックであれば、バス接続制御部１６を介さずに、ブロック１３はバス１４に接続される。
なお、本実施の形態では、バス制御装置１はSoCとして実現されており、共有メモリ１５は、SoC上に設けられていてもよいし、SoCに接続されるものであってもよい。

図２は、バス制御装置１におけるデータの転送処理の流れを説明するためのシーケンス図である。図２は、異なるブロック間において共有メモリを介してデータが転送される場合に、データを転送するブロックがポステドライト（posted write）方式を使用してデータをライトした後に、データが転送される他のブロックにデータのライトを通知し、その通知後に、他のブロックがデータを読み出す（以下、リードともいう）をする、という処理の流れをより詳細に示すものである。以下、複数のブロック１３中のブロックB1からブロックB2へ、データが転送される場合を例にして説明する。

図２に示すように、まず、ブロックB1が、ブロックB2にリードさせるデータを、ポステドライトによって共有メモリ１５の所定のアドレスに対して書き込みが行われる（ステップS1）。その書き込み処理が終了すると、ブロックB1は、割込信号を割込コントローラ１２へ出力する。
割込コントローラ１２は、割込信号を受信すると、割込信号が発生したことを、制御CPU１１に通知し、制御CPU１１は、所定の割込ハンドラ処理を実行する（ステップS2）。

割込ハンドラ処理では、割込に係るブロックを特定するためのブロック特定処理（ステップS21）と、割込原因を特定するための原因特定処理（ステップS22）とが行われる。
割込に係るブロックの特定（ステップS21）では、制御CPU１１が、バス１４を介して、割込コントローラ１２内の、割込信号に係る所定のレジスタの内容を読み出すことにより、割込信号を出力したブロックの特定が行われる。図１の矢印C1は、制御CPU１１が、割込コントローラ１２の所定のレジスタの内容を読み出すことを示している。

ステップS21において割込信号を発生したブロックが特定されると、ステップS22では、制御CPU１１は、バス１４を介して、その特定されたブロック内の所定の内部レジスタを参照することにより、割込原因を特定する。ここでは、ブロックB1が割込信号を出力したことが特定され、続いて、ブロックB1の所定の内部レジスタの内容を読み出すことによって割込の原因（ブロックB2へのデータの転送があったこと）が特定される。図１の矢印C2は、制御CPU１１が、ブロックB1の所定のレジスタの内容を読み出すことを示している。
言い換えると、制御CPU１１は、割込信号によって、ブロックB2へのデータ転送のための共有メモリ１５に対するデータの書き込み処理が終了したことを判定することができる。

そして、制御CPU１１は、ブロックB2へデータ転送があったことを通知する（ステップS3）。
その通知を受けると、ブロックB2が、共有メモリ１５からデータをリードするためのコマンド信号を発行する（ステップS4）。ブロックB2が、データを受信すると、リード処理が終了する。以上により、ブロックB1からB2へのデータ転送が行われる。

図３から図８は、ブロックとバスの間の信号を、スルーし、あるいは遮断したりするバス接続制御部１６の機能を説明するための図である。後述するように、バス接続制御部１６は、ブロックB1が共有メモリ１５に書き込んだデータを確定するために、トリガ信号が発生したら、ダミーリード信号を発行し、ダミーリードを発行している間は、ブロックB1とバス１４の間を遮断し、ダミーリードに対するレスポンスが返ってきたら、スルーにする。
図３から図８に示すように、バス接続制御部１６は、バス１４からブロックB1への信号及びブロックB1からバス１４への信号の流れを制御する。

一般に、異なるブロック間において、相手のブロックに対して、所定の通知をするためのトリガ信号として使用されるのは、割込信号である。従って、データ転送においてその転送の通知をするときに、割込信号が利用される。複数の割込信号には、通常、原因が、それぞれ複数設定されている。割り込みの原因となったブロック、すなわち割込信号を発生したブロックが特定されると、さらに、原因を特定するために、ブロックの内部レジスタ、すなわち割込の要因を示すレジスタの参照を行うことは、SW実装において一般的に行われている。

本実施の形態においても、その意味においては、ブロックB1が割込信号を発生したときに、ブロックB1の内部の要因レジスタが参照されるということは、一般的である。よって、要因レジスタの参照処理自体は、SWの実装面におけるオーバーヘッドとは見なされないという点に着目し、本実施の形態に係るバス制御装置１は、異なるブロック間のデータの共有、あるいはデータの転送において、割込信号による通知を行うシステム構成を前提としている。そして、所定の条件で、各ブロック１３はバス１４との接続関係において、ブロック１３とバス１４の両者間において、信号を遮断することができる機構を有するバスアーキテクチャを利用している。

このような機構を、以下、ダミーリードパッキングという。
以下、そのダミーリードパッキングの動作について説明する。
図３に示すように、通常状態では、ブロックB1とバス１４の間で信号の送受信は可能となっている。図３では、矢印A1がブロックB1とバス１４の間で双方向に信号が通ることを示している。すなわち、通常状態では、ブロックB1とバス１４の間は、バスプロトコルの信号はスルーの状態である。

しかし、一旦、上述したステップ制御CPU１１からブロックB1の所定の内部レジスタ（以下、要因レジスタという）のデータを読み出す信号（以下、要因レジスタリードコマンド）を受信すると、バス接続制御部１６は、以下に説明する所定の処理を実施するために、ブロックB1とバス１４の間の信号を遮断する。
なお、要因レジスタリードコマンドの検出は、コマンドとアドレスを監視することによって行われるが、具体的には、要因レジスタリードコマンドの検出は、コマンドがリードコマンドであり、かつそのリードのデータのアドレスが所定のアドレスであるか否かによって、行われる。

要因レジスタリードコマンドRRCは、図４に点線で示すように、バス接続制御部１６に受信され、バス接続制御部１６を通して、バス１４からブロックB1に供給される。バス接続制御部１６は、要因レジスタリードコマンド信号RRCを受信すると、図５に示すように、レジスタリードコマンド信号RRCはトリガ信号であるため、ブロックB1とバス１４間の信号の通過を遮断する。ブロックB1とバス１４間の信号の遮断は、ブロック１３とバス１４との間のバスの信号の流れを遮断することによって行われる。以上のように、要因レジスタリードコマンドRRCを受信すると、バス接続制御部１６は、要因レジスタリードコマンドをトリガ信号として、そのブロックとバス１４の間の信号を遮断する。

なお、遮断は、ブロック１３とバス接続制御部１６間、及びバス接続制御部１６とバス１４間においてバスプロトコル違反はない状態で行われる。例えば、バス接続制御部１６は、ビジー状態であるときは遮断せず、ビジー状態でないときに遮断する、というような条件を満たしながら、遮断を行う。

上述したように、バス接続制御部１６は、要因レジスタリードコマンドRRCである否かは、ブロックB1の所定の要因レジスタへのリードを要求するコマンドであるか否かによって、信号の流れを遮断するトリガ信号であるか否かの判断を行う。

もしも、その所定の要因レジスタへのリード要求でないコマンド（すなわち要因レジスタリードコマンドRRCでないコマンド）の場合は、バス接続制御部１６は、信号の遮断は行わない。

バス接続制御部１６は、トリガ信号を受信した場合には、要因レジスタリードコマンドRRCに対する要因レジスタリードに対するレスポンス信号（以下、レジスタリードレスポンスという）RRRを保留する。すなわち、ブロックB1は、要因レジスタリードコマンドRRCに対する、要因レジスタのデータを制御CPU１１へ返送するために、レジスタリードレスポンスRRRの送信を行うが、バス接続制御部１６は、その送信を保留する。
この保留は、例えば、バス接続制御部１６が、制御CPU１１あるいはバス１４がデータの受信をできない状態にあることを示す信号（以下、受信不可信号という）NRを、ブロックB1へ出力することによって行うことができる。このとき、バス接続制御部１６は、ブロックB1に対しては、制御CPU１１があるいはバス１４があたかもデータの受信ができないことを通知しているかの如く振る舞うことを意味する。他方、バス接続制御部１６は、制御CPU１１に対しては、ブロックB1がなかなか要因レジスタのデータを含むレジスタリードレスポンスRRRを送信してきていないように振る舞うことを意味する。
なお、保留の状態のとき、すなわちバス接続制御部１６が、制御CPU１１あるいはバス１４がデータの受信をできない状態にあることを、受信不可信号NRを供給することによってブロックB1に通知している状態のとき、ブロックB1は、レジスタリードレスポンスRRRを出し続ける。

次に、ブロックB1に接続されたバス接続制御部１６は、その要因レジスタについてのレジスタリードレスポンスRRRを保留している間に、バス１４を介して、共有メモリ１５に対して、図６に示すように、ダミーリードのためのコマンド信号（以下、ダミーリードコマンドという）DRCを発行する。ダミーリードコマンドDRCは、ブロックB1から共有メモリ１５のいずれかのアドレスのデータを読み出すためのコマンドである。ダミーリードコマンドDRCは、共有メモリ１５に供給され、共有メモリ１５は、そのデータ（レスポンス信号）D1をブロックB1へ返送する。共有メモリ１５は、ダミーリードコマンドDRCが、どこから送信されたか否かに関係なく、そのデータを、バス１４に出力する。

なお、ダミーリードコマンドDRCは、ブロックB1から共有メモリ１５のいずれかのアドレスのデータを読み出すためのコマンドであればよいので、ダミーリードコマンドDRCによって読み出されるデータは、ブロックB1がブロックB2へデータ転送するために書き込んだデータでなくでもよい。すなわち、ブロックB1からの共有メモリ１５中のいずれかのアドレスのデータを読み出すためのコマンドであればよい。

バス接続制御部１６は、図７に示すように、自己が送信したダミーリードコマンドDRCに対するレスポンス信号D1を受信すると、ブロックB2に転送するためにブロックB1が出力したデータが、共有メモリ１５に確実に書き込まれたと判定する。従って、バス接続制御部１６は、ダミーリードに対応するレスポンス信号D1を受信すると、図８に示すように、ブロックB1とバス１４間の信号の遮断を解除する。

なお、バス１４からダミーリードコマンドDRCに対するレスポンス信号D1が返ってくるが、このレスポンス信号D1はブロックB1に供給されず、ここでは、何ら使用されることなく、レスポンス信号D1は、廃棄される。

以上のように、ダミーリードコマンドDRCのレスポンス信号D1が返ってくると、バス接続制御部１６は、ブロックB1とバス１４間の接続を回復する。その接続が回復されると、それまで保留されていたレジスタリードレスポンスRRRが、バス接続制御部１６を介して、制御CPU１１に供給される。その結果、図２の割込ハンドラ処理（ステップS2）が終了するので、制御CPU１１は、ブロックB2へ、ブロックB1からのデータ転送があったことをブロックB2へ通知する（ステップS3）。そして、ブロックB2がブロックB1の書き込んだデータを共有メモリ１５から読み出すことによって、ブロックB1からブロックB2へのデータ転送が終了する。

次に、上述したバス接続制御部１６の構成について説明する。図９は、本実施の形態に係わるバス接続制御部１６の構成を説明するための図である。
図９に示すように、ブロック１３とバス１４とはバス接続されているが、バス接続制御部１６が、ブロック１３とバス１４の間に設けられている。バス接続制御部１６は、複数のマルチプレクサ（MUX）を含んで構成されている。複数のマルチプレクサ（MUX）は、ブロック１３からの信号をバス１４へ供給するためのマルチプレクサ群１６Aと、バス１４からの信号をブロック１３へ供給するためのマルチプレクサ群１６Bとを含んで構成されている。さらに、バス接続制御部１６は、リードコマンド検出部を有するトリガ信号検出部２１と、レスポンス信号検出部２２と、トリガ信号検出部２１からの信号及びレスポンス信号検出部２２からの信号に応じて、各マルチプレクサ（MUX）を制御するために、制御信号としての切換信号を出力する制御部２３を含む。

各マルチプレクサは、２つの入力部のうち一方を選択して出力部に出力する回路である信号切換部である。マルチプレクサ群１６Aの各マルチプレクサは、ブロック１３からの信号とレジスタ３１からの信号とを入力して、制御部２３からの切換信号SW1に基づいて、いずれか一方を選択して、バス１４へ供給する、複数のマルチプレクサ３２を含む。マルチプレクサ群１６Bの各マルチプレクサは、バス１４からの信号とレジスタ３３からの信号とを入力して、制御部２３からの切換信号SW2に基づいて、いずれか一方を選択して、ブロック１３へ供給する、複数のマルチプレクサ３４を含む。

上述した通常状態では、信号切換部としての、マルチプレクサ群１６Aの各マルチプレクサ３２は、ブロック１３からの信号をそのままバス１４へ供給するように、ブロック１３からの信号を選択して出力する状態になっている。同様に、通常状態では、信号切換部としての、マルチプレクサ群１６Bの各マルチプレクサ３４は、バス１４からの信号をそのままブロック１３へ供給するように、バス１４からの信号を選択して出力する状態になっている。

トリガ信号検出部２１は、バス１４からの所定の信号を監視し、上述した要因レジスタリードコマンドRRCを受信したか否かを判定するリードコマンド検出部を構成する。トリガ信号検出部２１は、マルチプレクサ群１６Bに入力される信号線の中の要因レジスタリードコマンドRRCを検出することができる信号線の信号を監視することによって、要因レジスタリードコマンドRRCを受信したか否かを判定する。トリガ信号検出部２１は、要因レジスタリードコマンドRRCを受信したことを検出すると、要因レジスタリードコマンドRRCを受信したことを示すRRC受信信号を制御部２３へ出力する。

レスポンス信号検出部２２は、バス１４からの信号を監視し、ダミーリードコマンドDRCに対するレスポンス信号D1を受信したか否かを判定する。レスポンス信号検出部２２は、マルチプレクサ群１６Bに入力される信号線の中のレスポンス信号D1を検出することができる信号線の信号を監視することによって、レスポンス信号D1を受信したか否かを判定する。レスポンス信号検出部２２は、レスポンス信号D1を受信したことを検出すると、レスポンス信号D1を受信したことを示すD1受信信号を制御部２３へ出力する。

制御部２３は、その要因レジスタリードコマンドRRCが入力されると、マルチプレクサ群１６Aの各マルチプレクサ３２に対してレジスタ３１の出力を選択し、ブロック１３からバス１４への信号を遮断する切換信号SW1を出力する。よって、制御部２３と各マルチプレクサ３２も、遮断部を構成する。また、この切換信号SW1に応じて、各マルチプレクサ３２がレジスタ３１からのデータ信号を選択することによって、バス接続制御部１６は、ダミーリードコマンドDRCを生成して、バス１４へ出力することができる。よって、制御部２３、各マルチプレクサ３２及び各レジスタ３１が、ダミーリードコマンド信号生成部を構成する。

また、制御部２３は、要因レジスタリードコマンドRRCが入力されると、マルチプレクサ群１６Bの所定のマルチプレクサ３４に対してレジスタ３３の出力を選択し、バス１４からブロック１３への信号を遮断するための切換信号SW2を出力する。よって、制御部２３と各マルチプレクサ３４が、遮断部を構成する。この切換信号SW2に応じて、所定のマルチプレクサ３４がレジスタ３３からのデータ信号を選択することによって、バス接続制御部１６は、受信不可信号NRを生成して、ブロック１３へ出力することができる。よって、制御部２３、各マルチプレクサ３４及び各レジスタ３３が、受信不可信号生成部を構成する。

さらに、制御部２３は、D1受信信号が入力されると、マルチプレクサ群１６Aの所定のマルチプレクサ３２に対してブロック１３からの信号を選択してバス１４へ出力する切換信号SW1を出力する。この切換信号SW1に応じて、所定のマルチプレクサ３２がブロック１３からのデータ信号を選択することによって、バス接続制御部１６は、ブロック１３からバス１４への信号をスルーの状態に戻すことができる。

同様に、制御部２３は、D1受信信号が入力されると、マルチプレクサ群１６Bの各マルチプレクサ３４に対してバス１４からの信号を選択してブロック１３へ出力する切換信号SW2を出力する。この切換信号SW2に応じて、各マルチプレクサ３４がバス１４からのデータ信号を選択することによって、バス接続制御部１６は、バス１４からブロック１３への信号をスルーの状態に戻すことができる。

遮断状態では、マルチプレクサ群１６Aの所定のマルチプレクサ３２は、接続されているレジスタ３１からのデータの信号をバス１４へ供給するように、レジスタ３１からの信号を選択して出力する状態になっている。同様に、遮断状態では、マルチプレクサ群１６Bの所定のマルチプレクサ３４は、接続されているレジスタ３３からのデータの信号をブロック１３へ供給するように、レジスタ３３からの信号を選択して出力する状態になっている。

従って、上述した遮断状態において、バス接続制御部１６が、受信不可信号NRを出力するが、その受信不可信号NRは、レジスタ３３からのデータ信号によって生成される。同様に、遮断状態において、バス接続制御部１６が、ダミーリードコマンドDRCを出力するが、ダミーリードコマンドDRCは、レジスタ３１からのデータ信号によって生成される。

なお、各レジスタ３１，３３の内容は、外部から設定できるように構成されている。また、各マルチプレクサは、遮断状態のときに、対応するレジスタ３１，３３の内容を出力するが、ダミーリードコマンドDRCあるいは受信不可信号NRに関係しないレジスタは、信号を出力しないようにマスクされる。

さらになお、バス接続制御部１６は、トリガ信号検出部２１，レスポンス信号検出部２２，制御部２３等で実現しているが、各種信号線、各種レジスタ等の内部状態に応じて動作するステートマシンによって実現してもよい。

以上説明した実施の形態に係るデータ転送装置によれば、ポステドライト（posted write）方式を使用しながら、ハードウエア実装の面で複雑な回路を用いず、かつソフトウエアの面でも簡単な処理で、転送データのコヒーレンシを保つことができる。すなわち、あるブロックがライトしたデータを、別のブロックがリードする際に、それらのコマンドの順番は100% 保証される。
特に、上述した実施の形態によれば、割込処理も従来行われていた割込処理と同様の処理であるため、HW及びSWの構成も簡単な構成となる。

よって、上述した実施の形態によれば、HWとSWの実装の難易度を上げることなく、かつ大幅な性能劣化を伴わずに、異なるブロックが共有メモリを介してデータをやりとりするための、コヒーレンシの確保のためのバス制御のアーキテクチャを実現することができる。
また、上述した実施の形態によれば、使用するバスプロトコル自体も、特別なものではないのではなく一般的なものを使い、かつブロック自体に変更が加える必要がないため、既存のIPに対する適用も容易に実施することができる。

次に、上述した実施の形態の変形例に係るブロックの構成について説明する。
図１０は、ブロック１３の変形例を説明するための図である。バスの構成によっては、コマンドあるいはデータの入出力の信号線が、予め決められている場合がある。図１０は、そのような場合において、ブロック１３Aが、マスタインターフェース（以下、マスタI/Fと略す）４１とスレーブインターフェース（以下、スレーブI/Fと略す）とを有する場合のブロックの構成を説明するための図である。このようなマスタI/FとスレーブI/Fとを有する構成は、例えば、標準化団体であるOCP-IP（Open Core Protocol International Partnership）が策定したOCP2.0等の規格に準拠した構成である。

それぞれが図１０に示すような構成を有する複数のブロックが、バス１４に接続されてデータ転送等を行う。バス１４に接続された各ブロックは、マスタI/FとスレーブI/Fとを有する。なお、バス１４に接続された複数のブロックの中には、ブロックの機能によっては、マスタI/Fだけを有し、スレーブI/Fを有しないブロック、あるいはスレーブI/Fだけを有し、マスタI/Fを有しないブロックがあってもよい。

マスタI/F４１は、他のブロックのスレーブI/F４２に対するコマンドを出力するためのインターフェースである。例えば、マスタI/F４１は、ライトあるいはリードのコマンドを出力し、ライトデータを出力し、あるいはリードデータを入力する。スレーブI/F４２は、他のブロックのマスタI/F４１からのコマンドを入力するためのインターフェースである。例えば、スレーブI/F４２は、リードコマンドを受信して、リードデータを出力する。そして、上述したバス接続制御部１６は、マスタI/F４１とスレーブI/F４２の２つのインターフェースと、バス１４との間に設けられる。

従って、図１０のブロック１３Aのような構成において、スレーブI/F４２を介して受信される要因レジスタリードコマンド信号RRCが、トリガ信号として、バス接続制御部１６によって検出されると、バス接続制御部１６は、バス１４とスレーブI/F４２との間のコマンド及びデータの入出力の経路と、マスタI/F４１とバス１４との間のコマンド及びデータの入出力の経路を、それぞれ遮断する。
その遮断により、バス接続制御部１６は、要因レジスタリードコマンド信号RRCに対応する、マスタI/F４１からのレジスタリードレスポンスRRRを保留する。

さらに、バス接続制御部１６は、その遮断後、ダミーリードコマンドDRCを共有メモリ１５に出力する。バス接続制御部１６は、ダミーリードコマンドDRCに対応するレスポンス信号D1を受信すると、そのレスポンス信号D1を廃棄し、上述の遮断を解除する。その解除により、マスタI/F４１とバス１４の間、及びスレーブI/F４２とバス１４の間の信号の経路はスルー状態になるので、スレーブI/F４２からのレジスタリードレスポンスRRRは、バス１４に出力される。その結果、ブロック１３Aから出力されたデータが共有メモリ１５に確実に書き込まれたことが保証されるので、制御CPU１１は、転送データの転送先であるブロックに、ブロック１３Aからのデータ転送があったことを通知する。その結果、転送先のブロックが、ブロック１３Aの書き込んだデータを共有メモリ１５から読み出すことによって、ブロック１３Aからのデータ転送が終了する。

さらになお、図１１に示すように、各ブロックは、複数のマスタI/F４１と１つのスレーブI/F４２を有するものであってもよい。図１１は、ブロック１３のさらなる変形例を示す
図である。
さらになお、本実施の形態のバス制御装置は、図１２に示すようにバスが複数あるシステムにおいても、適用可能である。図１２は、複数のブロックがそれぞれ対応するバスに接続された、複数のバスプロトコルを有するバスアークテクチャを示すブロック図である。

図１２において、複数のブロック１３がバスXに接続され、他の複数のブロック１３はバスYに接続され、さらに他のブロック１３がバスZに接続されている。
バスXとバスYは、バスブリッジであるX-Yブリッジによって接続されている。バスYとバスZは、バスブリッジであるY-Zブリッジによって接続されている。
各ブロック１３と対応するバスは、上述したバス接続制御部１６を介して接続されている。

図１２においても、各ブロック１３と各バスの間に設けられたバス接続制御部１６は、所定の要因レジスタリードコマンドRRCを検出すると、接続されたブロックとバスとの間のデータの送受信を遮断し、遮断している間に、ダミーリードコマンドDRCを発行し、ダミーリードコマンドDRCに対するレスポンス信号D1が返ってくると、上記の遮断を解除する、という一連の処理を行う。
図１２に示すように、３つのバスX,Y,Zを互いにブリッジにより接続するようなバスアーキテクチャにおいて、例えばバスXに接続されたブロックBAが実行する共有メモリ１５Aに対するライトを確定させる場合、ブロックBAとバスXに依存するダミーリードパッキング処理が実行されれば良い。この場合、ダミーリードコマンドDRCのリード先は共有メモリ１５Aでなければならない。

同様に、バスYに接続されたブロックBBが実行する共有メモリ１５Aに対するライトを確定させる場合には、ブロックBBとバスYに依存したダミーリードパッキング処理が実行されれば良い。同様に、バスZに接続されたブロックBCが実行する共有メモリ１５Aに対するライトを確定させる場合には、ブロックBCとバスZに依存したダミーリードパッキング処理が実行されれば良い。

図１２の場合も、ライトの確定のためのダミーリードコマンドDRCの発行のためのトリガ信号は、そのブロックの要因レジスタに対する要因レジスタリードコマンドRRC、としているので、各ブロックは接続されたバスのプロトコルのみを考慮したダミーリードパッキング処理が実行されば良い。すなわち、バス接続制御部１６は、各ブリッジの先のバスを考慮する必要がない。また、ダミーリードのトリガ信号である、要因レジスタリードコマンドRRCはどのバスから発行されても構わない。

以上のように、上述した本実施の形態及び変形例に係るバス制御装置およびバス制御方法によれば、ポステドライト（posted write）方式を使用した場合であっても、ハードウエア実装の面で複雑な回路を用いず、かつソフトウエアの面でも簡単な処理で、書き込みデータのコヒーレンシを保つことができる。
本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を変えない範囲において、種々の変更、改変等が可能である。

本発明の実施の形態に係わるバス制御装置の構成を示すブロック図である。 本発明の実施の形態に係わるデータの転送処理の流れを説明するためのシーケンス図である。 本実施の形態に係わるバス接続制御部の機能を説明するための図である。 本実施の形態に係わるバス接続制御部の機能を説明するための図である。 本実施の形態に係わるバス接続制御部の機能を説明するための図である。 本実施の形態に係わるバス接続制御部の機能を説明するための図である。 本実施の形態に係わるバス接続制御部の機能を説明するための図である。 本実施の形態に係わるバス接続制御部の機能を説明するための図である。 本実施の形態のバス接続制御部の構成を説明するための図である。 本実施の形態のブロックの変形例を説明するための図である。 本発明の実施のブロックのさらなる変形例を示す図である。 本発明の実施の複数のブロックがそれぞれ対応するバスに接続された、複数のバスプロトコルを有するバスアークテクチャを示すブロック図である。

符号の説明

１ バス制御装置、１３、１３A、１３B ブロック、１５ メモリ、１６ バス接続制御部、３１，３３ レジスタ、３２，３４ マルチプレクサ

Claims (5)

1. バスを介して、メモリに対してデータを書き込むためのライトコマンド信号を出力する１以上のブロックと、
   前記ブロックに対応して設けられ、前記バスと前記ブロックとの間の信号線の信号を監視して、前記ブロックの所定のレジスタのデータを読み出すためのリードコマンド信号を検出すると前記ブロックと前記バスとの間の信号線の接続を遮断し、前記メモリへのダミーリードコマンド信号を出力し、かつ、前記ダミーリードコマンド信号に対するレスポンス信号を受信すると前記遮断を解除するバス接続制御部と、
   を有することを特徴とするバス制御装置。
2. 前記バス接続制御部は、
   前記リードコマンド信号の受信を検出するリードコマンド検出部と、
   該リードコマンド検出部によって、前記リードコマンド信号が検出されると、対応するブロックと前記バスとの間の前記信号線の接続の遮断を行う遮断部と、
   該遮断部によって前記信号線の接続の遮断後、前記メモリに対して前記ダミーリードコマンド信号を出力するダミーリードコマンド信号出力部と、
   前記レスポンス信号を検出するレスポンス信号検出部と、
   を有し、前記バス接続制御部は、前記レスポンス信号検出部によって前記レスポンス信号が検出されると、前記遮断の解除を行うことを特徴とする請求項１に記載のバス制御装置。
3. 前記バスを含むバスアーキテクチャは、前記バスを含む複数のバスを有し、該複数のバス間は、それぞれバスブリッジを介して接続されていることを特徴とする請求項１に記載のバス制御装置。
4. 前記バス接続制御部は、前記バスへ前記ダミーリードコマンド信号を含むコマンド信号を出力する第１のインターフェースと、前記バスから前記リードコマンド信号を含むコマンド信号が入力される第２のインターフェースとを有することを特徴とする請求項１に記載のバス制御装置。
5. 前記バス接続制御部は、前記バスへ前記ダミーリードコマンド信号を含むコマンド信号をそれぞれが出力する複数の第１のインターフェースと、前記バスから前記リードコマンド信号を含むコマンド信号が入力される第２のインターフェースとを有することを特徴とする請求項１に記載のバス制御装置。

Images