動的キャッシングエンジン命令
全般的には、１つの側面において、この開示は、少なくとも１つのプログラムの少なくとも一部の複数の命令を記憶する１つの命令記憶装置と、当該命令記憶装置に結合された複数のエンジンの組とを備える１つのプロセッサを示す。エンジンは、１つのエンジン命令キャッシュと、少なくとも１つのプログラムの少なくとも一部のサブセットを要求する回路とを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
これは本出願と同日に出願された以下の出願に関連する出願である。
ａ．代理人整理番号Ｐ１６８５１ − "SERVICING ENGINE CACHE REQUESTS"
ｂ．代理人整理番号Ｐ１６８５２ − "THREAD-BASED ENGINE CACHE PARTITIONING"
【背景技術】
【０００２】
ネットワークは複数のコンピュータ及び他の複数のデバイスが通信することを可能にする。例えば、ネットワークは、ビデオ、オーディオ、電子メール等を表すデータを運ぶことができる。典型的には、ネットワークをわたって送られるデータは、パケットとして知られる小さな複数のメッセージに分割される。類推によって、１つのパケットは、メールボックスに投函した１つの封筒によく似ている。１つのパケットは、典型的には"ペイロード"及び１つの"ヘッダ"を含む。パケットの"ペイロード"は、封筒内のレターに似ている。パケットの"ヘッダ"は、封筒自体に書かれた情報によく似ている。ヘッダは、ネットワークデバイスがパケットを適切に処理することを助ける情報を含んでよい。例えば、ヘッダは、パケットの宛先を特定するアドレスを含むことができる。
【０００３】
１つの任意のパケットは、その宛先に到達する前に、多くの異なる中間ネットワークデバイス（例えば、" 複数のルータ"、" 複数のブリッジ"、及び"複数のスイッチ"）をわたって"ホップ"してよい。これらの中間デバイスは、様々なパケット処理オペレーションを頻繁に実行する。例えば、中間デバイスは、パケットをその宛先に向けてさらにどのように転送するかを決定したり、そのパケットを処理で用いるサービスのクオリティを決定したりするオペレーションを頻繁に実行する。
【０００４】
ネットワーク接続速度が増大するにつれて、１つの中間デバイスが１つのパケットを処理するための時間の量は小さくなり続けている。高速なパケット処理を実現すべく、多くのデバイスは、特定用途向け集積回路（ＡＳＩＣ）のような、専用の、"ハードウェアに組み込まれた"設計を特徴として持つ。これらの設計は、しかしながら、出現してくる複数のネットワーク技術及び通信プロトコルに適合させることが、多くの場合困難となる。
【０００５】
ＡＳＩＣに多くの場合付随する速度と柔軟性とを両立すべく、いくつかのネットワークデバイスは複数のプログラマブルネットワークプロセッサを特徴として持つ。ネットワークプロセッサは、ネットワークプロセッサの動作をソフトウェア技術者に速やかに再プログラムさせることを可能にする。
【０００６】
繰り返すと、多くの場合、ネットワーク接続の速度が増大することによって、１つのパケットを処理するために要する時間は、複数のパケットが到着する速度を著しく超えている。したがって、いくつかのネットワークプロセッサのアーキテクチャは、複数のパケットを同時に処理する複数のプロセッシングエンジンを特徴として持つ。例えば、１つのエンジンが１つのパケットをどのように転送するか決定している間に、他の１つのエンジンが異なる１つのパケットをどのように転送するかを決定する。１つの任意のパケットを処理するための時間は同じままであるが、複数のパケットを同時に処理することは、ネットワークプロセッサが到着するパケットの殺到に遅れないことを可能にする。
【図面の簡単な説明】
【０００７】
【図１】１つのネットワークプロセッサの複数の命令キャッシュを示す図である。
【０００８】
【図２】エンジンの命令キャッシュに複数の命令をフェッチするための１つの命令のオペレーションを示す図である。
【０００９】
【図３】ネットワークプロセッサエンジンによって実行される命令処理を示すフローチャートである。
【００１０】
【図４】複数の命令のキャッシングを示すフロー図である。
【００１１】
【図５】キャッシュされた複数の命令をサーチするエンジンの回路を示す図である。
【００１２】
【図６】ネットワークプロセッサエンジンの異なるスレッドにアロケートされた命令キャッシュメモリのマップを示す図である。
【００１３】
【図７】ネットワークプロセッサエンジンを示す図である。
【００１４】
【図８】ネットワークプロセッサを示す図である。
【００１５】
【図９】ネットワークデバイスを示す図である。
【発明を実施するための最良の形態】
【００１６】
図１は、複数のプロセッシングエンジン１０２を有するネットワークプロセッサ１００を示す。プロセッシングエンジン１０２は、パケットの次ホップの決定、サービス品質（ＱｏＳ）の適用、パケットトラフィックの計測等、種々のパケット処理オペレーションを実行すべくプログラムされている。示されたアーキテクチャでは、エンジン１０２は、エンジン１０２の高速ローカルメモリ１０４に記憶された複数のプログラム命令１０８を実行する。サイズ及びコスト制限によって、エンジン１０２によって提供される命令メモリ１０４の量は多くの場合限られている。エンジンメモリ１０４の限られた記憶容量が、プログラム１０８の全体のサイズ及び複雑さに厳し過ぎる制限を課すことを防ぐべく、図１は、１つのエンジン１０２におけるプログラム１０８の実行が進むにつれて、大きなプログラム１０８の複数のセグメント（例えば１０８ｂ）を１つのエンジン１０２に直接的にダウンロードする命令キャッシングスキームの一例を示す。
【００１７】
図１に示された例において、それぞれのエンジン１０２は、プログラム１０８の複数の命令のサブセットを記憶する命令キャッシュ１０４を有する。例えば、パケットエンジン１０２ａの命令キャッシュ１０４ａは、プログラム１０８のセグメント１０８ｂを持つ。プログラム１０８の残りは、複数のエンジン１０２によって共有される１つの命令記憶装置１０６に記憶されている。
【００１８】
最終的には、エンジン１０２ａは、セグメント１０８ｂ以外のプログラムセグメントにアクセスする必要があるかもしれない。例えば、プログラムはセグメント１０８ｂ外のプログラム１０８内のポイントに分岐する又は連続的に進む場合がある。エンジン１０２にプログラム１０８の実行を継続させることを可能にすべく、ネットワークプロセッサ１００は、要求された／必要とされた（複数の）セグメントをエンジン１０２ａのキャッシュ１０４ａにダウンロードしてよい。したがって、キャッシュに記憶される（複数の）セグメントは、プログラムの実行が進行するにつれて動的に変化する。
【００１９】
図１に示されるように、複数のエンジン１０２は、命令記憶装置１０６からキャッシュする複数の命令を受け取る。共有の命令記憶装置１０６は、更には、プロセッサ１００の内部又は外部にある階層的により高い命令記憶装置１１０から複数の命令をキャッシュしてよい。言い換えると、命令記憶装置１０４、１０６、及び１１０は、エンジンのＬ１命令キャッシュ１０４及び異なる複数のエンジンによって共有されるＬ２命令キャッシュ１０６を含むキャッシュヒエラルキーを形成する。
【００２０】
図１は、全ての複数のエンジン１０２に働く命令記憶装置１０６を示すが、ネットワークプロセッサ１００は、それに代えて、異なる複数のエンジン１０２の組に働く複数の共有された記憶装置１０６を有してよい。例えば、１つの共有された命令記憶装置１０６がエンジン＃１から＃４用の複数のプログラム命令を記憶するのに対し、他の１つの記憶装置がエンジン＃５から＃８用の複数のプログラム命令を記憶してよい。さらに、図１は、１つのプログラム１０８の複数の命令を記憶するエンジンキャッシュ１０４及び命令記憶装置１０６を示すが、それに代えて、エンジンキャッシュ１０４及び命令記憶装置１０６は、異なる複数のプログラムに属する複数の命令の複数の組を記憶してもよい。例えば、共有された命令記憶装置１０６は、それぞれのエンジン１０２用の、さらにはエンジン１０２の異なる複数のスレッド用の、複数の異なるプログラム命令を記憶してよい。
【００２１】
図１は、説明をし易くすべく、複数の命令１０８をソースコードで示す。共有された記憶装置１０６によって記憶されて複数のエンジンに配布される実際の命令は、典型的にはエンジンによって提供される命令セットで表される実行可能な複数の命令であってよい。
【００２２】
場合によっては、プログラム実行を継続すべくエンジン１０２によって必要とされる１つのプログラムセグメントは、"オンデマンド"原理で提供されてよい。すなわち、エンジン１０２は、実行を要する命令がキャッシュ１０４ａ内になくなるまで、命令キャッシュ１０４ａ内に記憶されている命令１０８ｂを実行し続けてよい。これが発生すると、エンジン１０２は、実行されるべき次の命令を含むプログラムセグメントを配送するよう、共有された記憶装置１０６に知らせる。この"オンデマンド"シナリオは、一方で、エンジン１０２のプログラム実行に遅延を発生させる。すなわち、"オンデマンド"シーケンスでは、エンジン１０２（又はエンジン１０２のスレッド）は必要とされる命令がロードされるまでアイドルでいつづける。この遅延は、必要とされる命令をエンジン１０２のＬ１キャッシュ１０４にダウンロードすることに伴うオペレーションだけでなく、共有された記憶装置１０６へのアクセスに対するエンジン１０２ｂ−１０２ｎ間の競合によっても生じ得る。
【００２３】
この遅延を可能性として避けるべく、図２は、プログラムの実行を継続するために命令が要求される時刻より前に、エンジンのキャッシュ１０４内へのプログラム命令の"プリフェッチ"をプログラムに開始させるフェッチ命令１２２を含む、プログラムソースコードリストの一部を示す。例えば、図２に示されるように、フェッチ命令１２２は、次のセグメント１０８ｂ内のポイントに実行が進む前に、エンジン１０２ｎに、共有された命令記憶装置１０６に必要とされる次のセグメント１８０ｂを求めて要求を発行（"１"）させる。エンジン１０２が、フェッチ命令１２２に続いて命令１２４を処理し続けている間に、要求されたセグメント１０８ｂがエンジン１０２の命令キャッシュ１０４ｎ内にロードされる。言い換えると、プログラムセグメントを取得する（"２"）ために使用される期間は、エンジンのプリフェッチ命令１２２の実行と、現在キャッシュされている（複数の）プログラムセグメント内にエンジン１０２が実効すべき命令が"無くなる"時間との間の期間に重なる。
【００２４】
図２に示される例では、複数のプログラム命令を取得する時間は、そのフェッチ命令に続く命令１２２を実行している期間によって隠匿された。フェッチ遅延は、完了するのにいくらかの時間を要する命令１２０（例えば、メモリオペレーション）の後に当該フェッチ命令を実行することによっても"隠匿"され得る。
【００２５】
図２に示されたフェッチ命令の例は、以下の構文を持つ。
【００２６】
Prefetch (SegmentAddress,SegmentCount)[, optional_token]
【００２７】
SegmentAddressは、共有記憶装置１０６から取得するプログラムの開始アドレスを表し、SegmentCountは、それに続くフェッチすべきセグメントの数を表す。場合によっては、SegmentAddressは、プログラムセグメントの開始アドレスを特定すべく限定されてよい。
【００２８】
optional_tokenは以下の構文を持つ。
【００２９】
optional_token = [ctx_swap[signal],][sig_done[signal]]
【００３０】
ctx_swapパラメータは、プログラムセグメントのフェッチの完了をシグナルが示すまで、他のエンジン実行スレッドにスワップするようエンジン１０２に命令する。sig_doneパラメータもフェッチの完了おいてセットされるステータスシグナルを示すが、エンジン１０２に複数のコンテクストをスワップするようには命令しない。
【００３１】
図２に示された命令構文は単なる一例であり、複数のプログラム命令をフェッチする他の複数の命令は、異なる複数のパラメータ、複数のキーワード、及び異なる複数のオプションを有してよい。さらに、命令は複数の異なるレベルにあってよい。例えば、命令は、エンジンの命令セットの一部であってよい。他にも、命令は、フェッチ命令に対応する複数のターゲット命令（例えば、エンジンが実行可能な複数の命令）を生成すべく１つのコンパイラによって処理されるソースコード命令であってよい。そのようなコンパイラは、ソースコードのテキスト文字を" 複数のトークン"にグループ化する語彙解析、そのトークンを文法的フレーズにグループ化する構文解析、ソースコードをより抽象的に表す中間言語コード生成、最適化等の、他の従来のコンパイラオペレーションを実行する。
【００３２】
フェッチ命令は、コード開発中にプログラマによって手動で挿入されてよい。例えば、初期のパケット分類に基づいて、そのパケットに対する残りのプログラムフローは知られている。したがって、フェッチ命令は、当該分類の後に、パケットを処理するのに必要な複数のセグメントを取得する。例えば、高レベル言語で書かれたプログラムは、以下の命令を含む。
【００３３】
switch(classify(packet.header)) {
case DropPacket: {
prefetch(DropCounterInstructions);
}
case ForwardPacket {
prefetch(RoutingLookupInstructions)
prefetch(PacketEnqueueInstructions);
} }
【００３４】
これは、パケットの分類に基づいて、適切な（複数の）プログラムセグメントをエンジン１０２の命令キャッシュ１０４にロードする。
【００３５】
プログラマが手動でフェッチ命令をコードに挿入してもよいが、フェッチ命令は、コンパイラ、アナライザ、プロファイラ、及び／又はプリプロセッサのようなソフトウェア開発ツールによってコードに挿入されてもよい。例えば、コードフロー解析が、異なるプログラムセグメントがいつロードされるべきかを特定してよい。例えば、コンパイラが、メモリアクセス命令の後、又は実行するのにいくらか時間を要する複数の命令のセットの前に、フェッチ命令を挿入してよい。
【００３６】
図３は、"オンデマンド"及び"フェッチ"命令に応答して複数の命令を取得する１つのエンジンのオペレーションを表すフローチャートを示す。図３に示されるように、実行すべき次のプログラム命令を特定するプログラムカウンタ１３０が更新される。例ば、次の連続する命令アドレスに進めるべくプログラムカウンタ１３０がインクリメントされるか、又は分岐命令に応答してカウンタ１３０がある他の命令アドレスにセットされてよい。示されるように、エンジンは、エンジンの命令キャッシュがプログラムカウンタによって特定される命令を現在保持しているか否かを判断１３２する。保持していない場合には、保持していない命令を共有された記憶装置からフェッチ１３６が取得するまで、エンジンスレッドはストール１３４する（例えば、命令を要求するスレッドがエンジンからスワップアウトされる）。
【００３７】
実行されるべき１つの命令がエンジンの命令キャッシュにあれば、エンジンは実行すべき次の命令がフェッチ命令であるか否かを判断１４０する。そうであれば、エンジンは、要求された（複数の）プログラムセグメントのフェッチ１４２を開始することができる。そうでなければ、エンジンは、通常通り命令を処理１４４することができる。
【００３８】
図４は、共有される命令キャッシュ１０６のアーキテクチャの一例を示す。命令キャッシュ１０６は、例えばネットワークプロセッサのスタートアップの間に、複数のエンジンで共有する複数の命令（"１"）を取得する。その後、共有された命令キャッシュ１０６は、複数の命令１０８の複数の部分を、必要に応じて及び／又は要求に応じて、複数のエンジンに配布する。
【００３９】
図４のアーキテクチャ例において示されるように、異なる２つのバス１５０、１５２が、共有されたキャッシュ１０６を複数のエンジン１０２に接続する。バス１５０は、複数のフェッチ要求を共有されたキャッシュ１０６に運ぶ（"２"）。これらの要求は、フェッチすべき（複数の）プログラムセグメント及び要求しているエンジンを特定する。複数の要求は、その要求がプリフェッチであるか"オンデマンド"であるかを特定してもよい。高バンド幅のバス１５２は、要求された（複数の）プログラムセグメントの中の複数の命令を、要求しているエンジン１０２に戻す（"４"）。バス１５２のバンド幅は、共有キャッシュ１０６が要求された複数の命令を複数のエンジンに同時に配布することを可能にする。例えば、バス１５２は、複数のエンジンに直接アロケートされたｎ本のラインに分割されてよい。例えば、４個のエンジンが複数のセグメントを要求した場合、それぞれはバスバンド幅の２５％がアロケートされる。
【００４０】
示されるように、共有されたキャッシュ１０６は、複数の要求が到着すると、例えばシーケンシャルサービスのための（ファーストインファーストアウト）ＦＩＦＯキュー１５４に複数の要求をキューしてよい。一方で、上記のように、実行されるべき命令がエンジンの命令キャッシュ１０４にロードされていない場合、スレッドはストールする。このように、実際にストールをもたらす"オンデマンド"要求に応えることは、ストールしないかもしれない結果になる"プリフェッチ"要求に応えることより切迫していることを意味する。示されるように、共有キャッシュ１０６は、複数のプリフェッチ要求を越えて複数のデマンド要求にプライオリティを与えることができる１つのアービタ１５６を含む。アービタ１５６は、専用回路を含んでよいし、プログラム可能であってもよい。
【００４１】
アービタ１５６は、様々な方法で複数のデマンド要求に優先順位をつけることができる。例えば、アービタ１５６は、デマンド要求をキュー１５４に加えず、代わりにその要求を速やかなサービス（"３"）のために提供する。複数の"デマンド"要求の間で優先順位をつけるべく、アービタ１５６は、キュー１５４内の複数の要求を超えてアービタ１５６によってプライオリティが与えられる、独立した"デマンド"ＦＩＦＯキューを管理してもよい。アービタ１５６は、デマンド要求をサービスすべく、進行中の複数の命令ダウンロードを速やかにサスペンドしてもよい。さらに、アービタ１５６は、"オンデマンド"要求を発行しているエンジンへの複数のセグメント命令の配布に、バス１５２のバンド幅の、１００％でない場合には、大部分をアロケートしてよい。
【００４２】
図５は、エンジンの命令キャッシュのアーキテクチャ例を示す。示されるように、キャッシュ記憶装置は、バス１６４を通じて共有された命令記憶装置１０６から受け取った命令を記憶する複数のメモリデバイス１６６ｘの集合によって提供される。個々のメモリ要素１６６ａは、１つのプログラムセグメントを保持するサイズであってよい。示されるように、それぞれのメモリ１６６ｘはアドレスデコーダと関連しており、アドレスデコーダは処理されるべき１つの命令のアドレスをエンジンから受け取り、その命令が関連するメモリ１６６内にあるか否かを判断するする。異なる複数のデコーダは、１つのアドレス上でパラレルに動作する。すなわち、それぞれのデコーダは、その関連するメモリを同時に検索する。メモリ１６６ｘの１つの中に発見されると、メモリ１６６ｘユニットは、エンジンによる処理のための要求された命令を出力１６８する。複数のメモリ１６６のいずれの中にも命令アドレスが発見されない場合、"ミス"信号１６８が生成される。
【００４３】
前述のように、１つのエンジンは複数の実行スレッドを提供してよい。実行中に、これらの複数の異なるスレッドは、複数の異なるプログラムセグメントをエンジンの命令キャッシュにロードする。キャッシュが満たされたとき、セグメントをキャッシュにロードすることは、ある他のセグメントがキャッシュから削除されることを要求する（"犠牲"）。何らかの保護なしでは、あるスレッドが他のスレッドによって現在使用されているセグメントを犠牲にする場合がある。他のスレッドが処理を再開したとき、最近犠牲にされたセグメントが共有されるキャッシュ１０６から再びフェッチされるかもしれない。命令キャッシュ１０４のこのスレッド内のスラッシングは、何度も繰り返される場合があり、システムのパフォーマンスを著しく低下させる。なぜなら、複数のセグメントは１つのスレッドによってキャッシュにロードされ、別のスレッドによって早々に犠牲にされ、短い時間の後に再びロードされるからである。
【００４４】
そのようなスラッシングに対処することを目的として、種々のメカニズムが、セグメントを犠牲にするスレッドの機能に制限を課すことができる。例えば、図６は、それぞれのエンジンスレッドがキャッシュ１０４の一部に排他的にアロケートされている１つのエンジンの命令キャッシュ１０４の、メモリマップを示す。例えば、スレッド０ １７２は、Ｎ個のプログラムセグメント１７２ａ、１７２ｂ、１７２ｎ用にメモリがアロケートされている。１つのスレッドのためにフェッチされた複数の命令セグメントは、キャッシュ１０４のスレッドのアロケーション内に存在することができる。スラッシングを防ぐことを目的として、ロジックが、他の複数のスレッドにアロケートされた複数のキャッシュパーティションから、１つのスレッドが複数のセグメントを犠牲にすることを制限してよい。
【００４５】
キャッシュされたセグメントに速やかにアクセスすることを目的として、１つのスレッドに関連する制御レジスタ及び状態レジスタ（ＣＳＲ）が、アロケートされたキャッシュ部分の開始アドレスを記憶してよい。このアドレスは、例えばスレッドの数に基づいて計算されてよい（例えば、アロケーション開始アドレス＝ベースアドレス＋(スレッド＃×１スレッド当たりにアロケートされたメモリ））。それぞれのパーティションは、例えばキャッシュエンジンへの共有される記憶装置１０６からのバーストフェッチサイズ又は共有記憶装置１０６からの転送の他の粒度に対応する、複数のセグメントにさらに分割されてよい。ＬＲＵ（最長時間未使用）情報が、１つのスレッドのアロケートされたキャッシュ部分の中の異なるセグメントに対して管理される。したがって、ＬＲＵスキームでは、与えられたスレッドのキャッシュの中で最も長期間使用されていないセグメントが最初に犠牲にされる。
【００４６】
示されたマップはまた、異なる複数のスレッド間で分割された領域に加えて"ロックダウン"部分１７０を有する。ロックダウン領域内の複数の命令は、イニシャライズ時にロードされ、犠牲から保護される。全スレッドは、この領域に記憶された複数の命令にアクセスして、実行することができる。
【００４７】
図６に示されたスキームのようなメモリアロケーションスキームは、スレッド間のスラッシングを防ぐことができる。一方で、他のアプローチも使用することができる。例えば、アクセスカウントが、現在セグメントを使用している複数のスレッドに関連づけられてよい。当該カウントが零に到達すると、当該セグメントが犠牲にされる。他にも、キャッシュ犠牲スキームは、異なる複数のルールを適用し得る。例えば、そのスキームは、いずれのスレッドによってもアクセスされていないロードされたセグメントを犠牲にすることを避けようとしてもよい。
【００４８】
図７は、エンジン１０２のアーキテクチャの一例を示す。エンジン１０２は、パケット処理用に適合された縮小命令セットコンピューティング（ＲＩＳＣ）プロセッサであってよい。例えば、エンジン１０２は、汎用プロセッサの命令セットによって通常提供される浮動小数命令又は整数除算命令を提供しない。
【００４９】
エンジン１０２は、他のコンポーネントに送信する又は他のコンポーネントから受信したデータをバッファリングする転送レジスタ１９２ａ、１９２ｂを介して、他のネットワークプロセッサコンポーネント（例えば、共有メモリ）と通信してよい。エンジン１０２は、他の（複数の）エンジンに組み込まれた"隣接"レジスタ１９４ａ、１９４ｂを介して、他の複数のエンジン１０２と通信してよい。
【００５０】
示されたエンジン１０２の例は、複数の実行スレッドを提供する。複数のスレッドをサポートすべく、エンジン１０２は、スレッドのそれぞれに対して１つのプログラムコンテクスト１８２を記憶する。コンテクスト１８２は、プログラムカウンタのようなスレッド状態データを含むことができる。スレッドアービタ１８２は、実行すべき１つのスレッドのプログラムコンテクスト１８２ｘを選択する。選択されたコンテクストに対するプログラムカウンタは、１つの命令キャッシュ１０４に供給される。キャッシュ１０４は、プログラムカウンタによって特定される命令が現在キャッシュされていない（例えば、セグメントがロックダウンキャッシュ領域又は現在実行しているスレッドにアロケートされた領域の中にそのセグメントがない）場合に、プログラムセグメントのフェッチを開始することができる。そうでなければ、キャッシュ１０４は、キャッシュされた命令を命令デコードユニット１８６に送ることができる。場合によっては、命令デコードユニット１９０は、当該命令を"フェッチ"命令とみなしてよく、セグメントのフェッチを開始してよい。そうでなければ、デコード１９０ユニットは、処理のために１つの実行ユニット（例えば、ＡＬＵ）に命令を供給して、異なる複数のエンジンによって共有されるリソース（例えば、メモリコントローラ）に、コマンドキュー１８８により要求を開始する。
【００５１】
フェッチコントロールユニット１８４は、共有されたメモリ１０６からのプログラムセグメントの取得を処理する。例えば、フェッチコントロールユニット１８４は、共有キャッシュ要求バスへのアクセスをネゴシエートして、要求を発行して、返された複数の命令を命令キャッシュ１０４の中に記憶することができる。フェッチコントロールユニット１８４は、以前にキャッシュされた複数の命令の犠牲を処理してもよい。
【００５２】
エンジン１０２の命令キャッシュ１０４及びデコーダ１８６は、１つの命令処理パイプラインの一部を形成する。すなわち、複数のクロックサイクルにわたって、１つの命令は、キャッシュ１０４からロードされ、デコード１８６され、（例えば、複数の汎用レジスタ１９６、複数の次の隣接レジスタ１９４ａ、複数の転送レジスタ１９２a、及びローカルメモリ１９８から）複数の命令オペランドがロードされ、実行データパス１９０によって実行される。最後に、オペレーションの結果が、（例えば、複数の汎用レジスタ１９６、ローカルメモリ１９８、複数の隣接レジスタ１９４ｂ、又は複数の転送レジスタ１９２ｂに）書き込まれる。多くの命令がパイプライン内に同時に存在し得る。すなわち、１つがデコードされている間に、他の１つがＬ１命令キャッシュ１０４からロードされている。
【００５３】
図８はネットワークプロセッサ２００の一例を示す。示されたネットワークプロセッサ２００は、Intel（登録商標）Internet eXchange network Processor (IXP)である。他のネットワークプロセッサは異なる設計を有する。
【００５４】
示されたネットワークプロセッサ２００は、１つのダイ上に集積された複数のパケットエンジン２０４の１つの集合を有する。上記のように、個々のパケットエンジン２０４は複数のスレッドを提供する。プロセッサ２００は、ネットワークオペレーションに含まれる"制御プレーン"タスクを実行すべく多くの場合プログラムされたコアプロセッサ２１０（例えば、StrongARM(登録商標) XScale（登録商標））を有してもよい。コアプロセッサ２１０は、一方で、"データプレーン"タスクを処理してもよく、追加のパケット処理スレッドを提供してよい。
【００５５】
示されるように、ネットワークプロセッサ２００は、プロセッサ２００と他の複数のネットワークコンポーネントとの間でパケットを運ぶことができるインタフェース２０２を特徴として有してもよい。例えば、プロセッサ２００は、スイッチファブリックに接続された他の（複数の）プロセッサ又は回路にプロセッサ２００がパケットを送ることを可能にするスイッチファブリックインタフェース２０２（例えば、Common Switch Interface（ＣＳＩＸ）インタフェース）を有してよい。プロセッサ２００は、プロセッサ２００が物理層（ＰＨＹ）及び／又は複数のリンク層デバイスと通信することを可能にするインタフェース２０２（例えば、System Packet Interface （ＳＰＩ）インタフェース）を有してよい。プロセッサ２００は、例えばホストと通信するためのインタフェース２０８（例えば、Peripheral Component Interconnect （ＰＣＩ）バスインタフェース）を有してもよい。示されるように、プロセッサ２００は、複数のメモリコントローラ２０６、２１２、１つのハッシュエンジン、及びスクラッチパッドメモリのような、複数のエンジンによって共有される他の複数のコンポーネントを有する。
【００５６】
上記のパケット処理技術は、ＩＸＰのような１つのネットワークプロセッサ上に種々の方法で実装されてよい。例えば、コアプロセッサ２１０は、ネットワークプロセッサの立ち上げの間に、共有される命令キャッシュ１０６に複数のプログラム命令を送ってよい。さらに、例えばプロセッサが非常に多数のエンジンを有している場合には、プロセッサ２００は、"２層の"命令キャッシュ階層に代えて、Ｎ層の命令キャッシュ階層を有してよい。
【００５７】
図９は、上記の技術が組み込まれたネットワークデバイスを示す。示されるように、デバイスは、スイッチファブリック３１０（例えば、クロスバ又は共有メモリスイッチファブリック）によって相互に接続されたラインカード３００（"複数のブレード"）の集合を持つ。スイッチファブリックは、例えば、ＣＳＩＸ、或いはハイパートランスポート、インフィニバンド、Peripheral Component Interconnect - Express （ＰＣＩ−Ｘ）等のような他のファブリック技術に準拠してよい。
【００５８】
個々のラインカード（例えば、３００ａ）は、ネットワーク接続を通じて通信を処理する１以上の物理層（ＰＨＹ）デバイス３０２（例えば、光、有線、及び無線ＰＨＹ）を含んでよい。複数のＰＨＹは、異なるネットワークメディアから運ばれた複数の物理信号と、デジタルシステムによって使用される複数のビット（例えば、複数の"０"及び複数の"１"）との間で変換する。ラインカード３００は、複数のフレームに対してエラー検出及び／又はエラー訂正のようなオペレーションを実行することが可能なフレーマデバイス３０４（例えば、イーサネット（登録商標）、同期光ネットワーク（ＳＯＮＥＴ）、高レベルデータリンク（ＨＤＬＣ）フレーマ、又は他の複数のレイヤ２デバイス）を含んでもよい。示されたラインカード３００は、上記の命令キャッシング技術を用いる１以上のネットワークプロセッサ３０６を含んでよい。ネットワークプロセッサ３０６は、（複数の）ＰＨＹ３００より受け取った複数のパケットに対して複数のパケット処理オペレーションを実行し、当該複数のパケットを、スイッチファブリック３１０を通じて、選択された出力インタフェースを提供するラインカードに導くようプログラムされている。場合によっては、（複数の）ネットワークプロセッサ３０６は、複数のフレーマデバイス３０４に代わって、"レイヤ２"動作を実行してよい。
【００５９】
図８及び９は、１つのエンジン、ネットワークプロセッサ、及び複数のネットワークプロセッサが組み込まれたデバイスのアーキテクチャ例を示すが、この技術は、他のエンジン、ネットワークプロセッサ、及びデバイスの設計に実装され得る。さらに、この技術は、種々のネットワークデバイス（例えば、ルータ、スイッチ、ブリッジ、ハブ、トラフィックジェネレータ等）に使用され得る。
【００６０】
ここで使用されている回路という用語は、ハードウェア組み込み回路、デジタル回路、アナログ回路、プログラマブル回路等を含む。プログラマブル回路はコンピュータプログラムで動作してよい。
【００６１】
そのようなコンピュータプログラムは、高レベル手続き型又はオブジェクト指向のプログラミング言語で書かれてよい。一方で、（複数の）プログラムは、必要に応じて、アセンブリ又はマシン言語で実装されることができる。その言語は、コンパイル又はインタープリトされてよい。さらに、これらの技術は、種々のネットワーク環境で使用され得る。
【００６２】
他の複数の実施形態は、以下の複数の請求項の範囲内にある。
【技術分野】
【０００１】
これは本出願と同日に出願された以下の出願に関連する出願である。
ａ．代理人整理番号Ｐ１６８５１ − "SERVICING ENGINE CACHE REQUESTS"
ｂ．代理人整理番号Ｐ１６８５２ − "THREAD-BASED ENGINE CACHE PARTITIONING"
【背景技術】
【０００２】
ネットワークは複数のコンピュータ及び他の複数のデバイスが通信することを可能にする。例えば、ネットワークは、ビデオ、オーディオ、電子メール等を表すデータを運ぶことができる。典型的には、ネットワークをわたって送られるデータは、パケットとして知られる小さな複数のメッセージに分割される。類推によって、１つのパケットは、メールボックスに投函した１つの封筒によく似ている。１つのパケットは、典型的には"ペイロード"及び１つの"ヘッダ"を含む。パケットの"ペイロード"は、封筒内のレターに似ている。パケットの"ヘッダ"は、封筒自体に書かれた情報によく似ている。ヘッダは、ネットワークデバイスがパケットを適切に処理することを助ける情報を含んでよい。例えば、ヘッダは、パケットの宛先を特定するアドレスを含むことができる。
【０００３】
１つの任意のパケットは、その宛先に到達する前に、多くの異なる中間ネットワークデバイス（例えば、" 複数のルータ"、" 複数のブリッジ"、及び"複数のスイッチ"）をわたって"ホップ"してよい。これらの中間デバイスは、様々なパケット処理オペレーションを頻繁に実行する。例えば、中間デバイスは、パケットをその宛先に向けてさらにどのように転送するかを決定したり、そのパケットを処理で用いるサービスのクオリティを決定したりするオペレーションを頻繁に実行する。
【０００４】
ネットワーク接続速度が増大するにつれて、１つの中間デバイスが１つのパケットを処理するための時間の量は小さくなり続けている。高速なパケット処理を実現すべく、多くのデバイスは、特定用途向け集積回路（ＡＳＩＣ）のような、専用の、"ハードウェアに組み込まれた"設計を特徴として持つ。これらの設計は、しかしながら、出現してくる複数のネットワーク技術及び通信プロトコルに適合させることが、多くの場合困難となる。
【０００５】
ＡＳＩＣに多くの場合付随する速度と柔軟性とを両立すべく、いくつかのネットワークデバイスは複数のプログラマブルネットワークプロセッサを特徴として持つ。ネットワークプロセッサは、ネットワークプロセッサの動作をソフトウェア技術者に速やかに再プログラムさせることを可能にする。
【０００６】
繰り返すと、多くの場合、ネットワーク接続の速度が増大することによって、１つのパケットを処理するために要する時間は、複数のパケットが到着する速度を著しく超えている。したがって、いくつかのネットワークプロセッサのアーキテクチャは、複数のパケットを同時に処理する複数のプロセッシングエンジンを特徴として持つ。例えば、１つのエンジンが１つのパケットをどのように転送するか決定している間に、他の１つのエンジンが異なる１つのパケットをどのように転送するかを決定する。１つの任意のパケットを処理するための時間は同じままであるが、複数のパケットを同時に処理することは、ネットワークプロセッサが到着するパケットの殺到に遅れないことを可能にする。
【図面の簡単な説明】
【０００７】
【図１】１つのネットワークプロセッサの複数の命令キャッシュを示す図である。
【０００８】
【図２】エンジンの命令キャッシュに複数の命令をフェッチするための１つの命令のオペレーションを示す図である。
【０００９】
【図３】ネットワークプロセッサエンジンによって実行される命令処理を示すフローチャートである。
【００１０】
【図４】複数の命令のキャッシングを示すフロー図である。
【００１１】
【図５】キャッシュされた複数の命令をサーチするエンジンの回路を示す図である。
【００１２】
【図６】ネットワークプロセッサエンジンの異なるスレッドにアロケートされた命令キャッシュメモリのマップを示す図である。
【００１３】
【図７】ネットワークプロセッサエンジンを示す図である。
【００１４】
【図８】ネットワークプロセッサを示す図である。
【００１５】
【図９】ネットワークデバイスを示す図である。
【発明を実施するための最良の形態】
【００１６】
図１は、複数のプロセッシングエンジン１０２を有するネットワークプロセッサ１００を示す。プロセッシングエンジン１０２は、パケットの次ホップの決定、サービス品質（ＱｏＳ）の適用、パケットトラフィックの計測等、種々のパケット処理オペレーションを実行すべくプログラムされている。示されたアーキテクチャでは、エンジン１０２は、エンジン１０２の高速ローカルメモリ１０４に記憶された複数のプログラム命令１０８を実行する。サイズ及びコスト制限によって、エンジン１０２によって提供される命令メモリ１０４の量は多くの場合限られている。エンジンメモリ１０４の限られた記憶容量が、プログラム１０８の全体のサイズ及び複雑さに厳し過ぎる制限を課すことを防ぐべく、図１は、１つのエンジン１０２におけるプログラム１０８の実行が進むにつれて、大きなプログラム１０８の複数のセグメント（例えば１０８ｂ）を１つのエンジン１０２に直接的にダウンロードする命令キャッシングスキームの一例を示す。
【００１７】
図１に示された例において、それぞれのエンジン１０２は、プログラム１０８の複数の命令のサブセットを記憶する命令キャッシュ１０４を有する。例えば、パケットエンジン１０２ａの命令キャッシュ１０４ａは、プログラム１０８のセグメント１０８ｂを持つ。プログラム１０８の残りは、複数のエンジン１０２によって共有される１つの命令記憶装置１０６に記憶されている。
【００１８】
最終的には、エンジン１０２ａは、セグメント１０８ｂ以外のプログラムセグメントにアクセスする必要があるかもしれない。例えば、プログラムはセグメント１０８ｂ外のプログラム１０８内のポイントに分岐する又は連続的に進む場合がある。エンジン１０２にプログラム１０８の実行を継続させることを可能にすべく、ネットワークプロセッサ１００は、要求された／必要とされた（複数の）セグメントをエンジン１０２ａのキャッシュ１０４ａにダウンロードしてよい。したがって、キャッシュに記憶される（複数の）セグメントは、プログラムの実行が進行するにつれて動的に変化する。
【００１９】
図１に示されるように、複数のエンジン１０２は、命令記憶装置１０６からキャッシュする複数の命令を受け取る。共有の命令記憶装置１０６は、更には、プロセッサ１００の内部又は外部にある階層的により高い命令記憶装置１１０から複数の命令をキャッシュしてよい。言い換えると、命令記憶装置１０４、１０６、及び１１０は、エンジンのＬ１命令キャッシュ１０４及び異なる複数のエンジンによって共有されるＬ２命令キャッシュ１０６を含むキャッシュヒエラルキーを形成する。
【００２０】
図１は、全ての複数のエンジン１０２に働く命令記憶装置１０６を示すが、ネットワークプロセッサ１００は、それに代えて、異なる複数のエンジン１０２の組に働く複数の共有された記憶装置１０６を有してよい。例えば、１つの共有された命令記憶装置１０６がエンジン＃１から＃４用の複数のプログラム命令を記憶するのに対し、他の１つの記憶装置がエンジン＃５から＃８用の複数のプログラム命令を記憶してよい。さらに、図１は、１つのプログラム１０８の複数の命令を記憶するエンジンキャッシュ１０４及び命令記憶装置１０６を示すが、それに代えて、エンジンキャッシュ１０４及び命令記憶装置１０６は、異なる複数のプログラムに属する複数の命令の複数の組を記憶してもよい。例えば、共有された命令記憶装置１０６は、それぞれのエンジン１０２用の、さらにはエンジン１０２の異なる複数のスレッド用の、複数の異なるプログラム命令を記憶してよい。
【００２１】
図１は、説明をし易くすべく、複数の命令１０８をソースコードで示す。共有された記憶装置１０６によって記憶されて複数のエンジンに配布される実際の命令は、典型的にはエンジンによって提供される命令セットで表される実行可能な複数の命令であってよい。
【００２２】
場合によっては、プログラム実行を継続すべくエンジン１０２によって必要とされる１つのプログラムセグメントは、"オンデマンド"原理で提供されてよい。すなわち、エンジン１０２は、実行を要する命令がキャッシュ１０４ａ内になくなるまで、命令キャッシュ１０４ａ内に記憶されている命令１０８ｂを実行し続けてよい。これが発生すると、エンジン１０２は、実行されるべき次の命令を含むプログラムセグメントを配送するよう、共有された記憶装置１０６に知らせる。この"オンデマンド"シナリオは、一方で、エンジン１０２のプログラム実行に遅延を発生させる。すなわち、"オンデマンド"シーケンスでは、エンジン１０２（又はエンジン１０２のスレッド）は必要とされる命令がロードされるまでアイドルでいつづける。この遅延は、必要とされる命令をエンジン１０２のＬ１キャッシュ１０４にダウンロードすることに伴うオペレーションだけでなく、共有された記憶装置１０６へのアクセスに対するエンジン１０２ｂ−１０２ｎ間の競合によっても生じ得る。
【００２３】
この遅延を可能性として避けるべく、図２は、プログラムの実行を継続するために命令が要求される時刻より前に、エンジンのキャッシュ１０４内へのプログラム命令の"プリフェッチ"をプログラムに開始させるフェッチ命令１２２を含む、プログラムソースコードリストの一部を示す。例えば、図２に示されるように、フェッチ命令１２２は、次のセグメント１０８ｂ内のポイントに実行が進む前に、エンジン１０２ｎに、共有された命令記憶装置１０６に必要とされる次のセグメント１８０ｂを求めて要求を発行（"１"）させる。エンジン１０２が、フェッチ命令１２２に続いて命令１２４を処理し続けている間に、要求されたセグメント１０８ｂがエンジン１０２の命令キャッシュ１０４ｎ内にロードされる。言い換えると、プログラムセグメントを取得する（"２"）ために使用される期間は、エンジンのプリフェッチ命令１２２の実行と、現在キャッシュされている（複数の）プログラムセグメント内にエンジン１０２が実効すべき命令が"無くなる"時間との間の期間に重なる。
【００２４】
図２に示される例では、複数のプログラム命令を取得する時間は、そのフェッチ命令に続く命令１２２を実行している期間によって隠匿された。フェッチ遅延は、完了するのにいくらかの時間を要する命令１２０（例えば、メモリオペレーション）の後に当該フェッチ命令を実行することによっても"隠匿"され得る。
【００２５】
図２に示されたフェッチ命令の例は、以下の構文を持つ。
【００２６】
Prefetch (SegmentAddress,SegmentCount)[, optional_token]
【００２７】
SegmentAddressは、共有記憶装置１０６から取得するプログラムの開始アドレスを表し、SegmentCountは、それに続くフェッチすべきセグメントの数を表す。場合によっては、SegmentAddressは、プログラムセグメントの開始アドレスを特定すべく限定されてよい。
【００２８】
optional_tokenは以下の構文を持つ。
【００２９】
optional_token = [ctx_swap[signal],][sig_done[signal]]
【００３０】
ctx_swapパラメータは、プログラムセグメントのフェッチの完了をシグナルが示すまで、他のエンジン実行スレッドにスワップするようエンジン１０２に命令する。sig_doneパラメータもフェッチの完了おいてセットされるステータスシグナルを示すが、エンジン１０２に複数のコンテクストをスワップするようには命令しない。
【００３１】
図２に示された命令構文は単なる一例であり、複数のプログラム命令をフェッチする他の複数の命令は、異なる複数のパラメータ、複数のキーワード、及び異なる複数のオプションを有してよい。さらに、命令は複数の異なるレベルにあってよい。例えば、命令は、エンジンの命令セットの一部であってよい。他にも、命令は、フェッチ命令に対応する複数のターゲット命令（例えば、エンジンが実行可能な複数の命令）を生成すべく１つのコンパイラによって処理されるソースコード命令であってよい。そのようなコンパイラは、ソースコードのテキスト文字を" 複数のトークン"にグループ化する語彙解析、そのトークンを文法的フレーズにグループ化する構文解析、ソースコードをより抽象的に表す中間言語コード生成、最適化等の、他の従来のコンパイラオペレーションを実行する。
【００３２】
フェッチ命令は、コード開発中にプログラマによって手動で挿入されてよい。例えば、初期のパケット分類に基づいて、そのパケットに対する残りのプログラムフローは知られている。したがって、フェッチ命令は、当該分類の後に、パケットを処理するのに必要な複数のセグメントを取得する。例えば、高レベル言語で書かれたプログラムは、以下の命令を含む。
【００３３】
switch(classify(packet.header)) {
case DropPacket: {
prefetch(DropCounterInstructions);
}
case ForwardPacket {
prefetch(RoutingLookupInstructions)
prefetch(PacketEnqueueInstructions);
} }
【００３４】
これは、パケットの分類に基づいて、適切な（複数の）プログラムセグメントをエンジン１０２の命令キャッシュ１０４にロードする。
【００３５】
プログラマが手動でフェッチ命令をコードに挿入してもよいが、フェッチ命令は、コンパイラ、アナライザ、プロファイラ、及び／又はプリプロセッサのようなソフトウェア開発ツールによってコードに挿入されてもよい。例えば、コードフロー解析が、異なるプログラムセグメントがいつロードされるべきかを特定してよい。例えば、コンパイラが、メモリアクセス命令の後、又は実行するのにいくらか時間を要する複数の命令のセットの前に、フェッチ命令を挿入してよい。
【００３６】
図３は、"オンデマンド"及び"フェッチ"命令に応答して複数の命令を取得する１つのエンジンのオペレーションを表すフローチャートを示す。図３に示されるように、実行すべき次のプログラム命令を特定するプログラムカウンタ１３０が更新される。例ば、次の連続する命令アドレスに進めるべくプログラムカウンタ１３０がインクリメントされるか、又は分岐命令に応答してカウンタ１３０がある他の命令アドレスにセットされてよい。示されるように、エンジンは、エンジンの命令キャッシュがプログラムカウンタによって特定される命令を現在保持しているか否かを判断１３２する。保持していない場合には、保持していない命令を共有された記憶装置からフェッチ１３６が取得するまで、エンジンスレッドはストール１３４する（例えば、命令を要求するスレッドがエンジンからスワップアウトされる）。
【００３７】
実行されるべき１つの命令がエンジンの命令キャッシュにあれば、エンジンは実行すべき次の命令がフェッチ命令であるか否かを判断１４０する。そうであれば、エンジンは、要求された（複数の）プログラムセグメントのフェッチ１４２を開始することができる。そうでなければ、エンジンは、通常通り命令を処理１４４することができる。
【００３８】
図４は、共有される命令キャッシュ１０６のアーキテクチャの一例を示す。命令キャッシュ１０６は、例えばネットワークプロセッサのスタートアップの間に、複数のエンジンで共有する複数の命令（"１"）を取得する。その後、共有された命令キャッシュ１０６は、複数の命令１０８の複数の部分を、必要に応じて及び／又は要求に応じて、複数のエンジンに配布する。
【００３９】
図４のアーキテクチャ例において示されるように、異なる２つのバス１５０、１５２が、共有されたキャッシュ１０６を複数のエンジン１０２に接続する。バス１５０は、複数のフェッチ要求を共有されたキャッシュ１０６に運ぶ（"２"）。これらの要求は、フェッチすべき（複数の）プログラムセグメント及び要求しているエンジンを特定する。複数の要求は、その要求がプリフェッチであるか"オンデマンド"であるかを特定してもよい。高バンド幅のバス１５２は、要求された（複数の）プログラムセグメントの中の複数の命令を、要求しているエンジン１０２に戻す（"４"）。バス１５２のバンド幅は、共有キャッシュ１０６が要求された複数の命令を複数のエンジンに同時に配布することを可能にする。例えば、バス１５２は、複数のエンジンに直接アロケートされたｎ本のラインに分割されてよい。例えば、４個のエンジンが複数のセグメントを要求した場合、それぞれはバスバンド幅の２５％がアロケートされる。
【００４０】
示されるように、共有されたキャッシュ１０６は、複数の要求が到着すると、例えばシーケンシャルサービスのための（ファーストインファーストアウト）ＦＩＦＯキュー１５４に複数の要求をキューしてよい。一方で、上記のように、実行されるべき命令がエンジンの命令キャッシュ１０４にロードされていない場合、スレッドはストールする。このように、実際にストールをもたらす"オンデマンド"要求に応えることは、ストールしないかもしれない結果になる"プリフェッチ"要求に応えることより切迫していることを意味する。示されるように、共有キャッシュ１０６は、複数のプリフェッチ要求を越えて複数のデマンド要求にプライオリティを与えることができる１つのアービタ１５６を含む。アービタ１５６は、専用回路を含んでよいし、プログラム可能であってもよい。
【００４１】
アービタ１５６は、様々な方法で複数のデマンド要求に優先順位をつけることができる。例えば、アービタ１５６は、デマンド要求をキュー１５４に加えず、代わりにその要求を速やかなサービス（"３"）のために提供する。複数の"デマンド"要求の間で優先順位をつけるべく、アービタ１５６は、キュー１５４内の複数の要求を超えてアービタ１５６によってプライオリティが与えられる、独立した"デマンド"ＦＩＦＯキューを管理してもよい。アービタ１５６は、デマンド要求をサービスすべく、進行中の複数の命令ダウンロードを速やかにサスペンドしてもよい。さらに、アービタ１５６は、"オンデマンド"要求を発行しているエンジンへの複数のセグメント命令の配布に、バス１５２のバンド幅の、１００％でない場合には、大部分をアロケートしてよい。
【００４２】
図５は、エンジンの命令キャッシュのアーキテクチャ例を示す。示されるように、キャッシュ記憶装置は、バス１６４を通じて共有された命令記憶装置１０６から受け取った命令を記憶する複数のメモリデバイス１６６ｘの集合によって提供される。個々のメモリ要素１６６ａは、１つのプログラムセグメントを保持するサイズであってよい。示されるように、それぞれのメモリ１６６ｘはアドレスデコーダと関連しており、アドレスデコーダは処理されるべき１つの命令のアドレスをエンジンから受け取り、その命令が関連するメモリ１６６内にあるか否かを判断するする。異なる複数のデコーダは、１つのアドレス上でパラレルに動作する。すなわち、それぞれのデコーダは、その関連するメモリを同時に検索する。メモリ１６６ｘの１つの中に発見されると、メモリ１６６ｘユニットは、エンジンによる処理のための要求された命令を出力１６８する。複数のメモリ１６６のいずれの中にも命令アドレスが発見されない場合、"ミス"信号１６８が生成される。
【００４３】
前述のように、１つのエンジンは複数の実行スレッドを提供してよい。実行中に、これらの複数の異なるスレッドは、複数の異なるプログラムセグメントをエンジンの命令キャッシュにロードする。キャッシュが満たされたとき、セグメントをキャッシュにロードすることは、ある他のセグメントがキャッシュから削除されることを要求する（"犠牲"）。何らかの保護なしでは、あるスレッドが他のスレッドによって現在使用されているセグメントを犠牲にする場合がある。他のスレッドが処理を再開したとき、最近犠牲にされたセグメントが共有されるキャッシュ１０６から再びフェッチされるかもしれない。命令キャッシュ１０４のこのスレッド内のスラッシングは、何度も繰り返される場合があり、システムのパフォーマンスを著しく低下させる。なぜなら、複数のセグメントは１つのスレッドによってキャッシュにロードされ、別のスレッドによって早々に犠牲にされ、短い時間の後に再びロードされるからである。
【００４４】
そのようなスラッシングに対処することを目的として、種々のメカニズムが、セグメントを犠牲にするスレッドの機能に制限を課すことができる。例えば、図６は、それぞれのエンジンスレッドがキャッシュ１０４の一部に排他的にアロケートされている１つのエンジンの命令キャッシュ１０４の、メモリマップを示す。例えば、スレッド０ １７２は、Ｎ個のプログラムセグメント１７２ａ、１７２ｂ、１７２ｎ用にメモリがアロケートされている。１つのスレッドのためにフェッチされた複数の命令セグメントは、キャッシュ１０４のスレッドのアロケーション内に存在することができる。スラッシングを防ぐことを目的として、ロジックが、他の複数のスレッドにアロケートされた複数のキャッシュパーティションから、１つのスレッドが複数のセグメントを犠牲にすることを制限してよい。
【００４５】
キャッシュされたセグメントに速やかにアクセスすることを目的として、１つのスレッドに関連する制御レジスタ及び状態レジスタ（ＣＳＲ）が、アロケートされたキャッシュ部分の開始アドレスを記憶してよい。このアドレスは、例えばスレッドの数に基づいて計算されてよい（例えば、アロケーション開始アドレス＝ベースアドレス＋(スレッド＃×１スレッド当たりにアロケートされたメモリ））。それぞれのパーティションは、例えばキャッシュエンジンへの共有される記憶装置１０６からのバーストフェッチサイズ又は共有記憶装置１０６からの転送の他の粒度に対応する、複数のセグメントにさらに分割されてよい。ＬＲＵ（最長時間未使用）情報が、１つのスレッドのアロケートされたキャッシュ部分の中の異なるセグメントに対して管理される。したがって、ＬＲＵスキームでは、与えられたスレッドのキャッシュの中で最も長期間使用されていないセグメントが最初に犠牲にされる。
【００４６】
示されたマップはまた、異なる複数のスレッド間で分割された領域に加えて"ロックダウン"部分１７０を有する。ロックダウン領域内の複数の命令は、イニシャライズ時にロードされ、犠牲から保護される。全スレッドは、この領域に記憶された複数の命令にアクセスして、実行することができる。
【００４７】
図６に示されたスキームのようなメモリアロケーションスキームは、スレッド間のスラッシングを防ぐことができる。一方で、他のアプローチも使用することができる。例えば、アクセスカウントが、現在セグメントを使用している複数のスレッドに関連づけられてよい。当該カウントが零に到達すると、当該セグメントが犠牲にされる。他にも、キャッシュ犠牲スキームは、異なる複数のルールを適用し得る。例えば、そのスキームは、いずれのスレッドによってもアクセスされていないロードされたセグメントを犠牲にすることを避けようとしてもよい。
【００４８】
図７は、エンジン１０２のアーキテクチャの一例を示す。エンジン１０２は、パケット処理用に適合された縮小命令セットコンピューティング（ＲＩＳＣ）プロセッサであってよい。例えば、エンジン１０２は、汎用プロセッサの命令セットによって通常提供される浮動小数命令又は整数除算命令を提供しない。
【００４９】
エンジン１０２は、他のコンポーネントに送信する又は他のコンポーネントから受信したデータをバッファリングする転送レジスタ１９２ａ、１９２ｂを介して、他のネットワークプロセッサコンポーネント（例えば、共有メモリ）と通信してよい。エンジン１０２は、他の（複数の）エンジンに組み込まれた"隣接"レジスタ１９４ａ、１９４ｂを介して、他の複数のエンジン１０２と通信してよい。
【００５０】
示されたエンジン１０２の例は、複数の実行スレッドを提供する。複数のスレッドをサポートすべく、エンジン１０２は、スレッドのそれぞれに対して１つのプログラムコンテクスト１８２を記憶する。コンテクスト１８２は、プログラムカウンタのようなスレッド状態データを含むことができる。スレッドアービタ１８２は、実行すべき１つのスレッドのプログラムコンテクスト１８２ｘを選択する。選択されたコンテクストに対するプログラムカウンタは、１つの命令キャッシュ１０４に供給される。キャッシュ１０４は、プログラムカウンタによって特定される命令が現在キャッシュされていない（例えば、セグメントがロックダウンキャッシュ領域又は現在実行しているスレッドにアロケートされた領域の中にそのセグメントがない）場合に、プログラムセグメントのフェッチを開始することができる。そうでなければ、キャッシュ１０４は、キャッシュされた命令を命令デコードユニット１８６に送ることができる。場合によっては、命令デコードユニット１９０は、当該命令を"フェッチ"命令とみなしてよく、セグメントのフェッチを開始してよい。そうでなければ、デコード１９０ユニットは、処理のために１つの実行ユニット（例えば、ＡＬＵ）に命令を供給して、異なる複数のエンジンによって共有されるリソース（例えば、メモリコントローラ）に、コマンドキュー１８８により要求を開始する。
【００５１】
フェッチコントロールユニット１８４は、共有されたメモリ１０６からのプログラムセグメントの取得を処理する。例えば、フェッチコントロールユニット１８４は、共有キャッシュ要求バスへのアクセスをネゴシエートして、要求を発行して、返された複数の命令を命令キャッシュ１０４の中に記憶することができる。フェッチコントロールユニット１８４は、以前にキャッシュされた複数の命令の犠牲を処理してもよい。
【００５２】
エンジン１０２の命令キャッシュ１０４及びデコーダ１８６は、１つの命令処理パイプラインの一部を形成する。すなわち、複数のクロックサイクルにわたって、１つの命令は、キャッシュ１０４からロードされ、デコード１８６され、（例えば、複数の汎用レジスタ１９６、複数の次の隣接レジスタ１９４ａ、複数の転送レジスタ１９２a、及びローカルメモリ１９８から）複数の命令オペランドがロードされ、実行データパス１９０によって実行される。最後に、オペレーションの結果が、（例えば、複数の汎用レジスタ１９６、ローカルメモリ１９８、複数の隣接レジスタ１９４ｂ、又は複数の転送レジスタ１９２ｂに）書き込まれる。多くの命令がパイプライン内に同時に存在し得る。すなわち、１つがデコードされている間に、他の１つがＬ１命令キャッシュ１０４からロードされている。
【００５３】
図８はネットワークプロセッサ２００の一例を示す。示されたネットワークプロセッサ２００は、Intel（登録商標）Internet eXchange network Processor (IXP)である。他のネットワークプロセッサは異なる設計を有する。
【００５４】
示されたネットワークプロセッサ２００は、１つのダイ上に集積された複数のパケットエンジン２０４の１つの集合を有する。上記のように、個々のパケットエンジン２０４は複数のスレッドを提供する。プロセッサ２００は、ネットワークオペレーションに含まれる"制御プレーン"タスクを実行すべく多くの場合プログラムされたコアプロセッサ２１０（例えば、StrongARM(登録商標) XScale（登録商標））を有してもよい。コアプロセッサ２１０は、一方で、"データプレーン"タスクを処理してもよく、追加のパケット処理スレッドを提供してよい。
【００５５】
示されるように、ネットワークプロセッサ２００は、プロセッサ２００と他の複数のネットワークコンポーネントとの間でパケットを運ぶことができるインタフェース２０２を特徴として有してもよい。例えば、プロセッサ２００は、スイッチファブリックに接続された他の（複数の）プロセッサ又は回路にプロセッサ２００がパケットを送ることを可能にするスイッチファブリックインタフェース２０２（例えば、Common Switch Interface（ＣＳＩＸ）インタフェース）を有してよい。プロセッサ２００は、プロセッサ２００が物理層（ＰＨＹ）及び／又は複数のリンク層デバイスと通信することを可能にするインタフェース２０２（例えば、System Packet Interface （ＳＰＩ）インタフェース）を有してよい。プロセッサ２００は、例えばホストと通信するためのインタフェース２０８（例えば、Peripheral Component Interconnect （ＰＣＩ）バスインタフェース）を有してもよい。示されるように、プロセッサ２００は、複数のメモリコントローラ２０６、２１２、１つのハッシュエンジン、及びスクラッチパッドメモリのような、複数のエンジンによって共有される他の複数のコンポーネントを有する。
【００５６】
上記のパケット処理技術は、ＩＸＰのような１つのネットワークプロセッサ上に種々の方法で実装されてよい。例えば、コアプロセッサ２１０は、ネットワークプロセッサの立ち上げの間に、共有される命令キャッシュ１０６に複数のプログラム命令を送ってよい。さらに、例えばプロセッサが非常に多数のエンジンを有している場合には、プロセッサ２００は、"２層の"命令キャッシュ階層に代えて、Ｎ層の命令キャッシュ階層を有してよい。
【００５７】
図９は、上記の技術が組み込まれたネットワークデバイスを示す。示されるように、デバイスは、スイッチファブリック３１０（例えば、クロスバ又は共有メモリスイッチファブリック）によって相互に接続されたラインカード３００（"複数のブレード"）の集合を持つ。スイッチファブリックは、例えば、ＣＳＩＸ、或いはハイパートランスポート、インフィニバンド、Peripheral Component Interconnect - Express （ＰＣＩ−Ｘ）等のような他のファブリック技術に準拠してよい。
【００５８】
個々のラインカード（例えば、３００ａ）は、ネットワーク接続を通じて通信を処理する１以上の物理層（ＰＨＹ）デバイス３０２（例えば、光、有線、及び無線ＰＨＹ）を含んでよい。複数のＰＨＹは、異なるネットワークメディアから運ばれた複数の物理信号と、デジタルシステムによって使用される複数のビット（例えば、複数の"０"及び複数の"１"）との間で変換する。ラインカード３００は、複数のフレームに対してエラー検出及び／又はエラー訂正のようなオペレーションを実行することが可能なフレーマデバイス３０４（例えば、イーサネット（登録商標）、同期光ネットワーク（ＳＯＮＥＴ）、高レベルデータリンク（ＨＤＬＣ）フレーマ、又は他の複数のレイヤ２デバイス）を含んでもよい。示されたラインカード３００は、上記の命令キャッシング技術を用いる１以上のネットワークプロセッサ３０６を含んでよい。ネットワークプロセッサ３０６は、（複数の）ＰＨＹ３００より受け取った複数のパケットに対して複数のパケット処理オペレーションを実行し、当該複数のパケットを、スイッチファブリック３１０を通じて、選択された出力インタフェースを提供するラインカードに導くようプログラムされている。場合によっては、（複数の）ネットワークプロセッサ３０６は、複数のフレーマデバイス３０４に代わって、"レイヤ２"動作を実行してよい。
【００５９】
図８及び９は、１つのエンジン、ネットワークプロセッサ、及び複数のネットワークプロセッサが組み込まれたデバイスのアーキテクチャ例を示すが、この技術は、他のエンジン、ネットワークプロセッサ、及びデバイスの設計に実装され得る。さらに、この技術は、種々のネットワークデバイス（例えば、ルータ、スイッチ、ブリッジ、ハブ、トラフィックジェネレータ等）に使用され得る。
【００６０】
ここで使用されている回路という用語は、ハードウェア組み込み回路、デジタル回路、アナログ回路、プログラマブル回路等を含む。プログラマブル回路はコンピュータプログラムで動作してよい。
【００６１】
そのようなコンピュータプログラムは、高レベル手続き型又はオブジェクト指向のプログラミング言語で書かれてよい。一方で、（複数の）プログラムは、必要に応じて、アセンブリ又はマシン言語で実装されることができる。その言語は、コンパイル又はインタープリトされてよい。さらに、これらの技術は、種々のネットワーク環境で使用され得る。
【００６２】
他の複数の実施形態は、以下の複数の請求項の範囲内にある。
【特許請求の範囲】
【請求項１】
少なくとも１つのプログラムの少なくとも一部の複数の命令を記憶する１つの命令記憶装置と、
前記命令記憶装置に結合された複数のエンジンの組であって、エンジンの個々は、エンジン命令キャッシュ、及び前記少なくとも１つのプログラムの少なくとも一部のサブセットを要求する回路を有する、複数のエンジンの組と
を備えるプロセッサ。
【請求項２】
前記エンジン命令キャッシュはＬ１キャッシュを有し、
前記命令記憶装置はＬ２キャッシュを有する
請求項１に記載のプロセッサ。
【請求項３】
複数のエンジンの第２の組に結合された第２命令記憶装置
さらに備える請求項１に記載のプロセッサ。
【請求項４】
前記複数のエンジンは、マルチスレッド化された複数のエンジンを有する
請求項１に記載のプロセッサ。
【請求項５】
要求する前記回路は、
前記エンジンの命令キャッシュに１つの命令が記憶されていない旨の決定に応答して要求する回路
を有する請求項１に記載のプロセッサ。
【請求項６】
要求する前記回路は、
１つのフェッチ命令に応答して要求する回路
を有する請求項１に記載のプロセッサ。
【請求項７】
前記フェッチ命令は、異なるスレッドにスイッチするよう前記エンジンに命令する
請求項６に記載のプロセッサ。
【請求項８】
前記フェッチ命令は、前記フェッチの状態に関する１つのシグナルを特定する
請求項６に記載のプロセッサ。
【請求項９】
前記フェッチ命令は、前記命令記憶装置がキャッシュすべき量を特定する
請求項６に記載のプロセッサ。
【請求項１０】
前記フェッチ命令は、前記プログラムの複数の命令をグルーピングする複数のセグメントの数として、前記量を特定する
請求項９に記載のプロセッサ。
【請求項１１】
前記エンジンは、
犠牲にすべき複数の命令を、前記エンジン命令キャッシュから選択する回路
を有する請求項１に記載のプロセッサ。
【請求項１２】
スイッチファブリックへの１つのインタフェース、メディアアクセスコントローラ（ＭＡＣ）への１つのインタフェース、及び物理層（ＰＨＹ）デバイスへの１つのインタフェースの少なくとも１つ
をさらに備える請求項１に記載のプロセッサ。
【請求項１３】
１つのダイに集積された複数のエンジンによって共有される１つの命令記憶装置に記憶された複数の命令のサブセットを要求する段階と、
複数の命令の前記サブセットを、前記サブセットを要求している前記複数のエンジンの１つで受け取る段階と、
前記受け取った複数の命令のサブセットを、前記複数のエンジンの１つの命令キャッシュに記憶する段階と
を備える方法。
【請求項１４】
前記命令記憶装置はＬ２キャッシュを有し、
前記複数のエンジンの１つの前記命令キャッシュはＬ１キャッシュを有する
請求項１３に記載の方法。
【請求項１５】
前記命令記憶装置は複数の命令記憶装置の組の１つを有し、前記複数の命令記憶装置のうちの異なる命令記憶装置は、複数のエンジンの異なる組によって共有される
請求項１３に記載の方法。
【請求項１６】
前記複数のエンジンは、マルチスレッド化された複数のエンジンを有する
請求項１３に記載の方法。
【請求項１７】
要求する段階は、
前記エンジンの命令キャッシュに１つの命令がキャッシュされていない旨の決定に応答して要求する段階
を有する請求項１３に記載の方法。
【請求項１８】
要求する段階は、
１つのフェッチ命令に応答して要求する段階
を有する請求項１３に記載の方法。
【請求項１９】
前記フェッチ命令に応答して異なるエンジンスレッドにスイッチする段階
をさらに備える請求項１３に記載の方法。
【請求項２０】
犠牲にすべき複数の命令を、前記エンジンの命令キャッシュから選択する段階
をさらに備える請求項１３に記載の方法。
【請求項２１】
１つのネットワークを通じて受け取った１つのパケットを処理するための前記複数の命令の前記サブセットを実行する段階
をさらに備える請求項１４に記載の方法。
【請求項２２】
１つのコンピュータ可読媒体に配置されたコンピュータプログラム製品であって、前記製品は、１つのプロセッサに、
ソースコードにアクセスさせ、
アクセスされたソースコードに基づいてターゲットコードを生成させる
複数の命令を備えており、
前記コンピュータプログラム製品の複数の命令は、前記プロセッサに、
複数のエンジンによって共有される１つの命令記憶装置によって記憶された複数のプログラム命令のサブセットへの要求に対応する、ソースコード命令に対するターゲットコードを生成させる複数の命令
を有する製品。
【請求項２３】
前記ソース命令は、フェッチすべき複数のプログラムセグメントの数を特定する
請求項２２に記載の製品。
【請求項２４】
前記ソース命令は、１つのコンテクストスイッチを指定する
請求項２２に記載の製品。
【請求項２５】
前記ターゲットコードは、前記複数のエンジンの１つの命令セットで表されるターゲットコード有する
請求項２２に記載の製品。
【請求項２６】
前記複数のエンジンの前記命令セットは、浮動小数オペレーションのためのいかなる命令も有していない
請求項２５に記載の製品。
【請求項２７】
１つのスイッチファブリックと、
前記スイッチファブリックによって相互に接続された複数のラインカードの組であって、複数のラインカードの前記組の少なくとも１つは、少なくとも１つのＰＨＹ及び少なくとも１つのネットワークプロセッサを有する、複数のラインカードの組と
を備え、
前記ネットワークプロセッサは、
１つの命令記憶装置と、
前記命令記憶装置に機能的に結合された、マルチスレッド化された複数のエンジンの組と
を含み、
複数のエンジンの前記組の個々は、
前記エンジンによって実行される複数の命令を記憶する１つのキャッシュと、
前記命令記憶装置から、前記命令記憶装置によって記憶された複数の命令のサブセットを要求する回路と
を持つネットワーク転送デバイス。
【請求項２８】
複数の命令の前記サブセットを要求する前記回路は、実行されるべき１つの命令が前記エンジンの命令キャッシュに発見されない場合に実行される回路を持つ
請求項２７に記載のネットワーク転送デバイス。
【請求項２９】
複数の命令の前記サブセットを要求する前記回路は、前記エンジンによって実行される１つの命令に応答する回路を持つ
請求項２７に記載のネットワーク転送デバイス。
【請求項３０】
１つの第２命令記憶装置と
前記第２命令記憶装置に結合された、マルチスレッド化された複数のエンジンの第２の組
をさらに含む請求項２７に記載のネットワーク転送デバイス。
【請求項１】
少なくとも１つのプログラムの少なくとも一部の複数の命令を記憶する１つの命令記憶装置と、
前記命令記憶装置に結合された複数のエンジンの組であって、エンジンの個々は、エンジン命令キャッシュ、及び前記少なくとも１つのプログラムの少なくとも一部のサブセットを要求する回路を有する、複数のエンジンの組と
を備えるプロセッサ。
【請求項２】
前記エンジン命令キャッシュはＬ１キャッシュを有し、
前記命令記憶装置はＬ２キャッシュを有する
請求項１に記載のプロセッサ。
【請求項３】
複数のエンジンの第２の組に結合された第２命令記憶装置
さらに備える請求項１に記載のプロセッサ。
【請求項４】
前記複数のエンジンは、マルチスレッド化された複数のエンジンを有する
請求項１に記載のプロセッサ。
【請求項５】
要求する前記回路は、
前記エンジンの命令キャッシュに１つの命令が記憶されていない旨の決定に応答して要求する回路
を有する請求項１に記載のプロセッサ。
【請求項６】
要求する前記回路は、
１つのフェッチ命令に応答して要求する回路
を有する請求項１に記載のプロセッサ。
【請求項７】
前記フェッチ命令は、異なるスレッドにスイッチするよう前記エンジンに命令する
請求項６に記載のプロセッサ。
【請求項８】
前記フェッチ命令は、前記フェッチの状態に関する１つのシグナルを特定する
請求項６に記載のプロセッサ。
【請求項９】
前記フェッチ命令は、前記命令記憶装置がキャッシュすべき量を特定する
請求項６に記載のプロセッサ。
【請求項１０】
前記フェッチ命令は、前記プログラムの複数の命令をグルーピングする複数のセグメントの数として、前記量を特定する
請求項９に記載のプロセッサ。
【請求項１１】
前記エンジンは、
犠牲にすべき複数の命令を、前記エンジン命令キャッシュから選択する回路
を有する請求項１に記載のプロセッサ。
【請求項１２】
スイッチファブリックへの１つのインタフェース、メディアアクセスコントローラ（ＭＡＣ）への１つのインタフェース、及び物理層（ＰＨＹ）デバイスへの１つのインタフェースの少なくとも１つ
をさらに備える請求項１に記載のプロセッサ。
【請求項１３】
１つのダイに集積された複数のエンジンによって共有される１つの命令記憶装置に記憶された複数の命令のサブセットを要求する段階と、
複数の命令の前記サブセットを、前記サブセットを要求している前記複数のエンジンの１つで受け取る段階と、
前記受け取った複数の命令のサブセットを、前記複数のエンジンの１つの命令キャッシュに記憶する段階と
を備える方法。
【請求項１４】
前記命令記憶装置はＬ２キャッシュを有し、
前記複数のエンジンの１つの前記命令キャッシュはＬ１キャッシュを有する
請求項１３に記載の方法。
【請求項１５】
前記命令記憶装置は複数の命令記憶装置の組の１つを有し、前記複数の命令記憶装置のうちの異なる命令記憶装置は、複数のエンジンの異なる組によって共有される
請求項１３に記載の方法。
【請求項１６】
前記複数のエンジンは、マルチスレッド化された複数のエンジンを有する
請求項１３に記載の方法。
【請求項１７】
要求する段階は、
前記エンジンの命令キャッシュに１つの命令がキャッシュされていない旨の決定に応答して要求する段階
を有する請求項１３に記載の方法。
【請求項１８】
要求する段階は、
１つのフェッチ命令に応答して要求する段階
を有する請求項１３に記載の方法。
【請求項１９】
前記フェッチ命令に応答して異なるエンジンスレッドにスイッチする段階
をさらに備える請求項１３に記載の方法。
【請求項２０】
犠牲にすべき複数の命令を、前記エンジンの命令キャッシュから選択する段階
をさらに備える請求項１３に記載の方法。
【請求項２１】
１つのネットワークを通じて受け取った１つのパケットを処理するための前記複数の命令の前記サブセットを実行する段階
をさらに備える請求項１４に記載の方法。
【請求項２２】
１つのコンピュータ可読媒体に配置されたコンピュータプログラム製品であって、前記製品は、１つのプロセッサに、
ソースコードにアクセスさせ、
アクセスされたソースコードに基づいてターゲットコードを生成させる
複数の命令を備えており、
前記コンピュータプログラム製品の複数の命令は、前記プロセッサに、
複数のエンジンによって共有される１つの命令記憶装置によって記憶された複数のプログラム命令のサブセットへの要求に対応する、ソースコード命令に対するターゲットコードを生成させる複数の命令
を有する製品。
【請求項２３】
前記ソース命令は、フェッチすべき複数のプログラムセグメントの数を特定する
請求項２２に記載の製品。
【請求項２４】
前記ソース命令は、１つのコンテクストスイッチを指定する
請求項２２に記載の製品。
【請求項２５】
前記ターゲットコードは、前記複数のエンジンの１つの命令セットで表されるターゲットコード有する
請求項２２に記載の製品。
【請求項２６】
前記複数のエンジンの前記命令セットは、浮動小数オペレーションのためのいかなる命令も有していない
請求項２５に記載の製品。
【請求項２７】
１つのスイッチファブリックと、
前記スイッチファブリックによって相互に接続された複数のラインカードの組であって、複数のラインカードの前記組の少なくとも１つは、少なくとも１つのＰＨＹ及び少なくとも１つのネットワークプロセッサを有する、複数のラインカードの組と
を備え、
前記ネットワークプロセッサは、
１つの命令記憶装置と、
前記命令記憶装置に機能的に結合された、マルチスレッド化された複数のエンジンの組と
を含み、
複数のエンジンの前記組の個々は、
前記エンジンによって実行される複数の命令を記憶する１つのキャッシュと、
前記命令記憶装置から、前記命令記憶装置によって記憶された複数の命令のサブセットを要求する回路と
を持つネットワーク転送デバイス。
【請求項２８】
複数の命令の前記サブセットを要求する前記回路は、実行されるべき１つの命令が前記エンジンの命令キャッシュに発見されない場合に実行される回路を持つ
請求項２７に記載のネットワーク転送デバイス。
【請求項２９】
複数の命令の前記サブセットを要求する前記回路は、前記エンジンによって実行される１つの命令に応答する回路を持つ
請求項２７に記載のネットワーク転送デバイス。
【請求項３０】
１つの第２命令記憶装置と
前記第２命令記憶装置に結合された、マルチスレッド化された複数のエンジンの第２の組
をさらに含む請求項２７に記載のネットワーク転送デバイス。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公表番号】特表２００７−５１０９８９（Ｐ２００７−５１０９８９Ａ）
【公表日】平成１９年４月２６日（２００７．４．２６）
【国際特許分類】
【出願番号】特願２００６−５３８２８６（Ｐ２００６−５３８２８６）
【出願日】平成１６年１０月２９日（２００４．１０．２９）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０３５９２３
【国際公開番号】ＷＯ２００５／０４８１１３
【国際公開日】平成１７年５月２６日（２００５．５．２６）
【出願人】（５９１００３９４３）インテル・コーポレーション (1,101)
【Ｆターム（参考）】
【公表日】平成１９年４月２６日（２００７．４．２６）
【国際特許分類】
【出願日】平成１６年１０月２９日（２００４．１０．２９）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０３５９２３
【国際公開番号】ＷＯ２００５／０４８１１３
【国際公開日】平成１７年５月２６日（２００５．５．２６）
【出願人】（５９１００３９４３）インテル・コーポレーション (1,101)
【Ｆターム（参考）】
[ Back to top ]