JP2008042773A - デバイス連携システム - Google Patents

Abstract

【課題】ＣＰＵを介在させることなく、データパケット送信時のイーサネットコントローラとセキュリティエンジンの動作を連携させる。
【解決手段】送信および暗号化対象となるパケットデータを準備して、メモリデバイス７に、パケットデータの暗号化要求のステータスの指示書を書き込み、セキュリティエンジン８によりその指示書に沿った暗号化が完了すると、その指示書のステータスを暗号化要求を示すデータから暗号化完了を示すデータに書き換え、このデータ書き換えに基づいて、イーサネットコントローラ９が前記暗号化されたパケットデータの送信を行うようにする。
【選択図】図１

Description

本発明は、特定の処理を行うことが可能なデバイスを複数組み合わせることで、特定アプリケーションを実現するデバイス連携システムに係り、特に複数のデバイスを高速で連携させることを可能とするデバイス連携システムに関するものである。

近年、パソコンやＳｏｃ（システムオンチップ）等のＣＰＵを核として動作するシステムは、データ処理や外部との通信手段を備えるため、多くのデバイスをシステムの一部として搭載している。そしてこれらのデバイスの中には、ＣＰＵがメモリに書き込んだ内容を指示書として参照し、それによってその後の動作を決定しているものもある。このようなデバイスは、通常、処理結果もメモリに書き込むことが多く、ＣＰＵはこの処理結果を示すデータを基にその後の処理を決定している。ネットワークコントローラや、データの暗号化／復号化を行うセキュリティエンジン等は、このようなデバイスに相当する。

しかしながら、ＩＰＳＥＣ（IP Security Protocol）のように、データの暗号化／復号化とネットワーク処理を、一連の処理として実施しなければならないような場合、ＣＰＵは複数のデバイス間において、結果を中継するための役割を担わなければならなくなる。つまり、前段の結果を後段のデバイスが引き継げるよう、ＣＰＵがデータの加工や指示書の作成等の処理を行う必要がある。

通常、ＣＰＵへの処理要求はデバイスからの割込信号によってなされるが、割込処理を行うには、ＣＰＵはそれまでに行っていたタスクの状態を保存し、その後必要な処理が記述されているプログラムをロードし、その後に実際の処理に取り掛かる、といったように、要求された処理を即座に実行することは非常に難しい（例えば、特許文献１では割込の回数を極力少なくしようという試みをしているが、データ受信の度に、最低１回は割込を発生させなくてはならない）。これは結果として、ＣＰＵ負荷の増大と処理速度の低下を引き起こし、システムパフォーマンスを劣化させることとなる。上記で例示したＩＰＳＥＣについて言えば、転送スループットの低下を意味する。
特開２００５−２２２２８１号公報

このような問題を回避する方法として、連携するデバイス同士を特殊なインターフェースで直接接続するといった手法が採られることもある。しかし、これは使用可能なデバイスの選択肢を狭め、結果としてコストの増大につながる上、場合によっては所望する機能が実現できなくなるといった事態も想定される。

本発明の目的は、ＣＰＵを介在させずに、且つ使用可能なデバイスの選択肢を狭めることなく、デバイス同士の連携を実現させて、ＣＰＵ負荷の低減と処理速度の向上を同時に実現可能としたデバイス連携システムを提供することである。

上記目的を達成するために、請求項１にかかる発明のデバイス連携システムは、メモリデバイスと、処理終了時に処理結果を示すデータを前記メモリデバイスの第１のアドレスに書き込む機能を有する第１のデバイスと、前記メモリデバイスの前記第１のアドレスの内容が前記データで書き換えられたことをトリガとして処理を開始する第２のデバイスとを備え、前記第１のデバイスの処理完了に基づき前記第２のデバイスの処理開始が行われるようにしたことを特徴とする。
請求項２にかかる発明は、請求項１に記載のデバイス連携システムにおいて、前記第１のデバイスの処理結果を示す前記データが第１のデータである場合は前記メモリデバイスの前記第１のアドレスの内容が前記データで書き換えられ、第２のデータである場合は書き換えられないようにしたことを特徴とする。
請求項３にかかる発明は、請求項２に記載のデバイス連携システムにおいて、前記第１のデバイスの処理結果を示す前記データが前記第２のデータである場合は、前記第１および第２のデバイス以外のデバイスに対して信号をアサートするようにしたことを特徴とする。
請求項４にかかる発明は、請求項２又は３に記載のデバイス連携システムにおいて、前記第１のデバイスの処理結果を示す前記データが前記第１のデータである場合と前記第２のデータである場合に応じて処理する内容を、外部から設定可能としたことを特徴とする。
請求項５にかかる発明は、請求項２、３又は４に記載のデバイス連携システムにおいて、前記第１のデータは前記第１のデバイスの処理が完了したことを示すデータであり、前記第２のデータは前記第１のデバイスの処理が失敗したことを示すデータであることを特徴とする。

本発明によれば、メモリの内容によって動作を開始し、終了時にはメモリに対して終了データを書きこむ複数のデバイスを、ＣＰＵを介在させることなく高速に連携させることができるという、優れた効果を得ることができる。また、適用対象のデバイスは、メモリの内容によって動作を開始し、終了時にはメモリに対してデータを書き込むデバイスであれば、全てが対象となり、特殊なインターフェースを必要としないので、使用可能なデバイスの選択肢が狭まることはない。

本発明は、前段のデバイスの処理結果判定を、ＣＰＵとは別に用意されたハードウェア（バスブリッジ回路）によって行い、その後、指定されていたアドレスの内容を書き換えることで後段のデバイスヘの指示を自動的に行い、結果としてＣＰＵを介さずにデバイス同士の連携を実現させることにより、ＣＰＵ負荷の低減と処理速度の向上を同時に実現するものである。

以下、図面を参照して本発明の実施例を詳細に説明する。図１は、本発明の１つの実施例のデバイス連携システムの構成を示すブロック図である。図１において、ＣＰＵ１、プログラムを格納するＲＯＭ３、ＣＰＵ１への割込信号を制御する割込コントローラ４、暗号化／復号化を行うセキュリティエンジン８、イーサネットコントローラ９、そしてメモリへのアクセス状態を監視するバスブリッジ回路５は、システムバス２によって接続され、各デバイス間ではお互いに情報を送受信することが可能となっている。

割込コントローラ４には、バスブリッジ回路５、セキュリティエンジン８、イーサネットコントローラ９からの割込信号が接続されており、割込コントローラ４はこれらの信号がアサートされるとＣＰＵ１へ通知する機能を有している。またＣＰＵ１からの指示により、これらの割込信号を個別にマスクすることも可能となっている。

バスブリッジ回路５は、通常、システムバス２経由で送られてくるメモリデバイス７へのアクセス要求を、内蔵するリクエストバッファ１１で受信し、そのままメモリコントローラ６経由でメモリデバイス７へ送信する。メモリデバイス７からの応答についても、リクエストバッファ１１はそのままシステムバス２へ送信する。しかし、システムバス２経由でリクエストバッファ１１が受信したアクセス要求が、ＣＰＵ１により設定されたコマンドレジスタ１２上に展開されている条件に合致すると、メモリデバイス７に対して読出し、書込み要求を発行し、メモリデバイス７の内容を一部変更する機能を有している。バスブリッジ回路５のコマンドレジスタ１２の詳細な動作については後述する。

イーサネットコントローラ９は、メモリデバイス７の特定のアドレスに用意された指示書（以降、コマンドディスクリプタと呼ぶ）に従い、メモリデバイス７上のパケットデータを、イーサネット１０へ送信する機能、及びイーサネット１０経由で受信したパケットデータをメモリデバイス７に配置する機能を持つ。送受信が終了すると、結果はメモリデバイス７の特定のアドレスに書き込まれる。

セキュリティエンジン８も、イーサネットコントローラ９と同様、メモリデバイス７の特定のアドレスに配置されるコマンドディスクリプタに従い、データの暗号化と復号化を行う機能を有している。処理結果も同様に、メモリデバイス７に書き込まれる。

＜コマンドレジスタの内容＞
さて、バスブリッジ回路５は、前述したようにリクエストバッファ１１とコマンドレジスタ１２を内蔵している。ＣＰＵ１はコマンドレジスタ１２上に、図２に示すようなデータ配列を展開することが可能となっている。以下、図２の各列の内容について説明する。「コマンド」は指示、「アドレスＡ」〜「アドレスＣ」はメモリデバイス７のアドレスを示し、「データＡ」は「アドレスＡ」に書き込まれるデータ、「データＢ」は「アドレスＢ」に書き込まれるデータを示す。

「コマンド」はライトアクセス要求の条件判定を基に、動作する内容を示すもので、「0x00」のときは無効で何も行わない。「0x01」のときは、条件が真の場合（「アドレスＡ」に「データＡ」が書き込まれたとき）に「アドレスＢ」の内容を「データＢ」に書き換え、条件が偽の場合にＣＰＵ１に割込信号をアサートする。このとき、「アドレスＢ」の内容（データＢ）は変化なしである。「0x02」のときは、条件が真の場合（「アドレスＡ」に「データＡ」が書き込まれたとき）に「アドレスＢ」に「アドレスＣ」の内容をコピーし、条件が偽の場合に何も行わない。

「アドレスＡ」はアクセス要求のアドレス値と比較される値、「データＡ」はアクセス要求のライトデータと比較される値、「アドレスＢ」は条件が真の場合に内容が変更される対象のアドレス、「データＢ」は条件が真の場合に「アドレスＢ」に書き込まれる値（コマンド＝「0x01」の場合のみ）、「アドレスＣ」は条件が真の場合に「アドレスＢ」にコピーされる内容を保持しているアドレス（コマンド＝「0x02」の場合のみ）である。

なお、条件判定については、「アドレスＡ」への書込みアクセス要求がなされた際に『「ライトデータ＝データＡ」の場合は真、それ以外は偽』と判定するものとする。但し「データＡ＝0xFFFFFFFF」の場合は特別に、書込みデータはどのような値であっても結果は真になるものとする。

＜イーサネットコントローラのコマンドディスクリプタ＞
イーサネットコントローラ９のコマンドディスクリプタは以下のような仕様になっているものとする（図３、図５、図７、図９）。「ステータス」はコマンド要求の有無、及びコマンドの実行結果を格納するもので、
「0x00000000」→無効で何もしない
「0x00000080」→パケット送信要求
「0x00000081」→パケット送信完了
「0x00000082」→パケット送信失敗
「0x80000080」→パケット受信要求
「0x80000081」→パケット受信完了
「0x80000082」→パケット受信失敗
を示す。「アドレス」は送信もしくは受信するパケットデータの配置アドレスを示し、「データサイズ」はパケットデータサイズを示す。

＜セキュリティエンジンのコマンドディスクリプタ＞
一方、セキュリティエンジン８のコマンドディスクリプタは以下のような仕様になっているものとする（図３、図５、図７、図９）。「ステータス」はコマンド要求の有無、及びコマンドの実行結果を格納するもので、
「0x00000000」→無効で何もしない
「0x0000aO80」→暗号化要求
「0x0000aO81」→暗号化完了
「0x0000a082」→暗号化失敗
「0x0000b080」→復号化要求
「0x0000b081」→復号化完了
「0x0000b082」→復号化失敗
を示す。「ソースアドレス」は暗号化もしくは復号化対象データの配置アドレス、「デスティネーションアドレス」は暗号化もしくは復号化が完了したデータの配置アドレス、「データサイズ」は暗号化もしくは復号化されるデータのデータサイズを示す。

＜送信処理＞
以降、ＩＰＳＥＣ処理を例として、送信処理と受信処理を行う際の手順を説明する。まず、送信処理の場合については、大まかな処理としては以下の手順を踏むこととなる。「ＣＰＵ１による暗号化対象となるパケットデータの準備」→「セキュリティエンジン８によるパケットデータの暗号化」→「イーサネットワークコントローラ９による暗号化されたパケットデータの送信」。

そこで、ＣＰＵ１は以下の手順で設定を行う。まず、パケットデータの準備を行う（図３）。これは、メモリデバイス７のアドレスＲに暗号化対象のパケットデータを配置することで行う。

次に、イーサネットコントローラ９のコマンドディスクリプタの準備を行う（図３）。これは、データサイズを設定し、暗号化されたパケットデータが配置されるアドレスＳを設定することで行う。このとき、送信要求は行わない（アドレスＰに無効を示す「0x00000000」をライトする）。

次に、バスブリッジ回路５のコマンドレジスタ１２に、データ書換機能の条件と動作を設定（図４）する。これは、セキュリティエンジン８の暗号化処理が終了すると、イーサネットコントローラ９がパケット送信を行うよう設定する。具体的には、コマンドを「0x01」として、『アドレスＱに暗号化完了を示す「0x0000aO81」がライトされる』→『アドレスＰにパケット送信要求を示す「0x00000080」をライト』のように設定する。

次に、セキュリティエンジン８のコマンドディスクリプタを準備（図３）する。これは、データサイズ、暗号化対象パケットデータのアドレスＲ、暗号化されたパケットデータを配置するアドレスＳを設定することで行う。そして、その後、暗号化処理を開始する（アドレスＱに暗号化要求を示す「0x0000aO80」をライトする）。

上記の設定が完了すると、セキュリティエンジン８はコマンドディスクリプタの内容を自動的に検知し、暗号化処理を開始する。その後、暗号化処理が完了し、アドレスＳに暗号化されたパケットデータが配置されると、暗号化完了を示す「0x0000a081」がアドレスＱに書き込まれる。なお、暗号化処理が失敗した場合、つまり、アドレスＱに暗号化失敗を示す「0x0000a082」が書き込まれた場合（図示せず）は、バスブリッジ回路５からＣＰＵ１に対して割込信号がアサートされ、ＣＰＵ１は処理が失敗したことを認識することとなる。

上記のように暗号化が完了した際、バスブリッジ回路５はコマンドレジスタ１２に設定された条件が満たされたことを検知する。このためバスブリッジ回路５は、図５に示すように、アドレスＱにアクセス要求どおり暗号化完了を示す「0x0000aO81」を書き込むと同時に、アドレスＰに対してパケット送信要求を示す「0x00000080」を書き込む。この時、バスブリッジ回路５はデータ書換処理が完了したことを意味するために、図６に示す様に、コマンドレジスタ１２の「コマンド」部分を無効を示す「0x00」にクリアする。

すると、今度はイーサネットコントローラ９が送信指示を自動的に検知し、暗号化されたパケットデータ（アドレスＳに配置されている）をイーサネット１０上に送信することとなる。送信完了後、イーサネットコントローラ９はＣＰＵ１に対して送信完了を示す割込通知を行う。

以上の一連の動作により、途中でＣＰＵ１が介在することなく、パケットデータは暗号化され、ネットワークに対して送信されることとなる。

＜受信処理＞
次に受信処理の場合については、大まかな処理としては以下の手順を踏むこととなる。「イーサネットコントローラ９による暗号化されているパケットデータの受信」→「セキュリティエンジン８によるパケットデータの復号化」→「ＣＰＵ１による復号化されたパケットデータの取り込み」

そこで、ＣＰＵ１は以下の手順で設定を行う。まず、セキュリティエンジン８のコマンドディスクリプタを準備（図７）する。これは、復号化対象パケットデータのアドレスＺと、復号されたパケットデータの配置アドレスＹを設定することで行う。データサイズはまだ決定されていないため、未定とする。このとき、復号化要求は行わない（アドレスＸ１に無効を示す「0x00000000」を書き込む）。

次に、バスブリッジ回路５のコマンドレジスタ１２に、データ書換機能の条件と動作を設定（図８）する。これは、イーサネットコントローラ９にパケット受信が終了すると、セキュリティエンジン８の復号化処理が開始されるように設定することで行う。具体的にはコマンドを「0x01」として、『アドレスＷ１にパケット受信完了を示す「0x80000081」が書き込まれる』→『アドレスＸ１に復号化要求を示す「0x0000b080」を書き込む』のように設定する。また、イーサネットコントローラ９がパケットサイズをセットすると、セキュリティエンジン８のデータサイズも同時にセットされるように設定する。具体的な処理は、コマンドを「0x02」として、『アドレスＷ２に何らかの値が書き込まれる』→『アドレスＸ２に、アドレスＷ２の内容をコピーする』となる。

次に、イーサネットコントローラ９のコマンドディスクリプタを準備（図７）する。これは、受信するパケットデータ（暗号化されている）の配置先アドレスＺを設定することで行う。そして、受信処理開始を指示（アドレスＷ１にパケット受信要求を示す「0x80000080」を書き込む）する。

上記の設定が完了すると、イーサネットコントローラ９はコマンドディスクリプタの内容を自動的に検知し、パケット受信処理を開始する。その後パケット受信が完了し、アドレスＺに暗号化されたパケットデータを配置すると、受信したパケットサイズ（ここでは例として「0x100」）を示すデータをアドレスＷ２に書き込むと同時に、完了を意味するデータとして、アドレスＷｌにパケット受信完了を示す「0x80000081」を書き込む。なお、パケット受信処理が失敗した場合、つまリアドレスＷ１にパケット受信失敗を示す「0x80000082」が書き込まれた場合は、バスブリッジからＣＰＵに対して割込信号がアサートされ、ＣＰＵは処理が失敗したことを認識することとなる。

上記のようにパケット受信が完了した際、バスブリッジ回路５はコマンドレジスタ１２に設定された条件が満たされたことを検知する。このためバスブリッジ回路５は、図９に示すように、アドレスＷ１にパケット受信完了を示す「0x80000081」を、アドレスＷ２にデータサイズ「0x100」を書き込むと同時に、アドレスＸ１に対して復号化要求を示す「0x0000bO80」を、アドレスＸ２にアドレスＷ２と同じ値であるデータサイズ「0x100」をそれぞれ書き込む。なお、この時、バスブリッジ回路５はデータ書換処理が完了したことを意味するために、図１０に示す様に、コマンドバッファ１２の「コマンド」部分を無効を示す「0x00」にクリアする。

すると、今度はセキュリティエンジン８が復号化指示を自動的に検知し、暗号化されたパケットデータ（アドレスＺに配置）を復号化し、復号化されたパケットデータをアドレスＹに配置することとなる。この後、セキュリティエンジン８はＣＰＵ１に対して復号化完了を示す割込通知を行い、ＣＰＵ１はそのデータを取り込むこととなる。

以上の一連の動作により、途中でＣＰＵ１を介在させることなく、暗号化されたパケットデータは受信・復号化されることとなる。

＜変形例＞
なお、ここではイーサネットコントローラ９とセキュリティエンジン８の２つのデバイスのみを連携させる場合を例として挙げたが、２番目に起動されたデバイスの処理完了通知によって３番目のデバイス（例えば画像処理エンジン等）を起動させる、といったように、さらに多くのデバイスであっても連携させることは可能となる。

本発明の１つの実施例のデバイス連携システムの構成を示すブロック図である。 バスブリッジ回路に内蔵されるコマンドレジスタに設定される値をマトリックスとして表した説明図である。 パケット送信前のメモリデバイスの内容を模式的に表した説明図である。 パケット送信前のコマンドレジスタの内容を模式的に表した説明図である。 パケット送信後のメモリデバイスの内容を模式的に表した説明図である。 パケット送信後のコマンドレジスタの内容を模式的に表した説明図である。 パケット受信前のメモリデバイスの内容を模式的に表した説明図である。 パケット受信前のコマンドレジスタの内容を模式的に表した説明図である。 パケット受信後のメモリデバイスの内容を模式的に表した説明図である。 パケット受信後のコマンドレジスタの内容を模式的に表した説明図である。

符号の説明

１：ＣＰＵ、２：システムバス、３：ＲＯＭ、４：割込コントローラ、５：バスブリッジ回路、６：メモリコントローラ、７：メモリデバイス、８：セキュリティエンジン、９：イーサネットコントローラ、１０：イーサネット、１１：リクエストバッファ、１２：コマンドレジスタ
Ｐ，Ｗ１：イーサネットコントローラのステータスデータのアドレス
Ｑ，Ｘ１：セキュリティエンジンのステータスデータのアドレス
Ｒ：暗号化対象パケットデータの配置先アドレス
Ｓ：暗号化されたパケットデータの配置先アドレス
Ｗ２：イーサネットコントローラのレングスデータのアドレス
Ｘ２：セキュリティエンジンのレングスデータのアドレス
Ｙ：復号化されたパケットデータの配置先アドレス
Ｚ：復号化対象パケットデータの配置先アドレス

Claims (5)

1. メモリデバイスと、処理終了時に処理結果を示すデータを前記メモリデバイスの第１のアドレスに書き込む機能を有する第１のデバイスと、前記メモリデバイスの前記第１のアドレスの内容が前記データで書き換えられたことをトリガとして処理を開始する第２のデバイスとを備え、前記第１のデバイスの処理完了に基づき前記第２のデバイスの処理開始が行われるようにしたことを特徴とするデバイス連携システム。
2. 請求項１に記載のデバイス連携システムにおいて、
   前記第１のデバイスの処理結果を示す前記データが第１のデータである場合は前記メモリデバイスの前記第１のアドレスの内容が前記データで書き換えられ、第２のデータである場合は書き換えられないようにしたことを特徴とするデバイス連携システム。
3. 請求項２に記載のデバイス連携システムにおいて、
   前記第１のデバイスの処理結果を示す前記データが前記第２のデータである場合は、前記第１および第２のデバイス以外のデバイスに対して信号をアサートするようにしたことを特徴とするデバイス連携システム。
4. 請求項２又は３に記載のデバイス連携システムにおいて、
   前記第１のデバイスの処理結果を示す前記データが前記第１のデータである場合と前記第２のデータである場合に応じて処理する内容を、外部から設定可能としたことを特徴とするデバイス連携システム。
5. 請求項２、３又は４に記載のデバイス連携システムにおいて、
   前記第１のデータは前記第１のデバイスの処理が完了したことを示すデータであり、前記第２のデータは前記第１のデバイスの処理が失敗したことを示すデータであることを特徴とするデバイス連携システム。
   

Images