(57)【要約】ストレージサーバー200はセマンティックプロセッサ100を用いてクライアントのリクエストを解析し応答する。セマンティックプロセッサ100内の直接実行パーサ140は、定義された文法にしたがって、クライアントのストレージサーバーのリクエストを含む入力ストリームを解析する。セマンティックプロセッサ実行エンジン150は、データ（例えば、データの移動、数学的及び論理的演算など）の操作をすることができ、クライアントがリクエストしてきたオペレーションを行うために直接実行パーサからのリクエストに応じてマイクロコードセグメントを実行する。このストレージサーバーによれば、作業効率が向上し、いくつかの実施例ではストレージサーバー全体を小型化することが可能になり、メディアデバイスの回路基板上に搭載可能な数個の比較的小型の集積回路から構成することができる。このセマンティックプロセッサ自体は、おそらく数ワットの電力を必要とするにすぎない。【選択図】図３
2007537550.tif 000002
【特許請求の範囲】
【請求項１】
データ演算用のクライアントのリクエストを受信するデータグラムインターフェイスと、
少なくとも一つのデータ記憶装置にアクセスするストレージインターフェイスと、
前記少なくとも一つのデータ記憶装置とデータ演算に応じてストレージインターフェイスを介してトランザクションするために、格納された文法に基づいて、受信したクライアントのリクエストを解析する能力を有するセマンティックプロセッサと、を備えるストレージサーバー。
【請求項２】
前記セマンティックプロセッサは、前記データグラムインターフェイスにおいて受信したデータグラムからシンボルを解析する直接実行パーサと、前記直接実行パーサによって指示通りにデータ演算を行う複数のセマンティックコード実行エンジンと、を備える請求項１に記載のストレージサーバー。
【請求項３】
前記セマンティックプロセッサは、前記データグラムインターフェイスにおいて受信したデータグラムからシンボルを解析する直接実行パーサと、前記解析されたデータグラムに対してデータ演算を行うマイクロプロセッサと、を有する請求項１に記載のストレージサーバー。
【請求項４】
前記セマンティックプロセッサは、パーサスタックを備え、スタックシンボルに従って前記データグラムインターフェイスにおいて受信したデータグラムからシンボルを解析する直接実行パーサと、前記直接実行パーサによって指示された通りデータ演算を行う少なくとも一つのセマンティックコード実行エンジンと、を備え、前記セマンティックコード実行エンジンは、前記パーサスタックの内容を修正することにより前記直接実行パーサのオペレーションを変更する能力を有している請求項１に記載のストレージサーバー。
【請求項５】
前記少なくとも一つのデータ記憶装置は、筐体を有するディスクドライブであり、前記データグラムインターフェイス、前記ストレージインターフェイス及び前記セマンティックプロセッサが前記ディスクドライブの筐体内に内蔵されている請求項１に記載のストレージサーバー。
【請求項６】
前記ストレージインターフェイスは、二次的なデータグラムインターフェイスであり、前記少なくとも一つのデータ記憶装置は前記二次的なデータグラムインターフェイスを介して遠隔からアクセスされるようになっており、前記ストレージサーバーは、当該ストレージサーバーにより受信したクライアントのリクエストを満たすために、前記少なくとも一つのデータ記憶装置のクライアントとして作動することができるようになっている請求項１に記載のストレージサーバー。
【請求項７】
さらに、データ演算用のクライアントのリクエストを受信する第２のデータグラムインターフェイスと、前記セマンティックプロセッサに前記二つのデータグラムからの解析データグラムシンボルの間で切り替えを行わせるパーサソースセレクタと、を備える請求項１に記載のストレージサーバー。
【請求項８】
さらに、前記格納された文法の少なくとも一部を保持する再構成可能なメモリを備え、当該メモリにより、前記ストレージサーバーが少なくとも二つの異なるストレージサーバープロトコルのセットを有するストレージサーバーとして機能すべく再構成可能になっている請求項１に記載のストレージサーバー。
【請求項９】
バッファでセマンティック式にデータを解析することによって、デジタルデータの処理を制御するように構成されている直接実行パーサと、
前記直接実行パーサによって指示されたときにデータ演算を行うように構成されているセマンティックプロセッシングユニットと、
前記セマンティックプロセッシングユニットによって指示されたときに前記デジタルデータを処理するように構成されたメモリサブシステムと、備えることを特徴とする装置。
【請求項１０】
前記メモリサブシステムは、メモリと前記セマンティックプロセッシングユニットとの間に接続された複数のメモリキャッシュを含む請求項９に記載の装置。
【請求項１１】
前記メモリサブシステムは、前記セマンティックプロセッシングユニットによって指示されたときにデジタルデータに対して暗号化演算を行う暗号化回路を含む請求項９に記載の装置。
【請求項１２】
前記メモリサブシステムは、前記セマンティックプロセッシングユニットによって指示されたときに検索機能(look-up functions)を実行する検索エンジンを含む請求項９に記載の装置。
【請求項１３】
前記バッファは、外部ネットワークから前記直接実行パーサによって解析されるデータを受け取るようになっている請求項９に記載の装置。
【請求項１４】
前記バッファは、前記セマンティックプロセッシングユニットから前記直接実行パーサによって解析されるデータを受け取るようになっている請求項９に記載の装置。
【発明の詳細な説明】
【関連する出願】
【０００１】
本出願は、2004年5月11に出願されたアメリカ特許出願No.10/843,727、2004年7月28日に出願されたアメリカ仮特許出願No.60/591,978、2004年7月27日に出願されたアメリカ仮特許出願No.60/591,663 、2004年7月22日に出願されたアメリカ仮特許出願No.60/590,738及び2004年7月28日に出願されたアメリカ仮特許出願No.60/592,000の優先権を主張している。
【０００２】
2003年1月24日に、Somsubhra Sikdarにより出願された「再構成可能なセマンティックプロセッサ」という題名の同時係属のアメリカ特許出願No.10/351,030を引用することにより、その内容が本出願に組み入れられているものとする。
【技術分野】
【０００３】
本発明はストレージサーバーに関し、より詳しくはデジタルセマンティックプロセッサ(“digital semantic processor”)を用いたストレージサーバーの実施例に関する。
【背景技術】
【０００４】
従来は、ストレージサーバーは、その他のコンピューターやコンピューター機器（以下、「クライアント」とする）に対するメディア及びファイルアクセスを提供するネットワーク接続されたコンピューターである。このストレージサーバーはWorld Wide Network（WAN）や、Local Area Network（LAN）を通してアクセス可能である。また、このストレージサーバーは他のコンピューター機器と専用のポイント・トゥ・ポイント接続を共有している場合もある。
【０００５】
ストレージサーバーは、Network Attached Storage (NAS)サーバー、Storage Area Network (SAN)サーバー、アプリケーション形式のサーバーなどを含む様々な種類のものでよい。
【０００６】
NASサーバーはディレクトリ構造を持つ。NASサーバーに対するリクエストは、通常、ファイルパスまたはファイル名を指定したり、作成や、読み取りや、書き込みや、添付などの作業(action)を指定するものである。NASサーバーは、リクエストを一つまたは複数のディスクのセクターまたはブロックへのディスクアクセストランザクション（disc sector/block disc access transactions）へと変換し、ディスク（またはその他の記憶媒体）にアクセスし、要求されたファイルレベルのトランザクションを実行する。このようなサーバーは、ファイルの開始位置を見つけるためにディレクトリ構造を保持し、それを利用している。また、このようなサーバーは、セグメント化されたファイルを再構成するとともに、ディスクまたは書き込み可能なメディア上に自由なセクターを見つけるために、ファイル・アロケーション・テーブルを保持し、それを利用している。
【０００７】
SANサーバーは、一般的に、ディスクセクターまたはブロックに基づいたトランザクションに対する直接のリクエストを受け取る。そして、SANサーバーは、ファイルシステムやデータブロック間の関係を理解しなくてもよい。ブロックリクエストは、メディアデバイス上の物理的なブロック位置に関係することもあるが、より典型的には、SANサーバーは論理上のブロックをサポートする。このようにして、サーバーは、物理的に単一のディスクドライブを、論理上で複数のディスクドライブとして見えるようにすることができる。また、RAID(Redundant Array of Independent Disks)スキームのように、物理的に複数のディスクドライブを、理論上で単一のディスクドライブとして見えるようにすることができる。
【０００８】
アプリケーション形式のサーバーは、一般的には、メディア特有の(media-specific)フォーマットでメディアに対するアクセスを提供する。例えば、アプリケーションスタイルのサーバーは、（ファイル名を知らないかもしれない、もしくはファイルに直接アクセスする権限を持たないかもしれない）クライアントから明確なファイルパスやファイル名が得られなくても、ストリーミング形式の音楽または映像に対するアクセスを提供することができる。一方で、ファイルからストリーミングメディアを読み取り、それをストリーミングパッケトフォーマットでカプセル化する。
【０００９】
構造上、大多数のストレージサーバーは、一般目的のコンピューターとほとんど異ならない（場合によっては、一般的なコンピューターより多くの高速度のディスクドライブ及びディスクバスコントローラーを備えていることもある）。図1は、典型的なストレージサーバー20のブロック図である。中央処理装置（CPU）22は、一般的には１つまたは複数のマイクロプロセッサであり、格納されたプログラム命令に従ってサーバーを操作する。このプロセッサは、逐次命令を処理する実行形式を提案し、またそれを導入したフォン・ノイマンにちなんで、フォン・ノイマン（VN）プロセッサまたはフォン・ノイマン（VN）マシンと呼ばれることが多い。
【００１０】
CPU 22は、前面のバス（FSB）26を介して、メモリコントローラー／ハブ（MCH）24に接続される。これは、マイクロプロセッサのプログラム命令を格納したり、データを保存したり、供給したり、消費したりするその他のシステムコンポーネントにCPU 22を接続させることに関する。MCH 24は、メモリバス32を介してシステムメモリ30を制御する。また、MCH 24は、ハブバス42を介してPCI (Peripheral Component Interconnect)ブリッジ40と通信することにより、メモリ30またはCPU 22のどちらか一方とPCI接続されたデバイスとの間でデータをやり取りする。
【００１１】
PCIブリッジ40及びPCIバス44を介して多様なデータソースやデータシンクデバイスをサーバー20に接続することができる。ストレージサーバーとして使う目的で2つの不可欠なデバイスは、ネットワークインターフェイスカード(NIC) 50とATA (AT Attachment)のようなメディアコントローラ60である。
【００１２】
NIC 50は、サーバーがローカルエリアネットワーク（LAN）や他のネットワークまたはFibre Channelスイッチ構造に直接接続することを可能にする。また、クライアントや当該サーバーに対してネットワークが見える状態とする他の装置とのポイント・トゥ・ポイント接続をも可能にする。こうして、NIC 50は、サーバーに対するコミュニケーションパスを提供し、データリクエストをクライアントから受け取るとともにそれらのリクエストに応答する。実際のネットワークの物理的コミュニケーションプロトコルは、例えば、それに対し、どのような有線または無線のコミュニケーションプロトコルが使用されても、異なるNICを挿入するとともに当該NIC用のソフトウェアデバイスドライバーをCPU 22へとロードすることによって、変えることができる。
【００１３】
ATAコントローラー60は、ハードディスクや、光ディスクや、テープドライブなどを接続するための少なくとも一つのATAバス62を提供する。各ATAバス62により、一つまたは二つのメディアデバイス64をストレージサーバー20に接続することができる。サーバーによっては、SATA (serial ATA)制御装置やSCSI (Small Computer System Interface)ホストアダプターのようなその他の制御装置を利用してもよい。
【００１４】
ストレージサーバーとして作動するためには、CPU 22は多様なソフトウェアプログラムを実行しなければならない。NASの場合、2つの一般的なフォーマットはNFS (Networked File System)とCIFS (Common Internet File System)である。前者のプロトコルは主としてUNIX環境下で用いられ、後者のプロトコルは主としてマイクロソフトのOS環境下で用いられる。NFSサーバーに対して、以下のようなソフトウェアプロセスがNFSを実行するのを助ける。すなわち、NIC 50用ネットワークデバイスドライバーや、TCP/IPドライバーや、TCP/IPからNFSサーバーソフトウェアへとデータを送るためのRPC (Remote Procedure Call) ドライバーおよびXDR (External Data Representation) ドライバーや、NFSサーバーソフトウェアそれ自体や、ローカルファイルシステムや、NFSサーバーソフトウェアをローカルファイルシステムとインターフェイスで接続するためのVFS (Virtual File System)ドライバーや、データバッファリングソフトウェアや、記憶装置制御装置／ホストアダプター（storage controller/host adapter）用のデバイスドライバなどがある。各NFSデータトランザクションに対して、CPU 22は、それぞれのソフトウェアの間で要求されるようにコンテキストを変化させながら、これらのソフトウェアそれぞれに対してプロセスを実行しなければならない。十分な能力を提供するためには、ストレージサーバー20は、比較的高速かつ高出力で動作しなければならず、マイクロプロセッサと、チップセットと、ネットワークインターフェイスと、メモリと、その他の周辺機器と、冷却ファンと、を操作するために、強制的な空気冷却及び十分な電力供給を必要とする。現在の技術状況では、1 Gbps (Gigabit per second) の全二重通信のネットワークコネクションの場合、約300ワットの出力を必要とし、800立方インチの体積を占め、記憶媒体を抜きにして約1500ドルの出費となる。
【００１５】
明確にNASリクエストを処理することを目的とした、ICハードウェアを作ろうと試みているメーカーもある。一般的に、このようなICの設計コストは、流れの速い遠隔コミュニケーションプロトコルの業界では回収することはできない。この業界では、特殊なプロトコルとストレージインターフェイスの限られた組み合わせに対処するように作成された特定の複雑な回路設計がすぐに時代遅れとなることはよくある。
【発明の開示】
【００１６】
多くのストレージサーバーのアプリケーションにおいて、マイクロプロセッサによるシーケンシャルなプログラムを用いたプローチは非効率的でありしかもかさばるものであると認識されている。現状では大多数のストレージサーバーは（most of the storage server's existence）、NICで受け取ったクライアントからのリクエストに応じてストレージサーバーの機能を実行するのに用いられている。リクエスト自身は、リクエストされた機能とオプションを限られた数しか持たないプロトコル特有のフォーマットで表されている。これらのリクエストに応答して、しっかり定義されたストレージシステムのコマンドがメディアデバイスに送られ、これらのコマンドの結果がプロトコル特有のデータグラムをクライアントへ返すのに用いられる。
【００１７】
ストレージサーバーがプログラム可能であり、コード共通性を持つことはかなり望ましい特性である。したがって、大容量のプロセッサとチップセット（例えば、Intel Corporation  社製やAdvanced Micro Device社製の物）が使用されてきており、ストレージサーバーをプログラム可能にするとともに標準的なオペレーティングシステムの使用を可能にし、それによりコストを削減している。残念ながら、そのようなオペレーション構造では、一般目的のマイクロプロセッサに基づいたシステムの柔軟性及び能力は、ほとんど使われなくなるか、あるいは非効率的に使われるにすぎないようになるであろう。
【００１８】
本発明は、ストレージサーバーに対して異なるアーキテクチャを提供するものであり、その代表的な実施例では、一般的にセマンティックプロセッサと称されているものが用いられる。このようなデバイスは構成可能であり、その処理（processing）がその「プログラミング（programming）」に依存するVNマシンのように再構成可能であるのが好ましい。本明細書では、「セマンティックプロセッサ」は少なくとも2つの以下の構成要素を持つ。すなわち、定義された文法に基づいて入力ストリームを解析するための直接実行パーサ(direct execution perser)と、直接実行パーサからのリクエストに応答してデータを制御すること（例えば、データの移動、数学的演算及び論理的演算など）ができる直接実行エンジンである。
【００１９】
セマンティックプロセッサのプログラミングはVNマシンに用いられる標準的なマシンコードと異なる。VNマシンでは、データパケットのプロトコル入力パラメーターは、シーケンシャルなマシン命令を用いて、非効率な点を分岐し、ルーピングしかつスレッド切り替えしながら、可能性のあるすべての入力と順次比較される。これに対し、セマンティックプロセッサは入力ストリームの「意味(semantics)」に直接応答する。言い換えると、セマンティックプロセッサが実行する「コード」セグメントは、入力データにより直接駆動(driven)される。例えば、パケット内に現れる可能性がある75程度のCIFSコマンドについて、セマンティックプロセッサが、パケットで送られる実際のCIFSコマンドに関連する文法やマイクロ命令をロードすることを可能にするのに必要なのは、以下で記述される実施例における単一の解析サイクルだけである。
【００２０】
以下の実施例で記述するストレージサーバーアプリケーションでは、セマンティックプロセッサは、従来のVNプロセッサ、チップセット及び付属機器の機能の多くを実行することができる。セマンティックプロセッサは、ネットワークポートまたはデータグラムインターフェイスからデータグラムを受け取る。これらのデータグラムの一部は、データオペレーションに対するクライアントのリクエストを含むであろう。セマンティックプロセッサは、サーバーによってサポートされるサーバープロトコル文法に対して設計されたパーサテーブルを用いて、受け取ったデータグラムの要素を解析する。何が解析されたかに基づいて、セマンティックプロセッサは、一つまたは複数のデータ記憶装置と共に応答のデータオペレーションを実行する。データオペレーションは、単一または複数の簡易実行ユニット上でマイクロ命令コードセグメントを起動することで実行される。データオペレーションが実行されると、セマンティックプロセッサはクライアントに送り返すための応答データグラムを作成する。この結果として生じるオペレーション上の効率により、いくつかの実施例においては、ストレージサーバー全体は、比較的小型で、メディアデバイスのプリント基板上に配置することができる数個の集積回路へとまとめることができ、セマンティックプロセッサ自身は、おそらく数ワットの電力を消費するに過ぎない。
【００２１】
以下の添付図面に基づいて本件出願の開示内容（発明を実施するための最良の形態）を読むことにより、本説明を最もよく理解できるだろう。
【発明を実施するための最良の形態】
【００２２】
図２は、本発明に係る多くの実施例を表現するハイレベルブロック図を示している。ストレージサーバーは、データグラムインターフェイス90及びストレージインターフェイス110を有するセマンティックプロセッサ100を備えている。このデータグラムインターフェイス90は、例えばネットワーク80（以下で示す）やクライアントとのポイント・トゥ・ポイント接続を介して、クライアントにサーバーとの接続を提供する。ストレージインターフェイス110は、セマンティックプロセッサに、クライアントからのリクエストに応じてデータ記憶装置120とのデータトランザクションを開始するためのパスを提供する。このデータ記憶装置はローカルであってもよい。また、このデータ記憶装置は、例えばセマンティックプロセッサ100がNASサーバーをクライアントに対してエミュレートしている場合、図示されているサーバーにネットワーク接続されていてもよい。その場合、同時に遠隔SANサーバーを物理的記憶装置として用いられる。
【００２３】
図３は、セマンティックプロセッサ100を備えたストレージサーバー200のより詳細なブロック図を示している。データグラムインターフェイス90は、セマンティックプロセッサ100のバッファ130を物理的インターフェイスデバイス（PHY）92と接続させる。物理的インターフェイスデバイス（PHY）92の例としては、イーサーネットや、Fibre Channelや、802.11xや、ユニバーサル・シリアル・バス（USB）や、ファイヤーワイヤーや、その他の物理レイヤーインターフェイスなどに対する光学的なあるいは電気的なもしくは無線によるドライバーとレシーバーのペアなどが挙げられる。データグラムインターフェイスは、入力デジタルデータストリームをバッファ130に供給し、バッファ130から出力デジタルデータストリームを受け取る。
【００２４】
図３において、ストレージインターフェイス110は、データ記憶装置120とセマンティックプロセッサ100間のブロックI／Oバスとして実施される。様々な実施例において、このバスは、セマンティックプロセッサ及びデータ記憶装置の構成のされかたによっては、ケーブル接続（iSCSI、Fibre Channel、SATA）でもサーキットボードバス（SATA）でもよい。図３は、ディスク制御装置122、ドライブエレクトロニクス124及びディスク126（ディスクの円盤、モーター及び読み書き用ヘッドをまとめたもの）などのハードディスクタイプのメディアデバイスの主な要素を示している。
【００２５】
セマンティックプロセッサ100の構成の1つが、図３で示しているストレージサーバー内に示されている。セマンティックプロセッサ100は、バッファ130において受け取る入力パケットまたは入力フレーム（例えば入力「ストリーム」）の処理を制御する直接実行パーサ (DXP：direct execution parser)を備えている。DXP 140は、現在のフレームから現在のシンボルまでの構文解析に基づいた、終端シンボル(terminal symbol)もしくは非終端のシンボル(non-termina symbol)からなる内蔵パーサスタック(perser stack)を保持している。パーサスタックの一番上にあるシンボルが終端シンボルである場合、DXP 140は、入力ストリームの先頭の部分のデータを終端シンボルと比較し、作業を継続するためにそれらが一致することを期待する。パーサスタックの一番上にあるシンボルが非終端シンボルである場合、DXP 140は非終端シンボル及び現在の入力データを用いて、スタックにある文法生成物（grammber production）を拡張する。解析が継続している間、DXP 140はセマンティックコード実行エンジン（SEE）150に入力セグメントを処理するか、あるいはその他のオペレーションを実行するように指示する。
【００２６】
この構造は、データの要求に応じて実行エンジンにタスクを割り当てる高性能文法パーサを備えており、データグラムプロトコルなどの高度に構成された入力に対し適応性があり、効果を発揮する。好ましい実施例では、セマンティックプロセッサは、そのテーブルを変更することにより再構成することができ、それによりVNマシンの魅力である柔軟性を持つ。セマンティックプロセッサは、与えられた入力に応答するので、一般的にVNマシンより小規模の命令セットで効率的に動作する。以下で説明するが、セマンティックプロセッサはマシンコンテキスト内でのデータ処理を可能にするので、この命令セットは有益なものである。
【００２７】
セマンティックプロセッサ100は、所定の機能を実行するために少なくとも三つのテーブルを用いる。生成規則を検索するためのコード(code for retrieving production roule)は、パーサテーブル（PT）170内に保存される。文法的生成規則(grammatical production roules)は、生成規則テーブル（PRT）180内に保存される。SEE 150に対するコードセグメントは、セマンティックコードテーブル（SCT）190内に保存される。
【００２８】
パーサテーブル170内のコードは、生成規則テーブル180内の生成規則を示す。パーサテーブルのコードは、例えば行列（row-column）フォーマットまたはコンテント・アドレッサブル（content addressable）フォーマットで保存される。行列フォーマットでは、テーブルの行は、内部パーサスタック上の非終端コードによってインデックス付けされる。そして、テーブルの列は、入力（例えば、現在Si-Bus上にあるシンボル）の先頭の部分にある入力データ値によってインデックス付けされる。コンテント・アドレッサブル（content addressable）フォーマットでは、非終端コードと入力データ値を連結することにより、テーブルに対する入力を提供することができる。
【００２９】
生成規則テーブル180は、パーサテーブル170内のコードによってインデックス付けされる。これらのテーブルは、パーサテーブルへのクエリー(query)が、非終端コード及び入力データ値に適用できる生成規則を直接送り返してくるよう、図3に示すようにリンクされてもよい。直接実行パーサは、スタックの一番上にある非終端コードをPRTから送り返されてきた生成規則と置き換え、その後、その入力の解析を継続する。
【００３０】
実際には、生成規則テーブル内に、多くの異なる文法に対するコードが同時に存在することができる。例えば、1つのコードのセットを、MAC（Media Access Control）パケットヘッダーフォーマット解析に割り当て、他のコードのセットを、アドレス解決プロトコル（ARP：Address Resolution Protocol）パケット処理や、インターネットプロトコル（IP）パケット処理や、通信制御プロトコルパケット（TCP）処理や、リアルタイム転送プロトコル（RTP）処理などに割り当てることができる。CIFSや、NFSや、その他のストレージサーバーのプロトコルに対する文法は、ストレージサーバー機能を追加するために、生成規則コードメモリに追加される。非終端コードは、生成規則コードメモリ122内で何らかの特定の順序で割り当てられる必要もなく、特定のプロトコルに関連するブロック内で何らかの特定の順序で割り当てられる必要もない。
【００３１】
セマンティックコードテーブル190は、パーサテーブルコードごとにインデックス付けすることができるか、生成規則テーブル180からインデックス付けすることができるか、もしくは両方でインデックス付けすることができる。一般的に、解析結果により、DXP 140は、所定の生成規則に対して、セマンティックコードテーブル190からのコードセグメントがSEE 150によってロードされかつ実行されるべきかどうかを判断することができる。
【００３２】
セマンティックコード実行エンジン150は、マシンコンテキスト160に対するアクセスパスを持つ。このマシンコンテキスト160は構成されたメモリインターフェイスであり、コンテキストシンボルによるアドレス化が可能である。マシンコンテキスト160と、パーサテーブル170と、生成規則テーブル180と、セマンティックコードテーブル190は、シンクロナスDRAM及びシンクロナスCAMのような内蔵メモリデバイスや、外部メモリデバイスや、またはこのようなリソースの組み合わせを用いてもよい。各テーブルまたはコンテキストは単に、共有された物理的メモリスペースに対するコンテキストインターフェイスに、その他のテーブルまたはコンテキストのうち一つまたは複数を提供するだけでよい。
【００３３】
セマンティックプロセッサ100の機能上のブロックに対する最適な設計の詳細については、本発明の範囲内には入っていない。適用できるセマンティックプロセッサの機能上のブロックの詳細なアーキテクチャのいくつかの例については、同時係属のアメリカ特許出願No. 10/351,030を参照されたし。この出願の内容は、それを引用することにより本出願に組み入れられているものとする。
【００３４】
ストレージサーバーコンテキスト内におけるセマンティックプロセッサ100の機能は、具体例により、さらによく理解できる。本例では、イーサーネット、IP、TCPがサポートする構造と共にCIFSコマンド及びCIFSデータ構造が用いられる。当業者であれば、ここで教示された概念がその他のサーバーコミュニケーションプロトコルにも同様に適用できるということを理解するであろう。
【００３５】
図４は、イーサーネット／IP／TCP／CIFSフレーム250（トレーラー(trailers)とチェックサム(checksums)は無視している）に関連したヘッダー／データブロックを示している。MACヘッダーは、その他のものとともに、サーバー200に提供するように意図されたあらゆるフレームに対するサーバー200のMACアドレスを含むようになっている。サーバー200は、さまざまなネットワーク及び転送プロトコルに対応しているが、この例では、インターネットプロトコル（IP）のネットワークヘッダー及び通信制御プロトコル（TCP）の転送プロトコルヘッダーを用いている。このTCPヘッダーの後ろに、CIFSストレージメッセージブロック(SMB)ヘッダーであるヘッダー１と、ヘッダー１に関連したデータを有するSMBデータバッファであるバッファ１が続く。多くのCIFSオペレーションコードは、フレームの長さの最大長が限度を越えない限り、必要に応じて同じSMB内のその他のCIFSオペレーションコードと組み合わせることができる。第二、第三などのオペレーションコードに対する追加のヘッダーは、第一のヘッダーの最後の数フィールドだけを持ち、それ以外の全フィールドは第一のヘッダーからインプライド(implied)される。図のように、最後のSMBヘッダーは、ヘッダーNとバッファNを含む。
【００３６】
図５は、フレームの第一のSMBヘッダーとSMBバッファのさらなる詳細を示している。完全なSMBヘッダーは、最初にそのプロトコルを示す。すなわち、キャラクター（character）0xFFは、これがSMBヘッダーであることを示す。コマンドキャラクターがプロトコルキャラクターの後に続き、リクエストされているのかあるいは応答すべきなのかいずれかの動作のためのオペレーションコードを示す。ステータス及びフラグフィールドは、SMBのその他のフィールドをどう解釈すべきかを判定するか、エラーが起こっているかどうかを判定するか、またはその両方を行う。MACシグネチャー（この例ではMACはメディア確認コード(Media Authorization Code)のことを表している）は、それが有効なとき、メッセージ認証に用いられる。
【００３７】
SMB内の次の４個のフィールドは、TIDと、PIDと、UIDと、MIDフィールドである。TID（階層識別子（Tree Identifier））は、クライアントがサーバーリソースとの接続に成功したときに、サーバーからクライアントに対して付与される。クライアントは、後のリクエストで、この付与されたTIDを用いて、そのリソースに問い合わせる。PID（process identifier）はクライアントにより付与される（サーバーがPIDを書きとめ、それを用いてクライアントに応答するが、その使用は主としてクライアントによる）。UID(user identifier)は、接続を承認したユーザーを識別するために、サーバーにより付与される。MID（multiple identifier）により、クライアントは、各トランザクション毎に異なるMIDを用いることで、未解決の複数のトランザクションに対し、同一のPIDを用いることができる。
【００３８】
パラメーターフィールドは長さと構造が可変であり、一般的に第一のキャラクターは次のパラメーターの長さを表し、その後にSMBオペレーションコードに適したパラメーターワードが続く。このオペレーションコードが、第二のSMBヘッダーとSMBバッファが続くことを示すものである場合、パラメーターワードの一部は、後続のオペレーションコードを示し、後続の短縮されたヘッダーの埋め合わせをする。
【００３９】
SMBはバイトカウントとバイトカウント長のバッファで終了する。このようなバッファは、例えば、ファイル名の送信、書き込んだデータのサーバーへの転送、読み込んだデータのクライアントへの転送などに用いられる。
【００４０】
このような背景のもとで、セマンティックプロセッサ100（図3に示している）に対する基本的なCIFSの機能性についての説明を進めることができる。
【００４１】
図３及び４に示されているように、バッファ130で受信した新しい各フレームは、MACヘッダーから始まる。このMACヘッダーは、宛先アドレスと、送信元アドレスと、ペイロードタイプフィールドと、ペイロードと、チェックサムを含んでいる。DXP 140は、宛先アドレスがストレージサーバー200に対して割り当てられたアドレスと一致し、かつそれがブロードキャストアドレスと一致することを期待して宛先のアドレスを解析する。宛先のアドレスが解析できない場合、DXPはSEE 150上でSEEコードセグメントを立ち上げてこのフレームを消去する。そうでなければ（otherwise）、送信元のアドレスは、SEEに消費され（consumed）、返答時に使用するために保存される。そしてペイロードタイプフィールドが解析される。
【００４２】
本例では、IPに対してMACペイロードタイプが解析される。したがって、DXPはIPヘッダーをそのパーサスタック上で解析するための生成規則をロードし、IPヘッダーを介して動作する。例えば、これは、パケットがストレージサーバーに提供されるよう意図されていたことを裏付けるために宛先IPアドレスを解析することや、IPヘッダーチェックサムをチェックしたり、アドレッシングテーブルをアップデートしたり、パケット返信やその他の処理のために宛先及び送信元アドレスを保存したり、フラグメント化されたIPパケットを再構築したりするためにSEEをディスパッチング(dispatching)すること、を含んでもよい。このIPヘッダーで示されるプロトコルは、DXPパーサスタック上で次のヘッダー（本例ではTCPヘッダー）用の生成規則をロードするために解析される。
【００４３】
その後TCPヘッダーが解析される。SEEは、宛先IPアドレスと、送信元IPアドレスと、宛先ポートと、送信元ポートと、に関係するTCPコネクションコンテキストをロードするために送られる（これは有効なコネクションが存在している場合に限られる。本実施例では、このような場合を想定している）。SEEはその後、連続番号と、確認応答番号と、ウインドウと、チェックサムと、コネクションコンテキストをアップデートするのに必要なその他のフィールドと、を消費する(consume)。このコンテキストは返答時に使用するため保存される。
【００４４】
MAC、IP及びTCPヘッダーがストレージサーバーとの有効なコネクションに対して解析されたと仮定すると、入力ストリーム上の次のシンボルは、このデータがSMBリクエストを含んでいることを示すものとなる。DXP 140は、このシンボルを解析し、CIFS文法生成規則をそのスタック上へロードする。
【００４５】
この次の入力シンボルは、CIFSコマンド（CIFSオペレーションコード）用の非終末シンボルと適合(matched)される。例えば、パーサテーブルは、CIFSオペレーションコード及び非終末シンボルの取りうるすべての組み合わせそれぞれに対するエントリーを持つことができる。CIFSコマンドが解析されると、コマンドフィールド内にあるCIFSオペレーションコードに関係する文法がパーサスタック上へとロードされる。
【００４６】
CIFSヘッダーのステータスフィールド及びフラグフィールドは解析されてもよいが、SEE 150により消費され、パケットコンテンツを解釈するときに使用するためにマシンコンテキスト160内に保存されるのが好ましい。
【００４７】
また、MACシグネチャーと、TIDと、PIDと、UIDと、MIDフィールドは、SEEに向かわされる（送られる）。このSEEは、このフィールドを返信フレームの再構築時に使用するために保存し、パケットが有効（valid）な送信元から送られ、適切なリソースへと向けられているかを認証するためにマシンコンテキスト160内で検索を実行する。
【００４８】
パラメーターフィールドのフォーマットはCIFSオペレーションコードによって変化する。オペレーションコードによっては、パラメーターフィールドの要素を解析するか、マイクロコードのセグメントを使用するパラメーターを消費するようSEE 150に指示するのが好ましいかもしれない。以下において、一般的なCIFSコマンドに関する例をいくつか挙げる。
【００４９】
CIFS NEGOTIATEクライアントのリクエストは、新しいクライアントにより、そのクライアントには理解できるCIFS方言を識別するために用いられる。NEGOTIATE用のパラメーターフィールドは、受け入れることができる方言をヌル終端文字列（null-terminated strings）としてリスト化するバイトカウントシンボルへと続くバイトカウントを含む。NEGOTIATE用の生成規則は、DXP 140に指示し、SEE 150にバイトカウントを保存させ、その後DXP 140は第一の入力文字列をNULLキャラクターまで解析する。文字列が既知の方言(dialect)であると解析された場合、DXP 140は、SEE 150に現在のフレームコンテキストに対応する方言用のコードを保存させる。また、SEE 150は、バイトカウントシンボルが解析完了（すべての方言が解析完了されたことを示す）されたかどうかを判定する。そうでなければ、SEE 150は、非終端シンボルをパーサスタックの一番上に載せ、DXP 140にその他の方言に対する残りの入力を解析させる。このプロセスはバイトカウントシンボルが解析され終わるまで続く。同時にSEE 150は、シンボルを入力ストリームの先頭へと載せ、DXP 140に方言の解析をやめさせる。DXP 140は、その後パケットの解析を終え、SEE 150に方言を（例えばpre-programmed hierarchical preferenceに従って）選択するように指示し、クライアントに新しいセッションに関連するパラメーターを付けた返答パケットを返信する。さらに、SEE 150は、新しいセッションのコンテキストをマシンコンテキスト160内にセットアップする。
【００５０】
クライアントがNEGOTIATE返答を受信すると、通常、クライアントは、セッションを完了するためにSESSION_SETUP_ANDXに対するSMBを送信する。DXP 140は、SMBを受信するとすぐに、第一のパラメーター（単語の合計数）を解析することができ、それがオペレーションコードとして適切であることを確認することができる。第二のパラメーターであるAnd X Commandは、このコマンドの後にこのフレーム内にもまた第二のコマンドXが現れるかどうか（及びどの第二のコマンドXが現れるかどうか）を示すものである（なお、CIFSは、「AndX」を用いて、以下に続くオペレーションコードと連結させてマルチオペレーションコードSMBを形成することができるオペレーションコードを識別する）。And X Commandが二番目のオペレーションコードが存在しない（0xFF）ことを示す場合、DXP 140はこれを解析することができ、作業を続けることができる。別々のオペレーションコードが存在する場合は、処理はより複雑になる。
【００５１】
第二のオペレーションコードは、様々なやり方で処理することができる。一つ目の方法は、第一と第二のオペレーションコードの取り得るすべての組み合わせに対して異なる別々の文法を書く方法である。この方法は、実現可能ではあるが、パーサテーブル及び生成規則テーブルの制限次第では、非効率的になりかねない。二つ目の方法は、マルチレベル文法を使用する方法である。この方法では、高レベルな文法がオペレーションコードを解析し、低レベルな文法が解析された各コードを処理する。三つ目の方法は、SEE 150からのプッシュバックメカニズムを使用する方法である。この方法では、例えば、And X Command パラメーターは、SEE 150にAnd X Commandを入力ストリームから保存するようにさせる生成規則をロードする。第一のオペレーションコードが完全に解析され終わると、SEE 150は、And X Commandパラメーターを入力ストリームの先頭へと戻すマイクロコードセグメントを起動するように指示される。DXP 140はその後、新しいオペレーションコードを解析し、第二のオペレーションコードが存在する場合には、その時点から新しいオペレーションコード用のパラメーターフィールド文法をロードすることを続ける。SMB内で追加されたAnd X Commandも、同様の方法で処理することができる。
【００５２】
その他のSESSION_SETUP_ANDXのパラメーターは、大半がセッションコンテキスト内に保存されるかあるいはパスワードの場合にはベリファイされるので、おそらく解析されることなくSEE 150により消費されることになろう。ヌル終端文字列（null-terminated strings）のパラメーターは、ヌル終端シンボルを探すために解析することができ、その後に、SEE150に対する、この時点で長さが決定されたシンボルの保存命令が続く。
【００５３】
一旦SESSION_SETUP_ANDXのコマンドが解析されると、SEE 150は返答パケットを作成するよう指示されることができる状態となる。しかし、第二のオペレーションコードが含まれる場合は、各オペレーションコードが処理されるまでパケットは完成されない。
【００５４】
LOGOFF_ANDXコマンドはセッションを終了するのに用いられる。このオペレーションコードに応じてセマンティックプロセッサにより実行される第一の機能は、SEE 150にこのセッション用のセッションコンテキストをマシンコンテキスト160から取り除かせることである。
【００５５】
TREE_CONNECT_ANDXコマンドは、セッションを、パラメーターストリングパスにより示される共有されたサーバーリソースと結びつけるために用いられる。このコマンドとともに含まれるパス文字列は、長さに対してのみ解析できるか、正しいサーバー名に対して解析できるか、もしくはその両方に対して解析できる。パス名の残りは解析することができる。ただ、有効なパスは、書き込み可能リソース上で頻繁に作成、破壊することができるので、各ディレクトリに対し的確な生成規則コードを維持することは挑戦的（challenging）かもしれない。したがって、一般的に、そのパスは開始のためにSEE 150に送られることとなる。他のやり方として、DXP 140は、「／」キャラクターを探して解析し、一回に一つのレベルだけSEE 150にパスを送信する。
【００５６】
SEE 150は、ブロックI／Oバスを介してデータ記憶装置120に保存されたディレクトリを読み込み、ルートディレクトリから開始し、そして、要求されたパスが存在してそれがクライアントから制限されていないことを確認することで、特定のパスを通過する。パスが正当であり、有効であると仮定すると、SEE 150は返答パケットを作成し、セッションコンテキスト内にパスを保存する。
【００５７】
NT_CREATE_ANDXコマンドは、ファイルまたはディレクトリを作成するか開く。DXP 140は、TREE_CONNECTコマンドを使用するときと同様、データ記憶装置120とのブロックI／Oトランザクションのために、このコマンドの大部分をSEE 150に渡してもよい。SEE 150は、可能ならば、適切なディレクトリを修正し、開かれたファイルに対しファイル識別子（file identifier(FID)）を割り当て、この開かれたファイルに対するファイルコンテキストをマシンコンテキスト160内で作成することにより、ファイルを開くか、作成するか、もしくはその両方を行う。SEE 150はその後、ファイル作成リクエスト／ファイルオープンリクエストの結果を示す適切な返答フレームをフォーマットする。
【００５８】
READ_ANDXコマンドは、クライアントにより、オープンFIDからデータを読み込むのに使用され、WRITE_Xコマンドは、クライアントにより、オープンFIDへデータを書き込むのに使用される。DXPがFIDパラメーターに至るまで解析すると、それはSEE 150に、Si-バスからFIDを取り出し、対応するファイルコンテキストをマシンコンテキスト160内で検索するように信号で伝える。SEE 150はその後、適切なブロックI／Oトランザクションを実行し、データ記憶装置120に対してデータの読み込みまたは書き込み、クライアントに対する返信パケットを作成する（construct）。なお、書き込みオペレーション返信フレームは、場合によっては、データ記憶装置とのすべてのブロックI／Oトランザクションが完了されるまでに生成されて送信されるようにしてもよい。
【００５９】
上述したコマンドは、実行可能性のあるCIFSコマンドの一部である。当業者であれば、これら上記の例から、どのようにしてセマンティックプロセッサが完全なCIFS機能を実行するか理解するであろう。さらに、セマンティックプロセッサがこれらのCIFSコマンドを実行することにより例示されるコンセプトは、セマンティックプロセッサ上でその他のストレージサーバープロトコルを実行することに適用できる。
【００６０】
図6は、その他のセマンティックプロセッサの実施例300を示している。セマンティックプロセッサ300は、4つのセマンティックコード実行エンジン152、154、156、158を備えている。セマンティックコード実行エンジン158は、ブロックI／Oサーキット112と通信する。マシンコンテキスト160は、2つの機能ユニットを備えている。この2つの機能ユニットは、可変マシンコンテキストデータメモリ（VMCD）162と配列マシンコンテキストデータメモリ（AMCD）164である。各SEEは、VMCD 162とはV-バスを介してやり取りを行うことができ、AMCD 164とはA-バスを介してやり取りを行うことができる。
【００６１】
セマンティックプロセッサ300では、DXP 140がSEEタスクを解析中のある特定の点において開始するべきであると決定すると、DXP 140はSEEの内の一つにSCT 140からマイクロ命令をロードするように信号で伝える。いくつかの命令セグメントに対するハンドルは、DXP 140に、それが任意の利用可能なSEEを選択することができることを示すようにしてもよい。また、このハンドルは、特定のSEE（例えばSEE 158は、ブロックI／Oに対するたった一つのアクセスのみ持つ）は、そのコードセグメントを受信するべきであることを示すようにしてもよい。複数のSEEが利用できることにより、いくつかの遅いタスク（例えばブロックI／O）がすべての処理を邪魔することなく、多くのタスクが平行して実行できるようになる。
【００６２】
厳密には必要ではないけれども、特定のSEEに特定の種類のタスクを割り振るようにすることもできる。例えば、SEE 152を指定された入力プロトコルSEEとすることができる。この入力プロトコルSEEは、IPと、TCPと、その他のプロトコルの入力側を処理し、クライアントと、セッションと、ファイルコンテキストを入ってくるCIFSフレームからのデータでアップデートするタスクに関与する。また、SEE 154をファイルシステムオペレーションの実行をするように指定することができる。このファイルシステムオペレーションは、例えば、ディレクトリと、ファイル・アロケーション・テーブルと、ユーザー／パスワードリストを理解しかつアップデート(update)したり、ユーザー及びリクエストなどを認証したりすることを含む。また、SEE 156を例えば、返信フレームの作成などのような、プロトコルの出力側の処理をするように指定することができる。さらに、SEE 158をデータ記憶装置とのやり取りを処理するように指定することもできる。このように分割することで、一つのSEEは、異なる解析タスクへと取り掛かりはじめているかもしれないDXP140を経由する必要なくその他のSEE上でマイクロコードを起動することができる。例えば、SEE 154はブロックI／O SEE 158上でタスクを起動し、ディレクトリを読み出すか書き換える（update）ことができる。他の例として、データが返信パケットに対して準備が整った時点で、出力プロトコルSEE 156はその他のSEEにより設定されるセマフォ(semaphore)を有することができる。
【００６３】
各SEEは、マシンコンテキストがデータにアクセスすることを可能にするパイプラインレジスタを有している。通常のCPUとは対照的に、好ましいSEEの実施例は、それらが処理するデータに対して使用される物理的データ記憶機構という概念を持たない。代わりに、データに対するアクセスはマシンコンテキストトランザクションの形態を取る。可変（例えばスカラー）データはV‐バスを介してアクセスされる。配列データはA‐バスを介してアクセスされる。入力ストリームデータはSi‐バスを介してアクセスされる。例えば、データコンテキストct内で所定の記憶場所offsetに配置されたｍオクテット長のスカラーデータの要素を読み込むために、SEEは命令デコーダーを使用し、V‐バスインターフェイスにバスリクエスト｛read, ct, offset, m｝を出す（issue）ように指示する。コンテキストmctは、セマンティックプロセッサのマスターコンテキストに問い合わせる。動作中の各CIFSセッションや、各オープンファイルや、各オープントランザクション等に対するサブコンテキストのようなその他のサブコンテキストは、通常、RSPが入力データを処理するのに合わせて、作成され、破壊される。
【００６４】
SEEパイプラインレジスタは、コマンドを送られるとすぐに、データ転送プロセスを制御する。複数のバス転送（bus transfer）がmオクテットを読み込むか書き込むように要求されると、パイプラインレジスタはトランザクションを終了まで追跡する。例として、6オクテットフィールドは、2つのマイクロ命令を使用してストリーム入力から可変マシンコンテキスト（machine-context variable）へと転送される。第一の命令は、6オクテットをSi‐バスからパイプラインレジスタへと読み込むことである。第二の命令は、その後、6オクテットをこのレジスタから可変マシンコンテキストへとV‐バスを介して書き込むことである。このレジスタインターフェイスは、どれだけ多くのバスデータサイクルが転送を達成するのに必要であっても、実行する。
【００６５】
VMCD 162は、V‐バス上で開始されるリクエストに役立つ。VMCD 162は、可変マシンコンテキストデータリクエストを物理的メモリトランザクションへと変換することができる。そのために、VMCD 162は、好ましくは、物理メモリ開始アドレスに対するマシンコンテキスト識別子を参照する変換テーブルを保持し、割り当て及び割り当て解除のための機構（mechanism）を持つ。そして、VMCD 162は、コンテキストが所定のSEEにより固定されることを可能にし、リクエストされたトランザクションがリクエストされたコンテキストの境界の外部へと流出（fall）しないことを確実にする。使用される実際のストレージ機構は、アプリケーションによって変えることができる。メモリは、完全に内蔵することも、完全に外付けにすることも、そららの二つの形態にすることもできる。また、大型外部メモリを有するキャッシュなどにすることもできる。外部メモリは、その他のメモリセクションに対する外部メモリと共有されてもよい。このメモリセクションとしては、所定の実施例におけるAMCDと、入力バッファと、出力バッファと、パーサテーブルと、生成規則テーブルと、セマンティックコードテーブルなどが挙げられる。
【００６６】
A-バスインターフェイス及びAMCD 164も、マシンコンテキスト配列の構成を備えていることを除き同様に動作する。異なる種類の配列及びテーブルに対し、割り当てや、割り当て解除や、書き込みや、読み込みや、検索や、場合によってはシンプルバスリクエストを用いたハッシュやソートさえ実行できるようにすることが好ましい。実際の基礎をなす（underlying）物理メモリは、異なる種類の配列及びテーブルに対し異なっていてもよい。この物理メモリは、例えば、高速オンボードRAMや、外部RAMや、外部ROMや、コンテント・アクセッサブル・メモリなどを含む。
【００６７】
図3に示されているストレージサーバーの構成は、本発明の実施例に係るサーバーの多数の実行可能性のある機能的パーティションの内の一つである。その他のいくつかの実行可能性のある構成が図7‐図10に示されており、以下においてそれらについて説明する。
【００６８】
図７は、一つまたは複数の従来のSATAドライブに対するインターフェイスを備えているストレージサーバー500を示している。ネットワークコネクション502（標準的な電子的または光学的なコネクタポートまたはアンテナ）により、クライアントは、要求されるプロトコルをサポートするFibre Channelや、EthernetなどのようなPHY 510と通信することができる。Ethernetに対しては、Broadcom BCM 5421またはMarvell 88E1011のような市販のPHYが使用可能である。
【００６９】
PHY 510は入力フレームをRSP 520に供給し、出力フレームをRSP 520から取り出す。RSP 520は、上述の構成の内の一つや、同時係属のアメリカ特許出願No. 10/351,030に記述されている構成の内の一つや、機能的に似ている他のあらゆるセマンティックプロセッシング構成で構成することができる。
【００７０】
RAM 530は、RSP 520に対して、例えばマシンコンテキストやバッファ用の物理的記憶装置を提供する。RAM 530は、数種類のメモリ（DRAM、Flash、CAMなど）で構成されていても、Synchronous DRAMのような一種類のメモリで構成されていてもよい。パーサテーブルと、生成規則テーブルと、セマンティックコードテーブルが、動作中に揮発性メモリに保存されたとき、起動用ROMまたは起動用フラッシュメモリが用いられ、RSP 520を初期化する。RSP 520がその他のデータ記憶装置と通信することを可能にするのに十分なコードが起動用メモリ内で利用可能である限り、非揮発性の格納されたテーブルの一部もデータ記憶装置内に存在することができる。
【００７１】
SATA制御装置540は、RSP 520のブロックI／Oポートに接続されており、RSP 520のディスクアクセスリクエストを制御する。SATA制御装置540は、例えばSII 3114やMarvell 88SX5080のような市販のSATA制御装置でよい。
【００７２】
SATA制御装置540は、SATAバスを介して、1つまたは複数のSATAデータ記憶装置と接続されている。図示されているように、ストレージサーバー500は、ドライブ550−0〜ドライブ550−Nを、それぞれSATAバス0〜SATAバスNを介してサポートする。
【００７３】
PHY 510、RSP 520、RAM 530及びSATA制御装置540は、共通のプリント基板（図示せず）上で相互に接続されるのが好ましい。このプリント基板は、SATAケーブルがバス0〜バスNを提供することで、ドライブと共に共通の筐体内に配置することができる。他のやり方として、SATAバス信号は、プリント基板上で、各ドライブのコネクターへ送られるか、コネクターを介してバックプレーン(backplane)へ送られてもよい。
【００７４】
別のストレージサーバーの実施例600が図8に示されている。好ましくは、この実施例においては、サーバー全体が、ストレージサーバーのクライエントとの接続を提供するためのネットワークコネクション602を有するディスクドライブのプリント基板上で実現される。ストレージサーバーアーキテクチャ500も同様の方法でパッケージ化することが可能であるが、ストレージサーバー600は、PHY 610及びSATA制御装置640をRSP 620内にまとめて入れることで、空間的余裕の作成及びコスト削減を実現する。SATA制御装置640は、少なくともその一部がSEEを用いて実施されるのが好ましい。
【００７５】
RSP 620インターフェイスのSATA制御装置セクションは、SATAケーブルまたは回路基板のバスを介して、ドライブエレクトロニクス660と接続している。このドライブエレクトロニクス660は、SATAインターフェイス、ディスクキャッシュ及びドライブ制御エレクトロニクスを含む。
【００７６】
サーバー全体がメディアデバイス内の共通の回路基板上で使用されれば、図９のストレージサーバー700に示すように、SATAインターフェイスを完全に取り除くことが可能となる。図９では、ディスク制御装置の機能はRSP 720で実施される。ブロック770として図示されている制御装置（例えば、Marvell 88C7500）と、モーターと、サーボ機構は、RSP 720と直接接続する。
【００７７】
図１０は、本質的にはトランスレーションゲートウェイ（“translation” gateway）であるストレージサーバー800を示している。ストレージサーバー800は、ネットワーク802と接続する第一の物理的ネットワークインターフェイスであるPHY1（ブロック810）を有しており、その結果、ストレージサーバークライアントに接続する。また、ストレージサーバーインターフェイス800は、ネットワークまたはポイント・トゥ・ポイント接続を介して1つまたは複数の物理的サーバー（例えば図示されているSANサーバー850）と接続するために、第二の物理的ネットワークインターフェイスであるPHY 2（ブロック840）を有する。RSP 820は、付属メモリ830を備えており、PHY 1及びPHY 2と接続している。PHY 1は、例えばEthernet PHYでよく、PHY 2は、例えばFibre Channel PHYでよい。
【００７８】
動作中、RSP 820は、NAS形式のリクエストまたはアプリケーション形式のリクエストのようなクライエントのリクエストに、遠隔接続されているサーバー850上でリクエストに着手することで、応答する。このようにして、サーバー800は、ネットワーク802上のクライエントからはサーバーに見え、サーバー850からはクライエントに見える。サーバー850はSANサーバーとして図示されているが、サーバー850はNASサーバーであってもよく、さらに言えばアプリケーション形式のサーバーであってもよい。PHY 1とPHY 2が同じサーバープロトコルをサポートするならば、ストレージサーバー800は、拡張可能なサーバー・ファームのための集合点や、暗号化点や、ファイヤーウォールという有用な機能を奏することができる。
【００７９】
PHY 1とPHY 2の両方がRSP 820にデータグラムを供給している場合、RSP 820はそれらの入力ストリーム両方に対し解析を提供することができる。例えば、PHY 1とPHY 2の入力ストリームはともに共通の入力バッファ内へ保存することができ、RSP 820内のDXP（図示せず）は、交互に両方の入力ストリーム内のデータグラムを解析することができ、こうして双方向のトランスレーションタスクを調整して実行する（coordinate）ことができる。また、RSP 820は、二つのDXPを用いて構成されてもよく、うち一つを各物理ポートに当て、これら二つでSEEの共通の保存場所とそれ以外のRSPのリソースを共有してもよい。
【００８０】
前述した実施例は、図１１及び図１２に示すような複数の物理的データ記憶装置に対するアクセスを提供する他のシステムアーキテクチャへ適用することができる。図１１では、ストレージサーバー900は、RSP 100を複数の物理的データ記憶装置（例えば、図示している4つの装置120−1、120−2、120−3、120−4）と接続させるストレージインターフェイスを備えている。これらのデータ記憶装置は、いくつか実施例では、RAID (Redundant Array of Independent Disks)配列としてアクセスされることがある。この場合、RSPがRAID制御装置として動作するか、別のRAID制御装置（図示せず）がストレージインターフェイス110の一部として使用される。他のやり方として、4つのデータ記憶装置は、JBOD(Just a Bunch Of Disks)配列として構成されてもよい。
【００８１】
一般的に、RSP100は、クライアントに対し仮想化されたストレージサーバーの他の形態を実行することができる。他のある形態では、クライエントアプリケーションにより使用されるディスクセクターアドレスは、RSPにより、多くの物理的デバイスの中の特定のデバイスのC-H-S (Cylinder-Head-Sector)アドレスへとマッピングされる。このような形態では、データ記憶装置120−1〜120−4までの記憶装置（場合によってはさらに多くの記憶装置）は空間的に同一の場所にある必要はなく、これによりクライアントに対する物理的リソース及びディスクの割り当てを高精度で制御することを可能にする。また、RSPは、別の中間機器がクライアントに対し仮想的な機能の全体または一部を提供する仮想形態内で機能することができる。
【００８２】
図１２は、ポート拡張器950を内蔵するストレージサーバーシステム1000内でRSPを使用している形態を示している。ポート拡張器９５０は、（外付けまたは内蔵されている）ＲＳＰ１００に接続されている単一のＳＡＴＡ制御装置ポートに接続しているが、その一方で多数の物理的データ記憶装置（図示されている装置120‐1〜120‐4）と通信できるようになっている。このような構成は、データ記憶装置と通信するためにRSPの一つのポートしか使用していないものの、全体としてのシステム処理能力（情報量/bandwidth）を増やすことができる。
【００８３】
図１３は、本発明の実施例と共に利用できるセマンティックプロセッサの他の実施例1100を示している。このセマンティックプロセッサ1100は、Port 0 PHY 93、Port 1 PHY 94、及びPCI-Xインターフェイス95と通信する。そして、これらはすべて、必要に応じて、プロセッサ1100に内蔵させるか、外付けでプロセッサ1100と接続させることができる。図３に示しているバッファ130は、ポート入力バッファ(PIB) 132及びポート出力バッファ (POB)134と置き換えられる。これらのバッファは、必ずしもプロセッサ1100の一部としてプロセッサ1100に内蔵される共通メモリセクションにある必要はないが、このように配置されるのが好ましい。PIB 132は、Port 0、Port 1及びPCI-Xインターフェイスそれぞれに対する少なくとも一つの入力キュー（queue）と関連し、それらを保持し、そして、同様に他のキューも保持することができる。POB 134は、Port 0、Port 1及びPCI-Xインターフェイスそれぞれに対する少なくとも一つの出力キュー（queue）と関連し、それらを保持し、そして、同様に他のキューも保持することができる。Port 0及びPort 1は、通常は、Gigabit Ethernetなどのデータグラムインターフェイスであり、一方で、PCI-Xインターフェイスは通常のPXI-Xバスに接続されている。ストレージサーバーの設計次第では、ストレージリソースはこれらのどのポートとも接続可能であり、クライアントもポート１またはポート2あるいはそれらの両方と接続可能である。
【００８４】
図3と異なり図13では、直接実行パーサ140は、パーサソースセレクタ136を介して、PIB 132内の複数の入力キューのそれぞれから入力を受け取ることができる。例えば、直接実行パーサ140は、それぞれの入力ソースに対し別々のパーサスタックを保持することができる。そして、直接実行パーサ140は、パケットの解析が終了するか、（例えば、SEEがパケットフィールドで何らかの計算を実行している間に）パケットの解析が行き詰った場合、入力ソースを切り替えるようにパーサソースセレクタ136に信号で伝えることができる。
【００８５】
SEEクラスター152は、N個のセマンティックコード実行エンジン150‐1〜150‐Nを備えている。このSEEクラスターは、ディスパッチャ（dispatcher）（図示せず）を備えており、Sx-バスを介してDXP 140と通信し、個々のSEEに対してタスクを配信するのが好ましい。
【００８６】
PIB読み込み制御装置133及びPOB書き込み制御装置135は、SEEクラスター152に、PIB 132及びPOB 134それぞれに対するアクセスを提供する。図のように、パーサソースー136及びPIB読み込み制御装置133により、DXP 140は、一つの入力からのデータに対し動作することができる。一方で、SEEクラスターはその他の入力からのデータにアクセスする。PIB読み込み制御装置133及びPOB書き込み制御装置135は、入力バッファ及び出力バッファに対し、非制限アクセスを提供するのが好ましい。
【００８７】
マシンコンテキストポート制御装置154は、SEEクラスター152に、マシンコンテキスト160に対するアクセスを提供する。ポートバッファ制御装置と同様に、マシンコンテキストポート制御装置154は、SEEクラスター152に、マシンコンテキスト160に対する非制限アクセスを提供する。
【００８８】
マシンコンテキスト160は、SEEクラスター152及びマネージメントマイクロプロセッサ195に対するメモリタスクを優先して、実行する。そして、マシンコンテキスト160は、通常、対象とするデータアクセスの属性に対応してそれぞれが特別化される一つまたは複数の特別なキャッシュを備えている。また、マシンコンテキスト160は、インライン暗号化やインライン認証を実行するのに用いることができる一つまたは複数の暗号化エンジンや認証エンジンを備えている。一つまたは複数の従来のメモリバスインターフェイスは、マシンコンテキスト160を物理メモリ165に接続する。この物理メモリは、例えばDRAM (Dynamic Random Access Memory)、CAM (Content Addressable Memory)や他のタイプの好ましい記憶装置から構成されてよい。物理メモリ165は、プロセッサ1100上に設けるかまたは外付けにするか、あるいはこれらの二つの配置に分けて設けてもよい。
【００８９】
マネージメントプロセッサ195は、セマンティックプロセッサ1100にとって望ましい機能の内従来のソフトウェアで無理なく達成できるものを実行する。例えば、マイクロプロセッサ195は、マシンコンテキスト160を介して、物理メモリ165内にあるマイクロプロセッサ自らが用いる命令スペース及びデータスペースと接続し、従来のソフトウェアを実行することができる。そしてこのプロセッサは、従来のソフトウェアを実行して、プロセッサを起動したり、パーサテーブル、生成規則テーブル及びセマンティックコードテーブルをロードまたは変更したり、統計値を収集したり、ロギングを実行したり、クライアントアクセスを管理したり、エラー回復を行うなどすることができる。また、マイクロプロセッサ制御装置195は、SEEがマイクロプロセッサに代わってタスクを実行するようリクエストするために、SEEクラスター152内のディスパッチャ（dispatcher）と通信可能であるのが好ましい。このマネージメントマイクロプロセッサは、セマンティックプロセッサ1100に組み込まれるのが好ましい。
【００９０】
前述した実施例において、セマンティックユニットは、データのブロックがディスクに書き込まれるときこのデータのブロックを暗号化したり、データのブロックがディスクから読み込まれるときこのデータのブロックを複合化したりできる。これにより一つまたは複数のディスクドライブ上で「休止している」データにセキュリティが提供される。例えば、セマンティックユニットがディスクに書き込むためのデータペイロードを受信するとき、書き込み用データペイロードに対する準備をするオペレーションは、パケットの暗号化を含んでもよい。このプロセスの逆が、暗号化されたデータをディスクから読み出すときに実行されてよい。
【００９１】
ここまで特殊な目的のための実行エンジンを図示し、記述してきたが、他の実施例では、前記パーサを一般的な目的のプロセッサ用のフロントエンドデータグラムプロセッサとして用いてもよい。
【００９２】
前述した実施例に例示されるように、ストレージサーバーをベースにした多くの異なるセマンティックプロセッサが本発明の範囲に含まれる。一番低機能なものでは、例えばFibre Channelにより企業ネットワークと接続されるSAN形式のサーバーに実行可能性がある。NAS形式のサーバーは、上述したCIFSの詳細な実施例に記述されるようなより高度な特徴を持つ。トランスレーションゲートウェイサーバー(translation-gateway server)は、クライアントに対し、潜在的に巨大でかつ変化する基礎をなす物理サーバーのアレイに対するアクセスを提供する。この場合、クライエントに物理サーバーは認知されない。
【００９３】
トランスレーションゲートウェイサーバーと物理サーバーは、両方とも、アプリケーション形式のサーバーとして構築されてよい。アプリケーション形式のサーバーでは、データはアプリケーション形式のフォーマットで保存される。例えば、ビデオオンデマンドサーバーは、複数のクライアントによって使用されるビデオを保存でき、またビデオの異なる部分を異なるクライアントに対し、そのそれぞれに独立したナビゲーションを持たせ、配信することができる。ミュージックオンデマンドサーバーも同様に動作することができる。
【００９４】
また、アプリケーション形式のサーバーは、デジタルカメラが比較的小さい内部バッファやフラッシュカードで動作することを可能にするデジタルカメラからの写真を保存する有線または無線のサーバーと同じように、アプリケーションに対する格納スペース（storage space）を提供することができる。このようなサーバーは、野外使用のために、比較的小型でバッテリー駆動式の携帯用タイプのものであってもよい。
【００９５】
また、セマンティックプロセッサを使用したストレージサーバーの実施例は、例えば家庭用コンピューターのデータネットワークや、オーディオネットワークや、ビデオネットワークで用いる無線用プロトコルを使用して（implement）もよい。前述した詳細な実施例は、従来の「ストレージ」デバイス（記憶装置）に焦点を置いてきたが、プリンタやスキャナや多機能プリンタやその他のデータ変換デバイスもまた、セマンティックプロセッサを使用したストレージサーバーに取り付けることができる。
【００９６】
当業者であれば、ここで教示された概念が他の多くの有効な方法で特定の用途に適用できるということを認めるであろう。セマンティックプロセッサを使用したストレージサーバーは、このサーバーが解析することができるプロトコルを変化させることで、異なる種類のクライアントを扱えるように構成することができるということは、容易に明らかとなる。好ましく構成されれば、ストレージサーバーは、同時に複数のストレージサーバープロトコルを解析し、異なる階層のクライアントによるアクセス（例えば、信頼できるクライエントからのSANアクセスとその他からのNASアクセス）を可能にすることさえできる。
【００９７】
図１４は、本発明の実施例に係るセマンティックプロセッサ2100のブロック図を示している。このセマンティックプロセッサ2100は、入力ポート2110を介して受信するデータストリーム（例えば、入力ストリーム）をバッファするための入力バッファ2300と、入力バッファ2300内のパケット処理を制御する直接実行パーサ（DXP）2400と、パケットのセグメントを処理したり、その他のオペレーションを実行したりするためのセマンティック処理ユニット2140と、パケットのセグメントを保存するか増やしたりするためのメモリシステム2130を備えている。
【００９８】
DXP 2400は、現在の入力フレームまたはパケットに対する現在の入力シンボルに至るまでの解析に基づいた非終端の（及び場合によっては終端の）シンボルからなるパーサスタック2430を保持する。パーサスタック2430の一番上に位置する単一のシンボル（または複数のシンボル）が終端シンボルである場合、DXP 2400は、入力ストリームの先頭の部分にあるデータDIを終端シンボルと比較し、作業を継続するためにそれらが一致することを期待する。パーサスタック2430の一番上に位置するシンボルが非終端（NT）シンボルである場合、DXP 2400は非末端シンボルNT及び現在の入力データDIを用い、スタック2430の文法生成物を拡張する。解析が継続している間、DXP 2400は、SPU 2140に、入力データのセグメントを処理するか、その他のオペレーションを実行するように指示する。
【００９９】
セマンティックプロセッサ2100は少なくとも三つのテーブルを使用する。SPU 2140に対するコードセグメントは、セマンティックコードテーブル2150内に格納される。複雑な文法生成テーブルは、生成規則テーブル（PRT）2250内に格納される。これらの生成規則を検索するための生成規則（PR）コードはパーサテーブル（PT）内に格納される。パーサテーブル2200内のコードはまた、DXP 2400が、所定の生成規則に対してセマンティックコードテーブル2150からのコードセグメントがSPU 2140によってロードされ実行されるべきかを検出することを可能にする。
【０１００】
パーサテーブル2200内の生成規則（PR）コードは、生成規則テーブル2250内の生成規則を示す。PRコードは、例えば行列（row-column）フォーマットまたはコンテント・アドレッサブル（content addressable）フォーマットで格納される。行列（row-column）フォーマットでは、テーブルの行は、内部パーサスタック2430の一番上にある非終端シンボルＮＴによりインデックス付けされ、テーブルの列は、入力の先頭にある入力データ値DIによりインデックス付けされる。コンテント・アドレッサブル（content addressable）フォーマットでは、非終端シンボルNTと単一（または複数）の入力データ値DIを連結したものが、テーブルに対する入力をなす。セマンティックプロセッサ2100は、コンテント・アドレッサブル（content addressable）フォーマットを使用し（implement）、DXP 2400が、非終端シンボルNTを8バイトの現在の入力データDIと連結させ、パーサテーブルに対する入力をなすようにすることが好ましい。他のやり方としては、パーサテーブル2200は、DXP 2400から受け取った非終端シンボルNTと8バイトの現在の入力データDIを連結させてもよい。
【０１０１】
本発明のいくつかの実施例は、図14に示す要素より多くの要素を含むが、本発明のオペレーション（operation）の理解のためにはこれらの要素は重要でないので、本開示ではそれらを省略する。
【０１０２】
以下において、本発明のいくつかの実施例に関する一般的なパーサオペレーションについて、図14、15A、15B、16及び17に基づいて説明する。図15Aは、パーサテーブル2200の一つの実行可能性がある実施例を示している。パーサテーブル2200は、生成規則（PR）コードメモリ2220で構成される。PRコードメモリ2220は、生成規則テーブル（PRT）2250内に保存されている対応する生成規則にアクセスするために用いられる多数のPRコードを保持している。実際には、生成規則コードメモリ2220内に、多くの異なる文法に対するコードが同時に存在することができる。特定の検索実施時（particular lookup implementation）に必要とされなければ、この入力値（例えば、現在の入力値DI[n]と連結された非終端（NT）シンボル）は、PRコードメモリ2220内でなんらかの特定の順序で割り当てられる必要はない。ただし、例の中のnは、選択されたバイトでの一致幅である。
【０１０３】
ある実施例では、パーサテーブル2200は、DXP 2400からNTシンボルとデータ値DI[n]を受け取るアドレッサー2210も備えている。アドレッサー2210は、NTシンボルをデータ値DI[n]と連結し、この連結したデータ値をPRコードメモリ2220へと格納する。他のやり方としては、DXP 2400は、NTシンボルとデータ値を、パーサテーブル2200へ送る前に連結してもよい。
【０１０４】
概念的には、生成規則コードメモリ2220の構造を、NTコードとデータ値の特有な組み合わせのそれぞれに対して一つのPRコードを持つマトリックスとして見ることが有用であることが多いが、本発明はそのようには限定されない。異なるアプリケーションに対し異なるメモリのタイプ及びメモリ構成が適当である場合もある。
【０１０５】
例えば、ある実施例では、パーサテーブル2200はコンテント・アドレッサブル・メモリ（CAM）として実施され、アドレッサー2210は、CAMがPRT2250内の生成規則に対応するPRコードを検索するための鍵としてNTコード及び入力データ値DI[n]を使用する。CAMはTCAMエントリー（entry）に属する三重（ternary）CAM（TCAM）であるのが好ましい。各TCAMエントリー（entry）は、NTコードとDI[n]一致値（DI[n] match value）から構成される。各NTコードは、複数のTCAMエントリーを保持することができる。DI[n] 一致値（DI[n] match value）の各ビットは、「0」、「1」または「X」に設定される。この「X」は「無視（Don't Care）」を表す。この機能により、PRコードは、パーサテーブル2200が一致を見つけるために、数（certain）ビットまたは数（certain）バイトのDI[n]とコード化されたパターンとが一致することだけを必要とする。例えば、TCAMの一行は、宛先IPアドレスフィールドに対するNTコードNT_IPを有しており、その後にセマンティックプロセッサに組み込まれるデバイスに対応する宛先IPアドレスを表す4バイトが続く。このTCAM行の残りの４バイトは「無視（Don't Care）」に設定される。こうして、NT_IP及び8バイトのDI[8]がパーサテーブル2200に提示された場合に、DI[8]の内の最初の4バイトが正しいIPアドレスを含んでいれば、DI[8]の残りの4バイトが何を含んでいても一致が生じることとなる。
【０１０６】
TCAMは、「無視（Don't Care）」機能を採用し、一つのNTに対し複数のTCAMエントリーがあってよいので、TCAMは所定のNTコード及びDI[n]一致値（DI[n] match value）に対して、複数の適合する（matching）TCAMエントリーを見つけることができる。TCAMは、そのハードウェアを通してこれらの一致（match）を優先し、最優先された一致（match）のみ出力する。さらに、NTコード及びDI[n] 一致値（DI[n] match value）がTCAMに提示された場合、TCAMは、並列処理的にTCAMエントリー（entry）毎に受け取ったNTコード及びDI[n]一致値（DI[n] match value）と一致させることを試みる。それゆえに、TCAMは、セマンティックプロセッサ2100の一回のクロックサイクルにおいて、パーサテーブル内に一致が見つかったかどうかを判定する機能を持つ。
【０１０７】
このアーキテクチャ（構造）の他の見方には、「可変予見（variable look-ahead）」パーサとして見る見方がある。TCAMには固定データ入力セグメント（例えば8ビット）が入力されるが、TCAMのコード化により、続く生成規則が現在の8バイトの入力のいずれかの部分に基づいて生成されることを可能にする。入力ストリームの先頭の部分の現在の8バイト内にある１ビットまたは１バイトが現在の規則に対して関係を持つ場合、TCAMエントリー（entry）は、照合作業の間、残りを無視するようにコード化してもよい。本質的に、現在の「シンボル」は、所定の生成規則に対して入力ストリームの先頭の部分の64ビットの何らかの組み合わせで定義することができる。一般的に、知的にコード化することにより、解析サイクルの回数と、NTコード数と、テーブルエントリーの数は、所定の解析タスクに関して一般的に減らすことができる。
【０１０８】
パーサテーブル2200内のTCAMは、上述したように、NT及びDI[n]と一致するTCAMエントリー2230に対応するPRコードを生成する。PRコードはDXP 2400に送り返されるか、直接PRテーブル2250に送り返されるか、またはその両方に送り返されてもよい。ある実施例では、PRコードは、一致状態を作り出すTCAMエントリーの行インデックスである。
【０１０９】
NT及びDI[n]と一致するTCAMエントリーが存在しない場合、いくつかの他のオプションが存在する。ある実施例では、PRコードは、「有効（valid）」ビットを伴う。このビットは、現在の入力の中に一致するTCAMエントリーが存在しない場合は設定されないままとなる。別の実施例では、パーサテーブル2200は、パーサテーブルにより供給されるNTに対応するデフォルトPRコードを構成する。正当なビット及びデフォルトのPRコードの用途は、以下において図15Bと関連して説明する。
【０１１０】
パーサテーブル2200は、DXP 2400及びSPU 2140が一つの回路に一体に組み込まれる場合、内蔵して配置されるか、外部に配置されるか、またはその両方で配置される。例えば、内蔵されたスタティックRAM（SRAM）またはTCAMは、パーサテーブル2200として動作可能である。他のやり方として、外部DRAMストレージまたはTCAMストレージがパーサテーブル2200を格納することもできる。このパーサテーブル2200は、外部メモリに対するメモリ制御装置として動作するかまたは外部メモリに対するメモリ制御装置と通信するアドレッサー2210を備えている。ある実施例では、パーサテーブル2200は、パーサテーブル2200の一部を保持することができる内蔵キャッシュを備えている外部メモリ内に配置することができる。
【０１１１】
図15Bは、生成規則テーブル2250の実行可能性のある実施例を示している。PRテーブル2250は、生成規則メモリ2270と、一致全パーサエントリーテーブル（Match All Parser entries Table）メモリ2280と、アドレッサー2260と、を備えている。
【０１１２】
ある実施例では、アドレッサー2260は、DXP 2400かパーサテーブル2200のいずれか一方からPRコードを受け取り、DXP 2400からNTシンボルを受け取る。好ましくは、受け取ったNTシンボルは、パーサテーブル2200へ送られるNTシンボルと同一のものであり、受け取ったPRコードを配置するのに用いられる。アドレッサー2260は、受け取ったPRコード及びNTシンボルを使用して対応する生成規則及びデフォルトの生成規則にそれぞれアクセスする。本発明の好ましい実施例では、受け取ったPRコードは生成規則を生成規則メモリ2270内にアドレスする。そして、受け取ったNTコードはデフォルトの生成規則をMAPT 2280内にアドレスする。アドレッサー2260はいくつかの実施例においては必ずしも必要ではないが、使用される場合は、DXP 2400の一部やPRT 2250の一部から構成したり、中間の（intermediate）機能ブロックとして構成することもできる。例えば、パーサテーブル2200またはDXP 2400がアドレスを直接構成する場合、アドレッサーは必要とされないかもしれない。
【０１１３】
生成規則メモリ2270は、三つのデータセグメントを含む生成規則2262を格納する。これらのデータセグメントは、シンボルセグメントと、SPUエントリーポイント（SEP）セグメントと、スキップバイトセグメントと、を含む。これらのセグメントは、長さ固定セグメントでも長さ可変のセグメントであってもよく、ヌル終端化されている（null-terminal）のが好ましい。シンボルセグメントは、DXPのパーサスタック2430（図17）上へと転送される終端シンボルか非終端シンボルを有している。SEPセグメントは、セグメントデータの処理中にSPU 2140によって使用されるSPUエントリーポイント（SEP）を有している。スキップバイトセグメントは、そのバッファポインターをインクリメントし、入力ストリームの処理を進めるために入力バッファ2300により使用されるスキップバイトデータを有している。また、生成規則の処理において有用なその他の情報を生成規則2262の一部として格納してもよい。
【０１１４】
MAPT 2280はデフォルトの生成規則2264を格納する。この生成規則は、本実施例では、生成規則メモリ2270内のPRと同じ構造を持ち、PRコードがパーサテーブルの検索中に見つからない場合にアクセスされる。
【０１１５】
生成規則メモリ2270とMAPT 2280は2つの別々のメモリブロックとして図示されているが、本発明はそれに限定されるわけではない。本発明の好ましい実施例では、生成規則メモリ2270及びMAPT 2280は、内蔵SRAMとして実施され、各生成規則及び各デフォルトの生成規則は複数のヌル終端化されたセグメントを保持する。
【０１１６】
生成規則及びデフォルトの生成規則は様々な長さを持つことがあるので、それらの個別のメモリ2270及び2280内へと簡単にインデックス付けして入れることを可能にするアプローチを取るのが好ましい。あるアプローチでは、各PRは、固定最大数のシンボルと、SEPと、スキップバイトフィールドのような補助のデータと、を含むことができる固定長さを持つ。所定のPRコードが許容された最大数のシンボルまたはSEPを必要としない場合、シーケンスは、NULLシンボルまたはSEPで終了される。所定のPRが最大数以上の数を必要とする場合、それは分割して二つのPRへと入れることができる。これらは、例えば第一のPRにスキップバイト値ゼロを持たせ、続く解析サイクルにおいて第二のPRがアクセスされるようにするスタックへNTを転送することで、アクセスされる。このアプローチでは、TCAMから得られる行アドレスがPRテーブル2250内の対応する生成規則の行アドレスと一致するように、TCAMエントリーとPRテーブルエントリーとの間で一対一の対応を維持することができる。
【０１１７】
PRT 2250のMAPT 2280セクションは、NTコードの代わりにPRコードを使用することを除いて同様にインデックス化される。例えば、PRコード上の有効なビットが設定されていない場合、アドレッサー2260は、現在のNTに対応する行をPRテーブルのアドレスとして選択することができる。例えば、2256個のNTが許容された場合、MAPT 2280は、各々がNTの一つに対してインデックス化された2256個のエントリーを含むことができる。パーサテーブル2200が現在のNT及びデータ入力DI[n]に対応するエントリーを一つも持たない場合、MAPT 2280からの対応するデフォルト生成規則がアクセスされる。
【０１１８】
例として宛先IPアドレスを考えると、パーサテーブルは、例えば、適切な解析サイクルの間に期待される二つの宛先アドレスの内一つに応答するように構成することができる。その他のすべての宛先アドレスに対しては、パーサテーブルエントリーは見つからないであろ。アドレッサー2260はその後、DXP 2400かSPU 2140もしくはその両方に現在のパケットを関係のないパケットとして消去するように命令する、現在のNTに対するデフォルト規則を検索するであろう。
【０１１９】
上述した生成規則テーブルをインデックス化するアプローチは、比較的簡単でかつすばやいルールアクセスを提供するが、その他のインデックス化スキームも実行可能性がある。可変長さPRテーブルエントリーに関して、PRコードを演算的に制御して、生成規則の物理的メモリの開始アドレスを決定することができる（これは、例えば生成規則が拡張された長さで保存され、次にPRコードが規則の保存された場所に従って割り当てられれば、実行可能である）。その他のアプローチでは、中間ポインターテーブルを使用することで、PRT2250内で生成規則のアドレスをPRコードから決定することや、MAPT 2280内のデフォルト生成規則のアドレスをNTシンボルから決定することができる。
【０１２０】
一つの追加の機能ユニットである入力バッファ2300をさらに詳しく説明した後で、生成規則2262または2264からのシンボルと、SEPと、スキップバイト値の使用法（use）を、以下でさらに説明する。
【０１２１】
図16は、本発明の実施例で利用可能である一つの実行可能性がある入力バッファ2300の具体例を示している。入力バッファ2300は以下の要素から構成される。
入力ポート2110を介してデータを受け取るバッファ2300。
バッファ2310内のデータを制御するための制御ブロック2300。
受け取ったデータに転送エラーがあるかを確認するためのエラー確認（EC）ブロック2320。
DXP 2400が、バッファ2310内のデータに対してFIFOアクセスをすることを可能にするFIFOブロック2340。
SPU 2140が、バッファ2310内のデータに対してランダムアクセスをすることを可能にするランダムアクセス（RA）ブロック2350。
ECブロック2320は、好ましくは、相互パケットギャップ（IGP）の違反及びイーサネットヘッダーのエラーを確認するとともに循環冗長コード（CRC）を算定することにより、受け取ったデータフレームまたはパケットがエラーを含んでいるかどうかを判定する。
【０１２２】
パケットや、フレームや、その他のデータセグメントが入力ポート2110を介してバッファ2310において受信されると、入力バッファ2300はDXP 2400にポートIDを転送し、DXP 2400に新しいデータが着いたことを告知する。ECブロック2320は、新しいデータにエラーがあるかどうかを確認し、ステータス信号としてDXP 2400へと送られるステータスビットを設定する。DXP 2400は、受け取ったデータセグメントのヘッダーを解析することを決定すると、制御_DXP信号を入力バッファ2300へと送る。この制御_DXP信号は、バッファ2310からのある量のデータを要求するか、またはバッファ2310がデータをDXP2400へと送ることなく、そのデータヘッドポインターをインクリメントすることを要求する。制御_DXP信号を受け取るとすぐに、制御ブロック2330は、バッファ2310からのデータを含む（リクエストされれば）データ_ DXP信号を、FIFOブロック2340を介してDXP 2400へと転送する。本発明のある実施例では、制御ブロック2330及びFIFOブロック2340は、制御キャラクターがDXP 2400へとデータ_DXP信号で送信される際に、制御キャラクターをデータセグメントへと追加する。この制御キャラクターは、転送されるデータの各バイトの先頭に付け加えられ、データの次のバイトが終端シンボルであるか非終端シンボルであるかどうかを示す1ビットのステータスフラグを有しているのが好ましい。この制御キャラクターは、パケットの先頭や、パケットの終端や、ポート_IDなどの特殊な非終端シンボルを含んでいてもよい。
【０１２３】
SPU 2140が、DXP 2400から、入力バッファデータ内のデータにアクセスするようSPU 2140に要求するSPUエントリーポイント（SEP）を受け取ると、SPU 2140は入力バッファ2300に、バッファ2310内の所定の場所にあるデータを要求する制御_SPU信号を送る。制御_SPU信号を受け取るとすぐに、制御ブロック2330はSPU 2140に側帯波（Sideband）信号を送り、RAブロック2350を介してSPU 2140へとバッファ2310からのデータを含むデータ_SPU信号を送る。この側帯波（Sideband）信号は、好ましくは、何バイトの送られたデータが有効であるかどうかとデータストリーム中にエラーがあるかどうかを示す。本発明のある実施例では、制御ブロック2330及びRAブロック2350は、データストリームがSPU 2140へ送信されるように、制御キャラクターをデータストリームへと追加する。この制御キャラクターは、必要であれば、演算されたCRC値及びエラーフラッグを、データストリーム内のパケットまたはフレームの末端に付け加えているのが好ましい。
【０１２４】
図17は、DXP 2400の一つの実行可能性のある具体例のブロック図を示している。パーサ制御有限状態マシン（FSM）2410は、図17に示すその他の論理ブロックからの入力に基づいて、全体的なDXP 2400のオペレーションを制御し、順序付ける。パーサスタック2430は、DXP 2400により実行されるシンボルを格納する。入力ストリームシーケンス制御部2420は、DXP 2400により処理されることとなる入力データ値を入力バッファ2300から読み出す。SPUインターフェイス2440はDXP 2400に代わって、タスクをSPU 2140へと送る。これらのブロックの特定の機能は、以下でさらに詳細に説明する。
【０１２５】
図14〜17に示すブロック図の基本的なオペレーションは、以下において、図18に示すデータストリーム解析に関するフローチャートに基づいて説明する。このフローチャート2500は、本発明の実施方式を示すために用いられる。
【０１２６】
ブロック2510では、セマンティックプロセッサ2100は、パケットが入力ポート2110を介して入力バッファ2300内で受信されるのを待つ。
【０１２７】
次の判定ブロック2512は、ブロック2510でパケットが受信されたかどうか判定する。パケットがまだ受信されてない場合、プロセスは、ブロック2510へと戻り、セマンティックプロセッサ2100がパケットが受信されるのを待つ。パケットが入力バッファにおいて受信されている場合、次のブロック2520では、入力バッファ2300は、ポートID信号をDXP 2400へと送る。この信号は、NTシンボルとしてパーサスタック2430上へと転送される。このポートID信号は、DXP 2400に、パケットが入力バッファ2300に到着したことを告知する。本発明の好ましい実施例では、ポートID信号は、入力ストリームシーケンス制御部2420で受信され、FSM 2410へと転送される。この信号は、パーサスタック2430上へ転送される。好ましくは、1ビットのステータスフラグは、ポートIDに先行して、あるいはポートIDと並列な関係で送られ、ポートIDをNTシンボルで表す。
【０１２８】
次のブロック2530では、DXP 2400は、パーサスタック2430の一番上にあるシンボルがスタックの一番下のシンボルでなく、このDXPがさらなる入力を待っていないと判定した後、入力バッファ2300からnバイトの入力ストリームデータをリクエストし、それを受信する。DXP 2400は、入力ストリームシーケンス制御部2420と入力バッファ2300の間のデータ／制御信号を介してデータをリクエストし、それを受信する。
【０１２９】
次の判定ブロック2532は、パーサスタック2430上のシンボルが終端（T）シンボルとNTシンボルのどちらであるかを判定する。この判定は、好ましくは、FSM 2410がパーサスタック2430上のシンボルのステータスフラグを読み込むことにより実行される。
【０１３０】
このシンボルが終端シンボルであると判定されると、次のブロック2540では、DXP 2400は、受信したNバイトのデータの次のバイトとTシンボルの間に一致があるかどうか確認する。FSM 2410は、入力ストリームシーケンス制御部2420により受信されたデータの次のバイトをパーサスタック2430上のTシンボルと比較することで、一致があるかどうか確認する。確認が完了した後、FSM 2410は、好ましくは、スタックポインターをデクリメントすることにより、Tシンボルをパーサスタックから取り除く（pop）。
【０１３１】
この次の判定ブロック2542は、データの次のバイトとTシンボルの間に一致があるかどうか判定する。一致がある場合、実行プログラムはブロック2530へと戻り、DXP 2400が、パーサスタック2430の一番上にあるシンボルがスタックの一番下のシンボルでなく、このDXPがさらなる入力を待っていないと判定した後、入力バッファ2300から追加の入力ストリームデータをリクエストし、それを受信する。本発明の好ましい実施例では、DXP 2400は、Tシンボルの一致があった場合、１バイトの入力ストリームデータだけリクエストし、それを受信し、入力シンボルが一つ消費される分DIバッファを補充する。
【０１３２】
一致がなかった場合、現在のデータセグメントの残りセグメントが周辺機器のどこかにあり解析不能であると推測される。次のブロック2550では、DXP 2400は、パーサスタック2430をリセットし、SEPを起動して、入力バッファ2300からの現在のパケットの残りを取り除く。本発明のある実施例では、FSM 2410は、残りのシンボルを取り除く（pop off）か、一番上のスタックポインターがスタックの一番下のシンボルを指し示すように設定することにより（こちらの方が好ましい）、パーサスタック2430をリセットする。DXP 2400は、SPUインターフェイス2440を介してSPU 2140にコマンドを送ることにより、SEP起動する。このコマンドは、SPU 2140がSCT 2150からマイクロ命令をロードすることを要求する。そしてこのマイクロ命令は実行されると、SPU 2140が、解析できないデータセグメントの残りを入力バッファ2300から取り除くことを可能にする。実行プログラムは、その後、ブロック2510へと戻る。
【０１３３】
なお、データストリーム内の解析できない入力のすべての例が、現在のデータセグメントの解析の中止をもたらす可能性がある訳ではない。例えば、パーサは、直接文法を用いることで、通常のヘッダーオプションを制御するように構成されてもよい。他のやり方としては、解析のためにヘッダーオプションをSPUへと送るデフォルト文法規則を使用することで、あまり一般的ではないかあるいは扱いにくいヘッダーオプションに対処することができる。
【０１３４】
判定ブロック2532におけるシンボルがNTシンボルであると判定されると、次のブロック2560では、DXP 2400は、パーサスタック2430から受け取ったNTシンボルと入力ストリームシーケンス制御部2420内の受信したNバイトDI[N]とをパーサテーブル2200へ送る。そこで、パーサテーブル2200は、例えば前述したように、一致があるかどうか確認する。図示した実施例では、パーサテーブル2200は、受信したNバイトとNTシンボルを連結させる。別のやり方としては、受信したNバイトとNTシンボルを、パーサテーブル2200へ送られる前に連結させてもよい。好ましくは、受信したNバイトは、SPUインターフェイス2440とパーサテーブル2200の両方へと同時に送られ、またNTシンボルは、パーサテーブル2200とPRT 2250の両方へと同時に送られる。一致確認が完了したあと、FSM2 410は、パーサスタック2430からNTシンボルを取り除く（pop）。これは、スタックポインターをデクリメントすることにより実行されるのが好ましい。
【０１３５】
次の判定ブロック2562は、パーサテーブル2200内で、Nバイトのデータと連結されたNTシンボルに対する一致があったかどうか判定する。一致がある場合、次のブロック2570では、パーサテーブル2200は一致に対応するPRコードをPRT 2250へと送り返し、そのPRコードは生成規則をPRT 2250内にアドレス指定する。その他のやり方では、PRコードは、DXP 2400を介してパーサテーブル2200からPRT 2250へと送られる。その後、実行プログラムはブロック2590から続く。
【０１３６】
一致がない場合、次のブロック2580では、DXP 2400は受信したNTシンボルを使用して、PRT 2250内でデフォルト生成規則を検索する。好ましい実施例では、デフォルト生成規則はPRT 2250内に配置されたMAPT 2280メモリ内で検索される。その他のやり方としては、MAPT 2280メモリは、PRT 2250以外のメモリブロック内に配置されてもよい。
【０１３７】
本発明の好ましい実施例では、PRT 2250がPRコードを受信すると、PRT 2250は、見つかった生成規則またはデフォルト生成規則のどちらかに対応するPRのみをDXP 2400へ送り返す。その他のやり方としては、PR及びデフォルトPRの両方をDXP 2400へと送り返し、DXP 2400がどちらを使用するか決定するやり方もある。
【０１３８】
次のブロック2590では、DXP 2400はPRT 2250から受信した規則を処理する。DXP 2400が受信した規則は、生成規則とデフォルト生成規則のどちらであってもよい。本発明の実施例では、FSM 2410は、規則を以下の三つのセグメントに分割する。ここで言う三つのセグメントとは、シンボルセグメントと、SEPセグメントと、スキップバイトセグメントのことである。規則の各セグメントは、簡単で正確な分割ができるように、固定された長さを持つかあるいはヌル終端化されているのが好ましい。
【０１３９】
図示している実施例では、FSM 2410はTシンボルか、NTシンボルか、またはその両方をパーサスタック2430に送る。これらのシンボルは、生成規則のシンボルセグメント内に含まれるものである。FSM 2410は、生成規則のSEPセグメント内に含まれるSEPを、SPUインターフェイス2440に送る。各SEPは、SCT 2150内に配置されたマイクロ命令に対するアドレスを備えている。これらのSEPを受け取るとすぐに、SPUインターフェイス2440は、SEPにより指定されたマイクロ命令を取り込み、それらを実行するように、SPU 2140を割り当てる。多くの場合、SPUにより完了されるタスクはさらなる入力データを必要としないので、SPUインターフェイス2440はまた、現在のDI[N]値をSPU 2140へと送る。他のやり方としては、SPUインターフェイス2440は、SPU 2140により実行されるマイクロ命令を取り込み、SPUを割り当てるのと同時にそれらのマイクロ命令をSPU 2140へ送る。FSM 2410は、入力ストリームシーケンス制御部2420を介して、生成規則のスキップバイトセグメントを入力バッファ2300に送る。入力バッファ2300は、スキップバイトデータを使用して、入力ストリーム内の配置を指し示す自身のバッファポインターをインクリメントする。各解析サイクルは、それ故に、0から8までの範囲のいずれかの個数の入力シンボルを消費することができる。
【０１４０】
DXP 2400がPRTから受信した規則を処理したあと、次の判定ブロック2592は、パーサスタック2430上の次のシンボルがスタックの一番下のシンボルかどうか判定する。次のシンボルがスタックの一番下のシンボルである場合、実行プログラムはブロック2510に戻り、そこで、セマンティックプロセッサ2100が、新しいパケットが入力ポート2110を介して入力バッファ2300において受信されるのを待つ。
【０１４１】
次のシンボルがスタックの一番下のシンボルでない場合、次の判定ブロック2594は、DXP2400が、パーサスタック上2430の次のシンボルの処理を開始する前に、それがさらなる入力を待っているかどうか判定する。図示しているDXP 2400は、SPU 2140が入力ストリームのセグメントの処理を開始するのを待つことや、SPU 2140が処理結果のデータを送り返すのを待つことなどができる。
【０１４２】
DXP 2400がさらなる入力を待っていない場合、実行プログラムはブロック2530へと戻り、そこで、DXP 2400が入力バッファ2300から入力ストリームデータをリクエストし、それを受信する。DXP 2400がさらなる入力を待っている場合、実行プログラムは、その入力が受信されるまで、ブロック2594へのループを続ける。
【０１４３】
図19は、別のセマンティックプロセッサの実施例を示している。セマンティックプロセッサ2600は、多数のセマンティックプロセッシングユニット（SPU）2140−1〜2140−Nを含むセマンティックプロセッシングユニット（SPU）のクラスター2640を備えている。SPU 2140−1〜2140−Nの各SPUは、同一の構成及び機能を持つのが好ましい。SPUクラスター2640は、メモリサブシステム2130と、SPUエントリーポイントSEEエントリーポイントディスパッチャ（dispatcher）2650と、SCT 2150と、ポート入力バッファ（PIB）2700と、ポート出力バッファ（POB） 2620と、マシン中央演算処理装置（MCPU）2660と、接続されている。
【０１４４】
DXP 2800が、解析の特定の時点でSPUタスクが開始されるべきであると判定すると、DXP 2800は、SEPディスパッチャ2650に、セマンティックコードテーブル（SCT）2150からマイクロ命令をロードし、SPUクラスター2640内の複数のSPU2140‐1〜2140‐NからSPUを割り当てて、タスクを実行するように信号で伝える。ロードされたマイクロ命令は、タスクが実行されるべきであることを示し、割り当てられたSPUへと送られる。割り当てられたSPUは、その後、マイクロ命令を実行し、入力ストリーム内のデータはそれに沿って処理される。その他のやり方としては、SPUは、SEPディスパッチャ2650により指示される場合、マイクロ命令をSCT2150から直接ロードしてもよい。
【０１４５】
より詳しく理解するために図20を参照すると、PIB 2700は少なくとも一つのネットワークインターフェイス入力バッファ2300（この図では、2300_0及び2300_1が図示されている）と、再循環バッファ2710と、相互周辺機器（PCI-X）入力バッファ2300_2と、を備えている。POB 2620（図示せず）は、少なくとも一つのネットワークインターフェイス出力バッファと、PCI-X出力バッファと、を備えている。ポートブロック2610は、各々が物理的インターフェイスを有している一つまたは複数のポートを備えている。この物理的インターフェイスの例としては、Fibre Channelや、802.11xや、ユニバーサル・シリアル・バス（USB）や、ファイヤーワイヤーや、SONETや、その他の物理レイヤーインターフェイスに対する光学的または電気的あるいは無線によるドライバーとレシーバーのペアなどが挙げられる。ポートブロック2610内のポートの数は、PIB 2700内のネットワークインターフェイス入力バッファの数及びPOB 2620内の出力バッファの数と対応するのが好ましい。
【０１４６】
少し戻って図19では、PCI-Xインターフェイス2630は、PIB 2700内のPCI-X入力バッファと、POB 2620内のPCI-X出力バッファと、外部PCIバス2670と、接続されている。PCIバス2670は、ディスクドライブや追加のネットワークポート用のインターフェイスなどのようなその他のPCI可能な周辺機器と接続することができる。
【０１４７】
MCPU 2660は、SPUクラスター2640及びメモリサブシステム2130と接続されている。MCPU 2660は、セマンティックプロセッサ2600にとって望ましい機能の中で、従来のソフトウェアで無理なく遂行できるものを実行する。これらの機能は、通常、あまり使われずかつ時間的に重要でない機能であり、そのコードの複雑性から、SCT2150内に含まれることを保障しない。MCPU 2660はまた、SPUがMCPUの代わりにタスクを実行することをリクエストするために、SEPディスパッチャ2650と通信できるのが好ましい。
【０１４８】
図20は、本発明の実施例に利用することができるポート入力バッファ（PIB）2700の一つの実行可能性がある具体例を示している。PIB 2700は、二つのネットワークインターフェイス入力バッファ2300_0及び2300_1と、再循環バッファ2710と、PCI-X入力バッファ2300_2と、を備えている。入力バッファ2300_0及び2300_1と、PCI-X入力バッファ2300_2は、機能的に入力バッファ2300と同等である。しかしこれらは、入力データを、ポートブロック2610と PCI-Xインターフェイス2630に対してそれぞれ異なっている入力から受け取る。
【０１４９】
再循環バッファ2710は、SPUクラスター2640から再循環データを受け取るバッファ2712と、バッファ2712内の再循環データを制御するための制御ブロック2714と、DXP 2800が（図21に示している）バッファ2712内の再循環データに対してFIFOアクセスすることを可能にするFIFOブロック2716と、SPUクラスター2640内のSPUがバッファ2712内の再循環データに対してランダムアクセス（RA）することを可能にするランダムアクセスブロック2718と、を備えている。SPUクラスターからの再循環データがバッファ2712において受信されると、再循環バッファ2710はポートIDをDXP 2800へと送り、新しいデータが到着したことをDXP 2800に告知する。送られるポートIDは、バッファ2712内の最初のシンボルであることが好ましい。
【０１５０】
DXP 2800が再循環データを解析すると決定すると、このDXPは再循環バッファ2710に制御_DXP信号を送信する。この制御_ DXP信号は、バッファ2712からの一定量のデータを要求するか、バッファ2712のデータポインターをインクリメントするように要求するものである。制御_ DXP信号を受信するとすぐに、制御ブロック2714は、FIFOブロック2716を介して、バッファ2712からのデータを含むデータ_DXP信号をDXP 2800に送信する。本発明のある実施例においては、この制御ブロック2714とFIFOブロック2716は、データ_DXP信号を使用しDXP 2800へと送信される再循環データに制御キャラクターを加える。この制御キャラクターは、転送されるデータの各バイトの最初の部分に付け加えられ、データのそのバイトが終端シンボルか非終端シンボルなのかどうかを示す１ビットのステータスフラグであることが好ましい。
【０１５１】
SPUクラスター2640内のSPU 2140が、SPUに再循環ストリーム内のデータにアクセスすることを要求するSPUエントリーポイント（SEP）をDXP 2800から受信すると、SPU 2140は、ある記憶場所に位置するデータをバッファ2712からリクエストする制御_DXP信号を再循環バッファ2710へと送る。制御_DXP信号を受信するとすぐに、制御ブロック2714は、バッファ2712からのデータを含むデータ_DXP信号を、RAブロック2718を介してSPU 2140へと送る。
【０１５２】
図21は、DXP 2800の一つの実行可能性のある具体例のブロック図を示している。パーサ制御有限状態マシン（FSM）2410は、図17に示されているDXP 2400に関して記述したのと同様のやり方で、図21に示しているその他の論理ブロックからの入力に基づいて、全体的なDXP 2800のオペレーションを制御し、それを順序付ける。しかし、入力バッファ2700内の複数の解析中の入力の存在により違いが生じる。これらの違いは、主に、パーサ制御FSM 2410と、スタックハンドラー2830と、入力ストリームシーケンス制御部2420とにある。加えて、図17に示すパーサスタック2430は、複数のパーサスタック2430_1〜2430_Mを保持することができるパーサスタックブロック2860と交換されている。最後に、パーサデータレジスタバンク2810が追加される。
【０１５３】
スタックハンドラー2830は、DXP 2800により実行されるシンボルを保存するとともにそれらを順序付けることで、複数のパーサスタック2430_1〜2430_ Mを制御する。本発明のある実施例では、パーサスタック2430_1〜2430_Mは一つのメモリ内に配置され、各パーサスタックはそのメモリの決まった場所に配置される。その他のやり方として、パーサスタックブロック2860内のパーサスタック2430_1〜2430_Mの数と大きさは、動作中の入力データポートの数及び文法の数を読み取って、スタックハンドラー2830により、動的に決定され、変化させられてもよい。
【０１５４】
DXP 2800は、複数のインターフェイスブロックを介して入力を受け取る。この複数のインターフェイスブロックは、パーサテーブル2840と、生成規則テーブル（PRT）インターフェイス2850と、入力ストリームシーケンス制御部2420と、SPUインターフェイス2440と、を含む。一般的に、これらのインターフェイスは、入力ストリームシーケンス制御部2420を除いて、前述したように機能する。
【０１５５】
入力ストリームシーケンス制御部2420及びデータレジスタバンク2810は、PIB 2700から入力ストリームデータを検索し、それを保持する。データレジスタバンク2810は、受信した入力ストリームデータを保存することができる複数のレジスタから構成される。レジスタの数は、パーサスタックテーブル2860内に存在できるパーサスタック2430_1〜2430_ Mの最大数に等しく、各レジスタはN個の入力シンボルを保持することができるのが好ましい。
【０１５６】
パーサ制御FSM 2410は、入力ストリームシーケンス制御部2420と、データレジスタバンク2810と、スタックハンドラー2830と、を制御し、異なる入力バッファ間で解析用コンテキストを切り替える。例えば、パーサ制御FSM 2410は、現在それが、入力バッファ2300_0と、入力バッファ2300_1と、PCI−X入力バッファ2300_2と、再循環バッファ2710と、のうちのどこから来たデータとともに動作しているのかを示すコンテキスト状態を保持する。このコンテキスト状態は入力ストリームシーケンス制御部2420に送信される。そして、入力ストリームシーケンス制御部にデータ入力に応答させるか、適切な入力バッファまたは再循環バッファに対するコマンドを伴った文法内のコマンドをスキップさせる。また、コンテキスト状態は、データレジスタバンク2810に送信される。そして、レジスタのロードや読み込み、現在のコンテキスト状態に対応するレジスタにアクセスする。最後に、このコンテキスト状態は、スタックハンドラー2830に送信され、スタックハンドラー2830に対するプッシュ(pushes)及びポップコマンドが、パーサスタック2430_1〜2430_ Mのうちの正しいパーサスタックへとアクセスするようにする。
【０１５７】
パーサ制御FSMは解析用コンテキストを変えるタイミングを決定する。例えば、スタックの一番下のシンボルが特定のパーサスタック上に到達するか、特定の解析用コンテキストがSPUオペレーションの結果解析に行き詰まると、パーサ制御FSMは次の解析用コンテキストの状態（state of the next parsing context）を調べ（examine）、解析を行う準備のできた解析用コンテキストが到着するまで、総当り方式を継続する。
【０１５８】
ブロック図15Aと、15Bと、19−21とにおける基礎的なオペレーションを図22に示すデータ解析のフローチャートに基づいて以下において説明する。フローチャート2900は、本発明の実施例にかかる実施方法を説明するために使用される。
【０１５９】
判定ブロック2905では、DXP 2800は、解析の行き詰ったパーサスタックに対応するデータ以外の新しいデータがPIB 2700において受信されたかどうか判定する。本発明の実施例では、PIB 2700内の4つのバッファは固有のポートIDを持つ。これらのポートIDは、新しいデータが受信されると、それぞれDXP 2800に送信される。好ましくは、再循環バッファ2710は、自身の固有のポートIDを各再循環データセグメント内の最初の一バイトとして有している。PIB 2700内の4つのバッファは、それぞれ固有の入力を持つので、DXP 2800は複数のポートIDを同時に受信することができる。DXP 2800が複数のポートIDを受信すると、総当り方式の調停（arbitration）を用いて、ポートに存在する新たなデータを解析するシーケンスを決定するようにするのが好ましい。
【０１６０】
本発明のある実施例では、特定のストリームで解析を中止しなければならなくなったとき、パーサスタックはDXP 2800により保存される。FSM 2410が、パーサスタックの選択を切り替えるようにスタックハンドラーに命令する制御信号をスタックハンドラー2830に送ると、パーサスタックは保存される。
【０１６１】
新しいデータがまだ受信されていないと、プロセスはブロック2905へ戻り、そこで、DXP 2800は、新しいデータがPIB 2700で受信されるのを待つ。
【０１６２】
新しいデータが受信されていると、次のブロック2910では、DXP 2800は、選択されたバッファのポートIDをNTシンボルとして選択されたパーサスタック上へ転送する。この選択されたバッファは、PIB内のバッファでDXPが解析することを決めたバッファである。そして、DXP 2800内の選択されたパーサスタックは、DXP 2800が実行されるシンボルをそこに格納することを選択したパーサスタックである。各ポートに対してロードされた文法またはその一部は、そのポートに対してロードされた最初の（initial）非終端シンボルに応じて、異なってよい。例えば、ある入力ポートがSONETフレームを受信し、他の入力ポートがイーサーネットフレームを受信した場合、各ポートに対するポートIDNTシンボルは、各ポートに対する適切な文法を機械的に選択するのに使用することができる。
【０１６３】
本発明のある実施例では、入力ストリームシーケンス制御部2420は、総当り方式の調停（arbitration）を介してPIB 2700内でバッファを選択し、スタックハンドラー2830はパーサスタックブロック2860内でパーサスタックを選択する。本発明の好ましい実施例では、FSM 2410は入力ストリームシーケンス制御部に、PIB 2700内でのバッファの選択を可能にするように指示する信号を送り、データレジスタバンク2810にレジスタを選択するように指示する制御レジスタ信号（Control Reg signal）を送る。同様にFSM 2410は、スタックハンドラー2830に、バッファの選択を可能にするように指示する制御信号か、パーサスタックをパーサスタックブロック2860内で動的に割り当てるように指示する制御信号を送る。
【０１６４】
説明のため、入力バッファ2300_0は、DXP 2800により選定された自身のポートIDを持ち、このパーサスタック2430_1は、入力バッファ2300_0からのデータの解析において使用される文法シンボルを格納するために、DXP 2800により選定されると仮定する。本発明の図示されている実施例では、スタックハンドラー2830が、FSM 2410からポートIDをSYMコードで受信し、転送コマンドを制御信号で受信した後、ポートIDはスタックハンドラー2830により、パーサスタック2430_1上へと送られる。ポートIDに先行する１ビットのステータスフラグは、ポートIDをNTシンボルとして表示する。
【０１６５】
次のブロック2920では、DXP 2800は、選択されたバッファ内のストリームからのNバイトのデータ（またはその一部）をリクエストし、それを受信する。図示されている実施例では、DXP 2800は、PIB 2700内の入力バッファ2300_0と入力ストリームシーケンス制御部2420の間のデータ／制御信号を介してデータをリクエストし、それを受信する。データが入力ストリーム制御部2420により受信されると、そのデータはデータレジスタ制御部2810内の選択されたレジスタへと格納される。データレジスタ制御部2810内の選択されたレジスタは、現在の解析用コンテキストにより制御される。
【０１６６】
次のブロック2930では、DXP 2800は、自身がさらなる入力を待っておらず、選択されたパーサスタック上のシンボルがスタックの一番下のシンボルでないと判定した後、選択されたパーサスタックの一番上にあるシンボル及び受信したNバイトのデータ（またはその一部）を処理する。ブロック2930は、一番上のシンボルが終端シンボルであるか非終端シンボルであるかの判定を含む。この判定は、スタックハンドラー2830により実行されてもよい。なお、この判定は、パーサスタック2430_1の一番上のシンボルのステータスフラグを読み込むとともに、そのステータスをFSM 2410へ接頭（P）コード信号として送信することにより実行されるのが好ましい。
【０１６７】
判定ブロック2935において、シンボルが終端（T）シンボルであると判定されると、DXP 2800は、受信したNバイトからのデータの次のバイトとTシンボルの間で一致があるかどうか調べる。
【０１６８】
本発明の好ましい実施例では、Tシンボルの一致があったかどうかを調べるためにDXP 2400により使用される一致信号Mは、比較器2820が、スタックハンドラー2830からのTシンボルを入力されるとともに、データレジスタ制御装置2810内の選択されたレジスタからのデータの次のバイトを入力されている場合に、比較器2820によりFSM 2410へと送られる。スタックハンドラー2830は、シンボルをパーサスタック2430_ 1から取り出す（pop off of）ことで、パーサスタック2430_1上のTシンボルを比較器2820の入力へと送る。
【０１６９】
ブロック2945において、現在のパーサスタックの一番上にあるシンボルが非終端（NT）シンボルであると判定されると、DXP 2800は、パーサスタック2430_ 1からのNTシンボルと、バンク2810から選択されたレジスタ内の受信されたNバイトと、をパーサテーブル2200へと送る。図示されている実施例では、NTシンボル及び受信されたNバイトはパーサテーブルインターフェイス2840へと送られる。これらは、パーサテーブル2200へと送られる前に連結される。他のやり方としては、NTシンボル及び受信したNバイトをパーサテーブル2200へと直接送ることができる。いくつかの実施例では、選択されたレジスタ内の受信したNバイトは、SPU 2140とパーサテーブル2200に同時に送られる。
【０１７０】
パーサスタック2430_ 1上のシンボルは、比較器2820と、パーサテーブルインターフェイス2450と、PRTインターフェイス2460とに同時に送られるのが好ましい。
【０１７１】
有効なブロック2935のTシンボルの一致が試みられたと仮定すると、その一致が成功した場合、実行プログラムはブロック2920へと戻り、そこで、DXP 2800は、PIB 2700からのNバイト以下の追加のデータをリクエストし、それを受信する。本発明のある実施例では、DXP 2800は、Tシンボルの一致があった場合、１バイトのストリームデータをリクエストし、それを受信するだけとなる。
【０１７２】
ブロック2935での一致が試みられ成功すると、次のブロック2940では、DXP 2800は、文法が指示すれば、選択されたパーサスタックを消去してもよく、その後、SEPを起動して現在のデータセグメントの残りを現在の入力バッファから削除する。
【０１７３】
DXP 2800は、残りのシンボルを取り出すとともにスタックポインターをスタックの一番下のシンボルへと設定するように指示する制御信号をスタックハンドラー2830へと送ることで、パーサスタック2430_1をリセットする。DXP 2800は、SPUインターフェイスを介してSPUディスパッチャ2650にコマンドを送ることでSEPを起動する。この命令に従って、SPUディスパッチャ2650は、SCT 2150からマイクロ命令を取り込むSPU 2140を割り当てる。このマイクロ命令は、実行されると、入力バッファ2300_ 0からの現在のデータセグメントの残りを削除する。その後、実行プログラムはブロック2905へと戻り、そこで、DXP 2800は、解析の行き詰ったパーサコンテキストを有するデータ入力を除いたデータ入力に関する新しいデータがPIB 2700において受信されたかどうか判定する。
【０１７４】
スタックの一番上のシンボルが非終端シンボルであると仮定すると、ブロック2935の代わりにブロック2945での一致が試みられる。パーサスタックテーブル2200内で、Nバイトのデータと連結されたNTシンボルに対する一致があった場合、実行プログラムはブロック2905へと進む。パーサテーブル2200は、一致に対応するPRコードをDXP 2800に送り返す。そしてDXP 2800は、PRコードを使用し、PRT 2250内で生成規則を検索する。ある実施例では、生成規則は、PRT 2250内に配置されたPRTメモリ2270内で検索される。
【０１７５】
図示されている実施例では、PRコードは、中間パーサテーブルインターフェイス2450及び中間PRTインターフェイス2460を介して、パーサテーブル2200からPRT 2250に送られる。その他のやり方としては、PRコードをパーサテーブル2200からPRT 2250に直接送ることができる。
【０１７６】
判定ブロック2945において一致が失敗すると、次のブロック2960では、DXP 2800は選択されたパーサスタックからのNTシンボルを使用して、PRT 2250内でデフォルト生成規則を検索する。ある実施例では、デフォルト生成規則は、PRT 2250内に配置されたMAPT 2280メモリ内で検索される。その他のやり方としては、MAPT 2280メモリをPRT 2250以外のメモリブロック内に配置することができる。
【０１７７】
図示されている実施例では、スタックハンドラー2830は、生成規則インターフェイス2850及びパーサテーブルインターフェイス2840に、NTシンボルを同時に送る。その他のやり方としては、スタックハンドラー2830は、パーサテーブル2200とPRT 2250に直接NTシンボルを送ることができる。PRT 2250がPRコード及びNTシンボルを受信すると、PRT 2250はPRTインターフェイス2850に、生成規則とデフォルト生成規則の両方を同時に送る。生成規則インターフェイス2480は、適切な規則だけをFSM 2410へと送り返す。他の実施例では、生成規則とデフォルト生成規則の両方がFSM 2410へと送られる。また他の実施例では、PRコードがPRT 2250へと送られたかどうかに応じて、PRT 2250はPRTインターフェイス2850に、PRとデフォルトPRのどちらか一方だけを送り返す。
【０１７８】
ブロック2950とブロック2960のどちらが実行された場合も、次のブロック2970へと進む。ブロック2970では、DXP 2800はPRT 2250から受信した生成規則を処理する。本発明のある実施例では、FSM 2410は生成規則を三つのセグメントへと分割する。この三つのセグメントは、シンボルセグメントと、SEPセグメントと、スキップバイトセグメントと、である。生成規則の各セグメントは、前述したように簡単で正確な分割を可能にするために、長さが固定されかつヌル終端化されているのが好ましい。
【０１７９】
図22に示しているブロック2970は、図18に示しているブロック2950と似た様なやり方で動作するが、以下のような違いがある。第一に、生成規則のシンボルセグメントは現在のコンテキストに対する適切なパーサスタック上へと転送される。第二に、生成規則のスキップバイトセクションは、データレジスタバンク内で現在のコンテキストに対して適切なレジスタを制御するとともに、現在のコンテキストに対して適切な入力バッファを制御するために使用される。第三に、SEPがSEPディスパッチャ（dispatcher）へと送られると、命令は、SPUによるセマンティックコードの実行に対して適切な入力バッファを指し示す。
【０１８０】
次の判定ブロック2975では、DXP 2800は、選択されたバッファ内の入力データがさらなる解析を必要としているかどうか判定する。本発明のある実施例では、スタック2430_1の（for）パーサスタックポインターが、スタックの一番下のシンボル以外のシンボルを指し示している場合、入力バッファ2300_0内の入力データはさらなる解析を必要とする。スタック2430_1の（for）パーサスタックポインターが、スタックの一番下のシンボルを指し示している場合、FSM 2410が、スタックハンドラー2830から空スタック信号(stack empty sugnal: SE)を受信するのが好ましい。
【０１８１】
選択されたバッファ内の入力データがさらに解析されることを必要としない場合、実行プログラムはブロック2905へと戻り、そこで、DXP 2800は、行き詰ったパーサスタックのバッファ以外のもう一つの入力バッファが、PIB 2700で来るのを待っている新しいデータを持っているかどうか判定する。
【０１８２】
選択されたバッファ内の入力データがさらに解析されることを必要とする場合、次の判定ブロック2985では、DXP 2800は、それが選択されたバッファ内の入力データの解析を継続することができるかどうか判定する。本発明のある実施例では、まだ解析が必要であっても、いくつかの理由により所定のバッファからの入力データで解析を中止することがある。この理由としては、未解決または実行中のSPUオペレーションによるものや、入力データの不足や、その他の入力バッファがDXP 2800内での解析において優先権を持っていること、などがある。ある実施例では、入力バッファ2300_0内の入力データについて優先権を持っている別の入力バッファは、以前格納されたパーサスタックを有していた入力バッファや、文法命令としてより高度な優先権を持つ入力バッファであってもよい。DXP 2800は、SEPディスパッチャ2650により、ステータス信号を介してSPU処理の遅れについて告知される。また、DXP 2800は、FSM 2410内に格納されているステータス値により、優先して解析するタスクについて告知される。
【０１８３】
DXPが現在の解析用コンテキストで解析を継続することができる場合、実行プログラムはブロック2920へと戻り、そこで、DXP 2800は、選択されたバッファ内の入力データからNバイト以下のデータをリクエストし、それを受信する。
【０１８４】
DXP2800が解析を継続することができない場合、次のブロック2990では、DXP 2800は選択されたパーサスタックを格納し、続いて、選択されたパーサスタックと、データレジスタバンク2810内で選択されたレジスタと、選択された入力バッファと、を選択解除する。FSM 2410から切り替え制御信号を受信すると、スタックハンドラー2830は、パーサスタック2430_ 1を格納し、その後パーサスタックブロック2860内で他のパーサスタックを選択することで、パーサスタック2430_ 1を選択解除する。
【０１８５】
入力ストリームシーケンス制御部2420は、FSM 2410から切り替え信号を受信すると、入力データをすでに受信しているPIB 2700内の他のバッファを選択することで入力バッファ2300_0を選択解除する。そしてデータレジスタバンク2810は、FSM 2410から切り替え信号を受信すると、他のレジスタを選択することにより、選択されたレジスタを選択解除する。DXP 2800により解析される新しいデータが来るのをPIB 2700で待っている他のバッファがない場合、入力バッファ2300_0と、選択されたレジスタと、パーサスタック2430_ 1は、動作中のままでいることができる。
【０１８６】
実行プログラムは、その後、ブロック2905へと戻り、DXP 2800は、解析が行き詰ったパーサスタックを有する入力ストリーム以外のほかの入力ストリームがPIB2700で受信されたかどうか判定する。
【０１８７】
図23は、本発明の実施例に係るセマンティックプロセッサ3100のブロック図を示している。セマンティックプロセッサ3100は、入力ポート3120を介して受信されるパケットデータストリームをバッファするための入力バッファ3140と、入力バッファ3140及び再循環バッファ3160において受信されるパケットデータの処理を制御する直接実行パーサ（DXP）3180と、パケットを処理するためのパケットプロセッサ3200と、を備えている。この入力バッファ3140及び再循環バッファ3160は、先入れ先出し（first-in-first-out(FIFO)）バッファであるのが好ましい。このパケットプロセッサ3200は、パケットのセグメントの処理またはその他のオペレーションの実行のための実行エンジン3220と、パケットのセグメントを格納したり、増やしたりするためのメモリサブシステム3240と、から構成される。
【０１８８】
DXP 3180は、入力バッファ3140内のパケットまたはフレーム（例えば入力「ストリーム」）の処理と、再循環バッファ3160内のパケットまたはフレーム（例えば再循環「ストリーム」）の処理と、を制御する。DXP 3180は、入力バッファ3140からの入力ストリームと、再循環バッファ3160からの再循環ストリームと、を同様のやり方で解析するので、以下で入力ストリームの解析についてのみ説明する。
【０１８９】
DXP 3180は、現在のシンボルまでの現在のフレームの解析に基づいて、終端シンボル及び非終端シンボルを含む内部パーサスタックを保持する。パーサスタックの一番上にあるシンボルが終端シンボルである場合、DXP 3180は、入力ストリームの先頭にあるデータを終端シンボルと比較し、作業を続けるために一致を期待する。パーサスタックの一番上にあるシンボルが非終端シンボルである場合、DXP 3180は、この非終端シンボル及び現在の入力データを使用しスタック上の文法生成物を拡大する。解析が続くと、DXP 3180は、実行エンジン3220に、入力のセグメントを処理するか、その他のオペレーションを実行するように指示を送る。
【０１９０】
セマンティックプロセッサ3180は、少なくとも2つのテーブルを使用する。複雑な文法生成規則は、生成規則テーブル（PRT）3190内に格納される。これらの生成規則を検索する(読み出す)ためのコードは、パーサテーブル（PT）3170内に格納される。パーサテーブル3170内のコードは、DXP 3180が、所定の生成規則に関して、パケットプロセッサ3200がパケットのセグメントについて実行すべき処理を決定することを可能にする。
【０１９１】
本発明の実施例の中には、図23に示したものより多くの構成要素を含むものもある。したがって、そのようなより複雑な実施例の説明を行う前に、図23に示されたセマンティックプロセッサ内のパケットフローについて説明する。
【０１９２】
図24は、図23に示すセマンティックプロセッサ3100を介して受信したパケットの処理に関するフローチャート3300である。このフローチャート3300は、本発明の方法を説明するのに使用される。
【０１９３】
ブロック3310では、パケットは入力ポート3120を介して、入力バッファ3140において受信される。次のブロック3320では、DXP 3180は入力バッファ3140内のパケットのヘッダーの解析を開始する。パケットが、パケットのペイロードの処理を可能にするために追加の操作か追加のパケットを必要としない場合、DXP 3180はヘッダーを完全に解析する。パケットが、パケットのペイロードの処理を可能にするために追加の操作か追加のパケットを必要とする場合、DXP 3180はヘッダーの解析をやめる。
【０１９４】
判定ブロック3330では、DXP 3180がヘッダーを完全に解析することができたかどうかが問われる。DXP 3180が完全にヘッダーの解析を行うことができた場合、次のブロック3370では、DXP 3180はパケットプロセッサ3200内のルーチンを呼び出し、パケットペイロードを処理する。その後、セマンティックプロセッサ3100は、次のパケットが入力ポート3120を介して、入力バッファ3140において受信されるのを待つ。
【０１９５】
DXP 3180がヘッダーの解析をやめなければならない場合、次のブロック3340では、DXP 3180は、追加のパケットを待つか、パケットプロセッサ3200内のルーチンを呼び出して、パケットを制御する。制御が完了するかあるいは追加のパケットが到着するとすぐに、パケットプロセッサ3200は調整された（解決された）パケットを作成する。
【０１９６】
次のブロック3350では、パケットプロセッサ3200は調整された（解決された）パケット（またはその一部）を再循環バッファ3160に書き込む。これは、再循環バッファがメモリサブシステム3240に対して直接メモリアクセスすることを可能にすることにより達成することができる。もしくは、直接実行エンジン3220に、メモリサブシステム3240からの調節されたパケットを読み込ませ、その後再循環バッファ3160に調節されたパケットを書き込ませることにより達成することができる。その他のやり方として、パケットプロセッサ3200内に処理時間を格納するためには、完全に調節されたパケットの代わりに、特別なヘッダーが再循環バッファ3160に書き込まれてもよい。この特別なヘッダーは、完全なパケットをパケットプロセッサのメモリサブシステム3240から転送することを必要とせずに、パケットプロセッサ3200に、調節されたパケットを処理するように指示する。
【０１９７】
次のブロック3360では、DXP 3180は、再循環バッファ3160内のデータのヘッダーの解析を開始する。その後、実行プログラムはブロック3330へと戻り、そこで、DXP 3180がヘッダーを完全に解析することができたかどうか問われる。DXP 3180がヘッダーを完全に解析することができた場合、その後次のブロック3370では、DXP 3180はパケットプロセッサ3200内のルーチンを呼び出し、パケットペイロードを処理する。その後、セマンティックプロセッサ3100は、新しいパケットが、入力ポート3120を介して入力バッファ3140において受信されるのを待つ。
【０１９８】
DXP 3180がヘッダーの解析をやめなければならない場合、実行プログラムはブロック3340へと戻り、そこで、DXP 3180が、パケットプロセッサ3200内のルーチンを呼び出し、パケットを制御するか、追加のパケットを待ち、その後、調節されたパケットを作成する。パケットプロセッサ3200は、その後、調節されたパケットを再循環バッファ3160へと書き込む。そして、DXP 3180は、再循環バッファ3160内のパケットのヘッダーの解析を開始する。
【０１９９】
図25は、セマンティックプロセッサ3400の他の実施例を示している。セマンティックプロセッサ3400は以下の要素を備えている。
ハッシュ機能（ハッシング関数）またはコンテント・アドレッサブル・メモリ（CAM）検索を介して動的ランダムアクセスメモリ（DRAM）3480内のデータにアクセスするためのアレイマシンコンテキストデータメモリ(AMCD) 3430
データの暗号化や、複合化や、認証のための暗号処理ブロック3440
DRAM3480へコンテキスト制御ブロックをキャッシュするとともに、DRAM3480からコンテキスト制御ブロックをキャッシュするためのコンテキスト制御ブロックキャッシュ3450
基本オペレーションにおいて使用されるデータをキャッシュするための通常キャッシュ3460
データストリームがDRAMへと書き込まれている間と、データストリームがDRAMから書き込まれている間に、データストリームをキャッシュするためのストリーミングキャッシュ3470
このコンテキスト制御ブロックキャッシュ3450は、ソフトウェア制御のキャッシュであるのが好ましい。すなわち、いつキャッシュラインが使用され、いつ使用されないかをプロセスが決定するのが好ましい。この五つの各ブロックはDRAM 3480及びセマンティックコード実行エンジン（SEE）と接続されている（なお、セマンティックコード実行エンジン（SEE）は、セマンティックプロセッシングユニット（SPU）3410とも称される）。SEE 3410は、DXP 3180により信号を送られると、パケットのセグメントを処理するか、その他のオペレーションを実行する。DXP 3180が、解析の特定の時点でSEEタスクを開始すると決定すると、DXP 3180はSEE 3410に、セマンティックコードテーブル（SCT）3420からマイクロ命令をロードするように信号で伝える。このロードされたマイクロ命令は、その後SEE 3410内で実行され、パケットのセグメントはそれに従って処理される。
【０２００】
図26は、図25に示しているセマンティックプロセッサ3400を介して受信したフラグメント化したインターネットプロトコル（IP）パケットの処理に関するフローチャート3500である。このフローチャート3500は、本発明の実施例に係る実施方式を説明するために使用される。
【０２０１】
パケットが入力ポート3120を介して入力バッファ3140において受信され、それに伴いDXP 3180が入力バッファ3140内のパケットのヘッダーの解析を開始すると、ブロック3510では、DXP 3180は、受信したパケットがフラグメント化したIPパケットであると判定されたため、受信したパケットのヘッダーの解析をやめる。DXP 3180は、IPヘッダーを完全に解析し、続く層に属するヘッダー(TCP、UDP、iSCSIなど)についてはどのヘッダーに対しても解析を行わないのが好ましい。
【０２０２】
次のブロック3520では、DXP 3180は、SEE 3410にSCT 3420から適切なマイクロ命令をロードするとともに、入力バッファ3140から受信したパケットを読み込むように信号で伝える。次のブロック3530では、SEE 3410は、受信したパケットをストリーミングキャッシュ3470を介してDRAM 3480へ書き込む。ブロック3520とブロック3530は二つの個別のステップとして示されているが、他のやり方としては、これらは、SEE 3410がパケットの読み込みと書き込みを同時に行うことで一つのステップとして実行されてもよい。このSEE 3410による同時に読み込みと書き込みを実行するオペレーションは、SEEパイプライン方式として知られている。このオペレーションでは、SPU 3410は、セマンティックプロセッサ3400内の二つのブロック間で転送されるストリーミングデータ用のコンジット(conduit)またはパイプラインとして動作する。
【０２０３】
次の判定ブロック3540では、SPU 3410は、コンテキスト制御ブロック（CCB）が正しいIPパケットフラグメントの収集や順序付けのために割り当てられているかどうか判定する。フラグメント化されたIPパケットに対応するフラグメントを収集しかつ順序付けするCCBは、DRAM 3480内に格納されるのが好ましい。CCBは、DRAM 3480内のIPフラグメントに対するポインターと、まだ到着していないフラグメント化されたIPパケットに対するビットマスクと、割り当てられた期間が過ぎたらセマンティックプロセッサ3400に追加のフラグメント化されたIPパケットを待つことをやめさせ、その後、DRAM 3480内のCCBに保存されたデータを開放させるためのタイマー値と、を含んでいる。
【０２０４】
SPU 3410は、受信したIPパケットフラグメントのヘッダーからのID（identification）及びプロトコルを組み合わせた、受信したフラグメント化されたIPパケットの送信元IPアドレスを鍵として使用して、AMCD 3430のコンテント・アドレッサブル・メモリ（CAM）の検索機能にアクセスすることで、CCBが割り当てられているかどうか判定するのが好ましい。その他のやり方としては、IPフラグメント鍵は、DRAM 3480内の別々のCCBテーブル内に格納される。そして、このやり方では、この鍵は、受信したIPパケットフラグメントのヘッダーからのID（identification）及びプロトコルを組み合わせた、受信したフラグメント化されたIPパケットの送信元IPアドレスを使用することでCAMとアクセスさせられる。このIPフラグメント鍵のアドレス化のやり方は、鍵の重複と鍵の大きさの問題を回避する。
【０２０５】
SPU 3410が、特定のフラグメント化されたパケットに関するフラグメントの集積と順序付けのためにCCBがまだ割り当てられていないと判定する場合、実行プログラムはブロック3550へと進み、そこでSPU 3410がCCBを割り当てる。SPU 3410は、割り当てられたCCBに対応する鍵を、AMCD 3430内のIPフラグメントCCBテーブルへ入力し、CCB内に配置されたタイマーを開始する。ここで言う鍵は、受信したフラグメント化されたIPパケットのヘッダーからのID（identification）及びプロトコルと、受信したIPフラグメントの送信元IPアドレスと、から構成されるものである。与えられたフラグメント化されたパケットに関する最初のフラグメントが受信されると、IPヘッダーはまた、後の再循環のために、CCBへ格納される。以後のフラグメントに関しては、IPヘッダーは格納される必要はない。
【０２０６】
CCBがフラグメント化されたIPパケットの収集と順序付けのために割り当てられるとすぐに、次のブロック3560では、SPU 3410はフラグメント化されたIPパケット（からIPヘッダーを除いたもの）に対するポインターをCCB内のDRAM 3480に格納する。フラグメントに対するポインターは、例えばリンクされたリストとしてCCB内に設ける（arrange）ことができる。好ましくは、SPU 3410は、受信されたフラグメントに対応するマスクの一部を受信されたものとしてマーキングすることで、ビットマスクを新たに割り当てられたCCBでアップデートしてよい。
【０２０７】
次の判定ブロック3570では、SPU 3410は、パケットからのIPフラグメントのすべてが受信されたかどうか判定する。この判定は、CCB内でビットマスクを使用して達成されるのが好ましい。当業者であれば、本発明とともに利用可能なビットマスクまたはそれと均等なトラッキング機構を実施するのに容易に利用可能な多数の技術があることを理解するであろう。
【０２０８】
フラグメントパケットに関するIPフラグメントのすべてが受信され終わっていない場合、セマンティックプロセッサ3400は、その他のフラグメントが受信されるまで、このフラグメント化されたパケットに関するさらなる処理を保留する。
【０２０９】
IPフラグメントのすべてが受信され終わっている場合、次のブロック3580では、SPU 3410は、タイマーをリセットするとともに、DRAM 3480からIPフラグメントを正しい順序で読み込み、その後、さらなる解析と処理のために、それらを再循環バッファ3160へ書き込む。SPU 3410は、特別なヘッダーと、再構築されたIPパケット（フラグメント化ビットは設定されていないまま）の最初（first）の部分と、だけを再循環バッファ3160へ書き込むのが好ましい。特別なヘッダーは、DXP 3180が、フラグメント化されたパケットのすべてを再循環バッファ3160へと転送する必要なく、DRAM 3480内に格納された再構築されたフラグメント化されたIPパケットの処理を指示することを可能にする。特別なヘッダーは、IPに対するパーサ文法をロードするとともにCCBに対するポインターをロードするように指定された非終端シンボルから構成することができる。こうして、パーサは通常、IPヘッダーを解析することができ、その後上位層（例えばTCP）のヘッダーの解析へと進むことができる。
【０２１０】
本発明の実施例では、DXP 3180は、総当り方式の調停（arbitration）を介して、再循環バッファ3160と入力バッファ3140のどちらか一方で受信されたデータを解析することを決定する。総当り方式の調停（arbitration）に関する高度な記述は、パケットデータストリームを受信するための第一と第二のバッファに関連して以下において説明する。DXP 3180は、第一のバッファ内のパケットの解析を完了すると、第二のバッファを見て、データが解析可能かどうか判定する。解析可能である場合、第二のバッファからのデータが解析される。解析可能でない場合、DXP 3180は、第一のバッファを再び見て、データが解析可能かどうか判定する。DXP 3180は、第一のバッファか第二のバッファのどちらかでデータが解析可能となるまで、この総当り方式の調停（arbitration）を続ける。
【０２１１】
図27は、図25に示すセマンティックプロセッサ3400を介して受信したパケットで、複合化か、認証か、またはその両方が必要なパケットの処理に関するフローチャート3600である。このフローチャート3600は、本発明の実施例に係るその他の実施方式を説明するのに使用される。
【０２１２】
パケットが入力バッファ3140または再循環バッファ3160において受信され、それに伴いDXP 3180が受信したパケットのヘッダーの解析を開始すると、ブロック3610では、DXP 3180は、受信したパケットは複合化か、認証か、またはその両方が必要であると判定されたため、受信したパケットのヘッダーの解析をやめる。DXP 3180が再循環バッファ3160からのパケットのヘッダーの解析を開始した場合、再循環バッファ3160は、前述した特別なヘッダー及び再構築されたIPパケットの最初の部分だけを含んでいるのが好ましい。
【０２１３】
次のブロック3620では、DXP 3180は、SPU 3410に、SCT 3420から適切なマイクロ命令をロードするとともに、入力バッファ3140または再循環バッファ3160から受信したパケットを読み込むように指示する信号を送る。SPU3410は、再循環バッファ内にまだ配置されていないデータに対しては、再循環バッファ3160の代わりにDRAM 3480からパケットフラグメントを読み込むのが好ましい。
【０２１４】
次のブロック3630では、SPU 3410は、受信したパケットを暗号処理ブロック3440へ書き込む。そして、パケットはそこで認証されるか、複合化されるか、またはその両方を実行される。好ましい実施例では、複合化及び認証は暗号処理ブロック3440内で平行して実行される。暗号処理ブロック3440は、Triple Data Encryption Standard (T-DES)、Advanced Encryption Standard（AES）、Message Digest 5 (MD-5)、Secure Hash Algorithm 1 (SHA-1)、Rivest Cipher 4 (RC-4) アルゴリズムなどを使用することで、パケットの認証や、暗号化や、複合化を、可能にする。ブロック3620及びブロック3630は二つの別々のステップとして図示されているが、他のやり方としては、SPU 3410がパケットの読み込みと書き込みを同時に行うことで、これらは一つのステップとして実行することができる。
【０２１５】
複合化されたパケットや認証されたパケットはこうして、SPU 3410へと書き込まれ、次のブロック3640では、SPU 3410は、さらなる処理のために、パケットを再循環バッファ3160へ書き込む。好ましい実施例では、暗号処理ブロック3440は、データをDRAM 3480から読み込むことができ、かつデータをDRAM 3480へと書き込むことができる直接メモリアクセスエンジンを備えている。複合化されたパケットや認証されたパケットをDRAM 3480へ戻して書き込むことで、SPU 3410は、DRAM 3480からの複合化されたパケットや認証されたパケットのヘッダーだけを読み込むことができ、続いて、それらを再循環バッファ3160へと書き込むことができる。パケットのペイロードはDRAM 3480内に残っているので、セマンティックプロセッサ3400は、処理時間を保存する。IPフラグメント化の時と同様（like with IP fragmentation）、特別なヘッダーは再循環バッファへ書き込まれ、パーサを方向付けるとともに、CCB情報をSPU 3410へと送り返す。
【０２１６】
フラグメント化されたIPや、暗号化されたIPや、認証IPが、セマンティックプロセッサ3400により受信された単一のパケット内に含まれる場合、再循環バッファ3160を通過するための複数のパスが必要となることがある。
【０２１７】
図28は、セマンティックプロセッサの別の実施例を示している。セマンティックプロセッサ3700は、複数のセマンティック実行エンジン(SEE) 3410_ 1〜3410_ Nを含んでいるセマンティック実行エンジン（SEE）クラスター3710を備えている。各SEE 3410_ 1〜SEE 3410_ Nは、同質であり、同一の機能を持つのが好ましい。SPUクラスター3710は、メモリサブシステム3240と、SEEエントリーポイント（SEP）ディスパッチャ（dispatcher）3720と、SCT 3420と、ポート入力バッファ（PIB）3730と、ポート出力バッファ（POB）3750と、マシン中央演算処理装置（MCPU）3771と、と連結される。
【０２１８】
DXP 3180が、解析の特定の時点でSEEタスクを開始すると決定すると、DXP 3180は、SEPディスパッチャ3720に、セマンティックコードテーブル（SCT）3420からマイクロ命令をロードするとともに、SEEクラスター3710内の複数のSEE 3410_1〜3410_NからSEEを割り当てて、タスクを実行ように指示する信号を送る。このロードされたマイクロ命令と実行されるタスクは、その後、割り当てられたSEEへ送られる。割り当てられたSEEは、その後、マイクロ命令を実行し、データパケットはそれに従って処理される。SEEは、その他のやり方として、SEPディスパッチャ3720に命令された場合、SCT 3420から直接マイクロ命令をロードすることができる。
【０２１９】
PIB 3730は、少なくとも一つのネットワークインターフェイス入力バッファと、再循環バッファと、周辺機器構成要素相互通信（PCI-X）入力バッファと、を備えている。POB 3750は、少なくとも一つのネットワークインターフェイス出力バッファと、周辺機器構成要素相互通信（PCI-X）出力バッファと、を備えている。ポートブロック3750は、一つまたは複数のポートを備えている。これらの各ポートは、物理的インターフェイスを備えている。この物理的インターフェイスの例としては、イーサーネットや、Fibre Channelや、802.11xや、ユニバーサル・シリアル・バス（USB）や、ファイヤーワイヤーや、その他の物理レイヤーインターフェイスなどに対する光学的なあるいは電気的なもしくは無線によるドライバーとレシーバーのペアなどが挙げられる。ポートブロック3470内のポートの数は、PIB 3730内のネットワークインターフェイス入力バッファの数と、POB 3750内の出力バッファの数と、一致する（対応する）のが好ましい。
【０２２０】
PCI-Xインターフェイス3760は、PIB 3730内のPCI-X入力バッファと、POB 3750内のPCI-X出力バッファと、外部PCI-Xバス3780と、接続される。PCIバス3780は、ディスクドライブや、追加のネットワークポートに対するインターフェイスなどのような、その他のPCIケーブル構成要素と接続することができる。
【０２２１】
MCPU 3771は、SEEクラスター3710と、メモリサブシステム3240と、に接続される。
MCPU 3771は、セマンティックプロセッサ3700にとって望ましい機能の中で、通常のハードウェア上で従来のソフトウェアを起動することで無理なく遂行できるものを実行する。これらの機能は、通常、あまり使われずかつ時間的に重要でない機能であり、そのコードの複雑性から、SCT 3420内に含まれることを保障しない。MCPU 3771はまた、SEEがMCPUの代わりにタスクを実行するようにリクエストするためにSEEクラスター3710内のディスパッチャ（dispatcher）と通信する機能を持つ。
【０２２２】
本発明のある実施例では、メモリサブシステム3240は、さらに、暗号処理ブロック3440と、コンテキスト制御ブロックキャッシュ3450と、通常キャッシュ3460と、ストリーミングキャッシュ3470と、をDRAM 3480及び外部DRAM 3791と接続させるDRAMインターフェイス3790から構成される。この実施例では、AMCD 3430は、外部TCAMと直接接続するが、一方で、外部SRAM 3795（静的ランダムアクセスメモリ）と接続される。
【０２２３】
図29は、図28に示しているセマンティックプロセッサ3700を介して受信したインターネット小型コンピューター用周辺機器インターフェイス（iSCSI）データの処理に関するフローチャート3800である。このフローチャート3800は、本発明の実施例に係る他の実施方法を説明するのに使用される。
【０２２４】
ブロック3810では、少なくとも一つの通信制御プロトコル（TCP）セッションを持つiSCSIコネクションが、iSCSIデータの転送のために、開始プログラム（initiator）と対象のセマンティックプロセッサ3700の間に確立される。セマンティックプロセッサ3700は、適切な文法をPT 3160及びPRT 3190内に含むとともに、マイクロコードをSCT3420内に有している。この文法及びマイクロコードにより、TCPセッションを確立し、その後MCPU 3771を介して、iSCSIコネクションの初期（initial）ログイン及び初期（initial）認証を処理する。ある実施例では、SPUクラスター3710内の一つまたは複数のSPUはTCPセッションの状態を整理しかつ保持する。このTCPセッションの状態は、TCPの再順序付けのための、CCBのDRAM 3480内での割り当てと、ウィンドウサイズ制限と、割り当てられたタイムフレーム内に開始プログラム(initiator)からさらなるTCPパケットやiSCSIパケットが到着しない場合にTCPセッションを終了するためのタイマーと、を含む。TCP CCBは、一旦iSCSIコネクションがMCPU 3771により確立されると、このCCBをiSCSI CCBと関連させるためのフィールドを保持するようになる。
【０２２５】
TCPセッションが、開始プログラムとともに確立されると、次のブロック3820では、セマンティックプロセッサ3700は、ブロック3810内に確立されたTCPセッションに対応するTCP／iSCSIパケットがPIB 3730の入力バッファ3140内に到着するのを待つ。セマンティックプロセッサ3700は、入力データの処理に利用可能な複数のSPU 3410-1〜3410-Nを備えているので、セマンティックプロセッサ3700は、ブロック3810内で確立されたTCPセッションに対応する次のTCP／iSCSIパケットを待っている間、複数のパケットを並列に受信し、それらを並列処理することができる。
【０２２６】
TCP／iSCSIパケットは、ポートブロック3740の入力ポート3120を介して、PIB 3730の入力バッファ3140において受信される。その後、DXP 3180は、入力バッファ3140内にあるパケットのTCPヘッダーを解析する。次のブロック3830では、DXP 3180は、SEPディスパッチャ3720に、SCT 3420から適切なマイクロ命令をロードするとともに、SPUクラスター3710からSPUを割り当てて、割り当てられたSPUにマイクロ命令を送るように指示する信号を送る。このマイクロ命令は、実行されると、割り当てられたSPUに、受信したパケットを入力バッファ3140から読み込み、その後、その受信したパケットをストリーミングキャッシュ3470を介してDRAM 3480へと書き込むように、要求するものである。この割り当てられたSPUはその後、AMCD 3430の検索機能を使用してTCP CCBを検索し、DRAM 3480内の受信したパケットの記憶場所（location）に対するポインターをTCP CCBへ格納し、TCP  CCB内でタイマーを再始動させる。割り当てられたSPUはその後、割り当て解除され、DXP 3180が決定するままにその他の処理に割り当てることができる。
【０２２７】
次のブロック3840では、受信したTCP／iSCSIパケットは、必要であれば、ペイロードデータのシーケンスが正しいことを保障するために再順序付けされる。当技術分野で周知のように、すべての先行するパケットが到着している場合、TCPパケットは適切な順序にあると考えられる。
【０２２８】
受信したパケットが適切な順序にあると判定されると、関連するSPUは、SEPディスパッチャ3720に、SCT 3420からiSCSI再循環に対するマイクロ命令をロードするように指示する信号を送る。次のブロック3850では、割り当てられたSPUは、iSCSIヘッダーと、TCPヘッダーからのTCPコネクションIDと、iSCSI非終端シンボルと、を組み合わせ特別なiSCSIヘッダーを作成する。割り当てられたSPUは、その後、特別なiSCSIヘッダーをPIB 3730内の再循環バッファ3160へ書き込む。その他のやり方としては、特別なiSCSIヘッダーを、それに対応するiSCSIペイロードとともに、再循環バッファ3160へと送ることができる。
【０２２９】
次のブロック3860では、特別なiSCSIヘッダーは解析され、その後セマンティックプロセッサ3700は、iSCSIペイロードを処理する。
【０２３０】
次の判定ブロック3870では、受信したTCP／iSCSIパケット内にもう一つのiSCSIヘッダーがあるかどうか尋ねられる。受信したTCP／iSCSIパケット内にもう一つのiSCSIヘッダーがある場合、実行プログラムはブロック3850へと戻り、そこで、この受信したTCP／iSCSIパケット内の第二のiSCSIヘッダーが第二のiSCSIペイロードを処理するために使用される。当技術分野で周知のように、単一のTCP／iSCSIパケット内に複数のiSCSIヘッダーとiSCSIペイロードがあってもよく、それゆえに、所定のいずれのiSCSIパケットにも、再循環バッファ3160及びDXP 3180を介して送られる複数のパケットセグメントがあってもよい。
【０２３１】
受信したTCP／iSCSIパケット内にもう一つのiSCSIヘッダーがない場合、ブロック3870は実行プログラムをブロック3820へと戻し、そこで、セマンティックプロセッサ3700が、ブロック3810内に確立されたTCPセッションに対応する別のTCP／iSCSIパケットが到着するのを待つ。割り当てられたSPUは、その後割り当て解除され、その後、DXP 3180が決定するままにその他の処理に割り当てることができる。
【０２３２】
当業者であれば、セマンティックプロセッサ3700により受信される単一のパケット内に暗号化と、認証と、IPフラグメント化と、iSCSIデータ処理と、のいずれかの組み合わせが含まれている場合、複数のパケットのセグメントが、異なる時点で、再循環バッファ3160を通過するようにしてもよいということを、理解するであろう。
【０２３３】
メモリサブシステム
図30は、メモリサブシステム3240をさらに詳しく示している。SPU 3710のクラスターとARM 3814は、メモリサブシステム3240と接続される。他の実施例では、ARM 3814は、SPU 3710を介してメモリサブシステム3240と接続される。メモリサブシステム3240は、それぞれ異なる種類のメモリアクセスに対して適応される複数の異なるキャッシュ領域3460と、3450と、3470と、3430と、3440と、3771と、を備えている。複数のキャッシュ領域3460と、3450と、3470と、3430と、3440と、3771と、は通常、キャッシュ領域3825と呼ばれる。SPUクラスター3710及びARM 3814は、キャッシュ領域3825のいずれかのキャッシュと接続し、今度はそのキャッシュが、メインDRAMアービター(arbiter) 3828を介して外部動的ランダムアクセスメモリ（DRAM）と接続する。しかし、ある実施例においては、CCBキャッシュ3450は、CCB DRAM制御装置3826を介して別の外部CCB DRAM 3791Bと接続してもよい。
【０２３４】
異なるキャッシュ領域3825は、異なるデータ処理オペレーションに関するDRAMのデータ転送を改善する。通常キャッシュ3460は、SPU 3710による通常目的のメモリアクセスのための標準的なキャッシュとして動作する。例えば、通常キャッシュ3460は、通常の制御オペレーションとデータアクセスオペレーションを指示するために使用される通常目的のランダムメモリアクセスのために使用されてもよい。
【０２３５】
CCBキャッシュ3450内のキャッシュライン取替えは、ソフトウェアコマンドにより排他的に制御される。これは、最後にどのハードウェアがキャッシュライン位置を占有した(occupy)かに基づいて、ハードウェアがキャッシュのコンテンツを制御する従来のキャッシュオペレーションと正反対である。CCBキャッシュ領域3450をソフトウェアで制御することで、キャッシュが、キャッシュラインを早くリロードしすぎるのを防ぐことができる。このリロードは、キャッシュラインが外部DRAM 3791Bからロードまたはアップデートされる前に、一つまたは複数のSPU 3710による何らかの中間処理を必要とすることがある。
【０２３６】
ストリーミングキャッシュ3470は、主にストリーミングパケットデータを処理するのに用いられる。ストリーミングキャッシュ3470は、ストリーミングパケット転送が、通常キャッシュ3460内のほとんどすべてのエントリーを置き換えることをやめさせる。ストリーミングキャッシュ3470は、一つまたは複数のSPU 3710が、まだデータがストリーミングキャッシュ3710内に配置されている間に、データを読み込む必要が出てくる可能性があるので、先入れ先出し（FIFO）メモリバッファの代わりにキャッシュとして実行される。FIFOが使用されると、ストリーミングデータは、外部DRAM 3791Aへとロードされてからしか読み込むことができなくなってしまう。ストリーミングキャッシュ3470は、各々が異なるパケットストリームを保持することができる複数のバッファを備えている。これにより、異なるSPU 3710は、異なるパケットストリームがストリーミングキャッシュ3470内に配置されている間にもそれらにアクセスすることができる。
【０２３７】
MCPU 3771は、主にARM 3814からの命令アクセスのために使用される。MCPU 3771は、ARM 3814と外部DRAM 3791A間のバーストモードアクセスの効率を向上させる。ARM 3814は、ある実施例では、32ビット幅である内蔵キャッシュ3815を備えている。MCPU 3771は、特に、32ビットバースト転送を制御する（handle）ように方向付けられている(direct)。MCPU 3771は、複数の32ビットバーストをARM 3814からバッファして、その後キャッシュラインがいくつかの閾値データ量に到達したとき、それらを外部DRAM 3791Aへバーストして（一斉に送って）よい。
【０２３８】
ある実施例では、各キャッシュ領域3825は、外部DRAM 3791Aと3791B内の異なる関連領域に、物理的に配置させてもよい。これと、MCPU 3771をキャッシュ領域と別々にすることにより、ARM 3814と外部DRAM 3791A間の命令転送が、他のキャッシュ領域に指示されるデータ転送により悪影響を及ぼされる（polluted）ことを防止する。例えば、SPU 3710は、キャッシュ領域3460と、3450と、3470と、を介して、ARM 3814により使用される命令スペース（instruction space）に悪影響を及ぼす（polluting）ことなく、データをロードすることができる。
【０２３９】
S−コード
図31は、異なるキャッシュ領域3825に対して、メモリアクセスが各SPU 3410によりどのように開始されるかを詳しく示している。簡単のため、図31には、通常キャッシュ3460と、CCBキャッシュ3450と、ストリーミングキャッシュ3470と、だけが示されている。
【０２４０】
マイクロ命令3900は、もう一つの呼び方としてSPUコード（S−Code）と呼ばれ、直接実行パーサ3180（図23に示している）からSPUサブシステム3710へと送られる。マイクロ命令3900の例は、図32Aでより詳しく示されている。このマイクロ命令3900は、各SPU 3410に、どのキャッシュ領域をデータ処理のために使用するのかを指示するターゲットフィールド3914を含んでもよい。例えば、図32Aに示しているキャッシュ領域フィールド3914は、SPU 3410にCCBキャッシュ3450を使用するように命令する。ターゲットフィールド3914は、SPU 3410に、MCPU 3771（図30に示している）や、再循環バッファ（図23に示している）や、出力バッファ3750（図28に示している）にアクセスするように命令するのに用いることもできる。
【０２４１】
図31に関して、各キャッシュ領域3825は、SPUサブシステム3710内に、関連したキューのセットを保持している。個々のSPU 3410は、データアクセスリクエストをキュー3902に送り、その後このキュー3902は異なるキャッシュ領域3825に対し順序正しいアクセスを提供する。このキュー3902はまた、異なるSPU 3410が、異なるキャッシュ領域3825に対するメモリアクセスを同時に導いたり、指示したりすることを可能にする。
【０２４２】
図32BはSPU 3410とキャッシュ領域3825間で送信されるキャッシュリクエスト3904の例を示している。このキャッシュリクエスト3904はアドレス及びあらゆる関連データを含んでいる。加えて、このキャッシュリクエスト3904は、どのSPU 3410がこのリクエスト3904と関連されているかを識別するSPUタグ3906を含んでいる。SPUタグ3906は、キャッシュ領域3825に、どのSPU 3410へリクエストされたデータを送信するかを伝える。
【０２４３】
調停（arbitration）
図30に関して、調停に特に関係しているのは、DRAMアービター(arbiter)3828である。このDRAMアービター3828は、ある実施例では、いつ異なるデータキャッシュ領域3825からのデータが外部DRAM 3791Aに対するアクセスを得るのかを判定するために総当り方式のアービトレーション(round robin arbitration)を用いている。総当り方式の調停スキームでは、メインのDRAMアービター3828は、所定の順序で、何れかのキャッシュ領域3825が外部DRAM 3791Aに対するアクセスをリクエストしたかどうかチェックし続ける。特定のキャッシュ領域3825がメモリアクセスリクエストを作成する場合、そのメモリアクセスリクエストに関連した総当り方式の実行期間中、そのメモリアクセスリクエストは外部DRAM 3791Aに対するアクセスとみなされる。アービター3828は、その後、メモリアクセスリクエストに関して次のキャッシュ領域3825を総当り順でチェックする。次のキャッシュ領域3825がメモリアクセスリクエストを持たない場合、アービター3828は次のキャッシュ領域3825を総当り順でチェックする。このプロセスは、各キャッシュ領域3825が総当り順で提供され、継続する。
【０２４４】
CCBキャッシュ3450と外部DRAM 3791A間のアクセスは、大量の情報量や回線容量（bandwidth）を消費することがある。CCB DRAM制御装置3826は、CCBキャッシュ（コンテキスト制御ブロックキャッシュ）3450と別の外部CCB DRAM 3791B間のCCB転送専用に使用することができる。異なるバス3834と3836は、それぞれ、DRAM 3791AとDRAM 3791Bの２つの異なるバンクに対するアクセスに使用することができる。他のキャッシュ領域3460、3470、3430、3440及び3771による外部メモリに対するアクセスは、メインのDRAMアービター3828によりバス3834を介して個別に調停される。CCBキャッシュ3450が外部DRAMに別のCCB制御装置3826を介して接続されていない場合、メインのDRAM制御装置（アービター）3828は、外部DRAM 3791Aに対するすべてのアクセスを、すべてのキャッシュ領域3825に対して調停する。
【０２４５】
他の実施例では、外部DRAM 3791Aに対するアクセスと外部CCB DRAM 3791Bに対するアクセスは交互的になされる（interleaved）。これは、CCBキャッシュ3450及びその他のキャッシュ領域3825は、外部DRAM 3791Aと外部DRAM 3791Bの両方に対するメモリアクセスを行うことができることを意味する。これは、2つのメモリバンク3791Aと3791Bが、同時にアクセスされることを可能にする。例えば、CCBキャッシュ3450は、外部メモリ3791Aからの読み込みオペレーションを行うと同時に、外部メモリ3791Bへの書き込みオペレーションを行うことができる。
【０２４６】
通常キャッシュ
図33は、通常キャッシュ3460の一例をより詳しく示している。この通常キャッシュ3460は、SPU 3410（図31に示している）の一つから物理アドレス3910を受け取る。キャッシュライン3918は、物理アドレス3910からの下位アドレススペース（LOA）3916に従って、アクセスされる。
【０２４７】
このキャッシュライン3918は、ある例では、その他のキャッシュ領域3825内で使用されるキャッシュラインと比べて比較的小型であるか、それらとは異なるサイズを持つことがある。例えば、キャッシュライン3918は、ストリーミングキャッシュ3470やCCBキャッシュ3450で使用されるキャッシュラインと比べずっと小型でもよい。これにより、異なるキャッシュ領域3825により処理される異なる種類のデータに対してよりカスタマイズされたメモリアクセスを提供する。例えば、キャッシュライン3918は、通常のデータ処理制御に対して使用する場合は、16バイト長あればよい。一方、ストリーミングキャッシュ3470に対して使用するキャッシュラインは、大型のデータブロックを転送するために、これより大型のキャッシュライン（例えば64ビット長のもの）を持つことがある。
【０２４８】
各キャッシュライン3918は、キャッシュライン内のデータが有効であるかどうかを示す関連有効フラグ（associated valid flag）3920を保持してもよい。また、このキャッシュライン3918は、関連高位アドレス（HOA）フィールド3922を保持する。通常キャッシュ3460は、物理アドレス3910を受け取り、その後、LO A3916と関連したキャッシュライン3918に対するHOA 3922及び有効フラグ3920を調べる。有効フラグ3920が有効なキャッシュ入力を示し、HOA 3922が物理アドレス3910に対するHOA 3914と一致する場合、キャッシュライン3918のコンテンツは、リクエストしているSPU 3410へ出力される。フラグフィールド3920が無効な入力（entry）を示している場合、キャッシュライン3918のコンテンツは、外部DRAM 3791A（図30に示している）内の対応するアドレスにより上書きされる。
【０２４９】
フラグフィールド3920は有効なキャッシュ入力（entry）を示しているが、HOA 3922が物理アドレス3910内のHOA 3914と一致しない場合、キャッシュライン3918内の入力（entry）の一つが、自動的に外部DRAM 3791Aへロードされるとともに、物理アドレス3910と関連する外部DRAM 3791Aのコンテンツは、LOA 3916と関連するキャッシュライン3918へロードされる。
【０２５０】
コンテキスト制御ブロック（CCB）キャッシュ
図34は、コンテキストコントロールブロック（CCB）キャッシュ3450をより詳しく示している。このCCB 3450は、複数のバッファ3940及び連想タグ（associative tag）3942を備えている。従来の4重連想キャッシュ（4-way associative cache）とは異なって、CCB 3450は本質的に32重連想キャッシュのように動作する。複数のCCBバッファ3940及び連想タグ（associative tag）3942は、SPU 3410を介して送信されるソフトウェアコマンドのセットにより制御される。このソフトウェアコマンド3946は、外部DRAM 3791Aまたは3791B（図30に示している）とCCBキャッシュ3450との間のデータ転送の制御のために使用されるキャッシュ／DRAM命令3946のセットを含んでいる。SPU／キャッシュコマンド3948のセットは、SPU 3410とCCBキャッシュ3450との間のデータ転送を制御するのに使用される。ソフトウェア命令3946は、ALLOCATE（割り当て）オペレーションと、LOAD（ロード）オペレーションと、COMMIT（委任）オペレーションと、DROP（廃棄）オペレーションと、を含んでいる。ソフトウェア命令3948は、READ（読み込みオペレーション及びWRITE（書き込み）オペレーションを含んでいる。
【０２５１】
図35は、SPU 3410とCCBキャッシュ3450の間で送信されるCCBコマンド3954の例をいくつか示している。これらのどのソフトウェアコマンド3944も、SPU 3410により、いつでもCCBキャッシュ3450に出すことができる。
【０２５２】
図34及び35に示すように、SPU 3410の一つが、CCBバッファ3940の一つを最初に割り当てるように命令するALLOCATEコマンド3954A、をCCBキャッシュ3450へ送る。ALLOCATEコマンド3954Aは、CCBを含むDRAM 3791内の物理アドレスに関連する特定のメモリアドレスかあるいは特定のCCBタグ3956を含むことができる。CCBキャッシュ3450内の制御装置3950は、受け取ったCCBアドレス3956と、各バッファ3940に関連するアドレスまたはタグとが、並列的に一致させる処理を行う。各バッファ3940に関連するアドレスは、関連するタグフィールド3942内に保持される。
【０２５３】
アドレス／タグ3956がどのタグフィールド3942にも保持されない場合、制御装置3950は、使用されていないバッファ3940の一つを特定のCCBタグ3956に割り当てる。アドレスがタグフィールド3942の一つにすでに存在している場合、制御装置3950は、すでに特定のCCBタグ3956と関連付けがなされているバッファ3940を使用する。
【０２５４】
制御装置3950は、応答（reply）3954BをリクエストしているSPU 3410へと送り返す。この応答は、CCBバッファ3940がうまく割り当てられたかどうかを示す。バッファ3940がうまく割り当てられた場合、制御装置3950は、CCBタグ3956を使用するすべてのSPU 3410からのすべてのCCBコマンド3944を、新しく割り当てられたバッファ3940へとマッピングする。
【０２５５】
SPU 3410が、現在外部DRAM 3791内にある特定のメモリアドレスに関するデータを無視してもよい状況がある。例えば、外部DRAM 3791内のデータが上書きされる予定がある場合などがこれにあたる。従来のキャッシュアーキテクチャでは、何らかの特定のアドレスを持ち、現在はキャッシュ内に保持されていないコンテンツは、自動的にメインのメモリからキャッシュへロードされる。しかし、ALLOCATEコマンド3946は、最初にDRAM 3791からデータを読み込む必要なく、単にバッファ3940の一つを割り当てる。こうして、それまでにバッファ3940内のデータを外部DRAM 3791から読み込んだり、それを外部DRAM 3791へ書き込んだりすることなく、バッファ3940を中間データ処理のためのメモ帳として使用することもできる。
【０２５６】
LOADまたはCOMMITのソフトウェアコマンド3946は、キャッシュバッファ3940の一つと外部DRAM 3791との間でのデータ転送を完了するために、必要とされる。例えばLOAD（ロード）コマンド3954Cは、SPU 3410から制御装置3950へと送られ、特定のCCBタグ3956に関連するCCBを、外部DRAMからCCBキャッシュ3450内の関連するバッファ3940へロードする。制御装置3950は、CCBタグ3956をDRAM物理アドレスへと変換することができる。その後、この制御装置3950は、DRAM物理アドレスと関連したDRAM 3791からCCBを取り込むことができる。
【０２５７】
COMMIT（委任）コマンド3954Cは、SPU 3410により、バッファ3940のコンテンツを、CCBタグ3956に関連するDRAM 3791内の物理アドレスへ書き込むために送信される。このCOMMITコマンド3956Cはまた、制御装置3950にバッファ3940の割り当てを解除させ、このバッファを他のCCBに割り当てることを可能にする。しかし、他のSPU 3410は、後で、同じCCBタグ3956に関するバッファ割り当てをリクエストすることができる。この制御装置3950は、CCBがバッファ3940の一つの中にまだ存在している場合、現在バッファ3940内に存在し、その内部に配置されているCCBを使用することができる。
【０２５８】
DROP（廃棄）コマンド3944は、制御装置3950に、特定のCCBタグ3956と関連した特定のバッファ3940のコンテンツを廃棄する（discard）ように命令する。制御装置3950は、バッファのコンテンツを外部DRAM 3791へロードすることなく、単にCCBキャッシュ3450内のバッファ3940を割り当て解除することにより、CCBを廃棄する。
【０２５９】
READ及びWRITE命令3948は、CCBキャッシュ3450とSPU 3410間でCCBデータを転送するのに使用される。READ及びWRITE命令3948は、バッファ3940があらかじめ割り当てられている場合に限り、SPU 3410とCCBキャッシュ3450との間でデータ転送することを可能にする。
【０２６０】
すべての利用可能なバッファ3940が現在使用中である場合、SPU 3410の一つは、現在のALLOCATEコマンドがCCBキャッシュにより提供されるようになるまでに、現在使用されているバッファ3940の一つに委任（COMMIT）をしなくてはならないだろう。制御装置3950は、異なるCCBアドレスに対してどのバッファ3940が割り当てられているかについてのトラック（履歴）を保持する。SPU 3410は、現在割り当てられたバッファ3940の数のカウントを保持することしか必要としない。カウント数が利用可能なバッファ3940の総数に到達する場合、SPU 3410の一つは、COMMITコマンドまたはDROPコマンドを出して、バッファ3940の一つを開放する（割り当て解除する）ことができる。ある実施例では、すくなくともSPU 3410の倍のバッファ3940を備えている。これにより、すべてのSPU 3410は二つの利用可能なバッファ3940を同時に確保することができる。
【０２６１】
CCBキャッシュ3450内のオペレーションはソフトウェア制御下にあるので、SPU 3410が制御するのは、バッファ3940が開放され、そのバッファが外部メモリ3791へデータを転送するときだけである。加えて、バッファ3940をCCBに対して最初に割り当てるSPU 3410は、LOADコマンドを出すSPU 3410や、最終的にCOMMITコマンドやDROPコマンドを出すことによりバッファ3940を開放するSPU 3410と、異なってもよい。
【０２６２】
コマンド3944は、CCBキャッシュ3450とDRAM 3791との間のデータ転送の完全なソフトウェア制御を可能にする。これは、パケットデータが一つまたは複数のSPU 3410により処理される場合と、パケット処理中に特定のCCBが、DRAM 3791へロードされる必要がないと判定されるかまたはそれがDRAM 3791から読み込まれる必要がないと判定される場合に、かなり効果的である。例えば、SPU 3410の一つは、パケットの処理中に、パケットが不正確なチェックサム値を持っていると判定することがある。そのパケットは、そのパケットをDRAM 3791へロードすることなく、CCBバッファ3940から廃棄（除外/Dropped）することができる。
【０２６３】
ある実施例のバッファ3940はキャッシュラインとして実施される。それゆえ、一つのキャッシュラインだけが外部DRAMメモリ3791へ戻されて書き込まれる。ある実施例では、キャッシュラインは512バイトであり、そのワード（words）は64バイト幅である。制御装置3950は、どのキャッシュラインが変更されたかを認識することができる。そして、COMMITコマンドの命令下にある間に限り、制御装置3950は、バッファ3940で変更されたキャッシュラインを外部DRAMメモリ3791に戻して書き込むことができる。
【０２６４】
図36は、TCPセッションの処理中にどのようにCCBが使用されるかの例を示している。セマンティックプロセッサ3100（図23に示している）は、どの種類のデータ処理に対しても使用することができるが、ここでは説明のためにTCPパケット3960が示されている。この例の中のパケット3960は、イーサネットヘッダー3962と、IPヘッダー3964と、送信元IPアドレス3966と、宛先IPアドレス3968と、TCPヘッダー3970と、送信元TCPポートアドレス3972と、宛先TCPポートアドレス3974と、ペイロード3976と、を含んでいる。
【０２６５】
直接実行パーサ3180は、一つまたは複数のSPUに、IPヘッダー3964から送信元IPアドレス及び宛先IPアドレスを得るように指示し、TCPヘッダー3970から送信元TCPポートアドレス及び宛先TCPポートアドレスを得るように指示する。これらのアドレスは、入力バッファ3140（図23に示している）内に配置されてもよい。
【０２６６】
SPU 3410は、4つのアドレス値3966と、3968と、3972と、3974と、をAMCD 3430内のCCB検索テーブル3978へ送る。この検索テーブル3978は、送信元IPアドレスフィールド3980と、宛先IPアドレスフィールド3982と、送信元TCPポートアドレスフィールド3984と、宛先TCPポートアドレス3986と、の配列（array）を含んでいる。各アドレスの特有な組み合わせは、関連したCCBタグ3979を持つ。
【０２６７】
AMCD 3430は、4つのアドレス値3966と、3968と、3972と、3974と、をCCB検索テーブル3978内の4つの入力（entry）と一致させようと試みる。一致がない場合、SPU 3410は、新しいCCBタグ3979をパケット3960に関連したTCPセッションに対して割り当てる。そして、この4つのアドレス値はテーブル3978へ書き込まれる。一致がある場合、AMCD 3430は、一致しているアドレスの組み合わせに関連するCCBタグ3979を送り返す。
【０２６８】
CCBタグ3979が送り返される場合、SPU 3410は、パケット3960の次の処理のために送り返されたCCBタグ3979を使用する。例えば、SPU 3410は、特定のヘッダー情報をこのパケット3960からCCBキャッシュ3450内に配置されたCCBへロードしてもよい。加えて、SPU 3410は、ペイロードデータ3976をパケット3960からストリーミングキャッシュ3470（図30に示している）へ送ってもよい。
【０２６９】
図37は、CCB 3990に保持されることがある制御情報を数例示している。CCB 3990は、セッションID 3994とともに（along with）CCBタグ3992を保持してもよい。セッションID 3994は、TCPセッションに関する送信元及び宛先アドレスを含んでもよい。CCB 3990はまた、外部メモリ3791内のパケットペイロードデータを含む記憶場所を識別する、リンクされたリストポインターを保持してもよい。CCB 3990はまた、TCPシーケンス番号3998及び受信確認番号4000を保持してもよい。CCB 3990は、TCPセッションを処理するのに必要とされるかもしれない他のなんらかのパラメーターも保持してよい。例えば、CCB 3990は、受信ウィンドウフィールド4002と、送信ウィンドウフィールド4004と、タイマーフィールド4006と、を保持してもよい。
【０２７０】
すべてのTCP制御フィールドは、関連した同一のCCB 3990内に配置される。これにより、SPU 3410は、同一のTCPセッションに関連する、CCBキャッシュ3450内の同一のCCBバッファ3940からのすべてのフィールドにすばやくアクセスすることができる。さらに、CCBキャッシュ3450はソフトウェアにより制御されるので、すべての必要とされる処理がすべての異なるSPU 3410により完了されるまで、SPU 3410はCCB 3990をCCBキャッシュ3450内に保持することができる。
【０２７１】
異なるOSIレイヤーに関連するCCB 3990があってもよい。例えば、一部のCCB 3990がSCSIセッションに関連し、それに割り当てられ、他のCCB 3990がSCSIセッション内のTCPセッションに関連し、それに割り当てられてもよい。
【０２７２】
図38は、いつSPU 3410がバッファ3940内のCCBコンテンツを処理し終わるのかと、いつバッファ3940が利用可能になりその他のSPUによるアクセスに対し開放されるのかと、を表すためにフラグ4112がどのようにCCBキャッシュ3450内で使用されているのかを示している。
【０２７３】
IPパケット4100は、処理システム3100（図23に示している）により受信される。このIPパケット4100は、IPヘッダー4102と、TCPヘッダー4104と、ISCSIヘッダー4106と、を含むヘッダーセクションを有している。このIPパケット4100はまた、パケットデータを含むペイロード4108を有している。パーサ3180（図23に示している）は、異なるSPU 3410に、異なるIPヘッダー4102と、TCPヘッダー4104と、ISCSIヘッダー4106と、に含まれる情報及びペイロード4108に含まれるデータを処理するように指示することができる。例えば、第一SPU♯1がIPヘッダー情報4102を処理し、SPU♯2がTCPヘッダー情報4104を処理し、SPU♯3がISCSIヘッダー情報4106を処理する。別のSPU♯Nに、パケットペイロード4108をストリーミングキャッシュ3470内のバッファ4114へロードするように指示してもよい。もちろん、SPU 3410のどの組み合わせも、IPパケット4100内のあらゆるヘッダー情報とペイロード情報を処理することがきる。
【０２７４】
IPパケット4100内のヘッダー情報のすべては、同じCCB 4110と関連付けされてもよい。SPU1−3は、CCBキャッシュを介して、CCB 4110を格納し、それにアクセスする。CCB 4110はまた、完了ビットマスク4112を備えている。ここでSPU 3410は、それらのタスクが完了した際に、完了マスク4112のビットに対し（意図せずに）未知の他のビットと論理OR演算を行う。例えば、SPU♯1は、CCB 4110内のIPヘッダー4102の処理が完了したときに、完了ビットマスク4112の第一のビットを設定（set）してもよい。SPU♯2は、TCPヘッダー4104の処理が完了したときに、完了ビットマスク4112の第二のビットを設定（set）することができる。完了ビットマスク4112のすべてのビットが設定される場合、これはIPパケット4100のSPUによる処理が完了したことを示す。
【０２７５】
こうして、ペイロード4108に対する処理が完了したとき、SPU♯Nは完了マスク4112をチェックする。マスク4112のすべてのビットが設定されている場合、SPU♯Nは、例えば、CCBキャッシュ3450（図31に示している）にCOMMITコマンドを送ってもよい。このCOMMITコマンドは、CCBキャッシュ3450に、CCB 4110を含んでいるキャッシュラインのコンテンツを外部DRAMメモリ3791へ委任するように指示する。
【０２７６】
ストリーミングキャッシュ
図39は、ストリーミングキャッシュ3470をより詳しく示している。ある実施例では、このストリーミングキャッシュ3470は、DRAM 3791からのデータの送受信のために使用される複数のバッファ4200を含んでいる。ある例のバッファ4200は、256バイト幅であり、各キャッシュラインは、タグフィールド4202と、VSDフィールド4204と、バッファ4200の64バイト部分と、を含んでいる。このようにして、4つのキャッシュラインは各バッファ4200と関連される。このストリーミングキャッシュ3470は、ある具体例（implementation）では、各SPU 3410に対し二つのバッファ4200を備えている。
【０２７７】
VSDフィールド4204は、キャッシュラインが有効か無効かどうかを示す有効値と、キャッシュラインがまだ更新されている最中にあるかあるいは更新され終わっている（dirty or clean）かどうかを示すステータス値と、読み込み状態か、書き込み状態か、非併合状態か、を示す命令値（direction value）と、を有している。
【０２７８】
ストリーミングキャッシュと特に関係があるのは、キャッシュ制御装置4206により行われる事前取り込みオペレーション（pre-fetch operation）である。物理アドレス4218は、DRAM 3791からの読み込みをリクエストしている複数のSPU 3410のうちの一つから制御装置4206へ送られる。制御装置4206は、物理アドレスをキャッシュラインの一つ（例えばキャッシュライン4210）と関連付ける。ストリーミングキャッシュ制御装置4206は、その後自動的に、バッファ4200内での同じFIFOのバイト順序と関連する三つの他の64バイトキャッシュライン4212、4214、4216に対する事前取り込み（pre-fetch）4217を行う。
【０２７９】
事前取り込み（pre-fetch）4217の一つの重要な態様（aspect）は、タグフィールド4202が異なるバッファ4200と関連付けされる方法である。タグフィールド4202は、制御装置4206により、特定のバッファ4200を識別するために使用される。物理アドレス4218のタグフィールド4202に関連する部分は、バッファ4200が連続的な物理アドレス配置を保持することを避けるように制御装置4206により選択される。例えば、制御装置4206は、物理アドレス4218の中頃の順番の複数のビット（middle order bit）4220を使用して、そのビットをタグフィールド4202と関連付けさせてもよい。これにより、三つの連続キャッシュライン4212、4214、4216の事前取り込み（pre-fetch）4217が、キャッシュライン4210と関連したストリーミングデータオペレーションと衝突するのを防止する。
【０２８０】
例えば、SPU 3410の一つは、ストリーミングキャッシュ3470に対して、関連物理アドレス4218を付けたコマンドを送ってもよい。このコマンドは、パケットデータがDRAMメモリ3791から特定のバッファ4200と関連する第一キャッシュライン4210へロードされることを要求する。このバッファ4200は、物理アドレス4218の一部と関連するタグ値4202を持っている。この後で、制御装置4206は、事前取り込みオペレーション（pre-fetch operation）を行って同じバッファ4200に関連するキャッシュライン4212、4214、4216をもロードするように試みてよい。しかし、バッファ4200は、SPU 3410によりすでに使用されているので、事前取り込み（pre-fetch）4217は、行き詰ることとなる。加えて、事前取り込み（pre-fetch）4217が完了することを許可されると、それらは、バッファ4200内にある、他のSPUコマンドに従ってすでにロードされたキャッシュラインを上書きすることができる。
【０２８１】
物理アドレス4218の中頃の順番の複数のビット（middle order bit）4220からタグ値4202を得ることで、連続した256バイトの各物理アドレス限界は、異なるメモリバッファ4200内に記憶（locate）されることとなる。これにより、事前取り込みオペレーション（pre-fetch operation）中のオペレーション同士の衝突を防止する。
【０２８２】
AMCD
図40は、図28のAMCD 3430の一例としての実施例の機能ブロック図である。SPUクラスター4012はAMCD 3430と直接通信する一方、ARM 4014はSPUクラスター4012におけるSPU 3710を介してAMCD 3430と通信することができる。AMCD 3430はSPU 3410に対してメモリ検索機能(memory lookup facility)を提供する。一つの例では、SPU 3410は、例えば外部DRAM 3791（図28参照）のようなメモリ内のどこに以前保存されたエントリーが保存されているかを判定する。AMCD 3430における検索機能は、ネットワークシステムのどこかのデータが保存されている場所を検索することができるのであって、外部DRAM 3791に限定されるものではない。
【０２８３】
このシステムが非学習モード(non-learning mode)のときは、SPU 3410はそれ自身のメモリマッピングのテーブルを保持し、エントリーを加え、削除しかつ修正することによりそのテーブルを管理する。このシステムが学習モード(learning mode)のときは、SPU 3410は、エントリーを加えながらTCAMメモリをサーチせよというコマンドあるいはエントリーを削除しながらTCAMメモリをサーチせよというコマンドを実行することによって、テーブルを保持する。いずれのモードにおいても、キーとなる値（以下、「キー値」とする）がこれらの異なるタイプのサーチのそれぞれを行うにあたってSPU 3410によって用いられる。
【０２８４】
図40のAMCD 3430は、検索インターフェイス(lookup interface)のセット（LUIF）4062を有している。一実施例では、AMCD 3430に8個のLUIFがある。LUIFの一例の詳細が図示されており、64ビットのレジスタ4066のセットを含んでいる。これらのレジスタ4066は、データ用の保存場所を提供するとともにメモリ検索を実行せよとのコマンドを提供する。また、検索結果もこれらのレジスタ4066を介して戻される。一実施例では、検索コマンド用の１個の64ビットレジスタと、データ保存用の７個までの64ビットレジスタを備えている。必ずしもすべてのレジスタが使用される必要はない。本発明のいくつかの実施例では、SPUクラスター4012とLUIF 4062の間の通信インターフェイスは64ビット幅であり、そのためLUIF 4062が複数の64ビットレジスタを含むのに好都合となっている。このコマンドの構造の一例が図41に示されており、その内容については以下で説明する。
【０２８５】
設計されたシステムには有限数のLUIF 4062があり、しかもこれらのLUIFは一度に１個以上のSPU 3410によってアクセスされることができないので、フリーのLUIFをSPU 3410に割り当てる機構が設けられている。フリーリスト4050はLUIF 4062の使用方法を管理する。SPU 3410がLUIF 4062にアクセスしたい場合、当該SPUがフリーリスト4050を読み、どのLUIF 4062が使用中かを調べる。フリーリスト4050を読んだ後、次の利用可能なフリーなLUIF 4062のアドレスが当該LUIF 4062が使用することができることを示す値とともに戻される。当該LUIF 4062についての戻された値が有効な場合には、SPU 3410は当該LUIFの制御を安全に行うことができる。次いで、第１のSPU 3410がLUIFを解放するまで当該特定のLUIF 4062は他のSPU 3410によって使われることができないというエントリーがフリーリスト4050になされる。この第１のSPU 3410がサーチを終えかつ戻ってきたサーチ結果を得た後、SPUは使用されたLUIFの識別子をフリーリスト4050に載せ、そして当該LUIFが再び他のSPU 3410による使用に対して利用可能な状態となる。フリーリスト4050にフリーなLUIFが無い場合、リクエストされているSPU 3410は、フリーなLUIFが無いことを知らされ、SPU 3410はフリーなLUIF 4062を得るために後で再びトライすることを強制させられる。また、フリーリスト4050は、SPUs 3410に処理すべき他のSPUリクエストを待ちながらインデックスのロードを開始させることを可能にせしめるパイプライニング機能も提供する。
【０２８６】
選択されたLUIFは、以下に記載するように、アービター(arbiter) 4068に検索コマンドとデータを送る。このアービター4068は、どの特定なLUIF 4062が特定のTCAM制御装置にアクセスするかを選択する。本実施例では、外部TCAM制御装置1072のほかに内蔵（内部）TCAM制御装置4076がある。外部TCAM制御装置4072は他の外部TCAM 4082に接続されており、またその外部TCAM 4082を介して外部SRAM 4096にも接続されている。同様に、内蔵TCAM制御装置4076は、内蔵TCAM 4096に接続されており、またその内蔵TCAM 4096を介して内蔵SRAM 4086にも接続されている。
【０２８７】
通常、本システムでは、一度に一つのTCAMだけが、すなわち内蔵TCAM 4096または外部TCAM 4082のいずれか一方だけが稼動する。換言すれば、本システムが外部TCAMとSRAM 4092を備えていると、AMCD 3430がこれらの外部メモリと通信する。同様に、システムが外部TCAM及びSRAM 4092を備えていない場合、AMCD 3430が内蔵TCAM 4096と内蔵SRAM 4086とだけ通信する。以下に述べるように、外部メモリがあるかどうかによって、一つの制御装置4076または4072だけが使用される。AMCD 3430によって使用されていない特定の制御装置4072または4076は、セットアップの過程で“turned off”であるとされる。一実施例では、システム初期化の際に、外部TCAM 4082があるかかどうかを示すセットアップコマンドがAMCD 3430に送られる。外部TCAM 4082がある場合、内蔵TCAM制御装置4076は“turned off”となり、外部TCAM 制御装置4072が使用される。これに対し、外部TCAM 4082がない場合、外部TCAM制御装置4072は“turned off”となり、内蔵TCAM 制御装置4076が使用される。簡単にするために、TCAM制御装置4076か4072のいずれか一方のTCAM制御装置だけが使用されることが好ましいが、AMCD 3430は、両方のTCAM制御装置4076及び4072を使用して実行することができるようになっている。
【０２８８】
実施例の一例では、内蔵TCAM 4096は512個のエントリーを含んでおり、SRAM 4086も同様である。他の実施例では、外部TCMA 4082は、外部SRAM 4092におけるエントリーの数と一致する64k〜256kのエントリーを含んでいる（一つのエントリーは72ビットであり、多数のエントリーが一緒に連動して72ビットより広いサーチ範囲を作り出す）。通常、SRAM 4086, 4092は、20ビット幅であり、一方TCMA 4082、4086はそれらよりも大分広い。内臓TCAM 4906は、例えば、164ビット幅とすることできるが、その一方、外部TCAM 4082は、例えば、72〜448ビット幅の範囲にある。
【０２８９】
SPU 3710が検索を実行すると、前述したように、パケットデータからキーを作成する。SPU 3410は、LUIFs 4062の内の一つリザーブし、次いでそのLUIF 4062のレジスタ4066にコマンド（CMD）及びデータをロードする。コマンド及びデータがロードされると、TCAM 4096または4082の内の一方でサーチを開始する。レジスタ4066からのコマンドはアービター4068に送られ、次いでそのデータを適したTCAM 4096,4082に送る。例えば、外部TCAM 4082があり、それが使用中であると仮定する。TCAMコマンドに対して、SPU 3410によって送られたデータが外部TCAM制御装置4072に提示され、そして当該制御装置4072がそのデータを外部TCAM 4082に提示する。外部TCAM 4082がキーデータの一致を見つけると、対応するデータが外部SRAM 4092から検索される。いくつかの実施例では、SRAM 4092は、TCAMに保存されたキー値によってインデックス化された所望のデータを含むメモリの記憶場所に対するポインターを格納している。このSRAM 4092からのポインターは、元のリクエストしたSPU 3410によって用いられた元のLUIF 40062のレジスタ4066を介して、リクエストしているSPU 3410に戻される。LUIFs 4062は、このようにして、DRAM 3791あるいはシステムのどこかにあるメモリ上で、サーチ、書き込み、読み出し、あるいは標準メンテナンス作業に用いることができる。
【０２９０】
これらの方法を用いることによって、TCAM 4082または4096は、CCB DRAM 3791B（図30）において高速検索に用いられる。また、TCAM 4082または4096は、非常に多くのセッション数が同時にIPv6用のCCBsに対して検索される必要があるアプリケーションに用いることもできる。さらに、TCAM 4082または4096は、異なるIPセッションに対するポートアドレスを検索する必要がある静的経路テーブル(static route table)を実施するのにも用いることができる。
【０２９１】
コンフィグレーションレジスターテーブル（configuration register table）4040のセットがメモリ検索を行うにあたってSPU 3410によって送られたキー値と関連して用いられる。一実施例では、16のテーブルエントリーがあり、各テーブルが0000〜1111の４ビットインディケータによってインデックス付けされることができる。例えば、コンフィグレーションテーブル4040に保存されているデータは、リクエストされている検索におけるキーのサイズを含むことができる。64, 72, 128, 144, 164, 192, 256, 288, 320, 384または448ビットのようないろいろなサイズのキーを用いることができる。コンフィグレーションテーブル4040には、特別なキーのサイズのデータ（キーが掛けられたデータがサーチされる場合）や他の種々のデータが保存されている。図41に示すように、テーブル識別子番号がビットロケーション19:16の位置に有り、コンフィグレーションテーブル4040においてどの値が用いられるかを示している。
【０２９２】
図42は、アービター4068の一例を示している。アービター4068は、各LUIF 4062に接続されている。また、アービター4068は、内蔵TCAM制御装置4076及び外部TCAM制御装置4072の両方に接続されているセレクトMUX 4067にも接続されている。前述したように、本発明のいくつかの実施例では、TCAM制御装置4076、4072のいずれか一方だけが一度に稼動し、当該制御装置が起動時にセレクタMUX 4067に送られる信号により制御される。この実施例では、アービター4068は、その出力信号が内蔵TCAM制御装置4076及び外部TCAM制御装置4072のいずれに送られたか区別していない。その代わりに、アービター4086は、単に、出力信号をセレクトMUX 4067に送るだけで、セレクトMUX 4067が該MUXに入力されたセットアップ値の状態に基づいて検索リクエストを適したTCAM制御装置4076または4072にルーティングして送るようになっている。
【０２９３】
アービター4068の機能は、図42において符号LUIF-1〜LUIF-8で示されているLUIFs 4062のどれかを選択することであり、選択されたLUIF 4062が選択されたTCAM制御装置4076または4072によって次に使用されることになる。このアービター4068は、その最も単純化された形態では、総当り式アービター(round-robin arbiter)として実施することができる。より知的なシステムでは、アービター4068は、以下に記載するように、過去の経緯を用いて、どのLUIF 4062が次に選択されるべきかを表すプライオリティ値を付与する。
【０２９４】
すなわち、このより知的なアービター4068では、プライオリティシステムがどのLUIF 4062が最も直近に使用されたか示すとともに、この内容を次の検索作業でどのLUIF 4062を選択すべきかの決定のためのファクターにするようになっている。図43は、知的アービターの一例における調停(arbitration)の例を示している。時間Ａでは、各プライオリティ値がすでに“０”に初期化されており、LUIF-3及びLUIF-7がオペレーション（作業）をペンディング状態としている。アービター4068は、一度に一つのLUIF 4062だけを選択するので、LUIF-3が調停を介して選択される。これは、オペレーションがペンディング中の他のLUIF (LUIF-7)も同じプライオリティ（この場合は“０”）を有しているためである。一旦、LUIF-3が選ばれると。そのプライオリティは“１”に設定される。時間Ｂでは、LUIF-3はペンディング中の新たなオペレーションを有しているのに対し、LUIF-7は依然としてまだ使われていないオペレーションを有している。この場合、アービター4068は、LUIF-7がLUIF-3よりも高いプライオリティを有しているので、LUIF-7を選択する。これは、すべてのLUIFsのそれぞれが均等に使われることを確実にするとともに、特定の一つのLUIFだけが検索時間を独占しないこと確実にする。
【０２９５】
時間Ｃでは、LUIF-1及びLUIF-3がペンディング中のオペレーションを有しており、アービター4068は、LUIF-1を選択する。これは、LUIF-3におけるオペレーションがより長くペンディング状態にあるが、LUIF-1がより高いプライオリティを有しているためである。最後の、時間Ｄにおいては、LUIF-3だけがペンディング中のオペレーションを有しているので、アービター4068はLUIF-3を選択肢、そのプライオリティを“２”にする。
【０２９６】
このようにして、アービター4068は知的な総当り式調停(intelligent round-robin arbitration)を実施する。換言すれば、一旦特定のLUIFが選択されると、当該LUIFが「ラインの端(end of the line)」まで移動し、ペンディング中のオペレーションを有している他のすべてのLUIFsが前記特定のLUIFが再び選択される前に使用されるようになっている。この方法は、各LUIF 4062がその検索機能を用いる時間を均等化させるとともに、特定の一つのLUIF 4062だけが検索帯域のすべてを独占しないようにすることを確実にする。
【０２９７】
上述したシステムは、前記オペレーションのすべてあるいはいくつかを行う専用のプロセッサシステムや、マイクロコントローラや、プログラマブル論理装置を使用することができる。また、上述したオペレーションのいくつかは、ソフトウェアで実行してもよく、またその他のオペレーションはハードウェアで実行してもよい。
【０２９８】
当業者であれば、本発明の範囲内で他の機能的なパーティションが可能であることを理解するであろう。また、どんな機能が共通の集積回路で実行されるか実行されないかは、アプリケーションによって変わることに留意されたい。
【０２９９】
最後に、本明細書では、いくつかの箇所で、「ある実施例では・・・」、「一つの実施例では・・・」、「他の実施例では・・・」、「いくつかの実施例では」といった表現があるが、これは必ずしも特定な同じ実施例を意味しているものではなく、またそこで記載された特徴が特定の一つの実施例だけに適用されることを意味しているわけではないことに留意されたい。
【図面の簡単な説明】
【０３００】
【図１】典型的フォン・ノイマンマシンストレージサーバーのブロック図を示している。
【図２】本発明の実施例に係る一般的なストレージサーバーのブロック図を示している。
【図３】本発明の実施例に係るストレージサーバーのより詳細なブロック図を示している。
【図４】イーサネット(Ethernet)／IP／TCP／CIFSストレージサーバーのクライアントのリクエストフレームの一般的な構造を示している。
【図５】図４に示しているCIFSフレーム構造のストレージメッセージブロック部分の詳細を示している。
【図６】前述した本発明の実施例に利用可能なセマンティックプロセッサの具体例（implementation）をブロック図で示している。
【図７】複数の物理的データ記憶装置を備えたストレージサーバー実施例のブロック図を示している。
【図８】データ記憶装置のプリント基板上で実施することができる本発明の実施例のブロック図を示している。
【図９】ディスクのドライブエレクトロニクスと直接通信するセマンティックプロセッサを有している実施例（implementation）のブロック図を示している。
【図１０】本発明の実施例に係る転換ストレージサーバーのブロック図を示している。
【図１１】複数の物理的データ記憶装置が、外部ストレージインターフェイスを介してセマンティックプロセッサによりアクセスされることを特徴とするシステムの実施例を示している。
【図１２】複数の物理的データ記憶装置がポート拡張器を介してセマンティックプロセッサと連結されることを特徴とするシステムの実施例を示している。
【図１３】本発明の実施例に利用可能なさらに別のセマンティックプロセッサの実施例を示している。
【図１４】本発明の実施例に利用可能なセマンティックプロセッサをブロック図で示している。
【図１５−Ａ】本発明の実施例に利用可能である一つの実行可能性のあるパーサテーブルの構成を示している。
【図１５−Ｂ】本発明の実施例に利用可能である一つの実行可能性のある生成規則テーブルの構成を示している。
【図１６】本発明の実施例に利用可能な入力バッファに関する一つの具体例をブロック図で示している。
【図１７】本発明の実施例に利用可能な直接実行パーサ（DXP）に関する一つの具体例をブロック図で示している。
【図１８】図１４に示しているセマンティックプロセッサ内でのデータ入力の処理に関するフローチャートの例である。
【図１９】本発明の実施例に利用可能な別のセマンティックプロセッサの実施例を示している。
【図２０】本発明の実施例に利用可能なポート入力バッファ（PIB）の実施例をブロック図で示している。
【図２１】本発明の実施例に利用可能な直接実行パーサ（DXP）の別の実施例をブロック図で示している。
【図２２】図１９に示すセマンティックプロセッサ内でのデータ入力の処理に関するフローチャートの例である。
【図２３】本発明の実施例に利用可能なセマンティックプロセッサをブロック図で示している。
【図２４】図２３に示す再循環バッファを備えたセマンティックプロセッサ内での受信したパケットの処理に関するフローチャートである。
【図２５】本発明の実施例に利用可能な別のセマンティックプロセッサの実施例をより詳しく示している。
【図２６】図２５に示しているセマンティックプロセッサ内での受信したフラグメント化されたIPパケットのフローチャートを示している。
【図２７】図２５に示しているセマンティックプロセッサ内で受信した、暗号化されているか、認証されていないか、またはその両方である、パケットのフローチャートを示している。
【図２８Ａ】本発明の実施例に利用可能であるさらに別のセマンティックプロセッサの実施例を示している。
【図２８Ｂ】本発明の実施例に利用可能であるさらに別のセマンティックプロセッサの実施例を示している。
【図２９】図28に示しているセマンティックプロセッサ内のTCPコネクションを介して受信したiSCSIパケットのフローチャートである。
【図３０】メモリサブシステムをより詳しく示す図である。
【図３１】メモリサブシステムをより詳しく示す図である。
【図３２Ａ】メモリサブシステムをより詳しく示す図である。
【図３２Ｂ】メモリサブシステムをより詳しく示す図である。
【図３３】メモリサブシステムをより詳しく示す図である。
【図３４】メモリサブシステムをより詳しく示す図である。
【図３５】メモリサブシステムをより詳しく示す図である。
【図３６】メモリサブシステムをより詳しく示す図である。
【図３７】メモリサブシステムをより詳しく示す図である。
【図３８】メモリサブシステムをより詳しく示す図である。
【図３９】メモリサブシステムをより詳しく示す図である。
【図４０】メモリサブシステムをより詳しく示す図である。
【図４１】メモリサブシステムをより詳しく示す図である。
【図４２】メモリサブシステムをより詳しく示す図である。
【図４３】メモリサブシステムをより詳しく示す図である。
【図１】
2007537550.tif 000003
【図２】
2007537550.tif 000004
【図３】
2007537550.tif 000005
【図４】
2007537550.tif 000006
【図５】
2007537550.tif 000007
【図６】
2007537550.tif 000008
【図７】
2007537550.tif 000009
【図８】
2007537550.tif 000010
【図９】
2007537550.tif 000011
【図１０】
2007537550.tif 000012
【図１１】
2007537550.tif 000013
【図１２】
2007537550.tif 000014
【図１３】
2007537550.tif 000015
【図１４】
2007537550.tif 000016
【図１５−Ａ】
2007537550.tif 000017
【図１５−Ｂ】
2007537550.tif 000018
【図１６】
2007537550.tif 000019
【図１７】
2007537550.tif 000020
【図１８】
2007537550.tif 000021
【図１９】
2007537550.tif 000022
【図２０】
2007537550.tif 000023
【図２１】
2007537550.tif 000024
【図２２】
2007537550.tif 000025
【図２３】
2007537550.tif 000026
【図２４】
2007537550.tif 000027
【図２５】
2007537550.tif 000028
【図２６】
2007537550.tif 000029
【図２７】
2007537550.tif 000030
【図２８Ａ】
2007537550.tif 000031
【図２８Ｂ】
2007537550.tif 000032
【図２９】
2007537550.tif 000033
【図３０】
2007537550.tif 000034
【図３１】
2007537550.tif 000035
【図３２Ａ】
2007537550.tif 000036
【図３２Ｂ】
2007537550.tif 000037
【図３３】
2007537550.tif 000038
【図３４】
2007537550.tif 000039
【図３５】
2007537550.tif 000040
【図３６】
2007537550.tif 000041
【図３７】
2007537550.tif 000042
【図３８】
2007537550.tif 000043
【図３９】
2007537550.tif 000044
【図４０】
2007537550.tif 000045
【図４１】
2007537550.tif 000046
【図４２】
2007537550.tif 000047
【図４３】
2007537550.tif 000048