特開2023-164403キャプチャバッファに格納されたデータを削減する方法及びシステム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023164403
(43)【公開日】2023-11-10
(54)【発明の名称】キャプチャバッファに格納されたデータを削減する方法及びシステム
(51)【国際特許分類】
H04L 43/028 20220101AFI20231102BHJP
【ＦＩ】
H04L43/028
【審査請求】未請求
【請求項の数】10
【出願形態】ＯＬ
【外国語出願】
(21)【出願番号】P 2023074726
(22)【出願日】2023-04-28
(31)【優先権主張番号】63/336,009
(32)【優先日】2022-04-28
(33)【優先権主張国・地域又は機関】US
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕ－ｒａｙ
(71)【出願人】
【識別番号】514046574
【氏名又は名称】キーサイト テクノロジーズ， インク．
(74)【代理人】
【識別番号】100099623
【弁理士】
【氏名又は名称】奥山 尚一
(74)【代理人】
【識別番号】100125380
【弁理士】
【氏名又は名称】中村 綾子
(74)【代理人】
【識別番号】100142996
【弁理士】
【氏名又は名称】森本 聡二
(74)【代理人】
【識別番号】100166268
【弁理士】
【氏名又は名称】田中 祐
(74)【代理人】
【識別番号】100218604
【弁理士】
【氏名又は名称】池本 理絵
(72)【発明者】
【氏名】アンドリュー・ロバート・ルヘイン
(72)【発明者】
【氏名】ダニエル・アレハンドロ・ガルシア・ウジョア
(57)【要約】 （修正有）
【課題】解析用の高速階層型パケットベースのプロトコルに準拠するデータリンクを介したデータの通信中に、インターポーザ回路のキャプチャバッファに格納されるデータを削減する方法及びシステムを提供する。
【解決手段】方法は、データのデータ完全性チェックをリアルタイムに実行し、データが正しい場合にはデータのトランザクション層パケット（ＴＬＰ）及びデータリンク層パケット（ＤＬＬＰ）からのデータ完全性チェックに対応するデータ完全性ビットを省き、ＡＣＫ／ＮＡＣＫパケットを使用して、データのＴＬＰが正常に配信を確認するために、ＡＣＫ／ＮＡＣＫの照合をリアルタイムに実行し、このＡＣＫ／ＮＡＣＫパケットを、キャプチャバッファに格納することから省き、データのＴＬＰ及び／又はＤＬＬＰから、リアルタイムにフィールドを削除及び／又は削減し、データのＴＬＰ及び／又はＤＬＬＰのデータペイロードを並列で圧縮する。
【選択図】図２
【解決手段】方法は、データのデータ完全性チェックをリアルタイムに実行し、データが正しい場合にはデータのトランザクション層パケット（ＴＬＰ）及びデータリンク層パケット（ＤＬＬＰ）からのデータ完全性チェックに対応するデータ完全性ビットを省き、ＡＣＫ／ＮＡＣＫパケットを使用して、データのＴＬＰが正常に配信を確認するために、ＡＣＫ／ＮＡＣＫの照合をリアルタイムに実行し、このＡＣＫ／ＮＡＣＫパケットを、キャプチャバッファに格納することから省き、データのＴＬＰ及び／又はＤＬＬＰから、リアルタイムにフィールドを削除及び／又は削減し、データのＴＬＰ及び／又はＤＬＬＰのデータペイロードを並列で圧縮する。
【選択図】図２
【特許請求の範囲】
【請求項1】
テスト対象システムと解析用のプロトコルアナライザとの間の高速階層型パケットベースのプロトコルに準拠するデータリンクを介したデータの通信中に、機能を損なうことなく、かつ前記解析で利用できる情報を失うことなく、インターポーザ回路のキャプチャバッファに格納される前記データの量を削減する方法であって、
前記データのデータ完全性チェックをリアルタイムに実行し、該データ完全性チェックにより、前記データが正しいことが示された場合、前記データのトランザクション層パケット（ＴＬＰ）及びデータリンク層パケット（ＤＬＬＰ）からの前記データ完全性チェックに対応するデータ完全性ビットを、前記キャプチャバッファに格納することから省くことと、
確認応答と否定応答（ＡＣＫ／ＮＡＣＫ）パケットを使用して、前記データの前記ＴＬＰの到着成功又は到着失敗を示すために、ＡＣＫ／ＮＡＣＫの照合をリアルタイムに実行し、前記ＡＣＫ／ＮＡＣＫパケットを、前記キャプチャバッファに格納することから省くことと、
前記キャプチャバッファに格納されるべき前記データの前記ＴＬＰ及び／又は前記ＤＬＬＰから、リアルタイムにフィールドを削除、及び／又は、削減することと
を含む方法。
前記データのデータ完全性チェックをリアルタイムに実行し、該データ完全性チェックにより、前記データが正しいことが示された場合、前記データのトランザクション層パケット（ＴＬＰ）及びデータリンク層パケット（ＤＬＬＰ）からの前記データ完全性チェックに対応するデータ完全性ビットを、前記キャプチャバッファに格納することから省くことと、
確認応答と否定応答（ＡＣＫ／ＮＡＣＫ）パケットを使用して、前記データの前記ＴＬＰの到着成功又は到着失敗を示すために、ＡＣＫ／ＮＡＣＫの照合をリアルタイムに実行し、前記ＡＣＫ／ＮＡＣＫパケットを、前記キャプチャバッファに格納することから省くことと、
前記キャプチャバッファに格納されるべき前記データの前記ＴＬＰ及び／又は前記ＤＬＬＰから、リアルタイムにフィールドを削除、及び／又は、削減することと
を含む方法。
【請求項2】
前記キャプチャバッファに格納されるべき前記データの前記ＴＬＰ及び／又は前記ＤＬＬＰのペイロードを並列に圧縮することを更に含み、
前記データの前記ＴＬＰ及び／又は前記ＤＬＬＰのペイロードを圧縮することは、前記インターポーザ回路での前記ＴＬＰ及び／又は前記ＤＬＬＰのペイロードからシンボルを複数のシリアルレーンで受信することと、前記ＴＬＰ及び／又は前記ＤＬＬＰの前記ペイロードからの前記シンボルをクロックサイクルの各クロックに到着するワイドワードへとデスキューすることと、前記ワイドワードを入力ストリームに配列することであって、各入力ストリームは前記クロックサイクルの各クロックに到着する各ワイドワードの同位置からのシンボルを含むことと、前記配列されたデスキュー後のシンボルをハッシュテーブルを使用して圧縮することと、前記圧縮後のシンボルを前記キャプチャバッファに格納することとを含む、
請求項１に記載の方法。
前記データの前記ＴＬＰ及び／又は前記ＤＬＬＰのペイロードを圧縮することは、前記インターポーザ回路での前記ＴＬＰ及び／又は前記ＤＬＬＰのペイロードからシンボルを複数のシリアルレーンで受信することと、前記ＴＬＰ及び／又は前記ＤＬＬＰの前記ペイロードからの前記シンボルをクロックサイクルの各クロックに到着するワイドワードへとデスキューすることと、前記ワイドワードを入力ストリームに配列することであって、各入力ストリームは前記クロックサイクルの各クロックに到着する各ワイドワードの同位置からのシンボルを含むことと、前記配列されたデスキュー後のシンボルをハッシュテーブルを使用して圧縮することと、前記圧縮後のシンボルを前記キャプチャバッファに格納することとを含む、
請求項１に記載の方法。
【請求項3】
前記データの前記データ完全性チェックをリアルタイムに実行することは、前記インターポーザ回路上の前記ＴＬＰと前記ＤＬＬＰにおいて巡回冗長検査（ＣＲＣ）をチェックし、前記インターポーザ回路上の前記ＴＬＰにおいてフレームパリティビットをチェックすることを含み、
前記データ完全性ビットを格納することから省くことは、誤りがないことを示す前記ＣＲＣのチェックサムを削除することであって、誤りを示す前記ＣＲＣのチェックサムを前記キャプチャバッファに格納することと、誤りがないことを示すフレームパリティビットを省くことであって、誤りを示すフレームパリティビットを前記キャプチャバッファに格納することとを含む、
請求項１に記載の方法。
前記データ完全性ビットを格納することから省くことは、誤りがないことを示す前記ＣＲＣのチェックサムを削除することであって、誤りを示す前記ＣＲＣのチェックサムを前記キャプチャバッファに格納することと、誤りがないことを示すフレームパリティビットを省くことであって、誤りを示すフレームパリティビットを前記キャプチャバッファに格納することとを含む、
請求項１に記載の方法。
【請求項4】
前記ＡＣＫ／ＮＡＣＫパケットはＤＬＬＰであり、
該ＡＣＫ／ＮＡＣＫ ＤＬＬＰを格納する代わりに、前記ＴＬＰはそれぞれ、前記キャプチャバッファ内で付加されたメタデータを含み、前記メタデータは、それぞれの前記ＴＬＰのＡＣＫ／ＮＡＣＫの状態を示す、請求項１に記載の方法。
該ＡＣＫ／ＮＡＣＫ ＤＬＬＰを格納する代わりに、前記ＴＬＰはそれぞれ、前記キャプチャバッファ内で付加されたメタデータを含み、前記メタデータは、それぞれの前記ＴＬＰのＡＣＫ／ＮＡＣＫの状態を示す、請求項１に記載の方法。
【請求項5】
前記ＴＬＰ及び／又は前記ＤＬＬＰから前記フィールドを削除することは、固定値及び／又は空値を有する既知のフィールドを削除することであって、前記既知のフィールドは、ユーザインタフェースにおいて回復することと、前記ＴＬＰ及び／又は前記ＤＬＬＰのパケットフローの始点と終点を示すフレーミングトークンを削除することであって、前記フレーミングトークンは、より小さいシンボルに置き換えられるか、又は前記フレーミングトークンは削除されることと、前記ユーザインタフェースに入力された設定に基づき、必須ではないものとして特定されたフィールドを削除することとの１つ以上を含む、請求項１に記載の方法。
【請求項6】
高速階層型パケットベースのプロトコルに準拠する高速データリンクを介して、テスト対象デバイス（ＤＵＴ）からホストコンピュータまでの前記高速階層型パケットベースのプロトコルでのデータを解析するアナライザソフトウェアを実行するように構成されたユーザインタフェース（ＵＩ）コンピュータと、
前記ＤＵＴと前記ホストコンピュータとの間で送信される前記データを監視するために前記高速データリンクに接続されたインターポーザ回路であって、該インターポーザ回路は、前記ＤＵＴと前記ホストコンピュータとの間で送信される前記データを格納するキャプチャバッファを含み、前記ＵＩコンピュータが前記アナライザソフトウェアで解析するためにアクセスできるインターポーザ回路と
を含み、前記インターポーザ回路は、
前記データのデータ完全性チェックをリアルタイムに実行し、前記データ完全性チェックにより、前記データが正しいことが示された場合には、前記データのトランザクション層パケット（ＴＬＰ）及びデータリンク層パケット（ＤＬＬＰ）からの前記データ完全性チェックに対応するデータ完全性ビットを、前記キャプチャバッファに格納することから省くことと、
確認応答と否定応答（ＡＣＫ／ＮＡＣＫ）パケットを使用して、前記データの前記ＴＬＰの到着成功又は到着失敗を示すために、ＡＣＫ／ＮＡＣＫの照合をリアルタイムに実行し、前記ＡＣＫ／ＮＡＣＫパケットを、前記キャプチャバッファに格納することから省くことと、
前記キャプチャバッファに格納されるべき前記データの前記ＴＬＰ及び／又は前記ＤＬＬＰから、リアルタイムにフィールドを削除、及び／又は、削減することと
を実行するようにプログラムされているシステム。
前記ＤＵＴと前記ホストコンピュータとの間で送信される前記データを監視するために前記高速データリンクに接続されたインターポーザ回路であって、該インターポーザ回路は、前記ＤＵＴと前記ホストコンピュータとの間で送信される前記データを格納するキャプチャバッファを含み、前記ＵＩコンピュータが前記アナライザソフトウェアで解析するためにアクセスできるインターポーザ回路と
を含み、前記インターポーザ回路は、
前記データのデータ完全性チェックをリアルタイムに実行し、前記データ完全性チェックにより、前記データが正しいことが示された場合には、前記データのトランザクション層パケット（ＴＬＰ）及びデータリンク層パケット（ＤＬＬＰ）からの前記データ完全性チェックに対応するデータ完全性ビットを、前記キャプチャバッファに格納することから省くことと、
確認応答と否定応答（ＡＣＫ／ＮＡＣＫ）パケットを使用して、前記データの前記ＴＬＰの到着成功又は到着失敗を示すために、ＡＣＫ／ＮＡＣＫの照合をリアルタイムに実行し、前記ＡＣＫ／ＮＡＣＫパケットを、前記キャプチャバッファに格納することから省くことと、
前記キャプチャバッファに格納されるべき前記データの前記ＴＬＰ及び／又は前記ＤＬＬＰから、リアルタイムにフィールドを削除、及び／又は、削減することと
を実行するようにプログラムされているシステム。
【請求項7】
前記インターポーザ回路は、
前記インターポーザ回路上の前記ＴＬＰと前記ＤＬＬＰにおいて巡回冗長検査（ＣＲＣ）をチェックし、前記インターポーザ回路上の前記ＴＬＰにおいてフレームパリティビットをチェックすることで、前記データの前記データ完全性チェックをリアルタイムに実行することと、
誤りがないことを示す前記ＣＲＣのチェックサムを削除することであって、誤りを示す前記ＣＲＣのチェックサムを前記キャプチャバッファに格納することと、誤りがないことを示すフレームパリティビットを省くことであって、誤りを示すフレームパリティビットを前記キャプチャバッファに格納することとを実行することで、前記データ完全性ビットを格納することから省くことと
を実行するようプログラムされている、請求項６に記載のシステム。
前記インターポーザ回路上の前記ＴＬＰと前記ＤＬＬＰにおいて巡回冗長検査（ＣＲＣ）をチェックし、前記インターポーザ回路上の前記ＴＬＰにおいてフレームパリティビットをチェックすることで、前記データの前記データ完全性チェックをリアルタイムに実行することと、
誤りがないことを示す前記ＣＲＣのチェックサムを削除することであって、誤りを示す前記ＣＲＣのチェックサムを前記キャプチャバッファに格納することと、誤りがないことを示すフレームパリティビットを省くことであって、誤りを示すフレームパリティビットを前記キャプチャバッファに格納することとを実行することで、前記データ完全性ビットを格納することから省くことと
を実行するようプログラムされている、請求項６に記載のシステム。
【請求項8】
前記ＡＣＫ／ＮＡＣＫパケットはＤＬＬＰであり、
該ＡＣＫ／ＮＡＣＫ ＤＬＬＰを格納する代わりに、前記ＴＬＰはそれぞれ、前記キャプチャバッファ内で付加されたメタデータを含み、前記メタデータは、それぞれの前記ＴＬＰのＡＣＫ／ＮＡＣＫの状態を示す、
請求項６に記載のシステム。
該ＡＣＫ／ＮＡＣＫ ＤＬＬＰを格納する代わりに、前記ＴＬＰはそれぞれ、前記キャプチャバッファ内で付加されたメタデータを含み、前記メタデータは、それぞれの前記ＴＬＰのＡＣＫ／ＮＡＣＫの状態を示す、
請求項６に記載のシステム。
【請求項9】
前記インターポーザ回路は、
固定値及び／又は空の値を有する既知のフィールドを削除することであって、該既知のフィールドは、ユーザインタフェースにおいて回復することと、
前記ＴＬＰ及び／又は前記ＤＬＬＰのパケットフローの始点と終点を示すフレーミングトークンを削除することであって、該フレーミングトークンは、より小さいシンボルに置き換えられるか、又は該フレーミングトークンは削除されることと、
前記ユーザインタフェースに入力された設定に基づき、必須ではないものとして特定されたフィールドを削除することと
のうちの１つ以上を実行することで、前記ＴＬＰ及び／又は前記ＤＬＬＰから前記フィールドを削除するようプログラムされている、請求項６に記載のシステム。
固定値及び／又は空の値を有する既知のフィールドを削除することであって、該既知のフィールドは、ユーザインタフェースにおいて回復することと、
前記ＴＬＰ及び／又は前記ＤＬＬＰのパケットフローの始点と終点を示すフレーミングトークンを削除することであって、該フレーミングトークンは、より小さいシンボルに置き換えられるか、又は該フレーミングトークンは削除されることと、
前記ユーザインタフェースに入力された設定に基づき、必須ではないものとして特定されたフィールドを削除することと
のうちの１つ以上を実行することで、前記ＴＬＰ及び／又は前記ＤＬＬＰから前記フィールドを削除するようプログラムされている、請求項６に記載のシステム。
【請求項10】
前記インターポーザ回路は、前記ＴＬＰの様々なアドレスフィールドのサイズを削減することで、前記ＴＬＰから前記フィールドを削減するようプログラムされている、請求項６に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
［関連出願の相互参照］
本出願は、米国特許法第１１９条（ｅ）に基づいて、２０２２年４月２８日に出願された米国仮出願第６３／３３６，００９号、２０２２年８月１８日に出願された米国仮出願第６３／３９９，１１８号、２０２２年１０月２４日に出願された米国仮出願第６３／４１８，７６１号及び２０２２年１２月８日に出願された米国仮出願第６３／４３１，１００号に対する優先権を主張する、２０２２年１２月２８日に出願された米国特許出願第１８／０９０，３１１号に対する優先権を主張するものである。米国仮出願第６３／３３６，００９号、米国仮出願第６３／３９９，１１８号、米国仮出願第６３／４１８，７６１号、及び米国仮出願第６３／４３１，１００号の全開示は、その全体が具体的に引用することにより明確に本明細書の一部をなすものとする。
本出願は、米国特許法第１１９条（ｅ）に基づいて、２０２２年４月２８日に出願された米国仮出願第６３／３３６，００９号、２０２２年８月１８日に出願された米国仮出願第６３／３９９，１１８号、２０２２年１０月２４日に出願された米国仮出願第６３／４１８，７６１号及び２０２２年１２月８日に出願された米国仮出願第６３／４３１，１００号に対する優先権を主張する、２０２２年１２月２８日に出願された米国特許出願第１８／０９０，３１１号に対する優先権を主張するものである。米国仮出願第６３／３３６，００９号、米国仮出願第６３／３９９，１１８号、米国仮出願第６３／４１８，７６１号、及び米国仮出願第６３／４３１，１００号の全開示は、その全体が具体的に引用することにより明確に本明細書の一部をなすものとする。
【背景技術】
【0002】
周辺機器相互接続エクスプレス（ＰＣＩｅ：Peripheral Component Interconnect Express）は、パーソナルコンピュータ（ＰＣ:personal computer）のホスト中央処理ユニット（ＣＰＵ：central processing unit）と、例えば、グラフィックスカード、サウンドカード、ソリッドステートドライブ（ＳＳＤ：solid state drive）、及びデータセンタで使用されるワークロードアクセラレータカード等の様々な高速周辺構成要素との間の代表的な相互接続プロトコルである。そのため、最新バージョンの仕様策定後、市場をできるだけ多く獲得するために、ＰＣＩｅインターコネクトをベースとする新製品を迅速に発売することが求められる。市場投入までの時間を短縮するために、様々なツールで開発活動を支援し、加速させている。よく使用されるツールの１つに、ＰＣＩｅプロトコルアナライザがある。従来のＰＣＩｅプロトコルアナライザは、ＰＣＩｅバス上で通信する様々なモジュール同士のＰＣＩｅ相互作用に関する詳細な解析とデバッグのユーザに対する支援を目的とする、様々な表示とプロトコル検索機能をサポートしている。
【0003】
一般的に、ＰＣＩｅは、周辺機器接続用の高速ハードウェアインタフェースとして使用されるレイヤパケットベースのプロトコルであり、このプロトコルでは、主として、データリンク層とトランザクション層と呼ばれる上位の２層でデータが転送される。データリンク層は、確認応答による配信の保証、フロー制御、及び電力管理機能をサポートする。データリンク層よりも上位にあるトランザクション層は、スプリットトランザクション（リクエストとレスポンスを時間で区切ったトランザクション）を実装して、ターゲットデバイスがレスポンス用のデータを収集している間、通信リンクが他のトラフィックを搬送できるようにする。階層型パケットベースプロトコルの最下層は、物理層と呼ばれる。
【0004】
開発段階のＰＣＩｅの最新バージョンである周辺機器相互接続分科会（ＰＣＩ－ＳＩＧ（商標）（Peripheral Component Interconnect Special Interest Group））によるＰＣＩｅ Ｇｅｎ６プロトコルでは、ＰＣＩｅ Ｇｅｎ５プロトコルで６４ＧＢ／秒、ＰＣＩｅ Ｇｅｎ４プロトコルで３２ＧＢ／秒という従来のマルチレーン帯域幅（multi-lane bandwidth）から最大１２８ＧＢ／秒まで増加するマルチレーン帯域幅を企図している。非常に高いスループットをサポートすることにより、ＰＣＩｅ Ｇｅｎ６プロトコルは、ストレージ業界において不揮発性メモリエクスプレス（ＮＶＭｅ：Non-Volatile Memory Express）、シリアルアドバンスドテクノロジアタッチメント（ＳＡＴＡ：Serial Advanced Technology Attachment）、及び、スモールコンピュータシステムインタフェース（ＳＣＳＩ：Small Computer System Interface）エクスプレスプロトコルと併用される他、例えば、ＣＸＬ、ＣＣＩＸ、Ｇｅｎ－Ｚ等の将来のアクセラレータプロトコルにも使用されることが見込まれる。このような高いビットレートに対応すべく、ＰＣＩｅプロトコルアナライザがＰＣＩｅバス上のプロトコル交換をキャプチャする場合、これまで提案されたソリューションは、ストレージ用の大容量メモリバッファに依存しており、例えば、ＰＣＩｅ Ｇｅｎ５で最大４秒間のフル６４ＧＢ／秒のデータキャプチャをサポートし得る。
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかし、このようなアプローチは、転送、格納、最終的には、処理する必要のあるデータが膨大であることが原因で、材料コストがかかり、さらに、誤りも起こりやすくなることで、信号完全性、及びデータ処理に関する課題を招くことがある。
【課題を解決するための手段】
【0006】
例示的な実施形態は、添付の図面と併せて読むと、以下の詳細な説明から最も深く理解される。種々の特徴は必ずしも縮尺通りに描かれていないことを強調したい。実際には、検討を明確にするために、寸法が任意に拡大又は縮小される場合がある。適用可能で、実用的な場合にはいつでも、同じ参照番号が同じ要素を指している。
【図面の簡単な説明】
【0007】
【図1】代表的な実施形態に係る、高速データリンクを介したデータの通信のキャプチャ中、機能を損なうことなく、かつ解析で利用できる情報を失うことなく、格納されたデータ量を削減するシステムの簡略ブロック図である。
【図2】代表的な実施形態に係る、高速階層型パケットベースのプロトコルに準拠するデータリンクを介したデータの通信中、機能を損なうことなく、かつ解析で利用できる情報を失うことなく、インターポーザ回路のキャプチャバッファに格納されるデータ量を削減する方法を示す簡略流れ図である。
【図3A】代表的な実施形態に係る、キャプチャバッファに格納せずに破棄するべき例示的なトランザクション層パケット（ＴＬＰ：transaction layer packet）及び例示的なデータリンク層パケット（ＤＬＬＰ：data link layer packet）のＣＲＣフィールドを示す図である。
【図3B】代表的な実施形態に係る、キャプチャバッファに格納せずに、ＡＣＫ／ＮＡＣＫパケットを破棄可能にする、ＴＬＰとＤＬＬＰのシーケンス番号フィールドを示す図である。
【図3C】代表的な実施形態に係る、キャプチャバッファに格納せずに、破棄すべきＴＬＰとＤＬＬＰのフレーミングトークンフィールドを示す図である。
【図4】例示的な１６レーンのＧｅｎ６ ＰＣＩｅリンクのＦＬＩＴを示す図である。
【図5A】代表的な実施形態に係る、キャプチャバッファに格納せずに、破棄すべき例示的な構成読み取りＴＬＰの既知のフィールドを示す図である。
【図5B】代表的な実施形態に係る、キャプチャバッファに格納する前に、サイズを削減するべき構成読み取りＴＬＰの削減可能フィールドを示す図である。
【図6】代表的な実施形態に係る、単一回路で並列データ圧縮を可能とするよう構成されたワイドワードデータのシンボルの例を示す図である。
【図7】代表的な実施形態に係る、高速階層型パケットベースのプロトコルに準拠するデータリンクを介したデータの通信中、インターポーザ回路のキャプチャバッファに格納されるべきデータペイロードの並列データ圧縮を実行する方法を示す簡略流れ図である。
【図8】従来の圧縮解除技術で圧縮解除するためのワイドワードデータ入力のシンボルを示す図である。
【図9】代表的な実施形態に係る、圧縮解除用の入力のために並べ替えられたワイドワードデータのシンボルを示す図である。
【図10】代表的な実施形態に係る、圧縮解除用のワイドワードデータ入力のシンボルを並べ替えるその他の例を示す図である。
【図11】代表的な実施形態に係る、圧縮解除用のワイドワードデータ入力のシンボルを並べ替えるその他の例を示す図である。
【図12】代表的な実施形態に係る、圧縮解除のための逆の構造体（inverse structure）を作成する方法を示す流れ図である。
【図13A】代表的な実施形態に係る、圧縮解除用のワイドワードデータ入力のシンボルを並べ替えるためのワイドワードデータの並列圧縮を示す図である。
【図13B】代表的な実施形態に係る、圧縮解除用のワイドワードデータ入力のシンボルを並べ替えることを示す図である。
【図13C】代表的な実施形態に係る、ワイドワードデータの並べ替えられたシンボルの圧縮解除を示す図である。
【図14】代表的な実施形態に係る、圧縮解除用の入力のためにシフトされたワイドワードデータのシンボルを示す図である。
【図15A】代表的な実施形態に係る、圧縮解除用のワイドワードデータ入力のシンボルをシフトするためのワイドワードデータの並列圧縮を示す図である。
【図15B】代表的な実施形態に係る、圧縮解除用のワイドワードデータ入力のシンボルをシフトすることを示す図である。
【図15C】代表的な実施形態に係る、ワイドワードデータのシフト後のシンボルの圧縮解除を示す図である。
【図16】代表的な実施形態に係る、データリンクを介したワイドワードデータの通信中、圧縮解除後のワイドワードデータを提供する方法を示す簡略流れ図である。
【図17A】代表的な実施形態に係る、データリンクを介したワイドワードデータの通信中、圧縮解除後のワイドワードデータを提供する方法を示す簡略流れ図である。
【図17B】代表的な実施形態に係る、高速データリンクを介したデータの通信中、格納されたデータ量を削減するコンピュータシステムの一例を示す簡略ブロック図である。
【図18】代表的な実施形態に係る、高速データリンクを介したデータの通信中、格納されたデータ量を削減するコンピュータシステムの一例を示す簡略ブロック図である。
【図19】左側が非ランダムデータからの圧縮後の出力であるのに対して、右側がランダムデータからの圧縮後の出力の例を示す図である。
【図20】代表的な実施形態に係る、圧縮効率に優れた並列データ圧縮用に構成されたワイドワードデータのシンボルの例を示す図である。
【図21】代表的な実施形態に係る、ワイドワードデータの圧縮をリアルタイムに向上させる方法の流れ図である。
【発明を実施するための形態】
【0008】
以下の詳細な説明では、説明のためであり、限定はしないが、本教示による一実施形態を完全に理解してもらうために、具体的な詳細を開示する代表的な実施形態が記述される。代表的な実施形態の説明を不明瞭にするのを避けるために、既知のシステム、デバイス、材料、動作方法及び製造方法の説明は省略される場合がある。それにもかかわらず、当業者の理解の範囲内にあるシステム、デバイス、材料及び方法は、本教示の範囲内にあり、代表的な実施形態に従って使用される場合がある。本明細書において使用される用語は特定の実施形態を説明することのみを目的としており、限定することを意図するものでないことは理解されたい。定義される用語は、定義された用語の科学技術的な意味に加えて、本教示の技術分野において一般的に理解され、受け入れられるような意味を有する。
種々の要素又は構成要素を説明するために、本明細書において第１の、第２の、第３の等の用語が使用される場合があるが、これらの要素又は構成要素はこれらの用語によって限定されるべきではないことは理解されたい。これらの用語は、或る要素又は構成要素を別の要素又は構成要素から区別するためにのみ使用される。したがって、以下に論じられる第１の要素又は構成要素は、本開示の教示から逸脱することなく、第２の要素又は構成要素と呼ぶことができる。
種々の要素又は構成要素を説明するために、本明細書において第１の、第２の、第３の等の用語が使用される場合があるが、これらの要素又は構成要素はこれらの用語によって限定されるべきではないことは理解されたい。これらの用語は、或る要素又は構成要素を別の要素又は構成要素から区別するためにのみ使用される。したがって、以下に論じられる第１の要素又は構成要素は、本開示の教示から逸脱することなく、第２の要素又は構成要素と呼ぶことができる。
【0009】
本明細書において使用される用語は、特定の実施形態を説明することのみを目的とし、限定することを意図するものではない。本明細書及び添付の特許請求の範囲において使用されるときに、「一つの（a、an）」及び「その、前記（the）」という単数形の用語は、文脈上、他の意味として明確に指示される場合を除いて、単数形及び複数形の両方を含むことを意図している。さらに、「備える、含む（comprises、comprising）」という用語及び／又は類似の用語（つまり、「備える、含む」という用語又は類似の用語あるいはそれらの全て）は、本明細書において使用されるときに、言及される特徴、要素及び／又は構成要素の存在を指定するが、１つ以上の他の特徴、要素、構成要素及び／又はそのグループの存在又は追加を除外しない。本明細書において使用されるときに、「及び／又は（and/or）」という用語は、関連して列挙される項目のうちの１つ以上の項目のありとあらゆる組み合わせを含む。
【0010】
別段の言及がない限り、或る要素又は構成要素が、別の要素又は構成要素に「接続される（connected to）」又は「結合される（coupled to）」又は「隣接する（adjacent to）」と言われるとき、その要素又は構成要素を他の要素又は構成要素に直接接続又は結合することができるか、又は介在する要素又は構成要素が存在する場合があることは理解されたい。すなわち、これらの用語及び類似の用語は、２つの要素又は構成要素を接続するために、１つ以上の中間にある要素又は構成要素が利用される場合がある事例を含む。しかしながら、或る要素又は構成要素が、別の要素又は構成要素に「直接接続される」と言われるとき、これは、２つの要素又は構成要素が、任意の中間にある又は介在する要素又は構成要素を用いることなく、互いに接続される事例のみを含む。
【0011】
本開示は、それゆえ、その様々な態様、実施形態及び／又は具体的な特徴若しくはサブ構成要素のうちの１つ以上を通して、以下に具体的に言及されるような利点のうちの１つ以上を明らかにすることを意図している。説明のためであり、限定はしないが、本教示による一実施形態を完全に理解してもらうために、具体的な詳細を開示する例示的な実施形態が記述される。しかしながら、本明細書において開示される具体的な詳細から逸脱するが、本開示と矛盾しない他の実施形態も依然として、添付の特許請求の範囲内にある。さらに、例示的な実施形態の説明を不明瞭にしないように、既知の装置及び方法の説明は省略される場合がある。そのような方法及び装置は、本開示の範囲内にある。
【0012】
代表的な実施形態によると、テスト対象システムと、解析用のプロトコルアナライザとの間の高速階層型パケットベースのプロトコルに準拠するデータリンクを介したデータの通信中、機能を損なうことなく、かつ解析で利用できる情報を失うことなく、インターポーザ回路のキャプチャバッファに格納されるデータ量を削減する方法が提供されている。この方法は、データのデータ完全性チェックをリアルタイムに実行し、このデータ完全性チェックにより、データが正しいことが示された場合には、データのトランザクション層パケット（ＴＬＰ：transaction layer packet）及びデータリンク層パケット（ＤＬＬＰ：data link layer packet）からのデータ完全性チェックに対応するデータ完全性ビットを、キャプチャバッファに格納することから省くことと、ＡＣＫ／ＮＡＣＫパケットを使用して、データのＴＬＰが正常に配信されたことを確認するために、確認応答と否定応答（ＡＣＫ／ＮＡＣＫ）の照合をリアルタイムに実行し、このＡＣＫ／ＮＡＣＫパケットを、キャプチャバッファに格納することから省くことと、キャプチャバッファに格納されるべきデータのＴＬＰ及び／又はＤＬＬＰ（つまり、ＴＬＰ又はＤＬＬＰあるいはそれらの両方）からリアルタイムにフィールドを削除、及び／又は削減（つまり、削除又は削減あるいはそれらの両方）をすること、及び／又は、キャプチャバッファに格納されるべきデータのＴＬＰ及び／又はＤＬＬＰのペイロードを並列で圧縮することとを含む。
【0013】
代表的な実施形態によると、システムは、高速階層型パケットベースのプロトコルに準拠する高速データリンクを介して、テスト対象デバイス（ＤＵＴ）からホストコンピュータまでの高速階層型パケットベースのプロトコルでのデータを解析するアナライザソフトウェアを実行するように構成されたユーザインタフェース（ＵＩ）コンピュータと、ＤＵＴとホストコンピュータとの間で送信されるデータを監視するために高速データリンクに接続されたインターポーザ回路（interposer circuit）であって、このインターポーザ回路は、ＤＵＴとホストコンピュータとの間で送信されるデータを格納するためのキャプチャバッファを含み、ＵＩコンピュータがアナライザソフトウェアで解析するためにアクセスすることができるインターポーザ回路とを含む。上記インターポーザ回路は、データのデータ完全性チェックをリアルタイムに実行し、このデータ完全性チェックにより、データが正しいことが示された場合には、データのＴＬＰ及びＤＬＬＰからのデータ完全性チェックに対応するデータ完全性ビットを、キャプチャバッファに格納することから省くことと、ＡＣＫ／ＮＡＣＫパケットを使用して、データのＴＬＰが正常に配信されたことを確認するために、ＡＣＫ／ＮＡＣＫの照合をリアルタイムに実行し、このＡＣＫ／ＮＡＣＫパケットを、キャプチャバッファに格納することから省くことと、キャプチャバッファに格納されるべきデータのＴＬＰ及び／又はＤＬＬＰからリアルタイムにフィールドを削除、及び／又は削減すること、及び／又は、キャプチャバッファに格納されるべきデータのＴＬＰ及び／又はＤＬＬＰのペイロードを並列で圧縮することとを実行するようにプログラムされている。
【0014】
代表的な実施形態によると、システムは、高速階層型パケットベースのプロトコルに準拠する高速データリンクを介して、ＤＵＴからホストコンピュータまでのデータを高速階層型パケットベースのプロトコルで解析するアナライザソフトウェアを実行するように構成されたＵＩコンピュータと、ＤＵＴとホストコンピュータとの間で送信されるデータを監視するために高速データリンクに接続されたインターポーザ回路であって、このインターポーザ回路は、ＤＵＴとホストコンピュータとの間で送信されるデータを格納するためのキャプチャバッファを含み、ＵＩコンピュータがアナライザソフトウェアで解析するためにアクセスできるインターポーザ回路とを含む。上記インターポーザ回路は、ＴＬＰ及び／又はＤＬＬＰを並列圧縮し、圧縮されたＴＬＰ及び／又はＤＬＬＰをキャプチャバッファに格納するようプログラムされており、ＴＬＰ及び／又はＤＬＬＰはそれぞれ、ヘッダ及びペイロードを含む。ＴＬＰ及び／又はＤＬＬＰを圧縮することは、インターポーザ回路でのＴＬＰ及び／又はＤＬＬＰのシンボルを、複数のシリアル高速レーンで受信することと、シリアル高速レーンからのシンボルを、ＴＬＰ及び／又はＤＬＬＰのクロックサイクルの各クロックに到着するワイドワードへとデスキューすることと、ワイドワードを入力ストリームに配列することであって、各入力ストリームは、クロックサイクルの各クロックに到着する各ワイドワードの同位置からのシンボルを含むことと、上記シンボルを圧縮するためのハッシュテーブルを用いてシンボルを圧縮し、最終的に圧縮されたシンボルをキャプチャバッファに格納することとを含む。
【0015】
代表的な実施形態によると、並列圧縮されたワイドワードデータを圧縮解除（decompress）する方法が提供されている。この方法は、ワイドワードデータ内のワイドワードのメモリ構造のインスタンスを作成することであって、メモリ構造の上記インスタンスは、ワイドワードの圧縮辞書の反対（inverse）からの参照結果（instance）であることと、メモリ構造の上記インスタンスを使用して、ワイドワードデータの途切れのない（gap-free）圧縮後の出力ストリームから複数の圧縮後の符号を反復して取得することであって、上記複数の圧縮後の符号の各圧縮後の符号は、少なくとも１つの文字コード、及び逆方向のポインタ（reverse-pointer：逆ポインタ）を含み、上記複数の圧縮後の符号の少なくとも１つの圧縮後の符号は、複数の文字コードを有するマルチシンボルの文字列を含むことと、複数の圧縮後の符号である逆ポインタをそれぞれ繰り返し辿って、圧縮解除後の中間ストリームを形成することと、少なくとも１つの圧縮後の符号のマルチシンボル文字列の複数の文字コードの順序を逆転させて、圧縮解除後のストリームを形成することとを含む。
【0016】
図１は、代表的な実施形態に係る、高速データリンクを介したデータの通信中、機能を損なうことなく、かつ解析で利用できる情報を失うことなく、格納されたデータ量を削減するシステムの簡略ブロック図である。
【0017】
図１を参照すると、システム１００は、ユーザインタフェース（ＵＩ）コンピュータ１１０、及びインターポーザ回路１２０を含む。インターポーザ回路１２０は、テスト対象デバイス（ＤＵＴ）１４０とテスト対象システムのホストコンピュータ１５０との間を高速データリンク１３０で接続し、高速データリンク１３０を通じて通信されるデータを受信、処理するように構成される。データはインターポーザ回路１２０によりＵＩコンピュータ１１０に供給され、このＵＩコンピュータは、高速データプロトコルに従って、データを解析するためのプロトコルアナライザをホストする。
【0018】
したがって、インターポーザ回路１２０は、ＤＵＴ１４０、ホストコンピュータ１５０、並びに、ＤＵＴ１４０とホストコンピュータ１５０との間の高速データリンク１３０を含む、テスト対象システムをテストするための「中間者（man in the middle）」として機能する。つまり、インターポーザ回路１２０は、本明細書で記載の実施形態に従って、テスト中に高速データをキャプチャし、キャプチャしたデータの一部をキャプチャバッファ１２５に格納し、このデータは、キャプチャ後の解析用にＵＩコンピュータ１１０へと供給される。インターポーザ回路１２０は、例えば、ユニバーサルシリアルバス（ＵＳＢ）（例えば、ＵＳＢ３．０）又はイーサネット接続でＵＩコンピュータ１１０に接続され得る。
【0019】
ＵＩコンピュータ１１０は、例えば、パーソナルコンピュータ（ＰＣ）でもよいが、プロトコルアナライザを実行できる任意の処理ユニット（例えば、後述の処理ユニット８１０）を、本教示の範囲から逸脱することなく、組み込むこともできる。同様に、ホストコンピュータ１５０は、例えば、ＰＣでもよいが、高速データプロトコルを介してＤＵＴ１４０とインタフェース接続できる任意の処理ユニット（例えば、後述の処理ユニット８１０）を、本教示の範囲から逸脱することなく、組み込むこともできる。例えば、ＤＵＴ１４０は、ホストコンピュータ１５０に挿入可能であり、ホストコンピュータ１５０とインタフェース接続するアドインカード又はシステムボード等の高速周辺デバイスであり得る。高速周辺デバイスの例には、グラフィックカード、サウンドカード、ＳＳＤ、ワークロードアクセラレータが含まれる。一般的に、高速周辺デバイスとは、仕様にもよるが（例えば、ＰＣＩｅ Ｇｅｎ６プロトコルのレーンあたり４ＧＢ／秒を超える）、レーンあたり毎秒０．２５ＧＢ超のデータ速度で動作するものであり、それゆえ、信頼性の高いデータ転送のために、高速データリンク１３０を介した高速プロトコルにより、データを通信する必要がある。
【0020】
高速データプロトコルは、例えば、PCI Express（商標）Base Specification Revision 3.0（２０１０年１１月１０日）(「ＰＣＩｅ Ｇｅｎ３プロトコル」)、PCI Express（商標）Base Specification Revision 4.0、Version 1.0（２０１７年１０月５日）(「ＰＣＩｅ Ｇｅｎ４プロトコル」)、PCI Express（商標）Base Specification Revision 5.0、Version 1.0（２０１９年５月２８日）(「ＰＣＩｅ Ｇｅｎ５プロトコル」)、又は、PCI Express（商標）Base Specification Revision 6.0、Version 1.0（２０２２年１月１１日）(「ＰＣＩｅ Ｇｅｎ６プロトコル」)に記載されている、ＰＣＩｅプロトコルである場合があり、これらは全て引用することにより、その全体が本明細書の一部をなすものとする。この場合、ＵＩコンピュータ１１０によって実施されるプロトコルアナライザは、例えば、Keysight Technologies, Inc.社から入手可能なＵ４３０１Ｂ ＰＣＩｅプロトコルアナライザ、又はＵ４３０５Ｂ ＰＣＩｅ、及びＬＴＳＳＭ Ｅｘｅｒｃｉｓｅｒであり得る。
【0021】
図示の実施形態では、インターポーザ回路１２０は、上述のように、ＤＵＴ１４０とホストコンピュータ１５０との間で送信されるデータを一時的に格納するためのキャプチャバッファ１２５を含む。インターポーザ回路１２０は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ：field programmable gate array）、及び／又は特定用途向け集積回路（ＡＳＩＣ：application specific integrated circuit）（つまり、ＦＰＧＡ又はＡＳＩＣあるいはそれらの両方）を含み得るが、図２を参照して後述するインターポーザ回路１２０の機能を実行できる任意の処理ユニット（例えば、処理ユニット８１０）を、本教示の範囲を逸脱せずに、組み込むこともできる。一実施形態において、インターポーザ回路１２０は、例えば、Xilinx, Inc.社から入手可能な内部高帯域幅メモリ（ＨＢＭ：high bandwidth memory）ダイナミックランダムアクセスメモリ（ＤＲＡＭ：dynamic random access memory）を有するＦＰＧＡによって実装され、キャプチャバッファ１２５として使用される。
【0022】
図２は、代表的な実施形態に係る、高速階層型パケットベースのプロトコルに準拠するデータリンクを介したデータの通信中、機能を損なうことなく、かつ解析で利用できる情報を失うことなく、インターポーザ回路のキャプチャバッファに格納されるデータ量を削減する方法を示す簡略流れ図である。図２の様々なステップは、上述のように、インターポーザ回路１２０によって実行可能である。この方法は、ＵＩコンピュータ１１０及びインターポーザ回路１２０にプロトコルアナライザを提供する。これにより、従来のソリューションに付随する複雑な配線及び信号完全性（signal integrity：シグナルインテグリティ）の問題を解消し、総コストを削減するとともに、例えば、高帯域インタフェース（生データを削減した）を使用して、アップロード時間の高速化をサポートする。
【0023】
図２を参照すると、キャプチャバッファに格納されるデータの量は、４つの基本段階（basic step：基本ステップ）を踏まえており、それぞれについて、以下で詳しく説明する。ブロックＳ２１１において、キャプチャバッファに格納されるデータのトランザクション層パケット（ＴＬＰ）及びデータリンク層パケット（ＤＬＬＰ）から、リアルタイムに実行されるデータのデータ完全性（data integrity）チェックに対応するデータ完全性ビットを削除する。データ完全性チェックでデータが正しいことが示されると、データ完全性ビットは削除される。そうでない場合、つまり、データ完全性チェックでデータが正しくないことが示された場合、データ完全性ビットは、ＴＬＰ及びＤＬＬＰに残され、ＵＩコンピュータ１１０による解析のために、標準プロトコルに従って、キャプチャバッファ１２５に格納される。
【0024】
ブロックＳ２１２において、意図された送信先におけるデータのＴＬＰの到着成功（correct arrival）又は到着失敗（incorrect arrival）をそれぞれ示す確認応答（ＡＣＫ：acknowledge）パケット及び否定応答（ＮＡＣＫ：negative acknowledge）パケットを、キャプチャバッファ１２５に格納しない。その代わりとして、ＡＣＫ／ＮＡＣＫ照合をリアルタイムに実行し、ＡＣＫパケットとＮＡＣＫパケットを使用してＴＬＰの送達が成功したことを確認してから、ＡＣＫ／ＮＡＣＫパケットを破棄する。ＴＬＰのＡＣＫ／ＮＡＣＫの状態を、メタデータとしてキャプチャバッファ１２５に記録することもできる。
【0025】
ブロックＳ２１３において、データのＴＬＰ及び／又はＤＬＬＰから、或るフィールドをリアルタイムに削除するか、又は、リアルタイムにフィールドのサイズを削減する。これは、固定値又は空値を持つ既知のフィールドを削除することと、ＴＬＰとＤＬＬＰのパケットフローの始点と終点を示すために使用されるフレーミングトークンを削除することと、複数のアクティブデバイスではなく、単一のアクティブデバイスをテストするために、全体として不要なフィールドを削減することと、特定のユースケースをデバッグするための値を一切持たない非必須のフィールドを除去することとを含む。
【0026】
ブロックＳ２１４において、キャプチャバッファ１２５に格納されるＴＬＰ及び／又はＤＬＬＰの全部又は一部を並列圧縮する。例えば、パケットのデータペイロードは、キャプチャバッファ１２５に格納するために圧縮されてもよい。データペイロードの圧縮は、例えば、ワイドワード（wide word）の各シンボルが、処理ユニットのクロックサイクルの次クロックにおいて、次シンボルと同じ場所で配置されるように、ペイロードでデータを配列することを含む。次に、既にメモリに格納されている以前のシンボルへのポインタを提供するハッシュテーブルを使用して、配列されたデータを圧縮する。全パケット（つまり、ヘッダを含めて）の圧縮は、実質的に同じ方法で実行することができる。
【0027】
［データ完全性チェック］
ブロックＳ２１１を参照すると、リアルタイムに実行可能で、キャプチャバッファ１２５への格納から省かれるデータ完全性ビットを提供するデータ完全性チェックには、様々な種類がある。種々の実施形態において、データ完全性チェックの種類には、巡回冗長検査（ＣＲＣ：cyclic redundancy checker）チェック、フレームパリティチェック、フロー制御ユニット（ＦＬＩＴ：Flow Control Unit）チェックがあり、それぞれについては、以下で説明する。これらのチェックに対応するＴＬＰ及び／又はＤＬＬＰのデータ完全性ビットは、チェックから各データが正しいことが示された場合には、格納されない。そうでない場合、つまり、データ完全性ビットにより、各データが正しくないことを示す場合、これらはパケットに残され、キャプチャバッファ１２５に格納されてＵＩコンピュータ１１０で解析され得る。
ブロックＳ２１１を参照すると、リアルタイムに実行可能で、キャプチャバッファ１２５への格納から省かれるデータ完全性ビットを提供するデータ完全性チェックには、様々な種類がある。種々の実施形態において、データ完全性チェックの種類には、巡回冗長検査（ＣＲＣ：cyclic redundancy checker）チェック、フレームパリティチェック、フロー制御ユニット（ＦＬＩＴ：Flow Control Unit）チェックがあり、それぞれについては、以下で説明する。これらのチェックに対応するＴＬＰ及び／又はＤＬＬＰのデータ完全性ビットは、チェックから各データが正しいことが示された場合には、格納されない。そうでない場合、つまり、データ完全性ビットにより、各データが正しくないことを示す場合、これらはパケットに残され、キャプチャバッファ１２５に格納されてＵＩコンピュータ１１０で解析され得る。
【0028】
［ＣＲＣチェック］
ＣＲＣチェックについては、チェックサムを含むＣＲＣフィールドが、データのＴＬＰ及びＤＬＬＰに含まれる。一般的に、チェックサムは、送信デバイス（例えば、ＤＵＴ１０５）のＣＲＣフィールドで提供され、受信デバイス（例えば、ホストＰＣ）において取得され、そこで元データのチェックサムと比較される。チェックサムが一致した場合、データに誤りがないと判断される。チェックサムの一致に失敗した場合には、例えば、ＮＡＣＫによってパケットの再送信を要求する等、補正措置が取られ得る。本実施形態において、誤りがないことを示すＣＲＣのチェックサムは、それぞれのパケットから削除されるが、誤りを示すＣＲＣのチェックサムは削除されないので、キャプチャバッファ１２５に格納される。
ＣＲＣチェックについては、チェックサムを含むＣＲＣフィールドが、データのＴＬＰ及びＤＬＬＰに含まれる。一般的に、チェックサムは、送信デバイス（例えば、ＤＵＴ１０５）のＣＲＣフィールドで提供され、受信デバイス（例えば、ホストＰＣ）において取得され、そこで元データのチェックサムと比較される。チェックサムが一致した場合、データに誤りがないと判断される。チェックサムの一致に失敗した場合には、例えば、ＮＡＣＫによってパケットの再送信を要求する等、補正措置が取られ得る。本実施形態において、誤りがないことを示すＣＲＣのチェックサムは、それぞれのパケットから削除されるが、誤りを示すＣＲＣのチェックサムは削除されないので、キャプチャバッファ１２５に格納される。
【0029】
図３Ａは、代表的な実施形態に係る、キャプチャバッファに格納せずに、破棄すべき例示的なＴＬＰ及び例示的なＤＬＬＰのＣＲＣフィールドを示す。ＴＬＰ及びＤＬＬＰＳのＣＲＣフィールドは、例えば、ＰＣＩｅ Ｇｅｎ３プロトコルのセクション２．７に従って提供されているが、例えば、他のＰＣＩｅプロトコル（例えばＰＣＩｅ Ｇｅｎ４～Ｇｅｎ６プロトコル）を含む、他のプロトコルにおけるＣＲＣフィールドも、本教示の範囲から逸脱せずに組み込むことができる。
【0030】
図３Ａを参照すると、例示的なＴＬＰ３１０は、以下の２つのＣＲＣフィールドを含む。すなわち、４ビットを含むＦＣＲＣフィールド３１１、及び３２ビットを含むＬＣＲＣフィールド３１２である。例示的なＤＬＬＰ３２０は、１６ビットを含むＣＲＣフィールド３２１を含む。これまで考察したように、ＦＣＲＣフィールド３１１、ＬＣＲＣフィールド３１２、及びＣＲＣフィールド３２１をキャプチャバッファ１２５に格納するのではなく、最初に、インターポーザ回路１２０自体でＣＲＣのチェックサムをチェックする。誤りがないことを示すチェックサムは、キャプチャバッファ１２５に格納されず、それぞれのパケットから削除されるが、誤りを示すＣＲＣのチェックサムは、通常どおり、キャプチャバッファ１２５に格納される。例えば、誤りがないことを示すチェックサムは、それぞれのパケットから削除することができる。通常、ＣＲＣ誤りが発生しない場合、パケット単位でキャプチャバッファ１２５に保存される記憶領域は、既知で固定である（例えば、ＴＬＰ３１０では３６ビット、ＤＬＬＰ３２０では１６ビット）。
【0031】
キャプチャバッファ１２５からＵＩコンピュータ１１０へのデータ転送インフラストラクチャは、データの完全性を保持すると見なしてもよいので、ＣＲＣを省略しても機能上の損失はない。その後、誤りが発生しない場合、ＣＲＣは、ＰＣＩｅリンクの送信側が最初にＣＲＣを計算するために使用するアルゴリズムの逆の処理を使用して、ＵＩコンピュータ１１０上で静的に再構築できる。こうすることで、ユーザはチェックサムが省略されていることを認識しない。例えば、Ｇｅｎ３プロトコルのセクション２．７の図２～図３８は、ＴＬＰエンドツーエンドのデータ完全性保護用の３２ビットＥＣＲＣを計算するためのＥＣＲＣアルゴリズムを示している。ＵＩコンピュータ１１０は、このアルゴリズムの逆の処理を使用して、ＴＬＰ３１０から以前に削除された任意のＥＣＲＣを再構築することができる。当然のことながら、例えば、他のＰＣＩｅプロトコル（例えば、ＰＣＩｅ Ｇｅｎ４～Ｇｅｎ６プロトコル）から提供されるアルゴリズムを含む、ＣＲＣを計算する他の既知のアルゴリズムを、本教示の範囲から逸脱することなく組み込むことができる。ＣＲＣ誤りがある場合、プロトコルアナライザでＣＲＣを全て解析できるように、ＣＲＣ誤りを有するＴＬＰ３１０及び／又はＤＬＬＰ３２０は、変更せずにキャプチャバッファ１２５に格納される。
【0032】
［フレームパリティビット］
フレームパリティビットはＴＬＰに含まれ、インターポーザ回路１２０上でもチェックされる。一般的に、フレームパリティビットは、受信デバイスが対応するフレーミングトークンを正しく観測していることを確認するためにチェックされる。一実施形態において、誤りがないことを示すフレームパリティビットは、キャプチャバッファ１２５への格納が省かれ、誤りを示すフレームパリティビットは、キャプチャバッファ１２５に格納される。フレームパリティビットの値は、フレームパリティチェックに従って決定される。フレームパリティチェックの実行例は、フレーミングトークンに関するＰＣＩｅ Ｇｅｎ３プロトコルのセクション４．２．２．３．１で記載されている。当然のことながら、例えば、他のＰＣＩｅプロトコル（例えば、ＰＣＩｅ Ｇｅｎ４～Ｇｅｎ６プロトコル）から提供されるプロセスを含む、フレームパリティチェックを実行する他の既知のプロセスも、本教示の範囲から逸脱することなく、組み込むことができる。一般的に、フレーミングトークンは、関連するシンボルの数、ひいては、次のフレーミングトークンの場所を指定又は示唆する。例えば、フレーミングトークンは、パケットの始点を示し、様々な種類のパケットを迅速、且つ容易に識別できるようにする特別なシンボルとすることができる。
フレームパリティビットはＴＬＰに含まれ、インターポーザ回路１２０上でもチェックされる。一般的に、フレームパリティビットは、受信デバイスが対応するフレーミングトークンを正しく観測していることを確認するためにチェックされる。一実施形態において、誤りがないことを示すフレームパリティビットは、キャプチャバッファ１２５への格納が省かれ、誤りを示すフレームパリティビットは、キャプチャバッファ１２５に格納される。フレームパリティビットの値は、フレームパリティチェックに従って決定される。フレームパリティチェックの実行例は、フレーミングトークンに関するＰＣＩｅ Ｇｅｎ３プロトコルのセクション４．２．２．３．１で記載されている。当然のことながら、例えば、他のＰＣＩｅプロトコル（例えば、ＰＣＩｅ Ｇｅｎ４～Ｇｅｎ６プロトコル）から提供されるプロセスを含む、フレームパリティチェックを実行する他の既知のプロセスも、本教示の範囲から逸脱することなく、組み込むことができる。一般的に、フレーミングトークンは、関連するシンボルの数、ひいては、次のフレーミングトークンの場所を指定又は示唆する。例えば、フレーミングトークンは、パケットの始点を示し、様々な種類のパケットを迅速、且つ容易に識別できるようにする特別なシンボルとすることができる。
【0033】
再度、図３Ａの例を参照すると、ＴＬＰ３１０は、フレームパリティビットとして１ビットを含む、フレームパリティ（ＦＰ：frame parity）フィールド３１３も含む。このばあいもやはり、ＦＰフィールド３１３を格納するのではなく、まずインターポーザ回路１２０でフレームパリティビットをチェックする。フレームパリティビットにより、誤りがないと示された場合、フレームパリティビットを各ＴＬＰ３１０から削除してから、ＴＬＰ３１０をキャプチャバッファ１２５に格納する。フレームパーティビットが誤りを示す場合、フレームパリティビットはＴＬＰ３１０に残り、ＵＩコンピュータ１１０による解析が可能になるよう、通常どおり、キャプチャバッファ１２５に格納される。
【0034】
誤りがないことを示すフレームパリティビットを削除しても、ＴＬＰ３１０あたりたった１ビットという僅かな節約にしかもたらさない。しかし、通常、パケットデコーダは、フレームパリティビットをチェックして、例えば、ＴＬＰ３１０内の始点ＴＬＰ（ＳＴＰ）トークン（フレーミングトークン）が正しく、データストリーム内で適切に形成されたＴＬＰ３１０を観測していることを確認する必要がある。例えば、インターポーザ回路１２０は、対応するパケットの始点を記録し、これに応じて、タイムスタンプを挿入することができるよう、フレームパリティビット、及びＳＴＰトークンをチェックする。インターポーザ回路１２０は、フィルタリングを適用し、メタデータを挿入できるように、ヘッダを復号し、パケット境界を回復する必要がある。適用され得る圧縮技術とは関係なく、インターポーザ回路１２０上のパケット境界を計算する必要があるので、１ビットしか節約できなくても、フレームパリティビットを除去することには価値がある。
【0035】
［ＦＬＩＴチェック］
高速データプロトコルの中には、前方誤り訂正（ＦＥＣ：forward error correction）を使用するものがあり（例えば、ＰＣＩｅ Ｇｅｎ６）、そうした場合、パケットは、例えば、２５６バイト等の固定長でなければならない。固定長パケットは、フロー制御ユニット（ＦＬＩＴ）と呼ばれる。各ＦＬＩＴは、通常、可変長である１つ以上のＴＬＰを、所定バイト数含み得る。ＦＬＩＴより長いＴＬＰの場合、ＴＬＰは複数のＦＬＩＴに分割される。一般的に、ＦＬＩＴを受信すると、受信デバイス（例えば、ホストコンピュータ１５０）は、ＦＬＩＴ内の各ＦＥＣグループ内の修正可能な誤りを訂正するＦＥＣ復号化を実行する。ＦＥＣ復号化後、ＣＲＣチェックを実行する。ＣＲＣのチェックに失敗した場合、受信デバイスはＦＬＩＴが正常に受信されなかったことを示す。これは、否定応答を送信デバイス（例えば、ＤＵＴ１４０）に送り返すことによって実行できる。
高速データプロトコルの中には、前方誤り訂正（ＦＥＣ：forward error correction）を使用するものがあり（例えば、ＰＣＩｅ Ｇｅｎ６）、そうした場合、パケットは、例えば、２５６バイト等の固定長でなければならない。固定長パケットは、フロー制御ユニット（ＦＬＩＴ）と呼ばれる。各ＦＬＩＴは、通常、可変長である１つ以上のＴＬＰを、所定バイト数含み得る。ＦＬＩＴより長いＴＬＰの場合、ＴＬＰは複数のＦＬＩＴに分割される。一般的に、ＦＬＩＴを受信すると、受信デバイス（例えば、ホストコンピュータ１５０）は、ＦＬＩＴ内の各ＦＥＣグループ内の修正可能な誤りを訂正するＦＥＣ復号化を実行する。ＦＥＣ復号化後、ＣＲＣチェックを実行する。ＣＲＣのチェックに失敗した場合、受信デバイスはＦＬＩＴが正常に受信されなかったことを示す。これは、否定応答を送信デバイス（例えば、ＤＵＴ１４０）に送り返すことによって実行できる。
【0036】
図４は、１６レーンのＰＣＩｅリンクの例示的ＦＬＩＴ４００を示す。図示の例では、ＦＬＩＴ４００は２５６バイトを含み、これは、以下のように割り当てられる。すなわち、最初の２３６バイトは、１つ以上のＴＬＰ（バイト０～２３５）に割り当てられ、次の６バイトは、データリンク層ペイロード（ＤＬＰ）に割り当てられ（バイト２３６～２４１をＤＬＰ０～ＤＬＰ５として図示）、次の８バイトは、ＣＲＣ４１１（バイト２４２～２４９をＣＲＣ０～ＣＲＣ７として図示）に割り当てられ、さらに、最後の６バイトは、誤り訂正符号（ＥＣＣ：error correction code）として示される、ＦＥＣ４１２に割り当てられる（バイト２５０～２５５を、例えば、３つのグループＥＣＣ０［０：１］～ＥＣＣ２［０：１］で図示）。ＦＥＣを実行したら、ＦＬＩＴ４００について、ＣＲＣチェックを行う。ＣＲＣチェックに通れば、ＣＲＣ４１１のＣＲＣ情報、及びＦＥＣ４１２のＦＥＣ情報の双方が、インターポーザ回路１２０上で破棄される。ＣＲＣ４１１は８バイト、ＦＥＣ４１２（又は、ＥＣＣ）は２バイトの３ブロックで、それぞれ２５６バイトのＦＬＩＴの末尾に配置される。そこで、ＣＲＣ４１１とＦＥＣ４１２を破棄することで、ＦＬＩＴ４００の２５６バイトのうち１４バイトが、キャプチャバッファ１２５に格納されない。注目すべきは、ＦＬＩＴにカプセル化されているＴＬＰは独自のＣＲＣを持たないので、図３Ａを参照して上述したとおり、ＴＬＰのＣＲＣチェックの代わりに、ＦＬＩＴのＣＲＣチェックを実行できるということである。
【0037】
［ＡＣＫ／ＮＡＣＫ］
ブロックＳ２１２を参照すると、ＡＣＫパケットとＮＡＣＫパケットを使用して関連データのＴＬＰの送達の成功をリアルタイムに確認するために、ＡＣＫとＮＡＣＫとの照合をリアルタイムに実行する。次に、ＡＣＫパケットとＮＡＣＫパケットを破棄する、つまり、これらはキャプチャバッファ１２５に格納されない。概して、データリンク層は、確認応答と否定応答の仕組みを使用して、トランザクション層のパケットの配信を確実にするように支援する。一般的に、後続のＤＬＬＰで一致するシーケンス番号を使用して、送信先（例えば、ホストコンピュータ１５０）における送信元（例えば、ＤＵＴ１０５）からの各ＴＬＰの到着成功又は到着失敗は、送信先から送信元に戻って報告される。このシーケンス番号を使用して、ＴＬＰと、ＡＣＫパケット及びＮＡＣＫパケット（ＤＬＬＰに相当）の双方との間を追跡し、これにより、ＴＬＰとＤＬＬＰにわたって一致するシーケンス番号を結び付けて、配信が成功したことを示す。タイマーを使用して、ＴＬＰの受信とそれに対応する確認応答の時間を計ることができる。送信先が確認応答（ＡＣＫパケット）を受信する前にタイマーが終了した場合（タイムアウト）、新しいＴＬＰで元データを再送信する。ＴＬＰとＤＬＬＰのシーケンス番号は再利用（ラップアラウンド（wrap around））してもよいが、その場合、シーケンス番号が再利用される際にライブパケットが「インフライト（in-flight）」であってはならない。
ブロックＳ２１２を参照すると、ＡＣＫパケットとＮＡＣＫパケットを使用して関連データのＴＬＰの送達の成功をリアルタイムに確認するために、ＡＣＫとＮＡＣＫとの照合をリアルタイムに実行する。次に、ＡＣＫパケットとＮＡＣＫパケットを破棄する、つまり、これらはキャプチャバッファ１２５に格納されない。概して、データリンク層は、確認応答と否定応答の仕組みを使用して、トランザクション層のパケットの配信を確実にするように支援する。一般的に、後続のＤＬＬＰで一致するシーケンス番号を使用して、送信先（例えば、ホストコンピュータ１５０）における送信元（例えば、ＤＵＴ１０５）からの各ＴＬＰの到着成功又は到着失敗は、送信先から送信元に戻って報告される。このシーケンス番号を使用して、ＴＬＰと、ＡＣＫパケット及びＮＡＣＫパケット（ＤＬＬＰに相当）の双方との間を追跡し、これにより、ＴＬＰとＤＬＬＰにわたって一致するシーケンス番号を結び付けて、配信が成功したことを示す。タイマーを使用して、ＴＬＰの受信とそれに対応する確認応答の時間を計ることができる。送信先が確認応答（ＡＣＫパケット）を受信する前にタイマーが終了した場合（タイムアウト）、新しいＴＬＰで元データを再送信する。ＴＬＰとＤＬＬＰのシーケンス番号は再利用（ラップアラウンド（wrap around））してもよいが、その場合、シーケンス番号が再利用される際にライブパケットが「インフライト（in-flight）」であってはならない。
【0038】
上記のように、インターポーザ回路１２０は、ＡＣＫパケット及びＮＡＣＫパケットをキャプチャバッファ１２５に格納することから省く。当然のことながら、システムが、とりわけ確認応答自体の問題をデバッグしている場合、この機能を無効にすることができる。一実施形態において、ＡＣＫパケットとＮＡＣＫパケット自体が格納されないにもかかわらず、ＴＬＰは、そのＴＬＰの確認応答状態を示すメタデータを、これに付加してキャプチャバッファ１２５内に備えることができる。メタデータは、ＴＬＰがキャプチャバッファ１２５に格納される前に、インターポーザ回路１２０によってＴＬＰに論理的に付加される。したがって、ＡＣＫパケットとＮＡＣＫパケットを格納することなくインターポーザ回路１２０でＡＣＫとＮＡＣＫとを照合し、メタデータでＡＣＫとＮＡＣＫの結果を示すことにより、実質的に「ロスレス（lossless）」のデータ圧縮を実現することができる。
【0039】
この方法には、或る程度のコストがかかる。これまで考察したように、ＡＣＫパケットとＮＡＣＫパケットのタイムスタンプを追加してより豊富なデータを作成しない限り、ＡＣＫパケットとＮＡＣＫパケットの正確な到着時刻は失われる。メタデータにタイムスタンプを追加すると、パケットバッファに格納されるべきデータ量が増加するが、その増加分は、本来、ＡＣＫとＮＡＣＫのパケット全体について格納されるはずのデータ量よりも少なくなる。ＴＬＰ３１０からのシーケンス番号と、（適宜）ＡＣＫパケット又はＮＡＣＫパケットに関連するタイムスタンプを与えると、根本的なプロトコルエラー（protocol error）がなければ、ＤＬＬＰ３２０は完全に再構築され得る。当然のことであるが、根本的なプロトコルエラーがあれば、ＤＬＬＰ３２０は全て格納されるはずである。さらに、ＤＬＬＰ３２０のタイムスタンプは、対応するＴＬＰ３１０の元のタイムスタンプとの差分として保持され得る。これにより、格納に必要なビット数が減少する一方、パケットストリームにおけるＤＬＬＰ３２０の場所も、依然として復元され得る。
【0040】
図３Ｂは、代表的な実施形態に係る、キャプチャバッファ１２５に格納せずに、ＡＣＫ／ＮＡＣＫパケットを破棄可能にする、上述の図３Ａに示したのと同じＴＬＰ３１０及び同じＤＬＬＰ３２０におけるシーケンス番号フィールドを示す。図３Ｂを参照すると、ＴＬＰ３１０はシーケンス番号フィールド３１４を含み、ＤＬＬＰ３２０はＤＬＬＰシーケンス番号フィールド３２４を含む。シーケンス番号が一致することで、配信に成功したことが示され、ＴＬＰパケットのＡＣＫとなるはずである。例えば、ＴＬＰ３１０内のシーケンス番号１つとＤＬＬＰ３２０内のシーケンス番号１つという、シーケンス番号のペアが一致すれば、ＴＬＰ３１０が確認応答された（ＡＣＫｅｄ）ことになる。この場合、シーケンス番号フィールド３１４及び３２４のシーケンス番号は格納されないが、ＴＬＰ３１０、及び／又は、ＡＣＫ、及び／又はＮＡＣＫが到着したかどうかを示す３ビットシンボルは格納される。シーケンス番号が各方向（例えば、上下）に順番に並んでいるので、各３ビットシンボルがどのシーケンス番号を参照しているかは、後で判断できる。図示の例では、ＡＣＫパケットとＮＡＣＫパケットのサイズ、ひいては、ＴＬＰごとに節約できるスペースは、既知で固定されている。例えば、ＰＣＩｅ Ｇｅｎ３プロトコルのセクション３．４．１において、非ＦＬＩＴモードでは、ＴＬＰ３１０ごとにＡＣＫ又はＮＡＣＫのパケットがそれぞれ６４ビットであるので、これまで考察したように、ＡＣＫ／ＮＡＣＫの状態を示すメタデータを３ビット追加して、ＴＬＰ３１０と関連付けてキャプチャバッファ１２５に格納すれば、６１ビット分の節約が可能となる。例えば、ＰＣＩｅ Ｇｅｎ ６プロトコルのセクション３．５．１では、ＡＣＫとＮＡＣＫのパケットの処理についても言及している。さらに、ＰＣＩｅ Ｇｅｎ６プロトコルでＦＬＩＴモードを有効にすることで、ＦＬＩＴあたり６バイトの節約を実現した。例えば、他のＰＣＩｅプロトコル（例えば、ＰＣＩｅ Ｇｅｎ４～Ｇｅｎ５プロトコル）を含む、他の既知のプロトコルにおけるＡＣＫとＮＡＣＫのパケットを、本教示の範囲から逸脱することなく、組み込むことができる。
【0041】
［フィールドの削除／削減］
再度、図２を参照すると、ブロックＳ２１３において、ＴＬＰ及び／又はＤＬＬＰの特定のフィールドを削除するか、又は、フィールド内のデータをリアルタイムに削減する。この圧縮技術に含まれ得るフィールドには、いくつかの種類がある。例えば、既知の固定値又は空値を持つ既知のフィールド、パケットフローの始点と終点を示すフレーミングトークンフィールド、及び、所与のユースケースについて値を持たない非必須フィールドは、除去することができる。また、テスト条件で必要以上に広いフィールドは、削減されることもある。
再度、図２を参照すると、ブロックＳ２１３において、ＴＬＰ及び／又はＤＬＬＰの特定のフィールドを削除するか、又は、フィールド内のデータをリアルタイムに削減する。この圧縮技術に含まれ得るフィールドには、いくつかの種類がある。例えば、既知の固定値又は空値を持つ既知のフィールド、パケットフローの始点と終点を示すフレーミングトークンフィールド、及び、所与のユースケースについて値を持たない非必須フィールドは、除去することができる。また、テスト条件で必要以上に広いフィールドは、削減されることもある。
【0042】
［既知のフィールドの除去］
ＴＬＰには、固定値及び空の値（empty value）を含む、値が既知のフィールドを含むものがある。通常、プロトコルは、とりわけ、例えば、ペイロードデータの前にある共通のヘッダフィールドに関して、本質的に規則的になるように設計されている。これは、プロトコルを復号化するために使用される状態機械を構築する際に必要な作業量を軽減するので、階層型プロトコル設計でよく検討される部分でもある。そのため、多くのパケットタイプには、一部のパケットで使用されるフィールドがあるが、別のタイプのパケットの場合では、固定の既知値、更には、空の値もある。例えば、様々なパケットにおいて、０でなければならない予備フィールド、未使用により０でなければならないトラフィッククラスインジケータ、（ペイロードには、常に単一のデータワード（例えば、４バイト）があることにより）１でなければならない長さフィールドがある。
ＴＬＰには、固定値及び空の値（empty value）を含む、値が既知のフィールドを含むものがある。通常、プロトコルは、とりわけ、例えば、ペイロードデータの前にある共通のヘッダフィールドに関して、本質的に規則的になるように設計されている。これは、プロトコルを復号化するために使用される状態機械を構築する際に必要な作業量を軽減するので、階層型プロトコル設計でよく検討される部分でもある。そのため、多くのパケットタイプには、一部のパケットで使用されるフィールドがあるが、別のタイプのパケットの場合では、固定の既知値、更には、空の値もある。例えば、様々なパケットにおいて、０でなければならない予備フィールド、未使用により０でなければならないトラフィッククラスインジケータ、（ペイロードには、常に単一のデータワード（例えば、４バイト）があることにより）１でなければならない長さフィールドがある。
【0043】
また、一部のパケットには、既知のフィルタ設定がある（例えば、ＰＣＩｅ Ｇｅｎ３プロトコルソフトウェアではトリガとして知られている）。例えば、バス上のいくつかのトーカ（talker）を検索する、又は、単一のエンドポイントデバイスをテストする場合には、デバイスアドレスフィールドは事前に分かっており、フィルタが正しく機能しているものとして、一致するパケットのみが格納される。例えば、２つのトーカを含むフィルタでは、既知の２つのトーカだけを識別すればよいので、大きなアドレス空間を必要とせず、アドレスフィールドのデータを削減することができる。場合によっては、１６ビットのアドレスを、たった１ビット、２ビット、又は３ビットまで減らすことができる場合もある。
【0044】
既知の（固定又は空の）値を持つ既知のフィールドは、パケットタイプごとに異なる場合があるが、これらのフィールドを定義し、パケット格納時にそれらを省略することは比較的簡単である。フィールド値が既知であるので、インターポーザ回路１２０で既知の値が正しいかどうかをチェックしてから、キャプチャバッファ１２５から省く限り、ユーザインタフェースによって回復させることが可能である。当然のことであるが、期待される既知の値と異なる場合は、既知のフィールドを含め、パケット全体を格納して、後でデバッグする必要がある。
【0045】
図５Ａは、代表的な実施形態に係る、キャプチャバッファに格納せずに、破棄すべき例示的な構成読み取りＴＬＰ（Config Read TLP）の既知のフィールドを示す。構成読み取りＴＬＰの既知のフィールドは、属性フィールド（Ａｔｔｒ）に関するセクション２．２．６．３等のＰＣＩｅ Ｇｅｎ３プロトコルに従って提供され、例えば、このセクションでは、トランザクションのデフォルト処理の変更を可能にするための更なる情報を提供している。図５Ａを参照すると、構成読み取りＴＬＰ３３０には、以下の規則が適用される。すなわち、ＴＣフィールド３３１を０００ｂとし、ＴＨフィールド３３３は、構成要求には適用されず、ビットは予備（恐らく、０）であり、Ａｔｔｒ［２］フィールドは予備（恐らく、０）であり、Ａ［１：０］フィールド３３４を００ｂとし、ＡＴフィールド３３５を００ｂとし、長さフィールド３３６を００ ００００ ０００１ｂ（１つ）とし、さらに、最後のＤＷ ＢＥフィールド３３７を００００ｂとする。フィールド３３２、３３８、及び３３９は予備としてマークされ、０とする。ＰＣＩｅ Ｇｅｎ３プロトコルの他の既知のフィールド、並びに、例えば、他のＰＣＩｅプロトコル（例えば、ＰＣＩｅ Ｇｅｎ４～Ｇｅｎ６プロトコル）を含む、他のプロトコルの既知のフィールドも、本教示の範囲から逸脱せずに組み込むことができる。
【0046】
［フレーミングトークンの除去］
種々のトークンは、ＴＬＰ及びＤＬＬＰのパケットフローの始点と終点を示すために使用されるシンボルである。フレーミングトークンは、その値を確認した後、より短いシンボルに置き換えることができる。一実施形態において、値ごとにフレーミングトークンをチェックし、値に誤りが見つかった場合は、例外又は特例を発生させて、その値を、より小さいが一意なビット系列に置き換える。この場合も、データがキャプチャバッファ１２５から抽出され、ＵＩコンピュータ１１０に送信される際には、その完全性と間隔は、パケットを搬送する輸送システムによって保存されるものとする。
種々のトークンは、ＴＬＰ及びＤＬＬＰのパケットフローの始点と終点を示すために使用されるシンボルである。フレーミングトークンは、その値を確認した後、より短いシンボルに置き換えることができる。一実施形態において、値ごとにフレーミングトークンをチェックし、値に誤りが見つかった場合は、例外又は特例を発生させて、その値を、より小さいが一意なビット系列に置き換える。この場合も、データがキャプチャバッファ１２５から抽出され、ＵＩコンピュータ１１０に送信される際には、その完全性と間隔は、パケットを搬送する輸送システムによって保存されるものとする。
【0047】
図３Ｃは、代表的な実施形態に係る、キャプチャバッファに格納せずに、破棄すべきＴＬＰとＤＬＬＰのフレーミングトークンフィールドを示す。図３Ｃは、これまで考察した図３Ａに示されるのと同じ例示的なＴＬＰ３１０とＤＬＬＰ３２０を示す。図３Ｃを参照すると、ＴＬＰ３１０はＳＴＰフィールド３１５を含み、ＤＬＬＰ３２０は、ＳＤＰトークン番号フィールド３２５を含む。ＳＴＰフィールド３１５は、ＴＬＰ３１０の始点パケットフロートークンを含み（終点パケットフロートークンを含むフィールドは、図示せず）、ＳＤＰトークン番号フィールド３２５は、ＤＬＬＰ３２０のフレーミングトークンを含む。ＳＴＰフィールド３１５、及びＳＤＰトークン番号フィールド３２５のそれぞれは、例えば、削除されてもよいし、より短いシンボルに置き換えられてもよい。
【0048】
［フィールドの削減］
これまで考察したように、プロトコル内の一部のパケットフィールドは、ＤＵＴ１４０で必要と想定されるよりもより広い（より多くのビットを使用）。例えば、或るシステムで最小限の構成（単一のデバイス）をテストすることがよくある。それゆえ、サウンドカード、グラフィックスカード、複数のアクセラレータ等の複数のＰＣＩｅデバイス（カード）が使用されているライブシステムと比較して、ホストコンピュータ１５０と通信するアクティブなＰＣＩｅデバイスは、１つとすることができる。したがって、１つ又は２つのＰＣＩｅデバイス（例えば、ＤＵＴ１４０）のみがアクティブである場合、複数のＰＣＩｅデバイスを収容できるアドレス空間は必要ない。
これまで考察したように、プロトコル内の一部のパケットフィールドは、ＤＵＴ１４０で必要と想定されるよりもより広い（より多くのビットを使用）。例えば、或るシステムで最小限の構成（単一のデバイス）をテストすることがよくある。それゆえ、サウンドカード、グラフィックスカード、複数のアクセラレータ等の複数のＰＣＩｅデバイス（カード）が使用されているライブシステムと比較して、ホストコンピュータ１５０と通信するアクティブなＰＣＩｅデバイスは、１つとすることができる。したがって、１つ又は２つのＰＣＩｅデバイス（例えば、ＤＵＴ１４０）のみがアクティブである場合、複数のＰＣＩｅデバイスを収容できるアドレス空間は必要ない。
【0049】
一実施形態において、テスト対象システム（ＤＵＴ１４０を含む）において、アクティブＤＵＴがライブシステムよりも少ない場合、必要なアクティブＤＵＴの数に応じて、アドレスフィールドのサイズを削減し、その代わりに、ルックアップテーブルを展開してもよい。例えば、アクティブＤＵＴが２つ又は３つしかない場合、アドレスフィールドを、１６ビットからそれぞれ１ビット、２ビット、又は３ビットだけに減らすことができる。インターポーザ回路１２０の起動時にルックアップテーブルのサイズをパラメータ化すれば、ユーザは、ＤＵＴの数と比較して利用可能なメモリを最大限活用できるよう、ＵＩコンピュータ１１０でのメモリ圧縮を構成可能である。
【0050】
また、要求側（Requester）（送信者）及びコンプリータ側（Completer）（受信者）のアドレスは、ミラーリングされた値のペアである。２人の当事者のみが会話に参加している場合（例えば、１つのＤＵＴ１４０と、１つのホストコンピュータ１５０）、一意のペアは１つだけである。さらに、インターポーザ回路１２０は、「中間者」としてダウンリンクチャネルとアップリンクチャネルの双方へと物理的に接続されているという理由により、方向性を認識しているので、アドレス指定方式はまったく要求されない場合がある。この場合、アドレスフィールド全体を除去することができる。
【0051】
図５Ｂは、代表的な実施形態に係る、キャプチャバッファに格納する前に、サイズを削減するべき構成読み取りＴＬＰの削減可能フィールドを示す図である。図５Ｂは、これまで考察した図５Ａに示されるのと同じ例示的な構成読み取りＴＬＰ３３０を示す。この場合もやはり、例えば、ＰＣＩｅ Ｇｅｎ３プロトコルに従って、構成読み取りＴＬＰの削減可能フィールドが提供される。例えば、他のＰＣＩｅプロトコル（例えば、ＰＣＩｅ Ｇｅｎ４～Ｇｅｎ６プロトコル）を含む、他のプロトコルの他の既知のフィールドの削減可能フィールドも、本教示の範囲から逸脱せずに組み込むことができる。
【0052】
図５Ｂを参照すると、削減可能フィールド３４０には、ＴＬＰ３３０の送信者に関連するアドレスデータであるバス番号（要求側）、Ｄｅｖ＃（Ｒｅｑ）（すなわち、デバイス番号（要求側））、及びＦｕｎｃ＃（Ｒ）（すなわち、機能番号（要求側））、並びに、ＴＬＰ３３０の受信者に関連するアドレスデータであるバス番号（コンプリータ側）、Ｄｅｖ＃（Ｃｏｍｐｌ）（すなわち、デバイス番号（コンプリータ側））、及びＦｕｎｃｔ＃（Ｃ）（すなわち、機能番号（コンプリータ側））が含まれている。一実施形態において、２ビット～３ビット以外全てを、削減可能フィールド３４０から除去することができる。ビット数はシステム固有であるが、上記フィールドのアクティブな組み合わせと同数のビットのみが必要である。一方、元パケットの要求側とコンプリータ側の実際のＰＣＩｅアドレスの最小長のエイリアスを格納するルックアップテーブルが作成される。インターポーザ回路１２０の起動時にルックアップテーブルのサイズをパラメータ化すれば、ユーザは、アドレス指定可能なエンティティ（例えば、ＤＵＴ）の数と比較して利用可能なメモリを最大限活用できるよう、ＵＩコンピュータ１１０でのメモリ圧縮を構成することができる。
【0053】
［必須でないフィールド／パケットの除去］
所与のユースケースで値を持たないフィールド全体は、ＴＬＰとＤＬＬＰから削除することができる。値を持たないパケット全体も削除され得る。さらに、ペイロードが大きい／長いＴＬＰやＤＬＬＰも、切り捨てることができる。つまり、特定のユースケースをデバッグする際に重要でない各フィールドを持つ多数のパケットタイプ（packet type）がある。このようなパケット、及び／又はパケット内の各フィールド（つまり、パケット、又はパケット内の各フィールド、あるいはそれらの両方）は、ユーザの構成に応じて省くことができる。例えば、ＵＩ設定に基づき、キャプチャストリームから除去することができるパケット、及び／又はパケットごとのフィールド（パケット、又はパケットごとのフィールド、あるいはそれらの両方）のリストが提供され得る。これでは、削除されたパケット及び／又はフィールド（つまり、パケット又はフィールドあるいはそれらの両方）が、ＵＩコンピュータ１１０で再構成できないので、「ロッシー（lossy）」な圧縮となるはずである。また、このストレージ方式では、実行時にどのフィールドが存在するかを指定する必要もある。それゆえ、固定ストレージ方式ではなく、フィールドを削除した際に記憶容量を最大化する融通の利くストレージ方式が、実装されている。注目すべきは、フィールド全体が削除されたり、又は、パケットが切り捨てられたりすると、ＵＩコンピュータ１１０において、これまで考察したデータ完全性チェック値がロスレスで回復されない場合があることである。
所与のユースケースで値を持たないフィールド全体は、ＴＬＰとＤＬＬＰから削除することができる。値を持たないパケット全体も削除され得る。さらに、ペイロードが大きい／長いＴＬＰやＤＬＬＰも、切り捨てることができる。つまり、特定のユースケースをデバッグする際に重要でない各フィールドを持つ多数のパケットタイプ（packet type）がある。このようなパケット、及び／又はパケット内の各フィールド（つまり、パケット、又はパケット内の各フィールド、あるいはそれらの両方）は、ユーザの構成に応じて省くことができる。例えば、ＵＩ設定に基づき、キャプチャストリームから除去することができるパケット、及び／又はパケットごとのフィールド（パケット、又はパケットごとのフィールド、あるいはそれらの両方）のリストが提供され得る。これでは、削除されたパケット及び／又はフィールド（つまり、パケット又はフィールドあるいはそれらの両方）が、ＵＩコンピュータ１１０で再構成できないので、「ロッシー（lossy）」な圧縮となるはずである。また、このストレージ方式では、実行時にどのフィールドが存在するかを指定する必要もある。それゆえ、固定ストレージ方式ではなく、フィールドを削除した際に記憶容量を最大化する融通の利くストレージ方式が、実装されている。注目すべきは、フィールド全体が削除されたり、又は、パケットが切り捨てられたりすると、ＵＩコンピュータ１１０において、これまで考察したデータ完全性チェック値がロスレスで回復されない場合があることである。
【0054】
［並列圧縮］
ブロックＳ２１４を参照すると、キャプチャバッファに格納されるワイドワードデータのＴＬＰ及び／又はＤＬＬＰのペイロードはリアルタイムに圧縮される。圧縮は、従来の圧縮技術のように直列に行われるのではなく、むしろ、並列に行われる。一実施形態において、ヘッダも、ＴＬＰ及び／又はＤＬＬＰのペイロードと一緒にリアルタイムに圧縮することができる。以下の考察は、説明を容易にするために、データペイロード圧縮に焦点を当てているが、本教示の範囲から逸脱することなく、全パケット圧縮に適用することができる。
ブロックＳ２１４を参照すると、キャプチャバッファに格納されるワイドワードデータのＴＬＰ及び／又はＤＬＬＰのペイロードはリアルタイムに圧縮される。圧縮は、従来の圧縮技術のように直列に行われるのではなく、むしろ、並列に行われる。一実施形態において、ヘッダも、ＴＬＰ及び／又はＤＬＬＰのペイロードと一緒にリアルタイムに圧縮することができる。以下の考察は、説明を容易にするために、データペイロード圧縮に焦点を当てているが、本教示の範囲から逸脱することなく、全パケット圧縮に適用することができる。
【0055】
背景として、全般的に理解されることは、例えば、ＬＺＷ、ＬＺ７７、及びＬＺ７８に基づくような既知の圧縮アルゴリズムにおける圧縮出力、及び圧縮で必要とされる辞書は、入力データの１シンボルを一度に読み取ることによって作成され、かかる辞書の内容は、ストリーム内で以前に出現したパターンの場所を知っているかどうかで異なるということである。それゆえ、このような依存性がある圧縮アルゴリズムは並列処理が困難である。
【0056】
一般的に、並列処理は、例えば複数のシンボルを同時に処理する単一の処理ユニットで圧縮アルゴリズムを１ステップで並列化する等により、効率を向上させる。このような戦略は、単一命令複数データ（ＳＩＭＤ：single instruction multiple data de-skewed lane）処理、又は「ワイドワード」処理と呼ばれることがあり、ワイドワードは、複数のシンボル（例えば、４、８、１６、又はそれ以上のシンボル）、並びに単一の回路からなるものとすることができ、各シンボルは、通常、１動作（operation）あたり複数バイトを含む全ての動作で、データの１バイトに等い。ＰＣＩｅに適用すると、各単一ＰＣＩｅレーンのデータは、クロックサイクルごとに複数のバイトを既に搬送している。しかし、ＰＣＩｅアナライザは、複数の単一のＰＣＩｅレーンではなく、結合されたデスキューレーンのデータを扱うので、最終的に、デスキューデータバスは、１２８バイト、２５６バイト、又はそれ以上の幅となり得る。この場合、従来のデータ圧縮では、各シンボルが８ビット幅である必要がないため、シンボルは複数バイトのデータからなると考えることができる。しかし、一般的に圧縮アルゴリズムは、入力シンボル（バイト）のビット幅が大きい場合（例えば、８ビットよりはるかに大きい、例えば、２＾１６（２１６）（２バイト）は、２＾８（２８）よりはるかに大きい）、圧縮効率が悪くなり、さらに、「ｎ」をビット幅として、辞書のサイズが２ｎ増えるため、圧縮アルゴリズムは全体として、はるかに多くのメモリを消費することとなる。
【0057】
例えば、各クロック入力のデータレートに辞書がリアルタイムに追従できるよう、ワイドワード設計では、辞書のワードサイズの変更（例えば、２５６バイトの変更）が必要となる。単一ポート付きメモリに１つの変更を書き込むのにハードウェアで１クロックサイクルが必要であり、ワードサイズ（例えば、２５６バイト）の変更が行われていることを踏まえると、データと同じペースを保ち、データ損失を避けるために必要な数のメモリポートを得るには、この例では、２５６のメモリブロックが必要である。さらに、従来のＦＰＧＡには、ブロックランダムアクセスメモリ（ＢＲＡＭ：block random access memory）が搭載されているが、各ＢＲＡＭのサイズは３６Ｋビットと小さく、２５６の辞書ごとに複数のＢＲＡＭが必要となる。現行の最大規模のＦＰＧＡでも、これだけの数の辞書を効率的に実装するのに十分なＢＲＡＭをサポートしていない。ラインレートでデータを処理するワイドワード（例えばＳＩＭＤ）実施態様では、辞書への追加ごとに１回のメモリ書き込み動作（operation）と、１回のメモリ読み出し動作が必要となり、各動作について、１クロックサイクルかかり、さらに、１つのメモリポート（つまり、合計２つのメモリポート）を使用するので、ワイドワードを読み出す際に算出される新しいマルチシンボルの圧縮後の符号ごとに、１回の変更が必要となる。
【0058】
ＢＲＡＭはツインポートであるので、各クロックサイクルの１クロックにつき、書き込み動作と読み出し動作をそれぞれ１度しか実行できない。それゆえ、圧縮アルゴリズムには、複数のＢＲＡＭ（より一般的には、複数のポート）が必要となる。複数のＢＲＡＭを搭載することで、いわゆる「メモリ待ち時間（memory latency）」が軽減されるので、各更新は単一クロックサイクルで別個のメモリポート経由で書き込むことができる。ただし、ＢＲＡＭ等のメモリの数がワイドワードの幅と同じ場合、メモリが少なくとも２５６個あり、各メモリには、新しい辞書エントリの１ワードサイズのみが含まれることになる。そのため、複数のメモリは、本質的に非コヒーレント（non-coherent：非同期式の）である。つまり、全メモリブロックはそれぞれ、複数のワードサイズのメモリにわたり分散された圧縮辞書で断片化される。より多くのクロックサイクルが利用できれば、メモリのコヒーレント（coherent）を保つことは可能かもしれないが、圧縮アルゴリズムの実時間制約を踏まえると、メモリの同期を別のアルゴリズムで行うことは困難である。
【0059】
こうした問題に対処するために、様々な実施形態では、シンボルワイドワード（ＳＩＭＤ）ごとの実装におけるメモリの断片化が問題とならない圧縮アルゴリズムを提供する。図６は、代表的な実施形態に係る、単一回路で並列データ圧縮を可能とするよう構成されたワイドワードデータのシンボルの例を示す。
【0060】
図６を参照すると、シリアルストリーム６２０は、それぞれのワイドワードにシンボル（バイト）ｂ０～ｂ１０を含む。理解される点として、シリアルストリーム６２０は、高速プロトコル（例えば、ＰＣＩｅ Ｇｅｎ６プロトコルでは最大１６レーン）に従って、複数のレーンを介して受信される。説明を簡略化するために、各ワイドワードは、より一般的な実装となる２５６シンボルとは異なり、図示の例では４つのシンボルからなる。例えば、第１のワイドワードには、バイトｂ０、ｂ１、ｂ２、及びｂ３が含まれ、第２のワイドワードには、バイトｂ４、ｂ５、ｂ６、及びｂ７が含まれる。各シンボルは、例えば、８ビットを持つバイトと仮定する。従来の圧縮アルゴリズムでは、シリアルストリームを「現状のままで（as is）」圧縮する、つまり、各シンボルの後に、シリアルストリームの次のシンボルが続くように圧縮する。
【0061】
しかし、図示の実施形態では、従来の圧縮アルゴリズムのように、シリアルストリームの次のシンボルを使用するのではなく、データストリームは、クロックサイクルの次クロックにおけるデータストリームの次の４シンボルのワイドワードの同じ場所から各シンボルの後に次のシンボルが続く入力ストリームを提供するよう、配列される。つまり、ワイドワードごとにシンボルが４つある場合、参照番号６３０によって示されるシンボルのシリアルストリーム内の異なる濃淡で示されるように、圧縮に関して、シンボルが４つおきにグループ化される。したがって、この例では、バイトｂ０、ｂ４、ｂ８、．．．は、第１の辞書（Ｄ１）について、第１の入力ストリーム６３１を形成し、バイトｂ１、ｂ５、ｂ９、．．．は、第２の辞書（Ｄ２）について、第２の入力ストリーム６３２を形成し、バイトｂ２、ｂ６、ｂ１０、．．．は、第３の辞書（Ｄ３）について、第３の入力ストリーム６３３を形成し、そして、バイトｂ３、ｂ７、ｂ１１、．．．は、第４の辞書（Ｄ４）について、第４の入力ストリーム６３４を形成し、各ワイドワードは４つのシンボルを持つ。そして、第１～第４の辞書内の同じ場所のバイトのセット（すなわち、図６に示す配列の各列）に対して、クロックサイクルごとに圧縮が行われる。より一般的には、第１番目～第ｎ番目の辞書に対して圧縮が行われ、ここで、ｎはワイドワードあたりのシンボル数である。これにより、効果的に並列圧縮を行うことができる。
【0062】
言い換えれば、データストリームが「ａｂｃｄ ｅｆｇｈ ｉｊｋｌ ｍｎｏｐ」として表されるビットとして提供されると仮定する。上記入力の場合、従来のＬＺＷ圧縮アルゴリズムでは、例えば、或るワイドワードについては、連続した一意のペア「ａｂ」、「ｂｃ」、及び「ｃｄ」、次のワイドワードについては、「ｅｆ」、「ｆｇ」、及び「ｇｈ」といった具合で、新しい辞書エントリが作成される。従来のＬＺＷ圧縮アルゴリズムでは、入力と同じ順番で、「ａ」「ｂ」「ｃ」「ｄ」．．．といった具合で出力される。プロセスのどの段階であっても、２つ以上のシンボルを組み合わせて単一の新しい出力シンボル（符号）にすることで、マルチシンボルの文字列を圧縮できる場合、圧縮アルゴリズムがそれを実行することになる。これが発生すると、新しい圧縮後の符号が出力される前に、相当のギャップが出力に生じる。
【0063】
しかし、種々の実施形態によると、この場合も、説明の便宜上、ワイドワードのサイズを４シンボルと仮定すると、以下で考察するように、ｎ＞＝０の場合、圧縮ステップごとに、（４ｎ＋ｉ）番目のシンボル（ｉ＝０、１、２、又は３）が考慮される。この場合、新しい辞書エントリは、連続クロック、及び、それぞれの入力が異なる辞書をアドレス指定する４つの配列済み入力（１～４）を含むクロックサイクルごとに、別個のメモリで次のようにペアリングされる、したがって、
１）ａｅ、ｅｉ、ｉｍ、．．．
２）ｂｆ、ｆｊ、ｊｎ、．．．
３）ｃｇ、ｇｋ、ｋｏ、．．．
４）ｄｈ、ｈｌ、ｌｐ、．．．
１）ａｅ、ｅｉ、ｉｍ、．．．
２）ｂｆ、ｆｊ、ｊｎ、．．．
３）ｃｇ、ｇｋ、ｋｏ、．．．
４）ｄｈ、ｈｌ、ｌｐ、．．．
【0064】
つまり、辞書の断片化されたメモリをサポートするために、各クロックサイクル「ｎ」で全ての「（ｗｏｒｄ＿ｓｉｚｅ＊ｎ＋ｉｎｐｕｔ＿ｓｔｒｅａｍ－１）」の値として、シンボルは、圧縮アルゴリズムへ効果的に提示される。そして、各シーケンスは、そのシンボルが以前に観測されたことがない場合には、新しい複数バイトのシンボルを作成する。この例のように、ワイドワードサイズが４の場合、圧縮アルゴリズムは、ｉの値ごとに１つずつ、別個に断片化された４つの辞書を使用して、全ての（４ｎ＋ｉ）番目の値（ｉ＝０、１、２、３）について動作する。したがって、表１に示すように、４つのシンボルの４つのブロックが、「ａｅｉｍ」、「ｂｆｊｎ」、「ｃｇｋｏ」、及び「ｄｈｌｐ」等、４つのメモリに符号化されることになる。データは、１つのメモリ「ユニット」について複数のストリームとして処理されるので、ストリームごとに１つの辞書（ハッシュテーブル）が処理される（例えば、各辞書には、１つ以上のＦＰＧＡメモリが含まれ得る）。
【0065】
【表1】
【0066】
表１で示した配列の列を読むと、バイトのペア「ａｅ」、「ｅｉ」、及び「ｉｍ」が、連続したクロックサイクルにおける第１の辞書への入力である。最終クロックサイクルでは、文字「ｍ」は、その列の最後のシンボルであり、さらに、後での圧縮に使用される新しいペアを形成するための後続シンボルがないので、第１の辞書に新しい辞書エントリを追加しない。同様に、バイト「ｂｆ」、「ｆｊ」、及び「ｊｎ」は、連続クロックサイクル等での第２の辞書への入力であり、バイト「ｃｇ」、「ｇｋ」、及び「ｋｏ」は、連続クロックサイクル等での第３の辞書への入力であり、バイト「ｄｈ」、「ｈｌ」、及び「ｌｐ」は４クロックサイクル以降の連続クロックサイクル等での第４の辞書への入力である。
【0067】
辞書Ｄの単純な実装では、ｉ番目（ｉ＝０、１、．．．、ｗｏｒｄ＿ｓｉｚｅ－１）の要素にＤ［ｉ］が格納されるような配列が、使用され得る。しかし、辞書Ｄの文字列の長さは可変であるため、ＦＰＧＡが提供する固定メモリ上では、単純な実装は、効率的でも、自明でもないはずである。辞書Ｄの単純なソフトウェア実装では、例えば、キーとして可変長文字列を、値として圧縮後の符号を持つ連想配列を使用可能であり、これは平衡バイナリツリー（balanced binary tree）として実装することができる。しかし、符号が既に知られているかどうかバイナリツリーにより確認するための各メモリ検索には、Ｏ（ｌｏｇ（ｎ））の動作（operation）が必要であり、ここで、ｎは格納されている文字列／整数のペアの数である。ＦＰＧＡ上でのリアルタイムの動作には、Ｏ（１）の動作が必要であり、つまり、ＦＰＧＡが、リアルタイムのデータを単数又は複数の辞書Ｄに圧縮するクロックサイクルが１つしかないということである。さらに、ＦＰＧＡでは、ＦＰＧＡのプログラミング時にメモリサイズを定義、固定する必要があるので、可変長文字列をキーとしてＦＰＧＡに格納することは、簡単（nontrivial）ではない。逆に、復号化の場合、各圧縮後の符号語（キー）は、未知の可変長のバイト（値）の文字列を指すことができ、この場合もやはり、ＦＰＧＡでは、簡単ではない。圧縮解除時には、クロックサイクルごとに１つの非圧縮（クリア符号）バイトを放出するよう、辞書Ｄの逆引き結果（reverse）（又は、反対からの参照結果）をＦＰＧＡに格納する。
【0068】
種々の実施形態によると、圧縮されるべきバイト列（sequence of byte）、つまり、可変長文字列は、プログラミング言語「Ｃ」の文字列である場合と同様に格納される。つまり、各バイト列は、リスト全体をトラバースできる（traversal）ようにするポインタと共に、複数文字の終端リストにＮＵＬＬ（ヌル）として格納される。これで、可変長文字列をＦＰＧＡに格納することに関する課題が解決される。バイト列（文字列）は、標準的な「Ｃ」プログラミング言語のように厳密な配列ではなく、各文字とともに格納されたリンクがそれぞれ、文字列の前文字を指す、単独のリンクリスト（singly linked list）のデータ構造と酷似したものである。このようなリンクリストのデータ構造は、「逆ポインタテーブル（reverse-pointer table）」と称することがある。この設計により、圧縮後の符号が、ＦＰＧＡメモリ内の可変長パターンを損失又は誤りなく指し示すことができる。ハッシュテーブルには、単純なバイナリツリーではなく、むしろハードウェアでハッシュ関数を介してアクセスされる。ハッシュ関数と逆ポインタテーブルとの組み合わせは、クロックサイクルにつき１回の読み出しと、クロックサイクルにつき１回の書き込みが要求されるリアルタイムのメモリアクセスをサポートする。
【0069】
逆ポインタテーブルは、例えば、Xilinx, Inc社から入手可能なＵｌｔｒａＳｃａｌｅ＋（商標）ＦＰＧＡのＵｌｔｒａＲＡＭ等の高密度、シングルクロック、２ポート、同期メモリを有する少なくとも１つのＦＰＧＡを用いて実装可能である。しかし、理解すべき点として、本教示の範囲を逸脱することなく、以下で検討するＵｌｔｒａＲＡＭと実質的に同じ機能を持つＦＰＧＡ、及び関連ＲＡＭを、組み込むことができる。一般的に、ＵｌｔｒａＲＡＭは、ＦＰＧＡで使用される従来型ＢＲＡＭの８倍の記憶容量を持つので、従来型ＦＰＧＡでは、例えば、本明細書で検討する２５６ワイドワードの設計で十分なＢＲＡＭを含むことができない。
【0070】
ＵｌｔｒａＲＡＭはＦＰＧＡのカラムナアーキテクチャ（columnar architecture）と互換性があるので、ＦＰＧＡの複数のＵｌｔｒａＲＡＭをインスタンス化し、ＦＰＧＡの全ての高さ（entire height）に対し、１つの列において直接的にカスケードすることが可能である。ＵｌｔｒａＲＡＭは、ＦＰＧＡの１つ以上の列に配列された２８８Ｋｂの単一クロック同期メモリブロックを含み、各メモリブロックは、最大２８８Ｋビットのデータを格納できる４Ｋ×７２ビットメモリブロックとして構成される。ＦＰＧＡの単一クロック領域の列には、１６個のメモリブロックが含まれる。
【0071】
各ＵｌｔｒａＲＡＭは２ポートを備え、いずれも各メモリブロックの４Ｋ×７２ビット全てをアドレス指定する。単一のＵＲＡＭには、前述のように、単一のＢＲＡＭの８倍の容量がある。これら２つのポートはそれぞれ独立して、クロックサイクルにつき１回の読み出し動作、又は１回の書き込み動作のいずれかを実行可能である。しかし、内部的には、ＦＰＧＡのスタティックランダムアクセスメモリ（ＳＲＡＭ：static random-access memory）配列はシングルポートメモリセルを使用する。デュアルポートの動作は、単一クロックサイクルでの第１のポートの動作に続く、第２のポートの動作により実行され、第１のポート及び第２のポートは、単一クロック入力を共有する。
【0072】
ＦＰＧＡ上で事前に必要なＯ（１）の動作を実現するハッシュテーブル又は辞書を使用して、逆ポインタテーブルを実装することができる。全般に、辞書は、ハードウェアではハッシュテーブルで実装されるが、ソフトウェアではバイナリツリーで実装することができる。ハッシュテーブル（辞書）は、下の表２で示すように、番号テーブル及びデータテーブルという、２つの別個のサブテーブルを含む。番号テーブルの各要素は、行ごとに２つのエントリを持つデータテーブルで使用されたエントリの数を格納する。ＦＰＧＡにおいて、符号化済みのシンボル（symbol）（文字列（a string））が既知であるか、又は、新たに符号を作成する必要があるかを判断する。これを行うために、各ハッシュエントリは、合計で最大３６ビットのメモリの利用可能なセルストレージを使用して、必要に応じ、最大１４ビットまで可能な最大１２ビットの圧縮後の符号と、８ビット文字（文字列の末尾シンボル）と、文字列内の前シンボルへの同サイズの逆ポインタが必要である。
【0073】
各データテーブルは、例えば、並列に格納されたワイドワードデータについてハッシュ関数を実行するために、１つ（又は、２つ）のＵｌｔｒａＲＡＭで実装され、各番号テーブルは、辞書インスタンスごとに２つ（又は、４つ）のＢＲＡＭで実装される。ハッシュサイズは、ＵｌｔｒａＲＡＭのアドレス空間（４Ｋ×７２ビット）と一致しており、表２で示すように、データの７２ビットを各メモリ位置で使用して、３６ビットのエントリを２個形成することができる。それゆえ、ＵｌｔｒａＲＡＭのデータレイアウトは、例えば、８個のＢＲＡＭと同じ全メモリフットプリントを有するが、例えば、ＢＲＡＭで必要とされる３６ビットエントリ８個よりも「より狭く」、かつ、「より深く」なっている。
【0074】
【表2】
【0075】
番号テーブルは、データテーブルの使用済み容量を示す。したがって、ＵｌｔｒａＲＡＭをデータテーブルに使用すると、ワードサイズ＊ＵｌｔｒａＲＡＭ（２５６ＵｌｔｒａＲＡＭの可能性があり、これは従来の大規模ＦＰＧＡの約２０％に相当）、及び、ワードサイズ＊２＊ＢＲＡＭ（５１２ＢＲＡＭの可能性がある）が得られる。表２において、両列のエントリｅｈ、ｉ（例えば、ｅ０，０、ｅ１，０、ｅ２，０、．．．、及びｅ０，１、ｅ１，１、ｅ２，１、．．．）はそれぞれ、ポインタ（ｊ）、圧縮中のシンボル文字列の末尾バイト、又は（ｘ）、並びに、ｊとｘから計算した逆ポインタという３つの値を含む構造体である。例えば、圧縮されるべき文字列が「ｃａｔ」という単語であるとすると、エントリｅ００は「ｔ」であり、別のエントリへの逆ポインタである可能性がある。その逆ポインタは、「ａ」、及び更に別のエントリへの逆ポインタを持ち、さらに、その逆ポインタは、「ｃ」、及びＮＵＬＬへの逆ポインタを持ち得る。ＮＵＬＬは逆ポインタがないことを示し、それがマルチシンボルの文字列の始点であることを示す。この配列によって、辞書に含まれる文字列の長さが可変であるという問題が解決される。注目すべきは、表１の各列が、図６の入力シンボルの文字列と等価であることである。例えば、表１の第１の列は、図６の第１の辞書の第１の入力ストリーム６３１に相当し得る。同様に、表１の各列、ひいては、図６の各入力ストリームについて、１つの表２が存在する。そのため、例えば、２５６ワイドワード設計（図６の４ワイドワード設計とは異なる）では、２５６の表２の異なるインスタンスを効果的に提供するはずである。
【0076】
圧縮に関するもう１つの例として、１つの入力ストリーム（例えば、第１の入力ストリーム６３１）で圧縮されるべき文字列、ひいては、１つの辞書（例えば、第１の辞書）をアドレス指定する文字列は、「ａ ｂ ａｂ ａｂａ ｂ」であり（スペースを入れないが、本明細書では、分かりやすくするためにスペースを入れてある）、この場合、ＬＺＷ圧縮アルゴリズムに従って圧縮された文字列は、例えば、９７ ９８ ２５６ ２５８ ９８となるはずである。最初の「ａ」、及び最初の「ｂ」は、これらの文字の最初の出現であるので、これらを圧縮できないが、文字「ａ」と「ｂ」が最初に観測された場合、符号２５６を使用する第１の辞書に新しいマルチシンボル文字列「ａｂ」が追加され、次に、このストリームに２回目の「ａｂ」の出現が見られた際、この新しい符号を２回目に出現した「ａｂ」に割り当てることができるので、マルチシンボル文字列は単一の符号へと圧縮される。同様に、「ａｂ」が最初に観測された際、辞書に値２５８を持つ新しい多文字コード「ａｂａ」を作成する機会が得られる。文字コード「ｂａ」に値２５７が割り当てられたが、アルゴリズムは圧縮を自動で最大化するので、値２５８を持つ「ａｂａ」が優先されることに留意されたい。２回目の「ａｂａ」の出現が観測されると、この新しい符号をマルチシンボル文字列で使用することができる。注意すべき点として、「ａ」と「ｂ」の出力は、ＡＳＣＩＩテーブルの文字「ａ」と「ｂ」それぞれの（例示的）数値表記９７と９８に過ぎない。
【0077】
「ａｂ」については、以前に出現した文字を含み、逆ポインタ：２５６、ｘ：９８、ｊ：９７を持つエントリが辞書に存在することになる。文字ｘ：９８（つまり、文字「ｂ」）、そして、ポインタｊ：９７（つまり、文字「ａ」）が、一時的に出力される。この場合、ポインタｊは文字「ａ」を指しているに過ぎない。「ａ」と「ｂ」が逆になっているので、圧縮解除すると、圧縮値２５６は「ａｂ」になる。エントリは、辞書の行ｈ（ｊ＝２５６，ｘ＝９７）＝５１２に出現し、他のハッシュ関数が以前に５１２を提供していなければ、ｅ５１２，０になる可能性が高く、その場合、エントリはｅ５１２，１となるはずである。このようなことが再び起こると、競合が発生し、この新しいマルチシンボル文字列は辞書に追加されず（圧縮は１クロックサイクルで行う必要があり、本来であれば、競合（conflict）を処理する方法がいくつかある）、圧縮効率が若干悪化することになる。それゆえ、ハッシュ関数ｈ（ｊ，ｘ）は、効率的である必要があり、この例では、競合の可能性を最小限に抑えるために、４０９６個のアドレス全てについて、均一にアクセスできるようにする必要がある。
【0078】
この例を続けると、「ａｂａ」については、以前に出現した文字を含み、逆ポインタ：２５８，ｘ：９７，ｊ：２５６を持つエントリ（ｈ（ｊ，ｘ）で算出）が辞書に存在することになる。文字ｘ：９７（つまり、文字「ａ」）、そして、ポインタｊ：２５６が、一時的に出力される。ポインタｊ：２５６は以前の場所に移動し、逆ポインタは２５６となる。この場合、上記と同じ手順に従うことで、前文字に追加される「ａｂ」の出力を再び提供し、「ａｂａ」となる。ここでいう「ａｂａ」は、実は逆になっているのだが、この例では、問題はない。文字の順序が問題であれば、例えば、上記の「ｃａｔ」という文字列の例では、圧縮解除時に順序が逆になるはずである。「ａｂａ」の出力は２５８である。最後の文字は単に「ｂ」であり、これ以上連結する文字列がないので、出力は単に９８（すなわち、文字「ｂ」）となる。
【0079】
注目すべきは、ＵｌｔｒａＲＡＭがＢＲＡＭほど柔軟ではなく、高性能でもないので、データがクロックサイクルごとに１回の圧縮の動作でクロック／ラインレートに到達し、読み取り動作と書き込み動作との間で遅延が発生するたびに、新たな遅延が発生する可能性があることである。このリスクを軽減するために、新しい符号語の挿入（書き込み動作）と、データを圧縮するためにその符号語の想定される使用（読み取り動作）との間で、最大「ｎ」個の新たなクロックサイクルを追加して、圧縮アルゴリズムを実行することができる。これにより、待ち時間が新たに発生しても、符号化と復号化のアルゴリズムが正しく動作することをもたらすが、例えば、従来のＬＺ７７又はＬＺ７８圧縮アルゴリズムと比較して、新しい符号語が「ｎ」クロックサイクル後まで使用できないことにより、圧縮が若干低下し得る。
【0080】
表２を使用して実装されるハッシュ関数ｈ（ｊ，ｘ）は、式（１）で実装される、式中、「＞＞」と「＜＜」はそれぞれ、ビット単位の右シフトと左シフトであり、「＾」は、ビット単位の排他的論理和（ＸＯＲ）演算、そして、「＆」は、ビット単位のＡＮＤ論理和を表している。
h(j,x)=((j>>4)^(j<<2)^(x<<4))&"0xFFF" 式（１）
h(j,x)=((j>>4)^(j<<2)^(x<<4))&"0xFFF" 式（１）
【0081】
ハッシュ関数ｈ（ｊ，ｘ）は、１２ビットの逆ポインタ（ｊ）と、８ビットの文字（ｘ）という、２つの入力パラメータを有する。ハッシュ関数ｈ（ｊ，ｘ）は、例えば、表２に行が示されているクロックサイクルごとに、新しい行を計算する。したがって、例えば、ｈ（ｊ＝０，ｘ＝１）＝１６の場合、表２の番号テーブルの１６行目が、アクセスされるはずである。行１６の番号サブテーブルには、表２のデータサブテーブルで満杯になっているエントリ数に応じ、０、１、又は２のいずれかが含まれることになる。１６行目が０、又は１であれば、ｅ１６，０、又はｅ１６，１のいずれかに文字ｘが書き込まれる。行１６が２である場合（つまり、この行は満杯である）、これは競合となり、この新しくハッシュされた文字列のエントリを追加できないことにより、この新しくハッシュされた文字列がデータストリームの後半で検出された場合には、最適な圧縮よりも若干悪化し得る。この文字は各シンボルであり、逆ポインタは、このシンボルを表１に示す配列にある以前のシンボルに関連付ける。ハッシュ関数ｈ（ｊ，ｘ）は、ＢＲＡＭを使用した場合の１０ビットの出力アドレスとは異なり、１２ビットの出力アドレス（例えば、４０９６の異なるアドレス）を持ち、全ての出力アドレスへと均一にアクセスすることができる。つまり、或る１つのアドレスが、他のアドレスよりも多くアクセスされないものとする。ハッシュ関数ｈ（ｊ，ｘ）は、ビット演算のみを用いるので、ハードウェア、例えばＦＰＧＡでの実装が容易で、しかも、類似した文字列について異なるハッシュ値をリアルタイムに一貫して生成することが可能である。
【0082】
他のハッシュ関数と同様、衝突（collision）の可能性がある。衝突とは、異なる文字列が同じハッシュ値を持つことである。或る行の双方の場所が使用された場合、競合（conflict）が発生する（上述のとおり）、つまり、その文字列に対する新たな圧縮後の符号を辞書に追加することはできず、既存の小さい方の符号を使用しなければならない。これにより、想定されていた圧縮が或る程度損なわれるが、ハッシュの競合を解決しようとしても、単一クロックサイクルでは達成できない２回目の検索として、リアルタイムの動作が可能となる。
【0083】
図７は、代表的な実施形態に係る、高速階層型パケットベースのプロトコルに準拠するデータリンクを介したデータの通信中、インターポーザ回路のキャプチャバッファに格納されるべきデータペイロードの並列データ圧縮を実行する方法を示す簡略流れ図である。
【0084】
図７を参照すると、並列データ圧縮を実行することは、ブロックＳ７１１において、高速データリンク１３０のＰＣＩｅレーン等の複数のシリアル高速データレーンにおけるインターポーザ回路１２０でそれぞれのデータペイロードを含む、ＴＬＰ及び／又はＤＬＬＰのシンボルを受信することを含む。ブロックＳ７１２において、ＴＬＰ及び／又はＤＬＬＰのシンボルを、クロックサイクルの各クロックに到着するワイドワードのシリアルストリーム（例えば、シリアルストリーム６２０）へとデスキューする。ブロックＳ７１３において、ワイドワードを、入力ストリーム（例えば、第１のストリーム６３１～第４の入力ストリーム６３４）へと配列する。各入力ストリームは、クロックサイクルの各クロックに到着する各ワイドワードの同じ場所からのシンボルを含み、これにより、各シンボルが、次のシンボルと共に正しい場所に配置され、最大２５６バイト以上の幅の入力ストリームを形成する。つまり、インターポーザ回路１２０は、クロックサイクルの各クロックで圧縮されるべきワイドワードを形成するために、高速プロトコルから提供される（最大）１６レーンから一度に圧縮する２５６以上のデータシンボル（バイト）を取得し、デスキューすることができる。上記考察において、バイトとシンボルはそれぞれ８ビットと仮定しているので、ワイドワードと圧縮に関して、これらの用語は同じ意味で使われる。
【0085】
ブロックＳ７１４において、式（１）で示されるハッシュ関数を実施し、ポインタを前シンボルに提供するハッシュテーブルを使用して、配列後のシンボルを圧縮する。ブロックＳ７１５において、圧縮後のシンボルは、キャプチャバッファ１２５に格納される。高速データプロトコルに従ってデータペイロードを解析するために、インターポーザ回路１２０、及び／又は、プロトコルアナライザを実行するＵＩコンピュータ１１０（つまり、インターポーザ回路１２０、又はプロトコルアナライザを実行するＵＩコンピュータ１１０、あるいはそれらの両方）によって、圧縮後のシンボルを圧縮解除することができる。
【0086】
図７のブロックＳ７１１～Ｓ７１５を参照して上述したプロセスは、プロトコルドメイン固有の圧縮技術と称することもある。これは、情報を失うことなく、キャプチャバッファ１２５に格納するのに必要なデータ量を圧縮、又は削減するために、プロセスごとにプロトコル設計を利用するためである。また、インターポーザ回路１２０が、ＤＵＴ１４０とホストコンピュータ１５０に関する「中間者」として動作しているため、プロトコルトラフィックをキャプチャし、処理する仕組みについて、何かしらの仮定がなされる場合がある。また、ホストコンピュータ１５０とテスト自体のユースケースは、忠実度を損なわずにデータを削減する仕組みと更に関係している可能性がある。
【0087】
前述のように、ＴＬＰ及び／又はＤＬＬＰのデータペイロードについて、又は、データペイロードとヘッダの双方について、圧縮を実行することができる。データペイロードとヘッダの双方について圧縮を実行する場合、ワイドワードが全て、そのまま圧縮器に渡される。これまで考察したように、圧縮がデータペイロードのみについて行われる場合には、データ完全性フィールドの削除、及び既知のフィールドの削除等、ワイドワードのヘッダに関して格納されるデータ量を削減する他の手法を実行してから、その後、残りの部分に対して圧縮を実行する。一実施形態において、圧縮前にデータペイロードを新たな２５６バイト幅のワードに再編成して、効率を高めるために、ギャップを最初に削除してもよい。
【0088】
［圧縮解除］
種々の実施形態において、必要なときに、圧縮後のデータを圧縮解除することができる。圧縮解除では、圧縮段階から辞書のコピーにアクセスする必要はないが、辞書は使用することができる。むしろ、一般的に言えば、圧縮後のワイドワードデータ入力の圧縮解除には、ワイドワード圧縮後データを適切に順序付けられた圧縮後の符号の単一ストリームとして表記する、結合された圧縮後の出力ストリームのコピーのみが必要となる。圧縮後のデータのみが、ＵＳＢ又はイーサネットリンクを介してＵＩコンピュータ１１０へと送信され、圧縮後のデータと辞書の完全セットが共に送信されないので、このことは、とりわけ、ＵＩコンピュータ１１０について有用である。
種々の実施形態において、必要なときに、圧縮後のデータを圧縮解除することができる。圧縮解除では、圧縮段階から辞書のコピーにアクセスする必要はないが、辞書は使用することができる。むしろ、一般的に言えば、圧縮後のワイドワードデータ入力の圧縮解除には、ワイドワード圧縮後データを適切に順序付けられた圧縮後の符号の単一ストリームとして表記する、結合された圧縮後の出力ストリームのコピーのみが必要となる。圧縮後のデータのみが、ＵＳＢ又はイーサネットリンクを介してＵＩコンピュータ１１０へと送信され、圧縮後のデータと辞書の完全セットが共に送信されないので、このことは、とりわけ、ＵＩコンピュータ１１０について有用である。
【0089】
途切れのない連続した単一シーケンス（ストリーム）として、圧縮後のデータを格納すると、最適なデータ記憶機構が得られる。しかし、シンボルを正しく復号化する上で、圧縮で生成されるデータの出力ストリームにおけるデータの順序が重要である。圧縮解除では、どの圧縮後のシンボルが、どの個々の元のワイドワード入力ストリーム（例えば、第１の入力ストリーム６３１～第４の入力ストリーム６３４）のそれぞれに属するかを特定できるようにする必要があり、こうすれば、圧縮後のシンボルを正しい辞書Ｄｉ（ｉ＝０、１、２、．．．、ｗｉｄｅｗｏｒｄ－１）にアドレス指定することができる。
【0090】
例えば、従来型ＬＺＷ圧縮アルゴリズムでは、圧縮後のシンボルが生成されると、このシンボルは出力ストリームに書き込まれる。したがって、ワイドワードシステム用に適応しない場合、入力ストリームにそれぞれ対応する複数の出力ストリームを、途切れのない理想的な単一出力ストリームへと統合する際に、ＬＺＷ圧縮アルゴリズム（及び、他の従来型圧縮アルゴリズム）では、順序情報が失われることになる。
【0091】
１つ以上の非圧縮シンボルを表す圧縮後のシンボルを作成すると、キャプチャバッファにおけるワイドワードの圧縮後の出力ストリームの順序が変わることになる。図８は、説明目的で、上述の圧縮技術を用いて生成された圧縮解除用ワイドワードデータの入力のシンボルの例を示す図である。
【0092】
図８を参照すると、ワイドワードデータの第１の入力ストリーム８１１（入力ストリーム０）及び第２の入力ストリーム８１２（入力ストリーム１）が、圧縮用に入力される。第１の入力ストリーム８１１及び第２の入力ストリーム８１２は、例えば、図６を参照してこれまで考察した第１の入力ストリーム６３１及び第２の入力ストリーム６３２と本質的に対応するが、便宜上、シンボルの番号は異なっている。第１の圧縮（中間）ストリーム８２１（圧縮後０）は、第１の入力ストリーム８１１について算出され、データが圧縮される時と、圧縮プロセス中にデータがキャプチャバッファに書き込まれる直前との中間ステップでの動作の順序を表す。同様に、第２の圧縮（中間）ストリーム８２２（圧縮後１）は、第２の入力ストリーム８１２について算出され、データが圧縮される時と、圧縮プロセス中にデータがキャプチャバッファに書き込まれる直前との中間ステップでの動作の順序を表す。途切れのない最終的な圧縮後の単一出力ストリーム８３０は、順番に格納されるデータに相当するが、以下で検討するように、キャプチャバッファは、圧縮後の第１のストリーム８２１におけるノーオペレーション（no-operation）（「ＮｏＯｐ」）エントリの存在により、圧縮解除目的用の出力シンボルのその後の順序が回復不能となるような順序付けとなっている。
【0093】
図８において、「ｂｎ」は、ストリーム「ｉ」のｎ番目の場所のシンボルを示し、「Ｄｉ」は、ストリーム「ｉ」について対応する辞書、すなわち、ｉ番目の辞書を示す。これまで検討した圧縮プロセスと同様、当初は、ワイドワードシンボルの各入力ストリーム（例えば、第１の入力ストリーム６３１～第４の入力ストリーム６３４）が、大きい方の辞書（Ｄ）自身の断片化された一部を使用して圧縮されていたので、ワイドワードシンボルのセットの各入力が、圧縮解除用に別々に処理される。そのため、圧縮解除時に同じ照合情報を使用する必要がある。図８の例では、第１の入力ストリーム８１１のシンボルは、第１の辞書Ｄ１をアドレス指定し、第２の入力ストリーム８１２のシンボルは、第２の辞書Ｄ２をアドレス指定しなければならないといった具合のルールとなっている。
【0094】
一般的に、圧縮アルゴリズムの入出力は、動作（operation）の観点からデータを処理する。圧縮段階中では、１回の動作では、単一のクロックサイクル（ハード制約に相当する）を要し、入力データの処理はリアルタイムに行われる必要がある。しかし、圧縮解除段階中では、このようなハード制約はなく、つまり、必要であれば、単一の動作に２クロック以上かかることもあり得る。説明を簡単にするために、最初に、動作の観点から、圧縮解除プロセスについて説明し、次に、ハードウェア上のクロックサイクルに動作をマッピングする例を示す（例えば、ＦＰＧＡ、又はＡＳＩＣ）。
【0095】
途切れのない圧縮後の出力ストリーム８３０におけるシンボルの順序に関して、圧縮処理中にシンボルｂ５とｂ６が単一符号に圧縮されると、通常、図８で示す例示的な圧縮処理により、第１の辞書Ｄ１を使用する第１の入力ストリーム８１１における場所ｂ５（動作番号５）で出力をスキップさせることになる。このスキップは、第１の入力ストリーム８１１について、計算された圧縮後の第１のストリーム８２１のＮｏＯｐエントリで示される。一般的に、２つ以上の元の入力シンボルを表す新しい圧縮後の符号が放出されようとしているが、まだ放出されていない場合には、ＮｏＯｐは発生する。これは、複数の入力シンボルを単一符号に圧縮した場合に発生する。例えば、元の２つの入力シンボルを圧縮すると１つのＮｏＯｐとなり、３つの入力シンボルを圧縮すると２つのＮｏＯｐとなる。したがって、入力シンボルが消費されるたびに、圧縮アルゴリズムは、その入力シンボルを圧縮できるかどうかをテストする。入力シンボルと一致する長いマルチシンボル文字列が既に知られている場合、入力シンボルをその長いマルチシンボル文字列で圧縮することができる。これが発生すれば必ず、その場所のシンボルがなくなるため、ＮｏＯｐエントリが導入される。したがって、新たに結合された圧縮後のシンボルｂ５及びｂ６を表す新たな圧縮後の符号は、シンボルｂ６（動作番号６）になるまで、第１の入力ストリーム８１１の出力において放出されない。
【0096】
単一出力ストリームを伴う非ワイドワード圧縮では、新たなマルチシンボル文字列ｂ５／ｂ６が、依然として、途切れのない圧縮後の出力ストリームにおいてシンボルｂ４と直列に続く次のシンボルのままであるため、ＮｏＯｐは問題ではない。つまり、圧縮する入力ストリームが１つであれば、並べ替え（reordering）が発生する可能性はなくなる。しかし、ワイドワード圧縮では、様々な入力ストリームを、途切れのない理想的な単一出力ストリームへと結合する際、１つ以上のＮｏＯｐによって、入力シンボルの順序が変わる場合がある。特に、キャプチャバッファ内のスペース効率に優れた最適なレイアウトには、途切れのない圧縮後の単一出力ストリームが必要である。
【0097】
図示の例において、圧縮後の第１のストリーム８２１にＮｏＯｐが存在することにより、圧縮後の単一出力ストリーム８３０は、正しく順序付けされていないキャプチャバッファ内のデータに相当する。図示のように、圧縮後の出力ストリーム８３０は、圧縮後の第１のストリーム８２１と圧縮後の第２のストリーム８２２との間で交互にシンボルを受信する。すなわち、圧縮後の出力ストリーム８３０は、圧縮後の第１のストリーム８２１からシンボルｂ１を、圧縮後の第２のストリーム８２２からシンボルｂ１を、圧縮後の第１のストリーム８２１からシンボルｂ２を、圧縮後の第２のストリーム８２２からシンボルｂ２を、といった具合で受信する。しかし、圧縮後の第１のストリーム８２１のＮｏＯｐエントリをスキップすることで、圧縮後の第２のストリーム８２２のシンボルｂ４の直後に、同じく圧縮後の第２のストリーム８２２からのシンボルｂ５が続き、そして、圧縮後の第１のストリーム８２１からのマルチシンボル文字列ｂ５／ｂ６が続くようになる。第１の入力ストリーム８１１が第１の辞書Ｄ１にアドレス指定され、そして、第２の入力ストリーム８１２が第２の辞書Ｄ２にアドレス指定されることを保証する順序が失われ、回復できないので、圧縮後の出力ストリーム８３０を圧縮解除用の入力として使用すると、各辞書のデータが元の順序で回復できなくなる。例えば、第２の入力ストリーム８１２を起点とする２つの隣接シンボルｂ４及びｂ５は、圧縮後の出力ストリーム８３０（円８３５で示す）において連続する場所で出現するので、交互に出現するシンボルがラウンドロビン（round robin）方式で交互のストリームを目指す場合、それらが異なる入力ストリームを起点とするものと、誤って仮定されるはずである。また、第１の入力ストリーム８１１を起点とするシンボルｂ５及びｂ６からのマルチシンボル文字列ｂ５／ｂ６は、第２の入力ストリーム８１２を起点とするシンボルｂ５の後で出現するものとする。それゆえ、ワイドワードで複数の入力ストリームからデータを復元することを支援するために、より予測しやすい順序が必要となる。
【0098】
１つの解決策としては、元の入力ストリーム（例えば、第１の入力ストリーム８１１、又は第２の入力ストリーム８１２）、及び各シンボルｂｎの関連する辞書を示す追加情報を含めることがある。追加情報により、正しい辞書Ｄｉをアドレス指定できるようになる。ただし、キャプチャバッファ内の途切れのない単一の出力ストリームへの圧縮中にデータがインターリーブされた後、別個の入力ストリームを識別するのに必要な追加情報の量まで、格納後のデータの量が増加するので、追加情報を含めることは、使用可能なデータストレージを最大化するという目的には逆効果となる。代替的には、辞書のデータをそれぞれ、別個の場所に配置して、辞書ごとに１ストライプずつ、圧縮後のデータの複数ストライプ（行）を効果的に作成することができる。ただし、１つのストライプで利用できるスペースを使い切ると、キャプチャプロセスが停止するので、この手法も最適ではない。つまり、或るストライプが満杯になると、一部にまだ空き領域がある場合でも、キャプチャバッファ内の他のストライプにそれ以上のデータを書き込むことはできない。
【0099】
これに対し、本明細書の実施形態によれば、圧縮後のデータは、マルチシンボル文字列の最初のシンボルが、（圧縮前に）本来出現する順序でキャプチャバッファに書き込まれるため、並べ替えが回避される。これは、圧縮中に途切れのない圧縮後の出力ストリームが作成されたときのシンボルの場所ではなく、途切れのない圧縮後の出力ストリームが非圧縮のマルチシンボル文字列である場合と同様に、途切れのない圧縮後の出力ストリームのシンボルの場所を使用することによって行われる。
【0100】
図９は、代表的な実施形態に係る、圧縮解除用のワイドワードデータ入力のシンボルを並べ替える例を示す図である。図９を参照すると、第１の入力ストリーム８１１からの２つの元の到着シンボルｂ５及びｂ６に相当する圧縮後のマルチシンボル文字列は、第１の到着シンボルｂ５の場所には書き込まれ、次の着信シンボルｂ６の場所には書き込まれない。つまり、図８で見られるように、マルチシンボル文字列ｂ５／ｂ６は、動作番号５で書き込まれ、動作番号６では書き込まれない。この「最初に到着するシンボル」の並び替えを行うことで、キャプチャバッファに格納された圧縮後の出力ストリーム９３０からシンボルｂ５及びｂ６の元の順序を復元するのに十分な情報が保持される。結合されたマルチシンボル文字列ｂ５／ｂ６が復号化される際、マルチシンボルｂ５／ｂ６が、第１の辞書Ｄ１に属することも分かっている、第１の入力ストリーム９１１に関する元の２つの非圧縮シンボルｂ５及びｂ６に相当するかについて、取得されたデータ符号に問い合わせることができる。そのため、順序は守られる。また、シンボルを早期に書き込むことはできず、他のストリームの残りのシンボルは、出力を並べ替える時間を稼ぐために一時バッファで遅延させることができる。
【0101】
具体的には、図９は、ワイドワードデータの第１の入力ストリーム９１１（入力ストリーム０）及び第２の入力ストリーム９１２（入力ストリーム１）を示し、これらは、圧縮用に以下で提供される。第１の入力ストリーム９１１及び第２の入力ストリーム９１２は、図６を参照してこれまで考察した第１の入力ストリーム６３１及び第２の入力ストリーム６３２とそれぞれ対応し得るが、便宜上、シンボルの番号は異なっている。図９は、第１の入力ストリーム９１１について計算され、本実施形態に従って並べ替えられた圧縮後の第１のストリーム９２１（圧縮後０）と、第２の入力ストリーム９１２について計算された圧縮後の第２のストリーム９２２（圧縮後１）も更に示しており、データが圧縮処理中に途切れのない圧縮後の出力ストリーム９３０としてキャプチャバッファに書き込まれる前の中間ステップにおける動作の順序を表している。その後の圧縮解除は、圧縮後の出力ストリーム９３０について、既知の圧縮解除アルゴリズムに従って実行される。最終的な圧縮解除後のストリーム９４０は、圧縮後の第１のストリーム９２１にＮｏＯｐエントリが存在するにもかかわらず、正しく順序付けられた、圧縮解除後のデータを示している。
【0102】
図示の実施形態によると、ワイドワード用の圧縮後の出力ストリーム９３０は、非圧縮文字列の元の場所における第１のシンボルに基づいて、交互に出現する第１の入力ストリーム９１１及び第２の入力ストリーム９１２からの連続する圧縮後のシンボルが互いに続くよう、圧縮中に書き込まれる。元の到着シンボルを圧縮できない場合、このシンボルは、無関係に、正しい動作中に正しい場所で放出される。１つ以上のシンボルがマルチシンボル文字列に圧縮されると、最終的に圧縮アルゴリズムが作成された際に、マルチシンボル文字列の最終動作ではなく、マルチシンボル文字列の第１のシンボルに対応する第１の動作で作成された場合と同様に、圧縮後の符号が出現するよう、圧縮後の符号は一時的にバッファされてから、第１の到着シンボルの順序で放出される。このインターリーブでは、入力ストリームのいずれか１つの入力シンボルが新たなマルチシンボル文字列に圧縮されれば必ず、全ての入力ストリームのシンボルを放出する際に適切な遅延を追加する必要がある。
【0103】
例えば、本明細書で説明する例示的なデュアルワイドワードシステムでは（説明をしやすくするため）、圧縮後の出力は常に、第１の入力ストリーム９１１、次いで、第２の入力ストリーム９１２のように、一対単位で放出させる。さらに、複数のシンボルを１つの新たなマルチシンボル文字列に圧縮すれば必ず、この新たな圧縮後のシンボル符号は、新たな符号内の最初の初期／第１の圧縮前のシンボルの場所に書き込まれる。例えば、圧縮後のマルチシンボル文字列ｂ５／ｂ６は、動作番号５では、シンボルｂ５の場所に書き込まれ、動作番号６ではシンボルｂ６の場所には書き込まれない。したがって、図示の例では、圧縮後の出力ストリーム９３０は、シンボルｂ５の場所ではなく、シンボルｂ６の場所で計算された圧縮後のストリーム９２１にＮｏＯｐが存在することにより、代表的な実施形態に従って、正しく順序付けられたキャプチャバッファ内のデータを表している。
【0104】
図示のように、圧縮後の出力ストリーム９３０は、圧縮後の第１のストリーム９２１と圧縮後の第２のストリーム９２２との間で交互にシンボルを受信する。すなわち、圧縮後の出力ストリーム９３０は、圧縮後の第１のストリーム９２１からシンボルｂ１を、圧縮後の第２のストリーム９２２からシンボルｂ１を、圧縮後の第１のストリーム９２１からシンボルｂ２を、圧縮後の第２のストリーム９２２からシンボルｂ２を、といった具合で受信する。このインターリーブ後の処理は、圧縮後の第２のストリーム９２２からシンボルｂ４を受信した後で、圧縮後の第１のストリーム９２１からマルチシンボル文字列ｂ５／ｂ６を受信することと、圧縮後の第２のストリーム９２２からシンボルｂ５を受信することとを含めるように進む。次に、またしても、切り替えられたＮｏＯｐエントリについて検討しているが、圧縮後の出力ストリーム９３０には書き込まれず、したがって、次のシンボルは、第２のストリーム９２２からのシンボルｂ６であり、そして、圧縮後の第１のストリーム９２１のシンボルｂ７が受信され、その後、圧縮後の第２のストリーム９２２からシンボルｂ７が受信される。したがって、図示の順序では、圧縮解除後のストリーム９４０（この場合も、円９３５で示す）で見られるように、元の順序で各辞書のデータを復元可能であり、ワイドワードにおける複数の入力ストリームからデータを復元できる。とりわけ、圧縮後の第１のストリーム９２１からのシンボルｂ６（参照番号９４１で図示）は、圧縮後の第２のストリーム９２２からのシンボルｂ５の直後で正しく配置される。
【0105】
「最初に到着するシンボル」の並び替え（デインターリーブ（de-interleaving））を行うことで、データを正しい順序で再構成するのに必要とされる２つの前提情報を保持することができる。第１に、図示の例では、マルチシンボル文字列ｂ５／ｂ６は、第２の入力ストリーム９１２のシンボルｂ５の場所ではなく、第１の入力ストリーム９１１のシンボルｂ５の場所に到着したことが分かっているので、それゆえ、第１の辞書Ｄ１でアドレス指定される。第２に、マルチシンボル文字列ｂ５／ｂ６に関する取得されたデータを調べると、最終的に圧縮されない文字列の長さが、１シンボルを超えることが分かっている。したがって、圧縮後のマルチシンボル文字列ｂ５／ｂ６を復号化して、例えば、圧縮解除ストリーム９４０を得る場合、正しいタイミングが来たら、シンボルｂ５を先に書き出してから、シンボルｂ６を後で書き出すことになる。このようにして、シンボルｂ５とｂ６が共に、圧縮解除後の最終ストリーム９４０の正しい位置へと書き込まれる。さらに、マルチシンボル文字列ｂ５／ｂ６の最終的な長さは、非圧縮の２シンボルであることが分かっているので、圧縮後の出力ストリーム９３０の次の符号が属する辞書を算出できる。特に、ＦＰＧＡ（又は、ＡＳＩＣ）を用いたハードウェア実装では、以下で考察する逆ポインタ技術により、シンボルを逆順に並び替える。
【0106】
つまり、圧縮後の単一符号が複数の入力シンボルに相当する場合、本実施形態に従って、圧縮解除後のシンボルの長さと位置を算出することができる。図示の例では、圧縮後の出力ストリーム９３０のバイトｂ５の位置に２バイトが図示されている。この情報を使用して、圧縮解除後のストリーム９４０を提供するために、他のインターリーブ後の入力ストリーム全ての圧縮解除後のシンボルを正しく読み取る方法を計算できる。
【0107】
図１０及び図１１は、代表的な実施形態に係る、圧縮解除用のワイドワードデータ入力のシンボルを並べ替えるその他の例を示す図である。図１０を参照すると、マルチシンボル文字列ｂ５／ｂ６は、圧縮後の第１のストリーム及び第２のストリーム（図示せず）のそれぞれにおいて、シンボルｂ５の位置にあるものと仮定する。したがって、圧縮後の出力ストリーム１０３０は、圧縮後の第２のストリームからのシンボルｂ４に続いて、圧縮後の第１のストリームからマルチシンボル文字列ｂ５／ｂ６を受信し、さらに、圧縮後の第１のストリームからのマルチシンボル文字列ｂ５／ｂ６に続いて、圧縮後の第２のストリームからマルチシンボル文字列ｂ５／ｂ６を受信する。それゆえ、圧縮解除後の後続ストリーム１０４０は、圧縮後の第１のストリームからのシンボルｂ６（参照番号１０４１で図示）及び圧縮後の第２のストリームからのシンボルｂ６（参照番号１０４２で図示）が、圧縮後の第２のストリームからのシンボルｂ５の直後に正しく配置されていることによって示されるように、正しい順序を備える。
【0108】
図１１を参照すると、結合された圧縮後のシンボルｂ５、ｂ６、及びｂ７を示すマルチシンボル文字列ｂ５～ｂ７は、圧縮後の第１のストリーム（図示せず）内のシンボルｂ５の位置にあると仮定する。したがって、圧縮後の出力ストリーム１１３０は、圧縮後の第２のストリームからのシンボルｂ４に続いて、圧縮後の第１のストリームからマルチシンボル文字列ｂ５～ｂ７を受信し、引き続き更に、マルチシンボル文字列ｂ５～ｂ７に続いて、圧縮後の第２のストリームからシンボルｂ５、ｂ６、及びｂ７を受信する。それゆえ、圧縮解除後の後続ストリーム１１４０は、圧縮後の第１のストリームからのシンボルｂ６（参照番号１１４１で図示）が、圧縮後の第２のストリームからのシンボルｂ５の直後に正しく配置され、さらに、圧縮後の第１のストリームからのシンボルｂ７（参照番号１１４２で図示）が、圧縮後の第２のストリームからのシンボルｂ６の直後に正しく配置されることで示されるように、正しい順序を備える。
【0109】
ＦＰＧＡ（又は、ＡＳＩＣ）を用いたハードウェア実施態様では、使用できるメモリが限られるため、複数長の文字列（マルチシンボル文字列）を効率よく格納するために逆ポインタ技術が利用されている。それゆえ、圧縮解除を確実に行うために、例えば、表２を参照して、これまで検討した圧縮段階中、複数の辞書用の逆構造体を作成する必要がある。
【0110】
図１２は、代表的な実施形態に係る、圧縮解除のための逆構造体を作成する方法を示す流れ図である。全般に、逆構造体の作成には、４つの復号プロセスが必要であるが、復号後の各出力シンボル（バイト）に対する各復号プロセスを１回の処理と見なしてもよい。各動作は、（ｉ）途切れのない圧縮後の出力ストリームの圧縮後の符号を読み取り、この圧縮後の符号で表される非圧縮シンボルを放出すること、又は、（ｉｉ）圧縮後の符号がマルチシンボル文字列で表される場合、文字列が全て書き出されるまで、マルチシンボル文字列内の個々のシンボルを１つずつ正しい順序で放出することのいずれかを含む。
【0111】
図１２を参照すると、ステップＳ１２０１において、ワイドワードの到着入力シンボルのそれぞれについて、メモリ構造のインスタンスを作成する。メモリ構造のインスタンスの例を、以下の表３Ａに示す。表３Ａは、各入力辞書Ｄｉの圧縮辞書の逆引きであり、１バイトの基本値（例えば、値０～２５５）を適切な文字コード値及び逆ポインタと関連付けたものである。注目すべきは、０～２５５バイトの逆ポインタがＮＵＬＬエントリであることで、これらのバイトは常に、複数シンボル文字列で想定される第１のバイト（又は、文字）であることを示している。したがって、表３Ａは、圧縮後の出力ストリームを圧縮解除する際に形成され得る、想定される全ての複数シンボル文字列の第１の想定文字のみを示している。
【0112】
【表3A】
【0113】
ステップＳ１２０２では、上述の第１の到着シンボル並び替えプロセスを使用して、辞書ごとの別個の入力ストリームに関する文字コードを途切れのない圧縮後の出力ストリームから繰り返し読み込んで、表３Ｂを作成する。
【0114】
【表3B】
【0115】
図９の例を参照すると、第１の入力ストリーム９１１及び第２の入力ストリーム９１２の双方に対して、途切れのない圧縮後の出力ストリーム９３０に圧縮後の符号が提供される。この符号のストリームでは、圧縮後の符号は、第１の入力ストリーム９１１及び第２の入力ストリーム９１２のそれぞれ（ひいては、第１の辞書Ｄ１及び第２の辞書Ｄ２のそれぞれ）について、表３Ｂの別コピーへと追加される。効率化のため、入力ストリームと同数の演算を並列に実行することができる。図９では、入力ストリームが２つあるので、２つの演算を同時並列的に行うことができる。
【0116】
単一入力ストリーム（第１の入力ストリーム）に関するより詳細な例を以下で説明し、最終的な途切れのない圧縮後のストリームの読み取り方法、及び圧縮後の符号の圧縮解除方法を示すことにする。結合されたインターリーブ後の最終的な途切れのない圧縮後のストリームの第１の入力ストリームの一部は、第１の辞書（Ｄ１）を使用して元の入力ストリームに関する圧縮後の符号を含む。例として、第１の入力ストリームには、シンボル（バイト）「ｃａｃａｔｃａｔ」が含まれ、この例では、圧縮後の符号「９９、９７、２５６、１１６、２５８」へと圧縮することができる。前述したように、既知のＡＳＣＩＩテーブルを使用して単一バイト値から文字を変換できるため、表３Ａはメモリ内では必要ない。したがって、例えば、ＡＳＣＩＩ表によれば、「ｃ」＝９９、「ａ」＝９７、「ｔ」＝１１６である。圧縮後の符号２５６と２５８は値が２５５より大きいので、これらはマルチシンボル文字列であり、表３Ｂに格納される。圧縮後の符号は、第１の入力ストリームについて、途切れのない圧縮後の出力ストリームから反復して取得され得る一方、対応する圧縮後の第２の入力ストリームでは、表３Ｂの別のインスタンス（図示せず）について、同じ動作が並列して実行されるといった具合である。さらに、このプロセスでは、第２の辞書（Ｄ２）を使用して第２の入力ストリームを復号化するのに必要なデータを作成する。
【0117】
本例の第１の入力ストリームに関して、ステップ１２０２の反復的な検索プロセスは、最初に、圧縮後の出力符号の圧縮後の符号９９を読み取ることと、さらに、２５５の後で次に使用可能なロケーション（ａｄｄｒ）の表３Ｂ（図の例では、ロケーションａｄｄｒ＝２５６）に逆ポインタ値９９を追加することを含む。次に、圧縮後の符号９９のａｄｄｒ＝９９における「ｃ」という文字コードを検索し、圧縮後の符号２５６のａｄｄｒ＝２５６に格納する。
【0118】
このプロセスは、他の圧縮後の符号についても継続される。つまり、反復的な検索プロセスには、圧縮後の符号９７を読み取ることと、次に使用可能なロケーションａｄｄｒ＝２５７（ａｄｄｒ＝２５６の次の場所）での表３Ｂに逆ポインタ値９７を追加することと、「ａ」というａｄｄｒ＝９７の文字コードを検索し、ａｄｄｒ＝２５７に格納することとも更に含まれる。そして、このプロセスには、圧縮後の符号２５６を読み取ることと、次に使用可能なロケーションａｄｄｒ＝２５８での表３Ｂに逆ポインタ値２５６を追加することと、「ｃ」というａｄｄｒ＝２５６の文字コードを検索し、ａｄｄｒ＝２５８に格納することとも含まれる。注目すべきは、このようにして、ａｄｄｒ＝２５８は、２５５より大きい逆ポインタの値を有しており、この場合、後述のように、次の演算は、第１の入力ストリームに関する新たな圧縮後の符号を読まないが、逆ポインタを辿って、第１の入力ストリームに関する次の演算で取るべき動作を決定することである。そして、このプロセスには、圧縮後の符号１１６を読み取ることと、次に使用可能なロケーションａｄｄｒ＝２５９の表３Ｂに逆ポインタ値１１６を追加することと、「ｔ」というａｄｄｒ＝１１６の文字コードを検索し、ａｄｄｒ＝２５９に格納することとも含まれる。
【0119】
ステップ１２０３において、第１の入力ストリームと第１の辞書について、途切れのない圧縮後の出力ストリームの各圧縮後の符号の逆ポインタを反復して辿ることにより、圧縮解除後の中間出力ストリームを形成する。圧縮解除後の中間出力ストリームは、一時バッファに格納可能である。この説明では、表３Ｂは、ＦＰＧＡ上のＢＲＡＭ又はＵＲＡＭメモリに格納された、又は、ＡＳＩＣ上のデュアルポートＳＲＡＭに格納された２つの単一アドレスのデュアルポートメモリ構造とみなすことができる。各演算の出力は１文字とする。
【0120】
第１の入力ストリームについて実行される反復プロセスの結果として、ＮＵＬＬエントリに逆ポインタとして達するまで逆ポインタのチェーンを辿ることで、各シンボル文字列の非圧縮出力を決定可能であり、この場合、ＮＵＬＬエントリはマルチシンボル文字列の先頭を示す。逆ポインタをトラバースしている間、復号化後の各マルチシンボル文字列の長さは、第３のＢＲＡＭ又はＦＰＧＡの「分散メモリ」であり得る、別個のメモリ配列Ｌに記録されるが、この場合、メモリ配列Ｌ［０］には、第１の文字列の長さ、Ｌ［１］には、第２の文字列の長さといった具合に、文字列の長さが記録される。動作ごとに１つの文字コードが放出される。このように逆ポインタを辿ることで、マルチシンボル文字列は一時キューに前後逆に書き出され、後述するステップＳ１２０４で逆順にされる。
【0121】
本例では、圧縮後の符号「９９、９７、２５６、１１６、２５８」を圧縮解除（）する第１の圧縮後の符号は、圧縮後の符号９９である。表３Ａを見ると、ロケーションａｄｄｒ＝９９は、逆ポインタがＮＵＬＬで、文字コードが「ｃ」であることを示す。これは、１文字コードなので、文字列の長さはＬ［０］＝１である。文字コード「ｃ」が出力されるので、それゆえ、第１の入力ストリームと第１の辞書の一時出力ストリームには、「ｃ」が含まれることになる。
【0122】
次に圧縮解除する圧縮後の符号は、圧縮後の符号９７である。表３Ａを見ると、ロケーションａｄｄｒ＝９７は、逆ポインタがＮＵＬＬで、文字コードが「ａ」であることを示す。文字列の長さはＬ［１］＝１である。文字コード「ａ」が出力されるので、これで、第１の入力ストリームと第１の辞書の一時出力ストリームには、「ｃａ」が含まれることになる。
【0123】
次に圧縮解除する圧縮後の符号は、圧縮後の符号２５６である。ａｄｄｒ＝２５６は表３Ａの最終アドレス（ａｄｄｒ＝２５５）より大きいので、表３Ｂを使用する。表３Ｂを見ると、ロケーションａｄｄｒ＝２５６は、逆ポインタが非ＮＵＬＬで、９９の値を備えることを示している。したがって、アドレス値ｉ＋１（すなわち、２５６＋１＝２５７）の第１の文字コードを読み出して、出力する。ロケーションａｄｄｒ＝２５７は、第１の文字コードが「ａ」であることを示す。ロケーションａｄｄｒ＝２５６の逆ポインタ値９９の後にａｄｄｒ＝９９が続き、これは、逆ポインタがＮＵＬＬで、第２の文字コードが「ｃ」であることを示す。したがって、圧縮後の符号２５６の逆ポインタをＮＵＬＬエントリに達するまで辿ることで、第１の文字コード「ａ」及び第２の文字コード「ｃ」が、マルチシンボル文字列「ａｃ」として出力されることになる。文字コードが２つあるので、この文字列の長さはＬ［２］＝２である。注目すべき点として、圧縮後の符号２５６の２つの文字コードが共に出力されるまで、第１の入力に関する次の圧縮後の符号は、次の反復では途切れのない圧縮後の出力ストリームから読み出されない。これで、第１の入力ストリームと第１の辞書の一時出力ストリームは、「ｃａａｃ」を含むようになった。
【0124】
次に圧縮解除する圧縮後の符号は、圧縮後の符号１１６である。表３Ａを見ると、ロケーションａｄｄｒ＝１１６は、逆ポインタがＮＵＬＬで、文字コードが「ｔ」であることを示す。文字列の長さはＬ［３］＝１である。文字コード「ｔ」が出力されるので、これで、第１の入力ストリームと第１の辞書Ｄ１の一時出力ストリームには、「ｃａａｃｔ」が含まれることになる。
【0125】
次に圧縮解除する圧縮後の符号は、圧縮後の符号２５８である。この場合もやはり、ａｄｄｒ＝２５８は表３Ａの最終アドレスより大きいので、表３Ｂを使用する。表３Ｂを見ると、ロケーションａｄｄｒ＝２５８は、逆ポインタが非ＮＵＬＬで、２５６の値を備えることを示している。したがって、アドレス値ｉ＋１（すなわち、２５８＋１＝２５９）の第１の文字コードを読み出して、出力する。ロケーションａｄｄｒ＝２５９は、第１の文字コードが「ｔ」であることを示す。ロケーションアドレス２５８の２５６の逆ポインタ値がａｄｄｒ＝２５６に続き、これもまた非ＮＵＬＬである（上述のとおり）。したがって、アドレス値ｉ＋１（すなわち、２５６＋１＝２５７）の第２の文字コードを読み出して、出力する。ロケーションａｄｄｒ＝２５７は、第２の文字コードが「ａ」であることを示す。ａｄｄｒ＝２５６の逆ポインタ値９９の後にａｄｄｒ＝９９が続き、この場合、逆ポインタがＮＵＬＬで、文字コードは、第３の文字コードの「ｃ」である。したがって、圧縮後の符号２５８の逆ポインタをＮＵＬＬエントリに達するまで辿ることで、第１の文字コード「ｔ」、第２の文字コード「ａ」及び第３の文字コード「ｃ」が、マルチシンボル文字列「ｔａｃ」として出力される。文字コードが３つあるので、この文字列の長さはＬ［４］＝３である。これで、第１の入力ストリームと第１の辞書の一時出力ストリームは、「ｃａａｃｔｔａｃ」を含むようになった。また、それぞれのサブレングス（sub-length）は、Ｌ［０］＝１、Ｌ［１］＝１、Ｌ［２］＝２、Ｌ［３］＝１、及びＬ［４］＝３である。この情報により、「ｃ」、「ａ」、「ａｃ」、「ｔ」、及び「ｔａｃ」の文字列を逆の順序にして、正しい順序が得られる。
【0126】
ステップＳ１２０４において、一時バッファからの圧縮解除後の中間出力ストリーム中のマルチシンボル文字列の文字コードの順序を逆にすることにより、第１の入力ストリームと第１の辞書の圧縮解除ストリームを形成する。例えば、圧縮後の符号２５６では、「ａｃ」が「ｃａ」となり、圧縮後の符号２５８では、「ｔａｃ」が「ｃａｔ」となる。これは、ハードウェアの構造体が逆ポインタを保持しているため、したがって、複数バイトを符号化する圧縮後のシンボルでは、逆の順序になった文字列を並べ替える必要があるためである。この例では、「ｔａｃ」のような３つの元の文字を符号化するシンボルが、逆方向の３回の動作サイクルにわたって、正しい文字列「ｃ」、次に「ａ」、次に「ｔ」のように放出され、「ｃａｔ」が得られる。それゆえ、ステップ１２０４において、一時バッファのマルチシンボル文字列を繰り返し逆の順序にして、「ｃ」、「ａ」、「ｃａ」、「ｔ」、及び「ｃａｔ」へと到達させ、出力後の非圧縮ストリームを形成する。マルチシンボル文字列は、値が１より大きいそれぞれの長さＬ［ｎ］に従って逆の順序にされる。
【0127】
ハードウェア（例えば、ＦＰＧＡ、又はＡＳＩＣ）では、１回の動作で１文字が放出される。したがって、動作の観点から、ステップＳ１２０１は、ステップＳ１２０３に相当する動作より、１動作先に実行され得る。すなわち、ステップＳ１２０１の演算が完了してから、ステップＳ１２０３に相当する動作を試みる必要がある。なお、ステップＳ１２０３で逆ポインタが辿られるたびに、このマルチシンボル文字列に関する格納済みの長さが増分される。この長さ情報は、ステップＳ１２０４で適用される。
【0128】
長さの値の更新と格納は１回の動作を要するが、ステップＳ１２０３で行う全計算における他の動作と同時に更新することも可能である。いずれにしても、ステップＳ１２０３で逆の順序にされたマルチシンボル文字列の最後の文字が算出されるまでは、長さ配列の情報を使用して、マルチシンボル文字列の最初の逆の順序にされていない文字を放出することはできない。したがって、ステップＳ１２０４は、ステップＳ１２０３の同等の動作の後、少なくとも「Ｌｌｏｎｇｅｓｔ」の動作が発生する。ここで、「Ｌｌｏｎｇｅｓｔ」とは、最も長い長さＬの文字列である。
【0129】
ステップＳ１２０２は、ステップ１２０３の直前で、このステップと重複するパイプラインで実行される。つまり、ステップ１２０３は、入力ストリーム［ｎ－１］を計算し、ステップ１２０２では、入力ストリーム［ｎ］を計算している。すなわち、ステップ１２０２の圧縮後の符号を全て計算してから、ステップ１２０３の同じ圧縮後の符号へと移行する。ステップ１２０４は重複しているが、最長のマルチシンボル文字列の長さで決まるいくつかの演算により遅延する。
【0130】
ハードウェアでは、データを圧縮解除する際に使用するモデルは、キャプチャバッファをスキャンし、データから対象ポイントを検索する。検索時間は、キャプチャ時間ほどタイムクリティカルではないので、必要に応じて、各圧縮解除動作に１クロックサイクル以上かかる場合がある。それゆえ、圧縮解除にかかる時間に対する制約は、圧縮の場合よりも緩和され得る。
【0131】
複数の入力ストリームを並列処理する場合、２５５を超える圧縮後の符号では、圧縮後の文字列がマルチシンボル文字列となるため、圧縮後の文字列の長さを１より長くする必要がある。同様に、逆ポインタを辿る場合、２５５より大きい値は、少なくとももう１文字読まなければならないことを意味する。文字列がまだ十分に復号化されていない場合でも、圧縮後の符号がマルチシンボル文字列であると分かれば、次の動作で入力ストリームの次の圧縮後の符号を読み取るべきではないと判断するのに十分な情報が得られる。その代わりに、次のワイドワード入力を読み取る次の動作では、同じワイドワード入力の次の圧縮後の符号を読み取るのではなく、逆ポインタを辿って、次の動作中に出力すべき次の文字を取得する。つまり、マルチシンボル文字列が作成されると、複数の入力から作成された圧縮後の符号の途切れのない圧縮後のインターリーブされた出力ストリームを読み取り、複数の辞書Ｄｉをアドレス指定する際に考慮する必要のある、１つ以上のＮｏＯｐが存在することになる。
【0132】
要するに、表３Ｂでは、０～２５５の間の値を持つ逆ポインタは、次のシンボルがマルチシンボル文字列の最後であることを示し、さらに、プロセスは、現在の入力ストリームと辞書に関する次の入力圧縮後の符号に進む必要がある。ただし、値が２５５より大きい逆ポインタは、後続の逆ポインタが少なくとも１つあることを示す。次の反復の後、入力ストリームの前ステップの逆ポインタがＮＵＬＬでない場合、圧縮中に別のＮｏＯｐが生成されているので、入力ストリームに関する途切れのない圧縮後の出力ストリーム内の次の圧縮後の符号を読み取るべきではない。そのため、次の圧縮後の符号を読むのではなく、逆ポインタを再び辿って、出力すべき文字コードを抽出する。同様に、後続の逆ポインタも非ＮＵＬＬである場合、出力されるべきマルチシンボル文字列に更に別の文字があることを示している。ただし、逆ポインタがＮＵＬＬの場合、マルチシンボル文字列内の結合されたシンボルは全て抽出されており、プロセスは現在の入力ストリームと辞書の次の入力圧縮後の符号に進む必要がある。
【0133】
ワードサイズの動作を並列に実行する場合、該当入力ストリームの前の圧縮後の符号が単一文字コードで表される限り、各動作「ｉ」で、次の入力ストリームについて、次の文字コードが読み取られる。そうでない場合、入力ストリームの前の文字コードがマルチシンボル文字列であれば、単一の反復「ｉ」の終了を示すワイドワードの同じ入力ストリームに戻るまで、次の代替入力ストリームからの次の文字コード、又は、次の入力ストリームへのスキップのいずれかを優先させて、文字コードの読み取りをスキップするといった具合であり、この場合もやはり、必要に応じて、入力ごとに文字コードが読み込まれるか、又は、入力と辞書ごとにマルチシンボル文字列が出力される。注目すべきは、各入力ストリーム／辞書の組み合わせｉ＝０における最初の文字コードが、常に単一の文字を表すということである。このようにして、圧縮後の出力ストリームの文字コードが、ラウンドロビン方式で読み取られる。
【0134】
図１０と図１１の例では、ワイドワードのワードサイズが２であるため、ペアワイズ（pair-wise：一対単位）方式で反復が行われる。図１３Ａ～図１３Ｃも同様に、代表的な実施形態に係る、圧縮用の複数のワイドワード入力のシンボルを順序付けする例を示しており、ここで、ワイドワードサイズは、２である。
【0135】
図１３Ａを参照すると、圧縮されるべきシリアルストリーム１３２０は、シンボル「ｃｃｂａｃｃｂａｃｔｂｃｃａｄｔ」を含む２つのワイドワードで、１６個のシンボル（バイト）を含む。参照番号１３３０で示すシンボルのシリアルストリームにおける異なる濃淡で示されるように、シリアルストリーム１３２０は、１つおきのシンボルが２つのワイドワードの一方に割り当てられるように配列される。したがって、第１の辞書（Ｄ１）用のシンボル「ｃｂｃｂｃｂｃｄ」を持つ第１の入力ストリーム１３３１と、第２の辞書（Ｄ２）用のシンボル「ｃａｃａｔｃａｔ」を持つ第２の入力ストリーム１３３２とを含む、別々の入力ストリームへの圧縮の観点から、他のシンボルは全て、グループ化される。注目すべきは、第２の入力ストリーム１３３２は、表３Ａ及び表３Ｂを参照して、これまで考察した例示的な第１の入力ストリームと同じであることである。
【0136】
上記の圧縮に関する実施形態に従って、ｃｃ１～ｃｃ８で示される８クロックサイクルで第１の入力ストリーム１３３１及び第２の入力ストリーム１３３２について、並列圧縮を実行する。第１の入力ストリーム１３３１及び第２の入力ストリーム１３３２は、例えば、既知のＡＳＣＩＩテーブルを使用して圧縮され得る。第１の入力ストリーム１３３１を圧縮すると、圧縮後の第１のストリーム１３４１（圧縮後０）が得られ、第２の入力ストリーム１３３２を圧縮すると、圧縮後の第２のストリーム１３４２（圧縮後１）が得られる。図示の例では、圧縮後の第１のストリーム１３４１は圧縮符号「９９、９８、ＮｏＯｐ、２５６、ＮｏＯｐ、ＮｏＯｐ、２５８、１００」を含み、圧縮後の第２のストリーム１３４２は圧縮符号「９９、９７、ＮｏＯｐ、２５６、１１６、ＮｏＯｐ、ＮｏＯｐ、２５８」（前述）を含む。
【0137】
図１３Ｂを参照すると、圧縮後の第１のストリーム１３４１及び第２のストリーム１３４２は、第１の到着シンボルの並び替えに従って並び替えられ、一時バッファに格納されるので、前述のように、マルチシンボル文字列は、複数シンボルのグループ内の第１のシンボルの位置に再配置される。とりわけ、圧縮後の第１のストリーム１３４１では、圧縮後の符号２５６で表されるマルチシンボル文字列を第４の位置から第３の位置に移動して、ＮｏＯｐエントリを右方向に１つシフトし、圧縮後の符号２５８を第７の位置から第５の位置に移動して、ＮｏＯｐエントリを右方向に１つシフトすることで、並べ替えられた圧縮後の第１のストリーム１３４１’（圧縮後０’）が得られる。圧縮後の第２のストリーム１３４２では、圧縮後の符号２５６で表されるマルチシンボル文字列を第４の位置から第３の位置に移動して、ＮｏＯｐエントリを右方向に１つシフトし、圧縮後の符号２５８を第８の位置から第６の位置に移動して、ＮｏＯｐエントリを右方向に１つシフトすることで、並べ替えられた圧縮後の第２のストリーム１３４２’（圧縮後１’）が得られる。注目すべきは、圧縮後の第２のストリーム１３４２の圧縮後の符号２５６及び２５８は、圧縮後の第１のストリーム１３４１の圧縮後の符号２５６及び２５８とは異なる文字コードを含むことである。
【0138】
並び替えられた圧縮後の第１のストリーム１３４１’と圧縮後の第２のストリーム１３４２’から順番にシンボルを交互に入力することで、圧縮後の最終的な出力ストリーム１３５０が形成される。ＮｏＯｐエントリは、この処理から除外されるため、圧縮後の出力ストリーム１３５０は、途切れのないものとなる。したがって、並べ替えられた圧縮後の第１のストリーム１３４１’からの圧縮後の符号２５８は、並べ替えられた圧縮後の第２のストリーム１３４２’からの圧縮後の符号２５６の直後に続き、並べ替えられた圧縮後の第２のストリーム１３４２’からの圧縮後の符号２５８は、並べ替えられた圧縮後の第２のストリーム１３４２’からの圧縮後の符号１１６の直後に続き、さらに、並べ替えられた圧縮後の第１のストリーム１３４１’からの圧縮後の符号１００は、並べ替えられた圧縮後の第２のストリーム１３４２’からの圧縮後の符号２５８の直後に続く。
【0139】
図１３Ｃを参照すると、代表的な実施形態に従って、圧縮後の出力ストリーム１３５０に対する圧縮解除を実行して、圧縮解除後のストリーム１３６０を提供し、圧縮解除後のストリーム１３６０は、図１３Ａで示される元のシリアルストリーム１３２０と一致する。圧縮解除は、図示の構成で左から右への反復的な演算で行われる。圧縮後の出力ストリーム１３５０は、図１３Ｃの上部に示されており、ここで、便宜上、対応するアドレスを有するシンボル及びマルチシンボル文字列を示すブロックは、分けられている。これまで考察したように、対応する文字コード（複数の場合もある）を決定するためのそれぞれの逆ポインタを使用して、一連の反復的な復号化の動作で圧縮解除を実行し、圧縮解除後の中間ストリーム１３５５を形成し、これを一時バッファに格納することができる。圧縮解除後の最終ストリーム１３６０は、圧縮後の出力ストリーム１３５０の各マルチシンボル文字列の文字コードの順序を逆転させることで形成される。
【0140】
便宜上、図１３Ｃの圧縮解除後の中間ストリーム１３５５の全体が示されており、全復号処理（overall decoding process）、及び復号後の文字コードの順序が示されている。ただし、復号後の文字コードを圧縮解除後の最終ストリーム１３６０に入力する次ステップに進む前に、圧縮解除後の中間ストリーム１３５５全体が、必ずしも形成されるとは限らない。つまり、いくつかの実施形態において、圧縮解除後の中間ストリーム１３５５を構築する際、圧縮解除後の中間ストリーム１３５５の復号済み文字コードを、圧縮解除後の最終ストリーム１３６０へと区分的に提示可能であり、これによって、中間の圧縮解除に必要な一時バッファのサイズが削減される。例えば、復号後の各文字コードは、対応する逆ポインタがＮＵＬＬの場合、圧縮解除後の中間ストリーム１３５５から圧縮解除後の最終ストリーム１３６０へと入力可能である。前述のように、ｎｕｌｌ（ヌル）の逆ポインタに到達するには、マルチシンボル文字列の複数の復号化ステップ（及び、圧縮解除後の最終ストリーム１３６０に入力するときの順序の逆転）が必要である。
【0141】
図示の例では、並び替えられた圧縮後の第１のストリーム１３４１’からの圧縮後の符号９９は、ＮＵＬＬへの逆ポインタを持つので、圧縮解除後の中間ストリーム１３５５の先頭位置には文字コード「ｃ」が出力される。並び替えられた圧縮後の第２のストリーム１３４２’からの圧縮後の符号９９は、ＮＵＬＬへの逆ポインタを持つので、圧縮解除後の中間ストリーム１３５５の次位置には文字コード「ｃ」が出力される。並び替えられた圧縮後の第１のストリーム１３４１’からの圧縮後の符号９８は、ＮＵＬＬへの逆ポインタを持つので、圧縮解除後の中間ストリーム１３５５の次位置には文字コード「ｂ」が出力される。並び替えられた圧縮後の第２のストリーム１３４２’からの圧縮後の符号９７は、ＮＵＬＬへの逆ポインタを持つので、圧縮解除後の中間ストリーム１３５５の次位置には文字コード「ａ」が出力される。これらそれぞれの文字列の長さをＬ＝１と表記している。
【0142】
並べ替えられた圧縮後の第１のストリーム１３４１’からの圧縮後の符号２５６は、マルチシンボル文字列「ｂｃ」を提供しており、圧縮後の符号２５６は、文字コード「ｂ」と、文字コードが「ｃ」の９９への逆ポインタと、ＮＵＬＬへの逆ポインタとを持つ。したがって、並び替えられた圧縮後の第１のストリーム１３４１’を伴う次の２回の演算にわたって、文字コード「ｂ」が、圧縮解除後の中間ストリーム１３６０の次位置に出力され、さらに、文字コード「ｃ」が、次の位置をスキップした直後の位置へと出力される。（後述するように、その後、圧縮解除後のストリーム１３６０を形成する際、文字コード「ｂ」と「ｃ」の順序が入れ替わる）。同様に、並べ替えられた圧縮後の第２のストリーム１３４２’からの圧縮後の符号２５６は、マルチシンボル文字列「ａｃ」を提供しており、ここで、圧縮後の符号２５６は、文字コード「ａ」と、文字コードが「ｃ」の９９への逆ポインタと、ＮＵＬＬへの逆ポインタとを持つ。したがって、並び替えられた圧縮後の第２のストリーム１３４２’を伴う次の２回の演算にわたって、文字コード「ａ」が、並び替えられた圧縮後の第１のストリーム１３４１’の圧縮後の符号２５６から、文字コード「ｂ」に続けて、圧縮解除後の中間ストリーム１３５５の次の位置に出力され、さらに、文字コード「ｃ」が、次の位置をスキップした直後の位置へと出力される。これらそれぞれの文字列の長さをＬ＝２と表記している。注目すべきは、復号後の圧縮後の符号が、圧縮解除後の最終ストリーム１３６０に入力され得るタイミングを決定するために、文字列長の値Ｌを使用できることである。
【0143】
次に、並べ替えられた圧縮後の第１のストリーム１３４１’からの圧縮後の符号２５８は、マルチシンボル文字列「ｃｂｃ」を提供しており、ここで、圧縮後の符号２５８は、文字コード「ｃ」と、文字コードが「ｂ」の２５６への逆ポインタと、文字コードが「ｃ」の９９への逆ポインタと、ＮＵＬＬへの逆ポインタとを持つ。したがって、並び替えられた圧縮後の第１のストリーム１３４１’を伴う次の３回の演算にわたって、文字コード「ｃ」が、圧縮解除後の中間ストリーム１３５５の次の位置に出力され、文字コード「ｂ」は、その次の位置をスキップした直後の位置に出力され、さらに、文字コード「ｃ」が、次の位置をスキップした直後の位置へと出力される。一方、並び替えられた圧縮後の第２のストリーム１３４２’からの圧縮後の符号１１６は、ＮＵＬＬへの逆ポインタを持つので、文字コード「ｔ」は、圧縮後の符号２５８から最初に出現した文字コード「ｃ」の次の圧縮解除後の中間ストリーム１３５５の位置に出力される。圧縮後の符号２５８の文字列の長さをＬ＝３、圧縮後の符号１１６の文字列の長さをＬ＝１として示している。
【0144】
最後に、並べ替えられた圧縮後の第２のストリーム１３４２’からの圧縮後の符号２５８は、マルチシンボル文字列「ｔａｃ」を提供しており、圧縮後の符号２５８は、文字コード「ｔ」と、文字コードが「ａ」の２５６への逆ポインタと、文字コードが「ｃ」の９９への逆ポインタと、ＮＵＬＬへの逆ポインタとを持つ。したがって、並び替えられた圧縮後の第２のストリーム１３４２’を伴う次の３回の動作にわたって、文字コード「ｔ」は、並び替えられた圧縮後の第１のストリーム１３４１’の圧縮後の符号２５８から、文字コード「ｂ」に続けて、圧縮解除後の中間ストリーム１３５５の次の位置に出力され、文字コード「ａ」は、次の位置にスキップした直後の位置に出力され、さらに、文字コード「ｃ」は、次の位置をスキップした直後の位置へと出力される。一方、並び替えられた圧縮後の第１のストリーム１３４１’からの圧縮後の符号１００は、ＮＵＬＬへの逆ポインタを持つので、文字コード「ｄ」は、圧縮後の符号２５８からの文字コード「ａ」の次の圧縮解除後の中間ストリーム１３５５の次の位置に出力される。圧縮後の符号２５８の文字列の長さをＬ＝３、圧縮後の符号１００の文字列の長さをＬ＝１として示している。
【0145】
圧縮解除後のストリーム１３６０は、マルチシンボル文字列内のそれぞれの文字コードの順序を逆にすることで、圧縮解除後の中間ストリーム１３５５から形成される。図示の例では、並び替えられた圧縮後の第１のストリーム１３４１’のマルチシンボル文字列は、文字コード「ｂｃ」に関する圧縮後の符号２５６と、文字コード「ｃｂｃ」に関する圧縮後の符号２５８とを含み、さらに、並び替えられた圧縮後の第２のストリーム１３４２’のマルチシンボル文字列は、文字コード「ａｃ」に関する圧縮後の符号２５６と、文字コード「ｔａｃ」に関する圧縮後の符号２５８とを含む。図１３Ｃで見られるように、並び替えられた圧縮後の第１のストリーム１３４１’の圧縮後の符号２５６からの文字コード「ｂｃ」の順序は、圧縮解除後のストリーム１３６０において、「ｃ」の後に「ｂ」という逆の順序（逆順）で受信される。並び替えられた圧縮後の第２のストリーム１３４２’の圧縮後の符号２５６からの文字コード「ａｃ」の順序は、圧縮解除後のストリーム１３６０において、「ｃ」の後に「ａ」という逆順で受信される。並び替えられた圧縮後の第１のストリーム１３４１’の圧縮後の符号２５８からの文字コード「ｃｂｃ」の順序は、圧縮解除後のストリーム１３６０において、「ｃ」の後に「ｂ」、その後に「ｃ」という逆順に受信される。並び替えられた圧縮後の第２のストリーム１３４２’の圧縮後の符号２５８からの文字コード「ｔａｃ」の順序は、圧縮解除後のストリーム１３６０において、「ｃ」の後に「ａ」、その後に「ｔ」という逆順に受信される。
【0146】
完了すると、結果としての圧縮解除後のストリーム１３６０は、図１３Ａで示される元のシリアルストリーム１３２０と同じになる。代替実施形態において、並べ替えられた圧縮後の第１のストリーム１３４１’を起点とする圧縮後の符号を、第１の一時バッファに格納された第１の一時出力ストリーム（マルチシンボル文字列の文字コードを逆順に含む場合もあれば、含まない場合もある）として圧縮解除し、さらに、並べ替えられた圧縮後の第２のストリーム１３４２’を起点とする圧縮後の符号を、第２の一時バッファに格納された第２の一時出力ストリーム（マルチシンボル文字列の文字コードを逆順に含む場合もあれば、含まない場合もある）として圧縮解除する。そして、第１の一時出力ストリーム及び第２の一時出力ストリームから順番にシンボルを交互に入力することにより、圧縮解除後のストリーム１３６０を形成することができる。
【0147】
代替実施形態において、各ＮｏＯｐエントリが次に使用できるマルチシンボル文字列に入れ替えられるバッファリングステップの代わりに、このバッファリングステップは、圧縮後のストリームをまとめる前に全てのＮｏＯｐエントリが削除されるよう、各ＮｏＯｐエントリを削除するだけで、マルチシンボル文字列がＮｏＯｐエントリの場所へとシフトされるプロセスを含む。つまり、マルチシンボルの値は、それぞれのＮｏＯｐ動作の最初の出現位置に移動する。これにより、有利には、複数回の書き込み動作の代わりに、ＮｏＯｐの各エントリに対応する１回の書き込み動作に置き換えられる。
【0148】
図１４は、代表的な実施形態に係る、圧縮解除用の入力のために並べ替えられたワイドワードデータのシンボルを示す。図１４を参照すると、第１の入力ストリーム１４１１を圧縮することで、２つの元の到着シンボルｂ５及びｂ６に相当する圧縮後のマルチシンボル文字列が得られるものと仮定する。従来では、例えば、図８の圧縮後の第１のストリーム８２１で示されているように、この圧縮により、シンボルｂ５の元の位置にＮｏＯｐエントリが配置され、さらに、対応する圧縮後の第１のストリーム内のシンボルｂ６の元の位置にマルチシンボル文字列ｂ５／ｂ６が配置される。しかし、図１４で示す実施形態において、この圧縮動作では、第１の入力ストリーム１４１１に対応する圧縮後の第１のストリーム１４２１からＮｏＯｐエントリを削除し、さらに、マルチシンボル文字列ｂ５／ｂ６を、削除したＮｏＯｐエントリの位置（シンボルｂ５の元の位置）までシフトさせる。この「シフト後のシンボル（shifted symbol）」の並び替えと、入力ストリームの元のサイズの格納を行うことで、キャプチャバッファに格納された圧縮後の出力ストリーム１４３０からシンボルｂ５及びｂ６の元の順序を復元するのに十分な情報が保持される。結合されたマルチシンボル文字列ｂ５／ｂ６が復号化される際、マルチシンボル文字列ｂ５／ｂ６が、第１の辞書Ｄ１に属することも分かっている、第１の入力ストリーム１４１１に関する元の２つの非圧縮シンボルｂ５及びｂ６に相当するかについて、取得されたデータ符号に問い合わせることができる。そのため、順序は守られる。
【0149】
具体的には、図１４は、ワイドワードデータの第１の入力ストリーム１４１１（入力ストリーム０）及び第２の入力ストリーム１４１２（入力ストリーム１）を示し、これらは、圧縮用に以下では提供される。第１の入力ストリーム１４１１及び第２の入力ストリーム１４１２は、図６を参照してこれまで考察した第１の入力ストリーム６３１及び第２の入力ストリーム６３２とそれぞれ対応し得るが、便宜上、シンボルの番号は異なっている。図１４は、第１の入力ストリーム１４１１について算出され、本実施形態に従って並び替えられた（シフト後）圧縮後の第１のストリーム１４２１（圧縮後０）、及び第２の入力ストリーム１４１２について算出された圧縮後の第２のストリーム１４２２（圧縮後１）も更に示す。圧縮後の第１のストリーム１４２１及び第２のストリーム１４２２は、圧縮処理中、データが途切れのない圧縮後の出力ストリーム１４３０としてキャプチャバッファに書き込まれる前の中間ステップにおける動作の順序に相当する。その後の圧縮解除は、圧縮後の出力ストリーム１４３０について、既知の圧縮解除アルゴリズムに従って実行される。最終的な圧縮解除後のストリーム１４４０は、第１の入力ストリーム１４１１の圧縮中に生成されたＮｏＯｐエントリにもかかわらず、正しく順序付けられた圧縮解除後のデータを示している。
【0150】
図示の実施形態によると、ワイドワード用の途切れのない圧縮後の出力ストリーム１４３０は、交互に出現する圧縮後の第１のストリーム１４２１及び第２のストリーム１４２２からの圧縮後の連続シンボルが、ＮｏＯｐエントリなしで互いに続くように圧縮中に書き込まれる。１つ以上のシンボルがマルチシンボル文字列に圧縮される場合には、圧縮後のシンボルは、一時的にバッファリングされてから、ＮｏＯｐエントリの元の位置に作成された場合と同様に、圧縮後のシンボルが出現するよう、先行のＮｏＯｐエントリ位置に放出される。元の到着シンボルを圧縮できない場合には、これらはそれぞれ、正しい動作中に正しい場所に放出されるか、又は、先行するマルチシンボル文字列がシフトされたのと同じエントリ数だけシフトされる。
【0151】
本明細書で説明する例示的なデュアルワイドワードシステムでは（説明をしやすくするため）、圧縮後の出力は常に、第１の入力ストリーム１４１１、次いで、第２の入力ストリーム１４１２のように一対を単位として放出される。第１の入力ストリーム１４１１に対応する圧縮後の第１のストリーム１４２１は、シンボルｂ５の該当位置に書き込まれた圧縮後のマルチシンボル文字列ｂ５／ｂ６を含み、この位置では、ＮｏＯｐエントリ（例えば、図８の圧縮後の第１のストリーム８２１で図示）が削除され、さらに、圧縮後のマルチシンボル文字列ｂ５／ｂ６がシンボルｂ５の位置までシフトされている。圧縮後の第２のストリーム１４２２は、第２の入力ストリーム１４１２の全てのシンボルを含む。
【0152】
圧縮後の出力ストリーム１４３０は、圧縮後の第１のストリーム１４２１と圧縮後の第２のストリーム１４２２との間で交互にシンボルを受信する。注目すべきは、或る入力ストリームの方が他の入力ストリームよりも圧縮が上手くいき、これにより、圧縮後のストリームがもたらされる場合が挙げられる。例えば、第１の入力ストリーム１４１１の圧縮は、第２の入力ストリーム１４１２の圧縮よりも優れており、その結果、圧縮後の第１のストリーム１４２１は、圧縮後の第２のストリーム１４２２よりも短くなる。この場合、圧縮後の第２のストリーム１４２２からのシンボルｂ６及びｂ７が圧縮後の出力ストリーム１４３０の終端で互いに隣接する等のように、圧縮後のストリームの終端に向かって、長いストリームからの圧縮後のシンボルが一緒に配置されることになる。したがって、圧縮後の各ストリームの圧縮後のシンボルの数は、圧縮解除中に追跡され、さらに、その数が圧縮後のストリームの対応する圧縮解除後の入力ストリームの元のサイズに達すると、該当ワイドワードの圧縮解除の残りの部分については、その圧縮後のストリームはスキップされる。
【0153】
図の例では、圧縮後の第１のストリーム１４２１に対応する第１の入力ストリーム１４１１と、第２のストリーム１４２２に対応する第２の入力ストリーム１４１２のそれぞれの元のサイズは、７である。元の入力ストリームのサイズが、ワイドワードストリーム内で正確に収まるように選択されるので、圧縮後のストリーム全てについて、この値は同じである。図の例では、元の入力ストリームが１４となるように選択されているので、第１の入力ストリーム１４１１及び第２の入力ストリーム１４１２（それぞれのサイズは７）は、合計１４となる。一般的に、ｎ％ｗｉｄｅ＿ｗｏｒｄ＝０（すなわち、ページのサイズは、ワイドワードで割り切れる）になるよう、ページのサイズｎは選択される。圧縮解除時では、以下で考察するように、圧縮後の第１のストリーム１４２１及び／又は第２のストリーム１４２２（つまり、第１のストリーム１４２１又は第２のストリーム１４２２あるいはそれらの両方）が、７つの圧縮解除値に達するとすぐに、その圧縮後のストリームが完全に圧縮解除されたことが分かる。
【0154】
圧縮後の第１のストリーム１４２１及び第２のストリーム１４２２からのシンボルを交互に受信することに関して、圧縮後の出力ストリーム１４３０は、圧縮後の第１のストリーム１４２１からシンボルｂ１を、圧縮後の第２のストリーム１４２２からシンボルｂ１を、圧縮後の第１のストリーム１４２１からシンボルｂ２を、圧縮後の第２のストリーム１４２２からシンボルｂ２をといった具合で受信する。このインターリーブ後のプロセスは、圧縮後の第２のストリーム１４２２からシンボルｂ４を受信した後で、圧縮後の第１のストリーム１４２１からマルチシンボル文字列ｂ５／ｂ６を受信することと、圧縮後の第２のストリーム１４２２からシンボルｂ５を受信することと、圧縮後の第１のストリーム１４２１からシンボルｂ７を受信することと、さらに、圧縮後の第２のストリーム１４２２からシンボルｂ７を受信することとを含むように進む。図示の順序では、圧縮解除後のストリーム１４４０（この場合も、円１４３５で示す）で見られるように、元の順序で各辞書のデータを復元可能であり、複数の入力ストリームからワイドワードとしてデータを復元できる。とりわけ、圧縮後の第１のストリーム１４２１からのシンボルｂ６（参照番号１４４１で図示）は、圧縮後の第２のストリーム１４２２からのシンボルｂ５の直後で正しく配置される。
【0155】
「シフト後のシンボル」の並び替え（デインターリーブ）を行うことで、データを正しい順序で再構成するのに必要とされる２つの前提情報を保持することができる。第１に、図示の例では、マルチシンボル文字列ｂ５／ｂ６は、シンボルｂ６の場所ではなく、第１の入力ストリーム１４１１のシンボルｂ５の場所に到着したことが分かっているので、それゆえ、第１の辞書Ｄ１にアドレス指定される。第２に、マルチシンボル文字列ｂ５／ｂ６に関する取得されたデータを調べると、最終的に圧縮されない文字列の長さが、１シンボルを超えることが分かっている。したがって、圧縮後のマルチシンボル文字列ｂ５／ｂ６を復号化して、例えば、圧縮解除ストリーム１４４０を得る場合、その書き込み動作の正しいタイミングが来たら、シンボルｂ５を先に書き出してから、シンボルｂ６を後で書き出すことになる。このようにして、シンボルｂ５とｂ６は共に、圧縮解除後の最終ストリーム１４４０の正しい位置へと書き込まれる。さらに、マルチシンボル文字列ｂ５／ｂ６の最終的な長さは、非圧縮の２つのシンボルであることが分かっているので、圧縮後の出力ストリーム１４３０の次の符号が属する辞書を算出できる。特に、ＦＰＧＡ（又は、ＡＳＩＣ）を用いたハードウェア実装では、以下で考察する逆ポインタ技術により、シンボルが逆の順序にされる。
【0156】
図１５Ａ～図１５Ｃも同様に、代表的な実施形態に係る、圧縮解除用の複数のワイドワード入力のシンボルを順序付けする例を示しており、ここで、ワイドワードサイズは、２である。とりわけ、図１５Ａ～図１５Ｃは、ＮｏＯｐエントリを削除するステップと、後続のマルチシンボル文字列を削除されたＮｏＯｐエントリの位置にまでそれぞれシフトするステップとをより詳細に示している。
【0157】
図１５Ａを参照すると、圧縮されるべきシリアルストリーム１５２０は、シンボル「ｃｃｂａｃｃｂａｃｔｂｃｃａｄｔ」を含む２つのワイドワードで、１６個のシンボル（バイト）を含む。参照番号１５３０で示すシンボルのシリアルストリームにおける異なる濃淡で示されるように、シリアルストリーム１５２０は、１つおきのシンボルが２つのワイドワードの一方に割り当てられるように配列される。したがって、第１の辞書（Ｄ１）用のシンボル「ｃｂｃｂｃｂｃｄ」を持つ第１の入力ストリーム１５３１と、第２の辞書（Ｄ２）用のシンボル「ｃａｃａｔｃａｔ」を持つ第２の入力ストリーム１５３２とを含む、別々の入力ストリームへの圧縮の観点から、他のシンボルは全て、グループ化される。注目すべきは、第２の入力ストリーム１５３２は、上記の表３Ａ及び表３Ｂを参照して、これまで考察した例示的な第１の入力ストリームと同じであることである。
【0158】
上記の圧縮に関する実施形態に従って、ｃｃ１～ｃｃ８で示される８クロックサイクルで第１の入力ストリーム１５３１及び第２の入力ストリーム１５３２について、並列圧縮を実行する。第１の入力ストリーム１５３１及び第２の入力ストリーム１５３２は、例えば、既知のＡＳＣＩＩテーブルを使用して圧縮され得る。第１の入力ストリーム１５３１を圧縮すると、圧縮後の第１のストリーム１５４１（圧縮後０）が得られ、第２の入力ストリーム１５３２を圧縮すると、圧縮後の第２のストリーム１５４２（圧縮後１）が得られる。図示の例では、圧縮後の第１のストリーム１５４１は圧縮符号「９９、９８、ＮｏＯｐ、２５６、ＮｏＯｐ、ＮｏＯｐ、２５８、１００」を含み、圧縮後の第２のストリーム１５４２は圧縮符号「９９、９７、ＮｏＯｐ、２５６、１１６、ＮｏＯｐ、ＮｏＯｐ、２５８」（前述）を含む。
【0159】
図１５Ｂを参照すると、圧縮後の第１のストリーム１５４１及び第２のストリーム１５４２は、シフト後のシンボルの並べ替えに従ってシフトされ、一時バッファに格納される場合も、格納されない場合もあるので、前述のように、マルチシンボル文字列を表す圧縮後の符号は、圧縮中に作成された対応するＮｏＯｐエントリにシフトされる。とりわけ、圧縮後の第１のストリーム１５４１では、第３の位置のＮｏＯｐエントリが削除され、圧縮後の符号２５６が表すマルチシンボル文字列が第４の位置から第３の位置へシフトされる。また、第５の位置と第６の位置のＮｏＯｐエントリは削除され、圧縮後の符号２５８は、第７の位置から第５の位置（すなわち、圧縮後の符号２５８の前の隣接する２つのＮｏＯｐエントリの最初のＮｏＯｐエントリ）にシフトされる。この結果は、並べ替えられた（シフトされた）圧縮後の第１のストリーム１５４１’（圧縮後０’）である。圧縮後の第２のストリーム１５４２では、ＮｏＯｐエントリが第３の位置から削除され、圧縮後の符号２５６で表されるマルチシンボル文字列が第４の位置から第３の位置へとシフトし、第６の位置及び第７の位置のＮｏＯｐエントリが削除され、さらに、圧縮後の符号２５８が第８の位置から第６の位置にシフトすることで、並べ替えられた（シフトされた）圧縮後の第２のストリーム１５４２’（圧縮後１’）が提供される。これは、並べ替えられた圧縮後の第１のストリーム１５４１’及び第２のストリーム１５４２’がバッファに格納されるかどうかに関係なく、バッファリングステップと称されることもある。注目すべきは、圧縮後の第２のストリーム１５４２の圧縮後の符号２５６及び２５８は、圧縮後の第１のストリーム１５４１の圧縮後の符号２５６及び２５８とは異なる文字コードを含み、このことは、こうした圧縮後のストリームの起点となる入力ストリームを追跡し続ける重要な理由である。
【0160】
並び替えられた（シフトされた）圧縮後の第１のストリーム１５４１’と圧縮後の第２のストリーム１５４２’から順番にシンボルを交互に入力することで、圧縮後の最終的な出力ストリーム１５５０が形成される。ＮｏＯｐエントリは事前に削除されているので、圧縮後の出力ストリーム１５５０は途切れのないものである。したがって、並べ替えられた圧縮後の第１のストリーム１５４１’からの圧縮後の符号２５６は、並べ替えられた圧縮後の第２のストリーム１５４２’からの圧縮後の符号９７の直後に続き、並べ替えられた圧縮後の第２のストリーム１５４２’からの圧縮後の符号２５６は、並べ替えられた圧縮後の第１のストリーム１５４１’からの圧縮後の符号２５６の直後に続き、並べ替えられた圧縮後の第１のストリーム１５４１’からの圧縮後の符号２５８は、並べ替えられた圧縮後の第２のストリーム１５４２’からの圧縮後の符号２５６の直後に続き、さらに、並べ替えられた圧縮後の第２のストリーム１５４２’からの圧縮後の符号２５８は、並べ替えられた圧縮後の第１のストリーム１５４１’からの圧縮後の符号１００の直後に続く。異なるバッファリングステップにより、圧縮後の最終的なストリーム１５５０は、上述した図１３Ｂで見られる実施形態の圧縮後の最終的な出力ストリーム１３５０とは異なるものである。
【0161】
図１５Ｃを参照すると、代表的な実施形態に従って、圧縮後の出力ストリーム１５５０に対する圧縮解除を実行して、圧縮解除後のストリーム１５６０を提供し、ここで、圧縮解除後のストリーム１５６０は、図１５Ａで示される元のシリアルストリーム１５２０と一致する。圧縮解除は、図示の構成で左から右への反復的な演算で行われる。圧縮後の出力ストリーム１５５０は、図１５Ｃの上部に示されており、ここで、便宜上、シンボル及びマルチシンボル文字列、並びに対応するアドレス及びパラメータを示すブロックは、分けられている。これまで考察したように、対応する文字コード（複数の場合もある）を決定するためのそれぞれの逆ポインタを使用して、一連の反復的な復号化動作で圧縮解除を実行し、圧縮解除後の中間ストリーム１５５５を形成し、これを全て、又は一部を一時バッファに格納することができる。圧縮解除後の最終ストリーム１５６０は、圧縮後の出力ストリーム１５５０の各マルチシンボル文字列の文字コードの順序を逆転させることで形成される。
【0162】
圧縮解除後の中間ストリーム１５５５を決定する際、圧縮後の符号のそれぞれと関連付けて、アドレス情報、及びパラメータを更新する。アドレス情報には、圧縮解除後のストリーム１５６０に含まれる現在の圧縮後の符号のアドレス（ａｄｒ）が含まれる。パラメータには、圧縮後の符号内の圧縮後のシンボルの数で決まるその圧縮後の符号の長さ（Ｌ）、ワイドワード内の入力ストリームの数であるワイドワード（ｗ）、並びに、現在の圧縮後の符号が圧縮解除される圧縮解除処理の時点における同一入力ストリームからの圧縮解除後のシンボルの累積数を示す圧縮解除値（ｄｃ）が含まれる。同じ入力ストリームを起点とする次の圧縮後の符号の次のアドレスは、現在のアドレス（ａｄｒ＋Ｌｗ）に長さ（Ｌ）とワイドワード（ｗ）との積を加算して計算される。同じ入力ストリームに関する次の圧縮解除値は、現在の圧縮解除値（ｄｃ＋Ｌ）に長さ（Ｌ）を加算して計算される。
【0163】
便宜上、図１５Ｃの圧縮解除後の中間ストリーム１５５５の全体が示されており、全復号プロセス、及び復号後の文字コードの順序が示されている。ただし、復号後の文字コードを圧縮解除後の最終ストリーム１５６０に入力する次ステップに進む前に、圧縮解除後の中間ストリーム１５５５全体が、必ずしも形成されるとは限らない。つまり、いくつかの実施形態において、圧縮解除後の中間ストリーム１５５５を構築する際、圧縮解除後の中間ストリーム１５５５の復号済み文字コードを、圧縮解除後の最終ストリーム１５６０へと区分的に提示可能であり、これによって、中間の圧縮解除に必要な一時バッファのサイズが削減される。例えば、復号後の各文字コードは、対応する逆ポインタがＮＵＬＬの場合、圧縮解除後の中間ストリーム１５５５から圧縮解除後の最終ストリーム１５６０へと入力可能である。前述のように、ｎｕｌｌの逆ポインタに到達するには、マルチシンボル文字列の複数の復号化ステップ（及び、圧縮解除後の最終ストリーム１５６０に入力するときの順序の逆転）が必要である。
【0164】
また、圧縮解除では、並べ替えられた圧縮後の第１のストリーム１５４１’及び第２のストリーム１５４２’のそれぞれについて、部分的に出力する必要はない。圧縮解除では、アドレスを使用して、圧縮解除後の文字列が最終的に出力される圧縮解除後のストリーム１５６０に含まれる位置を追跡し続けることで、必要なバッファメモリの量が削減され、さらに、個別に形成されたインターリーブステップとして、圧縮解除後の中間ストリーム１５５５が効果的に削除され得る。アドレスはワイドワードのサイズ（例えば、本例では２）の配列で追跡され、各ストリームは効果的に独立して圧縮解除されるので、圧縮解除処理は並列に実行できる。並び替えられた圧縮後の第１のストリーム１５４１’及び第２のストリーム１５４２’の最終位置は、それらが復号化される際に既知であるので、圧縮後の出力ストリーム１５５０がまだ完全に復号されていないときであっても、圧縮解除後の最終ストリーム１５６０の最初のいくつかの復号化文字を出力することができる。マルチシンボル文字列は、圧縮解除後のストリーム１５６０に提供されるべき復号化後の文字コードの順序を逆にするために、圧縮解除中に一時的に格納される必要があり、その後、必要に応じて、マルチシンボル文字列をストレージから削除することができる。
【0165】
とりわけ、図示の例を参照すると、並び替えられた圧縮後の第１のストリーム１５４１’からの圧縮後の符号９９は、ＮＵＬＬへの逆ポインタを持つので、圧縮解除後の中間ストリーム１５５５の第１の位置には、文字コード「ｃ」が、対応するアドレス情報、及びパラメータと共に出力される。図に示すように、圧縮後の符号９９のアドレスは、これが圧縮解除後のストリーム１５６０の圧縮解除後の第１のシンボルであるため、０（ａｄｒ［０］＝０）であり、圧縮後の符号９９の長さは、これが圧縮後の１のシンボルに相当するため、１（Ｌ＝１）であり、さらに、圧縮後の符号９９の圧縮解除値は、これまで圧縮解除されたシンボルがないため、０（ｄｃ［０］＝０）である。第１の入力ストリーム１５３１を起点とする次の圧縮解除後のシンボルの次のアドレスは、２であり、この値は、圧縮後の符号９９の長さ（Ｌ）とワイドワードのサイズ（ｗ）との積を、圧縮後の符号９９の現在のアドレスに加算したもの（ａｄｒ［０］＋Ｌ＊ｗ＝０＋（１＊２）＝２）で求められる。また、これまでの第１の入力ストリーム１５３１から圧縮解除したシンボルの累積数を示す次の圧縮解除値（ｄｃ）は、１であり、この値は、現在の符号９９の圧縮解除値に長さ（Ｌ）の値を加算して求められる（ｄｃ［０］＋Ｌ＝０＋１＝１）。次の圧縮解除値を元の第１の入力ストリーム１５１１のシンボルの総数（８）と比較して、並び替えられた圧縮後の第１のストリーム１５４１’が完全に圧縮解除されたか否かを判断する。この場合、次の圧縮解除値は１であり、１は８未満であるため、圧縮後の第１のストリーム１５４１’の圧縮解除は、ここでは停止しない。
【0166】
並び替えられた圧縮後の第２のストリーム１５４２’からの圧縮後の符号９９は、ＮＵＬＬへの逆ポインタを持つので、圧縮解除後の中間ストリーム１５５５の次位置には、文字コード「ｃ」が、対応するアドレス情報、及びパラメータと共に出力される。つまり、圧縮後の符号９９のアドレスは、これが圧縮解除後のストリーム１５６０の圧縮解除後の第２のシンボルであるため、１（ａｄｒ［１］＝１）であり、圧縮後の符号９９の長さは、これが圧縮後の１シンボルに相当するため、１（Ｌ＝１）であり、さらに、並び替えられた圧縮後の第２のストリーム１５４２’について、これまで圧縮解除されたシンボルはないため、圧縮後の符号の圧縮解除値９９は、０（ｄｃ［１］＝０）である。第２の入力ストリーム１５３２を起点とする次の圧縮解除後のシンボルの次のアドレスは、３であり、この値は、圧縮後の符号９９の長さ（Ｌ）とワイドワードのサイズ（ｗ）との積を、圧縮後の符号９９の現在のアドレスに加算したもの（ａｄｒ［１］＋Ｌ＊ｗ＝１＋（１＊２）＝３）で求められる。第２の入力ストリーム１５３２から圧縮解除したシンボルの累積数を示す次の圧縮解除値（ｄｃ）は、１であり、この値は、現在の符号９９の圧縮解除値に長さ（Ｌ）の値を加算して求められる（ｄｃ［１］＋Ｌ＝０＋１＝１）。次の圧縮解除値を元の第２の入力ストリーム１５１２のシンボルの総数（８）と比較して、並び替えられた圧縮後の第２のストリーム１５４２’が完全に圧縮解除されたか否かを判断する。この場合、次の圧縮解除値は１であり、１は８未満であるため、圧縮後の第２のストリーム１５４２’の圧縮解除は、ここでは停止しない。
【0167】
並び替えられた圧縮後の第１のストリーム１５４１’からの圧縮後の符号９８は、ＮＵＬＬへの逆ポインタを持つので、圧縮解除後の中間ストリーム１５５５の次位置には文字コード「ｂ」が出力される。対応するアドレス情報は、ａｄｒ［０］＝２を含み（これは、以前に、並び替えられた圧縮後の第１のストリーム１５４１’からの先行する圧縮後の符号９９で更新されている）、そして、対応するパラメータは、Ｌ＝１、及びｄｃ［０］＝１である（これは、以前に、並び替えられた圧縮後の第１のストリーム１５４１’から先行する圧縮後の符号９９で更新されている）。その後、アドレスａｄｒ［０］は、次の値で更新され、ａｄｒ［０］＋Ｌｗ＝２＋（１＊２）＝４となる。圧縮解除後の値ｄｃ［０］も、次の値で更新され、ｄｃ［０］＋Ｌ＝１＋１＝２となるが、これは８未満なので、圧縮後の第１のストリーム１５４１’の圧縮解除は停止しない。同様に、並び替えられた圧縮後の第２のストリーム１５４２’からの圧縮後の符号９７は、ＮＵＬＬへの逆ポインタを持つので、圧縮解除後の中間ストリーム１５５５の次位置には文字コード「ａ」が出力される。対応するアドレス情報は、ａｄｒ［１］＝３を含み（これは、以前に、並び替えられた圧縮後の第２のストリーム１５４２’からの先行する圧縮後の符号９９で更新されている）、そして、対応するパラメータは、Ｌ＝１、及びｄｃ［１］＝１である（これは、以前に、並び替えられた圧縮後の第２のストリーム１５４２’から先行する圧縮後の符号９９で更新されている）。その後、アドレスａｄｒ［１］は、更新されて、ａｄｒ［１］＋Ｌｗ＝５となる。圧縮解除後の値ｄｃ［１］も、次の値で更新され、ｄｃ［１］＋Ｌ＝２となるが、これは８未満なので、圧縮後の第２のストリーム１５４２’の圧縮解除は停止しない。
【0168】
並べ替えられた圧縮後の第１のストリーム１５４１’からの圧縮後の符号２５６は、次にマルチシンボル文字列「ｂｃ」を提供しており、圧縮後の符号２５６は、文字コード「ｂ」と、文字コードが「ｃ」の９９への逆ポインタと、ＮＵＬＬへの逆ポインタとを持つ。そのため、文字コード「ｂ」と「ｃ」がそれぞれ出力され、その後、圧縮解除後のストリーム１５６０に書き込まれる際、位置が逆になる。対応するアドレス情報は、ａｄｒ［０］＝４を含み、次いで、これを８に更新する。対応するパラメータは、Ｌ＝２、及びｄｃ［０］＝２であり、次いで、これを４に更新する。圧縮後の符号２５６には、第１の入力ストリーム１５３１の２つのシンボルからの２つの文字コード（「ｂｃ」）が含まれているので、長さ（Ｌ）は２である。ａｄｒ［０］＋Ｌｗ＝４＋（２＊２）＝８に従って、アドレス（ａｄｒ［０］）を８に更新する。ｄｃ［０］＋Ｌ＝２＋２＝４に従って、圧縮解除後の値（ｄｃ［０］）を４に更新し、これは、第１の入力ストリーム１５３１からの４つのシンボル（「ｃｂｃｂ」）が復号化されることになる。４は８未満であるため、並べ替えられた圧縮後の第１のストリーム１５４１’の圧縮解除は停止しない。
【0169】
同様に、並べ替えられた圧縮後の第２のストリーム１５４２’からの圧縮後の符号２５６は、マルチシンボル文字列「ａｃ」を提供しており、圧縮後の符号２５６は、文字コード「ａ」と、文字コードが「ｃ」の９９への逆ポインタと、ＮＵＬＬへの逆ポインタとを持つ。そのため、文字コード「ａ」と「ｃ」がそれぞれ出力され、その後、圧縮解除後のストリーム１５６０に書き込まれる際、位置が逆になる。対応するアドレス情報は、ａｄｒ［１］＝５を含み、これを９に更新する。対応するパラメータは、Ｌ＝２、及びｄｃ［１］＝２であり、これを４に更新する。圧縮後の符号２５６には、第２の入力ストリーム１５３２の２つのシンボルからの２つの文字コード（「ａｃ」）が含まれているので、長さ（Ｌ）は２である。ａｄｒ［１］＋Ｌｗ＝５＋（２＊２）＝９に従って、アドレス（ａｄｒ［１］）を９に更新する。ｄｃ［１］＋Ｌ＝２＋２＝４に従って、圧縮解除後の値（ｄｃ［１］）を４に更新し、これは、第２の入力ストリーム１５３２からの４つのシンボル（「ｃｃａｃａ」）が復号化されることを示す。４は８未満であるため、並べ替えられた圧縮後の第２のストリーム１５４２’の圧縮解除は停止しない。
【0170】
次に、並べ替えられた圧縮後の第１のストリーム１５４１’からの圧縮後の符号２５８は、マルチシンボル文字列「ｃｂｃ」を提供しており、圧縮後の符号２５８は、文字コード「ｃ」と、文字コードが「ｂ」の２５６への逆ポインタと、文字コードが「ｃ」の９９への逆ポインタと、ＮＵＬＬへの逆ポインタとを備える。そのため、文字コード「ｃ」、「ｂ」及び「ｃ」がそれぞれ出力され、その後、圧縮解除後のストリーム１５６０に書き込まれる際、位置が逆になる。対応するアドレス情報は、ａｄｒ［０］＝８を含み、次いで、これを１４に更新し、さらに、対応するパラメータは、Ｌ＝３、及びｄｃ［０］＝４であり、これを７に更新する。圧縮後の符号２５８には、第１の入力ストリーム１５３１の３つのシンボルからの３つの文字コード（「ｃｂｃ」）が含まれているので、長さ（Ｌ）は３である。ａｄｒ［０］＋Ｌｗ＝８＋（３＊２）＝１４に従って、アドレスを１４に更新する。ｄｃ［０］＋Ｌ＝４＋３＝７に従って、圧縮解除後の値（ｄｃ［０］）を７に更新し、これは、第１の入力ストリーム１５３１からの７つのシンボル（「ｃｂｃｂｃｂｃ」）が復号化されることを示す。７は８未満であるため、並べ替えられた圧縮後の第１のストリーム１５４１’の圧縮解除は停止しない。
【0171】
次に、並び替えられた圧縮後の第２のストリーム１５４２’からの圧縮後の符号１１６は、ＮＵＬＬへの逆ポインタを持つので、圧縮解除後の中間ストリーム１５５５の次位置には、文字コード「ｔ」が、対応するアドレス情報、及びパラメータと共に出力される。つまり、対応するアドレス情報は、ａｄｒ［１］＝９を含み、次いで、これを１１に更新し、さらに、対応するパラメータは、Ｌ＝１、及びｄｃ［１］＝４であり、次いで、これを５に更新する。ａｄｒ［１］＋Ｌｗ＝９＋（１＊２）＝１１に従って、アドレス（ａｄｒ［１］）を１１に更新する。ｄｃ［１］＋Ｌ＝４＋１＝５に従って、圧縮解除後の値（ｄｃ［１］）を５に更新し、これは、第２の入力ストリーム１５３２からの５つのシンボル（「ｃａｃａｔ」）が復号化されることを示す。５は８未満であるため、並べ替えられた圧縮後の第２のストリーム１５４２’の圧縮解除は停止しない。
【0172】
次に、並び替えられた圧縮後の第１のストリーム１５４１’からの圧縮後の符号１００は、ＮＵＬＬへの逆ポインタを持つので、圧縮解除後の中間ストリーム１５５５の次位置には、文字コード「ｄ」が、対応するアドレス情報、及びパラメータと共に出力される。つまり、対応するアドレス情報は、ａｄｒ［０］＝１４を含み、さらに、対応するパラメータは、Ｌ＝１、及びｄｃ［０］＝７であり、次いで、これを８に更新する。ｄｃ［０］＋Ｌ＝７＋１＝８に従って、圧縮解除後の値（ｄｃ［０］）を８に更新し、これは、第１の入力ストリーム１５３１からの８つのシンボル（「ｃｂｃｂｃｂｃｄ」）全てが復号化されることを示す。それゆえ、ｄｃ［０］は８に等しいので、並べ替えられた圧縮後の第１のストリーム１５４１’の圧縮解除は停止する。これで、並び替えられた圧縮後の第１のストリーム１５４１’の圧縮解除が完了したので、並び替えられた次の圧縮後の第１のストリームの圧縮解除を開始するために、アドレス（ａｄｒ［０］）を０に更新する。
【0173】
最後に、並べ替えられた圧縮後の第２のストリーム１５４２’からの圧縮後の符号２５８は、マルチシンボル文字列「ｔａｃ」を提供しており、圧縮後の符号２５８は、文字コード「ｔ」と、文字コードが「ａ」の２５６への逆ポインタと、文字コードが「ｃ」の９９への逆ポインタと、ＮＵＬＬへの逆ポインタとを備える。そのため、文字コード「ｔ」、「ａ」及び「ｃ」がそれぞれ出力され、その後、圧縮解除後のストリーム１５６０に書き込まれる際、位置が逆になる。対応するアドレス情報は、ａｄｒ［１］＝１１を含み、さらに、対応するパラメータは、Ｌ＝３、及びｄｃ［１］＝５であり、次いで、これを８に更新する。圧縮後の符号２５８には、第２の入力ストリーム１５３２の３つのシンボルからの３つの文字コード（「ｔａｃ」）が含まれているので、長さ（Ｌ）は３である。圧縮解除後の値（ｄｃ［１］）を８に更新し、これは、第２の入力ストリーム１５３２からの８つのシンボル（「ｃａｃａｔｃａｔ」）全てが復号化されることを示す。それゆえ、ｄｃ［１］は８に等しいため、並べ替えられた圧縮後の第２のストリーム１５４２’の圧縮解除は停止する。これで、並び替えられた圧縮後の第２のストリーム１５４２’の圧縮解除が完了したので、並び替えられた次の圧縮後の第２のストリームの圧縮解除を開始するために、アドレス（ａｄｒ［１］）を０に更新する。
【0174】
これまで考察したように、圧縮解除後のストリーム１５６０は、マルチシンボル文字列内のそれぞれの文字コード順を逆にすることで、圧縮解除後の中間ストリーム１５５５から形成される。文字コードの順序を逆にして、圧縮解除ストリーム１５６０を作成することは、反復的な圧縮解除プロセス中に行ってもよいし、又は、圧縮解除後の中間ストリーム１５５５が完成した後に行ってもよい。最終的な結果は、図１５Ｃで見られるとおりであり、並び替えられた圧縮後の第１のストリーム１５４１’の圧縮後の符号２５６からの文字コード「ｂｃ」の順序は、圧縮解除後のストリーム１５６０において、「ｃ」の後に「ｂ」という逆順で受信される。並び替えられた圧縮後の第２のストリーム１５４２’の圧縮後の符号２５６からの文字コード「ａｃ」の順序は、圧縮解除後のストリーム１５６０において、「ｃ」の後に「ａ」という逆順で受信される。並び替えられた圧縮後の第１のストリーム１５４１’の圧縮後の符号２５８からの文字コード「ｃｂｃ」の順序は、圧縮解除後のストリーム１５６０において、「ｃ」の後に「ｂ」、その後に「ｃ」という逆順で受信される。並び替えられた圧縮後の第２のストリーム１５４２’の圧縮後の符号２５８からの文字コード「ｔａｃ」の順序は、圧縮解除後のストリーム１５６０において、「ｃ」の後に「ａ」、その後に「ｔ」という逆順で受信される。
【0175】
完了すると、結果としての圧縮解除後のストリーム１５６０は、図１５Ａで示される元のシリアルストリーム１５２０と同じになる。代替実施形態において、並べ替えられた圧縮後の第１のストリーム１５４１’を起点とする圧縮後の符号を、第１の一時バッファに格納された第１の一時出力ストリーム（マルチシンボル文字列の文字コードを逆順に含む場合もあれば、含まない場合もある）として圧縮解除し、さらに、並べ替えられた圧縮後の第２のストリーム１５４２’を起点とする圧縮後の符号を、第２の一時バッファに格納された第２の一時出力ストリーム（マルチシンボル文字列の文字コードを逆順に含む場合もあれば、含まない場合もある）として圧縮解除する。そして、第１の一時出力ストリーム及び第２の一時出力ストリームから順番にシンボルを交互に入力することにより、圧縮解除後のストリーム１５６０を形成することができる。
【0176】
図１６は、代表的な実施形態に係る、データリンクを介したワイドワードデータの通信中、圧縮解除後のワイドワードデータを提供する方法を示す簡略流れ図である。この方法は、高速階層型パケットベースのプロトコルに準拠するデータリンクを介したデータの通信中に、機能を損なうことなく、かつ解析で利用できる情報を失うことなく、インターポーザ回路のキャプチャバッファに格納されるデータ量を削減する。図１６の様々なステップは、上述のインターポーザ回路１２０、及び／又はＵＩコンピュータ１１０（つまり、インターポーザ回路１２０、又はＵＩコンピュータ１１０、あるいはそれらの両方）で実行可能であり、従来のソリューションに付随する複雑な配線及び信号完全性の問題を解消し、総コストを削減するとともに、例えば、高帯域インタフェース（及びより少ない生データ）を使用して、アップロード時間の高速化をサポートする。これまで考察した図１３Ａ～図１３Ｃは、図１６で示される方法の一例を示す。
【0177】
図１６を参照すると、ブロックＳ１６０１において、圧縮されるべきシリアルストリームを、シリアルストリーム中の複数のワイドワードに対応する複数の入力ストリームに分割する。各入力ストリームは、所定数のシンボルを含む。
【0178】
ブロックＳ１６０２において、複数の入力ストリームに対して並列圧縮を実行して、対応する圧縮後のストリームを得る。圧縮後の各ストリームは、複数の圧縮後の符号を含み、各圧縮後の符号は、少なくとも１つの文字コード及び少なくとも１つの逆ポインタを含む。圧縮後のストリームの中には、複数の文字コードを有するマルチシンボル文字列と、そのマルチシンボル文字列に対応する少なくとも１つのＮｏＯｐエントリとを含む少なくとも１つの圧縮後の符号を有する。図８を参照して上述したように、各マルチシンボル文字列は、入力ストリーム中の２つ以上の元の入力シンボルを表す圧縮後の符号を示し、さらに、ＮｏＯｐエントリは、対応するマルチシンボル文字列に含まれる圧縮後のストリーム中の最初の、又は、次に圧縮される任意の元の入力シンボルの位置を効率良く取る。マルチシンボル文字列が２つを超える入力シンボルからの圧縮後の符号を含む場合には、圧縮後のストリームの入力シンボルの最後の位置を除く全ての位置にＮｏＯｐエントリが出現する。
【0179】
ブロックＳ１６０３において、圧縮後のストリームは、それぞれ、第１の到着シンボル並べ替え処理で並べ替えられ、並べ替えられた複数の圧縮後のストリームを形成する。少なくとも１つのマルチシンボル文字列を有する圧縮後のストリームごとに、各マルチシンボル文字列は、そのマルチシンボル文字列の第１のシンボルの位置まで移動し、対応するＮｏＯｐエントリ（複数の場合もある）は、第１のシンボルの位置からシフトする。つまり、記録された圧縮後のストリームにおいて、マルチシンボル文字列の位置がＮｏＯｐエントリ（複数の場合もある）の前に来るように、マルチシンボル文字列とＮｏＯｐエントリ（複数の場合もある）の位置が切り替わる。
【0180】
ブロックＳ１６０４では、ＮｏＯｐエントリを除いて、並び替えられた圧縮後のストリームから圧縮後の符号を交互に入力することにより、途切れのない圧縮後の出力ストリームが形成される。例えば、ワイドワードが２つある場合には、２つの並べ替えられた圧縮後のストリームからの圧縮後の符号同士をそれぞれ交互に配置することで、途切れのない圧縮後の出力ストリームが形成される。例えば、ワイドワードが４つある場合には、４つの並べ替えられた圧縮後のストリームからの圧縮後の符号を通じてそれぞれ反復的に循環させることで、途切れのない圧縮後の出力ストリームが形成される。
【0181】
ブロックＳ１６０５において、並べ替えられた異なる圧縮後のストリームから、途切れのない圧縮後の出力ストリーム内の圧縮後の符号を反復的に受信することによって、圧縮後の出力ストリームの圧縮解除を開始する。圧縮後の符号はそれぞれ、少なくとも１つの文字コードと、少なくとも１つの逆ポインタとを含む。少なくとも１つのマルチシンボル文字列を含む圧縮後のストリームにおいて、各マルチシンボル文字列は、それぞれ複数の文字コード、及び複数の逆ポインタを含む。
【0182】
ブロックＳ１６０６において、圧縮後の符号の逆ポインタをそれぞれ辿って、圧縮後の様々なストリームからの圧縮後の符号を反復的に復号化することによって、圧縮解除後の中間ストリームは形成される。すなわち、ＮＵＬＬエントリに達して、少なくとも１つの文字コードが得られるまで、各圧縮後の符号の少なくとも１つの逆ポインタを辿ることで、圧縮後の符号の復号化を実施する。圧縮後の符号がＮＵＬＬエントリを指す逆ポインタを１つ含む場合には、圧縮後の符号は、１文字コードを含む。圧縮後の符号が複数の逆ポインタを含み、その最後の逆ポインタがＮＵＬＬエントリを指す場合には、圧縮後の符号は、それぞれ複数の文字コードを含み、圧縮後の符号は、マルチシンボル文字列を含む。
【0183】
ブロックＳ１６０７において、圧縮後のストリームのそれぞれから各マルチシンボル文字列の文字コードの順序を逆転させることにより、圧縮解除された中間ストリームから圧縮解除されたストリームが形成される。残りの文字コードの順序は変わらない。圧縮解除後のストリームは、更なる処理と解析のために出力される。例えば、これまで考察したように、圧縮解除後のストリームは、ＵＩコンピュータ１１０に出力可能であり、このＵＩコンピュータは、高速データプロトコルに従って、データを解析するためのプロトコルアナライザを圧縮解除後のストリームに適用する。
【0184】
図１７Ａ及び図１７Ｂは、代表的な実施形態に係る、データリンクを介したワイドワードデータの通信中、圧縮解除後のワイドワードデータを提供する方法を示す簡略流れ図である。この方法では、高速階層型パケットベースのプロトコルに準拠するデータリンクを介したデータの通信中、機能を損なうことなく、かつ解析で利用できる情報を失うことなく、インターポーザ回路のキャプチャバッファに格納されるデータ量を削減可能である。図１７Ａ及び図１７Ｂの様々なステップは、上述のインターポーザ回路１２０、及び／又はＵＩコンピュータ１１０で実行可能であり、従来のソリューションに付随する複雑な配線及び信号完全性の問題を解消し、総コストを削減するとともに、例えば、高帯域インタフェース（及びより少ない生データの）を使用して、アップロード時間の高速化をサポートする。これまで考察した図１５Ａ～図１５Ｃは、図１７Ａ及び図１７Ｂで示される方法の一例を示す。
【0185】
図１７Ａを参照すると、ブロック１７０１において、圧縮されるべきデータのシリアルストリームを、シリアルストリーム中の複数のワイドワードに対応する複数の入力ストリームに分割する。各入力ストリームは、所定数のシンボルを含む。
【0186】
ブロックＳ１７０２において、複数の入力ストリームに対して並列圧縮を実行して、対応する圧縮後のストリームを得る。圧縮後の各ストリームは、複数の圧縮後の符号を含み、各圧縮後の符号は、少なくとも１つの文字コード及び少なくとも１つの逆ポインタを含む。圧縮後のストリームの中には、複数の文字コードを有するマルチシンボル文字列と、そのマルチシンボル文字列に対応する少なくとも１つのＮｏＯｐエントリとを含む少なくとも１つの圧縮後の符号を有するものがある。図８を参照して上述したように、各マルチシンボル文字列は、入力ストリーム中の２つ以上の元の入力シンボルを表す圧縮後の符号を示し、さらに、ＮｏＯｐエントリは、対応するマルチシンボル文字列に含まれる圧縮後のストリーム中の最初の元の入力シンボルの位置を効率よく得る。マルチシンボル文字列が２つを超える入力シンボルからの圧縮後の符号を含む場合には、圧縮後のストリームの入力シンボルの最後の位置を除く全ての位置にＮｏＯｐエントリが出現する。
【0187】
ブロックＳ１７０３では、該当する圧縮後のストリーム内の各ＮｏＯｐエントリを削除し、削除された各ＮｏＯｐエントリに続く複数の圧縮後の符号のうち任意の圧縮後の符号を、削除されたＮｏＯｐエントリの位置までシフトさせることによって、複数の圧縮後ストリームにおける各圧縮後ストリームを並べ替える。例えば、ＮｏＯｐエントリを１つ削除すると、圧縮後のストリーム中のＮｏＯｐエントリに続く圧縮後の符号は全て、削除されたＮｏＯｐエントリの方向に１つシフトして、並べ替えられた対応する圧縮後のストリームが形成される。隣接する２つのＮｏＯｐエントリを削除すると、圧縮後のストリーム中のＮｏＯｐエントリに続く圧縮後の符号は全て、削除されたＮｏＯｐエントリの方向に２つシフトして、並べ替えられた対応する圧縮後のストリームが形成されるといった具合である。
【0188】
ブロックＳ１７０４において、並べ替えられた複数の圧縮後のストリームから圧縮後の符号を反復的に入力することで（削除されたＮｏＯｐエントリがない場合）、途切れのない圧縮後の出力ストリームが形成される。例えば、ワイドワードが２つある場合、２つの並べ替えられた圧縮後のストリームからの圧縮後の符号同士をそれぞれ交互に配置することで、途切れのない圧縮後の出力ストリームが形成される。例えば、ワイドワードが４つある場合、４つの並べ替えられた圧縮後のストリームからの圧縮後の符号を通じてそれぞれ反復的に循環させることで、途切れのない圧縮後の出力ストリームが形成される。並べ替えられた圧縮後のストリームの圧縮後の符号の数が異なる場合、並べ替えられた圧縮後の長い方のストリームの末尾に追加された圧縮後の符号が、途切れのない圧縮後の出力ストリームの末尾に隣接して提供される。
【0189】
ブロックＳ１７０５では、途切れのない圧縮後の出力ストリームの圧縮解除が実行される。一般的に、この圧縮解除は、並び替えられたそれぞれの圧縮後のストリームに従って、途切れのない圧縮後の出力ストリームから圧縮後の符号を反復的に復号化して、対応する文字コードを取得することと、マルチシンボルを含む圧縮後の符号から取得された文字コードの順序を逆にすることと、取得された文字コードから圧縮解除されたストリームを構築することとにより、並列に実行される。図１７Ｂを参照して、圧縮解除を実行するプロセスについて詳細に検討する。圧縮解除後のストリームは、更なる処理と解析のために出力される。例えば、これまで考察したように、圧縮解除後のストリームは、ＵＩコンピュータ１１０に出力可能であり、このＵＩコンピュータは、高速データプロトコルに従って、データを解析するためのプロトコルアナライザを圧縮解除後のストリームに適用する。
【0190】
図１７Ｂは、図１７ＡのブロックＳ１７０５で示される圧縮解除プロセスの例示的実施態様である。図１７Ｂを参照すると、ブロックＳ１７５１～Ｓ１７５６は、圧縮後の出力ストリーム内の圧縮後の符号ごとに、圧縮解除後のストリーム内の現在のアドレス（ａｄｒ）で実行される。ブロックＳ１７５１では、途切れのない圧縮後の出力ストリームにおいて、現在のアドレスの圧縮後の符号が含まれる、並べ替えられた圧縮後のストリームを特定する。例えば、元のシリアルストリームに２つのワイドワードが含まれている場合、途切れのない圧縮後の出力ストリーム内の各圧縮後の符号は、並べ替えられた２つの圧縮後のストリームの一方から取得される。
【0191】
ブロックＳ１７５２において、ＮＵＬＬエントリに達して、少なくとも１つの文字コードが得られるまで、少なくとも１つの逆ポインタを辿ることで、圧縮後の符号の復号化を実施する。圧縮後の符号がＮＵＬＬエントリを指す逆ポインタを１つ含む場合、圧縮後の符号は、１文字コードを含む。圧縮後の符号が複数の逆ポインタを含み、その最後の逆ポインタがＮＵＬＬエントリを指す場合には、圧縮後の符号は、それぞれ複数の文字コードを含むことにより、圧縮後の符号は、マルチシンボル文字列を含む。
【0192】
ブロックＳ１７５３において、圧縮解除後のコードのアドレスを特定する。アドレス（ａｄｒ）は、圧縮解除後のストリーム中の圧縮解除後の文字コード（複数の場合もある）が占有すべき第１のアドレスである。例えば、圧縮後の符号が１文字コードを含む場合、その１文字コードが特定されたアドレスを占有することになる。圧縮後の符号に２つの文字コードが含まれている場合、この２つの文字コードは、特定されたアドレスと、並べ替えられた同じ圧縮後のストリーム（つまり、並べ替えられた他の圧縮後のストリーム（複数の場合もある）からの文字コード（複数の場合もある）のアドレスで区切られる）に提供される次のアドレスとをそれぞれ占有するといった、具合である。
【0193】
ブロックＳ１７５４において、圧縮後の符号のパラメータを決定する。パラメータには、例えば、圧縮後の符号の長さ（Ｌ）と、圧縮解除値（ｄｃ）が含まれる。圧縮後の符号の長さは、ブロックＳ１７５２で逆ポインタを辿ることにより実行された復号化に基づいて決定される。つまり、長さは、圧縮後の符号の文字コードの数に対応する。したがって、文字コードが１つの圧縮後の符号の長さはＬ＝１、文字コードが２つの圧縮後の符号の長さはＬ＝２といった具合になる。圧縮解除値は、現在の圧縮解除後のシンボルの前に、同じ入力ストリーム（ひいては、並び替えられた同じ圧縮後のストリーム）からの圧縮解除されたシンボルの累積数として決定される。圧縮後の符号が特定入力ストリームの最初の１つである場合には、シンボルがまだ圧縮解除されていないため、圧縮解除値は、０になる。同じ入力ストリームからの次の圧縮後の符号については、前の圧縮後の符号の圧縮解除値に前の圧縮後の符号の長さを加算した値を、圧縮解除値とする。一般的に、圧縮後の符号が１文字コードを含む場合、復号化値は１増分される。一般的に、圧縮後の符号が２文字コードを含む場合、復号化値は２増分されるといった具合である。
【0194】
ブロックＳ１７５５では、累積された圧縮解除値が、並べ替えられた圧縮後のストリームに対応する元の入力ストリームのシンボル数と等しいかどうかを判定する。例えば、これまで考察したように、元の入力ストリームには、８つのシンボルが含まれる場合がある。圧縮解除値がシンボル数と等しくない場合（ブロックＳ１７５５：Ｎｏ）、プロセスは、Ｓ１７５６のブロックに進み、並び替えられた同じ圧縮後のストリームからの次の圧縮後の符号の圧縮解除後のストリーム内の次のアドレスを、決定する。次アドレスは、現在のアドレス、長さ、及び、シリアルストリーム内のワイドワードの数（ｗ）に基づいて、決定することができる。つまり、前述のように、次のアドレスは、長さ（Ｌ）と数（ｗ）との積を現在のアドレス（ａｄｒ）に加算した数になる。現在のアドレスは、並べ替えられた同じ圧縮後のストリームの次の反復処理のために、圧縮解除後のストリーム内で決定された次のアドレスに設定される。
【0195】
その後、プロセスはブロックＳ１７５１に戻り、ここで、途切れのない圧縮後の出力ストリームにおいて、次の圧縮後の符号が含まれ、並べ替えられた圧縮後のストリームを特定する。これまで考察したように、並べ替えられた圧縮後のストリームは、以前の並べ替えられた圧縮後のストリームとは異なっており、これにより、圧縮後の符号は、圧縮解除を実行するためにインターリーブされる。例えば、元のシリアルストリームが２つのワイドワードを含む場合には、並べ替えられた圧縮後のストリームは、圧縮解除を行うために、並べ替えられた圧縮後の第１のストリームと並べ替えられた圧縮後の第２のストリームとの間で交互に並べられる。そして、プロセスを反復する。
【0196】
圧縮解除値がシンボル数と等しい場合（ブロックＳ１７５５：Ｙｅｓ）には、入力ストリーム内のシンボルに対応するその並び替えられた圧縮後のストリームからの圧縮後の符号が全て圧縮解除されたことを示しており、プロセスはブロックＳ１７５７に進む。ブロックＳ１７５７で、まだ完全に圧縮解除されていない並べ替えられた圧縮後のストリームが残っているかどうかを判断する。並べ替えられた圧縮後ストリームが、残っていない場合（ブロックＳ１７５７：Ｎｏ）には、プロセスは、後述するブロックＳ１７５８に進む。圧縮後の符号が残っている、並べ替えられた圧縮後のストリームが少なくとも１つある場合（ブロックＳ１７５７：Ｙｅｓ）には、プロセスはブロックＳ１７５１に戻り、ここで、途切れのない圧縮後の出力ストリームにおいて、次の圧縮後の符号が含まれ、並べ替えられた圧縮後のストリームを特定する。この時点で、他の並べ替えられた圧縮後のストリーム（複数の場合もある）からの圧縮後の符号を使い果たした可能性があるので、次の圧縮後の符号は、同じ並べ替えられた圧縮後のストリームからのものであり得る。そして、プロセスを反復する。
【0197】
ブロックＳ１７５８において、圧縮後の符号の現在のアドレスに対応する圧縮解除後のストリーム内のアドレスに、並び替えられた各圧縮後ストリームの各圧縮後の符号からの文字コード（複数の場合もある）を入力することによって、圧縮解除後のストリームが形成される。少なくとも１つの文字コードを入力することは、各圧縮後のストリームからの少なくとも１つのマルチシンボル文字列内のそれぞれの文字コードの順序を逆転させることを含む。マルチシンボル文字列ごとに、逆順の第１の文字コードが現在のアドレスに入力され、さらに、残りの文字コード（複数の場合もある）は、並べ替えられた同じ圧縮後のストリームで使用可能な圧縮解除後のストリーム内の次の連続するアドレス（複数の場合もある）へと入力される。残りの文字コードの順序とアドレスは、変わらない。最終的な結果は、前述の図１７ＡのブロックＳ１７０１において分割され、Ｓ１７０２において圧縮された元のシリアルストリームと同じ順序の文字コードを持つ圧縮解除後のストリームである。
【0198】
図１８は、代表的な実施形態に係る、高速データリンクを介したデータの通信中、格納されたデータ量を削減するコンピュータシステムの一例を示す簡略ブロック図である。
【0199】
図１８を参照すると、コンピュータシステム１８００は、処理ユニット１８１０と、本明細書で説明するプロセスを実行するために処理ユニット１８１０によって実行可能な命令を格納するためのメモリ１８２０と、並びに、ユーザが利用できるようにするためのディスプレイ１８３０及びインタフェース１８４０とを含む。処理ユニット１８１０は、１つ以上の処理デバイスを代表するものであり、本明細書の様々な実施形態で説明されている機能を実施するソフトウェア命令を実行するように構成されている。処理ユニット１８１０は、汎用コンピュータ、中央処理ユニット、１つ以上のプロセッサ、マイクロプロセッサ若しくはマイクロコントローラ、状態機械、プログラマブルロジックデバイス、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、又はこれらの組み合わせにより、ハードウェア、ソフトウェア、ファームウェア、配線接続論理回路、又はそれらの組み合わせの任意の組み合わせを使用して実装することができる。「プロセッサ（processor）」という用語は、特に、プログラム、又は機械実行可能命令を実施できる電子部品を包含する。「プロセッサ」への言及は、マルチコアプロセッサ、及び／又は、並列プロセッサ（つまり、マルチコアプロセッサ、又は並列プロセッサ、あるいはそれらの両方）のように、２つ以上のプロセッサ、又は処理コアを含むものと解釈するものとする。また、プロセッサは、単一コンピュータシステム内のプロセッサの集合体、又は、クラウドベース若しくは他のマルチサイトアプリケーション等、複数のコンピュータシステム間で分散されたプロセッサを称する場合もある。プログラムは、同じコンピューティングデバイス内、又は、複数のコンピューティングデバイスにわたって分散し得る１つ以上のプロセッサによって実行されるソフトウェア命令を含む。
【0200】
メモリ１８２０は、主メモリ、及び／又はスタティックメモリ（つまり、主メモリ、又はスタティックメモリ、あるいはそれらの両方）を含んでもよく、かかるメモリは、１つ以上のバスを介して互いに、及び処理ユニット１８１０と通信することができる。メモリ１８２０は、本明細書で記載される方法、及びプロセスのいくつかの、又は、全ての態様を実装するために使用される命令を格納する。メモリ１８２０は、例えば、任意の数、種類、及び、組み合わせのランダムアクセスメモリ（ＲＡＭ：random-access memory）と読み取り専用メモリ（ＲＯＭ：read-only memory）で実装することができ、さらに、ソフトウェアアルゴリズム、及びコンピュータプログラム等の様々な種類の情報を格納することができ、それらは全て処理ユニット１８１０によって実行可能である。様々な種類のＲＯＭとＲＡＭには、ディスクドライブ、フラッシュメモリ、電気的にプログラム可能な読み取り専用メモリ（ＥＰＲＯＭ：electrically programmable read-only memory）、電気的に消去可能、且つプログラム可能な読み取り専用メモリ（ＥＥＰＲＯＭ：electrically erasable and programmable read only memory）、レジスタ、ハードディスク、リムーバブルディスク、テープ、コンパクトディスク読み取り専用メモリ（ＣＤ－ＲＯＭ：compact disk read only memory）、デジタル多用途ディスク（ＤＶＤ：digital versatile disk）、フロッピーディスク、ｂｌｕ－ｒａｙディスク、ユニバーサルシリアルバス（ＵＳＢ：universal serial bus）ドライブ、又は、当該技術分野で知られている他の任意の形態の記憶媒体等、任意の数、種類、及び組み合わせのコンピュータ可読記憶媒体を含み得る。処理ユニット１８１０がＦＰＧＡを含む場合、例えば、メモリ１８２０は、上述のＵｌｔｒａＲＡＭ、又は、読み出し及び書き込み機能を備える他のＲＡＭを含めることができる。
【0201】
メモリ１８２０は、データと実行可能ソフトウェア命令を格納するための有形の記憶媒体であり、ソフトウェア命令が内部に格納されている間は、非一時的である。本明細書で使用する場合、「非一時的（non-trasitory）」という用語は、状態の永遠の特性ではなく、或る期間続く状態の特性として解釈されるものとする。「非一時的」という用語は、具体的に言えば、任意の時点で任意の場所に一時的にしか存在しない、搬送波若しくは信号、又は、他の形態の特性等、一時的な特性を否定するという意味である。メモリ１８２０は、様々な機能の実行を可能にするソフトウェア命令、及び／又はコンピュータ可読コード（つまり、ソフトウェア命令、又はコンピュータ可読コード、あるいはそれらの両方）を格納し得る。メモリ１８２０は、セキュア及び／又は暗号化（つまり、セキュア又は暗号化あるいはそれらの両方が）されているか、又は、セキュアでない場合及び／又は暗号化されていない場合（つまり、セキュアでない場合又は暗号化されていない場合あるいはそれらの両方の場合）もある。
【0202】
ディスプレイ１８３０は、例えば、コンピュータモニタ、テレビ、液晶ディスプレイ（ＬＣＤ：liquid crystal display）、有機発光ダイオード（ＯＬＥＤ：organic light emitting diode）、フラットパネルディスプレイ、固体ディスプレイ、又は陰極線管（ＣＲＴ：cathode ray tube）ディスプレイ等のモニタ、又は、電子ホワイトボードであり得る。また、ディスプレイ１８３０は、ユーザとの間で情報を表示及び受信するためのグラフィカルユーザインタフェース（ＧＵＩ：graphic user interface）を提供することもできる。
【0203】
インタフェース１８４０は、処理ユニット１８１０及び／又はメモリ１８２０（つまり、処理ユニット１８１０又はメモリ１８２０あるいはそれらの両方）によって出力された情報及びデータをユーザに提供するため、及び／又はユーザから入力された情報及びデータを受信するためのユーザインタフェース及び／又はネットワークインタフェース（つまり、ユーザインタフェース又はネットワークインタフェースあるいはそれらの両方）を含むことができる。すなわち、インタフェース１８４０は、ユーザがデータを入力し、本明細書に記載のプロセスの態様を制御又は動作することを可能にし、さらに、処理ユニット１８１０がユーザの制御又は動作の効果を示すことを可能にする。インタフェース１８４０は、例えば、マウス、キーボード、トラックボール、ジョイスティック、触覚デバイス、マイクロフォン、ビデオカメラ、タッチパッド、タッチスクリーン、マイクロフォン若しくはビデオカメラによってキャプチャされた音声若しくはジェスチャ認識等の１つ以上のユーザインタフェース、若しくは、コンピュータワークステーション１８０５からのユーザフィードバック、及びコンピュータワークステーションとの相互作用を可能にする他の周辺機器、又はコントロールを接続することができる。インタフェース１８４０は、ポート、ディスクドライブ、無線アンテナ、又は他の種類の受信機回路の１つ以上も含み得る。
【0204】
上記実施形態は、インターポーザ回路を通じて送信される複数の入力ストリームに対して並列ワイドワード圧縮を実行して、対応する圧縮後のストリームを取得することと、その圧縮後のストリームをキャプチャバッファに格納することとに依拠している。例えば、上述の図９、図１３Ａ、及び図１５Ａの例で見られるように、ＬＺＷ圧縮アルゴリズム等に従って、入力ストリームの１つに対する圧縮が正常に実行されると、バイトの反復を示す１つ以上のＮｏＯｐエントリが、対応する圧縮後のストリームに出現する。
【0205】
ただし、例えば、ランダムデータ等の反復パターンを多く持たないデータが入力ストリームに含まれる場合、インターポーザ回路１２０でのワイドワード圧縮（例えば、ＦＰＧＡ及び／又はＡＳＩＣを含む）は、キャプチャバッファ１２５等のバイナリ出力ストレージに読み書きする際に問題となり得る。一般的に、ランダムデータには、以前に出現したバイト列の反復がほとんど含まれていないため、圧縮率が悪くなる。ランダムデータの圧縮後のストリームは、格納される際、対応する入力ストリームの元の生の非圧縮バイト（８ビット）よりも多く、所与の出力を表現するビットを必要とする。これは、出力のサイズが、２５５より大きい数として符号化された新しい圧縮後のマルチシンボル出力に対応できる必要があるからである。圧縮後のシンボルとしての新たなマルチシンボル文字列（バイト列）は、最初は０～５１１の範囲の１０進数であり、元の非圧縮バイトあたり、９ビットを記憶媒体に書き込む必要がある。したがって、バイトを圧縮できない場合には、そのバイトは、依然として９ビットのストレージを必要とし、これは、記憶サイズが１２．５パーセント増加することと同じであり、効果が得られない（すなわち、実際には圧縮されない）。
【0206】
本明細書に記載の並列圧縮は、一般的な反復シーケンスが、複数の元の非圧縮のバイトを格納するために９ビットしか必要としないという事実に依拠している。ただし、ランダムデータ又は反復パターンがあまり多くない他のデータ（まとめて、「ランダムデータ」と称する）の場合には、データの大幅な削減を実現するには、これらの反復シーケンスが十分ではない。さらに、圧縮処理中も、圧縮辞書は増え続けている、つまり、１０進数５１１より大きい新しい出力では、キャプチャバッファ１２５に書き込むべきビット数が更に多くなるということである。これでは、圧縮せずに書き込むために８ビットしか必要としない非圧縮値が、９、１０、又はそれ以上のビットで書き込まれるようになると、スペースが無駄になる。
【0207】
図１９は、左側が非ランダムデータからの圧縮出力であるのに対して、右側がランダムデータからの圧縮出力の例を示す。入力ストリームが非ランダムデータを含む場合には、圧縮後の出力には、通常８ビットより大きい値が含まれる、これは、この値が以前に出現した反復バイトのシーケンスを表すからである。一般的に、最初の５１２個の値（１０進数０～５１１）は、９ビットを必要とし、次の５１２個の値（１０進数５１２～１０２３）は、１０ビットを必要とし、次の１０２４個の値（１０進数１０２４～２０４７）は、１１ビットを必要とし、次の２０４８個の値（１０進数２０４８～４０９５）は、１２ビットを必要とするといった具合である。辞書の最大エントリに達するまで、最初の５１２個の値を９ビットを使用して格納でき、次の５１２個の値を１０ビットを使用して格納でき、その後、全ての値をそのビット数で読み取ることを示しているので、この圧縮アルゴリズムの性質は、圧縮解除で有用である。例えば、辞書の最大エントリが４０９５の場合、１２ビットを使用して最大数の値を格納する。アルゴリズムでは、９ビットから１０ビット（図１９の破線で示す）、１０ビットから１１ビットといった具合に変更するタイミングを決定する。別の方法としては、圧縮後の各値と共に何かしらのメタデータを格納し、このメタデータには、値ごとに使用されるビット数が記載される。そして、各値は、最適ビット数の他、メタデータで表現可能である。しかし、メタデータは、必要なストレージを増加させる。したがって、読み取る値の数は事前に分かっているので、この「無駄な」メタデータは、書き込みと読み取り用の各シンボルのサイズを特定するのに必要ない。圧縮アルゴリズムは、単純に９ビットの書き込みから始まったら、次に高い辞書エントリの値が５１２に達したことを検出すると、１０ビットの書き込みを開始するといった、具合になる。そうでなければ、アルゴリズムは、ビットストリーム内のどこで１つの圧縮後の値が始まり、以前の圧縮後の値が終了したかが分からなくなるはずなので、各シンボルに書き込むビット数が分からないまま、データストレージからデータを正常に再読み取りすることができなくなる。
【0208】
比較すると、入力ストリームがランダムデータを含む場合には、書き込みと読み取りに１０ビット以上を必要とするデータストレージの領域では、２５６未満のストレージに書き込まれる値が多くなる。例えば、図１９の右側で図示される代表的な出力では、最初の５１１個の値を読み取った後、値２、６１、３２、９、４７、及び１２を読み取るために１０ビットが使用されているが、これらは全て５１２未満であるため、１０ビットの読み取りは必要ないはずである。その結果、入力ストリームの８ビットからなる大量の非圧縮バイトが、「圧縮後」の出力ストリームに１０ビット以上として書き込まれるので、非圧縮値に必要なものよりも多くのビットが使用される。これはスペースの無駄であり、ランダムデータが原因で生じる圧縮不良を引き起こし、理想よりも多くのビットで非圧縮値をあまりにも多く書き込むことによって、更なる連鎖反応が起こる。
【0209】
様々な実施形態によると、入力ストリームそれぞれのデータが、反復パターンを持たない（例えば、ランダムデータの場合）ことにより、上手く圧縮できない場合には、すぐに判別される。この判別を行うために、インターポーザ回路１２０は、圧縮中の入力ストリームにｎバイト（例えば、ｎ＝５００）の窓を適用し、対応する圧縮後のストリームに出力がないクロックのクロックサイクル数をカウントする。インターポーザ回路１２０が、マルチシンボルシーケンスである入力ストリームの現在のデータで以前に観測されたシーケンスを観測し、さらに、出力された圧縮後のストリームでマルチシンボルシーケンスを表す１つの新しい値として出力するために、より長いシーケンスを構築している場合には、クロックサイクルの出力はない。これまで考察したように、圧縮がアクティブなクロックサイクル中に出力が不足するのは、ＮｏＯｐ関数である。窓の終了時に、インターポーザ回路１２０は、窓内のバイト／クロック数ｎに対する窓内のＮｏＯｐの比率（ＮｏＯｐ／ｎ）を決定する。ＮｏＯｐの比率が所定の比率閾値未満の場合には、これは、入力ストリームのデータが十分に圧縮されていないことを意味する。この比率の所定閾値は、例えば、約０．０５～約０．２０の範囲内とすることができる。この比率が所定の比率閾値未満の場合には、入力ストリームの圧縮は完全に停止し、入力ストリームの送信は、圧縮されずに続行する。この比率が所定の比率閾値よりも高い場合には、これは、データの圧縮は良好であり、入力ストリームの圧縮は続行することを意味する。
【0210】
代表的な実施形態によると、リアルタイムにワイドワードデータを圧縮する方法が提供されている。この方法は、シリアルストリームを、このシリアルストリームの複数のワイドワードに対応する複数の入力ストリームへと分割することであって、各入力ストリームは、所定数のシンボルを含むことと、キャプチャバッファを含むインターポーザ回路を通じて、入力ストリームを送信することと、インターポーザ回路を通じて送信される入力ストリームに対して並列圧縮を実行して、対応する複数の圧縮後のストリームを取得し、この圧縮後のストリームをキャプチャバッファに格納することであって、この複数の圧縮後のストリームの１つ以上の圧縮後のストリームは、圧縮の副産物として生成され、対応するバイトの反復を示すＮｏＯｐエントリを含むことと、所定バイト数の並列圧縮を実行しながら、入力ストリームの各入力ストリームの所定バイト数に発生するＮｏＯｐエントリの数を特定することと、所定バイト数に対するＮｏＯｐエントリ数の比率を決定することと、この比率が所定の比率閾値を超える場合には、入力ストリームに対する並列圧縮の実行、及び、圧縮後のストリームの格納を続行することと、この比率が所定の比率閾値を超えない場合には、これは、ＮｏＯｐエントリの数が少なすぎて並列圧縮が効率的でないことを示しており、複数の入力ストリームに対する並列圧縮の実行、及び／又は、圧縮後のストリームの格納（つまり、複数の入力ストリームに対する並列圧縮の実行、又は圧縮後のストリームの格納、あるいはそれらの両方）を停止し、並列圧縮を実行せずに、インターポーザ回路を通して、入力ストリームを出力に送信し続けることで、データの格納時に元の８ビットのみが使用されるようにすることとを含む。
【0211】
別の代表的な実施形態によると、非一時的コンピュータ可読媒体は、並列圧縮された圧縮解除後のワイドワードデータを提供するための命令を格納する。少なくとも１つのプロセッサにより実行されると、この命令は、少なくとも１つのプロセッサに対して、シリアルストリームを、このシリアルストリームの複数のワイドワードに対応する複数の入力ストリームへと分割することであって、各入力ストリームは、所定数のシンボルを含むことと、キャプチャバッファを含むインターポーザ回路を通じて、入力ストリームの送信を制御することと、この入力ストリームに対して並列圧縮を実行して、対応する複数の圧縮後のストリームを取得し、この圧縮後のストリームをキャプチャバッファに格納することであって、この複数の圧縮後のストリームの１つ以上の圧縮後のストリームは、対応するバイトの反復を示すＮｏＯｐエントリを含むことと、所定バイト数の並列圧縮を実行しながら、複数の入力ストリームの各入力ストリームの所定バイト数に発生するＮｏＯｐエントリの数を特定することと、所定バイト数に対するＮｏＯｐエントリ数の比率を決定することと、この比率が所定の比率閾値を超える場合には、複数の入力ストリームに対する並列圧縮の実行、及び、圧縮後のストリームの格納を続行することと、この比率が所定の比率閾値を超えない場合には、複数の入力ストリームに対して実行された並列圧縮、及び／又は、圧縮後のストリームの格納（つまり、複数の入力ストリームに対して実行された並列圧縮、又は圧縮後のストリームの格納、あるいはそれらの両方）を停止し、並列圧縮を実行せずに、インターポーザ回路を通して、複数の入力ストリームの送信の制御を続行することとを実行させる。
【0212】
別の代表的な実施形態によると、システムは、並列圧縮された圧縮解除後のワイドワードデータを提供する。このシステムは、高速階層型パケットベースのプロトコルに準拠する高速データリンクを介して、テスト対象デバイス（ＤＵＴ：device under test）からホストコンピュータまでの高速階層型パケットベースのプロトコルでのデータのシリアルストリームを解析するアナライザソフトウェアを実行するように構成されたユーザインタフェース（ＵＩ）コンピュータと、高速データリンクに接続し、ＤＵＴとホストコンピュータとの間で送信されるデータを監視するインターポーザ回路とを含む。インターポーザ回路は、ＤＵＴとホストコンピュータとの間で送信されるデータを格納し、アナライザソフトウェアを使用して解析するために、ＵＩコンピュータからアクセス可能なキャプチャバッファを含む。インターポーザ回路は更に、少なくとも１つの処理ユニットも含み、この処理ユニットは、上記送信されたデータのシリアルストリームを、このシリアルストリームの複数のワイドワードに対応する複数の入力ストリームへと分割することであって、ここで各入力ストリームは、所定数のシンボルを含むことと、この複数の入力ストリームに対して並列圧縮を実行して、対応する複数の圧縮後のストリームを取得し、その圧縮後のストリームをキャプチャバッファに格納することであって、この複数の圧縮後のストリームの１つ以上の圧縮後のストリームは、対応するバイトの反復を示すＮｏＯｐエントリを含むことと、所定バイト数の並列圧縮を実行しながら、複数の入力ストリームの各入力ストリームの所定バイト数に発生するＮｏＯｐエントリの数を特定することと、所定バイト数に対するＮｏＯｐエントリ数の比率を決定することと、この比率が所定の比率閾値を超える場合には、複数の入力ストリームに対する並列圧縮の実行、及び、圧縮後のストリームの格納を続行することと、この比率が所定の比率閾値を超えない場合には、複数の入力ストリームに対して実行された並列圧縮、及び／又は、圧縮後のストリームの格納を停止することであって、上記データは、並列圧縮なしで、ＤＵＴとホストコンピュータとの間で送信され続けることとを実行するようにプログラムされる。
【0213】
図２０は、代表的な実施形態に係る、圧縮効率に優れた並列データ圧縮用に構成されたワイドワードデータのシンボルの例を示す。
【0214】
図２０を参照すると、例えば、図６、図１３Ａ、及び図１５Ａを参照して、これまで考察したように、ワイドワード２０２０は、並列圧縮を実行するために並列入力ストリームとして配列された２５６の入力ストリームを含む。図の例では、元のシリアルストリームは「０ＦＡＣ１５００．．．Ｂ００ＦＡＣ１５００．．．Ｂ００ＦＡＣ１５００．．．Ｂ００１０２０４０７．．．０５１７１９２２３０．．．」であり、元のシリアルストリームのバイトは２５６の入力ストリームに分割されている。各入力ストリームの最初の３バイトには、非ランダム構成データ及びヘッダ等の圧縮可能データが含まれているものと仮定する。各入力ストリーム内の第３のバイト以降のバイトには、例えば、トランザクション層パケット（ＴＬＰ）内のランダムペイロードデータ等の圧縮不能データが含まれるものと更に仮定する。圧縮アルゴリズムは、例えば、ＬＺＷ圧縮アルゴリズム、又は、例えば、ＬＺ７８圧縮アルゴリズムから派生した他の圧縮アルゴリズムとすることができる。
【0215】
入力データが圧縮不能になる時点は、事前に分からない。そのため、データが圧縮不能になった箇所を特定するために、圧縮を実行し、さらに、そのパフォーマンスをリアルタイムに解析して、各入力ストリームの入力データが圧縮を停止したタイミングを実用上の問題として判断する。より詳細には、入力ストリームの圧縮に成功すると、例えば、変形版のＬＺＷを使用して、対応する圧縮後の出力ストリームの反復バイトを表すＮｏＯｐエントリが生成されるので、以下で検討するように、圧縮後の出力ストリームの所定バイト数に対するＮｏＯｐエントリの数を数えることによって、圧縮の成功を判定することができる。
【0216】
図２０は、例示的な第１の入力ストリームのみに対する圧縮の成功を判定する処理を示す。第１の入力ストリームの最初の３バイトは、同じ１６進数値０Ｆ（すなわち、１０進数１５）である。このバイトが第１の入力ストリームで初めて現れるため、最初に出現した１６進数値０Ｆは、第１の（圧縮後の）出力ストリームの第１のクロックサイクルで１０進数１５へと変換される。次のクロックサイクルでは、アルゴリズムは以前に見られた別の１６進数値０Ｆを探し、最大限長い部分列を構築しようとするので、第１の出力ストリームにＮｏＯｐエントリが入力される。次のクロックサイクルでは、アルゴリズムは、別の１６進値０Ｆを探し、第１の出力ストリームにおいて、元の２バイト０Ｆ０Ｆを表す次の出力値２５６を出力する。これにより、第１の出力ストリームの圧縮部２０２２では、１５、ＮｏＯｐ，２５６の文字列となる。しかし、次の２クロックサイクルで読み取られる次の２バイト１と１７は、初めて見られるので、出力値は、元の入力値の非圧縮の等価値に過ぎない。これにより、第１の出力ストリームの非圧縮部２０２４に、１０進数１（すなわち、１６進数１から）、及び１０進数２３（すなわち、１６進数１７から）の文字列が生成される。
【0217】
この簡略例では、３つの出力エントリに１つのＮｏＯｐがあるので、第１の出力ストリームの最初の３つの出力値のＮｏＯｐ比は、０．３３と高くなる。ペイロードの「ランダムデータ」が出現し、ＮｏＯｐエントリが生成されない場合には、次の２つの出力値のＮｏＯｐ比は、０と低くなる。なお、この例は、説明目的にすぎない。実際のところ、データがランダムで圧縮不能であることを判断する値が２つしかない場合、少なすぎて正確ではない、つまり、有用ではない。したがって、様々な実施形態によると、ＮｏＯｐの比率を決定するためにｎバイトの窓（例えば、離散窓）が適用される、ここで、ｎは所定の値である。経験上、ｎ＝５００は、入力データが上手く圧縮されるかどうかを判断する上で良好な結果をもたらしたが、本教示の範囲から逸脱せずに、他のｎ値も取り入れてもよい。
【0218】
入力ストリームのデータがランダムであり、したがって圧縮が上手くいかないかどうかを判断するために、ＮｏＯｐエントリの数と窓あたりのバイト数ｎとの比率を所定の比率閾値と比較する。この比率の所定の比率閾値は、例えば、約０．０５～約０．２０の範囲内とすることができる。より具体的には、この比率の所定の比率閾値は、例えば、データがランダムである場合の適切な指標を提供するために、約０．１０とすることができる。なお、本教示の範囲から逸脱することなく、他の所定の比率閾値を適用してもよいことは言うまでもない。
【0219】
窓のサイズは、入力ストリームが圧縮不能になったタイミングをすぐに識別できるように、データに関して十分に小さくする必要があるが、窓を適用したことで、結果が信頼できなくなるほど小さくする必要はない。例えば、図２０の図示の例において、ｎ＝３バイトの離散窓は、データが圧縮不能になるタイミングを直ちに示すが、それがランダムであるかどうかに関するデータの性質を正確に反映するものではない。離散窓が大きすぎると、データが圧縮不能となるタイミングを特定するのが遅れることになる。例えば、ｎ＝５の場合、ＮｏＯｐの比率は、１／５＝０．２となり、ランダムデータのフローが既に開始しても、圧縮性テストに合格したことになる。
【0220】
一実施形態において、窓は、ｎバイトの離散窓とすることができる。離散窓の終了時に、次のｎバイトのセットをカバーするよう、離散窓がシフトされる。代替実施形態において、窓は、ｎバイトのスライディングウィンドウ（sliding window）としてもよく、スライディングウィンドウの終わりに達する度に、１バイトずつスライドする。この場合には、一時バッファを使用して、スライディングウィンドウを形成し、この一時バッファは、キャプチャバッファのｎバイトを保持し、ここで、圧縮後のコンテンツのｎバイトは、スライディングウィンドウである。ＮｏＯｐの数は、現在のウィンドウのコンテンツ全体でカウントされる。一時バッファは、例えば、現在の圧縮値を格納し（先頭にプッシュする）、ｎ＋１番目の圧縮値を後方に削除する（末尾からポップする）ファーストインファーストアウト（ＦＩＦＯ）バッファとすることができる。別の実施形態において、この比率は、窓を使用せずにｎバイトごとにチェックされるだけである。
【0221】
図２１は、代表的な実施形態に係る、ワイドワードデータの圧縮をリアルタイムに向上させる方法の流れ図である。この方法では、高速階層型パケットベースのプロトコルに準拠するデータリンクを介したデータの通信中、機能を損なうことなく、かつ解析で利用できる情報を失うことなく、インターポーザ回路のキャプチャバッファに格納されるデータ量を削減可能である。さらに、この方法は、格納に関して、圧縮プロセスが効率的でなくなったら必ず、圧縮をリアルタイムに停止し、圧縮せずに入力ストリームの転送を続行できる。図２１の様々なステップは、上述のように、インターポーザ回路１２０、及び／又は、ＵＩコンピュータ１１０によって実行可能である。
【0222】
図２１を参照すると、ブロックＳ２１１１において、圧縮されるべきデータのシリアルストリームは、シリアルストリーム中の複数のワイドワードに対応する複数の入力ストリームに分割される。各入力ストリームは、所定数のシンボルを含む。これまで考察したように、さらに、各入力ストリームには、圧縮可能（非ランダム）データと、圧縮不能（ランダム）データが含まれ得る。
【0223】
ブロックＳ２１１２において、キャプチャバッファを含むインターポーザ回路を通じて、入力ストリームを送信する。入力ストリームを、例えば、ＤＵＴ１４０からＵＩコンピュータ１１０及び／又はホストコンピュータ１５０（つまり、ＵＩコンピュータ１１０又はホストコンピュータ１５０あるいはそれらの両方）へと送信される。
【0224】
ブロックＳ２１１３において、インターポーザ回路を通じて送信される入力ストリームに対して、並列圧縮を実行して、対応する圧縮後のストリームを取得し、この圧縮後のストリームをキャプチャバッファに格納する。この並列圧縮の後、入力ストリームに対応する１つ以上の圧縮後の出力ストリームは、それぞれの入力ストリームのバイトの反復を示す、ＮｏＯｐエントリを生成する。圧縮は、所定のクロック周期を有するクロックで制御され、クロック周期ごとに入力ストリームの入力シンボルごとに、圧縮の判定を実施する。注目すべき点として、現バイトが入力ストリームの以前の連続バイトの反復である場合には、対応するクロックサイクルでの出力がないこと、つまり、そのクロックサイクルでは、ノーオペレーションであること（ＮｏＯｐエントリ）を示している。
【0225】
ブロックＳ２１１４において、所定バイト数の並列圧縮を実行しながら、複数の入力ストリームの各入力ストリームの所定バイト数（ｎ）で発生するＮｏＯｐエントリの数を特定する。並列圧縮を実行しながら、圧縮出力をスキップした（すなわち、ＮｏＯｐ）クロックサイクル数をカウントすることで、所定バイト数で発生するＮｏＯｐエントリの数を特定できる。圧縮出力をスキップするクロックサイクル数は、ＮｏＯｐエントリの数と等しくなる。一実施形態において、圧縮出力をスキップするクロックサイクルの数は、カウンタを使用してカウントすることができる。
【0226】
一実施形態において、ＮｏＯｐエントリの数は、入力ストリームに窓を適用することで特定され、ここで、窓のサイズは所定バイト数（ｎ）に等しくなる。つまり、ｎバイトの窓を適用し、窓内のＮｏＯｐエントリの数を特定し、さらに、ｎバイトの窓を次のｎバイトのセットに移動させる。
【0227】
ブロックＳ２１１５では、入力ストリームごとに、所定バイト数に対するＮｏＯｐエントリ数の比率を決定する。すなわち、比率＝ＮｏＯｐエントリ／ｎであり、ここで、ｎは比率を決定する窓内のバイト数である。注目すべき点として、上述したように、ＮｏＯｐエントリは、圧縮アルゴリズムの性質上、反復を示すために一時的に生成されるもので、キャプチャバッファには格納されない。したがって、ＮｏＯｐエントリは、事実上圧縮アルゴリズムの副産物として出現するが、代表的な実施形態に従って、ランダムデータの存在を特定するために使用される。
【0228】
ブロックＳ２１１６で、比率が所定の比率閾値を超えるかどうかを判定する。一実施形態において、この判定は、入力ストリームごとに行われる。代替実施形態において、この比率が所定の比率閾値を超えているかどうかに関する判定は、例えば、入力ストリームの１つを一次コンプレッサ（compressor）として使用して、他の入力ストリームのコンプレッサに通知することで、全ての並列入力ストリームに対して行われる。これまで考察したように、例えば、所定の比率閾値は、約０．０５～約０．２０の範囲とすることができる。この比率が所定の比率閾値を超えた場合（ブロックＳ２１１６：Ｙｅｓ）には、これは入力ストリーム中の圧縮可能（非ランダム）データを示すので、入力ストリーム中の次の所定バイト数（ｎ）にわたり、圧縮後のデータの並列圧縮と格納が継続される。これは、ブロックＳ２１１７でカウントをゼロにリセットし、さらに、入力ストリームの次の所定バイト数（ｎ）で並列圧縮を続行するブロックＳ２１１３のように、カウントを再スタートすることで示される。
【0229】
この比率が所定の比率閾値を超えない場合（ブロックＳ２１１６：Ｎｏ）には、これは、圧縮不能（ランダム）データであることを示しており、入力ストリームの並列圧縮と格納が停止する。その後、インターポーザ回路を通じた入力ストリームの送信は、並列圧縮を実行せずに、ブロックＳ２１１８で続行可能である。つまり、データ送信は、圧縮後の符号ではなく、クリア符号で続行される。これまで考察したように、この比率が所定の比率閾値を超えない場合には、これは、ＮｏＯｐエントリの数が少なすぎて並列圧縮が効率的でないことを示す。各入力ストリームの比率が決定されると、入力ストリームの圧縮を個別に停止することができる。或る入力ストリームを一次コンプレッサとして使用して、全ての入力ストリームの比率が決定されると、この一次コンプレッサは、他の入力ストリームに対して圧縮不能となったデータにフラグを付ける。一実施形態において、この比率は、この入力ストリームについて引き続き決定され、比率が再び好ましい状態になると、圧縮、又は格納を再開することができる。
【0230】
上記の実施形態には多くの利点がある。第１に、実装が容易である。クロックサイクルが出力をスキップする回数（すなわち、ＮｏＯｐ）をカウントするには、カウンタのみが必要である。カウンタは一定のクロックサイクル数（例えば、離散窓において）ごとにチェックされ、データがランダムかどうかが判断される。時間に対して測定されるＮｏＯｐの比率は、圧縮率に関する代理指標（proxy measure）である。さらに、データがランダムでない場合、通常のＬＺＷアルゴリズムは、変わらず続行し、リアルタイムに動作し続ける。
【0231】
第２に、この実施形態は、圧縮に失敗したバイト数の上限を、ｎ×幅のワードに制限する。ここで、ｎはウィンドウ内のバイト数、例えば、ｎ＝５００である。例えば、ワイドワードが２５６の場合、キャプチャバッファに書き込まれる圧縮に失敗したバイトは最大で１２８Ｋｂであり、通常、これは、入力データストリーム内の総データの１％未満に相当する。ランダムデータに遭遇したら、対応する圧縮後のデータストリームの出力ファイルが対応する入力ファイルより大きくなる前に、できるだけ早く圧縮を停止させ、これにより、圧縮処理の出力が圧縮処理への入力より大きくならないようにする。
【0232】
第３に、入力データストリームは、非ランダムデータで開始可能であり、これにより、圧縮に成功してから、ランダムデータに移行することができる。これは、例えば、データ転送に移行する前に、リンクが最初に起動モードになっている場合に発生し、この場合、そのペイロードのいずれかのランダムデータが送信される。この窓は、このような状況でも、たとえ、ランダムデータのペイロードがデータストリームの後半に出現し、最終的に、動作リンクの主要なトラフィックタイプになった場合であっても、このランダムデータのペイロードが確実に認識されるようにする。
【0233】
前述の実施形態は全て、コンピュータの機能を改善し、本来、ＵＩコンピュータ１１０及びインターポーザ回路１２０等のコンピュータ及び／又は他の処理デバイス（つまり、ＵＩコンピュータ１１０及びインターポーザ回路１２０等のコンピュータ、又は他の処理デバイス、あるいはそれらの両方）の機能に関する技術を改善させる。とりわけ、本明細書に記載の並列圧縮及び圧縮解除技術は、データをインターポーザ回路１２０からＵＩコンピュータ１１０まで高帯域幅で非常に迅速に提供し、ＵＩコンピュータ１１０、及び／又は、ＵＩコンピュータ１１０がホストするプロトコルアナライザ（ＵＩコンピュータ１１０、又はＵＩコンピュータ１１０がホストするプロトコルアナライザ、あるいはそれらの両方）による全てのデータのリアルタイム処理及び解析を可能とする。また、本明細書に記載の並列圧縮及び圧縮解除技術は、主として、圧縮後のストリーム中の圧縮符号の並び替えに基づいて、データの位置を追跡するので、実行に必要なメモリはごく僅かとなる。さらに、この並列圧縮及び圧縮解除技術では、コードを見ながらリアルタイムに、つまり、後戻りすることなく、圧縮と圧縮解除が可能である。圧縮されるデータの性質上、有効な結果が得られない場合、圧縮を監視して、中断することもできる。
【0234】
本発明は、図面及び上記説明に詳細に図示及び説明されてきたが、そのような説明図及び説明は、例示又は模範とみなされるべきであり、限定とみなされるべきではなく、本発明は、開示された実施形態に限定されるものではない。当業者であれば、請求項に係る発明を実施する際に、図面、開示及び添付の特許請求の範囲の検討により、開示される実施形態に対する他の変形形態を理解し、それを行うことができる。特許請求の範囲において、「を含む（comprising）」という単語は他の要素又はステップを排除せず、不定冠詞「一つの（"a" or "an"）」は複数形を排除しない。或る特定の手段が互いに異なる複数の従属請求項に列挙されているだけであれば、それらの手段を組み合わせて有利に使用することができないことは示されていないものとする。
【0235】
本発明の態様は、装置、方法又はコンピュータプログラム製品として具現化することができる。したがって、本発明の態様は、全体がソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコード等を含む）、又はソフトウェアの態様及びハードウェアの態様を組み合わせた実施形態の形を取ることができる。これらは全て、本明細書において、「回路」、「モジュール」又は「システム」と総称される場合がある。さらに、本発明の態様は、コンピュータ実行可能コードが具現化された１つ以上のコンピュータ可読媒体に具現化されるコンピュータプログラム製品の形を取ることができる。
【0236】
代表的な実施形態が本明細書に開示されているが、当業者であれば、本教示に従った多くの変形形態が可能であり、添付の特許請求の範囲の範囲内にあることが分かる。したがって、本発明は、添付の特許請求の範囲の範囲内にあることを除いて限定されるものではない。
【0237】
本開示の要約書は、米国特許法施行規則第１．７２（ｂ）に準拠するように与えられ、特許請求の範囲又は意味を解釈又は制限するために使用されないという了解の下に提出される。さらに、これまでの発明を実施するための形態において、本開示を簡素化する目的で、種々の特徴がまとめられる場合があるか、又は単一の実施形態において説明される場合がある。本開示は、特許請求される実施形態が、各請求項において明確に列挙されるより多くの特徴を必要とするという意図を反映すると解釈されるべきではない。むしろ、添付の特許請求の範囲が反映するように、発明の主題は、開示される実施形態のいずれかの実施形態の全ての特徴より少ない特徴を対象にする場合がある。したがって、添付の特許請求の範囲は発明を実施するための形態に組み込まれ、各請求項は、別々に特許請求される主題を規定するものとして自立している。
【図1】
【図2】
【図3A】
【図3B】
【図3C】
【図4】
【図5A】
【図5B】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13A】
【図13B】
【図13C】
【図14】
【図15A】
【図15B】
【図15C】
【図16】
【図17A】
【図17B】
【図18】
【図19】
【図20】
【図21】
【外国語明細書】