(57)【要約】      （修正有）【課題】通信ネットワークのタスクに対してハードウェアによるサポートを提供する。【解決手段】ホストコンピュータ１１と時間起動型通信ネットワーク１３間で通信コントローラ１２を介して交換されるデータフレームを処理するために、通信コントローラ内に置かれたプロセッサ手段２によってデータフレームが、第一のインタフェースＩｆ１を介してアクセス可能なインタフェースデータ記憶手段１４から読み取られ、このデータフレームに含まれるデータが構成テーブルに含まれているパッケージング情報にしたがって処理され、ユーザデータの部分が、インタフェースデータ記憶手段の関連するメモリー範囲またはレジスタ集合内のデータフレーム中にパッケージング情報に定義されているように記憶される。【選択図】図１
2007026435.tif 000002
【特許請求の範囲】
【請求項１】
ホストコンピュータと時間起動型通信ネットワーク間で通信コントローラを介して交換されるデータフレームを処理する方法において、前記方法が、
第一のインタフェース（Ｉｆ１）を介してアクセス可能なインタフェースデータ記憶手段（１４）からデータフレームを読み取るステップと、
前記通信コントローラ中に備えられている少なくとも一つのプロセッサ手段（２、４）中のデータフレームの少なくとも一部を処理するステップであり、前記データフレームに含まれるデータが、構成テーブル（３）に含まれているパッケージング情報にしたがって処理される前記ステップと、
前記インタフェースデータ記憶手段の関連するメモリー範囲またはレジスタ集合内のデータフレームにユーザデータの部分を、前記パッケージング情報に定義されているように記憶するステップと、
を含むことを特徴とする方法。
【請求項２】
構成テーブルにしたがって処理する前記ステップが、データフォーマットを、たとえばホストコンピュータの語長に調整するもしくはバイト順序をホストコンピュータの語長に調整したりするステップおよび／または処理されるデータのデータ範囲もしくはレジスタ集合を調整したりするステップを含む、請求項１に記載の方法。
【請求項３】
ホストコンピュータから発し、また、通信ネットワークに送られるように予定されるデータが、構成テーブルにしたがってホストコンピュータによって記述される少なくとも二つのメモリー領域からのデータを用いてデータフレームに合成される、請求項１または２に記載の方法。
【請求項４】
加えて、データステータスが生成され、前記データステータスが、データが受信される際に通過するチャネルに関する情報と、データが冗長的に送られるかどうかの情報と、メッセージ年齢を含んでいることを特徴とする、請求項１から３のいずれか一項に記載の方法。
【請求項５】
新たに受信されたが有効であると確認されていないデータが、有効なデータを上書き保存しないように防止され、したがって、メモリーまたはレジスタの集合中に存在するデータのメッセージ年齢が適用される、請求項１から４のいずれか一項に記載の方法。
【請求項６】
送られる予定のデータが、構成テーブルにしたがってホストコンピュータによって記述される少なくとも二つのメモリー範囲またはレジスタの集合またはメモリー範囲とレジスタ集合の組み合わせからのデータフレームに合成され、メモリー範囲、または、データフレームが送られた後であるパターン（たとえば、全ビットが「０」であったり「１」であったりするパターン）にセット／リセットされる、請求項１から５のいずれか一項に記載の方法。
【請求項７】
ホストコンピュータと一緒に用いられるメモリー領域および／または通信コントローラと一緒に用いられるメモリー領域に対してデータが読み／書きされる時間が構成テーブル中に定義される、請求項１から６のいずれか一項に記載の方法。
【請求項８】
ホストコンピュータにとってデータが利用可能となるアドレスが構成テーブル中に記憶される、請求項１から７のいずれか一項に記載の方法。
【請求項９】
構成テーブルが、通信コントローラとホストコンピュータ間でのデータ転送中に実行される動作のタイプを記述する、請求項１から８のいずれか一項に記載の方法。
【請求項１０】
冗長データの場合、有効なデータの転送部分は、構成テーブル中に定義されている規定にしたがって選択されて、冗長的に受信されたデータ部分をホストコンピュータにとってたった一回だけ利用可能なものとされる、請求項１から９のいずれか一項に記載の方法。
【請求項１１】
冗長データ部分が等しいかどうかチェックされる、請求項１０に記載の方法。
【請求項１２】
データフレームの処理に属すさまざまなタスクが、通信コントローラ中に備えられている複数の処理手段中で並行に実行される、請求項１から１１のいずれか一項に記載の方法。
【請求項１３】
ホストコンピュータと時間起動型通信ネットワーク間で交換されるデータフレームを処理する通信コントローラ用の処理デバイス（２）であり、前記処理デバイス（２）が、
プロセッサ手段（４）と、
インタフェースデータ記憶手段（１４）にアクセスする第一のインタフェース（Ｉｆ１）と、
を備え、前記プロセッサ手段（４）が、前記構成テーブルに含まれているパッケージング情報にしたがって前記インタフェースデータ記憶手段（１４）から読み取られたデータフレームの少なくとも一部を処理するように、また、前記インタフェースデータ記憶手段の関連するメモリー範囲またはレジスタ集合中に、データフレーム中のユーザデータの部分を前記パッケージング情報に定義されているように記憶するように適用されることを特徴とする、処理デバイス（２）。
【請求項１４】
前記構成テーブルをさらに備える、請求項１３に記載の処理デバイス。
【請求項１５】
パッケージング情報の交換用のホストコンピュータに接続されるように適用される第二のインタフェース（Ｉｆ３）をさらに備える、請求項１３または１４に記載の処理デバイス。
【請求項１６】
時間基準信号などの同期データの交換用の前記通信コントローラのプロトコルプロセッサに接続されるように適用される第三のインタフェース（Ｉｆ２）をさらに備える、請求項１３、１４または１５に記載の処理デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、時間起動型システムにおけるホストコンピュータと時間起動型通信ネットワークとの間で通信コントローラを介して交換されるデータフレームの処理に関する。前記種類の通信コントローラは、ホストコンピュータと時間起動型通信ネットワーク間での通信ネットワークインタフェース（たとえば、ＴＴＰバス）を実現するものである。
【背景技術】
【０００２】
時間起動型通信システム（たとえば、ＴＴＰやＦｌｅｘＲａｙ）は、分散埋め込み式リアルタイムシステムの信頼できる通信ソリューションである。従来のイベント起動型通信システムと比較して時間起動型通信システムで達成可能な高速のおかげで、ここのノードでのデータの取り扱いと処理の分量が一般的に増大する。これによって、データの取り扱いの効率に対して強い要求がされるようになる。
【０００３】
同時に、高安全性関数が、現在多くの応用ドメインで導入されている（たとえば、車両業界におけるＸｂＷ）。これによって、通信ソリューションを簡単に有効であると確認して検証することが必要とされるようになる。
【０００４】
時間起動型プロトコル（ＴＴＰ）は、時間起動型リアルタイムシステムを実現するように設計されている。時間起動型システムにとっては、ＯＳＥＫコンソーシアム（ｈｔｔｐ：／／ｗｗｗ．ｏｓｅｋ−ｖｄｘ．ｏｒｇ）によって定義されているＦＴ−ＣＯＭやＴＴＴｅｃｈＣｏｍｐｕｔｅｒｔｅｃｈｎｉｋ  ＡＧ  ＦＴ＿ＣＯＭプロダクツ実施例などの通信レイヤーを用いることが最新技術となっている。このような通信レイヤーに共通しているのは、これらのレイヤーがホストＣＰＵ上で実行されることであり、このため、アプリケーションソフトウエアは、ホストＣＰＵ上で通信レイヤーと処理時間を共有しなければならないということである。
【０００５】
次の２つのタイプのＦＴ＿ＣＯＭが一般的に用いられている。
【０００６】
・  ＴＴＴｅｃｈ  ＦＴ＿ＣＯＭなどの実行時間を最適化したＦＴ＿ＣＯＭ。このＴＴＴｅｃｈ  ＦＴ＿ＣＯＭは、通信を取り扱うために最適化されたタスクを生成する。処理や通信の要件が変更されれば、この最適化された生成の成果は変わる。
【０００７】
・  テーブル駆動型ＦＴ＿ＣＯＭ。タスクはテーブルに記入することによってコールされて、ライブラリからデータハンドラが起動される。データを取り扱うごとに、関数コールを発行しなければならない。このソリューションの長所は、ライブラリはたった一回認定すればよいことである。
【０００８】
テーブル駆動型ＦＴ＿ＣＯＭはしばしば、認定に要するオーバヘッドが少ないために好まれるが、それは、ライブラリをテーブル駆動型として実現するためにはたった一回だけ認定するだけでよいのに対して、最適化されたＦＴ＿ＣＯＭの場合、完全に認定しなおさなければならないからである。テーブル駆動型方式の場合、ノードのスケジュールが独立したツールによって変更されるとテーブルを再認定する必要がある。
【０００９】
図２を参照してなされる以下の説明は、本開示で用いられるいくつかの表現と用語を明瞭にするためである。一つの通信チャネルを介してＴＤＭＡスロット（図２ではＴＳｎで示される）中で送信／受信されるデータはデータフレームまたは単にフレームと呼ばれる。それぞれチャネルＣｈ０とＣｈ１を介して送られる二つのフレームＦ０とＦ１を、図２の上部に示す。論理的な観点からすれば、フレームは任意の数のメッセージ（大文字でＡからＧで示す）からなっており、これらのメッセージはメッセージボックス（ＭｓｇＢｏｘ１からＭｓｇＢｏｘ６と示す）と分類される。メッセージボックスのすべてのメッセージが独立したコンテンツを有しているが、共通したメッセージボックスステータス（ＭＢＳと示す）を共有している。最小のメッセージボックスはたった一つのメッセージから成っている。ＴＴＰコントローラは、ここでもチャネル０とチャネル１と呼ばれる２つの通信チャネルＣｈ０およびＣｈ１を備えている。これらのチャネルは双方とも、同じデータ（冗長メッセージに等しいが、図２では独立した大文字で特定される）および／または独立したメッセージを運搬する。冗長メッセージの意図は、通信プロセスの信頼性を向上させることにある。しかしながら、アプリケーション自身は、同じ情報を二度必要とすることはない。したがって、フレームとバーチャルフレーム（Ｖフレーム）を次のように区別する。Ｖフレームとは双方のチャネル上で一つのタイムスロットで受信された情報をマージしたものであるのに対して、冗長情報はＶフレームにたった一度だけ包含されるものである。図２において、ＶフレームＶＦ２は、二つのフレームＦ０とＦ１に対応するものとして示されている。フレームマージしてＶフレームとするプロセスに対してアンパッキングする（またはアンパックする）という用語を用いる。一方、ソースとしてのＶフィギュアとデータフレームとを発生するような動作に対してはいつでもパッキングする（またはパックする）という用語を用いる。この意味で、「パッキングされたフレーム」という用語はフレームのコンテンツを意味するものとして用い、「アンパックされたフレーム」とはＶフレームのコンテンツを意味するものとして用いる。さらに、この用語の使い方によって、フレームとはビットストリームにパックされた情報を包含しており、Ｖフレームとは同じ情報を構造化して（さらに冗長性なく）包含したものであることが示唆されるべきである。ここで、フレームステータス（ＦＳ）は、ＳＣＬ（同期化・通信レイヤー）によって受信時に生成され、メッセージボックスステータスはアンパック手順中にハードウエアＦＴ／ＣＯＭによって生成される。したがって、Ｖフレームをパックしてそれぞれのフレームを送信すると、送信者の側にはなんらステータス情報が付加されることはない。アクション時間という表現は、Ｖフレーム／フレームがハードウエアＦＴ／ＣＯＭによって処理されるはずの時点を意味するために用いられる。
【００１０】
さらに、本開示では次の略字が用いられる。
【００１１】
Ｃ−ＭＥＤＬ。ＣＯＭレイヤー記述リストであり、ＨＦＴＬ構成を含むメモリーブロック
ＣＮＩ。通信ネットワークインタフェースであり、二つのレイヤーＨＬとＳＣＬ間でのデータ交換のためのインタフェースデータ記憶手段を実現するメモリーブロック
ＨＬ。ホストレイヤーであり、ホストコンピュータ上で走行するアプリケーションレイヤー
ＨＩＬ。ホストインタフェースレイヤーであり、ホストコンピュータとＨＩＬの下方で接続された設計との間でデータを交換するために用いられる。これは、ホストタイミングとＨＩＬの下方で接続された設計の双方をサポートすることになっている。
【００１２】
ＨＦＴＬ。ハードウエア故障許容レイヤーであり、元来はソフトウエアとして実現された、冗長性の取り扱いなどの低レベルのタスクにハードウエアサポートを提供する通信ノードをホストＣＰＵから外したりメッセージをパック／アンパックしたりするために用いられる。
【００１３】
ＳＣＬ。同期化・通信レイヤーであり、ＳＣＬは同期化メッセージスケジュールである。
【００１４】
時間起動型システムはさらに、１９９７年にＫｌｕｗｅｒ  Ａｃａｄｅｍｉｃ出版のＨ．Ｋｏｐｅｔｚによる「リアルタイムシステム。分散埋め込み式アプリケーションの設計原理」中に記載されている。本発明の目的については、この本の特に第１．５．５、２．１．２、２．１．３、４．４．２、８．１．２節を参照。
【００１５】
すでに述べたように、ＦＴ−ＣＯＭの先行技術実施例では、ホストコンピュータのところにあるソフトウエアに完全な機能性が提供されている。これによって、ホストのところでかなりの処理時間のオーバヘッドが発生する。そのうえ、フレームバッファの前にあるフレームからのＣＯＭ−タスクがオーバーライトされ、このため、アプリケーションのタスクが中断されその結果、タスクが切り替えられて処理時間のオーバヘッドが発生する。
【発明の開示】
【発明が解決しようとする課題】
【００１６】
本発明の目的は、先行技術の上記の欠点を克服し、通信ノードのタスクをホストコンピュータがしなくて済みようにして、完全する低レベルのタスクに対してハードウエアによるサポートを提供することにある。
【課題を解決するための手段】
【００１７】
この目的は、ホストコンピュータと時間起動型通信ネットワーク間での通信コントローラを介して交換されるデータフレームを処理する方法であり、前記方法が、
第一のインタフェースを介してアクセス可能なインタフェースデータ記憶手段からデータフレームを読み取る（アクセスする）ステップと、
前記通信コントローラ中に備えられている少なくとも一つのプロセッサ手段中でデータフレームの少なくとも一部を処理するステップであり、前記データフレームに含まれているデータが構成テーブルに含まれているパッケージング情報にしたがって処理される前記ステップと、
前記インタフェースデータ記憶手段の関連メモリー範囲またはレジスタの集合中にデータフレームのユーザデータの部分を、前記パッケージング情報に定義されているように記憶するステップと、
を含む方法によって満足される。
【００１８】
本発明は、ホストとは独立して走行する別個のコプロセッサを装備することによってホストＣＰＵに対する処理要求を軽減するものである。テーブル駆動型ソリューションとは対照的に、ハードウエアモジュールは、動作を時間起動してアクティベートすることによって明示コールを回避する。通信（ＣＯＭ）レイヤーの完全な機能性をハードウエアで実現し、これによってタスクの切り替えと処理時間のオーバヘッドとを避けることが可能である。しかしながら、ＦＴ部分を実現する必要はないが、それはこの部分がＦＴＣＯＭのランタイムの微小な部分しか占めていないからである。
【００１９】
したがって、本発明によって、より効率的なスケジュールが許容され、また、ＣＯＭのオーバヘッドを劇的に減少させることが可能である。これは、データレートが増加し、アーキテクチャがより複雑になり、また、ＣＯＭのオーバヘッドも増加するものと予想される自動車の分野における応用分野のような応用分野においては特に重要である。ＨＷ  ＣＯＭレイヤーを用いることによって、ホストのところにおいてＣＰＵのオーバヘッドの最大で８０％が除去され、アプリケーションのタスクが中断されることを防止する。
【００２０】
本発明のさらなる展開では、構成テーブルによる処理は、データフォーマットを、たとえば、ホストコンピュータの語長に調整するもしくはバイト順序をホストコンピュータの語長に調整したりおよび／または処理されるデータのデータ範囲もしくはレジスタ集合を調整したりすることを含む。
【００２１】
フレームのアンパッキングに関連して、ホストコンピュータから発し、また、通信ネットワークに送られるように予定されるデータは、構成テーブルにしたがってホストコンピュータによって記述される少なくとも二つのメモリー領域からのデータを用いてデータフレームに合成するようにするのが望ましい。変更例では、送られる予定のデータは、構成テーブルにしたがってホストコンピュータによって記述される少なくとも二つのメモリー範囲またはレジスタの集合またはメモリー範囲とレジスタ集合の組み合わせからのデータフレームに合成されるが、このメモリー範囲、または、データフレームが送られた後であるパターン（たとえば、全ビットが「０」であったり「１」であったりするパターン）にセット／リセットされる。
【００２２】
加えて、データステータスが生成されるが、前記データステータスは、データが受信される際に通過するチャネルに関する情報と、データが冗長的に送られるかどうかの情報と、メッセージ年齢を含んでいる。新たに受信されたが有効であると確認されていないデータは、有効なデータを上書き保存しないようにされ、したがって、メモリーまたはレジスタの集合中に存在するデータのメッセージ年齢が適用されるようにするのが望ましい。
【００２３】
さらに、ホストコンピュータと一緒に用いられるメモリー領域および／または通信コントローラと一緒に用いられるメモリー領域に対してデータが読み／書きされる時間を構成テーブル中に定義すると長所となる。
【００２４】
ホストコンピュータにとってデータが利用可能となるアドレスは、構成テーブル中に適切に記憶される。構成テーブルはさらに、通信コントローラとホストコンピュータ間でのデータ転送中に実行される動作のタイプを記述する。
【００２５】
冗長データの場合、有効なデータの転送部分は、構成テーブル中に定義されている規定にしたがって選択して、冗長的に受信されたデータ部分をホストコンピュータにとってたった一回だけ利用可能なものとするようにするのが望ましい。この場合、冗長データ部分は等しいかどうか適切にチェックされる。
【００２６】
本発明の開発においては、データフレームの処理に属すさまざまなタスクが、通信コントローラ中に備えられている複数の処理手段中で並行に実行される。
【００２７】
同様に、本発明の目的は、ホストコンピュータと時間起動型通信ネットワーク間で交換されるデータフレームを処理する通信コントローラ用の処理デバイスによって達成されるが、前記デバイスは、
プロセッサ手段と、
インタフェースデータ記憶手段にアクセスする第一のインタフェースと、
を備え、前記プロセッサ手段が、前記構成テーブルに含まれているパッケージング情報にしたがって前記インタフェースデータ記憶手段から読み取られたデータフレームの少なくとも一部を処理するように、また、前記インタフェースデータ記憶手段の関連するメモリー範囲またはレジスタ集合中に、データフレーム中のユーザデータの部分を前記パッケージング情報に定義されているように記憶するように適用される。
【００２８】
本発明によるこのデバイスの長所を、上記の方法に関連して検討した。処理デバイスは、一つのモジュールもしくはチップとしてまたはコンポーネントを配置することによって実現されることに注意すべきである。
【００２９】
処理デバイスの長所となる開発にはさらに、構成テーブルが含まれる。さらに、パッケージング情報の交換用のホストコンピュータに接続されるように適用される第二のインタフェースおよび／または時間基準信号などの同期データの交換用の前記通信コントローラのプロトコルプロセッサに接続されるように適用される第三のインタフェースが含まれる。
【発明を実施するための最良の形態】
【００３０】
以下に、「ハードウエアＦＴ／ＣＯＭ」（上記の序文で用いたＦＴ−ＣＯＭと混合すべきではない）と呼ばれる本発明による処理デバイスの好ましい実施形態を検討する。この処理デバイスは、ホストコンピュータのＣＰＵに対してコプロセッサとして動作するハードウエア、好ましくはスタンドアロン型コンポーネントとして実現することが可能である。もちろん、本発明はこの特定の実施形態に限られず、当業者は、本発明の範囲と精神を実施する他の多くの方法があることを認識するであろう。
【００３１】
図１に、本発明にしたがって、ハードウエアＦＴ／ＣＯＭデバイス２を装備した、通信コントローラ１２（ＴＴＰコントローラ）を介して通信ネットワーク１３に接続されたホストコンピュータ１１を含んでいる通信ノード１を示す。波動ウエアＦＴ／ＣＯＭデバイス２は、ホスト独立型ＣＯＭレイヤー処理デバイスとして動作してパッケージングサービスを提供し、冗長性を取り扱い、メッセージステータス情報を生成する。図１に示す構造は、ＦＴ／ＣＯＭ機能性をソフトウエアで実現する「従来型の」ＴＴＰノード（Ｈ．Ｋｏｐｅｔｚの上記の本の第８．１．２節の図８．２に示されている）のハードウエア構造からの展開である。ＴＴＰコントローラ１２の更なるコンポーネントとして、ＲＯＭとして実現された関連のＴＴＰ制御データ１２２を持つプロトコルプロセッサ１２１と、バスガーディアン１２３ａおよび１２３ｂとがある。プロトコルプロセッサ１２１はＳＣＬ関数を実現する。ＣＮＩ（インタフェースデータ記憶装置として働く）は、メモリー管理ユニット１５（ＭＭＵ）によってアクセス可能なＲＡＭデバイス１４として実現されている。
【００３２】
ハードウエアＦＴ／ＣＯＭデバイス２の一つの目的は、ホストコンピュータ１１から通信ノードのタスクを取り除いて、ＣＮＩの低レベルタスクに対してハードウエアサポートを提供することにある。
【００３３】
ハードウエアＦＴ／ＣＯＭによってパック／アンパックされるべきデータは、ＭＭＵインタフェースＩｆ１を介してアクセス可能なＣＮＩメモリー１４中に置かれる。さらに、ハードウエアＦＴ／ＣＯＭ２は時間基準とＣ−ＭＥＤＬ記述識別子を獲得し、これで、システム中の他のすべてのコンポーネントと同期して走行することが可能となる。この情報は、ＳＣＬインタフェースＩｆ２を介してＳＣＬによって提供される。
【００３４】
図３に示すように、デバイス２は次の二つのコンポーネントから成っている。
【００３５】
・  パッケージング情報を含んでいるメモリー３、このメモリーは本発明の文脈ではＣ−ＭＥＤＬ（ＣＯＭレイヤーＭＥＤＬの略）と呼ばれる。
【００３６】
・  パッケージングエンジン４
図７を参照すると、図示する実施形態をＣ−ＭＥＤＬで実現したもののサイズは、１０２４ｘ１７ビットである。上位１６ビットはペイロードデータとパリティ保護用の最下位ビットと用に用いられる。メモリー幅とは対照的に、ラインの数、この場合では１０２４本、は結果として得られるハードウエア実施例に対しては取るに足りない影響しか持たず、メモリーのサイズを増加させるには、アドレスバスに対してだけ一ビット追加するだけで足り、残余のハードウエアは不変のままである。
【００３７】
論理的観点からすれば、Ｃ−ＭＥＤＬメモリーは次の四つの部分に区分けしなければならない。
【００３８】
Ｃ−ＭＥＤＬヘッダエリア７１。Ｃ−ＭＥＤＬメモリーの先頭から始まるヘッダーエリア。
【００３９】
Ｃ−ＭＥＤＬ記述エリア７２。個々のクラスタラウンドのパッケージング情報を含んでいるＣ−ＭＥＤＬ記述をアプリケーションに固有の数だけ含んでいる。
【００４０】
データタイプ記述エリア７３。このエリアはデータタイプに関する記述を含んでいる。これらのデータタイプは、個々のメッセージの構造を定義するために用いられる。
【００４１】
公衆データタイプ記述エリア７４。頻繁に用いられるデータタイプはここに記憶しなければならない。
【００４２】
メッセージ構造は互いにまったく異なっているとはいえ、バイト、語、倍長語などの共通して用いられるデータタイプの集合が存在する。配列や構造などのデータタイプは、ポインタによって自身の包含されている要素を参照する。このようなポインタのサイズは限られているため、互いに異なった配列／構造から参照される同じデータタイプは何回か例示化しなければならないという要件がある。このように複数回例示化することを回避するために、公衆データタイプエリアが導入された。構造と配列は、このエリアに対して絶対ポインタによってアドレス指定することが可能である。
【００４３】
本実施形態の文脈では、パッケージング情報はＣ−ＭＥＤＬ記述と呼ばれる。純粋な構造記述以外にも、Ｃ−ＭＥＤＬ記述は、メッセージを処理すべき時点や、ＣＮＩメモリーにおけるそのロケーションなどのさらなるパラメータを含むと長所となる。Ｃ−ＭＥＤＬ２１は、処理デバイス２によって保持され、したがって、ホストコンピュータ１１のＣＰＵには制御されないのが好ましい。パッケージング情報は、初期化フェーズ中にホストによってハードウエアＦＴ／ＣＯＭデバイス２に提供される。追加のホストインタフェースＩｆ３は、その情報の交換のために用いられる。
【００４４】
パッケージング性能を向上させるために、図４に示すように、ハードウエアＦＴ／ＣＯＭを例示化したものをいくつか一つのチップにパックすることが可能である。すべてのハードウエアＦＴ／ＣＯＭ例示化物２−１、２−２、．．．２−ｎが同時並行に動作するが、各々の例示化で処理される単数または複数の（Ｖ）フレームの一部が、Ｃ−ＭＥＤＬ３−１、．．．３−ｎ中に適切に定義することが可能である。
【００４５】
また、図５に示すようにすべてのパッケージングエンジン４−１、．．．４−ｎに対して共通したＣ−ＭＥＤＬ３０を用いて、メモリーのリソースを節約することが可能である。しかしながら、これは、Ｃ−ＭＥＤＬメモリーの帯域幅がすべてのパッケージングエンジンの間で共有され、このため、結果として得られるアーキテクチャのパッケージング性能が損なわれることを暗示するものである。
【００４６】
ここで、二つ以上のパッケージングエンジンが同じＶフレーム／フレーム上で動作する場合には、ＣＮＩメモリー１４に記憶されるデータの首尾一貫性を保障しなければならない。これは、ＣＮＩメモリー中でメッセージボックスを適切に整合することによって達成することが可能である。
【００４７】
ここに検討したハードウエアＦＴ／ＣＯＭの実施形態では、二つの通信チャネルを用いている。一般に、また、三つ以上の通信チャネルが展開される。さらに、再度図１を参照すると、追加のコンポーネント、特にコプロセッサ（図示せず）が、ホストコンピュータ１１と通信コントローラ（ＴＴＰコントローラ）１２１間に存在する。
【００４８】
以下に、パッケージングエンジン４をさらに詳しく説明する。
【００４９】
パッケージングエンジン−内部構造
図６を参照すると、パッケージングエンジン４はステータス・制御ユニット６９と、データＦＩＦＯ６１０、６１２（すなわち、データＦＩＦＯ  Ｆ＝６１０およびデータＦＩＦＯ  ＶＦ＝６１２）ならびにアドレスジェネレータ６２０、６２１、６２２（すなわち、Ａｄｄｒ  Ｇｅｎ  Ｃｈ０＝６２０、Ａｄｄｒ  Ｇｅｎ  Ｃｈ１＝６２１およびＡｄｄｒ  Ｇｅｎ  ＶＦ＝６２２）の集合と、コンパレータ６１ｃと、Ｃ−ＭＥＤＬアクセスコントローラ６３と、アクション時間コントローラ６５と、ビットシフター６６と、メッセージメモリーアクセスコントローラ６７と、セット・リセットユニット６８と、シーケンサ６４から成っている。
【００５０】
シーケンサ６４はパッケージングエンジン４のコアコンポーネントであり、これは、パッケージング情報Ｃ−ＭＥＤＬからフェッチして、フレームをパック／アンパックすることが要求されるすべての制御信号を生成する。アドレスジェネレータは、次にフェッチ／記憶される予定のＣＮＩメモリーアドレスを計算する。この目的のため、これらジェネレータは、シーケンサ６４から各々のメッセージボックスの開始アドレスと長さの情報を獲得する。チャネル１とチャネル０に割り当てられたアドレスジェネレータ６２１、６２０は、共通のデータＦＩＦＯ（＝データＦＩＦＯ  Ｆ）６１０を共有する。共通データＦＩＦＯを共有するということは最適化するということであり、あるアプリケーションの場合、対応するアドレスジェネレータに割り当てられるチャネル０とチャネル１に対して互いに別個の二つのＦＩＦＯを実現することもまた可能である。以下の説明は最適化された実施例に関する。
【００５１】
（ａ）冗長メッセージボックスが何も受信されなかったまたは送信されなかった場合、たった一つのアドレスジェネレータがアクティブとなり、したがって、たった一つのデータＦＩＦＯしか必要とされない。
【００５２】
（ｂ）冗長メッセージボックスが受信された場合、双方のアドレスジェネレータを起動しなければならない。この場合、メッセージメモリーアクセスコントローラは、アドレスジェネレータＣｈ０によってフェッチされたデータ（および関連の制御信号）を、データＦＩＦＯ  Ｖ  Ｆと関連しているデータバスに出力し直す。データＦＩＦＯ  Ｆとは対照的に、データＦＩＦＯ  Ｖ  Ｆは、メッセージメモリーアクセスコントローラによって提供されたデータを記憶することはない。その代わりに、推論的なアンパック手順が比較プロセスと同時並行に開始されるが、このプロセスは、データＦＩＦＯ  Ｆのデータを入力として用いてアンパックされたデータをデータＦＩＦＯ  Ｖ  Ｆに書き込む。こうするための要件として、アドレスジェネレータとデータＦＩＦＯを独立に構成しなければならない。
【００５３】
（ｃ）メッセージボックスが双方のチャネル上で送信された場合、メッセージメモリーアクセスコントローラは、（書き込み）肯定応答が生成される前に二つの書き込み動作を次のように実行する。一回目の書き込み動作に対しては、アドレスジェネレータＣｈ１によって提供されたアドレスを用い、二回目の動作に対しては、アドレスジェネレータＣｈ０のアドレスが用いられる。書き込み動作が双方とも実行された場合にだけ、ＷｒｉｔｅＡｃｋが生成され、これで、アドレスジェネレータは自身のアドレスを増分して、次のデータ語がデータＦＩＦＯ  Ｆによって提供される。
【００５４】
データＦＩＦＯは、ＣＮＩメモリーに記憶されるべきデータやこれからフェッチされたデータを保持する。これは、データＦＩＦＯのデータ流れ方向が構成可能でなければならないことを暗示するものである。メッセージメモリーアクセスコントローラ６７は、ＣＮＩメモリーに対するアクセスを調整するが、実際の必要次第で、ＭＭＵインタフェースＩｆ１の帯域幅は１つのコンポーネントに割り当てられたりすべてのコンポーネントによって共有されたりする。冗長メッセージボックスは、構成されると、コンパレータユニット６１ｃによってビットごとに比較される。冗長性チェックで不合格となると、それはステータス・制御ユニット６９に信号通知される。このユニットは、関連するすべてのステータス情報を含み、ハードウエアＦＴ／ＣＯＭの機能性をセットアップすることを可能とする。Ｃ−ＭＥＤＬアクセスコントローラ５３は、Ｃ−ＭＥＤＬメモリー３に対するアクセスをＨＩＬ（Ｉｆ３）とシーケンサ６４との間で調整する。アクション時間コントローラ６５は、Ｃ−ＭＥＤＬ中に指定されているアクション時間とインタフェースＩｆ２を介してＳＣＬから提供された基準時間を比較して、次のパッケージングプロセスが発生すべき時点を決定する。
【００５５】
パッケージングエンジン−初期化
リセットされると、Ｃ−ＭＥＤＬ０３が空になる／非初期化される。したがって、パッケージングエンジンは自動的に無効にされる。この状態では、ホストＣＰＵはＨＩＬポートＩｆ３を介してＣ−ＭＥＤＬ記述をダウンロードすることが可能である。ダウンロードが完了すると、ホストＣＰＵは、ステータス・制御ユニット６９内の制御レジスタ中の対応するビットをセットすることによってパッケージングエンジンを起動する。このモードでは、ホストＣＰＵはＣ−ＭＥＤメモリーにアクセスすることはない。ハードウエアまたはソフトウエアでリセットされると、このビットはクリアされ、その結果、パッケージングエンジンは自動的に無効にされる。
【００５６】
しかしながら、ホストＣＰＵはいまだ、パッケージングエンジンを再度無効にし、これによって、Ｃ−ＭＥＤＬメモリーに対するフルアクセスを獲得する可能性を有している。Ｃ−ＭＥＤＬと類似して、ハードウエアＦＴ／ＣＯＭの制御レジスタは、ハードウエアＦＴ／ＣＯＭによって初期化しなければならない。
【００５７】
パッケージングシーケンス
パッケージングエンジンはＣ−ＭＥＤＬをアドレス０ｘ００００から読み取りを開始するが、これについては図７を参照のこと。第一のフィールドにはＣ−ＭＥＤＬヘッダー７１が含まれる。シーケンサは、Ｃ−ＭＥＤＬヘッダーに記憶されているＣ−ＭＥＤＬ記述識別子と制御レジスタ中に指定されている識別子とを比較して、選択されたＣ−ＭＥＤＬ記述にジャンプする。
【００５８】
Ｃ−ＭＥＤＬ記述７２で最初に記入されるのはアクション時間であるが、ここで、選択されたクラスタラウンドの第一のフレームが処理されるはずである。この値はシーケンサによってアクション時間コントローラ中にコピーされる。このユニットは、基準時間をシーケンサから提供された値と比較して、双方が一致すれば開始パック信号を生成する。基準値がＣ−ＭＥＤＬ中に指定されているアクション時間より大きければ、致命的エラーが信号通知される。
【００５９】
アクション時間に続いて、メッセージボックスのアドレスが読み取られる。これらの値はアドレスジェネレータ６２０、６２１、６２２に記憶される。その後に、第一のメッセージボックス記述が続く。メッセージボックス制御フィールドをシーケンサ６４が評価して、パッケージングエンジンをセットアップする。
【００６０】
ここで、上記のタスクが指定されたアクション時間とは無関係に発生することがありえるが、それは、このようなタスクはメッセージデータをなんら操作しないからである。この時点で、パッケージングエンジンは、アクション時間コントローラが開始パック信号を起動するまで待つ。
【００６１】
開始パック信号がアクティブになると、パッケージングエンジンのすべてのコンポーネントが起動されて、パッケージング手順が開始される。構成次第で、冗長性チェックが、パッケージング手順に先立って実行される。
【００６２】
ハードウエアＦＴ／ＣＯＭはＣ−ＭＥＤＬを循環的に処理する。これは、クラスタラウンドの最後のメッセージボックスが処理されると、ハードウエアＦＴ／ＣＯＭはＣ−ＭＥＤＬの最初のアドレスにジャンプして、記述されているシーケンスが再度開始されることを意味する。
【図面の簡単な説明】
【００６３】
以下に、本発明を、次のそれぞれの図面を参照してより詳細に説明する。
【図１】本発明による処理モジュールを装備した通信ノードのハードウエア構造を示す図である。
【図２】フレームとＶフレームの構造を示す図である。
【図３】図１に示す処理モジュールの基本的構造を示す図である。
【図４】複数の処理ユニットを有する変更例のアーキテクチャを示す図である。
【図５】共通の構成テーブルを共有する複数の処理ユニットを持つ別の変更例を示す図である。
【図６】図３の処理モジュール中に含まれるパッケージングエンジンの内部構造を示すブロック図である。
【図７】Ｃ−ＭＥＤＬメモリーの区分けを示す図である。
【図１】
2007026435.tif 000003
【図２】
2007026435.tif 000004
【図３】
2007026435.tif 000005
【図４】
2007026435.tif 000006
【図５】
2007026435.tif 000007
【図６】
2007026435.tif 000008
【図７】
2007026435.tif 000009
【手続補正書】
【提出日】平成18年8月18日(2006.8.18)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項１
【補正方法】変更
【補正の内容】
【請求項１】
ホストコンピュータと時間起動型通信ネットワーク間で通信コントローラを介して交換されるデータフレームを処理する方法において、前記方法が、
第一のインタフェース（Ｉｆ１）を介してアクセス可能なインタフェースデータ記憶手段（１４）からデータフレームを読み取るステップと、
好ましくは前記通信コントローラ中に備えられている少なくとも一つのプロセッサ手段（２、４）中のデータフレームの少なくとも一部を処理するステップであり、前記データフレームに含まれるデータが、構成テーブル（３）に含まれているパッケージング情報にしたがって処理される前記ステップと、
前記インタフェースデータ記憶手段の関連するメモリー範囲またはレジスタ集合内のデータフレームにユーザデータの部分を、前記パッケージング情報に定義されているように記憶するステップと、
を含むことを特徴とする方法。
【外国語明細書】
2007026435.tif 000010
2007026435.tif 000011
2007026435.tif 000012
2007026435.tif 000013
2007026435.tif 000014
2007026435.tif 000015
2007026435.tif 000016
2007026435.tif 000017
2007026435.tif 000018
2007026435.tif 000019
2007026435.tif 000020
2007026435.tif 000021
2007026435.tif 000022
2007026435.tif 000023
2007026435.tif 000024
2007026435.tif 000025
2007026435.tif 000026
2007026435.tif 000027
2007026435.tif 000028
2007026435.tif 000029
2007026435.tif 000030