第1送受信装置および第2送受信装置を含み、複数の送受信装置が順次リング状に接続されるシステムにおいて、中継局となる送受信装置のデータ転送動作の際、転送経路においてエラーが発生した場合、前記中継局となる送受信装置が、中継する送信データの一部を内部で生成したデータに差し替えを行い、下流に送信する。前記内部で生成したデータの差し替えることは、エラーが発生した箇所を8b10bEncodingにおいて使用されていないデータパターンに差し替えることかまたは規格上使用されていないKSymbolかまたはアイドル状態を示す制御コードに差し替えることである請求項1に記載のシステム。転送経路においてエラーが発生した場合、前記中継局である送受信装置は、中継データのCRCを計算し、中継データ中のCRCに対して計算したCRCを破壊した値への差し替えを行い、受信先のホスト装置乃至前記送受信装置とは別個の送受信装置のCRCチェックでエラー検知させる請求項1に記載のシステム。複数の送受信装置が順次リング状に接続されるシステムにおいて、前記複数の送受信装置のうちの中継局となる場合の送受信装置は、データ転送動作の際、転送経路においてエラーが発生した場合、中継局である前記受信装置は、送信データ中の一部を内部で生成したデータに差し替えを行い、下流に送信する。前記装置内部で生成したデータの差し替えとは、エラーが発生した箇所を8b10bEncodingにおいて使用されていないデータパターンに差し替えることかまたは規格上使用されていないKSymbolかまたはアイドル状態を示す制御コードに差し替えることである請求項4に記載の送受信装置。転送データのエラーを認識でき、データ破壊の防止に有利な送受信装置およびこれを中継するシステムを提供する。実施形態によれば、第1送受信装置および第2送受信装置を含み、複数の送受信装置が順次リング状に接続されるシステムにおいて、中継局となる送受信装置のデータ転送動作の際、転送経路においてエラーが発生した場合、前記中継局となる送受信装置が、中継する送信データの一部を内部で生成したデータに差し替えを行い、下流に送信する。<作用効果>第2の実施形態によれば、少なくとも上記1と同様の効果が得られる。本例では、エラーが発生していると判定される場合Yesには、エラーの発生した箇所について、DSymbolから未使用のKSymbol制御コードに差し替える点で、上記第1の実施形態と相違する。例えば、上記図11bに示したように、エラーが発生している場合には、エラーの発生した箇所0xFB、0xF0について、DSymbolから未使用のKSymbol0x9Cに差し替える。続いて、差し替えられたデータに同様の8b10bEncodingを行い、次の下流のデバイスDevice1にデータを転送する。そのため、上記図11cに示すように、8b10bEncoding処理が行われた後のデータ列は、エラー発生箇所が0x0F2、0x30Dとなり、次の下流のデバイスDevice1に10b8bDecoding時にエラーを検知させることが可能となる。これは、後続の下流のデバイスDevice1では、元々エラーが発生していた箇所に、規格未定義のKSymbolを発見することになるので、正常のデータではないと判断することができるためである。[第3の実施形態CRCチェック]次に、第3の実施形態について、図13、図14を用いて説明する。この実施形態は、CRCチェックを行う際のエラー検知に関するものである。この説明において、上記説明と重複する部分の詳細な説明を省略する。<データ転送動作>本例では、データを中継する際にレイテンシを低く抑える上記第1、第2の実施形態とは異なり、データを中継する際にCRCチェックを行い、そのCRCチェックでエラーを検知する一例に関する。このように、本例では、データ転送の中継時にも、受信時と同じように受信データに対してCRC計算を行う。そして、新しく計算したCRCを最低でも1bit値を変更したもので古いCRCを差し替え、下流のデバイスに送信する点で、上記第1、第2の実施形態と相違する。このようにすることで、次の下流のデバイスでは、CRCチェックを行った結果、エラーとなるため、誤受信を防止することができる。なお、CRCはパケット内のデータに対して計算が行われ、パケットの先頭を示すCOMSOP制御コード、データ、CRC、パケットの終了を示すCOMEOPという順番で送信される。例えば、本例の場合、より具体的には、図13のように示される。まず、図13a~bに示すように、エラーによって化けたデータ0xFBは、そのまま通常のデータとみなして、CRCの再計算を行なう。ただし、元々パケット中に存在していたCRCの該当箇所本例では、COMEOPの前の2バイトデータ0x570x84に関しては、本例の計算の対象外である。このように、図中の処理4のように、新しく再計算したCRCでは該当箇所の値を反転させて古いCRCの箇所と置き換えを行う。CRCは最低1bitを反転させれば良いが、本実施例では全ビット反転させるとした。その後、同様の8b10bEncodingを行い処理5、次の下流のデバイスにデータを転送する。<データ転送フロー>本例のデータ転送フローは、図14のように示される。図示するように、まず、本例では、ステップS53の際、上流のデバイスDevice0が確認した転送データ内に、COMSOP受信後かつCOMEOPの2Byte以上前か否かの判定を行う。上記ステップS53の際に該当しないと判定される場合Noには、次のステップS55に進む。続いて、ステップS54の際、上記ステップS53の際に該当すると判定される場合Yesには、エラーの発生した箇所について、通常のCRC計算の対象とする点で、上記実施形態と相違する。続いて、ステップS55の際、COMEOPの1Byteもしくは2Byte前か否かの判定を行う。続いて、ステップS56の際、上記ステップS55の際に該当すると判定される場合Yesには、計算していたCRCを反転させる。例えば、図13に示したように、新しく再計算したCRCでは該当箇所の値を反転させて古いCRCの箇所と置き換えを行う。続いて、ステップS57に進む。続いて、ステップS57の際、上記ステップS55の際に該当しないと判定される場合Noには、同様にデータに8b10bEncodingを行い、次の下流のデバイスDevice1にデータを転送するEnd。<作用効果>第3の実施形態によれば、少なくとも上記1と同様の効果が得られる。さらに、本例では、データを中継する際にCRCチェックを行い、そのCRCチェックでエラーを検知させる。例えば、ステップS56の際、上記ステップS55の際に該当すると判定される場合Yesには、計算していたCRCを反転させる。図13に示したように、新しく再計算したCRCでは該当箇所の値を反転させて古いCRCの箇所と置き換えを行う。この操作によって、送信したデータは、下流のデバイスDevice1でCRCエラーとなるため、間接的にHostからDevice0への伝送路でエラーが発生したことを伝えることができる。そのため、誤受信を防止することができる。[第4の実施形態使用される制御コードと差し替える一例]次に、第4の実施形態について、図15、図16を用いて説明する。この実施形態は、使用される制御コードに差し替えてエラーを検知させる一例に関するものである。この説明において、上記実施形態と重複する部分の詳細な説明を省略する。<データ転送動作>本例では、規格で利用されている制御コードを使う方法に関する。第2の実施形態で説明したように、UHSII規格においてKSymbolが定められているが、制御コードはCOMというKSymbolと、もう一つのKSymbolがセットになることで、一つの意味を持つ制御コードとなる。また、制御コードには、COMLIDLやCOMDIDLのように、アイドル状態を示すだけの制御コードが定められている。そのため、本例では、アイドル状態を示すだけの制御コードを、エラーがあった箇所に埋め込むことで、続く下流のデバイスDevice1にエラーを検知させる。なお、エラーの発生までは第1の実施形態と同様である。図15a、bに示すように、処理4の際、2バイト単位でエラーが発生しているかチェックを行い、エラーが発生していた箇所0xFB0xF0には、データバースト転送中のアイドル状態を示すCOMDIDLに差し替えを行う。続いて、その後は、同様の8b10bEncodingを行い処理5、次の下流のデバイスDevice1への転送データとする。<データ転送フロー>本例のデータ転送フローは、図16のように示される。図示するように、本例では、ステップS64の際、ステップS63の際にエラーが発生していると判定される場合Yesには、該当箇所をデータバースト転送中のアイドル状態を示すCOMDIDLに差し替えを行う。例えば、図15に示したように、エラーが発生していた箇所0xFB0xF0には、データバースト転送中のアイドル状態を示すCOMDIDLに差し替えを行う。続いて、同様にデータに8b10bEncodingを行い、次の下流のデバイスDevice1にデータを転送するEnd。このように、本例では、元々エラーが発生していた箇所に、アイドル状態を示すCOMDIDLが存在することになるが、データパケット中にCOMDIDLが存在することは規格に定義されたデータ構造ではない。そのため、後続の下流のデバイスではCOMDIDLが混ざったパケットは、正常のデータではないと判断することができる。<作用効果>第4の実施形態によれば、少なくとも上記1と同様の効果が得られる。さらに、本例では、ステップS64の際、ステップS63の際にエラーが発生していると判定される場合Yesには、該当箇所をデータバースト転送中のアイドル状態を示すCOMDIDLに差し替えを行う。例えば、図15に示したように、エラーが発生していた箇所0xFB0xF0には、データバースト転送中のアイドル状態を示すCOMDIDLに差し替えを行う。このように、元々エラーが発生していた箇所に、アイドル状態を示すCOMDIDLが存在することになるが、データパケット中にCOMDIDLが存在することは規格に定義されたデータ構造ではない。そのため、後続の下流のデバイスではCOMDIDLが混ざったパケットは、正常のデータではないと判断することができる。必要に応じて、本例を適用することが可能である。[変形例]上記参考例および実施形態では、リング状にされたホスト装置Hostおよび2つのデバイスDevice0Device1を一例に挙げたが、これに限られることはない。例えば、リング状に接続されるホスト装置Hostおよび3つの以上のデバイスDevice0Device1Device2DeviceNであっても同様に適用可能である。この場合、データの中継局は、宛先局以外のデバイスが該当し得る。また、ホスト装置からデバイスへのデータ転送を例に説明したが、デバイスからホスト装置へのデータ転送においても、間に中継局が存在すれば、同様に適用可能である。また、リング接続に限られず、例えば、ホストと複数のデバイスが直列に接続される多重伝送システム等に対しても同様に適用可能である。本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。Host...ホスト装置、Device0...上流の第1送受信装置中継局、Device1...下流の第2送受信装置。[参考例]まず、参考例について、図1乃至図4を参照して、説明する。<システムリングトポロジー>まず、図1を用い、システムリングトポロジーについて説明する。図示するように、本例のシステムは、ホストHostと、2つの送受信デバイスDevice0Device1との各ノードの送信端子が次のノードの受信端子に接続される。そのため、このようなシステムを、リング輪を構成することから、リングトポロジーと称される。本例のリングトポロジーは、例えば、SDアソシエーションが策定したUHSII規格等に準拠される。このように、リングトポロジーは、複数のデバイスを接続するための接続形態の一つとして想定されるものである。ここで、上記UHSII規格に準拠したリングトポロジーでは、各ノード間でやりとりをするパケットにはヘッダが格納されており、パケット受信時にはヘッダ内に記載されている宛先IDと、自局のIDとの比較を行って、自局宛のパケットか、他局当てのパケットかの判断を行っている。しかし、例えばUHSII規格においては、パケット受信時に、パケットの内容にエラーが発生していないかを、巡回符号検査を用いて確認する必要がある。つまり一旦全データを受信し、パケットに埋め込まれているCRCの値と、受信したデータを利用して計算したCRCの値が一致し、エラーが発生していないことを確認できた場合にのみ、パケットの内容を見て宛先を判断できることになる。そのため、パケットサイズが比較的大きなデータパケットの場合に、他局宛のパケットの中継に時間がかかってしまうという傾向がある。そこで、UHSII規格においては、データパケットの転送が発生するデータバースト転送においては、パケットの中継にかかる時間を低く抑えるDataBurstStreamingという仕組みを導入している。<DataBurstStreamingの有効化フロー>図2に沿って、DataBurstStreamingの有効化フローについて説明する。ここでは、上記リングトポロジーにおいて、ホストからの送信されたパケットを受信Rxした上流のデバイスDevice0が、下流のデバイスDevice1にパケットを送信Txする場合を一例に挙げる。なお、以下のフローの制御は、後述するように、例えば、デバイスDevice0Device1内のコントローラが行う。まず、ステップS11の際、上流のデバイスDevice0は、ホストからパケットを受信する。続いて、ステップS12の際、受信したパケットのヘッダを確認する。続いて、ステップS13の際、ヘッダの内容から自局宛か否かを判定する。続いて、ステップS14の際、上記ステップS13の際に自局宛であると判定される場合Yes、自局である上流のデバイスDevice0でパケット処理を行い、このフローを終了するEnd。続いて、ステップS15の際、上記ステップS13の際に自局宛でないと判定される場合No、受信パケットを下位の局本例では、Device1に送信する。続いて、ステップS16の際、パケット受信した下流の局Device1は、フローコントロールリクエストパケットFCREQパケットか否かを判定する。FCREQパケットでないと判定される場合No、このフローを終了する。続いて、ステップS17の際、上記ステップS16の際にFCREQパケットである判定される場合Yes、DataBurstStreamingの有効化し、このフローを終了するEnd。このように、上記DataBurstStreamingフローでは、バースト転送に先立って行なわれフロー制御に使われるフローコントロールリクエストFCREQパケットを利用して、バースト転送の中継が有効化されるS17。そのため、上流のデバイスDevice0から下流のデバイスDevice1におけるパケットの中継時に、そのパケットがFCREQパケットの有無により、後続の下流のデバイスDevice1へのデータバースト転送が発生すると判断できる。そのため、続く下流のデバイスDevice1へのデータバースト中のパケットでは、ヘッダの確認などを行われず、送信されるデータをバッファリングせずにそのまま中継することができ、パケットの中継にかかる時間を低く抑えることができる。また、この中継状態では、データバーストの最後に転送される特殊な制御コードを中継したことで無効化される。次に、この動作のフローを示す。<DataBurstStreamingの無効化フロー>図3に沿って、DataBurstStreamingの無効化フローについて説明する。ここでは、上記リングトポロジーのデータ中継時において、上流のデバイスDevice0から、下流のデバイスDevice1にDataBurstStreamingの有効化により、パケットが送信Txされた場合を一例に挙げる。なお、以下のフローの制御は、同様に、例えば、デバイスDevice0Device1内のコントローラが行い、DataBurstStreamingが有効化されているのみ実行される。まず、ステップS21の際、上流のデバイスDevice0は、ホストから送信されたパケットデータを受信する。続いて、ステップS22の際、上流のデバイスDevice0は、受信したパケットを、上記DataBurstStreamingの有効化により、下流のデバイスDevice1に中継して送信する。続いて、ステップS23の際、上流のデバイスDevice0は、中継されたデータを確認する。続いて、ステップS24の際、上流のデバイスDevice0は、中継されたデータに、データバーストの最後に転送される終了制御コードEDBEndofDataBurstがあるか否かを判定する。上記ステップS24の際に、終了制御コードEDBがないと判定される場合No、このフローを終了するEnd。続いて、ステップS25の際、ステップS24の際に、上記ステップS24の際に終了制御コードEDBがあると判定される場合Yes、DataBurstStreamingを無効化し、このフローを終了するEnd。<ループバックパスLoopbackPathについて>次に、図4を用いて、上記来たデータをそのまま中継するループバックパスについて説明する。図示するように、ループバックパスについては、Deserializerの後で受信したデータを送信し直すLoopbackPathと、10b8bDecodingの後に受信したデータを送信し直すLoopbackPathという2種類が提示されている。図中に示す、8b10bEncoding、10b8bDecodingとは、8b10b符号化方式の符号化、復号化を行うブロックである。8b10b符号化方式は、8bitのデータを10bitで表現することにより、データの中にクロックや制御コードを埋め込むことができる。この方式は、例えば、イーサネット登録商標、ファイバーチャネル、IEEE1394、PCIExpress20、SerialATA、USB30など数多くの規格で採用されている。Serializerは、10bit幅のデータから、10倍の速度の1bit幅のデータに変換する。Deserializerは、その逆で、1bit幅のデータを10分の1の速度の10bit幅のデータに変換する。上記8b10bEncoding、10b8bDecoding、Serializer、Deserializerは、必要なデバイスDevice0Device1中の後述するコントローラ等が行う。上記の2種類の方法のうち、前者LoopbackPathの方法は、LoopbackPathの方法よりもデータの中継にかかるレイテンシが短いものの、8b10b符号化方式の特徴であるランニングディスパリティの保持に関して特殊な対処が必要となる。そのため、10b8bDecoding後に折り返すLoopbackPathの方が実装の観点から難易度が低く、好ましい。しかしながら、後者のLoopbackPathの方法でも、以下のような傾向が存在する。ここで、UHSII規格において、受信データは、以下の二段構えで、エラーのチェックを行なう。すなわち、110b8bDecodingにおいて10bitのデータが変換テーブルに存在するか否か28bitデータからパケットを抽出後、CRCを用いてパケットの正当性を確認するこのように、10b8bDecodingとCRCによる二重のチェックが行われることになる。しかしながら、ここで懸念されるのは、図1に示した構成において、次のような状況が発生した場合である。IHostからDevice1へデータパケットを送信する。II続いて、この際、Device0は中継局となるため、LoopbackPathの方法でデータパケットを中継する。IIIHostとDevice0間の経路においてノイズが入り、データは10b8bDecodingできないデータ化けが発生する。ここで、もしDevice0へのデータの送信だった場合には、中継局が入らないため、10b8bDecoding時にエラーを検出でき、そのデータパケットはCRCの結果に依らず無効と判断することができる。しかしながらDevice0は中継局なため、エラーが存在しているという8bitのデータを再度送信する必要がある。それは、8b10bEncodingにおいてエラー情報を伝達するという仕組み、機能は存在しないため、Device1へはエラー情報が存在しない10bitのデータが送信されることになるからである。そのため、Device1では10b8bDecodingは正常に終了し、CRCでのみパケットの正当性を確認することになる。CRCはパケットの全データのシグネチャのようなものであるため、まったく異なるデータでも可能性はとても低いものの偶然にCRCの値が一致する場合が存在する。そのため、10b8bDecodingでのエラーの検出が出来ない場合には、本来間違っているデータが正しいデータであると誤判断される可能性が上昇する。送信されたデータのエラー箇所を認識できないと、下流のデバイスDevice1ではエラーが発生したにも関わらず正しいデータであると誤認識し、結果としてデータが破壊されるおそれがある。このように、下流のデバイスDevice1がエラーデータを認識できず、そのまま受け取ってしまうという可能性が上昇してしまうため、データが破壊されるおそれがある。そこで、以下の実施形態では、上記参考例での知見を元に、上記のような受信データの誤受信を防ぐことができ、中継局となる上流のデバイスにおいて、どのようにして10b8bDecoding処理において検知したエラー情報を伝達し、次局の下流のデバイスに伝えていくかに関し、図面を参照してより具体的に説明する。尚、この説明においては、全図にわたり共通の部分には共通の参照符号を付す。[第1実施形態]次に、第1の実施形態について、図5乃至図9を用いて説明する。この説明において、上記の説明と重複する部分の詳細な説明を省略する。<1送受信装置Device0の構成例>まず、図5を用い、第1の実施形態に係る送受信装置本例では、半導体記憶装置の構成例について説明する。ここでは、一例として上記UHSII規格に準拠されるシステムリングトポロジーに配置される1つの送受信デバイスDevice0を一例に挙げる。ここで、図示するDevice0は、例えば、SDカード登録商標などに代表されるような、NANDFlashMemory11を実装したDeviceのブロック図である。しかしながら、ここに示したメモリデバイス構成に限れない。本例は、下記に説明するController12内のHostInterfaceController21に関連する技術においては、例えばMemoryController12とNANDFlashMemory11の替わりに、無線LANInterfaceを実装した無線LANカードのような送受信Deviceにおいても適用可能である。図示するように、本例に係るデバイスDevice0は、NAND型フラッシュメモリ11、およびこのNAND型フラッシュメモリ11を制御するコントローラ12を備える。NAND型フラッシュメモリNANDFlashMemory11は、ワード線およびビット線の交差位置にマトリックス状に配置される複数のメモリセルを有するメモリセルアレイに、データを不揮発に記憶する。メモリセルのそれぞれは、半導体基板上に順次積層されるトンネル絶縁膜、電荷蓄積層、電極間絶縁膜、制御ゲートを備える。制御ゲートは、上記ワード線に接続される。メモリセルの電流経路は、ビット線方向に複数個接続され、メモリセルユニットを形成する。また、データ書き込み、データ読み出しは、ワード線単位ページ単位で行われる。データ消去は、ブロック単位で一括して行われる。コントローラController12は、ホストインターフェイス21、MPU22、バッファ23、およびメモリコントローラ24を備える。ホストインターフェイスHostInterfaceController21は、このデバイスの外部からのコマンドパケットやデータパケットの受信RXおよび送信TXの際の所定の変換、例えば8b10bEncoding処理、10b8bDecoding処理、Serialize処理、Deserialize処理、CRC付加処理、CRCチェック処理を行う。MPU22は、このコントローラ12全体の制御を行う。バッファBuffer23は、ホストインターフェイス21やメモリコントローラ24からのデータや制御プログラム等を展開し、記憶する。メモリコントローラMemoryController24は、MPU22の制御を受け、NAND型フラッシュメモリ11の制御を行う。<2データ転送動作>次に、上記構成おけるデータ転送動作について説明する。2-1.エラー情報の発生についてまず、図6乃至図8を用い、データ転送動作の際のエラー情報の発生までについて説明する。ここでは、上記図1に示したメモリシステムリングトポロジーにおいて、ホストHostから送信されたデータについて、上流の中継局としてのデバイスDevice0が、下流のデバイスDevice1に対して、データを転送する場合を一例に挙げて以下説明する。また、以下の動作については、コントローラ12がその制御を行う。まず、図6aに示すように、ホストは、8bデータ列HostTxSide8bを、上流のデバイスDevice0に送信するため、このデータ列中のデータとシンボル情報Symbolに対して8b10bEncoding処理1を行い、図6bに示す10bのデータ列HostTxSide10bに変換する。ここで、KSymbolとは8b10b符号化において、8bitの情報を10bitで表現することにより、余った10bitのパターンのうち、いくつかを制御コードとして利用するためのコードである。例えば、UHSII規格において使用されるKSymbolの詳細については、次に第2の実施形態で後述する。続いて、ホストから送信された10bのデータ列は伝送路を通り、HostからDevice0へ転送が行われる。実際には送信側のSerialize処理によって1bitのビット列に変換され伝送路を通り、受信側でDeserialize処理されることで10bitのデータ列に変換されるが、簡略化のため、10bit単位で説明を行なう。また、以後の例でも同様である。この間にエラーが発生し2、10bのデータ列の値が化け、図6cに示すDevice0RxSide10bで示されるデータ列になるとする。本例では、図6c中のデータ0x3FB0x3F0が、データ化けした箇所とする。続いて、図7cからdに示すように、Device0において、10bのデータ列を10b8bDecodingによって、8bのデータ列Device0RxSide8bに変換する3。ここでエラーが発生した箇所0x3FB0x3F0は、10b8bの変換ができない値に化けている。そのため、8bのデータ列Device0RxSide8bでは、エラーフラグ付きErrorのデータ0xFB0xF0として変換される。ここで8bデータの値は実装によって値が異なるが、本実施例では10bデータの下位8bitを抽出している。また、Symbol情報はデコードできなかったということで不明とされる。ここで、このエラーを含んだ8bのデータ列Device0RxSide8bを、そのまま下流のデバイスDevice1に転送すると、本来間違っているデータ0xFB0xF0が正しいデータであると誤判断されるおそれがある。これは、例えば、10b8bDecodingでのエラーの検出が出来ない場合にその可能性が上昇する。その結果、下流のデバイスDevice1が、エラーのデータを正しいデータとして受け取り、結果としてデータ破壊が発生してしまう。2-2.エラーデータの差し替えそこで、図8eに示すように、エラーが発生している場合には、8b10bEncodingErrorinjection処理4の際、エラーが発生している箇所0xFB0xF0に、8b10b符号化では利用されていない10bitのパターンであるに差し替えを行う。そして、下流のデバイスDevice1に、この差し替えられた後のデータ列Device0Tx10bを送信することで、次の下流のデバイスDevice1に10b8bDecoding時にエラーを検知させることが可能となる。2-3データ転送動作フロー上記データ転送動作を動作フローに示すと、図9のように示される。まず、ステップS31の際、上流のデバイスDevice0は、ホストから送信されたパケットデータを受信する。この際、受信したデータに対して、例えば、10b8bDecoding処理を行う。続いて、ステップS32の際、デバイスDevice0は、変換後の受信データを確認する。続いて、ステップS33の際、受信データにエラーが発生しているか否かを判定する。この際、コントローラ12は、例えば、エラーフラグの有無により、エラーが発生しているか否かを判定する。例えば、上記図7に示したように、エラーが発生した箇所0x3FB0x3F0は、10b8bの変換ができない値に化けているため、8bのデータ列Device0RxSide8bでは、エラーフラグ付きErrorのデータ0xFB0xF0として変換される。続いて、ステップS34の際、上記ステップS33の際にエラーが発生していると判定される場合Yesには、8b10bEncodingで割り当てられていないデータに差し替えて、下流のデバイスDevice1に送信し、このフローを終了するEnd。例えば、上記図8に示したように、エラーが発生している場合には、コントローラ12は、8b10bEncodingErrorinjection処理4の際、エラーが発生している箇所0xFB0xF0に、未登録パターンであるに差し替えを行う。そのため、下流のデバイスDevice1に、この差し替えられた後のデータ列Device0TxSide10bを送信することで、次の下流のデバイスDevice1に10b8bDecoding時にエラーを検知させることが可能となる。一方、ステップS35の際、上記ステップS33の際にエラーが発生していないと判定される場合Noには、上記のような差し替えを行わず、8b10bEncoding処理を行ったデータを、下流のデバイスDevice1に送信し、このフローを終了するEnd。<3作用効果>第1の実施形態に係る構成および動作によれば、少なくとも下記1の効果が得られる。1転送データのエラーを認識でき、データ破壊を防止できる。上記図1に示したように、本例では、ホスト装置Hostから、第1送受信装置Device0および第2送受信装置Device1を含み、複数の送受信装置が順次リング状に接続されるシステムに適用される。そして、上流のデバイスDevice0が中継局となる場合のデータ転送動作の際、伝送路においてエラーが発生した場合、上流のデバイスDevice0は、下流のデバイスDevice1宛の送信データ中のエラーが発生した箇所に割り当てられていないデータを差し替えて、送信するS34。例えば、上記図8に示したように、エラーが発生している場合には、コントローラ12は、8b10bEncodingErrorinjection処理4の際、エラーが発生している箇所0xFB0xF0に、未登録パターンであるに差し替えを行う。このように、本例では、中継局の上流側のデバイスDevice0の8b10bEncoding処理において、転送データ列中のエラー箇所を、本来8b10b変換テーブルには載っていないパターンに差し替えることにより、下流側のデバイスDevice1にエラー情報を伝達する。そのため、続く下流側のデバイスDevice1では、転送されたデータ列を10b8bDecodingする際に、当該未登録パターンに差し替えられた箇所がエラーであると認識することができ、エラーを検出できる。このように、本例では、ホストと中継局である上流のデバイスDevice0の伝送経路中に転送データにノイズ等により10b8bDecodingできないデータ化けが発生した場合であっても、下流のデバイスDevice1は、そのエラー発生の箇所を認識することができる。送信されたデータのエラー箇所を認識できないと、下流のデバイスDevice1では誤って正しいデータと認識して受理する可能性が増加し、ホストにとってはデバイスに書き込んだデータが破壊されてしまうというおそれがある。よって、転送データのエラー発生箇所を認識でき、データ破壊を防止できる点で有利である。なお、第1の実施形態では全エラーにおいて、一つの未登録パターンを利用しているが、未登録パターンを複数用意し、任意の未登録パターンを利用しても良いことは勿論である。[第2の実施形態]次に、第2の実施形態について、図10乃至図12を用いて説明する。第2の実施形態は、エラー発生箇所に、規格上利用されていないKSymbolを差し替える一例に関するものである。この説明において、上記説明と重複する部分の詳細な説明を省略する。<KSymbolについて>まず、図10を用い、KSymbolについて説明する。図示するように、KSymbolとは8b10b符号化において、8bitの情報を10bitで表現することにより、余った10bitのパターンのうち、いくつかを制御コードとして利用することである。本例で図示するものは、UHSII規格においても使用される制御コードとしてのKSymbolを一例に挙げる。例えば、図中のKSymbolK280のシンボル名はSDBであり、機能としてはデータバーストを開始することStartofDataBurstであり、値は0x1Cである。以下、同様に、図示するようなKSymbolが定められている。ここで、図中のKSymbolのうち、例えば、K282、K284、K287、K307については、利用されていない未使用のKSymbolである。本例では、以下に詳説するように、エラー発生箇所に、K284等の利用されていない未使用のKSymbolを差し替える点で、上記第1の実施形態と相違する。<データ転送動作>本例では、UHSII規格においては利用されていない図10に示した以外のKSymbolをエラーがあった箇所に埋め込むことで、後続のノードにエラーを検知させる。まず、図11を用いて、データ転送動作について説明する。なお、エラーの発生までは上記第1の実施形態と同様であるため、詳細な説明は省略する。図11bに示すように、ホストから中継局としてデータ列Device0RxSide8bを受信した上流のデバイスDevice0は、8b10bEncoding処理5の前に、エラーの発生した箇所について、DSymbolから規格では未使用のKSymbol本実施例では0x9CのKSymbolに差し替えを行なう処理4。続いて、上流のデバイスDevice0は、差し替えられたデータに同様の8b10bEncodingを行い、次の下流のデバイスDevice1にデータを転送する。<データ転送フロー>本例のデータ転送フローは、図12のように示される。図示するように、本例では、ステップS44の際、ステップS43の際にエラーが発生していると判定される場合Yesには、エラーの発生した箇所について、DSymbolから未使用のKSymbol制御コードに差し替える点で、上記第1の実施形態と相違する。例えば、上記図11bに示したように、エラーが発生している場合には、エラーの発生した箇所0xFB、0xF0について、DSymbolから未使用のKSymbol制御コードに差し替える。続いて、ステップS45の際、差し替えられたデータに同様の8b10bEncodingを行い、次の下流のデバイスDevice1にデータを転送するEnd。そのため、上記図11cに示すように、8b10bEncoding処理が行われた後のデータ列は、エラー発生箇所が0x0F2、0x30Dとなり、次の下流のデバイスDevice1に10b8bDecoding時にエラーを検知させることが可能となる。これは、後続の下流のデバイスDevice1では、元々エラーが発生していた箇所に、規格未定義のKSymbolを発見することになるので、正常のデータではないと判断することができるためである。なお、この方法では、後続のノードにおいて利用されていないKSymbolが存在した場合にどう動作するか、によって影響されるため不確定とも思われる。<作用効果>第2の実施形態によれば、少なくとも上記1と同様の効果が得られる。本例では、エラーが発生していると判定される場合Yesには、エラーの発生した箇所について、DSymbolから未使用のKSymbol制御コードに差し替える点で、上記第1の実施形態と相違する。例えば、上記図11bに示したように、エラーが発生している場合には、エラーの発生した箇所0xFB、0xF0について、DSymbolから未使用のKSymbol0x9Cに差し替える。続いて、差し替えられたデータに同様の8b10bEncodingを行い、次の下流のデバイスDevice1にデータを転送する。そのため、上記図11cに示すように、8b10bEncoding処理が行われた後のデータ列は、エラー発生箇所が0x0F2、0x30Dとなり、次の下流のデバイスDevice1に10b8bDecoding時にエラーを検知させることが可能となる。これは、後続の下流のデバイスDevice1では、元々エラーが発生していた箇所に、規格未定義のKSymbolを発見することになるので、正常のデータではないと判断することができるためである。[第3の実施形態CRCチェック]次に、第3の実施形態について、図13、図14を用いて説明する。この実施形態は、CRCチェックを行う際のエラー検知に関するものである。この説明において、上記説明と重複する部分の詳細な説明を省略する。<データ転送動作>本例では、データを中継する際にレイテンシを低く抑える上記第1、第2の実施形態とは異なり、データを中継する際にCRCチェックを行い、そのCRCチェックでエラーを検知する一例に関する。このように、本例では、データ転送の中継時にも、受信時と同じように受信データに対してCRC計算を行う。そして、新しく計算したCRCを最低でも1bit値を変更したもので古いCRCを差し替え、下流のデバイスに送信する点で、上記第1、第2の実施形態と相違する。このようにすることで、次の下流のデバイスでは、CRCチェックを行った結果、エラーとなるため、誤受信を防止することができる。なお、CRCはパケット内のデータに対して計算が行われ、パケットの先頭を示すCOMSOP制御コード、データ、CRC、パケットの終了を示すCOMEOPという順番で送信される。例えば、本例の場合、より具体的には、図13のように示される。まず、図13a~bに示すように、エラーによって化けたデータ0xFBは、そのまま通常のデータとみなして、CRCの再計算を行なう。ただし、元々パケット中に存在していたCRCの該当箇所本例では、COMEOPの前の2バイトデータ0x570x84に関しては、本例の計算の対象外である。このように、図中の処理4のように、新しく再計算したCRCでは該当箇所の値を反転させて古いCRCの箇所と置き換えを行う。CRCは最低1bitを反転させれば良いが、本実施例では全ビット反転させるとした。その後、同様の8b10bEncodingを行い処理5、次の下流のデバイスにデータを転送する。<データ転送フロー>本例のデータ転送フローは、図14のように示される。図示するように、まず、本例では、ステップS53の際、上流のデバイスDevice0が確認した転送データ内に、COMSOP受信後かつCOMEOPの2Byte以上前か否かの判定を行う。上記ステップS53の際に該当しないと判定される場合Noには、次のステップS55に進む。続いて、ステップS54の際、上記ステップS53の際に該当すると判定される場合Yesには、エラーの発生した箇所について、通常のCRC計算の対象とする点で、上記実施形態と相違する。続いて、ステップS55の際、COMEOPの1Byteもしくは2Byte前か否かの判定を行う。続いて、ステップS56の際、上記ステップS55の際に該当すると判定される場合Yesには、計算していたCRCを反転させる。例えば、図13に示したように、新しく再計算したCRCでは該当箇所の値を反転させて古いCRCの箇所と置き換えを行う。続いて、ステップS57に進む。続いて、ステップS57の際、上記ステップS55の際に該当しないと判定される場合Noには、同様にデータに8b10bEncodingを行い、次の下流のデバイスDevice1にデータを転送するEnd。<作用効果>第3の実施形態によれば、少なくとも上記1と同様の効果が得られる。さらに、本例では、データを中継する際にCRCチェックを行い、そのCRCチェックでエラーを検知させる。例えば、ステップS56の際、上記ステップS55の際に該当すると判定される場合Yesには、計算していたCRCを反転させる。図13に示したように、新しく再計算したCRCでは該当箇所の値を反転させて古いCRCの箇所と置き換えを行う。この操作によって、送信したデータは、下流のデバイスDevice1でCRCエラーとなるため、間接的にHostからDevice0への伝送路でエラーが発生したことを伝えることができる。そのため、誤受信を防止することができる。[第4の実施形態使用される制御コードと差し替える一例]次に、第4の実施形態について、図15、図16を用いて説明する。この実施形態は、使用される制御コードに差し替えてエラーを検知させる一例に関するものである。この説明において、上記実施形態と重複する部分の詳細な説明を省略する。<データ転送動作>本例では、規格で利用されている制御コードを使う方法に関する。第2の実施形態で説明したように、UHSII規格においてKSymbolが定められているが、制御コードはCOMというKSymbolと、もう一つのKSymbolがセットになることで、一つの意味を持つ制御コードとなる。また、制御コードには、COMLIDLやCOMDIDLのように、アイドル状態を示すだけの制御コードが定められている。そのため、本例では、アイドル状態を示すだけの制御コードを、エラーがあった箇所に埋め込むことで、続く下流のデバイスDevice1にエラーを検知させる。なお、エラーの発生までは第1の実施形態と同様である。図15a、bに示すように、処理4の際、2バイト単位でエラーが発生しているかチェックを行い、エラーが発生していた箇所0xFB0xF0には、データバースト転送中のアイドル状態を示すCOMDIDLに差し替えを行う。続いて、その後は、同様の8b10bEncodingを行い処理5、次の下流のデバイスDevice1への転送データとする。<データ転送フロー>本例のデータ転送フローは、図16のように示される。図示するように、本例では、ステップS64の際、ステップS63の際にエラーが発生していると判定される場合Yesには、該当箇所をデータバースト転送中のアイドル状態を示すCOMDIDLに差し替えを行う。例えば、図15に示したように、エラーが発生していた箇所0xFB0xF0には、データバースト転送中のアイドル状態を示すCOMDIDLに差し替えを行う。続いて、同様にデータに8b10bEncodingを行い、次の下流のデバイスDevice1にデータを転送するEnd。このように、本例では、元々エラーが発生していた箇所に、アイドル状態を示すCOMDIDLが存在することになるが、データパケット中にCOMDIDLが存在することは規格に定義されたデータ構造ではない。そのため、後続の下流のデバイスではCOMDIDLが混ざったパケットは、正常のデータではないと判断することができる。<作用効果>第4の実施形態によれば、少なくとも上記1と同様の効果が得られる。さらに、本例では、ステップS64の際、ステップS63の際にエラーが発生していると判定される場合Yesには、該当箇所をデータバースト転送中のアイドル状態を示すCOMDIDLに差し替えを行う。例えば、図15に示したように、エラーが発生していた箇所0xFB0xF0には、データバースト転送中のアイドル状態を示すCOMDIDLに差し替えを行う。このように、元々エラーが発生していた箇所に、アイドル状態を示すCOMDIDLが存在することになるが、データパケット中にCOMDIDLが存在することは規格に定義されたデータ構造ではない。そのため、後続の下流のデバイスではCOMDIDLが混ざったパケットは、正常のデータではないと判断することができる。必要に応じて、本例を適用することが可能である。[変形例]上記参考例および実施形態では、リング状にされたホスト装置Hostおよび2つのデバイスDevice0Device1を一例に挙げたが、これに限られることはない。例えば、リング状に接続されるホスト装置Hostおよび3つの以上のデバイスDevice0Device1Device2DeviceNであっても同様に適用可能である。この場合、データの中継局は、宛先局以外のデバイスが該当し得る。また、ホスト装置からデバイスへのデータ転送を例に説明したが、デバイスからホスト装置へのデータ転送においても、間に中継局が存在すれば、同様に適用可能である。また、リング接続に限られず、例えば、ホストと複数のデバイスが直列に接続される多重伝送システム等に対しても同様に適用可能である。本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。