JP2004334871A - 可観測性についてｈｄｌイベントを分析するシステムおよび方法 - Google Patents

Abstract

【課題】デジタルシステムのリアルタイム可観測性の状況で、ハードウェア設計のシミュレーション中に発生するハードウェア設計言語（ＨＤＬ）イベントハードウェア記述言語のイベントをサポートする。
【解決手段】 本発明は、ＨＤＬイベントに関する情報を含むデータベースにおいて、可観測性イベントを含む全てのＨＤＬイベントを識別すること、上記識別された可観測性ＨＤＬイベントのそれぞれから、可観測性バス上で観測される、上記識別された可観測性ＨＤＬイベントを引き出す信号に固有の情報を取得すること、および、複数のエントリであって、該エントリはそれぞれ、上記可観測性バス上で観測される上記信号のうちの１つに対応し、上記観測された信号の上記１つに固有の信号情報を含む、複数のエントリを含むデータ構造を作成することを含む。
【選択図】図１

Description

本発明は、可観測性についてＨＤＬイベントを分析するシステムおよび方法に関する。

［関連出願の相互参照］
本出願は、２００３年３月２８日に出願された「A BUS INTERFACE MODULE」という名称の米国特許出願第１０／４０２，０９２号、２００３年３月２８日に出願された「SYSTEM AND METHOD FOR USING A DEBUG BUS AS A CAPTURE BUFFER」という名称の米国特許出願第１０／４０２，６２８号、２００３年３月２８日に出願された「SYSTEM AND METHOD FOR VERIFYING HDL EVENTS」という名称の米国特許出願第１０／４０２，１２２号、２００３年３月２８日に出願された「AN INTEGRATED CIRCUIT」という名称の米国特許出願第１０／４０２，０３４号、２００３年５月１０日に出願された「POST-SILICON TEST COVERAGE VERIFICATION」という名称の米国特許出願第６０／４６９，５７５号、２００３年５月９日に出願された「GENERAL PURPOSE DELAY LOGIC」という名称の米国特許出願第６０／４６９，１６８号に関する。

システム設計の複雑さの増加、この複雑さのために要求される投資金額の増加、および製品サイクルの短縮化は、チップセットについてのポストシリコン設計の検証に対して大きな難問を提示してきた。
このことは、システムが極端に大きくかつ複雑であり得る、ハイエンドのキャッシュ・コヒーレント・共有分散メモリアクセス(cache coherent non-uniform memory access)（「ｃｃＮＵＭＡ」）チップセットに特に当てはまる。
プロセッサによるポストシリコン検証は通常、少なくとも、大量のフルカスタム設計による機能的検証と同程度の電気的検証に的を絞っている。
チップセットは、チップセットが構成されている多数のセルに起因して異なる難問を提示する。
さらに、大きなｃｃＮＵＭＡサーバにおいて、バスの実質的な数(the sheer number of)、内部バス調停、キャッシュ・コヒーレンシ制御、待ち行列調停、待ち行列調停などに起因して、こうしたチップセットのポストシリコン機能検証は、電気的検証に関して、プロセッサが通常消費するよりも大量の資源を消費する。
内部可観測性（プレシリコンの検証では比較的簡単であるが）は、デバッグおよび機能テストの適用範囲に大きな障害をもたらす。

システム検証をいつ終了するかを決定することは、ポストシリコン検証を時間効果的に終了させることに対する第２の大きな障害である。
プレシリコンのシミュレーションベーステストは、労働集約的であることを指向し、かつ、疑似ランダムなテストに著しく依存するが、ポストシリコンテストは歴史的に、正常な調子(behavior)を示唆するシステム動作を観察することによって行われてきた。

ポストシリコン設計検証を行うことは、プレシリコン検証では通常見つけられないバグを露呈させることを容易にする業界標準のやり方である。
発見される通常のポストシリコンのバグは、システムの長期間の動作または実動作速度での動作をした後に明らかになるバグ、ハードウェアおよびファームウェアのインタフェースの不正確なモデリングに起因して生ずるバグ、プレシリコン検出を免れるレジスタ転送言語（「ＲＴＬ」）の誤りから生ずるバグ、ならびに、ＲＴＬからシリコンへの不正確なマッピングから生ずるバグ（合成／物理的バグ）を含む。
システムを働かせてポストシリコンのバグを露呈させるようにするという受け入れられる方法は、オペレーティングシステムおよび最終システムを対象とするソフトウェアアプリケーションを実行すること、システムの種々の部分にストレスをかける特定目的用のソフトウェアテストを作成すること、および、ランダムなシステム動作を生成するソフトウェアテストを実行することを含む。

リアルタイム可観測性（「ＲＴＯ」）は、オンチップまたはオフチップのいずれにおいてもリアルタイムで内部信号を監視し取り込むことができることを言う。
内部信号の可観測性機能は、いくつかのフィールドプログラマブルゲートアレイ（「ＦＰＧＡ」）アーキテクチャおよび特定用途向き集積回路（「ＡＳＩＣ」）で利用可能であるが、可観測性機能は通常、範囲が制限されている。
制限している因子は、シリコン面積、配線の制約、およびＩ／Ｏ制限であった。
さらに、可観測性機能は伝統的に、機能テストではなくデバッグの適用範囲に対して用いられてきた。

内部信号の可観測性能力があってもなくても、ＩＣが設計されると、設計がテストされる必要が存在する。
Ｖｅｒｉｌｏｇ ＨＤＬはハードウェア記述言語（「ＨＤＬ」）である。
ＨＤＬは、デジタルシステム、たとえば、コンピュータまたはコンピュータのコンポーネントを記述するのに用いられる言語である。
デジタルシステムをいくつかのレベルで記述することができる。
たとえば、ＨＤＬは、ＩＣチップ上でのワイヤ、抵抗器、およびトランジスタのレイアウト、すなわち、スイッチレベルで記述することができる。
対照的に、デジタルシステムのロジックゲートおよびフリップフロップ、すなわち、ゲートレベルを記述することができる。
より高いレベルは、レジスタおよびレジスタ間の情報ベクトルの転送を記述する。
これはレジスタ転送レベル（「ＲＴＬ」）と呼ばれる。
Ｖｅｒｉｌｏｇ ＨＤＬはこれらのレベルの全てをサポートする。

Ｖｅｒｉｌｏｇは離散的イベント時間シミュレータである。
当業者には認識されるように、Ｖｅｒｉｌｏｇ ＨＤＬにおいて、手続的ステートメントの実行は、指定されたイベントの発生でトリガーされることができる。
シミュレーション中のイベントの発生のレコードは、（「イベントログファイル」）の（「イベントログ」）として維持される。
ＨＤＬを用いるのは主に、設計が製作に委ねられる前の設計のシミュレーションにおいてである。
いくつかのＨＤＬが存在するが、デジタルシステムのリアルタイム可観測性の状況でＨＤＬイベントをサポートするＨＤＬは知られていない。

一実施形態において、本発明は、ハードウェア設計のシミュレーション中に発生するハードウェア設計言語（「ＨＤＬ」）イベントに関する情報を含むデータベースを処理する方法を対象とする。
方法は、上記データベースにおいて、可観測性イベントを含む全てのＨＤＬイベントを識別すること、上記識別された可観測性ＨＤＬイベントのそれぞれから、可観測性バス上で観測される、上記識別された可観測性ＨＤＬイベントを引き出す信号に固有の情報を取得すること、および、複数のエントリであって、該エントリはそれぞれ、上記可観測性バス上で観測される上記信号のうちの１つに対応し、上記観測された信号の上記１つに固有の信号情報を含む、複数のエントリを含むデータ構造を作成することを含む。

図面において、同様なまたは類似する要素は図面のいくつかの図にわたって同じ参照数字で指定されており、図示する種々の要素は必ずしも一定縮尺で描かれていない。

図１に示すように、一実施形態によれば、デバッグバス１００は、シリアルリングで内部接続された複数のバスセグメント１０２（０）〜１０２（４）を備え、バスがその中に実装されるＩＣ、たとえばＡＳＩＣのコアクロックスピードで動作する。
一実施態様において、デバッグバス１００は８０ビット幅であるが、一般に、デバッグバスの幅は、デバイスピンの制約と一致する。
さらに、示される実施形態は、５つのバスセグメント１０２（０）〜１０２（４）のみを使用するが、論理的で、物理的な適切なパーティショニングを行うのに必要であれば、５つより多いかまたは少ないバスセグメントを実装することができることが理解されるであろう。

各バスセグメント１０２（０）〜１０２（４）はいくつかのアクセスポイント１０４を備え、アクセスポイントにおいて、周辺ロジックからのデータがデバッグバス１００上にマルチプレクスされる(MUXed)。
図３および図４を参照して以下でより詳細に述べられるように、各アクセスポイント１０４は、独自の(proprietary)のＭＵＸ構造を有する標準ロジックブロックを備えており、標準ロジックブロックは、デバッグデータをアクセスポイントに送り込み(drive)、その後、データをデバッグバス１００上に送り込む。

図１に示すように、２つの可観測性ポート１０６、１０８が定義される。
一実施形態において、ポートの１つ、すなわち、ポート１０６は専用デバッグポートである。
他のポート、すなわちポート１０８は機能信号をロードされる。
デバッグバス１００は、これらのポート１０６、１０８の両方を駆動するデバッグデータを含む。
一実施形態において、デバッグポート１０６は、８０個のデータピンに４個のストローブピンを加えたものを有しており、ポート１０６をロジックアナライザ（図示せず）に直接接続することを意図して、１つにまとめられている(pumped)。

先に示したように、デバッグポート１０６は、コアクロックスピードで動作し、シリアルリングでバスセグメント１０２（０）〜１０２（４）に接続するデバッグバス１００から直接に供給される(feed)。
デバッグバス１００は分割され、バスがその中に実装されているＩＣの複数の機能領域のうちの任意の領域について、８０ビットの内部状態データに加えてその領域に対して入出力するパケットを観察することができる。
デバッグバス１００およびポート１０２、１０４の実施態様および動作に関するさらなる詳細は、２００３年３月２８日に出願された、「AN INTEGRATED CIRCUIT」という名称の、同一譲受人に譲渡された、同時係属中の米国特許出願第１０／４０２，０３４号に記載されている。

図２は、図１に示すデバッグバス１００のバスセグメント１０２（０）のより詳細なブロック図である。
図２に示すように、バスセグメント１０２（０）は複数のアクセスポイント１０４を含む。
４つのアクセスポイント１０４のみが示されているが、各バスセグメント１０２（０）〜１０２（４）は、バスセグメントが処理しなければならない信号の数によって必要とされる場合、より多いか、またはより少ないアクセスポイントを備えてもよいことに留意すべきである。

図２に示すように、各アクセスポイント１０４は、ローカルデータ取り入れ部２０２およびローカルデータ取り入れ部と接続された、対応するデバッグバス・インタフェースブロック（「ＤＢＩＢ」）すなわちバスインタフェースモジュール２０４を含む。
各アクセスポイント１０４において、周辺ロジックからの最大８０ビットのデータ（「ｄｂｕｇ＿ｒｅａｄ＿ｂｕｓ」）が、バス２０７に沿うＭＵＸ２０６を介して各アクセスポイントのＤＢＩＢ２０４に供給される。
制御およびステータスレジスタ（「ＣＳＲ」）２０８は、バス２１４を介して、以下でより詳細に述べるであろう目的で、３２ビットＭＵＸ選択信号（「^＊＿ｄｂｇ＿ｌｉｎｋ＿ｃｔｌ」）を、対応するＤＢＩＢ２０４のＭＵＸ２１０、２１２に供給する。

図３は、図２のＤＢＩＢ２０４の１つについてのより詳細なブロック図である。
一実施形態において、デバッグバス１００は、１０ビットの８つのブロックに論理的に分割される。
各ＤＢＩＢ２０４は、これらの１０ビットブロックのチェーンにおいて、直前のＤＢＩＢからの到来するデバッグバスデータ（「ｄｂｇ＿ｃｈａｉｎ＿ｉｎ」）を移動させ、かつ／または複製して、必要があれば、対応するローカルデータ取り入れ部２０２からの到来するデータ（「ｄｂｇ＿ｒｅａｄ＿ｂｕｓ」）用の場所を空けるようにし、新たに環境設定されたデータ（「ｄｂｇ＿ｃｈａｉｎ＿ｏｕｔ」）をチェーンにおける次のＤＢＩＢ２０４に渡すことができる。
一般に、各ＤＢＩＢ２０４は、以下の３つの機能を行う。
すなわち、
（１）ＤＢＩＢは直前のアクセスポイントからデータを伝える(pass on)。
（２）ＤＢＩＢは、１０ビットのデータブロックを直前のアクセスポイントからデバッグバスの他のレンジに移動させ、それによって、より効率のよい帯域幅の利用を可能にする。
（３）ＤＢＩＢは、１０ビットシャンクで周辺ロジックからのデータをマルチプレクス入力する。

先に示したように、データのマルチプレクスを管理可能にするために、デバッグバス１００は、１０ビットの８つのブロックに論理的に分割され、ブロックはそれぞれ、個別に操作されることができる。
さらに、各アクセスポイント１０４は、直前のアクセスポイントからのデータを登録し、対応するＣＳＲ制御信号（「^＊＿ｄｂｇ＿ｌｉｎｋ＿ｃｔｌ」）によって指定された１０ビットブロックにおいて、直前のアクセスポイントからのデータを再構成し、次のアクセスポイントに伝えるべきローカルデータをマルチプレクス入力する。
したがって、^＊＿ｄｂｇ＿ｌｉｎｋ＿ｃｏｎｔｒｏｌ信号はＭＵＸ選択信号として働く。

一実施形態の特徴によれば、機能信号の名前と、可観測性ポート１０６（図１）で機能信号を調べるのに必要とされるＭＵＸ選択環境設定と、可観測性ポート上での機能信号のビットセット位置とを含むＨＤＬイベントが定義される。
「ＥＶＥＮＴ＿ＤＢＧ＿Ｃ」と呼ばれる、こうしたイベントを定義する例示的なイベントマクロが以下に記載される。
「ＥＶＥＮＴ＿ＤＢＧ＿Ｃ」（<ｃｋ>，<ｍｕｘ＿ｓｅｌ>，<ｃｏｎｓｔａｎｔ>，<ｓｉｇｎａｌ＿ｎａｍｅ>，<ｏｆｆｓｅｔ>，<ｓｌｏｔ>，<ｅｖｅｎｔ＿ＩＤ>）；
<ｃｋ> コアクロック
<ｍｕｘ＿ｓｅｌ> <ｓｉｇｎａｌ＿ｎａｍｅ>によって識別される信号をイネーブルするのに必要とされる^＊＿ｄｂｇ＿ｌｉｎｋ＿ｃｔｌのビット。
このフィールドは１〜６４ビットである可能性がある。
このフィールドは変数であろう。
<ｃｏｎｓｔａｎｔ> <ｍｕｘ＿ｓｅｌ>＝<ｃｏｎｓｔａｎｔ>の時、イベントがトリガーされる。
このフィールドもまた１〜６４ビットである。
このフィールドは定数であろう。
ゼロを含む「ｄｏｎ'ｔ ｃａｒｅ」でない全てを含む。
<ｓｉｇｎａｌ＿ｎａｍｅ> デバッグバスへ行く信号（変数）。
ゼロを書き込んではならない。
<ｓｉｇｎａｌ＿ｎａｍｅ>によって識別される信号のフィールドは、（非ゼロ<ｏｆｆｓｅｔ>が指定されなければ）ブロック境界に整列されなければならない。
複数ブロックにまたがる信号はＯＫであるが、ブロックは、隣接していて、同じＭＵＸ選択ビットによってイネーブルされなければならない。
<ｏｆｆｓｅｔ> <ｓｉｇｎａｌ＿ｎａｍｅ>によって識別される信号の１０ビットブロック境界（１０進値０〜９）からのオフセット。
ほとんどの信号は１０ビットブロック境界に割り当てられているべきであり、それゆえこのフィールドにおいて０を有する。
<ｓｌｏｔ> <ｓｉｇｎａｌ＿ｎａｍｅ>によって識別される信号について、どのブロック（複数可）が書き込まれるかを示す８ビットマスク（定数）。
ブロックは隣接していなければならない。
<ｅｖｅｎｔ＿ＩＤ>） イベントＩＤ。
このフィールドは絶対に一意でなければならない。
プレフィックス（たとえば、ｐｉｎ＿ｄｂｇ＿ｂｌｏｃｋ０）としてのブロックの使用が提案される。
イベント マクロ

図４は、一実施形態に従って行われたシミュレーションの実行４００を示す。
図４に示すように、シミュレーションの実行４００中、デバッグバス１００（図１）のＶｅｒｉｌｏｇ ＨＤＬシミュレーション４０２が行われる。
シミュレーション４０２において、信号がデバッグバス上でアクティブであるような状態であるたびに（すなわち、<ｍｕｘ＿ｓｅｌ>＝<ｃｏｎｓｔａｎｔ>の時）、ＥＶＥＮＴ＿ＤＢＵＧ＿Ｃが発生し(fire)、信号名称、配置（すなわち、オフセットとスロット）、およびＭＵＸ選択信号の値を含むイベントの発生がイベントログ４０４に記される。
同時に、信号の値が可観測性ポートログ４０６に記される。

シミュレーションが終了すると、手動でか、または、その目的のために設計されたコンピュータプログラムまたはスクリプト４０８を用いるかのいずれかで、２つのログ４０４、４０６が比較されて、機能信号からのデータが、イベントログ４０４で示される全ての正しい値を有して、正しい位置の可観測性ポート上に現れるかどうかが判断される。
言い換えれば、イベントログ４０４のエントリは、指定された信号が、所定の場所の可観測性ポートに現れたことに対して状態が適切であったことを示す。
したがって、信号は、可観測性ポートログ４０６の対応する場所に現れるはずである。
このことが当てはまらない場合、すなわち、予期された信号が、可観測性ポートログ４０６で示される可観測性ポートに現れない場合、接続性の問題が指摘される可能性がある。

こうして検証されたデータはデータベース４１０に格納される。
図５を参照してより詳細に述べられるであろう一実施形態によれば、分析プログラムまたはスクリプト４１２は、自分自身から環境設定データベース４１４を生成する。
環境設定データベース４１４は、デバッグバス１００を環境設定するのに必要な情報を全て含んでいる。
特に、環境設定データベース４１４は、デバッグバス１００のＭＵＸ２０６、２１０、２１２を環境設定するのに必要なデータを含む。
こうして、各イベント自体を用いて、それ自身のインタフェースが定義される。

図５は、分析プログラム４１２の動作のフローチャートである。
ステップ５００にて、データベース４１０のディレクトリ構造およびファイル型を調べることによって、設計ファイルのファイルリストが生成される。
ステップ５０２にて、プログラム４１２は、列挙されたファイルのそれぞれを開き、各デバッグ可観測性イベントを１次元「イベントアレイ」５０３にコピーする。
ステップ５０２が終了すると、ステップ５０４にて、イベントアレイの各イベントは分析されて、（１）イベントを駆動する信号のリストと、（２）列挙された信号を識別可能にする環境設定ビットと、（３）列挙された信号を識別可能にする環境設定信号と、（４）信号の生成元の設計サブブロック（すなわち、ＡＳＩＣの一部）の名前が取得される。
イベントアレイの全てのビットが、ステップ５０４に述べたように分析されると、ステップ５０６にて、明示的には定義されていない各信号について、その信号のソースファイルまたは任意の参照されたインクルードファイルを調べることによって、信号のサイズが求められる。
同時に、ステップ５０８にて、明示的には定義されていない各環境設定信号について、その信号のソースファイルまたは任意の参照されたインクルードファイルを調べることによって、信号のサイズが求められる。
さらに、システムアドレス可能メモリへのマッピング（図示せず）が、各環境設定信号について取得され、環境設定信号の名前が、対応するシステムアドレス可能メモリのロケーションに変換される。

ステップ５１０にて、（以前のように各イベントではなく）各信号についてエントリが存在するデータ構造５１１が作成される。
データ構造５１１の各エントリには、信号についてのメモリロケーションと値とサブブロックの名前、ならびに信号がそこから取り出される(recovered)イベントから抽出された任意のコメントが含まれる。
ステップ５１２にて、境界／オーバラップテストおよび競合テストなどのデータ完全性チェックが、データ構造５１１のエントリ上で行われる。
ステップ５１４にて、データベース４１４（図４）が書き出される。

図５に示すステップの結果として、環境設定データベース４１４は、デバッグバス１００を環境設定するのに必要なデータの全てを含み、そのデータはテストされ正確であることが検証された。

こうして、本明細書に記載される本発明の実施形態は、ＨＤＬイベントを分析して、ＩＣのリアルタイム可観測性をイネーブルにするデータベースを生成するシステムおよび方法を提供する。
示され、述べられた実施形態は、単に例示的であることが特徴であった。
したがって、添付特許請求項に記載される本発明の範囲から逸脱することなく実施形態において種々の変更および修正が行われるであろうことが容易に理解されるべきである。
たとえば、実施形態はＡＳＩＣを参照して述べられているが、実施形態は、カスタムチップセット、フィールドプログラマブルゲートアレイ（「ＦＰＧＡ」）、プログラマブルロジックデバイス（「ＰＬＤ」）、汎用アレイロジック（「ＧＡＬ」）モジュール、および同様なものなどの他の型のＩＣで実施されてよいことが理解されるであろう。
さらに、本明細書で述べる実施形態は、Ｖｅｒｉｌｏｇ ＨＤＬ以外のＨＤＬを用いて実施することができる。
さらに、実施形態は、デバッグデータを参照して述べられているが、実施形態は、他の型のＨＤＬイベントおよび同様に対応するデータの検証に適用可能であることが認識されるであろう。

したがって、全てのこうした、変更、拡張、変形、修正、追加、削除、組み合わせなどは、本発明の範囲内にあると考えられ、その範囲は、添付特許請求に記載される範囲によってのみ規定される。

一実施形態のデバッグバスのブロック図である。 図１のデバッグバスのバスセグメントのブロック図である。 図２のバスセグメントを実装するために用いられる標準ロジックブロックのブロック図である。 一実施形態に従って行われたシミュレーションの実行を示す図である。 可観測性についてＨＤＬイベントを分析するプログラムの一実施形態の動作のフローチャートである。

符号の説明

１００・・・デバッグバス、
１０２・・・バスセグメント、
１０４・・・アクセスポイント、
１０６，１０８・・・可観測性ポート、
２０４・・・バスインタフェースモジュール、
２０６，２１０，２１２・・・ＭＵＸ、
２０８・・・ステータスレジスタ（ＣＳＲ）、
２１０，２１２・・・ＭＵＸ、
４００・・・シミュレーションの実行、
４０２・・・Ｖｅｒｉｌｏｇ ＨＤＬシミュレーション、
４０６・・・可観測性ポートログ、
４０８・・・スクリプト、
４１２・・・分析プログラム、
４１４・・・環境設定データベース、

Claims (10)

1. ハードウェア設計のシミュレーション（４０２）中に発生するハードウェア設計言語（「ＨＤＬ」）イベントに関する情報を含むデータベース（４１０）を処理する方法であって、
   前記データベース（４１０）において、可観測性イベントを含む全てのＨＤＬイベントを識別すること（５０２）と、
   前記識別された可観測性ＨＤＬイベントのそれぞれから、可観測性バス上で観測される、前記識別された可観測性ＨＤＬイベントを引き出す(drive)信号に固有の情報を取得すること（５０４）と、
   複数のエントリであって、該エントリはそれぞれ、前記可観測性バス上で観測される前記信号のうちの１つに対応し、前記観測された信号の前記１つに固有の信号情報を含む、複数のエントリを含むデータ構造を作成すること（５１１）と
   を含むデータベースを処理する方法。
2. 前記データ構造について完全性チェックを行うこと（５１２）
   をさらに含む請求項１に記載のデータベースを処理する方法。
3. 前記完全性チェックは、
   境界テストおよびオーバラップテスト
   を含む
   請求項２に記載のデータベースを処理する方法。
4. 前記完全性チェックは、
   競合テスト
   を含む
   請求項２に記載のデータベースを処理する方法。
5. 前記データ構造について前記完全性チェックを行なうことに続いて、前記可観測性バスを環境設定するための情報を含む環境設定データベース（４１４）を書き出す(write)こと（５１４）
   をさらに含む請求項２〜４のいずれかに記載のデータベースを処理する方法。
6. 前記信号情報は、
   各信号について、該信号の名前
   を含む
   請求項１〜５のいずれかに記載のデータベースを処理する方法。
7. 前記信号情報は、
   各信号について、該信号を識別可能にする(visible)環境設定ビット
   を含む
   請求項１〜６のいずれかに記載のデータベースを処理する方法。
8. 前記信号情報は、
   各信号について、該信号の生成元の設計サブブロックの名前
   を含む
   請求項１〜７のいずれかに記載のデータベースを処理する方法。
9. 非明示的に定義された各環境設定信号について、
   前記環境設定信号のサイズを求めること（５０８）と、
   前記環境設定信号をシステムがアドレス指定可能なメモリロケーションにマッピングすること（５０８）と
   をさらに含む請求項８に記載のデータベースを処理する方法。
10. 非明示的に定義された各信号について、該信号のサイズを求めること（５０６）
    をさらに含む請求項１〜９のいずれかに記載のデータベースを処理する方法。

Images