(57)【特許請求の範囲】
【請求項１】
データパケットプロセッサにおいて、処理中のパケットアカウンティング用の構成可能なキューイングシステムであって、
１つまたは複数のクラスタに配置された複数のキューと、
到着するパケットのパケット識別子を作成する識別機構と、
パケット識別子をキューに挿入し、パケット識別子をどのキューに挿入するかを決定する挿入論理と、
識別されたパケットの処理、完了したパケットのダウンロードの開始のためにキューからパケット識別子を選択し、または選択したパケット識別子を再キューイングする選択論理と
を有するキューイングシステム。
【請求項２】
すべてのキューのパケット識別子の総数が、固定され、クラスタの数およびクラスタごとのキューの数を、１から同一の最大個数まで変化することができ、クラスタの数が１と等しい場合、キューの数が最大個数になり、逆も同様である、請求項１に記載のキューイングシステム。
【請求項３】
キューの数を決定するクラスタの相対的な数が、プロセッサに関連する構成レジスタをセットすることによってセットされる、請求項２に記載のキューイングシステム。
【請求項４】
パケット識別子の総数が２５６であり、２５６個のパケットが、どの時点でもデータパケットプロセッサで処理中になることができることを意味する、請求項２に記載のキューイングシステム。
【請求項５】
クラスタまたはキューのいずれかの最大個数が３２であり、クラスタまたはキューの数が２のべきになるように制御される、請求項２に記載のキューイングシステム。
【請求項６】
作成される前記パケット識別子が、前記パケット自体が処理中に保管されるメモリ位置に関連する、請求項１に記載のキューイングシステム。
【請求項７】
処理中にパケットデータを保管するオンボードメモリが、パケットページに配置され、前記パケット識別子が、パケットの前記パケットデータが保管されるパケットページの先頭を識別するアドレスである、請求項６に記載のキューイングシステム。
【請求項８】
作成されキューイングされる前記パケット識別子が、前記メモリ位置の他に、前記パケットがそこから受信された装置の１つまたは複数の識別子と、前記パケットが処理中に総サイズが増加または減少したかの表示と、関連するパケットに関する処理が完了したか否かの表示と、前記パケット識別子を挿入すべき次のキューと、前記パケットが現在処理中であるかどうかの識別子とを含む、請求項６に記載のキューイングシステム。
【請求項９】
前記挿入論理が、パケットの優先順位を決定し、決定した前記優先順位に応じて前記パケットを特定のキューに挿入する、請求項１に記載のキューイングシステム。
【請求項１０】
クラスタが、番号を付けられ、識別されたパケットを処理する優先順位が、クラスタ番号による、請求項９に記載のキューイングシステム。
【請求項１１】
選択システムが、前記パケット識別子にセットされた次のキュー番号の値に基づいて再キューイングするパケットを選択する、請求項８に記載のキューイングシステム。
【請求項１２】
選択システムが、関連するパケットに関する処理が完了したかどうかの表示の値に基づいて、ダウンロードするパケットを選択する、請求項８に記載のキューイングシステム。
【請求項１３】
選択システムが、キュー番号による優先順位に基づいて処理するパケットを選択する、請求項１０に記載のキューイングシステム。
【請求項１４】
処理するパケットを選択するために優先順位クラスタのキューを選択する時に、公平アルゴリズムを伴う、請求項１３に記載のキューイングシステム。
【請求項１５】
前記データパケットプロセッサが、コンテキストレジスタによって実施され個々のストリームに関連する別々のコンテキストを有するマルチストリーミングプロセッサであり、選択システムが、選択された識別子に関連するパケットからのヘッダ情報を、使用可能なコンテキストにロードさせる、請求項１に記載のキューイングシステム。
【請求項１６】
ストリームより多数のコンテキストがあり、使用可能なコンテキストへのヘッダ情報のローディングが、バックグラウンドで、すなわち、パケットの処理と並列に、達成される、請求項１５に記載のキューイングシステム。
【請求項１７】
プロセッサによって実行されるソフトウェアが、パケット識別子のフィールドの個々の値を操作することが可能な、請求項８に記載のキューイングシステム。
【請求項１８】
前記挿入論理が、少なくとも部分的にフローに従って、パケットをキューに挿入し、挿入および選択論理が、個々のフローのパケット順序を保存するために協力する、請求項１に記載のキューイングシステム。
【請求項１９】
前記挿入論理が、ネットワークまたは交換装置から着信するパケットを、キューへの識別子挿入に関する最高の優先順位を用いて扱い、再キューイングするパケット識別子を次に高い優先順位を用いて扱い、ソフトウェアによって生成されるパケットの識別子を最低の優先順位を用いて扱う、請求項１に記載のキューイングシステム。
【請求項２０】
データパケットプロセッサであって、
１つまたは複数のソースからの着信パケットをバッファリングする入力バッファと、
処理中にパケットデータを保管するローカルパケットメモリと、
パケットデータを処理するストリームプロセッサユニットと、
処理中のパケットアカウンティング用の構成可能なキューイングシステムと
を含み、前記キューイングシステムが、１つまたは複数のクラスタに配置された複数のキューと、到着するパケットのパケット識別子を作成する識別機構と、パケット識別子をキューに挿入し、パケット識別子をどのキューに挿入するかを決定する挿入論理と、識別されたパケットの処理の開始のためにキューからパケット識別子を選択し、完了したパケットをダウンロードし、または選択したパケット識別子を再キューイングする選択論理とを含む
データパケットプロセッサ。
【請求項２１】
すべてのキューのパケット識別子の総数が固定され、クラスタの数およびクラスタごとのキューの数が、１から同一の最大個数まで変化することができ、クラスタの数が１と等しい場合、キューの数が最大個数になり、逆も同様である、請求項２０に記載のプロセッサ。
【請求項２２】
キューの数を決定するクラスタの相対的な数が、プロセッサに関連する構成レジスタをセットすることによってセットされる、請求項２１に記載のプロセッサ。
【請求項２３】
パケット識別子の総数が２５６であり、２５６個のパケットが、どの時点でも前記データパケットプロセッサで処理中になることができることを意味する、請求項２１に記載のプロセッサ。
【請求項２４】
クラスタまたはキューのいずれかの最大個数が３２であり、クラスタまたはキューの数が２のべきになるように制御される、請求項２１に記載のプロセッサ。
【請求項２５】
作成される前記パケット識別子が、前記パケット自体が処理中に保管されるメモリ位置に関連する、請求項２０に記載のプロセッサ。
【請求項２６】
処理中にパケットデータを保管するオンボードメモリが、パケットページに配置され、前記パケット識別子が、パケットの前記パケットデータが保管されるパケットページの先頭を識別するアドレスである、請求項２５に記載のプロセッサ。
【請求項２７】
作成されキューイングされる前記パケット識別子が、前記メモリ位置の他に、前記パケットがそこから受信された装置の１つまたは複数の識別子と、前記パケットが処理中に総サイズが増加または減少したかの表示と、関連するパケットに関する処理が完了したか否かの表示と、前記パケット識別子を挿入すべき次のキューと、前記パケットが現在処理中かどうかの識別子とを含む、請求項２５に記載のプロセッサ。
【請求項２８】
前記挿入論理が、パケットの優先順位を決定し、決定した前記優先順位に応じて前記パケットを特定のキューに挿入する、請求項２０に記載のプロセッサ。
【請求項２９】
クラスタが、番号を付けられ、識別されたパケットを処理する優先順位が、クラスタ番号による、請求項２８に記載のプロセッサ。
【請求項３０】
選択システムが、前記パケット識別子にセットされた次のキュー番号の値に基づいて再キューイングするパケットを選択する、請求項２７に記載のプロセッサ。
【請求項３１】
選択システムが、関連するパケットに関する処理が完了したかどうかの表示の値に基づいて、ダウンロードするパケットを選択する、請求項２７に記載のプロセッサ。
【請求項３２】
選択システムが、キュー番号による優先順位に基づいて処理するパケットを選択する、請求項２９に記載のプロセッサ。
【請求項３３】
処理するパケットを選択する優先順位クラスタのキューを選択する時に、公平アルゴリズムを伴う、請求項３２に記載のプロセッサ。
【請求項３４】
前記データパケットプロセッサが、コンテキストレジスタによって実施され個々のストリームに関連する別々のコンテキストを有するマルチストリーミングプロセッサであり、選択システムが、選択された識別子に関連するパケットからのヘッダ情報を、使用可能なコンテキストにロードさせる、請求項２０に記載のプロセッサ。
【請求項３５】
ストリームより多数のコンテキストがあり、使用可能なコンテキストへのヘッダ情報のローディングが、バックグラウンドで、すなわち、パケットの処理と並列に、達成される、請求項３４に記載のプロセッサ。
【請求項３６】
プロセッサによって実行されるソフトウェアが、パケット識別子のフィールドの個々の値を操作することができる、請求項２７に記載のプロセッサ。
【請求項３７】
前記挿入論理が、少なくとも部分的にフローに従って、パケットをキューに挿入し、挿入および選択論理が、個々のフローでパケットの順序を保存するために協力する、請求項２０に記載のプロセッサ。
【請求項３８】
前記挿入論理が、ネットワークまたは交換装置から着信するパケットを、キューへの識別子挿入に関する最高の優先順位を用いて扱い、再キューイングするパケット識別子を次に高い優先順位を用いて扱い、ソフトウェアによって生成されるパケットの識別子を最低の優先順位を用いて扱う、請求項２０に記載のプロセッサ。
【請求項３９】
データパケットプロセッサのパケットのアカウンティングの方法であって、
（ａ）プロセッサで１つまたは複数のクラスタに複数のキューを設けるステップと、
（ｂ）到着するパケットのパケット識別子を作成するステップと、
（ｃ）どのキューに挿入するかを決定する論理を有する挿入機構によってパケット識別子をキューに挿入するステップと、
（ｄ）識別されたパケットの処理の開始、完了したパケットのダウンロード、または選択されたパケット識別子の再キューイングのために、選択論理によってキューからパケット識別子を選択するステップと
を含む方法。
【請求項４０】
すべてのキューのパケット識別子の総数が、固定され、クラスタの数およびクラスタごとのキューの数が、１から同一の最大個数まで変化することができ、クラスタの数が１と等しい場合に、キューの数が最大個数になり、逆も同様である、請求項３９に記載の方法。
【請求項４１】
キューの数を決定するクラスタの相対的な数が、プロセッサに関連する構成レジスタをセットすることによってセットされる、請求項４０に記載の方法。
【請求項４２】
パケット識別子の総数が２５６であり、２５６個のパケットが、どの時点でもデータパケットプロセッサで処理中になることができることを意味する、請求項４０に記載の方法。
【請求項４３】
クラスタまたはキューのいずれかの最大個数が３２であり、クラスタまたはキューの数が２のべきになるように制御される、請求項４０に記載の方法。
【請求項４４】
作成される前記パケット識別子が、前記パケット自体が処理中に保管されるメモリ位置に関連する、請求項３９に記載の方法。
【請求項４５】
処理中にパケットデータを保管するオンボードメモリが、パケットページに配置され、前記パケット識別子が、パケットの前記パケットデータが保管されるパケットページの先頭を識別するアドレスである、請求項４４に記載の方法。
【請求項４６】
作成され、キューイングされる前記パケット識別子が、前記メモリ位置の他に、前記パケットがそこから受信された装置の１つまたは複数の識別子と、前記パケットが処理中に総サイズが増加または減少したかの表示と、関連するパケットに関する処理が完了したか否かの表示と、前記パケット識別子を挿入すべき次のキューと、前記パケットが現在処理中であるかの識別子とを含む、請求項４４に記載の方法。
【請求項４７】
前記挿入論理が、パケットの優先順位を決定し、決定した前記優先順位に応じて前記パケットを特定のキューに挿入する、請求項３９に記載の方法。
【請求項４８】
クラスタが、番号を付けられ、識別したパケットを処理する優先順位が、クラスタ番号による、請求項４７に記載の方法。
【請求項４９】
選択システムが、前記パケット識別子にセットされた次のキュー番号の値に基づいて再キューイングのためにパケットを選択する、請求項４６に記載の方法。
【請求項５０】
選択システムが、関連するパケットに関する処理が完了したかどうかの表示の値に基づいて、ダウンロードのためにパケットを選択する、請求項４６に記載の方法。
【請求項５１】
選択システムが、キュー番号による優先順位に基づく処理のためにパケットを選択する、請求項４８に記載の方法。
【請求項５２】
処理のためにパケットを選択する優先順位クラスタのキューを選択する時に、公平アルゴリズムを伴う、請求項４３に記載の方法。
【請求項５３】
前記データパケットプロセッサが、コンテキストレジスタによって実施され、個々のストリームに関連する別々のコンテキストを有するマルチストリーミングプロセッサであり、選択システムが、選択された識別子に関連するパケットからのヘッダ情報を、使用可能なコンテキストにロードさせる、請求項３９に記載の方法。
【請求項５４】
ストリームより多数のコンテキストがあり、使用可能なコンテキストへのヘッダ情報のローディングが、バックグラウンドすなわち、パケットの処理と並列に、達成される、請求項５３に記載の方法。
【請求項５５】
プロセッサによって実行されるソフトウェアが、パケット識別子のフィールドの個々の値を操作することが可能な、請求項４８に記載の方法。
【請求項５６】
前記挿入論理が、少なくとも部分的にフローに従って、パケットをキューに挿入し、挿入および選択論理が、個々のフローのパケット順序を保存するために協力する、請求項３９に記載の方法。
【請求項５７】
前記挿入論理が、ネットワークまたは交換装置から着信するパケットを、キューへの識別子挿入のために最高の優先順位を用いて扱い、再キューイングされるパケット識別子を次に高い優先順位を用いて扱い、ソフトウェアによって生成されるパケットの識別子を最低の優先順位を用いて扱う、請求項３９に記載の方法。
【請求項５８】
処理を待っている到着するパケットを管理するキューイングシステムを有するデータパケットプロセッサにおいて、
パケット番号の固定された範囲と、
割当機構と
を有し、前記割当機構が、前記固定された範囲の個別の番号をアカウンティングし、前記キューイングシステムのパケットが処理のために送られるかソフトウェアがパケットをアクティブにする時に番号を無効とマークし、前記キューイングシステムに置かれる新たに到着したパケットに無効な番号を再割り当てすることを特徴とする
パケット番号付けシステム。
【請求項５９】
ある時点でパケットに割り当てられたパケット番号が別の時点で同一のパケットに割り当てられることを保証するために、プローブビットが各パケットに関連付けられ、前記プローブビットが、パケット番号が割り当てられる時にデアサートされ、ストリームによって実行されるプローブ・アンド・セット（Ｐｒｏｂｅ  ａｎｄ  Ｓｅｔ）コマンドによってアサートされ、プローブビットがアサートされた後のどの時刻にも、アサートされたプローブビットが、前記パケット番号が前記同一のパケットに関連することを示すようにすることを特徴とする、請求項５８に記載のシステム。
【発明の詳細な説明】
【０００１】
（発明の分野）
本発明は、ディジタル処理の分野で、パケットネットワーク用のルータ内でのパケットの処理の装置および方法に関し、具体的には、特にダイナミックマルチストリーミングプロセッサでの、異なるタイプのプロセッサおよびマルチプロセッサシステムを使用するルーティング動作でのパケットのキューイングおよび優先順位付けの装置および方法に関する。
【０００２】
（関連文書の相互参照）
本明細書は、２０００年８月２日出願の米国仮特許出願第６０／１８１３６４号の米国特許法１１９（ｅ）条の下での優先の利益を主張し、前の特許出願のすべての開示を参照によって組み込む。
【０００３】
（発明の背景）
よく知られているインターネットネットワークは、本願の提出の時点で有名なよく知られた公衆がアクセス可能な通信ネットワークであり、これまでに使用可能にされたものの中で最も堅牢な情報および通信のソースであると論証できる。インターネットは、主な例として、本明細書で教示される装置および方法から利益を得るデータパケットネットワークの現在の応用分野の例で使用されるが、このデータパケットネットワークは、特定の標準化されたプロトコルに従うネットワークの１つにすぎない。やはり非常によく知られているように、インターネット（および関係するネットワーク）は、常に仕掛品である。すなわち、多数の研究者および開発者が、そのようなネットワークの動作を機能強化するための、ソフトウェアを含む新しいよりよい装置および方法を提供するために常時競争している。
【０００４】
一般に、データパケットネットワークでの最も需要の多い改良は、より高速のルーティング（単位時間あたりのパケット数が多い）と、メッセージングでのよりよい信頼性および忠実度を提供するものである。一般に必要とされているものは、パケットをルータ内で処理できる速度を高めるルータ装置および方法である。
【０００５】
当技術分野でよく知られているように、パケットルータは、データパケットを、通常は複数のポートの１つまたは複数で受信し、ある形で処理し、ルータの同一のまたは他のポートに送出して、下流の宛先へ継続する、コンピュータ化された機械である。そのようなコンピュータ化された動作の例として、インターネットが、個々のルータの膨大な相互接続されたネットワークであることを念頭におくと、個々のルータは、それが通信ポートによって接続されている外部ルータがどれであるかと、着信パケットについてネットワークを介する代替経路のどれが最適経路であるかを記憶しなければならない。個々のルータは、フローアカウンティングも達成しなければならず、フローは、一般に、共通のソースおよび終点宛先を有するパケットのストリームを意味する。一般に望まれているものは、個々のフローが共通の経路に従うことである。当業者は、コンピュータ化された処理に関する多数のそのような要件を知っている。
【０００６】
通常、インターネットネットワーク内のルータは、必要な多数のコンピューティングタスクを達成するための専用マイクロプロセッサとして１つまたは複数の中央処理装置（ＣＰＵ）を有する。本願出願時点での最新技術では、これらが、単一ストリーミングプロセッサである、すなわち、各プロセッサが、命令の単一のストリームを処理することができる。いくつかの場合に、開発者は、そのようなルーティング動作にマルチプロセッサ技術を適用する。本発明人は、複数の命令ストリームを同時に処理することができるダイナミックマルチストリーミング（ＤＭＳ）プロセッサの開発にしばらくかかわった。そのようなプロセッサに好ましい応用分野が、インターネットなどのパケットネットワークでのパケットの処理である。
【０００７】
上の「関連文書の相互参照」に記載の仮特許出願に、パケット処理へのＤＭＳ応用に好ましいアーキテクチャの説明および図面がある。そのアーキテクチャの機能領域の１つが、キューイングシステムを含む、汎用キューとそれに関連する方法および回路である。本発明が関係するのは、権能を付与する詳細を下で説明する、このキューイングシステムである。
【０００８】
（発明の概要）
本発明の好ましい実施形態では、データパケットプロセッサにおいて、処理中のパケットアカウンティング用の構成可能キューイングシステムが提供され、このシステムには、１つまたは複数のクラスタに配置された複数のキューと、到着するパケットのパケット識別子を作成する識別機構と、パケット識別子をキューに挿入し、パケット識別子をどのキューに挿入するかを決定する挿入論理と、識別されたパケットの処理の開始、完了したパケットのダウンロード、または選択されたパケット識別子の再キューイングのためにキューからのパケット識別子を選択する選択論理とが含まれる。
【０００９】
いくつかの実施形態では、すべてのキュー内のパケット識別子の総数が、固定され、クラスタの数およびクラスタごとのキューの数を、１から同一の最大個数まで変更することができ、クラスタの数が１と等しい場合に、キューの数が最大個数になり、逆も同様である。また、いくつかの実施形態で、キューの数を決定するクラスタの相対的な数が、プロセッサに関連する構成レジスタをセットすることによってセットされる。
【００１０】
いくつかの場合に、パケット識別子の総数が２５６であり、２５６個のパケットが、どの時点でもデータパケットプロセッサ内で処理中になることができることを意味する。また、いくつかの場合に、クラスタまたはキューのいずれかの最大個数が３２であり、クラスタまたはキューの数が２のべきになるように制御される。
【００１１】
いくつかの実施形態で、作成される前記パケット識別子が、前記パケット自体が処理中に保管されるメモリ位置に関連する。この場合に、処理中にパケットデータを保管するオンボードメモリが、パケットページに配置され、前記パケット識別子が、パケットの前記パケットデータが保管されるパケットページの先頭を識別するアドレスである。もう１つの機能強化で、作成されキューイングされる前記パケット識別子が、前記メモリ位置の他に、前記パケットがそこから受信された装置の１つまたは複数の識別子と、前記パケットが処理中に総サイズが増加または減少したかどうかの表示と、関連するパケットに対する処理が完了したか否かの表示と、前記パケット識別子を挿入しなければならない次のキューと、前記パケットが現在処理中であるかどうかの識別子とを含む。
【００１２】
いくつかの実施形態で、前記挿入論理が、パケットの優先順位を判定し、判定された前記優先順位に応じて前記パケットを特定のキューに挿入する。クラスタに番号を付けることができ、識別されたパケットを処理する優先順位が、これらの場合では、クラスタ番号による。
【００１３】
いくつかの実施形態で、選択システムが、前記パケット識別子内でセットされた次のキュー番号の値に基づいて再キューイングのためにパケットを選択する。また、いくつかの実施形態で、選択システムが、関連するパケットに対する処理が完了したかどうかの表示の値に基づいて、ダウンロードのためにパケットを選択する。
【００１４】
いくつかの実施形態で、選択システムが、キュー番号による優先順位に基づいて処理のためにパケットを選択し、いくつかの場合に、処理のためにパケットを選択するために優先順位クラスタ内のキューを選択する時に、公平アルゴリズムに従う。
【００１５】
いくつかの好ましい実施形態では、前記データパケットプロセッサが、コンテキストレジスタによって実施され個々のストリームに関連する別々のコンテキストを有するマルチストリーミングプロセッサであり、選択システムが、選択された識別子に関連するパケットからのヘッダ情報を、使用可能なコンテキストにロードさせる。ストリームより多数のコンテキストが存在することができ、使用可能なコンテキストへのヘッダ情報のローディングを、バックグラウンドすなわち、パケットの処理と並列に、達成することができる。
【００１６】
本発明のいくつかの実施形態では、プロセッサによって実行されるソフトウェアが、パケット識別子内のフィールドの個々の１つの値を操作することをイネーブルされる。また、いくつかの実施形態では、前記挿入論理が、少なくとも部分的にフローに従って、パケットをキューに挿入し、挿入および選択論理が、個々のフロー内のパケットの順序を保存するために協力する。さらなる実施形態では、前記挿入論理が、ネットワークまたはスイッチングファブリックから着信するパケットを、キューへの識別子挿入に関する最高の優先順位を用いて扱い、再キューイングされるパケット識別子を次に高い優先順位を用いて扱い、ソフトウェアによって生成されるパケットの識別子を最低の優先順位を用いて扱う。
【００１７】
本発明のもう１つの態様では、１つまたは複数のソースからの着信パケットをバッファリングする入力バッファと、処理中にパケットデータを保管するローカルパケットメモリと、パケットデータを処理するストリームプロセッサユニットと、処理中のパケットアカウンティング用の構成可能なキューイングシステムとを含むデータパケットプロセッサが提供される。前記キューイングシステムが、１つまたは複数のクラスタに配置された複数のキューと、到着するパケットのパケット識別子を作成する識別機構と、パケット識別子をキューに挿入し、パケット識別子をどのキューに挿入するかを決定する挿入論理と、識別されたパケットの処理の開始、完了したパケットのダウンロード、または選択されたパケット識別子の再キューイングのためにキューからパケット識別子を選択する選択論理とを含む。
【００１８】
プロセッサのいくつかの実施形態では、すべてのキュー内のパケット識別子の総数が、固定され、クラスタの数およびクラスタごとのキューの数を、１から同一の最大個数まで変更することができ、クラスタの数が１と等しい場合に、キューの数が最大個数になり、逆も同様である。また、いくつかの実施形態で、キューの数を決定するクラスタの相対的な数が、プロセッサに関連する構成レジスタをセットすることによってセットされる。
【００１９】
いくつかの場合に、パケット識別子の総数が２５６であり、２５６個のパケットが、どの時点でも前記データパケットプロセッサ内で処理中になることができることを意味する。また、いくつかの場合に、クラスタまたはキューのいずれかの最大個数が３２であり、クラスタまたはキューの数が２のべきになるように制御される。
【００２０】
いくつかの実施形態で、作成される前記パケット識別子が、前記パケット自体が処理中に保管されるメモリ位置に関連する。これらの実施形態では、処理中にパケットデータを保管するオンボードメモリが、パケットページに配置され、前記パケット識別子が、パケットの前記パケットデータが保管されるパケットページの先頭を識別するアドレスである。
【００２１】
いくつかの場合に、作成されキューイングされる前記パケット識別子が、前記メモリ位置の他に、前記パケットがそこから受信された装置の１つまたは複数の識別子と、前記パケットが処理中に総サイズが増加または減少したかどうかの表示と、関連するパケットに対する処理が完了したか否かの表示と、前記パケット識別子を挿入しなければならない次のキューと、前記パケットが現在処理中であるかどうかの識別子とを含む。
【００２２】
いくつかの実施形態で、前記挿入論理が、パケットの優先順位を判定し、判定された前記優先順位に応じて前記パケットを特定のキューに挿入する。これらの実施形態の一部では、クラスタが、番号を付けられ、識別されたパケットを処理する優先順位が、クラスタ番号による。
【００２３】
いくつかの場合に、選択システムが、前記パケット識別子内でセットされた次のキュー番号の値に基づいて再キューイングのためにパケットを選択する。また、いくつかの場合に、選択システムが、関連するパケットに対する処理が完了したかどうかの表示の値に基づいて、ダウンロードのためにパケットを選択する。さらに、キューが優先順位によって番号を付けられる場合に、選択システムが、キュー番号による優先順位に基づいて処理のためにパケットを選択することができる。この場合に、処理のためにパケットを選択するために優先順位クラスタ内のキューを選択する時に従う公平アルゴリズムを設けることができる。
【００２４】
いくつかの好ましい実施形態では、前記データパケットプロセッサが、コンテキストレジスタによって実施され個々のストリームに関連する別々のコンテキストを有するマルチストリーミングプロセッサであり、選択システムが、選択された識別子に関連するパケットからのヘッダ情報を、使用可能なコンテキストにロードさせる。これらの実施形態のいくつかで、ストリームより多数のコンテキストがあり、使用可能なコンテキストへのヘッダ情報のローディングが、バックグラウンドすなわち、パケットの処理と並列に、達成される。
【００２５】
このプロセッサのいくつかの実施形態で、プロセッサによって実行されるソフトウェアが、パケット識別子内のフィールドの個々の１つの値を操作することをイネーブルされる。また、このプロセッサのいくつかの実施形態で、前記挿入論理が、少なくとも部分的にフローに従って、パケットをキューに挿入し、挿入および選択論理が、個々のフロー内のパケットの順序を保存するために協力する。いくつかの場合に、前記挿入論理が、ネットワークまたはスイッチングファブリックから着信するパケットを、キューへの識別子挿入に関する最高の優先順位を用いて扱い、再キューイングされるパケット識別子を次に高い優先順位を用いて扱い、ソフトウェアによって生成されるパケットの識別子を最低の優先順位を用いて扱う。
【００２６】
本発明のもう１つの態様で、データパケットプロセッサ内でのパケットのアカウンティングの方法であって、（ａ）プロセッサ内で１つまたは複数のクラスタ内の複数のキューを設けるステップと、（ｂ）到着するパケットのパケット識別子を作成するステップと、（ｃ）どのキューに挿入するかを決定する論理を有する挿入機構によってパケット識別子をキューに挿入するステップと、（ｄ）識別されたパケットの処理の開始、完了したパケットのダウンロード、または選択されたパケット識別子の再キューイングのために、選択論理によってキューからパケット識別子を選択するステップとを含む方法。
【００２７】
この方法のいくつかの実施形態では、すべてのキュー内のパケット識別子の総数が、固定され、クラスタの数およびクラスタごとのキューの数を、１から同一の最大個数まで変更することができ、クラスタの数が１と等しい場合に、キューの数が最大個数になり、逆も同様である。いくつかの実施形態では、キューの数を決定するクラスタの相対的な数が、プロセッサに関連する構成レジスタをセットすることによってセットされる。
【００２８】
この方法のいくつかの実施形態では、パケット識別子の総数が２５６であり、２５６個のパケットが、どの時点でもデータパケットプロセッサ内で処理中になることができることを意味する。クラスタまたはキューのいずれかの最大個数を３２にすることができ、クラスタまたはキューの数が２のべきになるように制御される。
【００２９】
この方法の他の実施形態では、作成される前記パケット識別子が、前記パケット自体が処理中に保管されるメモリ位置に関連する。メモリをパケットページに配置することができ、前記パケット識別子が、パケットの前記パケットデータが保管されるパケットページの先頭を識別するアドレスである。
【００３０】
いくつかの場合に、作成されキューイングされる前記パケット識別子が、前記メモリ位置の他に、前記パケットがそこから受信された装置の１つまたは複数の識別子と、前記パケットが処理中に総サイズが増加または減少したかどうかの表示と、関連するパケットに対する処理が完了したか否かの表示と、前記パケット識別子を挿入しなければならない次のキューと、前記パケットが現在処理中であるかどうかの識別子とを含む。
【００３１】
いくつかの実施形態で、前記挿入論理が、パケットの優先順位を判定し、判定された前記優先順位に応じて前記パケットを特定のキューに挿入する。これらの場合のいくつかでは、クラスタが、番号を付けられ、識別されたパケットを処理する優先順位が、クラスタ番号による。これらの場合では、選択システムが、前記パケット識別子内でセットされた次のキュー番号の値に基づいて再キューイングのためにパケットを選択する。
【００３２】
この方法のいくつかの実施形態では、選択システムが、関連するパケットに対する処理が完了したかどうかの表示の値に基づいて、ダウンロードのためにパケットを選択し、キュー番号による優先順位に基づいて処理のためにパケットを選択することができる。処理のためにパケットを選択するために優先順位クラスタ内のキューを選択する時に、公平アルゴリズムに従うことができる。
【００３３】
本発明のいくつかの好ましい実施形態では、前記データパケットプロセッサが、コンテキストレジスタによって実施され個々のストリームに関連する別々のコンテキストを有するマルチストリーミングプロセッサであり、選択システムが、選択された識別子に関連するパケットからのヘッダ情報を、使用可能なコンテキストにロードさせる。
【００３４】
いくつかの実施形態で、ストリームより多数のコンテキストがあり、使用可能なコンテキストへのヘッダ情報のローディングが、バックグラウンドすなわち、パケットの処理と並列に、達成される。
【００３５】
いくつかの実施形態で、プロセッサによって実行されるソフトウェアが、パケット識別子内のフィールドの個々の１つの値を操作することをイネーブルされる。また、いくつかの実施形態で、前記挿入論理が、少なくとも部分的にフローに従って、パケットをキューに挿入し、挿入および選択論理が、個々のフロー内のパケットの順序を保存するために協力する。いくつかの場合に、前記挿入論理が、ネットワークまたはスイッチングファブリックから着信するパケットを、キューへの識別子挿入に関する最高の優先順位を用いて扱い、再キューイングされるパケット識別子を次に高い優先順位を用いて扱い、ソフトウェアによって生成されるパケットの識別子を最低の優先順位を用いて扱う。
【００３６】
本発明のもう１つの態様では、処理を待っている到着するパケットを管理するキューイングシステムを有するデータパケットプロセッサにおいて、固定された範囲のパケット番号と、割当機構とを有するパケット番号付けシステムが提供される。前記割当機構が、前記固定された範囲の個別の番号をアカウンティングし、前記キューイングシステム内のパケットが処理のために送られる時に番号をインアクティブとマークし、インアクティブな番号を前記キューイングシステムに置かれる新たに到着したパケットに再割り当てする。
【００３７】
いくつかの実施形態で、プローブビットが、ある時点でパケットに割り当てられたパケット番号が別の時点で同一のパケットに割り当てられることを保証するために各パケットに関連付けられ、前記プローブビットが、パケット番号が割り当てられる時にデアサートされ、ストリームによって実行されるＰｒｏｂｅ  ａｎｄ  Ｓｅｔコマンドによってアサートされ、プローブビットがアサートされた後のどの時刻にも、アサートされたプローブビットが、前記パケット番号が前記同一のパケットに関連することを示すようにすることを特徴とする。
【００３８】
下の権能を付与する詳細で教示される本発明の実施形態は、初めて、従来の機器を用いて前に可能であった速度をはるかに超える速度で、効率的でコスト効率のよい形で、着信パケットをキューに入れ、管理する、データパケットプロセッサを提供する。
【００３９】
（好ましい実施形態の説明）
上で参照した仮特許出願第６０／１８１３６４号に、発明人がＸＣａｌｉｂｅｒプロセッサと呼ぶ、パケットネットワークでのパケット処理専用のＤＭＳプロセッサのアーキテクチャに関する開示がある。参照された開示には、２つの広範囲の図面が提供され、その１つのＮＩＯブロック図と称する図には、ＸＣａｌｉｂｅｒプロセッサの全体的なアーキテクチャが、パケット処理ＡＳＩＣとの間の入出力ポートと共に示され、他方の図には、ＮＩＯ図に示された汎用キューの多数の態様が示されている。この優先権書類のＮＩＯシステムは、本明細書のパケット管理ユニット（ＰＭＵ）と等しい。本明細書が対象とするものは、汎用キューの複数の態様である。
【００４０】
図１は、優先権文書のＮＩＯ図に示されたものより高水準の機能ユニットの副分割を伴うＸＣａｌｉｂｅｒ  ＤＭＳプロセッサ１０１の単純化されたブロック図である。図１では、ＸＣａｌｉｂｅｒ  ＤＭＳプロセッサ１０１が、３つの機能領域に編成されるものとして示されている。外側のシステムインターフェースユニット（ＳＩＵ）領域１０７は、外部装置すなわち、ＸＣａｌｉｂｅｒプロセッサの外部の、通常はパケットを送信し、受信するための装置との通信を提供する。内側では、プロセッサ１０１が、２つの広範囲の機能ユニットすなわち、上記の優先権文書のＮＩＯシステムと等しいパケット管理ユニット（ＰＭＵ）１０３と、ストリームプロセッサユニット（ＳＰＵ）１０７に分割される。ＰＭＵの機能には、受信され処理されるすべてのパケットの、アカウンティングと管理が含まれる。ＳＰＵは、すべての計算タスクの責任を負う。
【００４１】
ＰＭＵは、ＸＣａｌｉｂｅｒプロセッサのうちで、コストの高いパケットヘッダアクセスとパケットのソートおよび管理のタスクの実行からＳＰＵをオフロードする部分であり、これらのタスクは、こうなっていなければ、プロセッサ全体の性能を大きく低下させるはずである。
【００４２】
パケット管理は、（ａ）パケット記憶用に割り振られるオンチップメモリの管理と、（ｂ）バックグラウンドで、着信パケットからのパケットヘッダ情報をＸＣａｌｉｂｅｒプロセッサの異なるコンテキスト（下でさらに説明するコンテキストレジスタ）にアップロードすることと、（ｃ）柔軟なキューイングシステムで、現在ＸＣａｌｉｂｅｒ内で処理中のパケットのパケット識別子を維持することによって達成される。
【００４３】
説明した、ＰＭＵによって実行されるパケット管理およびアカウンティングのタスクは、ＳＰＵコアによるパケットの処理と並列に実行される。この機能性を実装するために、ＰＭＵは、ネットワークから着信するパケットをバッファリングし、それらをＳＰＵコアに供給し、必要な場合に、処理が完了した時にそれらをネットワークに送出する、ハードウェア構造の組を有する。ＰＭＵは、本明細書の焦点である、内部パケットメモリストレージおよびキューイングシステムの構成など、その複数の機能の高い度合のプログラム可能性を特徴とする。
【００４４】
図２は、追加の詳細を示す、図１のＸＣａｌｉｂｅｒプロセッサのブロック図である。ＳＩＵ１０７およびＳＰＵ１０５は、図１で使用されたものと同一の符号を有する、単一のブロックとして図２に示されている。しかし、ＰＭＵは、要素の間に通信回線を示されて、かなり拡大されて詳細に示されている。
【００４５】
図２では、ネットワーク／スイッチングファブリックインターフェース２０３が示されており、これは、いくつかの場合に、たとえばインターネットなどのネットワークへまたは、たとえばパケットを受信し、送信し、ＸＣａｌｉｂｅｒプロセッサとパケットをやりとりする、パケットルータ内のスイッチングファブリックへの直接のインターフェース専用の特定用途向け集積回路（ＡＳＩＣ）である。この特定の例では、プロセッサ２０１と通信する２つのインポートと２つのアウトポートがある。ネットワークインインターフェース回路２０５およびネットワークアウトインターフェース回路２１５は、プロセッサへおよびプロセッサからのパケットトラフィックを処理し、これらの２つのインターフェースは、図２では便宜上別々に図示されているが、正しくはＳＩＵ１０７の一部である。
【００４６】
また、ＰＭＵ内のネットワークインターフェースには、プロセッサ２０１内に、入力バッファ２０７および出力バッファ２１７があり、これらは、プロセッサ２０１から出入りするパケットのフローをバッファリングするように働く。
【００４７】
図１をもう一度参照すると、パケット管理ユニット（ＰＭＵ）１０３が示されており、このＰＭＵ１０３を、パケット管理およびアカウンティングの要件をストリーム処理ユニットからオフロードするユニットとして説明した。これは、具体的には、図２で展開されたユニットであり、実質的に、入力バッファ（ＩＢ）２０７、出力バッファ（ＯＢ）２１７、ページングメモリ管理ユニット（ＰＭＭＵ）２０９、ローカルパケットメモリ（ＬＰＭ）２１９、コマンドユニット（ＣＵ）２１３、キューイングシステム（ＱＳ）２１１、構成レジスタ２２１、およびレジスタ転送ユニット（ＲＴＵ）２２７からなる。ＰＭＵの要素の間の通信経路は、図２では矢印によって示されており、特に本明細書の特定の焦点であるＱＳ２１１を含む、ＰＭＵの要素のさらなる説明を、下で提供する。
【００４８】
ＰＭＵの概要
図２に、ＰＭＵの要素が示されており、これらを下で簡単に識別する。パケットは、この例では、１６バイトネットワーク入力インターフェースを介してＰＭＵに到着する。この実施形態では、パケットデータが、２０Ｇｂｐｓ（最大）の速度でＰＭＵに到着する。３００ＭＨｚのＸＣａｌｉｂｅｒコア周波数動作速度で、平均８バイトのパケットデータが、すべてのＸＣａｌｉｂｅｒコアサイクルに受信される。ネットワーク入力インターフェースからの着信データは、インバッファ（ＩＢ）ブロック２０７でバッファリングされる。ＸＣａｌｉｂｅｒ内のネットワークインターフェース２０５は、外部装置がパケット送信の前にパケットにサイズを付加できなかった場合に、送信されるパケットのサイズをパケット自体に付加する機能を有する。２つまでの装置が、ＸＣａｌｉｂｅｒに（装置ごとに１０Ｇｂｐｓ）でパケットデータを送信することができ、２つのインポートが、接続されたＡＳＩＣから図示されている。特定のＡＳＩＣの存在および使用が、例示的であり、パケットを、他の装置から受信できることを理解されたい。さらに、いくつかの実施形態で、図示された２つのインポートより多数またはより少数のポートを設けることができる。
【００４９】
パケットメモリマネージャユニット（ＰＭＭＵ）２０９は、各着信パケットをオンチップローカルパケットメモリ（ＬＰＭ）２１９に保管しなければならないかどうかを決定するか、たとえばＬＰＭにそれを保管する余地が存在しない場合に、ＳＩＵブロックを介して、図示されていない外部パケットメモリ（ＥＰＭ）にパケットを送り出すかパケットをドロップすることを決定することができる。パケットをＬＰＭに保管する場合には、ＰＭＭＵは、パケットを保管する位置を決定し、それを行うのに必要なすべてのアドレスを生成する。生成されるアドレスは、好ましい実施形態では、ＬＰＭ内の１６バイトラインに対応し、パケットが、このメモリ内に連続して保管される。
【００５０】
ＰＭＭＵが着信パケットをドロップしない（最もありそうな）場合に、パケット識別子が作成され、このパケット識別子には、パケットが保管され始めたパケットメモリ内の固定サイズページへのポインタ（ｐａｃｋｅｔＰａｇｅと称する）が含まれる。識別子は、作成され、キューイングシステム（ＱＳ）ブロック２１１にエンキューされる。ＱＳは、０から２５５までの番号（ｐａｃｋｅｔＮｕｍｂｅｒと称する）を、新しいパケットのそれぞれに割り当てる。ＱＳは、パケットの優先順位に基づいて、ＸＣａｌｉｂｅｒ内で生きているパケットの識別子をソートし、ＳＰＵコアがパケットの状況に対する変更を通知する時に、ソーティングを更新する。ＱＳは、次にＳＰＵに供給されるパケット識別子を選択する。やはり、ＱＳは、本発明の特定の焦点である。
【００５１】
レジスタ転送ユニット（ＲＴＵ）ブロック２２７は、ＱＳからパケット識別子（ｐａｃｋｅｔＰａｇｅおよびｐａｃｋｅｔＮｕｍｂｅｒ）を受け取る時に、好ましい実施形態のＸＣａｌｉｂｅｒが特徴とする８つのコンテキストの中から、使用可能なコンテキスト（２２９、図２）を検索する。アーキテクチャおよび説明の目的から、コンテキストは、図２では別のユニット２２９として図示されているが、より広義のストリーム処理ユニットの一部とみなされる。
【００５２】
使用可能なコンテキストがない場合には、ＲＴＵは、１組の割込みを介してＳＰＵにこのイベントについて通知する能力を有する。コンテキストが使用可能である場合には、ＲＴＵは、パケット識別子情報とパケットのヘッダの選択されたフィールドとをコンテキストにロードし、その後、コンテキストを解放する（これは、その時点でＳＰＵの制御下に来る。ＲＴＵは、ＳＩＵを介してパケットのヘッダ情報にアクセスする。というのは、パケットが、オフチップＥＰＭに保管されている可能性があるからである。
【００５３】
結局、ＳＰＵコア内のストリームが、コンテキストを処理し、この事実についてＱＳに通知する。好ましい実施形態では、ＤＭＳコア内に８つのストリームがある。その後、ＱＳは、パケットの状況を（完了に）更新し、結局、このパケットが、ダウンロードのために選択される（すなわち、対応するパケットのパケットデータが、ＸＣａｌｉｂｅｒプロセッサから２つの外部装置の１つに送り出される）。
【００５４】
パケットが、ダウンロードのために選択される時に、ＱＳは、ｐａｃｋｅｔＰａｇｅ（他の情報の中でも）をＰＭＭＵブロックに送り、ＰＭＭＵブロックは、対応するラインアドレスを生成して、ＬＰＭからパケットデータを読み取るか（パケットがオンチップローカルメモリに保管された場合）、ＳＩＵに外部パケットメモリからＰＭＵにパケットを移動するように指示する。どの場合でも、読み取られたパケットデータのラインが、アウトバッファ（ＯＢ）ブロックにバッファリングされ、そこから、１６バイトネットワーク出力インターフェースを介して装置に送り出される。このインターフェースは、出力の相対物と独立である。好ましい実施形態のこのインターフェースの最大集計帯域幅も、出力装置ごとに１０Ｇｂｐｓの２０Ｇｂｐｓである。
【００５５】
コマンドユニット（ＣＵ）２１３は、ＳＰＵ１０５によって送られたコマンドを受け取る。コマンドは、多くの場合に新たに定義された命令である、ＳＰＵコアによってディスパッチされたパケット命令である。これらのコマンドは、３つの独立のタイプに分類され、ＰＭＵは、サイクルごとにタイプごとに１つのコマンド（合計３コマンド毎サイクルまで）を実行することができる。コマンドは、ロード様またはストア様とすることができる（ＰＭＵがＳＰＵへの応答を提供するか否かに依存する）。
【００５６】
ＰＭＵの多数の特徴が、メモリマップされた構成レジスタ２２１を介して、ＳＰＵによって構成される。そのような特徴の一部は、ブート時にプログラムされなければならず、残りは、動的に変更することができる。後者の一部について、ＳＰＵは、特徴の機能性を正しくプログラムするために、単一スレッドモードで動作していなければならない。ＣＵブロックは、これらの構成レジスタの更新を管理する。
【００５７】
ＰＭＵは、ＡＳＩＣ２０３とＸＣａｌｉｂｅｒ  ＤＭＳプロセッサ２０１の間のフロー制御を助ける機構を提供する。ＬＰＭ２１９またはＱＳ２１１が満杯になろうとしている時に、２つの異なる割込みが、ＳＰＵ１０５に対してＰＭＵによって生成される。ソフトウェアによって、対応する構造が完全に満杯になる前に、前もって何回の割込みが生成されるかが制御される。ソフトウェアは、これらの割込みの生成をディスエーブルすることもできる。
【００５８】
ＬＰＭ２１９も、メモリマップ式であり、ＳＰＵ１０５は、従来のロード／ストア機構を介してこれにアクセスすることができる。構成レジスタ２２１とＬＰＭ２１９の両方が、ＳＩＵ１０７によって保たれる開始アドレス（ベースアドレス）を有する。ＳＰＵ１０５からのＬＰＭ２１９および構成スペースに対する要求は、ＳＩＵブロック１０７を介してＰＭＵに到達する。ＳＩＵは、外部パケットメモリのベースアドレスも知っている。
【００５９】
インバッファ（ＩＢ）
外部装置によって送られたパケットデータは、ネットワーク入力インターフェース２０５を介して、好ましい実施形態ではＸＣａｌｉｂｅｒコアサイクルごとに８バイトの平均速度でＰＭＵに到着する。ＰＭＵのＩＢブロック２０７が、このデータを受け取り、バッファリングし、ＦＩＦＯ様の形でＬＰＭ２１９に供給し、いくつかの場合に、ＳＩＵにも供給する（本明細書の別の個所で説明する、パケットオーバーフローの場合に）。
【００６０】
ＸＣａｌｉｂｅｒ  ＤＭＳプロセッサ２０１は、潜在的に、２つまでの独立の装置との間でパケットデータを送信／受信することができる。各装置は、パケットデータと共に供給される装置識別子を用いてＳＩＵ１０７でタグを付けられる。１つの装置がパケットからのデータの送信を開始する時に、その装置は、パケットの終りに達するかバスエラーがＳＩＵによって検出されるまで、その同一のパケットからのデータの送信を継続する。
【００６１】
好ましい実施形態では、パケットの最初のバイトが、必ず、そのパケットの最初に送信される１６バイトのバイト０から始まる。パケットの最初の２バイトによって、パケットのバイト単位のサイズ（最初の２バイトを含む）が指定される。これらの２バイトは、外部装置がそれを付加しなかった場合に、ＳＩＵによって必ず付加される。１６バイトチャンクのバイトｋが、有効なバイトである場合に、バイト０からｋ−１も、有効なバイトである。これを保証できるのは、パケットの最初のバイトが、必ずバイト０から始まるからである。パケットが、必ず１６バイトチャンクのバイト０から始まり、パケットのサイズが前もって知られる（最初の２バイトで）ので、各バイトを検証するための有効ビットが不要であることに留意されたい。ネットワークインターフェースは、すべてのコアクロックで、１６バイトチャンクに少なくとも１つの有効なバイトが含まれるかどうかを指定する制御ビットを供給する。
【００６２】
ネットワーク入力インターフェースから受け取られた有効なデータは、バッファ２０７内で編成される。これは、８エントリのバッファであり、各エントリが、１６バイトのデータと各チャンクに関連する制御ビットとを保持する。ＰＭＭＵ２０９は、各エントリの制御ビットを調べ、新しいパケットが開始されるのかどうか、または２つ（までの）アクティブパケットのどちらにデータが属するかを判定し、それ相応に動作する。
【００６３】
ＩＢ２０７のエントリのそれぞれの１６バイトチャンクは、ＬＰＭ２１９内またはＥＰＭ（図示せず）内に保管される。ＬＰＭコントローラまたはＳＩＵのいずれかによって、パケットメモリに書き込む帯域幅が、少なくとも着信パケットデータの帯域幅に一致することと、パケットメモリへの着信パケットデータの書込が、パケットメモリへの他のアクセスより高い優先順位を有することが保証される。
【００６４】
いくつかの場合に、ＰＭＭＵ２０９がストールしたのでＩＢ２０７が満杯になる可能性があり、したがって、ＬＰＭが、ストールが解決されるまでＩＢのデータをそれ以上消費しなくなる。ＩＢが満杯になった時には、必ず、信号がネットワーク入力インターフェース２０５に送られ、ネットワーク入力インターフェース２０５は、ＩＢが受け入れるまで、必要な回数だけ次の１６バイトチャンクを再送出する。したがって、ＩＢが満杯になることに起因して失われるパケットデータはない。
【００６５】
アウトバッファ（ＯＢ）
ネットワーク出力インターフェース２１５も、入力インターフェースと同様に、２０Ｇｂｐｓ（出力装置ごとに１０Ｇｂｐｓ）の総集計帯域幅をサポートする。３００ＭＨｚのＸＣａｌｉｂｅｒクロック周波数で、ネットワーク出力インターフェースは、ＯＢブロックから、すべてのＸＣａｌｉｂｅｒサイクルに平均８バイトのデータを受け入れ、２つの出力装置の１つにそれを送る。ネットワーク入力インターフェースおよびネットワーク出力インターフェースは、互いに完全に独立である。
【００６６】
２つまでのパケット（出力装置ごとに１つ）を、同時に送ることができる。パケットが送られる装置は、パケットを送る装置に対応する必要がない。送出されるパケットデータは、ＬＰＭ２１９またはＥＰＭ（図示せず）のいずれかから来る。
【００６７】
ネットワークアウトインターフェース２１５で接続された２つの出力装置のそれぞれについて、ＰＭＭＵ２０９は、ダウンロードされ始める準備ができたパケットまたはダウンロード中のパケットを有するか、ダウンロードすべきパケットを有しないことができる。すべてのサイクルに、ＰＭＭＵ２０９は、両方の出力装置にまたがって最高のパケットを選択し、そのパケットに関する１６バイトのデータのダウンロードを開始する。ＰＭＭＵが、パケットから出力装置にパケットデータをダウンロードしている時には、必ず、現在のパケットが完全にダウンロードされるまで、異なるパケットからのデータが、同一の装置にダウンロードされない。
【００６８】
ＬＰＭ２１９から読み取られた（関連する制御情報と共に）パケットデータの１６バイトチャンクは、２つの８エントリバッファ（装置識別子ごとに１つ）の１つに供給される。これらのバッファの１つの先頭の内容は、ネットワーク出力インターフェースがそれを要求する時に、必ずネットワーク出力インターフェースに供給される。両方のバッファの先頭が有効である時には、ＯＢが、ラウンドロビン式にデータを供給する。
【００６９】
ネットワーク入力インターフェースと異なって、ネットワーク出力インターフェースに送られる１６ビットチャンク内では、バイトｋが有効である場合に、バイト０からｋ−１も有効であることを保証できない。この理由は、パケットが送出される時に、メモリ内の１６バイトチャンクのバイト０から開始する必要がないからである。したがって、送出されるパケットの先頭を含むデータの１６バイトチャンクのそれぞれについて、ＯＢ２１７は、チャンクの第１の有効なバイトがどこに存在するかをネットワークインターフェースに通知する必要がある。さらに、パケットの最初の２バイトにバイト単位のパケットのサイズが含まれるので、ネットワーク出力インターフェースは、そのパケットの最後の１６バイトチャンクのデータ内にあるパケットの最後の有効なバイトを見つけるための情報を有する。さらに、ＯＢ２１７は、ＳＩＵ１０７に、それがパケットのＣＲＣを計算する必要があるかどうかと、必要な場合にＣＲＣのタイプを知らせる制御ビットも供給する。この制御ビットは、ＰＭＭＵ２０９によってＯＢ２１７に供給される。
【００７０】
ページングメモリ管理ユニット（ＰＭＭＵ）
パケットメモリアドレススペースは、１６ＭＢである。１６ＭＢのうちで、ＸＣａｌｉｂｅｒプロセッサは、２５６ＫＢオンチップを特徴とする。残り（または一部）は、外部ストレージを使用して実装される。
【００７１】
パケットメモリアドレススペースは、ＳＰＵ１０５のＴＬＢ内で、ユーザスペースまたはカーネルスペースとして、かつ、キャッシュ可能またはキャッシュ不能としてマッピングすることができる。キャッシュ可能としてマッピングされる場合に、パケットメモリスペースは、ＳＰＵ１０５のＬ１データキャッシュにキャッシュ（ライトスルー）されるが、Ｌ２キャッシュにはキャッシュされない。
【００７２】
ＰＭＭＵ２０９の目標は、着信パケット（およびＳＰＵが生成したパケットも）をパケットメモリに保管することである。ネットワーク入力インターフェースからのパケットがＬＰＭ２１９におさまる場合に、ＰＭＭＵ２０９は、それを保管する場所を決定し、ＬＰＭ２１９への必要な書込アクセスを生成するが、ネットワーク入力インターフェースからのパケットがＥＰＭに保管されようとしている場合には、ＳＰＵ１０５は、ＥＰＭ内のどこにパケットを保管する必要があるかを判定し、ＳＩＵ１０７が、パケットの保管を担当する。どちらの場合でも、パケットは、連続的に保管され、パケット識別子が、ＰＭＭＵ２０９によって作成され、ＱＳ２１１に送られる。
【００７３】
ＳＰＵ１０５は、所与のサイズより大きいパケットが絶対にＬＰＭに保管されないように、ＬＰＭ２１９を構成することができる。そのようなパケットならびに、余地がないのでＬＰＭにおさまらないパケットは、ＰＭＭＵ２０９によって、ＳＩＵ１０７を介してＥＰＭに送られる。これは、オーバーフローと呼ばれる機構であり、ＰＭＵがそれを行うようにＳＰＵによって構成される。パケットのオーバーフローが許容されない場合には、パケットがドロップされる。この場合には、ＰＭＭＵ２０９が、ＳＰＵに割り込む（やはり、そうするように構成されている場合）。
【００７４】
パケットメモリへのパケットのアップロード
ＩＢ２０５の先頭に有効なデータがある時には、必ず、対応する装置識別子ビットを使用して、データがどのパケット（受け取られる２つの可能なパケットのうちの）に属するかを判定する。ネットワーク入力インターフェースが、装置識別子ｄと共に新しいパケットのデータの送出を開始する時に、データの残りのすべてが、エラーがネットワークインターフェースブロックによって識別されないかぎり、結局、同一の装置識別子ｄと共に到着する。ネットワーク入力インターフェースは、２つの異なる装置識別子からのデータをインターリーブすることができるが、所与のサイクル内には、１つの装置からのデータだけがＩＢ２０７によって受け取られる。
【００７５】
パケットをＬＰＭ２１９に保管する必要がある時には、ＰＭＭＵ２０９が、ＬＰＭ２１９に対するすべての書込アドレスおよび書込ストローブを生成する。パケットをＥＰＭに保管する必要がある場合には、ＳＩＵ１０７がそれらを生成する。
【００７６】
図３は、ＬＰＭ２１９または、図３で要素３０５として示されているが図２に図示されていないＥＰＭのいずれかへのデータのアップロードを示す図である。ＬＰＭまたはＥＰＭへの書込ストローブは、ＩＢのヘッダが有効なデータを有しない場合には生成されない。書込ストローブが生成される時には、必ず、ＩＢの先頭のデータの１６バイトチャンク（ＬＭＰラインに対応する）が、ＩＢから削除され、ＬＰＭまたはＥＰＭに保管される。ＩＢの先頭の装置識別子ビットは、２つのアドレスジェネレータ（入力装置ごとに１つ）から正しい書込アドレスを選択するのに使用される。
【００７７】
現在の実施形態では、１つの着信パケットだけを、ＳＩＵによってＥＰＭに同時に保管することができる（すなわち、１時に１つのオーバーフローパケットだけを、ＳＩＵによって処理することができる）。したがって、オーバーフローを必要とする第２のパケットがネットワーク入力インターフェースによって送られる場合に、このパケットのデータは、捨てられる（すなわち、パケットがドロップされる）。
【００７８】
２バイトパケットサイズヘッダ
ネットワーク入力インターフェースは、必ず、外部装置から受信したパケットに２バイトを付加する（この外部装置がまだそれを行っていない場合。そうでない場合には、ＳＩＵが、それらを付加しないようにプログラムされる）。この付加されたデータは、２つの付加されたバイトを含む、パケット全体のバイト単位のサイズを示す。したがって、ＸＣａｌｉｂｅｒ  ＤＭＳプロセッサによって処理されるパケットの最大サイズは、最初の２バイトを含めて６５５３５バイトである。
【００７９】
ネットワーク出力インターフェースは、パケットがＰＭＵによって返される時に（その処理中にドロップされなかった場合）、最初の２バイトが、やはり処理されたパケットのサイズを示すことを期待する。元のパケットのサイズが、ＸＣａｌｉｂｅｒプロセッサによって実行される処理の結果として変更される可能性がある（パケットが増大または縮小する可能性がある）。したがって、処理が６４Ｋ−１バイトを超えるサイズの増加をもたらす場合には、そのパケットを２つの異なるより小さいパケットに分割することが、ソフトウェアの責任になる。
【００８０】
ＰＭＵは、受け取られるパケットの優先順位が前もってわかっている時に、より効率的である。外部装置が優先順位情報をＰＭＵに提供できる場合に、パケットの第３バイトが、優先順位のために使用される。ソフトウェアは、ＰＭＵを、このバイトの情報を使用するか否かについてプログラムし、これは、Ｌｏｇ２ＩｎＱｕｅｕｅｓと称するブート時構成レジスタを介して行われる。
【００８１】
パケットのドロップ
ＬＰＭ２１９またはＥＰＭ３０５のいずれかに完全に保管されたパケットは、ＳＰＵ１０５が、それをドロップするコマンドを明示的にＰＭＵに送った場合に限ってドロップされる。パケットメモリに既に保管されているパケットの自動的なドロップは、行うことができない。言い換えると、ＸＣａｌｉｂｅｒ  ＤＭＳプロセッサによって受け取られたパケットのドロップアルゴリズムは、すべて、ソフトウェアで実装される。
【００８２】
しかし、ＰＭＵが着信パケットをドロップする可能性がある、いくつかの情況が存在する。（ａ）パケットがＬＰＭにおさまらず、パケットのオーバーフローがディスエーブルされている、（ｂ）パケットに関する受け取られたバイトの総数が、ＡＳＩＣ固有ヘッダの最初の２バイトでＡＳＩＣによって指定されたバイト数と同一でない、または（ｃ）外部装置とＳＩＵのネットワーク入力インターフェースブロックの間で送信エラーが発生した場合がある。ＰＭＭＵブロックは、そのようなエラーについて通知される。
【００８３】
上のケース（ａ）、（ｂ）、および（ｃ）のそれぞれについて、ＳＰＵへの割込みが生成される。ソフトウェアは、ＡｕｔｏｍａｔｉｃＰａｃｋｅｔＤｒｏｐＩｎｔＥｎａｂｌｅ、ＰａｃｋｅｔＥｒｒｏｒＩｎｔＥｎａｂｌｅオンザフライ構成フラグを使用して、これらの割込みの生成をディスエーブルすることができる。
【００８４】
仮想ページ
ＰＭＭＵ２０９の重要な処理が、メモリ断片化をできる限り少なくして、パケットをＬＰＭ２１９に連続的に保管する効率的な方法を提供することである。好ましい実施形態のアーキテクチャでは、ＳＰＵ１０５に、ＬＰＭ２１９の同一の領域内で類似するサイズのパケットをできる限りグループ化する機能が与えられる。これによって、総合的なメモリ断片化が減る。
【００８５】
低断片化特徴を実装するために、ＬＰＭ２１９が、それぞれ６４ＫＢの４つのブロックに論理的に分割される。各ブロックは、２５６バイトの固定されたアトミックページに分割される。しかし、すべてのブロックが、２のべきの増分での２５６バイトから６４ＫＢまで範囲の仮想ページを有する。ソフトウェアは、ＶｉｒｔｕａｌＰａｇｅＥｎａｂｌｅと称するオンザフライ構成レジスタを使用して、４つのブロックのそれぞれについて仮想ページの異なるサイズをイネーブル／ディスエーブルすることができる。これによって、いくつかのブロックを、あるサイズまでのパケットを保管するように構成することができるようになる。
【００８６】
ＰＭＵの編成および特徴は、サイズｓのパケットが、ｓ未満の最大仮想ページサイズを有するブロックに絶対に保管されないことを保証する。しかし、ｒの最小仮想ページサイズを有するブロックは、ｒより小さいサイズのパケットを受け入れる。これは、通常は、たとえば、１つまたは複数の他のブロックがより小さいパケットを保管するように構成されているが、満杯である場合に、そうなる。
【００８７】
ソフトウェアは、ＬＰＭの４つのブロックのどれであっても所有権を得ることができ、これは、対応する６４ＫＢのメモリが、ソフトウェア管理になることを意味する。このために、ブロックごとに構成フラグ（ＳｏｆｔｗａｒｅＯｗｎｅｄ）が存在する。ＰＭＭＵブロックは、関連するＳｏｆｔｗａｒｅＯｗｎｅｄフラグがアサートされているＬＰＭのブロックには、ネットワーク入力インターフェースからの着信パケットを保管しない。同様に、ＰＭＭＵは、ＳｏｆｔｗａｒｅＯｗｎｅｄフラグがアサートされているブロックのメモリについて、ＧｅｔＳｐａｃｅ動作（他所で説明する）を満足しない。しかし、ＰＭＭＵは、ソフトウェア所有ブロックにソフトウェアによって保管されたパケットを、どれでもダウンロードすることができる。
【００８８】
ＰＭＭＵ論理は、着信パケットがＬＰＭのブロックのどれかにおさまるかどうかを判定する。パケットがおさまる場合に、ＰＭＭＵは、４つのブロックのどれにおさまるかを判定し（パケットが複数のブロックにおさまる可能性があるので）、選択されたブロック内でパケットが使用する最初および最後のアトミックページを判定する。アトミックページが、着信パケットのために割り振られる。アトミックページに保管されるパケットデータが、ネットワーク出力インターフェースを介してＸＣａｌｉｂｅｒプロセッサから安全に送出された時に、ＬＰＭ内の対応するスペースを割振り解除する（すなわち、他の着信パケットに使用可能にする）ことができる。
【００８９】
ＥＰＭは、ＬＰＮと同様に、２５６バイトのアトミックページに論理的に分割される。しかし、ＰＭＭＵは、これらのページの割振り状況を維持しない。これらのページの割振り状況は、ソフトウェアによって管理される。どのパケットを保存するかに無関係に、ＰＭＭＵは、パケットの最初のデータが保管される位置の、パケットメモリ内のオフセット（アトミックページ単位）を生成する。このオフセットを、今後、ｐａｃｋｅｔＰａｇｅと呼ぶ。パケットメモリの最大サイズは１６ＭＢなので、ｐａｃｋｅｔＰａｇｅは１６ビット値である。
【００９０】
ＰＭＭＵが、パケットをＬＰＭ内に安全に保管するか、パケットの最後のバイトがＥＰＭに安全に保管されたことの肯定応答をＳＩＵ１０７から受け取るや否や、そのパケットのために作成されたｐａｃｋｅｔＰａｇｅが、ＱＳに送られる。ＱＳの動作は、下の権能を付与する詳細で説明する。
【００９１】
ｐａｃｋｅｔＰａｇｅオフセットの生成
ＰＭＭＵは、ＩＢの先頭のパケットデータに関連する装置識別子（ｄｅｖｉｃｅＩｄ）を常に監視する。ｄｅｖｉｃｅＩｄが現在アクティブでない（すなわち、そのｄｅｖｉｃｅＩｄによって送信された前のパケットが完全に受信済みである）場合に、これは、ＩＢの先頭に新しいパケットの最初のデータが含まれることを示す。この場合には、最初の２バイト（１６バイトチャンクのバイト０およびバイト１）によって、バイト単位のパケットのサイズが指定される。新しい着信パケットのサイズの情報を用いて、ＰＭＭＵは、そのパケットがＬＰＭ２１９におさまるかどうかを判定し、そうである場合には、それが４つのブロックのどれに保管されるかと、そのブロック内の開始アトミックページおよび終了アトミックページを判定する。
【００９２】
パケットがＬＰＭ２１９におさまるかどうかを判定し、その場合にどのアトミックページが必要であるかを判定する、ＰＭＭＵの現在の実施形態での必要なスループットは、２サイクルごとに１パケットである。１つの可能な２サイクル実装は、次のようになる：（ａ）判定が１サイクルで行われ、１時に１つの判定だけが行われ、（ｂ）判定の次のサイクルに、パケットを保管するのに必要なアトミックページが、割り振られ、仮想ページの新しい状態（割振り済み／割振り解除）を計算する。このサイクルでは、判定は許容されない。
【００９３】
図４ａは、ローカルパケットメモリに関する、並列の判定および割振りを示す図である。判定論理は、図示のように、４つの６４ＫＢブロックのすべてについて並列に実行される。
【００９４】
図４ｂに、４つの６４ＫＢブロックのそれぞれについて維持される必要がある状態を示す。この状態は、ＡｌｌｏｃａｔｉｏｎＭａｔｒｉｘと呼ばれ、１つまたは複数のアトミックページが割り振られるか割振り解除されるたびに再計算され、判定論理の入力である。ＦｉｔｓＶｅｃｔｏｒおよびＩｎｄｅｘＶｅｃｔｏｒに、ＡｌｌｏｃａｔｉｏｎＭａｔｒｉｘから計算される情報が含まれる。
【００９５】
ＡｌｌｏｃａｔｉｏｎＭａｔｒｉｘ［ＶＰＳｉｚｅ］［ＶＰＩｎｄｅｘ］は、バイト単位のサイズＶＰＳｉｚｅの仮想ページ番号ＶＰＩｎｄｅｘが既に割り振られているか否かを示す。ＦｉｔｓＶｅｃｔｏｒ［ＶＰＳｉｚｅ］は、ブロックが、少なくとも１つの割り振られていないサイズＶＰＳｉｚｅの仮想ページを有するかどうかを示す。ＦｉｔｓＶｅｃｔｏｒ［ＶＰＳｉｚｅ］がアサートされている場合には、ＩｎｄｅｘＶｅｃｔｏｒ［ＶＰＳｉｚｅ］ベクトルに、サイズＶＰＳｉｚｅの割り振られていない仮想ページのインデックスが含まれる。
【００９６】
ＳＰＵは、どの仮想ページサイズがイネーブルされているかをブロックのそれぞれについてプログラムする。ＥｎａｂｌｅＶｅｃｔｏｒ［ＶＰＳｉｚｅ］にこの情報が含まれる。この構成は、ＶｉｒｔｕａｌＰａｇｅＥｎａｂｌｅオンザフライ構成レジスタを使用して実行される。対応するＳｏｆｔｗａｒｅＯｗｎｅｄフラグがアサートされている場合に、ＡｌｌｏｃａｔｉｏｎＭａｔｒｉｘ［］［］、ＦｉｔｓＶｅｃｔｏｒ［］、ＩｎｄｅｘＶｅｃｔｏｒ［］、およびＥｎａｂｌｅＶｅｃｔｏｒ［］が、ドントケアであることに留意されたい。
【００９７】
この例では、判定論理のアルゴリズム（サイズｓバイトのパケットに関する）が、次のようになる。
【００９８】
１）Ｆｉｔｓ論理：ブロックのそれぞれについて、パケットがおさまるか否かを検査する。おさまる場合に、仮想ページサイズと、そのサイズの最初の仮想ページの番号を記憶する。
【数１】
0003801919.tif 000002
【００９９】
２）ブロック選択：パケットをおさめることができる最小の仮想ページ（イネーブルされていてもいなくても）を有するブロックが候補である。最小のイネーブルされた仮想ページを有するブロックを選択する。
【数２】
0003801919.tif 000003
0003801919.tif 000004
【０１００】
パケットがＬＰＭにおさまる場合に、作成されるｐａｃｋｅｔＰａｇｅは、パケットの最初のデータが保管されるＬＰＭ内のアトミックページの番号（ＬＰＭ内には１Ｋ個までの異なるアトミックページがある）になる。パケットがおさまらない場合には、ｐａｃｋｅｔＰａｇｅは、構成レジスタＯｖｅｒｆｌｏｗＡｄｄｒｅｓｓの内容を右に８ビットシフトしたものになる。パケットオーバーフロー機構を、副題「パケットオーバーフロー」の下で、本明細書の他所で説明する。
【０１０１】
パケットをどこに保管するかの判定の次のサイクルに、選択されたブロックについて、ＡｌｌｏｃａｔｉｏｎＭａｔｒｉｘ、ＦｉｔｓＶｅｃｔｏｒ、およびＩｎｄｅｘＶｅｃｔｏｒの新しい値を再計算しなければならない。ＦｉｔｓＶｅｃｔｏｒ［ＶＰＳｉｚｅ］がアサートされる場合には、ＩｎｄｅｘＶｅｃｔｏｒ［ＶＰＳｉｚｅ］が、対応する仮想ページサイズについて可能な最大の割り振られていない仮想ページのインデックスである。ＦｉｔｓＶｅｃｔｏｒ［ＶＰＳｉｚｅ］がデアサートされる場合には、ＩｎｄｅｘＶｅｃｔｏｒ［ＶＰＳｉｚｅ］は未定義である。
【０１０２】
パケットを保管するのに必要なアトミックページの数を計算し（ＮｕｍＡＰｓ）、対応するアトミックページを割り振る。選択されたブロック（Ｂ）に関するアトミックページの割振りは、下記のように行われる。
【０１０３】
１．ｊが最初のアトミックページ、ｋが最後のアトミックページ（ｋ−ｊ＋１＝ＮｕｍＡＰｓ）であるものとして、ＡｌｌｏｃａｔｉｏｎＭａｔｒｉｘ［ＡＰｓｉｚｅ］［ｊ．．ｋ］内のアトミックページの割振り状況に、割振り済みをセットする。
【０１０４】
２．ＡｌｌｏｃａｔｉｏｎＭａｔｒｉｘ［ｒ］［ｓ］の仮想ページの割振り状況を、図４ｂのメッシュ構造に従って更新する。（２ｋ＋１バイト仮想ページを構成する２つの２ｋバイト仮想ページのいずれかが割り振られる場合に、２ｋ＋１バイト仮想ページが割り振られる）。
【０１０５】
ｐａｃｋｅｔＰａｇｅが生成された時に、そのｐａｃｋｅｔＰａｇｅが、エンキューのためにＱＳに送られる。ＱＳは、満杯の場合（非常にまれ）に、ＰＭＭＵによって供給されるｐａｃｋｅｔＰａｇｅを受け入れることができない。この場合には、ＰＭＭＵは、次の新しいパケットのために新しいｐａｃｋｅｔＰａｇｅを生成することができなくなる。これがＩＢに圧力をかけ、ＩＢは、ＱＳが複数サイクルにわたって満杯のままである場合に満杯になる可能性がある。
【０１０６】
ＰＭＭＵブロックは、ＱＳがｐａｃｋｅｔＰａｇｅを保管しなければならないキュー番号も送る。ＰＭＭＵがこのキュー番号を生成する方法は、下で特にＱＳに割り当てられた節で説明する。
【０１０７】
ページ割振りの例
図５ａおよび５ｂに、アトミックページを割り振る方法の例を示す。簡単にするために、この例では、それぞれ２ＫＢの２つのブロック（０および１）があり、アトミックページサイズが２５６バイトであり、両方のブロックがＳｏｆｔｗａｒｅＯｗｎｅｄフラグをデアサートされていると仮定する。単一および二重の斜線区域は、割り振られた仮想ページを表す（単一の斜線のページは、現在のサイクルで割り振られるページに対応する）。この例では、２５６バイト、５１２バイト、１Ｋバイト、および５１２バイトのパケットサイズのシーケンスについて、ページがどのように割り振られるかを示す。このシーケンスの後に、たとえば２Ｋバイトパケットが、この例のＬＰＭにおさまらないことに留意されたい。
【０１０８】
ＦｉｔｓＶｅｃｔｏｒ［ＶＰＳｉｚｅ］がアサートされる時には、必ず、ＩｎｄｅｘＶｅｃｔｏｒ［ＶＰＳｉｚｅ］に、仮想ページサイズＶＰＳｉｚｅの最大の割り振られていない仮想ページインデックスが含まれる。最大のインデックスを選択する理由は、メモリスペースがよりよく利用されるからである。これを、図６ａおよび６ｂに示すが、この図では、２つの２５６バイトパケットが、１ブロックに保管されている。シナリオＡでは、２５６バイト仮想ページが、ランダムに選択されるが、シナリオＢでは、最大のインデックスが必ず選択される。図からわかるように、シナリオＡのブロックでは、２つの５１２バイト仮想ページだけが許容されるが、シナリオＢのブロックでは、３つが許容される。しかし、両方が、同数の２５６バイトパケットを許容するが、これは、このサイズが最小の割振り単位であるからである。常に最小の仮想ページインデックス番号を選択することによって、同一の効果が得られることに留意されたい。
【０１０９】
パケットオーバーフロー
パケットをＬＰＭに保管できない理由は、次の２つだけである。（ａ）パケットのサイズが、４つのすべてのブロックにまたがってイネーブルされた最大の仮想ページより大きい、または（ｂ）パケットのサイズが、イネーブルされた最大仮想ページ以下であるが、ＬＰＭ内で余地を見つけることができない。
【０１１０】
パケットがＬＰＭにおさまらない時には、ＰＭＭＵが、ＳＩＵを介してＥＰＭにパケットをオーバーフローさせる。それを行うために、ＰＭＭＵは、パケットが保管される初期アドレスをＳＩＵに供給する（パケットメモリ内の１６バイトオフセット）。この２０ビットアドレスは、次のようにして得られる。（ａ）１６ＭＳＢビットは、ＯｖｅｒｆｌｏｗＡｄｄｒｅｓｓ構成レジスタの１６ＭＳＢビットに対応する（すなわち、パケットメモリ内のアトミックページ番号）。（ｂ）４ＬＳＢビットは、ＨｅａｄｅｒＧｒｏｗｔｈＯｆｆｓｅｔ構成レジスタに対応する。このオーバーフローされるパケットのｐａｃｋｅｔＰａｇｅ値（ＱＳに送られる）は、ＯｖｅｒｆｌｏｗＡｄｄｒｅｓｓ構成レジスタの１６ＭＳＢビットである。
【０１１１】
オンザフライ構成フラグＯｖｅｒｆｌｏｗＥｎａｂｌｅがアサートされている場合に、ＰＭＭＵは、ＯｖｅｒｆｌｏｗＳｔａｒｔｅｄＩｎｔ割込みを生成する。ＯｖｅｒｆｌｏｗＳｔａｒｔｅｄＩｎｔ割込みが生成される時に、オーバーフローされるパケットのバイト単位のサイズが、ＰＭＭＵによって、ＳＰＵ読取専用構成レジスタＳｉｚｅＯｆＯｖｅｒｆｌｏｗｅｄＰａｃｋｅｔに書き込まれる。この時点で、ＰＭＭＵは、新しいパケットのオーバーフローを防ぐ内部ロックフラグをセットする。このロックフラグは、ソフトウェアがオンザフライ構成レジスタＯｖｅｒｆｌｏｗＡｄｄｒｅｓｓに書き込む時にリセットされる。パケットのオーバーフローが必要であるが、ロックフラグがセットされている場合には、そのパケットがドロップされる。
【０１１２】
この機構を用いて、オーバーフローされるパケットごとに１つの割込みだけが生成され、サービスされることが保証される。これによって、オーバーフローされる次のパケットが保管される開始アドレスが、ＳｉｚｅＯｆＯｖｅｒｆｌｏｗｅｄＰａｃｋｅｔレジスタを介して割り込みサービスルーチンに可視になる場所をソフトウェアが決定するためのプラットフォームも作られる。言い換えると、ソフトウェアがＥＰＭを管理する。
【０１１３】
ソフトウェアが、２つのＯｖｅｒｆｌｏｗＳｔａｒｔｅｄＩｎｔ割込みの間にＯｖｅｒｆｌｏｗＡｄｄｒｅｓｓを複数回書き込む場合には、その結果は未定義である。さらに、ソフトウェアが、ＯｖｅｒｆｌｏｗＡｄｄｒｅｓｓの１６ＭＳＢビットに０から１０２３をセットする場合に、パケットメモリ内の最初の１ＫアトミックページがＬＰＭに対応するので、その結果も未定義である。
【０１１４】
パケットメモリからのパケットのダウンロード
結局、ＳＰＵは、パケットの処理を完了し、その事実をＱＳに知らせる。この時点で、パケットを、ＬＰＭまたはＥＰＭのいずれかのメモリからダウンロードし、ＯＢを介して、接続された装置の１つに送信することができる。図７は、パケットのダウンロードに使用されるＸＣａｌｉｂｅｒ  ＤＭＳプロセッサのブロックの最上位の概略であり、図７の要素は、図２と同一の符号を付されている。ダウンロード処理は、以下の説明の助けを得て図７で追跡することができる。
【０１１５】
ＱＳ２１１が、パケットの処理が完了したことを知らされた時に、ＱＳは、このパケットを完了としてマークし、数サイクル後（パケットの優先順位に依存する）に、ＱＳが、パケットに関する下記の情報をＰＭＭＵ２０９に供給する（ＰＭＭＵがそれを要求する限り）。
（ａ）ｐａｃｋｅｔＰａｇｅ
（ｂ）優先順位（それが抽出された元のクラスタ番号）
（ｃ）末尾増大／縮小情報（本明細書で後で説明する）
（ｄ）アウトバウンド装置識別子ビット
（ｅ）ＣＲＣタイプフィールド（本明細書で後で説明する）
（ｆ）ＫｅｅｐＳｐａｃｅビット
【０１１６】
ＰＭＭＵブロック２０９に送られる装置識別子は、パケットが送信される外部装置を指定する１ビット値である。このアウトバウンド装置識別子は、ソフトウェアによって、２ビット値としてＱＳ２１１に供給される。
【０１１７】
パケットがＬＰＭ２１９に保管された場合には、ＰＭＭＵ２０９が、ＬＰＭ２１９への（１６ビットライン）読取アドレスおよび読取ストローブのすべてを生成する。読取アドレスが計算され、ＬＰＭ２１９から読み取られるラインをバッファリングするのに十分な余地がＯＢ２１７にあると、すぐに、読取ストローブが生成される。ＯＢ内のバッファｄが、装置識別子ｄに関連付けられる。このバッファは、２つの理由すなわち、（ａ）外部装置ｄが、一時的にＸＣａｌｉｂｅｒからのデータを受け入れないか、（ｂ）ＯＢからの読取データの速度が、それに書き込まれるデータの速度より低いのいずれかである場合に、満杯になる可能性がある。
【０１１８】
アトミックページ内のパケットデータが、すべてダウンロードされ、ＯＢに送られると、すぐに、そのアトミックページを割振り解除することができる。１つまたは複数のアトミックページの割振り解除は、上で説明したものと同一の手順に従う。しかし、ＬＰＭビットがデアサートされている場合には、アトミックページの割振り解除は行われない。パケットがＥＰＭ７０１にある場合には、ＫｅｅｐＳｐａｃｅビットがドントケアになる。
【０１１９】
パケットがＥＰＭ７０１に保管された場合には、ＰＭＭＵ２０９は、パケットの最初のバイトがあるＥＰＭ内のアドレスをＳＩＵ１０７に供給する。ＳＩＵは、ＥＰＭからのパケットのダウンロードを実行する。ＳＩＵは、ＯＢ２１７内の対応するバッファ内のバッファスペースも監視して、ＥＰＭ７０１から読み取られる１６バイトチャンクを書き込む余地があるかどうかを判定する。パケットが完全にダウンロードされた時に、ＳＩＵは、その事実についてＰＭＭＵに知らせ、その結果、ＰＭＭＵが、同一の装置識別子を有する次のパケットをダウンロードできるようにする。
【０１２０】
２つのパケット（装置ごとに１つ）が、同時に送信されている時に、最高優先順位のパケットからのデータが、まずメモリから読み出される。このプリエンプションは、１６バイト境界で、またはパケットがその伝送を終了した時に、発生する可能性がある。両方のパケットが同一の優先順位（ＱＳによって供給される）を有する場合には、ラウンドロビン法を使用して、データを次にダウンロードされるパケットを選択する。この選択論理では、ＯＢ内の２つのバッファがどれほど満杯であるかも考慮に入れる。たとえばバッファｄが満杯である場合に、装置識別子ｄを有するパケットは、データの次の１６バイトチャンクのダウンロードのためにＰＭＭＵ内で選択されなくなる。
【０１２１】
パケットが、パケットメモリ（ローカルまたは外部）からのダウンロードを開始される時に、ＰＭＭＵは、パケットの最初の有効なバイトがどこに存在するかを知っている。しかし、パケットのサイズは、パケットデータの最初のライン（または、いくつかの場合に最初の２ライン）がパケットメモリから読み取られるまで未知である。というのは、パケットのサイズが、パケットデータの最初の２バイトに含まれるからである。したがって、パケットのダウンロードの処理では、まず、パケットのサイズを判定するのに必要なラインアドレスを生成し、その後、必要な場合に、アクセスの残りを生成する。
【０１２２】
この論理では、パケットのサイズを指定する最初の２バイトが、データの１６バイトライン内のどの位置にも存在する可能性があることを考慮に入れる。特定のケースが、最初の２バイトが２つの連続するラインにまたがる時である（これは、最初のバイトがラインの第１６バイトであり、第２バイトが次のラインの第１バイトである時に発生する。
【０１２３】
ＰＭＭＵが、パケットのダウンロードを終了する（パケットのすべてのデータがパケットメモリから読み取られ、ＯＢに送られた）とすぐに、ＰＭＭＵが、このイベントについてＱＳに通知する。ＱＳは、対応するパケットをそのキューイングシステムから無効化する。
【０１２４】
パケットのダウンロードが開始される時に、パケットを先取りすることができない、すなわち、パケットが、その送信を終了する。同一のアウトバウンド装置識別子を有する、ダウンロードの準備ができた他のパケットは、前のパケットが送信されつつある間は、前のパケットが完全に送信されるまで送信することができない。
【０１２５】
パケットの増大／縮小
パケットの処理の結果として、ネットワークパケットのサイズが、増大、縮小、または同一サイズにとどまる可能性がある。サイズが変化する場合には、ＳＰＵが、パケットの同一の最初の２バイトにパケットの新しいサイズを書き込まなければならない。パケットの増大および縮小の現象を、図８に示す。
【０１２６】
パケットのヘッダと末尾の両方が、増大または縮小することができる。パケットが増大する時に、追加されるデータによって、ヘッダ増大を経験するパケットの直前に保管されていた可能性がある別のパケットまたは末尾増大の場合には真後に保管された別のパケットのデータが上書きされる可能性がある。この問題を避けるために、パケットがパケットメモリに保管される時に、すべてのパケットの前後に空のスペースが割り振られるようにＰＭＵを構成することができる。これらの空のスペースは、それぞれＨｅａｄｅｒＧｒｏｗｔｈＯｆｆｓｅｔおよびＴａｉｌＧｒｏｗｔｈＯｆｆｓｅｔというブート時構成レジスタを用いて指定され、これらのレジスタの粒度は、１６バイトである。最大のＨｅａｄｅｒＧｒｏｗｔｈＯｆｆｓｅｔは２４０バイト（１５個の１６バイトチャンク）であり、最大のＴａｉｌＧｒｏｗｔｈＯｆｆｓｅｔは、１００８バイト（６３個の１６バイトチャンク）である。どちらの場合でも、最小値は０バイトである。これらの増大オフセットが、すべての着信パケットに適用される、すなわち、異なる増大オフセットを異なるパケットに適用する機構がないことに留意されたい。
【０１２７】
ＰＭＭＵは、ＬＰＭ内のスペースを検索する時に、Ｓｉｚｅ（ｐａｃｋｅｔ）＋（（ＨｅａｄｅｒＧｒｏｗｔｈＯｆｆｓｅｔ＋ＴａｉｌＧｒｏｗｔｈＯｆｆｓｅｔ）＜＜４）の連続したスペースを探す。したがって、パケットの最初のバイト（ＡＳＩＣ固有ヘッダの最初のバイト）は、実際には、パケットメモリ内のオフセット（（ｐａｃｋｅｔＰａｇｅ＜＜８）＋（ＨｅａｄｅｒＧｒｏｗｔｈＯｆｆｓｅｔ＜＜４））から始まる。
【０１２８】
ソフトウェアは、デフォルトオフセットがいくつであるかを知っており、したがって、パケットが先頭と末尾の両方でどれだけ安全に増大できるかを知っている。パケットが最大オフセットを超えて増大する必要がある場合には、ソフトウェアは、パケットメモリ内の新しい位置にパケットを明示的に移動しなければならない。これを行うステップは、次の通りである。
【０１２９】
１）ソフトウェアが、ＰＭＵに、新しいサイズの連続したスペースのチャンクを要求する。ＰＭＵは、この新しいスペースを識別する（ポイントする）新しいｐａｃｋｅｔＰａｇｅを返す。
【０１３０】
２）ソフトウェアが、データを新しいメモリスペースに書き込む。
【０１３１】
３）ソフトウェアが、新しいｐａｃｋｅｔＰａｇｅを用いて古いｐａｃｋｅｔＰａｇｅの名前を変更する。
【０１３２】
４）ソフトウェアが、ＰＭＵに、古いｐａｃｋｅｔＰａｇｅに関連付けられたスペースを割振り解除するように要求する。
【０１３３】
ヘッダ増大または縮小の場合に、パケットデータは、もはや（（ｐａｃｋｅｔＰａｇｅ＜＜８）＋（ＨｅａｄｅｒＧｒｏｗｔｈＯｆｆｓｅｔ＜＜４））から始まらない。新しい開始位置は、パケットの処理が完了した時にＳＰＵによって実行される特殊な命令を用いてＰＭＵに供給される。この情報が、ＱＳブロックによってＰＭＭＵに供給される。
【０１３４】
タイムスタンプ
ＰＭＵ（次の節で詳細に説明する）のＱＳブロックは、ＸＣａｌｉｂｅｒプロセッサ内で処理中のパケットのｐａｃｋｅｔＰａｇｅ識別子をＦＩＦＯ様キューに保存することによって、着信パケットの順序を保証する。しかし、ソフトウェアは、ＱＳから明示的に識別子を抽出し、それらをキューのいずれかの末尾に挿入することによって、この順序付けを破ることができる。
【０１３５】
ソフトウェアがパケットの相対順序を保証するのを助けるために、ＰＭＭＵブロックに到着するすべてのパケットにタイムスタンプを付けるように、オンザフライ構成フラグＴｉｍｅＳｔａｍｐＥｎａｂｌｅｄを使用してＰＭＵを構成することができる。タイムスタンプは、８バイト値であり、コアクロックサイクルごとに増分される６４ビットカウンタから得られる。
【０１３６】
タイムスタンプ機能がオンである時には、ＰＭＭＵが、各パケットの前に８バイトタイムスタンプ値を付加し、タイムスタンプは、パケットがネットワーク出力インターフェースに送られる時にはぎとられる。タイムスタンプ値は、必ず、パケットメモリの第（ｋ−１）１６バイトチャンクの８ＭＳＢバイトを占め、ここで、ｋは、パケットのデータが開始される１６バイトラインオフセットである（ｋ＞０）。ＨｅａｄｅｒＧｒｏｗｔｈＯｆｆｓｅｔが０の場合には、タイムスタンプ値は、ＴｉｍｅＳｔａｍｐＥｎａｂｌｅｄがアサートされている場合であっても、付加されない。
【０１３７】
完全な６４ビットタイムカウンタ値は、読取専用構成レジスタ（ＴｉｍｅＣｏｕｎｔｅｒ）を介してソフトウェアに供給される。
【０１３８】
ＰＭＭＵでのソフトウェア動作
ソフトウェアは、ＰＭＭＵにアクセスして、連続するスペースのチャンクを要求するか解放する。具体的に言うと、ソフトウェアがＰＭＭＭＵに対して実行できる２つの動作がある。まず、ソフトウェアは、動作ＧｅｔＳｐａｃｅ（ｓｉｚｅ）を介して、ＬＰＭ内でｓｉｚｅバイトの連続したスペースを見つけることを試みることができる。ＰＭＵは、見つかった連続するスペースが始まるアトミックページ番号（すなわちｐａｃｋｅｔＰａｇｅ）と、成功ビットを用いて応答する。ＰＭＵが、スペースを見つけることができた場合には、成功ビットに「１」がセットされ、そうでない場合には「０」がセットされる。ＳｏｆｔｗａｒｅＯｗｎｅｄ構成ビットがアサートされているメモリのブロックについては、ＧｅｔＳｐａｃｅは満足されない。したがって、ソフトウェアは、ソフトウェア所有のＬＰＭブロックのメモリスペースを明示的に管理する。
【０１３９】
ＰＭＭＵは、要求されたスペースに必要なアトミックページを割り振る。着信パケットのアトミックページの割振りに使用されるビットの組ＥｎａｂｌｅＶｅｃｔｏｒは、ＧｅｔＳｐａｃｅ動作ではドントケアである。言い換えると、ｓｉｚｅバイトを含むのに十分な連続する割り振られていないアトミックページが、特定のブロックに存在する限り、ＧｅｔＳｐａｃｅ（ｓｉｚｅ）動作は、そのブロック内のすべての仮想ページがディスエーブルされている場合であっても成功する。
【０１４０】
さらに、ソフトウェア所有でないブロックの中で、ＧｅｔＳｐａｃｅ動作は、まずその仮想ページのすべてをディスエーブルされているブロックを使用してサービスされる。そのようなブロックが複数存在する場合には、最も小さいブロック番号が選択される。ｓｉｚｅが０である場合には、ＧｅｔＳｐａｃｅ（ｓｉｚｅ）は「０」を返す。
【０１４１】
ソフトウェアがＰＭＭＵに対して実行できる第２の動作が、ＦｒｅｅＳｐａｃｅ（ｐａｃｋｅｔＰａｇｅ）である。この動作では、ＰＭＵが、前に割り振られたアトミックページ（ｐａｃｋｅｔＰａｇｅで始まる）を割振り解除する。このスペースは、着信パケットの結果としてＰＭＭＵによって自動的に割り振られたものまたはＧｅｔＳｐａｃｅコマンドの結果としてのいずれかであった可能性がある。ＦｒｅｅＳｐａｃｅは、結果をソフトウェアに返さない。ＳｏｆｔｗａｒｅＯｗｎｅｄビットをアサートされたブロックに対するＦｒｅｅＳｐａｃｅ動作は、無視される（何も行われず、結果がＳＰＵに返されない）。
【０１４２】
ローカルパケットメモリ
図２および７の２１９に示されたローカルパケットメモリ（ＬＰＭ）は、この実施形態では、２５６ＫＢのサイズ、バイトイネーブルを伴う１６バイトライン幅、２バンク（偶数／奇数）、バンクごとに１つの読取ポートと１つの書込ポートを有し、完全にパイプライン式であり、１サイクルの待ち時間を有する。
【０１４３】
パケット処理において、ＬＰＭは、ＰＭＭＵおよびＳＩＵの両方から読取要求および書込要求を受け取る。ＬＰＭコントローラが、ＰＭＭＵからの要求が最高の優先順位を有することを保証する。ＰＭＭＵは、別のパケットを書き込んでいる間に、多くとも１つのパケットを読み取る。ＬＰＭコントローラは、ＰＭＭＵが、必ずＬＰＭへの専用ポートを有することを保証する。
【０１４４】
悪意のあるソフトウェアが、ＰＭＭＵによって書き込まれている／読み取られているものと同一のデータを読み取る／書き込むことができる。したがって、同一サイクル内の読取アクセスと書込アクセスが、異なる１６バイトラインアドレスに対して実行されるという保証はない。
【０１４５】
ＬＰＭへの要求は、この例では、１６バイトの単一アクセス（読取または書込のいずれか）として定義される。ＳＩＵは、マスクドロードまたはマスクドストアに関する複数の要求を生成するが、これは、本発明人が知っている新しい命令であり、少なくとも１つの別の特許申請書の主題である。したがって、マスクドロード／ストア動作は、最高優先順位のＰＭＭＵアクセスが同一のポートを必要とする場合に、これらの複数の要求の途中でストールされる可能性がある。
【０１４６】
ＰＭＭＵが読み取るか書き込む時に、バイトイネーブル信号が、セットされていると仮定される（すなわち、ライン内の１６バイトのすべてが、読み取られるか書き込まれる）。ＳＩＵが読取または書込を行う時には、バイトイネーブル信号が、意味を持ち、ＳＩＵによって供給される。
【０１４７】
ＳＰＵが、ＬＰＭ内の単一のバイト／ワードを読み取る時に、ＳＩＵは、対応する１６バイトラインを読み取り、所望のバイト／ワードの抽出および右寄せを実行する。ＳＰＵが、単一のバイト／ワードを書き込む時には、ＳＩＵが、正しい位置にそのバイト／ワードを有する１６バイトラインと有効バイト信号を生成する。
【０１４８】
動作の間の優先順位付け
ＰＭＭＵは、３つの異なるソース（ＩＢ、ＱＳ、およびソフトウェア）から、動作を実行する要求を３つまで受け取ることができる。たとえば、連続するスペースのチャンクに関する検索を実行する要求と、対応するアトミックページサイズを割り振る要求と、生成されたｐａｃｋｅｔＰａｇｅを供給する要求が、ＩＢおよび／またはソフトウェアから来る場合がある。所与のｐａｃｋｅｔＰａｇｅに関連するアトミックページの割振り解除を実行する要求が、ＱＳおよび／またはソフトウェアから来る場合もある。
【０１４９】
これらの動作の最初の動作が、２つを超えないサイクルを要することと、第２の動作が、１つを超えないサイクルを要することが必要である。ＰＭＭＵは、１時に１つの動作だけを実行する。ＰＭＭＵブロックは、最高から最低への順で、ＩＢ、ＱＳ、およびソフトウェアからの要求に優先順位を与える。
【０１５０】
早期満杯ＰＭＭＵ検出
ＰＭＵは、外部装置とＸＣａｌｉｂｅｒプロセッサの間のフロー制御を助ける機構を実施する。この機構の一部は、ＬＰＭが満杯になることの検出であり、この場合には、ＳＰＵに対するＮｏＭｏｒｅＰａｇｅｓＯｆＸｓｉｚｅＩｎｔ割込みが生成される。ＥＰＭは、ソフトウェア制御であり、したがって、その状態は、ＰＭＭＵハードウェアによって維持されない。
【０１５１】
ソフトウェアは、仮想ページサイズｓを指定することによって、ＮｏＭｏｒｅＰａｇｅｓＯｆＸｓｉｚｅＩｎｔ割込みをイネーブルすることができる。ＰＭＭＵは、そのサイズの使用可能な仮想ページが使用可能でない（すなわち、すべてのブロックについてＦｉｔｓＶｅｃｔｏｒ［ｓ］がデアサートされている）ことを検出した時に、必ずこの割込みを生成する。選択された仮想ページサイズが大きいほど、割込みが早く生成される。仮想ページのサイズは、オンザフライ構成レジスタＩｎｔＩｆＮｏＭｏｒｅＴｈａｎＸｓｉｚｅＰａｇｅｓ内の４ビット値（０：２５６バイト、１：５１２バイト、…、８：６４ＫＢ）を用いて示される。この値が８を超える時には、割込みは絶対に生成されない。
【０１５２】
最小仮想ページサイズが選択される（２５６バイト）場合には、ＬＰＭが完全に満杯（すなわち、１バイトパケットであっても、これ以上パケットが受け入れられない）時に、ＮｏＭｏｒｅＰａｇｅｓＯｆＸｓｉｚｅＩｎｔ割込みが生成される。
【０１５３】
一般に、ＩｎｔＩｆＮｏＭｏｒｅＴｈａｎＸｓｉｚｅＰａｇｅｓがＸである場合に、最も早く割込みが生成されるのは、ローカルパケットメモリが（１００／２Ｘ）％満杯の時である。アトミックページが２５６バイトなので、ＬＰＭが、３Ｋバイトのパケットデータで満杯になる可能性がある（パケットごとに３バイト、各パケットが１アトミックページを使用）ことに留意されたい。
【０１５４】
パケットサイズ不一致
ＰＭＭＵは、何バイトがＬＰＭまたはＥＰＭにアップロードされているかを記憶する。このサイズが、最初の２バイトで指定されたサイズと異なる場合には、ＳＰＵに対するＰａｃｋｅｔＥｒｒｏｒＩｎｔ割込みが生成される。この場合に、不一致のパケットサイズを有するパケットは、ドロップされる（既に割り振られたアトミックページは、割振り解除され、ｐａｃｋｅｔＰａｇｅは作成されない）。この場合には、ＡｕｔｏｍａｔｉｃＤｒｏｐＩｎｔ割込みは生成されない。実際のサイズが、最初の２バイトで指定されたサイズより大きい場合には、ＡＳＣＩから受け取られつつある残りのパケットデータが、安全に破棄される。
【０１５５】
パケットサイズ不一致が、インバウンド装置識別子Ｄ（Ｄ＝０、１）で検出された時には、同一の装置識別子から受け取られるそれ以降のパケットが、ソフトウェアがＣｌｅａｒＥｒｒｏｒＤ構成レジスタに（なんらかの値を）書き込むまで、ドロップされる。
【０１５６】
バスエラー回復
不完全なパケットデータが、外部バスエラーに起因して、ＰＭＵに到着するかＰＭＵから出てゆく可能性がある。具体的に言うと、ネットワーク入力インターフェースが、送り込まれたデータの１６バイトチャンクがバスエラーを有することを通知する場合があり、また、ＳＩＵが、ＥＰＭからダウンロードされたデータの１６バイトチャンクがバスエラーを有することを通知する場合がある。どちらの場合でも、ＰＭＭＵは、ＰａｃｋｅｔＥｒｒｏｒＩｎｔ割込みを生成して、このイベントについてＳＰＵに通知する。他の情報は、ＳＰＵには供給されない。
【０１５７】
エラーがＬＰＭ内で生成される場合には、このオンチップメモリ内でエラー検出機構が実装されていないので、そのエラーが検出されないことに留意されたい。バスエラーが発生する時には、必ず、影響されたパケットのデータが、それ以上はＰＭＵによって受け取られなくなる。これは、どちらの場合でもＳＩＵによって行われる。第１の場合について、ＰＭＭＵは、エラーイベントの前に受け取ったパケットデータのために使用された既に割り振られているアトミックページを割振り解除するだけでよい。
【０１５８】
バスエラーが、インバウンド装置識別子Ｄ（Ｄ＝０、１）で検出される時には、同一の装置識別子から受け取られるそれ以降のパケットが、ソフトウェアがＣｌｅａｒＥｒｒｏｒＤ（Ｄ＝０、１）構成レジスタに（なんらかの値を）書き込むまでドロップされる。
【０１５９】
キューイングシステム（ＱＳ）
ＸＣａｌｉｂｅｒプロセッサのＰＭＵ内のキューイングシステム（ＱＳ）は、現在ＸＣａｌｉｂｅｒプロセッサ内で処理中のパケットのパケット識別子およびパケットの状態を保持する機能、デフォルトまたはソフトウェア供給の優先順位によってパケットをソートされた状態に保つ機能、使用可能なコンテキストの１つにプリロードされる必要がある（バックグラウンドで）パケットを選択する機能、および外部装置への送出の準備ができた処理済みパケットを選択する機能を有する。
【０１６０】
図９は、ＱＳと、ＰＭＵおよびＳＰＵ内の他のブロックとの間の高水準通信を示すブロック図である。ＰＭＭＵが、ｐａｃｋｅｔＰａｇｅを作成する時に、そのｐａｃｋｅｔＰａｇｅが、キュー番号および装置識別子と共にＱＳに送られる。ＱＳは、そのｐａｃｋｅｔＰａｇｅを対応するキューにエンキューし、そのパケットに番号（ｐａｃｋｅｔＮｕｍｂｅｒ）を関連付ける。結局、パケットが、選択され、ＲＴＵに供給され、ＲＴＵは、ｐａｃｋｅｔＰａｇｅ、ｐａｃｋｅｔＮｕｍｂｅｒおよびパケットヘッダの選択されたフィールドを、使用可能なコンテキストにロードする。結局、ＳＰＵが、そのコンテキストを処理し、他の情報の中でも、パケットの処理が完了するかパケットがドロップされた時を、ＰＭＵに通信する。この通信に関して、ＳＰＵは、パケット識別子としてｐａｃｋｅｔＮｕｍｂｅｒを供給する。ＱＳは、完了（最初のケースで）としてそのパケットをマークし、パケットは、結局、パケットメモリからのダウンロードのために選択される。
【０１６１】
同一のフロー（同一のソースおよび宛先）のパケットが、ＸＣａｌｉｂｅｒプロセッサに到着したのと同一の順序で外部装置に送出される必要がある（ソフトウェアが明示的にこの順序付けを壊さない限り）ことが、この実施形態の要件である（非常に望ましい）。ＳＰＵがパケットの処理を開始する時には、フローは知られていない。フロー内のパケットの順序付けの記憶は、必要な処理の量に起因して、また、応用分野によってはアクティブフローの数が非常に大きくなる可能性があるので、コストの高いタスクである。したがって、フロー内の順序は、通常は、アグリゲーテッドフローキューを使用することによって記憶される。アグリゲーテッドフローキューでは、異なるフローからのパケット識別子が、順序付けのために同一のフローからのものとして扱われる。
【０１６２】
ＱＳは、アグリゲーテッドフローキューの維持というコストの高いタスクを、ハードウェアでバックグラウンドで行うことによって、このタスクをオフロードする。現在の実施形態では、３２個までのアグリゲーテッドフローキューを維持することができ、これらのキューのそれぞれが、暗黙の優先順位を有する。ソフトウェアは、３２個までのキューのどれにでもｐａｃｋｅｔＰａｇｅをエンキューすることができ、あるキューから別のキューへｐａｃｋｅｔＰａｇｅ識別子を移動することができる（たとえば、そのパケットの優先順位がソフトウェアによって発見された時に）。ソフトウェアは、必要な場合に、同一のフローに属するパケットのすべてのｐａｃｋｅｔＰａｇｅ識別子を同一のキューにエンキューすることが期待される。そうでなければ、パケットが、同一のフロー内で順序はずれで送出されるので、ネットワークの性能の低下が発生する可能性がある。ソフトウェアの介入なしで、ＱＳは、フローごとの到着の順序を保証する。
【０１６３】
汎用キュー
ＱＳは、３２個までのＦＩＦＯ様キューの組を実装し、これらのキューは、３２キューの場合に、０から３１までの番号が付けられる。各キューは、２５６個までのエントリを有することができる。しかし、すべてのキューのすべてのエントリの合計が、２５６を超えることはできない。したがって、キューサイズは動的である。キューエントリは、ｐａｃｋｅｔＰａｇｅ識別子と他の情報を合わせたものに対応する。したがって、２５６個までのパケットが、所与の時点でＸＣａｌｉｂｅｒプロセッサ内で処理中であることを許容される。この最大値は、ソフトウェアには不可視である。
【０１６４】
ＱＳがｐａｃｋｅｔＰａｇｅをエンキューする時には、必ず、０から２５５までの番号（ｐａｃｋｅｔＮｕｍｂｅｒ）が、ｐａｃｋｅｔＰａｇｅに割り当てられる。この番号は、ｐａｃｋｅｔＰａｇｅの値と共にソフトウェアに供給される。ソフトウェアは、ＱＳに対する動作を実行したい時に、ｐａｃｋｅｔＮｕｍｂｅｒ識別子を供給する。この識別子は、ＱＳによって、ｐａｃｋｅｔＰａｇｅ（および対応するパケットに関連する他の情報）をそのキューの中およびキューの間で突き止めるのに使用される。
【０１６５】
ソフトウェアは、ＸＣａｌｉｂｅｒプロセッサ内のキューの最大の個数が３２であることを知っている。キューは、使用されない限りディスエーブルされる。すなわち、ソフトウェアは、何個のキューが必要であるかを前もって判断する必要がない。キューは、少なくとも１つのパケットがそのキューに存在する時にイネーブルされる。
【０１６６】
異なるキューからの複数のパケット識別子が、実行される特定の動作の候補になることができる。したがって、動作が最初に適用されるパケット識別子を選択するための、優先順位付け機構が存在しなければならない。ソフトウェアは、「オンザフライ」構成レジスタＰｒｉｏｒｉｔｙＣｌｕｓｔｅｒｓを使用して、キューの間での相対優先順位を（オンザフライで）構成することができる。これは、異なるキューをクラスタにグループ化する方法を指定する３ビット値である。各クラスタは、優先順位を関連付けられる（クラスタ番号が高いほど、優先順位が高い）。ＱＳを構成することができる現在の実施形態での６つの異なるモードを、図１０に示す。
【０１６７】
図１０の最初の列は、「オンザフライ」構成レジスタＰｒｉｏｒｉｔｙＣｌｕｓｔｅｒｓの値である。ソフトウェアは、この番号を制御し、それによってＱＳ構成が定義される。たとえば、ＰｒｉｏｒｉｔｙＣｌｕｓｔｅｒｓ＝２の場合に、ＱＳは、４つのクラスタに構成され、各クラスタに８つのキューがある。４つのクラスタの第１のクラスタが、キュー０から７を有し、第２のクラスタが、キュー８から１５を有し、第３のクラスタが、１６から２３、４つのクラスタの最後のクラスタが、キュー２４から３１を有する。
【０１６８】
クラスタ内のキューは、ラウンドロビン式に公平に扱われる。クラスタは、厳密な優先順位式に扱われる。したがって、すべてのキューの枯渇がないことを保証する唯一のモードが、３２個のキューの１つのクラスタを意味する、ＰｒｉｏｒｉｔｙＣｌｕｓｔｅｒｓが０である時である。
【０１６９】
ＱＳへのｐａｃｋｅｔＰａｇｅ／ｄｅｖｉｃｅＩｄの挿入
図１１は、この実施形態の、図２および７のＱＳ２１１の包括的なアーキテクチャを示す図である。ｐａｃｋｅｔＰａｇｅおよびＤｅｖｉｃｅＩｄの情報の挿入が、個々のキューに向かう矢印によって示されている（この例では３２個のキュー）。この情報は、３つの可能なソースすなわち、ＰＭＭＵ、ＳＰＵ、およびＱＳからの再挿入から挿入される可能性がある。複数のソースがＱＳへの挿入の準備ができているｐａｃｋｅｔＰａｇｅを有する場合のための、機能要素１１０１によって示される優先順位論理がある。この実施形態では、優先順位は、優先順位の降順で、ＰＭＭＵ、ＱＳ、およびＳＰＵ（ソフトウェア）である。
【０１７０】
ＳＰＵ（ソフトウェア）からのパケットの挿入に関して、ソフトウェアは、それ自体でパケットを作成することができる。それを行うために、ソフトウェアは、まず、所与のサイズの空きスペースの連続したチャンク（ＳＰＵドキュメンテーションを参照されたい）をＰＭＵに要求し、ＰＭＵが、スペースが見つかった場合にｐａｃｋｅｔＰａｇｅを返す。ソフトウェアは、パケットが結局送出されるようにするために、そのｐａｃｋｅｔＰａｇｅを明示的に挿入する必要がある。ＱＳがこのｐａｃｋｅｔＰａｇｅを挿入する時に、作成されたｐａｃｋｅｔＮｕｍｂｅｒがＳＰＵに返される。ソフトウェアは、コマンドユニットを介して挿入を要求する（図２を参照されたい）。
【０１７１】
ＱＳからの挿入の場合には、キューの先頭にあるエントリを、別のキューの末尾に移動することができる。この動作は、選択機能１１０３として図示されている。
【０１７２】
ＰＭＵからの挿入の場合には、パケットがＸＣａｌｉｂｅｒプロセッサに到着した時に、ＰＭＭＵが、パケットにｐａｃｋｅｔＰａｇｅを割り当て、対応するパケットがパケットメモリに安全に保管されるや否や、ｐａｃｋｅｔＰａｇｅがＱＳに送られる。
【０１７３】
キュー内の例示的なエントリが、要素１１０５として図示されており、これは、下記のフィールドを有する。Ｖａｌｉｄ（１）は、エントリを検証する。ＰａｃｋｅｔＰａｇｅ（１６）は、パケットによって使用されるメモリ内の最初のアトミックページ番号である。ＮｅｘｔＱｕｅｕｅ（５）は、このエントリが現在属するキュー番号と異なる場合があり、その場合には、この番号によって、エントリがキューの先頭に達した時にｐａｃｋｅｔＰａｇｅが次に挿入される必要があるキューを示す。Ｄｅｌｔａ（１０）には、パケットのヘッダが増大または縮小のいずれかを受けたバイト数が含まれる。この値は、２の補数でコード化される。Ｃｏｍｐｌｅｔｅｄ（１）は、ソフトウェアが対応するパケットの処理を終了したかどうかを示す単一ビットである。ＤｅｖｉｃｅＩｄ（２）は、パケットに関連する装置識別子である。Ｃｏｍｐｌｅｔｅ動作がパケットに対して実行される（下で説明する）前には、ＤｅｖｉｃｅＩｄフィールドに、パケットを送り込んだ外部装置の装置識別子が含まれる。Ｃｏｍｐｌｅｔｅ動作の後には、このフィールドに、パケットが送られる装置の装置識別子が含まれる。Ａｃｔｉｖｅ（１）は、関連するパケットが現在ＳＰＵによって処理中であるかどうかを示す単一ビットである。ＣＲＣｔｙｐｅ（２）は、ＣＲＣをパケットについて計算する必要がある場合に、そのＣＲＣのタイプをネットワーク出力インターフェースに示す。Ｃｏｍｐｌｅｔｅ動作がパケットに対して実行される前には、このフィールドは０である。ＫｅｅｐＳｐａｃｅ（１）は、パケットがＬＰＭ内で占めるアトミックページを、ＰＭＭＵが割振り解除する（ＫｅｅｐＳｐａｃｅがデアサートされている）か否か（ＫｅｅｐＳｐａｃｅがアサートされている）を指定する。パケットがＥＰＭに存在する場合には、このビットは、ＰＭＭＵによって無視される。
【０１７４】
ＱＳは、ｐａｃｋｅｔＰａｇｅが挿入されるキューの番号を知る必要がある。ソフトウェアがｐａｃｋｅｔＰａｇｅを挿入する時には、キュー番号が、ＸＳｔｒｅａｍパケット命令によって明示的に供給され、このＸＳｔｒｅａｍパケット命令は、ＳＰＵの機能であり、本明細書の他所で説明する。ｐａｃｋｅｔＰａｇｅが、ＱＳ自体によって挿入される場合には、キュー番号は、ｐａｃｋｅｔＰａｇｅが存在するエントリのＮｅｘｔＱｕｅｕｅフィールドの値である。
【０１７５】
ｐａｃｋｅｔＰａｇｅがＰＭＭＵによって挿入される時に、キュー番号は、ソフトウェアがＬｏｇ２ＩｎｐｕｔＱｕｅｕｅｓ構成レジスタを（ブート時に）どのように構成したかに依存する。Ｌｏｇ２ＩｎｐｕｔＱｕｅｕｅｓに０がセットされている場合には、着信パケットのすべてのｐａｃｋｅｔＰａｇｅが、同一のキューにエンキューされ、このキューは、オンザフライ構成レジスタＦｉｒｓｔＩｎｐｕｔＱｕｅｕｅによって指定される。Ｌｏｇ２ＩｎｐｕｔＱｕｅｕｅｓにｋ（１≦ｋ≦５）がセットされている場合には、パケットの第３バイトのｋ個のＭＳＢビットによって、キュー番号が決定される。したがって、外部装置（またはＳＩＵのネットワーク入力インターフェースブロック）は、ＰＭＵに送られるパケットのそれぞれについて、２５６個までの優先順位を割り当てることができる。ＱＳは、この２５６個の優先順位を、２ｋにマッピングし、キュー番号ＦｉｒｓｔＩｎｐｕｔＱｕｅｕｅからＦｉｒｓｔＩｎｐｕｔＱｕｅｕｅ＋２ｋ−１までを使用して、着信パケットのｐａｃｋｅｔＰａｇｅおよびｄｅｖｉｃｅＩｄ情報を挿入する。
【０１７６】
外部装置が、同一フローのすべてのパケットについて、第３バイトの同一の５ＭＳＢビットを送信することが期待される。そうでないと、パケットが同一のフロー内で順序はずれで外部装置に送り返される可能性があるので、ネットワークの性能の低下が発生する可能性がある。ソフトウェアは、外部装置（またはＳＩＵ）が第３バイトでパケットの優先順位の情報を提供できるか否かを知っている。
【０１７７】
ｐａｃｋｅｔＰａｇｅ  ｐがキューｑに挿入される時に、使用されるエントリのＰａｃｋｅｔＰａｇｅフィールドにｐがセットされ、Ｖａｌｉｄフィールドに「１」がセットされる。他のフィールドの値は、挿入のソースに依存する。ソースがソフトウェア（ＳＰＵ）である場合には、Ｃｏｍｐｌｅｔｅｄが「０」であり、ＮｅｘｔＱｕｅｕｅがＳＰＵによって供給され、ＤｅｖｉｃｅＩｄが「０」であり、Ａｃｔｉｖｅが「１」であり、ＣＲＣｔｙｐｅが０であり、ＫｅｅｐＳｐａｃｅが０であり、Ｐｒｏｂｅｄが０である。
【０１７８】
ソースがＱＳである場合には、残りのフィールドに、挿入されるｐａｃｋｅｔＰａｇｅが現在存在するエントリでそれらのフィールドが有する値が割り当てられる。ソースがＰＭＭＵである場合には、Ｃｏｍｐｌｅｔｅｄが「０」であり、ＮｅｘｔＱｕｅｕｅがｑであり、ＤｅｖｉｃｅＩｄが、パケットをＸＣａｌｉｂｅｒに送信した外部装置の装置識別子であり、Ａｃｔｉｖｅが「０」であり、ＣＲＣｔｙｐｅが０であり、ＫｅｅｐＳｐａｃｅが０であり、Ｐｒｏｂｅｄが０である。
【０１７９】
監視論理
ＱＳは、すべてのキューのエントリを監視して、ある状態を検出するか、エントリを再エンキューする、ダウンロードのためにＰＭＭＵにｐａｃｋｅｔＰａｇｅ（および他の情報）を送る、ｐａｃｋｅｔＰａｇｅ（および他の情報）をＲＴＵに送るなど、対応する動作を実行する。
【０１８０】
検出のすべてが、単一サイクルで行われ、並列に行われる。
【０１８１】
エントリの再エンキュー
ＱＳは、キューの先頭のエンティティのすべてを監視して、パケットを別のキューに移動する必要があるかどうかを判定する。再エンキューされる候補エントリは、有効であり、キューの先頭にあり、パケットが現在存在するキューのキュー番号と異なるＮｅｘｔＱｕｅｕｅフィールド値を有する必要がある。
【０１８２】
再エンキューの複数の候補が存在する場合には、選択されるエントリは、本明細書で後で説明する優先順位方式に従って選択される。
【０１８３】
ダウンロードのためのエントリのＰＭＭＵへの送出
ＱＳは、キューの先頭のエンティティのすべてを監視して、パケットがパケットメモリからのダウンロードを必要としているかどうかを判定する。この動作が、図１１の１１０２である。ＸＣａｌｉｂｅｒから送出される候補エントリは、有効であり、キューの先頭にあり、パケットが現在存在するキューのキュー番号と同一のＮｅｘｔＱｕｅｕｅフィールド値を有し、Ｃｏｍｐｌｅｔｅｄフラグをアサートされ、Ａｃｔｉｖｅフラグをデアサートされている必要がある。さらに、ＱＳは、ダウンロードコマンドをＱＳに発行したものと同一のコンテキストからの保留中の読取または書込が存在しないことを保証する必要がある。
【０１８４】
ダウンロードの候補が複数存在する場合には、選択されるエントリは、本明細書で後で説明する優先順位方式に従って選択される。
【０１８５】
選択された候補は、ＰＭＭＵがそれを要求した場合に、ＰＭＭＵに送られるのみである。候補が要求された場合に、選択されたｐａｃｋｅｔＰａｇｅが、それが抽出されたクラスタ番号、末尾増大／縮小、アウトバウンド装置識別子ビット、ＣＲＣｔｙｐｅおよびＫｅｅｐＳｐａｃｅビットと共に、ＰＭＭＵに送られる。
【０１８６】
図１２は、Ｄｅｖｉｃｅｉｄフィールドのコーディングを示す表である。Ｄｅｖｉｃｅｉｄフィールドが０である場合には、アウトバウンドデバイス識別子は、インバウンドデバイス識別子と同一であり、後は表に示された通りである。
【０１８７】
エントリがＰＭＭＵに送られる時に、そのエントリは、「送信中」としてマークされ、キューイングシステムから抽出される（その結果、そのエントリが、送信の準備ができている他のパケットをブロックせず、異なるアウトバウンド装置識別子に進むようになる）。しかし、エントリは、対応するパケットが完全にダウンロードされたことをＰＭＭＵが通知するまで、無効化されない。したがって、このエントリに対するプローブタイプの動作は、有効としてすなわち、まだＸＣａｌｉｂｅｒプロセッサ内に存在するものとして扱われる。
【０１８８】
リインカーネーション効果
上で説明したように、ＱＳは、０から２５５まで（合計２５６個の数）のｐａｃｋｅｔＮｕｍｂｅｒを、ＸＣａｌｉｂｅｒに到達し、キューに挿入されるパケットのそれぞれに割り当てる。これは、パケット識別子が挿入される２５６エントリのテーブルを維持することによって行われる。この時点で、パケット識別子のＶａｌｉｄビットもアサートされる。ＸＣａｌｉｂｅｒによって処理されるパケットの総数は２５６をはるかに超えるので、パケット番号は、もちろん、ＸＣａｌｉｂｅｒプロセッサの動作全体を通じて再利用されなければならない。したがって、パケットがダウンロードのために選択される時に、ある時点で、ｐａｃｋｅｔＮｕｍｂｅｒが、もはや進行中の有効なパケットに関連しなくなり、その番号を再利用できるようになる。
【０１８９】
パケットは、ＸＣａｌｉｂｅｒ内で有効である限り、当初に割り当てられたｐａｃｋｅｔＮｕｍｂｅｒに関連する。ｐａｃｋｅｔＮｕｍｂｅｒを再利用に使用可能にする通常の形は、処理の前にコンテキストにプリロードするためにパケットがＱＳによってＲＴＵに送られることである。その後、パケットが、完全に処理され、完全にメモリからダウンロードされた時に、ｐａｃｋｅｔＮｕｍｂｅｒを関連付けるテーブル内のパケット識別子が、Ｖａｌｉｄビットを操作することによって無効とマークされる（図１１および付随するテキストを参照されたい）。
【０１９０】
通常の動作では、これまでに説明したシステムが、完全に妥当である。しかし、発明人は、ＡｃｔｉｖｅビットおよびＶａｌｉｄビットが、ストリームの間の競合を回避するのに十分でない状況があることを発見した。これらの状況の１つが、時々ガーベジコレクションと称するクリーンアップ処理に関係し、この処理では、ソフトウェアが、すべてのパケット番号を監視して、パケットがシステム内に長くとどまりすぎている時を判定し、ある条件の下でパケットを破棄し、新たに到着するパケットのためにシステム内のスペースを解放する。
【０１９１】
ガーベジコレクションなどのこれらの特殊な動作では、ストリームが、パケットの所有権を得なければならず、ストリームがパケットに対して実行する動作が、実際に正しいパケットに対して実行されることを保証しなければならない。しかし、ソフトウェアがパケットをプローブする時に、処置を講ずる前に、複数のストリームが動作しているので、また、システムの通常の動作によって、パケットがたとえばＲＴＵにも送られる可能性があるので、これらの特殊な動作で、プローブされるパケットが、特殊な動作が完了する前に、別のストリームによって選択され、影響を受けることが、完全に可能である。パケットは、たとえば、ＲＴＵに送られ、処理され、ダウンロードされる可能性があり、新しいパケットが、そのｐａｃｋｅｔＮｕｍｂｅｒに割り当てられる可能性があり、その新しいパケットが、当初のパケットと正確に同一のｐａｃｋｅｔＰａｇｅに保管される可能性さえある。ガーベジコレクション処理でのパケットの破棄などの特殊な動作が、元々破棄のために選択されたパケットではなく、新しい完全に有効なパケットを破棄する危険性がある。これは、もちろん、トラブルにつながる可能性がある、潜在的に多数のそのような特殊な動作の１つにすぎない。
【０１９２】
上記を検討して、発明人は、時間上の２つの異なる絶対点、たとえば時刻ｓおよび時刻ｒを与えられて、時刻ｓでの有効なｐａｃｋｅｔＮｕｍｂｅｒと時刻ｒでの同一のｐａｃｋｅｔＮｕｍｂｅｒが、同一のパケットに関連付けられていることを保証する機構を提供した。単純なプローブ動作は、十分でない。というのは、ｓの後でｒの前のある時に関連するパケットがダウンロードされ、もう１つの（異なる）パケットが到着し、前のパケットと正確に同一のメモリ位置に保管され、ダウンロードされたパケットと同一のｐａｃｋｅｔＮｕｍｂｅｒを割り当てられている可能性があるからである。
【０１９３】
異なる時刻での特定のパケットとのｐａｃｋｅｔＮｕｍｂｅｒの関連を保証するためにＸＣａｌｉｂｅｒで実装された機構には、パケット識別子内のプローブビットが含まれる。ガーベジコレクションなどの処理を実行する第１のストリームが、パケットをプローブする時に、Ｐｒｏｂｅ＆Ｓｅｔと称する特殊なコマンドが使用される。Ｐｒｏｂｅ＆Ｓｅｔは、プローブビットをセット（アサート）し、Ｖａｌｉｄビット、Ａｃｔｉｖｅビット、ｐａｃｋｅｔＰａｇｅアドレス、およびプローブビットの古い値などの通常の情報が、返される。第１ストリームは、その後、本明細書の他所で説明するＣｏｎｄｉｔｉｏｎａｌ  Ａｃｔｉｖａｔｅ命令を実行して、パケットの所有権を得る。また、キューイングシステムは、このＣｏｎｄｉｔｉｏｎａｌ  Ａｃｔｉｖａｔｅ命令を実行する時に、パケットのアクティブビットをアサートする。第１ストリームによってプローブビットがセットされた後のどの時刻であっても、第２ストリームが、後に同一のパケットをプローブする時に、アサートされたプローブビットによって、第１ストリームがこのパケットの制御を得ようとしていることが示される。第２ストリームは、このパケットをそのままにしておくことを知る。このプローブビットは、パケットがＸＣａｌｉｂｅｒプロセッサに入り、新しい（有効でない）番号が割り当てられる時にデアサートされる。
【０１９４】
ＲＴＵへのエントリの送出
ＲＴＵは、ＳＰＵ内でＸＣａｌｉｂｅｒプロセッサに対してバックグラウンドで、到着し、パケットメモリに完全に保管されたパケットのヘッダのいくつかのフィールドをアップロードする。このバックグラウンドでのパケットのヘッダのアップロードは、同一のパケットに関して複数回行われる場合がある。ＱＳは、どのパケットをＲＴＵに送る必要があるかを記憶する。この選択動作が、図１１に１１０４として図示されている。
【０１９５】
ＲＴＵは、パケットをプリロードするコンテキストを選択する時に、かならず、対応するパケットがもはやインアクティブパケットでないことをＱＳに通知する。ＱＳは、そのパケットをアクティブとしてマークする。
【０１９６】
ＲＴＵに送られる候補エントリは、有効であり、ＡｃｔｉｖｅビットおよびＣｏｍｐｌｅｔｅｄビットをデアサートされた最も古いエントリであり、パケットが現在存在するキューのキュー番号と同一のＮｅｘｔＱｕｅｕｅフィールド値を有し、候補が存在するキュー内のある個数を超えないパケットがＳＰＵ内で現在処理されつつあるという制限に従う必要がる。この制限に関するさらなる詳細は、本明細書で後に提供する。エントリがプリロードのためにＲＴＵに送られる時に、対応するＡｃｔｉｖｅビットがアサートされる。
【０１９７】
キューは、既にＲＴＵに提示されたパケット識別子を有するエントリと、まだ提示されていないエントリを有することができる。すべてのキューが、ＲＴＵに送られる必要がある、そのキュー内で最も古いエントリをポイントするポインタ（ＮｅｘｔＰａｃｋｅｔＦｏｒＲＴＵ）を有する。キュー内では、パケット識別子が、キューに挿入されたのと同じ順序で、ＲＴＵに送られる。
【０１９８】
ＲＴＵに送られる候補パケット識別子は、キューに関連する異なるＮｅｘｔＰａｃｋｅｔＦｏｒＲＴＵによってポイントされる識別子である。しかし、これらのポインタのいくつかが、存在しないエントリをポイントする場合がある（たとえば、キューが空の時、またはすべてのエントリが既にＲＴＵに送られている時）。キューのそれぞれの状態を記憶するハードウェアが、これらの状態を判定する。ＮｅｘｔＰａｃｋｅｔＦｏｒＲＴＵポインタによってポイントされる有効なエントリであることのほかに、候補エントリは、現在ＲＴＵ内で別のエントリによって使用されていないＲＴＵ優先順位（本明細書で後に説明する）を関連付けられることが必要である。複数の候補が存在する場合には、選択されるエントリは、本明細書で後に説明する優先順位方式に従って選択される。
【０１９９】
エントリがダウンロードのためにＰＭＭＵに送られる場合と異なって、ＲＴＵに送られるエントリは、そのキューから抽出されない。そうではなく、対応するＮｅｘｔＰａｃｋｅｔＦｏｒＲＴＵポインタが更新され、対応するＡｃｔｉｖｅビットがアサートされる。
【０２００】
ＱＳは、エントリが有効な候補であり、ＲＴＵテーブル内の対応するスロットが空いている限り、ＲＴＵブロック内の８エントリテーブルにエントリを送る。ＲＴＵは、ＲＴＵがＳＰＵに対して生成できる割込みのそれぞれについて１つの、多くとも８つのエントリを受け入れる。
【０２０１】
ＱＳは、ＲＴＵに送りたいエントリ（それが存在するキュー番号によって与えられる）の優先順位を、ＲＴＵによって処理される８つの優先順位（ＲＴＵ優先順位）の１つにマッピングする。このマッピングを、図１３の表に示すが、このマッピングは、異なるキューがグループ化されるクラスタの数（構成レジスタＰｒｉｏｒｉｔｙＣｌｕｓｔｅｒｓ）およびエントリが存在するキュー番号に依存する。
【０２０２】
ＲＴＵは、ＲＴＵ優先順位ごとに１つの８エントリのテーブルを有する。各エントリには、パケット識別子（ｐａｃｋｅｔＰａｇｅ、ｐａｃｋｅｔＮｕｍｂｅｒ、キュー番号）と、それを検証するＶａｌｉｄビットが含まれる。ＲＴＵは、そのテーブルのエントリｐの対応するＶａｌｉｄビットがデアサートされている場合に、必ずＲＴＵ優先順位ｐのパケット識別子を受け入れる。ＲＴＵが、ＱＳからＲＴＵ優先順位ｐのパケット識別子を受け取る時に、テーブルのエントリｐのＶａｌｉｄビットがアサートされ、パケット識別子が保管される。その時に、ＱＳが、対応するＮｅｘｔＰａｃｋｅｔＦｏｒＲＴＵポインタを更新することができる。
【０２０３】
キュー内で送られるパケット数の制限
ソフトウェアが、キューごとに、アクティブにすることができる（すなわち、ＳＰＵ内のストリームのいずれかによって処理される）パケットの数を制限することができる。これは、ＭａｘＡｃｔｉｖｅＰａｃｋｅｔｓオンザフライ構成レジスタを介して達成され、このレジスタでは、キューごとに、そのキュー内でストリームによって処理されることができるパケットの最大個数に対応する、１と２５６の間の値が指定される。
【０２０４】
ＱＳは、キューｑの現在アクティブなパケットの数を記憶する、キューｑごとのカウンタを維持する。このカウンタは、パケット識別子がキューｑからＲＴＵに送られる時、Ｍｏｖｅ動作によってパケットがキューｑに移動される時、またはＩｎｓｅｒｔ動作によってパケット識別子がキューｑに挿入される時に、必ず増分され、下記の動作のいずれかがキューｑ内の有効なエントリ内で実行される時に減分される：Ｃｏｍｐｌｅｔｅ動作、Ｅｘｔｒａｃｔ動作、エントリを異なるキューに移動するＭｏｖｅ動作、またはエントリをいずれかのキュー（同一のキューを含む）に移動するＭｏｖｅＡｎｄＲｅａｃｔｉｖａｔｅ動作。Ｍｏｖｅ、ＭｏｖｅＡｎｄＲｅａｃｔｉｖａｔｅ、Ｉｎｓｅｒｔ、Ｃｏｍｐｌｅｔｅ、およびＥｘｔｒａｃｔは、本明細書の他所で説明する動作である。
【０２０５】
キューｑのカウンタの値が、ＭａｘＡｃｔｉｖｅＰａｃｋｅｔｓ構成レジスタで指定された対応する最大値以上である時には、必ず、キューｑのエントリが、ＲＴＵへの送出を許可されない。カウンタの値が、より大きくなる可能性があるのは、ソフトウェアが、変更の時点でカウンタ値より小さい値にキューのＭａｘＡｃｔｉｖｅＰａｃｋｅｔｓ構成レジスタを変更することができ、キューが移動または挿入のバーストを受け取ることができるからである。
【０２０６】
ＱＳに対するソフトウェア動作
ソフトウェアは、ＱＳに影響する複数の命令を実行する。下記は、ＸＳｔｒｅａｍパケット命令のＳＰＵコアによるディスパッチの結果としてＱＳに対して生成される可能性があるすべての命令のリストである。
【０２０７】
Ｉｎｓｅｒｔ（ｐ、ｑ）：ｐａｃｋｅｔＰａｇｅ  ｐを、キューｑに挿入する。挿入が成功であった場合には、ＳＰＵに「１」が返され、そうでない場合には「０」が返される。挿入は、使用可能なエントリがない時（すなわち、２５６個のエントリのすべてが有効である時）に限って不成功になる。
【０２０８】
Ｍｏｖｅ（ｎ、ｑ）：ｑに対して、ｐａｃｋｅｔＮｕｍｂｅｒ  ｎが存在するエントリのＮｅｘｔＱｕｅｕｅフィールドをアサートする。
【０２０９】
ＭｏｖｅＡｎｄＲｅａｃｔｉｖａｔｅ（ｗ、ｑ）：ｐａｃｋｅｔＮｕｍｂｅｒ  ｎが存在するエントリのＮｅｘｔＱｕｅｕｅフィールドをｑにアサートし、Ａｃｔｉｖｅビットをデアサートする。
【０２１０】
Ｃｏｍｐｌｅｔｅ（ｎ、ｄ、ｅ）：ｐａｃｋｅｔＮｕｍｂｅｒ  ｎが存在するエントリのＣｏｍｐｌｅｔｅｄフラグをアサートし、Ｄｅｌｔａフィールドをｄにアサートし、ｄｅｖｉｃｅＩｄフィールドをｅにアサートする。Ａｃｔｉｖｅビットをデアサートし、ＫｅｅｐＳｐａｃｅビットをデアサートする。
【０２１１】
ＣｏｍｐｌｅｔｅＡｎｄＫｅｅｐＳｐａｃｅ（ｎ、ｄ、ｅ）：Ｃｏｍｐｌｅｔｅ（）と同一であるが、ＫｅｅｐＳｐａｃｅビットをアサートする。
【０２１２】
Ｅｘｔｒａｃｔ（ｎ）：ｐａｃｋｅｔＮｕｍｂｅｒ  ｎが存在するエントリのＶａｌｉｄフラグをリセットする。
【０２１３】
Ｒｅｐｌａｃｅ（ｎ、ｐ）：ｐａｃｋｅｔＮｕｍｂｅｒ  ｎが存在するエントリのＰａｃｋｅｔＰａｇｅフィールドにｐａｃｋｅｔＰａｇｅ  ｐをセットする。
【０２１４】
Ｐｒｏｂｅ（ｎ）：ｐａｃｋｅｔＮｕｍｂｅｒ  ｎがＱＳ内に存在するか否かの情報をソフトウェアに返す。存在する場合には、ＰａｃｋｅｔＰａｇｅ、Ｃｏｍｐｌｅｔｅｄ、ＮｅｘｔＱｕｅｕｅ、ＤｅｖｉｃｅＩｄ、ＣＲＣｔｙｐｅ、Ａｃｔｉｖｅ、ＫｅｅｐＳｐａｃｅ、およびＰｒｏｂｅｄフィールドを返す。
【０２１５】
ＣｏｎｄｉｔｉｏｎａｌＡｃｔｉｖａｔｅ（ｎ）：ｐａｃｋｅｔＮｕｍｂｅｒ  ｎが有効であり、Ｐｒｏｂｅｄがアサートされ、Ａｃｔｉｖｅがデアサートされ、パケットが送信中でない場合に、「１」を返す。この場合に、Ａｃｔｉｖｅビットがアサートされる。
【０２１６】
ＱＳは、潜在的にアクティブにされているパケットのパケット識別子が、ＲＴＵテーブルにあり、プリロードを待っている、またはプリロードされているかどうかを判定するためにＲＴＵに照会する。パケット識別子がテーブル内にある場合に、ＲＴＵがそれを無効化する。キューが、たまたは同時にそのパケットのプリロードを開始する場合には、ＱＳはそのパケットをアクティブにしない。
【０２１７】
ＰｒｏｂｅＡｎｄＳｅｔ（ｎ）：Ｐｒｏｂｅ（）と同一であるが、Ｐｒｏｂｅｄビットをアサートする（返されるＰｒｏｂｅｄビットは、古いＰｒｏｂｅｄビットである）。
【０２１８】
Ｐｒｏｂｅ（ｑ）：キューｑ内のサイズ（すなわち、有効なエントリの数）を提供する。
【０２１９】
無効な（すなわち存在しない）ｐａｃｋｅｔＮｕｍｂｅｒに対するＭｏｖｅ（）、ＭｏｖｅＡｎｄＲｅａｃｔｉｖａｔｅ（）、Ｃｏｍｐｌｅｔｅ（）、ＣｏｍｐｌｅｔｅＡｎｄＫｅｅｐＳｐａｃｅ（）、Ｅｘｔｒａｃｔ（）、およびＲｅｐｌａｃｅ（）は、無視される（割込みが生成されない）。
【０２２０】
Ａｃｔｉｖｅビットがデアサートされている有効なｐａｃｋｅｔＮｕｍｂｅｒに対するＭｏｖｅ、ＭｏｖｅＡｎｄＲｅａｃｔｉｖａｔｅ、Ｃｏｍｐｌｅｔｅ、ＣｏｍｐｌｅｔｅＡｎｄＫｅｅｐＳｐａｃｅ、Ｅｘｔｒａｃｔ、およびＲｅｐｌａｃｅは、生じてはならない（ソフトウェアによって保証される）。生じた場合には、結果は未定義である。Ｉｎｓｅｒｔ、Ｐｒｏｂｅ、ＰｒｏｂｅＡｎｄＳｅｔ、およびＣｏｎｄｉｔｉｏｎａｌＡｃｔｉｖａｔｅ動作だけが、ＳＰＵに応答する。
【０２２１】
ソフトウェアが、同一のパケットに影響するｍｏｖｅ様動作をＰＭＵに発行する場合に、結果は未定義である。というのは、移動がソフトウェアが指定した通りに発生するという保証がないからである。
【０２２２】
図１４は、有効なパケットのＡｃｔｉｖｅビット、Ｃｏｍｐｌｅｔｅｄビット、およびＰｒｏｂｅｄビットの許容される組合せを示す表である。
【０２２３】
基本動作
ソフトウェア動作および監視論理をサポートするために、ＱＳは、下記の基本動作をサポートする。
１．エントリを、キューの末尾にエンキューする。
２．エントリを、それが存在するキューからデキューする。
３．エントリを、それが現在存在するキューの先頭から別のキューの末尾に移動する。
４．キューのエントリをＲＴＵに供給する。
５．キューのサイズを供給する。
６．ｐａｃｋｅｔＮｕｍｂｅｒに関連するフィールドのいずれかを更新する。
【０２２４】
上の動作１、２、４、および６（同時に異なるパケットに適用される）は、本発明の好ましい実施形態では４サイクルで完了する。これは、１サイクルあたり１命令のスループットを暗示する。
【０２２５】
複数の動作が、同時に実行を開始される可能性がある時に、なんらかの優先順位付けが必要である。最高から最低の優先順位への順で、これらのイベントは、ＰＭＭＵからの挿入、エントリのデキュー、あるキューから別のキューへのエントリの移動、プリロードのためにＲＴＵへのエントリの送出、またはソフトウェア動作である。ソフトウェア動作の間の優先順位付けは、ソフトウェア動作が必ず順番に実行されるので、設計によって提供される。
【０２２６】
早期ＱＳ満杯検出
ＰＭＵは、ＡＳＩＣ（図２の要素２０３など）とＸＣａｌｉｂｅｒプロセッサの間のフロー制御を助ける機構を実装する。この機構の一部は、ＱＳが満杯になりつつあることを検出することであり、この場合には、ＳＰＵに対してＬｅｓｓＴｈａｎＸｐａｃｋｅｔＩｄＥｎｔｒｉｅｓＩｎｔ割込みが生成される。ソフトウェアは、０より大きい数ｚを指定する（ＩｎｔＩｆＬｅｓｓＴｈａｎＸｐａｃｋｅｔＩｄＥｎｔｒｉｅｓ構成レジスタで）ことによって、この割込みをイネーブルすることができる。割込みは、２５６−ｙ＜ｚの時に生成され、このｙは、現在ＸＣａｌｉｂｅｒ内で処理中のパケットの総数である。ｚ＝０の時には、割込みは絶対に発生しない。
【０２２７】
レジスタ転送ユニット（ＲＴＵ）
ＲＴＵブロックの目標は、使用可能なコンテキストに、ＸＣａｌｉｂｅｒ内で生きているパケットの情報をプリロードすることである。この情報は、パケットのｐａｃｋｅｔＰａｇｅおよびｐａｃｋｅｔＮｕｍｂｅｒと、そのヘッダのいくつかのフィールドである。選択されたコンテキストは、プリロードの時点でＰＭＵによって所有され、プリロードされるや否や、ＳＰＵに解放される。したがって、ＳＰＵは、ヘッダ情報をロードする、コストの高いロード動作を実行する必要がなく、したがって、パケット処理の総合的な待ち時間が減らされる。
【０２２８】
ＲＴＵは、ＱＳからパケット識別子（ｐａｃｋｅｔＰａｇｅ、ｐａｃｋｅｔＮｕｍｂｅｒ）と、パケットがそこから来たキューの番号を）ＱＳから受け取る。この識別子は、部分的にはネットワーク入力インターフェースを介してＸＣａｌｉｂｅｒに新しいパケットが到着した結果としてＰＭＭＵによって作成され（ｐａｃｋｅｔＰａｇｅ）、部分的にはｐａｃｋｅｔＰａｇｅおよびデバイス識別子がエンキューされる時にＱＳによって作成される（ｐａｃｋｅｔＮｕｍｂｅｒ）。
【０２２９】
ＲＴＵのもう１つの機能が、ＳＰＵコアによってディスパッチされたマスクドロード／ストア命令を実行することである。というのは、マスクドロード／ストア命令を実行する論理が、プリロードを実行する論理に類似するからである。したがって、両方の動作についてハードウェアを共用することができる。この理由から、ＲＴＵは、１時に両方ではなく、マスクドロード／ストア命令またはプリロードのいずれかを実行する。マスクドロード／ストア命令は、コマンドキュー（ＣＵ）ブロックを介してＲＴＵに到達する。
【０２３０】
コンテキストの状態
コンテキストは、ＰＭＵ所有またはＳＰＵ所有の２つの状態の１つになることができる。コンテキストの所有権は、現在の所有者がコンテキストを解放する時に変更される。ＰＭＵは、３つの場合にＳＰＵにコンテキストを解放する。第１に、ＲＴＵが、コンテキストへのパケットの情報のプリロードを終了した時である。第２に、ＳＰＵがＲＴＵにコンテキストを要求する時に、ＰＭＵがＳＰＵにコンテキストを解放する。この場合には、ＲＴＵが、解放できるコンテキストを有する場合に、そのコンテキストを解放する。第３に、８つのすべてのコンテキストが、ＰＭＵ所有である。プリロードされているコンテキストは、ＰＭＵ所有コンテキストとみなされることに留意されたい。
【０２３１】
ＳＰＵは、ＸＳｔｒｅａｍ  ＲＥＬＥＡＳＥ命令をディスパッチする時に、ＲＴＵにコンテキストを解放する。
【０２３２】
コンテキストのプリロード
ブート時に、ＰＭＵが、現在の例で説明される本発明の実施形態で使用可能な８つのコンテキストのうちの７つを所有し、ＳＰＵが、１つのコンテキストを所有する。ＰＭＵは、それが所有するコンテキストにパケットの情報をプリロードすることだけができる。コンテキストへのパケットの情報のプリロードの処理は、２ステップに分割することができる。パケットが開始されるアドレス（パケットメモリアドレススペース内のオフセット）をロードする第１フェーズ。このオフセットは、パケットのバイト単位のサイズをコーディングする２バイト値の第１バイトをポイントする。パケットが、タイムスタンプされ、ＨｅａｄｅｒＧｒｏｗｔｈＯｆｆｓｅｔが、０でない場合には、タイムスタンプ値が、オフセット−４に配置される。オフセットアドレスは、（ｐａｃｋｅｔＰａｇｅ＜＜８）｜（ＨｅａｄｅｒＧｒｏｗｔｈＯｆｆｓｅｔ＜＜４）として計算される。このオフセットは、選択されたコンテキストのレジスタ番号ＳｔａｒｔＬｏａｄｉｎｇＲｅｇｉｓｔｅｒにロードされる。ＳｔａｒｔＬｏａｄｉｎｇＲｅｇｉｓｔｅｒは、ブート時構成レジスタである。ｐａｃｋｅｔＮｕｍｂｅｒ値は、レジスタ番号ＳｔａｒｔＬｏａｄｉｎｇＲｅｇｉｓｔｅｒ＋１にロードされる。
【０２３３】
第２フェーズは、パケットヘッダをロードすることである。パケットヘッダは、レジスタＳｔａｒｔＬｏａｄｉｎｇＲｅｇｉｓｔｅｒ＋２、ＳｔａｒｔＬｏａｄｉｎｇＲｅｇｉｓｔｅｒ＋３、…（ＧＰＲレジスタが存在する限り、必要なだけいくつでも）を使用してロードされる。ＰａｔｔｅｒｎＭａｔｃｈｉｎｇＴａｂｌｅ［ｑ］（ｑは、パケットに関連するキュー番号である）マスクによって、パケットのヘッダをコンテキストのＧＰＲレジスタにロードする方法が指定される。ＰａｔｔｅｒｎＭａｔｃｈｉｎｇＴａｂｌｅは、マスクを含む、オンザフライ構成レジスタである。ヘッダデータを得るために、ＲＴＵは、必要な数のパケットデータの１６バイトラインをパケットメモリに読み込むようにＳＩＵに要求する。ＲＴＵは、パケットメモリから１６バイトライン（ローカルまたは外部のいずれか）を受け取る時に、この動作を制御するパターンマスクを使用して、コンテキストにロードすることが望まれるバイトを選択する。
【０２３４】
直前で説明した、パケットヘッダをロードするステップは、オンザフライＰｒｅｌｏａｄＭａｓｋＮｕｍｂｅｒ構成レジスタを介して、キューごとに、ソフトウェアによってディスエーブルすることができる。このレジスタでは、ＱＳ内の可能な３２個のキューのそれぞれについて、ＰａｔｔｅｒｎＭａｔｃｈｉｎｇＴａｂｌｅ内のどのマスク（０から２３まで）が、プリロードに使用されることになるかを指定する。２４と３１の間の値が、この構成レジスタ内で指定される場合には、それは、ＲＴＵによって、実行しないものとして解釈される。
【０２３５】
ＲＴＵは、コンテキストのＧＰＲレジスタにロードするだけである。必要なＣＰ０レジスタは、ＳＰＵによって初期化される。ロードされるコンテキストは、ＰＭＵ所有コンテキストなので、ＲＴＵは、ロードを実行するために、そのコンテキストへの使用可能なすべての書込ポート（この実施形態では４つ）を有する。
【０２３６】
プリロード動作が開始される時には、必ず、ＲＴＵが、専用インターフェースを介してＳＰＵにこのイベントを通知する。同様に、プリロード動作が完了する時にも、ＲＴＵが、ＳＰＵに通知する。したがって、ＳＰＵは、パケットのプリロードのそれぞれについて、２回の通知（開始および終了）を期待する。ＲＴＵが、同一サイクルでプリロードを開始し、終了する時（これは、パケットヘッダのロードのステップがディスエーブルされてる時に発生する）には、特別な通知が、ＳＰＵに供給される。この３つの場合のどれでも、ＲＴＵは、パケットに関連するコンテキスト番号およびＣｏｄｅＥｎｔｒｙＰｏｉｎｔ構成レジスタの内容を供給する。ＰＭＵが、８つのすべてのコンテキストがＰＭＵ所有なのでＳＰＵにコンテキストを解放する場合には、ＣｏｄｅＥｎｔｒｙＰｏｉｎｔＳｐｅｃｉａｌの内容が、ＳＰＵに供給される。ＲＴＵは、８エントリのテーブル（コンテキストごとに１エントリ）を有し、各エントリが、プリロードの準備ができているパケット識別子と、そのエントリを検証する有効ビットを有する。ＲＴＵは、プリロードを行うために、必ず、最高のエントリインデックスの有効な識別子を選択する。コンテキストが、この識別子に関連付けられる時に、対応する有効ビットが、デアサートされる。ＲＴＵは、１時に１つのコンテキストをプリロードする。コンテキストをロードした後に、そのコンテキストが、ＳＰＵに解放され、ＳＰＵ所有コンテキストになる。この時点で、ＲＴＵは、コンテキストにプリロードされる次のパケットについてテーブルを検索する（少なくとも１つのＰＭＵ所有コンテキストがある場合）。
【０２３７】
パターン照合テーブル
図１５に、サブマスクの組を含むオンザフライ構成レジスタであるパターン照合テーブルを示す。ＲＴＵは、コンテキストのプリロードに、このテーブル内のサブマスク（０から２３まで）のどれでも使用することができる。サブマスクを、複数のサブマスクを含むより大きいマスクにグループ化することもできる。
【０２３８】
図１６に、マスクのフォーマットを示す。マスクは、図示のように、それぞれ３２×２ビットのサブマスクの変数番号（１から８まで）である。すべてのサブマスクが、複合マスクが対応するサブマスクで終るのか、次のサブマスクに継続するのかを示す、関連付けられたビット（ＥｎｄＯｆＭａｓｋ)を有する。サブマスクの最大の総数は３２であり、そのうちの２４個（サブマスクインデックス０から２３）がグローバルであり、これは、ＳＰＵ内のすべてのストリームが、それを使用でき更新できることを意味し、８個が、ストリームごとのサブマスクである。ストリームごとのサブマスクは、ＥｎｄＯｆＭａｓｋビットを有しないが、これは、ストリームごとのサブマスクのグループ化が許容されないからである。
【０２３９】
各サブマスクの２つの３２ビットベクトルを、ＳｅｌｅｃｔＶｅｃｔｏｒおよびＲｅｇｉｓｔｅｒＶｅｃｔｏｒと呼ぶ。ＳｅｌｅｃｔＶｅｃｔｏｒは、パケットのヘッダからのどのバイトが、コンテキストに保管されるかを示す。ＲｅｇｉｓｔｅｒＶｅｃｔｏｒは、ＳｅｌｅｃｔＶｅｃｔｏｒによって選択されたバイトを保管し続けるためにコンテキスト内の次の連続するレジスタに切り替える時を示す。バイトは、レジスタ内で必ず右寄せされる。
【０２４０】
図１７に、図１６のマスクを使用するプリロード動作の例を示す。ＳｅｌｅｃｔＶｅｃｔｏｒでアサートされたビットによって、ヘッダの対応するバイトがレジスタに保管されることが示される。たとえば、ヘッダのバイト０、１、および７が、それぞれＧＰＲ番号ＳｔａｒｔＬｏａｄｉｎｇＲｅｇｉｓｔｅｒ＋２のバイト０、１、および２にロードされる（すなわち、ヘッダバイトは、レジスタにロードされる時に右寄せされる）。ＲｅｇｉｓｔｅｒＶｅｃｔｏｒでアサートされたビットは、現在のＧＰＲレジスタにそれ以上のヘッダバイトがロードされないことと、次のヘッダバイトがある場合に、それが次の（連続する）ＧＰＲレジスタにロードされることを示す。この例では、ヘッダのバイト１２および１３が、ＧＰＲ番号ＳｔａｒｔＬｏａｄｉｎｇＲｅｇｉｓｔｅｒ＋３にロードされる。
【０２４１】
ＰＭＵ所有コンテキストの選択
ＰＭＵコアには、合計８つの機能ユニットがある。しかし、複雑さと性能のトレードオフに起因して、ストリーム（コンテキスト）は、４つの機能ユニットの固定された組に命令を発行することだけができる。
【０２４２】
ＲＴＵは、所与の時に複数のコンテキストを所有することができる。したがって、プリロードが実行される時またはコンテキストをＳＰＵに供給する時に、コンテキストの１つを選択する論理が設けられる。この論理は、ＰＭＵコア内の異なるストリーム（コンテキスト）が、異なる機能ユニットに潜在的にどのように命令をディスパッチできるかに基づいて定義され、この論理の目標は、ＳＰＵ内の機能ユニットが潜在的に受け取ることができる動作のバランスをとることである。
【０２４３】
選択論理は、入力として、コンテキストごとに１ビットの、そのコンテキストがＰＭＵ所有またＳＰＵ所有のどちらであるかを示す８ビットをとる。この論理は、選択が可能なＰＭＵ所有コンテキストを出力する。
【表１】
0003801919.tif 000005
【０２４４】
選択論理は、前の２５４個の番号のリストを用いて指定される。数のそれぞれが、ＳＰＵ／ＰＭＵ所有コンテキストの可能な組合せに関連する。たとえば、第１の数は、組合せ「０００００００１」に対応する、すなわち、コンテキスト番号０がＰＭＵ所有であり、コンテキスト番号１から７がＳＰＵ所有である（ＬＳＢ桁がコンテキスト０に対応し、ＭＳＢ桁がコンテキスト７に対応し、０の値がＳＰＵ所有を意味し、１の値がＰＭＵ所有を意味する）。第２の数は、組合せ「００００００１０」に対応し、第３の数は、組合せ「００００００１１」に対応し、組合せ「１１１１１１１０」まで同様である。１９番目の組合せ（「０００１００１１」）は、前のリストの数３（または「００００００１１」）に関連し、これは、コンテキスト０および１を選択できることを意味する。コンテキスト４を選択することもできるが、これは、ＳＰＵコア内の機能ユニットの使用のバランスをとるための最適の選択ではない。
【０２４５】
使用可能なコンテキストがない時の割込み
ＲＴＵは、ＮｅｗＰａｃｋｅｔＩｄＴａｂｌｅ）と呼ばれる８エントリのテーブルを有する。このテーブルのエントリｐには、ｐのＲＴＵ優先順位を有するパケット識別子（ｐａｃｋｅｔＰａｇｅ、ｐａｃｋｅｔＮｕｍｂｅｒ、およびキュー番号）と、その識別子を検証するＶａｌｉｄビットが含まれる。ＲＴＵは、プリローディングまたはマスクドロード／ストアの実行でビジーでない時に、このテーブルから、最高のＲＴＵ優先順位を有する有効な識別子を得る。それが存在し、少なくとも１つのＰＭＵ所有コンテキストがある場合に、ＲＴＵは、ＰＭＵ所有コンテキストのプリロードを開始し、テーブル内のＶａｌｉｄビットをリセットする。
【０２４６】
ＰＭＵ所有コンテキストがない場合には、ＲＴＵは、コンテキストがＳＰＵによって解放されるまで、アイドルになる（保留中のソフトウェア動作がないと仮定して）。コンテキストが解放された時点で、ＲＴＵは、やはり、ＮｅｗＰａｃｋｅｔＩｄＴａｂｌｅから最高の有効なＲＴＵ優先順位の識別子を得る（ＲＴＵがＳＰＵによるコンテキストの解放を待っている間に、最高のＲＴＵ優先順位を有する新しい識別子が、ＱＳによって送られた可能性があるので）。Ｖａｌｉｄビットがリセットされ、パケット情報が、使用可能なコンテキストへのプリロードを開始される。この時点で、ＲＴＵは、ＱＳからＲＴＵ優先順位ｐのパケットを受け入れることができる。
【０２４７】
ＲＴＵ優先順位ｐを有する識別子が、ＱＳによってＲＴＵに送られる時に、その識別子が、ＮｅｗＰａｃｋｅｔＩｄＴａｂｌｅのエントリｐにロードされ、Ｖａｌｉｄビットがセットされる。この時に、ＮｅｗＰａｃｋｅｔＩｄＴａｂｌｅ内の有効な識別子の数（やってくる１つをカウントせずに）が、現在の使用可能なＰＭＵ所有コンテキスト（ＲＴＵが現在ロードしようとしているコンテキストをカウントせずに）以上である場合に、ＰａｃｋｅｔＡｖａｉｌａｂｌｅＢｕｔＮｏＣｏｎｔｅｘｔＰｒｉｏｒｉｔｙＰＩｎｔ割込みが、ＳＰＵに対して生成される。Ｐは、０から７までの範囲であり、その値は、ブート時構成フラグＰａｃｋｅｔＡｖａｉｌａｂｌｅＢｕｔＮｏ  ＣｏｎｔｅｘｔＩｎｔＭａｐｐｉｎｇによって決定される。このフラグが「０」である場合には、Ｐは、３ビットのブート時構成レジスタＤｅｆａｕｌｔＰａｃｋｅｔＰｒｉｏｒｉｔｙによって決定される。このフラグが「１」の場合には、Ｐは、ＲＴＵ優先順位である。しかし、ＰａｃｋｅｔＡｖａｉｌａｂｌｅＢｕｔＮｏＣｏｎｔｅｘｔＰｒｉｏｒｉｔｙＰｉｎｔは、対応する構成フラグＰａｃｋｅｔＡｖａｉｌａｂｌｅＢｕｔＮｏＣｏｎｔｅｘｔＰｒｉｏｒｉｔｙＰｉｎｔＥｎａｂｌｅがデアサートされている場合には、生成されない。
【０２４８】
ＳＰＵは、割込みを受け取った時に、ＲＴＵが新しいパケットのｐａｃｋｅｔＰａｇｅ、ｐａｃｋｅｔＮｕｍｂｅｒ、およびヘッダ情報をプリロードできるようにするために、それが所有するコンテキストを解放するか否かを決定する。
【０２４９】
ＲＴＵは、ＰａｃｋｅｔＡｖａｉｌａｂｌｅＢｕｔＮｏＣｏｎｔｅｘｔＰｒｉｏｒｉｔｙＰＩｎｔ割込みを生成する時に、数サイクル後に、ＳＰＵによって解放されたコンテキストを受け取る場合がある。しかし、このコンテキストは、たとえばストリームの１つがパケットの処理を終了した時に解放されたものである可能性がある。これは、ＰａｃｋｅｔＡｖａｉｌａｂｌｅＢｕｔＮｏＣｏｎｔｅｘｔＰｒｉｏｒｉｔｙＰＩｎｔ割込みの割り込みサービスルーチンが終了する前に発生する可能性がある。したがって、コンテキストが、ＩＳＲ完了に起因して解放される時に、割込みを引き起こしたプリロードされたパケットが、すでに、ＳＰＵ内の別のストリームによって最初に解放されたコンテキストを使用している可能性がある。したがって、割込みに起因して解放されるコンテキストが、別の（おそらく将来の）パケットプリロードに使用される。ＮｅｗＰａｃｋｅｔＩｄＴａｂｌｅ内の他のエントリが有効でない場合には、コンテキストは、識別子がＲＴＵに到達するか、ＳＰＲがＲＴＵにコンテキストを要求するまで、使用され、そのままになる。
【０２５０】
コンテキストがＳＰＵ所有になり、ＲＴＵが保留中のプリロードを有する時には、必ず、ＲＴＵが、最高優先順位の保留中のプリロード（ＮｅｗＰａｃｋｅｔＴａｂｌｅ内の最高の有効なエントリに対応する）を選択し、プリロードを開始する。このレベルに関連するＰａｃｋｅｔＡｖａｉｌａｂｌｅＢｕｔＮｏＣｏｎｔｅｘｔＰｒｉｏｒｉｔｙｉｎｔ割込みがアサートされた場合には、プリロードが開始される時に、その割込みがデアサートされる。
【０２５１】
ＲＴＵでのソフトウェア動作
ソフトウェアは、ＲＴＵに影響する複数の命令を実行する。下記は、ＳＰＵコアによるＸＳｔｒｅａｍパケット命令のディスパッチの結果としてＲＴＵに対して生成される可能性があるすべての動作のリストである。動作は、コマンドキュー（ＣＵ）を介して、命令を発行したストリームに関連するコンテキスト番号と共にＲＴＵに到着する。
【０２５２】
１．Ｒｅｌｅａｓｅ（ｃ）：コンテキスト番号ｃが、ＰＭＵ所有になる。
【０２５３】
２．ＧｅｔＣｏｎｔｅｘｔ：ＲＴＵが、ＰＭＵ所有コンテキスト番号の番号を返す。このコンテキストは、存在する場合に、ＳＰＵ所有になり、成功フラグがアサートされて返される。存在しない場合には、デアサートされて返され、この場合には、コンテキスト番号は無意味である。
【０２５４】
３．ＭａｓｋｅｄＬｏａｄ（ｒ、ａ、ｍ）、ＭａｓｋｅｄＳｔｏｒｅ（ｒ、ａ、ｍ）：ＳＰＵコアが、特殊な機能ユニットとしてＲＴＵを使用して、マスクドロード／ストア命令を実行する。というのは、マスクドロード／ストア命令を実行する論理が、プリロードを実行する論理に似ているからである。したがって、両方の動作についてハードウェアを共用することができる。この理由から、ＲＴＵは、１時に、両方ではなく、マスクドロード／ストアまたはプリロードのいずれかを実行する。マスクドロードまたはマスクドストアのいずれかについて、ＲＴＵは、下記のパラメータを受け取る。
（ａ）マスクドロード／ストア動作によって使用される、ＰａｔｔｅｒｎＭａｔｃｈｉｎｇＴａｂｌｅ内の最初のサブマスクのインデックスに対応するマスク番号ｍ。
（ｂ）マスクの適用が開始される（すべての）メモリ内の最初のバイトをポイントする３６ビットアドレスａ。
（ｃ）マスクドロード／ストア動作に用いられる最初のレジスタに対応するレジスタ番号ｒ（供給されたコンテキスト番号内の）。同一のコンテキスト番号内の後続のレジスタが、選択されたマスクに従って使用される。
【０２５５】
マスクドロード／ストア動作に関して、マスクは、メモリの任意のバイトで適用を開始されることができるが、プリロード動作で（マスクドロード様動作）は、マスクが、必ず１６バイト境界アドレスから適用される。というのは、ネットワーク入力インターフェースから来るパケットデータが、必ず、パケットメモリ内で１６バイトライン内のＬＳＢバイトから保管されるからである。
【０２５６】
ＭａｓｋｅｄＬｏａｄ動作、ＭａｓｋｅｄＳｔｏｒｅ動作、およびＧｅｔＣｏｎｔｅｘｔ動作は、ＲＴＵとＳＰＵの間の専用インターフェースを介して、完了した時をＳＰＵに通信する。ＲＴＵは、ソフトウェア動作にパケットプリロードより高い優先順位を与える。プリロードでは、パケットメモリにアクセスするが、マスクドロード／ストアでは、キャッシュ可能またはライトスルーでない限り、システム内のどのメモリにもアクセスすることができる。そうでない場合には、結果は未定義である。
【０２５７】
ＲＴＵは、前のマスクドロード／ストアコマンドを実行している間にＧｅｔＣｏｎｔｅｘｔコマンドまたはＲｅｌｅａｓｅコマンドを実行することができる。
【０２５８】
プログラミングモデル
ソフトウェアは、ブート時またはオンザフライのいずれかで、ＰＭＵの特徴のいくつかを構成することができる。ブート時のみに構成可能な特徴のすべて、およびオンザフライで構成可能な特徴の一部が、ＳＰＵが単一ストリームモードで動作している時に限って発生しなければならない。そうでない場合には、結果は未定義である。ＰＭＵは、ＳＰＵがどのモードで動作しているかを検査しない。
【０２５９】
ソフトウェアは、所与のパケットについてＰＭＵが維持する情報の一部を更新することができ、この情報を得ることもできる。これは、別の特許出願の対象である新しいＸＳｔｒｅａｍパケット命令を介して、ソフトウェアによって達成される。これらの命令は、ＰＭＵによって実行される３つの異なるタイプの動作（動作がＰＭＵのどのブロックすなわち、ＰＭＭＵ、ＱＳ、またはＲＴＵのどれに影響するかに依存する）を作る。これらの動作の一部が、結果をＰＭＵからＳＰＵに送り返すことを必要とする。
【０２６０】
パケットメモリおよび構成スペースは、メモリマップ式である。ＳＩＵは、パケットメモリのベースアドレスを用いて構成レジスタ（１６ＭＢ整列）を維持し、ＥＰＭのベースアドレスを用いて第２の構成レジスタを維持する。ソフトウェアは、連続するスペースとしてパケットメモリを見る。しかし、このシステムでは、パケットメモリのＥＰＭ部分を異なるスペースにマッピングすることができる。
【０２６１】
ＳＩＵは、ＰＭＵ構成レジスタスペースのベースを用いて、第３の構成レジスタも維持する。ＳＰＵによって実行されるＬＰＭおよびおよび構成スペースへのロード／ストアアクセスのすべてが、ＳＩＵを介してＰＭＵに達する。ＳＩＵは、アクセスがどのスペースに属するかを判定し、ＰＭＵに、アクセスがＬＰＭまたはＰＭＵ構成スペースのどちらに対するものであるかを知らせる。ＥＰＭへのアクセスは、ＰＭＵには透過的である。
【０２６２】
ＰＭＵは、あるイベントが発生した時にＳＰＵに割り込むことができる。ソフトウェアは、構成レジスタを介して、これらの割込みのすべてをディスエーブルすることができる。
【０２６３】
構成レジスタ
ＰＭＵの構成レジスタは、ＸＣａｌｉｂｅｒアドレススペースのＰＭＵ構成スペース内にある。このスペースのベースアドレスは、ＳＩＵによって維持され、ＰＭＵによって可視にする必要はない。ＳＩＵは、ＳＰＵによって実行される読取／書込アクセスがこのスペースに属する時を、書込アクセスの際に特定のレジスタを更新するのに必要な情報と共に、信号を用いてＰＭＵに通知する。
【０２６４】
ＰＭＵ構成レジスタには、ブート時にのみ構成することができるものと、オンザフライで構成することができるものがある。すべてのブート時構成レジスタおよび一部のオンザフライ構成レジスタには、単一ストリームモードでアクセスする必要がある。ブート時構成レジスタは、ＰＭＵがリセットモードである場合にのみ更新されなければならない。そうでない場合には、結果は未定義である。ＰＭＵは、単一ストリームモード構成レジスタが更新される時に、ＳＰＵが実際に単一ストリームモードであるかどうかを検査しない。すべての構成レジスタが、リセットシーケンスの後にデフォルト値を有する。
【０２６５】
この実施形態では、４ＫＢのＸＣａｌｉｂｅｒアドレススペースが、ＰＭＵ構成スペースに割り振られる。ＸＣａｌｉｂｅｒのＰＭＵ内では、これらの構成レジスタの一部が、使用されないか、まばらに使用される（すなわち、３２ビット構成レジスタの一部のビットだけが意味を持つ）のいずれかである。ＰＭＵ構成スペース内の定義されていないビットは、将来のＰＭＵ世代のために予約されている。ソフトウェアは、これらの予約済みビットを読み取るか書き込むことができるが、その内容は、完全に決定的ではあるが、未定義である。
【０２６６】
図１８に、論理的に３２ビットワードに分割される、ＰＭＵ構成スペースを示す。各ワードまたはワードの組に、構成レジスタが含まれる。
【０２６７】
図１９ａおよび１９ｂは、異なるＰＭＵ構成レジスタの、構成スペースの異なるワードへのマッピングを示す表の２つの部分である。各構成レジスタのブロック所有者も、この表に示されている。
【０２６８】
下記は、この特定の実施形態のすべての構成レジスタと、説明およびデフォルト値（ＰＭＵリセット後の）のリストである。構成レジスタのそれぞれについて、ビット幅を括弧内に示す。特に指定されない限り、構成レジスタの値は、構成スペース内の対応するワード内で右寄せされる。
【０２６９】
ブート時のみ構成レジスタ
１．Ｌｏｇ２ＩｎｐｕｔＱｕｅｕｅｓ（５）
（ａ）デフォルト値：０
（ｂ）説明：入力キューとして使用されるＱＳ内のキューの数（すなわち、ＰＭＭＵからのｐａｃｋｅｔＰａｇｅ／ｄｅｖｉｃｅＩｄが挿入されるキューの数）。
【０２７０】
２．ＰｒｉｏｒｉｔｙＣｌｕｓｔｅｒｉｎｇ（３）
（ａ）デフォルト値：５（３２クラスタ）
（ｂ）説明：ＱＳ内の異なるキューが優先順位クラスタ内でどのようにグループ化されるかを指定する（０：１クラスタ、１：２クラスタ、２：４クラスタ、…、５：３２クラスタ）。
【０２７１】
３．ＨｅａｄｅｒＧｒｏｗｔｈＯｆｆｓｅｔ（４）
（ａ）デフォルト値：０
（ｂ）説明：パケットがパケットメモリに保管される時にパケットの前に残される空の１６バイトチャンクの数。最大値は、１５個の１６バイトチャンク。最小値は０。
【０２７２】
４．ＴａｉｌＧｒｏｗｔｈＯｆｆｓｅｔ（６）
（ａ）フォルト値：０
（ｂ）説明：パケットがパケットメモリに保管される時にパケットの後に残される空の１６バイトチャンクの数。最大値は、６３個の１６バイトチャンク。最小値は０。
【０２７３】
５．ＰａｃｋｅｔＡｖａｉｌａｂｌｅＢｕｔＮｏＣｏｎｔｅｘｔＩｎｔＭａｐｐｉｎｇ（１）
（ａ）デフォルト値：０
（ｂ）説明：ＰａｃｋｅｔＡｖａｉｌａｂｌｅＢｕｔＮｏＣｏｎｔｅｘｔＰｒｉｏｒｉｔｙＰＩｎｔ割込みがイネーブルされる場合のＰを指定する。可能な値は次の通り：
（１）０：ＰはＤｅｆａｕｌｔＰａｃｋｅｔＰｒｉｏｒｉｔｙレジスタによって指定される。
（２）１：ＰはＲＴＵ優先順位である。
【０２７４】
６．ＳｔａｒｔＬｏａｄｉｎｇＲｅｇｉｓｔｅｒ（５）
（ａ）デフォルト値：１
（ｂ）説明：選択されたコンテキストでのパケットヘッダのバックグラウンドロードを実行する時にＲＴＵによってロードされる最初のＧＰＲレジスタ番号を決定する。このレジスタには、値（ｐａｃｋｅｔＰａｇｅ＜＜８）｜（ＨｅａｄｅｒＧｒｏｗｔｈＯｆｆｓｅｔ＜＜４）がロードされる。ｐａｃｋｅｔＮｕｍｂｅｒは、次のＧＰＲレジスタにロードされる。それに続くＧＰＲレジスタは、ＰａｔｔｅｒｎＭａｔｃｈｉｎｇＭａｓｋ０マスクがイネーブルされる場合に、それに続いてパケットヘッダデータをプリロードするのに使用される。
【０２７５】
７．ＰｒｅｌｏａｄＭａｓｋＮｕｍｂｅｒ（３２×５）
（ａ）デフォルト値：すべてのキューについてマスク３１（すなわち、ヘッダのプリロードがディスエーブルされる）。
（ｂ）説明：ＱＳの３２個の可能なキューのそれぞれについて、ＰａｔｔｅｒｎＭａｔｃｈｉｎｇＴａｂｌｅ内のどのマスクがプリロードに使用されるかを指定する。
【０２７６】
図１９ａから１９ｃに、ＰｒｅｌｏａｄＭａｓｋＮｕｍｂｅｒ構成レジスタのマッピングを示す。
【０２７７】
上で説明した構成レジスタは、現在の例のブート時のみ構成レジスタである。真下に、オンザフライ構成レジスタをリストする。
【０２７８】
単一ストリーム構成レジスタ
１．ＯｖｅｒｆｌｏｗＥｎａｂｌｅ（１）
（ａ）デフォルト値：０
（ｂ）説明：パケットがＬＰＭにおさまらない場合のパケットのオーバーフローをイネーブル／ディスエーブルする。ディスエーブルされた時には、パケットがドロップされる。
【０２７９】
２．ＰａｔｔｅｒｎＭａｔｃｈｉｎｇＴａｂｌｅ（２４×（３２×２＋１）
（ａ）デフォルト値（２４個のエントリのそれぞれについて）
（１）ＳｅｌｅｃｔＶｅｃｔｏｒ：すべてのバイトを選択する
（２）ＲｅｇｉｓｔｅｒＶｅｃｔｏｒ：レジスタごとに４つの連続するバイトを保管する
（３）ＥｎｄＯｆＭａｓｋ：１
（ｂ）説明：マスクドロード／ストア動作について、どのバイトをどの（連続する）レジスタにロード／ストアするかを指定する。このテーブルのマスク０は、ＲＴＵによって、バックグラウンドで、使用可能なコンテキストの１つにパケットのヘッダの一部のバイトをプリロードするのに使用される。合計２４個のマスクがある。
（ｃ）注：マスク０は、ＰＭＵがフリーズされる時（セクション０を参照されたい）に書き込まれる必要があり、そうでなければ、結果は未定義である。
【０２８０】
図２１に、真上で説明したＰａｔｔｅｒｎＭａｔｃｈｉｎｇＴａｂｌｅを示す。
【０２８１】
３．Ｆｒｅｅｚｅ（１）
（ａ）デフォルト値：１
（ｂ）説明：フリーズモードをイネーブル／ディスエーブルする。
【０２８２】
４．Ｒｅｓｅｔ（１）
（ａ）デフォルト値：０
（ｂ）説明：１がセットされている時に、ＰＭＵに強制的にリセットシーケンスを実行させる。ＰＭＵ内のすべてのパケットデータが失われる。リセットシーケンスの後には、すべての構成レジスタがデフォルト値を有する。
【０２８３】
複数ストリーム構成レジスタ
１．ＣｌｅａｒＥｒｒｏｒＤ（Ｄ＝０、１）
（ａ）デフォルト値：０
（ｂ）説明：ソフトウェアによって（なんらかのデータを）書き込まれる時に、装置識別子Ｄで検出されたパケットエラー状態がクリアされる。
【０２８４】
２．ＰａｃｋｅｔＡｖａｉｌａｂｌｅＢｕｔＮｏＣｏｎｔｅｘｔＰｒｉｏｒｉｔｙＰｉｎｔＥｎａｂｌｅ（８）［Ｐ＝０．．７］
（ａ）デフォルト値：０（すべてのレベルについて）
（ｂ）説明：ＰａｃｋｅｔＡｖａｉｌａｂｌｅＢｕｔＮｏＣｏｎｔｅｘｔＰｒｉｏｒｉｔｙＰｉｎｔ割込みをイネーブル／ディスエーブルする。
【０２８５】
３．ＡｕｔｏｍａｔｉｃＰａｃｋｅｔＤｒｏｐＩｎｔＥｎａｂｌｅ（１）
（ａ）デフォルト値：１
（ｂ）説明：ＡｕｔｏｍａｔｉｃＰａｃｋｅｔＤｒｏｐＩｎｔ割込みをイネーブル／ディスエーブルする。
【０２８６】
４．ＴｉｍｅＳｔａｍｐＥｎａｂｌｅ（１）
（ａ）デフォルト値：０
（ｂ）説明：パケットのタイムスタンプをイネーブル／ディスエーブルする。イネーブルされ、ＨｅａｄｅｒＧｒｏｗｔｈＯｆｆｓｅｔが０より大きい時に、パケットがパケットメモリに書き込まれる前に、４バイトのタイムスタンプがパケットに付加される。
【０２８７】
５．ＰａｃｋｅｔＥｒｒｏｒＩｎｔＥｎａｂｌｅ（１）
（ａ）デフォルト値：０
（ｂ）説明：ＰａｃｋｅｔＥｒｒｏｒＩｎｔ割込みをイネーブル／ディスエーブルする。
【０２８８】
６．ＶｉｒｔｕａｌＰａｇｅＥｎａｂｌｅ（９×４）
（ａ）デフォルト値：すべてのブロックについてすべての仮想ページがイネーブルされる。
（ｂ）説明：ＬＰＭが分割される４つのブロックのそれぞれの仮想ページをイネーブル／ディスエーブルする。２５６バイト（ＬＳＢビットによってイネーブルされる）から６４Ｋバイト（ＭＳＢビットによってイネーブルされる）までの、その間は２のべきのサイズの、９つまでの仮想ページがある。
【０２８９】
図２２に、ＶｉｒｔｕａｌＰａｇｅＥｎａｂｌｅレジスタを示す。
【０２９０】
７．ＯｖｅｒｆｌｏｗＡｄｄｒｅｓｓ（２４）
（ａ）デフォルト値：０ｘ４００００（ＥＰＭ内の最初のアトミックページ）。
（ｂ）説明：１６ＭＳＢビットが、オーバーフローしたパケットが保管され始めるパケットメモリ内のアトミックページ番号に対応する。８ＬＳＢビットは、「０」にハードワイヤされる（すなわち、ソフトウェアによってこれらのビットにセットされた値が、無視される）。ＯｖｅｒｆｌｏｗＡｄｄｒｅｓｓは、１６ＭＢパケットメモリ内のオフセットアドレスである。ＳＩＵは、このオフセットを、ＥＰＭ内の対応する物理アドレスに変換する。パケットメモリの最初の１Ｋアトミックページが、ＬＰＭに対応する。ソフトウェアが、ＯｖｅｒｆｌｏｗＡｄｄｒｅｓｓの１６ＭＳＢに０から１０２３までの値をセットした場合には、結果は未定義である。パケットがオーバーフローした時に、ＯｖｅｒｆｌｏｗＡｄｄｒｅｓｓの１６ＭＳＢビットが、そのパケットのｐａｃｋｅｔＰａｇｅになる。ＳＰＵは、この構成レジスタに書き込んだ時に、次のパケットオーバーフローを許容する。
【０２９１】
８．ＩｎｔＩｆＮｏＭｏｒｅＸｓｉｚｅＰａｇｅｓ（４）
（ａ）デフォルト値：０ｘＦ（すなわち、割込みが絶対に生成されない）。    （ｂ）説明：仮想ページのインデックスを指定する（０：２５６バイト、１：５１２バイト、…、８：６４Ｋバイト、９から１５：仮想ページなし）。ＰＭＭＵが、すべてのＬＰＭにそのサイズの仮想ページがこれ以上存在しないことを検出した時に、必ず、ＳＰＵに対してＮｏＭｏｒｅＴｈａｎＸＳｉｚｅＰａｇｅｓＩｎｔ割込みが生成される。
【０２９２】
９．ＩｎｔＩｆＬｅｓｓＴｈａｎＸｐａｃｋｅｔＩｄＥｎｔｒｉｅｓ（９）
（ａ）デフォルト値：０
（ｂ）説明：新しいパケット識別子に使用可能なＱＳ内のエントリの最小個数。使用可能なエントリの実際の個数がこの数未満である場合には、ＳＰＵに対して割込みが生成される。この数が０である場合には、ＬｅｓｓＴｈａｎＸＰａｃｋｅｔＩｄＥｎｔｒｉｅｓＩｎｔ割込みは生成されない。
【０２９３】
１０．ＤｅｆａｕｌｔＰａｃｋｅｔＰｒｉｏｒｉｔｙ（３）
（ａ）デフォルト値：０
（ｂ）説明：ＰａｃｋｅｔＡｖａｉｌａｂｌｅＢｕｔＮｏＣｏｎｔｅｘｔＭａｐｐｉｎｇが０である時の、ＰａｃｋｅｔＡｖａｉｌａｂｌｅＢｕｔＮｏＣｏｎｔｅｘｔＩｎｔ割込みの優先順位レベルを与える。
【０２９４】
１１．ＣｏｎｔｅｘｔＳｐｅｃｉｆｉｃＰａｔｔｅｒｎＭａｔｃｈｉｎｇＭａｓｋ：（８×（３２×２））
（ａ）デフォルト値：
（１）ＳｅｌｅｃｔＶｅｃｔｏｒ：すべてのバイトを選択する
（２）ＲｅｇｉｓｔｅｒＶｅｃｔｏｒ：各レジスタに４バイトを保管する（ＥｎｄＯｆＭａｓｋは１にハードワイヤされる）
（ｂ）説明：マスクドロード／ストア動作について、どのバイトをどの（連続する）レジスタにロード／ストアするかを指定する。ソフトウェアは、ストリームがその対応するコンテキスト固有マスクだけにアクセスすることを保証する。
【０２９５】
図２３に、ＣｏｎｔｅｘｔＳｐｅｃｉｆｉｃＰＡｔｔｅｒｎＭＡｔｃｈｉｎｇマスク構成レジスタを示す。
【０２９６】
１２．ＦｉｒｓｔＩｎｐｕｔＱｕｅｕｅ（５）
（ａ）デフォルト値：０
（ｂ）説明：ＰＭＭＵからのパケットが挿入されるキューの最小の番号を指定する。
【０２９７】
１３．ＳｏｆｔｗａｒｅＯｗｎｅｄ（４）
（ａ）デフォルト値：０（ソフトウェア所有でない）
（ｂ）説明：ＬＰＭブロックごとに１ビット。「１」の場合に、そのブロックがソフトウェア所有され、そのブロックのメモリがソフトウェアによって管理されることを示し、そのブロックのＶｉｒｔｕａｌＰａｇｅＥｎａｂｌｅビットがドントケアであることを示す。
【０２９８】
１４．ＭａｘＡｃｔｉｖｅＰａｃｋｅｔｓ（３２×９）
（ａ）デフォルト値：キューのそれぞれについて２５６。
（ｂ）説明：各キューｑについて、ＳＰＵによって処理できるキューｑ内のパケットの最大個数に対応する、０と２５６の間の値を指定する。
【０２９９】
図２４に、ＭａｘＡｃｔｉｖｅＰａｃｋｅｔｓ構成レジスタを示す。
【０３００】
１５．ＣｏｄｅＥｎｔｒｙＰｏｉｎｔ（３２×３０）
（ａ）デフォルト値：キューのそれぞれについて０。
（ｂ）説明：キューｑに関連するＣｏｄｅＥｎｔｒｙＰｏｉｎｔレジスタの内容は、キューｑに存在するパケットをプリロードされたコンテキストがアクティブにされる時に、ＳＰＵに送られる。
【０３０１】
１６．ＣｏｄｅＥｎｔｒｙＰｏｉｎｔＳｐｅｃｉａｌ（３０）
（ａ）デフォルト値：０
（ｂ）説明：このレジスタの内容は、すべてのコンテキストがＰＭＵ所有になるという事実に起因してコンテキストがアクティブにされる時に、ＳＰＵに送られる。
【０３０２】
１７．ＢｙｐａｓｓＨｏｏｋｓ（９）
（ａ）デフォルト値：０
（ｂ）説明：図３２を参照されたい。各ビットが、１つのハードウェアバイパスフックをアクティブにする。バイパスフックは、このレジスタの対応するビットがアサートされているサイクルに適用される。
【０３０３】
１８．ＩｎｔｅｒｎａｌＳｔａｔｅＷｒｉｔｅ（１２）
（ａ）デフォルト値：０
（ｂ）説明：図３３を参照されたい。内部ＰＭＵ状態の１ワードを指定する。内部状態のワードは、ＩｎｔｅｒｎａｌＳｔａｔｅＲｅａｄ構成レジスタを読み取る時に、ソフトウェアから使用可能になる。ＩｎｔｅｒｎａｌＳｔａｔｅＷｒｉｔｅ構成レジスタは、１実施形態では、ＰＭＵのデバッグに使用されるのみである。
【０３０４】
読取専用レジスタ
１．ＳｉｚｅＯｆＯｖｅｒｆｌｏｗｅｄＰａｃｋｅｔ（１６）
（ａ）デフォルト値：０
（ｂ）説明：ＰＭＵがパケットをオーバーフローしなければならない時に、必ず、このレジスタに、そのパケットのバイト単位のサイズが含まれる。
【０３０５】
２．ＴｉｍｅＣｏｕｎｔｅｒ（６４）
（ａ）デフォルト値：０
（ｂ）説明：ＰＭＵの最後のリセット以降のコアクロックサイクルの数が含まれる。
【０３０６】
ＴｉｍｅＣｏｕｎｔｅｒ構成レジスタを、図２５に示す。
【０３０７】
３．ＳｔａｔｕｓＲｅｇｉｓｔｅｒ（８）
（ａ）デフォルト値：１
（ｂ）説明：ＰＭＵの状態が含まれる。このレジスタは、リセットまたはフリーズが完了した時を見つける（ＦｒｅｅｚｅビットおよびＲｅｓｅｔビット）か、インバウンド装置識別子ごとのパケットエラーのソースを見つける（Ｅｒｒ：１−エラー、０−エラーなし；ＥＰＭ：１−パケットをＥＰＭにオーバーフローする間にエラーが発生した、０−パケットをＬＰＭにストアしている間にエラーが発生した；ＰＳＭ：１−パケットサイズ不一致に起因するエラー、０−バスエラーに起因するエラー）ために、ＳＰＵによってポーリングされる。
【０３０８】
図２６に、ＳｔａｔｕｓＲｅｇｉｓｔｅｒ構成レジスタを示す。
【０３０９】
割込み
ＰＭＵは、あるイベントが発生した時にＳＰＵに割り込むことができる。ソフトウェアは、上にリストした構成レジスタの一部を使用して、これらの割込みのすべてをディスエーブルすることができる。さらに、各ストリームが、これらの割込みを個別にマスクすることができるが、これは、別の特許出願の対象である。ＰＭＵが生成する割込みのリストは、次の通りである。
【０３１０】
１．ＯｖｅｒｆｌｏｗＳｔａｒｔｅｄＩｎｔ
（ａ）割込み条件：ＰＭＭＵは、着信パケットをＬｏｃａｌＰａｃｋｅｔＭｅｍｏｒｙに保管できない時に、ＳＩＵを介してＥｘｔｅｒｎａｌＰａｃｋｅｔＭｅｍｏｒｙにパケットをオーバーフローする。
（ｂ）ディスエーブル条件：ＯｖｅｒｆｌｏｗＥｎａｂｌｅ＝「０」
【０３１１】
２．ＮｏＭｏｒｅＰａｇｅｓＯｆＸＳｉｚｅＩｎｔ
（ａ）割込み条件：ＩｎｔＩｆＮｏＭｏｒｅＸＳｉｚｅＰａｇｅｓで示されたサイズの、使用可能な空き仮想ページがない。
（ｂ）ディスエーブル条件：ＩｎｔＩｆＮｏＭｏｒｅＸＳｉｚｅＰａｇｅｓ＝｛１０、１１、１２、１３、１４、１５｝。
【０３１２】
３．ＬｅｓｓＴｈａｎＸＰａｃｋｅｔＩｄＥｎｔｒｉｅｓＩｎｔ
（ａ）割込み条件：ＱＳ内で使用可能なエントリの実際の個数が、ＩｎｔＩｆＬｅｓｓＴｈａｎＸＰａｃｋｅｔＩｄＥｎｔｒｉｅｓ未満である。
（ｂ）ディスエーブル条件：ＩｎｔＩｆＬｅｓｓＴｈａｎＸＰａｃｋｅｔＩｄＥｎｔｒｉｅｓ＝０
【０３１３】
４．ＰａｃｋｅｔＡｖａｉｌａｂｌｅＢｕｔＮｏＣｏｎｔｅｘｔＰｒｉｏｒｉｔｙＰｉｎｔ（Ｐ＝０．．７）
（ａ）割込み条件：パケットが、ＱＳからＲＴＵによって受け取られたが、使用可能なコンテキストがない。
【０３１４】
（ｂ）ディスエーブル条件：ＰａｃｋｅｔＡｖａｉｌａｂｌｅＢｕｔＮｏＣｏｎｔｅｘｔＰｒｉｏｒｉｔｙＰＩｎｔＥｎａｂｌｅ＝「０」
【０３１５】
５．ＡｕｔｏｍａｔｉｃＰａｃｋｅｔＤｒｏｐＩｎｔ
（ａ）割込み条件：パケットをＬＰＭに保管することができず、ＯｖｅｒｆｌｏｗＥｎａｂｌｅ＝「０」である時。
（ｂ）ディスエーブル条件：ＡｕｔｏｍａｔｉｃＰａｃｋｅｔＤｒｏｐＩｎｔＥｎａｂｌｅ＝「０」
【０３１６】
６．ＰａｃｋｅｔＥｒｒｏｒＩｎｔ
（ａ）割込み条件：ＡＳＩＣから受け取られるパケットの実際のサイズが、ＡＳＩＣ固有ヘッダの最初の２バイトの値と一致しない時、またはバスエラーが発生した時。
（ｂ）ディスエーブル条件：ＰａｃｋｅｔＥｒｒｏｒＩｎｔＥｎａｂｌｅ＝「０」
【０３１７】
この実施形態でのＳＰＵへの割込みは、エッジトリガであり、これは、割込みがサービスされる時に、割込みを引き起こした条件がハードウェアでクリアされることを意味する。これは、割込みがＳＰＵによってサービスされる前に、割込みを引き起こした条件が複数回発生する可能性があることも意味する。したがって、対応する割込みサービスルーチンは、割込みを引き起こした条件が複数回発生した場合であっても、１回だけ実行される。
【０３１８】
この挙動は、いくつかの割込みについて望ましくない。それらの場合について、割込みがサービスされるまでその条件がさらに発生しないことを保証する特殊なインターロック機構が、ハードウェアで実装される。
【０３１９】
特殊なインターロック機構の例が、ＯｖｅｒｆｌｏｗＳｔａｒｔｅｄＩｎｔ割込みおよびＰａｃｋｅｔＡｖａｉｌａｂｌｅＢｕｔＮｏＣｏｎｔｅｘｔＰｒｉｏｒｉｔｙＰＩｎｔ割込みの場合である。第１の場合には、パケットがオーバーフローされた時に、ソフトウェアがオンザフライ構成レジスタＯｖｅｒｆｌｏｗＡｄｄｒｅｓｓに新しいアドレスを書き込むまで、他のパケットはオーバーフローされない。パケットがオーバーフローされたが、ＯｖｅｒｆｌｏｗＡｄｄｒｅｓｓレジスタがまだソフトウェアによって書き込まれていない場合には、ＬＰＭにおさまらないのでそうでなければオーバーフローされるはずの後続のパケットを、ドロップしなければならない。
【０３２０】
８つのＰａｃｋｅｔＡｖａｉｌａｂｌｅＢｕｔＮｏＣｏｎｔｅｘｔＰｒｉｏｒｉｔｙＰＩｎｔ（Ｐ＝０．．７）割込みについて、ＰＭＵアーキテクチャは、暗黙のうちに、複数の条件（Ｐのそれぞれについて）が発生しないことを保証する。これが設計によって保証されるのは、下記の理由による。
（ａ）ＰａｃｋｅｔＡｖａｉｌａｂｌｅＢｕｔＮｏＣｏｎｔｅｘｔＰｒｉｏｒｉｔｙＰＩｎｔ割込みは、ＲＴＵ優先順位Ｐのパケット識別子がＲＴＵに到達した時に限って生成され、
（ｂ）ＲＴＵ優先順位Ｐを有するパケット識別子は、多くとも１つだけがＲＴＵに存在する。
【０３２１】
他の割込みは、複数の条件の影響をこうむる可能性がある。したがって、ソフトウェアは、条件が発生した回数を正確に知るために、所与のタイプの割込みが発生した回数をカウントすることに頼ってはならない。
【０３２２】
保護の問題
この実施形態のＰＭＵのアーキテクチャは、下記の保護の問題を生じる。
【０３２３】
１．ストリームが、それが処理しているもの以外のパケットからデータを読み取る／書き込むことができる。ストリームは、すべてのパケットメモリにアクセスでき、パケットメモリがカーネルスペースとしてマッピングされない限り、ストリームが、全く関係のないパケットからのデータにアクセスできなくする機構がない。
【０３２４】
２．構成レジスタがメモリマップ式なので、どのストリームでも、ＳＰＵが単一ストリームモードであるか否かに無関係に、構成レジスタを更新することができる。具体的に言うと、どのストリームでも、ＰＭＵをフリーズし、リセットすることができる。
【０３２５】
３．パケットが、再アクティブ化を伴う完了または移動を行われる時に、必ず、ソフトウェアがそのパケットの「処理」を継続することを妨げるものがない。
【０３２６】
コマンドユニット（ＣＵ）
ソフトウェアは、所与のパケットについてＰＭＵが維持するいくつかの情報を更新し、この情報を得ることができる。これは、上で参照した新しいＸＳｔｒｅａｍパケット命令の一部を介して、ソフトウェアによって達成される。これらの命令の一部は、ＰＭＵからの応答を必要とするという意味で、ロード様である。他の命令は、ストア様命令であり、ＰＭＵからの応答を必要としない。
【０３２７】
図２７は、この例のＸＣａｌｉｂｅｒの他のブロックに関連する、図２のコマンドユニット２１３の図であり、図２７のブロックのすべてが、図２と同一の符号を有する。ＳＰＵは、すべてのコンテキストにまたがって１サイクルあたり多くとも２つのパケット命令をディスパッチする（ＳＰＵのクラスタごとに１命令）。パケット命令のタイプは、命令が影響するＰＭＵブロック（ＰＭＭＵ、ＱＳ、またはＲＴＵ）に対応する。ＳＰＵがパケット命令をディスパッチする時に、ＰＭＵへの単一のコマンドが、生成され、ＣＵブロック内の３つの異なるキューの１つに挿入される（コマンドが送られるＰＭＵブロックごとに１つのキュー）。ＰＭＵに対するコマンドは、ＰＭＭＵコマンドキュー２７０３に発行され、ＱＳへのコマンドは、ＱＳコマンドキュー２７０５に進み、ＲＴＵへのコマンドは、ＲＴＵコマンドキュー２７０７に進む。各キューが、８つまでのコマンドを保持することができる。ＳＰＵは、対応するキューに十分な空きエントリがある場合に限って、ＣＵにコマンドをディスパッチする。
【０３２８】
ＣＵは、コマンドをめいめいのブロックにディスパッチし、ＳＰＵに返される応答をキューイングする８エントリのＲｅｓｐｏｎｓｅＱｕｅｕｅ２７０９に応答（ある場合に）を収集する責任を負う。ＣＵは、所与のサイクルで３つ（３つのブロックのそれぞれから１つ）までの応答を受け取ることができる。（ａ）ストリームごとに１つの未解決のパケット命令だけが許容され、（ｂ）Ｒｅｓｐｏｎｓｅ  Ｑｕｅｕｅが、ストリームと同数のエントリを有し、（ｃ）ＰＭＵに対するコマンドがパケット命令ごとに１つだけ生成され、（ｄ）各ロード様コマンドごとに１つの応答だけが生成されるので、ＰＭＵブロックによって生成された応答をエンキューするのに十分なスペースがＲｅｓｐｏｎｓｅＱｕｅｕｅにあることが保証される。ＲｅｓｐｏｎｓｅＱｕｅｕｅは、１時に２つまでのコマンドをエンキューできなければならない。
【０３２９】
ＣＵ２１３は、ＳＩＵ１０７から、構成レジスタを更新する要求も受け取る。これらのコマンドは、コマンドとしてＰＭＭＵ、ＲＴＵ、およびＱＳブロックにも送られる。ＰＭＭＵ、ＱＳ、およびＲＴＵは、それらに適用される構成レジスタのローカルコピーを保持する。ＣＵも、すべての構成レジスタのコピーを保持し、このコピーが、ＳＩＵからの構成レジスタ読取を満足するのに使用される。
【０３３０】
読取専用構成レジスタに関して、ＣＵと読取専用構成レジスタを所有する特定のユニットとの間に特殊なインターフェースが設けられる。ＸＣａｌｉｂｅｒのＰＭＵ内には、２つの読取専用構成レジスタが存在し、一方はＰＭＭＵブロック内（ＳｉｚｅＯｆＯｖｅｒｆｌｏｗｅｄＰａｃｋｅｔ）、他方はＣＵブロック内（ＳｔａｔｕｓＲｅｇｉｓｔｅｒ）に存在する。ＰＭＭＵは、ＳｉｚｅＯｆＯｖｅｒｆｌｏｗｅｄＰａｃｋｅｔレジスタに書き込む時に、必ず、ＣＵに通知し、ＣＵは、そのローカルコピーを更新する。
【０３３１】
異なるキュー内のコマンドは、独立であり、ＰＭＵによって順序はずれで実行することができる。しかし、キュー内では、コマンドが、順番に、１時に１つずつ実行される。ＰＭＵは、１サイクルあたり３つまでのコマンドの実行を開始することができる。ＰＭＭＵブロックおよびＱＳブロックは、他のイベント（新しいパケットがＰＭＭＵに達した時の新しいｐａｃｋｅｔＰａｇｅの作成、またはＱＳに送出する必要があるパケット識別子の抽出など）に、ＳＰＵからのコマンドより高い優先順位を与える。これは、ＳＰＵにデータを送り返すことを要求するコマンドが、ＰＭＭＵまたはＱＳのいずれかが他の動作の実行でビジーなので、実行に複数サイクルを要する可能性があることを意味する。
【０３３２】
ＲＴＵ２２７は、コマンドの２つのソースすなわち、ＱＳ（使用可能なコンテキストにパケット情報をプリロードするため）およびＳＰＵ（ソフトウェアコマンド）を有する。ＲＴＵは、必ず、より高い優先順位をＳＰＵコマンドに与える。しかし、ＲＴＵは、保留中のＳＰＵコマンドを実行する前に、進行中のコンテキストプリロード動作を終了する。
【０３３３】
コマンド／応答フォーマット
ＣＭＵによって受け取られるコマンドは、この実施形態では３つのフィールドを有する。
１．コンテキスト番号。これは、コマンドを生成したストリームに関連するコンテキストである。
２．コマンドオペコード。これは、ＰＭＵによって実行されるコマンドのタイプを指定する数である。
３．コマンドデータ。これは、コマンドオペコードフィールドで指定されたコマンドを実行するために、ＰＭＵが必要とする異なる情報である。
【０３３４】
ＰＭＵは、コマンドを受け取った時に、そのコマンドを挿入する必要があるコマンドキューがどれであるかを判定する。キューのいずれかに挿入されたコマンドは、受け取られたコマンドに類似する構造を有するが、オペコードおよびデータのビット幅は、キューによって変化する。図２８の表に、キューのそれぞれに挿入されるコマンドのフォーマットを示す。含まれていないのが、ＣＵがＰＭＭＵブロック、ＱＳブロック、およびＲＴＵブロックに送るＲｅａｄ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  ＲｅｇｉｓｔｅｒコマンドおよびＷｒｉｔｅ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｒｅｇｉｓｔｅｒコマンドである。
【０３３５】
応答を必要とするコマンドのそれぞれが、そのコマンドを生成したストリームに関連するコンテキストに対応する番号を用いてタグを付けられる。生成される応答も、同一のコンテキスト番号を用いてタグを付けられ、その結果、ＳＰＵが、発行されたコマンドのどれにその応答が属するかを知るようになる。
【０３３６】
上で説明したように、３つのＰＭＵブロックからの応答をバッファリングするＲｅｓｐｏｎｓｅＱｕｅｕｅ２７０９（図２７）が、１つだけ存在する。応答を必要とするパケット命令が、ストリームごとに多くとも１つが未解決になるので、応答がどのブロックから来たかを示す必要がないことに留意されたい。したがって、応答に関連するコンテキスト番号は、応答をストリームに関連付けるのに十分な情報である。
【０３３７】
図２９は、異なるブロックが生成してＣＵに返す応答のフォーマットを示す表である。この表に含まれていないのは、ＣＵが構成レジスタ読取を実行する時の、ブロックのそれぞれによってＣＵに供給される構成レジスタ値である。
【０３３８】
ＲＴＵは、下記のイベントについて、ＣＵをバイパスする専用インターフェース（図２７の経路２７１１）を介してＳＰＵに通知する。
【０３３９】
１．マスクドロード／ストア動作が完了した。インターフェースは、コンテキスト番号を供給する。
【０３４０】
２．ＧｅｔＣｏｎｔｅｘｔが完了した。ＧｅｔＣｏｎｔｅｘｔ動作をディスパッチしたストリームに関連するコンテキスト番号およびＲＴＵによって選択されたコンテキスト番号が、インターフェースによって供給される。ＧｅｔＣｏｎｔｅｘｔが成功した時には、成功ビットがアサートされ、そうでない場合にはデアサートされる。
【０３４１】
３．プリロードの開始または終了。パケットに関連するコンテキスト番号および優先順位が、ＳＰＵに供給される。
【０３４２】
リセットモードおよびフリーズモード
ＰＭＵは、次の２つの場合にリセットモードに入ることができる。
１．ＳＰＵがＲｅｓｅｔ構成フラグをセットした。
２．ＸＣａｌｉｂｅｒがブートされた。
【０３４３】
ＰＭＵは、次の２つの場合にフリーズモードに入ることができる。
１．ＳＰＵがＦｒｅｅｚｅ構成フラグをセットした。
２．ＰＭＵがリセットシーケンスを完了した
【０３４４】
ＰＭＵのリセットシーケンスは、数サイクルを要する。このシーケンス中に、ＳｔａｔｕｓＲｅｇｉｓｔｅｒ構成レジスタのＲｅｓｅｔビットがセットされる。リセットシーケンスの後に、すべての構成レジスタに、そのデフォルト値がセットされ、ＰＭＵが、フリーズモードに入る（ＳｔａｔｕｓＲｅｇｉｓｔｅｒのＲｅｓｅｔビットが、リセットされ、Ｆｒｅｅｚｅビットがセットされる）。これが終わった時に、ＳＰＵが、Ｆｒｅｅｚｅ構成フラグをリセットし、その時点から、ＰＭＵが通常モードで動作する。
【０３４５】
ＳＰＵが、Ｆｒｅｅｚｅ構成フラグをセットする時に、ＰＭＵは、ＳｔａｔｕｓＲｅｇｉｓｔｅｒのＦｒｅｅｚｅビットをセットする前に、現在の１つまたは複数のトランザクションを終了する。フリーズモードに入った後は、ＰＭＵは、ネットワーク入力インターフェースからのデータを受け入れず、ネットワーク出力インターフェースを介してデータを送出せず、パケットをプリロードしない。
【０３４６】
ＰＭＵは、フリーズモードである間にすべてのＳＰＵコマンドの実行を継続する。
【０３４７】
ＳＰＵは、ＳｔａｔｕｓＲｅｇｉｓｔｅｒ構成レジスタをポーリングして、ＰＭＵがどのモードであるか（リセットまたはフリーズ）を判定し、ＰＭＵがモードを変更する時を検出する必要がある。
【０３４８】
ＣＵブロックは、残りのブロックに、リセットおよびフリーズを実行するように指示する。下記は、ＣＵがリセットおよび／またはフリーズ構成ビットへの書込を受け取る時の、ＣＵと他のブロックの間のプロトコルである。
１．ＣＵは、フリーズまたはリセットのいずれかを実行する必要があるブロックに通知する。
２．すべてのブロックが、フリーズまたはリセットを実行する。完了の後に、ブロックが、フリーズまたはリセットを完了したことをＣＵにシグナルバックする。
３．ＣＵは、リセットまたはフリーズが完了されるや否や、ＳｔａｔｕｓＲｅｇｉｓｔｅｒのビットを更新する。ソフトウェアが、ＳｔａｔｕｓＲｅｇｉｓｔｅｒをポーリングして、ＰＭＵが完全にフリーズした時を判定する。
【０３４９】
ＰＭＵ内の異なるブロックは、下記の時にフリーズを終了する。
１．ＩＢ、ＬＰＭ、ＣＵ、およびＱＳは、フリーズする必要がない。
２．インバウンドパケットがある場合に、ＰＭＭＵがインバウンドパケットのアップロードを終了すると同時に、およびアウトバウンドパケットがある場合に、ＰＭＭＵがそのダウンロードを終了すると同時に。
３．プリロード動作がある場合に、ＲＴＵが現在のプリロード動作を終了すると同時に。
４．ＯＢが空になると同時に。
【０３５０】
フリーズモードの時には、ブロックは、
１．新しいパケットのアップロードを開始せず、完了したパケットのダウンロードを開始せず、ＳＰＵ（ＰＭＭＵ）への割込みを生成せず、
２．コンテキストをプリロードせず、ＳＰＵ（ＲＴＵ）への割込みを生成しない。
【０３５１】
ソフトウェアが、Ｆｒｅｅｚｅ／Ｒｅｓｅｔ構成レジスタに「１」を書き込み、その後、ＰＭＵがフリーズまたはリセットする前に「０」を書き込む場合に、結果は未定義である。ＰＭＵは、フリーズ／リセットシーケンスを開始した後に、それを完了する。
【０３５２】
性能カウンタインターフェース
ＰＭＵは、異なるユニット内のいくつかのイベントをプローブする。これらのプローブは、ＳＩＵに送られ、性能プローブとしてソフトウェアによって使用される。ＳＩＵは、ＰＭＵがＳＩＵに送るイベントの一部をカウントするのに使用されるカウンタの組を有する。ソフトウェアが、ＸＣａｌｉｂｅｒチップ全体を通じて監視したいイベントを決定する。ソフトウェアが性能カウンタをどのように構成できるかに関するさらなる情報については、ＳＵＩアーキテクチャ仕様文書を参照されたい。
【０３５３】
図３０に、ＰＭＵとＳＩＵの間の性能カウンタインターフェースを示す。６４個までのイベントを、ＰＭＵ内でプローブすることができる。６４個のすべてのイベントが、各サイクルに、６４ビットバスを介してＳＩＵ（ＥｖｅｎｔＶｅｃｔｏｒ）に送られる。
【０３５４】
６４個のイベントのそれぞれに、値（０から６４Ｋ−１）を関連付けることができる。ソフトウェアが、イベントのうちの２つを選択する（ＥｖｅｎｔＡおよびＥｖｅｎｔＢ）。この２つのそれぞれについて、ＰＭＵが、イベントがＥｖｅｎｔＶｅｃｔｏｒバスに供給されるのと同時に、関連する１６ビット値（それぞれＥｖｅｎｔＤａｔａＡおよびＥｖｅｎｔＤａｔａＢ）を供給する。
【０３５５】
イベントは、レベルトリガである。したがって、ＰＭＵが、２つの連続するサイクルにわたってイベントをアサートする場合に、そのイベントは、２回カウントされる。ＥｖｅｎｔＶｅｃｔｏｒの対応する信号は、イベントが発生した場合に限って、イベントの状態が保持されるサイクルにわたってアサートされる。
【０３５６】
ＳＩＵは、実際にカウントされるイベントを選択する（ソフトウェアがＳＩＵをどのようにプログラムしたかに基づく）。ＳＩＵが、ＥｖｅｎｔＡまたはＥｖｅｎｔＢと異なるイベント番号をカウントすると決定した場合に、ＳＩＵ内のカウンタが、ＥｖｅｎｔＶｅｃｔｏｒ内の対応するビットがアサートされるサイクルについてイベントをカウントする。監視されるイベントがＥｖｅｎｔＡおよび／またはＥｖｅｎｔＢである場合に、ＳＩＵは、イベント／ｓをカウントするほかに、イベントが発生するたびに、ＥｖｅｎｔＤａｔａＡおよび／またはＥｖｅｎｔＤａｔａＢによってもう１つのカウンタを増分する。
【０３５７】
図３１に、ＰＭＵ１０３内の異なるブロック間の内部インターフェースの可能な実装を示す。ＣＵは、ＰＭＵとＳＩＵの間の、性能カウンタに関するインターフェースとして働く。ＣＵ２１３は、ＥｖｅｎｔＡおよびＥｖｅｎｔＢ内の情報を異なるユニットに分配し、ユニットのそれぞれの個々のＥｖｅｎｔＶｅｃｔｏｒ、ＥｖｅｎｔＤａｔａＡ、およびＥｖｅｎｔＤａｔａＢを収集する。
【０３５８】
ＣＵブロックは、異なるブロックからすべてのイベントを収集し、それらをＳＩＵに送る。ＣＵは、異なるブロックとインターフェースして、各ブロック内のどのイベントがＥｖｅｎｔＤａｔａＡおよび／またはＥｖｅｎｔＤａｔａＢ値を提供する必要があるかを通知する。
【０３５９】
性能イベントは、タイムクリティカルではない、すなわち、性能イベントは、発生したのと同一のサイクルにＳＩＵに報告される必要がない。
【０３６０】
図３４から３９に、性能カウンタに関連するすべてのイベントをリストした表が含まれる。これらのイベントは、ＰＭＵ内のブロックによってグループ化される。イベント番号を、第２列に示す。この番号は、イベントが発生する時にアサートされる、ＥｖｅｎｔＶｅｃｔｏｒ内のビットに対応する。第３列は、イベント名である。第４列に、イベントに関連するデータ値と、括弧内にそのビット幅を示す。最後の列に、イベントの説明を示す。
【０３６１】
ＣＵブロックは、異なるブロックからすべてのイベントを収集し、それらをＳＩＵに送る。ＣＵは、異なるブロックとインターフェースして、各ブロック内のどのイベントがＥｖｅｎｔＤａｔａＡおよび／またはＥｖｅｎｔＤａｔａＢ値を提供する必要があるかを通知する。
【０３６２】
性能イベントは、タイムクリティカルではない、すなわち、性能イベントは、発生したのと同一のサイクルにＳＩＵに報告される必要がない。
【０３６３】
デバッグバイパスおよびトリガイベント
ハードウェアデバッグフックが、シリコンのデバッグを助けるためにＰＭＵ内で実装されている。デバッグフックは、下記の２つのカテゴリに分類される。
１．バイパスフック：これによって、潜在的に欠陥のある機能をバイパスする。これらの機能によって生成される不完全な結果（または、場合によっては、結果が全くない）の代わりに、バイパスフックは、他の隣接するブロックをテストできるようにする少なくともいくつかの機能性を提供する。
２．トリガイベント：ＰＭＵ内で特定の条件（トリガイベント）が発生する時に、ＰＭＵは、自動的にシングルステップモードに入り、これは、ＯＣＩインターフェース（セクション）を介して、ＳＩＵがシングルステップモードを抜けるコマンドをＰＭＵに送るまで続く。
【０３６４】
さらに、ＰＭＵは、シングルステップされる能力を有する。信号（ＳｉｎｇｌｅＳｔｅｐ）が、ＯＣＩインターフェースから来る。サイクルごとに、ＰＭＵの異なるブロックが、この信号を監視する。この信号がデアサートされている時に、ＰＭＵは、普通に機能する。ＳｉｎｇｌｅＳｔｅｐがアサートされた時に、ＰＭＵは、作業を一切実行しなくなり、進行中のすべての動作が、この信号がデアサートされるまで保持される。言い換えると、ＰＭＵは、この信号がアサートされた時に何も行わない。これに対する唯一の例外が、ブロックがデータを失う可能性がある時である（例は、２つのブロックの間のインターフェース内とすることができる。ブロックＡが、データをブロックＢに送り、ブロックＢが次のサイクルにそのデータを得ると仮定する。ＳｉｎｇｌｅＳｔｅｐがこのサイクルにアサートされた場合には、ブロックＢは、Ａからのデータが失われないことを保証しなければならない）。
【０３６５】
バイパスフック
ＰＭＵ内の異なるバイパスフックは、オンザフライＢｙｐａｓｓＨｏｏｋｓ構成レジスタを介してアクティブ化される。図４０は、ＰＭＵ内で実装される異なるバイパスフックを示す表である。各フックの番号は、ＢｙｐａｓｓＨｏｏｋｓレジスタ内のビット番号に対応する。バイパスフックは、このレジスタ内の対応するビットがアサートされているサイクルの間、適用される。
【０３６６】
トリガイベント
下記は、ＰＭＵ内で実装されるトリガイベントのリストである。
【０３６７】
１．サイズｓバイトの新しいパケットが、ＩＢＵの先頭にある。
【数３】
0003801919.tif 000006
【０３６８】
２．ｐａｃｋｅｔＰａｇｅ  ｐｐを有するソースｓからのｐａｃｋｅｔＩｄが、ＱＳのキューｑに挿入される。
【数４】
0003801919.tif 000007
【０３６９】
３．ｐａｃｋｅｔＰａｇｅ  ｐｐおよびｐａｃｋｅｔＮｕｍｂｅｔ  ｐｎを有するキューｑからのｐａｃｋｅｔＩｄが、ＲＴＵに送られる。
【数５】
0003801919.tif 000008
【０３７０】
４．ｐａｃｋｅｔＰａｇｅ  ｐｐおよびｐａｃｋｅｔＮｕｍｂｅｒ  ｐｎを有するｐａｃｋｅｔＩｄが、ＱＳのキューｑの先頭に達する。
【数６】
0003801919.tif 000009
【０３７１】
５．ＲＴＵ優先順位ｐとｐａｃｋｅｔＰａｇｅ  ｐｐおよびｐａｃｋｅｔＮｕｍｂｅｒ  ｐｎを有するパケットが、コンテキストｃにプリロードされる。
【数７】
0003801919.tif 000010
【０３７２】
６．ｐａｃｋｅｔＰａｇｅ  ｐｐおよびｐａｃｋｅｔＮｕｍｂｅｒ  ｐｎを有するキューｑからのｐａｃｋｅｔＩｄが、ダウンロードのためにＰＭＭに送られる。
【数８】
0003801919.tif 000011
【０３７３】
７．ｐａｃｋｅｔＰａｇｅ  ｐｐおよびｐａｃｋｅｔＮｕｍｂｅｒ  ｐｎを有するｐａｃｋｅｔＩｄが、ＱＳのキューｑの先頭に達する。
【数９】
0003801919.tif 000012
【０３７４】
８．パケットコマンドｐｃが、ブロックｂによって実行される。
【数１０】
0003801919.tif 000013
【０３７５】
ＳＰＵおよびＳＩＵとの詳細なインターフェース
前の節で説明したアーキテクチャは、図４１に示されたハードウェアブロックで実装される。
【０３７６】
ＳＰＵ−ＰＭＵインターフェース
図４２から４５で、ＳＰＵ−ＰＭＵインターフェースを説明する。
【０３７７】
ＳＰＵ−ＰＭＵインターフェース
図４６から４９で、ＳＩＵ−ＰＭＵインターフェースを説明する。
【０３７８】
上の明細書で、パケットの処理に適応するマルチストリーミングプロセッサのパケットメモリユニット（ＰＭＵ）を権能を付与する詳細で説明した。アーキテクチャ、ハードウェア、ソフトウェア、および動作の詳細が、例示的実施形態で与えられる。説明した実施形態を、本発明の趣旨および範囲から逸脱せずにかなり詳細に変更できることが、当業者に明白であろう。たとえば、教示された新規のアーキテクチャおよび機能性を厳守しながらＩＣハードウェア、ファームウェア、およびソフトウェアをさまざまな形で達成できることが、よく知られている。したがって、添付の請求項は、最も広義の解釈と一致しなければならない。
【図面の簡単な説明】
【図１】  本発明の好ましい実施形態のＤＭＳプロセッサの機能領域の関係を示す単純化されたブロック図である。
【図２】  追加の詳細を示す、図１のＤＭＳプロセッサのブロック図である。
【図３】  本発明の実施形態でのＬＰＭまたはＥＰＭへのデータのアップロードを示すブロック図である。
【図４ａ】  本発明の実施形態でのデータアップロードのための判定および割振りを示す図である。
【図４ｂ】  ４つの６４ＫＢブロックのそれぞれについて維持される必要がある状態を示す図である。
【図５ａ】  本発明の実施形態でアトミックページがどのように割り振られるかの例を示す図である。
【図５ｂ】  本発明の実施形態でアトミックページがどのように割り振られるかの例を示す図である。
【図６ａ】  本発明の実施形態でメモリスペースがどのように効率的に使用されるかを示す図である。
【図６ｂ】  本発明の実施形態でメモリスペースがどのように効率的に使用されるかを示す図である。
【図７】  パケットのダウンロードに使用されるＸＣａｌｉｂｅｒ  ＰＭＵユニットのブロックの最上位の概略を示す図である。
【図８】  パケットの増大および縮小の現象を示す図である。
【図９】  本発明の実施形態での、ＱＳと、ＰＭＵおよびＳＰＵ内の他のブロックとの間の高水準通信を示すブロック図である。
【図１０】  ＱＳを構成できる、本発明の実施形態での６つの異なるモードを示す表である。
【図１１】  本発明の実施形態での、図２および図７のＱＳの包括的なアーキテクチャを示す図である。
【図１２】  本発明の実施形態でのアウトバウンドＤｅｖｉｃｅＩｄフィールドのコーディングを示す表である。
【図１３】  本発明の実施形態でのＲＴＵ転送の優先順位マッピングを示す表である。
【図１４】  本発明の実施形態での有効パケットのＡｃｔｉｖｅビット、Ｃｏｍｐｌｅｔｅｄビット、およびＰｒｏｂｅｄビットの許容される組合せを示す表である。
【図１５】  本発明の実施形態でのパターン照合テーブルの図である。
【図１６】  本発明の１実施形態でのマスクのフォーマットを示す図である。
【図１７】  図１６のマスクを使用するプリロード動作の例を示す図である。
【図１８】  本発明の実施形態でのＰＭＵ構成スペースを示す図である。
【図１９ａ】  構成レジスタマッピングの表である。
【図１９ｂ】  構成レジスタマッピングの表である。
【図１９ｃ】  構成レジスタマッピングの表である。
【図２０】  ＰｒｅｌｏａｄＭａｓｋＮｕｍｂｅｒ構成レジスタを示す図である。
【図２１】  本発明の好ましい実施形態のＰａｔｔｅｒｎＭａｔｃｈｉｎｇＴａｂｌｅを示す図である。
【図２２】  本発明の好ましい実施形態のＶｉｒｔｕａｌＰａｇｅＥｎａｂｌｅ構成レジスタを示す図である。
【図２３】  本発明の好ましい実施形態のＣｏｎｔｅｘｔＳｐｅｃｉｆｉｃＰａｔｔｅｒｎＭａｔｃｈｉｎｇＭａｓｋ構成レジスタを示す図である。
【図２４】  本発明の実施形態のＭａｘＡｃｔｉｖｅＰａｃｋｅｔｓ構成レジスタを示す図である。
【図２５】  本発明の実施形態のＴｉｍｅＣｏｕｎｔｅｒ構成レジスタを示す図である。
【図２６】  本発明の実施形態のＳｔａｔｕｓＲｅｇｉｓｔｅｒ構成レジスタを示す図である。
【図２７】  本発明の実施形態のコマンドユニットおよびコマンドキューの概略を示す図である。
【図２８】  本発明の実施形態のコマンドキューに挿入されるコマンドのフォーマットを示す表である。
【図２９】  本発明の実施形態の異なるブロックが生成してＣＵに返す応答のフォーマットを示す図である。
【図３０】  本発明の実施形態のＰＭＵとＳＩＵの間の性能カウンタインターフェースを示す図である。
【図３１】  本発明の実施形態のＰＭＵ内の異なるユニット間の内部インターフェースの可能な実装を示す図である。
【図３２】  本発明の実施形態のＢｙｐａｓｓＨｏｏｋｓ構成レジスタの図である。
【図３３】  本発明の実施形態のＩｎｔｅｒｎａｌＳｔａｔｅＷｒｉｔｅ構成レジスタの図である。
【図３４】  本発明の実施形態の性能カウンタに関連するイベントをリストした表である。
【図３５】  本発明の実施形態の性能カウンタに関連するイベントをリストした表である。
【図３６】  本発明の実施形態の性能カウンタに関連するイベントをリストした表である。
【図３７】  本発明の実施形態の性能カウンタに関連するイベントをリストした表である。
【図３８】  本発明の実施形態の性能カウンタに関連するイベントをリストした表である。
【図３９】  本発明の実施形態の性能カウンタに関連するイベントをリストした表である。
【図４０】  本発明の実施形態のＰＭＵ内で実装される異なるバイパスフックを示す表である。
【図４１】  本発明の実施形態の関連するアーキテクチャブロックおよびハードウェアブロックを示す表である。
【図４２】  本発明の実施形態のＳＰＵ−ＰＭＵインターフェースを示す表である。
【図４３】  本発明の実施形態のＳＰＵ−ＰＭＵインターフェースを示す表である。
【図４４】  本発明の実施形態のＳＰＵ−ＰＭＵインターフェースを示す表である。
【図４５】  本発明の実施形態のＳＰＵ−ＰＭＵインターフェースを示す表である。
【図４６】  本発明の実施形態のＳＩＵ−ＰＭＵインターフェースを示す表である。
【図４７】  本発明の実施形態のＳＩＵ−ＰＭＵインターフェースを示す表である。
【図４８】  本発明の実施形態のＳＩＵ−ＰＭＵインターフェースを示す表である。
【図４９】  本発明の実施形態のＳＩＵ−ＰＭＵインターフェースを示す表である。
【図１】
0003801919.tif 000014
【図２】
0003801919.tif 000015
【図３】
0003801919.tif 000016
【図４ａ】
0003801919.tif 000017
【図４ｂ】
0003801919.tif 000018
【図５ａ】
0003801919.tif 000019
【図５ｂ】
0003801919.tif 000020
【図６ａ】
0003801919.tif 000021
【図６ｂ】
0003801919.tif 000022
【図７】
0003801919.tif 000023
【図８】
0003801919.tif 000024
【図９】
0003801919.tif 000025
【図１０】
0003801919.tif 000026
【図１１】
0003801919.tif 000027
【図１２】
0003801919.tif 000028
【図１３】
0003801919.tif 000029
【図１４】
0003801919.tif 000030
【図１５】
0003801919.tif 000031
【図１６】
0003801919.tif 000032
【図１７】
0003801919.tif 000033
【図１８】
0003801919.tif 000034
【図１９ａ】
0003801919.tif 000035
【図１９ｂ】
0003801919.tif 000036
【図１９ｃ】
0003801919.tif 000037
【図２０】
0003801919.tif 000038
【図２１】
0003801919.tif 000039
【図２２】
0003801919.tif 000040
【図２３】
0003801919.tif 000041
【図２４】
0003801919.tif 000042
【図２５】
0003801919.tif 000043
【図２６】
0003801919.tif 000044
【図２７】
0003801919.tif 000045
【図２８】
0003801919.tif 000046
【図２９】
0003801919.tif 000047
【図３０】
0003801919.tif 000048
【図３１】
0003801919.tif 000049
【図３２】
0003801919.tif 000050
【図３３】
0003801919.tif 000051
【図３４】
0003801919.tif 000052
【図３５】
0003801919.tif 000053
【図３６】
0003801919.tif 000054
【図３７】
0003801919.tif 000055
【図３８】
0003801919.tif 000056
【図３９】
0003801919.tif 000057
【図４０】
0003801919.tif 000058
【図４１】
0003801919.tif 000059
【図４２】
0003801919.tif 000060
【図４３】
0003801919.tif 000061
【図４４】
0003801919.tif 000062
【図４５】
0003801919.tif 000063
【図４６】
0003801919.tif 000064
【図４７】
0003801919.tif 000065
【図４８】
0003801919.tif 000066
【図４９】
0003801919.tif 000067