(57)【要約】【課題】中間のメモリを必要とせず、メモリの使用を最小化する多重ネットワークプロトコルエンコーダ／デコーダを提供する。【解決手段】ネットワークパケットは、物理的伝送レベル機構から、各バイトが受信される度に、ＴＣＰ、ＩＰ、ユーザーデータプロトコル（ＵＤＰ）、ＰＰＰ、ローソケットのようなネットワークプロトコルをデコードするネットワークプロトコルレイヤー状態マシン（１０１）により受信される。各プロトコルハンドラは、中間のメモリを必要とせず、パケットからヘッダー情報を構文解析し、直ちに除去する。結果のデータは、Ｅメール、グラフィック、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、ジャバ、ハイパーテキストマークアップ言語（ＨＴＭＬ）のようなデータフォーマットをデコードするデータ状態マシン（１０４）から成るデータハンドラ（１０２）へ送られる。【選択図】図１
2007133902.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークパケットを受信及び送信し、パケットデータを有するネットワークパケットをエンコード及びデコードするためのネットワークプロトコルレイヤーモジュールと、
前記ネットワークプロトコルレイヤーモジュールと前記パケットデータを交換するためのデータハンドラモジュールと、
ネットワークプロトコルに対して最適化され、前記データハンドラモジュールと通信する少なくとも１つの状態マシンモジュールと
から成り、
前記ネットワークプロトコルレイヤーモジュールと前記データハンドラモジュールと前記少なくとも１つの状態マシンモジュールとは、ゲートレベル回路で実装された、対応する専用ハードウェア構造を含む
ことを特徴とする、ネットワークプロトコルパケットとデータをデコード及びエンコードするための装置。
【請求項２】
前記ネットワークプロトコルレイヤーモジュールが異なるネットワークプロトコルスタックを示す複数の状態マシンから成ることを特徴とする、上記請求項１に記載の装置。
【請求項３】
前記ネットワークプロトコルレイヤーモジュールが、ポイントツーポイントプロトコル(ＰＰＰ)、インターネットワークパケット(ＩＰ)、伝送制御プロトコル(ＴＣＰ)、ローソケット及び／又はユーザーデータグラムプロトコル（ＵＤＰ）の中の一つ又はそれ以上のネットワークプロトコルを実行することを特徴とする、上記請求項１に記載の装置。
【請求項４】
前記ネットワークパケットがリアルタイムで処理されることを特徴とする、上記請求項１に記載の装置。
【請求項５】
前記ネットワークパケットが同時に処理されることを特徴とする、上記請求項１に記載の装置。
【請求項６】
前記ネットワークパケットがシリアルに処理されることを特徴とする、上記請求項１に記載の装置。
【請求項７】
特定の前記状態マシンに一回以上要求されたデータは全て、特定の記憶位置に前記記憶位置を示すポインタを付けて配置されることを特徴とする、上記請求項１に記載の装置。
【請求項８】
前記データハンドラモジュールが、特定のデータ形式を処理する少なくとも一つの状態マシンから成ることを特徴とする、上記請求項１に記載の装置。
【請求項９】
前記データハンドラモジュールが、ハイパーデキスト転送プロトコル(ＨＴＴＰ)、ハイパーテキストマークアップ言語(ＨＴＭＬ)、ポストオフィスプロトコル(ＰＯＰ３)、インターネットメッセージアクセスプロトコル(ＩＭＡＰ４)、シンプルメール転送プロトコル(ＳＭＴＰ)、ジョイントフォトグラフィックエキスパートグループ(ＪＰＥＧ)、グラフィックインターチェンジフォーマット（ＧＩＦ）及び／又はジャバ言語のデータ形式の中から一つ又はそれ以上を処理することを特徴とする、上記請求項８に記載の装置。
【請求項１０】
前記データ形式がリアルタイムで処理されることを特徴とする、上記請求項９に記載の装置。
【請求項１１】
前記データ形式が同時に処理されることを特徴とする、上記請求項９に記載の装置。
【請求項１２】
前記データ形式がシリアルに処理されることを特徴とする、上記請求項９に記載の装置。
【請求項１３】
前記少なくとも１つの状態マシンで共有されるか、又は特定の前記状態マシンで一回以上要求される何れのデータも、特定の記憶位置に前記記憶位置を示すポインタを付けて配置されることを特徴とする、上記請求項９に記載の装置。
【請求項１４】
前記少なくとも１つの状態マシンで共有される何れのデータも、前記状態マシンに同時に提供されることを特徴とする、上記請求項９に記載の装置。
【請求項１５】
全てのメモリアクセスを裁定するメモリ制御モジュールを更に備えることを特徴とする、上記請求項１に記載の装置。
【請求項１６】
システムメモリとビデオメモリとが同じメモリ領域に存在することを可能にする統合メモリアーキテクチャ（ＵＭＡ）を含むメモリ制御モジュールを更に備えることを特徴とする、上記請求項１に記載の装置。
【請求項１７】
アービタブロックが二つの装置間で動的に回転するアルゴリズムに従って裁定する一つ又はそれ以上のアービタ論理ブロックから成るメモリ制御モジュールを更に備えることを特徴とする、上記請求項１に記載の装置。
【請求項１８】
メモリアクセスに関し、各装置に所与の裁定ツリー構造に基づいて固定された重み付き優先度を与えるように配列される一つ又はそれ以上のアービタ論理ブロックから成るメモリ制御モジュールを更に備えることを特徴とする、上記請求項１に記載の装置。
【請求項１９】
前記ネットワークプロトコルレイヤーモジュールと、前記データハンドラモジュールと、資源制御、システム及びユーザーインターフェースのためのメモリ制御モジュールとの間で、アービタとして働くアービタ状態マシンを更に備えることを特徴とする、上記請求項１に記載の装置。
【請求項２０】
ディスプレー制御器を更に含むことを特徴とする、上記請求項１に記載の装置。
【請求項２１】
前記ディスプレー制御器が、ＶＧＡ、リキッドクリスタルディスプレー（ＬＣＤ）又はライトエミッティングダイオード（ＬＥＤ）のディスプレー形式の中の一つを制御することを特徴とする、上記請求項２０に記載の装置。
【請求項２２】
インターネット信号をリアルタイムで処理し、前記処理されたインターネット信号をアプリケーション製品に送信することによって、前記装置が、インターネット信号とアプリケーション製品との間のインタフェースとして動作することを特徴とする、上記請求項１に記載の装置。
【請求項２３】
ネットワークプロトコルパケットとデータをデコード及びエンコードするための方法であって、
ネットワークパケットを受信及び送信し、パケットデータを有するネットワークパケットをエンコード及びデコードするためのネットワークプロトコルレイヤーモジュールを提供する段階と、
前記ネットワークプロトコルレイヤーモジュールと前記パケットデータを交換するためのデータハンドラモジュールを提供する段階と、
ネットワークプロトコルに対して最適化され、前記データハンドラモジュールと通信する少なくとも１つの状態マシンモジュールを提供する段階と
から成り、
前記ネットワークプロトコルレイヤーモジュールと前記データハンドラモジュールと前記少なくとも１つの状態マシンモジュールとは、ゲートレベル回路で実装された、対応する専用ハードウェア構造を含む
ことを特徴とする方法。
【請求項２４】
前記ネットワークプロトコルレイヤーモジュールが複数の状態マシンを使用して異なるネットワークプロトコルスタックを示す段階を更に実行することを特徴とする、上記請求項２３に記載の方法。
【請求項２５】
前記ネットワークプロトコルレイヤーモジュールが、ポイントツーポイントプロトコル(ＰＰＰ)、インターネットワークパケット(ＩＰ)、伝送制御プロトコル(ＴＣＰ)、ローソケット及び／又はユーザーデータグラムプロトコル（ＵＤＰ）の中の一つ又はそれ以上のネットワークプロトコルをエンコード及びデコードする段階を更に実行することを特徴とする上記請求項２３に記載の方法。
【請求項２６】
前記ネットワークプロトコルレイヤーモジュールが、ネットワークパケットをリアルタイムに処理する段階を更に実行することを特徴とする、上記請求項２３に記載の方法。
【請求項２７】
前記ネットワークプロトコルレイヤーモジュールが、ネットワークパケットを同時に処理する段階を更に実行することを特徴とする、上記請求項２３に記載の方法。
【請求項２８】
前記ネットワークプロトコルレイヤーモジュールが、ネットワークパケットをシリアル様式に処理する段階を更に実行することを特徴とする、上記請求項２３に記載の方法。
【請求項２９】
前記データハンドラモジュールが、少なくとも一つの状態マシンを使用して特定のデータ形式を処理する段階を更に実行することを特徴とする、上記請求項２３に記載の方法。
【請求項３０】
前記データハンドラモジュールが、データフィールドをデコードするためにＣＲＣアルゴリズムを使う段階を更に実行することを特徴とする、上記請求項２９に記載の方法。
【請求項３１】
前記データハンドラモジュールが、ハイパーデキスト転送プロトコル(ＨＴＴＰ)、ハイパーテキストマークアップ言語(ＨＴＭＬ)、ポストオフィスプロトコル(ＰＯＰ３)、インターネットメッセージアクセスプロトコル(ＩＭＡＰ４)、シンプルメール転送プロトコル(ＳＭＴＰ)、ジョイントフォトグラフィックエキスパートグループ(ＪＰＥＧ)、グラフィックインターチェンジフォーマット（ＧＩＦ）及び／又はジャバ言語のデータ形式の中から一つ又はそれ以上を処理する段階を更に実行することを特徴とする、上記請求項２９に記載の方法。
【請求項３２】
前記データハンドラモジュールが、パケットデータをリアルタイムで処理する段階を更に実行することを特徴とする、上記請求項２９に記載の方法。
【請求項３３】
前記データハンドラモジュールが、パケットデータを同時に処理する段階を更に実行することを特徴とする、上記請求項２９に記載の方法。
【請求項３４】
前記データハンドラモジュールが、パケットデータをシリアル様式に処理する段階を更に実行することを特徴とする、上記請求項２９に記載の方法。
【請求項３５】
前記データハンドラモジュールが、特定の前記少なくとも１つの状態マシンにより一回以上要求されたデータを全て、特定の記憶位置に前記記憶位置を示すポインタを付けて配置する段階を更に実行することを特徴とする、上記請求項２９に記載の方法。
【請求項３６】
全てのメモリアクセスを裁定するためのメモリ制御モジュールを提供する段階を更に含むことを特徴とする、上記請求項２３に記載の方法。
【請求項３７】
統合メモリアーキテクチャ（ＵＭＡ）を使用して、システムメモリとビデオメモリとが同じメモリ領域に存在することを可能にするメモリ制御モジュールを提供する段階を更に含むことを特徴とする、上記請求項２３に記載の方法。
【請求項３８】
前記ネットワークプロトコルレイヤーモジュールと、前記データハンドラモジュールと、資源制御、システム及びユーザーインターフェースのための前記メモリ制御モジュールとの間を裁定する段階を更に含むことを特徴とする、上記請求項３６に記載の方法。
【請求項３９】
データハンドラモジュールとネットワークプロトコルレイヤーモジュールとを制御する目的でシステム及びユーザー入力を翻訳する段階を更に含むことを特徴とする、上記請求項２３に記載の方法。
【請求項４０】
出力データを表示する段階を更に含むことを特徴とする、上記請求項２３に記載の方法。
【請求項４１】
出力データを表示する前記段階が、ＶＧＡ、テレビ、リキッドクリスタルディスプレー（ＬＣＤ）又はライトエミッティングダイオード（ＬＥＤ）のディスプレー形式の中の一つを制御する段階を更に含むことを特徴とする、上記請求項４０に記載の方法。
【請求項４２】
インターネット信号をリアルタイムで処理し、前記処理されたインターネット信号をアプリケーション製品に送信することによって、前記方法が、インターネット信号とアプリケーション製品との間のインタフェースを実装するために使用されることを特徴とする、上記請求項２３に記載の方法。
【請求項４３】
メモリアクセスを裁定し、ディスプレイデータを提供するために、前記データハンドラモジュールと通信するメモリ制御モジュールを更に含むことを特徴とする、上記請求項１に記載の装置。
【請求項４４】
メモリアクセスを裁定し、ディスプレイデータを提供するために、前記データハンドラモジュールと通信するメモリ制御モジュールを提供する段階を更に含むことを特徴とする、上記請求項２３に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワークプロトコルとデータパケットに関する。本発明は特に、ソフトウェア又はソフトウェア／ハードウェアのインプリメンテーションの時間を消費するオーバーヘッドを用いることなく、パケット受信の間にネットワークプロトコルのデコーディングを行い、パケットデータを処理することに関する。更に、本発明は、データのワンパス構文解析を可能とし、異なるスタックに対するデータパケットのバッファリングを省き、それによってメモリの使用を最小化できるようにする。
【背景技術】
【０００２】
コンピューターネットワークはデータの送受信のために様々な通信プロトコルの規定を必要とする。一般的に、コンピューターネットワークは、互いに通信できるように接続されているコンピューター、プリンター及びその他のコンピューター周辺機器のようなシステム装置から成る。データは、これらの装置間で、通信プロトコル標準を使いネットワークを通して通信されるデータパケットを通して伝送される。今日では、多数の異なるプロトコル標準が用いられている。広く使われているプロトコルには、例えばインターネットプロトコル（ＩＰ）、インターネットワークパケットエクスチェンジ（ＩＰＸ）、順次パケットエクスチェンジ（ＳＰＸ）、伝送制御プロトコル（ＴＣＰ）及びポイントツーポイントプロトコル（ＰＰＰ）等がある。各ネットワーク装置は、プロトコルとプロセスデータを翻訳するハードウェアとソフトウェアの組み合わせを含む。
【０００３】
例えば、コンピューターがローカルエリアネットワーク（ＬＡＮ）システムに連結されているようなところでは、ネットワーク装置はハードウェアを使ってリンクレイヤープロトコルを処理し、ソフトウェアを使ってネットワーク、伝送及び通信プロトコルを処理し、情報データ処理を行う。ネットワーク装置は通常、ハードウェア内で一つのリンクレイヤープロトコルを実行するが、その際、連結されているコンピューターをその特定のＬＡＮプロトコルだけに限定する。例えば、ネットワーク、伝送及び通信プロトコルのような高位のプロトコルは、データハンドラと共に、一度ネットワーク装置ハードウェアを通してシステムメモリへ伝送されると、データを処理するソフトウェアプログラムとして実行される。このインプリメンテーションの有利性は、コンピューターのような多目的装置を異なる様々なネットワーク設定で用いることができ、必要とされる任意のネットワークアプリケーションをサポートすることができるようにすることである。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、このインプリメンテーションを実行すると、そのシステムは、コンピューターのオペレーティングシステム（Ｏ．Ｓ．）及びコンピューターとネットワークのハードウェアと通信する異なるソフトウェアプロトコルとデータハンドラを調整するため、高いプロセッサオーバーヘッド、大量のシステムメモリ、複雑な構成設定を、コンピューターユーザーの部分に必要とすることになる。
【０００５】
処理時間中に必要なこの高いオーバーヘッドは１９９６年１月１６日にシュリエル他に発行された米国特許第５，４８５，４６０号に説明されており、一つの装置上で同一のプロトコルを実行する多重ソフトウェアプロトコルスタックの操作方法を教示している。この形式のインプリメンテーションは、マイクロソフトウインドウズを作動させるディスクオペレーティングシステム（ＤＯＳ）ベースのマシンで用いられている。通常のオペレーションの間は、ハードウェアがトランスポート又はリンクレイヤープロトコルを一度確認すると、結果として生じるデータパケットが、パケットフレームフォーマットを決定し、何れであれ特定のフレームヘッダーを取り除くソフトウェアレイヤーへ伝送される。次にパケットは異なるプロトコルスタックへ送られ、そこで特定のプロトコルに対して評価される。しかし、このパケットは、受容もしくは拒否される前に、幾つかのプロトコルスタックへ伝送されるであろう。ソフトウェアプロトコルスタックで生じるタイムラグのため、オーディオ及びビデオ送信がリアルタイムで処理できなくなり、そのため、再生の前にデータをバッファに入れなければならなくなる。プロトコルを処理するのに必要な処理オーバーヘッドの量は非常に多くて扱いにくく、強力な中央処理装置（ＣＰＵ）と大量のメモリを有するアプリケーションに適合するようにしなければならないのは明白である。
【０００６】
ネットワーク装置の従来型のモデルにはめ込むことのできない消費者製品が市場に参入してきている。これらの製品の例としてはページャー、セルラーフォン、ゲーム機、スマートテレホン及びテレビがある。これらの製品のほとんどが小さなフットプリント、８ビットの制御器、限定された記憶装置を持っているか、又は非常に限定された形状因子を必要とする。このような消費者製品は極度に単純化されており、低コストで消費電力が低くなければならない。先に述べたプロトコルインプリメンテーションは、必要とするハードウェアとプロセッサー出力が大きすぎるので、これらの要求に適合しない。そのような複雑なインプリメンテーションをコスト的に有効な方法で消費者製品に組み入れることは困難である。ネットワークアクセスを、低コスト、低電力の小型の形状因子装置上に簡単に形成できるように単純化できるなら、これらの製品は、インターネットのようなネットワークサービスにアクセスできる。
【課題を解決するための手段】
【０００７】
本発明は、メモリ要求が低く、非常に効率的なプロトコルデコーディングを提供する、低コスト、低電力で簡単に製作できる小型形状因子ネットワークアクセスモジュールを提供する。本発明は、バイトストリーミング法で複数のネットワークプロトコルを同時にデコードし、且つワンパス方式でパケットデータを処理し、それによってシステムメモリと形状因子の要件を低減し、更にソフトウェアＣＰＵオーバーヘッドを取り除くハードウェア統合システムから成る。
【０００８】
本発明の好適実施例は、ネットワークプロトコルレイヤー、データハンドラ、Ｏ．Ｓ．状態マシン及びハードウェアゲートレベルで実行されるメモリマネージャ状態マシンを含む。ネットワークパケットは、物理的トランスポートレベル機構から、ネットワークプロトコルレイヤー状態マシンで受信される。プロトコル状態マシンはＴＣＰ、ＩＰ、ユーザデータグラムプロトコル（ＵＤＰ）、ＰＰＰ、ローソケット等のネットワークプロトコルを同時に、各バイトが受信される度毎にデコードする。各プロトコルハンドラは、中間メモリを必要としないで、ヘッダー情報をパケットから直に構文解析し、解釈し、除去する。結果として生じたデータは、次のプロトコルレイヤー又はデータハンドラへ送信されるが、そのためにデータハンドラは、Ｅメール、グラフィック、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、ジャバ、ハイパーテキストマークアップ言語（ＨＴＭＬ）のようなデータフォーマットをデコードするデータ状態マシンから成る。各データ状態マシンは適切なデータに従って反応し、一つ以上のデータ状態マシンに要求されるデータはどれでも、各状態マシンに同時に提供される。ある特定のデータ状態マシンで一回以上要求されるデータは全て、特定のメモリ位置に、そのデータを明示するポインターと共に配置される（これによりメモリ使用が最小となる）。結果としてのディスプレーデータは、すぐにプリフォーマットされてディスプレー制御器へ送られる。出力ネットワークパケットは全て、データ状態マシンで作り出され、パケットにフォーマットを加え、インフォメーションヘッダー情報を検査合計し、物理的伝送レベル機構経由で結果としてのネットワークパケットを転送するネットワークプロトコル状態マシンを通して送られる。
【０００９】
好適実施例は、ネットワークパケットを処理するために、ＣＰＵとソフトウェアを必ずしも必要とはしないので、システムのコストを著しく低減する。ハードウェアゲートレベルインプリメンテーションは、設計者が、特定のアプリケーションが必要とする機能性を選択し、選定し、それでなお低コストで低電力の小型形状因子を保持することのできる、モジュール式の埋め込み可能な設計を提供する。
【発明を実施するための最良の形態】
【００１０】
図１に関して述べると、本発明は、ネットワークプロトコルレイヤー１０１、データハンドラ１０２、メモリ制御モジュール１０３、オペレーティングシステム（Ｏ．Ｓ．）状態マシンモジュール１０４から成り、これらはそれぞれハードウェアゲートレベルで実行される。ネットワークプロトコルレイヤー１０１は、入信ネットワークパケットをデコードし、発信ネットワークパケットをエンコードする。ネットワークプロトコルレイヤー１０１は、入信ネットワークパケットを同時デコードする異なるネットワークプロトコルスタック（すなわちＰＰＰ、ＴＣＰ、ＩＰ、ＵＤＰ及びローソケット）を表す複数の状態マシンから成る。ゲートレベル論理でプロトコルスタックを実行すれば、ネットワークパケットを、パケットが受信される度毎にリアルタイムでデコードできるようになるので、一時的メモリ保存が必要でなくなる。全パケットヘッダー情報が、状態マシンで除去され、確認されると、その結果のデータがデータハンドラ１０２へ伝送される。データハンドラ１０２は、複数の状態マシンから成り、その各々が特定のデータ形式（すなわちＨＴＴＰ、Ｅメールフォーマット（ポストオフィスプロトコル（ＰＯＰ３）、インターネットメッセージアクセスプロトコル（ＩＭＡＰ４）、シンプルメール伝送プロトコル（ＳＭＴＰ））、グラフィック標準（ジョイントフォトグラフィックエキスパートグループ（ＪＰＥＧ）、グラフィックインターチェンジフォーマット（ＧＩＦ））、ジャバ、ＨＴＭＬ）を処理する。データハンドラをゲートレベルで実行すれば、本発明で、受信されるデータをリアルタイムで同時処理できるようになり、これは特に、データの流れが受信される度にそれを処理するアプリケーション、すなわちジャバ、ＨＴＭＬ、ＰＯＰ３Ｅメール、音声と映像のアプリケーションに適している。一つ以上のデータ状態マシンが要求するいずれのデータも同じ方法で提供される。特定のデータ状態マシンが一回以上要求したデータは何れも、それらを明示するポインタ付きで特定のメモリ位置に配置される。全メモリアクセスは、メモリ制御モジュール１０３を通して裁定される。結果のディスプレーデータは何れも又、メモリ制御モジュール１０３を通して経路指定される。Ｏ．Ｓ．状態マシン１０４は、資源制御、システム、ユーザーインターフェース用の全ての状態マシンの間でアービタとして作動する。ユーザー入力は全てＯ．Ｓ．状態マシンで翻訳され、データハンドラ１０２に送られる。
【００１１】
例えば、ＨＴＭＬフォーマットを翻訳するデータハンドラは巡回冗長検査（ＣＲＣ）計算を使ってＨＴＭＬタグをデコードできる。ＨＴＭＬフォーマットはタグとして知られる文字列を含んでおり、タグはビデオ出力装置で表示されるときにテキストのすぐ後のブロックのフォーマッティングを制御する。これらのタグは、所与のタグに対しＣＲＣ番号を作り、フォーマット命令を可能にするために前記番号を使うことによって、効率良くデコードされる。そのようなデコードアルゴリズムはゲートレベルでの実行に適しており、ＨＴＭＬエンコードされたドキュメントを、今よりも速くビデオ出力装置上に表示できるようにする。
【００１２】
本発明は、ハードウェアゲートレベルで実行されるように述べられているが、これらの機能は、プログラム可能アレイ論理（ＰＡＬｓ）、一般アレイ論理（ＧＡＬｓ）、読み出し専用メモリ（ＲＯｍｓ）及びソフトウェアのような他の様々な方法でも実行できることを、当業者は容易に理解できるであろう。更に、特定のプロトコルとデータ形式が示されているが、本発明のモジュール性はこれら特定のプロトコル又はデータ形式に限定されないことを、当業者は容易に理解できるであろう。
【００１３】
図２では、本発明が高レベルのブロック線図で示されている。この線図は、本発明の全てのインプリメンテーションにおける、各モジュールの操作タスクを示す。Ｏ．Ｓ．状態マシン２０８は、システムの「接着」論理と装置制御インターフェースを含み、他のモジュールの状態マシン間で「交通巡査」として働く。ネットワークプロトコルレイヤー２０７はＴＣＰ／ＩＰ、ＵＤＰ、ローソケット、ＰＰＰプロトコル用の状態マシンを含む。メモリ制御モジュール２０６は、システムとビデオディスプレーメモリを同じメモリ領域に存在させる統合メモリアーキテクチャ（ＵＭＡ）のための論理を含む。ディスプレー制御器２０５は、ＶＧＡ、テレビジョン標準又は他の形式のディスプレーの制御を提供する。このインプリメンテーションでは四つのデータハンドラが用いられる。Ｅメールデータハンドラ２０１は、ＰＯＰ３とＩＭＡＰ４フォーマットを共に翻訳する。ＪＰＥＧとＧＩＦフォーマットをデコードする（商業と電信標準もデコードされる）翻訳プログラム２０２が実行される。ジャバ言語バイトコードを翻訳するジャバマシン２０３も含まれている。ワールドワイドウェブ（ＷＷＷ）ブラウザ２０４は、ＨＴＭＬデコーダ／アクセレレータ、ＨＴＴＰデータハンドラ、統合Ｅメール状態マシンを含んでいる。
【００１４】
例えば、入信するＪＰＥＧイメージパケットは、ＭＯＤＥＭ物理的伝送を想定して、システムを通してトレースされる。その要求は、ユーザーがキーボード３２１をタイプすることにより、所与のＪＰＥＧ画像をダウンロードしたいという希望を示すことで始まる。この入力はキーボードインターフェース３１６で翻訳され、Ｏ．Ｓ．状態マシン３１５へ伝送される。Ｏ．Ｓ．状態マシン３１５は、その入力を処理し、コマンドとしてＨＴＴＰクライアント３１１へ伝送する。ＨＴＴＰクライアントは要求パケットをつくり、それをポートデコーダ３０９を経てＴＣＰレイヤー３０８へ伝送する。ＴＣＰレイヤーは、適切なＴＣＰを頭に付け、それをＩＰレイヤー３０７へ伝送する。ＩＰレイヤーは次に、適切なＩＰヘッダーを頭に付け、そのパケットをＰＰＰレイヤー３０６へ伝送する。ＰＰＰレイヤーは、適切なヘッダーを前に付け、ＦＣＳを追加し、そのデータを物理的伝送インターフェース３０５へ伝送する。物理的伝送インターフェースはデータをビットストリームに直列化し、そのパケットをＭＯＤＥＭユニット３０４へ伝送する。要求がホストサーバーで受信されると、ホストサーバーは要求されたＪＰＥＧ画像をクライアントシステムへ送り返す。データはまずＭＯＤＥＭ３０４で受信され、このデータの存在を物理的伝送インターフェース３０５へ示す。物理的伝送インターフェースは次にＭＯＤＥＭからビット直列データを読み出し、それを並列バイトデータに変換し、データの存在をＰＰＰレイヤー３０６へ示す。ＰＰＰレイヤーは受信されるバイトを読む。ＰＰＰレイヤーは、有効スタートバイトを検知すると、入信バイトの構文解析を開始する。バイトストリームがＰＰＰプロトコルフィールドに達すると、ＰＰＰレイヤーはそれをデコードし、本例では埋め込まれているパケットをＩＰ型のものとしてデコードする。このプロトコルバイトに応答して、ＰＰＰレイヤーがＩＰレイヤー３０７を使用可能にし、ＩＰデータが受信されていることをＩＰレイヤー３０７へ示す。更に受信される全データバイトは、すぐに直接ＩＰレイヤーへ伝送される。ＩＰレイヤーは次に入信データバイトの構文解析を開始する。ＩＰレイヤーはＩＰヘッダープロトコルフィールドに達すると、どの高位プロトコルを使用可能にするか決定する。本例では、ＩＰレイヤーはプロトコルフィールドをＴＣＰ型のものとしてデコードする。この時点で、ＩＰレイヤーはＴＣＰレイヤー３０８を使用可能にし、ＴＣＰデータが受信されていることをＴＣＰレイヤーへ示す。このインジケータが稼働状態になれば、受信されるパケット内の全ての他のデータバイトは、ＩＰレイヤーとＴＣＰレイヤーの両方へ伝送される（ＩＰレイヤーは、検査合計計算を終えるためにデータバイトを必要とする）。ＴＣＰレイヤーは次に、入信データバイトの構文解析を開始する。ＴＣＰレイヤーは、ＴＣＰヘッダー宛先ポートフィールドに達すると、使用可能にするデータハンドラを決定する。本例では、ＰＯＲＴフィールドは、ＨＴＴＰクライアント３１１へデコードする。この時点でＰＯＲＴデコーダはＨＴＴＰクライアントを使用可能にし、ＨＴＴＰ要求データが現在受信されていることをＨＴＴＰクライアントに示す。次にＨＴＴＰクライアントは、受信されたデータバイトの構文解析を始める。ＨＴＴＰクライアントが、そのパケットはＪＰＥＧ型画像であると決定すれば、ＨＴＴＰクライアントはＪＰＥＧデコーダ３１３を使用可能にする。この時点で、全データバイトが今度はＪＰＥＧデコーダに送られる。ＪＰＥＧデコーダは、更なる入信データバイト全てを受信し、それらを順次処理する。結果としてのデコードされた画像は、メモリ制御器３１２を経てディスプレーメモリへ伝送され、ディスプレー装置３２６へ出力するように、ディスプレー制御器３２４で処理される。
【００１５】
図３でも示されているように、様々なレイヤーが、共有のメモリ資源へのアクセスを必要とする。全メモリアクセスは、単一のメモリ制御器によって裁定される。このメモリ制御器は、どのレイヤー又はハンドラが所与のいずれかのサイクルで統合メモリバッファへのアクセスを有するかを決定する。単一のメモリバッファユニット内に全てのシステムとディスプレーメモリバッファが共有されているために本メモリ制御器が必要なのである。統合メモリ制御器３１２は、様々なレイヤーから読み取り要求と書き込み要求を取り出し、固定された優先度重み付けを有する動的回転裁定体系に基づいて要求を裁定する。本アルゴリズムを図３Ａに示す。その図面の構成で、装置Ｄ２  ３０２Ａと装置Ｄ３  ３０３Ａの両方が同時にメモリアクセスを要求すると、アービタ３０７Ａは、最新のメモリアクセスを含んでいない装置にサイクルを与える。アービタ３０７Ａは次に、そのメモリ要求をＡ入力アービタ３０９Ａへ送る。アービタ３０９ＡでのＢ入力がアイドルであれば、次にその要求がアービタ３１０ＡのＢ入力へ送られる。アービタ３１０ＡへのＡ入力がアイドルであれば、その要求は、メモリユニットへ向けて作られる。全ての裁定決定は組み合わせ論理を使って実行され、それにより、他にメモリ要求がなされない場合、いずれの装置に対しても待ち状態を除去する。優先度重み付けは、裁定ツリー構造を構成することにより割当られる。図３Ａでは、装置Ｄ０  ３００Ａと装置Ｄ１  ３０１Ａはそれぞれ、２５％の優先度重み付けを有するが、２５％優先度重み付けとは、全装置が継続的なメモリ使用を要求する場合、全装置各々が時間の裁定２５％を獲得することを意味する。装置Ｄ２  ３０２Ａ、Ｄ３  ３０３Ａ、Ｄ４  ３０４Ａ、Ｄ５  ３０５Ａはそれぞれ、１２．５％の優先度重み付けを有する。メモリ制御器設計は、個々の裁定ユニットそれぞれが同じ論理構造を有することにより単純化される。この体系では、要求する装置の数とそれらの優先度重み付けは、アービタユニットを加えたり配列することによって容易に構成できる。
【００１６】
図４を見ると、本発明が提供するスピードの有利性は、現在使用されている従来型のアーキテクチャよりもかなり高い。図は、各タスクを遂行するために必要な時間を示す。ＨＴＭＬダウンロード４０１、ＨＴＭＬのデコード４０２、ＪＰＥＧダウンロード４０３、ＪＰＥＧのデコード４０４、ＪＡＶＡ（登録商標）ダウンロード４０５、ＪＡＶＡ（登録商標）バイトのデコード４０６、ストリーミングオーディオ４０７を必要とする一連のパケットに関して、これらのタスクに必要な合計時間が、従来型アーキテクチャ４０８と本発明（iレディ構成）４０９について示されている。本発明４０９は、これらのタスクに関して、従来型アーキテクチャ４０８よりもかなり速い。
【００１７】
図５を見ると、この形式のネットワークアクセスに関するアプリケーションの発展過程が示されている。現在、従来型ネットワーククライアントのモデルが使用されており、即ちコンピューター５０１である。ネットワークＰＣ５０２、ハンドヘルド装置５０３、スマートテレホン５０４、セットトップ装置５０５、スマートテレビ５０６の消費者製品のコンセプトは、今現実のものとなりつつある。本発明はこれらの製品に、コスト効率、スペース、スピード、パワー重視のネットワークアクセスを提供する。
【００１８】
図６を見ると、本発明は、テレビ６０２又はラジオチューナー６１１と殆ど同様に作動し、信号（パケット）は遅れることなくすぐに処理され、ディスプレー又はオーディオ出力へ送られる。インターネットチューナー６０８という用語はそのような信号処理装置に類似しているものとして本発明を説明するのに用いられている。インターネットチューナー６０８は、インターネット信号６０９と、スマートテレビ６０４、セットトップ装置６０５、スマートテレホン６０６、ハンドヘルド装置６０７のようなアプリケーション製品との間の、インターフェースとして働く。インターネットチューナー６０８は、テレビ６０２とラジオチューナー６１１が処理するように、リアルタイムでインターネット信号６０９を処理する。
【００１９】
図７はＯ．Ｓ．状態マシン７０１、ネットワークプロトコルレイヤー７０２、メモリ制御７０３、ディスプレー制御器７０４、Ｅメールデータハンドラー７０８、翻訳器７０７、ジャバマシン７０６、ＷＷＷブラウザ７０５を用いる本発明の全インプリメンテーションが、別個の二つのモジュールに分離できることを示している。本発明のモジュラー性によって、データハンドラ７１３（Ｅメールデータハンドラ７１７、翻訳器７１６、ジャバマシン７１５、ＷＷＷブラウザ７１４）のような機能が分離できて、確実なアプリケーションのために高レベルのＲＯＭコードに配置できるようになる。
【００２０】
以下のアプリケーションの例は更に、本発明のモジュール設計の万能性示している。
【００２１】
図８は本発明のネットワークＰＣに展開可能な構成を示す。一つのバリエーションは、Ｏ．Ｓ．状態マシン８０１、ネットワークプロトコルレイヤー８０２、メモリ制御器８０３、ディスプレー制御器８０４、Ｅメールデータハンドラ８０８、翻訳器８０７、ジャバマシン８０６、ＷＷＷブラウザ８０５を含む。これはＥメール８１７、翻訳器８１６、ジャバマシン８１５、ＷＷＷブラウザ８１４コード用のデータハンドラをマイクロプロセッサ８１３上で作動する高レベルのＲＯＭに置き換えることにより、変えることができる。マイクロプロセッサ８１３は、Ｏ．Ｓ．状態マシン８０９を通してネットワーク機能及びディスプレー機能と通信する。第三のバリエーションでは、サードパーティＲＯＭ８２３をコピーしているマイクロプロセッサ８２２が、ネットワークプロトコルレイヤー８１９とＯ．Ｓ．状態マシン８１８から入ってくるデータを翻訳できるようになっている。マイクロプロセッサ８２２は、ディスプレー制御器８２１を通してデータを表示する。
【００２２】
図９では、ハンドヘルド装置が、ネットワークプロトコルレイヤー９０１だけを用いて、それをカスタム伝送機構９０２と現在のマイクロ制御器９０４へインターフェースをとることができる。構成の中にＥメールデータハンドラ９０５を含めることにより、Ｅメール機能を追加することができる。更に本発明のモジュール性を実証すると、ネットワークプロトコルレイヤー９１１とジャバマシン９１０をハンドヘルド装置に追加すれば、ジャバアプレットを処理できる。
【００２３】
図１０を見ると、スマートテレホンは、Ｏ．Ｓ．状態マシン１００１、ネットワークプロトコルレイヤー１００２、メモリ制御１００３、Ｅメールデータハンドラ１００６、ディスプレー制御器１００４を実行することにより、Ｅメールの性能を加えることができる。ディスプレー制御器１００４は、ライトエミッティングダイオード（ＬＥＤ）、リキッドクリスタルディスプレー（ＬＣＤ）又はビッグマップのディスプレーを制御できる。物理的伝送制御１００５は、スマートテレホンの接続要件に応じて選択的に加えることができる。Ｏ．Ｓ．状態マシン１００７、ネットワークプロトコルレイヤー１００８、メモリ制御器１００９は、現在あるマイクロ制御器１０１０を使ってスマートテレホンに加えてもよい。マイクロ制御器１０１０は、サードパーティＥメイルクライアントコード１０１１を使ってＥメール機能を実行する。
【００２４】
最後に図１１を見ると、スマートテレビ、ケーブルボックス、ビデオカセットレコーダ（ＶＣＲｓ）、デジタルビデオディスク（ＤＶＤ）プレーヤ、ゲームマシンは、本発明が提供するネットワークアクセス性を利用すると有益である。Ｏ．Ｓ．状態マシン１１０２、ネットワークプロトコルレイヤー１１０３、メモリ制御器１１０４、ＷＷＷブラウザ１１０７、ジャバマシン１１０６、（選択で）ディスプレー制御器１１０５は、現在ある制御器１１０１にインターフェースされている。制御器１１０１がなければ、ディスプレー制御器１１０５が用いられる。Ｅメール１１１５機能は、本発明にモジュラー性があるので簡単に加えられる。既に述べたように、Ｅメール１１２４、翻訳器１１２３、ジャバマシン１１２２及びＷＷＷブラウザ１１２１コードのためのデータハンドラは、マイクロプロセッサ１１２０上で作動している高レベルＲＯＭ内に随意的に配置される。マイクロプロセッサ１１２０は、Ｏ．Ｓ．状態マシン１１１６を通して、ネットワークとディスプレー機能と通信する。
【００２５】
パケット受信例
図１２は、受信されるネットワークパケットを示す。パケットは、左から右へ示されているような以下の項目を含む。
‐  ＰＰＰヘッダー
‐  ＩＰヘッダー
‐  ＴＣＰヘッダー
‐  ＪＰＥＧデータ
‐  ＰＰＰ  ＦＣＳ（フィールド検査合計）
【００２６】
標識名ＰＰＰ  ＬＡＹＥＲ  ＥＮＡＢＬＥのラインは、有効スタートバイトが検知されると稼働状態に入り、図１３のＰＰＰブロック内で作り出される。このラインが一度高位になると、残りのＰＰＰブロックが稼働状態となる。ＰＰＰヘッダー内には、ＰＰＰパケットがカプセル封入されているプロトコルの形式を表示するフィールドがある。ＰＰＰヘッダーが圧縮されていない場合、これらはバイト４及び５である（スタートバイトＯ×７ｅを計算）。図１２では、これらのバイトは、カプセル封入されたデータはＩＰパケットであることを示す０×００と０×２１である。このフィールドをデコーディングした後、ＰＰＰブロックはＩＰ  ＬＡＹＥＲ  ＥＮＡＢＬＥとＰＰＰ  ＤＡＴＡ  ＦＩＥＬＤの信号を始動するが、これらは共に図１３のＩＰブロックを使用可能とする。ＩＰ  ＬＡＹＥＲ  ＥＮＡＢＬＥラインがＰＰＰプロトコルフィールドからデコードされ、ＰＰＰ  ＤＡＴＡ  ＦＩＥＬＤラインは、入信データバイトストリームがネットワークパケットのデータフィールド部分にあることを示す。ＩＰブロックが使用可能となるためには、これら二つのラインが稼働状態になければならない。ＩＰブロックが一度使用可能となると、入信データバイトの構文解析を開始する。図１２に戻るが、ＰＰＰヘッダーのすぐ後に続くデータはＩＰヘッダーである。ＩＰヘッダー内には、ＩＰパケット内にカプセル封入されたデータの形式を示すフィールドがある。図１２では、このフィールドは、カプセル封入されたデータはＴＣＰパケットであることを示す０×０６で表されている。ＴＣＰ  ＬＡＹＥＲ  ＥＮＡＢＬＥラインは、このフィールドをデコードするＩＰブロックに応答して始動される。ＩＰ  ＤＡＴＡ  ＦＩＥＬＤラインは、ＩＰヘッダープロトコルフィールドとＩＰデータフィールドの開始との間にバイトが幾らか入るので、２、３バイト遅れて稼働状態に入る。ＩＰ  ＤＡＴＡ  ＦＩＥＬＤ信号は、入信データバイトストリームがネットワークパケットのデータフィールド部分内にあることを示す。ＴＣＰ  ＬＡＹＥＲ  ＥＮＡＢＬＥとＩＰ  ＤＡＴＡ  ＦＩＥＬＤのラインは共に、図１３のＴＣＰブロックのために使用可能となるためには、稼働状態になければならない。ＴＣＰブロックが一旦使用可能となると、入信データバイトの構文解析を開始する。図１２に戻るが、ＩＰヘッダーのすぐ後に続くデータはＴＣＰヘッダーである。ＴＣＰヘッダー内には、宛先ポート用の２バイトフィールドがある。このフィールドは、カプセル封入されたデータがどのアプリケーション又はデータハンドラに向けられているかを示す。図１２では、このフィールドはポート０×０００３にデコードする。図１３では、ポート３はＨＴＴＰポートとして表されている。ＴＣＰヘッダー内で宛先ポートフィールドをデコードした後で、ＨＴＴＰ  ＥＮＡＢＬＥラインは始動される。ＴＣＰ  ＤＡＴＡ  ＦＩＥＬＤラインは、宛先ポートフィールドとＴＣＰデータフィールドの開始との間に中間的なバイトが幾らか入るので、２、３バイト遅れて始動される。図１３のＨＴＴＰ／ＰＯＲＴ３ブロックが使用可能となるためには、ＨＴＴＰ  ＥＮＡＢＬＥラインとＴＣＰ  ＤＡＴＡ  ＦＩＥＬＤラインの両方が稼働状態になければならない。一���ＨＴＴＰブロックが使用可能となると、ＨＴＴＰブロックは入信データバイトの構文解析を開始する。ＨＴＴＰブロックがＪＰＥＧヘッダーをデコードすると、図１３のＪＰＥＧデコーダブロックが使用可能となる。一旦ＪＰＥＧデコーダが使用可能になると、入信バイトの処理を開始する。ＪＰＥＧ使用可能ラインは、ＪＰＥＧブロックを使用可能にするために必要なラインだけである。
【００２７】
本発明は、好適実施例を参考にして述べられているが、本発明の精神と範囲から逸脱することなく、他のアプリケーションをこの中で既に述べられたものに代え得ることを、当業者は容易に理解できるであろう。従って、本発明は、以下の請求項によってのみ限定されるべきである。
【図面の簡単な説明】
【００２８】
【図１】本発明によるコアシステムのハイレベルデータの流れ線図である。
【図２】本発明によるシステムのハイレベルのブロック線図である。
【図３】本発明による全体システムインプリメンテーションの機能ブロック線図である。
【図３Ａ】本発明によるＵＭＡメモリ制御器の機能ブロック線図である。
【図４】従来型アーキテクチャと本発明に関しての、データタスク時間要件を示す時間比較チャートである。
【図５】本発明によるアプリケーションの考えられる発展過程を示す。
【図６】本発明によるインターネットチューナーの概念を示す。
【図７】本発明による二つのインプリメンテーションを示す。
【図８】本発明によるネットワークＰＣインプリメンテーションを示す。
【図９】本発明によるハンドヘルド装置インプリメンテーションを示す。
【図１０】本発明によるスマートテレホンインプリメンテーションを示す。
【図１１】本発明によるスマートテレビ、ケーブルボックス、ビデオカセットレコーダー（ＶＣＲ）、デジタルビデオディスク（ＤＶＤ）、ゲームマシンインプリメンテーションを示す。
【図１２】本発明による、受信されたパケットを共有するタイミング線図である。
【図１３】本発明による請求項１２のパケットに関する信号の流れを示すブロック概略線図である。
【図１】
2007133902.tif 000003
【図２】
2007133902.tif 000004
【図３】
2007133902.tif 000005
【図３Ａ】
2007133902.tif 000006
【図４】
2007133902.tif 000007
【図５】
2007133902.tif 000008
【図６】
2007133902.tif 000009
【図７】
2007133902.tif 000010
【図８】
2007133902.tif 000011
【図９】
2007133902.tif 000012
【図１０】
2007133902.tif 000013
【図１１】
2007133902.tif 000014
【図１２】
2007133902.tif 000015
【図１３】
2007133902.tif 000016