JP3606145B2 - データ転送制御装置及び電子機器 - Google Patents
データ転送制御装置及び電子機器 Download PDFInfo
- Publication number
- JP3606145B2 JP3606145B2 JP37050199A JP37050199A JP3606145B2 JP 3606145 B2 JP3606145 B2 JP 3606145B2 JP 37050199 A JP37050199 A JP 37050199A JP 37050199 A JP37050199 A JP 37050199A JP 3606145 B2 JP3606145 B2 JP 3606145B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- queue
- received packet
- reset
- received
- 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
- 238000012546 transfer Methods 0.000 title claims description 103
- 238000012545 processing Methods 0.000 claims description 122
- 238000000034 method Methods 0.000 claims description 58
- 230000008569 process Effects 0.000 claims description 47
- 239000003795 chemical substances by application Substances 0.000 description 81
- 239000003999 initiator Substances 0.000 description 23
- 238000007726 management method Methods 0.000 description 19
- 238000010586 diagram Methods 0.000 description 15
- 230000004044 response Effects 0.000 description 12
- 230000006870 function Effects 0.000 description 9
- 230000005540 biological transmission Effects 0.000 description 8
- 230000000052 comparative effect Effects 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 230000002093 peripheral effect Effects 0.000 description 4
- 230000008859 change Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000009432 framing Methods 0.000 description 1
- 230000026676 system process Effects 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 238000004148 unit process Methods 0.000 description 1
Images
Landscapes
- Information Transfer Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、データ転送制御装置及び電子機器に関し、特に、バスに接続される複数のノード間でＩＥＥＥ１３９４などの規格に準じたデータ転送を行うためのデータ転送制御装置及び電子機器に関する。
【０００２】
【背景技術及び発明が解決しようとする課題】
近年、ＩＥＥＥ１３９４と呼ばれるインターフェース規格が脚光を浴びている。このＩＥＥＥ１３９４は、次世代のマルチメディアにも対応可能な高速シリアルバスインターフェースを規格化したものである。このＩＥＥＥ１３９４によれば、動画像などのリアルタイム性が要求されるデータも扱うことができる。また、ＩＥＥＥ１３９４のバスには、プリンタ、スキャナ、ＣＤ−ＲＷドライブ、ハードディスクドライブなどのコンピュータの周辺機器のみならず、ビデオカメラ、ＶＴＲ、ＴＶなどの家庭用電化製品も接続できる。このため、電子機器のデジタル化を飛躍的に促進できるものとして期待されている。
【０００３】
さて、ＩＥＥＥ１３９４の上位プロトコルとして規格化されているＳＢＰ−２（Ｓｅｒｉａｌ Ｂｕｓ Ｐｒｏｔｏｃｏｌ−２）では、エージェントリセット、ターゲットリセット、リセットスタートなどのリセットが定義されている。即ち、ターゲット（プリンタ、スキャナ、ＣＤ−ＲＷ等）に何らかのエラーが発生し、データ転送処理を継続できないと判断した場合に、イニシエータ（パーソナルコンピュータ等）は、上記のリセットを要求する。そして、このようなリセットが要求された場合、リセットにより不要になる受信パケットについては破棄する必要がある。
【０００４】
また、ＩＥＥＥ１３９４においては、バスに電子機器が新たに接続されたり、バスから電子機器が取り外されたりして、バスに接続されるノードが増減すると、いわゆるバスリセットが発生する。そして、バスリセットが発生するとノードのトポロジ情報がクリアされ、未完了のトランザクションは全てキャンセルされるため、バスリセット発生前に受信したパケットは全て無効になる。
【０００５】
しかしながら、パケットを処理するファームウェアは、一般的に、処理速度の低いＣＰＵ上で動作している場合が多い。従って、受信パケットに対する処理は、そのパケットの受信後、所与の時間が経過してから行われるようになる。このため、多数の未処理のパケットが常にターゲットのデータバッファ上に存在することになる。従って、データバッファ上に存在する多数の受信パケットの中から、リセット（エージェントリセット、バスリセット等）により不要になる受信パケットを探し出す処理に多くの時間を要してしまう。このため、リセット処理に長時間を要してしまいシステム全体の処理がストールしてしまったり、ファームウェアの処理負担が過大になるなどの問題が生じる。
【０００６】
本発明は、以上のような技術的課題に鑑みてなされたものであり、その目的とするところは、リセット処理に要する時間の短縮化と処理負担の軽減化を図れるデータ転送制御装置及び電子機器を提供することにある。
【０００７】
【課題を解決するための手段】
上記課題を解決するために本発明は、バスに接続される複数のノード間でのデータ転送のためのデータ転送制御装置であって、自ノードのデータバッファに書き込まれた受信パケットを解析し、解析した受信パケットをキューに格納し、データバッファ上の受信パケットが無くなるまで受信パケットの解析及びキューへの格納を繰り返すパケット解析手段と、データバッファ上の受信パケットが無くなったところで、キューに格納された受信パケットを処理するパケット処理手段と、処理した受信パケットがリセットを指示するパケットであった場合には、キューに格納された受信パケットのうち前記リセットにより不要になる受信パケットを破棄するパケット破棄手段とを含むことを特徴とする。
【０００８】
本発明によれば、解析した受信パケットが直ぐには処理されずに、キューに格納される。そして、データバッファ上の受信パケットが無くなったところで、キューに格納された受信パケットの処理が開始される。そして、受信パケットがリセットを指示するパケットであった場合には、リセットにより不要になる受信パケットが破棄される。このようにすれば、リセットにより不要になる受信パケット（リセットの影響を受ける受信パケット）に対して、無駄なパケット処理が行われるのを防止でき、リセット処理に要する時間を大幅に短縮化できる。
【０００９】
なお、キューは複数設けることが望ましいが、１つでもよい。また、パケット処理手段が行う受信パケットの処理としては、例えば、後段の処理手段（要求実行手段等）に受信パケットを渡すなどの処理が考えられる。また、不要な受信パケットを破棄する処理としては、キューをクリアする処理等が考えられるが、受信パケットを個別的に破棄してもよい。
【００１０】
また本発明は、前記キューとして複数のキューが用意され、前記パケット解析手段が、解析した受信パケットを前記複数のキューの中のいずれかのキューに格納し、前記パケット破棄手段が、処理した受信パケットがリセットを指示するパケットであった場合には、リセットにより不要になる受信パケットが格納されているキューをクリアすることを特徴とする。
【００１１】
このようにすれば、リセットにより不要になる受信パケットをひとまとめに破棄できるため、受信パケットを破棄する処理を大幅に効率化できる。
【００１２】
なお、複数のキューとしては、その各々が、受信パケットを渡す後段の処理手段（要求実行手段等）に対応したキューを設けることが望ましい。
【００１３】
また本発明は、前記パケット処理手段から受信パケットを受け、他のノードからの要求を実行する第１の要求実行手段と、前記パケット処理手段から受信パケットを受け、他のノードからの要求を実行すると共に、前記第１の要求実行手段がリセットされると自身もリセットされる関係にある第２の要求実行手段とを含み、前記パケット解析手段が、前記第１の要求実行手段に渡すべき受信パケットについては第１のキューに格納し、前記第２の要求実行手段に渡すべき受信パケットについては第２のキューに格納し、前記パケット処理手段が、前記第１のキューに格納されている受信パケットを、前記第２のキューに格納されている受信パケットよりも優先して処理することを特徴とする。
【００１４】
このようにすれば、第１の要求実行手段に渡すべき受信パケットが優先的に処理されるようになる。従って、第１の要求実行手段がリセットされるとリセットされる関係にある第２の要求実行手段の受信パケットが、無駄に処理されてしまう事態を防止でき、リセット処理に要する時間を短縮化できる。
【００１５】
なお、第１、第２の要求実行手段としては例えばＳＢＰ−２におけるマネージメントエージェントやフェッチエージェントが考えられるが、本発明は、これに限定されない。
【００１６】
また本発明は、前記パケット破棄手段が、処理した受信パケットが前記第１の要求実行手段のリセットを指示するパケットであった場合には、前記第１、第２のキューの両方をクリアすることを特徴とする。
【００１７】
このようにすれば、処理が不要な第２の要求実行手段の受信パケットが、ひとまとめに破棄されるようになるため、処理の効率化を図れる。
【００１８】
また本発明は、前記第２の要求実行手段が、上層のデバイスのコマンド制御要求を実行する第３の要求実行手段と、データ転送要求を実行する第４の要求実行手段とを含み、前記パケット解析手段が、前記第３の要求実行手段に渡すべき受信パケットについては第３のキューに格納し、前記第４の要求実行手段に渡すべき受信パケットについては第４のキューに格納し、前記パケット処理手段が、前記第３のキューに格納されている受信パケットを、前記第４のキューに格納されている受信パケットよりも優先して処理することを特徴とする。
【００１９】
このようにすれば、第３の要求実行手段に渡すべき受信パケットを優先的に処理できるようになり、データ転送処理中に、デバイスのコマンド制御要求を割り込ませることが可能になる。
【００２０】
また本発明は、バスに接続される複数のノード間でのデータ転送のためのデータ転送制御装置であって、自ノードのデータバッファに書き込まれた受信パケットを解析し、解析した受信パケットをキューに格納し、データバッファ上の受信パケットが無くなるまで受信パケットの解析及びキューへの格納を繰り返すパケット解析手段と、データバッファ上の受信パケットが無くなったところでキューに格納された受信パケットを処理するパケット処理手段と、ノードのトポロジ情報をクリアするリセットが発生した場合には、前記リセットの発生前の受信パケットを破棄するパケット破棄手段とを含むことを特徴とする。
【００２１】
本発明によれば、解析した受信パケットが直ぐには処理されずに、キューに格納される。そして、データバッファ上の受信パケットが無くなったところで、キューに格納された受信パケットの処理が開始される。そして、ノードのトポロジ情報をクリアするリセットが発生すると、リセットの発生前の受信パケットが破棄される。従って、リセット発生前に受信したパケットに対して、無駄なパケット処理が行われるのを防止でき、リセット処理に要する時間を大幅に短縮化できる。
【００２２】
また本発明は、前記パケット破棄手段が、ノードのトポロジ情報をクリアするリセットが発生した場合には、受信パケットが格納されているキューをクリアすることを特徴とする。
【００２３】
このようにすれば、リセット発生前の受信パケットをひとまとめに破棄できるため、処理の効率化を図れる。
【００２４】
なお、キューをクリアするか否かの判断は、キューに受信パケットを格納する毎に行ってもよいし、全ての受信パケットがキューに格納された後に行ってもよい。
【００２５】
なお、ノードのトポロジ情報をクリアする前記リセットは、ＩＥＥＥ１３９４の規格において定義されるバスリセットであることが望ましい。
【００２６】
また本発明では、ＩＥＥＥ１３９４の規格に準拠したデータ転送を行うことが望ましい。
【００２７】
また本発明に係る電子機器は、上記のいずれかのデータ転送制御装置と、前記データ転送制御装置及びバスを介して相手ノードから受信したデータに所与の処理を施す装置と、処理が施されたデータを出力又は記憶するための装置とを含むことを特徴とする。また本発明に係る電子機器は、上記のいずれかのデータ転送制御装置と、前記データ転送制御装置及びバスを介して相手ノードに送信するデータに所与の処理を施す装置と、処理が施されるデータを取り込むための装置とを含むことを特徴とする。
【００２８】
本発明によれば、データ転送を制御するファームウェア等の処理負担を軽減できるため、電子機器の低コスト化、処理の高速化などを図ることができる。また、リセットの発生によりシステム全体の処理がストールしてしまうなどの事態を防止できるため、電子機器の信頼性を高めることができる。
【００２９】
【発明の実施の形態】
以下、本発明の好適な実施形態について図面を用いて詳細に説明する。
【００３０】
１．ＩＥＥＥ１３９４
まず、ＩＥＥＥ１３９４について簡単に説明する。
【００３１】
１．１ 概要
ＩＥＥＥ１３９４（ＩＥＥＥ１３９４−１９９５、Ｐ１３９４．ａ）では１００〜４００Ｍｂｐｓの高速なデータ転送が可能となっている（Ｐ１３９４．ｂでは８００〜３２００Ｍｂｐｓ）。また、転送速度が異なるノードをバスに接続することも許される。
【００３２】
各ノードはツリー状に接続されており、１つのバスに最大で６３個のノードが接続可能になっている。なお、バスブリッジを利用すれば約６４０００個のノードを接続することも可能である。
【００３３】
ＩＥＥＥ１３９４では、パケットの転送方式として非同期転送とアイソクロナス転送が用意されている。ここで非同期転送は、信頼性が要求されるデータの転送に好適な転送方式であり、アイソクロナス転送は、リアルタイム性が要求される動画像や音声などのデータの転送に好適な転送方式である。
【００３４】
１．２ 層構造
ＩＥＥＥ１３９４の層構造（プロトコル構成）を図１に示す。
【００３５】
ＩＥＥＥ１３９４のプロトコルは、トランザクション層、リンク層、物理層により構成される。また、シリアルバスマネージメントは、トランザクション層、リンク層、物理層をモニターしたり制御したりするものであり、ノードの制御やバスのリソース管理のための種々の機能を提供する。
【００３６】
トランザクション層は、上位層にトランザクション単位のインターフェース（サービス）を提供し、下層のリンク層が提供するインターフェースを通して、リードトランザクション、ライトトランザクション、ロックトランザクション等のトランザクションを実施する。
【００３７】
ここで、リードトランザクションでは、応答ノードから要求ノードにデータが転送される。一方、ライトトランザクションでは、要求ノードから応答ノードにデータが転送される。またロックトランザクションでは、要求ノードから応答ノードにデータが転送され、応答ノードがそのデータに処理を施して要求ノードに返信する。
【００３８】
リンク層は、アドレッシング、データチェック、パケット送受信のためのデータフレーミング、アイソクロナス転送のためのサイクル制御などを提供する。
【００３９】
物理層は、リンク層により使用されるロジカルシンボルの電気信号への変換や、バスの調停や、バスの物理的インターフェースを提供する。
【００４０】
１．３ ＳＢＰ−２
さて、図２に示すように、ＩＥＥＥ１３９４のトランザクション層の一部の機能を含む上位のプロトコルとして、ＳＢＰ−２（Ｓｅｒｉａｌ Ｂｕｓ Ｐｒｏｔｏｃｏｌ−２）と呼ばれるプロトコルが提案されている。
【００４１】
ここでＳＢＰ−２は、ＳＣＳＩのコマンドセットをＩＥＥＥ１３９４のプロトコル上で利用可能にするために提案されたものである。このＳＢＰ−２を用いれば、既存のＳＣＳＩ規格の電子機器で使用されていたＳＣＳＩのコマンドセットに最小限の変更を加えて、ＩＥＥＥ１３９４規格の電子機器に使用できるようになる。従って、電子機器の設計や開発を容易化できる。また、ＳＣＳＩのコマンドだけではなく、デバイス固有のコマンドもカプセル化して利用できるため、非常に汎用性が高い。
【００４２】
図３に示すようにＳＢＰ−２では、まず、イニシエータ（例えばパーソナルコンピュータ）により作成されたログインＯＲＢ（Ｏｐｅｒａｔｉｏｎ Ｒｅｑｕｅｓｔ Ｂｌｏｃｋ）を用いてログイン処理が行われる（ステップＴ１）。次に、ダミーＯＲＢを用いてフェッチエージェントの初期化が行われる（ステップＴ２）。そして、コマンドブロックＯＲＢ（ノーマルコマンドＯＲＢ）を用いてコマンド処理が行われ（ステップＴ３）、最後に、ログアウトＯＲＢを用いてログアウト処理が行われる（ステップＴ４）。
【００４３】
ここで、ステップＴ３のコマンド処理においては、図４のＡ１に示すように、イニシエータがライト要求パケットを転送して（ライト要求トランザクションを発行して）、ターゲットのドアベルレジスタをリングする。すると、Ａ２に示すように、ターゲットがリード要求パケットを転送し、イニシエータが対応するリード応答パケットを返す。これにより、イニシエータが作成したＯＲＢ（コマンドブロックＯＲＢ）が、ターゲットのデータバッファにフェッチされる。そして、ターゲットは、フェッチされたＯＲＢに含まれるコマンドを解析する。
【００４４】
そして、ＯＲＢに含まれるコマンドがＳＣＳＩのライトコマンドであった場合には、Ａ３に示すように、ターゲットがリード要求パケットをイニシエータに転送し、イニシエータが対応するリード応答パケットを返す。これにより、イニシエータのデータバッファに格納されているデータがターゲットに転送される。そして、例えばターゲットがプリンタであった場合には、転送されたデータがプリンタエンジンにより印刷される。
【００４５】
一方、ＯＲＢに含まれるコマンドがＳＣＳＩのリードコマンドであった場合には、図５のＢ１に示すように、ターゲットは、一連のライト要求パケットをイニシエータに転送する。これにより、例えばターゲットがスキャナであった場合には、スキャナエンジンにより取得されたスキャンデータが、イニシエータのデータバッファに転送されることになる。
【００４６】
このＳＢＰ−２によれば、ターゲットは、自身が都合の良いときに要求パケットを転送して（トランザクションを発行して）、データを送受信できる。従って、イニシエータとターゲットが同期して動く必要がなくなるため、データ転送効率を高めることができる。
【００４７】
なお、ＩＥＥＥ１３９４の上位プロトコルとしては、ＳＢＰ−２以外にも、ＦＣＰ（Ｆｕｎｃｔｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）と呼ばれるプロトコルなども提案されている。
【００４８】
１．４ バスリセット
ＩＥＥＥ１３９４では、電源が投入されたり、途中でデバイスの抜き差しが発生すると、バスリセットが発生する。即ち、各ノードは、ポートの電圧変化を監視している。そして、バスに新たなノードが接続されるなどしてポートの電圧に変化が生じると、この変化を検知したノードは、バス上の他のノードに対して、バスリセットが発生したことを知らせる。また、各ノードの物理層は、バスリセットが発生したことをリンク層に伝える。
【００４９】
そして、このようにバスリセットが発生すると、ノードＩＤなどのトポロジ情報がクリアされる。そして、その後、トポロジ情報が自動的に再設定される。即ち、バスリセット後、ツリー識別、自己識別が行われる。その後、アイソクロナスリソースマネージャ、サイクルマスタ、バスマネージャ等の管理ノードが決定される。そして、通常のパケット転送が再開される。
【００５０】
このようにＩＥＥＥ１３９４では、バスリセット後にトポロジ情報が自動的に再設定されるため、電子機器のケーブルを自由に抜き差しできるようになり、いわゆるホットプラグを実現できる。
【００５１】
なお、トランザクションの途中でバスリセットが発生した場合には、そのトランザクションはキャンセルされる。そして、キャンセルされたトランザクションを発行した要求ノードは、トポロジ情報が再設定された後に、要求パケットを再度転送する。また、応答ノードは、バスリセットによりキャンセルされたトランザクションの応答パケットを要求ノードに返送してはならない。
【００５２】
２．全体構成
次に、本実施形態のデータ転送制御装置の全体構成例について図６を用いて説明する。なお、以下では、イニシエータ（相手ノード）との間でデータ転送を行うターゲット（自ノード）がプリンタである場合について例にとり説明するが、本発明はこれに限定されない。
【００５３】
本実施形態のデータ転送制御装置１０は、ＰＨＹデバイス１２（物理層のデバイス）、リンクデバイス１４（リンク層のデバイス）、ＣＰＵ１６（プロセッサ）、データバッファ１８（記憶手段）、ファームウェア２０（処理手段）を含む。なお、ＰＨＹデバイス１２、リンクデバイス１４、ＣＰＵ１６、データバッファ１８は、任意の構成要素であり、本実施形態のデータ転送制御装置１０は、これらの構成要素を全て含む必要はない。
【００５４】
ＰＨＹデバイス１２は、図１の物理層のプロトコルをハードウェアにより実現するための回路であり、リンクデバイス１４により使用されるロジカルシンボルを電気信号に変換する機能を有する。
【００５５】
リンクデバイス１４は、図１のリンク層のプロトコルやトランザクション層のプロトコルの一部をハードウェアにより実現するための回路であり、ノード間でのパケット転送のための各種サービスを提供する。
【００５６】
ＣＰＵ１６は、装置全体の制御やデータ転送の制御を行うものである。
【００５７】
データバッファ１８は、転送データ（パケット）を一時的に格納するバッファであり、ＳＲＡＭ、ＳＤＲＡＭ、或いはＤＲＡＭなどのハードウェアにより構成される。なお、本実施形態では、データバッファ１８は、特には限定されないがランダムアクセス可能なパケット記憶手段として機能する。
【００５８】
ファームウェア２０は、ＣＰＵ１６上で動作する種々の処理ルーチン（処理モジュール）を含むプログラムであり、トランザクション層のプロトコルは、このファームウェア２０と、ハードウェアであるＣＰＵ１６等により実現される。
【００５９】
なお、イニシエータであるパーソナルコンピュータ１００が含むデバイスドライバ１０２は、周辺機器を管理制御するための種々の処理ルーチンを含むプログラムである。このプログラムは、情報記憶媒体１１０（ＦＤ、ＣＤ−ＲＯＭ、ＤＶＤ、ＲＯＭ）を利用してパーソナルコンピュータ１００にインストールされる。
【００６０】
ここで、デバイスドライバ１０２のプログラムは、ホストシステムが有する情報記憶媒体（ハードディスク、磁気テープ等）からインターネットなどのネットワークを介してダウンロードし、パーソナルコンピュータ１００にインストールするようにしてもよい。
【００６１】
ファームウェア２０（Ｆ／Ｗ）は、コミュニケーション部３０（ＣＯＭ）、マネージメントエージェント４０（ＭＮＧ）、フェッチエージェント５０（ＦＣＨ１）、フェッチエージェント６０（ＦＣＨ２）、プリントタスク部７０（ＰＲＴ）を含む。
【００６２】
ここで、コミュニケーション部３０は、リンクデバイス１４などのハードウェアとの間のインターフェースとして機能する処理モジュールである。
【００６３】
マネージメントエージェント４０（第１の要求実行手段）は、ログイン、リコネクト、ログアウト、リセット等の管理を行う処理モジュールである。例えばイニシエータがターゲットにログインを要求した場合には、まず、このマネージメントエージェント４０が、このログイン要求を受け付けることになる。
【００６４】
フェッチエージェント５０、６０（コマンドブロックエージェント。第２の要求実行手段）は、イニシエータからの要求を実行するための処理モジュールであり、より具体的には、コマンドブロックＯＲＢが含むコマンドを実行する。フェッチエージェント５０、６０は、単一の要求しか扱うことができないマネージメントエージェント４０と異なり、イニシエータからの要求により自身がフェッチしたＯＲＢのリンクリストも扱うことができる。
【００６５】
プリンタスク部７０は、プリンタエンジンやスキャナエンジン（上層のデバイス）との間でＤＭＡ転送を行うための処理モジュールである。
【００６６】
なお、フェッチエージェント５０（第３（第２）の要求実行手段）は、後段のプリンタエンジンやスキャナエンジン（上層のデバイス）のコマンド制御のための処理モジュールであり、フェッチエージェント６０（第４（第２）の要求実行手段）は、後段のプリンタエンジンやスキャナエンジンとの間のデータ転送のための処理モジュールである。
【００６７】
例えばプリンタエンジンとのデータ転送中にインク残量を調べたい場合に、フェッチエージェントが１つしかないと、ＯＲＢのリンクリストによるデータ転送が全て完了するまで、インク残量をチェックできない。
【００６８】
本実施形態では、互いに独立なフェッチエージェントを２つ設けている（３つ以上でもよい）。そして、コマンド制御用のフェッチエージェント５０の処理の優先度を、データ転送用のフェッチエージェント６０の処理の優先度よりも高くしている。より具体的には、後述するように、コマンド制御用のフェッチエージェント５０に渡す受信パケットを、データ転送用のフェッチエージェント６０に渡す受信パケットよりも優先して処理するようにしている。
【００６９】
このようにすることで、ＯＲＢのリンクリストによるデータ転送処理の間に、インク残量チェックなどのプリンタのコマンド制御処理を割り込ませることできる。従って、データ転送処理が終わるのを長時間待つことなく、インク残量をチェックできるようになり、データ転送に影響を与えることなく、デバイスのコマンド制御ができるようになる。
【００７０】
さて、コミュニケーション部３０は、パケット解析部３２、パケット処理部３４、パケット破棄部３６を含む。
【００７１】
ここで、パケット解析部３２は、パーソナルコンピュータ１００からＩＥＥＥ１３９４バス、ＰＨＹデバイス１２、リンクデバイス１４を介してデータバッファ１８に書き込まれた受信パケットを解析する。そして、解析した受信パケットをキューに格納する。
【００７２】
なお、このキューは、例えばＣＰＵ１６のローカルメモリ上に確保することができる。また、後述するように複数のキューがある場合には、パケット解析部３２は、解析結果に応じたキューに受信パケットを格納する。
【００７３】
そして、パケット解析部３２は、受信パケットをキューに格納すると、次の受信パケットを解析する。そして、データバッファ１８上の受信パケットが無くなるまで、受信パケットの解析及びキューへの格納を繰り返す。
【００７４】
パケット処理部３４は、データバッファ１８上の受信パケットが無くなったところで、キューに格納された受信パケットを処理する。より具体的には、キューに格納された受信パケットをマネージメントエージェント４０（ＭＮＧ）、フェッチエージェント５０（ＦＣＨ１）、或いはフェッチエージェント６０（ＦＣＨ２）に渡す。例えば、ＭＮＧ用のキュー、ＦＣＨ１用のキュー、ＦＣＨ２用のキューというように複数のキューがある場合には、ＭＮＧ用のキューに格納される受信パケットについてはマネージメントエージェント４０に渡す。また、ＦＣＨ１用、ＦＣＨ２用のキューに格納される受信パケットについては、各々、フェッチエージェント５０、６０に渡す。
【００７５】
パケット破棄部３６は、パケット処理部３４により処理された受信パケットが、エージェントリセット、ターゲットリセット、リセットスタートなどのリセットを指示するパケットであった場合には、キューに格納された受信パケットのうちリセットにより不要になる受信パケット（リセットの影響を受ける受信パケット）を破棄する処理を行う。そして、例えばキューが複数ある場合には、リセットされるエージェントのキューをクリアすることで、受信パケットをひとまとめに破棄する。
【００７６】
また、パケット破棄部３６は、バスリセット（広義にはノードのトポロジ情報をクリアするリセット）が発生した場合には、バスリセット発生前に受信したパケットを破棄する処理を行う。
【００７７】
３．本実施形態の特徴
３．１ リセット時の不要パケットの破棄
さて、ＳＢＰ−２においては、ターゲットにエラーが発生した場合に、イニシエータはターゲットに対してリセットを指示するパケット（以下、リセットパケットと呼ぶ）を転送できる。そして、この場合に、ＳＢＰ−２ではレベルの異なる種々のリセットが用意されている。例えば、リセットスタートは最も強いレベルのリセットであり、ノード状態が全てリセットされる。また、アボートタスクやアボートタスクセットでは、タスクやタスクのセットがリセットされ、ターゲットリセットではターゲットがリセットされる。また、エージェントリセットでは、フェッチエージェントのみがリセットされる。
【００７８】
なお、リセットスタート、エージェントリセットは、イニシエータが所定のレジスタに所定の情報をライトすることによりターゲットに伝えられ、アボートタスク、アボートタスクセット、ターゲットリセットは、イニシエータから転送されるマネージメントＯＲＢを用いてターゲットに伝えられる。
【００７９】
このように、イニシエータからリセットパケットが転送されてくると、リセットにより不要になるパケットについては破棄する必要がある。そして、この場合に、図７の比較例では、受信パケットを解析した後に直ぐにパケット処理（エージェントに受信パケットを渡す処理等）を行う（ステップＴ１、Ｔ２）。次に、受信パケットがリセットパケットか否かを判断し、リセットパケットであれば受信パケットを破棄する処理を行う（ステップＴ３、Ｔ４）。そして、以上の処理を、受信パケットが無くなるまで繰り返す（ステップＴ５）。
【００８０】
しかしながら、この比較例では、リセットにより破棄される運命にある受信パケットに対しても、パケット処理が行われてしまう。従って、リセット処理が非常に非効率になる。
【００８１】
特に、プリンタやスキャナやＣＤ−ＲＷなどの周辺機器に本実施形態のデータ転送制御装置を組み込んだ場合、製品コストの制約から、安価で処理能力が低いＣＰＵが使用される場合が多い、従って、そのＣＰＵ上で動作するファームウェアもその制約の影響を受けて、処理速度が遅くなってしまう。このため、受信パケットの処理が間に合わなくなり、多数の未処理の受信パケットが自ノード（ターゲット）のデータバッファ上に存在するようになる。従って、リセット処理時間の増加の問題は更に深刻なものになる。
【００８２】
そこで本実施形態では図８のＣ１、Ｃ２に示すように、ターゲットのデータバッファに書き込まれた受信パケットを解析した後、解析した受信パケットを直ぐには処理せずにキューに格納する。そして、Ｃ３に示すように、データバッファ上の受信パケットが無くなったところで、キューに格納された受信パケットを処理する。そして、Ｃ４に示すように、処理した受信パケットがエージェントリセット等のリセットパケットであった場合には、リセットにより不要になる受信パケット（リセットの影響を受ける受信パケット）を破棄する。
【００８３】
このようにすれば、リセットにより、パケット処理を行うまでもなく不要になる受信パケットについては、パケット処理を行わないで済むようになる。従って、全ての受信パケットに対してパケット処理が行われる図７の比較例に比べて、リセット処理に要する時間を大幅に短縮化できる。この結果、システム全体の処理がリセット処理によりストールしてしまう事態を防止できると共に、ファームウェアの処理負担も軽減化できる。
【００８４】
更に、本実施形態では、受信パケットを格納するキューを複数用意し、解析した受信パケットを、複数のキューの中のいずれかに仕分けして格納する。そしてリセットが発生した場合には、リセットにより不要になる受信パケットが格納されているキューをクリアする。
【００８５】
より具体的には、図９（Ａ）に示すように、マネージメントエージェントに渡す受信パケットを格納するためのＭＮＧキューと、フェッチエージェントに渡す受信パケットを格納するためのＦＣＨキューを用意する。そして、図９（Ａ）、（Ｂ）に示すように、受信パケットの解析結果に応じたキューに受信パケットを格納する。即ち、マネージメントエージェントに渡すパケットについてはＭＮＧキューに格納し、フェッチエージェントに渡すパケットについてはＦＣＨキューに格納する。
【００８６】
そして、図９（Ｃ）に示すように、例えば受信パケットがエージェントリセットであると判明した場合（エージェントリセットレジスタへのライトパケットであると判明した場合）には、ＦＣＨキューをクリアする。即ち、ＦＣＨキューに格納されている受信パケットは、フェッチエージェントに渡すパケットであり、エージェントリセットにより不要になるパケットである。従って、エージェントキュー自体をクリアすることで、これらの不要パケットをひとまとめにして破棄できる。
【００８７】
このように、キューのクリアにより受信パケットを破棄するようにすれば、不要な受信パケットをひとまとめに破棄できるようになり、受信パケットを破棄する処理を大幅に効率化できる。これにより、リセット処理を更に高速化できるようになる。
【００８８】
また、本実施形態では、第１のエージェントがリセットされると第２のエージェントがリセットされるという関係がある場合に、第１のエージェント用のキューに格納されている受信パケットを、第２のエージェント用のキューに格納されている受信パケットよりも優先して処理するようにしている。
【００８９】
より具体的には、図１０（Ａ）に示すように、マネージメントエージェント（第１の要求実行手段）用のＭＮＧキューと、フェッチエージェント（第２の要求実行手段）用のＦＣＨキューがある場合には、ＭＮＧキューに格納される受信パケットを優先的に処理する（フェッチエージェントは、マネージメントエージェントがリセットされると自身もリセットされる関係にある）。即ち、ＭＮＧキューに格納されている全ての受信パケットについてのパケット処理（マネージメントエージェントにパケットを渡す等の処理）が完了した後に、図１０（Ｂ）に示すように、ＦＣＨキューに格納されている受信パケットのパケット処理を開始する。
【００９０】
このようにすれば、図１０（Ｃ）に示すように、例えばＭＮＧキューに格納される受信パケットの中にリセットスタートを指示するパケットがあった場合に、ＭＮＧキューとＦＣＨキューの両方をクリアできる。これにより、ＦＣＨキューに格納される受信パケットは破棄され、これらの受信パケットに対して無駄なパケット処理を行わなくて済むようになる。この結果、リセット処理の更なる効率化を図れ、リセット処理を高速に完了できるようになる。
【００９１】
なお、本実施形態では図１１（Ａ）に示すように、フェッチエージェント（第２の要求実行手段）として、コマンド制御用のフェッチエージェントＦＣＨ１（第３の要求実行手段）とデータ転送用のフェッチエージェントＦＣＨ２（第４の要求実行手段）を用意している。そして、コマンド制御用のフェッチエージェントＦＣＨ１に渡すべき受信パケットについてはＦＨＣ１キューに格納し、データ転送用のフェッチエージェントＦＣＨ２に渡すべき受信パケットについてはＦＨＣ２キューに格納する。そして、図１１（Ａ）に示すように、ＦＣＨ１キューに格納されているコマンド制御用の受信パケットを優先して処理し、ＦＣＨ１キューの全ての受信パケットについてのパケット処理が完了した後に、図１１（Ｂ）に示すように、ＦＣＨ２キューに格納されている受信パケットのパケット処理を開始する。
【００９２】
このようにすれば、フェッチエージェントＦＣＨ１による処理が優先されるようになり、フェッチエージェントＦＣＨ２によるデータ転送処理の間に、フェッチエージェントＦＣＨ１によるコマンド制御処理を容易に割り込ませることができる。従って、印刷が完了するのを待つことなく、インク残量を調べることなどが可能になる。
【００９３】
３．２ バスリセット時の不要パケットの処理
ＩＥＥＥ１３９４においては、バスに電子機器が新たに接続されたり、バスから電子機器が取り外されたりすると、バスリセットが発生する。そして、バスリセットが発生すると、ノードのトポロジ情報がクリアされ、バスリセット発生時点で未完了であったトランザクションは全てキャンセルされる。このため、バスリセット発生前に受信したパケットは全て無効になる。
【００９４】
ところが、前述のように、データ転送制御装置が組み込まれる周辺機器で動作するＣＰＵは処理能力が低い。このため、このＣＰＵ上で動作するファームウェアも高速に受信パケットを処理できず、多数の未処理の受信パケットがデータバッファ上に存在するようになる。従って、バスリセットが発生した場合には、これらの多数の未処理の受信パケットの中から、バスリセット発生前のパケットを区別して破棄する処理が必要になる。従って、ファームウェアの処理負荷も過大になる。
【００９５】
そこで本実施形態では、図１２（Ａ）に示すように、ターゲットのデータバッファに書き込まれた受信パケットを解析した後、解析した受信パケットを直ぐには処理せずにキューに格納する。そして、データバッファ上の受信パケットが無くなったところでキューに格納された受信パケットを処理する。そして、バスリセットが発生した場合には、バスリセット発生前に受信したパケットを破棄するようにする。
【００９６】
より具体的には、図１２（Ｂ）に示すように、受信パケットのキューへの格納中にＩＥＥＥ１３９４のバス上でバスリセットが発生した場合には、受信パケットのキューをクリアして、バスリセット発生前の受信パケットを破棄する（この場合には、データバッファ上の受信パケットも破棄することが望ましい）。また、図１２（Ｃ）に示すように、全ての受信パケットをキューに格納した後、受信パケットの処理中に、バスリセットが発生した場合にも、受信パケットのキューをクリアして、受信パケットを破棄する。
【００９７】
以上のようにすれば、バスリセットにより、パケット処理を行うまでもなく不要になる受信パケットについては、パケット処理を行わないで済むようになる。従って、全ての受信パケットに対してパケット処理が行われる図７の比較例に比べて、バスリセット処理に要する時間を大幅に短縮化できる。この結果、システム全体の処理がバスリセット処理によりストールしてしまう事態を防止できると共に、ファームウェアの処理負担も軽減化できる。
【００９８】
また、キューのクリアにより受信パケットを破棄すれば、バスリセット発生前の多数の受信パケットをひとまとめに破棄できるため、受信パケットを破棄する処理を更に効率化できる。特に、ＣＰＵの処理能力の低さに起因して多数の未処理の受信パケットがデータバッファ上に存在するような場合には、キューのクリアにより受信パケットを破棄する本実施形態の手法は、処理の効率化に非常に効果的なものとなる。
【００９９】
４．本実施形態の処理
次に、本実施形態の詳細な処理例について図１３、図１４のフロチャートを用いて説明する。
【０１００】
ＣＰＵ（或いはリンクデバイス）からの割り込みが発生すると、その割り込み要因を解析し、解析が済んだ割り込み要因をクリアする（ステップＳ１）。ここで割り込み要因としては、パケット受信の割り込み、バスリセット発生の割り込み、プリンタへのＤＭＡ転送終了の割り込み、ＣＰＵのタイマ割り込みなどがある。
【０１０１】
次に、解析した割り込み要因が、パケット受信の割り込みか否かを判断し（ステップＳ２）、パケット受信の割り込みではなかった場合には、バスリセット発生の割り込みか否かを判断する（ステップＳ３）。そして、バスリセット発生の割り込みであった場合には、エージェントキューの全てと送信キューをクリアし（ステップＳ４。図１２（Ｂ）、（Ｃ）参照）、バスリセット発生前の受信パケットを破棄する。
【０１０２】
次に、ＣＰＵからの割り込み要因が存在するか否かを判断し（ステップＳ５）、存在する場合には、その割り込み要因を解析し、解析が済んだ割り込み要因をクリアする（ステップＳ６）。次に、解析が済んでいない未処理の割り込み要因が、まだ存在するか否かを判断し（ステップＳ７）、存在する場合にはステップＳ２に戻り、存在しない場合には割り込み処理を終了する。
【０１０３】
ステップＳ２でパケット受信の割り込みが発生したと判断した場合には、受信パケットが、自身が転送した要求パケットに対するイニシエータの応答パケットか否かを判断する（図１４のステップＳ８）。そして、応答パケットであった場合には、応答パケットに関する処理（データバッファにおける応答パケットの格納場所のポインタ制御等）を行う（ステップＳ９）。
【０１０４】
次に、パケットの解析結果に基づいて、受信パケットがエージェントに渡すパケットか否かを判断する（ステップＳ１０）。そして、エージェントに渡すパケットであった場合には、図９（Ａ）、（Ｂ）で説明したように、受信パケットを、対応するエージェントのキューに格納する（ステップＳ１１）。例えば、マネージメントエージェントに渡す受信パケットはＭＮＧキューに格納し、フェッチエージェントに渡す受信パケットはＦＣＨキューに格納する。
【０１０５】
次に、バスリセットが発生しているか否かを判断する（ステップＳ１２）。そして、バスリセットが発生している場合には、図１２（Ｂ）で説明したように、エージェントキューの全てと送信キューをクリアする（ステップＳ２２）。一方、発生していない場合には、キューに格納すべき受信パケットがデータバッファ上にまだ存在しているか否かを判断し（ステップＳ１３）、存在している場合にはステップＳ１１に戻る。そして、データバッファ上の受信パケットが無くなるまで、ステップＳ１１、Ｓ１２、Ｓ１３の処理を繰り返す。
【０１０６】
次に、キューへの受信パケットの格納後、バスリセットが発生しているか否かを判断する（ステップＳ１４）。そして、発生している場合には、図１２（Ｃ）で説明したように、エージェントキューの全てと送信キューをクリアする（ステップＳ２２）。一方、発生してない場合には、図８のＣ３に示すように、キューに格納されている受信パケットに対する処理（エージェントに渡す処理等）があるか否かを判断する（ステップＳ１５）。そして、処理がある場合には、図１０（Ａ）で説明したように、優先順位の高いエージェントキュー（例えばＭＮＧキュー）から処理を行う（ステップＳ１６）。
【０１０７】
次に、受信パケットがリセットパケット（リセットを指示するパケット）か否かを判断する（ステップＳ１７）。例えば、ターゲットリセットの場合には、エージェントがＯＲＢの内容を解析することで、リセットパケットか否かを判断できる。また、エージェントリセットやリセットスタートの場合には、エージェントがパケットのライトアドレスを解析することで、リセットパケットか否かを判断できる。
【０１０８】
受信パケットがリセットパケットであった場合には、図９（Ｃ）や図１０（Ｃ）で説明したように、リセットにより影響を受けるエージェントキューをクリアする（ステップＳ１８）。例えば、マネージメントエージェントのリセットの場合には、ＭＮＧキューとＦＣＨキューの両方をクリアする。一方、フェッチエージェントのリセットの場合には、ＦＣＨキューのみをクリアする。
【０１０９】
次に、データバッファ上の送信バッファに空きがあり、且つ、送信要求が存在するか否かを判断し（ステップＳ１９）、存在する場合にはパケット送信を行う（ステップＳ２０）。次に、バスリセットが発生しているか否かを判断し（ステップＳ２１）、発生している場合には、エージェントキューの全てと送信キューをクリアする（ステップＳ２２）。一方、発生してない場合には、図１３のステップＳ３に戻る。
【０１１０】
そして、ステップＳ３〜Ｓ７、Ｓ２、Ｓ８〜Ｓ２１の処理を繰り返して、キューに格納されている受信パケットを１つずつ順次処理して行く。即ち、まず、優先順位が最も高いキュー（例えばＭＮＧキュー）に格納されている受信パケットを１つずつ順次処理して行き、全ての受信パケットに対する処理が完了した場合には、２番目に優先順位が高いキュー（例えばＦＣＨ１キュー）に格納されている受信パケットを処理する。そして、そのキューの全ての受信パケットの処理が完了すると、３番目に優先順位が高いキュー（例えばＦＣＨ２キュー）に格納されている受信パケットを処理する。以上のようにして、キューに格納されている全ての受信パケットに対して処理を行う。
【０１１１】
５．電子機器
次に、本実施形態のデータ転送制御装置を含む電子機器の例について説明する。
【０１１２】
例えば図１５（Ａ）に電子機器の１つであるプリンタの内部ブロック図を示し、図１６（Ａ）にその外観図を示す。ＣＰＵ（マイクロコンピュータ）５１０はシステム全体の制御などを行う。操作部５１１はプリンタをユーザが操作するためのものである。ＲＯＭ５１６には、制御プログラム、フォントなどが格納され、ＲＡＭ５１８はＣＰＵ５１０のワーク領域として機能する。表示パネル５１９はプリンタの動作状態をユーザに知らせるためのものである。
【０１１３】
ＰＨＹデバイス５０２、データ転送制御装置５００を介して、パーソナルコンピュータなどの相手ノードから送られてきた印字データは、バス５０４を介して印字処理部（プリンタエンジン）５１２に直接送られる。そして、印字データは、印字処理部５１２にて所与の処理が施され、プリントヘッダなどからなる印字部（データを出力するための装置）５１４により紙に印字されて出力される。
【０１１４】
図１５（Ｂ）に電子機器の１つであるスキャナの内部ブロック図を示し、図１６（Ｂ）にその外観図を示す。ＣＰＵ５２０はシステム全体の制御などを行う。操作部５２１はスキャナをユーザが操作するためのものである。ＲＯＭ５２６には制御プログラムなどが格納され、ＲＡＭ５２８はＣＰＵ５２０のワーク領域として機能する。
【０１１５】
光源、光電変換器などからなる画像読み取り部（データを取り込むための装置）５２２により原稿の画像が読み取られ、読み取られた画像のデータは画像処理部（スキャナエンジン）５２４により処理される。そして、処理後の画像データがバス５０５を介してデータ転送制御装置５００に直接送られる。データ転送制御装置５００は、この画像データにヘッダなどを付加することでパケットを生成し、ＰＨＹデバイス５０２を介してパーソナルコンピュータなどの相手ノードに送信する。
【０１１６】
図１５（Ｃ）に電子機器の１つであるＣＤ−ＲＷドライブの内部ブロック図を示し、図１６（Ｃ）にその外観図を示す。ＣＰＵ５３０はシステム全体の制御などを行う。操作部５３１はＣＤ−ＲＷをユーザが操作するためのものである。ＲＯＭ５３６には制御プログラムなどが格納され、ＲＡＭ５３８はＣＰＵ５３０のワーク領域として機能する。
【０１１７】
レーザ、モータ、光学系などからなる読み取り＆書き込み部（データを取り込むための装置又はデータを記憶するための装置）５３３によりＣＤ−ＲＷ５３２から読み取られたデータは、信号処理部５３４に入力され、エラー訂正処理などの所与の信号処理が施される。そして、信号処理が施されたデータが、バス５０６を介してデータ転送制御装置５００に直接送られる。データ転送制御装置５００は、このデータにヘッダなどを付加することでパケットを生成し、ＰＨＹデバイス５０２を介してパーソナルコンピュータなどの相手ノードに送信する。
【０１１８】
一方、ＰＨＹデバイス５０２、データ転送制御装置５００を介して、相手ノードから送られてきたデータは、バス５０６を介して信号処理部５３４に直接送られる。そして、信号処理部５３４によりこのデータに所与の信号処理が施され、読み取り＆書き込み部５３３によりＣＤ−ＲＷ５３２に記憶される。
【０１１９】
なお、図１５（Ａ）、（Ｂ）、（Ｃ）において、ＣＰＵ５１０、５２０、５３０の他に、データ転送制御装置５００でのデータ転送制御のためのＣＰＵを別に設けるようにしてもよい。
【０１２０】
また、図１５（Ａ）、（Ｂ）、（Ｃ）ではＲＡＭ５０１（データバッファに相当）がデータ転送制御装置５００の外部に設けられているが、ＲＡＭ５０１をデータ転送制御装置５００に内蔵させてもよい。
【０１２１】
本実施形態のデータ転送制御装置を電子機器に用いれば、データ転送制御装置や電子機器に何らかのエラーが発生して、データ転送制御装置がリセットされた場合にも、短時間で正常状態に復帰できるようになる。また、バスに新たな電子機器が接続されてバスリセットが発生した場合にも、短い時間でバスリセット状態から復帰でき、システム全体がストールしてしまう事態を防止できる。
【０１２２】
また本実施形態のデータ転送制御装置を電子機器に用いれば、高速なデータ転送が可能になる。従って、ユーザがパーソナルコンピュータなどによりプリントアウトの指示を行った場合に、少ないタイムラグで印字が完了するようになる。また、スキャナへの画像取り込みの指示の後に、少ないタイムラグで読み取り画像をユーザは見ることができるようになる。また、ＣＤ−ＲＷからのデータの読み取りや、ＣＤ−ＲＷへのデータの書き込みを高速に行うことができるようになる。
【０１２３】
また本実施形態のデータ転送制御装置を電子機器に用いることで、ＣＰＵ上で動作するファームウェアの処理負担が軽減され、安価なＣＰＵや低速のバスを用いることが可能になる。更に、データ転送制御装置の低コスト化、小規模化を図れるため、電子機器の低コスト化、小規模化も図れるようになる。
【０１２４】
なお本実施形態のデータ転送制御装置を適用できる電子機器としては、上記以外にも例えば、種々の光ディスクドライブ（ＣＤ−ＲＯＭ、ＤＶＤ）、光磁気ディスクドライブ（ＭＯ）、ハードディスクドライブ、ＴＶ、ＶＴＲ、ビデオカメラ、オーディオ機器、電話機、プロジェクタ、パーソナルコンピュータ、電子手帳、ワードプロセッサなど種々のものを考えることができる。
【０１２５】
なお、本発明は本実施形態に限定されず、本発明の要旨の範囲内で種々の変形実施が可能である。
【０１２６】
例えば、本発明のデータ転送制御装置の構成は、図６に示す構成が特に望ましいが、これに限定されるものではない。
【０１２７】
また、受信パケットを破棄する手法も、本実施形態で説明した手法が特に望ましいが、これに限定されるものではない。
【０１２８】
また、本実施形態では、２つ又は３つのキューを設ける場合について説明したが、４つ以上のキューを設けるようにしてもよい。
【０１２９】
また、本発明は、ＩＥＥＥ１３９４規格でのデータ転送に適用されることが特に望ましいが、これに限定されるものではない。例えばＩＥＥＥ１３９４と同様の思想に基づく規格やＩＥＥＥ１３９４を発展させた規格におけるデータ転送にも本発明は適用できる。
【図面の簡単な説明】
【図１】ＩＥＥＥ１３９４の層構造について示す図である。
【図２】ＳＢＰ−２について説明するための図である。
【図３】ＳＢＰ−２のデータ転送処理の概略について説明するための図である。
【図４】データをイニシエータからターゲットに転送する場合のコマンド処理について説明するための図である。
【図５】データをターゲットからイニシエータに転送する場合のコマンド処理について説明するための図である。
【図６】本実施形態のデータ転送制御装置の構成例を示す図である。
【図７】比較例の処理について説明するためのフローチャートである。
【図８】リセット時の本実施形態の手法について説明するための図である。
【図９】図９（Ａ）、（Ｂ）、（Ｃ）は、複数のキューを用意し、キューをクリアすることにより、不要なパケットを破棄する手法について説明するための図である。
【図１０】図１０（Ａ）、（Ｂ）、（Ｃ）は、優先順位の高いキューを優先的に処理する手法について説明するための図である。
【図１１】図１１（Ａ）、（Ｂ）は、コマンド制御用のフェッチエージェントのキューを優先的に処理する手法について説明するための図である。
【図１２】図１２（Ａ）、（Ｂ）、（Ｃ）は、バスリセット時の本実施形態の手法について説明するための図である。
【図１３】本実施形態の詳細な処理例を示すフローチャートである。
【図１４】本実施形態の詳細な処理例を示すフローチャートである。
【図１５】図１５（Ａ）、（Ｂ）、（Ｃ）は、種々の電子機器の内部ブロック図の例である。
【図１６】図１６（Ａ）、（Ｂ）、（Ｃ）は、種々の電子機器の外観図の例である。
【符号の説明】
１０ データ転送制御装置
１２ ＰＨＹデバイス
１４ リンクデバイス
１６ ＣＰＵ
１８ データバッファ
２０ ファームウェア（Ｆ／Ｗ）
３０ コミュニケーション部（ＣＯＭ）
３２ パケット解析部
３４ パケット処理部
３６ パケット破棄部
４０ マネージメントエージェント（ＭＮＧ。第１の要求実行手段）
５０ フェッチエージェント（ＦＣＨ１。第３（第２）の要求実行手段）
６０ フェッチエージェント（ＦＣＨ２。第４（第２）の要求実行手段）
７０ プリントタスク部（ＰＲＴ）
１００ パーソナルコンピュータ
１０２ デバイスドライバ
１０４ データバッファ
１１０ 情報記憶媒体
【発明の属する技術分野】
本発明は、データ転送制御装置及び電子機器に関し、特に、バスに接続される複数のノード間でＩＥＥＥ１３９４などの規格に準じたデータ転送を行うためのデータ転送制御装置及び電子機器に関する。
【０００２】
【背景技術及び発明が解決しようとする課題】
近年、ＩＥＥＥ１３９４と呼ばれるインターフェース規格が脚光を浴びている。このＩＥＥＥ１３９４は、次世代のマルチメディアにも対応可能な高速シリアルバスインターフェースを規格化したものである。このＩＥＥＥ１３９４によれば、動画像などのリアルタイム性が要求されるデータも扱うことができる。また、ＩＥＥＥ１３９４のバスには、プリンタ、スキャナ、ＣＤ−ＲＷドライブ、ハードディスクドライブなどのコンピュータの周辺機器のみならず、ビデオカメラ、ＶＴＲ、ＴＶなどの家庭用電化製品も接続できる。このため、電子機器のデジタル化を飛躍的に促進できるものとして期待されている。
【０００３】
さて、ＩＥＥＥ１３９４の上位プロトコルとして規格化されているＳＢＰ−２（Ｓｅｒｉａｌ Ｂｕｓ Ｐｒｏｔｏｃｏｌ−２）では、エージェントリセット、ターゲットリセット、リセットスタートなどのリセットが定義されている。即ち、ターゲット（プリンタ、スキャナ、ＣＤ−ＲＷ等）に何らかのエラーが発生し、データ転送処理を継続できないと判断した場合に、イニシエータ（パーソナルコンピュータ等）は、上記のリセットを要求する。そして、このようなリセットが要求された場合、リセットにより不要になる受信パケットについては破棄する必要がある。
【０００４】
また、ＩＥＥＥ１３９４においては、バスに電子機器が新たに接続されたり、バスから電子機器が取り外されたりして、バスに接続されるノードが増減すると、いわゆるバスリセットが発生する。そして、バスリセットが発生するとノードのトポロジ情報がクリアされ、未完了のトランザクションは全てキャンセルされるため、バスリセット発生前に受信したパケットは全て無効になる。
【０００５】
しかしながら、パケットを処理するファームウェアは、一般的に、処理速度の低いＣＰＵ上で動作している場合が多い。従って、受信パケットに対する処理は、そのパケットの受信後、所与の時間が経過してから行われるようになる。このため、多数の未処理のパケットが常にターゲットのデータバッファ上に存在することになる。従って、データバッファ上に存在する多数の受信パケットの中から、リセット（エージェントリセット、バスリセット等）により不要になる受信パケットを探し出す処理に多くの時間を要してしまう。このため、リセット処理に長時間を要してしまいシステム全体の処理がストールしてしまったり、ファームウェアの処理負担が過大になるなどの問題が生じる。
【０００６】
本発明は、以上のような技術的課題に鑑みてなされたものであり、その目的とするところは、リセット処理に要する時間の短縮化と処理負担の軽減化を図れるデータ転送制御装置及び電子機器を提供することにある。
【０００７】
【課題を解決するための手段】
上記課題を解決するために本発明は、バスに接続される複数のノード間でのデータ転送のためのデータ転送制御装置であって、自ノードのデータバッファに書き込まれた受信パケットを解析し、解析した受信パケットをキューに格納し、データバッファ上の受信パケットが無くなるまで受信パケットの解析及びキューへの格納を繰り返すパケット解析手段と、データバッファ上の受信パケットが無くなったところで、キューに格納された受信パケットを処理するパケット処理手段と、処理した受信パケットがリセットを指示するパケットであった場合には、キューに格納された受信パケットのうち前記リセットにより不要になる受信パケットを破棄するパケット破棄手段とを含むことを特徴とする。
【０００８】
本発明によれば、解析した受信パケットが直ぐには処理されずに、キューに格納される。そして、データバッファ上の受信パケットが無くなったところで、キューに格納された受信パケットの処理が開始される。そして、受信パケットがリセットを指示するパケットであった場合には、リセットにより不要になる受信パケットが破棄される。このようにすれば、リセットにより不要になる受信パケット（リセットの影響を受ける受信パケット）に対して、無駄なパケット処理が行われるのを防止でき、リセット処理に要する時間を大幅に短縮化できる。
【０００９】
なお、キューは複数設けることが望ましいが、１つでもよい。また、パケット処理手段が行う受信パケットの処理としては、例えば、後段の処理手段（要求実行手段等）に受信パケットを渡すなどの処理が考えられる。また、不要な受信パケットを破棄する処理としては、キューをクリアする処理等が考えられるが、受信パケットを個別的に破棄してもよい。
【００１０】
また本発明は、前記キューとして複数のキューが用意され、前記パケット解析手段が、解析した受信パケットを前記複数のキューの中のいずれかのキューに格納し、前記パケット破棄手段が、処理した受信パケットがリセットを指示するパケットであった場合には、リセットにより不要になる受信パケットが格納されているキューをクリアすることを特徴とする。
【００１１】
このようにすれば、リセットにより不要になる受信パケットをひとまとめに破棄できるため、受信パケットを破棄する処理を大幅に効率化できる。
【００１２】
なお、複数のキューとしては、その各々が、受信パケットを渡す後段の処理手段（要求実行手段等）に対応したキューを設けることが望ましい。
【００１３】
また本発明は、前記パケット処理手段から受信パケットを受け、他のノードからの要求を実行する第１の要求実行手段と、前記パケット処理手段から受信パケットを受け、他のノードからの要求を実行すると共に、前記第１の要求実行手段がリセットされると自身もリセットされる関係にある第２の要求実行手段とを含み、前記パケット解析手段が、前記第１の要求実行手段に渡すべき受信パケットについては第１のキューに格納し、前記第２の要求実行手段に渡すべき受信パケットについては第２のキューに格納し、前記パケット処理手段が、前記第１のキューに格納されている受信パケットを、前記第２のキューに格納されている受信パケットよりも優先して処理することを特徴とする。
【００１４】
このようにすれば、第１の要求実行手段に渡すべき受信パケットが優先的に処理されるようになる。従って、第１の要求実行手段がリセットされるとリセットされる関係にある第２の要求実行手段の受信パケットが、無駄に処理されてしまう事態を防止でき、リセット処理に要する時間を短縮化できる。
【００１５】
なお、第１、第２の要求実行手段としては例えばＳＢＰ−２におけるマネージメントエージェントやフェッチエージェントが考えられるが、本発明は、これに限定されない。
【００１６】
また本発明は、前記パケット破棄手段が、処理した受信パケットが前記第１の要求実行手段のリセットを指示するパケットであった場合には、前記第１、第２のキューの両方をクリアすることを特徴とする。
【００１７】
このようにすれば、処理が不要な第２の要求実行手段の受信パケットが、ひとまとめに破棄されるようになるため、処理の効率化を図れる。
【００１８】
また本発明は、前記第２の要求実行手段が、上層のデバイスのコマンド制御要求を実行する第３の要求実行手段と、データ転送要求を実行する第４の要求実行手段とを含み、前記パケット解析手段が、前記第３の要求実行手段に渡すべき受信パケットについては第３のキューに格納し、前記第４の要求実行手段に渡すべき受信パケットについては第４のキューに格納し、前記パケット処理手段が、前記第３のキューに格納されている受信パケットを、前記第４のキューに格納されている受信パケットよりも優先して処理することを特徴とする。
【００１９】
このようにすれば、第３の要求実行手段に渡すべき受信パケットを優先的に処理できるようになり、データ転送処理中に、デバイスのコマンド制御要求を割り込ませることが可能になる。
【００２０】
また本発明は、バスに接続される複数のノード間でのデータ転送のためのデータ転送制御装置であって、自ノードのデータバッファに書き込まれた受信パケットを解析し、解析した受信パケットをキューに格納し、データバッファ上の受信パケットが無くなるまで受信パケットの解析及びキューへの格納を繰り返すパケット解析手段と、データバッファ上の受信パケットが無くなったところでキューに格納された受信パケットを処理するパケット処理手段と、ノードのトポロジ情報をクリアするリセットが発生した場合には、前記リセットの発生前の受信パケットを破棄するパケット破棄手段とを含むことを特徴とする。
【００２１】
本発明によれば、解析した受信パケットが直ぐには処理されずに、キューに格納される。そして、データバッファ上の受信パケットが無くなったところで、キューに格納された受信パケットの処理が開始される。そして、ノードのトポロジ情報をクリアするリセットが発生すると、リセットの発生前の受信パケットが破棄される。従って、リセット発生前に受信したパケットに対して、無駄なパケット処理が行われるのを防止でき、リセット処理に要する時間を大幅に短縮化できる。
【００２２】
また本発明は、前記パケット破棄手段が、ノードのトポロジ情報をクリアするリセットが発生した場合には、受信パケットが格納されているキューをクリアすることを特徴とする。
【００２３】
このようにすれば、リセット発生前の受信パケットをひとまとめに破棄できるため、処理の効率化を図れる。
【００２４】
なお、キューをクリアするか否かの判断は、キューに受信パケットを格納する毎に行ってもよいし、全ての受信パケットがキューに格納された後に行ってもよい。
【００２５】
なお、ノードのトポロジ情報をクリアする前記リセットは、ＩＥＥＥ１３９４の規格において定義されるバスリセットであることが望ましい。
【００２６】
また本発明では、ＩＥＥＥ１３９４の規格に準拠したデータ転送を行うことが望ましい。
【００２７】
また本発明に係る電子機器は、上記のいずれかのデータ転送制御装置と、前記データ転送制御装置及びバスを介して相手ノードから受信したデータに所与の処理を施す装置と、処理が施されたデータを出力又は記憶するための装置とを含むことを特徴とする。また本発明に係る電子機器は、上記のいずれかのデータ転送制御装置と、前記データ転送制御装置及びバスを介して相手ノードに送信するデータに所与の処理を施す装置と、処理が施されるデータを取り込むための装置とを含むことを特徴とする。
【００２８】
本発明によれば、データ転送を制御するファームウェア等の処理負担を軽減できるため、電子機器の低コスト化、処理の高速化などを図ることができる。また、リセットの発生によりシステム全体の処理がストールしてしまうなどの事態を防止できるため、電子機器の信頼性を高めることができる。
【００２９】
【発明の実施の形態】
以下、本発明の好適な実施形態について図面を用いて詳細に説明する。
【００３０】
１．ＩＥＥＥ１３９４
まず、ＩＥＥＥ１３９４について簡単に説明する。
【００３１】
１．１ 概要
ＩＥＥＥ１３９４（ＩＥＥＥ１３９４−１９９５、Ｐ１３９４．ａ）では１００〜４００Ｍｂｐｓの高速なデータ転送が可能となっている（Ｐ１３９４．ｂでは８００〜３２００Ｍｂｐｓ）。また、転送速度が異なるノードをバスに接続することも許される。
【００３２】
各ノードはツリー状に接続されており、１つのバスに最大で６３個のノードが接続可能になっている。なお、バスブリッジを利用すれば約６４０００個のノードを接続することも可能である。
【００３３】
ＩＥＥＥ１３９４では、パケットの転送方式として非同期転送とアイソクロナス転送が用意されている。ここで非同期転送は、信頼性が要求されるデータの転送に好適な転送方式であり、アイソクロナス転送は、リアルタイム性が要求される動画像や音声などのデータの転送に好適な転送方式である。
【００３４】
１．２ 層構造
ＩＥＥＥ１３９４の層構造（プロトコル構成）を図１に示す。
【００３５】
ＩＥＥＥ１３９４のプロトコルは、トランザクション層、リンク層、物理層により構成される。また、シリアルバスマネージメントは、トランザクション層、リンク層、物理層をモニターしたり制御したりするものであり、ノードの制御やバスのリソース管理のための種々の機能を提供する。
【００３６】
トランザクション層は、上位層にトランザクション単位のインターフェース（サービス）を提供し、下層のリンク層が提供するインターフェースを通して、リードトランザクション、ライトトランザクション、ロックトランザクション等のトランザクションを実施する。
【００３７】
ここで、リードトランザクションでは、応答ノードから要求ノードにデータが転送される。一方、ライトトランザクションでは、要求ノードから応答ノードにデータが転送される。またロックトランザクションでは、要求ノードから応答ノードにデータが転送され、応答ノードがそのデータに処理を施して要求ノードに返信する。
【００３８】
リンク層は、アドレッシング、データチェック、パケット送受信のためのデータフレーミング、アイソクロナス転送のためのサイクル制御などを提供する。
【００３９】
物理層は、リンク層により使用されるロジカルシンボルの電気信号への変換や、バスの調停や、バスの物理的インターフェースを提供する。
【００４０】
１．３ ＳＢＰ−２
さて、図２に示すように、ＩＥＥＥ１３９４のトランザクション層の一部の機能を含む上位のプロトコルとして、ＳＢＰ−２（Ｓｅｒｉａｌ Ｂｕｓ Ｐｒｏｔｏｃｏｌ−２）と呼ばれるプロトコルが提案されている。
【００４１】
ここでＳＢＰ−２は、ＳＣＳＩのコマンドセットをＩＥＥＥ１３９４のプロトコル上で利用可能にするために提案されたものである。このＳＢＰ−２を用いれば、既存のＳＣＳＩ規格の電子機器で使用されていたＳＣＳＩのコマンドセットに最小限の変更を加えて、ＩＥＥＥ１３９４規格の電子機器に使用できるようになる。従って、電子機器の設計や開発を容易化できる。また、ＳＣＳＩのコマンドだけではなく、デバイス固有のコマンドもカプセル化して利用できるため、非常に汎用性が高い。
【００４２】
図３に示すようにＳＢＰ−２では、まず、イニシエータ（例えばパーソナルコンピュータ）により作成されたログインＯＲＢ（Ｏｐｅｒａｔｉｏｎ Ｒｅｑｕｅｓｔ Ｂｌｏｃｋ）を用いてログイン処理が行われる（ステップＴ１）。次に、ダミーＯＲＢを用いてフェッチエージェントの初期化が行われる（ステップＴ２）。そして、コマンドブロックＯＲＢ（ノーマルコマンドＯＲＢ）を用いてコマンド処理が行われ（ステップＴ３）、最後に、ログアウトＯＲＢを用いてログアウト処理が行われる（ステップＴ４）。
【００４３】
ここで、ステップＴ３のコマンド処理においては、図４のＡ１に示すように、イニシエータがライト要求パケットを転送して（ライト要求トランザクションを発行して）、ターゲットのドアベルレジスタをリングする。すると、Ａ２に示すように、ターゲットがリード要求パケットを転送し、イニシエータが対応するリード応答パケットを返す。これにより、イニシエータが作成したＯＲＢ（コマンドブロックＯＲＢ）が、ターゲットのデータバッファにフェッチされる。そして、ターゲットは、フェッチされたＯＲＢに含まれるコマンドを解析する。
【００４４】
そして、ＯＲＢに含まれるコマンドがＳＣＳＩのライトコマンドであった場合には、Ａ３に示すように、ターゲットがリード要求パケットをイニシエータに転送し、イニシエータが対応するリード応答パケットを返す。これにより、イニシエータのデータバッファに格納されているデータがターゲットに転送される。そして、例えばターゲットがプリンタであった場合には、転送されたデータがプリンタエンジンにより印刷される。
【００４５】
一方、ＯＲＢに含まれるコマンドがＳＣＳＩのリードコマンドであった場合には、図５のＢ１に示すように、ターゲットは、一連のライト要求パケットをイニシエータに転送する。これにより、例えばターゲットがスキャナであった場合には、スキャナエンジンにより取得されたスキャンデータが、イニシエータのデータバッファに転送されることになる。
【００４６】
このＳＢＰ−２によれば、ターゲットは、自身が都合の良いときに要求パケットを転送して（トランザクションを発行して）、データを送受信できる。従って、イニシエータとターゲットが同期して動く必要がなくなるため、データ転送効率を高めることができる。
【００４７】
なお、ＩＥＥＥ１３９４の上位プロトコルとしては、ＳＢＰ−２以外にも、ＦＣＰ（Ｆｕｎｃｔｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）と呼ばれるプロトコルなども提案されている。
【００４８】
１．４ バスリセット
ＩＥＥＥ１３９４では、電源が投入されたり、途中でデバイスの抜き差しが発生すると、バスリセットが発生する。即ち、各ノードは、ポートの電圧変化を監視している。そして、バスに新たなノードが接続されるなどしてポートの電圧に変化が生じると、この変化を検知したノードは、バス上の他のノードに対して、バスリセットが発生したことを知らせる。また、各ノードの物理層は、バスリセットが発生したことをリンク層に伝える。
【００４９】
そして、このようにバスリセットが発生すると、ノードＩＤなどのトポロジ情報がクリアされる。そして、その後、トポロジ情報が自動的に再設定される。即ち、バスリセット後、ツリー識別、自己識別が行われる。その後、アイソクロナスリソースマネージャ、サイクルマスタ、バスマネージャ等の管理ノードが決定される。そして、通常のパケット転送が再開される。
【００５０】
このようにＩＥＥＥ１３９４では、バスリセット後にトポロジ情報が自動的に再設定されるため、電子機器のケーブルを自由に抜き差しできるようになり、いわゆるホットプラグを実現できる。
【００５１】
なお、トランザクションの途中でバスリセットが発生した場合には、そのトランザクションはキャンセルされる。そして、キャンセルされたトランザクションを発行した要求ノードは、トポロジ情報が再設定された後に、要求パケットを再度転送する。また、応答ノードは、バスリセットによりキャンセルされたトランザクションの応答パケットを要求ノードに返送してはならない。
【００５２】
２．全体構成
次に、本実施形態のデータ転送制御装置の全体構成例について図６を用いて説明する。なお、以下では、イニシエータ（相手ノード）との間でデータ転送を行うターゲット（自ノード）がプリンタである場合について例にとり説明するが、本発明はこれに限定されない。
【００５３】
本実施形態のデータ転送制御装置１０は、ＰＨＹデバイス１２（物理層のデバイス）、リンクデバイス１４（リンク層のデバイス）、ＣＰＵ１６（プロセッサ）、データバッファ１８（記憶手段）、ファームウェア２０（処理手段）を含む。なお、ＰＨＹデバイス１２、リンクデバイス１４、ＣＰＵ１６、データバッファ１８は、任意の構成要素であり、本実施形態のデータ転送制御装置１０は、これらの構成要素を全て含む必要はない。
【００５４】
ＰＨＹデバイス１２は、図１の物理層のプロトコルをハードウェアにより実現するための回路であり、リンクデバイス１４により使用されるロジカルシンボルを電気信号に変換する機能を有する。
【００５５】
リンクデバイス１４は、図１のリンク層のプロトコルやトランザクション層のプロトコルの一部をハードウェアにより実現するための回路であり、ノード間でのパケット転送のための各種サービスを提供する。
【００５６】
ＣＰＵ１６は、装置全体の制御やデータ転送の制御を行うものである。
【００５７】
データバッファ１８は、転送データ（パケット）を一時的に格納するバッファであり、ＳＲＡＭ、ＳＤＲＡＭ、或いはＤＲＡＭなどのハードウェアにより構成される。なお、本実施形態では、データバッファ１８は、特には限定されないがランダムアクセス可能なパケット記憶手段として機能する。
【００５８】
ファームウェア２０は、ＣＰＵ１６上で動作する種々の処理ルーチン（処理モジュール）を含むプログラムであり、トランザクション層のプロトコルは、このファームウェア２０と、ハードウェアであるＣＰＵ１６等により実現される。
【００５９】
なお、イニシエータであるパーソナルコンピュータ１００が含むデバイスドライバ１０２は、周辺機器を管理制御するための種々の処理ルーチンを含むプログラムである。このプログラムは、情報記憶媒体１１０（ＦＤ、ＣＤ−ＲＯＭ、ＤＶＤ、ＲＯＭ）を利用してパーソナルコンピュータ１００にインストールされる。
【００６０】
ここで、デバイスドライバ１０２のプログラムは、ホストシステムが有する情報記憶媒体（ハードディスク、磁気テープ等）からインターネットなどのネットワークを介してダウンロードし、パーソナルコンピュータ１００にインストールするようにしてもよい。
【００６１】
ファームウェア２０（Ｆ／Ｗ）は、コミュニケーション部３０（ＣＯＭ）、マネージメントエージェント４０（ＭＮＧ）、フェッチエージェント５０（ＦＣＨ１）、フェッチエージェント６０（ＦＣＨ２）、プリントタスク部７０（ＰＲＴ）を含む。
【００６２】
ここで、コミュニケーション部３０は、リンクデバイス１４などのハードウェアとの間のインターフェースとして機能する処理モジュールである。
【００６３】
マネージメントエージェント４０（第１の要求実行手段）は、ログイン、リコネクト、ログアウト、リセット等の管理を行う処理モジュールである。例えばイニシエータがターゲットにログインを要求した場合には、まず、このマネージメントエージェント４０が、このログイン要求を受け付けることになる。
【００６４】
フェッチエージェント５０、６０（コマンドブロックエージェント。第２の要求実行手段）は、イニシエータからの要求を実行するための処理モジュールであり、より具体的には、コマンドブロックＯＲＢが含むコマンドを実行する。フェッチエージェント５０、６０は、単一の要求しか扱うことができないマネージメントエージェント４０と異なり、イニシエータからの要求により自身がフェッチしたＯＲＢのリンクリストも扱うことができる。
【００６５】
プリンタスク部７０は、プリンタエンジンやスキャナエンジン（上層のデバイス）との間でＤＭＡ転送を行うための処理モジュールである。
【００６６】
なお、フェッチエージェント５０（第３（第２）の要求実行手段）は、後段のプリンタエンジンやスキャナエンジン（上層のデバイス）のコマンド制御のための処理モジュールであり、フェッチエージェント６０（第４（第２）の要求実行手段）は、後段のプリンタエンジンやスキャナエンジンとの間のデータ転送のための処理モジュールである。
【００６７】
例えばプリンタエンジンとのデータ転送中にインク残量を調べたい場合に、フェッチエージェントが１つしかないと、ＯＲＢのリンクリストによるデータ転送が全て完了するまで、インク残量をチェックできない。
【００６８】
本実施形態では、互いに独立なフェッチエージェントを２つ設けている（３つ以上でもよい）。そして、コマンド制御用のフェッチエージェント５０の処理の優先度を、データ転送用のフェッチエージェント６０の処理の優先度よりも高くしている。より具体的には、後述するように、コマンド制御用のフェッチエージェント５０に渡す受信パケットを、データ転送用のフェッチエージェント６０に渡す受信パケットよりも優先して処理するようにしている。
【００６９】
このようにすることで、ＯＲＢのリンクリストによるデータ転送処理の間に、インク残量チェックなどのプリンタのコマンド制御処理を割り込ませることできる。従って、データ転送処理が終わるのを長時間待つことなく、インク残量をチェックできるようになり、データ転送に影響を与えることなく、デバイスのコマンド制御ができるようになる。
【００７０】
さて、コミュニケーション部３０は、パケット解析部３２、パケット処理部３４、パケット破棄部３６を含む。
【００７１】
ここで、パケット解析部３２は、パーソナルコンピュータ１００からＩＥＥＥ１３９４バス、ＰＨＹデバイス１２、リンクデバイス１４を介してデータバッファ１８に書き込まれた受信パケットを解析する。そして、解析した受信パケットをキューに格納する。
【００７２】
なお、このキューは、例えばＣＰＵ１６のローカルメモリ上に確保することができる。また、後述するように複数のキューがある場合には、パケット解析部３２は、解析結果に応じたキューに受信パケットを格納する。
【００７３】
そして、パケット解析部３２は、受信パケットをキューに格納すると、次の受信パケットを解析する。そして、データバッファ１８上の受信パケットが無くなるまで、受信パケットの解析及びキューへの格納を繰り返す。
【００７４】
パケット処理部３４は、データバッファ１８上の受信パケットが無くなったところで、キューに格納された受信パケットを処理する。より具体的には、キューに格納された受信パケットをマネージメントエージェント４０（ＭＮＧ）、フェッチエージェント５０（ＦＣＨ１）、或いはフェッチエージェント６０（ＦＣＨ２）に渡す。例えば、ＭＮＧ用のキュー、ＦＣＨ１用のキュー、ＦＣＨ２用のキューというように複数のキューがある場合には、ＭＮＧ用のキューに格納される受信パケットについてはマネージメントエージェント４０に渡す。また、ＦＣＨ１用、ＦＣＨ２用のキューに格納される受信パケットについては、各々、フェッチエージェント５０、６０に渡す。
【００７５】
パケット破棄部３６は、パケット処理部３４により処理された受信パケットが、エージェントリセット、ターゲットリセット、リセットスタートなどのリセットを指示するパケットであった場合には、キューに格納された受信パケットのうちリセットにより不要になる受信パケット（リセットの影響を受ける受信パケット）を破棄する処理を行う。そして、例えばキューが複数ある場合には、リセットされるエージェントのキューをクリアすることで、受信パケットをひとまとめに破棄する。
【００７６】
また、パケット破棄部３６は、バスリセット（広義にはノードのトポロジ情報をクリアするリセット）が発生した場合には、バスリセット発生前に受信したパケットを破棄する処理を行う。
【００７７】
３．本実施形態の特徴
３．１ リセット時の不要パケットの破棄
さて、ＳＢＰ−２においては、ターゲットにエラーが発生した場合に、イニシエータはターゲットに対してリセットを指示するパケット（以下、リセットパケットと呼ぶ）を転送できる。そして、この場合に、ＳＢＰ−２ではレベルの異なる種々のリセットが用意されている。例えば、リセットスタートは最も強いレベルのリセットであり、ノード状態が全てリセットされる。また、アボートタスクやアボートタスクセットでは、タスクやタスクのセットがリセットされ、ターゲットリセットではターゲットがリセットされる。また、エージェントリセットでは、フェッチエージェントのみがリセットされる。
【００７８】
なお、リセットスタート、エージェントリセットは、イニシエータが所定のレジスタに所定の情報をライトすることによりターゲットに伝えられ、アボートタスク、アボートタスクセット、ターゲットリセットは、イニシエータから転送されるマネージメントＯＲＢを用いてターゲットに伝えられる。
【００７９】
このように、イニシエータからリセットパケットが転送されてくると、リセットにより不要になるパケットについては破棄する必要がある。そして、この場合に、図７の比較例では、受信パケットを解析した後に直ぐにパケット処理（エージェントに受信パケットを渡す処理等）を行う（ステップＴ１、Ｔ２）。次に、受信パケットがリセットパケットか否かを判断し、リセットパケットであれば受信パケットを破棄する処理を行う（ステップＴ３、Ｔ４）。そして、以上の処理を、受信パケットが無くなるまで繰り返す（ステップＴ５）。
【００８０】
しかしながら、この比較例では、リセットにより破棄される運命にある受信パケットに対しても、パケット処理が行われてしまう。従って、リセット処理が非常に非効率になる。
【００８１】
特に、プリンタやスキャナやＣＤ−ＲＷなどの周辺機器に本実施形態のデータ転送制御装置を組み込んだ場合、製品コストの制約から、安価で処理能力が低いＣＰＵが使用される場合が多い、従って、そのＣＰＵ上で動作するファームウェアもその制約の影響を受けて、処理速度が遅くなってしまう。このため、受信パケットの処理が間に合わなくなり、多数の未処理の受信パケットが自ノード（ターゲット）のデータバッファ上に存在するようになる。従って、リセット処理時間の増加の問題は更に深刻なものになる。
【００８２】
そこで本実施形態では図８のＣ１、Ｃ２に示すように、ターゲットのデータバッファに書き込まれた受信パケットを解析した後、解析した受信パケットを直ぐには処理せずにキューに格納する。そして、Ｃ３に示すように、データバッファ上の受信パケットが無くなったところで、キューに格納された受信パケットを処理する。そして、Ｃ４に示すように、処理した受信パケットがエージェントリセット等のリセットパケットであった場合には、リセットにより不要になる受信パケット（リセットの影響を受ける受信パケット）を破棄する。
【００８３】
このようにすれば、リセットにより、パケット処理を行うまでもなく不要になる受信パケットについては、パケット処理を行わないで済むようになる。従って、全ての受信パケットに対してパケット処理が行われる図７の比較例に比べて、リセット処理に要する時間を大幅に短縮化できる。この結果、システム全体の処理がリセット処理によりストールしてしまう事態を防止できると共に、ファームウェアの処理負担も軽減化できる。
【００８４】
更に、本実施形態では、受信パケットを格納するキューを複数用意し、解析した受信パケットを、複数のキューの中のいずれかに仕分けして格納する。そしてリセットが発生した場合には、リセットにより不要になる受信パケットが格納されているキューをクリアする。
【００８５】
より具体的には、図９（Ａ）に示すように、マネージメントエージェントに渡す受信パケットを格納するためのＭＮＧキューと、フェッチエージェントに渡す受信パケットを格納するためのＦＣＨキューを用意する。そして、図９（Ａ）、（Ｂ）に示すように、受信パケットの解析結果に応じたキューに受信パケットを格納する。即ち、マネージメントエージェントに渡すパケットについてはＭＮＧキューに格納し、フェッチエージェントに渡すパケットについてはＦＣＨキューに格納する。
【００８６】
そして、図９（Ｃ）に示すように、例えば受信パケットがエージェントリセットであると判明した場合（エージェントリセットレジスタへのライトパケットであると判明した場合）には、ＦＣＨキューをクリアする。即ち、ＦＣＨキューに格納されている受信パケットは、フェッチエージェントに渡すパケットであり、エージェントリセットにより不要になるパケットである。従って、エージェントキュー自体をクリアすることで、これらの不要パケットをひとまとめにして破棄できる。
【００８７】
このように、キューのクリアにより受信パケットを破棄するようにすれば、不要な受信パケットをひとまとめに破棄できるようになり、受信パケットを破棄する処理を大幅に効率化できる。これにより、リセット処理を更に高速化できるようになる。
【００８８】
また、本実施形態では、第１のエージェントがリセットされると第２のエージェントがリセットされるという関係がある場合に、第１のエージェント用のキューに格納されている受信パケットを、第２のエージェント用のキューに格納されている受信パケットよりも優先して処理するようにしている。
【００８９】
より具体的には、図１０（Ａ）に示すように、マネージメントエージェント（第１の要求実行手段）用のＭＮＧキューと、フェッチエージェント（第２の要求実行手段）用のＦＣＨキューがある場合には、ＭＮＧキューに格納される受信パケットを優先的に処理する（フェッチエージェントは、マネージメントエージェントがリセットされると自身もリセットされる関係にある）。即ち、ＭＮＧキューに格納されている全ての受信パケットについてのパケット処理（マネージメントエージェントにパケットを渡す等の処理）が完了した後に、図１０（Ｂ）に示すように、ＦＣＨキューに格納されている受信パケットのパケット処理を開始する。
【００９０】
このようにすれば、図１０（Ｃ）に示すように、例えばＭＮＧキューに格納される受信パケットの中にリセットスタートを指示するパケットがあった場合に、ＭＮＧキューとＦＣＨキューの両方をクリアできる。これにより、ＦＣＨキューに格納される受信パケットは破棄され、これらの受信パケットに対して無駄なパケット処理を行わなくて済むようになる。この結果、リセット処理の更なる効率化を図れ、リセット処理を高速に完了できるようになる。
【００９１】
なお、本実施形態では図１１（Ａ）に示すように、フェッチエージェント（第２の要求実行手段）として、コマンド制御用のフェッチエージェントＦＣＨ１（第３の要求実行手段）とデータ転送用のフェッチエージェントＦＣＨ２（第４の要求実行手段）を用意している。そして、コマンド制御用のフェッチエージェントＦＣＨ１に渡すべき受信パケットについてはＦＨＣ１キューに格納し、データ転送用のフェッチエージェントＦＣＨ２に渡すべき受信パケットについてはＦＨＣ２キューに格納する。そして、図１１（Ａ）に示すように、ＦＣＨ１キューに格納されているコマンド制御用の受信パケットを優先して処理し、ＦＣＨ１キューの全ての受信パケットについてのパケット処理が完了した後に、図１１（Ｂ）に示すように、ＦＣＨ２キューに格納されている受信パケットのパケット処理を開始する。
【００９２】
このようにすれば、フェッチエージェントＦＣＨ１による処理が優先されるようになり、フェッチエージェントＦＣＨ２によるデータ転送処理の間に、フェッチエージェントＦＣＨ１によるコマンド制御処理を容易に割り込ませることができる。従って、印刷が完了するのを待つことなく、インク残量を調べることなどが可能になる。
【００９３】
３．２ バスリセット時の不要パケットの処理
ＩＥＥＥ１３９４においては、バスに電子機器が新たに接続されたり、バスから電子機器が取り外されたりすると、バスリセットが発生する。そして、バスリセットが発生すると、ノードのトポロジ情報がクリアされ、バスリセット発生時点で未完了であったトランザクションは全てキャンセルされる。このため、バスリセット発生前に受信したパケットは全て無効になる。
【００９４】
ところが、前述のように、データ転送制御装置が組み込まれる周辺機器で動作するＣＰＵは処理能力が低い。このため、このＣＰＵ上で動作するファームウェアも高速に受信パケットを処理できず、多数の未処理の受信パケットがデータバッファ上に存在するようになる。従って、バスリセットが発生した場合には、これらの多数の未処理の受信パケットの中から、バスリセット発生前のパケットを区別して破棄する処理が必要になる。従って、ファームウェアの処理負荷も過大になる。
【００９５】
そこで本実施形態では、図１２（Ａ）に示すように、ターゲットのデータバッファに書き込まれた受信パケットを解析した後、解析した受信パケットを直ぐには処理せずにキューに格納する。そして、データバッファ上の受信パケットが無くなったところでキューに格納された受信パケットを処理する。そして、バスリセットが発生した場合には、バスリセット発生前に受信したパケットを破棄するようにする。
【００９６】
より具体的には、図１２（Ｂ）に示すように、受信パケットのキューへの格納中にＩＥＥＥ１３９４のバス上でバスリセットが発生した場合には、受信パケットのキューをクリアして、バスリセット発生前の受信パケットを破棄する（この場合には、データバッファ上の受信パケットも破棄することが望ましい）。また、図１２（Ｃ）に示すように、全ての受信パケットをキューに格納した後、受信パケットの処理中に、バスリセットが発生した場合にも、受信パケットのキューをクリアして、受信パケットを破棄する。
【００９７】
以上のようにすれば、バスリセットにより、パケット処理を行うまでもなく不要になる受信パケットについては、パケット処理を行わないで済むようになる。従って、全ての受信パケットに対してパケット処理が行われる図７の比較例に比べて、バスリセット処理に要する時間を大幅に短縮化できる。この結果、システム全体の処理がバスリセット処理によりストールしてしまう事態を防止できると共に、ファームウェアの処理負担も軽減化できる。
【００９８】
また、キューのクリアにより受信パケットを破棄すれば、バスリセット発生前の多数の受信パケットをひとまとめに破棄できるため、受信パケットを破棄する処理を更に効率化できる。特に、ＣＰＵの処理能力の低さに起因して多数の未処理の受信パケットがデータバッファ上に存在するような場合には、キューのクリアにより受信パケットを破棄する本実施形態の手法は、処理の効率化に非常に効果的なものとなる。
【００９９】
４．本実施形態の処理
次に、本実施形態の詳細な処理例について図１３、図１４のフロチャートを用いて説明する。
【０１００】
ＣＰＵ（或いはリンクデバイス）からの割り込みが発生すると、その割り込み要因を解析し、解析が済んだ割り込み要因をクリアする（ステップＳ１）。ここで割り込み要因としては、パケット受信の割り込み、バスリセット発生の割り込み、プリンタへのＤＭＡ転送終了の割り込み、ＣＰＵのタイマ割り込みなどがある。
【０１０１】
次に、解析した割り込み要因が、パケット受信の割り込みか否かを判断し（ステップＳ２）、パケット受信の割り込みではなかった場合には、バスリセット発生の割り込みか否かを判断する（ステップＳ３）。そして、バスリセット発生の割り込みであった場合には、エージェントキューの全てと送信キューをクリアし（ステップＳ４。図１２（Ｂ）、（Ｃ）参照）、バスリセット発生前の受信パケットを破棄する。
【０１０２】
次に、ＣＰＵからの割り込み要因が存在するか否かを判断し（ステップＳ５）、存在する場合には、その割り込み要因を解析し、解析が済んだ割り込み要因をクリアする（ステップＳ６）。次に、解析が済んでいない未処理の割り込み要因が、まだ存在するか否かを判断し（ステップＳ７）、存在する場合にはステップＳ２に戻り、存在しない場合には割り込み処理を終了する。
【０１０３】
ステップＳ２でパケット受信の割り込みが発生したと判断した場合には、受信パケットが、自身が転送した要求パケットに対するイニシエータの応答パケットか否かを判断する（図１４のステップＳ８）。そして、応答パケットであった場合には、応答パケットに関する処理（データバッファにおける応答パケットの格納場所のポインタ制御等）を行う（ステップＳ９）。
【０１０４】
次に、パケットの解析結果に基づいて、受信パケットがエージェントに渡すパケットか否かを判断する（ステップＳ１０）。そして、エージェントに渡すパケットであった場合には、図９（Ａ）、（Ｂ）で説明したように、受信パケットを、対応するエージェントのキューに格納する（ステップＳ１１）。例えば、マネージメントエージェントに渡す受信パケットはＭＮＧキューに格納し、フェッチエージェントに渡す受信パケットはＦＣＨキューに格納する。
【０１０５】
次に、バスリセットが発生しているか否かを判断する（ステップＳ１２）。そして、バスリセットが発生している場合には、図１２（Ｂ）で説明したように、エージェントキューの全てと送信キューをクリアする（ステップＳ２２）。一方、発生していない場合には、キューに格納すべき受信パケットがデータバッファ上にまだ存在しているか否かを判断し（ステップＳ１３）、存在している場合にはステップＳ１１に戻る。そして、データバッファ上の受信パケットが無くなるまで、ステップＳ１１、Ｓ１２、Ｓ１３の処理を繰り返す。
【０１０６】
次に、キューへの受信パケットの格納後、バスリセットが発生しているか否かを判断する（ステップＳ１４）。そして、発生している場合には、図１２（Ｃ）で説明したように、エージェントキューの全てと送信キューをクリアする（ステップＳ２２）。一方、発生してない場合には、図８のＣ３に示すように、キューに格納されている受信パケットに対する処理（エージェントに渡す処理等）があるか否かを判断する（ステップＳ１５）。そして、処理がある場合には、図１０（Ａ）で説明したように、優先順位の高いエージェントキュー（例えばＭＮＧキュー）から処理を行う（ステップＳ１６）。
【０１０７】
次に、受信パケットがリセットパケット（リセットを指示するパケット）か否かを判断する（ステップＳ１７）。例えば、ターゲットリセットの場合には、エージェントがＯＲＢの内容を解析することで、リセットパケットか否かを判断できる。また、エージェントリセットやリセットスタートの場合には、エージェントがパケットのライトアドレスを解析することで、リセットパケットか否かを判断できる。
【０１０８】
受信パケットがリセットパケットであった場合には、図９（Ｃ）や図１０（Ｃ）で説明したように、リセットにより影響を受けるエージェントキューをクリアする（ステップＳ１８）。例えば、マネージメントエージェントのリセットの場合には、ＭＮＧキューとＦＣＨキューの両方をクリアする。一方、フェッチエージェントのリセットの場合には、ＦＣＨキューのみをクリアする。
【０１０９】
次に、データバッファ上の送信バッファに空きがあり、且つ、送信要求が存在するか否かを判断し（ステップＳ１９）、存在する場合にはパケット送信を行う（ステップＳ２０）。次に、バスリセットが発生しているか否かを判断し（ステップＳ２１）、発生している場合には、エージェントキューの全てと送信キューをクリアする（ステップＳ２２）。一方、発生してない場合には、図１３のステップＳ３に戻る。
【０１１０】
そして、ステップＳ３〜Ｓ７、Ｓ２、Ｓ８〜Ｓ２１の処理を繰り返して、キューに格納されている受信パケットを１つずつ順次処理して行く。即ち、まず、優先順位が最も高いキュー（例えばＭＮＧキュー）に格納されている受信パケットを１つずつ順次処理して行き、全ての受信パケットに対する処理が完了した場合には、２番目に優先順位が高いキュー（例えばＦＣＨ１キュー）に格納されている受信パケットを処理する。そして、そのキューの全ての受信パケットの処理が完了すると、３番目に優先順位が高いキュー（例えばＦＣＨ２キュー）に格納されている受信パケットを処理する。以上のようにして、キューに格納されている全ての受信パケットに対して処理を行う。
【０１１１】
５．電子機器
次に、本実施形態のデータ転送制御装置を含む電子機器の例について説明する。
【０１１２】
例えば図１５（Ａ）に電子機器の１つであるプリンタの内部ブロック図を示し、図１６（Ａ）にその外観図を示す。ＣＰＵ（マイクロコンピュータ）５１０はシステム全体の制御などを行う。操作部５１１はプリンタをユーザが操作するためのものである。ＲＯＭ５１６には、制御プログラム、フォントなどが格納され、ＲＡＭ５１８はＣＰＵ５１０のワーク領域として機能する。表示パネル５１９はプリンタの動作状態をユーザに知らせるためのものである。
【０１１３】
ＰＨＹデバイス５０２、データ転送制御装置５００を介して、パーソナルコンピュータなどの相手ノードから送られてきた印字データは、バス５０４を介して印字処理部（プリンタエンジン）５１２に直接送られる。そして、印字データは、印字処理部５１２にて所与の処理が施され、プリントヘッダなどからなる印字部（データを出力するための装置）５１４により紙に印字されて出力される。
【０１１４】
図１５（Ｂ）に電子機器の１つであるスキャナの内部ブロック図を示し、図１６（Ｂ）にその外観図を示す。ＣＰＵ５２０はシステム全体の制御などを行う。操作部５２１はスキャナをユーザが操作するためのものである。ＲＯＭ５２６には制御プログラムなどが格納され、ＲＡＭ５２８はＣＰＵ５２０のワーク領域として機能する。
【０１１５】
光源、光電変換器などからなる画像読み取り部（データを取り込むための装置）５２２により原稿の画像が読み取られ、読み取られた画像のデータは画像処理部（スキャナエンジン）５２４により処理される。そして、処理後の画像データがバス５０５を介してデータ転送制御装置５００に直接送られる。データ転送制御装置５００は、この画像データにヘッダなどを付加することでパケットを生成し、ＰＨＹデバイス５０２を介してパーソナルコンピュータなどの相手ノードに送信する。
【０１１６】
図１５（Ｃ）に電子機器の１つであるＣＤ−ＲＷドライブの内部ブロック図を示し、図１６（Ｃ）にその外観図を示す。ＣＰＵ５３０はシステム全体の制御などを行う。操作部５３１はＣＤ−ＲＷをユーザが操作するためのものである。ＲＯＭ５３６には制御プログラムなどが格納され、ＲＡＭ５３８はＣＰＵ５３０のワーク領域として機能する。
【０１１７】
レーザ、モータ、光学系などからなる読み取り＆書き込み部（データを取り込むための装置又はデータを記憶するための装置）５３３によりＣＤ−ＲＷ５３２から読み取られたデータは、信号処理部５３４に入力され、エラー訂正処理などの所与の信号処理が施される。そして、信号処理が施されたデータが、バス５０６を介してデータ転送制御装置５００に直接送られる。データ転送制御装置５００は、このデータにヘッダなどを付加することでパケットを生成し、ＰＨＹデバイス５０２を介してパーソナルコンピュータなどの相手ノードに送信する。
【０１１８】
一方、ＰＨＹデバイス５０２、データ転送制御装置５００を介して、相手ノードから送られてきたデータは、バス５０６を介して信号処理部５３４に直接送られる。そして、信号処理部５３４によりこのデータに所与の信号処理が施され、読み取り＆書き込み部５３３によりＣＤ−ＲＷ５３２に記憶される。
【０１１９】
なお、図１５（Ａ）、（Ｂ）、（Ｃ）において、ＣＰＵ５１０、５２０、５３０の他に、データ転送制御装置５００でのデータ転送制御のためのＣＰＵを別に設けるようにしてもよい。
【０１２０】
また、図１５（Ａ）、（Ｂ）、（Ｃ）ではＲＡＭ５０１（データバッファに相当）がデータ転送制御装置５００の外部に設けられているが、ＲＡＭ５０１をデータ転送制御装置５００に内蔵させてもよい。
【０１２１】
本実施形態のデータ転送制御装置を電子機器に用いれば、データ転送制御装置や電子機器に何らかのエラーが発生して、データ転送制御装置がリセットされた場合にも、短時間で正常状態に復帰できるようになる。また、バスに新たな電子機器が接続されてバスリセットが発生した場合にも、短い時間でバスリセット状態から復帰でき、システム全体がストールしてしまう事態を防止できる。
【０１２２】
また本実施形態のデータ転送制御装置を電子機器に用いれば、高速なデータ転送が可能になる。従って、ユーザがパーソナルコンピュータなどによりプリントアウトの指示を行った場合に、少ないタイムラグで印字が完了するようになる。また、スキャナへの画像取り込みの指示の後に、少ないタイムラグで読み取り画像をユーザは見ることができるようになる。また、ＣＤ−ＲＷからのデータの読み取りや、ＣＤ−ＲＷへのデータの書き込みを高速に行うことができるようになる。
【０１２３】
また本実施形態のデータ転送制御装置を電子機器に用いることで、ＣＰＵ上で動作するファームウェアの処理負担が軽減され、安価なＣＰＵや低速のバスを用いることが可能になる。更に、データ転送制御装置の低コスト化、小規模化を図れるため、電子機器の低コスト化、小規模化も図れるようになる。
【０１２４】
なお本実施形態のデータ転送制御装置を適用できる電子機器としては、上記以外にも例えば、種々の光ディスクドライブ（ＣＤ−ＲＯＭ、ＤＶＤ）、光磁気ディスクドライブ（ＭＯ）、ハードディスクドライブ、ＴＶ、ＶＴＲ、ビデオカメラ、オーディオ機器、電話機、プロジェクタ、パーソナルコンピュータ、電子手帳、ワードプロセッサなど種々のものを考えることができる。
【０１２５】
なお、本発明は本実施形態に限定されず、本発明の要旨の範囲内で種々の変形実施が可能である。
【０１２６】
例えば、本発明のデータ転送制御装置の構成は、図６に示す構成が特に望ましいが、これに限定されるものではない。
【０１２７】
また、受信パケットを破棄する手法も、本実施形態で説明した手法が特に望ましいが、これに限定されるものではない。
【０１２８】
また、本実施形態では、２つ又は３つのキューを設ける場合について説明したが、４つ以上のキューを設けるようにしてもよい。
【０１２９】
また、本発明は、ＩＥＥＥ１３９４規格でのデータ転送に適用されることが特に望ましいが、これに限定されるものではない。例えばＩＥＥＥ１３９４と同様の思想に基づく規格やＩＥＥＥ１３９４を発展させた規格におけるデータ転送にも本発明は適用できる。
【図面の簡単な説明】
【図１】ＩＥＥＥ１３９４の層構造について示す図である。
【図２】ＳＢＰ−２について説明するための図である。
【図３】ＳＢＰ−２のデータ転送処理の概略について説明するための図である。
【図４】データをイニシエータからターゲットに転送する場合のコマンド処理について説明するための図である。
【図５】データをターゲットからイニシエータに転送する場合のコマンド処理について説明するための図である。
【図６】本実施形態のデータ転送制御装置の構成例を示す図である。
【図７】比較例の処理について説明するためのフローチャートである。
【図８】リセット時の本実施形態の手法について説明するための図である。
【図９】図９（Ａ）、（Ｂ）、（Ｃ）は、複数のキューを用意し、キューをクリアすることにより、不要なパケットを破棄する手法について説明するための図である。
【図１０】図１０（Ａ）、（Ｂ）、（Ｃ）は、優先順位の高いキューを優先的に処理する手法について説明するための図である。
【図１１】図１１（Ａ）、（Ｂ）は、コマンド制御用のフェッチエージェントのキューを優先的に処理する手法について説明するための図である。
【図１２】図１２（Ａ）、（Ｂ）、（Ｃ）は、バスリセット時の本実施形態の手法について説明するための図である。
【図１３】本実施形態の詳細な処理例を示すフローチャートである。
【図１４】本実施形態の詳細な処理例を示すフローチャートである。
【図１５】図１５（Ａ）、（Ｂ）、（Ｃ）は、種々の電子機器の内部ブロック図の例である。
【図１６】図１６（Ａ）、（Ｂ）、（Ｃ）は、種々の電子機器の外観図の例である。
【符号の説明】
１０ データ転送制御装置
１２ ＰＨＹデバイス
１４ リンクデバイス
１６ ＣＰＵ
１８ データバッファ
２０ ファームウェア（Ｆ／Ｗ）
３０ コミュニケーション部（ＣＯＭ）
３２ パケット解析部
３４ パケット処理部
３６ パケット破棄部
４０ マネージメントエージェント（ＭＮＧ。第１の要求実行手段）
５０ フェッチエージェント（ＦＣＨ１。第３（第２）の要求実行手段）
６０ フェッチエージェント（ＦＣＨ２。第４（第２）の要求実行手段）
７０ プリントタスク部（ＰＲＴ）
１００ パーソナルコンピュータ
１０２ デバイスドライバ
１０４ データバッファ
１１０ 情報記憶媒体
Claims (11)
- バスに接続される複数のノード間でのデータ転送のためのデータ転送制御装置であって、
自ノードのデータバッファに書き込まれた受信パケットを解析し、解析した受信パケットをキューに格納し、データバッファ上の受信パケットが無くなるまで受信パケットの解析及びキューへの格納を繰り返すパケット解析手段と、
データバッファ上の受信パケットが無くなったところで、キューに格納された受信パケットを処理するパケット処理手段と、
処理した受信パケットがリセットを指示するパケットであった場合には、キューに格納された受信パケットのうち前記リセットにより不要になる受信パケットを破棄するパケット破棄手段とを含み、
前記キューとして複数のキューが用意され、
前記パケット解析手段が、
解析した受信パケットを前記複数のキューの中のいずれかのキューに格納し、
前記パケット破棄手段が、
処理した受信パケットがリセットを指示するパケットであった場合には、リセットにより不要になる受信パケットが格納されているキューをクリアすることを特徴とするデータ転送制御装置。 - 請求項１において、
前記パケット処理手段から受信パケットを受け、他のノードからの要求を実行する第１の要求実行手段と、
前記パケット処理手段から受信パケットを受け、他のノードからの要求を実行すると共に、前記第１の要求実行手段がリセットされると自身もリセットされる関係にある第２の要求実行手段とを含み、
前記パケット解析手段が、
前記第１の要求実行手段に渡すべき受信パケットについては第１のキューに格納し、前記第２の要求実行手段に渡すべき受信パケットについては第２のキューに格納し、
前記パケット処理手段が、
前記第１のキューに格納されている受信パケットを、前記第２のキューに格納されている受信パケットよりも優先して処理することを特徴とするデータ転送制御装置。 - バスに接続される複数のノード間でのデータ転送のためのデータ転送制御装置であって、
自ノードのデータバッファに書き込まれた受信パケットを解析し、解析した受信パケットをキューに格納し、データバッファ上の受信パケットが無くなるまで受信パケットの解析及びキューへの格納を繰り返すパケット解析手段と、
データバッファ上の受信パケットが無くなったところで、キューに格納された受信パケットを処理するパケット処理手段と、
処理した受信パケットがリセットを指示するパケットであった場合には、キューに格納された受信パケットのうち前記リセットにより不要になる受信パケットを破棄するパケット破棄手段と、
前記パケット処理手段から受信パケットを受け、他のノードからの要求を実行する第１の要求実行手段と、
前記パケット処理手段から受信パケットを受け、他のノードからの要求を実行すると共に、前記第１の要求実行手段がリセットされると自身もリセットされる関係にある第２の要求実行手段とを含み、
前記パケット解析手段が、
前記第１の要求実行手段に渡すべき受信パケットについては第１のキューに格納し、前記第２の要求実行手段に渡すべき受信パケットについては第２のキューに格納し、
前記パケット処理手段が、
前記第１のキューに格納されている受信パケットを、前記第２のキューに格納されてい る受信パケットよりも優先して処理することを特徴とするデータ転送制御装置。 - 請求項２又は３において、
前記パケット破棄手段が、
処理した受信パケットが前記第１の要求実行手段のリセットを指示するパケットであった場合には、前記第１、第２のキューの両方をクリアすることを特徴とするデータ転送制御装置。 - 請求項２乃至４のいずれかにおいて、
前記第２の要求実行手段が、
上層のデバイスのコマンド制御要求を実行する第３の要求実行手段と、データ転送要求を実行する第４の要求実行手段とを含み、
前記パケット解析手段が、
前記第３の要求実行手段に渡すべき受信パケットについては第３のキューに格納し、前記第４の要求実行手段に渡すべき受信パケットについては第４のキューに格納し、
前記パケット処理手段が、
前記第３のキューに格納されている受信パケットを、前記第４のキューに格納されている受信パケットよりも優先して処理することを特徴とするデータ転送制御装置。 - バスに接続される複数のノード間でのデータ転送のためのデータ転送制御装置であって、
自ノードのデータバッファに書き込まれた受信パケットを解析し、解析した受信パケットをキューに格納し、データバッファ上の受信パケットが無くなるまで受信パケットの解析及びキューへの格納を繰り返すパケット解析手段と、
データバッファ上の受信パケットが無くなったところでキューに格納された受信パケットを処理するパケット処理手段と、
ノードのトポロジ情報をクリアするリセットが発生した場合には、前記リセットの発生前の受信パケットを破棄するパケット破棄手段とを含み、
前記パケット破棄手段が、
受信パケットがキューに格納される毎に前記リセットが発生したか否かを判断し、前記リセットが発生したと判断した場合には、前記リセット発生前の受信パケットが格納されているキューをクリアすることで、前記リセット発生前の受信パケットを破棄することを特徴とするデータ転送制御装置。 - 請求項６において、
前記パケット破棄手段が、
ノードのトポロジ情報をクリアするリセットが発生した場合には、受信パケットが格納されているキューをクリアすることを特徴とするデータ転送制御装置。 - 請求項６又は７において、
ノードのトポロジ情報をクリアする前記リセットが、ＩＥＥＥ１３９４の規格において定義されるバスリセットであることを特徴とするデータ転送制御装置。 - 請求項１乃至８のいずれかにおいて、
ＩＥＥＥ１３９４の規格に準拠したデータ転送を行うことを特徴とするデータ転送制御装置。 - 請求項１乃至９のいずれかのデータ転送制御装置と、
前記データ転送制御装置及びバスを介して相手ノードから受信したデータに所与の処理を施す装置と、
処理が施されたデータを出力又は記憶するための装置とを含むことを特徴とする電子機器。 - 請求項１乃至９のいずれかのデータ転送制御装置と、
前記データ転送制御装置及びバスを介して相手ノードに転送するデータに所与の処理を施す装置と、
処理が施されるデータを取り込むための装置とを含むことを特徴とする電子機器。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP37050199A JP3606145B2 (ja) | 1999-12-27 | 1999-12-27 | データ転送制御装置及び電子機器 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP37050199A JP3606145B2 (ja) | 1999-12-27 | 1999-12-27 | データ転送制御装置及び電子機器 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001186146A JP2001186146A (ja) | 2001-07-06 |
| JP3606145B2 true JP3606145B2 (ja) | 2005-01-05 |
Family
ID=18497077
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP37050199A Expired - Fee Related JP3606145B2 (ja) | 1999-12-27 | 1999-12-27 | データ転送制御装置及び電子機器 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3606145B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3671925B2 (ja) | 2002-03-20 | 2005-07-13 | セイコーエプソン株式会社 | データ転送制御装置、電子機器及びデータ転送制御方法 |
| GB2512214B (en) * | 2011-10-26 | 2020-10-07 | Intel Corp | Multi-touch interface schemes |
-
1999
- 1999-12-27 JP JP37050199A patent/JP3606145B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001186146A (ja) | 2001-07-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3843667B2 (ja) | データ転送制御装置及び電子機器 | |
| JP3608441B2 (ja) | データ転送制御装置及び電子機器 | |
| JP3584789B2 (ja) | データ転送制御装置及び電子機器 | |
| JP3598923B2 (ja) | データ転送制御装置、情報記憶媒体及び電子機器 | |
| US6937355B1 (en) | Data communications apparatus for resuming data transfer after interruption | |
| EP1033658B1 (en) | Communication apparatus with means for allocating alternate designation information to each function unit, and communication system with two such communication apparatus | |
| JP3606133B2 (ja) | データ転送制御装置及び電子機器 | |
| JP3539287B2 (ja) | データ転送制御装置及び電子機器 | |
| JP3494041B2 (ja) | データ転送制御装置及び電子機器 | |
| JP3606145B2 (ja) | データ転送制御装置及び電子機器 | |
| US6457072B1 (en) | System and method for effectively performing physical direct memory access operations | |
| JP3494042B2 (ja) | データ転送制御装置及び電子機器 | |
| JP3624767B2 (ja) | データ転送制御装置、情報記憶媒体及び電子機器 | |
| JP4627456B2 (ja) | 通信システム、サイクルマスタノード及び通信方法 | |
| JP3598924B2 (ja) | データ転送制御装置、情報記憶媒体及び電子機器 | |
| JP2003244277A (ja) | プロトコル変換によるデータ転送方法とシステムならびにプログラム | |
| JP3598922B2 (ja) | データ転送制御装置、情報記憶媒体及び電子機器 | |
| JP3610982B2 (ja) | データ転送制御装置及び電子機器 | |
| JP2003023471A (ja) | パケット送受信処理回路 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A871 | Explanation of circumstances concerning accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A871 Effective date: 20040312 |
|
| A975 | Report on accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A971005 Effective date: 20040409 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040622 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040820 |
|
| 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: 20040914 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040927 |
|
| 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: 20081015 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091015 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101015 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101015 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111015 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121015 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121015 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131015 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |