(57)【要約】【課題】  本発明は、バス使用を要請したマスターに予想待機時間を伝送し、予想待機時間の間マスターが有効な作業を行なうことができるようにするバスシステム及びその制御方法を提供する。【解決手段】  予約待機時間を伝送するバスシステムが開示される。本バスシステムは、複数のマスターと、スレーブと、複数のマスター及びスレーブとの間のバス接続を支援し、複数のマスターのうち一つがバス使用中の場合、複数のマスターのうち少なくとも一つの他マスターに予想待機時間を伝送するバス部と、を含む。これにより、マスターが予約待機時間を用いて有効な作業をスケジューリングすることができるようになる。【選択図】図２
2008198185.tif 000002
【特許請求の範囲】
【請求項１】
複数のマスターと、
スレーブと、
前記複数のマスター及びスレーブとの間のバス接続を支援し、前記複数のマスターのうちの一つがバス使用中の場合、前記複数のマスターのうち少なくとも一つの他マスターに予想待機時間を伝送するバス部と、
を含むことを特徴とするバスシステム。
【請求項２】
前記バス部は、
前記複数のマスターと通信するためのマスターインターフェース部と、
前記予想待機時間をチェックして前記マスターインターフェース部を介して前記少なくとも一つの他マスターに伝送する制御部と、
を含むことを特徴とする請求項１に記載のバスシステム。
【請求項３】
前記バス部は、
前記複数のマスターに対する既存待機時間データが保存されたメモリを更に含み、
前記制御部は、前記既存待機時間を考慮して前記予想待機時間を決定することを特徴とする請求項２に記載のバスシステム。
【請求項４】
前記バス部は、
前記複数のマスターのうち現在バスを使用しているマスターのバス使用残存時間と、バス使用を先に要請した他マスターのバス使用要請時間データとを保存しているメモリを更に含み、
前記制御部は、前記バス使用残存時間と前記バス使用要請時間とを考慮して、前記予想待機時間を決定することを特徴とする請求項２に記載のバスシステム。
【請求項５】
前記バス部は、
前記複数のマスターのうち現在バスを使用しているマスターのバス使用残存時間と、優先順位を有するバス使用要請マスターのバス使用要請時間データとを保存しているメモリを更に含み、
前記制御部は、前記バス使用残存時間と前記バス使用要請時間とを考慮して、前記予想待機時間を決定することを特徴とする請求項２に記載のバスシステム。
【請求項６】
前記バス部は、
前記複数のマスターに対する固定された予想待機時間データが保存されたメモリを更に含み、
前記制御部は、前記固定された予想待機時間を考慮して前記予想待機時間を決定することを特徴とする請求項２に記載のバスシステム。
【請求項７】
前記マスターは、
前記バス部とインターフェースしてデータを送受信するバスインターフェース部と、
前記バスインターフェース部を介して前記予想待機時間が伝送されると、前記予想待機時間を用いて作業をスケジューリングするスケジューラと、
を含むことを特徴とする請求項１に記載のバスシステム。
【請求項８】
前記バスシステムはＳｏＣに用いられるオンチップバスシステムであることを特徴とする請求項１ないし請求項７のうちいずれか１項に記載のバスシステム。
【請求項９】
複数のマスターとスレーブとの間の接続を支援するバスを含むバスシステムの制御方法において、
（ａ）前記複数のマスターのうち第１マスターが前記バスを介して前記スレーブとデータを送受信するステップと、
（ｂ）第２マスターが前記バス使用を要請するステップと、
（ｃ）前記第２マスターに予想待機時間を伝送するステップと、
を含むことを特徴とする制御方法。
【請求項１０】
前記複数のマスターに対する既存待機時間を考慮して前記予想待機時間を決定するステップを更に含むことを特徴とする請求項９に記載の制御方法。
【請求項１１】
前記第１マスターのバス使用残存時間と、バス使用を先に要請した他マスターのバス使用要請時間とを考慮して、前記予想待機時間を決定するステップを更に含むことを特徴とする請求項９に記載の制御方法。
【請求項１２】
バス使用を要請したマスターの優先順位を確認するステップと、
前記第２マスターより優先順位を有する他マスターが存在すれば、前記第１マスターのバス使用残存時間と前記他マスターのバス使用要請時間とを考慮して、前記予想待機時間を決定するステップを更に含むことを特徴とする請求項９に記載の制御方法。
【請求項１３】
前記複数のマスターに対する固定された予想待機時間を考慮して、前記予想待機時間を決定するステップを更に含むことを特徴とする請求項９に記載の制御方法。
【請求項１４】
前記第２マスターが前記バスから伝送された前記予想待機時間を用いて作業をスケジューリングするステップを更に含むことを特徴とする請求項９に記載の制御方法。
【請求項１５】
前記バスシステムはＳｏＣに用いられるオンチップバスシステムであることを特徴とする請求項９ないし請求項１４のうちいずれか１項に記載の制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はバスシステム及びその制御方法に関し、より詳細には、システムオンチップに用いられるバスシステム及びその制御方法に関する。
【背景技術】
【０００２】
近年、互いに異なる機能を果たす数多くの複数のチップを１チップ上に集積するシステムオンチップ（ＳｏＣ）の使用が普遍化されている。
【０００３】
ＳｏＣは、「Ｓｙｓｔｅｍ  ｏｎ  Ｃｈｉｐ」の略字であって「Ｓｙｓｔｅｍ  Ｏｎ  Ａ  Ｃｈｉｐ」とも言うが、一つのシステムを一つのチップに詰め込むことを意味する。システムとは、「特定の目的を達成するために作業を行うことのできる総合装置」と辞書に明示されており、たとえば「コンピュータと周辺装置そしてソフトウェアまで総称する」とされている。
【０００４】
システムを具現するためには、ＳｏＣの応用分野によって異なるが、ソフトウェアでチップの動作をコントロールするためのプロセッサと、データを保存して使用するためのメモリが基本要素となる。そして、チップの応用分野によって、ＲＦモジュール、アナログモジュール、特殊機能のＡＳＩＣモジュール、周辺機器モジュールが搭載される。現在のＳｏＣは、性格や機能が独立なモジュール同士が、特殊のシステム機能を得るために互いに接続されてデータのやり取りをしながら動作することを総称している。
【０００５】
このようなＳｏＣは、様々な大規模のモジュールが複合的に接続されているため、その規模が大きいことから、設計した後に検証、製造するまで多くの時間と人力が消耗される。これを克服するために、ＳｏＣをより容易く開発するための方法論が台頭されたが、そのうち代表的なものがＩＰを用いた設計方法とプラットフォームを用いた設計方法がある。
【０００６】
プラットフォームは大きく２つに構成されるが、一つはＳｏＣアーキテクチャでありもう一つはＩＰインターフェース標準規定である。ＳｏＣアーキテクチャとは、大きく半導体モジュール（又はＩＰ）間の信号接続規約（プロトコル）と信号接続構造（トポロジー）から構成されている。信号接続構造（トポロジー）はバスの物理的な構造を言うが、大きく一つのバスから構成されたＳｉｎｇｌｅ  Ｓｈａｒｅｄ  Ｂｕｓ構造、バスを幾つかに分けてバス間ではブリッジを使用して接続するＨｉｅｒａｃｈｉｃａｌ  Ｂｕｓ構造、ＩＰ間の接続がトークンリング（Ｔｏｋｅｎ−ｒｉｎｇ）方式に構成されたＲｉｎｇ  Ｂｕｓ構造、そしてＩＰ毎にデータバスが一個ずつ付いているＣｒｏｓｓｂａ  Ｓｗｉｔｃｈ  Ｂｕｓ構造などがある。
【０００７】
複雑なシステムを更に複雑にするのは、検証された設計モジュール（ＩＰ）間の接続である。３２ｂｉｔ（アドレス３２ｂｉｔ、データ３２ｂｉｔ）の構造を有するＩＰ４個が互いに直接接続されて動作するためには、（３２ｂｉｔ＋３２ｂｉｔ）×３＝１９２ｂｉｔラインが交差しながらチップ全体を占めることになる。ＩＰが多くなるほどデータラインは更に複雑になる。これを解決する一つの方法として提示されたのが、現のＰＣＢ構造においても使用されているＳｏＣ接続構造の共用バス（Ｓｈａｒｅｄ  Ｂｕｓ）構造である。共用バス構造とは、全体のチップ内でＩＰ間の接続を共用のデータラインを使用して接続することを意味する。上記のように３２ｂｉｔ構造のＩＰが４個あれば、共用バスは（３２ｂｉｔ＋３２ｂｉｔ）＝６４ｂｉｔラインになる。この共用バスはＩＰ数が更に多くなっても同等のビットのデータラインを有する。共用バスを使用すればライン数が減少して便利であるが、共用バスには同時間に一つのＩＰのデータしか接続することができないという問題点がある。従って、共用バスを利用しようとする各マスターはバス利用待機時間の間は他の作業を行なうことができないという問題点がある。
【０００８】
図１Ａ及び図１Ｂは、従来技術の問題点を説明するための図である。
図１Ａは、共用バスを用いたＳｏＣアーキテクチャを構成する要素を説明するための図である。同図によると、複数のマスター（Ｍａｓｔｅｒ  １〜Ｍａｓｔｅｒ  ｎ）がオンチップバス（Ｏｎ−Ｃｈｉｐ  Ｂｕｓ）を介して複数のスレーブ（Ｓｌａｖｅ  １〜Ｓｌａｖｅ  ｎ）とデータを送受信している。
【０００９】
図１Ｂは、バス使用を要請したマスターの状態を示す図である。
同図によると、マスターがバス使用要請信号（ｒｅｑｍ）を伝送した後、承認信号（ｇｒａｎｔｍ）が伝送されるまで、待機状態（ＩＤＬＥ  ＴＩＭＥ）にいなければならないため、他の作業を行なうことができないという問題点がある。
【特許文献１】米国特許第７０９６２９１号公報
【特許文献２】米国特許第７０６９３６３号公報
【特許文献３】米国特許第７００７１２１号公報
【特許文献４】米国特許号５５５５４２５号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
本発明は前述の問題点を鑑みてなされたもので、本発明の目的は、バス使用を要請したマスターに予想待機時間を伝送し、予想待機時間の間マスターが有効な作業を行なうことができるようにするバスシステム及びその制御方法を提供することにある。
【課題を解決するための手段】
【００１１】
前述の目的を達成するための本発明の一実施形態によると、本バスシステムは、複数のマスターと、スレーブと、前記複数のマスター及びスレーブとの間のバス接続を支援し、前記複数のマスターのうちの一つがバス使用中の場合、前記複数のマスターのうち少なくとも一つの他マスターに予想待機時間を伝送するバス部と、を含む。
【００１２】
好ましくは、前記バス部は、前記複数のマスターと通信するためのマスターインターフェース部と、前記予想待機時間をチェックして前記マスターインターフェース部を介して前記少なくとも一つの他マスターに伝送する制御部と、を含む。
【００１３】
より好ましくは、前記バス部は、前記複数のマスターに対する既存待機時間データが保存されたメモリを更に含み、前記制御部は、前記既存待機時間を考慮して前記予想待機時間を決定することができる。
【００１４】
また好ましくは、前記バス部は、前記複数のマスターのうち現在バスを使用しているマスターのバス使用残存時間と、バス使用を先に要請した他マスターのバス使用要請時間データとを保存しているメモリを更に含み、前記制御部は、前記バス使用残存時間と前記バス使用要請時間とを考慮して、前記予想待機時間を決定することができる。
【００１５】
また好ましくは、前記バス部は、前記複数のマスターのうち現在バスを使用しているマスターのバス使用残存時間と、優先順位を有するバス使用要請マスターのバス使用要請時間データとを保存しているメモリを更に含み、前記制御部は、前記バス使用残存時間と前記バス使用要請時間とを考慮して、前記予想待機時間を決定することができる。
【００１６】
また好ましくは、前記バス部は、前記複数のマスターに対する固定された予想待機時間データが保存されたメモリを更に含み、前記制御部は、前記固定された予想待機時間を考慮して前記予想待機時間を決定することができる。
【００１７】
また好ましくは、前記マスターは、前記バス部とインターフェースしてデータを送受信するバスインターフェース部と、前記バスインターフェース部を介して前記予想待機時間が伝送されると、前記予想待機時間を用いて作業をスケジューリングするスケジューラと、を含むことができる。
【００１８】
また好ましくは、前記バスシステムはＳｏＣに用いられるオンチップ（ｏｎ  ｃｈｉｐ）バスシステムに具現することが可能である。
【００１９】
一方、本発明の一実施形態によると、複数のマスターとスレーブとの間の接続を支援するバスを含むバスシステムの制御方法は、（ａ）前記複数のマスターのうち第１マスターが前記バスを介して前記スレーブとデータを送受信するステップと、（ｂ）第２マスターが前記バス使用を要請するステップと、（ｃ）前記第２マスターに予想待機時間を伝送するステップと、を含む。
【００２０】
好ましくは、前記複数のマスターに対する既存待機時間を考慮して前記予想待機時間を決定するステップを更に含む。
【００２１】
より好ましくは、前記第１マスターのバス使用残存時間と、バス使用を先に要請した他マスターのバス使用要請時間とを考慮して、前記第２マスターの予想待機時間を決定するステップを更に含むことができる。
【００２２】
また好ましくは、バス使用を要請したマスターの優先順位を確認するステップと、前記第２マスターより優先順位を有する他マスターが存在すれば、前記第１マスターのバス使用残存時間と前記他マスターのバス使用要請時間とを考慮して、前記予想待機時間を決定するステップを更に含むことができる。
【００２３】
また好ましくは、前記複数のマスターに対する固定された予想待機時間を考慮して前記予想待機時間を決定するステップを更に含むことができる。
【００２４】
また好ましくは、前記第２マスターが前記バスから伝送された前記予想待機時間を用いて作業をスケジューリングするステップを更に含むことができる。
【００２５】
また好ましくは、前記バスシステムはＳｏＣに用いられるオンチップバスシステムに具現することが可能である。
【発明の効果】
【００２６】
本発明によると、バスがマスターの予想待機時間をチェックして伝送することができるようになる。これにより、マスターは予想待機時間の間、内部スケジューリングにより有効な作業を行うことができるので、ユーザの便宜性が改善される。
【発明を実施するための最良の形態】
【００２７】
以下、添付の図面に基づいて本発明の好適な実施形態を詳説する。
【００２８】
図２は、本発明の一実施形態に係るバスシステムの構成を示すブロック図である。同図によると、本バスシステム２００はマスター１（２１０）、マスタ２（２２０）、スレーブ２３０、及びバス部２４０を含む。
【００２９】
本バスシステム２００は、オンチップバスシステムに具現することができる。オンチップバス（Ｏｎ−Ｃｈｉｐ  Ｂｕｓ）は、システムオンチップ（Ｓｙｓｔｅｍ−ｏｎ−Ｃｈｉｐ）に必須的なプロトコルである。ここで、システムオンチップは、システムを１チップ積載するという辞典的な意味を有し、一つのチップ上に駆動可能な製品、すなわちシステムを設計する技術を意味する。
【００３０】
ここで、マスター２１０、２２０は、バスを使用することのできる権利を有するＩＰ又は各種のコンポーネントのことを言う用語であって、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｃ  Ｄｒｉｖｅ）コントローラ、マイクロプロセッサ（Ｍｉｃｒｏ  Ｐｒｏｃｅｓｓｏｒ）、オーディオＤＳＰ（Ｄｉｇｉｔａｌ  Ｓｉｇｎａｌ  Ｐｒｏｃｅｓｓｏｒ）、及びＭＰＥＧ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔ  Ｇｒｏｕｐ）などから構成することができる。
【００３１】
スレーブ２３０は、マスターによって制御されるＩＰ又は各種のコンポーネントのことを言う用語であって、入出力装置、メモリなどから構成することができる。本実施形態では、説明の便宜上、マスターが２つ、スレーブが１つの場合を示しており、マスターとスレーブの個数は場合によって２つ以上に具現することもできる。
【００３２】
マスター２１０、２２０は、スレーブ２３０にデータを書き込んだり読み出す役割を果たし、このためにバス部２４０にバス占有要請を行なう。本実施形態において、マスター１（２１０）はスレーブとデータを送受信するためにバスを占有している状態であり、マスター２（２２０）はその以降にバス使用を要請した状態であると仮定する。
【００３３】
バス部２４０は、マスター２１０、２２０及びスレーブ２３０との間の接続を支援する役割を果たす。一般に、マスター２１０，２２０のバス占有要請に対して、現在バスを使用しているマスターの存在有無と予め設定されたマスターの優先権を考慮して、特定の一つのマスターにのみバス占有を許容（Ｂｕｓ  Ｇｒａｎｔ）する。また、既にバスを占有しているマスター１（２１０）がある場合には、バス占有を要請したマスター２（２２０）に予想待機時間を伝送する役割を果たす。
【００３４】
バス占有が許容されたマスター１（２１０）は、バスマスター２１０になってスレーブ２３０にデータを書き込んだり読み出しをする。そして、バスマスター２１０はデータの書き込み又は読み出しの動作が完全に終了するまでにバスを占有し、その後、バス占有を要請したマスター２（２２０）は現在バスマスター２１０によるデータの書き込み又は読み出しの動作が終了するまでに待機状態にいなければならないし、この待機状態の間はバス部２４０から伝送された予想待機時間を用いて他の作業を行なうことができるようになる。
【００３５】
図３は、図２に示されたマスターの細部構成を示すブロック図である。同図によると、マスター２２０は、バスインターフェース部２２１及びスケジューラ２２２を含む。図３のマスター２２０は、図２のシステムのうちマスター１（２１０）又はマスター２（２２０）になることができる。
【００３６】
バスインターフェース部２２１は、図２に示されたバス部２４０とインターフェースしてデータを送受信する役割を果たす。
【００３７】
スケジューラ２２２は、バスインターフェース部２２１を介して予想待機時間が伝送されると、予想待機時間を用いて作業をスケジューリングする役割を果たす。すなわち、スケジューラ２２２は、バス部２４０から予想待機時間が受信されると、他マスターがバス使用中の場合、予想待機時間の間に他の有効な後続作業を行なうように作業をスケジューリングすることができる。
【００３８】
図４Ａ及び図４Ｂは、図２に示されたバス部の細部構成を示す図である。
図４Ａは、図２に示されたバス部の一実施形態に係る細部構成を示すブロック図である。同図によると、バス部２４０は、マスターイオンターフェース部２４１及び制御部２４２を含む。
【００３９】
マスターインターフェース部２４１は、マスター２１０、２２０と通信を行なう役割を果たす。
【００４０】
制御部２４２は、バス使用を要請したマスター２（２２０）の予想待機時間をチャックし、マスターインターフェース部２４１を介してマスター２（２２０）に伝送する役割を果たす。
【００４１】
マスター２（２２０）の予想待機時間は、制御部２４２の優先権政策によって異なり得る。具体的に、制御部２４２の政策には順番が絶対的に固定された固定的優先権（ｆｉｘｅｄ  ｐｒｉｏｒｉｔｙ  ｓｃｈｅｍｅ）、定められた順番の通りに優先権が異なってくる循環的優先権政策（ｒｏｕｎｄ−ｒｏｂｉｎ  ｐｒｉｏｒｉｔｙ）、循環的優先権の政策を改造したＴＤＭ（Ｔｉｍｅ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘ）優先権政策、優先権確率の概念を導入したＬｏｔｔｅｒｙ方式などがある。すなわち、制御部２４２は各マスター毎にバスを使用した頻度を見てバス使用の優先順位を設定することもでき、又は制御プログラムに従ってバス使用の優先順位を設定することもできる。
【００４２】
図４Ｂは、図２に示されたバス部の他の実施形態に係る細部構成を示すブロック図である。同図によると、バス部２４０は、マスターインターフェース部２４１、制御部２４２、及びメモリ２４３を含む。同図に示された各構成要素のうち、図４Ａに示された実施形態と重複する部分については具体的な細部説明は省略する。
【００４３】
メモリ２４３は、複数のマスターに対する既存待機時間データを保存する。この場合、制御部２４２は、メモリ２４３に保存された既存待機時間を考慮し、各マスターの予想待機時間を決定することができる。
【００４４】
又は、メモリ２４３は、複数のマスターのうち現在バスを使用しているマスターのバス使用残存時間と、バス使用を先に要請したマスターのバス使用要請時間データとを保存する。この場合、制御部２４２は、メモリ２４３に保存されたバス使用残存時間とバス使用要請時間とを考慮し、各マスターの予想待機時間を決定することができる。
【００４５】
又は、メモリ２４３は、複数のマスターのうち現在バスを使用しているマスターのバス使用残存時間と、優先順位を有するバス使用要請マスターのバス使用要請時間データとを保存する。この場合、制御部２４２は、メモリ２４３に保存されたバス使用残存時間とバス使用要請時間とを考慮し、各マスターの予想待機時間を決定することができる。
【００４６】
又は、メモリ２４３は、各マスターに対して固定された予想待機時間データを保存する。この場合、制御部２４２は、メモリ２４３に保存された予想待機時間を考慮し、各マスターの予想待機時間を決定することができる。
【００４７】
図５は、本発明の一実施形態に係るオンチップバスシステムの構成要素間のインターフェースを説明するための図である。
【００４８】
同図によると、本オンチップバスシステム５００は、マスター５１０、オンチップバス５２０、スレーブ５３０、及び各データインターフェース１〜２０を含む。
【００４９】
マスター５１０はオンチップバス５２０に、ａｄｄｒｅｓｓ１、ｔｒａｎｓｆｅｒ  ｔｙｐｅ２、ｗｒｉｔｅ３、ｔｒａｎｓｆｅｒ  ｓｉｚｅ４、ｂｕｒｓｔ  ｔｙｐｅ５、ｒｅｑｕｅｓｔ６、ｗｒｉｔｅ  ｄａｔａ７信号を伝送し、オンチップバス５２０からｇｒａｎｔ８、ｒｅａｄ９、ｓｌａｃｋ  ｔｉｍｅ１０、ｒｅａｄ  ｄａｔａ１１などの信号を受信する。
【００５０】
また、オンチップバス５２０はスレーブ５３０に、ｓｅｌｅｃｔｉｏｎ１２、ａｄｄｒｅｓｓ１３、ｗｒｉｔｅ１４、ｔｒａｎｓｆｅｒ  ｔｙｐｅ１５、ｔｒａｎｓｆｅｒ  ｓｉｚｅ１６、ｂｕｒｓｔ  ｔｙｐｅ１７、ｗｒｉｔｅ  ｄａｔａ１８信号を伝送し、スレーブ５３０からｒｅａｄｙ１９、ｒｅａｄ  ｄａｔａ２０などの信号を受信する。
【００５１】
図６Ａないし図６Ｃは、マスターの予想待機時間を決定する多様な方法を説明するための図である。
【００５２】
図６Ａは、マスターの既存待機時間を用いて予想待機時間を決定する方法を説明するための図である。
同図において、横軸はマスターに対して既存に待機時間が割当てられた回を示し、縦軸はマスターの種類を示す。同図によると、マスター１の場合、最近（０回目）２０サイクルが割当てられ、その以前（１回目）は２５サイクル、その以前（２回目）は４５サイクル、その以前（３回目）は２０サイクルが割当てられたことがある。この場合、バス部２４０は、既存にマスター１に割当てられた待機時間を平均し、マスター１の現在予想待機時間を決定することができる。本実施形態においては、最近４回目までの既存待機時間に基づいてデータを作成し、ｓｅｃｏｎｄ単位を使用しているが、これは一実施例に過ぎず、場合によって多様に変更可能である。
【００５３】
図６Ｂは、マスターの現在バス利用状態を用いて予想待機時間を決定する方法を説明するための図である。
【００５４】
同図において、横軸はマスターの状態（ＳＴＡＴＵＳ）、バス使用残存時間（ＲＥＭ．ＴＩＭＥ）、バースト長さ（ＢＲＳＴ  ＬＥＮ）、予想待機時間（ＳＬＡＣＫ）を示し、縦軸はマスターの種類を示す。同図によると、マスター１の場合、待機状態（ＷＡＩＴＩＮＧ）にあり、ＢＲＳＴ  ＬＥＮが１６サイクル、ＳＬＡＣＫが２０サイクルである。マスター２の場合、サービス中（ＩＮ  ＳＥＲＶＩＣＥ）にあり、ＲＥＭ．ＴＩＭＥが１７サイクル、ＢＲＳＴ  ＬＥＮが３２サイクルである。また、マスター３、マスター５は、ＩＤＬＥ状態にあり、マスター４はバス利用要請状態（ＲＥＱ）にあり、ＢＲＳＴ  ＬＥＮが８サイクルである。
【００５５】
この場合、バス利用を要請したマスター４は、現在ＩＮ  ＳＥＲＶＩＣＥ状態にあるマスター２のＲＥＭ．ＴＩＭＥ１７サイクルに待機状態にあるマスター１のＢＲＳＴ  ＬＥＮ１６サイクルを加算した値だけの待機時間が割当てられ得る。
【００５６】
本実施形態においては、マスターの優先順位を考慮せずに予想待機時間を割当てる場合について説明したが、マスターの優先順位を考慮する場合には予想待機時間が変更され得る。たとえば、マスター１に予想待機時間が先に割当てられた場合でも、マスター４の優先順位が更に高い場合、マスター４が先にデータを送受信するように予想待機時間を割当てることができる。
【００５７】
図６Ｃ及び図６Ｄは、各マスターに予想待機時間が固定されている場合を説明するための図である。
【００５８】
図６Ｃは、各マスターに同一の予想待機時間が予め設定されている場合を説明するための図である。同図によると、各マスター（ｍａｓｔｅｒ  １〜ｍａｓｔｅｒ  ｎ）に同一の予想待機時間が予め設定されることができ、バス部２４０はこの予想待機時間をマスターに伝送し、その間各マスターが他の作業をスケジューリングするようにすることができる。
【００５９】
図６Ｄは、各マスター毎に異なる予想時間が予め設定されている場合を説明するための図である。同図によると、各マスター毎に異なる予想待機時間が予め設定されることができ、バス部２４０はこの予想待機時間をマスターに伝送し、その間各マスターが他の作業をスケジューリングするようにすることができる。各マスター毎の予想待機時間は各マスターの特性及びバスの利用状態などを考慮して設定することができる。
【００６０】
図７Ａ及び図７Ｂは、様々な場合によるマスターの予想待機時間を説明するための図である。
【００６１】
図７Ａは、バス使用要請信号（ｒｅｐｍ）の伝送後、バス使用承認信号（ｇｒａｔｍ）の伝送時間まで約６０サイクルの予想待機時間が伝送された場合である。
【００６２】
図７Ｂは、バス使用要請信号（ｒｅｐｍ）の伝送後、すぐバス使用承認信号（ｇｒａｔｍ）が伝送された場合であって、０サイクルの予想待機時間が伝送された場合である。
【００６３】
図８は、本発明の一実施形態に係るバスシステムの制御方法を説明するためのフローチャートである。ここで、バスシステムは、ＳｏＣに用いられるオンチップバスシステムに具現することが可能である。
【００６４】
図８の制御方法によると、複数のマスターのうち第１マスターがバスを介してスレーブとデータを送受信する途中（Ｓ８１０）、第２マスターがバス使用を要請する（Ｓ８２０）。次いで、バスが第２マスターに予想待機時間を伝送する（Ｓ８３０）。
【００６５】
この場合、バスは複数のマスターに対する既存待機時間を考慮し、第２マスターに伝送する予想待機時間を決定することができる。
【００６６】
又は、第１マスターのバス使用残存時間と先にバス使用を要請したマスターのバス使用要請時間を考慮し、第２マスターに伝送する予想待機時間を決定することができる。
【００６７】
又は、第２マスターと優先順位を有するバス使用を要請したマスターの優先順位を確認し、第１マスターのバス使用残存時間と優先順位を有するバス使用要請マスターのバス使用要請時間とを考慮し、予想待機時間を決定することができる。
【００６８】
又は、複数のマスターに対する固定された予想待機時間を考慮し、第２マスターに伝送する予想待機時間を決定することができる。
【００６９】
図９は、本発明の他の実施形態に係るバスシステムの制御方法を説明するためのフローチャートである。
【００７０】
図９の制御方法によると、複数のマスターのうち第１マスターがバスを介してスレーブとデータを送受信する途中（Ｓ９１０）、第２マスターがバス使用を要請する（Ｓ９２０）。次に、バスが第２マスターに予想待機時間を伝送する（Ｓ９３０）。
【００７１】
その後、第２マスターがバスから伝送された予想待機時間を用いて作業をスケジューリングすることができる（Ｓ９４０）。
【００７２】
これにより、バス使用待機時間の間、マスターが有効な作業を行うことができるようになる。
【００７３】
以上、本発明の好適な実施形態を図示及び説明してきたが、本発明の技術的範囲は前述の実施形態に限定するものではなく、特許請求の範囲に基づいて定められ、特許請求の範囲において請求する本発明の要旨から外れることなく当該発明が属する技術分野において通常の知識を有する者であれば誰もが多様な変形実施が可能であることは勿論のことであり、該変更した技術は特許請求の範囲に記載された発明の技術的範囲に属するものである。
【図面の簡単な説明】
【００７４】
【図１Ａ】従来技術の問題点を説明するための図である。
【図１Ｂ】従来技術の問題点を説明するための図である。
【図２】本発明の一実施形態に係るバスシステムの構成を示すブロック図である。
【図３】図２に示されたマスターの細部構成を示すブロック図である。
【図４Ａ】図２に示されたバス部の細部構成を示す図である。
【図４Ｂ】図２に示されたバス部の細部構成を示す図である。
【図５】本発明の一実施形態に係るオンチップバスシステムにおける構成要素間のインターフェースを説明するための図である。
【図６Ａ】マスターの予想待機時間を決定する多様な方法を説明するための図である。
【図６Ｂ】マスターの予想待機時間を決定する多様な方法を説明するための図である。
【図６Ｃ】マスターの予想待機時間を決定する多様な方法を説明するための図である。
【図６Ｄ】マスターの予想待機時間を決定する多様な方法を説明するための図である。
【図７Ａ】様々な場合によるマスターの予想待機時間を説明するための図である。
【図７Ｂ】様々な場合によるマスターの予想待機時間を説明するための図である。
【図８】本発明の一実施形態に係るバスシステムの制御方法を説明するためのフローチャートである。
【図９】本発明の他の実施形態に係るバスシステムの制御方法を説明するためのフローチャートである。
【符号の説明】
【００７５】
２１０      マスター１
２２０      マスター２
２３０      スレーブ
２４０      バス部
２２１      バスインターフェース部
２２２      スケジューラ
２２３      メモリ
２４１      マスターインターフェース部
２４２      制御部
【図１Ａ】
2008198185.tif 000003
【図１Ｂ】
2008198185.tif 000004
【図２】
2008198185.tif 000005
【図３】
2008198185.tif 000006
【図４Ａ】
2008198185.tif 000007
【図４Ｂ】
2008198185.tif 000008
【図５】
2008198185.tif 000009
【図６Ａ】
2008198185.tif 000010
【図６Ｂ】
2008198185.tif 000011
【図６Ｃ】
2008198185.tif 000012
【図６Ｄ】
2008198185.tif 000013
【図７Ａ】
2008198185.tif 000014
【図７Ｂ】
2008198185.tif 000015
【図８】
2008198185.tif 000016
【図９】
2008198185.tif 000017