JP3584789B2 - データ転送制御装置及び電子機器 - Google Patents
データ転送制御装置及び電子機器 Download PDFInfo
- Publication number
- JP3584789B2 JP3584789B2 JP20124999A JP20124999A JP3584789B2 JP 3584789 B2 JP3584789 B2 JP 3584789B2 JP 20124999 A JP20124999 A JP 20124999A JP 20124999 A JP20124999 A JP 20124999A JP 3584789 B2 JP3584789 B2 JP 3584789B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- data
- header
- data transfer
- control device
- 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
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40052—High-speed IEEE 1394 serial bus
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
- H04L12/462—LAN interconnection over a bridge based backbone
- H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/64—Hybrid switching systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/64—Hybrid switching systems
- H04L12/6418—Hybrid transport
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Systems (AREA)
- Detection And Correction Of Errors (AREA)
- Small-Scale Networks (AREA)
- Communication Control (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、データ転送制御装置及びこれを含む電子機器に関し、特に、バスに接続される複数のノード間でＩＥＥＥ１３９４などの規格に準じたデータ転送を行うデータ転送制御装置及びこれを含む電子機器に関する。
【０００２】
【背景技術及び発明が解決しようとする課題】
近年、ＩＥＥＥ１３９４と呼ばれるインターフェース規格が脚光を浴びている。このＩＥＥＥ１３９４は、次世代のマルチメディアにも対応可能な高速シリアルバスインターフェースを規格化したものである。このＩＥＥＥ１３９４によれば、動画像などのリアルタイム性が要求されるデータも扱うことができる。また、ＩＥＥＥ１３９４のバスには、プリンタ、スキャナ、ＣＤ−ＲＷドライブ、ハードディスクドライブなどのコンピュータの周辺機器のみならず、ビデオカメラ、ＶＴＲ、ＴＶなどの家庭用電化製品も接続できる。このため、電子機器のデジタル化を飛躍的に促進できるものとして期待されている。
【０００３】
しかしながら、このＩＥＥＥ１３９４に準拠したデータ転送制御装置には次のような課題があることが判明した。
【０００４】
即ち、現在のＩＥＥＥ１３９４規格によれば最大で４００Ｍｂｐｓの転送速度が実現可能となっている。しかし、現実には、処理のオーバーヘッドの存在に起因して、システム全体の実転送速度はこれよりもかなり低くなっている。つまり、ＣＰＵ上で動作するファームウェアやアプリケーションソフトウェアが、送信データを準備したり、受信データを取り込んだりするなどの処理に多くの時間を要してしまい、バス上での転送速度が速くても、結局、高速なデータ転送を実現できない。
【０００５】
特に、周辺機器に組み込まれるＣＰＵは、パーソナルコンピュータなどのホストシステムに組み込まれるＣＰＵに比べて処理能力が低い。このため、ファームウェア等の処理のオーバーヘッドの問題は、非常に深刻なものとなる。従って、このようなオーバーヘッドの問題を効果的に解消できる技術が望まれている。
【０００６】
本発明は、以上のような技術的課題に鑑みてなされたものであり、その目的とするところは、ファームウェア等の処理のオーバーヘッドを軽減し、小規模なハードウェアで高速なデータ転送を実現できるデータ転送制御装置及びこれが用いられる電子機器を提供することにある。
【０００７】
【課題を解決するための手段】
上記課題を解決するために本発明は、バスに接続される複数のノード間でＩＥＥＥ１３９４の規格に準拠したデータ転送を行うためのデータ転送制御装置であって、ノード間でのパケット転送のためのサービスを提供するリンク回路と、前記リンク回路を介して受信したパケットを、ランダムアクセス可能なパケット記憶手段に書き込む書き込み回路とを含み、前記リンク回路が、他のノードから受信したパケットのヘッダに含まれるヘッダＣＲＣ又はトランザクションコードをチェックし、パケットのヘッダにＣＲＣエラーがあると判断した場合又はパケットのトランザクションコードが不知のコードであると判断した場合には、該パケットを無効にする処理を行うことを特徴とする。
【０００８】
本発明によれば、パケットのヘッダがＣＲＣエラーの場合やパケットのトランザクションコードが不知の場合には、そのパケットが無効になるように（破棄されるように）、リンク回路が処理を行う。これにより、そのパケットに対するファームウェア等の処理が不要になる。この結果、ファームウェアの処理負担を軽減でき、データ転送を高速化できる。
【０００９】
また本発明は、パケットのヘッダにＣＲＣエラーがあると判断した場合には、前記パケット記憶手段のヘッダ領域での受信済み位置を指すヘッダポインタを、１つ前のパケットの受信完了時に指していた位置に戻すことで、該パケットを無効にすることを特徴とする。このようにすれば、ヘッダの前半部分がパケット記憶手段に既に書き込まれてしまったような状況においても、ヘッダポインタを戻すという簡易な処理でパケットを無効にできるようになる。
【００１０】
また本発明は、ヘッダＣＲＣエラーが発生したことを示すステータス情報を記憶する手段を含むことを特徴とする。また本発明は、不知のコードのパケットを受信したことを示すステータス情報を記憶する手段を含むことを特徴とする。このようにすれば、もし仮にファームウェアが、ヘッダＣＲＣエラーの発生のステータスを知りたい場合や、不知のコードのパケットの受信のステータスを知りたい場合に、このステータスをファームウェアに伝えることができるようになる。
【００１１】
また本発明は、パケットのトランザクションコードが不知のコードであると判断した場合には、前記パケット記憶手段に該パケットを書き込まないようにすることで、該パケットを無効にすることを特徴とする。このようにすれば、そのパケットは存在しなかったことになり、ファームウェアの処理負担を軽減できる。
【００１２】
また本発明は、パケットのヘッダにＣＲＣエラーがあると判断した場合又はパケットのトランザクションコードが不知のコードであると判断した場合には、受信完了ステータスを不生成にすることを特徴とする。このようにすれば、ファームウェアの割り込み処理が不要になり、ファームウェアが無駄な処理を行うのを防止できる。
【００１３】
また本発明は、バスに接続される複数のノード間でＩＥＥＥ１３９４の規格に準拠したデータ転送を行うためのデータ転送制御装置であって、ノード間でのパケット転送のためのサービスを提供するリンク回路と、前記リンク回路を介して受信したパケットを、ランダムアクセス可能なパケット記憶手段に書き込む書き込み回路とを含み、前記リンク回路が、他のノードから受信したパケットのデータに含まれるデータＣＲＣをチェックし、パケットのデータにＣＲＣエラーがあると判断した場合には、該パケットのヘッダを有効にし、該パケットのデータを無効にする処理を行うことを特徴とする。
【００１４】
本発明によれば、データＣＲＣエラーの場合には、そのパケットのヘッダを有効にし、データだけが無効になるように、リンク回路が処理を行う。これにより、そのデータを読み出す等の処理が不要になり、ファームウェアの処理負担を軽減できる。また、ヘッダを無効にせずに残すことで、ファームウェアが、データＣＲＣエラー発生時用の処理を行うことができるようになる。
【００１５】
また本発明は、パケットのデータにＣＲＣエラーがあると判断した場合には、前記パケット記憶手段のヘッダ領域での受信済み位置を指すヘッダポインタについては戻さず、前記パケット記憶手段のデータ領域での受信済み位置を指すデータポインタを、１つ前のパケットの受信完了時に指していた位置に戻すことで、該パケットのデータを無効にすることを特徴とする。このようにすれば、データポインタを戻すという簡易な処理でパケットを無効にできるようになる。
【００１６】
また本発明は、バスに接続される複数のノード間でＩＥＥＥ１３９４の規格に準拠したデータ転送を行うためのデータ転送制御装置であって、ノード間でのパケット転送のためのサービスを提供するリンク回路と、前記リンク回路を介して受信したパケットを、ランダムアクセス可能なパケット記憶手段に書き込む書き込み回路と、受信したブロードキャストパケットを無効にする第１のモードと、受信したブロードキャストパケットを有効にする第２のモードとを設定するための手段とを含み、前記リンク回路が、他のノードから受信したパケットのヘッダに含まれるデスティネーションＩＤをチェックし、パケットがブロードキャストパケットであると判断し且つ前記第１のモードに設定されていた場合には、該パケットを無効にする処理を行うことを特徴とする。
【００１７】
本発明によれば、受信したブロードキャストパケットを無効にする第１のモードと、有効にする第２のモードのいずれで動作するかを選択できるようになり、データ転送制御装置の汎用性を高めることができる。そして、第１のモードに設定されている時にブロードキャストパケットを受信した場合には、そのパケットが無効になるように、リンク回路が処理を行う。これにより無駄な処理が行われるのを防止でき、データ転送の高速化を図れる。
【００１８】
また本発明は、パケットがブロードキャストパケットであると判断し且つ前記第１のモードに設定されていた場合には、前記パケット記憶手段に該パケットを書き込まないようにすることで、該パケットを無効にすることを特徴とする。このようにすれば、パケット記憶手段への書き込み処理が行われないようになり、無駄な処理が行われるのを防止できる。
【００１９】
また本発明に係る電子機器は、上記のいずれかのデータ転送制御装置と、前記データ転送制御装置及びバスを介して他のノードから受信したデータに所与の処理を施す装置と、処理が施されたデータを出力又は記憶するための装置とを含むことを特徴とする。また本発明に係る電子機器は、上記のいずれかのデータ転送制御装置と、前記データ転送制御装置及びバスを介して他のノードに送信するデータに所与の処理を施す装置と、処理が施されるデータを取り込むための装置とを含むことを特徴とする。
【００２０】
本発明によれば、他のノードから転送されたデータを電子機器において出力したり記憶したりする処理、電子機器において取り込んだデータを他のノードに転送したりする処理を高速化することが可能になる。また、本発明によれば、データ転送制御装置を小規模化できると共に、データ転送を制御するファームウェアなどの処理負担を軽減できるため、電子機器の低コスト化、小規模化などを図ることも可能になる。
【００２１】
【発明の実施の形態】
以下、本発明の好適な実施形態について図面を用いて詳細に説明する。
【００２２】
１．ＩＥＥＥ１３９４
まず、ＩＥＥＥ１３９４について簡単に説明する。
【００２３】
１．１ 概要
ＩＥＥＥ１３９４（ＩＥＥＥ１３９４−１９９５、Ｐ１３９４．ａ）では１００〜４００Ｍｂｐｓの高速なデータ転送が可能となっている（Ｐ１３９４．ｂでは８００〜３２００Ｍｂｐｓ）。また、転送速度が異なるノードをバスに接続することも許される。
【００２４】
各ノードはツリー状に接続されており、１つのバスに最大で６３個のノードが接続可能になっている。なお、バスブリッジを利用すれば約６４０００個のノードを接続することも可能である。
【００２５】
ＩＥＥＥ１３９４では、パケットの転送方式として非同期転送とアイソクロナス転送が用意されている。ここで非同期転送は、信頼性が要求されるデータの転送に好適な転送方式であり、アイソクロナス転送は、リアルタイム性が要求される動画像や音声などのデータの転送に好適な転送方式である。
【００２６】
１．２ 層構造
ＩＥＥＥ１３９４の層構造（プロトコル構成）を図１に示す。
【００２７】
ＩＥＥＥ１３９４のプロトコルは、トランザクション層、リンク層、物理層により構成される。また、シリアルバスマネージメントは、トランザクション層、リンク、物理層をモニターしたり制御したりするものであり、ノードの制御やバスのリソース管理のための種々の機能を提供する。
【００２８】
トランザクション層は、上位層にトランザクション単位のインターフェース（サービス）を提供し、下層のリンク層が提供するインターフェースを通して、リードトランザクション、ライトトランザクション、ロックトランザクション等のトランザクションを実施する。
【００２９】
ここで、リードトランザクションでは、応答ノードから要求ノードにデータが転送される。一方、ライトトランザクションでは、要求ノードから応答ノードにデータが転送される。またロックトランザクションでは、要求ノードから応答ノードにデータが転送され、応答ノードがそのデータに処理を施して要求ノードに返信する。
【００３０】
リンク層は、アドレッシング、データチェック、パケット送受信のためのデータフレーミング、アイソクロナス転送のためのサイクル制御などを提供する。
【００３１】
物理層は、リンク層により使用されるロジカルシンボルの電気信号への変換や、バスの調停や、バスの物理的インターフェースを提供する。
【００３２】
なお、図２に示すように、ＩＥＥＥ１３９４のトランザクション層の一部の機能を含む上位のプロトコルとして、ＳＢＰ−２（Ｓｅｒｉａｌ Ｂｕｓ Ｐｒｏｔｏｃｏｌ−２）と呼ばれるプロトコルが提案されている。
【００３３】
ここでＳＢＰ−２は、ＳＣＳＩのコマンドセットをＩＥＥＥ１３９４のプロトコル上で利用可能にするために提案されたものである。このＳＢＰ−２を用いれば、既存のＳＣＳＩ規格の電子機器で使用されていたＳＣＳＩのコマンドセットに最小限の変更を加えて、ＩＥＥＥ１３９４規格の電子機器に使用できるようになる。従って、電子機器の設計や開発を容易化できる。また、ＳＣＳＩのコマンドだけではなく、デバイス固有のコマンドもカプセル化して利用できるため、非常に汎用性が高い。
【００３４】
このＳＢＰ−２では、まず、イニシエータ（パーソナルコンピュータ等）が、ログインやフェッチ・エージェントの初期化のためのＯＲＢ（Ｏｐｅｒａｔｉｏｎ Ｒｅｑｕｅｓｔ Ｂｌｏｃｋ）を作成して、ターゲット（プリンタ、ＣＤ−ＲＷドライブ等）に送る。次に、イニシエータは、コマンド（リードコマンド、ライトコマンド）を含むＯＲＢ（コマンドブロックＯＲＢ）を作成して、その作成したＯＲＢのアドレスを、ターゲットに知らせる。そして、ターゲットは、そのアドレスをフェッチすることにより、イニシエータが作成したＯＲＢを取得する。ＯＲＢに含まれるコマンドがリードコマンドであった場合には、ターゲットは、ブロックライトトランザクションを発行して、イニシエータのデータバッファ（メモリ）にターゲットのデータを送信する。一方、ＯＲＢに含まれるコマンドがライトコマンドであった場合には、ターゲットは、ブロックリードトランザクションを発行して、イニシエータのデータバッファからデータを受信する。
【００３５】
このＳＢＰ−２によれば、ターゲットは、自身が都合の良いときにトランザクションを発行して、データを送受信できる。従って、イニシエータとターゲットが同期して動く必要がなくなるため、データ転送効率を高めることができる。
【００３６】
なお、ＩＥＥＥ１３９４の上位プロトコルとしては、ＳＢＰ−２以外にも、ＦＣＰ（Ｆｕｎｃｔｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）と呼ばれるプロトコルなども提案されている。
【００３７】
１．３ パケットフォーマット
図３に、ＩＥＥＥ１３９４規格の、非同期でブロックデータを有するパケットのフォーマットを示す。
【００３８】
図３において、ＤｅｓｔＩＤ（デスティネーションＩＤ）は送信先のノードを識別するためのＩＤであり、ｔｌは、トランザクションを識別するためのラベルである。ｒｔは、リトライのためのコードであり、ｔｃｏｄｅは、パケットのフォーマットやトランザクションのタイプを識別するためのコードである。ｐｒｉはプライオリティであり、ＳｏｕｒｃｅＩＤは送信元のノードを識別するためのＩＤである。
【００３９】
Ｈｅａｄｅｒ ＣＲＣはヘッダのＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）エラーを検出するためのコードであり、Ｄａｔａ ＣＲＣはデータのＣＲＣエラーを検出するためのコードである。ヘッダやデータに付加される冗長ビットであるこれらのＣＲＣをチェックすることで、ヘッダやデータの誤りを検出できるようになる。
【００４０】
１．４ ブロードキャスト
ＩＥＥＥ１３９４のアドレッシングは６４ビット幅になっており、その上位１６ビットがノードＩＤになっている。また、このノードＩＤの上位１０ビットが、バス識別のためのＢＵＳ＿ＩＤとなっており、下位６ビットがノード識別のためのＰＨＹ＿ＩＤになっている。そして、ＤｅｓｔＩＤのＰＨＹ＿ＩＤ（下位６ビット）が０ｘ３Ｆ（＝６３）になってるパケットはブロードキャストパケットと呼ばれ、このパケットは、バスに接続される全てのノードに対して配信されるようになる。
【００４１】
２．全体構成
次に、本実施形態のデータ転送制御装置の全体構成の例について図４を用いて説明する。
【００４２】
図４において、ＰＨＹインターフェース１０は、ＰＨＹデバイス（物理層のデバイス）とのインターフェースを行う回路である。
【００４３】
リンクコア２０（リンク回路）は、リンク層のプロトコルやトランザクション層のプロトコルの一部をハードウェアにより実現する回路であり、ノード間でのパケット転送のための各種サービスを提供する。レジスタ２２は、これらのプロトコルを実現したリンクコア２０を制御するためのレジスタである。
【００４４】
ＦＩＦＯ（ＡＴＦ）３０、ＦＩＦＯ（ＩＴＦ）３２、ＦＩＦＯ（ＲＦ）３４は、各々、非同期送信用、アイソクロナス送信用、受信用のＦＩＦＯであり、例えばレジスタや半導体メモリなどのハードウェアにより構成される。本実施形態では、これらのＦＩＦＯ３０、３２、３４の段数は非常に少ない。例えば１つのＦＩＦＯの段数は、好ましくは３段以下であり、更に好ましくは２段以下となる。
【００４５】
ＤＭＡＣ４０（読み出し回路）、ＤＭＡＣ４２（読み出し回路）、ＤＭＡＣ４４（書き込み回路）は、各々、ＡＴＦ用、ＩＴＦ用、ＲＦ用のＤＭＡコントローラである。これらのＤＭＡＣ４０、４２、４４を用いることで、ＣＰＵ６６に介入されることなく、ＲＡＭ８０とリンクコア２０との間でのデータ転送が可能になる。なお、レジスタ４６は、ＤＭＡＣ４０、４２、４４などを制御するレジスタである。
【００４６】
ポートインターフェース５０は、アプリケーション層のデバイス（例えばプリンタの印字処理を行うデバイス）とのインターフェースを行う回路である。本実施形態では、このポートインターフェース５０を用いて、例えば８ビットのデータ転送が可能になっている。
【００４７】
ＦＩＦＯ（ＰＦ）５２は、アプリケーション層のデバイスとの間でのデータ転送のためのＦＩＦＯであり、ＤＭＡＣ５４は、ＰＦ用のＤＭＡコントローラである。レジスタ５６は、ポートインターフェース５０やＤＭＡＣ５４を制御するレジスタである。
【００４８】
ＳＢＰ−２コア８４は、ＳＢＰ−２のプロトコルの一部をハードウェアにより実現する回路である。レジスタ８８は、ＳＢＰ−２コア８４を制御するためのレジスタである。ＤＭＡＣ（ＳＢＰ−２用）８６は、ＳＢＰ−２コア８４用のＤＭＡコントローラである。
【００４９】
ＲＡＭ領域管理回路３００は、ＲＡＭ８０の各領域を管理するための回路である。ＲＡＭ領域管理回路３００は、ＲＡＭ８０の各領域がフルになったり、エンプティになった場合に、各種のフル信号、エンプティ信号を用いてＤＭＡＣ４０、４２、４４、５４、８６を制御する。
【００５０】
ＣＰＵインターフェース６０は、データ転送制御装置をコントロールするＣＰＵ６６とのインターフェースを行う回路である。ＣＰＵインターフェース６０は、アドレスデコーダ６２、データ同期化回路６３、割り込みコントローラ６４を含む。クロック制御回路６８は、本実施形態で使用されるクロックを制御するものであり、ＰＨＹデバイス（ＰＨＹチップ）から送られてくるＳＣＬＫや、マスタークロックであるＨＣＬＫが入力される。
【００５１】
バッファマネージャ７０は、ＲＡＭ８０とのインターフェースを管理する回路である。バッファマネージャ７０は、バッファマネージャの制御のためのレジスタ７２、ＲＡＭ８０へのバス接続を調停する調停回路７４、各種の制御信号を生成するシーケンサ７６を含む。
【００５２】
ＲＡＭ８０は、ランダムアクセス可能なパケット記憶手段として機能するものであり、その機能は例えばＳＲＡＭ、ＳＤＲＡＭ、ＤＲＡＭなどにより実現される。
【００５３】
なおＲＡＭ８０は、本実施形態のデータ転送制御装置に内蔵させることが特に望ましいが、その一部又は全部を外付けにすることも可能である。
【００５４】
図５に、ＲＡＭ８０のメモリマップの一例を示す。図５に示すように本実施形態では、ＲＡＭ８０が、ヘッダ領域（ＡＲ２、ＡＲ３、ＡＲ４、ＡＲ６）とデータ領域（ＡＲ５、ＡＲ７、ＡＲ８、ＡＲ９）に分離されている。そして、パケットのヘッダ（広義には制御情報）はヘッダ領域に格納され、パケットのデータ（ＯＲＢ、ストリーム）はデータ領域に格納される。
【００５５】
また本実施形態では、図５に示すように、ＲＡＭ８０のデータ領域（ＡＲ５、ＡＲ７、ＡＲ８、ＡＲ９）が、ＯＲＢ領域（ＡＲ５、ＡＲ７）とストリーム領域（ＡＲ８、ＡＲ９）に分離されている。
【００５６】
更に本実施形態では、ＲＡＭ８０が、受信領域（ＡＲ２、ＡＲ４、ＡＲ５、ＡＲ９）と送信領域（ＡＲ３、ＡＲ６、ＡＲ７、ＡＲ８）に分離されている。
【００５７】
なお、ＯＲＢ（第１の層用の第１のデータ）は、上述したようにＳＢＰ−２用のデータ（コマンド）である。一方、ストリーム（第１の層より上層の第２の層用の第２のデータ）は、アプリケーション層用のデータ（プリンタの印字データ、ＣＤ−ＲＷの読み出し・書き込みデータ、スキャナによる取り込み画像データ等）である。
【００５８】
また、ＡＲ１、ＡＲ２、ＡＲ３に示すＨＷ（ハードウェア）用ページテーブル領域、ＨＷ用受信ヘッダ領域、ＨＷ用送信ヘッダ領域は、図４に示すＳＢＰ−２コア８４（ＳＢＰ−２をハードウェアにより実現する回路）が、ページテーブルや受信ヘッダや送信ヘッダを書き込んだり読み出したりするための領域である。
【００５９】
また、図５においてＡＲ４、ＡＲ５、ＡＲ８、ＡＲ９に示す領域は、いわゆるリングバッファ構造になっている。
【００６０】
さて、図４のバス９０（或いはバス９２、９４）は、アプリケーションに接続されるものである（第１のバス）。またバス９５（或いはバス９６）はデータ転送制御装置をコントロールし、或いはデータをリード・ライトするためのものであり、データ転送制御装置をコントロールするデバイス（例えばＣＰＵ）に電気的に接続される（第２のバス）。またバス１００（或いはバス１０２、１０４、１０５、１０６、１０７、１０８、１０９）は、物理層のデバイス（ＰＨＹデバイス）に電気的に接続されるものである（第３のバス）。また、バス１１０は、ランダムアクセス可能な記憶手段であるＲＡＭ８０に電気的に接続されるものである（第４のバス）。またバス９９は、ＳＢＰ−２コア８４がハードウェアによりＳＢＰ−２を実現するためのヘッダ情報やページテーブル情報をリード・ライトするためのものである（第５のバス）。
【００６１】
バッファマネージャ７０の調停回路７４は、ＤＭＡＣ４０、４２、４４、ＣＰＵインターフェース６０、ＤＭＡＣ８６、５４からのバスアクセス要求の調停を行う。そして、この調停結果に基づいて、各々、バス１０５、１０７、１０９、９６、９９、９４のいずれかと、ＲＡＭ８０のバス１１０との間にデータの経路が確立される（第１、第２、第３、第５のバスのいずれかと第４のバスとの間にデータ経路が確立される）。
【００６２】
本実施形態の１つの特徴は、ランダムアクセスが可能でありパケットを格納するＲＡＭ８０を設けると共に、互いに分離されるバス９０、９５、９９、１００と、これらのバスをＲＡＭ８０のバス１１０に接続するための調停回路７４とを設けた点にある。
【００６３】
例えば図６に、本実施形態と構成の異なるデータ転送制御装置の例を示す。このデータ転送制御装置では、リンクコア９０２は、ＰＨＹインターフェース９００、バス９２２を介してＰＨＹデバイスと接続される。また、リンクコア９０２は、ＦＩＦＯ９０４、９０６、９０８、ＣＰＵインターフェース９１０、バス９２０を介してＣＰＵ９１２に接続される。そして、ＣＰＵ９１２は、バス９２４を介して、ＣＰＵにローカルなメモリであるＲＡＭ９１４に接続される。
【００６４】
図６の構成のデータ転送制御装置を用いた場合のデータ転送の手法について図７を用いて説明する。ＰＨＹデバイス９３０を介して他のノードから送られてきた受信パケットは、バス９２２、データ転送制御装置９３２、バス９２０を介してＣＰＵ９１２が受け取る。そして、ＣＰＵ９１２は、受け取った受信パケットをバス９２４を介してＲＡＭ９１４に一旦書き込む。そして、ＣＰＵ９１２は、ＲＡＭ９１４に書き込まれた受信パケットをバス９２４を介して読み出し、アプリケーション層が使用できるように加工し、バス９２６を介してアプリケーション層のデバイス９３４に転送する。
【００６５】
一方、アプリケーション層のデバイス９３４からのデータを転送する場合には、ＣＰＵ９１２は、このデータをＲＡＭ９１４に書き込む。そして、ＲＡＭ９１４のデータにヘッダを付加することでＩＥＥＥ１３９４に準拠したパケットを生成する。そして生成されたパケットは、データ転送制御装置９３２、ＰＨＹデバイス９３０などを介して他のノードに送信される。
【００６６】
しかしながら、このような図７のデータ転送手法によると、ＣＰＵ９１２の処理負担が非常に重くなる。従って、ノード間を接続するシリアルバスの転送速度が高速になっても、ＣＰＵ９１２の処理のオーバーヘッドなどに起因して、システム全体の実転送速度は低くなり、結局、高速なデータ転送を実現できない。
【００６７】
これに対して、本実施形態では図８に示すように、データ転送制御装置１２０、アプリケーション層のデバイス１２４間のバス９０と、ＣＰＵバス９６と、データ転送制御装置１２０、ＲＡＭ８０間のバス１１０とが互いに分離されている。従って、ＣＰＵバス９６をデータ転送の制御のみに使用できるようになる。また、バス９０を占有して、データ転送制御装置１２０、アプリケーション層のデバイス１２４間でデータ転送を行うことができるようになる。例えば、データ転送制御装置１２０が組み込まれる電子機器がプリンタである場合には、バス９０を占有して印字データを転送できるようになる。この結果、ＣＰＵ６６の処理負担を軽減でき、システム全体の実転送速度を高めることができる。またＣＰＵ６６として安価なものを採用できると共に、ＣＰＵバス９６として高速なバスを使用する必要性がなくなる。このため、電子機器の低コスト化、小規模化を図れるようになる。
【００６８】
３． 詳細例
３．１ リンコア、ＦＩＦＯ、ＤＭＡＣの詳細な構成
図９に、リンクコア２０（リンク回路）、ＦＩＦＯ３４、ＤＭＡＣ４４（書き込み回路）の詳細な構成の一例を示す。
【００６９】
リンクコア２０は、バス監視回路１３０、直列・並列変換回路１３２、パケット整形回路１６０、レジスタ２２を含む。
【００７０】
ここでバス監視回路１３０は、ＰＨＹインターフェース１０を介してＰＨＹデバイスに接続される８ビット幅のデータバスＤ、２ビット幅のコントロールバスＣＴＬを監視する回路である。
【００７１】
直列・並列変換回路１３２は、データバスＤのデータを３２ビットのデータに変換する回路である。
【００７２】
パケット整形回路１６０は、各ノードから転送されてきたパケットを上層が使用できるように整形する回路である。例えば前述した図３は、ＩＥＥＥ１３９４規格の、非同期でブロックデータを有するパケットのフォーマットである。一方、図１０は、ＲＡＭ８０のヘッダ領域に格納される、非同期受信でブロックデータを有するパケットのヘッダ部分のフォーマットである。このように本実施形態では、図３のフォーマットのパケットを、ファームウェアなどの上層が使用できるように、図１０に示すフォーマットのパケットに整形している。
【００７３】
パケット整形回路１６０は、パケット診断回路１４２、シーケンサ１６７、バッファ１６８、セレクタ１７０を含み、パケット診断回路１４２は、ＴＡＧ生成回路１６２、ステータス生成回路１６４、エラーチェック回路１６６を含む。
【００７４】
ここでパケット診断回路１４２は、パケットの診断を行う回路である。ＴＡＧ生成回路１６２は、パケットのヘッダ、データ等を書き込む領域を区別するための情報であるＴＡＧを生成する回路であり、ステータス生成回路１６４は、パケットに付加する各種のステータスを生成する回路である。エラーチェック回路１６６は、パケットのエラーチェックを行う回路である。例えば、図３のパケットのＨｅａｄｅｒ ＣＲＣやＤａｔａ ＣＲＣのチェックを行う。また、エラーチェック回路１６６はＤｅｓｔＩＤやｔｃｏｄｅのチェックも行う。より具体的には、ＤｅｓｔＩＤをチェックすることで、受信したパケットがブロードキャストパケットか否かを判断し、ｔｃｏｄｅをチェックすることで、受信したパケットのｔｃｏｄｅが不知のコード（Ｕｎｋｔｃｏｄｅ）か否かを判断する。
【００７５】
シーケンサ１６７は各種の制御信号を生成するものである。バッファ１６８、セレクタ１７０は、直列・並列変換回路１３２からのＤＩ、パケット診断回路１４２からのステータス、ＤＭＡＣ４４からのデータポインタＤＰのいずれかを、パケット診断回路１４２からの信号ＳＥＬにより選択するためのものである。
【００７６】
レジスタ２２は、ヘッダＣＲＣエラーをファームウェアに伝えるためのレジスタ２３、不知のコード（Ｕｎｋｔｃｏｄｅ）のパケットを受信したことをファームウェアに伝えるためのレジスタ２４を含む。また、受信したブロードキャストパケットを無効にする第１のモード（破棄するモード）と、有効にする第２のモード（ファームウェアに渡すモード）とを設定するためのレジスタ２５を含む。
【００７７】
ＦＩＦＯ３４は、リンコア２０からの出力データであるＲＤの位相と、ＲＡＭ８０への書き込みデータであるＷＤＡＴＡの位相とを調整するためのバッファとして機能するものであり、ＦＩＦＯ状態判断回路３５を含む。ＦＩＦＯ状態判断回路３５は、ＦＩＦＯ３４が空になると、信号ＥＭＰＴＹをアクティブにし、ＦＩＦＯ３４がフルになると、信号ＦＵＬＬをアクティブにする。
【００７８】
ＤＭＡＣ４４は、パケット分離回路１８０、アクセス要求実行回路１９０、アクセス要求発生回路１９２を含む。
【００７９】
ここでパケット分離回路１８０は、パケット整形回路１６０により整形されたパケットをＴＡＧ（ＤＴＡＧ）に基づいてデータ、ヘッダ等に分離して、ＲＡＭの各領域（図５参照）に書き込む処理を行う。
【００８０】
アクセス要求実行回路１９０は、リンクコア２０からのアクセス要求を実行するための回路である。アクセス要求実行回路１９０は、ＦＩＦＯ状態判断回路３５からのＦＵＬＬがアクティブになると、ＦＦＵＬＬをアクティブにする。パケット整形回路１６０内のシーケンサ１６７は、ＦＦＵＬＬがアクティブでないことを条件に、ＲＤ（ＲｘＤａｔａ）のストローブ信号であるＲＤＳをアクティブにする。
【００８１】
なおＲＦＡＩＬは、受信における失敗を、シーケンサ１６７がアクセス要求実行回路１９０に対して知らせるための信号である。
【００８２】
アクセス要求発生回路１９２は、ＲＡＭ８０へのアクセス要求を発生するための回路である。アクセス要求発生回路１９２は、バッファマネージャ７０からの書き込みアクノリッジメントであるＷＡＣＫやＦＩＦＯ状態判断回路３５からのＥＭＰＴＹなどを受け、書き込み要求であるＷＲＥＱをバッファマネージャ７０に出力する。
【００８３】
３．２ パケットの分離及びＲＡＭの各領域への書き込み
ＴＡＧ生成回路１６２は、図１１に示すような４ビットのＴＡＧを生成している。そして、リンクコア２０は、パケット（図３参照）のスタート（最初の１クワドレット）、ヘッダ、データ（ＯＲＢ、ストリーム）をＲＤとしてＦＩＦＯ３４に出力する際に、この生成された４ビットのＴＡＧも同時にＦＩＦＯ３４に出力する。そして、本実施形態では、このＴＡＧを利用することで、パケットを分離し、ＲＡＭの各領域（図５参照）に書き込んでいる。
【００８４】
より具体的には、図９のＴＡＧ判別回路１８２が、ＦＩＦＯ３４から出力されるＤＴＡＧ（＝ＴＡＧ）を判別し、ＦＩＦＯ３４の出力ＷＤＡＴＡの書き込み領域を決める。そして、アドレス発生回路１８８が含むポインタ更新回路１８４が、この決められた領域において、ポインタ（データポインタ、ヘッダポインタ）を順次更新（インクリメント、デクリメント）する。そして、アドレス発生回路１８８は、この順次更新されるポインタが指すアドレスを発生して、ＷＡＤＲとしてバッファマネージャ７０に出力する。このようにすることで、パケットのヘッダ、ＯＲＢ、ストリームが、図５に示すようなＲＡＭの各領域に書き込まれるようになる。
【００８５】
なお、アドレス発生回路１８８は、データポインタＤＰ（受信ＯＲＢ領域のデータポインタ、受信ストリーム領域のデータポインタ等）をパケット整形回路１６０に出力しており、パケット整形回路１６０は、このデータポインタをパケットのヘッダに埋め込んでいる（図１０のＣ３０参照）。これにより、ヘッダ領域に格納されるヘッダとデータ領域に格納されるデータとを対応づけることが可能になる。
【００８６】
次に、図１１のＴＡＧ（ＤＴＡＧ）について説明する。図１１において、例えばＴＡＧが（０００１）、（００１０）であった場合には、受信パケットのヘッダ（ＦＩＦＯ３４の出力ＷＤＡＴＡ）が図５の受信ヘッダ領域へ書き込まれる。また、ＴＡＧが（０１００）であった場合には、受信パケットのデータが受信ＯＲＢ領域に書き込まれ、ＴＡＧが（０１０１）であった場合には、受信パケットのデータが受信ストリーム領域に書き込まれることになる。
【００８７】
また、ＴＡＧが（１００１）、（１０１０）であった場合には、受信パケットのヘッダがＨＷ（ハードウェア）用受信ヘッダ領域に書き込まれる。また、ＴＡＧが（１１００）であった場合には、受信パケットのデータがＨＷ用受信ＯＲＢ領域に書き込まれ、ＴＡＧが（１１０１）であった場合には、受信パケットのデータがＨＷ用受信ストリーム領域に書き込まれることになる。なお、ここでＨＷ（ハードウェア）用とは、図４のＳＢＰ−２コア８４用という意味である。
【００８８】
３．３ 通常受信動作
次に、図１２のタイミング波形図を用いて、通常時の受信動作について説明する。
【００８９】
図９の直列・並列変換回路１３２は、データバスＤからの８ビットのデータを３２ビットのデータに変換して、図１２に示すようにＤＩとして出力する。また、ＤＩのデータが有効か否かを示す信号ＤＩＥや、ＤＩの取り込みタイミングを決めるストローブ信号ＤＩＳも出力する。なお、図１２において、ＤＩのＨ１、Ｈ２、Ｈ３、Ｈ４は、各々、図３のヘッダの第１、第２、第３、第４クワドレットである。また、ＨＣＲＣは、図３のＨｅａｄｅｒ ＣＲＣである（第５クワドレット）。また、Ｄ１、Ｄ２・・・はデータであり（ここではＯＲＢデータ）、ＤＣＲＣは図３のＤａｔａ ＣＲＣである。
【００９０】
図９のエラーチェック回路１６６は、ＤＩの中のＨＣＲＣに基づいて、ヘッダＣＲＣエラーがあるか否かを判断し、ヘッダＣＲＣエラーではない場合には、図１２のＥ１に示すように信号ＨＣＲＣＯＫをアクティブにする。
【００９１】
また、エラーチェック回路１６６は、ＤＩの中のＤＣＲＣに基づいてデータＣＲＣエラーがあるか否かをチェックし、データＣＲＣエラーではない場合には、Ｅ２に示すように信号ＤＣＲＣＯＫをアクティブにする。
【００９２】
バッファ１６８及びセレクタ１７０は、パケット診断回路１４２からのステータス、直列・並列変換回路１３２からのＤＩ、パケット分離回路１８０からのデータポインタＤＰを受け、これらのいずれかを選択してＲＤとしてＦＩＦＯ３４に出力する。例えば図１２のＥ３ではデータポインタＤＰが選択されて、ＲＤとして出力されている。
【００９３】
ＴＡＧ生成回路１６２は、図１１で説明したＴＡＧを生成し、このＴＡＧを、ＲＤの出力に同期させてＦＩＦＯ３４に出力する。また、シーケンサ１６７は、上記のＲＤ及びＴＡＧのストローブ信号ＲＤＳを、ＦＩＦＯ３４に出力する。
【００９４】
ＦＩＦＯ３４は、ＴＡＧ、ＲＤ、ＲＤＳを受け、ＤＴＡＧ、ＷＤＡＴＡを出力する。このＷＤＡＴＡは、バッファマネジャ７０からのＷＡＣＫがアクティブになったことを条件に、ＲＡＭ８０に書き込まれる。即ち、ＲＡＭ８０への書き込み要求ＷＲＥＱは、図４の調停回路７４によりアービトレーションされるため、ＲＤの出力タイミングとＷＲＥＱ及びＷＡＣＫの出力タイミングは同期しない。
【００９５】
パケットの受信が完了すると、ＩＥＥＥ１３９４のバス上での調停に勝ったことを条件に、相手ノードに対してＡＣＫ（ＡＣＫパケット）が返送される。そして、相手ノードに対して返送したＡＣＫの内容が、Ｅ４に示すフッターＦＴＲ（ステータス生成回路１６４により生成されるステータス）の中に挿入される。
【００９６】
フッターＦＴＲがＲＡＭ８０に書き込まれると、Ｅ５に示すようにＩＮＴＲＸＣＯＭＰイベントの信号がアクティブになる。このＩＮＴＲＸＣＯＭＰは、図４の割り込みコントローラ６４に入力される。これにより、ＣＰＵ６６上で動作するファームウェアに対して、受信の完了が知らされる。そして、割り込みを受けたファームウェアは、ＲＡＭ８０のヘッダ領域、データ領域に格納されるヘッダ、データを読みに行く。
【００９７】
３．４ ヘッダＣＲＣエラー
図１３に、ヘッダＣＲＣエラーが検出された場合のタイミング波形図を示す。本実施形態では、パケットのヘッダにＣＲＣエラーがあった場合には、そのパケットがファームウェアに伝わらないように、そのパケットを無効にしている。
【００９８】
エラーチェック回路１６６によりヘッダＣＲＣエラーが検出されると、図１３のＥ１０に示すタイミングで、ＨＣＲＣＯＫがＨレベル（アクティブ）に変化せず、Ｌレベル（非アクティブ）のままとなる。すると、Ｅ１１に示すように、ストローブ信号ＲＤＳがＬレベル（非アクティブ）に固定され、ＲＡＭ８０へのパケットの書き込み処理が中断される。また、Ｅ１２に示すように、ヘッダポインタをクリアする信号ＨＰＣＬＲがアクティブになる。また、Ｅ１３に示すように、ＩＮＴＲＸＣＯＭＰイベントも発生しない。
【００９９】
信号ＨＰＣＬＲは、図９に示すようにアドレス発生回路１８８に入力される。そして、ＨＰＣＬＲがアクティブになると、アドレス発生回路１８８のポインタ更新回路１８４が、図１４に示すように、ヘッダポインタＨＰ（ヘッダ領域での受信済み位置を指すポインタ）を、前のパケットの受信完了時にＨＰが指していた位置に戻す。これにより、ヘッダＣＲＣエラーが検出されたヘッダ（ヘッダ３）は存在しなかったことになる。
【０１００】
即ち、ヘッダＣＲＣエラーが検出されても、その解析は不可能であるため、そのヘッダをファームウェアに渡しても無意味である。そこで、本実施形態では、ファームウェアの処理負担を軽減するために、ヘッダＣＲＣエラーが検出された場合に、そのヘッダを無効にし、ファームウェアに伝わらないようしている。例えば図１３のＥ１３に示すように、ヘッダＣＲＣエラーの時には、受信完了のＩＮＴＲＸＣＯＭＰイベントが発生せず、これに起因するＣＰＵへの割り込みも発生しない。このため、パケットを受信した事実もファームウェアに伝えられない。また、図１４に示すようにヘッダポインタＨＰが前の位置に戻るため、ヘッダＣＲＣエラーが検出されたヘッダは、ファームウェアにとって存在しなかったことになる。これにより受信処理に関わるファームウェアの処理を簡素化でき、装置の小規模化を図れる。また、ヘッダＣＲＣエラーが発生した場合の処理に要する時間を節約でき、データ転送の高速化を図れる。
【０１０１】
なお、図６のようにパケット記憶手段としてＲＡＭではなくＦＩＦＯを用いる構成では、ヘッダＣＲＣエラーが検出された時点で既にＦＩＦＯに入力されてしまったヘッダの第１〜第４クワドレットについては、無効にすることができない。従って、ファームウェアは、このパケットを受け取らざるを得ない。従って、ファームウェアの処理負担を軽減できない。
【０１０２】
これに対して、本実施形態では、パケット記憶手段として、ランダムアクセス可能なＲＡＭ８０を用いている。従って、例えば図１４に示すようにヘッダポインタを前の位置に戻すこと等により、パケットを無効にできるようになる。この結果、ファームウェアはこのパケットを受け取る必要がなくなり、ファームウェアの処理負担を軽減できる。
【０１０３】
なお、本実施形態では、ヘッダＣＲＣエラーが検出された場合に、ヘッダＣＲＣエラーが検出されたことを示すステータスＨＣＥを、図９のレジスタ２３（ファームウェアが読み出し可能なレジスタ）に書き込むようにしている。このようにすれば、もし仮にファームウェアが、ヘッダＣＲＣエラー検出のステータスＨＣＥを必要とする場合には、このステータスをファームウェアに伝えることが可能になる。
【０１０４】
３．５ Ｕｎｋｔｃｏｄｅ
図１５に、ｔｃｏｄｅが不知のコード（Ｕｎｋｔｃｏｄｅ）であった場合のタイミング波形図を示す。本実施形態では、ｔｃｏｄｅがＵｎｋｔｃｏｄｅであると判断した場合には、そのパケットがファームウェアに伝わらないように、そのパケットを無効にしている。
【０１０５】
即ち、図１５のＥ２０に示すように、ヘッダの第１クワドレットでエラーチェック回路１６６がＵｎｋｔｃｏｄｅを検出すると、Ｅ２１に示すように、ストローブ信号ＲＤＳがＬレベル（非アクティブ）に固定される。これにより、パケットがＲＡＭ８０に書き込まれないようになる。つまり、他ノード宛のパケットと同様の取り扱いになる。また、Ｅ２２に示すように、ＩＮＴＲＸＣＯＭＰイベントも発生しない。
【０１０６】
即ち、Ｕｎｋｔｃｏｄｅが検出された場合、そのパケットのｔｄｏｄｅは不明となる。そして、ｔｃｏｄｅが不明の場合には、ヘッダのサイズもわからず、Ｈｅａｄｅｒ ＣＲＣの位置もわからない。従って、Ｕｎｋｔｃｏｄｅの検出後の処理は全て無意味であり、そのヘッダをファームウェアに渡す必要はない。そこで、本実施形態では、ファームウェアの処理負担を軽減するために、Ｕｎｋｔｃｏｄｅが検出された場合に、そのヘッダがＲＡＭに書き込まれないようにしている。これにより、Ｕｎｋｔｃｏｄｅに関するファームウェアの処理が不要になり、データ転送の高速化を図れる。
【０１０７】
なお、本実施形態では、不知のコードのパケットを受信したことを示すステータスＵＮＫを、図９のレジスタ２４（ファームウェアが読み出し可能なレジスタ）に書き込むようにしている。このようにすれば、もし仮にファームウェアが、不知のコードのパケットの受信のステータスＵＮＫを必要とする場合には、このステータスをファームウェアに伝えることが可能になる。
【０１０８】
３．６ データＣＲＣエラー
図１６に、データＣＲＣエラーが検出された場合のタイミング波形図を示す。本実施形態では、データＣＲＣエラーが検出された場合に、そのパケットのヘッダを有効にし、そのパケットのデータを無効にしている。
【０１０９】
エラーチェック回路１６６によりデータＣＲＣエラーが検出されると、図１６のＥ３０に示すタイミングで、ＤＣＲＣＯＫがＨレベルに変化せず、Ｌレベル（非アクティブ）のままとなる。すると、Ｅ３１に示すように、データポインタをクリアする信号ＤＰＣＬＲがアクティブになる。
【０１１０】
なお、この場合には、Ｅ３２に示すように、ＩＮＴＲＸＣＯＭＰイベントが発生する。また、相手ノードにはＡＣＫデータエラーのパケットが返信される（Ｅ３３のフッターＦＴＲには、ＡＣＫデータエラーを返信したことを示す情報が挿入される）。
【０１１１】
信号ＤＰＣＬＲは、図９に示すようにアドレス発生回路１８８に入力される。そして、ＤＰＣＬＲがアクティブになると、アドレス発生回路１８８のポインタ更新回路１８４が、図１７に示すようにデータポインタＤＰ（データ領域での受信済み位置を指すポインタ）を、前のパケットの受信完了時にＤＰが指していた位置に戻す。これにより、データＣＲＣエラーが検出されたパケットのデータ（データ３）は存在しなかったことになる。
【０１１２】
一方、図１４の場合と異なり、図１７では、ヘッダポインタＨＰは変化せず、ヘッダ（ヘッダ３）は残る。従って、ファームウェアはそのヘッダ３を読み出すことができるようになる。
【０１１３】
即ち、データＣＲＣエラーの場合には、そのデータについては解析が不可能であるため、そのデータをファームウェアに渡しても無意味である。従って、図１７に示すようにデータポインタＤＰを前の位置に戻すことで、データＣＲＣエラーが検出されたパケットのデータについては破棄する。このようにすれば、データポインタとデータ長に基づくアドレス計算が不要になり、ファームウェアの処理負担を軽減できる。
【０１１４】
一方、ヘッダについてはファームウェアが使用する可能性もあるので、破棄せずに残すようにする。データＣＲＣエラーの場合には、パケットを再送させるためのトランザクションを発行する等の処理が必要になるかもしれず、そのためにはデータＣＲＣエラーが生じたパケットのヘッダをファームウェアが解析できるようにする必要があるからである。即ち、ファームウェアは、このヘッダを解析することで、データＣＲＣエラーが生じたパケットのＳｏｕｒｃｅＩＤ、ｔｃｏｄｅ、トランザクションラベルｔｌなどを知ることができるようになる。この結果、ファームウェアは、データＣＲＣエラー発生時用のトランザクション処理を適正に実行できるようになる。
【０１１５】
３．７ ブロードキャストパケット
さて、図２で説明したＳＢＰ−２と呼ばれるプロトコルでは、基本的にブロードキャストパケットは用いない。ＳＢＰ−２では、イニシエータとターゲットの間でピア・ツー・ピア（ｐｅｅｒ ｔｏ ｐｅｅｒ）でデータ転送が行われるからである。
【０１１６】
従って、ＳＢＰ−２に特化したデータ転送制御装置にする場合には、ファームウェアの処理負担を軽減するために、ブロードキャストパケットの受信を無効にできることが望まれる。
【０１１７】
そこで本実施形態では、受信したブロードキャストパケットを無効にする第１のモード（ブロードキャストパケットを破棄するモード）と、有効にする第２のモード（ファームウェアに渡すモード）とを、図９のレジスタ２５を用いて設定できるようにしている（ファームウェアが設定する）。
【０１１８】
図１８に、第１のモードでブロードキャストパケットを受信した場合のタイミング波形図を示す。本実施形態では、第１のモードでブロードキャストパケットを受信した場合には、そのパケットがファームウェアに伝わらないように、そのパケットを無効にしている。
【０１１９】
即ち図１８のＥ４０に示すように、ヘッダの第１クワドレットで、エラーチェック回路１６６が、受信パケットがブロードキャストパケットか否かをＤｅｓｔＩＤに基づき判断する。そして、ブロードキャストであると判断された場合（０ｘ３Ｆである場合）には、Ｅ４１に示すように、ストローブ信号ＲＤＳがＬレベル（非アクティブ）に固定される。これにより、パケットがＲＡＭ８０に書き込まれないようになる。つまり、他ノード宛のパケットと同様の取り扱いになる。また、Ｅ４２に示すように、ＩＮＴＲＸＣＯＭＰイベントも発生しない。これにより、受信したブロードキャストパケットは存在しなかったものと見なされ、ブロードキャストに関するファームウェアの処理が不要になる。従って、ＳＢＰ−２に特化したデータ転送制御装置のデータ転送の高速化を図れるようになる。
【０１２０】
なお、ブロードキャストパケットを有効にする第２のモードでブロードキャストパケットを受信した場合には、図１２で説明した通常受信動作になる。
【０１２１】
３．８ ファームウェアの処理
次に、本実施形態の手法により、ファームウェアの処理が如何に軽減されるかについて説明する。
【０１２２】
図１９（Ａ）は、本実施形態の手法を用いない比較例において、ファームウェアが行う処理について示すフローチャートであり、図１９（Ｂ）は、本実施形態において、ファームウェアが行う処理について示すフローチャートである。
【０１２３】
まず、ヘッダを記憶手段から読み出す（ステップＳ１）。そして、ヘッダに含まれるｔｃｏｄｅを解析し、不知のｔｃｏｄｅであれば処理を終了する（ステップＳ２、Ｓ３）。次に、ヘッダに含まれるＨｅａｄｅｒ ＣＲＣを解析し、ヘッダＣＲＣエラーであれば処理を終了する（ステップＳ４、Ｓ５）。そして、ヘッダに含まれるＤｅｓｔＩＤを解析し、受信したパケットがブロードキャストパケットであれば処理を終了する（ステップＳ６、Ｓ７）。次に、パケット処理に移行する（ステップＳ８）。
【０１２４】
一方、本実施形態によれば、図１９（Ｂ）に示すように、ファームウェアは、ヘッダを読み出した後、直ぐにパケット処理に移行できる（ステップＳ１１、Ｓ１２）。即ち、図１９（Ａ）のステップＳ２〜Ｓ７の処理が不要になる。これにより、ファームウェアの処理負担を格段に軽減でき、データ転送を高速化できる。
【０１２５】
図２０（Ａ）は、比較例において、ファームウェアが行うパケット処理について示すフローチャートであり、図２０（Ｂ）は、本実施形態において、ファームウェアが行うパケット処理について示すフローチャートである。
【０１２６】
図２０（Ａ）の比較例では、まず、ファームウェアが、Ｄａｔａ ＣＲＣを解析し、データＣＲＣエラーか否かを判断する（ステップＳ２１、Ｓ２２）。そして、データＣＲＣエラーではない場合には、読み出したデータを、後段のアプリケーション層のデバイスに渡し、トランザクション処理に移行する（ステップＳ２３、Ｓ２５）。一方、データＣＲＣエラーである場合には、そのパケットのデータを破棄し、トランザクション処理に移行する（ステップＳ２４、Ｓ２５）
図２０（Ｂ）の本実施形態では、まず、ファームウェアが、受信パケットのヘッダ（フッターＦＴＲ）に含まれるＡＣＫを解析し、データＣＲＣエラーか否かを判断する（ステップＳ３１、Ｓ３２）。そして、データＣＲＣエラーではない場合には、読み出したデータを、後段のアプリケーション層のデバイスに渡し、トランザクション処理に移行する（ステップＳ３３、Ｓ３４）。一方、データＣＲＣエラーである場合には、そのまま、トランザクション処理に移行する（ステップＳ３５）。
【０１２７】
このように、本実施形態によれば、図２０（Ａ）のステップＳ２４のデータを破棄する処理が不要になる。このデータを破棄する処理は、例えば、データポインタとデータ長に基づくアドレス計算などが必要になり、負荷が重い。本実施形態によれば、このようなアドレス計算が不要になるため、ファームウェアの処理負担を格段に軽減できる。
【０１２８】
４．電子機器
次に、本実施形態のデータ転送制御装置を含む電子機器の例について説明する。
【０１２９】
例えば図２１（Ａ）に電子機器の１つであるプリンタの内部ブロック図を示し、図２２（Ａ）にその外観図を示す。ＣＰＵ（マイクロコンピュータ）５１０はシステム全体の制御などを行う。操作部５１１はプリンタをユーザが操作するためのものである。ＲＯＭ５１６には、制御プログラム、フォントなどが格納され、ＲＡＭ５１８はＣＰＵ５１０のワーク領域として機能する。表示パネル５１９はプリンタの動作状態をユーザに知らせるためのものである。
【０１３０】
ＰＨＹデバイス５０２、データ転送制御装置５００を介して、パーソナルコンピュータなどの他のノードから送られてきた印字データは、バス５０４を介して印字処理部５１２に直接送られる。そして、印字データは、印字処理部５１２にて所与の処理が施され、プリントヘッダなどからなる印字部（データを出力するための装置）５１４により紙に印字されて出力される。
【０１３１】
図２１（Ｂ）に電子機器の１つであるスキャナの内部ブロック図を示し、図２２（Ｂ）にその外観図を示す。ＣＰＵ５２０はシステム全体の制御などを行う。操作部５２１はスキャナをユーザが操作するためのものである。ＲＯＭ５２６には制御プログラムなどが格納され、ＲＡＭ５２８はＣＰＵ５２０のワーク領域として機能する。
【０１３２】
光源、光電変換器などからなる画像読み取り部（データを取り込むための装置）５２２により原稿の画像が読み取られ、読み取られた画像のデータは画像処理部５２４により処理される。そして、処理後の画像データがバス５０５を介してデータ転送制御装置５００に直接送られる。データ転送制御装置５００は、この画像データにヘッダなどを付加することでパケットを生成し、ＰＨＹデバイス５０２を介してパーソナルコンピュータなどの他のノードに送信する。
【０１３３】
図２１（Ｃ）に電子機器の１つであるＣＤ−ＲＷドライブの内部ブロック図を示し、図２２（Ｃ）にその外観図を示す。ＣＰＵ５３０はシステム全体の制御などを行う。操作部５３１はＣＤ−ＲＷをユーザが操作するためのものである。ＲＯＭ５３６には制御プログラムなどが格納され、ＲＡＭ５３８はＣＰＵ５３０のワーク領域として機能する。
【０１３４】
レーザ、モータ、光学系などからなる読み取り＆書き込み部（データを取り込むための装置又はデータを記憶するための装置）５３３によりＣＤ−ＲＷ５３２から読み取られたデータは、信号処理部５３４に入力され、エラー訂正処理などの所与の信号処理が施される。そして、信号処理が施されたデータが、バス５０６を介してデータ転送制御装置５００に直接送られる。データ転送制御装置５００は、このデータにヘッダなどを付加することでパケットを生成し、ＰＨＹデバイス５０２を介してパーソナルコンピュータなどの他のノードに送信する。
【０１３５】
一方、ＰＨＹデバイス５０２、データ転送制御装置５００を介して、他のノードから送られてきたデータは、バス５０６を介して信号処理部５３４に直接送られる。そして、信号処理部５３４によりこのデータに所与の信号処理が施され、読み取り＆書き込み部５３３によりＣＤ−ＲＷ５３２に記憶される。
【０１３６】
なお、図２２（Ａ）、（Ｂ）、（Ｃ）において、ＣＰＵ５１０、５２０、５３０の他に、データ転送制御装置５００でのデータ転送制御のためのＣＰＵを別に設けるようにしてもよい。
【０１３７】
また、図２２（Ａ）、（Ｂ）、（Ｃ）ではＲＡＭ５０１（図４のＲＡＭ８０に相当）がデータ転送制御装置５００の外部に設けられているが、ＲＡＭ５０１をデータ転送制御装置５００に内蔵させてもよい。
【０１３８】
本実施形態のデータ転送制御装置を電子機器に用いることで、高速なデータ転送が可能になる。従って、ユーザがパーソナルコンピュータなどによりプリントアウトの指示を行った場合に、少ないタイムラグで印字が完了するようになる。また、スキャナへの画像取り込みの指示の後に、少ないタイムラグで読み取り画像をユーザは見ることができるようになる。また、ＣＤ−ＲＷからのデータの読み取りや、ＣＤ−ＲＷへのデータの書き込みを高速に行うことができるようになる。更に、例えば１つのホストシステムに複数の電子機器を接続して利用したり、複数のホストシステムに複数の電子機器を接続して利用したりすることも容易になる。
【０１３９】
また本実施形態のデータ転送制御装置を電子機器に用いることで、ＣＰＵ上で動作するファームウェアの処理負担が軽減され、安価なＣＰＵや低速のバスを用いることが可能になる。更に、データ転送制御装置の低コスト化、小規模化を図れるため、電子機器の低コスト化、小規模化も図れるようになる。
【０１４０】
なお本実施形態のデータ転送制御装置を適用できる電子機器としては、上記以外にも例えば、種々の光ディスクドライブ（ＣＤ−ＲＯＭ、ＤＶＤ）、光磁気ディスクドライブ（ＭＯ）、ハードディスクドライブ、ＴＶ、ＶＴＲ、ビデオカメラ、オーディオ機器、電話機、プロジェクタ、パーソナルコンピュータ、電子手帳、ワードプロセッサなど種々のものを考えることができる。
【０１４１】
なお、本発明は本実施形態に限定されず、本発明の要旨の範囲内で種々の変形実施が可能である。
【０１４２】
例えば、本発明のデータ転送制御装置の構成は、図４に示す構成が特に望ましいが、これに限定されるものではない。
【０１４３】
また、パケットのヘッダやデータを無効にする手法は、本実施形態で説明したものが特に望ましいが、これに限定されるものではない。
【０１４４】
また、本発明は、少なくともＩＥＥＥ１３９４の思想に基づくものであれば、ＩＥＥＥ１３９４を発展させた規格におけるデータ転送にも適用できる。
【図面の簡単な説明】
【図１】ＩＥＥＥ１３９４の層構造について示す図である。
【図２】ＳＢＰ−２について説明するための図である。
【図３】ＩＥＥＥ１３９４規格の、非同期でブロックデータを有するパケットのフォーマットである。
【図４】本実施形態のデータ転送制御装置の構成例を示す図である。
【図５】ＲＡＭ（パケット記憶手段）の分離（分割）手法について説明するための図である。
【図６】比較例の構成について示す図である。
【図７】図６の構成によるデータ転送の手法について説明するための図である。
【図８】本実施形態のデータ転送の手法について説明するための図である。
【図９】リンクコア、ＤＭＡＣ、ＦＩＦＯの詳細な構成例について示す図である。
【図１０】ＲＡＭに格納される、非同期受信でブロックデータを有するパケットのヘッダ部分のフォーマットである。
【図１１】ＴＡＧについて説明するための図である。
【図１２】通常時の受信動作について説明するためのタイミング波形図である。
【図１３】ヘッダＣＲＣエラーの時の受信動作について説明するためのタイミング波形図である。
【図１４】ヘッダＣＲＣエラーの時にヘッダポインタを前の位置に戻す手法について説明するための図である。
【図１５】Ｕｎｋｔｃｏｄｅの時の受信動作について説明するためのタイミング波形図である。
【図１６】データＣＲＣエラーの時の受信動作について説明するためのタイミング波形図である。
【図１７】データＣＲＣエラーの時にデータポインタを前の位置に戻す手法について説明するための図である。
【図１８】第１のモードでブロードキャストパケットを受信した時の動作について説明するためのタイミング波形図である。
【図１９】図１９（Ａ）、（Ｂ）は、比較例及び本実施形態においてファームウェアが行う処理について示すフローチャートである。
【図２０】図２０（Ａ）、（Ｂ）も、比較例及び本実施形態においてファームウェアが行う処理について示すフローチャートである。
【図２１】図２１（Ａ）、（Ｂ）、（Ｃ）は、種々の電子機器の内部ブロック図の例である。
【図２２】図２２（Ａ）、（Ｂ）、（Ｃ）は、種々の電子機器の外観図の例である。
【符号の説明】
１０ ＰＨＹインターフェース
２０ リンクコア
２２ レジスタ
２３ ＨＣＥレジスタ
２４ ＵＮＫレジスタ
２５ ＢＣレジスタ
３０ ＦＩＦＯ（ＡＴＦ）
３２ ＦＩＦＯ（ＩＴＦ）
３４ ＦＩＦＯ（ＲＦ）
４０ ＤＭＡＣ（ＡＴＦ用）
４２ ＤＭＡＣ（ＩＴＦ用）
４４ ＤＭＡＣ（ＲＦ用）
４６ レジスタ
５０ ポートインターフェース
５２ ＦＩＦＯ（ＰＦ）
５４ ＤＭＡＣ（ＰＦ用）
５６ レジスタ
６０ ＣＰＵインターフェース
６２ アドレスデコーダ
６３ データ同期化回路
６４ 割り込みコントローラ
６６ ＣＰＵ
６８ クロック制御回路
７０ バッファマネージャ
７２ レジスタ
７４ 調停回路
７６ シーケンサ
８０ ＲＡＭ（パケット記憶手段）
８４ ＳＢＰ−２コア
８６ ＤＭＡＣ（ＳＢＰ−２用）
９０、９２、９４ バス（第１のバス）
９５、９６ バス（第２のバス）
９９ バス（第５のバス）
１００、１０２、１０４、１０５、
１０６、１０７、１０８、１０９ バス（第３のバス）
１１０ バス（第４のバス）
１２０ データ転送制御装置
１２２ ＰＨＹデバイス
１２４ アプリケーション層のデバイス
１３０ バス監視回路
１３２ 直列・並列変換回路
１４２ パケット診断回路
１６０ パケット整形回路
１６２ ＴＡＧ生成回路
１６４ ステータス生成回路
１６６ エラーチェック回路
１６７ シーケンサ
１６８ バッファ
１７０ セレクタ
１８０ パケット分離回路
１８２ ＴＡＧ判別回路
１８４ ポインタ更新回路
１８８ アドレス発生回路
１９０ アクセス要求実行回路
１９２ アドレス要求発生回路
３００ ＲＡＭ領域管理回路
【発明の属する技術分野】
本発明は、データ転送制御装置及びこれを含む電子機器に関し、特に、バスに接続される複数のノード間でＩＥＥＥ１３９４などの規格に準じたデータ転送を行うデータ転送制御装置及びこれを含む電子機器に関する。
【０００２】
【背景技術及び発明が解決しようとする課題】
近年、ＩＥＥＥ１３９４と呼ばれるインターフェース規格が脚光を浴びている。このＩＥＥＥ１３９４は、次世代のマルチメディアにも対応可能な高速シリアルバスインターフェースを規格化したものである。このＩＥＥＥ１３９４によれば、動画像などのリアルタイム性が要求されるデータも扱うことができる。また、ＩＥＥＥ１３９４のバスには、プリンタ、スキャナ、ＣＤ−ＲＷドライブ、ハードディスクドライブなどのコンピュータの周辺機器のみならず、ビデオカメラ、ＶＴＲ、ＴＶなどの家庭用電化製品も接続できる。このため、電子機器のデジタル化を飛躍的に促進できるものとして期待されている。
【０００３】
しかしながら、このＩＥＥＥ１３９４に準拠したデータ転送制御装置には次のような課題があることが判明した。
【０００４】
即ち、現在のＩＥＥＥ１３９４規格によれば最大で４００Ｍｂｐｓの転送速度が実現可能となっている。しかし、現実には、処理のオーバーヘッドの存在に起因して、システム全体の実転送速度はこれよりもかなり低くなっている。つまり、ＣＰＵ上で動作するファームウェアやアプリケーションソフトウェアが、送信データを準備したり、受信データを取り込んだりするなどの処理に多くの時間を要してしまい、バス上での転送速度が速くても、結局、高速なデータ転送を実現できない。
【０００５】
特に、周辺機器に組み込まれるＣＰＵは、パーソナルコンピュータなどのホストシステムに組み込まれるＣＰＵに比べて処理能力が低い。このため、ファームウェア等の処理のオーバーヘッドの問題は、非常に深刻なものとなる。従って、このようなオーバーヘッドの問題を効果的に解消できる技術が望まれている。
【０００６】
本発明は、以上のような技術的課題に鑑みてなされたものであり、その目的とするところは、ファームウェア等の処理のオーバーヘッドを軽減し、小規模なハードウェアで高速なデータ転送を実現できるデータ転送制御装置及びこれが用いられる電子機器を提供することにある。
【０００７】
【課題を解決するための手段】
上記課題を解決するために本発明は、バスに接続される複数のノード間でＩＥＥＥ１３９４の規格に準拠したデータ転送を行うためのデータ転送制御装置であって、ノード間でのパケット転送のためのサービスを提供するリンク回路と、前記リンク回路を介して受信したパケットを、ランダムアクセス可能なパケット記憶手段に書き込む書き込み回路とを含み、前記リンク回路が、他のノードから受信したパケットのヘッダに含まれるヘッダＣＲＣ又はトランザクションコードをチェックし、パケットのヘッダにＣＲＣエラーがあると判断した場合又はパケットのトランザクションコードが不知のコードであると判断した場合には、該パケットを無効にする処理を行うことを特徴とする。
【０００８】
本発明によれば、パケットのヘッダがＣＲＣエラーの場合やパケットのトランザクションコードが不知の場合には、そのパケットが無効になるように（破棄されるように）、リンク回路が処理を行う。これにより、そのパケットに対するファームウェア等の処理が不要になる。この結果、ファームウェアの処理負担を軽減でき、データ転送を高速化できる。
【０００９】
また本発明は、パケットのヘッダにＣＲＣエラーがあると判断した場合には、前記パケット記憶手段のヘッダ領域での受信済み位置を指すヘッダポインタを、１つ前のパケットの受信完了時に指していた位置に戻すことで、該パケットを無効にすることを特徴とする。このようにすれば、ヘッダの前半部分がパケット記憶手段に既に書き込まれてしまったような状況においても、ヘッダポインタを戻すという簡易な処理でパケットを無効にできるようになる。
【００１０】
また本発明は、ヘッダＣＲＣエラーが発生したことを示すステータス情報を記憶する手段を含むことを特徴とする。また本発明は、不知のコードのパケットを受信したことを示すステータス情報を記憶する手段を含むことを特徴とする。このようにすれば、もし仮にファームウェアが、ヘッダＣＲＣエラーの発生のステータスを知りたい場合や、不知のコードのパケットの受信のステータスを知りたい場合に、このステータスをファームウェアに伝えることができるようになる。
【００１１】
また本発明は、パケットのトランザクションコードが不知のコードであると判断した場合には、前記パケット記憶手段に該パケットを書き込まないようにすることで、該パケットを無効にすることを特徴とする。このようにすれば、そのパケットは存在しなかったことになり、ファームウェアの処理負担を軽減できる。
【００１２】
また本発明は、パケットのヘッダにＣＲＣエラーがあると判断した場合又はパケットのトランザクションコードが不知のコードであると判断した場合には、受信完了ステータスを不生成にすることを特徴とする。このようにすれば、ファームウェアの割り込み処理が不要になり、ファームウェアが無駄な処理を行うのを防止できる。
【００１３】
また本発明は、バスに接続される複数のノード間でＩＥＥＥ１３９４の規格に準拠したデータ転送を行うためのデータ転送制御装置であって、ノード間でのパケット転送のためのサービスを提供するリンク回路と、前記リンク回路を介して受信したパケットを、ランダムアクセス可能なパケット記憶手段に書き込む書き込み回路とを含み、前記リンク回路が、他のノードから受信したパケットのデータに含まれるデータＣＲＣをチェックし、パケットのデータにＣＲＣエラーがあると判断した場合には、該パケットのヘッダを有効にし、該パケットのデータを無効にする処理を行うことを特徴とする。
【００１４】
本発明によれば、データＣＲＣエラーの場合には、そのパケットのヘッダを有効にし、データだけが無効になるように、リンク回路が処理を行う。これにより、そのデータを読み出す等の処理が不要になり、ファームウェアの処理負担を軽減できる。また、ヘッダを無効にせずに残すことで、ファームウェアが、データＣＲＣエラー発生時用の処理を行うことができるようになる。
【００１５】
また本発明は、パケットのデータにＣＲＣエラーがあると判断した場合には、前記パケット記憶手段のヘッダ領域での受信済み位置を指すヘッダポインタについては戻さず、前記パケット記憶手段のデータ領域での受信済み位置を指すデータポインタを、１つ前のパケットの受信完了時に指していた位置に戻すことで、該パケットのデータを無効にすることを特徴とする。このようにすれば、データポインタを戻すという簡易な処理でパケットを無効にできるようになる。
【００１６】
また本発明は、バスに接続される複数のノード間でＩＥＥＥ１３９４の規格に準拠したデータ転送を行うためのデータ転送制御装置であって、ノード間でのパケット転送のためのサービスを提供するリンク回路と、前記リンク回路を介して受信したパケットを、ランダムアクセス可能なパケット記憶手段に書き込む書き込み回路と、受信したブロードキャストパケットを無効にする第１のモードと、受信したブロードキャストパケットを有効にする第２のモードとを設定するための手段とを含み、前記リンク回路が、他のノードから受信したパケットのヘッダに含まれるデスティネーションＩＤをチェックし、パケットがブロードキャストパケットであると判断し且つ前記第１のモードに設定されていた場合には、該パケットを無効にする処理を行うことを特徴とする。
【００１７】
本発明によれば、受信したブロードキャストパケットを無効にする第１のモードと、有効にする第２のモードのいずれで動作するかを選択できるようになり、データ転送制御装置の汎用性を高めることができる。そして、第１のモードに設定されている時にブロードキャストパケットを受信した場合には、そのパケットが無効になるように、リンク回路が処理を行う。これにより無駄な処理が行われるのを防止でき、データ転送の高速化を図れる。
【００１８】
また本発明は、パケットがブロードキャストパケットであると判断し且つ前記第１のモードに設定されていた場合には、前記パケット記憶手段に該パケットを書き込まないようにすることで、該パケットを無効にすることを特徴とする。このようにすれば、パケット記憶手段への書き込み処理が行われないようになり、無駄な処理が行われるのを防止できる。
【００１９】
また本発明に係る電子機器は、上記のいずれかのデータ転送制御装置と、前記データ転送制御装置及びバスを介して他のノードから受信したデータに所与の処理を施す装置と、処理が施されたデータを出力又は記憶するための装置とを含むことを特徴とする。また本発明に係る電子機器は、上記のいずれかのデータ転送制御装置と、前記データ転送制御装置及びバスを介して他のノードに送信するデータに所与の処理を施す装置と、処理が施されるデータを取り込むための装置とを含むことを特徴とする。
【００２０】
本発明によれば、他のノードから転送されたデータを電子機器において出力したり記憶したりする処理、電子機器において取り込んだデータを他のノードに転送したりする処理を高速化することが可能になる。また、本発明によれば、データ転送制御装置を小規模化できると共に、データ転送を制御するファームウェアなどの処理負担を軽減できるため、電子機器の低コスト化、小規模化などを図ることも可能になる。
【００２１】
【発明の実施の形態】
以下、本発明の好適な実施形態について図面を用いて詳細に説明する。
【００２２】
１．ＩＥＥＥ１３９４
まず、ＩＥＥＥ１３９４について簡単に説明する。
【００２３】
１．１ 概要
ＩＥＥＥ１３９４（ＩＥＥＥ１３９４−１９９５、Ｐ１３９４．ａ）では１００〜４００Ｍｂｐｓの高速なデータ転送が可能となっている（Ｐ１３９４．ｂでは８００〜３２００Ｍｂｐｓ）。また、転送速度が異なるノードをバスに接続することも許される。
【００２４】
各ノードはツリー状に接続されており、１つのバスに最大で６３個のノードが接続可能になっている。なお、バスブリッジを利用すれば約６４０００個のノードを接続することも可能である。
【００２５】
ＩＥＥＥ１３９４では、パケットの転送方式として非同期転送とアイソクロナス転送が用意されている。ここで非同期転送は、信頼性が要求されるデータの転送に好適な転送方式であり、アイソクロナス転送は、リアルタイム性が要求される動画像や音声などのデータの転送に好適な転送方式である。
【００２６】
１．２ 層構造
ＩＥＥＥ１３９４の層構造（プロトコル構成）を図１に示す。
【００２７】
ＩＥＥＥ１３９４のプロトコルは、トランザクション層、リンク層、物理層により構成される。また、シリアルバスマネージメントは、トランザクション層、リンク、物理層をモニターしたり制御したりするものであり、ノードの制御やバスのリソース管理のための種々の機能を提供する。
【００２８】
トランザクション層は、上位層にトランザクション単位のインターフェース（サービス）を提供し、下層のリンク層が提供するインターフェースを通して、リードトランザクション、ライトトランザクション、ロックトランザクション等のトランザクションを実施する。
【００２９】
ここで、リードトランザクションでは、応答ノードから要求ノードにデータが転送される。一方、ライトトランザクションでは、要求ノードから応答ノードにデータが転送される。またロックトランザクションでは、要求ノードから応答ノードにデータが転送され、応答ノードがそのデータに処理を施して要求ノードに返信する。
【００３０】
リンク層は、アドレッシング、データチェック、パケット送受信のためのデータフレーミング、アイソクロナス転送のためのサイクル制御などを提供する。
【００３１】
物理層は、リンク層により使用されるロジカルシンボルの電気信号への変換や、バスの調停や、バスの物理的インターフェースを提供する。
【００３２】
なお、図２に示すように、ＩＥＥＥ１３９４のトランザクション層の一部の機能を含む上位のプロトコルとして、ＳＢＰ−２（Ｓｅｒｉａｌ Ｂｕｓ Ｐｒｏｔｏｃｏｌ−２）と呼ばれるプロトコルが提案されている。
【００３３】
ここでＳＢＰ−２は、ＳＣＳＩのコマンドセットをＩＥＥＥ１３９４のプロトコル上で利用可能にするために提案されたものである。このＳＢＰ−２を用いれば、既存のＳＣＳＩ規格の電子機器で使用されていたＳＣＳＩのコマンドセットに最小限の変更を加えて、ＩＥＥＥ１３９４規格の電子機器に使用できるようになる。従って、電子機器の設計や開発を容易化できる。また、ＳＣＳＩのコマンドだけではなく、デバイス固有のコマンドもカプセル化して利用できるため、非常に汎用性が高い。
【００３４】
このＳＢＰ−２では、まず、イニシエータ（パーソナルコンピュータ等）が、ログインやフェッチ・エージェントの初期化のためのＯＲＢ（Ｏｐｅｒａｔｉｏｎ Ｒｅｑｕｅｓｔ Ｂｌｏｃｋ）を作成して、ターゲット（プリンタ、ＣＤ−ＲＷドライブ等）に送る。次に、イニシエータは、コマンド（リードコマンド、ライトコマンド）を含むＯＲＢ（コマンドブロックＯＲＢ）を作成して、その作成したＯＲＢのアドレスを、ターゲットに知らせる。そして、ターゲットは、そのアドレスをフェッチすることにより、イニシエータが作成したＯＲＢを取得する。ＯＲＢに含まれるコマンドがリードコマンドであった場合には、ターゲットは、ブロックライトトランザクションを発行して、イニシエータのデータバッファ（メモリ）にターゲットのデータを送信する。一方、ＯＲＢに含まれるコマンドがライトコマンドであった場合には、ターゲットは、ブロックリードトランザクションを発行して、イニシエータのデータバッファからデータを受信する。
【００３５】
このＳＢＰ−２によれば、ターゲットは、自身が都合の良いときにトランザクションを発行して、データを送受信できる。従って、イニシエータとターゲットが同期して動く必要がなくなるため、データ転送効率を高めることができる。
【００３６】
なお、ＩＥＥＥ１３９４の上位プロトコルとしては、ＳＢＰ−２以外にも、ＦＣＰ（Ｆｕｎｃｔｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）と呼ばれるプロトコルなども提案されている。
【００３７】
１．３ パケットフォーマット
図３に、ＩＥＥＥ１３９４規格の、非同期でブロックデータを有するパケットのフォーマットを示す。
【００３８】
図３において、ＤｅｓｔＩＤ（デスティネーションＩＤ）は送信先のノードを識別するためのＩＤであり、ｔｌは、トランザクションを識別するためのラベルである。ｒｔは、リトライのためのコードであり、ｔｃｏｄｅは、パケットのフォーマットやトランザクションのタイプを識別するためのコードである。ｐｒｉはプライオリティであり、ＳｏｕｒｃｅＩＤは送信元のノードを識別するためのＩＤである。
【００３９】
Ｈｅａｄｅｒ ＣＲＣはヘッダのＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）エラーを検出するためのコードであり、Ｄａｔａ ＣＲＣはデータのＣＲＣエラーを検出するためのコードである。ヘッダやデータに付加される冗長ビットであるこれらのＣＲＣをチェックすることで、ヘッダやデータの誤りを検出できるようになる。
【００４０】
１．４ ブロードキャスト
ＩＥＥＥ１３９４のアドレッシングは６４ビット幅になっており、その上位１６ビットがノードＩＤになっている。また、このノードＩＤの上位１０ビットが、バス識別のためのＢＵＳ＿ＩＤとなっており、下位６ビットがノード識別のためのＰＨＹ＿ＩＤになっている。そして、ＤｅｓｔＩＤのＰＨＹ＿ＩＤ（下位６ビット）が０ｘ３Ｆ（＝６３）になってるパケットはブロードキャストパケットと呼ばれ、このパケットは、バスに接続される全てのノードに対して配信されるようになる。
【００４１】
２．全体構成
次に、本実施形態のデータ転送制御装置の全体構成の例について図４を用いて説明する。
【００４２】
図４において、ＰＨＹインターフェース１０は、ＰＨＹデバイス（物理層のデバイス）とのインターフェースを行う回路である。
【００４３】
リンクコア２０（リンク回路）は、リンク層のプロトコルやトランザクション層のプロトコルの一部をハードウェアにより実現する回路であり、ノード間でのパケット転送のための各種サービスを提供する。レジスタ２２は、これらのプロトコルを実現したリンクコア２０を制御するためのレジスタである。
【００４４】
ＦＩＦＯ（ＡＴＦ）３０、ＦＩＦＯ（ＩＴＦ）３２、ＦＩＦＯ（ＲＦ）３４は、各々、非同期送信用、アイソクロナス送信用、受信用のＦＩＦＯであり、例えばレジスタや半導体メモリなどのハードウェアにより構成される。本実施形態では、これらのＦＩＦＯ３０、３２、３４の段数は非常に少ない。例えば１つのＦＩＦＯの段数は、好ましくは３段以下であり、更に好ましくは２段以下となる。
【００４５】
ＤＭＡＣ４０（読み出し回路）、ＤＭＡＣ４２（読み出し回路）、ＤＭＡＣ４４（書き込み回路）は、各々、ＡＴＦ用、ＩＴＦ用、ＲＦ用のＤＭＡコントローラである。これらのＤＭＡＣ４０、４２、４４を用いることで、ＣＰＵ６６に介入されることなく、ＲＡＭ８０とリンクコア２０との間でのデータ転送が可能になる。なお、レジスタ４６は、ＤＭＡＣ４０、４２、４４などを制御するレジスタである。
【００４６】
ポートインターフェース５０は、アプリケーション層のデバイス（例えばプリンタの印字処理を行うデバイス）とのインターフェースを行う回路である。本実施形態では、このポートインターフェース５０を用いて、例えば８ビットのデータ転送が可能になっている。
【００４７】
ＦＩＦＯ（ＰＦ）５２は、アプリケーション層のデバイスとの間でのデータ転送のためのＦＩＦＯであり、ＤＭＡＣ５４は、ＰＦ用のＤＭＡコントローラである。レジスタ５６は、ポートインターフェース５０やＤＭＡＣ５４を制御するレジスタである。
【００４８】
ＳＢＰ−２コア８４は、ＳＢＰ−２のプロトコルの一部をハードウェアにより実現する回路である。レジスタ８８は、ＳＢＰ−２コア８４を制御するためのレジスタである。ＤＭＡＣ（ＳＢＰ−２用）８６は、ＳＢＰ−２コア８４用のＤＭＡコントローラである。
【００４９】
ＲＡＭ領域管理回路３００は、ＲＡＭ８０の各領域を管理するための回路である。ＲＡＭ領域管理回路３００は、ＲＡＭ８０の各領域がフルになったり、エンプティになった場合に、各種のフル信号、エンプティ信号を用いてＤＭＡＣ４０、４２、４４、５４、８６を制御する。
【００５０】
ＣＰＵインターフェース６０は、データ転送制御装置をコントロールするＣＰＵ６６とのインターフェースを行う回路である。ＣＰＵインターフェース６０は、アドレスデコーダ６２、データ同期化回路６３、割り込みコントローラ６４を含む。クロック制御回路６８は、本実施形態で使用されるクロックを制御するものであり、ＰＨＹデバイス（ＰＨＹチップ）から送られてくるＳＣＬＫや、マスタークロックであるＨＣＬＫが入力される。
【００５１】
バッファマネージャ７０は、ＲＡＭ８０とのインターフェースを管理する回路である。バッファマネージャ７０は、バッファマネージャの制御のためのレジスタ７２、ＲＡＭ８０へのバス接続を調停する調停回路７４、各種の制御信号を生成するシーケンサ７６を含む。
【００５２】
ＲＡＭ８０は、ランダムアクセス可能なパケット記憶手段として機能するものであり、その機能は例えばＳＲＡＭ、ＳＤＲＡＭ、ＤＲＡＭなどにより実現される。
【００５３】
なおＲＡＭ８０は、本実施形態のデータ転送制御装置に内蔵させることが特に望ましいが、その一部又は全部を外付けにすることも可能である。
【００５４】
図５に、ＲＡＭ８０のメモリマップの一例を示す。図５に示すように本実施形態では、ＲＡＭ８０が、ヘッダ領域（ＡＲ２、ＡＲ３、ＡＲ４、ＡＲ６）とデータ領域（ＡＲ５、ＡＲ７、ＡＲ８、ＡＲ９）に分離されている。そして、パケットのヘッダ（広義には制御情報）はヘッダ領域に格納され、パケットのデータ（ＯＲＢ、ストリーム）はデータ領域に格納される。
【００５５】
また本実施形態では、図５に示すように、ＲＡＭ８０のデータ領域（ＡＲ５、ＡＲ７、ＡＲ８、ＡＲ９）が、ＯＲＢ領域（ＡＲ５、ＡＲ７）とストリーム領域（ＡＲ８、ＡＲ９）に分離されている。
【００５６】
更に本実施形態では、ＲＡＭ８０が、受信領域（ＡＲ２、ＡＲ４、ＡＲ５、ＡＲ９）と送信領域（ＡＲ３、ＡＲ６、ＡＲ７、ＡＲ８）に分離されている。
【００５７】
なお、ＯＲＢ（第１の層用の第１のデータ）は、上述したようにＳＢＰ−２用のデータ（コマンド）である。一方、ストリーム（第１の層より上層の第２の層用の第２のデータ）は、アプリケーション層用のデータ（プリンタの印字データ、ＣＤ−ＲＷの読み出し・書き込みデータ、スキャナによる取り込み画像データ等）である。
【００５８】
また、ＡＲ１、ＡＲ２、ＡＲ３に示すＨＷ（ハードウェア）用ページテーブル領域、ＨＷ用受信ヘッダ領域、ＨＷ用送信ヘッダ領域は、図４に示すＳＢＰ−２コア８４（ＳＢＰ−２をハードウェアにより実現する回路）が、ページテーブルや受信ヘッダや送信ヘッダを書き込んだり読み出したりするための領域である。
【００５９】
また、図５においてＡＲ４、ＡＲ５、ＡＲ８、ＡＲ９に示す領域は、いわゆるリングバッファ構造になっている。
【００６０】
さて、図４のバス９０（或いはバス９２、９４）は、アプリケーションに接続されるものである（第１のバス）。またバス９５（或いはバス９６）はデータ転送制御装置をコントロールし、或いはデータをリード・ライトするためのものであり、データ転送制御装置をコントロールするデバイス（例えばＣＰＵ）に電気的に接続される（第２のバス）。またバス１００（或いはバス１０２、１０４、１０５、１０６、１０７、１０８、１０９）は、物理層のデバイス（ＰＨＹデバイス）に電気的に接続されるものである（第３のバス）。また、バス１１０は、ランダムアクセス可能な記憶手段であるＲＡＭ８０に電気的に接続されるものである（第４のバス）。またバス９９は、ＳＢＰ−２コア８４がハードウェアによりＳＢＰ−２を実現するためのヘッダ情報やページテーブル情報をリード・ライトするためのものである（第５のバス）。
【００６１】
バッファマネージャ７０の調停回路７４は、ＤＭＡＣ４０、４２、４４、ＣＰＵインターフェース６０、ＤＭＡＣ８６、５４からのバスアクセス要求の調停を行う。そして、この調停結果に基づいて、各々、バス１０５、１０７、１０９、９６、９９、９４のいずれかと、ＲＡＭ８０のバス１１０との間にデータの経路が確立される（第１、第２、第３、第５のバスのいずれかと第４のバスとの間にデータ経路が確立される）。
【００６２】
本実施形態の１つの特徴は、ランダムアクセスが可能でありパケットを格納するＲＡＭ８０を設けると共に、互いに分離されるバス９０、９５、９９、１００と、これらのバスをＲＡＭ８０のバス１１０に接続するための調停回路７４とを設けた点にある。
【００６３】
例えば図６に、本実施形態と構成の異なるデータ転送制御装置の例を示す。このデータ転送制御装置では、リンクコア９０２は、ＰＨＹインターフェース９００、バス９２２を介してＰＨＹデバイスと接続される。また、リンクコア９０２は、ＦＩＦＯ９０４、９０６、９０８、ＣＰＵインターフェース９１０、バス９２０を介してＣＰＵ９１２に接続される。そして、ＣＰＵ９１２は、バス９２４を介して、ＣＰＵにローカルなメモリであるＲＡＭ９１４に接続される。
【００６４】
図６の構成のデータ転送制御装置を用いた場合のデータ転送の手法について図７を用いて説明する。ＰＨＹデバイス９３０を介して他のノードから送られてきた受信パケットは、バス９２２、データ転送制御装置９３２、バス９２０を介してＣＰＵ９１２が受け取る。そして、ＣＰＵ９１２は、受け取った受信パケットをバス９２４を介してＲＡＭ９１４に一旦書き込む。そして、ＣＰＵ９１２は、ＲＡＭ９１４に書き込まれた受信パケットをバス９２４を介して読み出し、アプリケーション層が使用できるように加工し、バス９２６を介してアプリケーション層のデバイス９３４に転送する。
【００６５】
一方、アプリケーション層のデバイス９３４からのデータを転送する場合には、ＣＰＵ９１２は、このデータをＲＡＭ９１４に書き込む。そして、ＲＡＭ９１４のデータにヘッダを付加することでＩＥＥＥ１３９４に準拠したパケットを生成する。そして生成されたパケットは、データ転送制御装置９３２、ＰＨＹデバイス９３０などを介して他のノードに送信される。
【００６６】
しかしながら、このような図７のデータ転送手法によると、ＣＰＵ９１２の処理負担が非常に重くなる。従って、ノード間を接続するシリアルバスの転送速度が高速になっても、ＣＰＵ９１２の処理のオーバーヘッドなどに起因して、システム全体の実転送速度は低くなり、結局、高速なデータ転送を実現できない。
【００６７】
これに対して、本実施形態では図８に示すように、データ転送制御装置１２０、アプリケーション層のデバイス１２４間のバス９０と、ＣＰＵバス９６と、データ転送制御装置１２０、ＲＡＭ８０間のバス１１０とが互いに分離されている。従って、ＣＰＵバス９６をデータ転送の制御のみに使用できるようになる。また、バス９０を占有して、データ転送制御装置１２０、アプリケーション層のデバイス１２４間でデータ転送を行うことができるようになる。例えば、データ転送制御装置１２０が組み込まれる電子機器がプリンタである場合には、バス９０を占有して印字データを転送できるようになる。この結果、ＣＰＵ６６の処理負担を軽減でき、システム全体の実転送速度を高めることができる。またＣＰＵ６６として安価なものを採用できると共に、ＣＰＵバス９６として高速なバスを使用する必要性がなくなる。このため、電子機器の低コスト化、小規模化を図れるようになる。
【００６８】
３． 詳細例
３．１ リンコア、ＦＩＦＯ、ＤＭＡＣの詳細な構成
図９に、リンクコア２０（リンク回路）、ＦＩＦＯ３４、ＤＭＡＣ４４（書き込み回路）の詳細な構成の一例を示す。
【００６９】
リンクコア２０は、バス監視回路１３０、直列・並列変換回路１３２、パケット整形回路１６０、レジスタ２２を含む。
【００７０】
ここでバス監視回路１３０は、ＰＨＹインターフェース１０を介してＰＨＹデバイスに接続される８ビット幅のデータバスＤ、２ビット幅のコントロールバスＣＴＬを監視する回路である。
【００７１】
直列・並列変換回路１３２は、データバスＤのデータを３２ビットのデータに変換する回路である。
【００７２】
パケット整形回路１６０は、各ノードから転送されてきたパケットを上層が使用できるように整形する回路である。例えば前述した図３は、ＩＥＥＥ１３９４規格の、非同期でブロックデータを有するパケットのフォーマットである。一方、図１０は、ＲＡＭ８０のヘッダ領域に格納される、非同期受信でブロックデータを有するパケットのヘッダ部分のフォーマットである。このように本実施形態では、図３のフォーマットのパケットを、ファームウェアなどの上層が使用できるように、図１０に示すフォーマットのパケットに整形している。
【００７３】
パケット整形回路１６０は、パケット診断回路１４２、シーケンサ１６７、バッファ１６８、セレクタ１７０を含み、パケット診断回路１４２は、ＴＡＧ生成回路１６２、ステータス生成回路１６４、エラーチェック回路１６６を含む。
【００７４】
ここでパケット診断回路１４２は、パケットの診断を行う回路である。ＴＡＧ生成回路１６２は、パケットのヘッダ、データ等を書き込む領域を区別するための情報であるＴＡＧを生成する回路であり、ステータス生成回路１６４は、パケットに付加する各種のステータスを生成する回路である。エラーチェック回路１６６は、パケットのエラーチェックを行う回路である。例えば、図３のパケットのＨｅａｄｅｒ ＣＲＣやＤａｔａ ＣＲＣのチェックを行う。また、エラーチェック回路１６６はＤｅｓｔＩＤやｔｃｏｄｅのチェックも行う。より具体的には、ＤｅｓｔＩＤをチェックすることで、受信したパケットがブロードキャストパケットか否かを判断し、ｔｃｏｄｅをチェックすることで、受信したパケットのｔｃｏｄｅが不知のコード（Ｕｎｋｔｃｏｄｅ）か否かを判断する。
【００７５】
シーケンサ１６７は各種の制御信号を生成するものである。バッファ１６８、セレクタ１７０は、直列・並列変換回路１３２からのＤＩ、パケット診断回路１４２からのステータス、ＤＭＡＣ４４からのデータポインタＤＰのいずれかを、パケット診断回路１４２からの信号ＳＥＬにより選択するためのものである。
【００７６】
レジスタ２２は、ヘッダＣＲＣエラーをファームウェアに伝えるためのレジスタ２３、不知のコード（Ｕｎｋｔｃｏｄｅ）のパケットを受信したことをファームウェアに伝えるためのレジスタ２４を含む。また、受信したブロードキャストパケットを無効にする第１のモード（破棄するモード）と、有効にする第２のモード（ファームウェアに渡すモード）とを設定するためのレジスタ２５を含む。
【００７７】
ＦＩＦＯ３４は、リンコア２０からの出力データであるＲＤの位相と、ＲＡＭ８０への書き込みデータであるＷＤＡＴＡの位相とを調整するためのバッファとして機能するものであり、ＦＩＦＯ状態判断回路３５を含む。ＦＩＦＯ状態判断回路３５は、ＦＩＦＯ３４が空になると、信号ＥＭＰＴＹをアクティブにし、ＦＩＦＯ３４がフルになると、信号ＦＵＬＬをアクティブにする。
【００７８】
ＤＭＡＣ４４は、パケット分離回路１８０、アクセス要求実行回路１９０、アクセス要求発生回路１９２を含む。
【００７９】
ここでパケット分離回路１８０は、パケット整形回路１６０により整形されたパケットをＴＡＧ（ＤＴＡＧ）に基づいてデータ、ヘッダ等に分離して、ＲＡＭの各領域（図５参照）に書き込む処理を行う。
【００８０】
アクセス要求実行回路１９０は、リンクコア２０からのアクセス要求を実行するための回路である。アクセス要求実行回路１９０は、ＦＩＦＯ状態判断回路３５からのＦＵＬＬがアクティブになると、ＦＦＵＬＬをアクティブにする。パケット整形回路１６０内のシーケンサ１６７は、ＦＦＵＬＬがアクティブでないことを条件に、ＲＤ（ＲｘＤａｔａ）のストローブ信号であるＲＤＳをアクティブにする。
【００８１】
なおＲＦＡＩＬは、受信における失敗を、シーケンサ１６７がアクセス要求実行回路１９０に対して知らせるための信号である。
【００８２】
アクセス要求発生回路１９２は、ＲＡＭ８０へのアクセス要求を発生するための回路である。アクセス要求発生回路１９２は、バッファマネージャ７０からの書き込みアクノリッジメントであるＷＡＣＫやＦＩＦＯ状態判断回路３５からのＥＭＰＴＹなどを受け、書き込み要求であるＷＲＥＱをバッファマネージャ７０に出力する。
【００８３】
３．２ パケットの分離及びＲＡＭの各領域への書き込み
ＴＡＧ生成回路１６２は、図１１に示すような４ビットのＴＡＧを生成している。そして、リンクコア２０は、パケット（図３参照）のスタート（最初の１クワドレット）、ヘッダ、データ（ＯＲＢ、ストリーム）をＲＤとしてＦＩＦＯ３４に出力する際に、この生成された４ビットのＴＡＧも同時にＦＩＦＯ３４に出力する。そして、本実施形態では、このＴＡＧを利用することで、パケットを分離し、ＲＡＭの各領域（図５参照）に書き込んでいる。
【００８４】
より具体的には、図９のＴＡＧ判別回路１８２が、ＦＩＦＯ３４から出力されるＤＴＡＧ（＝ＴＡＧ）を判別し、ＦＩＦＯ３４の出力ＷＤＡＴＡの書き込み領域を決める。そして、アドレス発生回路１８８が含むポインタ更新回路１８４が、この決められた領域において、ポインタ（データポインタ、ヘッダポインタ）を順次更新（インクリメント、デクリメント）する。そして、アドレス発生回路１８８は、この順次更新されるポインタが指すアドレスを発生して、ＷＡＤＲとしてバッファマネージャ７０に出力する。このようにすることで、パケットのヘッダ、ＯＲＢ、ストリームが、図５に示すようなＲＡＭの各領域に書き込まれるようになる。
【００８５】
なお、アドレス発生回路１８８は、データポインタＤＰ（受信ＯＲＢ領域のデータポインタ、受信ストリーム領域のデータポインタ等）をパケット整形回路１６０に出力しており、パケット整形回路１６０は、このデータポインタをパケットのヘッダに埋め込んでいる（図１０のＣ３０参照）。これにより、ヘッダ領域に格納されるヘッダとデータ領域に格納されるデータとを対応づけることが可能になる。
【００８６】
次に、図１１のＴＡＧ（ＤＴＡＧ）について説明する。図１１において、例えばＴＡＧが（０００１）、（００１０）であった場合には、受信パケットのヘッダ（ＦＩＦＯ３４の出力ＷＤＡＴＡ）が図５の受信ヘッダ領域へ書き込まれる。また、ＴＡＧが（０１００）であった場合には、受信パケットのデータが受信ＯＲＢ領域に書き込まれ、ＴＡＧが（０１０１）であった場合には、受信パケットのデータが受信ストリーム領域に書き込まれることになる。
【００８７】
また、ＴＡＧが（１００１）、（１０１０）であった場合には、受信パケットのヘッダがＨＷ（ハードウェア）用受信ヘッダ領域に書き込まれる。また、ＴＡＧが（１１００）であった場合には、受信パケットのデータがＨＷ用受信ＯＲＢ領域に書き込まれ、ＴＡＧが（１１０１）であった場合には、受信パケットのデータがＨＷ用受信ストリーム領域に書き込まれることになる。なお、ここでＨＷ（ハードウェア）用とは、図４のＳＢＰ−２コア８４用という意味である。
【００８８】
３．３ 通常受信動作
次に、図１２のタイミング波形図を用いて、通常時の受信動作について説明する。
【００８９】
図９の直列・並列変換回路１３２は、データバスＤからの８ビットのデータを３２ビットのデータに変換して、図１２に示すようにＤＩとして出力する。また、ＤＩのデータが有効か否かを示す信号ＤＩＥや、ＤＩの取り込みタイミングを決めるストローブ信号ＤＩＳも出力する。なお、図１２において、ＤＩのＨ１、Ｈ２、Ｈ３、Ｈ４は、各々、図３のヘッダの第１、第２、第３、第４クワドレットである。また、ＨＣＲＣは、図３のＨｅａｄｅｒ ＣＲＣである（第５クワドレット）。また、Ｄ１、Ｄ２・・・はデータであり（ここではＯＲＢデータ）、ＤＣＲＣは図３のＤａｔａ ＣＲＣである。
【００９０】
図９のエラーチェック回路１６６は、ＤＩの中のＨＣＲＣに基づいて、ヘッダＣＲＣエラーがあるか否かを判断し、ヘッダＣＲＣエラーではない場合には、図１２のＥ１に示すように信号ＨＣＲＣＯＫをアクティブにする。
【００９１】
また、エラーチェック回路１６６は、ＤＩの中のＤＣＲＣに基づいてデータＣＲＣエラーがあるか否かをチェックし、データＣＲＣエラーではない場合には、Ｅ２に示すように信号ＤＣＲＣＯＫをアクティブにする。
【００９２】
バッファ１６８及びセレクタ１７０は、パケット診断回路１４２からのステータス、直列・並列変換回路１３２からのＤＩ、パケット分離回路１８０からのデータポインタＤＰを受け、これらのいずれかを選択してＲＤとしてＦＩＦＯ３４に出力する。例えば図１２のＥ３ではデータポインタＤＰが選択されて、ＲＤとして出力されている。
【００９３】
ＴＡＧ生成回路１６２は、図１１で説明したＴＡＧを生成し、このＴＡＧを、ＲＤの出力に同期させてＦＩＦＯ３４に出力する。また、シーケンサ１６７は、上記のＲＤ及びＴＡＧのストローブ信号ＲＤＳを、ＦＩＦＯ３４に出力する。
【００９４】
ＦＩＦＯ３４は、ＴＡＧ、ＲＤ、ＲＤＳを受け、ＤＴＡＧ、ＷＤＡＴＡを出力する。このＷＤＡＴＡは、バッファマネジャ７０からのＷＡＣＫがアクティブになったことを条件に、ＲＡＭ８０に書き込まれる。即ち、ＲＡＭ８０への書き込み要求ＷＲＥＱは、図４の調停回路７４によりアービトレーションされるため、ＲＤの出力タイミングとＷＲＥＱ及びＷＡＣＫの出力タイミングは同期しない。
【００９５】
パケットの受信が完了すると、ＩＥＥＥ１３９４のバス上での調停に勝ったことを条件に、相手ノードに対してＡＣＫ（ＡＣＫパケット）が返送される。そして、相手ノードに対して返送したＡＣＫの内容が、Ｅ４に示すフッターＦＴＲ（ステータス生成回路１６４により生成されるステータス）の中に挿入される。
【００９６】
フッターＦＴＲがＲＡＭ８０に書き込まれると、Ｅ５に示すようにＩＮＴＲＸＣＯＭＰイベントの信号がアクティブになる。このＩＮＴＲＸＣＯＭＰは、図４の割り込みコントローラ６４に入力される。これにより、ＣＰＵ６６上で動作するファームウェアに対して、受信の完了が知らされる。そして、割り込みを受けたファームウェアは、ＲＡＭ８０のヘッダ領域、データ領域に格納されるヘッダ、データを読みに行く。
【００９７】
３．４ ヘッダＣＲＣエラー
図１３に、ヘッダＣＲＣエラーが検出された場合のタイミング波形図を示す。本実施形態では、パケットのヘッダにＣＲＣエラーがあった場合には、そのパケットがファームウェアに伝わらないように、そのパケットを無効にしている。
【００９８】
エラーチェック回路１６６によりヘッダＣＲＣエラーが検出されると、図１３のＥ１０に示すタイミングで、ＨＣＲＣＯＫがＨレベル（アクティブ）に変化せず、Ｌレベル（非アクティブ）のままとなる。すると、Ｅ１１に示すように、ストローブ信号ＲＤＳがＬレベル（非アクティブ）に固定され、ＲＡＭ８０へのパケットの書き込み処理が中断される。また、Ｅ１２に示すように、ヘッダポインタをクリアする信号ＨＰＣＬＲがアクティブになる。また、Ｅ１３に示すように、ＩＮＴＲＸＣＯＭＰイベントも発生しない。
【００９９】
信号ＨＰＣＬＲは、図９に示すようにアドレス発生回路１８８に入力される。そして、ＨＰＣＬＲがアクティブになると、アドレス発生回路１８８のポインタ更新回路１８４が、図１４に示すように、ヘッダポインタＨＰ（ヘッダ領域での受信済み位置を指すポインタ）を、前のパケットの受信完了時にＨＰが指していた位置に戻す。これにより、ヘッダＣＲＣエラーが検出されたヘッダ（ヘッダ３）は存在しなかったことになる。
【０１００】
即ち、ヘッダＣＲＣエラーが検出されても、その解析は不可能であるため、そのヘッダをファームウェアに渡しても無意味である。そこで、本実施形態では、ファームウェアの処理負担を軽減するために、ヘッダＣＲＣエラーが検出された場合に、そのヘッダを無効にし、ファームウェアに伝わらないようしている。例えば図１３のＥ１３に示すように、ヘッダＣＲＣエラーの時には、受信完了のＩＮＴＲＸＣＯＭＰイベントが発生せず、これに起因するＣＰＵへの割り込みも発生しない。このため、パケットを受信した事実もファームウェアに伝えられない。また、図１４に示すようにヘッダポインタＨＰが前の位置に戻るため、ヘッダＣＲＣエラーが検出されたヘッダは、ファームウェアにとって存在しなかったことになる。これにより受信処理に関わるファームウェアの処理を簡素化でき、装置の小規模化を図れる。また、ヘッダＣＲＣエラーが発生した場合の処理に要する時間を節約でき、データ転送の高速化を図れる。
【０１０１】
なお、図６のようにパケット記憶手段としてＲＡＭではなくＦＩＦＯを用いる構成では、ヘッダＣＲＣエラーが検出された時点で既にＦＩＦＯに入力されてしまったヘッダの第１〜第４クワドレットについては、無効にすることができない。従って、ファームウェアは、このパケットを受け取らざるを得ない。従って、ファームウェアの処理負担を軽減できない。
【０１０２】
これに対して、本実施形態では、パケット記憶手段として、ランダムアクセス可能なＲＡＭ８０を用いている。従って、例えば図１４に示すようにヘッダポインタを前の位置に戻すこと等により、パケットを無効にできるようになる。この結果、ファームウェアはこのパケットを受け取る必要がなくなり、ファームウェアの処理負担を軽減できる。
【０１０３】
なお、本実施形態では、ヘッダＣＲＣエラーが検出された場合に、ヘッダＣＲＣエラーが検出されたことを示すステータスＨＣＥを、図９のレジスタ２３（ファームウェアが読み出し可能なレジスタ）に書き込むようにしている。このようにすれば、もし仮にファームウェアが、ヘッダＣＲＣエラー検出のステータスＨＣＥを必要とする場合には、このステータスをファームウェアに伝えることが可能になる。
【０１０４】
３．５ Ｕｎｋｔｃｏｄｅ
図１５に、ｔｃｏｄｅが不知のコード（Ｕｎｋｔｃｏｄｅ）であった場合のタイミング波形図を示す。本実施形態では、ｔｃｏｄｅがＵｎｋｔｃｏｄｅであると判断した場合には、そのパケットがファームウェアに伝わらないように、そのパケットを無効にしている。
【０１０５】
即ち、図１５のＥ２０に示すように、ヘッダの第１クワドレットでエラーチェック回路１６６がＵｎｋｔｃｏｄｅを検出すると、Ｅ２１に示すように、ストローブ信号ＲＤＳがＬレベル（非アクティブ）に固定される。これにより、パケットがＲＡＭ８０に書き込まれないようになる。つまり、他ノード宛のパケットと同様の取り扱いになる。また、Ｅ２２に示すように、ＩＮＴＲＸＣＯＭＰイベントも発生しない。
【０１０６】
即ち、Ｕｎｋｔｃｏｄｅが検出された場合、そのパケットのｔｄｏｄｅは不明となる。そして、ｔｃｏｄｅが不明の場合には、ヘッダのサイズもわからず、Ｈｅａｄｅｒ ＣＲＣの位置もわからない。従って、Ｕｎｋｔｃｏｄｅの検出後の処理は全て無意味であり、そのヘッダをファームウェアに渡す必要はない。そこで、本実施形態では、ファームウェアの処理負担を軽減するために、Ｕｎｋｔｃｏｄｅが検出された場合に、そのヘッダがＲＡＭに書き込まれないようにしている。これにより、Ｕｎｋｔｃｏｄｅに関するファームウェアの処理が不要になり、データ転送の高速化を図れる。
【０１０７】
なお、本実施形態では、不知のコードのパケットを受信したことを示すステータスＵＮＫを、図９のレジスタ２４（ファームウェアが読み出し可能なレジスタ）に書き込むようにしている。このようにすれば、もし仮にファームウェアが、不知のコードのパケットの受信のステータスＵＮＫを必要とする場合には、このステータスをファームウェアに伝えることが可能になる。
【０１０８】
３．６ データＣＲＣエラー
図１６に、データＣＲＣエラーが検出された場合のタイミング波形図を示す。本実施形態では、データＣＲＣエラーが検出された場合に、そのパケットのヘッダを有効にし、そのパケットのデータを無効にしている。
【０１０９】
エラーチェック回路１６６によりデータＣＲＣエラーが検出されると、図１６のＥ３０に示すタイミングで、ＤＣＲＣＯＫがＨレベルに変化せず、Ｌレベル（非アクティブ）のままとなる。すると、Ｅ３１に示すように、データポインタをクリアする信号ＤＰＣＬＲがアクティブになる。
【０１１０】
なお、この場合には、Ｅ３２に示すように、ＩＮＴＲＸＣＯＭＰイベントが発生する。また、相手ノードにはＡＣＫデータエラーのパケットが返信される（Ｅ３３のフッターＦＴＲには、ＡＣＫデータエラーを返信したことを示す情報が挿入される）。
【０１１１】
信号ＤＰＣＬＲは、図９に示すようにアドレス発生回路１８８に入力される。そして、ＤＰＣＬＲがアクティブになると、アドレス発生回路１８８のポインタ更新回路１８４が、図１７に示すようにデータポインタＤＰ（データ領域での受信済み位置を指すポインタ）を、前のパケットの受信完了時にＤＰが指していた位置に戻す。これにより、データＣＲＣエラーが検出されたパケットのデータ（データ３）は存在しなかったことになる。
【０１１２】
一方、図１４の場合と異なり、図１７では、ヘッダポインタＨＰは変化せず、ヘッダ（ヘッダ３）は残る。従って、ファームウェアはそのヘッダ３を読み出すことができるようになる。
【０１１３】
即ち、データＣＲＣエラーの場合には、そのデータについては解析が不可能であるため、そのデータをファームウェアに渡しても無意味である。従って、図１７に示すようにデータポインタＤＰを前の位置に戻すことで、データＣＲＣエラーが検出されたパケットのデータについては破棄する。このようにすれば、データポインタとデータ長に基づくアドレス計算が不要になり、ファームウェアの処理負担を軽減できる。
【０１１４】
一方、ヘッダについてはファームウェアが使用する可能性もあるので、破棄せずに残すようにする。データＣＲＣエラーの場合には、パケットを再送させるためのトランザクションを発行する等の処理が必要になるかもしれず、そのためにはデータＣＲＣエラーが生じたパケットのヘッダをファームウェアが解析できるようにする必要があるからである。即ち、ファームウェアは、このヘッダを解析することで、データＣＲＣエラーが生じたパケットのＳｏｕｒｃｅＩＤ、ｔｃｏｄｅ、トランザクションラベルｔｌなどを知ることができるようになる。この結果、ファームウェアは、データＣＲＣエラー発生時用のトランザクション処理を適正に実行できるようになる。
【０１１５】
３．７ ブロードキャストパケット
さて、図２で説明したＳＢＰ−２と呼ばれるプロトコルでは、基本的にブロードキャストパケットは用いない。ＳＢＰ−２では、イニシエータとターゲットの間でピア・ツー・ピア（ｐｅｅｒ ｔｏ ｐｅｅｒ）でデータ転送が行われるからである。
【０１１６】
従って、ＳＢＰ−２に特化したデータ転送制御装置にする場合には、ファームウェアの処理負担を軽減するために、ブロードキャストパケットの受信を無効にできることが望まれる。
【０１１７】
そこで本実施形態では、受信したブロードキャストパケットを無効にする第１のモード（ブロードキャストパケットを破棄するモード）と、有効にする第２のモード（ファームウェアに渡すモード）とを、図９のレジスタ２５を用いて設定できるようにしている（ファームウェアが設定する）。
【０１１８】
図１８に、第１のモードでブロードキャストパケットを受信した場合のタイミング波形図を示す。本実施形態では、第１のモードでブロードキャストパケットを受信した場合には、そのパケットがファームウェアに伝わらないように、そのパケットを無効にしている。
【０１１９】
即ち図１８のＥ４０に示すように、ヘッダの第１クワドレットで、エラーチェック回路１６６が、受信パケットがブロードキャストパケットか否かをＤｅｓｔＩＤに基づき判断する。そして、ブロードキャストであると判断された場合（０ｘ３Ｆである場合）には、Ｅ４１に示すように、ストローブ信号ＲＤＳがＬレベル（非アクティブ）に固定される。これにより、パケットがＲＡＭ８０に書き込まれないようになる。つまり、他ノード宛のパケットと同様の取り扱いになる。また、Ｅ４２に示すように、ＩＮＴＲＸＣＯＭＰイベントも発生しない。これにより、受信したブロードキャストパケットは存在しなかったものと見なされ、ブロードキャストに関するファームウェアの処理が不要になる。従って、ＳＢＰ−２に特化したデータ転送制御装置のデータ転送の高速化を図れるようになる。
【０１２０】
なお、ブロードキャストパケットを有効にする第２のモードでブロードキャストパケットを受信した場合には、図１２で説明した通常受信動作になる。
【０１２１】
３．８ ファームウェアの処理
次に、本実施形態の手法により、ファームウェアの処理が如何に軽減されるかについて説明する。
【０１２２】
図１９（Ａ）は、本実施形態の手法を用いない比較例において、ファームウェアが行う処理について示すフローチャートであり、図１９（Ｂ）は、本実施形態において、ファームウェアが行う処理について示すフローチャートである。
【０１２３】
まず、ヘッダを記憶手段から読み出す（ステップＳ１）。そして、ヘッダに含まれるｔｃｏｄｅを解析し、不知のｔｃｏｄｅであれば処理を終了する（ステップＳ２、Ｓ３）。次に、ヘッダに含まれるＨｅａｄｅｒ ＣＲＣを解析し、ヘッダＣＲＣエラーであれば処理を終了する（ステップＳ４、Ｓ５）。そして、ヘッダに含まれるＤｅｓｔＩＤを解析し、受信したパケットがブロードキャストパケットであれば処理を終了する（ステップＳ６、Ｓ７）。次に、パケット処理に移行する（ステップＳ８）。
【０１２４】
一方、本実施形態によれば、図１９（Ｂ）に示すように、ファームウェアは、ヘッダを読み出した後、直ぐにパケット処理に移行できる（ステップＳ１１、Ｓ１２）。即ち、図１９（Ａ）のステップＳ２〜Ｓ７の処理が不要になる。これにより、ファームウェアの処理負担を格段に軽減でき、データ転送を高速化できる。
【０１２５】
図２０（Ａ）は、比較例において、ファームウェアが行うパケット処理について示すフローチャートであり、図２０（Ｂ）は、本実施形態において、ファームウェアが行うパケット処理について示すフローチャートである。
【０１２６】
図２０（Ａ）の比較例では、まず、ファームウェアが、Ｄａｔａ ＣＲＣを解析し、データＣＲＣエラーか否かを判断する（ステップＳ２１、Ｓ２２）。そして、データＣＲＣエラーではない場合には、読み出したデータを、後段のアプリケーション層のデバイスに渡し、トランザクション処理に移行する（ステップＳ２３、Ｓ２５）。一方、データＣＲＣエラーである場合には、そのパケットのデータを破棄し、トランザクション処理に移行する（ステップＳ２４、Ｓ２５）
図２０（Ｂ）の本実施形態では、まず、ファームウェアが、受信パケットのヘッダ（フッターＦＴＲ）に含まれるＡＣＫを解析し、データＣＲＣエラーか否かを判断する（ステップＳ３１、Ｓ３２）。そして、データＣＲＣエラーではない場合には、読み出したデータを、後段のアプリケーション層のデバイスに渡し、トランザクション処理に移行する（ステップＳ３３、Ｓ３４）。一方、データＣＲＣエラーである場合には、そのまま、トランザクション処理に移行する（ステップＳ３５）。
【０１２７】
このように、本実施形態によれば、図２０（Ａ）のステップＳ２４のデータを破棄する処理が不要になる。このデータを破棄する処理は、例えば、データポインタとデータ長に基づくアドレス計算などが必要になり、負荷が重い。本実施形態によれば、このようなアドレス計算が不要になるため、ファームウェアの処理負担を格段に軽減できる。
【０１２８】
４．電子機器
次に、本実施形態のデータ転送制御装置を含む電子機器の例について説明する。
【０１２９】
例えば図２１（Ａ）に電子機器の１つであるプリンタの内部ブロック図を示し、図２２（Ａ）にその外観図を示す。ＣＰＵ（マイクロコンピュータ）５１０はシステム全体の制御などを行う。操作部５１１はプリンタをユーザが操作するためのものである。ＲＯＭ５１６には、制御プログラム、フォントなどが格納され、ＲＡＭ５１８はＣＰＵ５１０のワーク領域として機能する。表示パネル５１９はプリンタの動作状態をユーザに知らせるためのものである。
【０１３０】
ＰＨＹデバイス５０２、データ転送制御装置５００を介して、パーソナルコンピュータなどの他のノードから送られてきた印字データは、バス５０４を介して印字処理部５１２に直接送られる。そして、印字データは、印字処理部５１２にて所与の処理が施され、プリントヘッダなどからなる印字部（データを出力するための装置）５１４により紙に印字されて出力される。
【０１３１】
図２１（Ｂ）に電子機器の１つであるスキャナの内部ブロック図を示し、図２２（Ｂ）にその外観図を示す。ＣＰＵ５２０はシステム全体の制御などを行う。操作部５２１はスキャナをユーザが操作するためのものである。ＲＯＭ５２６には制御プログラムなどが格納され、ＲＡＭ５２８はＣＰＵ５２０のワーク領域として機能する。
【０１３２】
光源、光電変換器などからなる画像読み取り部（データを取り込むための装置）５２２により原稿の画像が読み取られ、読み取られた画像のデータは画像処理部５２４により処理される。そして、処理後の画像データがバス５０５を介してデータ転送制御装置５００に直接送られる。データ転送制御装置５００は、この画像データにヘッダなどを付加することでパケットを生成し、ＰＨＹデバイス５０２を介してパーソナルコンピュータなどの他のノードに送信する。
【０１３３】
図２１（Ｃ）に電子機器の１つであるＣＤ−ＲＷドライブの内部ブロック図を示し、図２２（Ｃ）にその外観図を示す。ＣＰＵ５３０はシステム全体の制御などを行う。操作部５３１はＣＤ−ＲＷをユーザが操作するためのものである。ＲＯＭ５３６には制御プログラムなどが格納され、ＲＡＭ５３８はＣＰＵ５３０のワーク領域として機能する。
【０１３４】
レーザ、モータ、光学系などからなる読み取り＆書き込み部（データを取り込むための装置又はデータを記憶するための装置）５３３によりＣＤ−ＲＷ５３２から読み取られたデータは、信号処理部５３４に入力され、エラー訂正処理などの所与の信号処理が施される。そして、信号処理が施されたデータが、バス５０６を介してデータ転送制御装置５００に直接送られる。データ転送制御装置５００は、このデータにヘッダなどを付加することでパケットを生成し、ＰＨＹデバイス５０２を介してパーソナルコンピュータなどの他のノードに送信する。
【０１３５】
一方、ＰＨＹデバイス５０２、データ転送制御装置５００を介して、他のノードから送られてきたデータは、バス５０６を介して信号処理部５３４に直接送られる。そして、信号処理部５３４によりこのデータに所与の信号処理が施され、読み取り＆書き込み部５３３によりＣＤ−ＲＷ５３２に記憶される。
【０１３６】
なお、図２２（Ａ）、（Ｂ）、（Ｃ）において、ＣＰＵ５１０、５２０、５３０の他に、データ転送制御装置５００でのデータ転送制御のためのＣＰＵを別に設けるようにしてもよい。
【０１３７】
また、図２２（Ａ）、（Ｂ）、（Ｃ）ではＲＡＭ５０１（図４のＲＡＭ８０に相当）がデータ転送制御装置５００の外部に設けられているが、ＲＡＭ５０１をデータ転送制御装置５００に内蔵させてもよい。
【０１３８】
本実施形態のデータ転送制御装置を電子機器に用いることで、高速なデータ転送が可能になる。従って、ユーザがパーソナルコンピュータなどによりプリントアウトの指示を行った場合に、少ないタイムラグで印字が完了するようになる。また、スキャナへの画像取り込みの指示の後に、少ないタイムラグで読み取り画像をユーザは見ることができるようになる。また、ＣＤ−ＲＷからのデータの読み取りや、ＣＤ−ＲＷへのデータの書き込みを高速に行うことができるようになる。更に、例えば１つのホストシステムに複数の電子機器を接続して利用したり、複数のホストシステムに複数の電子機器を接続して利用したりすることも容易になる。
【０１３９】
また本実施形態のデータ転送制御装置を電子機器に用いることで、ＣＰＵ上で動作するファームウェアの処理負担が軽減され、安価なＣＰＵや低速のバスを用いることが可能になる。更に、データ転送制御装置の低コスト化、小規模化を図れるため、電子機器の低コスト化、小規模化も図れるようになる。
【０１４０】
なお本実施形態のデータ転送制御装置を適用できる電子機器としては、上記以外にも例えば、種々の光ディスクドライブ（ＣＤ−ＲＯＭ、ＤＶＤ）、光磁気ディスクドライブ（ＭＯ）、ハードディスクドライブ、ＴＶ、ＶＴＲ、ビデオカメラ、オーディオ機器、電話機、プロジェクタ、パーソナルコンピュータ、電子手帳、ワードプロセッサなど種々のものを考えることができる。
【０１４１】
なお、本発明は本実施形態に限定されず、本発明の要旨の範囲内で種々の変形実施が可能である。
【０１４２】
例えば、本発明のデータ転送制御装置の構成は、図４に示す構成が特に望ましいが、これに限定されるものではない。
【０１４３】
また、パケットのヘッダやデータを無効にする手法は、本実施形態で説明したものが特に望ましいが、これに限定されるものではない。
【０１４４】
また、本発明は、少なくともＩＥＥＥ１３９４の思想に基づくものであれば、ＩＥＥＥ１３９４を発展させた規格におけるデータ転送にも適用できる。
【図面の簡単な説明】
【図１】ＩＥＥＥ１３９４の層構造について示す図である。
【図２】ＳＢＰ−２について説明するための図である。
【図３】ＩＥＥＥ１３９４規格の、非同期でブロックデータを有するパケットのフォーマットである。
【図４】本実施形態のデータ転送制御装置の構成例を示す図である。
【図５】ＲＡＭ（パケット記憶手段）の分離（分割）手法について説明するための図である。
【図６】比較例の構成について示す図である。
【図７】図６の構成によるデータ転送の手法について説明するための図である。
【図８】本実施形態のデータ転送の手法について説明するための図である。
【図９】リンクコア、ＤＭＡＣ、ＦＩＦＯの詳細な構成例について示す図である。
【図１０】ＲＡＭに格納される、非同期受信でブロックデータを有するパケットのヘッダ部分のフォーマットである。
【図１１】ＴＡＧについて説明するための図である。
【図１２】通常時の受信動作について説明するためのタイミング波形図である。
【図１３】ヘッダＣＲＣエラーの時の受信動作について説明するためのタイミング波形図である。
【図１４】ヘッダＣＲＣエラーの時にヘッダポインタを前の位置に戻す手法について説明するための図である。
【図１５】Ｕｎｋｔｃｏｄｅの時の受信動作について説明するためのタイミング波形図である。
【図１６】データＣＲＣエラーの時の受信動作について説明するためのタイミング波形図である。
【図１７】データＣＲＣエラーの時にデータポインタを前の位置に戻す手法について説明するための図である。
【図１８】第１のモードでブロードキャストパケットを受信した時の動作について説明するためのタイミング波形図である。
【図１９】図１９（Ａ）、（Ｂ）は、比較例及び本実施形態においてファームウェアが行う処理について示すフローチャートである。
【図２０】図２０（Ａ）、（Ｂ）も、比較例及び本実施形態においてファームウェアが行う処理について示すフローチャートである。
【図２１】図２１（Ａ）、（Ｂ）、（Ｃ）は、種々の電子機器の内部ブロック図の例である。
【図２２】図２２（Ａ）、（Ｂ）、（Ｃ）は、種々の電子機器の外観図の例である。
【符号の説明】
１０ ＰＨＹインターフェース
２０ リンクコア
２２ レジスタ
２３ ＨＣＥレジスタ
２４ ＵＮＫレジスタ
２５ ＢＣレジスタ
３０ ＦＩＦＯ（ＡＴＦ）
３２ ＦＩＦＯ（ＩＴＦ）
３４ ＦＩＦＯ（ＲＦ）
４０ ＤＭＡＣ（ＡＴＦ用）
４２ ＤＭＡＣ（ＩＴＦ用）
４４ ＤＭＡＣ（ＲＦ用）
４６ レジスタ
５０ ポートインターフェース
５２ ＦＩＦＯ（ＰＦ）
５４ ＤＭＡＣ（ＰＦ用）
５６ レジスタ
６０ ＣＰＵインターフェース
６２ アドレスデコーダ
６３ データ同期化回路
６４ 割り込みコントローラ
６６ ＣＰＵ
６８ クロック制御回路
７０ バッファマネージャ
７２ レジスタ
７４ 調停回路
７６ シーケンサ
８０ ＲＡＭ（パケット記憶手段）
８４ ＳＢＰ−２コア
８６ ＤＭＡＣ（ＳＢＰ−２用）
９０、９２、９４ バス（第１のバス）
９５、９６ バス（第２のバス）
９９ バス（第５のバス）
１００、１０２、１０４、１０５、
１０６、１０７、１０８、１０９ バス（第３のバス）
１１０ バス（第４のバス）
１２０ データ転送制御装置
１２２ ＰＨＹデバイス
１２４ アプリケーション層のデバイス
１３０ バス監視回路
１３２ 直列・並列変換回路
１４２ パケット診断回路
１６０ パケット整形回路
１６２ ＴＡＧ生成回路
１６４ ステータス生成回路
１６６ エラーチェック回路
１６７ シーケンサ
１６８ バッファ
１７０ セレクタ
１８０ パケット分離回路
１８２ ＴＡＧ判別回路
１８４ ポインタ更新回路
１８８ アドレス発生回路
１９０ アクセス要求実行回路
１９２ アドレス要求発生回路
３００ ＲＡＭ領域管理回路
Claims (11)
- バスに接続される複数のノード間でＩＥＥＥ１３９４の規格に準拠したデータ転送を行うためのデータ転送制御装置であって、
ノード間でのパケット転送のためのサービスを提供するリンク回路と、
前記リンク回路を介して受信したパケットを、ランダムアクセス可能なパケット記憶手段に書き込む書き込み回路とを含み、
前記リンク回路が、
他のノードから受信したパケットのヘッダに含まれるヘッダＣＲＣ又はトランザクションコードをチェックし、パケットのヘッダにＣＲＣエラーがあると判断した場合又はパケットのトランザクションコードが不知のコードであると判断した場合には、該パケットを無効にする処理を行い、
パケットのヘッダにＣＲＣエラーがあると判断した場合又はパケットのトランザクションコードが不知のコードであると判断した場合には、受信完了ステータスを不生成にすることを特徴とするデータ転送制御装置。 - 請求項１において、
パケットのヘッダにＣＲＣエラーがあると判断した場合には、前記パケット記憶手段のヘッダ領域での受信済み位置を指すヘッダポインタを、１つ前のパケットの受信完了時に指していた位置に戻すことで、該パケットを無効にすることを特徴とするデータ転送制御装置。 - 請求項１又は２において、
ヘッダＣＲＣエラーが発生したことを示すステータス情報を記憶する手段を含むことを特徴とするデータ転送制御装置。 - 請求項１乃至３のいずれかにおいて、
不知のコードのパケットを受信したことを示すステータス情報を記憶する手段を含むことを特徴とするデータ転送制御装置。 - 請求項１乃至４のいずれかにおいて、
パケットのトランザクションコードが不知のコードであると判断した場合には、前記パケット記憶手段に該パケットを書き込まないようにすることで、該パケットを無効にすることを特徴とするデータ転送制御装置。 - バスに接続される複数のノード間でＩＥＥＥ１３９４の規格に準拠したデータ転送を行うためのデータ転送制御装置であって、
ノード間でのパケット転送のためのサービスを提供するリンク回路と、
前記リンク回路を介して受信したパケットを、ランダムアクセス可能なパケット記憶手段に書き込む書き込み回路とを含み、
前記リンク回路が、
他のノードから受信したパケットのデータに含まれるデータＣＲＣをチェックし、パケットのデータにＣＲＣエラーがあると判断した場合には、該パケットのヘッダを有効にし、該パケットのデータを無効にする処理を行うことを特徴とするデータ転送制御装置。 - 請求項６において、
パケットのデータにＣＲＣエラーがあると判断した場合には、前記パケット記憶手段のヘッダ領域での受信済み位置を指すヘッダポインタについては戻さず、前記パケット記憶手段のデータ領域での受信済み位置を指すデータポインタを、１つ前のパケットの受信完了時に指していた位置に戻すことで、該パケットのデータを無効にすることを特徴とするデータ転送制御装置。 - バスに接続される複数のノード間でＩＥＥＥ１３９４の規格に準拠したデータ転送を行うためのデータ転送制御装置であって、
ノード間でのパケット転送のためのサービスを提供するリンク回路と、
前記リンク回路を介して受信したパケットを、ランダムアクセス可能なパケット記憶手段に書き込む書き込み回路と、
受信したブロードキャストパケットを無効にする第１のモードと、受信したブロードキャストパケットを有効にする第２のモードとを設定するための手段とを含み、
前記リンク回路が、
他のノードから受信したパケットのヘッダに含まれるデスティネーションＩＤをチェックし、パケットがブロードキャストパケットであると判断し且つ前記第１のモードに設定されていた場合には、該パケットを無効にする処理を行うことを特徴とするデータ転送制御装置。 - 請求項８において、
パケットがブロードキャストパケットであると判断し且つ前記第１のモードに設定されていた場合には、前記パケット記憶手段に該パケットを書き込まないようにすることで、該パケットを無効にすることを特徴とするデータ転送制御装置。 - 請求項１乃至９のいずれかのデータ転送制御装置と、
前記データ転送制御装置及びバスを介して他のノードから受信したデータに所与の処理を施す装置と、
処理が施されたデータを出力又は記憶するための装置とを含むことを特徴とする電子機器。 - 請求項１乃至９のいずれかのデータ転送制御装置と、
前記データ転送制御装置及びバスを介して他のノードに送信するデータに所与の処理を施す装置と、
処理が施されるデータを取り込むための装置とを含むことを特徴とする電子機器。
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP20124999A JP3584789B2 (ja) | 1999-07-15 | 1999-07-15 | データ転送制御装置及び電子機器 |
| US09/787,129 US6725413B1 (en) | 1999-07-15 | 2000-07-12 | Data transfer control device and electronic equipment |
| PCT/JP2000/004638 WO2001006711A1 (fr) | 1999-07-15 | 2000-07-12 | Controleur de transfert de donnees et dispositif electronique |
| TW089114133A TW513881B (en) | 1999-07-15 | 2000-07-14 | Data transfer controller and electronic device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP20124999A JP3584789B2 (ja) | 1999-07-15 | 1999-07-15 | データ転送制御装置及び電子機器 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001036548A JP2001036548A (ja) | 2001-02-09 |
| JP3584789B2 true JP3584789B2 (ja) | 2004-11-04 |
Family
ID=16437821
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP20124999A Expired - Fee Related JP3584789B2 (ja) | 1999-07-15 | 1999-07-15 | データ転送制御装置及び電子機器 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US6725413B1 (ja) |
| JP (1) | JP3584789B2 (ja) |
| TW (1) | TW513881B (ja) |
| WO (1) | WO2001006711A1 (ja) |
Families Citing this family (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1178620A1 (fr) * | 2000-07-31 | 2002-02-06 | Koninklijke Philips Electronics N.V. | Procédé et systeme pour la synchronisation de trame |
| US20030118022A1 (en) * | 2001-12-21 | 2003-06-26 | Chip Engines | Reconfigurable data packet header processor |
| JP4098987B2 (ja) * | 2002-01-31 | 2008-06-11 | 富士通株式会社 | インターフェース変換システム及びデータ転送方法 |
| US20050289148A1 (en) * | 2004-06-10 | 2005-12-29 | Steven Dorner | Method and apparatus for detecting suspicious, deceptive, and dangerous links in electronic messages |
| KR100567309B1 (ko) | 2004-06-15 | 2006-04-04 | 삼성전자주식회사 | 데이터 헤더 오류 체크를 통한 버스 사용 효율 향상 방법 |
| US7664898B2 (en) * | 2006-02-01 | 2010-02-16 | Broadcom | Method and system for efficient framing on addressed buses |
| JP2009246587A (ja) | 2008-03-31 | 2009-10-22 | Hitachi Communication Technologies Ltd | Ｏｆｄｍ信号を受信する通信装置、ｏｆｄｍ無線通信システム及びｏｆｄｍ受信方法 |
| US20090268736A1 (en) * | 2008-04-24 | 2009-10-29 | Allison Brian D | Early header CRC in data response packets with variable gap count |
| US20090268727A1 (en) * | 2008-04-24 | 2009-10-29 | Allison Brian D | Early header CRC in data response packets with variable gap count |
| US20090271532A1 (en) * | 2008-04-24 | 2009-10-29 | Allison Brian D | Early header CRC in data response packets with variable gap count |
| JP5350927B2 (ja) * | 2009-07-29 | 2013-11-27 | アルパイン株式会社 | 通信装置および通信チップからの受信データ取得方法 |
| US9846664B2 (en) | 2010-07-09 | 2017-12-19 | Cypress Semiconductor Corporation | RFID interface and interrupt |
| US8686836B2 (en) * | 2010-07-09 | 2014-04-01 | Cypress Semiconductor Corporation | Fast block write using an indirect memory pointer |
| US9092582B2 (en) | 2010-07-09 | 2015-07-28 | Cypress Semiconductor Corporation | Low power, low pin count interface for an RFID transponder |
| US8957763B2 (en) | 2010-07-09 | 2015-02-17 | Cypress Semiconductor Corporation | RFID access method using an indirect memory pointer |
| JP5907099B2 (ja) * | 2013-03-21 | 2016-04-20 | 日本電気株式会社 | 入出力処理装置、アドレス正当性検証方法およびアドレス正当性検証用プログラム |
| WO2015167475A1 (en) * | 2014-04-29 | 2015-11-05 | Hewlett-Packard Development Company, L.P. | Updating a pointer based on a validation of a packet |
| JP7270387B2 (ja) * | 2019-01-15 | 2023-05-10 | キヤノン株式会社 | 画像処理装置、画像処理装置の制御方法、およびプログラム |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2173738B (en) * | 1985-04-19 | 1989-07-12 | Roneo Alcatel Ltd | Secure transport of information between electronic stations |
| JPH05227180A (ja) * | 1992-02-14 | 1993-09-03 | Nec Corp | ネットワークの中継装置 |
| JPH06350611A (ja) * | 1993-06-14 | 1994-12-22 | Mitsubishi Electric Corp | 通信処理方式 |
| JP3190214B2 (ja) * | 1994-09-07 | 2001-07-23 | 株式会社東芝 | データ送受信システム |
| US6018816A (en) * | 1997-04-04 | 2000-01-25 | Canon Kabushiki Kaisha | Information processing system and method, image processing system and method, information processing apparatus and computer readable memory |
| US6185207B1 (en) * | 1997-06-19 | 2001-02-06 | International Business Machines Corporation | Communication system having a local area network adapter for selectively deleting information and method therefor |
| JP3837843B2 (ja) * | 1997-06-23 | 2006-10-25 | ソニー株式会社 | シリアルインタフェース回路 |
-
1999
- 1999-07-15 JP JP20124999A patent/JP3584789B2/ja not_active Expired - Fee Related
-
2000
- 2000-07-12 WO PCT/JP2000/004638 patent/WO2001006711A1/ja active Application Filing
- 2000-07-12 US US09/787,129 patent/US6725413B1/en not_active Expired - Fee Related
- 2000-07-14 TW TW089114133A patent/TW513881B/zh not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| WO2001006711A1 (fr) | 2001-01-25 |
| US6725413B1 (en) | 2004-04-20 |
| JP2001036548A (ja) | 2001-02-09 |
| TW513881B (en) | 2002-12-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3584789B2 (ja) | データ転送制御装置及び電子機器 | |
| JP3543647B2 (ja) | データ転送制御装置及び電子機器 | |
| JP3543649B2 (ja) | データ転送制御装置及び電子機器 | |
| US6857028B1 (en) | Data transfer control device and electronic equipment | |
| JP3785747B2 (ja) | シリアルインタフェース回路およびその信号処理方法 | |
| JP3733699B2 (ja) | シリアルインタフェース回路 | |
| US6978327B1 (en) | Data transfer control device and electronic equipment for performing data | |
| JP3494041B2 (ja) | データ転送制御装置及び電子機器 | |
| JP3494040B2 (ja) | データ転送制御装置及び電子機器 | |
| US6834316B1 (en) | Data transfer controller and electronic device | |
| JPH1117710A (ja) | シリアルインタフェース回路 | |
| JP4582180B2 (ja) | データ伝送装置 | |
| JP3610982B2 (ja) | データ転送制御装置及び電子機器 | |
| JPH11308300A (ja) | シリアルインタフェース回路 | |
| JP2004118704A (ja) | インターフェイス装置およびインターフェイス装置の制御方法 | |
| JPH1117774A (ja) | シリアルインタフェース回路 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040224 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040426 |
|
| 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: 20040713 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040726 |
|
| 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: 20070813 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080813 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080813 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090813 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090813 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100813 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110813 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120813 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130813 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |