JP2005514838A - 拡張タイプ／拡張長さフィールドを有するパケットヘッダを利用したコンピュータシステムにおけるエージェント間の通信トランザクションタイプ - Google Patents

Abstract

コンピュータシステム内の高速シリアルインタフェースを介し送信装置と受信装置が接続される。送信装置は、タイプフィールドの値に応じてタイプフィールドまたは長さフィールドを拡張する拡張タイプ／拡張長さフィールドを有するパケットを送信する。拡張タイプ／拡張長さフィールドは、タイプフィールドがメモリリードリクエストトランザクションを示すとき、長さフィールドを拡張する。

Description

発明の詳細な説明

［発明の技術分野］
本発明は、コンピュータシステムの技術分野に関する。より詳細には、本発明は、高速ポイント・ツー・ポイント相互接続及び通信アーキテクチャの技術分野に関する。
［発明の背景］
コンピュータシステム、サーバ、ネットワークスイッチ及びルータ、無線通信装置などの計算装置は、典型的には多数の異なる要素から構成されている。そのような要素はしばしば、プロセッサ、システム制御論理、メモリシステム、入出力インタフェースなどを含む。要素間の通信を容易にするため、計算装置は計算システムの異なる要素によるそうような装置により提供される多数のアプリケーションの支援により互いに通信することが可能となる汎用的な入出力バスに長らく依存してきた。

そのような汎用バスアーキテクチャの最も普及しているものの１つは、おそらくＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスである。ＰＣＩバス規格（ＰＣＩローカルバス仕様、改定２．２、１９９８年１２月１８日リリース）は、マルチドロップ、相互接続チップのためのパラレルバスアーキテクチャ、拡張ボード及び計算装置内における任意の形式のプロセッサ／メモリサブシステムを定義する。典型的なＰＣＩバスの実現形態では１３３Ｍｂｐｓのスループット（すなわち、３３ＭＨｚで３２ビット）であるが、ＰＣＩ２．２規格では１３３ＭＨｚまでのクロックされたパラレル接続のピンあたり６４ビットが可能となり、これにより１Ｇｂｐｓを上回る理論上のスループットが可能となる。

最近まで、ＰＣＩバスアーキテクチャにより提供されるスループットは最先端の計算装置（例えば、マイクロプロセッササーバアプリケーション、ネットワーク機器など）の内部通信要求さえも受け容れられるだけの適切な帯域幅を提供してきた。しかしながら、処理能力の近年の進展や増大する入出力帯域幅要求は、ＰＣＩバスアーキテクチャのような従来の汎用的アーキテクチャがそのような計算装置の処理上のボトルネックとなりつつある状況をつくっている。

従来のアーキテクチャに関する他の制限は、そのようなアーキテクチャが典型的には同期（時間依存）データストリームの処理に適さないということである。同期データストリームの一例として、データがその受信と同時に利用され、音声部分が映像部分と同期することを保証するトランスポート機構を要するマルチメディアデータストリームがある。従来の汎用入出力アーキテクチャはデータを非同期、あるいは帯域幅により許容されるランダムなインターバルで処理する。マルチメディアストリームデータのそのような非同期処理は、データ損失及び／または音声と映像との不整合を生じる可能性がある。

本発明は、以下に与えられる詳細な説明及び本発明の実施例に関する添付された図面から十分理解されるであろう。しかしながら、それらは本発明を説明される特定の実施例に限定するものではなく、単に説明と理解のため与えられたものである。
［詳細な説明］
電子機器内での配置のため、スケーラブル及び拡張可能な汎用的入出力通信プラットフォームを提供するポイント・ツー・ポイントパケットベース相互接続アーキテクチャ、通信プロトコル及び関連する方法の実施例が説明される。開示された実施例は、拡張汎用入出力相互接続アーキテクチャ及び関連する通信プロトコルに関する。一例となる実施例では、各自が要素間の拡張汎用入出力通信をサポートする拡張汎用入出力に関する特徴の少なくとも一部を含む、ホストブリッジを有するルートコンプレックス（ｒｏｏｔ ｃｏｍｐｌｅｘ）、スイッチまたはエンドポイントの１以上が含まれる。

そのような要素の拡張汎用入出力装置間の通信は、以下に限定されるものではないが、バーチャル通信チャンネル、テイラーベースエラー転送（「テイラー（ｔａｉｌｅｒ）」はエラー状態を示すトランザクションレイヤパケットに付加される）、レガシーＰＣＩベースデバイスのサポート、複数のリクエストレスポンスタイプ、フロー制御及び／またはデータインテグリティ管理機能を含む１以上の画期的な特徴をサポートする通信プロトコルを使ったシリアル通信チャンネルを利用した一実施例において実行される。本実施例においてサポートされる通信プロトコルは、物理層、データリンク層及びトランザクション層を含む通信プロトコルスタックを有する。

他の実施例では、通信エージェントは前述の特徴の一部を有する拡張汎用入出力エンジンを有する。さらに、様々な実施例の１以上の要素が、ハードウェア、ソフトウェア、伝搬信号またはそれらを組み合わせたものにより実現されてもよい。

図１は、本実施例に対するコンピュータシステムである電子機器１００のブロック図である。システム１００は、プロセッサ１０２と、ルートコンプレックス１０４の一部として含まれるホストブリッジ１０３と、スイッチ１０８と、エンドポイント１１０とを有し、各自は図示されるように接続される。ルートコンプレックス１０４、スイッチ１０８及びエンドポイント１１０は、拡張汎用入出力通信ポート１０６の１以上のインスタンスを有する。図示されるように、要素１０２、１０４、１０８及び１１０のそれぞれは、拡張汎用入出力通信ポートを介し１以上の拡張汎用入出力通信チャンネルをサポートする通信リンク１１２を通じて少なくとも１つの他の要素に接続される。システム１００は、様々な従来及び非従来的な計算システム、サーバ、ネットワークスイッチ、ネットワークルータ、無線通信加入者ユニット、無線通信電話インフラストラクチャ要素、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、セットトップボックスあるいは拡張汎用入出力相互接続アーキテクチャ及び／またはここで説明される通信プロトコルの少なくとも一部の統合を通じて導入される通信リソースを利用した任意の電子機器の何れかを表すものとする。

本実施例では、プロセッサ１０２は、電子機器１００の機能的能力の１以上の特徴を制御する。この点に関して、プロセッサ１０２は、以下に限定されるものではないが、マイクロプロセッサ、ＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）、ＰＬＡ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ａｒｒａｙ）、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、マイクロコントローラなどの１以上を含む様々な制御論理装置の何れかを表す。

ルートコンプレックス１０４は、プロセッサ１０２、スイッチ１０８及びエンドポイント１１０との間の通信インタフェースを提供する。ここで利用される「ルートコンプレックス」という用語は、ホストコントローラ、メモリコントローラハブ、ＩＯコントローラハブ、あるいは上記を任意に組み合わせたもの、またはチップセット／ＣＰＵ要素の組み合わせ（すなわち、計算システム環境において）に最も近い拡張汎用入出力階層の論理エンティティをいう。図１では１つのユニットとして示されているが、ルートコンプレックス１０４は複数の物理的要素により実現されてもよい。ルートコンプレックス１０４には、スイッチ１０８、エンドポイント１１０、及び特に図示されてはいないが、レガシーブリッジ１１４または１１６のような他の周辺装置との通信を容易にする１以上の拡張汎用入出力ポート１０６が備えられている。一実施例では、各拡張汎用入出力インタフェースポートは異なる階層領域を表す。この点に関して、図１の実施例は３つの階層領域を有するルートコンプレックス１０４を示す。

図２は、一例となる拡張汎用入出力ポート１０６を示す。本実施例では、拡張汎用入出力ポート１０６は、図示されるように、トランザクション層２０２と、データリンク層２０４と、論理サブブロック２０８及び物理サブブロック２１０とを有する物理層２０６とを有する通信スタックを実現する。トランザクション層の要素がより詳細に以下で説明される。

トランザクション層２０２は、拡張汎用入出力アーキテクチャと装置コアとの間のインタフェースを提供する。トランザクション層２０２の主要な役割は、エージェント内の１以上の論理デバイスに対するパケットの組み立て及び分解である。

拡張汎用入出力アーキテクチャの主要な目的の一つは、装置間における通信の効率性を最大化することである。一実施例では、トランザクション層は、パイプラインフルスプリットトランザクションプロトコル（ｐｉｐｅｌｉｎｅｄ ｆｕｌｌ ｓｐｌｉｔ−ｔｒａｎｓａｃｔｉｏｎ ｐｒｏｔｏｃｏｌ）と共に、トランザクションレイヤパケットの順序及び処理要求を区別するための機構を実現する。トランザクション層はさらに、トランザクションレイヤパケットの構築及び処理を把握する。

拡張汎用入出力アーキテクチャの一実施例は、以下の基本的なトランザクションタイプ及びアドレススペース、すなわち、メモリ、Ｉ／Ｏ、コンフィギュレーション及びメッセージをサポートする。３２ビットと６４ビットの２つのアドレッシングタイプがサポートされている。

リクエスト及びコンプリーションパケット、それらは単にリクエスト及びコンプリーションとして呼ばれるかもしれない、を使ってトランザクションが実行される。コンプリーションは、例えば、リードデータ（ｒｅａｄ ｄａｔａ）を返したり、Ｉ／Ｏのコンプリーション及びコンフィギュレーションライトトランザクション（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｗｒｉｔｅ ｔｒａｎｓａｃｔｉｏｎ）を承認するのに必要な場合にのみ利用される。コンプリーションは、（以下に説明される）パケットヘッダのＲｅｑｕｅｓｔｅｒ ＩＤフィールドの値により、それに対応するリクエストと関連付けされる。

本実施例におけるすべてのトランザクションレイヤパケットは所定のヘッダから始まる。トランザクションレイヤパケットの中には、トランザクションレイヤパケットヘッダにおいて特定されるフォーマットフィールドにより決定されるようなヘッダに続くデータが含まれているものもある。トランザクションレイヤパケットは、所定の最大ペイロードサイズ値によりサイズ制限される。本実施例におけるトランザクションレイヤパケットデータは、４バイトの自然に位置合わせされたものであり、４バイトダブルワード単位である。

図３は、トランザクションレイヤパケットヘッダの開始の一実施例のフォーマットを示す図である。各トランザクションレイヤパケットヘッダは３ビットフォーマットフィールド（Ｆｍｔ［２：０］）を含む。トランザクションレイヤパケットヘッダはまた４ビットタイプフィールド（Ｔｙｐｅ［３：０］）を含む。トランザクションレイヤパケットフォーマットの決定のため、ＦｍｔとＴｙｐｅフィールドの両方が復号される必要がある。以下の表１はＦｍｔフィールドの一例となる符号化を示す。

本実施例のためのトランザクションレイヤヘッダはまた、２ビットＥｘｔｅｎｄｅｄ Ｔｙｐｅ／Ｅｘｔｅｎｄｅｄ Ｌｅｎｇｔｈフィールド（Ｅｔ／Ｅｌ）を含む。このフィールドは、Ｔｙｐｅフィールドの値に応じてＴｙｐｅフィールドまたはＬｅｎｇｔｈフィールドの拡張に利用される。本実施例のＬｅｎｇｔｈフィールドは通常８ビットフィールドであるが、Ｔｙｐｅフィールドの値がＥｔ／ＥｌフィールドはＬｅｎｇｔｈフィールドの拡張に利用されると示す場合、１０ビットフィールドとなるよう拡張されてもよい。Ｔｙｐｅフィールドは、Ｔｙｐｅ［３：０］フィールドの値に応じて、Ｅｔ／Ｅｌフィールドを添付することにより６ビットフィールドとなるよう拡張されてもよい。一例となるＦｍｔ、Ｔｙｐｅ及びＥｔ／Ｅｌフィールド符号化に対して以下の表２を参照せよ（他の実施例は他の符号化スキームを利用するかもしれない）。Ｅｔ／Ｅｌフィールドは、特別に示される場合を除き、Ｔｙｐｅフィールドの拡張として利用される。

リクエストパケットは、いくつかのタイプのリクエストパケットに対して、いくつかのダブルワードデータが続くリクエストヘッダを有する。ここで使われる「ダブルワード」という用語は、３２ビット長のデータを示す。本実施例では、Ｍｅｓｓａｇｅ Ｒｅｑｕｅｓｔ ＨｅａｄｅｒのＬｅｎｇｔｈフィールドは、データ長を明示的に示すＭｅｓｓａｇｅ以外では利用されない。本実施例ではまた、Ｍｅｍｏｒｙ Ｒｅａｄ Ｒｅｑｕｅｓｔ及びＭｅｍｏｒｙ Ｗｒｉｔｅ Ｒｅｑｕｅｓｔには、Ｅｌ／Ｅｔフィールドが１０ビット長のフィールドを形成するためＬｅｎｇｔｈフィールドと連結される。１０ビット長のフィールドは、４ｋＢまでのデータを示すリード及びライトリクエストを可能にする。他のタイプのトランザクションレイヤパケットは、１ｋＢまでのデータを示すＬｅｎｇｔｈ［７：０］フィールドのサイズにより制限される。任意のトランザクションレイヤパケットに含まれるデータ量は、一実施例では所定の最大ペイロードサイズに制限される。データを有するトランザクションレイヤパケットに対して、Ｌｅｎｇｔｈフィールドの値と実際のデータ量は等しくなるべきである。受信者がＬｅｎｇｔｈフィールドの値と実際のデータ量が一致しないと判断すると、パケットはＭａｌｆｏｒｍｅｄ Ｔｒａｎｓａｃｔｉｏｎ Ｌａｙｅｒ Ｐａｃｋｅｔとして扱われる。Ｍａｌｆｏｒｍｅｄ Ｔｒａｎｓａｃｔｉｏｎ Ｌａｙｅｒ Ｐａｃｋｅｔが以下で説明される。

図４は３２ビットアドレスフォーマットをサポートするリクエストパケットヘッダの図であり、図５は６４ビットアドレスフォーマットをサポートするリクエストパケットヘッダの図である。一実施例では、メモリリードリクエストとメモリライトリクエストは、３２ビットアドレスフォーマットあるいは６４ビットアドレスフォーマットを利用する。４ＧＢ以下のアドレスに対しては、３２ビットフォーマットが利用される。

図４及び５のリクエストパケットヘッダはまた、Ｆｉｒｓｔ Ｄｏｕｂｌｅ Ｗｏｒｄ Ｂｙｔｅ Ｅｎａｂｌｅフィールド（ファーストＤＷＢＥ）とＬａｓｔ Ｄｏｕｂｌｅ Ｗｏｒｄ Ｂｙｔｅ Ｅｎａｂｌｅフィールド（ラストＤＷＢＥ）を含む。Ｆｉｒｓｔ Ｄｏｕｂｌｅ Ｗｏｒｄ Ｂｙｔｅ Ｅｎａｂｌｅフィールドは、任意のメモリリードまたはライトリクエストの第１ダブルワードのバイトイネーブルを有する。このフィールドはまた、入出力あるいはコンフィギュレーションリクエストのダブルワードのみのバイトイネーブルを有する。Ｌａｓｔ Ｄｏｕｂｌｅ Ｗｏｒｄ Ｂｙｔｅ Ｅｎａｂｌｅフィールドは、任意のメモリリードまたはライトリクエストの最後のダブルワードのバイトイネーブルを有する。これらのバイトイネーブルフィールドは、メッセージリクエストヘッダ（以下で説明される図７を参照せよ）のメッセージコードフィールドと重複するため、Ｍｅｓｓａｇｅと共には利用されない。

一実施例では、バイトイネーブルフィールドの各バイトに対して、「０」の値は、データの対応するバイトが書き込まれないか、あるいは予めフェッチできない場合には、コンプリータ（ｃｏｍｐｌｅｔｏｒ）で読み込まれないということを示す。ここで使われる「コンプリータ」という用語は、リクエストパケットヘッダによりアドレス指定される論理デバイスを示す。「１」の値は、データの対応するバイトが書き込まれるか、あるいはプリフェッチできない場合には、コンプリータで読み込まれるということを示す。Ｆｉｒｓｔ Ｄｏｕｂｌｅ Ｗｏｒｄ Ｂｙｔｅ Ｅｎａｂｌｅフィールドに対して、ビット０はデータの第１ダブルワードのバイト０に対応する。ビット１はデータの第１ダブルワードのバイト１に対応する。ビット２はデータの第１ダブルワードのバイト２に対応する。ビット３はデータの第１ダブルワードのバイト３に対応する。Ｌａｓｔ Ｄｏｕｂｌｅ Ｗｏｒｄ Ｂｙｔｅ Ｅｎａｂｌｅフィールドに対して、ビット０はデータの最終ダブルワードのバイト０に対応する。ビット１はデータの最終ダブルワードのバイト１に対応する。ビット２はデータの最終ダブルワードのバイト２に対応する。ビット３はデータの最終ダブルワードのバイト３に対応する。

図４、５、６及び８の一例となるパケットヘッダは、Ｒｅｑｕｅｓｔｅｒ ＩＤフィールドと、Ｔａｇフィールドと、Ａｔｔｒｉｂｕｔｅフィールドと、Ｖｉｒｔｕａｌ Ｃｈａｎｎｅｌ ＩＤフィールドとを有する。Ｒｅｑｕｅｓｔｅｒ ＩＤフィールドとＴａｇフィールドは共にＴｒａｎｓａｃｔｉｏｎ ＩＤフィールドを形成する。Ｒｅｑｕｅｓｔｅｒ ＩＤフィールドはＢｕｓ Ｎｕｍｂｅｒフィールド、Ｄｅｖｉｃｅ Ｎｕｍｂｅｒフィールド、Ｆｕｃｎｔｉｏｎ Ｎｕｍｂｅｒフィールドに分割される。

Ｔａｇフィールドは、各リクエストを行う装置により生成される５ビットフィールドである。このタグ値は、当該リクエストを行った装置のコンプリーションに要するすべての未処理のリクエストに対し一意的なものである。Ｔｒａｎｓａｃｔｉｏｎ ＩＤフィールドは、すべてのリクエスト及びコンプリーションと共に含まれている。これらの実施例のＲｅｑｕｅｓｔｏｒ ＩＤフィールドは、すべてのファンクション（１つのファンクションは、一意的なファンクション番号によりコンフィギュレーションスペースにおいて特定されるマルチファンクション装置の１つの独立したセクションである）に対し一意的な１６ビットの値である。ファンクションは、ファンクションによりコンプリーションされたすべてのコンフィギュレーションライトと共に供給されるＢｕｓ Ｎｕｍｂｅｒを取得し、この番号をＲｅｑｕｅｓｔｏｒ ＩＤフィールドのＢｕｓ Ｎｕｍｂｅｒセクションに供給する。１つの要素の各論理デバイスは、当該要素をアドレス指定するコンフィギュレーションリクエストに対して一意的なＤｅｖｉｃｅ Ｎｕｍｂｅｒに応答するよう設計される。これらの実施例に対して、要素は多数の（おそらく数十までの）論理デバイスを有するようにしてもよい。要素の論理デバイスと関連付けされる各ファンクションは、当該要素と論理デバイスをアドレス指定するコンフィギュレーションリクエストに対して一意的なファンクション番号に応答するよう設計される。各論理デバイスは８つまでの論理関数を有するようにしてもよい。

Ａｔｔｒｉｂｕｔｅフィールドはトランザクションの特性を特定する。Ａｔｔｒｉｂｕｔｅフィールドで特定可能な属性は、プライオリティ属性（ｐｒｉｏｒｉｔｙ ａｔｔｒｉｂｕｔｅ）、トランザクションオーダリング属性（ｔｒａｎｓａｃｔｉｏｎ ｏｒｄｅｒｉｎｇ ａｔｔｒｉｂｕｔｅ）及びキャッシュコヒーレンシー管理属性（ｃａｃｈｅ ｃｏｈｅｒｅｎｃｙ ｍａｎａｇｅｍｅｎｔ ａｔｔｒｉｂｕｔｅ）を含む。

Ｖｉｒｔｕａｌ Ｃｈａｎｎｅｌ ＩＤフィールドは、バーチャルチャンネルを特定する。これら実施例では、Ｖｉｒｔｕａｌ Ｃｈａｎｎｅｌ ＩＤフィールドは、トランザクションベーシスと同様に、１６までのバーチャルチャンネルの特定を可能にする４ビットフィールドである。これら実施例では、バーチャルチャンネル０は汎用トラフィックのために利用され、０以外のバーチャルチャンネルは同期トラフィックのために利用される。

図６は、Ｍｅｓｓａｇｅのパケットヘッダの図である。表２に示されるように、メッセージは、データを含んでも含まなくともよく、またコンプリーションを必要としてもしなくてもよい。Ｍｅｓｓａｇｅは、拡張汎用入出力相互接続アーキテクチャをサポートするシステム内のすべての装置により復号される。

メッセージリクエストに対して、Ｍｅｓｓａｇｅフィールドは特定サイクルの決定、当該メッセージがデータを有するか、及び当該メッセージがコンプリーションを要するか決定するため復号される。本実施例に対するＭｅｓｓａｇｅフィールドは、バイトイネーブルフィールドが他のトランザクションタイプに対して通常存在する８ビットフィールドである。サポートされていないメッセージは受信装置によりコンプリーション要求されないものとして（以下に説明されるコンプリーション要求されないトランザクション）扱われる。

本実施例のＭｅｓｓａｇｅは複数のグループに分割される。リクエストを有するデータを含む８つのグループと、含まない８つのグループがある。異なるグループ数を使った他の実施例が可能である。本実施例に対して、表２に示されるように、リクエストを有するデータを含む８つのグループはＦｍｔフィールドにｂ１１０という値を有する。データを含まない８つのグループはＦｍｔフィールドにｂ０１０という値を有する。サブフィールドｓ［２：０］はＴｙｐｅフィールドからの１ビットとＥｔ／Ｅｌフィールドからの２ビットを含む。サブフィールドｓ［２：０］は８つのグループの１つを示す。

実現可能な様々なメッセージの例として、以下に限定されるものではないが、装置をロック解除するメッセージ、装置をリセットするメッセージ、訂正可能なエラー状態を示すメッセージ、訂正不可能なエラー状態を示すメッセージ、致命的なエラー状態を示すメッセージ、不良なリクエストパケットの通知に利用されるメッセージ、パワー管理に関するメッセージ、制御／管理命令に関するメッセージ、レガシー（例えば、ＰＣＩ）インタラプト信号（または他のレガシー信号）をエミュレートするメッセージが含まれる。これら様々なメッセージタイプは前述のグループの１つに分割されうる。例えば、パワー管理メッセージのすべては１つのグループに含まれてもよく、インタラプト信号メッセージは他のグループに含まれてもよい。

図７は、コンフィギュレーショントランザクションのリクエストヘッダフォーマットを示す図である。コンフィギュレーションスペースは、これら実施例の４つのサポートされたアドレススペースの１つである。

図８は、コンプリーションヘッダのフォーマットの一実施例を示す図である。すべてのリードリクエスト及びいくつかのライトリクエストはコンプリーションを必要とする。コンプリーションは、あるタイプのコンプリーションに対して、データのいくつかのダブルワードが続く官僚ヘッダを有する。図８に示されるＣｏｍｐｌｅｔｉｏｎ Ｓｔａｔｕｓ［２：０］フィールドはコンプリーション状態を示す。表３は一例となる符号化スキームを示す。

Ｃｏｍｐｌｅｔｅｒ ＩＤ［１５：０］フィールドは、上述のＲｅｑｕｅｓｔｅｒ ＩＤフィールドと同じタイプの情報を有する。Ｃｏｍｐｌｅｔｅｒ ＩＤフィールドに与えられる値は、リクエストをコンプリーションさせるエージェントのバス／装置／ファンクションに対応する。コンプリーションヘッダは、リクエストパケットのヘッダに供給されたものと同じＲｅｑｕｅｓｔｅｒ ＩＤ、Ｔａｇ及びＣｈａｎｎｎｅｌ ＩＤの値を有する。コンプリーションヘッダはまた、リクエストのヘッダと共に初期的に供給されたものと同じＡｔｔｒｉｂｕｔｅフィールドの値を有する。コンプリーションパケットはスイッチとルートコンプレックスにより、対応するリクエストトランザクションを開始したポートにルーティングされる。

メモリリードリクエストトランザクションに対して、ここのコンプリーションパケットは、合成時に対応するリードリクエストに関するコンプリーションパケットのすべてが特定されたデータ量を返す限り、対応するリードリクエストにより要求されたデータ量の合計より小さく与えられてもよい。これらの実施例では、Ｉ／Ｏ及びコンフィギュレーションリードリクエストは、ちょうど１つのコンプリーションパケットによりコンプリーションされる。

データを有するコンプリーションは、パケットヘッダのデータ量を特定する。コンプリーションパケットが特定されたものと異なるデータ量を実際有する場合、マルフォームドトランザクションレイヤパケットが生じる。

合成された図９ａ及び９ｂは、受信したトランザクションレイヤパケットの一例となる処理方法のフロー図を構成する。以下に説明される処理は、必ずしも連続的に行われる必要はない。実施例の中には、いくつかの処理を同時に実行するものもあるかもしれない。ブロック９０５において、受信したパケットのＦｍｔ及びＬｅｎｇｔｈフィールドに含まれる値が当該パケットの実際のサイズに一致しているかチェックされる。不一致はパケットの形成不良を表し、ブロック９２５に示されるように、エラーケースが発生する。エラーケースの処理が以下で説明される。受信したパケットの実際のサイズがＦｍｔとＬｅｎｇｔｈフィールドと不一致を示していない場合、処理はブロック９１０で継続する。

受信したパケットが６４ビットアドレス指定を利用したメモリリクエストである場合、ブロック９１０においてアドレスビット［６３：３２］の何れかが非ゼロであるかチェックされる。アドレスビット［６３：３２］の何れも非ゼロであれば、結果は形成不良パケットと判断され、処理はエラーケースのブロック９２５に進む。アドレスビット［６３：３２］の少なくとも１つが非ゼロである場合、処理はブロック９１５で継続する。

ブロック９１５において、パケットヘッダの任意のフィールドがリザーブ値を有するかチェックされる。リザーブ値が検出されると、結果は形成不良パケットと判断され、処理はエラーケースのブロック９２５に進む。リザーブ値が検出されなければ、処理はブロック９３０で継続される。

ブロック９３０において、当該パケットがリクエストパケットかコンプリーションパケットか決定される。パケットがコンプリーションパケットである場合、処理はコンプリーション処理ブロック９３５に進む。コンプリーション処理は以下でより十分に説明される。受信パケットがコンプリーションパケットでない場合、処理はブロック９４０において継続される。ここで、ブロック９４０に達するすべてのパケットはリクエストパケットであるということに注目せよ。

ブロック９４０において、コンプリート処理装置によりサポートされるリクエストタイプであるかチェックされる。リクエストタイプがサポートされていない場合、結果は非サポートリクエストと判断され、処理はエラーケースブロック９２５に進む。本実施例では、サポートされていないリクエストタイプがブロードキャストメッセージあるいはブロードキャストメッセージに対して予約された符号化を利用したメッセージである場合、当該パケットは静かに破棄され、エラーケースは発生しない。リクエストタイプがコンプリート処理装置によりサポートされている場合、処理はブロック９４５で継続される。

ブロック９４５に示されるように、コンプリート処理装置は内部エラーによりリクエストパケットに応答することができない場合、結果は「コンプリータ中止」と判断され、処理はエラーケースブロック９２５に進む。そうでない場合、リクエストはブロック９５０において供される。リクエストに供するのに、ブロック９４０及び９４５に示される処理を繰り返す必要があるかもしれない。

リクエストが良好に提供されると、処理はブロック９５５において継続される。ブロック９５５により示されるように、処理されたリクエストがコンプリーション要する場合、コンプリーションパケットがブロック９６０において返される。

図１０は、受信したリクエストパケットに関するエラー状態の一例となる処理方法のフロー図である。ブロック１０１０に示されるように、受信したリクエストがコンプリーションを期待している場合、適切なコンプリーション状態を有するコンプリーションがブロック１０２０において送信される。コンプリーションはリクエストを行った装置に返される。受信したリクエストがコンプリーションを期待していない場合、ブロック１０３０においてエラーメッセージがリクエストを行った装置に送信される。当該エラーはブロック１０４０においてシステムに通知される。ブロック１０３０に示されるエラーメッセージ送信処理はプログラム可能なオプションとして実現されてもよい。

システムの中には、前述の拡張汎用入出力相互接続アーキテクチャに加えて、１以上のＰＣＩバスを含むものがあるかもしれない。拡張汎用入出力相互接続アーキテクチャを介してＰＣＩバス上の装置に送られるメモリ、Ｉ／Ｏ及びコンフィギュレーションリクエストに対して、これら実施例のコンプリーション状態は当該サイクルの実際のＰＣＩ終了を表す。例えば、非ポストＰＣＩサイクルは、コンプリーション状態が決定されうる前に、ＰＣＩバス上で実際提供されねばならない。他のすべての場合に対して、コンプリーション状態の値が以下に説明されるように定義される。

リクエストがコンプリート処理装置により良好にコンプリーションされると、その結果コンプリーション状態の値は「コンプリーション成功」（表３に示されるように本実施例に対しては「０００」としてコンプリーション状態フィールドに符号化される）となる。例えば、ホストブリッジからのリードリクエストはスイッチを介してコンプリータエンドポイントに送られる。コンプリータはコンプリーション成功状態を示すコンプリーションパケットに応答して、さらにリードリクエストのデータに応答する。スイッチはこのコンプリーションパケットをホストブリッジに送り返す。

コンプリート処理装置によりリクエストが受信及び復号されるが、コンプリート処理装置はリクエストされたトランザクションをサポートしておらず、当該リクエストがコンプリーションを要するとき、その結果コンプリーション状態は「非サポートリクエスト」（表３に示されるように本実施例に対しては「００１」としてコンプリーション状態フィールドに符号化される）となる。非サポートリクエストの一例は範囲外のアドレスへのメモリリードリクエストであろう。この場合には、コンプリータはこのリクエストをサポートすることができず、リクエストを行った装置はコンプリーションを期待している。

コンプリート処理装置によりリクエストが受信及び復号され、このコンプリート装置がリクエストされたトランザクションをサポートすることができず、リクエストを行った装置がコンプリーションを期待していない場合、結果としてのコンプリーション状態は非サポートリクエストとなる。リクエストを行った装置はコンプリーションを期待していないため、コンプリーション状態は、図１０に関して説明されたように、メッセージを介してリクエストを行った装置に通信される。リクエストを行った装置がコンプリーションを期待しない非サポートリクエストの一例は、領域外のアドレスへのメモリライトトランザクションである。メッセージを介したコンプリーションの通信は、選択的な特徴として実現されてもよい。

コンプリート処理装置によりリクエストが受信及び復号されるが、内部エラーによりコンプリート処理装置が応答できないとき、結果としてのコンプリーション状態は「コンプリータ中止」（本実施例では「１００」としてコンプリーション状態フィールドに符号化される）となる。

コンプリート処理装置がパケット生成規則に従わないパケットを受信すると、結果として「形成不良パケット」となる。コンプリート処理装置は、リクエストを行った装置に送られる「形成不良パケット」エラーメッセージを送信することにより、この状況に応答する。本実施例において、形成不良パケットを受信したスイッチは、他の何れのポートも意図された宛先ポートとして肯定的に特定されなければ、パケットを上流ポートに送信しなければならない。

リードコンプリーションが「コンプリーション成功」以外のコンプリーション状態を有するとき、コンプリーションパケットと共にデータは返されない。コンプリーション不成功状態によるリードコンプリーションは、当該リクエストに対して送信された最後のコンプリーションである。例えば、コンプリータがリードリクエストを提供するための４つの部分に分割してもよく、第２コンプリーションパケットがコンプリータ中止コンプリーション状態を生じる。最終的な２つのコンプリーションパケットは送信されない。リクエストを行う装置が、コンプリーション不成功状態のコンプリーションパケットを受信すると、リクエストが終了されたとみなし、当該リードリクエストに対応する追加的コンプリーションパケットは期待されない。

図１１は、システムエージェントによって期待されないコンプリーションパケットの一実施例による処理方法のフロー図である。「期待されないコンプリーション」は、エージェントが同一のエージェントにより発せられた任意の未処理のリクエストに対応しないコンプリーションを受信する場合に起こる。図１１の例示的方法において、ブロック１１１０は、期待されていないコンプリーションが存在しない場合、通常の処理がブロック１１２０において継続されるということを示している。しかしながら、期待されていないコンプリーションが受信されると、この期待されていないコンプリーションパケットはブロック１１３０において破棄される。パケットの破棄後、上記エラー状態がブロック１１４０においてシステムに通知されてもよい。本実施例では、エラーの通知はソフトウェアによりプログラム可能なオプションであるかもしれない。

図１２は、リクエストを行う装置による「コンプリーション成功」以外のコンプリーション状態を有するコンプリーションパケットの一実施例による処理方法のフロー図である。ブロック１２１０は、コンプリーション状態が「コンプリーション成功」である場合、ブロック１２２０において通常の処理が継続されるということを示す。コンプリーション状態が「コンプリーション成功」以外の場合、ブロック１２３０においてＣｏｍｐｌｅｔｅｒ ＩＤフィールドの値が記録される。本実施例では、Ｃｏｍｐｌｅｔｅｒ ＩＤ値はレジスタに格納されている。その後、ブロック１２４０において、「コンプリーション不成功受信」ビットが本実施例のリクエストを行った装置のレジスタに設定される。ブロック１２５０において、上記エラー状態が通知される。エラー状態の通知はプログラム可能なオプションとして実現されてもよい。ソフトウェアエージェントは、Ｃｏｍｐｌｅｔｅｒ ＩＤ値と「コンプリーション不成功受信」ビットを利用して、エラー状態のソースを突き止める。

図１３は、コンプリート処理装置による「コンプリーション成功」以外のコンプリーション状態を有するコンプリーションパケットの一実施例による処理方法のフロー図である。ブロック１３１０は、送信されたコンプリーションパケットのコンプリーション状態が「コンプリーション成功」である場合、ブロック１３２０において通常の処理が継続されるということを示している。コンプリーション状態が「コンプリーション成功」以外である場合、ブロック１３３０においてＲｅｑｕｅｓｔｅｒ ＩＤとＴａｇフィールドの値が記録される。本実施例では、Ｒｅｑｕｅｓｔｅｒ ＩＤとＴａｇ値が１以上のレジスタに格納される。その後、ブロック１３４０において、「コンプリーション不成功送信」ビットが本実施例のコンプリート処理装置のレジスタに設定される。上記エラー状態がブロック１３５０において通知されてもよい。エラー状態の通知はプログラム可能なオプションとして実現されてもよい。ソフトウェアエージェントは、Ｒｅｑｕｅｓｔｅｒ ＩＤ、Ｔａｇ値及び「コンプリーション不成功送信」ビットを利用して、エラー状態のソースを突き止める。

上記明細書において、特定の実施例を参照することにより本発明が説明された。しかしながら、添付されたクレームに与えられるような本発明のより広範な趣旨及び範囲から逸脱することなく様々な変更及び修正が可能であるということは明らかであろう。従って、明細書及び図面は限定的なものというよりも例示的なものとみなされるべきである。

明細書における「ある実施例」、「一実施例」、「いくつかの実施例」あるいは「他の実施例」という表現は、実施例に関して説明された特定の特徴、構成または特性が本発明の必ずしもすべての実施例でなく、少なくともいくつかの実施例に含まれるということを意味するものである。「ある実施例」、「一実施例」あるいは「いくつかの実施例」の様々な様相は、必ずしも同一の実施例を言及しているものではない。

図１は、一実施例によるコンピュータシステムのブロック図である。 図２は、一例となる拡張汎用入出力ポートの図である。 図３は、一実施例によるトランザクションレイヤパケットヘッダの開始のフォーマットを示す図である。 図４は、３２ビットアドレスフォーマットをサポートするリクエストパケットヘッダの図である。 図５は、６４ビットアドレスフォーマットをサポートするリクエストパケットヘッダの図である。 図６は、Ｍｅｓｓａｇｅのパケットヘッダの図である。 図７は、コンフィギュレーショントランザクションのリクエストヘッダフォーマットを示す図である。 図８は、コンプリーションヘッダの一実施例によるフォーマットを示す図である。 図９ａは、受信したトランザクションレイヤパケットの一実施例による処理方法のフロー図である。 図９ｂは、受信したトランザクションレイヤパケットの一実施例による処理方法のフロー図である。 図１０は、受信したリクエストパケットに関するエラー状態の一実施例による処理方法のフロー図である。 図１１は、システムエージェントにより期待されないコンプリーションパケットの一実施例による処理方法のフロー図である。 図１２は、リクエスト装置による「コンプリーション成功」以外のコンプリーション状態を有するコンプリーションパケットの一実施例による処理方法のフロー図である。 図１３は、コンプリート処理装置による「コンプリーション成功」以外のコンプリーション状態を有するコンプリーションパケットの一実施例による処理方法のフロー図である。

Claims (18)

1. 第１フィールドを有するパケットヘッダを出力するデータパス出力ユニットを有する装置であって、前記第１フィールドは第２フィールドまたは第３フィールドを前記第２フィールドの内容に応じて拡張するためのものであることを特徴とする装置。
2. 請求項１記載の装置であって、前記第２フィールドはタイプフィールドであることを特徴とする装置。
3. 請求項２記載の装置であって、前記第３フィールドは長さフィールドであるあることを特徴とする装置。
4. 請求項３記載の装置であって、前記第１フィールドは、前記タイプフィールドがメモリリードリクエストトランザクションを示す場合、前記長さフィールドを拡張するのに利用されることを特徴とする装置。
5. 請求項４記載の装置であって、前記第１フィールドは前記パケットヘッダの前記タイプフィールド及び前記長さフィールドとの間で、かつ隣接して配置されることを特徴とする装置。
6. 請求項５記載の装置であって、前記タイプフィールドは前記データパス出力ユニットにより出力される前記パケットヘッダの第１バイトに配置されることを特徴とする装置。
7. 第１フィールドを有するパケットヘッダを受信するデータパス入力ユニットを有する装置であって、前記第１フィールドは第２フィールドまたは第３フィールドを前記第２フィールドの内容に応じて拡張するためのものであることを特徴とする装置。
8. 請求項７記載の装置であって、前記第２フィールドはタイプフィールドであることを特徴とする装置。
9. 請求項８記載の装置であって、前記第３フィールドは長さフィールドであるあることを特徴とする装置。
10. 請求項９記載の装置であって、前記第１フィールドは、前記タイプフィールドがメモリリードリクエストトランザクションを示す場合、前記長さフィールドを拡張するのに利用されることを特徴とする装置。
11. 請求項１０記載の装置であって、前記第１フィールドは前記パケットヘッダの前記タイプフィールド及び前記長さフィールドとの間で、かつ隣接して配置されることを特徴とする装置。
12. 請求項１１記載の装置であって、前記タイプフィールドはデータパス出力ユニットにより出力される前記パケットヘッダの第１バイトに配置されることを特徴とする装置。
13. 第１フィールドを有するパケットヘッダを送信する送信装置と、
    前記送信装置に接続され、前記パケットヘッダを受信する受信装置とを有するシステムであって、前記第１フィールドは第２フィールドまたは第３フィールドを前記第２フィールドの内容に応じて拡張するためのものであることを特徴とするシステム。
14. 請求項１３記載のシステムであって、前記第２フィールドはタイプフィールドであることを特徴とするシステム。
15. 請求項１４記載のシステムであって、前記第３フィールドは長さフィールドであるあることを特徴とするシステム。
16. 請求項１５記載のシステムであって、前記第１フィールドは、前記タイプフィールドがメモリリードリクエストトランザクションを示す場合、前記長さフィールドを拡張するのに利用されることを特徴とするシステム。
17. 請求項１６記載のシステムであって、前記第１フィールドは前記パケットヘッダの前記タイプフィールド及び前記長さフィールドとの間で、かつ隣接して配置されることを特徴とするシステム。
18. 請求項１７記載のシステムであって、前記タイプフィールドはデータパス出力ユニットにより出力される前記パケットヘッダの第１バイトに配置されることを特徴とするシステム。

Images