JP3791742B2 - Ｐｃｉバス制御システム - Google Patents
Ｐｃｉバス制御システム Download PDFInfo
- Publication number
- JP3791742B2 JP3791742B2 JP14927999A JP14927999A JP3791742B2 JP 3791742 B2 JP3791742 B2 JP 3791742B2 JP 14927999 A JP14927999 A JP 14927999A JP 14927999 A JP14927999 A JP 14927999A JP 3791742 B2 JP3791742 B2 JP 3791742B2
- Authority
- JP
- Japan
- Prior art keywords
- pci bus
- function
- pci
- data
- master
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 230000006870 function Effects 0.000 claims description 209
- 230000005540 biological transmission Effects 0.000 claims description 117
- 238000012545 processing Methods 0.000 claims description 72
- 238000004891 communication Methods 0.000 claims description 59
- 230000004044 response Effects 0.000 claims description 31
- 238000004364 calculation method Methods 0.000 claims description 7
- 230000007115 recruitment Effects 0.000 claims description 7
- 238000010586 diagram Methods 0.000 description 101
- 238000000034 method Methods 0.000 description 84
- 230000008569 process Effects 0.000 description 55
- 230000000694 effects Effects 0.000 description 23
- 238000012546 transfer Methods 0.000 description 10
- 238000007726 management method Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 3
- 238000003491 array Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 239000003999 initiator Substances 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000010348 incorporation Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012946 outsourcing Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/14—Handling requests for interconnection or transfer
- G06F13/36—Handling requests for interconnection or transfer for access to common bus or bus system
- G06F13/362—Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
Description
【０００１】
【発明の属する技術分野】
本発明は、ＰＣＩ（Peripheral Component Interconnect）バス制御を行うＰＣＩバス制御システムに関するものである。
【０００２】
【従来の技術】
従来、パーソナルコンピュータ（ＰＣ）等で採用しているＰＣＩバス制御システムでは、デバイスは全てＰＣＩバス制御をしないノン−インテリジェントデバイスで構成されている。よって、ＰＣＩバスマスタ（ＰＣ側）が全てのＰＣＩ通信の制御を行っていた。
【０００３】
【発明が解決しようとする課題】
しかしながら、上記従来のように、ＰＣＩバスマスタ側が全てのＰＣＩ通信の制御を行う場合、次のような問題点があった。即ち、ＰＣＩバスマスタが全てのデバイスに対してアクセスする必要があり、このため、ＰＣＩバスマスタが全てのデバイスに対してアクセスするためのドライバを持つ必要があった。
【０００４】
【課題を解決するための手段】
本発明は、前述の課題を解決するため次の構成を採用する。
〈構成１〉
ＰＣＩバスマスタと、単独ではＰＣＩのバストランザクションを開始する機能を持たない複数のノン−インテリジェントデバイスと、ＰＣＩバスを経由した通信を自ら行う機能を持つインテリジェントデバイスとが接続されるＰＣＩバス制御システムであって、前記ＰＣＩバスマスタは、所定の前記ノン−インテリジェントデバイスの仮オーナを決定するために、前記インテリジェントデバイスに仮オーナ要求を示すコマンドを送信する機能と、サービス情報送信要求を仮オーナの承諾した前記インテリジェントデバイスに送信する機能とを備え、前記インテリジェントデバイスは、前記ＰＣＩバスマスタからの仮オーナ要求を示すコマンドに対して承諾及び拒否のいずれかの受信応答を示すコマンドを前記ＰＣＩバスマスタに送信する機能と、前記ＰＣＩバスマスタから受信した前記サービス情報送信要求に対し前記ノン−インテリジェントデバイスから対応するサービス情報を収集し、該サービス情報を前記ＰＣＩバスマスタに送信する機能と、を備えることを特徴とするＰＣＩバス制御システム。
【０００５】
＜構成２＞
構成１に記載のＰＣＩバス制御システムにおいて、前記インテリジェントデバイスおよび前記ノン−インテリジェントデバイスは、前記ＰＣＩバスマスタが各デバイスを初期化する際に参照するコンフィグレーションレジスタを備え、該レジスタの予め決められた先頭の数ビットを、インテリジェントデバイスかノン−インテリジェントデバイスかを識別するための値とすることを特徴とするＰＣＩバス制御システム。
【０００６】
＜構成３＞
構成１または２に記載のＰＣＩバス制御システムにおいて、前記インテリジェントデバイスおよび前記ノン−インテリジェントデバイスのメモリに、ＰＣＩデバイスドライバの初期化時に使用する通信用作業領域を設け、かつ、当該通信用作業領域をメモリ領域の先頭に設けたことを特徴とするＰＣＩバス制御システム。
【０００７】
＜構成４＞
構成２に記載のＰＣＩバス制御システムにおいて、前記先頭の数ビットは、各機能にマッピングする領域の先頭に設けた、ＰＣＩデバイスドライバの初期化時に使用する通信用作業領域を有するか否かを示す値であることを特徴とするＰＣＩバス制御システム。
【０００８】
〈構成５〉
構成１に記載のＰＣＩバス制御システムにおいて、送信側デバイスから受信側デバイスへの送信データの先頭に、次の送信データのＰＣＩヘッダの先頭アドレスを示すネクストポインタと、当該送信データにおけるデータエリアのアドレスを示すデータエリアポインタとを示すＰＣＩヘッダを備え、かつ、前記ネクストポインタの最下位ビットを、送信データが連続するか否かを示すフラグとしたことを特徴とするＰＣＩバス制御システム。
【０００９】
＜構成６＞
構成１または２に記載のＰＣＩバス制御システムにおいて、前記ＰＣＩバスマスタおよび前記インテリジェントデバイスは、全システム内に存在する機能と一意に対応づけられ、各機能毎に設けられたデバイスプロファイルを有し、各デバイスプロファイルは、送信先のメールボックスのアドレスを示すメールボックスポインタと、送信先の処理に割り込みを発生させる割り込み要求レジスタのアドレスを示す割り込み要求レジスタポインタと、自分宛のコマンドとその引数を格納するメールボックスとを備え、機能ＸのデバイスプロファイルＹのメールボックスポインタは、機能ＹのデバイスプロファイルＸのメールボックスのアドレスを示し、各機能のデバイスプロファイルＸの割り込み要求レジスタポインタは、機能Ｘの割り込み要求レジスタのアドレスを示すよう構成されていることを特徴とするＰＣＩバス制御システム。
【００１０】
＜構成７＞
構成６に記載のＰＣＩバス制御システムにおいて、前記ＰＣＩバスマスタは、前記インテリジェントデバイスの機能に対して、配布するデバイスプロファイルのサイズと個数とを通知することによりコピーする先頭アドレスを入手するコピー先アドレス問い合わせ処理部と、コピーする先頭アドレスに基づき、配布するデバイスプロファイルのメールボックスポインタを求めるメールボックスポインタ計算処理部とを備えたことを特徴とするＰＣＩバス制御システム。
【００１１】
＜構成８＞
構成６または７に記載のＰＣＩバス制御システムにおいて、割り込み要求レジスタの各ビットは、それぞれ、各機能と一意に対応づけられ、かつ、各機能が他の機能に対して割り込みを要求する場合は、相手自身のビットに書き込みを行うよう構成されていることを特徴とするＰＣＩバス制御システム。
【００１２】
〈構成９〉
構成１に記載のＰＣＩバス制御システムにおいて、送信側デバイスから受信側デバイスへの送信データの先頭に、次の送信データのＰＣＩヘッダの先頭アドレスを示すネクストポインタと、送信データにおけるデータエリアのアドレスを示すデータエリアポインタと、送信データのデータサイズとを示すＰＣＩヘッダを備えたことを特徴とするＰＣＩバス制御システム。
【００１３】
＜構成１０＞
構成１、５または９のいずれかに記載のＰＣＩバス制御システムにおいて、前記ＰＣＩバスマスタおよび前記インテリジェントデバイスは、階層処理構造における自層の処理を行うヘッダ情報中に、ヘッダのサイズを示す情報を含むと共に、ヘッダ情報の総データ量が特定の値の倍数となるように可変長のデータであるパディングを付加するようにしたことを特徴とするＰＣＩバス制御システム。
【００１４】
＜構成１１＞
構成１、２、３、６、７、１０のいずれかに記載のＰＣＩバス制御システムにおいて、前記インテリジェントデバイスは、予め決められた初期化時暫定マスタよりデバイスマスタ募集があった場合、自身がデバイスマスタになれる条件を備えていた場合はデバイスマスタに応募し、デバイスマスタが自身に決定した場合は他のデバイスの初期化処理を行うよう構成されていることを特徴とするＰＣＩバス制御システム。
【００１５】
【発明の実施の形態】
以下、本発明の実施の形態を具体例を用いて詳細に説明する。
《具体例１》
具体例１は、ＰＣＩバス上のＰＣＩバスを経由した通信を自ら行う機能（Initiator機能）を持たないデバイス（ノン−インテリジェントデバイス）をオーナとして管理するインテリジェントデバイスを備えるようにしたものである。
【００１６】
〈構成〉
図１は本発明のＰＣＩバス制御システムの具体例１を示す構成図である。
図のシステムは、ＰＣＩバス（PCI BUS）１上に接続されたプリンタ（Printer）２、インテリジェントデバイス（PCI Device (Intelligent)またはMFP(Intelligent)）３、ノン−インテリジェントデバイス（PCI Device (Non Intelligent)）４からなる。
【００１７】
プリンタ２は、ＰＣＩバスマスタ（PCI BUS Master）としての機能を有するデバイスである。インテリジェントデバイス３は、自身にＣＰＵを持ち、ＰＣＩバス１を経由した通信を自ら行う機能（Initiator機能）を持っているデバイスである。ノン−インテリジェントデバイス４は、ＰＣＩバス１を経由した通信を行う機能を持たないデバイスである。
【００１８】
即ち、インテリジェントデバイス３は、ノン−インテリジェントデバイス４をオーナとして管理するデバイスであり、オーナとして管理するノン−インテリジェントデバイス４のデバイスドライバを備え、かつ、そのノン−インテリジェントデバイス４へアクセスする機能と、他のデバイスからそのノン−インテリジェントデバイス４へのアクセス要求を取りまとめる(中継する)機能とを有している。
【００１９】
図２は、本発明のＰＣＩバス制御システムのソフトウェア階層構造を示す説明図である。
図示のように、ＰＣＩバス１を経由する二つのデバイス間通信は、ＰＣＩデバイスドライバ（PCI Device Driver）の上位層としてゲート（Gate）層を、ゲート層の上位層としてＩＥＥＥ１２８４．４（プロトコル層）とサービスマネージャ（Service Maneger）を使用する。ここで、ＰＣＩデバイスドライバは、ＰＣＩバスのデバイスドライバ、ゲート層は、それぞれのデバイスを識別するＰＣＩバスに接続されるボードレベルの制御を行う部分、サービスマネージャは、例えば、印刷といったサービスを制御する部分である。
【００２０】
動作的には、送信元ＰＣＩデバイスドライバが作成する送信データは送信先ＰＣＩデバイスドライバが処理する。送信元ゲートが作成する送信データは送信先ゲートが処理する。送信元ＩＥＥＥ１２８４．４が作成する送信データは送信先ＩＥＥＥ１２８４．４が処理する。送信元ＩＥＥＥ１２８４．４の上位層が作成する送信データは送信先ＩＥＥＥ１２８４．４の上位層が処理する。以上のような階層構造により構成される。
【００２１】
〈動作〉
インテリジェントデバイス３が、先ず自身を初期化し、ノン−インテリジェントデバイス４は、インテリジェントデバイス（オーナ）３による初期化待ちとなる。
【００２２】
図３は、ノン−インテリジェントデバイス４の初期化の説明図である。
具体例のＰＣＩの初期化処理（拡張ＰＣＩ初期化処理、拡張Gate初期化処理）では、ノン−インテリジェントデバイス４に対してアクセス可能な仮のオーナを決定するプロセスを実行する。また、サービスマネージャの初期化では、仮サービスの認識、オーナの募集を行う。
【００２３】
デバイスマスタ（PCI BUS Master：ＰＣＩバスマスタ）は、仮オーナ決定処理を行う。よって、本仕様ではＰＣＩバスマスタ上に存在する各ノン−インテリジェントデバイス４は、仮オーナになれる機能をもったインテリジェントデバイス３が必要である。仮オーナの役割は、オーナとなっているノン−インテリジェントデバイス４の関連情報に対して、ＰＣＩバスマスタからの問い合わせに回答することである。例えば、後述するサービスマネージャの初期化で必要となる情報の収集が行われるが、その際に、ノン−インテリジェントデバイス４は、その要求に対応できないため、仮オーナとなったインテリジェントデバイス３は代わりにそのデバイスの情報を収集し送信する。
【００２４】
仮オーナを決定するため、ＰＣＩバスマスタは先ず一つのノン−インテリジェントデバイス４に対する仮オーナ要求を、存在する全インテリジェントデバイス３に順番に送信する。
【００２５】
図４は、仮オーナ決定処理の説明図である。
図示のように、ＰＣＩバスマスタは、ノン−インテリジェントデバイス４が複数存在する場合には、図４に示すような処理を、そのノン−インテリジェントデバイス４の数分繰り返す。例えばノン−インテリジェントデバイス４が５個ある場合は、図４に示す処理を５回繰り返す。尚、ＰＣＩバスマスタは、ノン−インテリジェントデバイス４が存在しない場合には、仮オーナ要求を送信しない。
【００２６】
ここで、各デバイス（インテリジェントデバイス３）は、ＰＣＩバスマスタから送信される「仮オーナ要求」を示すコマンドを受信すると、以下のいずれかの応答をしなければならない。
(1)仮オーナ受諾：自デバイスが「仮オーナ」機能を有している場合
(2)仮オーナ拒否：自デバイスが「仮オーナ」機能を有していない場合
【００２７】
図５は、仮オーナ決定シーケンスの説明図である。
仮オーナ決定シーケンスにおいて、「仮オーナ決定」を示すコマンドの送信は仮オーナ決定シーケンスの最後に行われる。各仮オーナ決定シーケンスはＰＣＩバス１上に存在するノン−インテリジェントデバイス４の数に対応している。よって、ＰＣＩバスマスタはＰＣＩバス１上に存在するノン−インテリジェントデバイス４の数と同数の仮オーナ決定コマンドを発行する。「仮オーナ決定」を示すコマンドを受信したインテリジェントデバイス３は「受信応答」を示すコマンドを返信する。
【００２８】
また、いずれかの仮オーナとなったインテリジェントデバイス３であっても、ＰＣＩバスマスタからの次の「仮オーナ要求」を示すコマンドに対して「仮オーナ受諾」を示すコマンドを返すことも可能とする。これにより、複数のノン−インテリジェントデバイス４の仮オーナになることが可能である。
以上が、図３における拡張ＰＣＩ初期化処理および拡張Gate初期化処理の内容である。
【００２９】
次に、図３におけるサービスマネージャ（Service Manager）初期化処理について説明する。
サービスマネージャの初期化はデバイスマスタとなったデバイスを中心に行う。一般にデバイスマスタはＰＣＩバスマスタとなっているデバイスが担当し、ＰＣＩデバイスドライバおよびゲートの初期化以降の初期化を受け持つ。
【００３０】
図６は、サービスマネージャの初期化時における仮サービスの認識処理の説明図である。
デバイスマスタの他システムのディスカバリ処理として、各システムが持つサービスの情報収集が行われる。この時に、仮オーナは、デバイスマスタから「Pre-Service Profile送信要求」コマンドを受信すると、仮オーナとなっているノン−インテリジェントデバイス４のサービス情報もまとめてデバイスマスタに連絡しなければならない。仮オーナは、仮オーナとなっているノン−インテリジェントデバイス４のサービス内容については判断できないため、仮オーナがデバイスマスタに通知する（「Pre-Service Profile送信」コマンドを送信する）サービスは仮サービスと定義する。
【００３１】
デバイスマスタは、全システム中に仮サービスが存在することを認識すると、その仮サービスを正式なサービスにするために、その仮サービスに対するオーナを唯一割り当てる処理を行う。
【００３２】
図７は、サービス整合処理の説明図である。
デバイスマスタは、全ノン−インテリジェントデバイス４に対しオーナの割り当てが終了（成功・不成功不問）すると、オーナからのサービスの更新を待つ。オーナからサービスの更新があった場合は、再びサービスプロファイル（Service Profile）を更新してサービスの整合を行う。尚、サービスプロファイルとは、どのデバイスがどのようなサービスを提供するかを示す情報である。
【００３３】
オーナは、その仮サービスに対する全権利を持っているので自由な対応が可能である。以下に対応例を示す。
【００３４】
対応例(1)
仮サービスを独占使用する場合は、「サービスの削除」を行い、他の処理からアクセスできないようにする。そのサービス専用のデバイスドライバでアクセスする必要がある。
【００３５】
対応例(2)
共有サービスの配布役をする場合は、サービスプロファイルに新サービスとして「サービスの変更」を行い、他の処理からの要求に対して仮サービスの使用権を配布する。
【００３６】
対応例(3)
共有サービスのアクセスマスタを行う場合は、サービスプロファイルに新サービスとして「サービスの変更」を行い、他の処理からの要求に対して新サービスを提供する。
【００３７】
〈効果〉
以上のように具体例１によれば、ＰＣＩバスを介して通信する機能を持たないノン−インテリジェントデバイスのオーナとなるインテリジェントデバイスを設けたので、以下のような効果が期待できる。
【００３８】
(1)ＰＣＩバスマスタが、必ず、接続されるデバイス全てにアクセスする機能（デバイスドライバ）を持つ必要がなくなる。例えば、ＰＣＩバス経由のＳＣＳＩボードが接続されていた場合、本具体例の仕様により、ＰＣＩバスマスタはＳＣＳＩドライバを装備することなくＳＣＳＩボードの提供するサービスを使用することができる。同一のＰＣＩバスに接続されているＰＣＩバスマスタ以外のデバイスについても同様の効果が期待できる。
【００３９】
(2)本システムでは、インテリジェントデバイスの接続をサポートしているため、ＰＣＩバスマスタのＰＣＩ通信における負荷を減少させることができる。
【００４０】
《具体例２》
具体例２は、具体例１の構成において、ＰＣＩバス上に接続されているデバイスが拡張ＰＣＩ仕様を有しているか、また、インテリジェントデバイス／ノン−インテリジェントデバイスであるかを識別するようにしたものである。尚、拡張ＰＣＩ仕様とは、ＰＣＩデバイスドライバの初期化時に使用する通信用作業領域を、各機能にマッピングする領域の先頭に設けている仕様を意味するが、これについては、具体例３で説明する。
【００４１】
〈構成〉
図８は、具体例２におけるコンフィグレーションレジスタと拡張ＰＣＩ初期化処理の説明図である。
コンフィグレーションレジスタ（Configuration Register）のフォーマットは、図示のように、その先頭にはデバイスＩＤ（Device ＩＤ）を格納するよう構成されている。本具体例では、このデバイスＩＤの先頭４ビットを、そのコンフィグレーションレジスタを有するデバイスが拡張ＰＣＩ仕様であるか、インテリジェントデバイス／ノン−インテリジェントデバイスかを識別するための値としている。
【００４２】
図９は、本具体例で設定するデバイスＩＤの説明図である。
本具体例では、ＰＣＩコンフィグレーション空間に設けるコンフィグレーションレジスタのデバイスＩＤに、図９に示す拡張ＰＣＩ仕様を設ける。即ち、上位４ビットが１６進数のＡ（１０１０）である場合は、拡張ＰＣＩ仕様のインテリジェントデバイスであり、１６進数の５（０１０１）である場合は、拡張ＰＣＩ仕様のノン−インテリジェントデバイスである。また、それ以外の値の場合は、拡張ＰＣＩ仕様ではないデバイスであることを示している。尚、図中、×××は、Don't Careを示している。
【００４３】
また、図中のDevice ＩＤやVender ＩＤ等、コンフィグレーションレジスタのフォーマット自体は従来と同様であるため、ここでの各用語の説明は省略する。
【００４４】
更に、本具体例では、ＰＣＩバスマスタが、標準のＰＣＩ初期化処理に加えて、拡張ＰＣＩ仕様であるか、インテリジェントデバイス／ノン−インテリジェントデバイスであるかの識別処理を行うよう構成されている。
【００４５】
先ず、標準のＰＣＩ初期化処理を行うためのＰＣＩバスマスタの処理構造について説明する。
標準のＰＣＩ初期化処理は、図８に示すように、大きく分けて、デバイスボード発見処理８１、発見したデバイスの有効化処理８２、メモリ・Ｉ／Ｏ空間割当て処理８３、割り込み設定処理８４の四つから構成されている。
【００４６】
本具体例では、ＰＣＩバスマスタが行う標準のＰＣＩ初期化処理に加え、以下の処理を追加する。
デバイスボード発見処理で、各デバイスのコンフィグレーションレジスタのデバイスＩＤと、ベンダＩＤ（Vender ＩＤ）を確認する処理があるが、その部分に拡張ＰＣＩ仕様がサポートされているかを判断する処理８５と、確認したデバイスがインテリジェントデバイス３であるか、ノン−インテリジェントデバイス４であるかを判断する処理８６を追加する。
【００４７】
即ち、３２ビットからなるデバイスＩＤのうち、先頭４ビットを用いて、拡張ＰＣＩ仕様サポート判断処理８５とインテリジェントデバイス／ノン−インテリジェントデバイス識別処理８６を行う。
【００４８】
〈動作〉
ＰＣＩコンフィグレーション空間に設けるコンフィグレーションレジスタのデバイスＩＤに、図９に示す拡張ＰＣＩ仕様の識別データを格納する。
【００４９】
ＰＣＩバスマスタは、各デバイスのコンフィグレーションレジスタのデバイスＩＤを読み出し、その上位４ビットにより、読み出しているコンフィグレーションレジスタが対応する機能がインテリジェントデバイス３であるかノン−インテリジェントデバイス４であるかを識別する。
【００５０】
図１０は、具体例２の動作フローチャートである。
先ず、ＰＣＩバスマスタは、ＰＣＩコンフィグレーションレジスタのデバイスＩＤを読込み（ステップＳ１０１）、その先頭４ビットが１６進数のＡ（１０１０）であるか比較する（ステップＳ１０２）。
【００５１】
ステップＳ１０２において、１６進数のＡ（１０１０）であった場合は、以降、そのデバイスをインテリジェントデバイスとして扱う（ステップＳ１０３）。一方、ステップＳ１０２において、１６進数のＡ（１０１０）でなかった場合は、１６進数の５（０１０１）であるかを比較する（ステップＳ１０４）。
【００５２】
ステップＳ１０４において、１６進数の５（０１０１）であった場合は、以降、そのデバイスをノン−インテリジェントデバイスとして扱う（ステップＳ１０５）。また、ステップＳ１０２において１６進数のＡ（１０１０）でなく、かつ、ステップＳ１０４において１６進数の５（０１０１）でもない場合、拡張ＰＣＩ仕様をサポートしていないデバイスであるとし、以降、システムからアクセスできないよう切り離し処理を行う（ステップＳ１０６）。
【００５３】
〈効果〉
以上説明したように、具体例２によれば、各デバイスを初期化する際に参照するコンフィグレーションレジスタの予め決められた先頭ビット数を、拡張ＰＣＩ仕様であるか、インテリジェントデバイスかノン−インテリジェントデバイスかを識別するための値としたので、以下のような効果が期待できる。
【００５４】
(1)ＰＣＩバスに接続されるデバイスがインテリジェントデバイスかノン−インテリジェントデバイスかが固定されていない場合でも容易に判別することができる。
(2)コマンド等のレスポンスの有無によって、インテリジェントデバイス／ノン−インテリジェントデバイスを識別する場合に比べて判断に要する時間が短い。
(3)標準のＰＣＩ初期化処理と同一の処理において、拡張ＰＣＩ仕様のデバイスであるかの判定が可能である。
【００５５】
《具体例３》
具体例３は、ＰＣＩデバイスドライバの初期化時に使用する通信用作業領域を、デバイス側に設け、かつ、各機能にマッピングする領域の先頭に設けたものである。
【００５６】
〈構成〉
図１１は、具体例３の説明図である。
コミュニケーションエリア（Communication Area：通信用作業領域）は、拡張ＰＣＩの初期化時にＰＣＩバスマスタと各デバイスの機能間で通信するために使用する領域である。このコミュニケーションエリアは、ＰＣＩバスマスタと各デバイスの機能に対し各々一つ用意する。
【００５７】
ここで、本具体例では、ＰＣＩバスマスタ用には、ＰＣＩ空間の（00000000H）番地に固定的に割り付ける。一方、各デバイスの機能毎には、各機能をマッピングするＰＣＩ空間の先頭アドレスに割り当てる。
【００５８】
即ち、コミュニケーションエリアは、コミュニケーションエリアを持つＰＣＩ機能に対して割り込みを発生させる割り込み要求レジスタ（ＰＣＩInterrupt Register（図中、ＰＩＲで示す））と、コミュニケーションエリアを持つＰＣＩ機能に対しての要求であるコマンドを格納するエリア１（Area１）と、エリア１に格納するコマンドの引数を格納するエリア２（Area２）、エリア３（Area３）からなる。
【００５９】
〈動作〉
図１２は、具体例３のＰＣＩバスマスタからデバイスへのコマンド送信動作の説明図である。
ＰＣＩバスマスタは、送信先デバイスのコミュニケーションエリアのエリア１に、拡張ＰＣＩコマンドを、エリア２、エリア３にコマンドの引数をそれぞれ格納する（図中、▲１▼で示す）。
【００６０】
図１３および図１４は、コマンドの説明図である。
図示のように、ＰＣＩバスマスタからの、受信要求、受信応答、受信否定応答といったコマンドに対する設定値が決められている。尚、“Ｈ→Ｓ”がＰＣＩバスマスタから各デバイスへの送信可能なデータ、“Ｓ→Ｈ”が各デバイスからＰＣＩバスマスタへの送信可能なデータである。また、ノン−インテリジェントデバイス４に対して使用するコマンドは、リセット要求とファクトリーリセット要求のみとなる。
【００６１】
図１２に戻り、ＰＣＩバスマスタは、送信先デバイスのコミュニケーションエリアのＰＩＲに（OOOOOOO1H）を書き込む（図中▲２▼で示す）。これにより、送信先デバイスに対して割り込みが発生する（図中、▲３▼で示す）。送信先デバイスは、割り込み中でコミュニケーションエリアのエリア１から拡張ＰＣＩコマンドを、エリア２、エリア３からコマンドに対応する引数を読み出す（図中▲４▼）。尚、ＰＣＩバスマスタは、各コマンドの送信に対するレスポンスを２秒間でタイムアウトとする。タイムアウトとなった場合は原則として再送は行わない。このため、コマンドを受けたデバイスは２秒以内に応答する必要がある。
【００６２】
図１５は、各インテリジェントデバイスがＰＣＩバスマスタに拡張ＰＣＩコマンドを送信する場合の説明図である。
送信元デバイスは、送信元デバイスのコミュニケーションエリアのエリア１に拡張ＰＣＩコマンドを、エリア２、エリア３にコマンドの引数をそれぞれ格納する（図中、▲１▼）。この場合のコマンドは、図１３、図１４中の“Ｓ→Ｈ”に示した通りである。
【００６３】
送信元デバイスは、送信元デバイスのコミュニケーションエリアのＰＩＲに（OOOOOOO0H）以外の値を書き込む（図中、▲２▼）。図示例では（00000001H）を書き込んでいる。これにより、ＰＣＩバスマスタでは割り込みが発生する（図中、▲３▼）。ＰＣＩバスマスタは、割り込み中でコミュニケーションエリアのエリア１から拡張ＰＣＩコマンドを、エリア２、エリア３からコマンドに対応する引数を読み出す（図中、▲４▼）。
【００６４】
各デバイスは各コマンドの送信に対するレスポンスを２秒間をタイムアウトとする。タイムアウトとなった場合は原則として再送は行わない。コマンドの受信を受けたＰＣＩバスマスタは、２秒以内に応答する必要がある。
【００６５】
〈効果〉
以上説明したように、具体例３によれば、ＰＣＩデバイスドライバの初期化時に使用する通信用作業領域をデバイス側に設け、かつ、各機能にマッピングする領域の先頭に設けるようにしたので、以下のような効果が期待できる。
【００６６】
(1)初期化通信のために使用する領域が、共有メモリの先頭に集中しているため共有メモリを使用しないデバイス（Ｉ／Ｏ空間のみ使用するデバイス）が有っても最小限のメモリ領域を確保することで使用可能となる。
【００６７】
(2)初期化通信のために使用する領域が、共有メモリの先頭に集中しているため、各デバイスのメモリ空間の初期化がし易くなる。即ち、先頭領域を無条件に通信用作業領域として認識すればよいため、初期化処理においてＰＣＩバスマスタ側の、各デバイスとやり取りするための通信用作業領域を決定する処理を簡素化することができる。
【００６８】
(3)コマンド書き込み領域エリア１〜エリア３が各デバイス側にあるため、ＰＣＩバスマスタは各デバイスを独立して初期化することができる。即ち、ＰＣＩバスマスタ側は、各デバイスの応答を待たずに初期化処理を進めることができる。
【００６９】
《具体例４》
具体例４は、送信データのＰＣＩヘッダ中に、次の送信データが連続するか否かを示す連続フラグ（Continue Flag）を設定するようにしたものである。
【００７０】
〈構成〉
図１６は、具体例４の説明図である。
各デバイスには、送信側データ処理部の構成として、送信データ受付部１６１、連続フラグ設定部（Continue Flag設定部）１６２、コマンド送信処理部１６３を、受信側データ処理部の構成として、コマンド判断処理部１６４、連続フラグ判断処理部（Continue Flag判断処理部）１６５、データコピー処理部１６６を備えている。
【００７１】
送信データ受付部１６１は、上位層から送信されるデータを受け取るための機能部である。連続フラグ設定部１６２は、本具体例で新規に追加した機能部であり、後述する連続フラグを設定する機能を有している。
【００７２】
図１７は、本具体例のＰＣＩヘッダの構成図である。
ＰＣＩヘッダ（PCI Header）は、ＰＣＩヘッダ同士をアドレスでつなぎ、リンク構造で管理する場合に使用するネクストポインタ（Next Pointer）と、送信するデータの先頭アドレスを示すデータエリアポインタ（Data Area Pointer）と、送信するデータのサイズを示すデータサイズ（Data Size）の各領域から構成される。そして、本具体例では、ネクストポインタの下位１ビットを、そのデータが連続してコピーされる必要があるのか否かを示すための識別フラグＦ（連続フラグ）として使用するよう構成されている。
【００７３】
連続フラグは、０にセットしてある場合、特に意味を持たないが、１にセットしてある場合、そのＰＣＩヘッダが持つデータ領域と、ネクストポインタでリンクするＰＣＩヘッダの持つデータ領域は連続アドレス空間にコピーされる必要があることを示している。
【００７４】
図１６に戻り、コマンド送信処理部１６３は、上位層から指定されたデバイスに対してデータを送信するためのコマンドを送信する機能部である。
【００７５】
受信側データ処理部におけるコマンド判断処理部１６４は、送信側から送られたコマンドを受信し、その内容を解析する機能部である。連続フラグ判断処理部１６５は、本具体例で新規に追加した機能部であり、送信側データ処理部の連続フラグ設定部１６２に対応する受信側の構成である。データコピー処理部１６６は、受信するデータをコピーする処理を行うための機能部である。
【００７６】
〈動作〉
ＰＣＩバスを経由して通信する上位層は、通常プロトコル層を使用する。プロトコル層は、データを送信する場合に上位層の用意したデータの前にプロトコル層独自のヘッダ情報を添付する。この時、上位層が用意したデータ領域の前の部分は必ずしも未使用領域ではないため、プロトコル層のヘッダが挿入できないという問題点が発生する。
【００７７】
図１８は、この問題の説明図である。
図示のように、プロトコル層がデータを送信する際にヘッダ情報の領域が空いていない場合、上位層の送信データを他の空きエリアにコピーし、その領域にヘッダ情報を付与する。ところが、このような手段を取る場合、上位層の送信データは概して大量である場合が多いため、大量であることを前提とする設計が必要である。これに対して、本具体例では、以下に示すような処理を行うことにより、このような上位層の大量のデータをコピーすることなくヘッダ情報を挿入することが可能である。
【００７８】
図１９は、具体例４の動作を示す説明図である。
図２０は、具体例４におけるデータ送信の概念を示す説明図である。
【００７９】
図１９に示すように送信側が受信側に対して「受信要求」を示すコマンドを送信し、受信側は指定されたデータをコピーする。コピー後、送信側に対して「受信応答」を示すコマンドを送信する。
【００８０】
送信側が受信側に対して受信を要求する場合に、指定するデータの先頭アドレスとサイズを通知する必要がある。そこで、本具体例では、図１７に示したようなＰＣＩヘッダを使用し、送信するデータを受信側に通知する。
【００８１】
連続フラグは、０にセットしてある場合、特に意味を持たないが、１にセットしてある場合、そのＰＣＩヘッダが持つデータ領域と、ネクストポインタでリンクするＰＣＩヘッダの持つデータ領域は連続アドレス空間にコピーされる必要があることを示している。
【００８２】
図２０に示した例では、プロトコル層のヘッダ情報がデータ領域（Ａ）、上位層の送信データがデータ領域（Ｂ）となる。ここで、連続フラグがＯＮ（＝１）であるため、受信側では、連続アドレスにコピーする。
【００８３】
一方、連続アドレスにコピーする必要のないものは、連続フラグをＯＦＦ（＝０）とする。これにより受信側では、所定のアドレスにデータをコピーする。
【００８４】
また、上位層が送信するデータサイズには通常制限は存在しないが、プロトコル層の１回の送信サイズには制限があることが多い。よって、上位層の送信データを複数に分割して送信する必要がある。このような場合でも受信側としては受信データが分割せず、連続した領域に一つの固まりとして受信できることが必要な場合も多い。従って、このような場合においても、本具体例により上位層の大量なデータをコピーすることなく受信側へ効率のよい転送を行うことが可能となる。
【００８５】
例えば、図示例では、データ領域（Ｂ）の連続フラグをＯＮ（＝１）にし、更に、ネクストポインタにデータ領域（Ｃ）を管理するＰＣＩヘッダをリンクさせ、更にデータ領域（Ｄ）を管理するＰＣＩヘッダをリンクさせる（データ領域（Ｃ）とデータ領域（Ｄ）は図示省略している）。送信する上位層のデータを前半部と後半部の二つに分割して送付すると仮定した場合、データ領域（Ｄ）を管理するＰＣＩヘッダの連続フラグはＯＦＦ（＝０）となり、データ領域（Ａ）とデータ領域（Ｃ）がプロトコルヘッダ情報で、データ領域（Ｂ）が上位層データ前半部、データ領域（Ｄ）が上位層データ後半部となる。
【００８６】
尚、図１９に示すように、本具体例では、受信側が送信側から「受信要求」コマンドを受信し、データブロックをコピーするが、コピーに失敗し、何回かリトライしてもコピーが成功しない場合、受信側から「受信否定応答」コマンドを送信する。送信側からこの「受信応答」コマンドを受信した場合、データを修復できない場合は、送信を断念する。
【００８７】
〈効果〉
以上説明したように、具体例４によれば、ＰＣＩヘッダ情報としてネクストポインタの下位ビットを連続データの識別を行うビットとしたので、以下のような効果が期待できる。
【００８８】
(1)ＰＣＩバスを経由して通信する上位層は通常プロトコル層を使用する。この場合において、上位層の大量なデータをコピーすることなく、プロトコル層のヘッダ情報を上位層データの前の領域に挿入することが可能となる。
【００８９】
(2)上位層の大量なデータをコピーすることなく、送信側の連続したデータを受信側へ連続した一つのデータとして転送することができ、受信側の効率のよい処理を助けることが可能となる。
【００９０】
(3)本具体例のＰＣＩヘッダを使用することにより、受信側はネクストポインタを先行して辿ることにより、受信用の連続空間として必要なサイズをコピー前に知ることができる。
【００９１】
《具体例５》
具体例５は、各機能間の通信を共通の手順で行うためのデバイス管理用テーブルの構造に関するものである。
【００９２】
〈構成〉
図２１は、具体例５の構成および処理の説明図である。
ＰＣＩバスを経由して接続している複数のデバイス上に機能（Func）０〜機能（Func）５までの６個の機能が搭載されているとする。そのそれぞれの機能に対して、次に示すような構造を持つデバイスプロファイルを配列構造で機能数分だけ割り当てる。
【００９３】
図２２は、デバイスプロファイルの構造図である。
図示のように、デバイスプロファイルは、各機能の種類を識別するためのClassCodeと、デバイスプロファイルのバージョンを特定するRev.と、送信先のメールボックス（Mail Box）の先頭アドレスを特定するメールボックスポインタ（&Mail Box）と、送信先処理に割り込みを発生させる割り込み要求レジスタの先頭アドレスである割り込み要求レジスタポインタ（&PIR：以下、ＰＩＲポインタという）と、自分宛のコマンドとその引数を格納するメールボックス（Mail Box）と、コンフィグ アドレス フォーマット（CONFIG_ADDRESS Farmat）と、フリーエリア（FREE Area）で構成されている。
【００９４】
次に、メールボックスポインタ（&Mail Box）の構造について説明する。
図２３は、メールボックスポインタの構造を示す説明図である。
図示のように、各機能に対して割り当てられたデバイスプロファイルの配列は、全システム内に存在する機能（Func）の数と同数であり、配列の添え字（０〜５）は機能番号（Func0〜Func5）に対応している。
【００９５】
従って、例えば、機能４に割り当てられたデバイスプロファイルの配列を例に取ると、デバイスプロファイル［０］のメールボックスポインタ（&Mail Box）は、機能０のデバイスプロファイル［４］のメールボックス（Mail Box）の先頭アドレスを指す。
【００９６】
以下、同様に、
デバイスプロファイル［１］のメールボックスポインタは、機能１のデバイスプロファイル［４］のメールボックスの先頭アドレスを指す。
デバイスプロファイル［２］のメールボックスポインタは、機能２のデバイスプロファイル［４］のメールボックスの先頭アドレスを指す。
デバイスプロファイル［３］のメールボックスポインタは、機能３のデバイスプロファイル［４］のメールボックスの先頭アドレスを指す。
デバイスプロファイル［４］のメールボックスポインタは、機能４のデバイスプロファイル［４］のメールボックスの先頭アドレスを指す。
デバイスプロファイル［５］のメールボックスポインタは、機能５のデバイスプロファイル［４］のメールボックスの先頭アドレスを指す。
【００９７】
即ち、機能Ｘのデバイスプロファイル［Ｙ］のメールボックスポインタは、機能Ｙのデバイスプロファイル［Ｘ］のメールボックスの先頭アドレスを示している。つまり、各機能は、お互いに他の機能に対するメールボックスを持つよう構成されている。
【００９８】
次に、ＰＩＲポインタ（&PIR）の構造を説明する。
図２４は、ＰＩＲポインタの構造を示す説明図である。
機能４に割り当てられたデバイスプロファイルの配列を例に取ると、デバイスプロファイル［０］のＰＩＲポインタは、機能０のＰＩＲの先頭アドレスを指す。
【００９９】
以下、同様に、
デバイスプロファイル［１］のＰＩＲポインタは、機能１のＰＩＲの先頭アドレスを指す。
デバイスプロファイル［２］のＰＩＲポインタは、機能２のＰＩＲの先頭アドレスを指す。
デバイスプロファイル［３］のＰＩＲポインタは、機能３のＰＩＲの先頭アドレスを指す。
デバイスプロファイル［４］のＰＩＲポインタは、機能４のＰＩＲの先頭アドレスを指す。
デバイスプロファイル［５］のＰＩＲポインタは、機能５のＰＩＲの先頭アドレスを指す。
【０１００】
即ち、いずれかの機能のデバイスプロファイル［Ｘ］のＰＩＲポインタは、機能ＸのＰＩＲの先頭アドレスを示している。つまり、各機能はお互いに他の機能に対するＰＩＲポインタを持つよう構成されている。
【０１０１】
次にメールボックスの構造について説明する。
図２５は、メールボックスの構造を示す説明図である。
機能４に割り当てられたデバイスプロファイルの配列を例に取ると、機能０から機能４へのコマンド通知は、デバイスプロファイル［０］のメールボックスに対して行われる。尚、図中、デバイス１（Device１）中のデバイスプロファイル（Device Profile）は、機能４のデバイスプロファイルを示している。
【０１０２】
以下、同様に、
機能１から機能４へのコマンド通知は、デバイスプロファイル［１］のメールボックスに対して行われる。
機能２から機能４へのコマンド通知は、デバイスプロファイル［２］のメールボックスに対して行われる。
機能３から機能４へのコマンド通知は、デバイスプロファイル［３］のメールボックスに対して行われる。
機能４から機能４へのコマンド通知は、通常発生しないが、デバイスプロファイル［４］のメールボックスに対して行われる。
機能５から機能４へのコマンド通知は、デバイスプロファイル［５］のメールボックスに対して行われる。
【０１０３】
即ち、機能Ｘから機能Ｙへのコマンド通知は、機能Ｙのデバイスプロファイル［Ｘ］のメールボックスに対して行われる。つまり、各機能は、お互いに自身に持つ他の機能宛のメールボックスにコマンド通知を行うよう構成されている。
【０１０４】
〈動作〉
図２６は、具体例５の動作フローチャートである。
送信側デバイスの機能は、送信先デバイスの機能が持つメールボックスのアドレスを調べる（ステップＳ２６１）。調べたメールボックスアドレスに対してメールを投函する（ステップＳ２６２）。次に、メールボックスのＭＢＡｒｅａ１にＰＣＩコマンドを格納し、ＭＢＡｒｅａ２にＭＢＡｒｅａ１に格納したＰＣＩコマンドに対応する第一引数を格納し、ＭＢＡｒｅａ３に第二引数を格納する処理をメールボックスにメールを投函すると定義する。
【０１０５】
次に、送信先に割り込みを発生させ、メールボックスに格納したコマンドを受信させるために、送信先のＰＩＲ先頭アドレスを調べる（ステップＳ２６３）。調べたＰＩＲアドレスに対して０以外の数値を書き込む（ステップＳ２６４）。このオペレーションにより、送信先に対して割り込みが発生する。
【０１０６】
受信側では、割り込みが発生すると送信元の機能を識別する（ステップＳ２６５）。通常、デバイスプロファイルのメールボックスをデバイスプロファイル［０］から順にチェックする等の処理を行う。
【０１０７】
次に、メールボックスに書き込まれているＰＣＩコマンドを解析し、コマンドの内容に沿った処理に分岐する（ステップＳ２６６）。仮に、データの受信要求であった場合は、ＭＢＡｒｅａ２より第一引数としてデータの先頭アドレスを読み出し、ＭＢＡｒｅａ３より第二引数としてデータのサイズを読み出し、自分のワークエリアに対してコピーする（ステップＳ２６７）。
【０１０８】
次に、上記ステップＳ２６１の送信先デバイス上の機能に対応するメールボックスアドレスの調べ方を説明する。
【０１０９】
図２７は、送信先デバイス上の機能に対応するメールボックスアドレスの調べ方の説明図である。
通信先のメールボックスアドレスは、通信元が持っているデバイスプロファイル一式の中に存在している。通信元のデバイスプロファイル一式中で、送信先に対応するデバイスプロファイル中に、送信先のデバイスプロファイル一式中で送信元に対応するデバイスプロファイルのメールボックスアドレスが格納されている。
【０１１０】
例えば、機能４から機能０に対してＰＣＩコマンドを送信する場合を例とすると、機能０に割り当てられているデバイスプロファイル配列のデバイスプロファイル［４］中のメールボックスの先頭アドレスを格納している。よって、機能４は機能０に対してＰＣＩコマンドを送信する場合は、自分に割り当てられているデバイスプロファイル［０］のメールボックスポインタを参照することにより、目的のメールボックスアドレスを得ることができる。
【０１１１】
次に、上記ステップＳ２６２のメールボックスへのメールを投函する処理を説明する。
図２８は、そのメールボックスへのメール投函処理の説明図である。
【０１１２】
ここで、機能４が機能３に対してデータを送信するためにメールを送信する場合を例とする。
機能４は機能３が割り当てられたデバイスプロファイル配列のデバイスプロファイル［４］中のメールボックスに対して、ＭＢＡｒｅａ１に「受信要求」を示すコマンドを、ＭＢＡｒｅａ２に送信データ先頭アドレスを、ＭＢＡｒｅａ３に送信データサイズを格納する。
【０１１３】
次に、上記ステップＳ２６３の送信先デバイス上の機能に対応するＰＩＲアドレスの調べ方を説明する。
図２９は、その送信先デバイス上の機能に対応するＰＩＲアドレスの調べ方の説明図である。
【０１１４】
通信先のＰＩＲアドレスは、通信元が持っているデバイスプロファイル一式の中に存在している。通信元のデバイスプロファイル一式中で、送信先に対応するデバイスプロファイル中にＰＩＲアドレスは格納されている。
【０１１５】
機能４から機能０に対してＰＣＩコマンドを送信する場合を例とすると、機能０が割り当てられているデバイスプロファイル配列のデバイスプロファイル［０］中のＰＩＲポインタ（&PIR）を参照することにより、機能４は機能０に対して割り込みを発生させることが可能となる。
【０１１６】
〈効果〉
以上のように、具体例５によれば、各機能間の通信を共通の手順で行うためのデバイス管理用テーブルを備えるようにしたので、以下のような効果が期待できる。
【０１１７】
図３０は、具体例５の効果の説明図である。
(1)図３０に示すような接続環境において任意の機能からＰＣＩバスマスタ上の機能への通信、複数機能を搭載するデバイス上のそれぞれの機能への通信、単一機能を搭載するデバイス上の機能への通信、そして、自デバイス上の他の機能への通信を共通の手順で実現することが可能となる。
【０１１８】
(2)デバイス間の通信において必ずＰＣＩバスマスタを経由しなければならない必要がないため、ＰＣＩバスマスタの通信における負荷を減少させることができる。
【０１１９】
《具体例６》
具体例６は、具体例５におけるデバイス管理用テーブルの作成手段に関するものである。
【０１２０】
〈構成〉
図３１は、具体例６の構成および処理を示す説明図である。
図示のように、ＰＣＩバスマスタは、コピー先アドレス問い合わせ処理部３１１と、メールボックスポインタ計算処理部３１２を備えている。
【０１２１】
コピー先アドレス問い合わせ処理部３１１は、各インテリジェントデバイスの機能に対して、配布するデバイスプロファイルのサイズと個数とを通知することによりコピーする先頭アドレスを入手する機能を有している。また、メールボックスポインタ計算処理部３１２は、コピー先アドレス問い合わせ処理部３１１で求めたコピーする先頭アドレスに基づき、配布するデバイスプロファイルのメールボックスポインタを求める機能を有している。
【０１２２】
〈動作〉
本具体例では、具体例５で説明したデバイスプロファイル配列の作成をより効率的に行うようにしたものである。
【０１２３】
デバイスプロファイル配列一式の作成は、全てＰＣＩバスマスタで行う。ＰＣＩバスマスタは、各デバイスプロファイル配列作成後に、各インテリジェントデバイスに対してデバイスプロファイル配列を割り当てる。
【０１２４】
以下、メールボックスポインタの決定方法についてその手順を説明する。メールボックスポインタの決定は以下の手順で行う。
(1)デバイスプロファイル配列のコピー先アドレス問い合わせ処理
(2)メールボックスポインタ計算処理
【０１２５】
先ず、コピー先アドレス問い合わせ処理部３１１が行うデバイスプロファイル配列コピー先アドレス問い合わせ処理について説明する。
図３２は、デバイスプロファイル配列のコピー先アドレス問い合わせ処理の説明図である。
図３３は、デバイスプロファイル配列のコピー先アドレス回答処理の説明図である。
【０１２６】
ＰＣＩバスマスタは、自分の管理するＰＣＩバス上に存在する全てのインテリジェントデバイスに対して図３２に示す手順でデバイスプロファイル配列のコピー先アドレスを問い合わせる。
【０１２７】
ＰＣＩバスマスタは、割り当てるべきデバイスプロファイル配列中のデバイスプロファイルの個数と、デバイスプロファイル配列全体のサイズを割当先インテリジェントデバイスへ通知する。この通信手順は、具体例３で説明した方法を使用した例である。
【０１２８】
次に、ＰＣＩバスマスタよりデバイスプロファイルに関する情報を受け取ったインテリジェントデバイスは、図３３に示す手順で、デバイスプロファイル配列のコピー先アドレスを回答する。本通信手順も具体例３で説明したものを使用した例である。
【０１２９】
図３４は、メールボックスポインタ計算処理の説明図である。
先ず、図３４において、ＰＣＩバスマスタが全てのデバイスプロファイル配列のメールボックスポインタを求める概念について説明する。
【０１３０】
ＰＣＩバスマスタは、ＰＣＩバスに接続している全機能に対してデバイスプロファイル配列を作成する。例として、機能１（Func１）用のデバイスプロファイル配列を作成する場合を想定する。
【０１３１】
先ず、デバイスプロファイル［０］のメールボックスポインタを、デバイスプロファイル［１］は自分用なので省略し、次にデバイスプロファイル［２］のメールボックスポインタを、そして全機能分のメールボックスポインタを決定する。
【０１３２】
例として、デバイスプロファイル［２］のメールボックスポインタを設定する場合を想定する。
先ず、デバイスプロファイル［２］は、機能２（Func２）に送信する場合のメールボックスのアドレスでなければならないため、デバイスプロファイル配列を機能２にコピーしたと仮定する（図中、▲１▼で示す）。次に、機能１が各機能にＰＣＩコマンドを送信する場合は、各機能が持つデバイスプロファイル配列の１番に書き込むわけなので、デバイスプロファイル［１］が対象となる（図中、▲２▼で示す）。
【０１３３】
機能２にコピーした場合のデバイスプロファイル［１］中のメールボックスポインタのアドレスを求める（図中、▲３▼で示す）。求めたアドレスは作成中の機能１用に割り当てるデバイスプロファイル［２］におけるメールボックスポインタに格納する（図中、▲４▼で示す）。
【０１３４】
本具体例では、図中の▲１▼で示す「デバイスプロファイル配列を機能２にコピーしたと仮定する」処理を、デバイスプロファイル配列コピー先アドレスを問い合わせることにより求めている。
【０１３５】
次に、ＰＣＩバスマスタの具体的なメールボックスポインタの設定手順を説明する。
図３５は、ＰＣＩバスマスタの具体的なメールボックスポインタの設定手順を示す説明図である。
先ず、作成するデバイスプロファイル配列を割り当てる機能番号をカレント番号としてＸに設定する（ステップＳ３５１）。次に、最後の機能分の作成が終了したかを判断する（ステップＳ３５２）。ここで、全機能分のデバイスプロファイル配列の作成が終了した場合は本処理を終了する。
【０１３６】
現在カレントになっている機能のデバイスプロファイル配列が全て作成終了しているかを判断する（ステップＳ３５３）。ここで、デバイスプロファイル配列の作成が終了している場合は、ステップＳ３５７に移行する。
【０１３７】
作成するデバイスプロファイルが対応する機能が、インテリジェントデバイスであるかノン−インテリジェントデバイスであるかを判断する。即ち、機能１に対応するデバイスプロファイルはデバイスプロファイル［１］、機能２に対応するデバイスプロファイルはデバイスプロファイル［２］である。
【０１３８】
ステップＳ３５４において、対応する機能がノン−インテリジェントデバイスである場合はステップＳ３５６に移行する。一方、ステップＳ３５４において、対応する機能がインテリジェントデバイスである場合は、メールボックスアドレスを算出し、デバイスプロファイルのメールボックスポインタに格納する（ステップＳ３５５）。現在カレントになっている機能番号をＸ、デバイスプロファイルのサイズをＺ、デバイスプロファイルの先頭からメールボックスまでのオフセットをＭ、現在処理しているデバイスプロファイル配列の添え字をｙとし、前工程で機能ｙから受信したデバイスプロファイル配列コピー先アドレスをＹとすると、メールボックスアドレスは以下の式で求められる。
【０１３９】
＆Ｍａｉｌ Ｂｏｘ＝ＸＺ＋Ｙ＋Ｍ
そして、次のデバイスプロファイルへと移動し（ステップＳ３５６）、その後、ステップＳ３５３に戻る。ここで、移動は、同一の機能用に作成しているデバイスプロファイル配列中で一つ増加する方向へ移る。
【０１４０】
ステップＳ３５３において、デバイスプロファイルの残りがなかった場合、作成しているデバイスプロファイル配列を割り当てる機能を次に移動する（ステップＳ３５７）。移動は、デバイスプロファイルの添え字を０に戻し、機能番号を一つ増加する方向へ移る。その後、ステップＳ３５２に移行する。
【０１４１】
〈効果〉
以上のように、具体例６によれば、ＰＣＩバスマスタがデバイス管理用テーブルを作成して各インテリジェントデバイスに配布するようにしたので、次のような効果が期待できる。
【０１４２】
(1)全てのデバイスプロファイルの初期化をＰＣＩバスマスタが行うため、各々のデバイスの開発が容易となる。
(2)デバイスプロファイルの構造に項目が追加された場合でも、ＰＣＩバスマスタ以外のデバイスの処理を変更する必要がない。
【０１４３】
《具体例７》
具体例７は、具体例５における割り込み要求レジスタ（ＰＩＲ）のビットを各機能に割り当てるようにしたものである。
【０１４４】
〈構成〉
図３６は、具体例７の割り込み要求レジスタの構成図である。
具体例７は、具体例５の構成に加えて、図３６に示すような割り込み要求レジスタを備えたものである。
【０１４５】
割り込み要求レジスタ（ＰＩＲ）は、最上位ビット３１がセット・クリアを示すフラグとなっており、ビット０〜ビット３０のいずれかに１をセットし、最上位ビット３１に１をセットすることによりビット０〜ビット３０に対してセットした１が反映され、このＰＩＲが持つシステムに対して割り込みを発生させるよう構成されている。
【０１４６】
一度、ビット０〜ビット３１に対して反映された１は、反映されたビットを１にし、最上位ビット３１に０をセットすることにより、０にクリアすることができるよう構成されている。このような仕様を持つ割り込み要求レジスタを各インテリジェントデバイスに対して一つ設ける。
【０１４７】
〈動作〉
具体例５で説明したメールボックスを使用する通信方法を使用した場合を例として以下に説明する。
図３７は、送信側が行うＰＣＩの割り込み要求レジスタの使用方法の説明図である。
図示例では、機能４（Func４）が機能３（Func３）にコマンドを通知する処理を例としている。
【０１４８】
先ず、機能４を持つインテリジェントデバイスは、送信するデータの情報（「受信要求」を示すコマンド、データの先頭アドレス、データのサイズ）を規定されたメールボックスに対して格納する。
【０１４９】
次に、格納したことを機能３に通知するために機能３が持つＰＩＲに対して決められた値を書き込む。ＰＩＲに０以外の値が書き込まれたことにより機能３に割り込みが発生する。
【０１５０】
図３８は、ＰＩＲの各ビットにおける意味づけの説明図である。
ＰＩＲの各ビットは、同一ＰＣＩバス上に接続された各機能にそれぞれ対応している。ビット０が機能０に、ビット１が機能１に、ビット２が機能２にといったように、以下同様にしてビット３０が機能３０の機能に対応する。但し、この対応は、ハードウェア的な結線とは関係なくソフトウェア上で対応させている状態を示す。
【０１５１】
更に、ＰＩＲの仕様として、ビット０〜ビット３０は各機能に対応しているが、ビット３１は〈構成〉の項で説明したように、ビット０〜ビット３０に対してセットされた１のデータが割り込みを要求するものか、解除するものかを指定するビットとなっている。ビット０〜ビット３０に対する０の書き込みは何の意味もなさない。よって、このレジスタが、（00000000 00000000 00000000 10010000）である時に、（10000000 00000000 00000000 00000001）を書き込んだ時には（00000000 00000000 00000000 10010001）となる構造を持つ。即ち、セット時は各ビットのＯＲとなる。
【０１５２】
尚、クリア時はビット０〜ビット３０のうち、１のデータのビットがクリアされる。例えば、図示のように、（X0000000 00001000 10001000 10001000）である時に、（00000000 00000000 00000000 11111111）を書き込んだ時には、ビット０〜ビット７の値がクリアされるため、（X0000000 00001000 10001000 00000000）となる。
【０１５３】
次に、送信先のＰＩＲに書き込む決められた値を説明する。
図３９は、送信先のＰＩＲに書き込む決められた値を示す説明図である。
機能１が他の機能に対して割り込みを入れる場合は、固定的にビット１とビット３１のみを１にしたデータを割り込み先のＰＩＲに対して書き込む。このことにより、受信側で割り込み要求を出した機能を特定することが可能となる。
【０１５４】
機能の番号は、初期化時にＰＣＩバスマスタより配布されたデバイスプロファイル配列とした時の添え字に該当する。よって、ダイナミックに割り当てられる数値である。
【０１５５】
受信側が行うＰＣＩの割り込み要求レジスタの使用方法を説明する。
図４０は、その受信側が行うＰＣＩの割り込み要求レジスタの使用方法の説明図である。
【０１５６】
図４０では、割り込みが発生するとＰＩＲの値を読み込む。ＰＩＲ中のデータは、図３９に示すように割り込みの要求元を示している。機能４により割り込みが要求された場合は、ＰＩＲのビット４が１にセットされている。機能３は、ＰＩＲのビット４が１にセットされていることにより、割り込みの要求元が機能４であることを知ることができる。
【０１５７】
機能３は、割り込みの要求元が機能４と分かることにより、機能４が対応するデバイスプロファイル［４］のメールボックスにコマンドを格納していることを知り、コマンドを読み出し、コマンドの解析処理へ移行する。
【０１５８】
また、機能３の割り込み処理が起動した時点で、複数の機能から割り込み要求が極めて短い時間に発生した場合に複数のビットが１にセットされている可能性がある。このような場合にも本具体例は対応することができる。
【０１５９】
〈効果〉
以上のように、具体例７によれば、ＰＩＲの各ビットを、それぞれ各機能と一意に対応づけるようにしたので、以下のような効果が期待できる。
【０１６０】
(1)コマンドを受信したデバイス（機能）は、ＰＩＲをチェックするだけでコマンド送信元のデバイス（機能）を特定することができる。
(2)複数の機能から割り込み要求が極めて短い時間に発生した場合に複数のビットが１にセットされている可能性があるが、特別な対応なく同じ手順で対応することができる。
【０１６１】
《具体例８》
具体例８は、ＰＣＩヘッダ中に、次の送信データの情報と、データエリアのポインタと、データサイズとを備えるようにしたものである。
【０１６２】
〈構成〉
図４１は、具体例８におけるＰＣＩヘッダの構成図である。
ＰＣＩヘッダ（PCI Header）は、ＰＣＩヘッダ同士をアドレスでつなぎ、リンク構造で管理する場合に使用するネクストポインタ（Next Pointer）と、送信するデータの先頭アドレスを示すデータエリアポインタ（Data Area Pointer）と、送信するデータのサイズを示すデータサイズ（Data Size）の各領域から構成される。尚、このＰＣＩヘッダの構造は具体例４で説明したＰＣＩヘッダと基本的に同様である。
【０１６３】
〈動作〉
図４２は、本具体例の動作の基本的概念を示す説明図である。
データ送信側のインテリジェントデバイスは、受信側のインテリジェントデバイスに対して送信するデータの情報（データ先頭アドレス、データサイズ）と共にデータ「受信要求」を示すコマンドを送信する。
【０１６４】
受信側は、「受信要求」を示すコマンドを認識すると、データの情報（データ先頭アドレス、データサイズ）を元にデータのコピーを行う。データのコピー後、受信側は受信完了を送信側に対して連絡するため「受信応答」を示すコマンドを送信する。
【０１６５】
以上のようなコマンドによる逐次転送が基本となっている。よって、送信側は、送信したコマンドに対する応答が受信側より来る前に次のコマンドを送信することができない仕組みになっている。この仕組みの長所は確実なデータ転送ができる点にあるが、データの高速転送には不向きである。
【０１６６】
そこで、本具体例では、上記の長所を失うことなく高速な転送手段を提供する。先ず、本具体例で使用するＰＣＩデータの構造を図４１を用いて説明する。
【０１６７】
本具体例のＰＣＩ通信では、直接データを扱わず、図に示すＰＣＩヘッダを使用しデータを管理する。ＰＣＩヘッダは、データを先頭アドレスとデータサイズにより管理する。更に、上述したように、ＰＣＩヘッダ同士をリンクするネクストポインタを含む構造を持っている。
【０１６８】
以上説明したデータ管理方法を使用し、高速転送を行う手順を以下に説明する。
送信側は、一つの「受信要求」を示すコマンドに対する「受信応答」を示すコマンドを受信するまでは、上位層より送信要求が来ても同一の受信側に対しては「受信要求」を発信することはできない。
【０１６９】
図４３は、このような連続送信時の送信側のシーケンスを示す説明図である。
送信元ＰＣＩデバイスドライバは、最初の送信データ（１）を上位層から受け付けると、ＰＣＩヘッダをデータ（１）にリンクさせる（図中、▲１▼で示す）。この時点でＰＣＩヘッダには０を代入する。
【０１７０】
送信元ＰＣＩデバイスドライバは、受信側デバイスドライバに対して「受信要求」コマンドを送信する（図中▲２▼で示す）。送信元デバイスドライバは、受信側デバイスドライバからの「受信応答」コマンドを受信する前に次の送信データ（２）を上位層より受け付けると、ＰＣＩヘッダをデータ（２）にリンクさせ（図中、▲３▼で示す）、データ（１）を管理しているＰＣＩヘッダのネクストポインタをデータ（２）を管理しているＰＣＩヘッダの先頭にリンクさせる（図中、▲４▼で示す）。送信元デバイスドライバは、受信側デバイスドライバから「受信応答」コマンドを受信する前に更に次の送信データ（３）を上位層より受け付けると、ＰＣＩヘッダをデータ（３）にリンクさせ、データ（２）を管理しているＰＣＩヘッダのネクストポインタをデータ（３）を管理しているＰＣＩヘッダの先頭にリンクさせる（図中、▲６▼で示す）。以上のように、受信側ＰＣＩデバイスドライバからの「受信応答」コマンドを受信するまでこのような操作を繰り返す。
【０１７１】
以上の処理では、受信側がネクストポインタを見るタイミングにより、リンクしたことが受信側に認識されない場合が発生する。このような場合を次に説明する。
【０１７２】
図４４は、リンクしたことが受信側に認識されない場合の説明図である。
図において、▲６▼のタイミングと前後して受信側からデータ（２）まで受信完了したことを示す「受信応答」コマンドを受信すると（図中、▲７▼で示す）、送信側インテリジェントデバイスは、データ（３）からの「受信要求」コマンドを送信する（図中、▲８▼で示す）。送信側は以上の処理が全てとなる。
【０１７３】
次に、連続送信時の受信側のシーケンスを説明する。
図４５は、連続送信時の受信側のシーケンスを示す説明図である。
受信側のＰＣＩデバイスドライバは、送信側ＰＣＩデバイスドライバから「受信要求」コマンドを受信すると（図中、▲１▼で示す）、コマンドの引数であるＰＣＩヘッダの先頭アドレスと、ＰＣＩヘッダのサイズからＰＣＩヘッダのコピーを行う（ステップＳ４５１）。送信側上位層からの送信データの情報（先頭アドレス、データサイズ）は、ＰＣＩヘッダ中で管理されているため、ＰＣＩデバイスドライバ間でやり取りするコマンドの引数はＰＣＩヘッダの情報となる。
【０１７４】
次に、受信側のＰＣＩデバイスドライバは受信したＰＣＩヘッダの管理する情報からデータの（１）の先頭アドレスとデータサイズを読み出す（ステップＳ４５２）。そして、その情報に従いデータをコピーする（ステップＳ４５３）。
【０１７５】
受信側のＰＣＩデバイスドライバは、受信したＰＣＩヘッダの管理する情報からネクストポインタを読み出しＮＵＬＬであるか判断する（ステップＳ４５４）。ＮＵＬＬである場合は後続のデータが存在しないことを意味するので、ステップＳ４５８に移行する。ＮＵＬＬでない場合は、後続のデータが存在することを意味するので、ステップＳ４５５に移行する。受信側のＰＣＩデバイスドライバは、受信したＰＣＩヘッダの管理する情報からデータ（２）の先頭アドレスとデータサイズを読み出す（ステップＳ４５６）。そして、その情報に従いデータをコピーする（ステップＳ４５７）。
【０１７６】
受信側のデバイスドライバは、以上の工程で「受信要求」コマンドを受信してから一定時間内に「受信応答」コマンドを送信する必要がある。図では、データ（２）を受信したところでタイムアウトが迫ったため、データ（３）の受信をあきらめ、応答を送信側ＰＣＩデバイスドライバへ返している（ステップＳ４５８）。
【０１７７】
また、ステップＳ４５４と同様の判断を各データコピーの完了時に行い、ＰＣＩヘッダのネクストポインタがＮＵＬＬである場合も応答の送信を行う。
【０１７８】
また、ＰＣＩヘッダのネクストポインタを次々に先読みし、予め受信するデータの総容量を見積り、その後にデータをコピーする手段をとることもできる。
【０１７９】
図４６は、予め受信するデータの総容量を見積り、その後にデータをコピーする場合の説明図である。
即ち、図示のように、受信側ＰＣＩデバイスドライバでは、ネクストポインタが０となるまでＰＣＩヘッダをコピーし（ステップＳ４６１〜ステップＳ４６４）、その後データをコピーする（ステップＳ４６５〜ステップＳ４６８）。尚、ネクストポインタが０か、コマンド受信から２秒以内に受信応答を行う（ステップＳ４６９）のは、上記の連続送信時の受信側のシーケンスと同様である。
【０１８０】
また、受信側の都合により、一つのコマンド・レスポンスに対して一つのデータを送受信することも問題なくできる。
つまり、本具体例の通信方式では受信側の受信方法を柔軟に作成することができる。これは、様々なデバイスを接続しなければならないＰＣＩバス間の通信方法としては重要な項目である。
【０１８１】
〈効果〉
以上のように、具体例８によれば、ＰＣＩヘッダ中に、次の送信データの情報と、データエリアのポインタと、データサイズとを備えるようにしたので、以下に示すような効果が期待できる。
【０１８２】
(1)一つのデータブロック転送において、一組のコマンド・レスポンスを必要としないため、高速なデータ転送を実現することができる。
(2)一定時間毎にレスポンスを出すことのみが決まっているだけであるため、受信側の受信方法を柔軟に作成することができる。これは、様々なデバイスを接続しなければならないＰＣＩバス間の通信方法としては重要な項目である。
【０１８３】
《具体例９》
具体例９は、自層の処理を行うヘッダ情報中に、ヘッダのサイズを示す情報と、ヘッダ情報のバイト数が特定の値の倍数となるような可変長のデータであるパディングとを付加するようにしたものである。
【０１８４】
〈構成〉
具体例１の構成において、ＰＣＩデバイスドライバの上位層としてゲート層を定義する。
【０１８５】
図４７は、ゲートヘッダの説明図である。
ゲートヘッダ（Gate Header）が付いたデータをゲートパケット（Gate Packet）として図示の構成をとる。ゲートヘッダは、ヘッダテールに上位層データの境界を調節するパディング（Padding）領域と、そのパディング領域を含めたゲートヘッダサイズを示すヘッダサイズ（Header Size）領域を持つことを特徴とする。
【０１８６】
図４８は、ヘッダサイズ領域の説明図である。
図示のように、ゲートヘッダは、ヘッダテールに上位層データの境界を調節するパディング領域と、このパディング領域を含めたゲートヘッダサイズを示すヘッダサイズ領域を持つ。
【０１８７】
〈動作〉
通常、階層構造で構成されている通信システムでは、送信データは、上位層データと、プロトコル層のヘッダ情報と、下位層（デバイスドライバ等）ヘッダとがアドレス的に接した構造をとっている。
【０１８８】
図４９は、パディング無しとパディングありの場合の説明図であり、（ａ）はパディング無し、（ｂ）はパディングありの場合である。
図の（ａ）に示すような階層構造で構成されている場合、プロトコル層で選択されるプロトコルによってヘッダのサイズが４バイト境界に揃わない場合が多い。これにより、上位層データが４バイト境界に揃わなくなり、このようなデータを受信した上位層は、ＤＭＡ等の高速データ転送手段が使用できなくなる。
【０１８９】
本具体例では、下位層と上位層（プロトコル層）との通信経路を制御するゲート層をデバイスドライバとプロトコル層の間に設け、そのヘッダ構造にパディング領域を設ける。このパディング領域を使用することにより、プロトコル層のヘッダ情報部のサイズに関係なく、全データ若しくは上位層データの開始位置を４バイト境界に揃えることができる。
【０１９０】
送信側動作について以下に説明する。
通常の送信手順では、４バイト境界に沿って上位層が送信データを作成する。次に上位層データの前部に接するようにプロトコル層のヘッダ情報を作成する。
【０１９１】
図５０は、上位層のデータがゲート層に来た時点の動作を示すフローチャートである。
ゲート層は、プロトコル層からの送信データを受信すると（ステップＳ５０１）。受信した送信データの先頭アドレスを４で割り、その余りを計算する（ステップＳ５０２）。その余りが０であった場合は、パディングの添付は行わず、ヘッダサイズにゲートヘッダのサイズである１２を格納する（ステップＳ５０３）。
【０１９２】
ステップＳ５０２において、余りが１であった場合、送信データの先頭アドレスの最後の数値は１、５、９、Ｄのどれかであるから、パディングを一つ添付する（ステップＳ５０４）。そして、ヘッダサイズにゲートヘッダのサイズである１２＋１を格納する（ステップＳ５０５）。
【０１９３】
ステップＳ５０２において、余りが２であった場合、送信データの先頭アドレスの最後の数値は２、６、Ａ、Ｅのどれかであるから、パディングを二つ添付する（ステップＳ５０６）。そして、ヘッダサイズにゲートヘッダのサイズである１２＋２を格納する（ステップＳ５０７）。
【０１９４】
ステップＳ５０２において、余りが３であった場合、送信データの先頭アドレスの最後の数値は３、７、Ｂ、Ｆのどれかであるから、パディングを三つ添付する（ステップＳ５０８）。そして、ヘッダサイズにゲートヘッダのサイズである１２＋３を格納する（ステップＳ５０９）。
【０１９５】
次に、受信側の処理において、デバイスドライバ（ＰＣＩデバイスドライバ）から受信データを受け取った時点の動作について説明する。
【０１９６】
図５１は、受信側の動作を示すフローチャートである。
ゲート層は、デバイスドライバが受信したデータを受け取ると（ステップＳ５１１）、ゲートヘッダ中のヘッダサイズをチェックする（ステップＳ５１２）。その値が１２である時、ゲートヘッダにパディングは付いていないと判断し、プロトコル層へ渡すアドレスを受信データ先頭アドレスにゲートヘッダ分を加えた位置に移動させる。
【０１９７】
ステップＳ５１２でチェックした結果、その値が１３である時、ゲートヘッダにパディングが一つ付いていると判断し、プロトコル層に渡すアドレスを受信データ先頭アドレスにゲートヘッダ＋２を加えた位置に移動させる（ステップＳ５１４）。
【０１９８】
ステップＳ５１２でチェックした結果、その値が１４である時、ゲートヘッダにパディングが二つ付いていると判断し、プロトコル層に渡すアドレスを受信データ先頭アドレスにゲートヘッダ＋３を加えた位置に移動させる（ステップＳ５１５）。
【０１９９】
ステップＳ５１２でチェックした結果、その値が１５である時、ゲートヘッダにパディングが三つ付いていると判断し、プロトコル層に渡すアドレスを受信データ先頭アドレスにゲートヘッダ＋３を加えた位置に移動させる（ステップＳ５１６）。
【０２００】
ゲート層は、上記ステップＳ５１３〜ステップＳ５１６で求めた先頭アドレスをプロトコル層へ通知する（ステップＳ５１７）。
【０２０１】
〈効果〉
以上のように、具体例９によれば、自層の処理を行うヘッダ情報中に、ヘッダのサイズを示す情報と、ヘッダ情報のバイト数が特定の値の倍数となるような可変長のデータであるパディングとを付加するようにしたので、以下のような効果が期待できる。
【０２０２】
(1)プロトコル層のヘッダ情報部のサイズに関係なく、上位層データの開始位置を４バイト境界に揃えることができる。
(2)プロトコル層のヘッダ情報部に関係なく、全データの開始位置を４バイト境界に揃えることができる。
【０２０３】
《具体例１０》
具体例１０は、各インテリジェントデバイスに、システムの初期化を行う機能を備えるようにしたものである。
【０２０４】
〈構成〉
図５２は、具体例１０の構成および処理の説明図である。
具体例１０は、具体例１の構成に対し、ＰＣＩバスマスタが唯一の初期化時に暫定的に初期化の主導権を持つ初期化時暫定マスタの機能を持つ点と、その他デバイスが他のデバイスを初期化する機能を持つ点とを付加している。
【０２０５】
図示のように、初期化時暫定マスタ側は、ゲートＩＤ振り分け処理と、マスタ募集処理とを行うよう構成され、デバイス側は、ゲートＩＤ入手処理と、マスタへの立候補処理とを行うよう構成されている。また、デバイス側は、デバイスマスタが自身に決定した場合は、他のデバイスの初期化処理を行うよう構成されている。
【０２０６】
〈動作〉
本具体例では、ＰＣＩデバイスドライバレベルの初期化をＰＣＩバスマスタが行った後に、暫定的に初期化の主導権を持つ初期化時暫定マスタ機能がＰＣＩバスマスタの上位層として動作する。
【０２０７】
本処理は、先ず上位層同士でお互いを認識するためのＩＤを割り当てる処理を実行する。次に暫定初期化以降の初期化の主導権を持つマスタの募集処理を実行する。この時に、ＰＣＩバスマスタ以外のデバイスはマスタになるための機能を有している場合は初期化時暫定マスタからのマスタ募集に対して立候補することができる。そして、初期化時暫定マスタからマスタ権を譲られた場合には、今後マスタとなり、全システム間の初期化を取りまとめる。初期化時暫定マスタは、他のデバイスにマスタ権を譲った場合は、以降一般のデバイスとして動作する。
【０２０８】
マスタとして動作するための機能をデバイスマスタと定義し、新しいデバイスマスタを決定するまでの手順を以下に説明する。
【０２０９】
図５３は、デバイスマスタの決定処理の説明図である。
先ず、ＰＣＩバスマスタが持つ初期化時暫定マスタの処理について説明する。
初期化時暫定マスタは、各インテリジェントデバイスに対してマスタを募集することを示す「デバイスマスタ募集」コマンドを送信する（ステップＳ５３１ａ）。そのコマンドの応答としてマスタになることができる／またはできないことを意味する「デバイスマスタ応募」コマンドを受信する（ステップＳ５３２ａ）。
【０２１０】
「デバイスマスタ募集」コマンドを送信した全てのインテリジェントデバイスより、「デバイスマスタ応募」コマンドを受信すると、その中から一つマスタとなるインテリジェントデバイスを選定する（ステップＳ５３３ａ）。
【０２１１】
初期化時暫定マスタは、マスタと選定したインテリジェントデバイスに対しては、以降のデバイス間初期化を依頼することを示す「デバイスマスタ決定」コマンドを、それ以外のインテリジェントデバイスに対しては、マスタとして選定しなかったことを示す「デバイスマスタ不採用」コマンドを送信する（ステップＳ５３４ａ）。
【０２１２】
次に、ＰＣＩバスマスタ以外のデバイスの処理について説明する。
各インテリジェントデバイスは、初期化時暫定マスタからの「デバイスマスタ募集」コマンドを受信すると（ステップＳ５３１ｂ）、自機能の中にデバイスマスタ機能が含まれているかを確認する（ステップＳ５３２ｂ）。含まれていない場合は引数でマスタに立候補しないことを示して初期化時暫定マスタに対して「デバイスマスタ応募」コマンドを送信する（ステップＳ５３３ｂ）。引数を使用する代わりにマスタに応募しないことを示す「デバイスマスタ非応募」コマンドを使用してもよい。
【０２１３】
「デバイスマスタ応募」コマンド、若しくは「デバイスマスタ非応募」コマンドを、初期化時暫定マスタに送信した後に、初期化時暫定マスタより「デバイスマスタ決定」コマンドまたは、「デバイスマスタ不採用」コマンドを受信する（ステップＳ５３４ｂ）。「デバイスマスタ決定」コマンドを受信した場合は、以降マスタとなり、システム間初期化の主導権を取る。「デバイスマスタ不採用」コマンドを受信した場合は、引き続き一般のデバイスとして動作する。
【０２１４】
ところで、本具体例の構成では、ＰＣＩデバイスドライバの上位にゲート層を設けている。ゲート層は主に複数の上位層（プロトコル層）と複数の下位層（デバイスドライバ）間の経路選択、経路制御を行う階層である。
【０２１５】
よって、デバイスマスタは、ゲートの初期化後、ゲートの通信機能を使用して各システム間のその他のイニシャルの主導権を握る。組み込み上、ゲート自身がデバイスマスタとしての機能を持つ必要はないが、以下のデバイスマスタの動作例ではデバイスマスタ機能がゲートに存在するものとして説明する。
【０２１６】
図５４は、デバイスマスタになるための条件を示す説明図である。
デバイスマスタは自システムの上位層が各システム間で初期化を行う時のキック（起動）をかける処理を受け持つ。各システム上の全ての上位層は、システム間で初期化開始を行う場合、デバイスマスタからの初期化開始要求を使用することにより他のシステム上の同一上位層との同期を取ることができ、双方で初期化を開始してしまう等の問題を回避できる。
【０２１７】
図５５は、デバイスマスタの初期化概要の説明図である。
本具体例では、上位層間初期化を行う上位層の例としてＸＸＸマネージャ、ＹＹＹマネージャを使用する（ＸＸＸマネージャ、ＹＹＹマネージャは任意の上位層）。
【０２１８】
デバイスマスタは上位層に対して「（主導権付き）初期化要求」を発信する。ここでは、ＸＸＸマネージャとＹＹＹマネージャに対して行っている。スレーブゲートは、上位層に対して「（主導権なし）初期化要求」を出す（出す／出さないは各システムのプログラム仕様による）。
【０２１９】
図示例では、デバイスマスタにより「（主導権付き）初期化要求」を受信したＸＸＸマネージャ、ＹＹＹマネージャはそれぞれ他システムのＸＸＸマネージャ、ＹＹＹマネージャに対して主導権を持ち初期化を行っている。
【０２２０】
〈効果〉
以上のように、具体例１０によれば、システムの初期化を行うデバイスをＰＣＩバスマスタ固定ではなく、各デバイス間とのやり取りで決定し、他のデバイスが受け持つことができるようにしたので、以下の効果が期待できる。
【０２２１】
(1)ＰＣＩバスマスタを持つシステムと対等の関係にあるシステムを開発し、バスに接続する場合にそのシステムにデバイスマスタを持たせる構造で開発することができるため、開発単位としてまとまる効果がある。よって、そのシステムの開発が容易になり、アウトソーシング等の戦略が取りやすい。
【０２２２】
(2)ＰＣＩバスマスタの初期化機能が正常に動作しない場合のバックアップ機能となる。よって、全システムの信頼性、保全性が向上する。
【図面の簡単な説明】
【図１】本発明のＰＣＩバス制御システムの具体例１を示す構成図である。
【図２】本発明のＰＣＩバス制御システムのソフトウェア階層構造を示す説明図である。
【図３】ノン−インテリジェントデバイス４の初期化の説明図である。
【図４】仮オーナ決定処理の説明図である。
【図５】仮オーナ決定シーケンスの説明図である。
【図６】サービスマネージャの初期化時における仮サービスの認識処理の説明図である。
【図７】サービス整合処理の説明図である。
【図８】具体例２におけるコンフィグレーションレジスタと拡張ＰＣＩ初期化処理の説明図である。
【図９】具体例２で設定するデバイスＩＤの説明図である。
【図１０】具体例２の動作フローチャートである。
【図１１】具体例３の説明図である。
【図１２】具体例３のＰＣＩバスマスタからデバイスへのコマンド送信動作の説明図である。
【図１３】コマンドの説明図（その１）である。
【図１４】コマンドの説明図（その２）である。
【図１５】各インテリジェントデバイスがＰＣＩバスマスタに拡張ＰＣＩコマンドを送信する場合の説明図である。
【図１６】具体例４の説明図である。
【図１７】具体例４のＰＣＩヘッダの構成図である。
【図１８】具体例４に関する問題の説明図である。
【図１９】具体例４の動作を示す説明図である。
【図２０】具体例４におけるデータ送信の概念を示す説明図である。
【図２１】具体例５の構成および処理の説明図である。
【図２２】デバイスプロファイルの構造図である。
【図２３】メールボックスポインタの構造を示す説明図である。
【図２４】ＰＩＲポインタの構造を示す説明図である。
【図２５】メールボックスの構造を示す説明図である。
【図２６】具体例５の動作フローチャートである。
【図２７】送信先デバイス上の機能に対応するメールボックスアドレスの調べ方の説明図である。
【図２８】メールボックスへのメール投函処理の説明図である。
【図２９】送信先デバイス上の機能に対応するＰＩＲアドレスの調べ方の説明図である。
【図３０】具体例５の効果の説明図である。
【図３１】具体例６の構成および処理を示す説明図である。
【図３２】デバイスプロファイル配列のコピー先アドレス問い合わせ処理の説明図である。
【図３３】デバイスプロファイル配列のコピー先アドレス回答処理の説明図である。
【図３４】メールボックスポインタ計算処理の説明図である。
【図３５】ＰＣＩバスマスタの具体的なメールボックスポインタの設定手順を示す説明図である。
【図３６】具体例７の割り込み要求レジスタの構成図である。
【図３７】送信側が行うＰＣＩの割り込み要求レジスタの使用方法の説明図である。
【図３８】ＰＩＲの各ビットにおける意味づけの説明図である。
【図３９】送信先のＰＩＲに書き込む決められた値を示す説明図である。
【図４０】受信側が行うＰＣＩの割り込み要求レジスタの使用方法の説明図である。
【図４１】具体例８におけるＰＣＩヘッダの構成図である。
【図４２】具体例８の動作の基本的概念を示す説明図である。
【図４３】連続送信時の送信側のシーケンスを示す説明図である。
【図４４】リンクしたことが受信側に認識されない場合の説明図である。
【図４５】連続送信時の受信側のシーケンスを示す説明図である。
【図４６】予め受信するデータの総容量を見積り、その後にデータをコピーする場合の説明図である。
【図４７】具体例９におけるゲートヘッダの説明図である。
【図４８】ヘッダサイズ領域の説明図である。
【図４９】パディング無しとパディングありの場合の説明図である。
【図５０】上位層のデータがゲート層に来た時点の動作を示すフローチャートである。
【図５１】具体例９の受信側の動作を示すフローチャートである。
【図５２】具体例１０の構成および処理の説明図である。
【図５３】デバイスマスタの決定処理の説明図である。
【図５４】デバイスマスタになるための条件を示す説明図である。
【図５５】デバイスマスタの初期化概要の説明図である。
【符号の説明】
１ ＰＣＩバス
２ プリンタ（ＰＣＩバスマスタ）
３ インテリジェントデバイス
４ ノン−インテリジェントデバイス
【発明の属する技術分野】
本発明は、ＰＣＩ（Peripheral Component Interconnect）バス制御を行うＰＣＩバス制御システムに関するものである。
【０００２】
【従来の技術】
従来、パーソナルコンピュータ（ＰＣ）等で採用しているＰＣＩバス制御システムでは、デバイスは全てＰＣＩバス制御をしないノン−インテリジェントデバイスで構成されている。よって、ＰＣＩバスマスタ（ＰＣ側）が全てのＰＣＩ通信の制御を行っていた。
【０００３】
【発明が解決しようとする課題】
しかしながら、上記従来のように、ＰＣＩバスマスタ側が全てのＰＣＩ通信の制御を行う場合、次のような問題点があった。即ち、ＰＣＩバスマスタが全てのデバイスに対してアクセスする必要があり、このため、ＰＣＩバスマスタが全てのデバイスに対してアクセスするためのドライバを持つ必要があった。
【０００４】
【課題を解決するための手段】
本発明は、前述の課題を解決するため次の構成を採用する。
〈構成１〉
ＰＣＩバスマスタと、単独ではＰＣＩのバストランザクションを開始する機能を持たない複数のノン−インテリジェントデバイスと、ＰＣＩバスを経由した通信を自ら行う機能を持つインテリジェントデバイスとが接続されるＰＣＩバス制御システムであって、前記ＰＣＩバスマスタは、所定の前記ノン−インテリジェントデバイスの仮オーナを決定するために、前記インテリジェントデバイスに仮オーナ要求を示すコマンドを送信する機能と、サービス情報送信要求を仮オーナの承諾した前記インテリジェントデバイスに送信する機能とを備え、前記インテリジェントデバイスは、前記ＰＣＩバスマスタからの仮オーナ要求を示すコマンドに対して承諾及び拒否のいずれかの受信応答を示すコマンドを前記ＰＣＩバスマスタに送信する機能と、前記ＰＣＩバスマスタから受信した前記サービス情報送信要求に対し前記ノン−インテリジェントデバイスから対応するサービス情報を収集し、該サービス情報を前記ＰＣＩバスマスタに送信する機能と、を備えることを特徴とするＰＣＩバス制御システム。
【０００５】
＜構成２＞
構成１に記載のＰＣＩバス制御システムにおいて、前記インテリジェントデバイスおよび前記ノン−インテリジェントデバイスは、前記ＰＣＩバスマスタが各デバイスを初期化する際に参照するコンフィグレーションレジスタを備え、該レジスタの予め決められた先頭の数ビットを、インテリジェントデバイスかノン−インテリジェントデバイスかを識別するための値とすることを特徴とするＰＣＩバス制御システム。
【０００６】
＜構成３＞
構成１または２に記載のＰＣＩバス制御システムにおいて、前記インテリジェントデバイスおよび前記ノン−インテリジェントデバイスのメモリに、ＰＣＩデバイスドライバの初期化時に使用する通信用作業領域を設け、かつ、当該通信用作業領域をメモリ領域の先頭に設けたことを特徴とするＰＣＩバス制御システム。
【０００７】
＜構成４＞
構成２に記載のＰＣＩバス制御システムにおいて、前記先頭の数ビットは、各機能にマッピングする領域の先頭に設けた、ＰＣＩデバイスドライバの初期化時に使用する通信用作業領域を有するか否かを示す値であることを特徴とするＰＣＩバス制御システム。
【０００８】
〈構成５〉
構成１に記載のＰＣＩバス制御システムにおいて、送信側デバイスから受信側デバイスへの送信データの先頭に、次の送信データのＰＣＩヘッダの先頭アドレスを示すネクストポインタと、当該送信データにおけるデータエリアのアドレスを示すデータエリアポインタとを示すＰＣＩヘッダを備え、かつ、前記ネクストポインタの最下位ビットを、送信データが連続するか否かを示すフラグとしたことを特徴とするＰＣＩバス制御システム。
【０００９】
＜構成６＞
構成１または２に記載のＰＣＩバス制御システムにおいて、前記ＰＣＩバスマスタおよび前記インテリジェントデバイスは、全システム内に存在する機能と一意に対応づけられ、各機能毎に設けられたデバイスプロファイルを有し、各デバイスプロファイルは、送信先のメールボックスのアドレスを示すメールボックスポインタと、送信先の処理に割り込みを発生させる割り込み要求レジスタのアドレスを示す割り込み要求レジスタポインタと、自分宛のコマンドとその引数を格納するメールボックスとを備え、機能ＸのデバイスプロファイルＹのメールボックスポインタは、機能ＹのデバイスプロファイルＸのメールボックスのアドレスを示し、各機能のデバイスプロファイルＸの割り込み要求レジスタポインタは、機能Ｘの割り込み要求レジスタのアドレスを示すよう構成されていることを特徴とするＰＣＩバス制御システム。
【００１０】
＜構成７＞
構成６に記載のＰＣＩバス制御システムにおいて、前記ＰＣＩバスマスタは、前記インテリジェントデバイスの機能に対して、配布するデバイスプロファイルのサイズと個数とを通知することによりコピーする先頭アドレスを入手するコピー先アドレス問い合わせ処理部と、コピーする先頭アドレスに基づき、配布するデバイスプロファイルのメールボックスポインタを求めるメールボックスポインタ計算処理部とを備えたことを特徴とするＰＣＩバス制御システム。
【００１１】
＜構成８＞
構成６または７に記載のＰＣＩバス制御システムにおいて、割り込み要求レジスタの各ビットは、それぞれ、各機能と一意に対応づけられ、かつ、各機能が他の機能に対して割り込みを要求する場合は、相手自身のビットに書き込みを行うよう構成されていることを特徴とするＰＣＩバス制御システム。
【００１２】
〈構成９〉
構成１に記載のＰＣＩバス制御システムにおいて、送信側デバイスから受信側デバイスへの送信データの先頭に、次の送信データのＰＣＩヘッダの先頭アドレスを示すネクストポインタと、送信データにおけるデータエリアのアドレスを示すデータエリアポインタと、送信データのデータサイズとを示すＰＣＩヘッダを備えたことを特徴とするＰＣＩバス制御システム。
【００１３】
＜構成１０＞
構成１、５または９のいずれかに記載のＰＣＩバス制御システムにおいて、前記ＰＣＩバスマスタおよび前記インテリジェントデバイスは、階層処理構造における自層の処理を行うヘッダ情報中に、ヘッダのサイズを示す情報を含むと共に、ヘッダ情報の総データ量が特定の値の倍数となるように可変長のデータであるパディングを付加するようにしたことを特徴とするＰＣＩバス制御システム。
【００１４】
＜構成１１＞
構成１、２、３、６、７、１０のいずれかに記載のＰＣＩバス制御システムにおいて、前記インテリジェントデバイスは、予め決められた初期化時暫定マスタよりデバイスマスタ募集があった場合、自身がデバイスマスタになれる条件を備えていた場合はデバイスマスタに応募し、デバイスマスタが自身に決定した場合は他のデバイスの初期化処理を行うよう構成されていることを特徴とするＰＣＩバス制御システム。
【００１５】
【発明の実施の形態】
以下、本発明の実施の形態を具体例を用いて詳細に説明する。
《具体例１》
具体例１は、ＰＣＩバス上のＰＣＩバスを経由した通信を自ら行う機能（Initiator機能）を持たないデバイス（ノン−インテリジェントデバイス）をオーナとして管理するインテリジェントデバイスを備えるようにしたものである。
【００１６】
〈構成〉
図１は本発明のＰＣＩバス制御システムの具体例１を示す構成図である。
図のシステムは、ＰＣＩバス（PCI BUS）１上に接続されたプリンタ（Printer）２、インテリジェントデバイス（PCI Device (Intelligent)またはMFP(Intelligent)）３、ノン−インテリジェントデバイス（PCI Device (Non Intelligent)）４からなる。
【００１７】
プリンタ２は、ＰＣＩバスマスタ（PCI BUS Master）としての機能を有するデバイスである。インテリジェントデバイス３は、自身にＣＰＵを持ち、ＰＣＩバス１を経由した通信を自ら行う機能（Initiator機能）を持っているデバイスである。ノン−インテリジェントデバイス４は、ＰＣＩバス１を経由した通信を行う機能を持たないデバイスである。
【００１８】
即ち、インテリジェントデバイス３は、ノン−インテリジェントデバイス４をオーナとして管理するデバイスであり、オーナとして管理するノン−インテリジェントデバイス４のデバイスドライバを備え、かつ、そのノン−インテリジェントデバイス４へアクセスする機能と、他のデバイスからそのノン−インテリジェントデバイス４へのアクセス要求を取りまとめる(中継する)機能とを有している。
【００１９】
図２は、本発明のＰＣＩバス制御システムのソフトウェア階層構造を示す説明図である。
図示のように、ＰＣＩバス１を経由する二つのデバイス間通信は、ＰＣＩデバイスドライバ（PCI Device Driver）の上位層としてゲート（Gate）層を、ゲート層の上位層としてＩＥＥＥ１２８４．４（プロトコル層）とサービスマネージャ（Service Maneger）を使用する。ここで、ＰＣＩデバイスドライバは、ＰＣＩバスのデバイスドライバ、ゲート層は、それぞれのデバイスを識別するＰＣＩバスに接続されるボードレベルの制御を行う部分、サービスマネージャは、例えば、印刷といったサービスを制御する部分である。
【００２０】
動作的には、送信元ＰＣＩデバイスドライバが作成する送信データは送信先ＰＣＩデバイスドライバが処理する。送信元ゲートが作成する送信データは送信先ゲートが処理する。送信元ＩＥＥＥ１２８４．４が作成する送信データは送信先ＩＥＥＥ１２８４．４が処理する。送信元ＩＥＥＥ１２８４．４の上位層が作成する送信データは送信先ＩＥＥＥ１２８４．４の上位層が処理する。以上のような階層構造により構成される。
【００２１】
〈動作〉
インテリジェントデバイス３が、先ず自身を初期化し、ノン−インテリジェントデバイス４は、インテリジェントデバイス（オーナ）３による初期化待ちとなる。
【００２２】
図３は、ノン−インテリジェントデバイス４の初期化の説明図である。
具体例のＰＣＩの初期化処理（拡張ＰＣＩ初期化処理、拡張Gate初期化処理）では、ノン−インテリジェントデバイス４に対してアクセス可能な仮のオーナを決定するプロセスを実行する。また、サービスマネージャの初期化では、仮サービスの認識、オーナの募集を行う。
【００２３】
デバイスマスタ（PCI BUS Master：ＰＣＩバスマスタ）は、仮オーナ決定処理を行う。よって、本仕様ではＰＣＩバスマスタ上に存在する各ノン−インテリジェントデバイス４は、仮オーナになれる機能をもったインテリジェントデバイス３が必要である。仮オーナの役割は、オーナとなっているノン−インテリジェントデバイス４の関連情報に対して、ＰＣＩバスマスタからの問い合わせに回答することである。例えば、後述するサービスマネージャの初期化で必要となる情報の収集が行われるが、その際に、ノン−インテリジェントデバイス４は、その要求に対応できないため、仮オーナとなったインテリジェントデバイス３は代わりにそのデバイスの情報を収集し送信する。
【００２４】
仮オーナを決定するため、ＰＣＩバスマスタは先ず一つのノン−インテリジェントデバイス４に対する仮オーナ要求を、存在する全インテリジェントデバイス３に順番に送信する。
【００２５】
図４は、仮オーナ決定処理の説明図である。
図示のように、ＰＣＩバスマスタは、ノン−インテリジェントデバイス４が複数存在する場合には、図４に示すような処理を、そのノン−インテリジェントデバイス４の数分繰り返す。例えばノン−インテリジェントデバイス４が５個ある場合は、図４に示す処理を５回繰り返す。尚、ＰＣＩバスマスタは、ノン−インテリジェントデバイス４が存在しない場合には、仮オーナ要求を送信しない。
【００２６】
ここで、各デバイス（インテリジェントデバイス３）は、ＰＣＩバスマスタから送信される「仮オーナ要求」を示すコマンドを受信すると、以下のいずれかの応答をしなければならない。
(1)仮オーナ受諾：自デバイスが「仮オーナ」機能を有している場合
(2)仮オーナ拒否：自デバイスが「仮オーナ」機能を有していない場合
【００２７】
図５は、仮オーナ決定シーケンスの説明図である。
仮オーナ決定シーケンスにおいて、「仮オーナ決定」を示すコマンドの送信は仮オーナ決定シーケンスの最後に行われる。各仮オーナ決定シーケンスはＰＣＩバス１上に存在するノン−インテリジェントデバイス４の数に対応している。よって、ＰＣＩバスマスタはＰＣＩバス１上に存在するノン−インテリジェントデバイス４の数と同数の仮オーナ決定コマンドを発行する。「仮オーナ決定」を示すコマンドを受信したインテリジェントデバイス３は「受信応答」を示すコマンドを返信する。
【００２８】
また、いずれかの仮オーナとなったインテリジェントデバイス３であっても、ＰＣＩバスマスタからの次の「仮オーナ要求」を示すコマンドに対して「仮オーナ受諾」を示すコマンドを返すことも可能とする。これにより、複数のノン−インテリジェントデバイス４の仮オーナになることが可能である。
以上が、図３における拡張ＰＣＩ初期化処理および拡張Gate初期化処理の内容である。
【００２９】
次に、図３におけるサービスマネージャ（Service Manager）初期化処理について説明する。
サービスマネージャの初期化はデバイスマスタとなったデバイスを中心に行う。一般にデバイスマスタはＰＣＩバスマスタとなっているデバイスが担当し、ＰＣＩデバイスドライバおよびゲートの初期化以降の初期化を受け持つ。
【００３０】
図６は、サービスマネージャの初期化時における仮サービスの認識処理の説明図である。
デバイスマスタの他システムのディスカバリ処理として、各システムが持つサービスの情報収集が行われる。この時に、仮オーナは、デバイスマスタから「Pre-Service Profile送信要求」コマンドを受信すると、仮オーナとなっているノン−インテリジェントデバイス４のサービス情報もまとめてデバイスマスタに連絡しなければならない。仮オーナは、仮オーナとなっているノン−インテリジェントデバイス４のサービス内容については判断できないため、仮オーナがデバイスマスタに通知する（「Pre-Service Profile送信」コマンドを送信する）サービスは仮サービスと定義する。
【００３１】
デバイスマスタは、全システム中に仮サービスが存在することを認識すると、その仮サービスを正式なサービスにするために、その仮サービスに対するオーナを唯一割り当てる処理を行う。
【００３２】
図７は、サービス整合処理の説明図である。
デバイスマスタは、全ノン−インテリジェントデバイス４に対しオーナの割り当てが終了（成功・不成功不問）すると、オーナからのサービスの更新を待つ。オーナからサービスの更新があった場合は、再びサービスプロファイル（Service Profile）を更新してサービスの整合を行う。尚、サービスプロファイルとは、どのデバイスがどのようなサービスを提供するかを示す情報である。
【００３３】
オーナは、その仮サービスに対する全権利を持っているので自由な対応が可能である。以下に対応例を示す。
【００３４】
対応例(1)
仮サービスを独占使用する場合は、「サービスの削除」を行い、他の処理からアクセスできないようにする。そのサービス専用のデバイスドライバでアクセスする必要がある。
【００３５】
対応例(2)
共有サービスの配布役をする場合は、サービスプロファイルに新サービスとして「サービスの変更」を行い、他の処理からの要求に対して仮サービスの使用権を配布する。
【００３６】
対応例(3)
共有サービスのアクセスマスタを行う場合は、サービスプロファイルに新サービスとして「サービスの変更」を行い、他の処理からの要求に対して新サービスを提供する。
【００３７】
〈効果〉
以上のように具体例１によれば、ＰＣＩバスを介して通信する機能を持たないノン−インテリジェントデバイスのオーナとなるインテリジェントデバイスを設けたので、以下のような効果が期待できる。
【００３８】
(1)ＰＣＩバスマスタが、必ず、接続されるデバイス全てにアクセスする機能（デバイスドライバ）を持つ必要がなくなる。例えば、ＰＣＩバス経由のＳＣＳＩボードが接続されていた場合、本具体例の仕様により、ＰＣＩバスマスタはＳＣＳＩドライバを装備することなくＳＣＳＩボードの提供するサービスを使用することができる。同一のＰＣＩバスに接続されているＰＣＩバスマスタ以外のデバイスについても同様の効果が期待できる。
【００３９】
(2)本システムでは、インテリジェントデバイスの接続をサポートしているため、ＰＣＩバスマスタのＰＣＩ通信における負荷を減少させることができる。
【００４０】
《具体例２》
具体例２は、具体例１の構成において、ＰＣＩバス上に接続されているデバイスが拡張ＰＣＩ仕様を有しているか、また、インテリジェントデバイス／ノン−インテリジェントデバイスであるかを識別するようにしたものである。尚、拡張ＰＣＩ仕様とは、ＰＣＩデバイスドライバの初期化時に使用する通信用作業領域を、各機能にマッピングする領域の先頭に設けている仕様を意味するが、これについては、具体例３で説明する。
【００４１】
〈構成〉
図８は、具体例２におけるコンフィグレーションレジスタと拡張ＰＣＩ初期化処理の説明図である。
コンフィグレーションレジスタ（Configuration Register）のフォーマットは、図示のように、その先頭にはデバイスＩＤ（Device ＩＤ）を格納するよう構成されている。本具体例では、このデバイスＩＤの先頭４ビットを、そのコンフィグレーションレジスタを有するデバイスが拡張ＰＣＩ仕様であるか、インテリジェントデバイス／ノン−インテリジェントデバイスかを識別するための値としている。
【００４２】
図９は、本具体例で設定するデバイスＩＤの説明図である。
本具体例では、ＰＣＩコンフィグレーション空間に設けるコンフィグレーションレジスタのデバイスＩＤに、図９に示す拡張ＰＣＩ仕様を設ける。即ち、上位４ビットが１６進数のＡ（１０１０）である場合は、拡張ＰＣＩ仕様のインテリジェントデバイスであり、１６進数の５（０１０１）である場合は、拡張ＰＣＩ仕様のノン−インテリジェントデバイスである。また、それ以外の値の場合は、拡張ＰＣＩ仕様ではないデバイスであることを示している。尚、図中、×××は、Don't Careを示している。
【００４３】
また、図中のDevice ＩＤやVender ＩＤ等、コンフィグレーションレジスタのフォーマット自体は従来と同様であるため、ここでの各用語の説明は省略する。
【００４４】
更に、本具体例では、ＰＣＩバスマスタが、標準のＰＣＩ初期化処理に加えて、拡張ＰＣＩ仕様であるか、インテリジェントデバイス／ノン−インテリジェントデバイスであるかの識別処理を行うよう構成されている。
【００４５】
先ず、標準のＰＣＩ初期化処理を行うためのＰＣＩバスマスタの処理構造について説明する。
標準のＰＣＩ初期化処理は、図８に示すように、大きく分けて、デバイスボード発見処理８１、発見したデバイスの有効化処理８２、メモリ・Ｉ／Ｏ空間割当て処理８３、割り込み設定処理８４の四つから構成されている。
【００４６】
本具体例では、ＰＣＩバスマスタが行う標準のＰＣＩ初期化処理に加え、以下の処理を追加する。
デバイスボード発見処理で、各デバイスのコンフィグレーションレジスタのデバイスＩＤと、ベンダＩＤ（Vender ＩＤ）を確認する処理があるが、その部分に拡張ＰＣＩ仕様がサポートされているかを判断する処理８５と、確認したデバイスがインテリジェントデバイス３であるか、ノン−インテリジェントデバイス４であるかを判断する処理８６を追加する。
【００４７】
即ち、３２ビットからなるデバイスＩＤのうち、先頭４ビットを用いて、拡張ＰＣＩ仕様サポート判断処理８５とインテリジェントデバイス／ノン−インテリジェントデバイス識別処理８６を行う。
【００４８】
〈動作〉
ＰＣＩコンフィグレーション空間に設けるコンフィグレーションレジスタのデバイスＩＤに、図９に示す拡張ＰＣＩ仕様の識別データを格納する。
【００４９】
ＰＣＩバスマスタは、各デバイスのコンフィグレーションレジスタのデバイスＩＤを読み出し、その上位４ビットにより、読み出しているコンフィグレーションレジスタが対応する機能がインテリジェントデバイス３であるかノン−インテリジェントデバイス４であるかを識別する。
【００５０】
図１０は、具体例２の動作フローチャートである。
先ず、ＰＣＩバスマスタは、ＰＣＩコンフィグレーションレジスタのデバイスＩＤを読込み（ステップＳ１０１）、その先頭４ビットが１６進数のＡ（１０１０）であるか比較する（ステップＳ１０２）。
【００５１】
ステップＳ１０２において、１６進数のＡ（１０１０）であった場合は、以降、そのデバイスをインテリジェントデバイスとして扱う（ステップＳ１０３）。一方、ステップＳ１０２において、１６進数のＡ（１０１０）でなかった場合は、１６進数の５（０１０１）であるかを比較する（ステップＳ１０４）。
【００５２】
ステップＳ１０４において、１６進数の５（０１０１）であった場合は、以降、そのデバイスをノン−インテリジェントデバイスとして扱う（ステップＳ１０５）。また、ステップＳ１０２において１６進数のＡ（１０１０）でなく、かつ、ステップＳ１０４において１６進数の５（０１０１）でもない場合、拡張ＰＣＩ仕様をサポートしていないデバイスであるとし、以降、システムからアクセスできないよう切り離し処理を行う（ステップＳ１０６）。
【００５３】
〈効果〉
以上説明したように、具体例２によれば、各デバイスを初期化する際に参照するコンフィグレーションレジスタの予め決められた先頭ビット数を、拡張ＰＣＩ仕様であるか、インテリジェントデバイスかノン−インテリジェントデバイスかを識別するための値としたので、以下のような効果が期待できる。
【００５４】
(1)ＰＣＩバスに接続されるデバイスがインテリジェントデバイスかノン−インテリジェントデバイスかが固定されていない場合でも容易に判別することができる。
(2)コマンド等のレスポンスの有無によって、インテリジェントデバイス／ノン−インテリジェントデバイスを識別する場合に比べて判断に要する時間が短い。
(3)標準のＰＣＩ初期化処理と同一の処理において、拡張ＰＣＩ仕様のデバイスであるかの判定が可能である。
【００５５】
《具体例３》
具体例３は、ＰＣＩデバイスドライバの初期化時に使用する通信用作業領域を、デバイス側に設け、かつ、各機能にマッピングする領域の先頭に設けたものである。
【００５６】
〈構成〉
図１１は、具体例３の説明図である。
コミュニケーションエリア（Communication Area：通信用作業領域）は、拡張ＰＣＩの初期化時にＰＣＩバスマスタと各デバイスの機能間で通信するために使用する領域である。このコミュニケーションエリアは、ＰＣＩバスマスタと各デバイスの機能に対し各々一つ用意する。
【００５７】
ここで、本具体例では、ＰＣＩバスマスタ用には、ＰＣＩ空間の（00000000H）番地に固定的に割り付ける。一方、各デバイスの機能毎には、各機能をマッピングするＰＣＩ空間の先頭アドレスに割り当てる。
【００５８】
即ち、コミュニケーションエリアは、コミュニケーションエリアを持つＰＣＩ機能に対して割り込みを発生させる割り込み要求レジスタ（ＰＣＩInterrupt Register（図中、ＰＩＲで示す））と、コミュニケーションエリアを持つＰＣＩ機能に対しての要求であるコマンドを格納するエリア１（Area１）と、エリア１に格納するコマンドの引数を格納するエリア２（Area２）、エリア３（Area３）からなる。
【００５９】
〈動作〉
図１２は、具体例３のＰＣＩバスマスタからデバイスへのコマンド送信動作の説明図である。
ＰＣＩバスマスタは、送信先デバイスのコミュニケーションエリアのエリア１に、拡張ＰＣＩコマンドを、エリア２、エリア３にコマンドの引数をそれぞれ格納する（図中、▲１▼で示す）。
【００６０】
図１３および図１４は、コマンドの説明図である。
図示のように、ＰＣＩバスマスタからの、受信要求、受信応答、受信否定応答といったコマンドに対する設定値が決められている。尚、“Ｈ→Ｓ”がＰＣＩバスマスタから各デバイスへの送信可能なデータ、“Ｓ→Ｈ”が各デバイスからＰＣＩバスマスタへの送信可能なデータである。また、ノン−インテリジェントデバイス４に対して使用するコマンドは、リセット要求とファクトリーリセット要求のみとなる。
【００６１】
図１２に戻り、ＰＣＩバスマスタは、送信先デバイスのコミュニケーションエリアのＰＩＲに（OOOOOOO1H）を書き込む（図中▲２▼で示す）。これにより、送信先デバイスに対して割り込みが発生する（図中、▲３▼で示す）。送信先デバイスは、割り込み中でコミュニケーションエリアのエリア１から拡張ＰＣＩコマンドを、エリア２、エリア３からコマンドに対応する引数を読み出す（図中▲４▼）。尚、ＰＣＩバスマスタは、各コマンドの送信に対するレスポンスを２秒間でタイムアウトとする。タイムアウトとなった場合は原則として再送は行わない。このため、コマンドを受けたデバイスは２秒以内に応答する必要がある。
【００６２】
図１５は、各インテリジェントデバイスがＰＣＩバスマスタに拡張ＰＣＩコマンドを送信する場合の説明図である。
送信元デバイスは、送信元デバイスのコミュニケーションエリアのエリア１に拡張ＰＣＩコマンドを、エリア２、エリア３にコマンドの引数をそれぞれ格納する（図中、▲１▼）。この場合のコマンドは、図１３、図１４中の“Ｓ→Ｈ”に示した通りである。
【００６３】
送信元デバイスは、送信元デバイスのコミュニケーションエリアのＰＩＲに（OOOOOOO0H）以外の値を書き込む（図中、▲２▼）。図示例では（00000001H）を書き込んでいる。これにより、ＰＣＩバスマスタでは割り込みが発生する（図中、▲３▼）。ＰＣＩバスマスタは、割り込み中でコミュニケーションエリアのエリア１から拡張ＰＣＩコマンドを、エリア２、エリア３からコマンドに対応する引数を読み出す（図中、▲４▼）。
【００６４】
各デバイスは各コマンドの送信に対するレスポンスを２秒間をタイムアウトとする。タイムアウトとなった場合は原則として再送は行わない。コマンドの受信を受けたＰＣＩバスマスタは、２秒以内に応答する必要がある。
【００６５】
〈効果〉
以上説明したように、具体例３によれば、ＰＣＩデバイスドライバの初期化時に使用する通信用作業領域をデバイス側に設け、かつ、各機能にマッピングする領域の先頭に設けるようにしたので、以下のような効果が期待できる。
【００６６】
(1)初期化通信のために使用する領域が、共有メモリの先頭に集中しているため共有メモリを使用しないデバイス（Ｉ／Ｏ空間のみ使用するデバイス）が有っても最小限のメモリ領域を確保することで使用可能となる。
【００６７】
(2)初期化通信のために使用する領域が、共有メモリの先頭に集中しているため、各デバイスのメモリ空間の初期化がし易くなる。即ち、先頭領域を無条件に通信用作業領域として認識すればよいため、初期化処理においてＰＣＩバスマスタ側の、各デバイスとやり取りするための通信用作業領域を決定する処理を簡素化することができる。
【００６８】
(3)コマンド書き込み領域エリア１〜エリア３が各デバイス側にあるため、ＰＣＩバスマスタは各デバイスを独立して初期化することができる。即ち、ＰＣＩバスマスタ側は、各デバイスの応答を待たずに初期化処理を進めることができる。
【００６９】
《具体例４》
具体例４は、送信データのＰＣＩヘッダ中に、次の送信データが連続するか否かを示す連続フラグ（Continue Flag）を設定するようにしたものである。
【００７０】
〈構成〉
図１６は、具体例４の説明図である。
各デバイスには、送信側データ処理部の構成として、送信データ受付部１６１、連続フラグ設定部（Continue Flag設定部）１６２、コマンド送信処理部１６３を、受信側データ処理部の構成として、コマンド判断処理部１６４、連続フラグ判断処理部（Continue Flag判断処理部）１６５、データコピー処理部１６６を備えている。
【００７１】
送信データ受付部１６１は、上位層から送信されるデータを受け取るための機能部である。連続フラグ設定部１６２は、本具体例で新規に追加した機能部であり、後述する連続フラグを設定する機能を有している。
【００７２】
図１７は、本具体例のＰＣＩヘッダの構成図である。
ＰＣＩヘッダ（PCI Header）は、ＰＣＩヘッダ同士をアドレスでつなぎ、リンク構造で管理する場合に使用するネクストポインタ（Next Pointer）と、送信するデータの先頭アドレスを示すデータエリアポインタ（Data Area Pointer）と、送信するデータのサイズを示すデータサイズ（Data Size）の各領域から構成される。そして、本具体例では、ネクストポインタの下位１ビットを、そのデータが連続してコピーされる必要があるのか否かを示すための識別フラグＦ（連続フラグ）として使用するよう構成されている。
【００７３】
連続フラグは、０にセットしてある場合、特に意味を持たないが、１にセットしてある場合、そのＰＣＩヘッダが持つデータ領域と、ネクストポインタでリンクするＰＣＩヘッダの持つデータ領域は連続アドレス空間にコピーされる必要があることを示している。
【００７４】
図１６に戻り、コマンド送信処理部１６３は、上位層から指定されたデバイスに対してデータを送信するためのコマンドを送信する機能部である。
【００７５】
受信側データ処理部におけるコマンド判断処理部１６４は、送信側から送られたコマンドを受信し、その内容を解析する機能部である。連続フラグ判断処理部１６５は、本具体例で新規に追加した機能部であり、送信側データ処理部の連続フラグ設定部１６２に対応する受信側の構成である。データコピー処理部１６６は、受信するデータをコピーする処理を行うための機能部である。
【００７６】
〈動作〉
ＰＣＩバスを経由して通信する上位層は、通常プロトコル層を使用する。プロトコル層は、データを送信する場合に上位層の用意したデータの前にプロトコル層独自のヘッダ情報を添付する。この時、上位層が用意したデータ領域の前の部分は必ずしも未使用領域ではないため、プロトコル層のヘッダが挿入できないという問題点が発生する。
【００７７】
図１８は、この問題の説明図である。
図示のように、プロトコル層がデータを送信する際にヘッダ情報の領域が空いていない場合、上位層の送信データを他の空きエリアにコピーし、その領域にヘッダ情報を付与する。ところが、このような手段を取る場合、上位層の送信データは概して大量である場合が多いため、大量であることを前提とする設計が必要である。これに対して、本具体例では、以下に示すような処理を行うことにより、このような上位層の大量のデータをコピーすることなくヘッダ情報を挿入することが可能である。
【００７８】
図１９は、具体例４の動作を示す説明図である。
図２０は、具体例４におけるデータ送信の概念を示す説明図である。
【００７９】
図１９に示すように送信側が受信側に対して「受信要求」を示すコマンドを送信し、受信側は指定されたデータをコピーする。コピー後、送信側に対して「受信応答」を示すコマンドを送信する。
【００８０】
送信側が受信側に対して受信を要求する場合に、指定するデータの先頭アドレスとサイズを通知する必要がある。そこで、本具体例では、図１７に示したようなＰＣＩヘッダを使用し、送信するデータを受信側に通知する。
【００８１】
連続フラグは、０にセットしてある場合、特に意味を持たないが、１にセットしてある場合、そのＰＣＩヘッダが持つデータ領域と、ネクストポインタでリンクするＰＣＩヘッダの持つデータ領域は連続アドレス空間にコピーされる必要があることを示している。
【００８２】
図２０に示した例では、プロトコル層のヘッダ情報がデータ領域（Ａ）、上位層の送信データがデータ領域（Ｂ）となる。ここで、連続フラグがＯＮ（＝１）であるため、受信側では、連続アドレスにコピーする。
【００８３】
一方、連続アドレスにコピーする必要のないものは、連続フラグをＯＦＦ（＝０）とする。これにより受信側では、所定のアドレスにデータをコピーする。
【００８４】
また、上位層が送信するデータサイズには通常制限は存在しないが、プロトコル層の１回の送信サイズには制限があることが多い。よって、上位層の送信データを複数に分割して送信する必要がある。このような場合でも受信側としては受信データが分割せず、連続した領域に一つの固まりとして受信できることが必要な場合も多い。従って、このような場合においても、本具体例により上位層の大量なデータをコピーすることなく受信側へ効率のよい転送を行うことが可能となる。
【００８５】
例えば、図示例では、データ領域（Ｂ）の連続フラグをＯＮ（＝１）にし、更に、ネクストポインタにデータ領域（Ｃ）を管理するＰＣＩヘッダをリンクさせ、更にデータ領域（Ｄ）を管理するＰＣＩヘッダをリンクさせる（データ領域（Ｃ）とデータ領域（Ｄ）は図示省略している）。送信する上位層のデータを前半部と後半部の二つに分割して送付すると仮定した場合、データ領域（Ｄ）を管理するＰＣＩヘッダの連続フラグはＯＦＦ（＝０）となり、データ領域（Ａ）とデータ領域（Ｃ）がプロトコルヘッダ情報で、データ領域（Ｂ）が上位層データ前半部、データ領域（Ｄ）が上位層データ後半部となる。
【００８６】
尚、図１９に示すように、本具体例では、受信側が送信側から「受信要求」コマンドを受信し、データブロックをコピーするが、コピーに失敗し、何回かリトライしてもコピーが成功しない場合、受信側から「受信否定応答」コマンドを送信する。送信側からこの「受信応答」コマンドを受信した場合、データを修復できない場合は、送信を断念する。
【００８７】
〈効果〉
以上説明したように、具体例４によれば、ＰＣＩヘッダ情報としてネクストポインタの下位ビットを連続データの識別を行うビットとしたので、以下のような効果が期待できる。
【００８８】
(1)ＰＣＩバスを経由して通信する上位層は通常プロトコル層を使用する。この場合において、上位層の大量なデータをコピーすることなく、プロトコル層のヘッダ情報を上位層データの前の領域に挿入することが可能となる。
【００８９】
(2)上位層の大量なデータをコピーすることなく、送信側の連続したデータを受信側へ連続した一つのデータとして転送することができ、受信側の効率のよい処理を助けることが可能となる。
【００９０】
(3)本具体例のＰＣＩヘッダを使用することにより、受信側はネクストポインタを先行して辿ることにより、受信用の連続空間として必要なサイズをコピー前に知ることができる。
【００９１】
《具体例５》
具体例５は、各機能間の通信を共通の手順で行うためのデバイス管理用テーブルの構造に関するものである。
【００９２】
〈構成〉
図２１は、具体例５の構成および処理の説明図である。
ＰＣＩバスを経由して接続している複数のデバイス上に機能（Func）０〜機能（Func）５までの６個の機能が搭載されているとする。そのそれぞれの機能に対して、次に示すような構造を持つデバイスプロファイルを配列構造で機能数分だけ割り当てる。
【００９３】
図２２は、デバイスプロファイルの構造図である。
図示のように、デバイスプロファイルは、各機能の種類を識別するためのClassCodeと、デバイスプロファイルのバージョンを特定するRev.と、送信先のメールボックス（Mail Box）の先頭アドレスを特定するメールボックスポインタ（&Mail Box）と、送信先処理に割り込みを発生させる割り込み要求レジスタの先頭アドレスである割り込み要求レジスタポインタ（&PIR：以下、ＰＩＲポインタという）と、自分宛のコマンドとその引数を格納するメールボックス（Mail Box）と、コンフィグ アドレス フォーマット（CONFIG_ADDRESS Farmat）と、フリーエリア（FREE Area）で構成されている。
【００９４】
次に、メールボックスポインタ（&Mail Box）の構造について説明する。
図２３は、メールボックスポインタの構造を示す説明図である。
図示のように、各機能に対して割り当てられたデバイスプロファイルの配列は、全システム内に存在する機能（Func）の数と同数であり、配列の添え字（０〜５）は機能番号（Func0〜Func5）に対応している。
【００９５】
従って、例えば、機能４に割り当てられたデバイスプロファイルの配列を例に取ると、デバイスプロファイル［０］のメールボックスポインタ（&Mail Box）は、機能０のデバイスプロファイル［４］のメールボックス（Mail Box）の先頭アドレスを指す。
【００９６】
以下、同様に、
デバイスプロファイル［１］のメールボックスポインタは、機能１のデバイスプロファイル［４］のメールボックスの先頭アドレスを指す。
デバイスプロファイル［２］のメールボックスポインタは、機能２のデバイスプロファイル［４］のメールボックスの先頭アドレスを指す。
デバイスプロファイル［３］のメールボックスポインタは、機能３のデバイスプロファイル［４］のメールボックスの先頭アドレスを指す。
デバイスプロファイル［４］のメールボックスポインタは、機能４のデバイスプロファイル［４］のメールボックスの先頭アドレスを指す。
デバイスプロファイル［５］のメールボックスポインタは、機能５のデバイスプロファイル［４］のメールボックスの先頭アドレスを指す。
【００９７】
即ち、機能Ｘのデバイスプロファイル［Ｙ］のメールボックスポインタは、機能Ｙのデバイスプロファイル［Ｘ］のメールボックスの先頭アドレスを示している。つまり、各機能は、お互いに他の機能に対するメールボックスを持つよう構成されている。
【００９８】
次に、ＰＩＲポインタ（&PIR）の構造を説明する。
図２４は、ＰＩＲポインタの構造を示す説明図である。
機能４に割り当てられたデバイスプロファイルの配列を例に取ると、デバイスプロファイル［０］のＰＩＲポインタは、機能０のＰＩＲの先頭アドレスを指す。
【００９９】
以下、同様に、
デバイスプロファイル［１］のＰＩＲポインタは、機能１のＰＩＲの先頭アドレスを指す。
デバイスプロファイル［２］のＰＩＲポインタは、機能２のＰＩＲの先頭アドレスを指す。
デバイスプロファイル［３］のＰＩＲポインタは、機能３のＰＩＲの先頭アドレスを指す。
デバイスプロファイル［４］のＰＩＲポインタは、機能４のＰＩＲの先頭アドレスを指す。
デバイスプロファイル［５］のＰＩＲポインタは、機能５のＰＩＲの先頭アドレスを指す。
【０１００】
即ち、いずれかの機能のデバイスプロファイル［Ｘ］のＰＩＲポインタは、機能ＸのＰＩＲの先頭アドレスを示している。つまり、各機能はお互いに他の機能に対するＰＩＲポインタを持つよう構成されている。
【０１０１】
次にメールボックスの構造について説明する。
図２５は、メールボックスの構造を示す説明図である。
機能４に割り当てられたデバイスプロファイルの配列を例に取ると、機能０から機能４へのコマンド通知は、デバイスプロファイル［０］のメールボックスに対して行われる。尚、図中、デバイス１（Device１）中のデバイスプロファイル（Device Profile）は、機能４のデバイスプロファイルを示している。
【０１０２】
以下、同様に、
機能１から機能４へのコマンド通知は、デバイスプロファイル［１］のメールボックスに対して行われる。
機能２から機能４へのコマンド通知は、デバイスプロファイル［２］のメールボックスに対して行われる。
機能３から機能４へのコマンド通知は、デバイスプロファイル［３］のメールボックスに対して行われる。
機能４から機能４へのコマンド通知は、通常発生しないが、デバイスプロファイル［４］のメールボックスに対して行われる。
機能５から機能４へのコマンド通知は、デバイスプロファイル［５］のメールボックスに対して行われる。
【０１０３】
即ち、機能Ｘから機能Ｙへのコマンド通知は、機能Ｙのデバイスプロファイル［Ｘ］のメールボックスに対して行われる。つまり、各機能は、お互いに自身に持つ他の機能宛のメールボックスにコマンド通知を行うよう構成されている。
【０１０４】
〈動作〉
図２６は、具体例５の動作フローチャートである。
送信側デバイスの機能は、送信先デバイスの機能が持つメールボックスのアドレスを調べる（ステップＳ２６１）。調べたメールボックスアドレスに対してメールを投函する（ステップＳ２６２）。次に、メールボックスのＭＢＡｒｅａ１にＰＣＩコマンドを格納し、ＭＢＡｒｅａ２にＭＢＡｒｅａ１に格納したＰＣＩコマンドに対応する第一引数を格納し、ＭＢＡｒｅａ３に第二引数を格納する処理をメールボックスにメールを投函すると定義する。
【０１０５】
次に、送信先に割り込みを発生させ、メールボックスに格納したコマンドを受信させるために、送信先のＰＩＲ先頭アドレスを調べる（ステップＳ２６３）。調べたＰＩＲアドレスに対して０以外の数値を書き込む（ステップＳ２６４）。このオペレーションにより、送信先に対して割り込みが発生する。
【０１０６】
受信側では、割り込みが発生すると送信元の機能を識別する（ステップＳ２６５）。通常、デバイスプロファイルのメールボックスをデバイスプロファイル［０］から順にチェックする等の処理を行う。
【０１０７】
次に、メールボックスに書き込まれているＰＣＩコマンドを解析し、コマンドの内容に沿った処理に分岐する（ステップＳ２６６）。仮に、データの受信要求であった場合は、ＭＢＡｒｅａ２より第一引数としてデータの先頭アドレスを読み出し、ＭＢＡｒｅａ３より第二引数としてデータのサイズを読み出し、自分のワークエリアに対してコピーする（ステップＳ２６７）。
【０１０８】
次に、上記ステップＳ２６１の送信先デバイス上の機能に対応するメールボックスアドレスの調べ方を説明する。
【０１０９】
図２７は、送信先デバイス上の機能に対応するメールボックスアドレスの調べ方の説明図である。
通信先のメールボックスアドレスは、通信元が持っているデバイスプロファイル一式の中に存在している。通信元のデバイスプロファイル一式中で、送信先に対応するデバイスプロファイル中に、送信先のデバイスプロファイル一式中で送信元に対応するデバイスプロファイルのメールボックスアドレスが格納されている。
【０１１０】
例えば、機能４から機能０に対してＰＣＩコマンドを送信する場合を例とすると、機能０に割り当てられているデバイスプロファイル配列のデバイスプロファイル［４］中のメールボックスの先頭アドレスを格納している。よって、機能４は機能０に対してＰＣＩコマンドを送信する場合は、自分に割り当てられているデバイスプロファイル［０］のメールボックスポインタを参照することにより、目的のメールボックスアドレスを得ることができる。
【０１１１】
次に、上記ステップＳ２６２のメールボックスへのメールを投函する処理を説明する。
図２８は、そのメールボックスへのメール投函処理の説明図である。
【０１１２】
ここで、機能４が機能３に対してデータを送信するためにメールを送信する場合を例とする。
機能４は機能３が割り当てられたデバイスプロファイル配列のデバイスプロファイル［４］中のメールボックスに対して、ＭＢＡｒｅａ１に「受信要求」を示すコマンドを、ＭＢＡｒｅａ２に送信データ先頭アドレスを、ＭＢＡｒｅａ３に送信データサイズを格納する。
【０１１３】
次に、上記ステップＳ２６３の送信先デバイス上の機能に対応するＰＩＲアドレスの調べ方を説明する。
図２９は、その送信先デバイス上の機能に対応するＰＩＲアドレスの調べ方の説明図である。
【０１１４】
通信先のＰＩＲアドレスは、通信元が持っているデバイスプロファイル一式の中に存在している。通信元のデバイスプロファイル一式中で、送信先に対応するデバイスプロファイル中にＰＩＲアドレスは格納されている。
【０１１５】
機能４から機能０に対してＰＣＩコマンドを送信する場合を例とすると、機能０が割り当てられているデバイスプロファイル配列のデバイスプロファイル［０］中のＰＩＲポインタ（&PIR）を参照することにより、機能４は機能０に対して割り込みを発生させることが可能となる。
【０１１６】
〈効果〉
以上のように、具体例５によれば、各機能間の通信を共通の手順で行うためのデバイス管理用テーブルを備えるようにしたので、以下のような効果が期待できる。
【０１１７】
図３０は、具体例５の効果の説明図である。
(1)図３０に示すような接続環境において任意の機能からＰＣＩバスマスタ上の機能への通信、複数機能を搭載するデバイス上のそれぞれの機能への通信、単一機能を搭載するデバイス上の機能への通信、そして、自デバイス上の他の機能への通信を共通の手順で実現することが可能となる。
【０１１８】
(2)デバイス間の通信において必ずＰＣＩバスマスタを経由しなければならない必要がないため、ＰＣＩバスマスタの通信における負荷を減少させることができる。
【０１１９】
《具体例６》
具体例６は、具体例５におけるデバイス管理用テーブルの作成手段に関するものである。
【０１２０】
〈構成〉
図３１は、具体例６の構成および処理を示す説明図である。
図示のように、ＰＣＩバスマスタは、コピー先アドレス問い合わせ処理部３１１と、メールボックスポインタ計算処理部３１２を備えている。
【０１２１】
コピー先アドレス問い合わせ処理部３１１は、各インテリジェントデバイスの機能に対して、配布するデバイスプロファイルのサイズと個数とを通知することによりコピーする先頭アドレスを入手する機能を有している。また、メールボックスポインタ計算処理部３１２は、コピー先アドレス問い合わせ処理部３１１で求めたコピーする先頭アドレスに基づき、配布するデバイスプロファイルのメールボックスポインタを求める機能を有している。
【０１２２】
〈動作〉
本具体例では、具体例５で説明したデバイスプロファイル配列の作成をより効率的に行うようにしたものである。
【０１２３】
デバイスプロファイル配列一式の作成は、全てＰＣＩバスマスタで行う。ＰＣＩバスマスタは、各デバイスプロファイル配列作成後に、各インテリジェントデバイスに対してデバイスプロファイル配列を割り当てる。
【０１２４】
以下、メールボックスポインタの決定方法についてその手順を説明する。メールボックスポインタの決定は以下の手順で行う。
(1)デバイスプロファイル配列のコピー先アドレス問い合わせ処理
(2)メールボックスポインタ計算処理
【０１２５】
先ず、コピー先アドレス問い合わせ処理部３１１が行うデバイスプロファイル配列コピー先アドレス問い合わせ処理について説明する。
図３２は、デバイスプロファイル配列のコピー先アドレス問い合わせ処理の説明図である。
図３３は、デバイスプロファイル配列のコピー先アドレス回答処理の説明図である。
【０１２６】
ＰＣＩバスマスタは、自分の管理するＰＣＩバス上に存在する全てのインテリジェントデバイスに対して図３２に示す手順でデバイスプロファイル配列のコピー先アドレスを問い合わせる。
【０１２７】
ＰＣＩバスマスタは、割り当てるべきデバイスプロファイル配列中のデバイスプロファイルの個数と、デバイスプロファイル配列全体のサイズを割当先インテリジェントデバイスへ通知する。この通信手順は、具体例３で説明した方法を使用した例である。
【０１２８】
次に、ＰＣＩバスマスタよりデバイスプロファイルに関する情報を受け取ったインテリジェントデバイスは、図３３に示す手順で、デバイスプロファイル配列のコピー先アドレスを回答する。本通信手順も具体例３で説明したものを使用した例である。
【０１２９】
図３４は、メールボックスポインタ計算処理の説明図である。
先ず、図３４において、ＰＣＩバスマスタが全てのデバイスプロファイル配列のメールボックスポインタを求める概念について説明する。
【０１３０】
ＰＣＩバスマスタは、ＰＣＩバスに接続している全機能に対してデバイスプロファイル配列を作成する。例として、機能１（Func１）用のデバイスプロファイル配列を作成する場合を想定する。
【０１３１】
先ず、デバイスプロファイル［０］のメールボックスポインタを、デバイスプロファイル［１］は自分用なので省略し、次にデバイスプロファイル［２］のメールボックスポインタを、そして全機能分のメールボックスポインタを決定する。
【０１３２】
例として、デバイスプロファイル［２］のメールボックスポインタを設定する場合を想定する。
先ず、デバイスプロファイル［２］は、機能２（Func２）に送信する場合のメールボックスのアドレスでなければならないため、デバイスプロファイル配列を機能２にコピーしたと仮定する（図中、▲１▼で示す）。次に、機能１が各機能にＰＣＩコマンドを送信する場合は、各機能が持つデバイスプロファイル配列の１番に書き込むわけなので、デバイスプロファイル［１］が対象となる（図中、▲２▼で示す）。
【０１３３】
機能２にコピーした場合のデバイスプロファイル［１］中のメールボックスポインタのアドレスを求める（図中、▲３▼で示す）。求めたアドレスは作成中の機能１用に割り当てるデバイスプロファイル［２］におけるメールボックスポインタに格納する（図中、▲４▼で示す）。
【０１３４】
本具体例では、図中の▲１▼で示す「デバイスプロファイル配列を機能２にコピーしたと仮定する」処理を、デバイスプロファイル配列コピー先アドレスを問い合わせることにより求めている。
【０１３５】
次に、ＰＣＩバスマスタの具体的なメールボックスポインタの設定手順を説明する。
図３５は、ＰＣＩバスマスタの具体的なメールボックスポインタの設定手順を示す説明図である。
先ず、作成するデバイスプロファイル配列を割り当てる機能番号をカレント番号としてＸに設定する（ステップＳ３５１）。次に、最後の機能分の作成が終了したかを判断する（ステップＳ３５２）。ここで、全機能分のデバイスプロファイル配列の作成が終了した場合は本処理を終了する。
【０１３６】
現在カレントになっている機能のデバイスプロファイル配列が全て作成終了しているかを判断する（ステップＳ３５３）。ここで、デバイスプロファイル配列の作成が終了している場合は、ステップＳ３５７に移行する。
【０１３７】
作成するデバイスプロファイルが対応する機能が、インテリジェントデバイスであるかノン−インテリジェントデバイスであるかを判断する。即ち、機能１に対応するデバイスプロファイルはデバイスプロファイル［１］、機能２に対応するデバイスプロファイルはデバイスプロファイル［２］である。
【０１３８】
ステップＳ３５４において、対応する機能がノン−インテリジェントデバイスである場合はステップＳ３５６に移行する。一方、ステップＳ３５４において、対応する機能がインテリジェントデバイスである場合は、メールボックスアドレスを算出し、デバイスプロファイルのメールボックスポインタに格納する（ステップＳ３５５）。現在カレントになっている機能番号をＸ、デバイスプロファイルのサイズをＺ、デバイスプロファイルの先頭からメールボックスまでのオフセットをＭ、現在処理しているデバイスプロファイル配列の添え字をｙとし、前工程で機能ｙから受信したデバイスプロファイル配列コピー先アドレスをＹとすると、メールボックスアドレスは以下の式で求められる。
【０１３９】
＆Ｍａｉｌ Ｂｏｘ＝ＸＺ＋Ｙ＋Ｍ
そして、次のデバイスプロファイルへと移動し（ステップＳ３５６）、その後、ステップＳ３５３に戻る。ここで、移動は、同一の機能用に作成しているデバイスプロファイル配列中で一つ増加する方向へ移る。
【０１４０】
ステップＳ３５３において、デバイスプロファイルの残りがなかった場合、作成しているデバイスプロファイル配列を割り当てる機能を次に移動する（ステップＳ３５７）。移動は、デバイスプロファイルの添え字を０に戻し、機能番号を一つ増加する方向へ移る。その後、ステップＳ３５２に移行する。
【０１４１】
〈効果〉
以上のように、具体例６によれば、ＰＣＩバスマスタがデバイス管理用テーブルを作成して各インテリジェントデバイスに配布するようにしたので、次のような効果が期待できる。
【０１４２】
(1)全てのデバイスプロファイルの初期化をＰＣＩバスマスタが行うため、各々のデバイスの開発が容易となる。
(2)デバイスプロファイルの構造に項目が追加された場合でも、ＰＣＩバスマスタ以外のデバイスの処理を変更する必要がない。
【０１４３】
《具体例７》
具体例７は、具体例５における割り込み要求レジスタ（ＰＩＲ）のビットを各機能に割り当てるようにしたものである。
【０１４４】
〈構成〉
図３６は、具体例７の割り込み要求レジスタの構成図である。
具体例７は、具体例５の構成に加えて、図３６に示すような割り込み要求レジスタを備えたものである。
【０１４５】
割り込み要求レジスタ（ＰＩＲ）は、最上位ビット３１がセット・クリアを示すフラグとなっており、ビット０〜ビット３０のいずれかに１をセットし、最上位ビット３１に１をセットすることによりビット０〜ビット３０に対してセットした１が反映され、このＰＩＲが持つシステムに対して割り込みを発生させるよう構成されている。
【０１４６】
一度、ビット０〜ビット３１に対して反映された１は、反映されたビットを１にし、最上位ビット３１に０をセットすることにより、０にクリアすることができるよう構成されている。このような仕様を持つ割り込み要求レジスタを各インテリジェントデバイスに対して一つ設ける。
【０１４７】
〈動作〉
具体例５で説明したメールボックスを使用する通信方法を使用した場合を例として以下に説明する。
図３７は、送信側が行うＰＣＩの割り込み要求レジスタの使用方法の説明図である。
図示例では、機能４（Func４）が機能３（Func３）にコマンドを通知する処理を例としている。
【０１４８】
先ず、機能４を持つインテリジェントデバイスは、送信するデータの情報（「受信要求」を示すコマンド、データの先頭アドレス、データのサイズ）を規定されたメールボックスに対して格納する。
【０１４９】
次に、格納したことを機能３に通知するために機能３が持つＰＩＲに対して決められた値を書き込む。ＰＩＲに０以外の値が書き込まれたことにより機能３に割り込みが発生する。
【０１５０】
図３８は、ＰＩＲの各ビットにおける意味づけの説明図である。
ＰＩＲの各ビットは、同一ＰＣＩバス上に接続された各機能にそれぞれ対応している。ビット０が機能０に、ビット１が機能１に、ビット２が機能２にといったように、以下同様にしてビット３０が機能３０の機能に対応する。但し、この対応は、ハードウェア的な結線とは関係なくソフトウェア上で対応させている状態を示す。
【０１５１】
更に、ＰＩＲの仕様として、ビット０〜ビット３０は各機能に対応しているが、ビット３１は〈構成〉の項で説明したように、ビット０〜ビット３０に対してセットされた１のデータが割り込みを要求するものか、解除するものかを指定するビットとなっている。ビット０〜ビット３０に対する０の書き込みは何の意味もなさない。よって、このレジスタが、（00000000 00000000 00000000 10010000）である時に、（10000000 00000000 00000000 00000001）を書き込んだ時には（00000000 00000000 00000000 10010001）となる構造を持つ。即ち、セット時は各ビットのＯＲとなる。
【０１５２】
尚、クリア時はビット０〜ビット３０のうち、１のデータのビットがクリアされる。例えば、図示のように、（X0000000 00001000 10001000 10001000）である時に、（00000000 00000000 00000000 11111111）を書き込んだ時には、ビット０〜ビット７の値がクリアされるため、（X0000000 00001000 10001000 00000000）となる。
【０１５３】
次に、送信先のＰＩＲに書き込む決められた値を説明する。
図３９は、送信先のＰＩＲに書き込む決められた値を示す説明図である。
機能１が他の機能に対して割り込みを入れる場合は、固定的にビット１とビット３１のみを１にしたデータを割り込み先のＰＩＲに対して書き込む。このことにより、受信側で割り込み要求を出した機能を特定することが可能となる。
【０１５４】
機能の番号は、初期化時にＰＣＩバスマスタより配布されたデバイスプロファイル配列とした時の添え字に該当する。よって、ダイナミックに割り当てられる数値である。
【０１５５】
受信側が行うＰＣＩの割り込み要求レジスタの使用方法を説明する。
図４０は、その受信側が行うＰＣＩの割り込み要求レジスタの使用方法の説明図である。
【０１５６】
図４０では、割り込みが発生するとＰＩＲの値を読み込む。ＰＩＲ中のデータは、図３９に示すように割り込みの要求元を示している。機能４により割り込みが要求された場合は、ＰＩＲのビット４が１にセットされている。機能３は、ＰＩＲのビット４が１にセットされていることにより、割り込みの要求元が機能４であることを知ることができる。
【０１５７】
機能３は、割り込みの要求元が機能４と分かることにより、機能４が対応するデバイスプロファイル［４］のメールボックスにコマンドを格納していることを知り、コマンドを読み出し、コマンドの解析処理へ移行する。
【０１５８】
また、機能３の割り込み処理が起動した時点で、複数の機能から割り込み要求が極めて短い時間に発生した場合に複数のビットが１にセットされている可能性がある。このような場合にも本具体例は対応することができる。
【０１５９】
〈効果〉
以上のように、具体例７によれば、ＰＩＲの各ビットを、それぞれ各機能と一意に対応づけるようにしたので、以下のような効果が期待できる。
【０１６０】
(1)コマンドを受信したデバイス（機能）は、ＰＩＲをチェックするだけでコマンド送信元のデバイス（機能）を特定することができる。
(2)複数の機能から割り込み要求が極めて短い時間に発生した場合に複数のビットが１にセットされている可能性があるが、特別な対応なく同じ手順で対応することができる。
【０１６１】
《具体例８》
具体例８は、ＰＣＩヘッダ中に、次の送信データの情報と、データエリアのポインタと、データサイズとを備えるようにしたものである。
【０１６２】
〈構成〉
図４１は、具体例８におけるＰＣＩヘッダの構成図である。
ＰＣＩヘッダ（PCI Header）は、ＰＣＩヘッダ同士をアドレスでつなぎ、リンク構造で管理する場合に使用するネクストポインタ（Next Pointer）と、送信するデータの先頭アドレスを示すデータエリアポインタ（Data Area Pointer）と、送信するデータのサイズを示すデータサイズ（Data Size）の各領域から構成される。尚、このＰＣＩヘッダの構造は具体例４で説明したＰＣＩヘッダと基本的に同様である。
【０１６３】
〈動作〉
図４２は、本具体例の動作の基本的概念を示す説明図である。
データ送信側のインテリジェントデバイスは、受信側のインテリジェントデバイスに対して送信するデータの情報（データ先頭アドレス、データサイズ）と共にデータ「受信要求」を示すコマンドを送信する。
【０１６４】
受信側は、「受信要求」を示すコマンドを認識すると、データの情報（データ先頭アドレス、データサイズ）を元にデータのコピーを行う。データのコピー後、受信側は受信完了を送信側に対して連絡するため「受信応答」を示すコマンドを送信する。
【０１６５】
以上のようなコマンドによる逐次転送が基本となっている。よって、送信側は、送信したコマンドに対する応答が受信側より来る前に次のコマンドを送信することができない仕組みになっている。この仕組みの長所は確実なデータ転送ができる点にあるが、データの高速転送には不向きである。
【０１６６】
そこで、本具体例では、上記の長所を失うことなく高速な転送手段を提供する。先ず、本具体例で使用するＰＣＩデータの構造を図４１を用いて説明する。
【０１６７】
本具体例のＰＣＩ通信では、直接データを扱わず、図に示すＰＣＩヘッダを使用しデータを管理する。ＰＣＩヘッダは、データを先頭アドレスとデータサイズにより管理する。更に、上述したように、ＰＣＩヘッダ同士をリンクするネクストポインタを含む構造を持っている。
【０１６８】
以上説明したデータ管理方法を使用し、高速転送を行う手順を以下に説明する。
送信側は、一つの「受信要求」を示すコマンドに対する「受信応答」を示すコマンドを受信するまでは、上位層より送信要求が来ても同一の受信側に対しては「受信要求」を発信することはできない。
【０１６９】
図４３は、このような連続送信時の送信側のシーケンスを示す説明図である。
送信元ＰＣＩデバイスドライバは、最初の送信データ（１）を上位層から受け付けると、ＰＣＩヘッダをデータ（１）にリンクさせる（図中、▲１▼で示す）。この時点でＰＣＩヘッダには０を代入する。
【０１７０】
送信元ＰＣＩデバイスドライバは、受信側デバイスドライバに対して「受信要求」コマンドを送信する（図中▲２▼で示す）。送信元デバイスドライバは、受信側デバイスドライバからの「受信応答」コマンドを受信する前に次の送信データ（２）を上位層より受け付けると、ＰＣＩヘッダをデータ（２）にリンクさせ（図中、▲３▼で示す）、データ（１）を管理しているＰＣＩヘッダのネクストポインタをデータ（２）を管理しているＰＣＩヘッダの先頭にリンクさせる（図中、▲４▼で示す）。送信元デバイスドライバは、受信側デバイスドライバから「受信応答」コマンドを受信する前に更に次の送信データ（３）を上位層より受け付けると、ＰＣＩヘッダをデータ（３）にリンクさせ、データ（２）を管理しているＰＣＩヘッダのネクストポインタをデータ（３）を管理しているＰＣＩヘッダの先頭にリンクさせる（図中、▲６▼で示す）。以上のように、受信側ＰＣＩデバイスドライバからの「受信応答」コマンドを受信するまでこのような操作を繰り返す。
【０１７１】
以上の処理では、受信側がネクストポインタを見るタイミングにより、リンクしたことが受信側に認識されない場合が発生する。このような場合を次に説明する。
【０１７２】
図４４は、リンクしたことが受信側に認識されない場合の説明図である。
図において、▲６▼のタイミングと前後して受信側からデータ（２）まで受信完了したことを示す「受信応答」コマンドを受信すると（図中、▲７▼で示す）、送信側インテリジェントデバイスは、データ（３）からの「受信要求」コマンドを送信する（図中、▲８▼で示す）。送信側は以上の処理が全てとなる。
【０１７３】
次に、連続送信時の受信側のシーケンスを説明する。
図４５は、連続送信時の受信側のシーケンスを示す説明図である。
受信側のＰＣＩデバイスドライバは、送信側ＰＣＩデバイスドライバから「受信要求」コマンドを受信すると（図中、▲１▼で示す）、コマンドの引数であるＰＣＩヘッダの先頭アドレスと、ＰＣＩヘッダのサイズからＰＣＩヘッダのコピーを行う（ステップＳ４５１）。送信側上位層からの送信データの情報（先頭アドレス、データサイズ）は、ＰＣＩヘッダ中で管理されているため、ＰＣＩデバイスドライバ間でやり取りするコマンドの引数はＰＣＩヘッダの情報となる。
【０１７４】
次に、受信側のＰＣＩデバイスドライバは受信したＰＣＩヘッダの管理する情報からデータの（１）の先頭アドレスとデータサイズを読み出す（ステップＳ４５２）。そして、その情報に従いデータをコピーする（ステップＳ４５３）。
【０１７５】
受信側のＰＣＩデバイスドライバは、受信したＰＣＩヘッダの管理する情報からネクストポインタを読み出しＮＵＬＬであるか判断する（ステップＳ４５４）。ＮＵＬＬである場合は後続のデータが存在しないことを意味するので、ステップＳ４５８に移行する。ＮＵＬＬでない場合は、後続のデータが存在することを意味するので、ステップＳ４５５に移行する。受信側のＰＣＩデバイスドライバは、受信したＰＣＩヘッダの管理する情報からデータ（２）の先頭アドレスとデータサイズを読み出す（ステップＳ４５６）。そして、その情報に従いデータをコピーする（ステップＳ４５７）。
【０１７６】
受信側のデバイスドライバは、以上の工程で「受信要求」コマンドを受信してから一定時間内に「受信応答」コマンドを送信する必要がある。図では、データ（２）を受信したところでタイムアウトが迫ったため、データ（３）の受信をあきらめ、応答を送信側ＰＣＩデバイスドライバへ返している（ステップＳ４５８）。
【０１７７】
また、ステップＳ４５４と同様の判断を各データコピーの完了時に行い、ＰＣＩヘッダのネクストポインタがＮＵＬＬである場合も応答の送信を行う。
【０１７８】
また、ＰＣＩヘッダのネクストポインタを次々に先読みし、予め受信するデータの総容量を見積り、その後にデータをコピーする手段をとることもできる。
【０１７９】
図４６は、予め受信するデータの総容量を見積り、その後にデータをコピーする場合の説明図である。
即ち、図示のように、受信側ＰＣＩデバイスドライバでは、ネクストポインタが０となるまでＰＣＩヘッダをコピーし（ステップＳ４６１〜ステップＳ４６４）、その後データをコピーする（ステップＳ４６５〜ステップＳ４６８）。尚、ネクストポインタが０か、コマンド受信から２秒以内に受信応答を行う（ステップＳ４６９）のは、上記の連続送信時の受信側のシーケンスと同様である。
【０１８０】
また、受信側の都合により、一つのコマンド・レスポンスに対して一つのデータを送受信することも問題なくできる。
つまり、本具体例の通信方式では受信側の受信方法を柔軟に作成することができる。これは、様々なデバイスを接続しなければならないＰＣＩバス間の通信方法としては重要な項目である。
【０１８１】
〈効果〉
以上のように、具体例８によれば、ＰＣＩヘッダ中に、次の送信データの情報と、データエリアのポインタと、データサイズとを備えるようにしたので、以下に示すような効果が期待できる。
【０１８２】
(1)一つのデータブロック転送において、一組のコマンド・レスポンスを必要としないため、高速なデータ転送を実現することができる。
(2)一定時間毎にレスポンスを出すことのみが決まっているだけであるため、受信側の受信方法を柔軟に作成することができる。これは、様々なデバイスを接続しなければならないＰＣＩバス間の通信方法としては重要な項目である。
【０１８３】
《具体例９》
具体例９は、自層の処理を行うヘッダ情報中に、ヘッダのサイズを示す情報と、ヘッダ情報のバイト数が特定の値の倍数となるような可変長のデータであるパディングとを付加するようにしたものである。
【０１８４】
〈構成〉
具体例１の構成において、ＰＣＩデバイスドライバの上位層としてゲート層を定義する。
【０１８５】
図４７は、ゲートヘッダの説明図である。
ゲートヘッダ（Gate Header）が付いたデータをゲートパケット（Gate Packet）として図示の構成をとる。ゲートヘッダは、ヘッダテールに上位層データの境界を調節するパディング（Padding）領域と、そのパディング領域を含めたゲートヘッダサイズを示すヘッダサイズ（Header Size）領域を持つことを特徴とする。
【０１８６】
図４８は、ヘッダサイズ領域の説明図である。
図示のように、ゲートヘッダは、ヘッダテールに上位層データの境界を調節するパディング領域と、このパディング領域を含めたゲートヘッダサイズを示すヘッダサイズ領域を持つ。
【０１８７】
〈動作〉
通常、階層構造で構成されている通信システムでは、送信データは、上位層データと、プロトコル層のヘッダ情報と、下位層（デバイスドライバ等）ヘッダとがアドレス的に接した構造をとっている。
【０１８８】
図４９は、パディング無しとパディングありの場合の説明図であり、（ａ）はパディング無し、（ｂ）はパディングありの場合である。
図の（ａ）に示すような階層構造で構成されている場合、プロトコル層で選択されるプロトコルによってヘッダのサイズが４バイト境界に揃わない場合が多い。これにより、上位層データが４バイト境界に揃わなくなり、このようなデータを受信した上位層は、ＤＭＡ等の高速データ転送手段が使用できなくなる。
【０１８９】
本具体例では、下位層と上位層（プロトコル層）との通信経路を制御するゲート層をデバイスドライバとプロトコル層の間に設け、そのヘッダ構造にパディング領域を設ける。このパディング領域を使用することにより、プロトコル層のヘッダ情報部のサイズに関係なく、全データ若しくは上位層データの開始位置を４バイト境界に揃えることができる。
【０１９０】
送信側動作について以下に説明する。
通常の送信手順では、４バイト境界に沿って上位層が送信データを作成する。次に上位層データの前部に接するようにプロトコル層のヘッダ情報を作成する。
【０１９１】
図５０は、上位層のデータがゲート層に来た時点の動作を示すフローチャートである。
ゲート層は、プロトコル層からの送信データを受信すると（ステップＳ５０１）。受信した送信データの先頭アドレスを４で割り、その余りを計算する（ステップＳ５０２）。その余りが０であった場合は、パディングの添付は行わず、ヘッダサイズにゲートヘッダのサイズである１２を格納する（ステップＳ５０３）。
【０１９２】
ステップＳ５０２において、余りが１であった場合、送信データの先頭アドレスの最後の数値は１、５、９、Ｄのどれかであるから、パディングを一つ添付する（ステップＳ５０４）。そして、ヘッダサイズにゲートヘッダのサイズである１２＋１を格納する（ステップＳ５０５）。
【０１９３】
ステップＳ５０２において、余りが２であった場合、送信データの先頭アドレスの最後の数値は２、６、Ａ、Ｅのどれかであるから、パディングを二つ添付する（ステップＳ５０６）。そして、ヘッダサイズにゲートヘッダのサイズである１２＋２を格納する（ステップＳ５０７）。
【０１９４】
ステップＳ５０２において、余りが３であった場合、送信データの先頭アドレスの最後の数値は３、７、Ｂ、Ｆのどれかであるから、パディングを三つ添付する（ステップＳ５０８）。そして、ヘッダサイズにゲートヘッダのサイズである１２＋３を格納する（ステップＳ５０９）。
【０１９５】
次に、受信側の処理において、デバイスドライバ（ＰＣＩデバイスドライバ）から受信データを受け取った時点の動作について説明する。
【０１９６】
図５１は、受信側の動作を示すフローチャートである。
ゲート層は、デバイスドライバが受信したデータを受け取ると（ステップＳ５１１）、ゲートヘッダ中のヘッダサイズをチェックする（ステップＳ５１２）。その値が１２である時、ゲートヘッダにパディングは付いていないと判断し、プロトコル層へ渡すアドレスを受信データ先頭アドレスにゲートヘッダ分を加えた位置に移動させる。
【０１９７】
ステップＳ５１２でチェックした結果、その値が１３である時、ゲートヘッダにパディングが一つ付いていると判断し、プロトコル層に渡すアドレスを受信データ先頭アドレスにゲートヘッダ＋２を加えた位置に移動させる（ステップＳ５１４）。
【０１９８】
ステップＳ５１２でチェックした結果、その値が１４である時、ゲートヘッダにパディングが二つ付いていると判断し、プロトコル層に渡すアドレスを受信データ先頭アドレスにゲートヘッダ＋３を加えた位置に移動させる（ステップＳ５１５）。
【０１９９】
ステップＳ５１２でチェックした結果、その値が１５である時、ゲートヘッダにパディングが三つ付いていると判断し、プロトコル層に渡すアドレスを受信データ先頭アドレスにゲートヘッダ＋３を加えた位置に移動させる（ステップＳ５１６）。
【０２００】
ゲート層は、上記ステップＳ５１３〜ステップＳ５１６で求めた先頭アドレスをプロトコル層へ通知する（ステップＳ５１７）。
【０２０１】
〈効果〉
以上のように、具体例９によれば、自層の処理を行うヘッダ情報中に、ヘッダのサイズを示す情報と、ヘッダ情報のバイト数が特定の値の倍数となるような可変長のデータであるパディングとを付加するようにしたので、以下のような効果が期待できる。
【０２０２】
(1)プロトコル層のヘッダ情報部のサイズに関係なく、上位層データの開始位置を４バイト境界に揃えることができる。
(2)プロトコル層のヘッダ情報部に関係なく、全データの開始位置を４バイト境界に揃えることができる。
【０２０３】
《具体例１０》
具体例１０は、各インテリジェントデバイスに、システムの初期化を行う機能を備えるようにしたものである。
【０２０４】
〈構成〉
図５２は、具体例１０の構成および処理の説明図である。
具体例１０は、具体例１の構成に対し、ＰＣＩバスマスタが唯一の初期化時に暫定的に初期化の主導権を持つ初期化時暫定マスタの機能を持つ点と、その他デバイスが他のデバイスを初期化する機能を持つ点とを付加している。
【０２０５】
図示のように、初期化時暫定マスタ側は、ゲートＩＤ振り分け処理と、マスタ募集処理とを行うよう構成され、デバイス側は、ゲートＩＤ入手処理と、マスタへの立候補処理とを行うよう構成されている。また、デバイス側は、デバイスマスタが自身に決定した場合は、他のデバイスの初期化処理を行うよう構成されている。
【０２０６】
〈動作〉
本具体例では、ＰＣＩデバイスドライバレベルの初期化をＰＣＩバスマスタが行った後に、暫定的に初期化の主導権を持つ初期化時暫定マスタ機能がＰＣＩバスマスタの上位層として動作する。
【０２０７】
本処理は、先ず上位層同士でお互いを認識するためのＩＤを割り当てる処理を実行する。次に暫定初期化以降の初期化の主導権を持つマスタの募集処理を実行する。この時に、ＰＣＩバスマスタ以外のデバイスはマスタになるための機能を有している場合は初期化時暫定マスタからのマスタ募集に対して立候補することができる。そして、初期化時暫定マスタからマスタ権を譲られた場合には、今後マスタとなり、全システム間の初期化を取りまとめる。初期化時暫定マスタは、他のデバイスにマスタ権を譲った場合は、以降一般のデバイスとして動作する。
【０２０８】
マスタとして動作するための機能をデバイスマスタと定義し、新しいデバイスマスタを決定するまでの手順を以下に説明する。
【０２０９】
図５３は、デバイスマスタの決定処理の説明図である。
先ず、ＰＣＩバスマスタが持つ初期化時暫定マスタの処理について説明する。
初期化時暫定マスタは、各インテリジェントデバイスに対してマスタを募集することを示す「デバイスマスタ募集」コマンドを送信する（ステップＳ５３１ａ）。そのコマンドの応答としてマスタになることができる／またはできないことを意味する「デバイスマスタ応募」コマンドを受信する（ステップＳ５３２ａ）。
【０２１０】
「デバイスマスタ募集」コマンドを送信した全てのインテリジェントデバイスより、「デバイスマスタ応募」コマンドを受信すると、その中から一つマスタとなるインテリジェントデバイスを選定する（ステップＳ５３３ａ）。
【０２１１】
初期化時暫定マスタは、マスタと選定したインテリジェントデバイスに対しては、以降のデバイス間初期化を依頼することを示す「デバイスマスタ決定」コマンドを、それ以外のインテリジェントデバイスに対しては、マスタとして選定しなかったことを示す「デバイスマスタ不採用」コマンドを送信する（ステップＳ５３４ａ）。
【０２１２】
次に、ＰＣＩバスマスタ以外のデバイスの処理について説明する。
各インテリジェントデバイスは、初期化時暫定マスタからの「デバイスマスタ募集」コマンドを受信すると（ステップＳ５３１ｂ）、自機能の中にデバイスマスタ機能が含まれているかを確認する（ステップＳ５３２ｂ）。含まれていない場合は引数でマスタに立候補しないことを示して初期化時暫定マスタに対して「デバイスマスタ応募」コマンドを送信する（ステップＳ５３３ｂ）。引数を使用する代わりにマスタに応募しないことを示す「デバイスマスタ非応募」コマンドを使用してもよい。
【０２１３】
「デバイスマスタ応募」コマンド、若しくは「デバイスマスタ非応募」コマンドを、初期化時暫定マスタに送信した後に、初期化時暫定マスタより「デバイスマスタ決定」コマンドまたは、「デバイスマスタ不採用」コマンドを受信する（ステップＳ５３４ｂ）。「デバイスマスタ決定」コマンドを受信した場合は、以降マスタとなり、システム間初期化の主導権を取る。「デバイスマスタ不採用」コマンドを受信した場合は、引き続き一般のデバイスとして動作する。
【０２１４】
ところで、本具体例の構成では、ＰＣＩデバイスドライバの上位にゲート層を設けている。ゲート層は主に複数の上位層（プロトコル層）と複数の下位層（デバイスドライバ）間の経路選択、経路制御を行う階層である。
【０２１５】
よって、デバイスマスタは、ゲートの初期化後、ゲートの通信機能を使用して各システム間のその他のイニシャルの主導権を握る。組み込み上、ゲート自身がデバイスマスタとしての機能を持つ必要はないが、以下のデバイスマスタの動作例ではデバイスマスタ機能がゲートに存在するものとして説明する。
【０２１６】
図５４は、デバイスマスタになるための条件を示す説明図である。
デバイスマスタは自システムの上位層が各システム間で初期化を行う時のキック（起動）をかける処理を受け持つ。各システム上の全ての上位層は、システム間で初期化開始を行う場合、デバイスマスタからの初期化開始要求を使用することにより他のシステム上の同一上位層との同期を取ることができ、双方で初期化を開始してしまう等の問題を回避できる。
【０２１７】
図５５は、デバイスマスタの初期化概要の説明図である。
本具体例では、上位層間初期化を行う上位層の例としてＸＸＸマネージャ、ＹＹＹマネージャを使用する（ＸＸＸマネージャ、ＹＹＹマネージャは任意の上位層）。
【０２１８】
デバイスマスタは上位層に対して「（主導権付き）初期化要求」を発信する。ここでは、ＸＸＸマネージャとＹＹＹマネージャに対して行っている。スレーブゲートは、上位層に対して「（主導権なし）初期化要求」を出す（出す／出さないは各システムのプログラム仕様による）。
【０２１９】
図示例では、デバイスマスタにより「（主導権付き）初期化要求」を受信したＸＸＸマネージャ、ＹＹＹマネージャはそれぞれ他システムのＸＸＸマネージャ、ＹＹＹマネージャに対して主導権を持ち初期化を行っている。
【０２２０】
〈効果〉
以上のように、具体例１０によれば、システムの初期化を行うデバイスをＰＣＩバスマスタ固定ではなく、各デバイス間とのやり取りで決定し、他のデバイスが受け持つことができるようにしたので、以下の効果が期待できる。
【０２２１】
(1)ＰＣＩバスマスタを持つシステムと対等の関係にあるシステムを開発し、バスに接続する場合にそのシステムにデバイスマスタを持たせる構造で開発することができるため、開発単位としてまとまる効果がある。よって、そのシステムの開発が容易になり、アウトソーシング等の戦略が取りやすい。
【０２２２】
(2)ＰＣＩバスマスタの初期化機能が正常に動作しない場合のバックアップ機能となる。よって、全システムの信頼性、保全性が向上する。
【図面の簡単な説明】
【図１】本発明のＰＣＩバス制御システムの具体例１を示す構成図である。
【図２】本発明のＰＣＩバス制御システムのソフトウェア階層構造を示す説明図である。
【図３】ノン−インテリジェントデバイス４の初期化の説明図である。
【図４】仮オーナ決定処理の説明図である。
【図５】仮オーナ決定シーケンスの説明図である。
【図６】サービスマネージャの初期化時における仮サービスの認識処理の説明図である。
【図７】サービス整合処理の説明図である。
【図８】具体例２におけるコンフィグレーションレジスタと拡張ＰＣＩ初期化処理の説明図である。
【図９】具体例２で設定するデバイスＩＤの説明図である。
【図１０】具体例２の動作フローチャートである。
【図１１】具体例３の説明図である。
【図１２】具体例３のＰＣＩバスマスタからデバイスへのコマンド送信動作の説明図である。
【図１３】コマンドの説明図（その１）である。
【図１４】コマンドの説明図（その２）である。
【図１５】各インテリジェントデバイスがＰＣＩバスマスタに拡張ＰＣＩコマンドを送信する場合の説明図である。
【図１６】具体例４の説明図である。
【図１７】具体例４のＰＣＩヘッダの構成図である。
【図１８】具体例４に関する問題の説明図である。
【図１９】具体例４の動作を示す説明図である。
【図２０】具体例４におけるデータ送信の概念を示す説明図である。
【図２１】具体例５の構成および処理の説明図である。
【図２２】デバイスプロファイルの構造図である。
【図２３】メールボックスポインタの構造を示す説明図である。
【図２４】ＰＩＲポインタの構造を示す説明図である。
【図２５】メールボックスの構造を示す説明図である。
【図２６】具体例５の動作フローチャートである。
【図２７】送信先デバイス上の機能に対応するメールボックスアドレスの調べ方の説明図である。
【図２８】メールボックスへのメール投函処理の説明図である。
【図２９】送信先デバイス上の機能に対応するＰＩＲアドレスの調べ方の説明図である。
【図３０】具体例５の効果の説明図である。
【図３１】具体例６の構成および処理を示す説明図である。
【図３２】デバイスプロファイル配列のコピー先アドレス問い合わせ処理の説明図である。
【図３３】デバイスプロファイル配列のコピー先アドレス回答処理の説明図である。
【図３４】メールボックスポインタ計算処理の説明図である。
【図３５】ＰＣＩバスマスタの具体的なメールボックスポインタの設定手順を示す説明図である。
【図３６】具体例７の割り込み要求レジスタの構成図である。
【図３７】送信側が行うＰＣＩの割り込み要求レジスタの使用方法の説明図である。
【図３８】ＰＩＲの各ビットにおける意味づけの説明図である。
【図３９】送信先のＰＩＲに書き込む決められた値を示す説明図である。
【図４０】受信側が行うＰＣＩの割り込み要求レジスタの使用方法の説明図である。
【図４１】具体例８におけるＰＣＩヘッダの構成図である。
【図４２】具体例８の動作の基本的概念を示す説明図である。
【図４３】連続送信時の送信側のシーケンスを示す説明図である。
【図４４】リンクしたことが受信側に認識されない場合の説明図である。
【図４５】連続送信時の受信側のシーケンスを示す説明図である。
【図４６】予め受信するデータの総容量を見積り、その後にデータをコピーする場合の説明図である。
【図４７】具体例９におけるゲートヘッダの説明図である。
【図４８】ヘッダサイズ領域の説明図である。
【図４９】パディング無しとパディングありの場合の説明図である。
【図５０】上位層のデータがゲート層に来た時点の動作を示すフローチャートである。
【図５１】具体例９の受信側の動作を示すフローチャートである。
【図５２】具体例１０の構成および処理の説明図である。
【図５３】デバイスマスタの決定処理の説明図である。
【図５４】デバイスマスタになるための条件を示す説明図である。
【図５５】デバイスマスタの初期化概要の説明図である。
【符号の説明】
１ ＰＣＩバス
２ プリンタ（ＰＣＩバスマスタ）
３ インテリジェントデバイス
４ ノン−インテリジェントデバイス
Claims (11)
- ＰＣＩバスマスタと、単独ではＰＣＩのバストランザクションを開始する機能を持たない複数のノン−インテリジェントデバイスと、ＰＣＩバスを経由した通信を自ら行う機能を持つインテリジェントデバイスとが接続されるＰＣＩバス制御システムであって、
前記ＰＣＩバスマスタは、
所定の前記ノン−インテリジェントデバイスの仮オーナを決定するために、前記インテリジェントデバイスに仮オーナ要求を示すコマンドを送信する機能と、
サービス情報送信要求を仮オーナの承諾した前記インテリジェントデバイスに送信する機能とを備え、
前記インテリジェントデバイスは、
前記ＰＣＩバスマスタからの仮オーナ要求を示すコマンドに対して承諾及び拒否のいずれかの受信応答を示すコマンドを前記ＰＣＩバスマスタに送信する機能と、
前記ＰＣＩバスマスタから受信した前記サービス情報送信要求に対し前記ノン−インテリジェントデバイスから対応するサービス情報を収集し、該サービス情報を前記ＰＣＩバスマスタに送信する機能と、
を備えることを特徴とするＰＣＩバス制御システム。 - 請求項１に記載のＰＣＩバス制御システムにおいて、
前記インテリジェントデバイスおよび前記ノン−インテリジェントデバイスは、
前記ＰＣＩバスマスタが各デバイスを初期化する際に参照するコンフィグレーションレジスタを備え、該レジスタの予め決められた先頭の数ビットを、インテリジェントデバイスかノン−インテリジェントデバイスかを識別するための値とすることを特徴とするＰＣＩバス制御システム。 - 請求項１または２に記載のＰＣＩバス制御システムにおいて、
前記インテリジェントデバイスおよび前記ノン−インテリジェントデバイスのメモリに、ＰＣＩデバイスドライバの初期化時に使用する通信用作業領域を設け、かつ、当該通信用作業領域をメモリ領域の先頭に設けたことを特徴とするＰＣＩバス制御システム。 - 請求項２に記載のＰＣＩバス制御システムにおいて、
前記先頭の数ビットは、各機能にマッピングする領域の先頭に設けた、ＰＣＩデバイスドライバの初期化時に使用する通信用作業領域を有するか否かを示す値であることを特徴とするＰＣＩバス制御システム。 - 請求項１に記載のＰＣＩバス制御システムにおいて、
送信側デバイスから受信側デバイスへの送信データの先頭に、次の送信データのＰＣＩヘッダの先頭アドレスを示すネクストポインタと、当該送信データにおけるデータエリアのアドレスを示すデータエリアポインタとを示すＰＣＩヘッダを備え、かつ、前記ネクストポインタの最下位ビットを、送信データが連続するか否かを示すフラグとしたことを特徴とするＰＣＩバス制御システム。 - 請求項１または２に記載のＰＣＩバス制御システムにおいて、
前記ＰＣＩバスマスタおよび前記インテリジェントデバイスは、
全システム内に存在する機能と一意に対応づけられ、各機能毎に設けられたデバイスプロファイルを有し、
各デバイスプロファイルは、送信先のメールボックスのアドレスを示すメールボックスポインタと、送信先の処理に割り込みを発生させる割り込み要求レジスタのアドレスを示す割り込み要求レジスタポインタと、自分宛のコマンドとその引数を格納するメールボックスとを備え、
機能ＸのデバイスプロファイルＹのメールボックスポインタは、機能ＹのデバイスプロファイルＸのメールボックスのアドレスを示し、各機能のデバイスプロファイルＸの割り込み要求レジスタポインタは、機能Ｘの割り込み要求レジスタのアドレスを示すよう構成されていることを特徴とするＰＣＩバス制御システム。 - 請求項６に記載のＰＣＩバス制御システムにおいて、
前記ＰＣＩバスマスタは、
前記インテリジェントデバイスの機能に対して、配布するデバイスプロファイルのサイズと個数とを通知することによりコピーする先頭アドレスを入手するコピー先アドレス問い合わせ処理部と、
前記コピーする先頭アドレスに基づき、配布するデバイスプロファイルのメールボックスポインタを求めるメールボックスポインタ計算処理部とを備えたことを特徴とするＰＣＩバス制御システム。 - 請求項６または７に記載のＰＣＩバス制御システムにおいて、
割り込み要求レジスタの各ビットは、それぞれ、各機能と一意に対応づけられ、かつ、各機能が他の機能に対して割り込みを要求する場合は、相手自身のビットに書き込みを行うよう構成されていることを特徴とするＰＣＩバス制御システム。 - 請求項１に記載のＰＣＩバス制御システムにおいて、
送信側デバイスから受信側デバイスへの送信データの先頭に、次の送信データのＰＣＩヘッダの先頭アドレスを示すネクストポインタと、当該送信データにおけるデータエリアのアドレスを示すデータエリアポインタと、当該送信データのデータサイズとを示すＰＣＩヘッダを備えたことを特徴とするＰＣＩバス制御システム。 - 請求項１、５または９のいずれかに記載のＰＣＩバス制御システムにおいて、
前記ＰＣＩバスマスタおよび前記インテリジェントデバイスは、
階層処理構造における自層の処理を行うヘッダ情報中に、ヘッダのサイズを示す情報を含むと共に、当該ヘッダ情報の総データ量が特定の値の倍数となるように可変長のデータであるパディングを付加するようにしたことを特徴とするＰＣＩバス制御システム。 - 請求項１、２、３、６、７、１０のいずれかに記載のＰＣＩバス制御システムにおいて、
前記インテリジェントデバイスは、
予め決められた初期化時暫定マスタよりデバイスマスタ募集があった場合、自身がデバイスマスタになれる条件を備えていた場合はデバイスマスタに応募し、デバイスマスタが自身に決定した場合は他のデバイスの初期化処理を行うよう構成されていることを特徴とするＰＣＩバス制御システム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP14927999A JP3791742B2 (ja) | 1999-05-28 | 1999-05-28 | Ｐｃｉバス制御システム |
| US09/579,173 US6678770B1 (en) | 1999-05-28 | 2000-05-25 | PCI bus control system having intelligent devices that own and manage non-intelligent devices for relaying information from non-intelligent devices |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP14927999A JP3791742B2 (ja) | 1999-05-28 | 1999-05-28 | Ｐｃｉバス制御システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000339267A JP2000339267A (ja) | 2000-12-08 |
| JP3791742B2 true JP3791742B2 (ja) | 2006-06-28 |
Family
ID=15471742
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP14927999A Expired - Fee Related JP3791742B2 (ja) | 1999-05-28 | 1999-05-28 | Ｐｃｉバス制御システム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6678770B1 (ja) |
| JP (1) | JP3791742B2 (ja) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100612003B1 (ko) * | 2000-02-26 | 2006-08-11 | 삼성전자주식회사 | 통신망에서 비트 스트림 송수신 장치 및 그 방법 |
| GB0028353D0 (en) * | 2000-11-21 | 2001-01-03 | Aspex Technology Ltd | Improvements relating to digital data communications |
| KR100391170B1 (ko) * | 2000-12-28 | 2003-07-12 | 엘지전자 주식회사 | 메인 프로세싱 회로 데이터 보드 |
| US20020178316A1 (en) * | 2001-05-23 | 2002-11-28 | Schmisseur Mark A. | System and method for defining private functions of a multi-function peripheral device |
| US7243167B2 (en) * | 2003-09-19 | 2007-07-10 | Intel Corporation | Managing peripheral device address space resources using a tunable bin-packing/knapsack algorithm |
| US7853742B2 (en) * | 2004-04-26 | 2010-12-14 | Intel Corporation | System and method to conditionally shrink an executable module |
| KR100599112B1 (ko) * | 2004-05-08 | 2006-07-13 | 삼성전자주식회사 | Ｐｃｉ 시스템에서 에이전트간 통신 방법 및 통신 장치 |
| CN1877537A (zh) * | 2005-06-10 | 2006-12-13 | 鸿富锦精密工业（深圳）有限公司 | 外围部件互连设备信息识别系统及方法 |
| KR101172885B1 (ko) * | 2008-12-18 | 2012-08-10 | 한국전자통신연구원 | 디바이스 식별자를 이용한 디바이스 프로파일 제공 시스템 및 방법 |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| ATE149713T1 (de) * | 1992-11-04 | 1997-03-15 | Siemens Ag | Anordnung mit mehreren aktiven und passiven busteilnehmern |
| US5515516A (en) * | 1994-03-01 | 1996-05-07 | Intel Corporation | Initialization mechanism for symmetric arbitration agents |
| US5838935A (en) * | 1995-06-15 | 1998-11-17 | Intel Corporation | Method and apparatus providing programmable decode modes for secondary PCI bus interfaces |
| US5848249A (en) * | 1995-06-15 | 1998-12-08 | Intel Corporation | Method and apparatus for enabling intelligent I/O subsystems using PCI I/O devices |
| US5790811A (en) * | 1996-05-17 | 1998-08-04 | Advanced Micro Devices, Inc. | System and method for performing data transfers during PCI idle clock cycles |
| US5842025A (en) * | 1996-08-27 | 1998-11-24 | Mmc Networks, Inc. | Arbitration methods and apparatus |
| US5815731A (en) * | 1996-10-31 | 1998-09-29 | International Business Machines Corporation | Method and system for providing device driver configurations on demand |
| US6041364A (en) * | 1996-12-19 | 2000-03-21 | Intel Corporation | Method and system for adding a device entry to a device tree upon detecting the connection of a device |
| US5983024A (en) * | 1997-11-26 | 1999-11-09 | Honeywell, Inc. | Method and apparatus for robust data broadcast on a peripheral component interconnect bus |
| US6023736A (en) * | 1997-12-19 | 2000-02-08 | International Business Machines Corporation | System for dynamically configuring I/O device adapters where a function configuration register contains ready/not ready flags corresponding to each I/O device adapter |
| JPH11238030A (ja) * | 1998-02-20 | 1999-08-31 | Mitsubishi Electric Corp | Ｐｃｉ−ｐｃｉブリッジおよびそのための先入れ先出しメモリ |
| US6073198A (en) * | 1998-03-31 | 2000-06-06 | Micron Electronics, Inc. | System for peer-to-peer mastering over a computer bus |
| US6266770B1 (en) * | 1998-04-14 | 2001-07-24 | Micron Technology, Inc. | Method for autonomous configuration of peer devices |
| US6119191A (en) * | 1998-09-01 | 2000-09-12 | International Business Machines Corporation | Performing PCI access cycles through PCI bridge hub routing |
| US6230216B1 (en) * | 1999-01-28 | 2001-05-08 | Vlsi Technology, Inc. | Method for eliminating dual address cycles in a peripheral component interconnect environment |
| US6223232B1 (en) * | 1999-02-22 | 2001-04-24 | Vlsi Technology, Inc. | System and method to predict configuration of a bus target |
| US6493777B1 (en) * | 1999-09-15 | 2002-12-10 | Lucent Technologies Inc. | Method for dynamically reconfiguring data bus control |
-
1999
- 1999-05-28 JP JP14927999A patent/JP3791742B2/ja not_active Expired - Fee Related
-
2000
- 2000-05-25 US US09/579,173 patent/US6678770B1/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US6678770B1 (en) | 2004-01-13 |
| JP2000339267A (ja) | 2000-12-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7822908B2 (en) | Discovery of a bridge device in a SAS communication system | |
| CN101115054B (zh) | 用于网络接口控制器的存储器映射的缓冲器 | |
| US7581015B2 (en) | Communication device having transmitting and receiving units supports RDMA communication | |
| KR100449807B1 (ko) | 호스트 버스 인터페이스를 갖는 데이터 전송 프로토콜제어 시스템 | |
| US4768150A (en) | Application program interface to networking functions | |
| US6185607B1 (en) | Method for managing network data transfers with minimal host processor involvement | |
| US10044796B2 (en) | Method and system for transmitting an application message between nodes of a clustered data processing system | |
| CN101937406B (zh) | 一种VxWorks操作系统中实现驱动1394设备的方法和系统 | |
| JP2002541554A (ja) | ユニバーサル・シリアル・バスに基づくｐｃフラッシュディスクのためのアーキテクチャ | |
| US5987530A (en) | Method for caching data and generating only one read request to read the requested data and additional data in universal serial bus system | |
| US9268490B2 (en) | Storage system | |
| JP3791742B2 (ja) | Ｐｃｉバス制御システム | |
| US8250260B2 (en) | Method, arrangement, data processing program and computer program product for exchanging message data in a distributed computer system | |
| CN102033840A (zh) | 总线协议转换装置和总线协议转换方法 | |
| US7069305B2 (en) | Computer system and a data transfer method thereof using remote direct memory access | |
| CN1331070C (zh) | 数据通信的方法及设备 | |
| US7043603B2 (en) | Storage device control unit and method of controlling the same | |
| JP4208506B2 (ja) | 高性能記憶装置アクセス環境 | |
| US6714994B1 (en) | Host bridge translating non-coherent packets from non-coherent link to coherent packets on conherent link and vice versa | |
| US7240167B2 (en) | Storage apparatus | |
| KR100653178B1 (ko) | 전송제어프로토콜 오프로드 엔진 기반의 전송제어프로토콜전송정보 생성 및 관리 장치 및 그 방법 | |
| US6678722B1 (en) | Interprocessor communication system for parallel processing | |
| JP5482263B2 (ja) | エンドポイント共有システムおよびデータ転送方法 | |
| CN113220238B (zh) | 一种通用sas控制器接口实现方法 | |
| JP3644158B2 (ja) | 並列計算機におけるデータ送受信方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050530 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050614 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050812 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051108 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060110 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060228 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060330 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100414 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100414 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110414 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110414 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130414 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140414 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |