JP2000174779A

JP2000174779A - データ処理装置

Info

Publication number: JP2000174779A
Application number: JP34767598A
Authority: JP
Inventors: Mitsuru Shimada; 満島田; Shinichiro Ikoma; 伸一郎生駒; Atsushi Takegami; 篤竹上; Sachiko Oda; 祥子小田
Original assignee: Texas Instruments Japan Ltd
Current assignee: Texas Instruments Japan Ltd
Priority date: 1998-12-08
Filing date: 1998-12-08
Publication date: 2000-06-23
Anticipated expiration: 2018-12-08
Also published as: JP4112716B2

Abstract

(57)【要約】【課題】IEEE1394規格準拠のシリアルバスを用いてデー
タ通信を行うデータ処理装置の、データ送受信の効率低
下を抑止する。【解決手段】データ処理装置１は、演算器９と比較器８
とを有している。演算器９は、これから送出しようとす
る送出予定のリクエストパケットに応答する受信予定の
レスポンスパケットのデータサイズを求め、比較器８
は、受信予定のレスポンスパケットのデータサイズと、
受信バッファ７の空き容量とを比較し、受信バッファ７
の空き容量が受信予定のレスポンスパケットのデータサ
イズよりも小さいときには、パケット送信装置３に、送
出予定のリクエストパケットをIEEE1394バス６に送出さ
せないようにしているので、受信バッファ７の空き容量
が少なくて、レスポンスパケットが受信できないような
場合には、リクエストパケットを送出させないようにす
ることができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はデータ処理装置に関
し、特にIEEE1394規格に準拠したシリアルバスを介して
パケット単位でデータの送受信を行うシステムに用いら
れるデータ処理装置に関する。

【０００２】

【従来の技術】従来では、パソコン等のデータ処理装置
で画像データや音声データを取り込んだり、ＡＶ機器を
コントロールするためには、ビデオキャプチャボードや
ＲＳ２３２Ｃバス等が個別に必要であり、統一した取り
扱いをすることはできなかった。

【０００３】そこで近年では、マルチメディア時代のデ
ータ通信に適した規格が提案されており、例えば、「IE
EE1394ハイパフォーマンスシリアルバス規格(以下、IEE
E1394規格という)」により、高速大容量の通信を自由に
行えるような環境整備がなされている。

【０００４】図４の符号１０１に、従来のデータ処理装
置の一例を示す。このデータ処理装置１０１は、IEEE13
94規格に準拠し、パケット単位でデータの転送が可能な
シリアルバス(以下でIEEE1394バスと称する)１０６に接
続されている。このIEEE1394バス１０６には、他のデー
タ処理装置が複数個接続されており、データ処理装置１
０１は、IEEE1394バス１０６を介して他のデータ処理装
置に、リクエストパケットを送信し、リクエストパケッ
トを送信した他のデータ処理装置に、リクエストパケッ
トに対応したレスポンスパケットを生成させ、一連のレ
スポンスパケットを取得することができるように構成さ
れている。

【０００５】このデータ処理装置１０１は、パケット処
理装置１０２と、送信装置１０３と、パケット受信装置
１０４と、送信バッファ１０５と、受信バッファ１０７
とをそれぞれ１個ずつ有している。このうち、送信装置
１０３は、複数のパケット送信装置を有しており、ここ
では、３個のパケット送信装置１０３₁〜１０３₃を有し
ているものとする。

【０００６】パケット処理装置１０２の出力は、送信バ
ッファ１０５の入力に、送信バッファ１０５の出力は、
送信装置１０３の入力にそれぞれ接続されており、送信
装置１０３の出力は、IEEE1394バス１０６に接続されて
いる。

【０００７】データ処理装置１０１を用いて、リクエス
トパケットを送信するには、まず、パケット処理装置１
０２が所定のプログラムに従って、リクエストパケット
を次々に生成し、送信バッファ１０５へと順次出力す
る。送信バッファ１０５は、ＦＩＦＯ(First in first
out)構造のメモリから成っており、パケット処理装置１
０２で次々に生成されたリクエストパケットを一時的に
記憶する。

【０００８】送信装置１０３の各パケット送信装置１０
３₁〜１０３₃は、送信バッファ１０５に保持されている
リクエストパケットを、順次１個ずつ読み出し、IEEE13
94バス１０６へと送出する。

【０００９】リクエストパケットがIEEE1394バス１０６
へと送出されると、リクエストパケットの内容で特定さ
れた他のデータ処理装置が相手方のデータ処理装置とな
り、かかる相手方のデータ処理装置が、IEEE1394バス１
０６からリクエストパケットを順次受信し、その内容を
読み出す。相手方のデータ処理装置は、リクエストパケ
ットの内容に応じて特定されるデータを、自分自身が有
する記憶領域から読み出し、読み出したデータに所定の
情報を付して、リクエストパケットへの応答となるレス
ポンスパケットを次々に生成して、IEEE1394バス１０６
へと次々に送出する。

【００１０】IEEE1394バス１０６には、パケット受信装
置１０４の入力が、パケット受信装置１０４の出力に
は、受信バッファ１０７の入力が、それぞれ接続されて
おり、受信バッファ１０７の出力は、パケット処理装置
１０２の入力に接続されている。

【００１１】パケット受信装置１０４にレスポンスパケ
ットが到達すると、パケット受信装置１０４は、受信バ
ッファ１０７の空き容量に応じて、レスポンスパケット
が受信可能か否かを判断する。ここで「受信」とは、レ
スポンスパケットがパケット受信装置１０４に到達し、
受信バッファ１０７に保持されることまでを指してい
る。

【００１２】そして、受信バッファ１０７に、レスポン
スパケットを保持できる分の空き領域があるときには、
パケット受信装置１０４は、受信可能であると判断す
る。そして、IEEE1394バス１０６からレスポンスパケッ
トを受け取り、受信バッファ１０７に出力することで、
レスポンスパケットの受信がなされる。

【００１３】受信バッファ１０７は、入力されたレスポ
ンスパケットを一旦保持して、パケット処理装置１０２
の読み出し要求に応じてパケット処理装置１０２へと出
力する。パケット処理装置１０２へレスポンスパケット
が出力されたら、そのレスポンスパケットが占有してい
た領域は解放される。パケット処理装置１０２は、入力
されたレスポンスパケットを、所定の記憶装置に格納す
るなどの処理をする。

【００１４】上記のようにレスポンスパケットが受信さ
れたら、データ処理装置１０１は、相手方のデータ処理
装置に、「成功」のアクノレジを返して、レスポンスパ
ケットが受信されたことを通知する。なお、アクノレジ
とは、４ビットの情報等からなり、各トランザクション
が成功か、ビジーかといった情報が組み込まれているも
のである。

【００１５】上記した図４のデータ処理装置１０１で
は、パケット送信装置１０３₁〜１０３₃は、リクエスト
パケットを送出してから、そのリクエストパケットに対
応するレスポンスパケットが受信されるまでは受信待ち
状態になり、レスポンスパケットが受信されたことがパ
ケット受信装置１０４で確認されて、各パケット送信装
置１０３₁〜１０３₃に通知されるまでは、新たなリクエ
ストパケットを送出しないようにされている。

【００１６】そして、各パケット送信装置１０３₁〜１
０３₃は、受信待ち状態が解除されたら、直ちに新たな
リクエストパケットを送出できる状態に復帰するように
されている。

【００１７】このため、受信バッファ１０７の空き容量
が小さく、新たなリクエストパケットに対応するレスポ
ンスパケットを、パケット受信装置１０４が受信できな
いときであっても、パケット送信装置１０３₁〜１０３₃
は、可能な限り新たなリクエストパケットを送出してし
まうことがある。

【００１８】このような場合には、レスポンスパケット
を受信することができないため、レスポンスパケットが
到達すると、データ処理装置１０１が「ビジー」のアク
ノレジを相手方のデータ処理装置に返す。

【００１９】「ビジー」のアクノレジが返されると相手
方のデータ処理装置は、レスポンスパケットを再度送信
し(リトライ)、パケット受信装置１０４がレスポンスパ
ケットを受信できて「成功」のアクノレジが返されるま
でリトライを繰り返し、「成功」のアクノレジが返され
ないときには、所定の回数だけリトライを繰り返す。こ
の間はIEEE1394バス１０６が無駄に使われてしまうの
で、データ送受信の効率が低くなってしまう。

【００２０】特に、図４に示すようにデータ処理装置１
０１がパケット送信装置１０３₁〜１０３₃を複数有して
いるときには、複数のリクエストパケットに対応するレ
スポンスパケットが、IEEE1394バス１０６に一度に送出
されてしまい、送出された全てのレスポンスパケットの
データサイズの総和が受信バッファ１０７の空き容量を
超えてしまうことが多く、パケット受信装置１０４がこ
れら全てのレスポンスパケットを一度に受信できない状
態になってしまうことが多かった。

【００２１】

【発明が解決しようとする課題】本発明は、上記従来技
術の不都合を解決するために創作されたものであり、そ
の目的は、IEEE1394バスに接続されるデータ処理装置に
おいてデータの送受信を行なう場合に、データ送受信の
効率を高めることができる技術を提供することにある。

【００２２】

【課題を解決するための手段】上記課題を解決するため
に、本発明の請求項１に記載のデータ処理装置は、シリ
アルバスに接続され、リクエストパケットを上記シリア
ルバスに送信する送信装置と、上記シリアルバスに接続
され、上記リクエストパケットに対応するレスポンスパ
ケットを上記シリアルバスから受信する受信装置と、上
記受信装置から供給されるレスポンスパケットを保持す
る受信バッファと、上記リクエストパケットに対応する
レスポンスパケットのデータサイズと上記受信バッファ
の空き容量との大小関係を判定する判定装置とを有し、
上記送信装置は上記判定装置の判定結果に応じてリクエ
ストパケットの上記シリアルバスへの送信の制御を行な
う。

【００２３】請求項２に記載のデータ処理装置は、請求
項１に記載のデータ処理装置であって、上記送信装置を
複数個有し、上記判定装置は上記各送信装置におけるリ
クエストパケットに対応するレスポンスパケットの総デ
ータサイズと上記受信バッファの空き容量との大小関係
を判定し、上記各送信装置は上記判定装置の判定結果に
応じてリクエストパケットの上記シリアルバスへの送信
を制御する。

【００２４】また、請求項３に記載のデータ処理装置
は、請求項１又は２に記載のデータ処理装置であって、
上記リクエストパケット、上記レスポンスパケット、並
びに上記シリアルバスはIEEE1394規格に準拠するように
構成されている。

【００２５】本発明のデータ処理装置では、判定装置
が、送出予定のリクエストパケットに応じたレスポンス
パケットのデータサイズと、受信バッファの空き容量に
基づいて、送出予定のリクエストパケットを送出するこ
とが可能か否かを判定し、この判定に基づいて、送信装
置が送出予定のリクエストパケットを送出しているの
で、例えば、レスポンスパケットのデータサイズと、受
信バッファの空き容量とを比較した結果、受信バッファ
の空き容量が少なくて、レスポンスパケットを受信装置
が受信できない状態にあるときには、送信装置に、送出
予定のリクエストパケットを送出させないようにするこ
とができ、送出予定のリクエストパケットを送出すると
きには、常にレスポンスパケットを受信できるだけの空
き容量が受信バッファに確保されるようにすることがで
きる。このため、送出予定のリクエストパケットが送出
されるときには、常にレスポンスパケットを受信するこ
とが可能な状態になっている。

【００２６】従って、受信バッファの空き容量が少な
く、レスポンスパケットが受信できないときには、送出
予定のリクエストパケットは送出されないので、受信装
置で受信が拒否され、リトライが繰り返されてシリアル
バスが無駄に使われなくなる。このため、従来に比して
データ送受信の効率を高めることができる。

【００２７】また、本発明のデータ処理装置において、
送信装置が複数あるときには、送出予定のリクエストパ
ケットに応じたレスポンスパケットのデータサイズと、
受信バッファの空き容量とに加えて、未受信のレスポン
スパケットのデータサイズを参照することで、送出予定
のリクエストパケットを送出することが可能か否かを判
定している。

【００２８】このため、受信バッファの空き容量が、未
受信のレスポンスパケットのデータサイズと、受信予定
のレスポンスパケットのデータサイズとの総和よりも小
さく、未受信のレスポンスパケットと、受信予定のレス
ポンスパケットが一度に受信されようとしたときに、全
部のレスポンスパケットを受信することができない状態
にあるときには、送信装置に、送出予定のリクエストパ
ケットを送出させないようにすることができる。

【００２９】従って、未受信のレスポンスパケットと、
受信予定のレスポンスパケットが一度に生成され、続け
て受信されようとしたときにも、受信バッファにはこれ
ら全部のレスポンスパケットを保持できるだけの空き容
量が確保されていることになるので、全部のレスポンス
パケットを続けて受信することができる。

【００３０】特に、未受信のレスポンスパケットのデー
タサイズが大きい場合に、未受信のレスポンスパケット
が受信されて受信バッファの空き容量が小さくなって
も、その空き容量は、受信予定のレスポンスパケットの
データサイズよりも大きくなるので、受信予定のレスポ
ンスパケットが受信装置で受信拒否されることがなくな
る。これにより、受信装置で受信が拒否されて、リトラ
イが繰り返されることがないので、データ送受信の効率
が低下することがなくなる。

【００３１】

【発明の実施の形態】本発明の実施の形態について、図
面を参照して説明する。図１の符号１は、本実施形態の
データ処理装置１である。このデータ処理装置１は、IE
EE1394バス６に接続されている。このIEEE1394バス６に
は、他のデータ処理装置が複数個接続されており、当該
データ処理装置１は、IEEE1394バス６を介して他のデー
タ処理装置にリクエストパケットを送信し、リクエスト
パケットが送信された他のデータ処理装置に、複数のレ
スポンスパケットを生成させて一連のレスポンスパケッ
トを取得することができるように構成されている。

【００３２】このデータ処理装置１は、パケット処理装
置２と、パケット送信装置３と、パケット受信装置４
と、送信バッファ５と、受信バッファ７と、判定回路１
０とを有している。

【００３３】パケット処理装置２の出力は、送信バッフ
ァ５の入力に、送信バッファ５の出力は、パケット送信
装置３の入力にそれぞれ接続されており、パケット送信
装置３の出力は、IEEE1394バス６に接続されている。

【００３４】かかるデータ処理装置１を用いて、リクエ
ストパケットを送信する際には、まず、パケット処理装
置２がリクエストパケットを次々に生成し、送信バッフ
ァ５へと次々に出力する。

【００３５】送信バッファ５はＦＩＦＯ構造のメモリか
らなり、パケット処理装置２からリクエストパケットが
次々に入力されると、それらのリクエストパケットを一
時的に記憶する。

【００３６】パケット送信装置３は、最初に１個のリク
エストパケットを送信バッファ５から読み出して、IEEE
1394バス６へと送出する。パケット送信装置３は、リク
エストパケットを送出すると、そのリクエストパケット
に対応するレスポンスパケットが受信されたことがパケ
ット受信装置４から通知されるまで受信待ち状態にな
り、新たにリクエストパケットを送出しないようにされ
る。

【００３７】他方、リクエストパケットがIEEE1394バス
６へと送出されると、リクエストパケットの内容に応じ
て特定された他のデータ処理装置(以下で相手方のデー
タ処理装置と称する。)が、IEEE1394バス６からリクエ
ストパケットを受信し、その内容を読み出す。相手方の
データ処理装置は、リクエストパケットの内容に応じ
て、リクエストパケットへの応答となるレスポンスパケ
ットを生成して、IEEE1394バス６へと送出する。

【００３８】このIEEE1394バス６には、パケット受信装
置４の入力が、パケット受信装置４の出力には、受信バ
ッファ７の入力が、それぞれ接続されており、受信バッ
ファ７の出力は、パケット処理装置２の入力に接続され
ている。

【００３９】パケット受信装置４にレスポンスパケット
が到達すると、パケット受信装置４は、受信バッファ７
の空き容量に応じて、レスポンスパケットが受信可能か
否かを判断する。本発明で「受信」とは、レスポンスパ
ケットがパケット受信装置に到達し、受信バッファに保
持されることまでを指すものとする。

【００４０】そして、受信バッファ７に、レスポンスパ
ケットを保持できる分の空き領域があるときには、パケ
ット受信装置４は、レスポンスパケットが受信可能であ
ると判断して、IEEE1394バスからレスポンスパケットを
受けとる。

【００４１】こうしてパケット受信装置４がIEEE1394バ
ス６からレスポンスパケットを受けとって、そのレスポ
ンスパケットを受信バッファ７に出力するとともに、レ
スポンスパケットを受信した旨をパケット送信装置３に
通知する。レスポンスパケットを受信した旨が、受信待
ち状態にあったパケット送信装置３に通知されると、パ
ケット送信装置３の受信待ち状態は解除される。しか
し、後述する送出不許可の制御命令がパケット送信装置
３に入力されているときには、受信待ち状態が解除され
ている場合でも、送出予定のリクエストパケットの送出
をしないようにされる。

【００４２】受信バッファ７は、入力されたレスポンス
パケットを、内部に設けられたメモリ(図示せず)に一時
保持する。受信バッファ７がレスポンスパケットを保持
している間に、送信バッファ５には、これから送出しよ
うとするリクエストパケット(以下で送出予定のリクエ
ストパケットと称する。)が保持されており、パケット
送信装置３へと出力される。

【００４３】パケット送信装置３は、送出予定のリクエ
ストパケットが入力されると、そのデータサイズを、演
算器９に出力する。演算器９は、入力されたデータサイ
ズから、そのリクエストパケットに対応するレスポンス
パケット(以下で受信予定のレスポンスパケットと称す
る。)のデータサイズを求めて、比較器８の一方の入力
へと出力する。

【００４４】一方、パケット受信装置４の内部には検出
回路(図示せず)が設けられている。この検出回路は、受
信バッファ７内部のメモリの空き容量を常時検出してお
り、検出された空き容量を、比較器８の他方の入力へと
出力している。

【００４５】比較器８は、受信予定のレスポンスパケッ
トのデータサイズと、受信バッファ７の空き容量とを比
較する。受信バッファ７の空き容量が、受信予定のレス
ポンスパケットを受信できる程度に大きい場合には、リ
クエストパケットが送出されるが、受信済みのレスポン
スパケットがまだ受信バッファ７に保持されているた
め、受信バッファ７の空き容量が受信予定のレスポンス
パケットのデータサイズよりも小さい場合には、比較器
８は、パケット送信装置３に、送出不許可の制御命令を
出力する。この送出不許可の制御命令により、パケット
送信装置３は、受信待ち状態が解除されている場合であ
っても、送出予定のリクエストパケットの送出ができな
くなる。

【００４６】その後、受信バッファ７から受信済みのレ
スポンスパケットがパケット処理装置２に出力され、受
信済みのレスポンスパケットが占有していたメモリ領域
が解放されると、受信バッファ７のメモリの空き容量が
増える。

【００４７】こうしてメモリの空き容量が増えて受信予
定のレスポンスパケットのデータサイズよりも大きくな
った場合には、比較器８は、送出許可の制御命令をパケ
ット送信装置３に出力する。送出許可の制御命令が入力
されると、パケット送信装置３は、送出予定のリクエス
トパケットをIEEE1394バス６に送出する。

【００４８】このように、データ処理装置１では、受信
バッファ７の空き容量が、受信予定のレスポンスパケッ
トのデータサイズよりも小さく、受信予定のレスポンス
パケットを受信できる分だけ確保されていないときに
は、パケット送信装置３はリクエストパケットを送出で
きないようにされている。従って、リトライが繰り返さ
れて、バスが無駄に使われることがなくなる。

【００４９】以上までは、１個のパケット送信装置を有
しているデータ処理装置１について説明したが、送信す
るリクエストパケットの量が多いときなどに備え、パケ
ット送信装置を複数設ける場合がある。以下で、図２を
参照し、パケット送信装置を複数有するデータ処理装置
について説明する。

【００５０】図２で符号１１は本発明の他の実施形態の
データ処理装置を示している。このデータ処理装置１１
は、パケット処理装置１２と、パケット受信装置１４
と、送信バッファ１５と、受信バッファ１７と、判定回
路２０とを有している点では図１のデータ処理装置１と
同様であるが、判定回路２０がディスパチャ１９を有し
ており、ディスパッチャ１９が送信装置１３と送信バッ
ファ１５との間に配置されている点と、送信装置１３
が、複数のパケット送信装置１３₁〜１３₃を有している
点とで、図１のデータ処理装置１と異なる。ここでは、
送信装置は３個のパケット送信装置１３₁〜１３₃を有し
ているものとする。

【００５１】そして、パケット処理装置１２の出力は送
信バッファ１５の入力に、送信バッファ１５の出力はデ
ィスパッチャ１９の入力に、ディスパッチャ１９の出力
は送信装置１３の入力に、それぞれ接続されており、送
信装置１３の出力は、IEEE1394バス１６に接続されてい
る。

【００５２】以上のような構成のデータ処理装置１１に
おいて、複数のリクエストパケットを次々に送信するに
は、まず、パケット処理装置１２が、複数のリクエスト
パケットを次々に生成し、送信バッファ１５へと順次出
力する。

【００５３】図３(ａ)の符号３０に、IEEE1394規格準拠
のリクエストパケットの一般的なフォーマットの概略を
示す。このリクエストパケットは、第１のパケット領域
３１と、第２のパケット領域３２とを有しており、その
それぞれに、tLabelと、データサイズが記載されてい
る。このうちtLabelは、各機器から送信されたリクエス
トパケットやレスポンスパケット等の、未解決の各トラ
ンザクションに割り当てられた固有のタグであって、リ
クエストパケットと、レスポンスパケットとの対応をつ
けるための番号である。そして、データサイズは、１個
のリクエストパケット全体のデータサイズを示すもので
ある。

【００５４】このようなフォーマットを有するリクエス
トパケットが送信バッファ１５に入力されると、ディス
パッチャ１９は、送信バッファ１５に入力された順にこ
れらのリクエストパケットを次々に読み出し、リクエス
トパケットの第１、第２のパケット領域３１、３２か
ら、tLabelと、データサイズとをそれぞれ取得する。こ
こでは、最初に３個のリクエストパケットを読み出し、
読み出した各リクエストパケットのtLabelと、データサ
イズとをそれぞれ取得するものとする。

【００５５】ディスパッチャ１９は、これから送出しよ
うとするリクエストパケットのデータサイズから、その
リクエストパケットに対応するレスポンスパケットのデ
ータサイズをそれぞれ求め、それぞれのtLabelとデータ
サイズとを組にし、ディスパッチャ１９が有している記
憶領域に書き込む。

【００５６】図３(ｂ)の符号４０に、ディスパッチャ１
９が有している記憶領域の一例を示す。この記憶領域４
０は、第１〜第６の領域４１〜４６を有している。第１
〜第３の領域４１〜４３には、各パケット送信装置１３
₁〜１３₃から送出される各リクエストパケットのtLabel
が書き込まれるようにされており、第４〜第６の領域４
４〜４６のそれぞれには、各パケット送信装置１３₁〜
１３₃から送出されるリクエストパケットに応じて生成
されるレスポンスパケットのデータサイズが、書き込ま
れるようにされている。

【００５７】こうして、第１〜第３の領域４１〜４３に
書き込まれた各リクエストパケットのtLabelと、第４〜
第６の領域４４〜４６に書き込まれた各レスポンスパケ
ットのデータサイズが、それぞれ一対一に対応付けられ
て、一組になるようにされている。

【００５８】そして、後にリクエストパケットに対応す
るレスポンスパケットが受信されたことがディスパッチ
ャ１９に通知されたら、そのリクエストパケットのtLab
elと、レスポンスパケットのデータサイズとの組は、記
憶領域４０から消去されるようにされている。

【００５９】こうして、記憶領域４０に、各リクエスト
パケットのtLabelと、各リクエストパケットに対応する
レスポンスパケットのデータサイズをそれぞれ書き込ん
だら、ディスパッチャ１９は、パケット送信装置１３₁
〜１３₃のそれぞれへ、リクエストパケットを均等に出
力するようにされている。ここでは、３個のリクエスト
パケットを読み出しているので、パケット送信装置１３
₁〜１３₃のそれぞれへ、リクエストパケットを１個ずつ
出力する。

【００６０】各パケット送信装置１３₁〜１３₃は、入力
されたリクエストパケットを、IEEE1394バス１６へと送
出する。各パケット送信装置１３₁〜１３₃は、送出した
リクエストパケットに対するレスポンスパケットが、パ
ケット受信装置１４で受信されたことが確認されるまで
は、受信待ち状態になり、新たなリクエストパケットを
送出しないようになっている。

【００６１】各パケット送信装置１３₁〜１３₃から、IE
EE1394バス１６へとリクエストパケットが送出される
と、各リクエストパケットの内容に応じて特定される他
のデータ処理装置が、リクエストパケットをIEEE1394バ
ス１６から受信する。

【００６２】ここでは、同一の他のデータ処理装置が、
パケット送信装置１３₁〜１３₃から送信された３個のリ
クエストパケットへの応答になる３個のレスポンスパケ
ットを次々に生成するものとする。そして、パケット送
信装置１３₁から送出されたリクエストパケットに対応
するレスポンスパケットが、最初にIEEE1394バス１６へ
と送出されるものとし、パケット送信装置１３₂、１３₃
から送信されたリクエストパケットへの対応となるレス
ポンスパケットは、まだIEEE1394バス１６へと送出され
ていないものとする。

【００６３】このIEEE1394バス１６にはパケット受信装
置１４の入力が、パケット受信装置１４の出力には受信
バッファ１７の入力が、それぞれ接続されており、受信
バッファ１７の出力は、パケット処理装置１２の入力に
接続されている。

【００６４】IEEE1394バス１６からパケット受信装置１
４にレスポンスパケットが到達すると、パケット受信装
置１４は、受信バッファ１７の空き容量に応じて、レス
ポンスパケットが受信可能か否かを判断する。

【００６５】パケット受信装置１４は、受信バッファ１
７に、レスポンスパケットを保持できる分の空き領域が
あるときには、レスポンスパケットが受信可能であると
判断する。そしてパケット受信装置１４は、IEEE1394バ
ス１６から到達したレスポンスパケットを受信バッファ
１７に出力するとともに、レスポンスパケットを受信し
た旨を、パケット送信装置１３₁とディスパッチャ１９
に通知する。

【００６６】レスポンスパケットが受信されたことが通
知されると、パケット送信装置１３ ₁の受信待ち状態が
解除される。しかし、後述する送出不許可の制御命令が
パケット送信装置１３₁に入力されているときには、受
信待ち状態が解除された場合でも、送出予定のリクエス
トパケットの送出ができないようにされる。

【００６７】一方ディスパッチャ１９は、レスポンスパ
ケットを受信したことが通知されたら、記憶領域４０の
第１、第４の領域部４１、４４から、受信済みのレスポ
ンスパケットに対応するリクエストパケットのtLabel
と、上記レスポンスパケットのデータサイズとを消去す
る。

【００６８】受信バッファ１７は、入力された受信済み
のレスポンスパケットを一時保持する。受信バッファ１
７が受信済みのレスポンスパケットを保持している間
に、送信バッファ１５から、これから送出されようとす
るリクエストパケット(以下で送出予定のリクエストパ
ケットと称する。)が、ディスパッチャ１９に出力され
る。

【００６９】ディスパッチャ１９は、送出予定のリクエ
ストパケットから、そのtLabelとデータサイズとを取得
し、送出予定のリクエストパケットに対応するレスポン
スパケット(以下で受信予定のレスポンスパケットと称
する)のデータサイズを求め、tLabelとともに一対一に
対応付け、一組にして記憶領域４０の第１、第４の領域
４１、４４に書き込む。

【００７０】すると、この時点で記憶領域４０には、そ
れぞれパケット送信装置１３₂、１３ ₃から送出され、ま
だパケット受信装置１４に受信されていないリクエスト
パケット(以下で未受信のリクエストパケットと称す
る。)のtLabelと、そのリクエストパケットに対応する
未受信のレスポンスパケットのデータサイズとに加え
て、送出予定のリクエストパケットのtLabelと、受信予
定のレスポンスパケットのデータサイズとが書き込まれ
ていることになる。

【００７１】ディスパッチャ１９は、記憶領域４０に書
き込まれた未受信のレスポンスパケットのデータサイズ
と、受信予定のレスポンスパケットのデータサイズとの
総和(以下で未受信及び受信予定のレスポンスパケット
のデータサイズの総和と称する)を求める。こうして求
められた未受信及び受信予定のレスポンスパケットのデ
ータサイズとの総和は、比較器１８の一方の入力へと入
力される。

【００７２】パケット受信装置１４には、検出回路(図
示せず)が設けられており、受信バッファ１７の空き容
量が常時検出されている。こうして検出回路で検出され
た受信バッファ１７の空き容量は、比較器１８の他方の
入力に入力される。

【００７３】比較器１８は、未受信及び受信予定のレス
ポンスパケットのデータサイズの総和と、受信バッファ
１７の空き容量とを常時比較している。この時点で、未
受信のレスポンスパケットは、パケット送信装置１
３₂、１３₃から出力されたリクエストパケットに対応し
たレスポンスパケットであって、受信予定のレスポンス
パケットは、パケット送信装置１３₂、１３₃から出力さ
れたリクエストパケットに対応するレスポンスパケット
であるものとする。

【００７４】受信バッファ１７の空き容量が、未受信及
び受信予定のレスポンスパケットのデータサイズの総和
よりも大きい場合には、比較器１８は送出許可の制御命
令をパケット送信装置１３₁に出力する。この制御命令
が入力されると、パケット送信装置１３₁は、送出予定
のリクエストパケットをIEEE1394バス１６に送出する。

【００７５】一方、受信バッファ１７の空き容量が、未
受信及び受信予定のレスポンスパケットのデータサイズ
の総和よりも少ない場合には、比較器１８は、パケット
送信装置１３₁に、送出不許可の制御命令を出力する。

【００７６】この制御命令により、受信待ち状態が解除
されていても、パケット送信装置１３₁は、送出予定の
リクエストパケットを送出できないようにされる。

【００７７】従来では、パケット送信装置１３₂、１３₃
から送信されたリクエストパケットに対する未受信のレ
スポンスパケットがパケット受信装置１４で受信されて
しまうと、受信バッファ１７の空き容量が少なくなっ
て、受信予定のレスポンスパケットが受信できなくなる
ことが考えられたが、本発明では、受信バッファ１７の
空き容量が受信予定のレスポンスパケットのデータサイ
ズよりも小さくなるときには、送出予定のリクエストパ
ケットは出力できなくなるので、送出予定のリクエスト
パケットが送出されるときには、常に受信予定のレスポ
ンスパケットのデータサイズ分の空き容量が、受信バッ
ファ１７に確保されていることになる。

【００７８】従って、送出予定のリクエストパケットが
送出されるときには、常に受信予定のレスポンスパケッ
トは受信可能な状態にある。受信バッファ１７から受信
済みのレスポンスパケットがパケット処理装置１２に出
力され、受信済みのレスポンスパケットが占有していた
メモリ領域が解放されると、受信バッファ１７の空き容
量が増える。こうして受信バッファ１７の空き容量が増
えて未受信及び受信予定のレスポンスパケットのデータ
サイズの総和よりも多くなったら、比較器１８は、送出
許可の制御命令をパケット送信装置１３₁に出力する。

【００７９】後に、未受信のレスポンスパケットがパケ
ット受信装置で受信されると、パケット送信装置１
３₂、１３₃の受信待ち状態が解除されるが、各パケット
送信装置１３₂、１３₃もまた、パケット送信装置１３₁
と同様に、送出許可の制御命令が出力されるまでは新た
なリクエストパケットを送出できないようにされてい
る。

【００８０】以上説明したように、データ処理装置１１
では、ディスパッチャ１９で求められた未受信及び受信
予定のレスポンスパケットのデータサイズの総和と、受
信バッファ１７の空き容量とを比較器１８で比較し、受
信バッファ１７の空き容量が未受信及び受信予定のレス
ポンスパケットのデータサイズの総和よりも小さいとき
には、パケット送信装置１３₁〜１３₃が受信待ち状態に
なっていなくとも、送出予定のリクエストパケットを送
信できないようにし、受信バッファ１７の空き容量が未
受信及び受信予定のレスポンスパケットのデータサイズ
の総和よりも大きくなったときに、送出予定のリクエス
トパケットを送信できるようにしている。

【００８１】このため、未受信のレスポンスパケット
と、受信予定のレスポンスパケットが一度に生成され
て、次々と受信されるような状態になった場合でも、送
出予定のリクエストパケットを送出するときには、受信
バッファ１７に、未受信及び受信予定のレスポンスパケ
ットのデータサイズの総和分の空き容量が確保されてい
るので、全てのレスポンスパケットを次々に受信するこ
とができる。これにより、未受信のレスポンスパケット
が受信された場合でも、受信バッファ１７の空き容量が
少なくて、受信予定のレスポンスパケットが受信できな
くなるということがなくなる。

【００８２】従って、受信を拒否されたレスポンスパケ
ットが他のデータ処理装置から再送されることもなくな
るので、「ビジー」のアクノレジが他のデータ処理装置
側に返され、他のデータ処理装置側でリトライが繰り返
されて、バスが無駄に使われないようにすることができ
る。

【００８３】なお、図２のデータ処理装置１１では、パ
ケット送信装置１３₁〜１３₃を３個有するものとしてい
るが、本発明はこれに限らず、パケット送信装置を何個
有するものとしてもよい。このときには、ディスパッチ
ャ１９内の記憶領域４０内に、パケット送信装置の個数
に対応する数の領域を設け、各領域を各パケット送信装
置に対応付けて、それぞれの領域にtLabelやデータサイ
ズを書き込むようにすればよい。

【００８４】また、記憶領域に書き込むのは、tLabelに
限らず、例えば、各パケット送信装置１３₁〜１３₃を識
別するためにそれぞれに割り振られた機械番号と、レス
ポンスパケットのデータサイズとを組にして記憶領域に
書きこんでもよい。

【００８５】

【発明の効果】送出予定のリクエストパケットを送出す
るときには、常にレスポンスパケットを受信することが
可能な状態になり、受信バッファの空き容量が少なく、
レスポンスパケットが受信できないときには、送出予定
のリクエストパケットは送出されないので、受信装置で
受信が拒否され、リトライが繰り返される間にシリアル
バスが無駄に使われ、データ送受信の効率が低くなって
しまうことを抑止することができる。

【図面の簡単な説明】

【図１】本発明の実施形態のデータ処理装置を説明する
図

【図２】複数のパケット送信装置を有する本発明の実施
形態のデータ処理装置を説明する図

【図３】(ａ)：リクエストパケットのフォーマットを説
明する図 (ｂ)：ディスパッチャに設けられた記憶領域を説明する
図

【図４】従来のデータ処理装置を説明する図

【符号の説明】

１……データ処理装置２……パケット処理装置
３、１３₁〜１３₃……パケット送信装置(送信装置)
４……パケット受信装置(受信装置) ６……IEEE1394バ
ス(バス) ７……受信バッファ８、１８……比較器
９……演算器１０、２０…判定回路(判定手段)

───────────────────────────────────────────────────── フロントページの続き (72)発明者竹上篤東京都港区北青山３丁目６番12号青山富士ビル日本テキサス・インスツルメンツ株式会社内 (72)発明者小田祥子東京都港区北青山３丁目６番12号青山富士ビル日本テキサス・インスツルメンツ株式会社内Ｆターム(参考） 5K032 AA01 CD01 DB20

Claims

【特許請求の範囲】

【請求項１】シリアルバスに接続され、リクエストパケ
ットを上記シリアルバスに送信する送信装置と、上記シリアルバスに接続され、上記リクエストパケット
に対応するレスポンスパケットを上記シリアルバスから
受信する受信装置と、上記受信装置から供給されるレスポンスパケットを保持
する受信バッファと、上記リクエストパケットに対応するレスポンスパケット
のデータサイズと上記受信バッファの空き容量との大小
関係を判定する判定装置と、を有し、上記送信装置は上記判定装置の判定結果に応じ
てリクエストパケットの上記シリアルバスへの送信の制
御を行なうデータ処理装置。
【請求項２】上記送信装置を複数個有し、上記判定装置
は上記各送信装置におけるリクエストパケットに対応す
るレスポンスパケットの総データサイズと上記受信バッ
ファの空き容量との大小関係を判定し、上記各送信装置
は上記判定装置の判定結果に応じてリクエストパケット
の上記シリアルバスへの送信を制御する請求項１に記載
のデータ処理装置。
【請求項３】上記リクエストパケット、上記レスポンス
パケット、並びに上記シリアルバスはIEEE1394規格に準
拠するように構成されている請求項１又は２に記載のデ
ータ処理装置。