JPWO2004038620A1 - システム開発方法及びデータ処理システム - Google Patents
システム開発方法及びデータ処理システム Download PDFInfo
- Publication number
- JPWO2004038620A1 JPWO2004038620A1 JP2004546404A JP2004546404A JPWO2004038620A1 JP WO2004038620 A1 JPWO2004038620 A1 JP WO2004038620A1 JP 2004546404 A JP2004546404 A JP 2004546404A JP 2004546404 A JP2004546404 A JP 2004546404A JP WO2004038620 A1 JPWO2004038620 A1 JP WO2004038620A1
- Authority
- JP
- Japan
- Prior art keywords
- bus
- cfg
- transition
- description
- sync
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/32—Circuit design at the digital level
- G06F30/327—Logic synthesis; Behaviour synthesis, e.g. mapping logic, HDL to netlist, high-level language to RTL or netlist
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/32—Circuit design at the digital level
- G06F30/33—Design verification, e.g. functional simulation or model checking
- G06F30/3323—Design verification, e.g. functional simulation or model checking using formal methods, e.g. equivalence checking or property checking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/10—Requirements analysis; Specification techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/51—Source to source
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- General Physics & Mathematics (AREA)
- Evolutionary Computation (AREA)
- Geometry (AREA)
- Software Systems (AREA)
- Stored Programmes (AREA)
- Devices For Executing Special Programs (AREA)
Abstract
並列動作の記述が可能なプログラム言語を用いて複数のデバイスを定義したプログラム記述（１）を入力し、入力したプログラム記述を中間表現に変換し（Ｓ２）、中間表現に対し、実時間制約を満足するパラメータを生成し（Ｓ３）、生成したパラメータに基づいてハードウェア記述言語による回路記述を合成する（Ｓ４）。中間表現は、コンカレントなコントロールフローフラグ、コンカレントなパラメータ付き時間オートマトン等である。前記パラメータ生成に、パラメトリック・モデルチェッキングを行う。プログラム記述は、ｒｕｎメソッドを用いてデバイスの定義を行い、バリア同期を用いてデバイスのクロック同期を定義する。これにより、実時間制約を満たすバス・システムを設計することができる。
Description
本発明は、並列動作を記述できる言語からディジタル回路を開発する方法、更には並列動作を記述できる言語からディジタル回路のハードウェア合成を行うデータ処理システムに関する。
近年、モバイル・コンピューティング環境を実現する上で、システムＬＳＩの果たす役割はその重要性を増している。また、モバイル・コンピューティングでは実時間制約を如何に満たすかが、しばしば問題となる。更に、システムＬＳＩを実装する上で要求性能を満たすよう設計する場合、バス・システムの設計が重要となる。然るに、バス・システムを実時間制約を満たすよう効率良く設計する為の設計手法がシステム・シミュレーションによる方法以外提案されていないのが現状である。システムシミュレーションについて記載された文献の例として下記の特許文献がある。
特許文献１：特開２００２−２７９３３３号公報
特許文献２：特開２０００−０３５８９８号公報
特許文献３：特開平０７−０８４８３２号公報
特許文献１：特開２００２−２７９３３３号公報
特許文献２：特開２０００−０３５８９８号公報
特許文献３：特開平０７−０８４８３２号公報
本発明の目的は、Ｊａｖａ（登録商標）等の並列動作を記述可能なプログラム言語を用いてバス・システム等のハードウェア設計の工数を低減することにある。
本発明の目的は、並列動作を記述可能なプログラム言語とパラメトリック・モデルチェッキングを用いた、実時間制約を満たすバス・システムの新規設計手法を提供することにある。
本発明の別の目的は、モデルチェッキング技術とハードウェア合成技術の融合による新たな設計手法を提供することにある。
本発明のさらに別の目的は、実時間制約を有するバス・システムに対する並列動作記述可能なプログラム言語によるモデル化とパラメトリック・モデルチェックングによる検証、更にはハードウェア合成を実現することにある。
本発明の前記並びにその他の目的と新規な特徴は本明細書の記述及び添付図面から明らかになるであろう。
本願において開示される発明のうち代表的なものの概要を簡単に説明すれば下記の通りである。
すなわち、並列動作の記述が可能なプログラム言語を用いて複数のデバイスを定義したプログラム記述を入力し、入力したプログラム記述を中間表現に変換し、この中間表現に対し、実時間制約を満足するパラメータを生成し、生成したパラメータに基づいてハードウェア記述言語による回路記述を合成する。
上記より、Ｊａｖａ（登録商標）等の並列動作を記述可能なプログラム言語によりバスシステム等に対するモデル化を行って、実時間制約を満たすシステムの設計を行うことができる。これにより、ハードウェア設計の工数低減が可能になる。
本発明の一つの形態として、前記中間表現は、コンカレントなコントロールフローフラグ、コンカレントなパラメータ付き時間オートマトン、又はパラメータ付き時間オートマトンである。
本発明の一つの形態として、前記パラメータ生成に、パラメトリック・モデルチェッキングを行う。モデルチェッキング技術とハードウェア合成技術の融合による新たな設計手法を提供することができる。
本発明の一つの形態として、前記実時間制約はＲＰＣＴＬで与えられる。
本発明の一つの形態として、前記プログラム記述はｒｕｎメソッドを用いてデバイスの定義を行い、バリア同期を用いてデバイスのクロック同期を定義する。
本発明の目的は、並列動作を記述可能なプログラム言語とパラメトリック・モデルチェッキングを用いた、実時間制約を満たすバス・システムの新規設計手法を提供することにある。
本発明の別の目的は、モデルチェッキング技術とハードウェア合成技術の融合による新たな設計手法を提供することにある。
本発明のさらに別の目的は、実時間制約を有するバス・システムに対する並列動作記述可能なプログラム言語によるモデル化とパラメトリック・モデルチェックングによる検証、更にはハードウェア合成を実現することにある。
本発明の前記並びにその他の目的と新規な特徴は本明細書の記述及び添付図面から明らかになるであろう。
本願において開示される発明のうち代表的なものの概要を簡単に説明すれば下記の通りである。
すなわち、並列動作の記述が可能なプログラム言語を用いて複数のデバイスを定義したプログラム記述を入力し、入力したプログラム記述を中間表現に変換し、この中間表現に対し、実時間制約を満足するパラメータを生成し、生成したパラメータに基づいてハードウェア記述言語による回路記述を合成する。
上記より、Ｊａｖａ（登録商標）等の並列動作を記述可能なプログラム言語によりバスシステム等に対するモデル化を行って、実時間制約を満たすシステムの設計を行うことができる。これにより、ハードウェア設計の工数低減が可能になる。
本発明の一つの形態として、前記中間表現は、コンカレントなコントロールフローフラグ、コンカレントなパラメータ付き時間オートマトン、又はパラメータ付き時間オートマトンである。
本発明の一つの形態として、前記パラメータ生成に、パラメトリック・モデルチェッキングを行う。モデルチェッキング技術とハードウェア合成技術の融合による新たな設計手法を提供することができる。
本発明の一つの形態として、前記実時間制約はＲＰＣＴＬで与えられる。
本発明の一つの形態として、前記プログラム記述はｒｕｎメソッドを用いてデバイスの定義を行い、バリア同期を用いてデバイスのクロック同期を定義する。
第１図は本発明に係る設計方法の全体を例示するフローチャートである。
第２図は単一バス・システムのジャバ言語によるモデル化のデザインパターンを例示する説明図である。
第３図はモデル化におけるクロック同期メカニズムとしてバリア同期によるクロック同期メソッドを用いた例を示す説明図である。
第４図はレジスタへの値書込みを実現するモデル化の記述を例示する説明図である。
第５図はバス権獲得を管理するメソッドを例示する説明図である。
第６図は第５図の各メソッドの呼び出し関係を表すコールグラフである。
第７図はバス権獲得メカニズムのジャバ言語記述を例示する説明図である。
第８図は第７図の続きを示すジャバ言語記述の説明図である。
第９図はバス権解放を管理するメソッドの説明図である。
第１０図は第９図の各メソッドの呼び出し関係を表すコールグラフである。
第１１図はバス権解放メカニズムのジャバ言語記述を例示する説明図である。
第１２図はｓｙｎｃ＿ｒｅａｄメソッドのジャバ言語コードの説明図である。
第１３図はｒｕｎ（）でのｓｙｎｃ＿ｒｅａｄメソッド記述例を示す説明図である。
第１４図はｓｙｎｃ＿ｂｕｒｓｔ＿ｒｅａｄのジャバ言語コードを示す説明図である。
第１５図はｅｎｄＢｕｒｓｔＡｃｃｅｓｓのジャバ言語コードを示す説明図である。
第１６図はｆｒｅｅＢｕｒｓｔＢｕｓＬｏｃｋのジャバ言語コードを示す説明図である。
第１７図はｒｕｎ（）でのバーストリードの記述例を示を説明図である。
第１８図はｓｙｎｃ＿ｗｒｉｔｅのジャバ言語コードを示す説明図である。
第１９図はｒｕｎ（）でのｓｙｎｃ＿ｗｒｉｔｅメソッド記述例を示す説明図である。
第２０図はｓｙｎｃ＿ｂｕｒｓｔ＿ｗｒｉｔｅのジャバ言語コードを示す説明図である。
第２１図はｒｕｎ（）でのバーストライトの記述例を示す説明図である。
第２２図はジャバ言語記述による実装例の概略仕様を示す説明図である。
第２３図はコマンドインタフェースに関するｒｕｎ（）ｍｅｔｈｏｄの実装例の一部を示す説明図である。
第２４図は第２３図の実装例の続きを示す説明図である。
第２５図は第２４図の実装例の続きを示す説明図である。
第２６図は第２５図の実装例の続きを示す説明図である。
第２７図はユニファイドメモリに関するｒｕｎ（）ｍｅｔｈｏｄの実装例を示す説明図である。
第２８図はグラフィック描画ユニットに関するｒｕｎ（）ｍｅｔｈｏｄの実装例を示す説明図である。
第２９図は第２８図の実装例の続きを示す説明図である。
第３０図は第２９図の実装例の続きを示す説明図である。
第３１図は第３０図の実装例の続きを示す説明図である。
第３２図は第３１図の実装例の続きを示す説明図である。
第３３図は表示ユニットに関するｒｕｎ（）ｍｅｔｈｏｄの実装例を示す説明図である。
第３４図は第３３図の実装例の続きを示す説明図である。
第３５図は中間表現への変換工程の詳細を全体的に例示する説明図である。
第３６図はＣ−ＣＦＧの形式を例示する説明図である。
第３７図はｓｙｎｃｈｒｏｎｉｚｅｄの扱い（ハード合成用）について示す説明図である。
第３８図はｓｙｎｃｈｒｏｎｉｚｅｄの扱い（パラメトリック・モデルチェッキング用）について示す説明図である。
第３９図はＣｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅの場合のＣＦＧを示す説明図である。
第４０図はＣｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅに関しハード合成用のＣＦＧを例示する説明図である。
第４１図はパラメトリック・モデルチェッキング用のＣＦＧを例示する説明図である。
第４２図はグラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）に関するＣＦＧを例示する説明図である。
第４３図は第４２図のＣＦＧの続を示す説明図である。
第４４図はパラメトリック・モデルチェッキング用のＣＦＧを例示する説明図である。
第４５図は第４５図のＣＦＧの続を示す説明図である。
第４６図は前記表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）に関するＣＦＧを例示する説明図である。
第４７図はパラメトリック・モデルチェッキング用のＣＦＧを例示する説明図である。
第４８図はコマンドインタフェース（Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ）のＣＦＧ、グラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）のＣＦＧ、及び前記表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）のＣＦＧにおける夫々の開始ノードの結合状態を例示する説明図である。
第４９図は固定優先度スケジューラを例示する説明図である。
第５０図はコマンドインタフェース（Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ）のＣＦＧに対する抽象化の様子を順を追って示す最初の説明図である。
第５１図は第５０図の続を示す説明図である。
第５２図は第５１図の続を示す説明図である。
第５３図は第５２図の続を示す説明図である。
第５４図は第５３図の続を示す説明図である。
第５５図は第５４図の続を示す説明図である。
第５６図は第５５図の続を示す説明図である。
第５７図はグラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）のＣＦＧに対する抽象化処理の結果を例示する説明図である。
第５８図は表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）のＣＦＧに対する抽象化処理の結果を例示する説明図である。
第５９図はコマンドインタフェース（Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ）のＣＦＧに対するＴＮＦＡへの変換の様子を順を追って示す説明図である。
第６０図は第５９図の続を示す説明図である。
第６１図は第６０図の続を示す説明図である。
第６２図はグラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）のＣＦＧに対するＴＮＦＡへの変換の様子を順を追って示す説明図である。
第６３図は第６２図の続を示す説明図である。
第６４図は第６３図の続を示す説明図である。
第６５図は第６４図の続を示す説明図である。
第６６図は表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）のＣＦＧに対するＴＮＦＡへの変換の様子を順を追って例示する説明図である。
第６７図は第６６図の続を示す説明図である。
第６８図は第６７図の続を示す説明図である。
第６９図は第６１図、第６４図、第６８図で求めたＴＮＦＡの積ＴＮＦＡの構成例を示す説明図である。
第７０図はパラメータに上限値を与えた時に、積ＴＮＦＡを構成する段階で制約を満たさない遷移枝の削除過程を示す説明図である。
第７１図は第７０図の続を示す説明図である。
第７２図は第７１図の続を示す説明図である。
第７３図は第７２図の続を示す説明図である。
第７４図は第７３図の続を示す説明図である。
第７５図は第７４図の続を示す説明図である。
第７６図は第７５図の続を示す説明図である。
第７７図はＣ−ＴＮＦＡ２ＴＮＦＡでＡｂｓｔｒａｃｔｉｏｎ ｏｆ ＴＮＦＡを適時コールした場合の処理の経過の一部を示す説明図である。
第７８図は第７７図の続を示す説明図である。
第７９図は第７８図の続を示す説明図である。
第８０図は得られたパラメータ条件に対して目的関数を各パラメタ値の合計として、これを最小化するという線形計画問題を解いた結果を例示する説明図である。
第８１図は第８０図の結果に対し、ｋｂ１＝２，ｋｂ２＝１，ｋｂ３＝１の制約を追加して得た解を例示する説明図である。
第８２図は第８１図の結果に対し更にｋｒ１以外のパラメタ変数を１以上という制約を追加して得た解を例示する説明図である。
第８３図はＢａｓｉｃＢｌｏｃｋへの実行サイクルの割り当てを例示する説明図である。
第８４図は固定優先度スケジューラを例示する説明図である。
第８５図は第８４図に示す固定優先度スケジューラの一部を用いて変形した後のＣＦＧを例示する説明図である。
第８６図は変形後のＣｏｍｍａｎｄ ＩｎｔｅｒｆａｃｅのＣＦＧの一部を例示する説明図である。
第８７図は第８６図の続きを示す説明図である。
第８８図は孤立ノードへのＣＦＧの割り当てに関するＣＦＧを例示する説明図である。
第８９図は共有レジスタに関しＣＦＧ生成のためのインライン展開の対象になる記述を例示する説明図である。
第９０図は共有レジスタに関する擬似Ｃ記述を例示する説明図である。
第９１図は第９０図の続を示す説明図である。
第２図は単一バス・システムのジャバ言語によるモデル化のデザインパターンを例示する説明図である。
第３図はモデル化におけるクロック同期メカニズムとしてバリア同期によるクロック同期メソッドを用いた例を示す説明図である。
第４図はレジスタへの値書込みを実現するモデル化の記述を例示する説明図である。
第５図はバス権獲得を管理するメソッドを例示する説明図である。
第６図は第５図の各メソッドの呼び出し関係を表すコールグラフである。
第７図はバス権獲得メカニズムのジャバ言語記述を例示する説明図である。
第８図は第７図の続きを示すジャバ言語記述の説明図である。
第９図はバス権解放を管理するメソッドの説明図である。
第１０図は第９図の各メソッドの呼び出し関係を表すコールグラフである。
第１１図はバス権解放メカニズムのジャバ言語記述を例示する説明図である。
第１２図はｓｙｎｃ＿ｒｅａｄメソッドのジャバ言語コードの説明図である。
第１３図はｒｕｎ（）でのｓｙｎｃ＿ｒｅａｄメソッド記述例を示す説明図である。
第１４図はｓｙｎｃ＿ｂｕｒｓｔ＿ｒｅａｄのジャバ言語コードを示す説明図である。
第１５図はｅｎｄＢｕｒｓｔＡｃｃｅｓｓのジャバ言語コードを示す説明図である。
第１６図はｆｒｅｅＢｕｒｓｔＢｕｓＬｏｃｋのジャバ言語コードを示す説明図である。
第１７図はｒｕｎ（）でのバーストリードの記述例を示を説明図である。
第１８図はｓｙｎｃ＿ｗｒｉｔｅのジャバ言語コードを示す説明図である。
第１９図はｒｕｎ（）でのｓｙｎｃ＿ｗｒｉｔｅメソッド記述例を示す説明図である。
第２０図はｓｙｎｃ＿ｂｕｒｓｔ＿ｗｒｉｔｅのジャバ言語コードを示す説明図である。
第２１図はｒｕｎ（）でのバーストライトの記述例を示す説明図である。
第２２図はジャバ言語記述による実装例の概略仕様を示す説明図である。
第２３図はコマンドインタフェースに関するｒｕｎ（）ｍｅｔｈｏｄの実装例の一部を示す説明図である。
第２４図は第２３図の実装例の続きを示す説明図である。
第２５図は第２４図の実装例の続きを示す説明図である。
第２６図は第２５図の実装例の続きを示す説明図である。
第２７図はユニファイドメモリに関するｒｕｎ（）ｍｅｔｈｏｄの実装例を示す説明図である。
第２８図はグラフィック描画ユニットに関するｒｕｎ（）ｍｅｔｈｏｄの実装例を示す説明図である。
第２９図は第２８図の実装例の続きを示す説明図である。
第３０図は第２９図の実装例の続きを示す説明図である。
第３１図は第３０図の実装例の続きを示す説明図である。
第３２図は第３１図の実装例の続きを示す説明図である。
第３３図は表示ユニットに関するｒｕｎ（）ｍｅｔｈｏｄの実装例を示す説明図である。
第３４図は第３３図の実装例の続きを示す説明図である。
第３５図は中間表現への変換工程の詳細を全体的に例示する説明図である。
第３６図はＣ−ＣＦＧの形式を例示する説明図である。
第３７図はｓｙｎｃｈｒｏｎｉｚｅｄの扱い（ハード合成用）について示す説明図である。
第３８図はｓｙｎｃｈｒｏｎｉｚｅｄの扱い（パラメトリック・モデルチェッキング用）について示す説明図である。
第３９図はＣｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅの場合のＣＦＧを示す説明図である。
第４０図はＣｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅに関しハード合成用のＣＦＧを例示する説明図である。
第４１図はパラメトリック・モデルチェッキング用のＣＦＧを例示する説明図である。
第４２図はグラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）に関するＣＦＧを例示する説明図である。
第４３図は第４２図のＣＦＧの続を示す説明図である。
第４４図はパラメトリック・モデルチェッキング用のＣＦＧを例示する説明図である。
第４５図は第４５図のＣＦＧの続を示す説明図である。
第４６図は前記表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）に関するＣＦＧを例示する説明図である。
第４７図はパラメトリック・モデルチェッキング用のＣＦＧを例示する説明図である。
第４８図はコマンドインタフェース（Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ）のＣＦＧ、グラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）のＣＦＧ、及び前記表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）のＣＦＧにおける夫々の開始ノードの結合状態を例示する説明図である。
第４９図は固定優先度スケジューラを例示する説明図である。
第５０図はコマンドインタフェース（Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ）のＣＦＧに対する抽象化の様子を順を追って示す最初の説明図である。
第５１図は第５０図の続を示す説明図である。
第５２図は第５１図の続を示す説明図である。
第５３図は第５２図の続を示す説明図である。
第５４図は第５３図の続を示す説明図である。
第５５図は第５４図の続を示す説明図である。
第５６図は第５５図の続を示す説明図である。
第５７図はグラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）のＣＦＧに対する抽象化処理の結果を例示する説明図である。
第５８図は表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）のＣＦＧに対する抽象化処理の結果を例示する説明図である。
第５９図はコマンドインタフェース（Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ）のＣＦＧに対するＴＮＦＡへの変換の様子を順を追って示す説明図である。
第６０図は第５９図の続を示す説明図である。
第６１図は第６０図の続を示す説明図である。
第６２図はグラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）のＣＦＧに対するＴＮＦＡへの変換の様子を順を追って示す説明図である。
第６３図は第６２図の続を示す説明図である。
第６４図は第６３図の続を示す説明図である。
第６５図は第６４図の続を示す説明図である。
第６６図は表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）のＣＦＧに対するＴＮＦＡへの変換の様子を順を追って例示する説明図である。
第６７図は第６６図の続を示す説明図である。
第６８図は第６７図の続を示す説明図である。
第６９図は第６１図、第６４図、第６８図で求めたＴＮＦＡの積ＴＮＦＡの構成例を示す説明図である。
第７０図はパラメータに上限値を与えた時に、積ＴＮＦＡを構成する段階で制約を満たさない遷移枝の削除過程を示す説明図である。
第７１図は第７０図の続を示す説明図である。
第７２図は第７１図の続を示す説明図である。
第７３図は第７２図の続を示す説明図である。
第７４図は第７３図の続を示す説明図である。
第７５図は第７４図の続を示す説明図である。
第７６図は第７５図の続を示す説明図である。
第７７図はＣ−ＴＮＦＡ２ＴＮＦＡでＡｂｓｔｒａｃｔｉｏｎ ｏｆ ＴＮＦＡを適時コールした場合の処理の経過の一部を示す説明図である。
第７８図は第７７図の続を示す説明図である。
第７９図は第７８図の続を示す説明図である。
第８０図は得られたパラメータ条件に対して目的関数を各パラメタ値の合計として、これを最小化するという線形計画問題を解いた結果を例示する説明図である。
第８１図は第８０図の結果に対し、ｋｂ１＝２，ｋｂ２＝１，ｋｂ３＝１の制約を追加して得た解を例示する説明図である。
第８２図は第８１図の結果に対し更にｋｒ１以外のパラメタ変数を１以上という制約を追加して得た解を例示する説明図である。
第８３図はＢａｓｉｃＢｌｏｃｋへの実行サイクルの割り当てを例示する説明図である。
第８４図は固定優先度スケジューラを例示する説明図である。
第８５図は第８４図に示す固定優先度スケジューラの一部を用いて変形した後のＣＦＧを例示する説明図である。
第８６図は変形後のＣｏｍｍａｎｄ ＩｎｔｅｒｆａｃｅのＣＦＧの一部を例示する説明図である。
第８７図は第８６図の続きを示す説明図である。
第８８図は孤立ノードへのＣＦＧの割り当てに関するＣＦＧを例示する説明図である。
第８９図は共有レジスタに関しＣＦＧ生成のためのインライン展開の対象になる記述を例示する説明図である。
第９０図は共有レジスタに関する擬似Ｃ記述を例示する説明図である。
第９１図は第９０図の続を示す説明図である。
本発明の一例として、実時間制約を有するバス・システムのＪａｖａ（登録商標）によるモデル化及びパラメトリック・モデルチェッキングによる検証とハードウェア合成について説明する。本明細書ではＪａｖａ（登録商標）を単にジャバ言語とも記す。
《設計方法の全体》
第１図には設計方法の全体が示される。設計対象とされるシステムはジャバ言語による記述（ジャバ言語記述）でモデル化される（Ｓ１）。ジャバ言語記述によるモデル化では、単一バス上のデバイスをジャバ言語のｒｕｎ（）メソッドを用いて記述する。ｒｕｎ（）メソッドはマルチスレッドを構成するスレッドにおいて実行させたいプログラムコードがその（）内に記述される。クロックはバリア同期を用いて実現される。一般的にバリア同期とは複数のモジュールからのデータを受信する場合に同時刻に処理されるべき全てのデータを待つための同期手法として把握することができる。
次いで、Ｓ１で生成されたジャバ言語記述（ジャバコード）１を読み込み、中間表現に変換する（Ｓ２）。ここで、中間表現２は、コンカレントなコントロール・フロー・グラフ（以下、Ｃ−ＣＦＧ）、コンカレントなパラメータ付き時間オートマトン（以下、Ｃ−ＴＮＦＡ）、パラメータ付き時間オートマトン（以下、ＴＮＦＡ）からなる。ＣＦＧ（コントロール・フロー・グラフ）は一般に関数内部において制御の流れを示すグラムを意味する。ＴＮＦＡ（オートマトン）とは、有限の種類の入力を離散的な時刻に受け、過去から現在までに入力された入力の系列を、回路で決まった個数以下のクラスに分類して記憶し、それに基づいて有限の種類の出力を出す回路の論理的なモデルとして把握することができる。
中間表現２として得られたＴＮＦＡとＲＰＣＴＬ（Ｒｅａｌ Ｔｉｍｅ Ｐａｒａｍｅｔｒｉｃ Ｃｏｍｐｕｔａｔｉｏｎ Ｔｒｅｅ Ｌｏｇｉｃ）３で記述された実時間制約を読み込み、パラメトリック・モデル・チェッキングを実行し（Ｓ３）、入力ＲＰＣＴＬ等を満たすパラメータ条件４を導出する。
満足するパラメータ条件がなければ方式変更を行いジャバ言語記述を修正し、満足するパラメータ条件があれが、そのパラメータ条件をサイクル制約として、Ｃ−ＣＦＧを読み込んで高位合成（Ｓ４）によりＨＤＬ（ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）による回路記述５へ変換する。回路記述は例えばＲＴＬ（Ｒｅｇｉｓｔｅｒ Ｔｒａｎｓｆｅｒ Ｌｅｖｅｌ）である。
上記開発方法はそれを実現するためのプログラムをコンピュータ装置で実行することによって行なわれる。ジャバ言語記述からＨＤＬを得る為の開発支援プログラムはディジタル回路の設計支援プログラムとして位置付けることができる。
本設計手法により、単一バスシステムの上流工程でのモデル化、検証が可能となり、かつ実時間制約を満たすハードウェアの設計自動化が可能となる。上流工程での検証が可能なのは、設計対象システムはジャバ言語記述でモデル化され、その記述自身が実行可能にされるからである。
《ジャバ言語によるモデル化に対する制約》
ジャバ言語によるモデル化に際してのジャバ言語記述とバスシステムに対する制約について説明する。単一バス・システムのジャバ言語によるモデル化を目的とするため、ジャバ言語記述に対し、
１）ダイナミック・インスタンシエーションの禁止、
２）ｒｕｎ（）メソッドからのｓｔａｒｔ（）メソッドコールの禁止、
の制約を置く。制約１）はＬＳＩのプロセス変更に関するものであり、ここではハードウェアを扱っている事から、許容可能な制約であると考えられる。また、制約２）はバス・プロトコルの検証を目的とする限りに於いては、直接バス動作に関わる部分のみをモデル化すれば良い為、許容可能な制約であると考えられる。
また、パラメトリック・モデルチェッキング・ツールの制約から、モデルに対して、
３）単一双方向バス・システム、
４）バス権制御は固定優先度
５）バス上の各デバイスは一定周期で処理を終了、の制約を課す。上記制約の緩和は新たな課題として位置付けられる。
《ジャバ言語によるモデル化の為のデザインパターン》
第２図には単一バス・システムのジャバ言語によるモデル化の為のデザインパターンが例示される。単一バス・システムのジャバ言語によるモデル化はＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）で与えられる第２図のデザインパターンに沿って記述される。バス上の各デバイス動作をＤｅｖｉｃｅＩｍｐｌ Ｃｌａｓｓ内のｒｕｎ（）メソッドに実装し、バスを介してアクセスがあるデバイス内レジスタはＲｅｇｉｓｔｅｒ Ｃｌａｓｓ内のａｔｔｒｉｂｕｔｅ（属性）として実装し、バスを介しての同期通信メソッドをＲｅｇｉｓｔｅｒ Ｃｌａｓｓのメソッドとして実装する。また、バスに対応するＢｕｓ Ｃｌａｓｓ、バスのロック管理を行うＢｕｓＣｏｎｔｒｏｌｌｅｒ Ｃｌａｓｓ、及びクロック同期を管理するＣｌｏｃｋ Ｃｏｎｔｒｏｌｌｅｒ Ｃｌａｓｓを実装する。バスのロック管理とはバスアービトレーションの制御を意味する。第２図の標記において、棒線を付した三角記号△は継承を意味し、例えばＤｅｖｉｃｅＩｍｐｌ ＣｌａｓｓはＤｅｖｉｃｅ Ｃｌａｓｓの子クラスであり、ＤｅｖｉｃｅＩｍｐｌ ＣｌａｓｓはＤｅｖｉｃｅ Ｃｌａｓｓのメソッドを使用可能である。記号→はユース（ｕｓｅ）を意味し、例えばＤｅｖｉｃｅ ＣｌａｓｓはＣｌｏｃｋ Ｃｏｎｔｒｏｌｌｅｒ Ｃｌａｓｓのメソッドを利用する。
尚、ジャバ言語コードの再利用性を高めるため、下記方針
１）デバイスの追加・削除（ＤｅｖｉｃｅＩｍｐｌ Ｃｌａｓｓの追加・削除）、
２）デバイス動作の変更（ＤｅｖｉｃｅＩｍｐｌ Ｃｌａｓｓのｒｕｎ（）メソッドの変更）、
３）共有変数の追加・削除（Ｒｅｇｉｓｔｅｒ Ｃｌａｓｓのａｔｔｒｉｂｕｔｅの追加・削除）、
４）バスプロトコルの追加・変更（Ｒｅｇｉｓｔｅｒ Ｃｌａｓｓの同期通信メソッドの追加・変更）、
にて、ジャバ言語コードの変更が可能となるようデザイン・パターンを定義している。
第２図のデザインパターンにおける各クラス（Ｃｌａｓｓ）について説明する。
（１）Ｄｅｖｉｃｅクラス
デバイスに共通の要素をまとめた抽象クラスである。レジスタやバスは複数ある場合でも処理内容自体が異なることはないため、同じクラスオブジェクトを複数生成ことにより複数存在することを表現できるが、デバイスはデバイスごとにその処理内容が異なる。よって、並列動作を行なうためにＴｈｒｅａｄクラスを継承し、Ｃｌｏｃｋ ｃｏｎｔｒｏｌｌｅｒ Ｃｌａｓｓのインスタンス、Ｒｅｇｉｓｔｅｒ Ｃｌａｓｓのインスタンス、Ｂｕｓ Ｃｌａｓｓのインスタンスを表すメンバ変数、各デバイスがアクセス可能な共有レジスタの情報を登録する為のメンバ変数、及び各デバイスがアクセス可能な共有レジスタの情報を登録する為のメソッドといったようなデバイスに共通な要素をまとめたクラスとしてＤｅｖｉｃｅクラスを実装する。
（２）ＤｅｖｉｃｅＩｍｐｌクラス
実際のデバイスにあたるクラスである。デバイスはデバイスごとに処理内容が異なるため、デバイスに必要な要素をまとめたＤｅｖｉｃｅクラスを継承し、その処理内容を記述する。つまり、Ａという処理を行なうＤｅｖｉｃｅＩｍｐｌＡクラス、Ｂという処理を行なうＤｅｖｉｃｅＩｍｐｌＢクラスといったように処理ごとにＤｅｖｉｃｅクラスの実装クラスが存在することになる。
（３）Ｒｅｇｉｓｔｅｒクラス
共有レジスタに対応するクラスである。レジスタの値を表すメンバ変数と、その値をリード／ライトするメソッドから成る。
（４）Ｂｕｓクラス
バスに対応するクラスである。バスが使用中であるか否かの状態を表すメンバ変数、そのバスに繋がっている共有レジスタをあらわすメンバ変数、及び、状態を変更するメソッドから成る。
（５）ＢｕｓＣｏｎｔｒｏｌｌｅｒクラス
バスを介した共有レジスタへのアクセス時のバスロックとバスのロック解放を行なうクラスである。バスのロック・ロック解放はこのクラスに対して依頼する。特に、バスに対して１つデバイスがアクセスを行うとフラグ変数を１に設定するメソッドを含む。このフラグをバスアクセス・フラグとしてメンバ変数として持ち、このメンバ変数により、同一クロック内での複数回のバスロック動作を回避している。
（６）ＣｌｏｃｋＣｏｎｔｒｏｌｌｅｒクラス
クロック管理クラスである。バスシステム上の各デバイスにクロック同期動作を行なわせるために、１クロック分の処理終了の通知を集め、全デバイスの処理終了が認められたら、次のクロックの処理を行なってよいという通知を行うと同時にＢｕｓＣｏｎｔｒｏｌｌｅｒ Ｃｌａｓｓのバスアクセス・フラグを０にリセットする。
《モデル化におけるクロック同期メカニズム》
クロック同期メカニズムについて説明する。第３図に示すバリア同期によるクロック同期メソッドを用いて、クロックを実現する。具体的には、１クロック分の処理終了の通知を集め、全デバイスの処理終了が認められたら、次のクロックの処理を行なってよいという通知を行う。
また、バスのロックが残っていない場合には、Ｂｕｓ Ｃｌａｓｓのバスアクセス・フラグを０にリセットする。尚、クロック遷移はパラメトリック・モデル・チェッキングへの入力に際して、パラメータ化される為、必ずしも１クロック単位であるとは限らない。
このクロック遷移のパラメータ化により、サイクル精度でのモデル化よりも抽象度の高いモデル化を実現する。
レジスタへの値書き込みには１クロックを要する為、それを実現する必要がある。これは、ｃｏｎｓｕｍｅ＿１＿ｃｌｏｃｋメソッド内で、第４図に例示されるＲｅｇｉｓｔｅｒ ＣｌａｓｓのａｓｓｉｇｎＷｒｉｔｅＶａｌｕｅメソッドをコールする事で実現している。
《モデル化におけるバス権獲得メカニズム》
バス権管理の同期メカニズムとして、先ずバス権獲得メカニズムについて説明する。バス権獲得メカニズムは、第５図に示すメソッドにより、バス権獲得を管理する。バス権の要求はｇｅｔＢｕｓＬｏｃｋメソッドにより行う。第６図には第５図の各メソッドの呼び出し関係を表すコールグラフが示される。第７図及び第８図には上記バス権獲得メカニズムのジャバ言語記述が例示される。
《モデル化におけるバス権解放メカニズム》
次にバス権解放メカニズムについて説明する。バス権解放メカニズムは第９図にに示すメソッドにより、バス権解放を管理する。バス権の解放はｆｒｅｅＢｕｓＬｏｃｋメソッドにより行う。第１０図には第９図の各メソッドの呼び出し関係を表すコールグラフが示される。第１１図には上記バス権解放メカニズムのジャバ言語記述が例示される。
《モデル化における排他的同期リード・メソッド》
バスへの排他的同期アクセス方式として、排他的同期リード・メソッドについて説明する。排他的同期リード・メソッドには以下のシングルリードとバーストリードがある。シングルリードはｓｙｎｃ＿ｒｅａｄメソッドをｒｕｎ（）でコールする事で実現される。バーストリードは、ｓｙｎｃ＿ｂｕｒｓｔ＿ｒｅａｄ、ｅｎｄＢｕｒｓｔＡｃｃｅｓｓ、ｃｏｎｓｕｍｅ＿ｃｌｏｃｋメソッドをｒｕｎ（）の、ｓｙｎｃｈｒｏｎｉｚｅｄブロック内で用いる事で実現される。
第１２図にはｓｙｎｃ＿ｒｅａｄメソッドのジャバ言語コード、第１３図にはｒｕｎ（）でのｓｙｎｃ＿ｒｅａｄメソッド記述例が示される。ｒｕｎ（）での記述例に現れる未定義メソッド、即ち、ｄｏ＿ｓｏｍｅｔｈｉｎｇ＿ｗ＿ｏｒ＿ｗｏ＿ｃｌｏｃｋ＿ｂｏｕｎｄａｒｙ（）はクロック境界を含んでもよい何らかの処理を意味し、ｄｏ＿ｓｏｍｅｔｈｉｎｇ＿ｗｏ＿ｃｌｏｃｋ＿ｂｏｕｎｄａｒｙ（）はクロック境界を含まない何らかの処理を意味する。
第１４図にはｓｙｎｃ＿ｂｕｒｓｔ＿ｒｅａｄのジャバ言語コード、第１５図にはｅｎｄＢｕｒｓｔＡｃｃｅｓｓのジャバ言語コード、第１６図にはｆｒｅｅＢｕｒｓｔＢｕｓＬｏｃｋのジャバ言語コード、第１７図にはｒｕｎ（）でのバーストリードの記述例が示される。バーストリードでは、バスのロックはコールする度に重ねて獲得し、バスの解放を行わないで値を返す。そして、バーストリード回数のリードが終了すると、重ねたロックを一気に解放するという実装方法となっている。この実装により、毎サイクル、リード値が返ってくるというバースト動作を実現している。
《モデル化における排他的同期ライト・メソッド》
バスへの排他的同期アクセス方式として、排他的同期ライト・メソッドについて説明する。排他的同期ライト・メソッドには以下のシングルリードとバーストリードがある。シングルライトはｓｙｎｃ＿ｗｒｉｔｅメソッドをｒｕｎ（）でコールする事で実現される。バーストライトはｓｙｎｃ＿ｂｕｒｓｔ＿ｗｒｉｔｅ、ｅｎｄＢｕｒｓｔＡｃｃｅｓｓ、ｃｏｎｓｕｍｅ＿ｃｌｏｃｋメソッドをｒｕｎ（）の、ｓｙｎｃｈｒｏｎｉｚｅｄブロック内で用いる事で実現される。
第１８図にはｓｙｎｃ＿ｗｒｉｔｅのジャバ言語コードが示され、第１９図にはｒｕｎ（）でのｓｙｎｃ＿ｗｒｉｔｅメソッド記述例が示される。
第２０図にはｓｙｎｃ＿ｂｕｒｓｔ＿ｗｒｉｔｅのジャバ言語コードが示され、第２１図にはｒｕｎ（）でのバーストライトの記述例が示される。バーストライトでは、バスのロックはコールする度に重ねて獲得し、書き込み処理終了後バスの解放を行わないで処理を終了する。そして、バーストライト回数のライトが終了すると、重ねたロックを一気に解放するという実装方法となっている。この実装により、毎サイクル、ライト値が書き込めるというバースト動作を実現している。
《ジャバ言語記述による実装例》
ジャバ言語記述による実装例を説明する。第２２図には実装例の概略仕様が示される。ここでは、共有メモリ方式の２次元グラフィックス描画・表示システムを一例とする。同図に示されるシステムは、コマンドインタフェース（Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ）、ユニファイドメモリ（Ｕｎｉｆｉｅｄ Ｍｅｍｏｒｙ）、グラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）、及び表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）を有し、それらは双方向バス（Ｓｉｎｇｌｅ ｂｉ−ｄｅｒｅｃｔｉｏｎ Ｂｕｓ）に共有する。
（１）Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅは、外部からの描画コマンドを受付け、バスを介して受け付けた描画コマンドをメモリへ転送する。
（２）Ｕｎｉｆｉｅｄ Ｍｅｍｏｒｙは、描画コマンド、描画ソースデータ、表示データを一元的に格納するメモリである。システムの低コスト化・部品点数削減に効果大。モデルを単純化する為、Ｊａｖａでは配列で表現する。本デバイスはスレーブデバイスである。
（３）Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔは、Ｕｎｉｆｉｅｄ Ｍｅｍｏｒｙに描画コマンドがあるかをボーリングで調べ、存在する場合は、描画コマンド、描画データをバスを介してリードしながら描画処理を行い、描画結果を内部バッファに格納し、一気にＵｎｉｆｉｅｄ Ｍｅｍｏｒｙへバースト転送する。モデルを単純化する為、描画コマンド、描画データ転送は配列への連続アクセスで実現する。
（４）Ｄｉｓｐｌａｙ Ｕｎｉｔは、表示データをリードしながら１ラインずつ表示を行う。モデルを単純化する為、垂直同期はモデル化しない。また、水平帰線期間はバスアクセスを行わないものとする。
上記コマンドインタフェース（Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ）、グラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）、及び表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）がバスマスタデバイスであり、ユニファイドメモリ（Ｕｎｉｆｉｅｄ Ｍｅｍｏｒｙ）がバススレーブデバイスである。バスマスタデバイスが同時にバス権獲得を行った場合の、バス権獲得の優先順位は、表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）＞コマンドインタフェース（Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ）＞グラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）とする。
次に、第２２図の仕様に対するｒｕｎ（）ｍｅｔｈｏｄの実装例について説明する。
（１）Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ
先ず、コマンドインタフェースに関するｒｕｎ（）ｍｅｔｈｏｄの実装例を説明する。その実装例は第２３図乃至第２６図に例示される。外部入力ｗｒｉｔｅ＿ｒｅｑ信号（具体的にはＣＰＵからのライト信号）があり且つｗａｉｔ出力信号の値決定に用いる内部変数ｗａｉｔ＿ｆｌａｇがｆａｌｓｅだとコマンド受付を実行（一定サイクル消費）し、その後に先ずｗａｉｔ＿ｆｌａｇ変数をｔｒｕｅとする。次いで、バス権取得を試み、取得できたらＵｎｉｆｉｅｄ Ｍｅｍｏｒｙのコマンドフラグ０，１をｓｙｎｃ＿ｂｕｒｓｔ＿ｒｅａｄで読み出し、値が０（描画コマンド処理済み）であるコマンドフラグに対応するメモリ領域に対して、バス権を取得した状態のままで、ｓｙｎｃ＿ｂｕｒｓｔ＿ｗｒｉｔｅを実行し、コマンドフラグ、描画コマンド、描画ソースデータを転送し、ｗａｉｔ＿ｆｌａｇ変数をｆａｌｓｅとする。但し、モデル簡略化の為、例えコマンドフラグが両方とも０であっても、コマンドフラグ０に対応するメモリ領域へのｓｙｎｃ＿ｂｕｒｓｔ＿ｗｒｉｔｅによる書き込みのみを実行するものとし、描画ソースデータの転送は省略する。
ｗｒｉｔｅ＿ｆｌａｇ変数がｔｒｕｅで、ｗｒｉｔｅ＿ｒｅｑ入力信号がｔｒｕｅの場合のみ、ｗａｉｔ信号をｔｒｕｅとし、それ以外はｗａｉｔ信号をｆａｌｓｅとする。特に、コマンド受付実行中はｗａｉｔ＿ｆｌａｇ変数をｆａｌｓｅとする。尚、ｗａｉｔ信号、ｗａｉｔ＿ｆｌａｇ変数ともに初期値はｆａｌｓｅとする。
また、Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅが受け付けるコマンドは、コマンドフラグ、描画コマンド、描画ソースデータ、テクスチャデータの格納開始・終了アドレスからなっており、テクスチャデータの格納開始・終了アドレスは描画コマンドに含まれているものとする。
（２）Ｕｎｉｆｉｅｄ Ｍｅｍｏｒｙ
ユニファイドメモリに関するｒｕｎ（）ｍｅｔｈｏｄの実装例を説明する。その実装例は第２７図に例示される。グラフィックス描画コマンド、描画ソース・グラフィックス・データ、描画後の表示用データを一元的に格納しているメモリ。モデル化を簡略化する為、何も実行しないスレッドとして実現。このメモリの実体はＲｅｇｉｓｔｅｒ Ｃｌａｓｓのインスタンスとしてｒｕｎ（）メソッド内でアローケートされている。
尚、モデル簡略化の為、メモリ配列を下記
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［０］：コマンドフラグ０、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［１］：描画コマンド０、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［２］：コマンドフラグ１、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［３］：描画コマンド１、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［４］：描画ソース・データ、及び描画後の表示用データ、の構造としている。
実際には、描画ソース・データと描画後の表示データを格納している配列のなすメモリ空間を２分し（一方をＢｕｆｆｅｒ０、他方をＢｕｆｆｅｒ１とする）、フレーム表示毎にメモリ配列を、
（Ｂｕｆｆｅｒ０，Ｂｕｆｆｅｒ１）＝（描画ソース・データ，描画後の表示用データ）（Ｂｕｆｆｅｒ０，Ｂｕｆｆｅｒ１）＝（描画後の表示用データ，描画ソース・データ）となるように、交互に切り替えているとする。従って、描画ソース・データを描画後の表示用データで上書きする事はないとする。更に、モデル簡略化の為、描画ソース・データの転送は省略する。
また、モデル簡略化の為に、テクスチャ・データは省略しており、描画コマンドも最高で２つしか格納しないものとし、コマンド０，１の実行順番がどうであっても描画結果には影響しないものとする。
（３）Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ
グラフィック描画ユニットに関するｒｕｎ（）ｍｅｔｈｏｄの実装例を説明する。その実装例は第２８図乃至第３２図に例示される。Ｕｎｉｆｉｅｄ Ｍｅｍｏｒｙのコマンドフラグ０，１をある一定周期毎にｓｙｎｃ＿ｂｕｒｓｔ＿ｒｅａｄにより読み出す（バス権獲得・解放動作）。何れか一方の値が１であった場合、内部状態変数ｒｅｎｄｅｒ＿ｓｔａｒｔをｔｒｕｅとし、バス権獲得を試み、獲得に成功したなら、描画コマンド、描画データをｓｙｎｃ＿ｂｕｒｓｔ＿ｒｅａｄで読み込みながら、描画処理を実行し、描画結果を内部バッファに書き込む（読み込み終了次第、コマンドフラグを０にクリアし、バス権解放する）。但し、モデル簡略化の為、例えコマンドフラグが両方とも０であっても、コマンドフラグ０に対応する描画コマンドのみを実行するものとし、描画ソースデータの転送は省略する。再び、バス権獲得を試み、獲得に成功したなら、描画結果をｓｙｎｃ＿ｂｕｒｓｔ＿ｗｒｉｔｅでＵｎｉｆｉｅｄ Ｍｅｍｏｒｙへ転送し、バス権を解放し、内部状態変数ｒｅｎｄｅｒ＿ｓｔａｒｔをｆａｌｓｅとする。尚、内部状態変数ｒｅｎｄｅｒ＿ｓｔａｒｔの初期値はｆａｌｓｅである。
（４）Ｄｉｓｐｌａｙ Ｕｎｉｔ
表示ユニットに関するｒｕｎ（）ｍｅｔｈｏｄの実装例を説明する。その実装例は第３３図及び第３４図に例示される。Ｕｎｉｆｉｅｄ Ｍｅｍｏｒｙから描画後の表示用データを読み込みＣＲＴへ出力する。但し、モデル簡略化の為、水平同期のみを扱うものとする。これは、水平帰線期間内に描画が開始・終了する為のサイクル制約をパラメトリック・モデルチェッキングで求める事を目的としているからである。
さて、Ｄｉｓｐｌａｙ Ｕｎｉｔは、内部変数ｄｉｓｐｌａｙ＿ｓｔａｒｔをｔｕｒｅに設定し、Ｕｎｉｆｉｅｄ Ｍｅｍｏｒｙから描画後の表示用データをｓｙｎｃ＿ｂｕｒｓｔ＿ｒｅａｄにて読み込む。データ読み込み終了後に内部変数ｄｉｓｐｌａｙ＿ｓｔａｒｔをｆａｌｓｅとして、ライン表示を実行し、ライン表示終了後から水平帰線期間に相当する適当なサイクルを消費し、再び、ライン表示を同じ手順で行うものとする。また、転送サイクルのみをモデル化すれば良いので、メモリアドレスは簡略的に表現し、常に同一メモリ空間から読み出しているものとする。
《パラメトリック解析》
ここでパラメトリック解析の目標について説明する。本来、描画は１フレーム表示の表示期間及び、垂直帰線期間の間に１フレーム分の実行を終了しておれば良いと考えられるので、水平帰線期間での描画が満たすべき性質を勘案すると、検証内容としては下記条件を満たすサイクル制約の導出で十分である。即ち、「表示用データ取得終了後に描画を開始し、次の表示開始までに描画を終了する事がある。但し、描画開始・終了にデータ転送サイクルは含まれ、表示はｎサイクル以内に終了する。」である。上記制約をＲＰＣＴＬ（Ｒｅａｌ Ｔｉｍｅ Ｐａｒａｍｅｔｒｉｃ Ｃｏｍｐｕｔａｔｉｏｎ Ｔｒｅｅ Ｌｏｇｉｃ）で記述すると下記
ＥＦ｛＜ｄｉｓｐｌａｙ＿ｅｎｄ＞（ＡＦ（＜ｒｅｎｄｅｒ＿ｂｅｇｉｎ＞ｔｒｕｅ）
＆＆｛ＡＦ（＜ｒｅｎｄｅｒ＿ｅｎｄ＞ｔｒｕｅ）ＡＵ（＜ｄｉｓｐｌａｙ＿ｂｅｇｉｎ＞ｔｒｕｅ）｝）｝
＆＆ ＡＧ｛［ｄｉｓｐｌａｙ＿ｂｅｇｉｎ］（ＡＦ＜＝ｎ（［ｄｉｓｐｌａｙ＿ｅｎｄ］ｔｒｕｅ））｝
の３個の制約のアンド条件となる。尚、表示データ取得終了迄に未実行の描画コマンドがＵｎｉｆｉｅｄ Ｍｅｍｏｒｙ上に常に存在する事が仮定できるものとする。ここで、ｎは適当な正整数であり、各変数は下記の通り、ｄｉｓｐｌａｙ＿ｂｅｇｉｎ：内部変数ｄｉｓｐｌａｙ＿ｓｔａｒｔの０から１への立ち上がりイベント
ｄｉｓｐｌａｙ＿ｅｎｄ：内部変数ｄｉｓｐｌａｙ＿ｓｔａｒｔの１から０への立ち下がりイベント
ｒｅｎｄｅｒ＿ｂｅｇｉｎ：内部変数ｒｅｎｄｅｒ＿ｓｔａｒｔの０から１への立ち上がりイベント
ｒｅｎｄｅｒ＿ｅｎｄ：内部変数ｒｅｎｄｅｒ＿ｓｔａｒｔの１から０への立ち下がりイベント
を表す。
パラメトリック・モデルチェッキングを高速化する目的で、ＲＰＣＴＬを
ＡＧ｛［ｄｉｓｐｌａｙ＿ｂｅｇｉｎ］（ＡＦ＜＝ｎ（［ｄｉｓｐｌａｙ＿ｅｎｄ］ｔｒｕｅ））｝ （＊）
と、それ以外の部分に分離し、例えば、
ＥＦ｛＜ｄｉｓｐｌａｙ＿ｅｎｄ＞（ＥＦ（＜ｒｅｎｄｅｒ＿ｂｅｇｉｎ＞ｔｒｕｅ）＆＆｛ＥＦ（＜ｒｅｎｄｅｒ＿ｅｎｄ＞ｔｒｕｅ）ＡＵ（＜ｄｉｓｐｌａｙ＿ｂｅｇｉｎ＞ｔｒｕｅ）｝）｝
から実行し、パラメータ条件を導出し、導出されたパラメータから（＊）のｎの上限を求め、既に求めたパラメータ条件に矛盾しないパラメータ条件が導出できるまで、ｎの値を減じて繰り返し、（＊）のパラメトリック解析を実施するものとする。
ＲＰＣＴＬやそれを用いたパラメトリック・モデルチェッキングの詳細は次の文献、“Ａｋｉｏ Ｎａｋａｔａ ａｎｄ Ｔｅｒｕｏ Ｈｉｇａｓｈｉｎｏ：”Ｄｅｒｉｖｉｎｇ Ｐａｒａｍｅｔｅｒ Ｃｏｎｄｉｔｉｏｎｓ ｆｏｒ Ｐｅｒｉｏｄｉｃ Ｔｉｍｅｄ Ａｕｔｏｍａｔａ Ｓａｔｉｓｆｙｉｎｇ Ｒｅａｌ−Ｔｉｍｅ Ｔｅｍｐｏｒａｌ Ｌｏｇｉｃ Ｆｏｒｍｕｌａｓ”，Ｐｒｏｃ．ｏｆ ＩＦＩＰ ＴＣ６／ＷＧ６．１ Ｉｎｔ’ｌ Ｃｏｎｆ．ｏｎ Ｆｏｒｍａｌ Ｔｅｃｈｎｉｑｕｅｓ ｆｏｒ Ｎｅｔｗｏｒｋｅｄ ａｎｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍｓ（ＦＯＲＴＥ２００１），Ｃｈｅｊｕ Ｉｓｌａｎｄ，Ｋｏｒｅａ，Ｋｌｕｗｅｒ Ａｃａｄｅｍｉｃ Ｐｕｂｌｉｓｈｅｒｓ，ｐｐ．１５１−１６６，Ａｕｇ．２００１．”に記載ある。
《中間表現への変換》
第３５図には中間表現へ変換工程の詳細が全体的に例示される。バスシステムをモデル化して記述されたジャバ言語記述はＣ（ｃｏｎｃｕｒｒｅｎｔ）−ＣＦＧに変換され（Ｊａｖａ２Ｃ−ＣＦＧ）、Ｃ−ＣＦＧはＣ−ＴＮＦＡに変換され（Ｃ−ＣＦＧ２Ｃ−ＴＮＦＡ）、Ｃ−ＴＮＦＡはＴＮＦＡに変換される（Ｃ−ＴＮＦＡ２ＴＮＦＡ）。パラメトリック・モデルチェッキングを経てＣ−ＣＦＧがＨＤＬに変換される（Ｃ−ＣＦＧ２ＨＤＬ）。尚、上記Ｊａｖａ２Ｃ−ＣＦＧ等の標記において、数字“２”は“ｔｏ”を意味するものと理解されたい。
《Ｊａｖａ２Ｃ−ＣＦＧ》
ジャバ言語記述からＣ−ＣＦＧへの変換アルゴリズムの概要を説明する。各ｒｕｎ（）メソッドに対応するＣＦＧを生成する。特に、クロック同期メソッド（ｃｏｎｓｕｍｅ＿ｃｌｏｃｋ）はクロック境界として識別し、呼び出しメソッドは呼び出し関係を表すノードを用いて表現する。各ｒｕｎ（）メソッドに対応するＣＦＧが生成されると、ｆｏｒｋノードを設け、そのノードから各ＣＦＧの開始ノードへのｆｏｒｋ枝を付加する。特に、バス上の各デバイスにｒｕｎ（）メソッドが対応するものとしてＪａｖａが記述されている事を前提とし、メモリデバイスに関しては、ＣＦＧ生成対象外である事の指定を与えるものとする。
次いで、呼び出しメソッドのＣＦＧを作成し、呼び出しメソッドがｓｙｎｃｈｒｏｎｉｚｅｄブロック内に存在する場合は、呼び出しメソッド内のｓｙｎｃｈｒｏｎｉｚｅｄをＣＦＧから削除する。特に、呼び出しメソッドがＲｅｇｉｓｔｅｒクラス内の通信メソッドである場合はＣＦＧの作成を行わず、インスタンス関係からどのデバイス内のどのレジスタへのアクセスかと通信メソッドの名前だけを識別し、その情報をＣＦＧに保持する。但し、図ではどのレジスタへのアクセスかの情報は省略している。尚、通信メソッドが内部にクロック同期メソッドを含む場合は、その出力枝にクロック境界をマークする。更に、呼び出しメソッド全体のサイクル制約を導出する以外は、呼び出しメソッドをインライニングする。この例では、Ｒｅｎｄｅｒｓｉｎｇメソッド、Ｄｉｓｐｌａｙメソッドはインライニングしない。
ｓｙｎｃｈｒｏｎｉｚｅｄを予め定めたＣＦＧに展開し、ハード合成用の固定優先度スケジューラをＦＳＭ（Ｆｉｎｉｔｅ Ｓｔａｔｅ Ｍａｃｈｉｎｅ）の形式でスケルトンとして予め与えてあるライブラリと実際にＣＦＧを生成したｒｕｎ（）メソッドの個数を用いて、自動生成する。ここで、ＣＦＧはハード合成用とパラメトリック・モデルチェッキング用の２種作成する。
尚、固定値伝播や、代入によるローカル変数消去等のコードレベル最適化をＣＦＧ上で実施する。特に、信号の入力・出力・入出力はメンバ変数で表し、端子方向に関しては、プログラム内での代入文で右辺にあるのか左辺にあるのかや条件文での変数の用いられ方を解析して決定する。入出力信号として識別された場合、データ依存性を考慮して、入力と出力に適当な信号のリネームを行って分離する。
Ｊａｖａ２Ｃ−ＣＦＧに関し、以下で、Ｊａｖａ記述例に沿って、各ｒｕｎ（）メソッドのＣＦＧ生成結果、Ｃ−ＣＦＧ生成結果、及び固定優先度・スケジューラのＦＳＭについて説明する。
先ずＣＦＧの形式について説明する。第３６図にはＣ−ＣＦＧの形式が例示される。各ＣＦＧは分岐枝の開始と終了を表すノードと、ループ枝の開始と終了を表すノードを含み、分岐条件、ループ終了条件を対応する枝に付加した形式とする。特に、クロック境界ノードを枝上に付加する事でクロック境界を表現する。また、メソッドコールに対応するノードを用いる事で、サブＣＦＧとのリンクを表現する。各ＣＦＧの並列実行を表すｆｏｒｋノードはＣＦＧへの頂点へ付加する事で表現する。
ｓｙｎｃｈｒｏｎｉｚｅｄの扱い（ハード合成用）について説明する。第３７図に例示されるように、ｓｙｎｃｈｒｏｎｉｚｅｄの開始をＣＦＧ上でｂｅｇｉｎ＿ｓｙｎｃとラベル付けされたノードとして表し、ｓｙｎｃｈｒｏｎｉｚｅｄの終了をｅｎｄ＿ｓｙｎｃとラベル付けされたノードでし、ＣＦＧを生成。その後、その両ノードを夫々下図に示すように変換する。
ｓｙｎｃｈｒｏｎｉｚｅｄの扱い（パラメトリック・モデルチェッキング用）について説明する。第３８図に例示されるように、ｓｙｎｃｈｒｏｎｉｚｅｄの開始をＣＦＧ上でＢｅｇｉｎ＿ｓｙｎｃとラベル付けされたノードとして表し、ｓｙｎｃｈｒｏｎｉｚｅｄの終了をＥｎｄ＿ｓｙｎｃとラベル付けされたノードでし、ＣＦＧを生成。その後、その両ノードを夫々第３８図に示すように変換する。
上記に従うと、前記Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅの場合、ＣＦＧは第３９図に示される。ｇｅｔＷｒｉｔｅＳｉｇｎａｌ（）メソッドは、シミュレーションを実施する為に行った記述であり、処理系への入力では外部からの入力信号ｗｒｉｔｅ＿ｒｅｑであるとして修正されているものとし、入力テストベクタの個数を表すｄｃｏｍ＿ｉｎｄｅｘを補正する記述も削除されているものとする。また、ｄｒａｗｉｎｇ＿ｃｏｍｍａｎｄｓも配列として表現されているが、これもシミュレーションを実施する為になされたものであり、内部変数ｉｎｐｕｔ＿ｃｏｍｍａｎｄに入力変数ｄｒａｗｉｎｇ＿ｃｏｍｍａｎｄｓが入力されている記述が処理系に入力されているのもとして扱う。
前記Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅに関し、ハード合成用のＣＦＧは第４０図に示され、パラメトリック・モデルチェッキング用のＣＦＧは第４１図に例示される。
前記グラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）に関し、第４２図及び第４３図にはそのＣＦＧが例示され、第４４図及び第４５図にはそのパラメトリック・モデルチェッキング用のＣＦＧが例示される。
前記表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）に関し、第４６図にはそのＣＦＧが例示され、第４７図にはそのパラメトリック・モデルチェッキング用のＣＦＧが例示される。
第４８図にはコマンドインタフェース（Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ）のＣＦＧ、グラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）のＣＦＧ、及び前記表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）のＣＦＧにおける夫々の開始ノードの結合状態が例示される。
固定優先度スケジューラ（Ｆｉｘｅｄ Ｐｒｉｏｒｉｔｙ Ｓｃｈｅｄｕｌｅｒ）について説明する。実際にトップレベルのＣＦＧを生成したｒｕｎメソッドの数を識別し、夫々のデバイスにバス権取得通知を行うための信号ｌｏｃｋｅｄ＿ｉの組みからなるステートを作成する。単一バスシステムであるため、それらステートは、１つのｌｏｃｋｅｄ＿ｉのみが１でその他が０であるものを構成すれば良い。また、全てのｌｏｃｋｅｄ＿ｉが０であるステートも作成する。優先度情報に基づき、バス権要求信号ｌｏｃｋ＿ｉを受けて行う状態遷移枝を設ければバス権管理用の固定優先度スケジューラが構成できる。特に、全てのｌｏｃｋｅｄ＿ｉが０であるステートをリセット解除時の開始ステートとする。また、各状態遷移は１＜＝ｔ＜＝ｋｌの時間制約が付加されているものとする。このパラメータは後のパラメトリック・モデルチェッキングで決定されるパラメータである。尚、例えば、ｋｌ＝２とし、各遷移を２クロック遷移とした場合は、出力値は変化が起こるまで、前の値を保持しているものとして解釈するものとする。
第４９図には本例に対応する固定優先度スケジューラが例示される。同図における信号の意味は、
ｌｏｃｋ＿１：Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅからのバス権要求信号
ｌｏｃｋ＿２：Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔからのバス権要求信号
ｌｏｃｋ＿３：Ｄｉｓｐｌａｙ Ｕｎｉｔからのバス権要求信号
ｌｏｃｋｅｄ＿１：Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅへのバス権取得通知信号
ｌｏｃｋｅｄ＿２：Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔへのバス権取得通知信号
ｌｏｃｋｅｄ＿３：Ｄｉｓｐｌａｙ Ｕｎｉｔへのバス権取得通知信号
である。尚、バス権取得の優先度が、
Ｄｉｓｐｌａｙ Ｕｎｉｔ＞Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ＞Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔであるので、遷移条件は、
ｌｏｃｋ＿３：Ｄｉｓｐｌａｙ Ｕｎｉｔへの遷移
！ｌｏｃｋ＿３＆＆ｌｏｃｋ＿１：Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅへの遷移条件
！ｌｏｃｋ＿３＆＆！ｌｏｃｋ＿１＆＆ｌｏｃｋ＿２：Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔへの遷移条件
ｏｔｈｅｒｗｉｓｅ：全てのｌｏｃｋｅｄ＿ｉが０であるステートへの遷移条件
となる。
《Ａｂｓｔｒａｃｔｉｏｎ ｏｆ ｅａｃｈ ＣＦＧ》
夫々のＣＦＧの抽象化処理について説明する。先ず、そのアルゴリズムの概要を説明する。各ＢａｓｉｃＢｌｏｃｋに対して、０＜＝ｔ＜＝ｋｉなる時間遷移条件を付加し、Ｂｅｇｉｎ＿ｓｙｎｃノードとＥｎｄ＿ｓｙｎｃノードに対して０＜＝ｔ＜＝ｋｌを付加し、通信メソッドを表すノードに対して、バースト開始に１＜＝ｔ＜＝ｋｂ１、バースト動作に０＜＝ｔ＜＝ｋｂ２、バースト終了に０＜＝ｔ＜＝ｋｂ３を付加する。但し、通信メソッドを表すノードに対しては、バースト開始が２サイクル以上、バースト動作時は１サイクル以上、バースト終了が１サイクル以上を要すると考え、後述のノードのマージによる抽象化を行う際には、サイクル制約の補正を行う。Ｂｅｇｉｎ＿ｓｙｎｃとＥｎｄ＿ｓｙｎｃノード以外の制約を付加したノードをクロック境界と見做して抽象化を行う。
通信メソッドは動作内容を全て抽象化し、連続する場合は、１つのノードにまとめ、例えばバースト開始（１＜＝ｔ＜＝ｋｂ１）、クロック境界（ｔ＝１）、（バースト動作（０＜＝ｔ＜＝ｋｂ２）＋クロック境界（ｔ＝１））３回、バースト終了（０＜＝ｔ＜＝ｋｂ３）、クロック境界（ｔ＝１）とすると、
６＜＝ｔ＜＝（ｋｂ１＋１−１）＋３（ｋｂ２＋１−１）＋（ｋｂ３＋１−１）＝ｋｂ１＋３ｋｂ２＋ｋｂ３（＞＝２＋３＊１＋１＝６）
なるサイクル制約を持つクロック境界として１つにまとめる。また、分岐ノードは全て非決定分岐であるとする。Ｂａｓｉｃ Ｂｌｏｃｋノードに関しては、入力ＲＰＣＴＬで用いる変数のみ残し他は抽象化する。分岐ノード下位に存在するＢａｓｉｃ Ｂｌｏｃｋに対応する部分が異なる分岐で同じ場合は、１つを残して他を削除する。
特にループノードに関しては、ｂｒｅａｋ、ｃｏｎｔｉｎｕｅを含まない固定回数ループの場合はアンローリングを実施し、それ以外の場合は、ループを抜ける条件枝の直前に全体で０＜＝ｔ＜＝ｋｌｏｏｐのサイクル制約を持つようなＣＦＧノードの集合を設ける事でループを削除する。ここで、ｋｌｏｏｐの満たすべき条件を別に算出するものとする。更に連続するクロック境界はパーコレーション・ベースの移動を行う事で、１つに纏め、遷移サイクル制約を更新する。
ここで、各クロック境界のパラメータ化により、クロック境界に与えた遷移サイクル制約の意味は、クロック境界から次のクロック境界への遷移に対するサイクル制約である。
コマンドインタフェース（Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ）のＣＦＧに対する抽象化の様子が順を追って第５０図乃至第５６図に例示される。第５７図にはグラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）のＣＦＧに対する抽象化処理の結果が例示される。第５８図には表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）のＣＦＧに対する抽象化処理の結果が例示される。
《Ｃ−ＣＦＧ２Ｃ−ＴＮＦＡ》
Ｃ−ＴＮＦＡからＴＮＦＡへの変換処理について説明する。ＴＮＦＡとは時間オートマトンであり、各遷移が、
ｓ−ａ＠？ｔ［Ｐ（ｔ）］−＞ｓ’
の形式で表されるものである。ここで、各記号の意味は、
ｓ，ｓ’：状態、
ａ：動作（省略可能）、
＠？ｔ：状態ｓを訪れてから動作ａを実行するまでの経過時間をｔに代入、Ｐ（ｔ）：時間制約（ｔに関する線形不等式の論理結合）、
である。また、その意味は「ｓからｔ単位時間経過後に状態ｓ’に遷移。ただし、ｔは時間制約Ｐ（ｔ）を満たす場合に限る」である。
Ｃ−ＴＮＦＡは、複数のＴＮＦＡが並列動作するモデルであり、動作ｓｙｎｃは高々１つのＴＮＦＡしか実行できないモデルである。特に連続する動作ｓｙｎｃに対しては他のＴＮＦＡが割り込めない。尚、各ＴＮＦＡに対して、初期状態から初期状態への遷移に対して、上限を与える為の時間制約を課す事が可能である。
次にＣ−ＣＦＧからＣ−ＴＮＦＡへの変換処理について説明する。先ず、その変換アルゴリズムの概要を説明する。Ｂｅｇｉｎ＿ｓｙｎｃ、Ｅｎｄ＿ｓｙｎｃで挟まれた部分を識別し、ｓｙｎｃブロックとする。Ｓｙｎｃブロック内に存在しないクロック境界ノードにステート割り当て候補とし、またｓｙｎｃブロック内であっても検証性質に必要となる信号がＢａｓｉｃ Ｂｌｏｃｋとして与えられている場合はその前後のクロック境界ノードにステートを割り当て候補とし、最後にＢｅｇｉｎ＿ｓｙｎｃ、Ｅｎｄ＿ｓｙｎｃの変換で導入したクロック境界をステート割り当て候補とする。得られたステート割り当て候補を重複が無いようにし、ステート割り当てを行い、各ステートからステートまでをＤＦＳ（Ｄｅｐｔｈ Ｆｉｒｓｔ Ｓｅａｒｃｈ）でトラバースする事でＴＮＦＡへの変換を行う。得られたＴＮＦＡに対して、ｓｙｎｃブロックに対応する遷移を検出し、ｓｙｎｃ遷移とする。連続するｓｙｎｃ遷移でない遷移は１つの遷移に纏める事でステート数の削減を行う。
コマンドインタフェース（Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ）のＣＦＧに対するＴＮＦＡへの変換の様子が順を追って第５９図乃至第６１図に例示される。
第６２図乃至第６５図にはグラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）のＣＦＧに対するＴＮＦＡへの変換の様子が順を追って例示される。第６５図において、検証性質は、「表示用データ取得終了後に描画を開始し、次の表示開始までに描画を終了する事がある。但し、描画開始・終了にデータ転送サイクルは含まれ、表示はｎサイクル以内に終了する。」であり、これは、描画が開始される事がもしあればという前提にたった検証性質であるから、Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔに対応するＴＮＦＡにおいて、表示データ取得終了迄に未実行の描画コマンドがＵｎｉｆｉｅｄ Ｍｅｍｏｒｙ上に存在しない事を表すＲ２からＲ１への遷移はこの検証には不要となる。従って、これは削除されている。
第６６図乃至第６８図には表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）のＣＦＧに対するＴＮＦＡへの変換の様子が順を追って例示される。
《Ｃ−ＴＮＦＡ２ＴＮＦＡ》
Ｃ−ＴＮＦＡからＴＮＦＡへの変換アルゴリズムの概要を説明する。先ず、下記方針（１）〜（５）に従ってＣ−ＴＮＦＡから積ＴＮＦＡを構成する。
（１）ｓｙｎｃ動作とそれ以外の動作は互いにインタリーブされる。ここで、ｓｙｎｃ動作を行っている間にバス権をとる必要が無い動作、即ちｓｙｎｃでない動作を（一般に複数）並行して実行できることを表現。但し、ｓｙｎｃ動作を１遷移実行する間の他のＴＮＦＡの並行遷移に遷移枝を通る回数に制限を設け、それを満たす各遷移の遷移時間の上限を導出する。特に、回数は１から始め、意味のある解が得られるまで、回数を１づつインクリメントするものとする。
（２）複数のｓｙｎｃ動作が実行可能な場合は静的優先度が最も高いものによって遷移する。ここで、動いていない状態ｓに関してはａｇｅ（ｓ，ｔ）（状態ｓで時間ｔだけが経過した状態）に遷移。ただし、連続するｓｙｎｃ遷移の間には他の動作は割り込めない。
（３）ａｇｅ（ｓ，ｔ）以降の遷移に関しては、時間ｔに関して下記補正を行う。即ち、ｓ−［Ｐ（ｔ１）］−＞ｓ’ならばａｇｅ（ｓ，ｔ）−［Ｐ（ｔ＋ｔ１）］−＞ｓ’［ｔ＋ｔ１／ｔ１］、とする。ここで、ｓ［ｅ／ｔ］：状態ｓからの遷移条件に現れる変数ｔを式ｅで置き換えることを表す。尚、再構成したＰ（ｔ）が矛盾した式になっている場合、その遷移は削除し、その遷移へのみ到達する状態全てを削除するものとする。
（４）各遷移の時間変数ｔは下記に示すように、異なる名前に変更する。即ち、ｓ−［Ｐ（ｔ）］−＞ｓ’−［Ｑ（ｔ）］−＞ｓ’’はｓ−［Ｐ（ｔ１）］−＞ｓ’−［Ｑ（ｔ２）］−＞ｓ’’に変更する。ａｇｅ（ｓ，ｔ）に関する補正によって、各遷移条件はそれ以前の遷移の時間変数も含む式になるため、それらを区別するために、この変更が必要となる。
（５）上限を与えたＴＮＦＡがある場合、構成後のＴＮＦＡでその初期状態を含む状態間の遷移がその上限を満たさない場合、その途中にある状態で上限を満たす遷移内に存在する状態を削除対象外とし、削除対象外とならなかった状態を削除する。
尚、Ａｂｓｔｒａｃｔｉｏｎ ｏｆ ｅａｃｈ ＣＦＧのステップで抽象化対象から除外されたＲＰＣＴＬに用いられている変数を伴う遷移が現れるとその次の状態まで構成し、上記構成方針での作成での切りの良いところで、Ａｂｓｔｒａｃｔｉｏｎ ｏｆ ＴＮＦＡをコールし、構成中のＴＮＦＡの抽象化を行う。
次にＣ−ＴＮＦＡからＴＮＦＡへの変換処理を詳細に説明する。先ず、遷移回数の仮定による遷移時間の上限を決定する。即ち、各ＴＮＦＡの強連結成分を求め、強連結成分内での遷移枝を１回のみ通る各遷移の下限遷移時間の総計が最大となる最長パスと、そのパス上の頂点でその後段の頂点への遷移時間の下限が最小の頂点を求め、最長パスにその後段頂点へのパスを追加したパスの２つを求める。次いで、夫々のパスの下限遷移時間の総計を求める。これにより、
Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ：２２ ２３
Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ：２８ ２９
Ｄｉｓｐｌａｙ Ｕｎｉｔ：１１ １２
が求まる。さて、各ＴＮＦＡの２つ目の下限遷移時間の総計から１引いた値、
Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ：２２
Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ：２８
Ｄｉｓｐｌａｙ Ｕｎｉｔ：１１
を求める。各ＴＮＦＡの各遷移の上限時間を、他のＴＮＦＡに対して求めた値の最小値を与える事で決定し、得られた時間遷移の上限値が矛盾したものとなっていないかを、既に上限が与えられている遷移の上限値と比較する事で調べ、もし、矛盾がでたなら２回に増加させる。そうでなければ、上限が与えられていない遷移に求めた上限を与える事で線形不等式の論理結合を構成する。特に、回数を増加させる場合、最長パスの下限遷移時間の総計と回数の積を取った値と、その値に先に求めた最小の遷移時間を加えた値を算出すればよい。
尚、パラメトリック・モデルチェッキングを実施し、パラメータ条件が非負整数解を持たない場合にも回数の増加を行って処理をすすめる事とする。ここで、非負整数解の算出には、線形計画法を用いる。具体的には、フリーソフトＬＰ−ＳＯＬＶを用いて得られたパラメータ条件を満たす範囲で、パラメータの和が最小となる解を算出する。仮に、得られた解が意味をなさない場合は、パラメータの最小値を付加するなどして対処する。
さて、本例の場合、遷移枝を一回のみ遷移可能とした仮定では、各ＴＮＦＡの遷移時間の上限として
Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ：１１
Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ：１１
Ｄｉｓｐｌａｙ Ｕｎｉｔ：２２
が求まる。また、矛盾が起こることなく、以下に示す線形不等式の論理結合、
０＜＝ｋ１＋ｋ２＋ｋｌｏｏｐ１＜＝７ ＆＆ ５＜＝ｋｂ１＋ｋｂ２＋ｋｂ３＋ｋｌ＜＝８ ＆＆ ７＜＝ｋｂ１＋３ｋｂ２＋ｋｂ３＋ｋｌ＜＝１１ ＆＆ １＜＝ｋｌ＜＝１１ ＆＆ １＜＝ｋ１＋ｋ２＋ｋ３＋ｋｌｏｏｐ１＋ｋｌ＜＝６ ＆＆ ３＜＝ｋ４＜＝１１ ＆＆ ５＜＝ｋｂ１＋ｋｂ２＋ｋｂ３＋ｋｌ＜＝１１ ＆＆ ６＜＝ｋｂ１＋４ｋｂ２＋ｋｂ３＋３ｋｒ１＜＝１２ ＆＆ １＜＝３ｋｒ２＋ｋｌ＜＝８ ＆＆ ９＜＝ｋｂ１＋５ｋｂ２＋ｋｂ３＋ｋｌ＜＝１２ ＆＆ ｋｒ１＝ｋｂ２−１ ＆＆ ８＜＝ｋｂ１＋５ｋｂ２＋ｋｂ３＜＝２４ ＆＆ １＜＝ｋｌ＋６ｋｄ＜＝１９
が得られる。また、遷移枝を２回まで遷移可能とした場合、各ＴＮＦＡの遷移時間の上限として
Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ：２２
Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ：２２
Ｄｉｓｐｌａｙ Ｕｎｉｔ：４４
が求まり、以下に示す線形不等式の論理結合、
０＜＝ｋ１＋ｋ２＋ｋｌｏｏｐ１＜＝１８ ＆＆ ５＜＝ｋｂ１＋ｋｂ２＋ｋｂ３＋ｋｌ＜＝１９ ＆＆ ７＜＝ｋｂ１＋３ｋｂ２＋ｋｂ３＋ｋｌ＜＝２２ ＆＆ １＜＝ｋｌ＜＝２２ ＆＆ １＜＝ｋ１＋ｋ２＋ｋ３＋ｋｌｏｏｐ１＋ｋｌ＜＝１７ ＆＆ ３＜＝ｋ４＜＝２ ＆＆ ５＜＝ｋｂ１＋ｋｂ２＋ｋｂ３＋ｋｌ＜＝２２ ＆＆ ６＜＝ｋｂ１＋４ｋｂ２＋ｋｂ３＋３ｋｒ１＜＝２３ ＆＆ １＜＝３ｋｒ２＋ｋｌ＜＝１９ ＆＆ ９＜＝ｋｂ１＋５ｋｂ２＋ｋｂ３＋ｋｌ＜＝２３ ＆＆ ｋｒ１＝ｋｂ２−１ ＆＆ ８＜＝ｋｂ１＋５ｋｂ２＋ｋｂ３＜＝４６ ＆＆ １＜＝ｋｌ＋６ｋｄ＜＝４１
が得られる。
この工程は、Ａｓｓｕｍｅ Ｇｕａｒａｎｔｅｅ Ｒｅａｓｏｎｉｎｇと呼ばれる手法であり、パラメトリック解析での実施は公知ではない。
第６９図には第６１図、第６４図、第６８図で求めたＴＮＦＡの積ＴＮＦＡの構成例が示される。これに基づいてＴＮＦＡを求める過程が第７０図乃至第７６図に示される。
《Ａｂｓｔｒａｃｔｉｏｎ ｏｆ ＴＮＦＡ》
ＴＮＦＡの抽象化処理について説明する。先ず、そのアルゴリズムの概要を説明する。ＴＮＦＡで抽象化時に残した変数への代入を行っている遷移枝と、その遷移枝の始点ノード及び終点ノードのみを残し、残すべき頂点を始点として、次に残すべき頂点が現れるまで頂点と辺をトラバースしながら遷移時間を再計算する事で、その他の頂点を全て抽象化する。但し、葉に対応する状態は抽象化の対象から除外する。
先の例では抽象化の実施がまだ起こらない段階までしかＴＮＦＡを構成しなかったので、抽象化が必要となる様先の例を意図的に若干修正して、第７７図乃至第７９図ににＣ−ＴＮＦＡ２ＴＮＦＡでＡｂｓｔｒａｃｔｉｏｎ ｏｆ ＴＮＦＡを適時コールした場合の処理の経過の一部を示す。ここでは、ｋｌには具体的な値は与えないものとする。
《パラメトリック解析結果》
前記文献に述べられているアルゴリズムを用いて、遷移を２回以上通らない制約で、探索深さ最大値１６として、以下の検証性質
ＥＦ（＜ｄｉｓｐｌａｙｅｎｄ＞（（ＡＦ（＜ｒｅｎｄｅｒｂｅｇｉｎ＞ｔｒｕｅ））ａｎｄ（（ＡＦ（＜ｒｅｎｄｅｒｅｎｄ＞ｔｒｕｅ））ＡＵ（＜ｄｉｓｐｌａｙｂｅｇｉｎ＞ｔｒｕｅ））））に関してパラメタ条件を導出すると、以下の条件、
０＜＝ｋｄ ＆＆ ０＜＝ｋｒ２ ＆＆ ０＜＝ｋｒ１ ＆＆ ０＜＝ｋｂ３ ＆＆ ０＜＝ｋｂ２ ＆＆ ０＜＝ｋｂ１ ＆＆ ０＜＝ｋｌｏｏｐ１ ＆＆ ０＜＝ｋ５ ＆＆ ４＜＝ｋ４ ＆＆ ０＜＝ｋ３ ＆＆ ０＜＝ｋ１ ＆＆ ０＜＝ｋ２ ＆＆ １２＜＝ｋｂ１＋９ｋｂ２＋ｋｂ３ ＆＆ ４ ＜＝ｋｌ）
を得る。これと先に求めた、遷移を２回以上通らないという制約から得られたパラメータ条件
０＜＝ｋ１＋ｋ２＋ｋｌｏｏｐ１＜＝７ ＆＆ ５＜＝ｋｂ１＋ｋｂ２＋ｋｂ３＋ｋｌ＜＝８ ＆＆ ７＜＝ｋｂ１＋３ｋｂ２＋ｋｂ３＋ｋｌ＜＝１１ ＆＆ １＜＝ｋｌ＜＝１１ ＆＆ １＜＝ｋ１＋ｋ２＋ｋ３＋ｋｌｏｏｐ１＋ｋｌ＜＝６ ＆＆ ３＜＝ｋ４＜＝１１ ＆＆ ５＜＝ｋｂ１＋ｋｂ２＋ｋｂ３＋ｋｌ＜＝１１ ＆＆ ６＜＝ｋｂ１＋４ｋｂ２＋ｋｂ３＋３ｋｒ１＜＝１２ ＆＆ １＜＝３ｋｒ２＋ｋｌ＜＝８ ＆＆ ９＜＝ｋｂ１＋５ｋｂ２＋ｋｂ３＋ｋｌ＜＝１２ ＆＆ ｋｒ１＝ｋｂ２−１ ＆＆ ８＜＝ｋｂ１＋５ｋｂ２＋ｋｂ３＜＝２４ ＆＆ １＜＝ｋｌ＋６ｋｄ＜＝１９
との論理積を取って、得られたパラメータ条件に対して、目的関数を各パラメタ値の合計として、これを最小化するという線形計画問題をフリーソフトＬＰ＿ＳＯＬＶＥにて解かせると、第８０図の解を得る。
第８０図の結果では、バスアクセス終了通知が０サイクルで行われなければならず、また、描画サイクルｋｒ２と表示サイクルｋｄが０であるので、意味のある解とは言えないので、ｋｂ１＝２，ｋｂ２＝１，ｋｂ３＝１の制約を追加し、第８１図の解を得た。
第８１図の結果でも、描画サイクルｋｒ２と表示サイクルｋｄが０であるので、意味のある解とは言えないので、ｋｂ１＝２，ｋｂ２＝１，ｋｂ３＝１の制約に加えてさらに、ｋｒ１以外のパラメタ変数は１以上という制約を追加し、第８２図の解を得た。以後、このパラメータ値を採用して議論を進める。
《ハード合成》
ハードウェア合成処理についてその概要を先ず説明する。（１）〜（１１）の方針にてハードウェアの生成が行なわれる。
（１）事前にＲｅｇｉｓｔｅｒクラスに登録された通信メソッドの種類からバスコマンドの割り当てを行う。
（２）ユーザ情報として、どのデバイスにどの共有レジスタが存在するかを受付け、各デバイス内のレジスタ数に対応するデバイス内アドレスを割り当てる。
（３）共有レジスタが割付られたデバイス（ｒｕｎ（）メソッド）の数を取得し、共有レジスタが割り当てられたデバイスにグローバルなアドレスを割り当てる。
（４）インライニング（展開）を実施しなかった通信メソッド以外のメソッドのインライニングを行う。（通信メソッドと指定したメソッド以外のメソッドは事前にインライニングされている事に注意。）
（５）パラメトリック解析結果から得られた、Ｂａｓｉｃ Ｂｌｏｃｋの実行サイクルを各デバイスの合成用ＣＦＧに反映する。
（６）各デバイス夫々のＣＦＧを変形し、通信メソッドとそれ以外のコントロールフロー部が互いに通信するモデルに変換する。
（７）前記（６）で得られた変換後のＣＦＧ内の通信メソッドに対応する部分に、バスコマンド生成記述を挿入する。通信メソッドは、グローバルアドレス、共有レジスタアドレス、バスコマンドを出力し、データ読み出し・書き込みの何れかを実行する記述からなるＣＦＧとなり、それらの信号生成・受理に要するサイクルは、パラメトリック解析の結果により決定される。
（８）共有レジスタアドレスから、各デバイス内のレジスタの配列インデックスを生成するアドレスデコーダとグローバル・アドレスを識別するアドレスデコーダを共有レジスタが割り当てられたデバイス内に生成し、出力トライステートを共有レジスタの出力に接続し、トライステート・イネーブル信号として、各デバイスからのデータ入力ステージを表す信号の論理和を用いる。共有レジスタの入力に関しては、取り込み動作が起こらない限り内部変数は前の値を保持する為バスから信号を接続すれば良よく、各デバイスからのデータ入力ステージを表す信号の論理和を元にデータ取り込み判定を行う。但し、これらはＣＦＧとして表現する。（自デバイス内に共有レジスタがあったとしても、この方式に従って、アクセスが行われているものとする。）
（９）変形等で得られた各ＣＦＧの信号通信関係（入力、出力）を識別し（バスは入出力）、夫々をモジュールとして識別する。
（１０）各ＣＦＧを「サイクルアキュレートなプログラム記述からのハード合成」に従って、ＨＤＬへと変換する。
（１１）バスに対してリピータ回路をＨＤＬの形式で挿入する。
前記バスコマンドの割り当てに関し、本例で登録したバスアクセス・メソッドは、ｓｙｎｃ＿ｒｅａｄ、ｓｙｎｃ＿ｗｒｉｔｅ、ｓｙｎｃ＿ｂｕｒｓｔ＿ｒｅａｄ、ｓｙｎｃ＿ｂｕｒｓｔ＿ｗｒｉｔｅ、ｅｎｄＢｕｒｓｔＡｃｃｅｓｓであるが、各ｒｕｎ（）メソッドのＣＦＧを解析すると、実際に用いられているバスアクセスメソッドは、ｓｙｎｃ＿ｂｕｒｓｔ＿ｒｅａｄ、ｓｙｎｃ＿ｂｕｒｓｔ＿ｗｒｉｔｅ、ｅｎｄＢｕｒｓｔＡｃｃｅｓｓであるため、バスコマンドを
ｓｙｎｃ＿ｂｕｒｓｔ＿ｒｅａｄ ２’ｂ００
ｓｙｎｃ＿ｂｕｒｓｔ＿ｗｒｉｔｅ ２’ｂ０１
ｅｎｄＢｕｒｓｔＡｃｃｅｓｓ ２’ｂ１０
ＮＯＰ ２’ｂ１１
のように割り当てる。
上記アドレス割り当てに関しては、共有レジスタはＵｎｉｆｉｅｄ Ｍｅｍｏｒｙにのみ割り付けられ、Ｕｎｉｆｉｅｄ Ｍｅｍｏｒｙの仕様から割り付けられた共有レジスタは
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［０］：コマンドフラグ０、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［１］：描画コマンド０、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［２］：コマンドフラグ１、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［３］：描画コマンド１、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［４］：描画ソース・データ、及び描画後の表示用データ、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［５］：描画ソース・データ、及び描画後の表示用データ、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［６］：描画ソース・データ、及び描画後の表示用データ、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［７］：描画ソース・データ、及び描画後の表示用データ、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［８］：描画ソース・データ、及び描画後の表示用データ、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［９］：描画ソース・データ、及び描画後の表示用データ、となる。尚、ユーザ情報から各レジスタのビット幅が指定されているものとし、それぞれ３２ビット（ｕｎｓｉｇｎｅｄ ｉｎｔ）であるとする。
バスアクセス・メソッドはレジスタ内のバイトアクセス等を行わないので、各レジスタのアドレスを
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［０］：４’ｂ００００、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［１］：４’ｂ０００１、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［２］：４’ｂ００１０、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［３］：４’ｂ００１１、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［４］：４’ｂ０１００、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［５］：４’ｂ０１０１、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［６］：４’ｂ０１１０、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［７］：４’ｂ０１１１、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［８］：４’ｂ１０００、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［９］：４’ｂ１００１、のように決定する。
また、アドレス割り当てに関し、共有レジスタが割り当てられたデバイスはＵｎｉｆｉｅｄ Ｍｅｍｏｒｙしか存在しないため、グローバルアドレスの割付を行わない。
尚、本例では１つのデバイスのみに共有レジスタの割り当てを行っているが、以降の説明に於いてこれは一般性を欠くものではない。それは、以降に処理手順を示す事で明らかとなる。
前記ＢａｓｉｃＢｌｏｃｋへの実行サイクルの割り当てに関しては、ここでは、Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅのみ取り上げて説明を行う。特に、先に求めたパラメータ値から、ｋｌ＝４，ｋｂ１＝２，ｋｂ２＝１，ｋｂ３＝１、ｋ１＝ｋ２＝ｋ３＝１、として説明を行う。パラメータ条件から、各ＢａｓｉｃＢｌｏｃｋの下に割り当てられたサイクル数のクロック境界を挿入する。ここでは、バスアクセス・メソッドを扱う対象としていない事に注意。更に、与えたパラメータで、例を示しているが一般性を失わない事に注意。次ページに変形後のＣＦＧを示す。尚、ｋｌの値は、直接各デバイスのハード合成用ＣＦＧには影響を与えない事にも注意。これは、固定優先度スケジューラにのみ影響する。第８３図にはＢａｓｉｃＢｌｏｃｋへの実行サイクルの割り当ての例が示される。
固定優先度スケジューラの修正に関しては、既に得られているＦＳＭ（Ｆｉｎｉｔｅ Ｓｔａｔｅ Ｍａｃｈｉｎｅ）の遷移サイクルをｋｌに変更する、即ち、クロック境界を各遷移枝に４つ付加すれば良い。ここからのＨＤＬ生成は、各状態からの遷移を分岐ノードに表現し直し、かつ各状態での信号代入はその状態への遷移枝上での最後のクロック境界直下にＢａｓｉｃＢｌｏｃｋを設け、そこにレジスタ代入文を記述する形式で置き換える事で、このＦＭＳ自体をＣＦＧと見做す事で、「サイクルアキュレートな記述からのＨＤＬ生成」を用いる事で可能である。第８４図に示す固定優先度スケジューラの一部を用いて変形後のＣＦＧが第８５図に示される。
ＣＦＧの変形に関しては、元のＣＦＧからバスアクセス・メソッドの括りだしを行い、バスアクセス・メソッドと元のＣＦＧとの通信ノードを設る。具体的には、下記を行う。
１）ハード合成用のＣＦＧ生成段階で、クロック境界を含むバスアクセス・メソッドのクロックをバスアクセス・メソッドを表すノードの直下にクロック境界を追加したが、これを削除する。
２）バスアクセス・メソッドを表すノードを下記処理を行うＢａｓｉｃ Ｂｌｏｃｋに置き換える。
▲１▼出力信号ｓｔａｒｔ＿ｃｏｍｍに１を代入する。
▲２▼バスコマンドを出力信号ｂｕｓ＿ｃｍｄに代入する。バースト転送の場合、初期サイクルでは、
〈１〉出力信号ｉｎｉｔの０を代入
〈２〉アクセスするデバイスのアドレスと共有レジスタのアドレスを連結して出力信号ａｄｄｒｅｓｓに代入
〈３〉クロック境界挿入×ｎｂｆ
〈４〉リードメソッドなら、代入すべき変数に入力信号ｄａｔａ＿ｉｎを代入
〈５〉ライトメソッドなら、出力すべき値または変数を出力信号ｄａｔａ＿ｏｕｔに代入
〈６〉クロック境界×ｍｂｆ、を行う。ここで、ｎｂｆ＋ｍｂｆ＝ｋｂ１である。この例では、ｎｂｆ＝ｍｂｆ＝１とする。
バースト転送の場合、転送終了では、
〈１〉クロック境界挿入×ｎ、を行う。ここで、ｎ＝ｋｂ３である。ここでは、ｎ＝１とする。
バースト転送の場合、それ以外では、
〈１〉出力信号ｉｎｉｔに１を代入
〈２〉アクセスするデバイスのアドレスと共有レジスタのアドレスを連結して出力信号ａｄｄｒｅｓｓに代入
〈３〉クロック境界挿入×ｎｂ
〈４〉リードメソッドなら、代入すべき変数に入力信号ｄａｔａ＿ｉｎを代入
〈５〉ライトメソッドなら、出力すべき値または変数を出力信号ｄａｔａ＿ｏｕｔに代入
〈６〉クロック境界×ｍｂを行う。ここで、ｎｂ＋ｍｂ＝ｋｂ２である。この例では、ｎｂ＝０、ｍｂ＝１とする。
シングル転送の場合、
〈１〉アクセスするデバイスのアドレスと共有レジスタのアドレスを連結して出力信号ａｄｄｒｅｓｓに代入
〈２〉クロック境界挿入×ｎｓ
〈３〉リードメソッドなら、代入すべき変数に入力信号ｄａｔａ＿ｉｎを代入
〈４〉ライトメソッドなら、出力すべき値または変数を出力信号ｄａｔａ＿ｏｕｔに代入
〈５〉クロック境界挿入×ｍｓ、を行う。ここで、ｎｓ＋ｍｓ＝ｋｓである。
▲３▼出力信号ｓｔａｒｔ＿ｃｏｍｍに０を代入する。
３）バスアクセスメソッドを表す孤立ノードを作成し、置き換えて生成したＢａｓｉｃ Ｂｌｏｃｋとの通信ノードを設ける。通信ノードとして、
ｓｔａｒｔ＿ｃｏｍｍ：Ｂａｓｉｃ Ｂｌｏｃｋ→孤立ノード
ｂｕｓ＿ｃｍｄ：Ｂａｓｉｃ Ｂｌｏｃｋ→孤立ノード
ａｄｄｒｅｓｓ：Ｂａｓｉｃ Ｂｌｏｃｋ→孤立ノード
ｄａｔａ＿ｉｎ：孤立ノード →Ｂａｓｉｃ Ｂｌｏｃｋ
ｄａｔａ＿ｏｕｔ：Ｂａｓｉｃ Ｂｌｏｃｋ→孤立ノード、を設ける。
第８６図及び第８７図には変形後のＣｏｍｍａｎｄ ＩｎｔｅｒｆａｃｅのＣＦＧの一部が示される。第８７図において、クロック境界の傍らに記載された変数はパラメータであり、その数だけクロック境界を生成することを意味する。
孤立ノードへのＣＦＧの割り当てに関しては、第８８図のＣＦＧを自動生成する。第８８図において、特に、ＡＤ＿ＢＵＳはアドレスバスを、Ｄ＿ＢＵＳはデータバスを表し、ｄａｔａ＿ｉｎ＿ｅｎ＿ｉはデータ入力ステージを、ｄａｔａ＿ｏｕｔ＿ｅｎ＿ｉはデータ出力ステージを表す。ここで、ｉは各デバイスのインデックスを表す。また、アドレスバスのバス幅は、割り当てたバスコマンドのビット幅とアドレスのビット幅の合計とし、データバスはアクセスするレジスタのビット幅とする。また、クロック境界の傍にかかれた変数はパラメータであり、その数だけクロック境界を生成する事を意味する。尚、各変数の値は、ＣＦＧの変形過程で用いた変数の値と等しい。
共有レジスタに関しては、第８９図の記述をインライン展開したものに対応するＣＦＧの生成を行えばよい。但し、入出力変数であるＡＤ＿ＢＵＳ、Ｄ＿ＢＵＳの入力、出力への分離は行わず、またＣＦＧ上での最適化に於いては、ＡＤ＿ＢＵＳ、Ｄ＿ＢＵＳに対する変数最適化は実施しないものとする。第８９図、第９０図及び第９１図には共有レジスタに関する擬似Ｃ記述である。サイクルアキュレートな記述からのＨＤＬ生成に関しては本発明者による先の出願（特願２００２−３０００７３）を参照することができる。
以上本発明者によってなされた発明を実施形態に基づいて具体的に説明したが、本発明はそれに限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは言うまでもない。
例えば、積オートマトンの構成に関しては、ＴＮＦＡ積オートマトンを構成するとき、遷移枝の通過回数でＡｓｓｕｍｅ Ｇｕａｒａｎｔｅｅ Ｒｅａｓｏｎｉｎｇを実施したが、本来は、ｓｙｎｃ動作の通過回数で行うべきである。理由は、ｓｙｎｃ動作はバスアクセス動作を意味しており、並列に動いているＴＮＦＡが何回ｓｙｎｃ動作を実施したかは、そのＴＮＦＡに対応するデバイスがバスアクセスを何回行ったかに対応するからであり、Ｒｅｆｉｎｅｍｅｎｔ及びパラメトリック・モデルチェッキングで得られるのは、遷移サイクルの条件のみならず、その検証性質を実施している間に各デバイスが高々どれだけバスアクセスを行うかの情報も得られるからである。但し、この手法であると、組み合わせ爆発を起し得るので、何らかの高速な枝切りが必要となる。
積オートマトンの構成に関しては、今回は、パラメトリック・モデルチェッキングの停止性を吟味せず、バウンデッド・モデルチェッキングとして、検証性質を満たす必要条件を求める事を行ったが、本来は十分を求める必要がある。その為、アルゴリズムの停止性に関する研究を更に行う必要がある。
バスモデルの拡張に関しては、単一双方向バスのみではなく、単方向バスや、ローカルバスを含むもの、またバス・ブリッジを介してバスが階層化されているような複数バスシステムを扱うようにしてもよい。
また、水平帰線期間のみを扱ったが、本来は垂直帰線期間もモデル化して、１フレームを表示している間に最低１フレーム分の描画が終了するための十分条件を求める必要がある。
《設計方法の全体》
第１図には設計方法の全体が示される。設計対象とされるシステムはジャバ言語による記述（ジャバ言語記述）でモデル化される（Ｓ１）。ジャバ言語記述によるモデル化では、単一バス上のデバイスをジャバ言語のｒｕｎ（）メソッドを用いて記述する。ｒｕｎ（）メソッドはマルチスレッドを構成するスレッドにおいて実行させたいプログラムコードがその（）内に記述される。クロックはバリア同期を用いて実現される。一般的にバリア同期とは複数のモジュールからのデータを受信する場合に同時刻に処理されるべき全てのデータを待つための同期手法として把握することができる。
次いで、Ｓ１で生成されたジャバ言語記述（ジャバコード）１を読み込み、中間表現に変換する（Ｓ２）。ここで、中間表現２は、コンカレントなコントロール・フロー・グラフ（以下、Ｃ−ＣＦＧ）、コンカレントなパラメータ付き時間オートマトン（以下、Ｃ−ＴＮＦＡ）、パラメータ付き時間オートマトン（以下、ＴＮＦＡ）からなる。ＣＦＧ（コントロール・フロー・グラフ）は一般に関数内部において制御の流れを示すグラムを意味する。ＴＮＦＡ（オートマトン）とは、有限の種類の入力を離散的な時刻に受け、過去から現在までに入力された入力の系列を、回路で決まった個数以下のクラスに分類して記憶し、それに基づいて有限の種類の出力を出す回路の論理的なモデルとして把握することができる。
中間表現２として得られたＴＮＦＡとＲＰＣＴＬ（Ｒｅａｌ Ｔｉｍｅ Ｐａｒａｍｅｔｒｉｃ Ｃｏｍｐｕｔａｔｉｏｎ Ｔｒｅｅ Ｌｏｇｉｃ）３で記述された実時間制約を読み込み、パラメトリック・モデル・チェッキングを実行し（Ｓ３）、入力ＲＰＣＴＬ等を満たすパラメータ条件４を導出する。
満足するパラメータ条件がなければ方式変更を行いジャバ言語記述を修正し、満足するパラメータ条件があれが、そのパラメータ条件をサイクル制約として、Ｃ−ＣＦＧを読み込んで高位合成（Ｓ４）によりＨＤＬ（ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）による回路記述５へ変換する。回路記述は例えばＲＴＬ（Ｒｅｇｉｓｔｅｒ Ｔｒａｎｓｆｅｒ Ｌｅｖｅｌ）である。
上記開発方法はそれを実現するためのプログラムをコンピュータ装置で実行することによって行なわれる。ジャバ言語記述からＨＤＬを得る為の開発支援プログラムはディジタル回路の設計支援プログラムとして位置付けることができる。
本設計手法により、単一バスシステムの上流工程でのモデル化、検証が可能となり、かつ実時間制約を満たすハードウェアの設計自動化が可能となる。上流工程での検証が可能なのは、設計対象システムはジャバ言語記述でモデル化され、その記述自身が実行可能にされるからである。
《ジャバ言語によるモデル化に対する制約》
ジャバ言語によるモデル化に際してのジャバ言語記述とバスシステムに対する制約について説明する。単一バス・システムのジャバ言語によるモデル化を目的とするため、ジャバ言語記述に対し、
１）ダイナミック・インスタンシエーションの禁止、
２）ｒｕｎ（）メソッドからのｓｔａｒｔ（）メソッドコールの禁止、
の制約を置く。制約１）はＬＳＩのプロセス変更に関するものであり、ここではハードウェアを扱っている事から、許容可能な制約であると考えられる。また、制約２）はバス・プロトコルの検証を目的とする限りに於いては、直接バス動作に関わる部分のみをモデル化すれば良い為、許容可能な制約であると考えられる。
また、パラメトリック・モデルチェッキング・ツールの制約から、モデルに対して、
３）単一双方向バス・システム、
４）バス権制御は固定優先度
５）バス上の各デバイスは一定周期で処理を終了、の制約を課す。上記制約の緩和は新たな課題として位置付けられる。
《ジャバ言語によるモデル化の為のデザインパターン》
第２図には単一バス・システムのジャバ言語によるモデル化の為のデザインパターンが例示される。単一バス・システムのジャバ言語によるモデル化はＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）で与えられる第２図のデザインパターンに沿って記述される。バス上の各デバイス動作をＤｅｖｉｃｅＩｍｐｌ Ｃｌａｓｓ内のｒｕｎ（）メソッドに実装し、バスを介してアクセスがあるデバイス内レジスタはＲｅｇｉｓｔｅｒ Ｃｌａｓｓ内のａｔｔｒｉｂｕｔｅ（属性）として実装し、バスを介しての同期通信メソッドをＲｅｇｉｓｔｅｒ Ｃｌａｓｓのメソッドとして実装する。また、バスに対応するＢｕｓ Ｃｌａｓｓ、バスのロック管理を行うＢｕｓＣｏｎｔｒｏｌｌｅｒ Ｃｌａｓｓ、及びクロック同期を管理するＣｌｏｃｋ Ｃｏｎｔｒｏｌｌｅｒ Ｃｌａｓｓを実装する。バスのロック管理とはバスアービトレーションの制御を意味する。第２図の標記において、棒線を付した三角記号△は継承を意味し、例えばＤｅｖｉｃｅＩｍｐｌ ＣｌａｓｓはＤｅｖｉｃｅ Ｃｌａｓｓの子クラスであり、ＤｅｖｉｃｅＩｍｐｌ ＣｌａｓｓはＤｅｖｉｃｅ Ｃｌａｓｓのメソッドを使用可能である。記号→はユース（ｕｓｅ）を意味し、例えばＤｅｖｉｃｅ ＣｌａｓｓはＣｌｏｃｋ Ｃｏｎｔｒｏｌｌｅｒ Ｃｌａｓｓのメソッドを利用する。
尚、ジャバ言語コードの再利用性を高めるため、下記方針
１）デバイスの追加・削除（ＤｅｖｉｃｅＩｍｐｌ Ｃｌａｓｓの追加・削除）、
２）デバイス動作の変更（ＤｅｖｉｃｅＩｍｐｌ Ｃｌａｓｓのｒｕｎ（）メソッドの変更）、
３）共有変数の追加・削除（Ｒｅｇｉｓｔｅｒ Ｃｌａｓｓのａｔｔｒｉｂｕｔｅの追加・削除）、
４）バスプロトコルの追加・変更（Ｒｅｇｉｓｔｅｒ Ｃｌａｓｓの同期通信メソッドの追加・変更）、
にて、ジャバ言語コードの変更が可能となるようデザイン・パターンを定義している。
第２図のデザインパターンにおける各クラス（Ｃｌａｓｓ）について説明する。
（１）Ｄｅｖｉｃｅクラス
デバイスに共通の要素をまとめた抽象クラスである。レジスタやバスは複数ある場合でも処理内容自体が異なることはないため、同じクラスオブジェクトを複数生成ことにより複数存在することを表現できるが、デバイスはデバイスごとにその処理内容が異なる。よって、並列動作を行なうためにＴｈｒｅａｄクラスを継承し、Ｃｌｏｃｋ ｃｏｎｔｒｏｌｌｅｒ Ｃｌａｓｓのインスタンス、Ｒｅｇｉｓｔｅｒ Ｃｌａｓｓのインスタンス、Ｂｕｓ Ｃｌａｓｓのインスタンスを表すメンバ変数、各デバイスがアクセス可能な共有レジスタの情報を登録する為のメンバ変数、及び各デバイスがアクセス可能な共有レジスタの情報を登録する為のメソッドといったようなデバイスに共通な要素をまとめたクラスとしてＤｅｖｉｃｅクラスを実装する。
（２）ＤｅｖｉｃｅＩｍｐｌクラス
実際のデバイスにあたるクラスである。デバイスはデバイスごとに処理内容が異なるため、デバイスに必要な要素をまとめたＤｅｖｉｃｅクラスを継承し、その処理内容を記述する。つまり、Ａという処理を行なうＤｅｖｉｃｅＩｍｐｌＡクラス、Ｂという処理を行なうＤｅｖｉｃｅＩｍｐｌＢクラスといったように処理ごとにＤｅｖｉｃｅクラスの実装クラスが存在することになる。
（３）Ｒｅｇｉｓｔｅｒクラス
共有レジスタに対応するクラスである。レジスタの値を表すメンバ変数と、その値をリード／ライトするメソッドから成る。
（４）Ｂｕｓクラス
バスに対応するクラスである。バスが使用中であるか否かの状態を表すメンバ変数、そのバスに繋がっている共有レジスタをあらわすメンバ変数、及び、状態を変更するメソッドから成る。
（５）ＢｕｓＣｏｎｔｒｏｌｌｅｒクラス
バスを介した共有レジスタへのアクセス時のバスロックとバスのロック解放を行なうクラスである。バスのロック・ロック解放はこのクラスに対して依頼する。特に、バスに対して１つデバイスがアクセスを行うとフラグ変数を１に設定するメソッドを含む。このフラグをバスアクセス・フラグとしてメンバ変数として持ち、このメンバ変数により、同一クロック内での複数回のバスロック動作を回避している。
（６）ＣｌｏｃｋＣｏｎｔｒｏｌｌｅｒクラス
クロック管理クラスである。バスシステム上の各デバイスにクロック同期動作を行なわせるために、１クロック分の処理終了の通知を集め、全デバイスの処理終了が認められたら、次のクロックの処理を行なってよいという通知を行うと同時にＢｕｓＣｏｎｔｒｏｌｌｅｒ Ｃｌａｓｓのバスアクセス・フラグを０にリセットする。
《モデル化におけるクロック同期メカニズム》
クロック同期メカニズムについて説明する。第３図に示すバリア同期によるクロック同期メソッドを用いて、クロックを実現する。具体的には、１クロック分の処理終了の通知を集め、全デバイスの処理終了が認められたら、次のクロックの処理を行なってよいという通知を行う。
また、バスのロックが残っていない場合には、Ｂｕｓ Ｃｌａｓｓのバスアクセス・フラグを０にリセットする。尚、クロック遷移はパラメトリック・モデル・チェッキングへの入力に際して、パラメータ化される為、必ずしも１クロック単位であるとは限らない。
このクロック遷移のパラメータ化により、サイクル精度でのモデル化よりも抽象度の高いモデル化を実現する。
レジスタへの値書き込みには１クロックを要する為、それを実現する必要がある。これは、ｃｏｎｓｕｍｅ＿１＿ｃｌｏｃｋメソッド内で、第４図に例示されるＲｅｇｉｓｔｅｒ ＣｌａｓｓのａｓｓｉｇｎＷｒｉｔｅＶａｌｕｅメソッドをコールする事で実現している。
《モデル化におけるバス権獲得メカニズム》
バス権管理の同期メカニズムとして、先ずバス権獲得メカニズムについて説明する。バス権獲得メカニズムは、第５図に示すメソッドにより、バス権獲得を管理する。バス権の要求はｇｅｔＢｕｓＬｏｃｋメソッドにより行う。第６図には第５図の各メソッドの呼び出し関係を表すコールグラフが示される。第７図及び第８図には上記バス権獲得メカニズムのジャバ言語記述が例示される。
《モデル化におけるバス権解放メカニズム》
次にバス権解放メカニズムについて説明する。バス権解放メカニズムは第９図にに示すメソッドにより、バス権解放を管理する。バス権の解放はｆｒｅｅＢｕｓＬｏｃｋメソッドにより行う。第１０図には第９図の各メソッドの呼び出し関係を表すコールグラフが示される。第１１図には上記バス権解放メカニズムのジャバ言語記述が例示される。
《モデル化における排他的同期リード・メソッド》
バスへの排他的同期アクセス方式として、排他的同期リード・メソッドについて説明する。排他的同期リード・メソッドには以下のシングルリードとバーストリードがある。シングルリードはｓｙｎｃ＿ｒｅａｄメソッドをｒｕｎ（）でコールする事で実現される。バーストリードは、ｓｙｎｃ＿ｂｕｒｓｔ＿ｒｅａｄ、ｅｎｄＢｕｒｓｔＡｃｃｅｓｓ、ｃｏｎｓｕｍｅ＿ｃｌｏｃｋメソッドをｒｕｎ（）の、ｓｙｎｃｈｒｏｎｉｚｅｄブロック内で用いる事で実現される。
第１２図にはｓｙｎｃ＿ｒｅａｄメソッドのジャバ言語コード、第１３図にはｒｕｎ（）でのｓｙｎｃ＿ｒｅａｄメソッド記述例が示される。ｒｕｎ（）での記述例に現れる未定義メソッド、即ち、ｄｏ＿ｓｏｍｅｔｈｉｎｇ＿ｗ＿ｏｒ＿ｗｏ＿ｃｌｏｃｋ＿ｂｏｕｎｄａｒｙ（）はクロック境界を含んでもよい何らかの処理を意味し、ｄｏ＿ｓｏｍｅｔｈｉｎｇ＿ｗｏ＿ｃｌｏｃｋ＿ｂｏｕｎｄａｒｙ（）はクロック境界を含まない何らかの処理を意味する。
第１４図にはｓｙｎｃ＿ｂｕｒｓｔ＿ｒｅａｄのジャバ言語コード、第１５図にはｅｎｄＢｕｒｓｔＡｃｃｅｓｓのジャバ言語コード、第１６図にはｆｒｅｅＢｕｒｓｔＢｕｓＬｏｃｋのジャバ言語コード、第１７図にはｒｕｎ（）でのバーストリードの記述例が示される。バーストリードでは、バスのロックはコールする度に重ねて獲得し、バスの解放を行わないで値を返す。そして、バーストリード回数のリードが終了すると、重ねたロックを一気に解放するという実装方法となっている。この実装により、毎サイクル、リード値が返ってくるというバースト動作を実現している。
《モデル化における排他的同期ライト・メソッド》
バスへの排他的同期アクセス方式として、排他的同期ライト・メソッドについて説明する。排他的同期ライト・メソッドには以下のシングルリードとバーストリードがある。シングルライトはｓｙｎｃ＿ｗｒｉｔｅメソッドをｒｕｎ（）でコールする事で実現される。バーストライトはｓｙｎｃ＿ｂｕｒｓｔ＿ｗｒｉｔｅ、ｅｎｄＢｕｒｓｔＡｃｃｅｓｓ、ｃｏｎｓｕｍｅ＿ｃｌｏｃｋメソッドをｒｕｎ（）の、ｓｙｎｃｈｒｏｎｉｚｅｄブロック内で用いる事で実現される。
第１８図にはｓｙｎｃ＿ｗｒｉｔｅのジャバ言語コードが示され、第１９図にはｒｕｎ（）でのｓｙｎｃ＿ｗｒｉｔｅメソッド記述例が示される。
第２０図にはｓｙｎｃ＿ｂｕｒｓｔ＿ｗｒｉｔｅのジャバ言語コードが示され、第２１図にはｒｕｎ（）でのバーストライトの記述例が示される。バーストライトでは、バスのロックはコールする度に重ねて獲得し、書き込み処理終了後バスの解放を行わないで処理を終了する。そして、バーストライト回数のライトが終了すると、重ねたロックを一気に解放するという実装方法となっている。この実装により、毎サイクル、ライト値が書き込めるというバースト動作を実現している。
《ジャバ言語記述による実装例》
ジャバ言語記述による実装例を説明する。第２２図には実装例の概略仕様が示される。ここでは、共有メモリ方式の２次元グラフィックス描画・表示システムを一例とする。同図に示されるシステムは、コマンドインタフェース（Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ）、ユニファイドメモリ（Ｕｎｉｆｉｅｄ Ｍｅｍｏｒｙ）、グラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）、及び表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）を有し、それらは双方向バス（Ｓｉｎｇｌｅ ｂｉ−ｄｅｒｅｃｔｉｏｎ Ｂｕｓ）に共有する。
（１）Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅは、外部からの描画コマンドを受付け、バスを介して受け付けた描画コマンドをメモリへ転送する。
（２）Ｕｎｉｆｉｅｄ Ｍｅｍｏｒｙは、描画コマンド、描画ソースデータ、表示データを一元的に格納するメモリである。システムの低コスト化・部品点数削減に効果大。モデルを単純化する為、Ｊａｖａでは配列で表現する。本デバイスはスレーブデバイスである。
（３）Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔは、Ｕｎｉｆｉｅｄ Ｍｅｍｏｒｙに描画コマンドがあるかをボーリングで調べ、存在する場合は、描画コマンド、描画データをバスを介してリードしながら描画処理を行い、描画結果を内部バッファに格納し、一気にＵｎｉｆｉｅｄ Ｍｅｍｏｒｙへバースト転送する。モデルを単純化する為、描画コマンド、描画データ転送は配列への連続アクセスで実現する。
（４）Ｄｉｓｐｌａｙ Ｕｎｉｔは、表示データをリードしながら１ラインずつ表示を行う。モデルを単純化する為、垂直同期はモデル化しない。また、水平帰線期間はバスアクセスを行わないものとする。
上記コマンドインタフェース（Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ）、グラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）、及び表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）がバスマスタデバイスであり、ユニファイドメモリ（Ｕｎｉｆｉｅｄ Ｍｅｍｏｒｙ）がバススレーブデバイスである。バスマスタデバイスが同時にバス権獲得を行った場合の、バス権獲得の優先順位は、表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）＞コマンドインタフェース（Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ）＞グラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）とする。
次に、第２２図の仕様に対するｒｕｎ（）ｍｅｔｈｏｄの実装例について説明する。
（１）Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ
先ず、コマンドインタフェースに関するｒｕｎ（）ｍｅｔｈｏｄの実装例を説明する。その実装例は第２３図乃至第２６図に例示される。外部入力ｗｒｉｔｅ＿ｒｅｑ信号（具体的にはＣＰＵからのライト信号）があり且つｗａｉｔ出力信号の値決定に用いる内部変数ｗａｉｔ＿ｆｌａｇがｆａｌｓｅだとコマンド受付を実行（一定サイクル消費）し、その後に先ずｗａｉｔ＿ｆｌａｇ変数をｔｒｕｅとする。次いで、バス権取得を試み、取得できたらＵｎｉｆｉｅｄ Ｍｅｍｏｒｙのコマンドフラグ０，１をｓｙｎｃ＿ｂｕｒｓｔ＿ｒｅａｄで読み出し、値が０（描画コマンド処理済み）であるコマンドフラグに対応するメモリ領域に対して、バス権を取得した状態のままで、ｓｙｎｃ＿ｂｕｒｓｔ＿ｗｒｉｔｅを実行し、コマンドフラグ、描画コマンド、描画ソースデータを転送し、ｗａｉｔ＿ｆｌａｇ変数をｆａｌｓｅとする。但し、モデル簡略化の為、例えコマンドフラグが両方とも０であっても、コマンドフラグ０に対応するメモリ領域へのｓｙｎｃ＿ｂｕｒｓｔ＿ｗｒｉｔｅによる書き込みのみを実行するものとし、描画ソースデータの転送は省略する。
ｗｒｉｔｅ＿ｆｌａｇ変数がｔｒｕｅで、ｗｒｉｔｅ＿ｒｅｑ入力信号がｔｒｕｅの場合のみ、ｗａｉｔ信号をｔｒｕｅとし、それ以外はｗａｉｔ信号をｆａｌｓｅとする。特に、コマンド受付実行中はｗａｉｔ＿ｆｌａｇ変数をｆａｌｓｅとする。尚、ｗａｉｔ信号、ｗａｉｔ＿ｆｌａｇ変数ともに初期値はｆａｌｓｅとする。
また、Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅが受け付けるコマンドは、コマンドフラグ、描画コマンド、描画ソースデータ、テクスチャデータの格納開始・終了アドレスからなっており、テクスチャデータの格納開始・終了アドレスは描画コマンドに含まれているものとする。
（２）Ｕｎｉｆｉｅｄ Ｍｅｍｏｒｙ
ユニファイドメモリに関するｒｕｎ（）ｍｅｔｈｏｄの実装例を説明する。その実装例は第２７図に例示される。グラフィックス描画コマンド、描画ソース・グラフィックス・データ、描画後の表示用データを一元的に格納しているメモリ。モデル化を簡略化する為、何も実行しないスレッドとして実現。このメモリの実体はＲｅｇｉｓｔｅｒ Ｃｌａｓｓのインスタンスとしてｒｕｎ（）メソッド内でアローケートされている。
尚、モデル簡略化の為、メモリ配列を下記
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［０］：コマンドフラグ０、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［１］：描画コマンド０、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［２］：コマンドフラグ１、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［３］：描画コマンド１、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［４］：描画ソース・データ、及び描画後の表示用データ、の構造としている。
実際には、描画ソース・データと描画後の表示データを格納している配列のなすメモリ空間を２分し（一方をＢｕｆｆｅｒ０、他方をＢｕｆｆｅｒ１とする）、フレーム表示毎にメモリ配列を、
（Ｂｕｆｆｅｒ０，Ｂｕｆｆｅｒ１）＝（描画ソース・データ，描画後の表示用データ）（Ｂｕｆｆｅｒ０，Ｂｕｆｆｅｒ１）＝（描画後の表示用データ，描画ソース・データ）となるように、交互に切り替えているとする。従って、描画ソース・データを描画後の表示用データで上書きする事はないとする。更に、モデル簡略化の為、描画ソース・データの転送は省略する。
また、モデル簡略化の為に、テクスチャ・データは省略しており、描画コマンドも最高で２つしか格納しないものとし、コマンド０，１の実行順番がどうであっても描画結果には影響しないものとする。
（３）Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ
グラフィック描画ユニットに関するｒｕｎ（）ｍｅｔｈｏｄの実装例を説明する。その実装例は第２８図乃至第３２図に例示される。Ｕｎｉｆｉｅｄ Ｍｅｍｏｒｙのコマンドフラグ０，１をある一定周期毎にｓｙｎｃ＿ｂｕｒｓｔ＿ｒｅａｄにより読み出す（バス権獲得・解放動作）。何れか一方の値が１であった場合、内部状態変数ｒｅｎｄｅｒ＿ｓｔａｒｔをｔｒｕｅとし、バス権獲得を試み、獲得に成功したなら、描画コマンド、描画データをｓｙｎｃ＿ｂｕｒｓｔ＿ｒｅａｄで読み込みながら、描画処理を実行し、描画結果を内部バッファに書き込む（読み込み終了次第、コマンドフラグを０にクリアし、バス権解放する）。但し、モデル簡略化の為、例えコマンドフラグが両方とも０であっても、コマンドフラグ０に対応する描画コマンドのみを実行するものとし、描画ソースデータの転送は省略する。再び、バス権獲得を試み、獲得に成功したなら、描画結果をｓｙｎｃ＿ｂｕｒｓｔ＿ｗｒｉｔｅでＵｎｉｆｉｅｄ Ｍｅｍｏｒｙへ転送し、バス権を解放し、内部状態変数ｒｅｎｄｅｒ＿ｓｔａｒｔをｆａｌｓｅとする。尚、内部状態変数ｒｅｎｄｅｒ＿ｓｔａｒｔの初期値はｆａｌｓｅである。
（４）Ｄｉｓｐｌａｙ Ｕｎｉｔ
表示ユニットに関するｒｕｎ（）ｍｅｔｈｏｄの実装例を説明する。その実装例は第３３図及び第３４図に例示される。Ｕｎｉｆｉｅｄ Ｍｅｍｏｒｙから描画後の表示用データを読み込みＣＲＴへ出力する。但し、モデル簡略化の為、水平同期のみを扱うものとする。これは、水平帰線期間内に描画が開始・終了する為のサイクル制約をパラメトリック・モデルチェッキングで求める事を目的としているからである。
さて、Ｄｉｓｐｌａｙ Ｕｎｉｔは、内部変数ｄｉｓｐｌａｙ＿ｓｔａｒｔをｔｕｒｅに設定し、Ｕｎｉｆｉｅｄ Ｍｅｍｏｒｙから描画後の表示用データをｓｙｎｃ＿ｂｕｒｓｔ＿ｒｅａｄにて読み込む。データ読み込み終了後に内部変数ｄｉｓｐｌａｙ＿ｓｔａｒｔをｆａｌｓｅとして、ライン表示を実行し、ライン表示終了後から水平帰線期間に相当する適当なサイクルを消費し、再び、ライン表示を同じ手順で行うものとする。また、転送サイクルのみをモデル化すれば良いので、メモリアドレスは簡略的に表現し、常に同一メモリ空間から読み出しているものとする。
《パラメトリック解析》
ここでパラメトリック解析の目標について説明する。本来、描画は１フレーム表示の表示期間及び、垂直帰線期間の間に１フレーム分の実行を終了しておれば良いと考えられるので、水平帰線期間での描画が満たすべき性質を勘案すると、検証内容としては下記条件を満たすサイクル制約の導出で十分である。即ち、「表示用データ取得終了後に描画を開始し、次の表示開始までに描画を終了する事がある。但し、描画開始・終了にデータ転送サイクルは含まれ、表示はｎサイクル以内に終了する。」である。上記制約をＲＰＣＴＬ（Ｒｅａｌ Ｔｉｍｅ Ｐａｒａｍｅｔｒｉｃ Ｃｏｍｐｕｔａｔｉｏｎ Ｔｒｅｅ Ｌｏｇｉｃ）で記述すると下記
ＥＦ｛＜ｄｉｓｐｌａｙ＿ｅｎｄ＞（ＡＦ（＜ｒｅｎｄｅｒ＿ｂｅｇｉｎ＞ｔｒｕｅ）
＆＆｛ＡＦ（＜ｒｅｎｄｅｒ＿ｅｎｄ＞ｔｒｕｅ）ＡＵ（＜ｄｉｓｐｌａｙ＿ｂｅｇｉｎ＞ｔｒｕｅ）｝）｝
＆＆ ＡＧ｛［ｄｉｓｐｌａｙ＿ｂｅｇｉｎ］（ＡＦ＜＝ｎ（［ｄｉｓｐｌａｙ＿ｅｎｄ］ｔｒｕｅ））｝
の３個の制約のアンド条件となる。尚、表示データ取得終了迄に未実行の描画コマンドがＵｎｉｆｉｅｄ Ｍｅｍｏｒｙ上に常に存在する事が仮定できるものとする。ここで、ｎは適当な正整数であり、各変数は下記の通り、ｄｉｓｐｌａｙ＿ｂｅｇｉｎ：内部変数ｄｉｓｐｌａｙ＿ｓｔａｒｔの０から１への立ち上がりイベント
ｄｉｓｐｌａｙ＿ｅｎｄ：内部変数ｄｉｓｐｌａｙ＿ｓｔａｒｔの１から０への立ち下がりイベント
ｒｅｎｄｅｒ＿ｂｅｇｉｎ：内部変数ｒｅｎｄｅｒ＿ｓｔａｒｔの０から１への立ち上がりイベント
ｒｅｎｄｅｒ＿ｅｎｄ：内部変数ｒｅｎｄｅｒ＿ｓｔａｒｔの１から０への立ち下がりイベント
を表す。
パラメトリック・モデルチェッキングを高速化する目的で、ＲＰＣＴＬを
ＡＧ｛［ｄｉｓｐｌａｙ＿ｂｅｇｉｎ］（ＡＦ＜＝ｎ（［ｄｉｓｐｌａｙ＿ｅｎｄ］ｔｒｕｅ））｝ （＊）
と、それ以外の部分に分離し、例えば、
ＥＦ｛＜ｄｉｓｐｌａｙ＿ｅｎｄ＞（ＥＦ（＜ｒｅｎｄｅｒ＿ｂｅｇｉｎ＞ｔｒｕｅ）＆＆｛ＥＦ（＜ｒｅｎｄｅｒ＿ｅｎｄ＞ｔｒｕｅ）ＡＵ（＜ｄｉｓｐｌａｙ＿ｂｅｇｉｎ＞ｔｒｕｅ）｝）｝
から実行し、パラメータ条件を導出し、導出されたパラメータから（＊）のｎの上限を求め、既に求めたパラメータ条件に矛盾しないパラメータ条件が導出できるまで、ｎの値を減じて繰り返し、（＊）のパラメトリック解析を実施するものとする。
ＲＰＣＴＬやそれを用いたパラメトリック・モデルチェッキングの詳細は次の文献、“Ａｋｉｏ Ｎａｋａｔａ ａｎｄ Ｔｅｒｕｏ Ｈｉｇａｓｈｉｎｏ：”Ｄｅｒｉｖｉｎｇ Ｐａｒａｍｅｔｅｒ Ｃｏｎｄｉｔｉｏｎｓ ｆｏｒ Ｐｅｒｉｏｄｉｃ Ｔｉｍｅｄ Ａｕｔｏｍａｔａ Ｓａｔｉｓｆｙｉｎｇ Ｒｅａｌ−Ｔｉｍｅ Ｔｅｍｐｏｒａｌ Ｌｏｇｉｃ Ｆｏｒｍｕｌａｓ”，Ｐｒｏｃ．ｏｆ ＩＦＩＰ ＴＣ６／ＷＧ６．１ Ｉｎｔ’ｌ Ｃｏｎｆ．ｏｎ Ｆｏｒｍａｌ Ｔｅｃｈｎｉｑｕｅｓ ｆｏｒ Ｎｅｔｗｏｒｋｅｄ ａｎｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍｓ（ＦＯＲＴＥ２００１），Ｃｈｅｊｕ Ｉｓｌａｎｄ，Ｋｏｒｅａ，Ｋｌｕｗｅｒ Ａｃａｄｅｍｉｃ Ｐｕｂｌｉｓｈｅｒｓ，ｐｐ．１５１−１６６，Ａｕｇ．２００１．”に記載ある。
《中間表現への変換》
第３５図には中間表現へ変換工程の詳細が全体的に例示される。バスシステムをモデル化して記述されたジャバ言語記述はＣ（ｃｏｎｃｕｒｒｅｎｔ）−ＣＦＧに変換され（Ｊａｖａ２Ｃ−ＣＦＧ）、Ｃ−ＣＦＧはＣ−ＴＮＦＡに変換され（Ｃ−ＣＦＧ２Ｃ−ＴＮＦＡ）、Ｃ−ＴＮＦＡはＴＮＦＡに変換される（Ｃ−ＴＮＦＡ２ＴＮＦＡ）。パラメトリック・モデルチェッキングを経てＣ−ＣＦＧがＨＤＬに変換される（Ｃ−ＣＦＧ２ＨＤＬ）。尚、上記Ｊａｖａ２Ｃ−ＣＦＧ等の標記において、数字“２”は“ｔｏ”を意味するものと理解されたい。
《Ｊａｖａ２Ｃ−ＣＦＧ》
ジャバ言語記述からＣ−ＣＦＧへの変換アルゴリズムの概要を説明する。各ｒｕｎ（）メソッドに対応するＣＦＧを生成する。特に、クロック同期メソッド（ｃｏｎｓｕｍｅ＿ｃｌｏｃｋ）はクロック境界として識別し、呼び出しメソッドは呼び出し関係を表すノードを用いて表現する。各ｒｕｎ（）メソッドに対応するＣＦＧが生成されると、ｆｏｒｋノードを設け、そのノードから各ＣＦＧの開始ノードへのｆｏｒｋ枝を付加する。特に、バス上の各デバイスにｒｕｎ（）メソッドが対応するものとしてＪａｖａが記述されている事を前提とし、メモリデバイスに関しては、ＣＦＧ生成対象外である事の指定を与えるものとする。
次いで、呼び出しメソッドのＣＦＧを作成し、呼び出しメソッドがｓｙｎｃｈｒｏｎｉｚｅｄブロック内に存在する場合は、呼び出しメソッド内のｓｙｎｃｈｒｏｎｉｚｅｄをＣＦＧから削除する。特に、呼び出しメソッドがＲｅｇｉｓｔｅｒクラス内の通信メソッドである場合はＣＦＧの作成を行わず、インスタンス関係からどのデバイス内のどのレジスタへのアクセスかと通信メソッドの名前だけを識別し、その情報をＣＦＧに保持する。但し、図ではどのレジスタへのアクセスかの情報は省略している。尚、通信メソッドが内部にクロック同期メソッドを含む場合は、その出力枝にクロック境界をマークする。更に、呼び出しメソッド全体のサイクル制約を導出する以外は、呼び出しメソッドをインライニングする。この例では、Ｒｅｎｄｅｒｓｉｎｇメソッド、Ｄｉｓｐｌａｙメソッドはインライニングしない。
ｓｙｎｃｈｒｏｎｉｚｅｄを予め定めたＣＦＧに展開し、ハード合成用の固定優先度スケジューラをＦＳＭ（Ｆｉｎｉｔｅ Ｓｔａｔｅ Ｍａｃｈｉｎｅ）の形式でスケルトンとして予め与えてあるライブラリと実際にＣＦＧを生成したｒｕｎ（）メソッドの個数を用いて、自動生成する。ここで、ＣＦＧはハード合成用とパラメトリック・モデルチェッキング用の２種作成する。
尚、固定値伝播や、代入によるローカル変数消去等のコードレベル最適化をＣＦＧ上で実施する。特に、信号の入力・出力・入出力はメンバ変数で表し、端子方向に関しては、プログラム内での代入文で右辺にあるのか左辺にあるのかや条件文での変数の用いられ方を解析して決定する。入出力信号として識別された場合、データ依存性を考慮して、入力と出力に適当な信号のリネームを行って分離する。
Ｊａｖａ２Ｃ−ＣＦＧに関し、以下で、Ｊａｖａ記述例に沿って、各ｒｕｎ（）メソッドのＣＦＧ生成結果、Ｃ−ＣＦＧ生成結果、及び固定優先度・スケジューラのＦＳＭについて説明する。
先ずＣＦＧの形式について説明する。第３６図にはＣ−ＣＦＧの形式が例示される。各ＣＦＧは分岐枝の開始と終了を表すノードと、ループ枝の開始と終了を表すノードを含み、分岐条件、ループ終了条件を対応する枝に付加した形式とする。特に、クロック境界ノードを枝上に付加する事でクロック境界を表現する。また、メソッドコールに対応するノードを用いる事で、サブＣＦＧとのリンクを表現する。各ＣＦＧの並列実行を表すｆｏｒｋノードはＣＦＧへの頂点へ付加する事で表現する。
ｓｙｎｃｈｒｏｎｉｚｅｄの扱い（ハード合成用）について説明する。第３７図に例示されるように、ｓｙｎｃｈｒｏｎｉｚｅｄの開始をＣＦＧ上でｂｅｇｉｎ＿ｓｙｎｃとラベル付けされたノードとして表し、ｓｙｎｃｈｒｏｎｉｚｅｄの終了をｅｎｄ＿ｓｙｎｃとラベル付けされたノードでし、ＣＦＧを生成。その後、その両ノードを夫々下図に示すように変換する。
ｓｙｎｃｈｒｏｎｉｚｅｄの扱い（パラメトリック・モデルチェッキング用）について説明する。第３８図に例示されるように、ｓｙｎｃｈｒｏｎｉｚｅｄの開始をＣＦＧ上でＢｅｇｉｎ＿ｓｙｎｃとラベル付けされたノードとして表し、ｓｙｎｃｈｒｏｎｉｚｅｄの終了をＥｎｄ＿ｓｙｎｃとラベル付けされたノードでし、ＣＦＧを生成。その後、その両ノードを夫々第３８図に示すように変換する。
上記に従うと、前記Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅの場合、ＣＦＧは第３９図に示される。ｇｅｔＷｒｉｔｅＳｉｇｎａｌ（）メソッドは、シミュレーションを実施する為に行った記述であり、処理系への入力では外部からの入力信号ｗｒｉｔｅ＿ｒｅｑであるとして修正されているものとし、入力テストベクタの個数を表すｄｃｏｍ＿ｉｎｄｅｘを補正する記述も削除されているものとする。また、ｄｒａｗｉｎｇ＿ｃｏｍｍａｎｄｓも配列として表現されているが、これもシミュレーションを実施する為になされたものであり、内部変数ｉｎｐｕｔ＿ｃｏｍｍａｎｄに入力変数ｄｒａｗｉｎｇ＿ｃｏｍｍａｎｄｓが入力されている記述が処理系に入力されているのもとして扱う。
前記Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅに関し、ハード合成用のＣＦＧは第４０図に示され、パラメトリック・モデルチェッキング用のＣＦＧは第４１図に例示される。
前記グラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）に関し、第４２図及び第４３図にはそのＣＦＧが例示され、第４４図及び第４５図にはそのパラメトリック・モデルチェッキング用のＣＦＧが例示される。
前記表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）に関し、第４６図にはそのＣＦＧが例示され、第４７図にはそのパラメトリック・モデルチェッキング用のＣＦＧが例示される。
第４８図にはコマンドインタフェース（Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ）のＣＦＧ、グラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）のＣＦＧ、及び前記表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）のＣＦＧにおける夫々の開始ノードの結合状態が例示される。
固定優先度スケジューラ（Ｆｉｘｅｄ Ｐｒｉｏｒｉｔｙ Ｓｃｈｅｄｕｌｅｒ）について説明する。実際にトップレベルのＣＦＧを生成したｒｕｎメソッドの数を識別し、夫々のデバイスにバス権取得通知を行うための信号ｌｏｃｋｅｄ＿ｉの組みからなるステートを作成する。単一バスシステムであるため、それらステートは、１つのｌｏｃｋｅｄ＿ｉのみが１でその他が０であるものを構成すれば良い。また、全てのｌｏｃｋｅｄ＿ｉが０であるステートも作成する。優先度情報に基づき、バス権要求信号ｌｏｃｋ＿ｉを受けて行う状態遷移枝を設ければバス権管理用の固定優先度スケジューラが構成できる。特に、全てのｌｏｃｋｅｄ＿ｉが０であるステートをリセット解除時の開始ステートとする。また、各状態遷移は１＜＝ｔ＜＝ｋｌの時間制約が付加されているものとする。このパラメータは後のパラメトリック・モデルチェッキングで決定されるパラメータである。尚、例えば、ｋｌ＝２とし、各遷移を２クロック遷移とした場合は、出力値は変化が起こるまで、前の値を保持しているものとして解釈するものとする。
第４９図には本例に対応する固定優先度スケジューラが例示される。同図における信号の意味は、
ｌｏｃｋ＿１：Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅからのバス権要求信号
ｌｏｃｋ＿２：Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔからのバス権要求信号
ｌｏｃｋ＿３：Ｄｉｓｐｌａｙ Ｕｎｉｔからのバス権要求信号
ｌｏｃｋｅｄ＿１：Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅへのバス権取得通知信号
ｌｏｃｋｅｄ＿２：Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔへのバス権取得通知信号
ｌｏｃｋｅｄ＿３：Ｄｉｓｐｌａｙ Ｕｎｉｔへのバス権取得通知信号
である。尚、バス権取得の優先度が、
Ｄｉｓｐｌａｙ Ｕｎｉｔ＞Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ＞Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔであるので、遷移条件は、
ｌｏｃｋ＿３：Ｄｉｓｐｌａｙ Ｕｎｉｔへの遷移
！ｌｏｃｋ＿３＆＆ｌｏｃｋ＿１：Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅへの遷移条件
！ｌｏｃｋ＿３＆＆！ｌｏｃｋ＿１＆＆ｌｏｃｋ＿２：Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔへの遷移条件
ｏｔｈｅｒｗｉｓｅ：全てのｌｏｃｋｅｄ＿ｉが０であるステートへの遷移条件
となる。
《Ａｂｓｔｒａｃｔｉｏｎ ｏｆ ｅａｃｈ ＣＦＧ》
夫々のＣＦＧの抽象化処理について説明する。先ず、そのアルゴリズムの概要を説明する。各ＢａｓｉｃＢｌｏｃｋに対して、０＜＝ｔ＜＝ｋｉなる時間遷移条件を付加し、Ｂｅｇｉｎ＿ｓｙｎｃノードとＥｎｄ＿ｓｙｎｃノードに対して０＜＝ｔ＜＝ｋｌを付加し、通信メソッドを表すノードに対して、バースト開始に１＜＝ｔ＜＝ｋｂ１、バースト動作に０＜＝ｔ＜＝ｋｂ２、バースト終了に０＜＝ｔ＜＝ｋｂ３を付加する。但し、通信メソッドを表すノードに対しては、バースト開始が２サイクル以上、バースト動作時は１サイクル以上、バースト終了が１サイクル以上を要すると考え、後述のノードのマージによる抽象化を行う際には、サイクル制約の補正を行う。Ｂｅｇｉｎ＿ｓｙｎｃとＥｎｄ＿ｓｙｎｃノード以外の制約を付加したノードをクロック境界と見做して抽象化を行う。
通信メソッドは動作内容を全て抽象化し、連続する場合は、１つのノードにまとめ、例えばバースト開始（１＜＝ｔ＜＝ｋｂ１）、クロック境界（ｔ＝１）、（バースト動作（０＜＝ｔ＜＝ｋｂ２）＋クロック境界（ｔ＝１））３回、バースト終了（０＜＝ｔ＜＝ｋｂ３）、クロック境界（ｔ＝１）とすると、
６＜＝ｔ＜＝（ｋｂ１＋１−１）＋３（ｋｂ２＋１−１）＋（ｋｂ３＋１−１）＝ｋｂ１＋３ｋｂ２＋ｋｂ３（＞＝２＋３＊１＋１＝６）
なるサイクル制約を持つクロック境界として１つにまとめる。また、分岐ノードは全て非決定分岐であるとする。Ｂａｓｉｃ Ｂｌｏｃｋノードに関しては、入力ＲＰＣＴＬで用いる変数のみ残し他は抽象化する。分岐ノード下位に存在するＢａｓｉｃ Ｂｌｏｃｋに対応する部分が異なる分岐で同じ場合は、１つを残して他を削除する。
特にループノードに関しては、ｂｒｅａｋ、ｃｏｎｔｉｎｕｅを含まない固定回数ループの場合はアンローリングを実施し、それ以外の場合は、ループを抜ける条件枝の直前に全体で０＜＝ｔ＜＝ｋｌｏｏｐのサイクル制約を持つようなＣＦＧノードの集合を設ける事でループを削除する。ここで、ｋｌｏｏｐの満たすべき条件を別に算出するものとする。更に連続するクロック境界はパーコレーション・ベースの移動を行う事で、１つに纏め、遷移サイクル制約を更新する。
ここで、各クロック境界のパラメータ化により、クロック境界に与えた遷移サイクル制約の意味は、クロック境界から次のクロック境界への遷移に対するサイクル制約である。
コマンドインタフェース（Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ）のＣＦＧに対する抽象化の様子が順を追って第５０図乃至第５６図に例示される。第５７図にはグラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）のＣＦＧに対する抽象化処理の結果が例示される。第５８図には表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）のＣＦＧに対する抽象化処理の結果が例示される。
《Ｃ−ＣＦＧ２Ｃ−ＴＮＦＡ》
Ｃ−ＴＮＦＡからＴＮＦＡへの変換処理について説明する。ＴＮＦＡとは時間オートマトンであり、各遷移が、
ｓ−ａ＠？ｔ［Ｐ（ｔ）］−＞ｓ’
の形式で表されるものである。ここで、各記号の意味は、
ｓ，ｓ’：状態、
ａ：動作（省略可能）、
＠？ｔ：状態ｓを訪れてから動作ａを実行するまでの経過時間をｔに代入、Ｐ（ｔ）：時間制約（ｔに関する線形不等式の論理結合）、
である。また、その意味は「ｓからｔ単位時間経過後に状態ｓ’に遷移。ただし、ｔは時間制約Ｐ（ｔ）を満たす場合に限る」である。
Ｃ−ＴＮＦＡは、複数のＴＮＦＡが並列動作するモデルであり、動作ｓｙｎｃは高々１つのＴＮＦＡしか実行できないモデルである。特に連続する動作ｓｙｎｃに対しては他のＴＮＦＡが割り込めない。尚、各ＴＮＦＡに対して、初期状態から初期状態への遷移に対して、上限を与える為の時間制約を課す事が可能である。
次にＣ−ＣＦＧからＣ−ＴＮＦＡへの変換処理について説明する。先ず、その変換アルゴリズムの概要を説明する。Ｂｅｇｉｎ＿ｓｙｎｃ、Ｅｎｄ＿ｓｙｎｃで挟まれた部分を識別し、ｓｙｎｃブロックとする。Ｓｙｎｃブロック内に存在しないクロック境界ノードにステート割り当て候補とし、またｓｙｎｃブロック内であっても検証性質に必要となる信号がＢａｓｉｃ Ｂｌｏｃｋとして与えられている場合はその前後のクロック境界ノードにステートを割り当て候補とし、最後にＢｅｇｉｎ＿ｓｙｎｃ、Ｅｎｄ＿ｓｙｎｃの変換で導入したクロック境界をステート割り当て候補とする。得られたステート割り当て候補を重複が無いようにし、ステート割り当てを行い、各ステートからステートまでをＤＦＳ（Ｄｅｐｔｈ Ｆｉｒｓｔ Ｓｅａｒｃｈ）でトラバースする事でＴＮＦＡへの変換を行う。得られたＴＮＦＡに対して、ｓｙｎｃブロックに対応する遷移を検出し、ｓｙｎｃ遷移とする。連続するｓｙｎｃ遷移でない遷移は１つの遷移に纏める事でステート数の削減を行う。
コマンドインタフェース（Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ）のＣＦＧに対するＴＮＦＡへの変換の様子が順を追って第５９図乃至第６１図に例示される。
第６２図乃至第６５図にはグラフィック描画ユニット（Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ）のＣＦＧに対するＴＮＦＡへの変換の様子が順を追って例示される。第６５図において、検証性質は、「表示用データ取得終了後に描画を開始し、次の表示開始までに描画を終了する事がある。但し、描画開始・終了にデータ転送サイクルは含まれ、表示はｎサイクル以内に終了する。」であり、これは、描画が開始される事がもしあればという前提にたった検証性質であるから、Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔに対応するＴＮＦＡにおいて、表示データ取得終了迄に未実行の描画コマンドがＵｎｉｆｉｅｄ Ｍｅｍｏｒｙ上に存在しない事を表すＲ２からＲ１への遷移はこの検証には不要となる。従って、これは削除されている。
第６６図乃至第６８図には表示ユニット（Ｄｉｓｐｌａｙ Ｕｎｉｔ）のＣＦＧに対するＴＮＦＡへの変換の様子が順を追って例示される。
《Ｃ−ＴＮＦＡ２ＴＮＦＡ》
Ｃ−ＴＮＦＡからＴＮＦＡへの変換アルゴリズムの概要を説明する。先ず、下記方針（１）〜（５）に従ってＣ−ＴＮＦＡから積ＴＮＦＡを構成する。
（１）ｓｙｎｃ動作とそれ以外の動作は互いにインタリーブされる。ここで、ｓｙｎｃ動作を行っている間にバス権をとる必要が無い動作、即ちｓｙｎｃでない動作を（一般に複数）並行して実行できることを表現。但し、ｓｙｎｃ動作を１遷移実行する間の他のＴＮＦＡの並行遷移に遷移枝を通る回数に制限を設け、それを満たす各遷移の遷移時間の上限を導出する。特に、回数は１から始め、意味のある解が得られるまで、回数を１づつインクリメントするものとする。
（２）複数のｓｙｎｃ動作が実行可能な場合は静的優先度が最も高いものによって遷移する。ここで、動いていない状態ｓに関してはａｇｅ（ｓ，ｔ）（状態ｓで時間ｔだけが経過した状態）に遷移。ただし、連続するｓｙｎｃ遷移の間には他の動作は割り込めない。
（３）ａｇｅ（ｓ，ｔ）以降の遷移に関しては、時間ｔに関して下記補正を行う。即ち、ｓ−［Ｐ（ｔ１）］−＞ｓ’ならばａｇｅ（ｓ，ｔ）−［Ｐ（ｔ＋ｔ１）］−＞ｓ’［ｔ＋ｔ１／ｔ１］、とする。ここで、ｓ［ｅ／ｔ］：状態ｓからの遷移条件に現れる変数ｔを式ｅで置き換えることを表す。尚、再構成したＰ（ｔ）が矛盾した式になっている場合、その遷移は削除し、その遷移へのみ到達する状態全てを削除するものとする。
（４）各遷移の時間変数ｔは下記に示すように、異なる名前に変更する。即ち、ｓ−［Ｐ（ｔ）］−＞ｓ’−［Ｑ（ｔ）］−＞ｓ’’はｓ−［Ｐ（ｔ１）］−＞ｓ’−［Ｑ（ｔ２）］−＞ｓ’’に変更する。ａｇｅ（ｓ，ｔ）に関する補正によって、各遷移条件はそれ以前の遷移の時間変数も含む式になるため、それらを区別するために、この変更が必要となる。
（５）上限を与えたＴＮＦＡがある場合、構成後のＴＮＦＡでその初期状態を含む状態間の遷移がその上限を満たさない場合、その途中にある状態で上限を満たす遷移内に存在する状態を削除対象外とし、削除対象外とならなかった状態を削除する。
尚、Ａｂｓｔｒａｃｔｉｏｎ ｏｆ ｅａｃｈ ＣＦＧのステップで抽象化対象から除外されたＲＰＣＴＬに用いられている変数を伴う遷移が現れるとその次の状態まで構成し、上記構成方針での作成での切りの良いところで、Ａｂｓｔｒａｃｔｉｏｎ ｏｆ ＴＮＦＡをコールし、構成中のＴＮＦＡの抽象化を行う。
次にＣ−ＴＮＦＡからＴＮＦＡへの変換処理を詳細に説明する。先ず、遷移回数の仮定による遷移時間の上限を決定する。即ち、各ＴＮＦＡの強連結成分を求め、強連結成分内での遷移枝を１回のみ通る各遷移の下限遷移時間の総計が最大となる最長パスと、そのパス上の頂点でその後段の頂点への遷移時間の下限が最小の頂点を求め、最長パスにその後段頂点へのパスを追加したパスの２つを求める。次いで、夫々のパスの下限遷移時間の総計を求める。これにより、
Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ：２２ ２３
Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ：２８ ２９
Ｄｉｓｐｌａｙ Ｕｎｉｔ：１１ １２
が求まる。さて、各ＴＮＦＡの２つ目の下限遷移時間の総計から１引いた値、
Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ：２２
Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ：２８
Ｄｉｓｐｌａｙ Ｕｎｉｔ：１１
を求める。各ＴＮＦＡの各遷移の上限時間を、他のＴＮＦＡに対して求めた値の最小値を与える事で決定し、得られた時間遷移の上限値が矛盾したものとなっていないかを、既に上限が与えられている遷移の上限値と比較する事で調べ、もし、矛盾がでたなら２回に増加させる。そうでなければ、上限が与えられていない遷移に求めた上限を与える事で線形不等式の論理結合を構成する。特に、回数を増加させる場合、最長パスの下限遷移時間の総計と回数の積を取った値と、その値に先に求めた最小の遷移時間を加えた値を算出すればよい。
尚、パラメトリック・モデルチェッキングを実施し、パラメータ条件が非負整数解を持たない場合にも回数の増加を行って処理をすすめる事とする。ここで、非負整数解の算出には、線形計画法を用いる。具体的には、フリーソフトＬＰ−ＳＯＬＶを用いて得られたパラメータ条件を満たす範囲で、パラメータの和が最小となる解を算出する。仮に、得られた解が意味をなさない場合は、パラメータの最小値を付加するなどして対処する。
さて、本例の場合、遷移枝を一回のみ遷移可能とした仮定では、各ＴＮＦＡの遷移時間の上限として
Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ：１１
Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ：１１
Ｄｉｓｐｌａｙ Ｕｎｉｔ：２２
が求まる。また、矛盾が起こることなく、以下に示す線形不等式の論理結合、
０＜＝ｋ１＋ｋ２＋ｋｌｏｏｐ１＜＝７ ＆＆ ５＜＝ｋｂ１＋ｋｂ２＋ｋｂ３＋ｋｌ＜＝８ ＆＆ ７＜＝ｋｂ１＋３ｋｂ２＋ｋｂ３＋ｋｌ＜＝１１ ＆＆ １＜＝ｋｌ＜＝１１ ＆＆ １＜＝ｋ１＋ｋ２＋ｋ３＋ｋｌｏｏｐ１＋ｋｌ＜＝６ ＆＆ ３＜＝ｋ４＜＝１１ ＆＆ ５＜＝ｋｂ１＋ｋｂ２＋ｋｂ３＋ｋｌ＜＝１１ ＆＆ ６＜＝ｋｂ１＋４ｋｂ２＋ｋｂ３＋３ｋｒ１＜＝１２ ＆＆ １＜＝３ｋｒ２＋ｋｌ＜＝８ ＆＆ ９＜＝ｋｂ１＋５ｋｂ２＋ｋｂ３＋ｋｌ＜＝１２ ＆＆ ｋｒ１＝ｋｂ２−１ ＆＆ ８＜＝ｋｂ１＋５ｋｂ２＋ｋｂ３＜＝２４ ＆＆ １＜＝ｋｌ＋６ｋｄ＜＝１９
が得られる。また、遷移枝を２回まで遷移可能とした場合、各ＴＮＦＡの遷移時間の上限として
Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅ：２２
Ｇｒａｐｈｉｃｓ Ｒｅｎｄｅｒｉｎｇ Ｕｎｉｔ：２２
Ｄｉｓｐｌａｙ Ｕｎｉｔ：４４
が求まり、以下に示す線形不等式の論理結合、
０＜＝ｋ１＋ｋ２＋ｋｌｏｏｐ１＜＝１８ ＆＆ ５＜＝ｋｂ１＋ｋｂ２＋ｋｂ３＋ｋｌ＜＝１９ ＆＆ ７＜＝ｋｂ１＋３ｋｂ２＋ｋｂ３＋ｋｌ＜＝２２ ＆＆ １＜＝ｋｌ＜＝２２ ＆＆ １＜＝ｋ１＋ｋ２＋ｋ３＋ｋｌｏｏｐ１＋ｋｌ＜＝１７ ＆＆ ３＜＝ｋ４＜＝２ ＆＆ ５＜＝ｋｂ１＋ｋｂ２＋ｋｂ３＋ｋｌ＜＝２２ ＆＆ ６＜＝ｋｂ１＋４ｋｂ２＋ｋｂ３＋３ｋｒ１＜＝２３ ＆＆ １＜＝３ｋｒ２＋ｋｌ＜＝１９ ＆＆ ９＜＝ｋｂ１＋５ｋｂ２＋ｋｂ３＋ｋｌ＜＝２３ ＆＆ ｋｒ１＝ｋｂ２−１ ＆＆ ８＜＝ｋｂ１＋５ｋｂ２＋ｋｂ３＜＝４６ ＆＆ １＜＝ｋｌ＋６ｋｄ＜＝４１
が得られる。
この工程は、Ａｓｓｕｍｅ Ｇｕａｒａｎｔｅｅ Ｒｅａｓｏｎｉｎｇと呼ばれる手法であり、パラメトリック解析での実施は公知ではない。
第６９図には第６１図、第６４図、第６８図で求めたＴＮＦＡの積ＴＮＦＡの構成例が示される。これに基づいてＴＮＦＡを求める過程が第７０図乃至第７６図に示される。
《Ａｂｓｔｒａｃｔｉｏｎ ｏｆ ＴＮＦＡ》
ＴＮＦＡの抽象化処理について説明する。先ず、そのアルゴリズムの概要を説明する。ＴＮＦＡで抽象化時に残した変数への代入を行っている遷移枝と、その遷移枝の始点ノード及び終点ノードのみを残し、残すべき頂点を始点として、次に残すべき頂点が現れるまで頂点と辺をトラバースしながら遷移時間を再計算する事で、その他の頂点を全て抽象化する。但し、葉に対応する状態は抽象化の対象から除外する。
先の例では抽象化の実施がまだ起こらない段階までしかＴＮＦＡを構成しなかったので、抽象化が必要となる様先の例を意図的に若干修正して、第７７図乃至第７９図ににＣ−ＴＮＦＡ２ＴＮＦＡでＡｂｓｔｒａｃｔｉｏｎ ｏｆ ＴＮＦＡを適時コールした場合の処理の経過の一部を示す。ここでは、ｋｌには具体的な値は与えないものとする。
《パラメトリック解析結果》
前記文献に述べられているアルゴリズムを用いて、遷移を２回以上通らない制約で、探索深さ最大値１６として、以下の検証性質
ＥＦ（＜ｄｉｓｐｌａｙｅｎｄ＞（（ＡＦ（＜ｒｅｎｄｅｒｂｅｇｉｎ＞ｔｒｕｅ））ａｎｄ（（ＡＦ（＜ｒｅｎｄｅｒｅｎｄ＞ｔｒｕｅ））ＡＵ（＜ｄｉｓｐｌａｙｂｅｇｉｎ＞ｔｒｕｅ））））に関してパラメタ条件を導出すると、以下の条件、
０＜＝ｋｄ ＆＆ ０＜＝ｋｒ２ ＆＆ ０＜＝ｋｒ１ ＆＆ ０＜＝ｋｂ３ ＆＆ ０＜＝ｋｂ２ ＆＆ ０＜＝ｋｂ１ ＆＆ ０＜＝ｋｌｏｏｐ１ ＆＆ ０＜＝ｋ５ ＆＆ ４＜＝ｋ４ ＆＆ ０＜＝ｋ３ ＆＆ ０＜＝ｋ１ ＆＆ ０＜＝ｋ２ ＆＆ １２＜＝ｋｂ１＋９ｋｂ２＋ｋｂ３ ＆＆ ４ ＜＝ｋｌ）
を得る。これと先に求めた、遷移を２回以上通らないという制約から得られたパラメータ条件
０＜＝ｋ１＋ｋ２＋ｋｌｏｏｐ１＜＝７ ＆＆ ５＜＝ｋｂ１＋ｋｂ２＋ｋｂ３＋ｋｌ＜＝８ ＆＆ ７＜＝ｋｂ１＋３ｋｂ２＋ｋｂ３＋ｋｌ＜＝１１ ＆＆ １＜＝ｋｌ＜＝１１ ＆＆ １＜＝ｋ１＋ｋ２＋ｋ３＋ｋｌｏｏｐ１＋ｋｌ＜＝６ ＆＆ ３＜＝ｋ４＜＝１１ ＆＆ ５＜＝ｋｂ１＋ｋｂ２＋ｋｂ３＋ｋｌ＜＝１１ ＆＆ ６＜＝ｋｂ１＋４ｋｂ２＋ｋｂ３＋３ｋｒ１＜＝１２ ＆＆ １＜＝３ｋｒ２＋ｋｌ＜＝８ ＆＆ ９＜＝ｋｂ１＋５ｋｂ２＋ｋｂ３＋ｋｌ＜＝１２ ＆＆ ｋｒ１＝ｋｂ２−１ ＆＆ ８＜＝ｋｂ１＋５ｋｂ２＋ｋｂ３＜＝２４ ＆＆ １＜＝ｋｌ＋６ｋｄ＜＝１９
との論理積を取って、得られたパラメータ条件に対して、目的関数を各パラメタ値の合計として、これを最小化するという線形計画問題をフリーソフトＬＰ＿ＳＯＬＶＥにて解かせると、第８０図の解を得る。
第８０図の結果では、バスアクセス終了通知が０サイクルで行われなければならず、また、描画サイクルｋｒ２と表示サイクルｋｄが０であるので、意味のある解とは言えないので、ｋｂ１＝２，ｋｂ２＝１，ｋｂ３＝１の制約を追加し、第８１図の解を得た。
第８１図の結果でも、描画サイクルｋｒ２と表示サイクルｋｄが０であるので、意味のある解とは言えないので、ｋｂ１＝２，ｋｂ２＝１，ｋｂ３＝１の制約に加えてさらに、ｋｒ１以外のパラメタ変数は１以上という制約を追加し、第８２図の解を得た。以後、このパラメータ値を採用して議論を進める。
《ハード合成》
ハードウェア合成処理についてその概要を先ず説明する。（１）〜（１１）の方針にてハードウェアの生成が行なわれる。
（１）事前にＲｅｇｉｓｔｅｒクラスに登録された通信メソッドの種類からバスコマンドの割り当てを行う。
（２）ユーザ情報として、どのデバイスにどの共有レジスタが存在するかを受付け、各デバイス内のレジスタ数に対応するデバイス内アドレスを割り当てる。
（３）共有レジスタが割付られたデバイス（ｒｕｎ（）メソッド）の数を取得し、共有レジスタが割り当てられたデバイスにグローバルなアドレスを割り当てる。
（４）インライニング（展開）を実施しなかった通信メソッド以外のメソッドのインライニングを行う。（通信メソッドと指定したメソッド以外のメソッドは事前にインライニングされている事に注意。）
（５）パラメトリック解析結果から得られた、Ｂａｓｉｃ Ｂｌｏｃｋの実行サイクルを各デバイスの合成用ＣＦＧに反映する。
（６）各デバイス夫々のＣＦＧを変形し、通信メソッドとそれ以外のコントロールフロー部が互いに通信するモデルに変換する。
（７）前記（６）で得られた変換後のＣＦＧ内の通信メソッドに対応する部分に、バスコマンド生成記述を挿入する。通信メソッドは、グローバルアドレス、共有レジスタアドレス、バスコマンドを出力し、データ読み出し・書き込みの何れかを実行する記述からなるＣＦＧとなり、それらの信号生成・受理に要するサイクルは、パラメトリック解析の結果により決定される。
（８）共有レジスタアドレスから、各デバイス内のレジスタの配列インデックスを生成するアドレスデコーダとグローバル・アドレスを識別するアドレスデコーダを共有レジスタが割り当てられたデバイス内に生成し、出力トライステートを共有レジスタの出力に接続し、トライステート・イネーブル信号として、各デバイスからのデータ入力ステージを表す信号の論理和を用いる。共有レジスタの入力に関しては、取り込み動作が起こらない限り内部変数は前の値を保持する為バスから信号を接続すれば良よく、各デバイスからのデータ入力ステージを表す信号の論理和を元にデータ取り込み判定を行う。但し、これらはＣＦＧとして表現する。（自デバイス内に共有レジスタがあったとしても、この方式に従って、アクセスが行われているものとする。）
（９）変形等で得られた各ＣＦＧの信号通信関係（入力、出力）を識別し（バスは入出力）、夫々をモジュールとして識別する。
（１０）各ＣＦＧを「サイクルアキュレートなプログラム記述からのハード合成」に従って、ＨＤＬへと変換する。
（１１）バスに対してリピータ回路をＨＤＬの形式で挿入する。
前記バスコマンドの割り当てに関し、本例で登録したバスアクセス・メソッドは、ｓｙｎｃ＿ｒｅａｄ、ｓｙｎｃ＿ｗｒｉｔｅ、ｓｙｎｃ＿ｂｕｒｓｔ＿ｒｅａｄ、ｓｙｎｃ＿ｂｕｒｓｔ＿ｗｒｉｔｅ、ｅｎｄＢｕｒｓｔＡｃｃｅｓｓであるが、各ｒｕｎ（）メソッドのＣＦＧを解析すると、実際に用いられているバスアクセスメソッドは、ｓｙｎｃ＿ｂｕｒｓｔ＿ｒｅａｄ、ｓｙｎｃ＿ｂｕｒｓｔ＿ｗｒｉｔｅ、ｅｎｄＢｕｒｓｔＡｃｃｅｓｓであるため、バスコマンドを
ｓｙｎｃ＿ｂｕｒｓｔ＿ｒｅａｄ ２’ｂ００
ｓｙｎｃ＿ｂｕｒｓｔ＿ｗｒｉｔｅ ２’ｂ０１
ｅｎｄＢｕｒｓｔＡｃｃｅｓｓ ２’ｂ１０
ＮＯＰ ２’ｂ１１
のように割り当てる。
上記アドレス割り当てに関しては、共有レジスタはＵｎｉｆｉｅｄ Ｍｅｍｏｒｙにのみ割り付けられ、Ｕｎｉｆｉｅｄ Ｍｅｍｏｒｙの仕様から割り付けられた共有レジスタは
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［０］：コマンドフラグ０、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［１］：描画コマンド０、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［２］：コマンドフラグ１、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［３］：描画コマンド１、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［４］：描画ソース・データ、及び描画後の表示用データ、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［５］：描画ソース・データ、及び描画後の表示用データ、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［６］：描画ソース・データ、及び描画後の表示用データ、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［７］：描画ソース・データ、及び描画後の表示用データ、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［８］：描画ソース・データ、及び描画後の表示用データ、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［９］：描画ソース・データ、及び描画後の表示用データ、となる。尚、ユーザ情報から各レジスタのビット幅が指定されているものとし、それぞれ３２ビット（ｕｎｓｉｇｎｅｄ ｉｎｔ）であるとする。
バスアクセス・メソッドはレジスタ内のバイトアクセス等を行わないので、各レジスタのアドレスを
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［０］：４’ｂ００００、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［１］：４’ｂ０００１、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［２］：４’ｂ００１０、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［３］：４’ｂ００１１、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［４］：４’ｂ０１００、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［５］：４’ｂ０１０１、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［６］：４’ｂ０１１０、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［７］：４’ｂ０１１１、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［８］：４’ｂ１０００、
ｍｅｍ＿ｃｏｎ＿ｒｅｇ．ｃｕｒｒｅｎｔ＿ｖａｌｕｅ［９］：４’ｂ１００１、のように決定する。
また、アドレス割り当てに関し、共有レジスタが割り当てられたデバイスはＵｎｉｆｉｅｄ Ｍｅｍｏｒｙしか存在しないため、グローバルアドレスの割付を行わない。
尚、本例では１つのデバイスのみに共有レジスタの割り当てを行っているが、以降の説明に於いてこれは一般性を欠くものではない。それは、以降に処理手順を示す事で明らかとなる。
前記ＢａｓｉｃＢｌｏｃｋへの実行サイクルの割り当てに関しては、ここでは、Ｃｏｍｍａｎｄ Ｉｎｔｅｒｆａｃｅのみ取り上げて説明を行う。特に、先に求めたパラメータ値から、ｋｌ＝４，ｋｂ１＝２，ｋｂ２＝１，ｋｂ３＝１、ｋ１＝ｋ２＝ｋ３＝１、として説明を行う。パラメータ条件から、各ＢａｓｉｃＢｌｏｃｋの下に割り当てられたサイクル数のクロック境界を挿入する。ここでは、バスアクセス・メソッドを扱う対象としていない事に注意。更に、与えたパラメータで、例を示しているが一般性を失わない事に注意。次ページに変形後のＣＦＧを示す。尚、ｋｌの値は、直接各デバイスのハード合成用ＣＦＧには影響を与えない事にも注意。これは、固定優先度スケジューラにのみ影響する。第８３図にはＢａｓｉｃＢｌｏｃｋへの実行サイクルの割り当ての例が示される。
固定優先度スケジューラの修正に関しては、既に得られているＦＳＭ（Ｆｉｎｉｔｅ Ｓｔａｔｅ Ｍａｃｈｉｎｅ）の遷移サイクルをｋｌに変更する、即ち、クロック境界を各遷移枝に４つ付加すれば良い。ここからのＨＤＬ生成は、各状態からの遷移を分岐ノードに表現し直し、かつ各状態での信号代入はその状態への遷移枝上での最後のクロック境界直下にＢａｓｉｃＢｌｏｃｋを設け、そこにレジスタ代入文を記述する形式で置き換える事で、このＦＭＳ自体をＣＦＧと見做す事で、「サイクルアキュレートな記述からのＨＤＬ生成」を用いる事で可能である。第８４図に示す固定優先度スケジューラの一部を用いて変形後のＣＦＧが第８５図に示される。
ＣＦＧの変形に関しては、元のＣＦＧからバスアクセス・メソッドの括りだしを行い、バスアクセス・メソッドと元のＣＦＧとの通信ノードを設る。具体的には、下記を行う。
１）ハード合成用のＣＦＧ生成段階で、クロック境界を含むバスアクセス・メソッドのクロックをバスアクセス・メソッドを表すノードの直下にクロック境界を追加したが、これを削除する。
２）バスアクセス・メソッドを表すノードを下記処理を行うＢａｓｉｃ Ｂｌｏｃｋに置き換える。
▲１▼出力信号ｓｔａｒｔ＿ｃｏｍｍに１を代入する。
▲２▼バスコマンドを出力信号ｂｕｓ＿ｃｍｄに代入する。バースト転送の場合、初期サイクルでは、
〈１〉出力信号ｉｎｉｔの０を代入
〈２〉アクセスするデバイスのアドレスと共有レジスタのアドレスを連結して出力信号ａｄｄｒｅｓｓに代入
〈３〉クロック境界挿入×ｎｂｆ
〈４〉リードメソッドなら、代入すべき変数に入力信号ｄａｔａ＿ｉｎを代入
〈５〉ライトメソッドなら、出力すべき値または変数を出力信号ｄａｔａ＿ｏｕｔに代入
〈６〉クロック境界×ｍｂｆ、を行う。ここで、ｎｂｆ＋ｍｂｆ＝ｋｂ１である。この例では、ｎｂｆ＝ｍｂｆ＝１とする。
バースト転送の場合、転送終了では、
〈１〉クロック境界挿入×ｎ、を行う。ここで、ｎ＝ｋｂ３である。ここでは、ｎ＝１とする。
バースト転送の場合、それ以外では、
〈１〉出力信号ｉｎｉｔに１を代入
〈２〉アクセスするデバイスのアドレスと共有レジスタのアドレスを連結して出力信号ａｄｄｒｅｓｓに代入
〈３〉クロック境界挿入×ｎｂ
〈４〉リードメソッドなら、代入すべき変数に入力信号ｄａｔａ＿ｉｎを代入
〈５〉ライトメソッドなら、出力すべき値または変数を出力信号ｄａｔａ＿ｏｕｔに代入
〈６〉クロック境界×ｍｂを行う。ここで、ｎｂ＋ｍｂ＝ｋｂ２である。この例では、ｎｂ＝０、ｍｂ＝１とする。
シングル転送の場合、
〈１〉アクセスするデバイスのアドレスと共有レジスタのアドレスを連結して出力信号ａｄｄｒｅｓｓに代入
〈２〉クロック境界挿入×ｎｓ
〈３〉リードメソッドなら、代入すべき変数に入力信号ｄａｔａ＿ｉｎを代入
〈４〉ライトメソッドなら、出力すべき値または変数を出力信号ｄａｔａ＿ｏｕｔに代入
〈５〉クロック境界挿入×ｍｓ、を行う。ここで、ｎｓ＋ｍｓ＝ｋｓである。
▲３▼出力信号ｓｔａｒｔ＿ｃｏｍｍに０を代入する。
３）バスアクセスメソッドを表す孤立ノードを作成し、置き換えて生成したＢａｓｉｃ Ｂｌｏｃｋとの通信ノードを設ける。通信ノードとして、
ｓｔａｒｔ＿ｃｏｍｍ：Ｂａｓｉｃ Ｂｌｏｃｋ→孤立ノード
ｂｕｓ＿ｃｍｄ：Ｂａｓｉｃ Ｂｌｏｃｋ→孤立ノード
ａｄｄｒｅｓｓ：Ｂａｓｉｃ Ｂｌｏｃｋ→孤立ノード
ｄａｔａ＿ｉｎ：孤立ノード →Ｂａｓｉｃ Ｂｌｏｃｋ
ｄａｔａ＿ｏｕｔ：Ｂａｓｉｃ Ｂｌｏｃｋ→孤立ノード、を設ける。
第８６図及び第８７図には変形後のＣｏｍｍａｎｄ ＩｎｔｅｒｆａｃｅのＣＦＧの一部が示される。第８７図において、クロック境界の傍らに記載された変数はパラメータであり、その数だけクロック境界を生成することを意味する。
孤立ノードへのＣＦＧの割り当てに関しては、第８８図のＣＦＧを自動生成する。第８８図において、特に、ＡＤ＿ＢＵＳはアドレスバスを、Ｄ＿ＢＵＳはデータバスを表し、ｄａｔａ＿ｉｎ＿ｅｎ＿ｉはデータ入力ステージを、ｄａｔａ＿ｏｕｔ＿ｅｎ＿ｉはデータ出力ステージを表す。ここで、ｉは各デバイスのインデックスを表す。また、アドレスバスのバス幅は、割り当てたバスコマンドのビット幅とアドレスのビット幅の合計とし、データバスはアクセスするレジスタのビット幅とする。また、クロック境界の傍にかかれた変数はパラメータであり、その数だけクロック境界を生成する事を意味する。尚、各変数の値は、ＣＦＧの変形過程で用いた変数の値と等しい。
共有レジスタに関しては、第８９図の記述をインライン展開したものに対応するＣＦＧの生成を行えばよい。但し、入出力変数であるＡＤ＿ＢＵＳ、Ｄ＿ＢＵＳの入力、出力への分離は行わず、またＣＦＧ上での最適化に於いては、ＡＤ＿ＢＵＳ、Ｄ＿ＢＵＳに対する変数最適化は実施しないものとする。第８９図、第９０図及び第９１図には共有レジスタに関する擬似Ｃ記述である。サイクルアキュレートな記述からのＨＤＬ生成に関しては本発明者による先の出願（特願２００２−３０００７３）を参照することができる。
以上本発明者によってなされた発明を実施形態に基づいて具体的に説明したが、本発明はそれに限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは言うまでもない。
例えば、積オートマトンの構成に関しては、ＴＮＦＡ積オートマトンを構成するとき、遷移枝の通過回数でＡｓｓｕｍｅ Ｇｕａｒａｎｔｅｅ Ｒｅａｓｏｎｉｎｇを実施したが、本来は、ｓｙｎｃ動作の通過回数で行うべきである。理由は、ｓｙｎｃ動作はバスアクセス動作を意味しており、並列に動いているＴＮＦＡが何回ｓｙｎｃ動作を実施したかは、そのＴＮＦＡに対応するデバイスがバスアクセスを何回行ったかに対応するからであり、Ｒｅｆｉｎｅｍｅｎｔ及びパラメトリック・モデルチェッキングで得られるのは、遷移サイクルの条件のみならず、その検証性質を実施している間に各デバイスが高々どれだけバスアクセスを行うかの情報も得られるからである。但し、この手法であると、組み合わせ爆発を起し得るので、何らかの高速な枝切りが必要となる。
積オートマトンの構成に関しては、今回は、パラメトリック・モデルチェッキングの停止性を吟味せず、バウンデッド・モデルチェッキングとして、検証性質を満たす必要条件を求める事を行ったが、本来は十分を求める必要がある。その為、アルゴリズムの停止性に関する研究を更に行う必要がある。
バスモデルの拡張に関しては、単一双方向バスのみではなく、単方向バスや、ローカルバスを含むもの、またバス・ブリッジを介してバスが階層化されているような複数バスシステムを扱うようにしてもよい。
また、水平帰線期間のみを扱ったが、本来は垂直帰線期間もモデル化して、１フレームを表示している間に最低１フレーム分の描画が終了するための十分条件を求める必要がある。
本発明は、並列動作を記述できる言語からディジタル回路のハードウェア合成を行うデータ処理システムなど広く適用することができる。
Claims (7)
- 並列動作の記述が可能なプログラム言語を用いて複数のデバイスを定義したプログラム記述を入力し、入力したプログラム記述を中間表現に変換し、この中間表現に対し、実時間制約を満足するパラメータを生成し、生成したパラメータに基づいてハードウェア記述言語による回路記述を合成することを特徴とするシステム開発方法。
- 前記中間表現は、コンカレントなコントロールフローフラグ、コンカレントなパラメータ付き時間オートマトン、又はパラメータ付き時間オートマトンであることを特徴とする請求項１記載のシステム開発方法。
- 前記パラメータ生成に、パラメトリック・モデルチェッキングを行うことを特徴とする請求項２記載のシステム開発方法。
- 前記実時間制約はＲＰＣＴＬで与えられることを特徴とする請求項３記載のシステム開発方法。
- 前記プログラム記述はｒｕｎメソッドを用いてデバイスの定義を行い、バリア同期を用いてデバイスのクロック同期を定義することを特徴とする請求項４記載のシステム開発方法。
- 並列動作の記述が可能なプログラム言語を用いて複数のデバイスを定義したプログラム記述を入力し、入力したプログラム記述を中間表現に変換し、この中間表現に対し、実時間制約を満足するパラメータを生成し、生成したパラメータに基づいてハードウェア記述言語による回路記述を合成することを特徴とするデータ処理システム。
- 前記プログラム記述はｒｕｎメソッドを用いてデバイスの定義を行い、バリア同期を用いてデバイスのクロック同期を定義することを特徴とする請求項６記載のデータ処理システム。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002313201 | 2002-10-28 | ||
| JP2002313201 | 2002-10-28 | ||
| PCT/JP2003/012840 WO2004038620A1 (ja) | 2002-10-28 | 2003-10-07 | システム開発方法及びデータ処理システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPWO2004038620A1 true JPWO2004038620A1 (ja) | 2006-02-23 |
| JP3899104B2 JP3899104B2 (ja) | 2007-03-28 |
Family
ID=32171161
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004546404A Expired - Fee Related JP3899104B2 (ja) | 2002-10-28 | 2003-10-07 | システム開発方法及びデータ処理システム |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US20060015858A1 (ja) |
| JP (1) | JP3899104B2 (ja) |
| AU (1) | AU2003272931A1 (ja) |
| WO (1) | WO2004038620A1 (ja) |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8095921B2 (en) * | 2005-10-12 | 2012-01-10 | International Business Machines Corporation | Identifying code that wastes time switching tasks |
| EP1804185A1 (en) * | 2005-12-27 | 2007-07-04 | Semiconductor Energy Laboratory Co., Ltd. | Parameter setting method and circuit operation testing method and electronic processing device |
| TW200725415A (en) * | 2005-12-30 | 2007-07-01 | Tatung Co Ltd | Method for automatically translating high level programming language into hardware description language |
| TW200725412A (en) * | 2005-12-30 | 2007-07-01 | Tatung Co Ltd | Method for converting high-level programming language method into hardware component graph |
| US8645923B1 (en) * | 2008-10-31 | 2014-02-04 | Symantec Corporation | Enforcing expected control flow in program execution |
| JP5123255B2 (ja) * | 2009-06-09 | 2013-01-23 | 株式会社東芝 | アーキテクチャ検証装置 |
| WO2012057170A1 (ja) | 2010-10-27 | 2012-05-03 | 株式会社日立製作所 | ソースコード変換方法およびソースコード変換プログラム |
| JP5770073B2 (ja) * | 2011-11-25 | 2015-08-26 | 株式会社ジャパンディスプレイ | 表示装置及び電子機器 |
| CN102624476B (zh) * | 2012-01-10 | 2014-09-10 | 南京邮电大学 | 一种基于模型检测的无线传感器网络时间同步检验方法 |
| US8959494B2 (en) * | 2012-03-20 | 2015-02-17 | Massively Parallel Technologies Inc. | Parallelism from functional decomposition |
| US9424168B2 (en) * | 2012-03-20 | 2016-08-23 | Massively Parallel Technologies, Inc. | System and method for automatic generation of software test |
| US9977655B2 (en) | 2012-03-20 | 2018-05-22 | Massively Parallel Technologies, Inc. | System and method for automatic extraction of software design from requirements |
| US9324126B2 (en) | 2012-03-20 | 2016-04-26 | Massively Parallel Technologies, Inc. | Automated latency management and cross-communication exchange conversion |
| WO2014152800A1 (en) | 2013-03-14 | 2014-09-25 | Massively Parallel Technologies, Inc. | Project planning and debugging from functional decomposition |
| US11537415B2 (en) | 2018-10-02 | 2022-12-27 | Inter-University Research Institute Corporation Research Organization Of Information And Systems | Information processing apparatus, information processing circuit, information processing system, and information processing method |
| US11636245B2 (en) | 2021-08-11 | 2023-04-25 | International Business Machines Corporation | Methods and systems for leveraging computer-aided design variability in synthesis tuning |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2317245A (en) * | 1996-09-12 | 1998-03-18 | Sharp Kk | Re-timing compiler integrated circuit design |
| US6226776B1 (en) * | 1997-09-16 | 2001-05-01 | Synetry Corporation | System for converting hardware designs in high-level programming language to hardware implementations |
| US7035781B1 (en) * | 1999-12-30 | 2006-04-25 | Synopsys, Inc. | Mixed language simulator |
| US20030121027A1 (en) * | 2000-06-23 | 2003-06-26 | Hines Kenneth J. | Behavioral abstractions for debugging coordination-centric software designs |
| US20030005407A1 (en) * | 2000-06-23 | 2003-01-02 | Hines Kenneth J. | System and method for coordination-centric design of software systems |
| US6598218B2 (en) * | 2000-12-19 | 2003-07-22 | United Microelectronics Corp. | Optical proximity correction method |
| US6691301B2 (en) * | 2001-01-29 | 2004-02-10 | Celoxica Ltd. | System, method and article of manufacture for signal constructs in a programming language capable of programming hardware architectures |
| US7299470B2 (en) * | 2001-09-13 | 2007-11-20 | International Business Machines Corporation | Method and system for regulating communication traffic using a limiter thread |
| US6964029B2 (en) * | 2002-10-31 | 2005-11-08 | Src Computers, Inc. | System and method for partitioning control-dataflow graph representations |
-
2003
- 2003-10-07 AU AU2003272931A patent/AU2003272931A1/en not_active Abandoned
- 2003-10-07 WO PCT/JP2003/012840 patent/WO2004038620A1/ja active Application Filing
- 2003-10-07 US US10/533,062 patent/US20060015858A1/en not_active Abandoned
- 2003-10-07 JP JP2004546404A patent/JP3899104B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| WO2004038620A1 (ja) | 2004-05-06 |
| AU2003272931A1 (en) | 2004-05-13 |
| JP3899104B2 (ja) | 2007-03-28 |
| US20060015858A1 (en) | 2006-01-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3899104B2 (ja) | システム開発方法及びデータ処理システム | |
| US20210081258A1 (en) | Synthesis Path For Transforming Concurrent Programs Into Hardware Deployable on FPGA-Based Cloud Infrastructures | |
| Perry | VHDL: programming by example | |
| US8417504B2 (en) | Conversion of circuit description to a transaction model | |
| US8386973B2 (en) | Behavioral synthesis apparatus, method, and program having test bench generation function | |
| JPH10177485A (ja) | ソフトウェアプログラムの提供方法、情報格納媒体を含む製品及び記述提供方法 | |
| JPH11213031A (ja) | ソフトウェアにおけるハードウェアの検証、およびその逆の検証 | |
| Mulkers et al. | Analysis of shared data structures for compile-time garbage collection in logic programs | |
| Ziegenbein et al. | Combining multiple models of computation for scheduling and allocation | |
| US7496869B1 (en) | Method and apparatus for implementing a program language description of a circuit design for an integrated circuit | |
| CN115935872A (zh) | 一种可扩展的fpga仿真验证自动化方法 | |
| Simpson | FPGA design | |
| JP2008140405A (ja) | 電子回路と制御プログラムとのコバリデーション方法 | |
| JP2002140379A (ja) | 高位合成方法および高位合成装置 | |
| US20070271080A1 (en) | Model generation method for software/hardware collaboration design | |
| Chiodo et al. | Synthesis of mixed software-hardware implementations from CFSM specifications | |
| US6952817B1 (en) | Generating hardware interfaces for designs specified in a high level language | |
| US7865345B2 (en) | Simulation apparatus and method | |
| JP2007207120A (ja) | システム検証装置及びその検証方法 | |
| US20020183997A1 (en) | Apparatus and method for specifying the configuration of mixed-language simulation models | |
| Lapalme et al. | . NET framework-a solution for the next generation tools for system-level modeling and simulation | |
| US20020170037A1 (en) | Apparatus and method for controlling event ordering in a mixed- language simulator | |
| Ku et al. | Synthesis of asics with hercules and hebe | |
| Davare et al. | A platform-based design flow for kahn process networks | |
| Lisboa Malaquias et al. | A formal framework to design and prove trustworthy memory controllers |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060620 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060810 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060912 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061113 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20061212 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20061222 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110105 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110105 Year of fee payment: 4 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110105 Year of fee payment: 4 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120105 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130105 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130105 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140105 Year of fee payment: 7 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| LAPS | Cancellation because of no payment of annual fees |