送受信装置およびこれを中継するシステム
【課題】転送データのエラーを認識でき、データ破壊を防止に有利な送受信装置およびそれを中継するシステムを提供する。
【解決手段】実施形態によれば、第１送受信装置(Device 0)および第２送受信装置(Device 1)を含み、複数の送受信装置が順次リング状に接続されるシステムにおいて、中継局となる送受信装置(Device 0)のデータ転送動作の際、転送経路においてエラーが発生した場合、前記中継局となる送受信装置(Device 0)が、中継する送信データの一部を内部で生成したデータに差し替えを行い、下流に送信する。
【解決手段】実施形態によれば、第１送受信装置(Device 0)および第２送受信装置(Device 1)を含み、複数の送受信装置が順次リング状に接続されるシステムにおいて、中継局となる送受信装置(Device 0)のデータ転送動作の際、転送経路においてエラーが発生した場合、前記中継局となる送受信装置(Device 0)が、中継する送信データの一部を内部で生成したデータに差し替えを行い、下流に送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
送受信装置およびこれを中継するシステムに関するものである。
【背景技術】
【０００２】
近年、ＳＤカード（登録商標）などのデータ記憶デバイスの大容量化、デジタルカメラ等の解像度向上による画像の高精細化、また画像データのフレームレート向上による高画質化には目覚ましいものがある。このような背景のもと、デジタルカメラ等のホスト機器と、データを記録する記憶デバイス等との間のデータ伝送量は、増大の一途をたどっている。このような大容量データ伝送においては、接続ケーブルの簡略化、消費電力の抑制、ＥＭＩ放射ノイズ低減などの観点から、小振幅差動信号による高速シリアル伝送方式が一般的に用いられるようになってきている。また、この様な高速シリアル伝送方式では、伝送の安定化を図るために８ｂ／１０ｂの様なコーディングが用いられることが一般的である。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００３−２７３９３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
転送データのエラーを認識でき、データ破壊の防止に有利な送受信装置およびこれを中継するシステムを提供する。
【課題を解決するための手段】
【０００５】
実施形態によれば、第１送受信装置および第２送受信装置を含み、複数の送受信装置が順次リング状に接続されるシステムにおいて、中継局となる送受信装置のデータ転送動作の際、転送経路においてエラーが発生した場合、前記中継局となる送受信装置が、中継する送信データの一部を内部で生成したデータに差し替えを行い、下流に送信する。
【図面の簡単な説明】
【０００６】
【図１】参考例に係るシステム（リングトポロジー）を示すブロック図。
【図２】参考例に係るData Burst Streamingの有効化を示すフロー図。
【図３】参考例に係るData Burst Streamingの無効化を示すフロー図。
【図４】参考例に係るループバックパスを示すブロック図。
【図５】第１の実施形態に係る送受信装置（Device 0）の構成例を示すブロック図。
【図６】第１の実施形態に係るエラー情報の発生（１）を示す図。
【図７】第１の実施形態に係るエラー情報の発生（２）を示す図。
【図８】第１の実施形態に係るエラー情報の伝達を示す図。
【図９】第１の実施形態に係るエラー情報のエラー検知を示すフロー図。
【図１０】第２の実施形態に係るK-Symbolを示す図。
【図１１】第２の実施形態に係るエラー情報の伝達を示す図。
【図１２】第２の実施形態に係るエラー情報のエラー検知を示すフロー図。
【図１３】第３の実施形態に係るエラー情報の伝達を示す図。
【図１４】第３の実施形態に係るエラー情報のエラー検知を示すフロー図。
【図１５】第４の実施形態に係るエラー情報の伝達を示す図。
【図１６】第４の実施形態に係るエラー情報のエラー検知を示すフロー図。
【発明を実施するための形態】
【０００７】
［参考例］
まず、参考例について、図１乃至図４を参照して、説明する。
【０００８】
＜システム（リングトポロジー）＞
まず、図１を用い、システム（リングトポロジー）について説明する。
【０００９】
図示するように、本例のシステムは、ホスト（Host）と、２つの送受信デバイス（Device 0, Device 1）との各ノードの送信端子が次のノードの受信端子に接続される。そのため、このようなシステムを、リング（輪）を構成することから、リングトポロジーと称される。
【００１０】
本例のリングトポロジーは、例えば、ＳＤアソシエーションが策定したUHS-II規格等に準拠される。このように、リングトポロジーは、複数のデバイスを接続するための接続形態の一つとして想定されるものである。
【００１１】
ここで、上記UHS-II規格に準拠したリングトポロジーでは、各ノード間でやりとりをするパケットにはヘッダが格納されており、パケット受信時にはヘッダ内に記載されている宛先ID(以下DID)と、自局のID(OWN_NODE_ID)との比較を行って、自局宛のパケットか、他局当てのパケットかの判断を行っている。
【００１２】
しかし、例えばUHS-II規格においては、パケット受信時に、パケットの内容にエラーが発生していないかを、巡回符号検査(CRC)を用いて確認する必要がある。つまり一旦全データを受信し、パケットに埋め込まれているCRCの値と、受信したデータを利用して計算したCRCの値が一致し、エラーが発生していないことを確認できた場合にのみ、パケットの内容を見て宛先を判断できることになる。そのため、パケットサイズが比較的大きな(512Bなど)データパケットの場合に、他局宛のパケットの中継に時間がかかってしまうという傾向がある。
【００１３】
そこで、UHS-II規格においては、データパケットの転送が発生するデータバースト転送においては、パケットの中継にかかる時間を低く抑えるData Burst Streamingという仕組みを導入している。
【００１４】
＜Data Burst Streamingの有効化フロー＞
図２に沿って、Data Burst Streamingの有効化フローについて説明する。ここでは、上記リングトポロジーにおいて、ホストからの送信されたパケットを受信（Rx）した上流のデバイス（Device 0）が、下流のデバイス（Device 1）にパケットを送信（Tx）する場合を一例に挙げる。なお、以下のフローの制御は、後述するように、例えば、デバイス（Device 0, Device 1）内のコントローラが行う。
まず、ステップＳ１１の際、上流のデバイス（Device 0）は、ホストからパケットを受信する。
【００１５】
続いて、ステップＳ１２の際、受信したパケットのヘッダを確認する。
【００１６】
続いて、ステップＳ１３の際、ヘッダの内容から自局宛か否かを判定する。
【００１７】
続いて、ステップＳ１４の際、上記ステップＳ１３の際に自局宛であると判定される場合（Yes）、自局である上流のデバイス（Device 0）でパケット処理を行い、このフローを終了する（End）。
【００１８】
続いて、ステップＳ１５の際、上記ステップＳ１３の際に自局宛でないと判定される場合（No）、受信パケットを下位の局（本例では、Device 1）に送信する。
【００１９】
続いて、ステップＳ１６の際、パケット受信した下流の局（Device 1）は、フローコントロールリクエストパケット（FCREQパケット）か否かを判定する。FCREQパケットでないと判定される場合（No）、このフローを終了する。
【００２０】
続いて、ステップＳ１７の際、上記ステップＳ１６の際にFCREQパケットである判定される場合（Yes）、Data Burst Streamingの有効化し、このフローを終了する（End）。
【００２１】
このように、上記Data Burst Streamingフローでは、バースト転送に先立って行なわれフロー制御に使われるフローコントロールリクエスト（FCREQ）パケットを利用して、バースト転送の中継が有効化される（Ｓ１７）。そのため、上流のデバイス（Device 0）から下流のデバイス（Device 1）におけるパケットの中継時に、そのパケットがFCREQパケットの有無により、後続の下流のデバイス（Device 1）へのデータバースト転送が発生すると判断できる。そのため、続く下流のデバイス（Device 1）へのデータバースト中のパケットでは、ヘッダの確認などを行われず、送信されるデータをバッファリングせずにそのまま中継することができ、パケットの中継にかかる時間を低く抑えることができる。
【００２２】
また、この中継状態では、データバーストの最後に転送される特殊な制御コード(例えば、EDB: End of Data Burst)を中継したことで無効化される。次に、この動作のフローを示す。
【００２３】
＜Data Burst Streamingの無効化フロー＞
図３に沿って、Data Burst Streamingの無効化フローについて説明する。ここでは、上記リングトポロジーのデータ中継時において、上流のデバイス（Device 0）から、下流のデバイス（Device 1）にData Burst Streamingの有効化により、パケットが送信（Tx）された場合を一例に挙げる。なお、以下のフローの制御は、同様に、例えば、デバイス（Device 0, Device 1）内のコントローラが行い、Data Burst Streamingが有効化されているのみ実行される。
まず、ステップＳ２１の際、上流のデバイス（Device 0）は、ホストから送信されたパケットデータを受信する。
【００２４】
続いて、ステップＳ２２の際、上流のデバイス（Device 0）は、受信したパケットを、上記Data Burst Streamingの有効化により、下流のデバイス（Device 1）に中継して送信する。
【００２５】
続いて、ステップＳ２３の際、上流のデバイス（Device 0）は、中継されたデータを確認する。
【００２６】
続いて、ステップＳ２４の際、上流のデバイス（Device 0）は、中継されたデータに、データバーストの最後に転送される終了制御コード（EDB: End of Data Burst）があるか否かを判定する。上記ステップＳ２４の際に、終了制御コード（EDB）がないと判定される場合（No）、このフローを終了する（End）。
【００２７】
続いて、ステップＳ２５の際、ステップＳ２４の際に、上記ステップＳ２４の際に終了制御コード（EDB）があると判定される場合（Yes）、Data Burst Streamingを無効化し、このフローを終了する（End）。
【００２８】
＜ループバックパス（Loopback Path）について＞
次に、図４を用いて、上記「来たデータをそのまま中継する」ループバックパスについて説明する。
【００２９】
図示するように、ループバックパスについては、Deserializerの後で受信したデータを送信し直すLoopback Path(1)と、10b8b Decodingの後に受信したデータを送信し直すLoopback Path(2)という２種類が提示されている。
【００３０】
図中に示す、8b10b Encoding、10b8b Decodingとは、8b10b符号化方式の符号化、復号化を行うブロックである。8b10b符号化方式は、8bitのデータを10bitで表現することにより、データの中にクロックや制御コードを埋め込むことができる。この方式は、例えば、イーサネット（登録商標）、ファイバーチャネル、IEEE 1394、PCI Express 2.0、Serial ATA、USB 3.0など数多くの規格で採用されている。
【００３１】
Serializerは、10bit幅のデータから、10倍の速度の1bit幅のデータに変換する(Serialize処理)。Deserializerは、その逆で、1bit幅のデータを10分の1の速度の10bit幅のデータに変換する(Deserialize処理)。上記8b10b Encoding、10b8b Decoding、Serializer、Deserializerは、必要なデバイス（Device 0, Device 1）中の後述するコントローラ等が行う。
【００３２】
上記の２種類の方法のうち、前者Loopback Path(1)の方法は、Loopback Path(2)の方法よりもデータの中継にかかるレイテンシが短いものの、8b10b符号化方式の特徴であるランニングディスパリティの保持に関して特殊な対処が必要となる。そのため、10b8b Decoding後に折り返すLoopback Path(2)の方が実装の観点から難易度が低く、好ましい。しかしながら、後者のLoopback Path(2)の方法でも、以下のような傾向が存在する。
【００３３】
ここで、UHS-II規格において、受信データは、以下の二段構えで、エラーのチェックを行なう。すなわち、
１. 10b8b Decodingにおいて10bitのデータが変換テーブルに存在するか否か
２. 8bitデータからパケットを抽出後、CRCを用いてパケットの正当性を確認する
このように、10b8b DecodingとCRCによる二重のチェックが行われることになる。
【００３４】
しかしながら、ここで懸念されるのは、図１に示した構成において、次のような状況が発生した場合である。
【００３５】
（I） HostからDevice1へデータパケットを送信する。
【００３６】
（II） 続いて、この際、Device0は中継局となるため、Loopback Path(2)の方法でデータパケットを中継する。
【００３７】
（III） HostとDevice0間の経路においてノイズが入り、データは10b8b Decodingできないデータ化けが発生する。
【００３８】
ここで、もしDevice0へのデータの送信だった場合には、中継局が入らないため、10b8b Decoding時にエラーを検出でき、そのデータパケットはCRCの結果に依らず無効と判断することができる。しかしながらDevice0は中継局なため、エラーが存在しているという8bitのデータを再度送信する必要がある。それは、8b10b Encodingにおいてエラー情報を伝達するという仕組み、機能は存在しないため、Device1へはエラー情報が存在しない10bitのデータが送信されることになるからである。
【００３９】
そのため、Device1では10b8b Decodingは正常に終了し、CRCでのみパケットの正当性を確認することになる。CRCはパケットの全データのシグネチャのようなものであるため、まったく異なるデータでも可能性はとても低いものの偶然にCRCの値が一致する場合が存在する。そのため、10b8b Decodingでのエラーの検出が出来ない場合には、本来間違っているデータが正しいデータであると誤判断される可能性が上昇する。送信されたデータのエラー箇所を認識できないと、下流のデバイス（Device 1）ではエラーが発生したにも関わらず正しいデータであると誤認識し、結果としてデータが破壊されるおそれがある。
【００４０】
このように、下流のデバイス（Device1）がエラーデータを認識できず、そのまま受け取ってしまうという可能性が上昇してしまうため、データが破壊されるおそれがある。
【００４１】
そこで、以下の実施形態では、上記参考例での知見を元に、上記のような受信データの誤受信を防ぐことができ、中継局となる上流のデバイスにおいて、どのようにして10b8b Decoding処理において検知したエラー情報を伝達し、次局の下流のデバイスに伝えていくかに関し、図面を参照してより具体的に説明する。尚、この説明においては、全図にわたり共通の部分には共通の参照符号を付す。
【００４２】
［第１実施形態］
次に、第１の実施形態について、図５乃至図９を用いて説明する。この説明において、上記の説明と重複する部分の詳細な説明を省略する。
【００４３】
＜１.送受信装置（Device 0）の構成例＞
まず、図５を用い、第１の実施形態に係る送受信装置（本例では、半導体記憶装置）の構成例について説明する。ここでは、一例として上記UHS-II規格に準拠されるシステム（リングトポロジー）に配置される１つの送受信デバイス（Device 0）を一例に挙げる。
【００４４】
ここで、図示するDevice 0は、例えば、ＳＤカード（登録商標）などに代表されるような、NAND Flash Memory １１を実装したDeviceのブロック図である。しかしながら、ここに示したメモリデバイス構成に限れない。本例は、下記に説明するController１２内のHost Interface Controller２１に関連する技術においては、例えばMemory Controller１２とNAND Flash Memory １１の替わりに、無線LAN Interfaceを実装した無線LANカードのような送受信Deviceにおいても適用可能である。
【００４５】
図示するように、本例に係るデバイス（Device 0）は、ＮＡＮＤ型フラッシュメモリ１１、およびこのＮＡＮＤ型フラッシュメモリ１１を制御するコントローラ１２を備える。
【００４６】
ＮＡＮＤ型フラッシュメモリ（NAND Flash Memory）１１は、ワード線およびビット線の交差位置にマトリックス状に配置される複数のメモリセルを有するメモリセルアレイに、データを不揮発に記憶する。メモリセルのそれぞれは、半導体基板上に順次積層されるトンネル絶縁膜、電荷蓄積層、電極間絶縁膜、制御ゲートを備える。制御ゲートは、上記ワード線に接続される。メモリセルの電流経路は、ビット線方向に複数個接続され、メモリセルユニットを形成する。
また、データ書き込み、データ読み出しは、ワード線単位（ページ単位）で行われる。データ消去は、ブロック単位で一括して行われる。
【００４７】
コントローラ（Controller）１２は、ホストインターフェイス２１、ＭＰＵ２２、バッファ２３、およびメモリコントローラ２４を備える。
【００４８】
ホストインターフェイス（Host Interface Controller）２１は、このデバイスの外部(ホストや自分以外のデバイス)からのコマンドパケットやデータパケットの受信RXおよび送信TXの際の所定の変換、例えば8b10b Encoding処理、10b8b Decoding処理、Serialize処理、Deserialize処理、CRC付加処理、CRCチェック処理を行う。
【００４９】
ＭＰＵ２２は、このコントローラ１２全体の制御を行う。
【００５０】
バッファ（Buffer）２３は、ホストインターフェイス２１やメモリコントローラ２４からのデータや制御プログラム等を展開し、記憶する。
【００５１】
メモリコントローラ（Memory Controller）２４は、ＭＰＵ２２の制御を受け、ＮＡＮＤ型フラッシュメモリ１１の制御を行う。
【００５２】
＜２.データ転送動作＞
次に、上記構成おけるデータ転送動作について説明する。
２−１．エラー情報の発生について
まず、図６乃至図８を用い、データ転送動作の際のエラー情報の発生までについて説明する。ここでは、上記図１に示したメモリシステム（リングトポロジー）において、ホスト（Host）から送信されたデータについて、上流の中継局としてのデバイス（Device 0）が、下流のデバイス（Device 1）に対して、データを転送する場合を一例に挙げて以下説明する。また、以下の動作については、コントローラ１２がその制御を行う。
【００５３】
まず、図６（ａ）に示すように、ホストは、８ｂデータ列（Host Tx Side 8b）を、上流のデバイス（Device 0）に送信するため、このデータ列中のデータ(8b Data)とシンボル情報（Symbol）に対して8b10b Encoding処理（１）を行い、図６（ｂ）に示す10bのデータ列（Host Tx Side 10b）に変換する。
ここで、K-Symbolとは8b10b符号化において、8bitの情報を10bitで表現することにより、余った10bitのパターンのうち、いくつかを制御コードとして利用するためのコードである。例えば、UHS-II規格において使用されるK-Symbolの詳細については、次に第２の実施形態で後述する。
【００５４】
続いて、ホストから送信された10bのデータ列は伝送路を通り、HostからDevice0へ転送が行われる。実際には送信側のSerialize処理によって1bitのビット列に変換され伝送路を通り、受信側でDeserialize処理されることで10bitのデータ列に変換されるが、簡略化のため、10bit単位で説明を行なう。また、以後の例でも同様である。
【００５５】
この間にエラーが発生し（２）、10bのデータ列の値が化け、図６（ｃ）に示す”Device0 Rx Side 10b”で示されるデータ列になるとする。本例では、図６（ｃ）中のデータ"0x3FB", "0x3F0"が、データ化けした箇所とする。
【００５６】
続いて、図７（ｃ）から（ｄ）に示すように、Device0において、10bのデータ列を10b8b Decodingによって、8bのデータ列（Device 0 Rx Side8b）に変換する（３）。ここでエラーが発生した箇所"0x3FB", "0x3F0"は、10b8bの変換ができない値に化けている。そのため、8bのデータ列（Device 0 Rx Side8b）では、エラーフラグ付き（Error）のデータ"0xFB", "0xF0"として変換される。ここで8bデータの値は実装によって値が異なるが、本実施例では10bデータの下位8bitを抽出している。また、Symbol情報はデコードできなかったということで不明とされる。
【００５７】
ここで、このエラーを含んだ8bのデータ列（Device 0 Rx Side 8b）を、そのまま下流のデバイス（Device 1）に転送すると、本来間違っているデータ"0xFB", "0xF0"が正しいデータであると誤判断されるおそれがある。これは、例えば、10b8b Decodingでのエラーの検出が出来ない場合にその可能性が上昇する。
【００５８】
その結果、下流のデバイス（Device 1）が、エラーのデータを正しいデータとして受け取り、結果としてデータ破壊が発生してしまう。
【００５９】
２−２．エラーデータの差し替え
そこで、図８（ｅ）に示すように、エラーが発生している場合には、8b10b Encoding＆Error injection処理（４）の際、エラーが発生している箇所"0xFB", "0xF0"に、8b10b符号化では利用されていない10bitのパターンである(0x010)に差し替えを行う。
そして、下流のデバイス（Device 1）に、この差し替えられた後のデータ列（Device 0 Tx 10b）を送信することで、次の下流のデバイス（Device 1）に10b8b Decoding時にエラーを検知させることが可能となる。
【００６０】
２−３.データ転送動作フロー
上記データ転送動作を動作フローに示すと、図９のように示される。
まず、ステップＳ３１の際、上流のデバイス（Device 0）は、ホストから送信されたパケットデータを受信する。この際、受信したデータに対して、例えば、10b8b Decoding処理を行う。
【００６１】
続いて、ステップＳ３２の際、デバイス（Device 0）は、変換後の受信データを確認する。
【００６２】
続いて、ステップＳ３３の際、受信データにエラーが発生しているか否かを判定する。この際、コントローラ１２は、例えば、エラーフラグの有無により、エラーが発生しているか否かを判定する。例えば、上記図７に示したように、エラーが発生した箇所"0x3FB", "0x3F0"は、10b8bの変換ができない値に化けているため、8bのデータ列（Device 0 Rx Side8b）では、エラーフラグ付き（Error）のデータ"0xFB", "0xF0"として変換される。
【００６３】
続いて、ステップＳ３４の際、上記ステップＳ３３の際にエラーが発生していると判定される場合（Yes）には、8b10b Encodingで割り当てられていないデータに差し替えて、下流のデバイス（Device 1）に送信し、このフローを終了する（End）。
【００６４】
例えば、上記図８に示したように、エラーが発生している場合には、コントローラ１２は、8b10b Encoding＆Error injection処理（４）の際、エラーが発生している箇所"0xFB", "0xF0"に、未登録パターンである(0x010)に差し替えを行う。そのため、下流のデバイス（Device 1）に、この差し替えられた後のデータ列（Device 0 Tx Side 10b）を送信することで、次の下流のデバイス（Device 1）に10b8b Decoding時にエラーを検知させることが可能となる。
【００６５】
一方、ステップＳ３５の際、上記ステップＳ３３の際にエラーが発生していないと判定される場合（No）には、上記のような差し替えを行わず、8b10b Encoding処理を行ったデータを、下流のデバイス（Device 1）に送信し、このフローを終了する（End）。
【００６６】
＜３.作用効果＞
第１の実施形態に係る構成および動作によれば、少なくとも下記（１）の効果が得られる。
【００６７】
（１）転送データのエラーを認識でき、データ破壊を防止できる。
上記図１に示したように、本例では、ホスト装置（Host）から、第１送受信装置（Device 0）および第２送受信装置（Device 1）を含み、複数の送受信装置が順次リング状に接続されるシステムに適用される。そして、上流のデバイス（Device 0）が中継局となる場合のデータ転送動作の際、伝送路においてエラーが発生した場合、上流のデバイス（Device 0）は、下流のデバイス（Device 1）宛の送信データ中のエラーが発生した箇所に割り当てられていないデータを差し替えて、送信する（Ｓ３４）。
【００６８】
例えば、上記図８に示したように、エラーが発生している場合には、コントローラ１２は、8b10b Encoding＆Error injection処理（４）の際、エラーが発生している箇所"0xFB", "0xF0"に、未登録パターンである(0x010)に差し替えを行う。
【００６９】
このように、本例では、中継局の上流側のデバイス（Device 0）の8b10b Encoding処理において、転送データ列中のエラー箇所を、本来8b10b変換テーブルには載っていないパターン(0x010)に差し替えることにより、下流側のデバイス（Device 1）にエラー情報を伝達する。
【００７０】
そのため、続く下流側のデバイス（Device 1）では、転送されたデータ列を10b8b Decodingする際に、当該未登録パターン(0x010)に差し替えられた箇所がエラーであると認識することができ、エラーを検出できる。
【００７１】
このように、本例では、ホストと中継局である上流のデバイス（Device 0）の伝送経路中に転送データにノイズ等により10b8b Decodingできないデータ化けが発生した場合であっても、下流のデバイス（Device 1）は、そのエラー発生の箇所を認識することができる。
【００７２】
送信されたデータのエラー箇所を認識できないと、下流のデバイス（Device 1）では誤って正しいデータと認識して受理する可能性が増加し、ホストにとってはデバイスに書き込んだデータが破壊されてしまうというおそれがある。
【００７３】
よって、転送データのエラー発生箇所を認識でき、データ破壊を防止できる点で有利である。
【００７４】
なお、第１の実施形態では全エラーにおいて、一つの未登録パターン(0x010)を利用しているが、未登録パターンを複数用意し、任意の未登録パターンを利用しても良いことは勿論である。
【００７５】
［第２の実施形態］
次に、第２の実施形態について、図１０乃至図１２を用いて説明する。第２の実施形態は、エラー発生箇所に、規格上利用されていないK-Symbolを差し替える一例に関するものである。この説明において、上記説明と重複する部分の詳細な説明を省略する。
【００７６】
＜K-Symbolについて＞
まず、図１０を用い、K-Symbolについて説明する。
【００７７】
図示するように、K-Symbolとは8b10b符号化において、8bitの情報を10bitで表現することにより、余った10bitのパターンのうち、いくつかを制御コードとして利用することである。本例で図示するものは、UHS-II規格においても使用される制御コードとしてのK-Symbolを一例に挙げる。
【００７８】
例えば、図中のK-Symbol（K28.0）のシンボル名はSDBであり、機能としてはデータバーストを開始すること（Start of Data Burst）であり、値は0x1Cである。以下、同様に、図示するようなK-Symbolが定められている。
【００７９】
ここで、図中のK-Symbolのうち、例えば、K28.2 (Value:0x5C)、K28.4 (Value:0x9C)、K28.7 (Value:0xFC)、K30.7 (Value:0xFE)については、利用されていない未使用のK-Symbolである。
【００８０】
本例では、以下に詳説するように、エラー発生箇所に、K28.4 (Value:0x9C)等の利用されていない未使用のK-Symbolを差し替える点で、上記第１の実施形態と相違する。
【００８１】
＜データ転送動作＞
本例では、UHS-II規格においては利用されていない図１０に示した以外のK-Symbolをエラーがあった箇所に埋め込むことで、後続のノードにエラーを検知させる。
【００８２】
まず、図１１を用いて、データ転送動作について説明する。なお、エラーの発生までは上記第１の実施形態と同様であるため、詳細な説明は省略する。
【００８３】
図１１（ｂ）に示すように、ホストから中継局としてデータ列（Device 0 Rx Side 8b）を受信した上流のデバイス（Device 0）は、8b10b Encoding 処理（５）の前に、エラーの発生した箇所について、D-Symbolから規格では未使用のK-Symbol（本実施例では0x9CのK-Symbol）に差し替えを行なう（処理４）。
【００８４】
続いて、上流のデバイス（Device 0）は、差し替えられたデータに同様の8b10b Encoding を行い(処理５)、次の下流のデバイス（Device 1）にデータを転送する。
【００８５】
＜データ転送フロー＞
本例のデータ転送フローは、図１２のように示される。
図示するように、本例では、ステップＳ４４の際、ステップＳ４３の際にエラーが発生していると判定される場合（Yes）には、エラーの発生した箇所について、D-Symbolから未使用のK-Symbol（制御コード）に差し替える点で、上記第１の実施形態と相違する。例えば、上記図１１（ｂ）に示したように、エラーが発生している場合には、エラーの発生した箇所"0xFB"、"0xF0"について、D-Symbolから未使用のK-Symbol（制御コード）に差し替える。
【００８６】
続いて、ステップＳ４５の際、差し替えられたデータに同様の8b10b Encoding を行い、次の下流のデバイス（Device 1）にデータを転送する（End）。そのため、上記図１１（ｃ）に示すように、8b10b Encoding処理が行われた後のデータ列は、エラー発生箇所が"0x0F2"、"0x30D"となり、次の下流のデバイス（Device 1）に10b8b Decoding時にエラーを検知させることが可能となる。
【００８７】
これは、後続の下流のデバイス（Device 1）では、元々エラーが発生していた箇所に、規格未定義のK-Symbolを発見することになるので、正常のデータではないと判断することができるためである。
【００８８】
なお、この方法では、後続のノードにおいて利用されていないK-Symbolが存在した場合にどう動作するか、によって影響されるため不確定とも思われる。
【００８９】
＜作用効果＞
第２の実施形態によれば、少なくとも上記（１）と同様の効果が得られる。
【００９０】
本例では、エラーが発生していると判定される場合（Yes）には、エラーの発生した箇所について、D-Symbolから未使用のK-Symbol（制御コード）に差し替える点で、上記第１の実施形態と相違する。例えば、上記図１１（ｂ）に示したように、エラーが発生している場合には、エラーの発生した箇所"0xFB"、"0xF0"について、D-Symbolから未使用のK-Symbol（0x9C）に差し替える。
【００９１】
続いて、差し替えられたデータに同様の8b10b Encoding を行い、次の下流のデバイス（Device 1）にデータを転送する。そのため、上記図１１（ｃ）に示すように、8b10b Encoding処理が行われた後のデータ列は、エラー発生箇所が"0x0F2"、"0x30D"となり、次の下流のデバイス（Device 1）に10b8b Decoding時にエラーを検知させることが可能となる。
【００９２】
これは、後続の下流のデバイス（Device 1）では、元々エラーが発生していた箇所に、規格未定義のK-Symbolを発見することになるので、正常のデータではないと判断することができるためである。
【００９３】
［第３の実施形態（CRCチェック）］
次に、第３の実施形態について、図１３、図１４を用いて説明する。この実施形態は、CRCチェックを行う際のエラー検知に関するものである。この説明において、上記説明と重複する部分の詳細な説明を省略する。
【００９４】
＜データ転送動作＞
本例では、データを中継する際にレイテンシを低く抑える上記第１、第２の実施形態とは異なり、データを中継する際にCRCチェックを行い、そのCRCチェックでエラーを検知する一例に関する。
【００９５】
このように、本例では、データ転送の中継時にも、受信時と同じように受信データに対してCRC計算を行う。そして、新しく計算したCRCを最低でも1bit値を変更したもので古いCRCを差し替え、下流のデバイスに送信する点で、上記第１、第２の実施形態と相違する。
【００９６】
このようにすることで、次の下流のデバイスでは、CRCチェックを行った結果、エラーとなるため、誤受信を防止することができる。
【００９７】
なお、CRCはパケット内のデータに対して計算が行われ、パケットの先頭を示すCOM+SOP制御コード、データ、CRC、パケットの終了を示すCOM+EOPという順番で送信される。
【００９８】
例えば、本例の場合、より具体的には、図１３のように示される。
【００９９】
まず、図１３（ａ）〜（ｂ）に示すように、エラーによって化けたデータ"0xFB"は、そのまま通常のデータとみなして、CRCの再計算を行なう。
【０１００】
ただし、元々パケット中に存在していたCRCの該当箇所（本例では、COM+EOPの前の２バイトデータ"0x57", "0x84 "）に関しては、本例の計算の対象外である。
【０１０１】
このように、図中の処理（４）のように、新しく再計算したCRCでは該当箇所の値を反転させて古いCRCの箇所と置き換えを行う。CRCは最低1bitを反転させれば良いが、本実施例では全ビット反転させるとした。
【０１０２】
その後、同様の8b10b Encodingを行い（処理（５））、次の下流のデバイスにデータを転送する。
【０１０３】
＜データ転送フロー＞
本例のデータ転送フローは、図１４のように示される。
図示するように、まず、本例では、ステップＳ５３の際、上流のデバイス（Device 0）が確認した転送データ内に、COM+SOP受信後かつCOM+EOPの2Byte以上前か否かの判定を行う。上記ステップＳ５３の際に該当しないと判定される場合（No）には、次のステップＳ５５に進む。
【０１０４】
続いて、ステップＳ５４の際、上記ステップＳ５３の際に該当すると判定される場合（Yes）には、エラーの発生した箇所について、通常のCRC計算の対象とする点で、上記実施形態と相違する。
【０１０５】
続いて、ステップＳ５５の際、COM+EOPの１Byteもしくは２Byte前か否かの判定を行う。
【０１０６】
続いて、ステップＳ５６の際、上記ステップＳ５５の際に該当すると判定される場合（Yes）には、計算していたCRCを反転させる。例えば、図１３に示したように、新しく再計算したCRCでは該当箇所の値を反転させて古いCRCの箇所と置き換えを行う。
【０１０７】
続いて、ステップＳ５７に進む。
【０１０８】
続いて、ステップＳ５７の際、上記ステップＳ５５の際に該当しないと判定される場合（No）には、同様にデータに8b10b Encodingを行い、次の下流のデバイス（Device 1）にデータを転送する（End）。
【０１０９】
＜作用効果＞
第３の実施形態によれば、少なくとも上記（１）と同様の効果が得られる。
【０１１０】
さらに、本例では、データを中継する際にCRCチェックを行い、そのCRCチェックでエラーを検知させる。
【０１１１】
例えば、ステップＳ５６の際、上記ステップＳ５５の際に該当すると判定される場合（Yes）には、計算していたCRCを反転させる。図１３に示したように、新しく再計算したCRCでは該当箇所の値を反転させて古いCRCの箇所と置き換えを行う。
【０１１２】
この操作によって、送信したデータは、下流のデバイス（Device 1）でCRCエラーとなるため、間接的にHostからDevice 0への伝送路でエラーが発生したことを伝えることができる。そのため、誤受信を防止することができる。
【０１１３】
［第４の実施形態（使用される制御コードと差し替える一例）］
次に、第４の実施形態について、図１５、図１６を用いて説明する。この実施形態は、使用される制御コードに差し替えてエラーを検知させる一例に関するものである。この説明において、上記実施形態と重複する部分の詳細な説明を省略する。
【０１１４】
＜データ転送動作＞
本例では、規格で利用されている制御コードを使う方法に関する。
【０１１５】
第２の実施形態で説明したように、UHS-II規格においてK-Symbolが定められているが、制御コードはCOMというK-Symbolと、もう一つのK-Symbolがセットになることで、一つの意味を持つ制御コードとなる。また、制御コードには、COM+LIDLやCOM+DIDLのように、アイドル状態を示すだけの制御コードが定められている。
【０１１６】
そのため、本例では、アイドル状態を示すだけの制御コードを、エラーがあった箇所に埋め込むことで、続く下流のデバイス（Device 1）にエラーを検知させる。なお、エラーの発生までは第１の実施形態と同様である。
【０１１７】
図１５（ａ）、（ｂ）に示すように、処理（４）の際、２バイト単位でエラーが発生しているかチェックを行い、エラーが発生していた箇所（"0xFB", "0xF0"）には、データバースト転送中のアイドル状態を示すCOM+DIDLに差し替えを行う。
【０１１８】
続いて、その後は、同様の8b10b Encodingを行い（処理（５））、次の下流のデバイス（Device 1）への転送データとする。
【０１１９】
＜データ転送フロー＞
本例のデータ転送フローは、図１６のように示される。
図示するように、本例では、ステップＳ６４の際、ステップＳ６３の際にエラーが発生していると判定される場合（Yes）には、該当箇所をデータバースト転送中のアイドル状態を示すCOM+DIDLに差し替えを行う。例えば、図１５に示したように、エラーが発生していた箇所（"0xFB", "0xF0"）には、データバースト転送中のアイドル状態を示すCOM+DIDLに差し替えを行う。
【０１２０】
続いて、同様にデータに8b10b Encodingを行い、次の下流のデバイス（Device 1）にデータを転送する（End）。
【０１２１】
このように、本例では、元々エラーが発生していた箇所に、アイドル状態を示すCOM+DIDLが存在することになるが、データパケット中にCOM+DIDLが存在することは規格に定義されたデータ構造ではない。そのため、後続の下流のデバイスではCOM+DIDLが混ざったパケットは、正常のデータではないと判断することができる。
【０１２２】
＜作用効果＞
第４の実施形態によれば、少なくとも上記（１）と同様の効果が得られる。
【０１２３】
さらに、本例では、ステップＳ６４の際、ステップＳ６３の際にエラーが発生していると判定される場合（Yes）には、該当箇所をデータバースト転送中のアイドル状態を示すCOM+DIDLに差し替えを行う。例えば、図１５に示したように、エラーが発生していた箇所（"0xFB", "0xF0"）には、データバースト転送中のアイドル状態を示すCOM+DIDLに差し替えを行う。
【０１２４】
このように、元々エラーが発生していた箇所に、アイドル状態を示すCOM+DIDLが存在することになるが、データパケット中にCOM+DIDLが存在することは規格に定義されたデータ構造ではない。そのため、後続の下流のデバイスではCOM+DIDLが混ざったパケットは、正常のデータではないと判断することができる。
【０１２５】
必要に応じて、本例を適用することが可能である。
【０１２６】
［変形例］
上記参考例および実施形態では、リング状にされたホスト装置（Host）および２つのデバイス（Device 0, Device 1）を一例に挙げたが、これに限られることはない。
【０１２７】
例えば、リング状に接続されるホスト装置（Host）および３つの以上のデバイス（Device 0, Device 1, Device 2, ,,, , Device N）であっても同様に適用可能である。この場合、データの中継局は、宛先局以外のデバイスが該当し得る。
【０１２８】
また、ホスト装置からデバイスへのデータ転送を例に説明したが、デバイスからホスト装置へのデータ転送においても、間に中継局が存在すれば、同様に適用可能である。
【０１２９】
また、リング接続に限られず、例えば、ホストと複数のデバイスが直列に接続される多重伝送システム等に対しても同様に適用可能である。
【０１３０】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１３１】
Host…ホスト装置、Device 0…上流の第１送受信装置（中継局）、Device 1…下流の第２送受信装置。
【技術分野】
【０００１】
送受信装置およびこれを中継するシステムに関するものである。
【背景技術】
【０００２】
近年、ＳＤカード（登録商標）などのデータ記憶デバイスの大容量化、デジタルカメラ等の解像度向上による画像の高精細化、また画像データのフレームレート向上による高画質化には目覚ましいものがある。このような背景のもと、デジタルカメラ等のホスト機器と、データを記録する記憶デバイス等との間のデータ伝送量は、増大の一途をたどっている。このような大容量データ伝送においては、接続ケーブルの簡略化、消費電力の抑制、ＥＭＩ放射ノイズ低減などの観点から、小振幅差動信号による高速シリアル伝送方式が一般的に用いられるようになってきている。また、この様な高速シリアル伝送方式では、伝送の安定化を図るために８ｂ／１０ｂの様なコーディングが用いられることが一般的である。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００３−２７３９３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
転送データのエラーを認識でき、データ破壊の防止に有利な送受信装置およびこれを中継するシステムを提供する。
【課題を解決するための手段】
【０００５】
実施形態によれば、第１送受信装置および第２送受信装置を含み、複数の送受信装置が順次リング状に接続されるシステムにおいて、中継局となる送受信装置のデータ転送動作の際、転送経路においてエラーが発生した場合、前記中継局となる送受信装置が、中継する送信データの一部を内部で生成したデータに差し替えを行い、下流に送信する。
【図面の簡単な説明】
【０００６】
【図１】参考例に係るシステム（リングトポロジー）を示すブロック図。
【図２】参考例に係るData Burst Streamingの有効化を示すフロー図。
【図３】参考例に係るData Burst Streamingの無効化を示すフロー図。
【図４】参考例に係るループバックパスを示すブロック図。
【図５】第１の実施形態に係る送受信装置（Device 0）の構成例を示すブロック図。
【図６】第１の実施形態に係るエラー情報の発生（１）を示す図。
【図７】第１の実施形態に係るエラー情報の発生（２）を示す図。
【図８】第１の実施形態に係るエラー情報の伝達を示す図。
【図９】第１の実施形態に係るエラー情報のエラー検知を示すフロー図。
【図１０】第２の実施形態に係るK-Symbolを示す図。
【図１１】第２の実施形態に係るエラー情報の伝達を示す図。
【図１２】第２の実施形態に係るエラー情報のエラー検知を示すフロー図。
【図１３】第３の実施形態に係るエラー情報の伝達を示す図。
【図１４】第３の実施形態に係るエラー情報のエラー検知を示すフロー図。
【図１５】第４の実施形態に係るエラー情報の伝達を示す図。
【図１６】第４の実施形態に係るエラー情報のエラー検知を示すフロー図。
【発明を実施するための形態】
【０００７】
［参考例］
まず、参考例について、図１乃至図４を参照して、説明する。
【０００８】
＜システム（リングトポロジー）＞
まず、図１を用い、システム（リングトポロジー）について説明する。
【０００９】
図示するように、本例のシステムは、ホスト（Host）と、２つの送受信デバイス（Device 0, Device 1）との各ノードの送信端子が次のノードの受信端子に接続される。そのため、このようなシステムを、リング（輪）を構成することから、リングトポロジーと称される。
【００１０】
本例のリングトポロジーは、例えば、ＳＤアソシエーションが策定したUHS-II規格等に準拠される。このように、リングトポロジーは、複数のデバイスを接続するための接続形態の一つとして想定されるものである。
【００１１】
ここで、上記UHS-II規格に準拠したリングトポロジーでは、各ノード間でやりとりをするパケットにはヘッダが格納されており、パケット受信時にはヘッダ内に記載されている宛先ID(以下DID)と、自局のID(OWN_NODE_ID)との比較を行って、自局宛のパケットか、他局当てのパケットかの判断を行っている。
【００１２】
しかし、例えばUHS-II規格においては、パケット受信時に、パケットの内容にエラーが発生していないかを、巡回符号検査(CRC)を用いて確認する必要がある。つまり一旦全データを受信し、パケットに埋め込まれているCRCの値と、受信したデータを利用して計算したCRCの値が一致し、エラーが発生していないことを確認できた場合にのみ、パケットの内容を見て宛先を判断できることになる。そのため、パケットサイズが比較的大きな(512Bなど)データパケットの場合に、他局宛のパケットの中継に時間がかかってしまうという傾向がある。
【００１３】
そこで、UHS-II規格においては、データパケットの転送が発生するデータバースト転送においては、パケットの中継にかかる時間を低く抑えるData Burst Streamingという仕組みを導入している。
【００１４】
＜Data Burst Streamingの有効化フロー＞
図２に沿って、Data Burst Streamingの有効化フローについて説明する。ここでは、上記リングトポロジーにおいて、ホストからの送信されたパケットを受信（Rx）した上流のデバイス（Device 0）が、下流のデバイス（Device 1）にパケットを送信（Tx）する場合を一例に挙げる。なお、以下のフローの制御は、後述するように、例えば、デバイス（Device 0, Device 1）内のコントローラが行う。
まず、ステップＳ１１の際、上流のデバイス（Device 0）は、ホストからパケットを受信する。
【００１５】
続いて、ステップＳ１２の際、受信したパケットのヘッダを確認する。
【００１６】
続いて、ステップＳ１３の際、ヘッダの内容から自局宛か否かを判定する。
【００１７】
続いて、ステップＳ１４の際、上記ステップＳ１３の際に自局宛であると判定される場合（Yes）、自局である上流のデバイス（Device 0）でパケット処理を行い、このフローを終了する（End）。
【００１８】
続いて、ステップＳ１５の際、上記ステップＳ１３の際に自局宛でないと判定される場合（No）、受信パケットを下位の局（本例では、Device 1）に送信する。
【００１９】
続いて、ステップＳ１６の際、パケット受信した下流の局（Device 1）は、フローコントロールリクエストパケット（FCREQパケット）か否かを判定する。FCREQパケットでないと判定される場合（No）、このフローを終了する。
【００２０】
続いて、ステップＳ１７の際、上記ステップＳ１６の際にFCREQパケットである判定される場合（Yes）、Data Burst Streamingの有効化し、このフローを終了する（End）。
【００２１】
このように、上記Data Burst Streamingフローでは、バースト転送に先立って行なわれフロー制御に使われるフローコントロールリクエスト（FCREQ）パケットを利用して、バースト転送の中継が有効化される（Ｓ１７）。そのため、上流のデバイス（Device 0）から下流のデバイス（Device 1）におけるパケットの中継時に、そのパケットがFCREQパケットの有無により、後続の下流のデバイス（Device 1）へのデータバースト転送が発生すると判断できる。そのため、続く下流のデバイス（Device 1）へのデータバースト中のパケットでは、ヘッダの確認などを行われず、送信されるデータをバッファリングせずにそのまま中継することができ、パケットの中継にかかる時間を低く抑えることができる。
【００２２】
また、この中継状態では、データバーストの最後に転送される特殊な制御コード(例えば、EDB: End of Data Burst)を中継したことで無効化される。次に、この動作のフローを示す。
【００２３】
＜Data Burst Streamingの無効化フロー＞
図３に沿って、Data Burst Streamingの無効化フローについて説明する。ここでは、上記リングトポロジーのデータ中継時において、上流のデバイス（Device 0）から、下流のデバイス（Device 1）にData Burst Streamingの有効化により、パケットが送信（Tx）された場合を一例に挙げる。なお、以下のフローの制御は、同様に、例えば、デバイス（Device 0, Device 1）内のコントローラが行い、Data Burst Streamingが有効化されているのみ実行される。
まず、ステップＳ２１の際、上流のデバイス（Device 0）は、ホストから送信されたパケットデータを受信する。
【００２４】
続いて、ステップＳ２２の際、上流のデバイス（Device 0）は、受信したパケットを、上記Data Burst Streamingの有効化により、下流のデバイス（Device 1）に中継して送信する。
【００２５】
続いて、ステップＳ２３の際、上流のデバイス（Device 0）は、中継されたデータを確認する。
【００２６】
続いて、ステップＳ２４の際、上流のデバイス（Device 0）は、中継されたデータに、データバーストの最後に転送される終了制御コード（EDB: End of Data Burst）があるか否かを判定する。上記ステップＳ２４の際に、終了制御コード（EDB）がないと判定される場合（No）、このフローを終了する（End）。
【００２７】
続いて、ステップＳ２５の際、ステップＳ２４の際に、上記ステップＳ２４の際に終了制御コード（EDB）があると判定される場合（Yes）、Data Burst Streamingを無効化し、このフローを終了する（End）。
【００２８】
＜ループバックパス（Loopback Path）について＞
次に、図４を用いて、上記「来たデータをそのまま中継する」ループバックパスについて説明する。
【００２９】
図示するように、ループバックパスについては、Deserializerの後で受信したデータを送信し直すLoopback Path(1)と、10b8b Decodingの後に受信したデータを送信し直すLoopback Path(2)という２種類が提示されている。
【００３０】
図中に示す、8b10b Encoding、10b8b Decodingとは、8b10b符号化方式の符号化、復号化を行うブロックである。8b10b符号化方式は、8bitのデータを10bitで表現することにより、データの中にクロックや制御コードを埋め込むことができる。この方式は、例えば、イーサネット（登録商標）、ファイバーチャネル、IEEE 1394、PCI Express 2.0、Serial ATA、USB 3.0など数多くの規格で採用されている。
【００３１】
Serializerは、10bit幅のデータから、10倍の速度の1bit幅のデータに変換する(Serialize処理)。Deserializerは、その逆で、1bit幅のデータを10分の1の速度の10bit幅のデータに変換する(Deserialize処理)。上記8b10b Encoding、10b8b Decoding、Serializer、Deserializerは、必要なデバイス（Device 0, Device 1）中の後述するコントローラ等が行う。
【００３２】
上記の２種類の方法のうち、前者Loopback Path(1)の方法は、Loopback Path(2)の方法よりもデータの中継にかかるレイテンシが短いものの、8b10b符号化方式の特徴であるランニングディスパリティの保持に関して特殊な対処が必要となる。そのため、10b8b Decoding後に折り返すLoopback Path(2)の方が実装の観点から難易度が低く、好ましい。しかしながら、後者のLoopback Path(2)の方法でも、以下のような傾向が存在する。
【００３３】
ここで、UHS-II規格において、受信データは、以下の二段構えで、エラーのチェックを行なう。すなわち、
１. 10b8b Decodingにおいて10bitのデータが変換テーブルに存在するか否か
２. 8bitデータからパケットを抽出後、CRCを用いてパケットの正当性を確認する
このように、10b8b DecodingとCRCによる二重のチェックが行われることになる。
【００３４】
しかしながら、ここで懸念されるのは、図１に示した構成において、次のような状況が発生した場合である。
【００３５】
（I） HostからDevice1へデータパケットを送信する。
【００３６】
（II） 続いて、この際、Device0は中継局となるため、Loopback Path(2)の方法でデータパケットを中継する。
【００３７】
（III） HostとDevice0間の経路においてノイズが入り、データは10b8b Decodingできないデータ化けが発生する。
【００３８】
ここで、もしDevice0へのデータの送信だった場合には、中継局が入らないため、10b8b Decoding時にエラーを検出でき、そのデータパケットはCRCの結果に依らず無効と判断することができる。しかしながらDevice0は中継局なため、エラーが存在しているという8bitのデータを再度送信する必要がある。それは、8b10b Encodingにおいてエラー情報を伝達するという仕組み、機能は存在しないため、Device1へはエラー情報が存在しない10bitのデータが送信されることになるからである。
【００３９】
そのため、Device1では10b8b Decodingは正常に終了し、CRCでのみパケットの正当性を確認することになる。CRCはパケットの全データのシグネチャのようなものであるため、まったく異なるデータでも可能性はとても低いものの偶然にCRCの値が一致する場合が存在する。そのため、10b8b Decodingでのエラーの検出が出来ない場合には、本来間違っているデータが正しいデータであると誤判断される可能性が上昇する。送信されたデータのエラー箇所を認識できないと、下流のデバイス（Device 1）ではエラーが発生したにも関わらず正しいデータであると誤認識し、結果としてデータが破壊されるおそれがある。
【００４０】
このように、下流のデバイス（Device1）がエラーデータを認識できず、そのまま受け取ってしまうという可能性が上昇してしまうため、データが破壊されるおそれがある。
【００４１】
そこで、以下の実施形態では、上記参考例での知見を元に、上記のような受信データの誤受信を防ぐことができ、中継局となる上流のデバイスにおいて、どのようにして10b8b Decoding処理において検知したエラー情報を伝達し、次局の下流のデバイスに伝えていくかに関し、図面を参照してより具体的に説明する。尚、この説明においては、全図にわたり共通の部分には共通の参照符号を付す。
【００４２】
［第１実施形態］
次に、第１の実施形態について、図５乃至図９を用いて説明する。この説明において、上記の説明と重複する部分の詳細な説明を省略する。
【００４３】
＜１.送受信装置（Device 0）の構成例＞
まず、図５を用い、第１の実施形態に係る送受信装置（本例では、半導体記憶装置）の構成例について説明する。ここでは、一例として上記UHS-II規格に準拠されるシステム（リングトポロジー）に配置される１つの送受信デバイス（Device 0）を一例に挙げる。
【００４４】
ここで、図示するDevice 0は、例えば、ＳＤカード（登録商標）などに代表されるような、NAND Flash Memory １１を実装したDeviceのブロック図である。しかしながら、ここに示したメモリデバイス構成に限れない。本例は、下記に説明するController１２内のHost Interface Controller２１に関連する技術においては、例えばMemory Controller１２とNAND Flash Memory １１の替わりに、無線LAN Interfaceを実装した無線LANカードのような送受信Deviceにおいても適用可能である。
【００４５】
図示するように、本例に係るデバイス（Device 0）は、ＮＡＮＤ型フラッシュメモリ１１、およびこのＮＡＮＤ型フラッシュメモリ１１を制御するコントローラ１２を備える。
【００４６】
ＮＡＮＤ型フラッシュメモリ（NAND Flash Memory）１１は、ワード線およびビット線の交差位置にマトリックス状に配置される複数のメモリセルを有するメモリセルアレイに、データを不揮発に記憶する。メモリセルのそれぞれは、半導体基板上に順次積層されるトンネル絶縁膜、電荷蓄積層、電極間絶縁膜、制御ゲートを備える。制御ゲートは、上記ワード線に接続される。メモリセルの電流経路は、ビット線方向に複数個接続され、メモリセルユニットを形成する。
また、データ書き込み、データ読み出しは、ワード線単位（ページ単位）で行われる。データ消去は、ブロック単位で一括して行われる。
【００４７】
コントローラ（Controller）１２は、ホストインターフェイス２１、ＭＰＵ２２、バッファ２３、およびメモリコントローラ２４を備える。
【００４８】
ホストインターフェイス（Host Interface Controller）２１は、このデバイスの外部(ホストや自分以外のデバイス)からのコマンドパケットやデータパケットの受信RXおよび送信TXの際の所定の変換、例えば8b10b Encoding処理、10b8b Decoding処理、Serialize処理、Deserialize処理、CRC付加処理、CRCチェック処理を行う。
【００４９】
ＭＰＵ２２は、このコントローラ１２全体の制御を行う。
【００５０】
バッファ（Buffer）２３は、ホストインターフェイス２１やメモリコントローラ２４からのデータや制御プログラム等を展開し、記憶する。
【００５１】
メモリコントローラ（Memory Controller）２４は、ＭＰＵ２２の制御を受け、ＮＡＮＤ型フラッシュメモリ１１の制御を行う。
【００５２】
＜２.データ転送動作＞
次に、上記構成おけるデータ転送動作について説明する。
２−１．エラー情報の発生について
まず、図６乃至図８を用い、データ転送動作の際のエラー情報の発生までについて説明する。ここでは、上記図１に示したメモリシステム（リングトポロジー）において、ホスト（Host）から送信されたデータについて、上流の中継局としてのデバイス（Device 0）が、下流のデバイス（Device 1）に対して、データを転送する場合を一例に挙げて以下説明する。また、以下の動作については、コントローラ１２がその制御を行う。
【００５３】
まず、図６（ａ）に示すように、ホストは、８ｂデータ列（Host Tx Side 8b）を、上流のデバイス（Device 0）に送信するため、このデータ列中のデータ(8b Data)とシンボル情報（Symbol）に対して8b10b Encoding処理（１）を行い、図６（ｂ）に示す10bのデータ列（Host Tx Side 10b）に変換する。
ここで、K-Symbolとは8b10b符号化において、8bitの情報を10bitで表現することにより、余った10bitのパターンのうち、いくつかを制御コードとして利用するためのコードである。例えば、UHS-II規格において使用されるK-Symbolの詳細については、次に第２の実施形態で後述する。
【００５４】
続いて、ホストから送信された10bのデータ列は伝送路を通り、HostからDevice0へ転送が行われる。実際には送信側のSerialize処理によって1bitのビット列に変換され伝送路を通り、受信側でDeserialize処理されることで10bitのデータ列に変換されるが、簡略化のため、10bit単位で説明を行なう。また、以後の例でも同様である。
【００５５】
この間にエラーが発生し（２）、10bのデータ列の値が化け、図６（ｃ）に示す”Device0 Rx Side 10b”で示されるデータ列になるとする。本例では、図６（ｃ）中のデータ"0x3FB", "0x3F0"が、データ化けした箇所とする。
【００５６】
続いて、図７（ｃ）から（ｄ）に示すように、Device0において、10bのデータ列を10b8b Decodingによって、8bのデータ列（Device 0 Rx Side8b）に変換する（３）。ここでエラーが発生した箇所"0x3FB", "0x3F0"は、10b8bの変換ができない値に化けている。そのため、8bのデータ列（Device 0 Rx Side8b）では、エラーフラグ付き（Error）のデータ"0xFB", "0xF0"として変換される。ここで8bデータの値は実装によって値が異なるが、本実施例では10bデータの下位8bitを抽出している。また、Symbol情報はデコードできなかったということで不明とされる。
【００５７】
ここで、このエラーを含んだ8bのデータ列（Device 0 Rx Side 8b）を、そのまま下流のデバイス（Device 1）に転送すると、本来間違っているデータ"0xFB", "0xF0"が正しいデータであると誤判断されるおそれがある。これは、例えば、10b8b Decodingでのエラーの検出が出来ない場合にその可能性が上昇する。
【００５８】
その結果、下流のデバイス（Device 1）が、エラーのデータを正しいデータとして受け取り、結果としてデータ破壊が発生してしまう。
【００５９】
２−２．エラーデータの差し替え
そこで、図８（ｅ）に示すように、エラーが発生している場合には、8b10b Encoding＆Error injection処理（４）の際、エラーが発生している箇所"0xFB", "0xF0"に、8b10b符号化では利用されていない10bitのパターンである(0x010)に差し替えを行う。
そして、下流のデバイス（Device 1）に、この差し替えられた後のデータ列（Device 0 Tx 10b）を送信することで、次の下流のデバイス（Device 1）に10b8b Decoding時にエラーを検知させることが可能となる。
【００６０】
２−３.データ転送動作フロー
上記データ転送動作を動作フローに示すと、図９のように示される。
まず、ステップＳ３１の際、上流のデバイス（Device 0）は、ホストから送信されたパケットデータを受信する。この際、受信したデータに対して、例えば、10b8b Decoding処理を行う。
【００６１】
続いて、ステップＳ３２の際、デバイス（Device 0）は、変換後の受信データを確認する。
【００６２】
続いて、ステップＳ３３の際、受信データにエラーが発生しているか否かを判定する。この際、コントローラ１２は、例えば、エラーフラグの有無により、エラーが発生しているか否かを判定する。例えば、上記図７に示したように、エラーが発生した箇所"0x3FB", "0x3F0"は、10b8bの変換ができない値に化けているため、8bのデータ列（Device 0 Rx Side8b）では、エラーフラグ付き（Error）のデータ"0xFB", "0xF0"として変換される。
【００６３】
続いて、ステップＳ３４の際、上記ステップＳ３３の際にエラーが発生していると判定される場合（Yes）には、8b10b Encodingで割り当てられていないデータに差し替えて、下流のデバイス（Device 1）に送信し、このフローを終了する（End）。
【００６４】
例えば、上記図８に示したように、エラーが発生している場合には、コントローラ１２は、8b10b Encoding＆Error injection処理（４）の際、エラーが発生している箇所"0xFB", "0xF0"に、未登録パターンである(0x010)に差し替えを行う。そのため、下流のデバイス（Device 1）に、この差し替えられた後のデータ列（Device 0 Tx Side 10b）を送信することで、次の下流のデバイス（Device 1）に10b8b Decoding時にエラーを検知させることが可能となる。
【００６５】
一方、ステップＳ３５の際、上記ステップＳ３３の際にエラーが発生していないと判定される場合（No）には、上記のような差し替えを行わず、8b10b Encoding処理を行ったデータを、下流のデバイス（Device 1）に送信し、このフローを終了する（End）。
【００６６】
＜３.作用効果＞
第１の実施形態に係る構成および動作によれば、少なくとも下記（１）の効果が得られる。
【００６７】
（１）転送データのエラーを認識でき、データ破壊を防止できる。
上記図１に示したように、本例では、ホスト装置（Host）から、第１送受信装置（Device 0）および第２送受信装置（Device 1）を含み、複数の送受信装置が順次リング状に接続されるシステムに適用される。そして、上流のデバイス（Device 0）が中継局となる場合のデータ転送動作の際、伝送路においてエラーが発生した場合、上流のデバイス（Device 0）は、下流のデバイス（Device 1）宛の送信データ中のエラーが発生した箇所に割り当てられていないデータを差し替えて、送信する（Ｓ３４）。
【００６８】
例えば、上記図８に示したように、エラーが発生している場合には、コントローラ１２は、8b10b Encoding＆Error injection処理（４）の際、エラーが発生している箇所"0xFB", "0xF0"に、未登録パターンである(0x010)に差し替えを行う。
【００６９】
このように、本例では、中継局の上流側のデバイス（Device 0）の8b10b Encoding処理において、転送データ列中のエラー箇所を、本来8b10b変換テーブルには載っていないパターン(0x010)に差し替えることにより、下流側のデバイス（Device 1）にエラー情報を伝達する。
【００７０】
そのため、続く下流側のデバイス（Device 1）では、転送されたデータ列を10b8b Decodingする際に、当該未登録パターン(0x010)に差し替えられた箇所がエラーであると認識することができ、エラーを検出できる。
【００７１】
このように、本例では、ホストと中継局である上流のデバイス（Device 0）の伝送経路中に転送データにノイズ等により10b8b Decodingできないデータ化けが発生した場合であっても、下流のデバイス（Device 1）は、そのエラー発生の箇所を認識することができる。
【００７２】
送信されたデータのエラー箇所を認識できないと、下流のデバイス（Device 1）では誤って正しいデータと認識して受理する可能性が増加し、ホストにとってはデバイスに書き込んだデータが破壊されてしまうというおそれがある。
【００７３】
よって、転送データのエラー発生箇所を認識でき、データ破壊を防止できる点で有利である。
【００７４】
なお、第１の実施形態では全エラーにおいて、一つの未登録パターン(0x010)を利用しているが、未登録パターンを複数用意し、任意の未登録パターンを利用しても良いことは勿論である。
【００７５】
［第２の実施形態］
次に、第２の実施形態について、図１０乃至図１２を用いて説明する。第２の実施形態は、エラー発生箇所に、規格上利用されていないK-Symbolを差し替える一例に関するものである。この説明において、上記説明と重複する部分の詳細な説明を省略する。
【００７６】
＜K-Symbolについて＞
まず、図１０を用い、K-Symbolについて説明する。
【００７７】
図示するように、K-Symbolとは8b10b符号化において、8bitの情報を10bitで表現することにより、余った10bitのパターンのうち、いくつかを制御コードとして利用することである。本例で図示するものは、UHS-II規格においても使用される制御コードとしてのK-Symbolを一例に挙げる。
【００７８】
例えば、図中のK-Symbol（K28.0）のシンボル名はSDBであり、機能としてはデータバーストを開始すること（Start of Data Burst）であり、値は0x1Cである。以下、同様に、図示するようなK-Symbolが定められている。
【００７９】
ここで、図中のK-Symbolのうち、例えば、K28.2 (Value:0x5C)、K28.4 (Value:0x9C)、K28.7 (Value:0xFC)、K30.7 (Value:0xFE)については、利用されていない未使用のK-Symbolである。
【００８０】
本例では、以下に詳説するように、エラー発生箇所に、K28.4 (Value:0x9C)等の利用されていない未使用のK-Symbolを差し替える点で、上記第１の実施形態と相違する。
【００８１】
＜データ転送動作＞
本例では、UHS-II規格においては利用されていない図１０に示した以外のK-Symbolをエラーがあった箇所に埋め込むことで、後続のノードにエラーを検知させる。
【００８２】
まず、図１１を用いて、データ転送動作について説明する。なお、エラーの発生までは上記第１の実施形態と同様であるため、詳細な説明は省略する。
【００８３】
図１１（ｂ）に示すように、ホストから中継局としてデータ列（Device 0 Rx Side 8b）を受信した上流のデバイス（Device 0）は、8b10b Encoding 処理（５）の前に、エラーの発生した箇所について、D-Symbolから規格では未使用のK-Symbol（本実施例では0x9CのK-Symbol）に差し替えを行なう（処理４）。
【００８４】
続いて、上流のデバイス（Device 0）は、差し替えられたデータに同様の8b10b Encoding を行い(処理５)、次の下流のデバイス（Device 1）にデータを転送する。
【００８５】
＜データ転送フロー＞
本例のデータ転送フローは、図１２のように示される。
図示するように、本例では、ステップＳ４４の際、ステップＳ４３の際にエラーが発生していると判定される場合（Yes）には、エラーの発生した箇所について、D-Symbolから未使用のK-Symbol（制御コード）に差し替える点で、上記第１の実施形態と相違する。例えば、上記図１１（ｂ）に示したように、エラーが発生している場合には、エラーの発生した箇所"0xFB"、"0xF0"について、D-Symbolから未使用のK-Symbol（制御コード）に差し替える。
【００８６】
続いて、ステップＳ４５の際、差し替えられたデータに同様の8b10b Encoding を行い、次の下流のデバイス（Device 1）にデータを転送する（End）。そのため、上記図１１（ｃ）に示すように、8b10b Encoding処理が行われた後のデータ列は、エラー発生箇所が"0x0F2"、"0x30D"となり、次の下流のデバイス（Device 1）に10b8b Decoding時にエラーを検知させることが可能となる。
【００８７】
これは、後続の下流のデバイス（Device 1）では、元々エラーが発生していた箇所に、規格未定義のK-Symbolを発見することになるので、正常のデータではないと判断することができるためである。
【００８８】
なお、この方法では、後続のノードにおいて利用されていないK-Symbolが存在した場合にどう動作するか、によって影響されるため不確定とも思われる。
【００８９】
＜作用効果＞
第２の実施形態によれば、少なくとも上記（１）と同様の効果が得られる。
【００９０】
本例では、エラーが発生していると判定される場合（Yes）には、エラーの発生した箇所について、D-Symbolから未使用のK-Symbol（制御コード）に差し替える点で、上記第１の実施形態と相違する。例えば、上記図１１（ｂ）に示したように、エラーが発生している場合には、エラーの発生した箇所"0xFB"、"0xF0"について、D-Symbolから未使用のK-Symbol（0x9C）に差し替える。
【００９１】
続いて、差し替えられたデータに同様の8b10b Encoding を行い、次の下流のデバイス（Device 1）にデータを転送する。そのため、上記図１１（ｃ）に示すように、8b10b Encoding処理が行われた後のデータ列は、エラー発生箇所が"0x0F2"、"0x30D"となり、次の下流のデバイス（Device 1）に10b8b Decoding時にエラーを検知させることが可能となる。
【００９２】
これは、後続の下流のデバイス（Device 1）では、元々エラーが発生していた箇所に、規格未定義のK-Symbolを発見することになるので、正常のデータではないと判断することができるためである。
【００９３】
［第３の実施形態（CRCチェック）］
次に、第３の実施形態について、図１３、図１４を用いて説明する。この実施形態は、CRCチェックを行う際のエラー検知に関するものである。この説明において、上記説明と重複する部分の詳細な説明を省略する。
【００９４】
＜データ転送動作＞
本例では、データを中継する際にレイテンシを低く抑える上記第１、第２の実施形態とは異なり、データを中継する際にCRCチェックを行い、そのCRCチェックでエラーを検知する一例に関する。
【００９５】
このように、本例では、データ転送の中継時にも、受信時と同じように受信データに対してCRC計算を行う。そして、新しく計算したCRCを最低でも1bit値を変更したもので古いCRCを差し替え、下流のデバイスに送信する点で、上記第１、第２の実施形態と相違する。
【００９６】
このようにすることで、次の下流のデバイスでは、CRCチェックを行った結果、エラーとなるため、誤受信を防止することができる。
【００９７】
なお、CRCはパケット内のデータに対して計算が行われ、パケットの先頭を示すCOM+SOP制御コード、データ、CRC、パケットの終了を示すCOM+EOPという順番で送信される。
【００９８】
例えば、本例の場合、より具体的には、図１３のように示される。
【００９９】
まず、図１３（ａ）〜（ｂ）に示すように、エラーによって化けたデータ"0xFB"は、そのまま通常のデータとみなして、CRCの再計算を行なう。
【０１００】
ただし、元々パケット中に存在していたCRCの該当箇所（本例では、COM+EOPの前の２バイトデータ"0x57", "0x84 "）に関しては、本例の計算の対象外である。
【０１０１】
このように、図中の処理（４）のように、新しく再計算したCRCでは該当箇所の値を反転させて古いCRCの箇所と置き換えを行う。CRCは最低1bitを反転させれば良いが、本実施例では全ビット反転させるとした。
【０１０２】
その後、同様の8b10b Encodingを行い（処理（５））、次の下流のデバイスにデータを転送する。
【０１０３】
＜データ転送フロー＞
本例のデータ転送フローは、図１４のように示される。
図示するように、まず、本例では、ステップＳ５３の際、上流のデバイス（Device 0）が確認した転送データ内に、COM+SOP受信後かつCOM+EOPの2Byte以上前か否かの判定を行う。上記ステップＳ５３の際に該当しないと判定される場合（No）には、次のステップＳ５５に進む。
【０１０４】
続いて、ステップＳ５４の際、上記ステップＳ５３の際に該当すると判定される場合（Yes）には、エラーの発生した箇所について、通常のCRC計算の対象とする点で、上記実施形態と相違する。
【０１０５】
続いて、ステップＳ５５の際、COM+EOPの１Byteもしくは２Byte前か否かの判定を行う。
【０１０６】
続いて、ステップＳ５６の際、上記ステップＳ５５の際に該当すると判定される場合（Yes）には、計算していたCRCを反転させる。例えば、図１３に示したように、新しく再計算したCRCでは該当箇所の値を反転させて古いCRCの箇所と置き換えを行う。
【０１０７】
続いて、ステップＳ５７に進む。
【０１０８】
続いて、ステップＳ５７の際、上記ステップＳ５５の際に該当しないと判定される場合（No）には、同様にデータに8b10b Encodingを行い、次の下流のデバイス（Device 1）にデータを転送する（End）。
【０１０９】
＜作用効果＞
第３の実施形態によれば、少なくとも上記（１）と同様の効果が得られる。
【０１１０】
さらに、本例では、データを中継する際にCRCチェックを行い、そのCRCチェックでエラーを検知させる。
【０１１１】
例えば、ステップＳ５６の際、上記ステップＳ５５の際に該当すると判定される場合（Yes）には、計算していたCRCを反転させる。図１３に示したように、新しく再計算したCRCでは該当箇所の値を反転させて古いCRCの箇所と置き換えを行う。
【０１１２】
この操作によって、送信したデータは、下流のデバイス（Device 1）でCRCエラーとなるため、間接的にHostからDevice 0への伝送路でエラーが発生したことを伝えることができる。そのため、誤受信を防止することができる。
【０１１３】
［第４の実施形態（使用される制御コードと差し替える一例）］
次に、第４の実施形態について、図１５、図１６を用いて説明する。この実施形態は、使用される制御コードに差し替えてエラーを検知させる一例に関するものである。この説明において、上記実施形態と重複する部分の詳細な説明を省略する。
【０１１４】
＜データ転送動作＞
本例では、規格で利用されている制御コードを使う方法に関する。
【０１１５】
第２の実施形態で説明したように、UHS-II規格においてK-Symbolが定められているが、制御コードはCOMというK-Symbolと、もう一つのK-Symbolがセットになることで、一つの意味を持つ制御コードとなる。また、制御コードには、COM+LIDLやCOM+DIDLのように、アイドル状態を示すだけの制御コードが定められている。
【０１１６】
そのため、本例では、アイドル状態を示すだけの制御コードを、エラーがあった箇所に埋め込むことで、続く下流のデバイス（Device 1）にエラーを検知させる。なお、エラーの発生までは第１の実施形態と同様である。
【０１１７】
図１５（ａ）、（ｂ）に示すように、処理（４）の際、２バイト単位でエラーが発生しているかチェックを行い、エラーが発生していた箇所（"0xFB", "0xF0"）には、データバースト転送中のアイドル状態を示すCOM+DIDLに差し替えを行う。
【０１１８】
続いて、その後は、同様の8b10b Encodingを行い（処理（５））、次の下流のデバイス（Device 1）への転送データとする。
【０１１９】
＜データ転送フロー＞
本例のデータ転送フローは、図１６のように示される。
図示するように、本例では、ステップＳ６４の際、ステップＳ６３の際にエラーが発生していると判定される場合（Yes）には、該当箇所をデータバースト転送中のアイドル状態を示すCOM+DIDLに差し替えを行う。例えば、図１５に示したように、エラーが発生していた箇所（"0xFB", "0xF0"）には、データバースト転送中のアイドル状態を示すCOM+DIDLに差し替えを行う。
【０１２０】
続いて、同様にデータに8b10b Encodingを行い、次の下流のデバイス（Device 1）にデータを転送する（End）。
【０１２１】
このように、本例では、元々エラーが発生していた箇所に、アイドル状態を示すCOM+DIDLが存在することになるが、データパケット中にCOM+DIDLが存在することは規格に定義されたデータ構造ではない。そのため、後続の下流のデバイスではCOM+DIDLが混ざったパケットは、正常のデータではないと判断することができる。
【０１２２】
＜作用効果＞
第４の実施形態によれば、少なくとも上記（１）と同様の効果が得られる。
【０１２３】
さらに、本例では、ステップＳ６４の際、ステップＳ６３の際にエラーが発生していると判定される場合（Yes）には、該当箇所をデータバースト転送中のアイドル状態を示すCOM+DIDLに差し替えを行う。例えば、図１５に示したように、エラーが発生していた箇所（"0xFB", "0xF0"）には、データバースト転送中のアイドル状態を示すCOM+DIDLに差し替えを行う。
【０１２４】
このように、元々エラーが発生していた箇所に、アイドル状態を示すCOM+DIDLが存在することになるが、データパケット中にCOM+DIDLが存在することは規格に定義されたデータ構造ではない。そのため、後続の下流のデバイスではCOM+DIDLが混ざったパケットは、正常のデータではないと判断することができる。
【０１２５】
必要に応じて、本例を適用することが可能である。
【０１２６】
［変形例］
上記参考例および実施形態では、リング状にされたホスト装置（Host）および２つのデバイス（Device 0, Device 1）を一例に挙げたが、これに限られることはない。
【０１２７】
例えば、リング状に接続されるホスト装置（Host）および３つの以上のデバイス（Device 0, Device 1, Device 2, ,,, , Device N）であっても同様に適用可能である。この場合、データの中継局は、宛先局以外のデバイスが該当し得る。
【０１２８】
また、ホスト装置からデバイスへのデータ転送を例に説明したが、デバイスからホスト装置へのデータ転送においても、間に中継局が存在すれば、同様に適用可能である。
【０１２９】
また、リング接続に限られず、例えば、ホストと複数のデバイスが直列に接続される多重伝送システム等に対しても同様に適用可能である。
【０１３０】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１３１】
Host…ホスト装置、Device 0…上流の第１送受信装置（中継局）、Device 1…下流の第２送受信装置。
【特許請求の範囲】
【請求項１】
第１送受信装置および第２送受信装置を含み、複数の送受信装置が順次リング状に接続されるシステムにおいて、
中継局となる送受信装置のデータ転送動作の際、転送経路においてエラーが発生した場合、前記中継局となる送受信装置が、中継する送信データの一部を内部で生成したデータに差し替えを行い、下流に送信する。
【請求項２】
前記内部で生成したデータの差し替えることは、エラーが発生した箇所を8b10b Encodingにおいて使用されていないデータパターンに差し替えることかまたは規格上使用されていないK-Symbolかまたはアイドル状態を示す制御コードに差し替えることである
請求項１に記載のシステム。
【請求項３】
転送経路においてエラーが発生した場合、前記中継局である送受信装置は、中継データのCRCを計算し、中継データ中のCRCに対して計算したCRCを破壊した値への差し替えを行い、受信先のホスト装置乃至前記送受信装置とは別個の送受信装置のCRCチェックでエラー検知させる
請求項１に記載のシステム。
【請求項４】
複数の送受信装置が順次リング状に接続されるシステムにおいて、
前記複数の送受信装置のうちの中継局となる場合の送受信装置は、データ転送動作の際、転送経路においてエラーが発生した場合、中継局である前記受信装置は、送信データ中の一部を内部で生成したデータに差し替えを行い、下流に送信する。
【請求項５】
前記装置内部で生成したデータの差し替えとは、エラーが発生した箇所を8b10b Encodingにおいて使用されていないデータパターンに差し替えることかまたは規格上使用されていないK-Symbolかまたはアイドル状態を示す制御コードに差し替えることである
請求項４に記載の送受信装置。
【請求項１】
第１送受信装置および第２送受信装置を含み、複数の送受信装置が順次リング状に接続されるシステムにおいて、
中継局となる送受信装置のデータ転送動作の際、転送経路においてエラーが発生した場合、前記中継局となる送受信装置が、中継する送信データの一部を内部で生成したデータに差し替えを行い、下流に送信する。
【請求項２】
前記内部で生成したデータの差し替えることは、エラーが発生した箇所を8b10b Encodingにおいて使用されていないデータパターンに差し替えることかまたは規格上使用されていないK-Symbolかまたはアイドル状態を示す制御コードに差し替えることである
請求項１に記載のシステム。
【請求項３】
転送経路においてエラーが発生した場合、前記中継局である送受信装置は、中継データのCRCを計算し、中継データ中のCRCに対して計算したCRCを破壊した値への差し替えを行い、受信先のホスト装置乃至前記送受信装置とは別個の送受信装置のCRCチェックでエラー検知させる
請求項１に記載のシステム。
【請求項４】
複数の送受信装置が順次リング状に接続されるシステムにおいて、
前記複数の送受信装置のうちの中継局となる場合の送受信装置は、データ転送動作の際、転送経路においてエラーが発生した場合、中継局である前記受信装置は、送信データ中の一部を内部で生成したデータに差し替えを行い、下流に送信する。
【請求項５】
前記装置内部で生成したデータの差し替えとは、エラーが発生した箇所を8b10b Encodingにおいて使用されていないデータパターンに差し替えることかまたは規格上使用されていないK-Symbolかまたはアイドル状態を示す制御コードに差し替えることである
請求項４に記載の送受信装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公開番号】特開２０１３−１７０９０（Ｐ２０１３−１７０９０Ａ）
【公開日】平成２５年１月２４日（２０１３．１．２４）
【国際特許分類】
【出願番号】特願２０１１−１４９３７９（Ｐ２０１１−１４９３７９）
【出願日】平成２３年７月５日（２０１１．７．５）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２５年１月２４日（２０１３．１．２４）
【国際特許分類】
【出願日】平成２３年７月５日（２０１１．７．５）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]