JP3899104B2 - システム開発方法及びデータ処理システム - Google Patents
システム開発方法及びデータ処理システム Download PDFInfo
- Publication number
- JP3899104B2 JP3899104B2 JP2004546404A JP2004546404A JP3899104B2 JP 3899104 B2 JP3899104 B2 JP 3899104B2 JP 2004546404 A JP2004546404 A JP 2004546404A JP 2004546404 A JP2004546404 A JP 2004546404A JP 3899104 B2 JP3899104 B2 JP 3899104B2
- Authority
- JP
- Japan
- Prior art keywords
- bus
- cfg
- description
- transition
- 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.)
- Expired - Fee Related
Links
Images
Classifications
-
- 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
- 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/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)
Description
特許文献1:特開2002−279333号公報
特許文献2:特開2000−035898号公報
特許文献3:特開平07−084832号公報
本発明の目的は、並列動作を記述可能なプログラム言語とパラメトリック・モデルチェッキングを用いた、実時間制約を満たすバス・システムの新規設計手法を提供することにある。
本発明の別の目的は、モデルチェッキング技術とハードウェア合成技術の融合による新たな設計手法を提供することにある。
本発明のさらに別の目的は、実時間制約を有するバス・システムに対する並列動作記述可能なプログラム言語によるモデル化とパラメトリック・モデルチェックングによる検証、更にはハードウェア合成を実現することにある。
本発明の前記並びにその他の目的と新規な特徴は本明細書の記述及び添付図面から明らかになるであろう。
本願において開示される発明のうち代表的なものの概要を簡単に説明すれば下記の通りである。
すなわち、並列動作の記述が可能なプログラム言語を用いて複数のデバイスを定義したプログラム記述を入力し、入力したプログラム記述を中間表現に変換し、この中間表現に対し、実時間制約を満足するパラメータを生成し、生成したパラメータに基づいてハードウェア記述言語による回路記述を合成する。
上記より、Java(登録商標)等の並列動作を記述可能なプログラム言語によりバスシステム等に対するモデル化を行って、実時間制約を満たすシステムの設計を行うことができる。これにより、ハードウェア設計の工数低減が可能になる。
本発明の一つの形態として、前記中間表現は、コンカレントなコントロールフローフラグ、コンカレントなパラメータ付き時間オートマトン、又はパラメータ付き時間オートマトンである。
本発明の一つの形態として、前記パラメータ生成に、パラメトリック・モデルチェッキングを行う。モデルチェッキング技術とハードウェア合成技術の融合による新たな設計手法を提供することができる。
本発明の一つの形態として、前記実時間制約はRPCTLで与えられる。
本発明の一つの形態として、前記プログラム記述はrunメソッドを用いてデバイスの定義を行い、バリア同期を用いてデバイスのクロック同期を定義する。
第2図は単一バス・システムのジャバ言語によるモデル化のデザインパターンを例示する説明図である。
第3図はモデル化におけるクロック同期メカニズムとしてバリア同期によるクロック同期メソッドを用いた例を示す説明図である。
第4図はレジスタへの値書込みを実現するモデル化の記述を例示する説明図である。
第5図はバス権獲得を管理するメソッドを例示する説明図である。
第6図は第5図の各メソッドの呼び出し関係を表すコールグラフである。
第7図はバス権獲得メカニズムのジャバ言語記述を例示する説明図である。
第8図は第7図の続きを示すジャバ言語記述の説明図である。
第9図はバス権解放を管理するメソッドの説明図である。
第10図は第9図の各メソッドの呼び出し関係を表すコールグラフである。
第11図はバス権解放メカニズムのジャバ言語記述を例示する説明図である。
第12図はsync_readメソッドのジャバ言語コードの説明図である。
第13図はrun()でのsync_readメソッド記述例を示す説明図である。
第14図はsync_burst_readのジャバ言語コードを示す説明図である。
第15図はendBurstAccessのジャバ言語コードを示す説明図である。
第16図はfreeBurstBusLockのジャバ言語コードを示す説明図である。
第17図はrun()でのバーストリードの記述例を示を説明図である。
第18図はsync_writeのジャバ言語コードを示す説明図である。
第19図はrun()でのsync_writeメソッド記述例を示す説明図である。
第20図はsync_burst_writeのジャバ言語コードを示す説明図である。
第21図はrun()でのバーストライトの記述例を示す説明図である。
第22図はジャバ言語記述による実装例の概略仕様を示す説明図である。
第23図はコマンドインタフェースに関するrun()methodの実装例の一部を示す説明図である。
第24図は第23図の実装例の続きを示す説明図である。
第25図は第24図の実装例の続きを示す説明図である。
第26図は第25図の実装例の続きを示す説明図である。
第27図はユニファイドメモリに関するrun()methodの実装例を示す説明図である。
第28図はグラフィック描画ユニットに関するrun()methodの実装例を示す説明図である。
第29図は第28図の実装例の続きを示す説明図である。
第30図は第29図の実装例の続きを示す説明図である。
第31図は第30図の実装例の続きを示す説明図である。
第32図は第31図の実装例の続きを示す説明図である。
第33図は表示ユニットに関するrun()methodの実装例を示す説明図である。
第34図は第33図の実装例の続きを示す説明図である。
第35図は中間表現への変換工程の詳細を全体的に例示する説明図である。
第36図はC−CFGの形式を例示する説明図である。
第37図はsynchronizedの扱い(ハード合成用)について示す説明図である。
第38図はsynchronizedの扱い(パラメトリック・モデルチェッキング用)について示す説明図である。
第39図はCommand Interfaceの場合のCFGを示す説明図である。
第40図はCommand Interfaceに関しハード合成用のCFGを例示する説明図である。
第41図はパラメトリック・モデルチェッキング用のCFGを例示する説明図である。
第42図はグラフィック描画ユニット(Graphics Rendering Unit)に関するCFGを例示する説明図である。
第43図は第42図のCFGの続を示す説明図である。
第44図はパラメトリック・モデルチェッキング用のCFGを例示する説明図である。
第45図は第45図のCFGの続を示す説明図である。
第46図は前記表示ユニット(Display Unit)に関するCFGを例示する説明図である。
第47図はパラメトリック・モデルチェッキング用のCFGを例示する説明図である。
第48図はコマンドインタフェース(Command Interface)のCFG、グラフィック描画ユニット(Graphics Rendering Unit)のCFG、及び前記表示ユニット(Display Unit)のCFGにおける夫々の開始ノードの結合状態を例示する説明図である。
第49図は固定優先度スケジューラを例示する説明図である。
第50図はコマンドインタフェース(Command Interface)のCFGに対する抽象化の様子を順を追って示す最初の説明図である。
第51図は第50図の続を示す説明図である。
第52図は第51図の続を示す説明図である。
第53図は第52図の続を示す説明図である。
第54図は第53図の続を示す説明図である。
第55図は第54図の続を示す説明図である。
第56図は第55図の続を示す説明図である。
第57図はグラフィック描画ユニット(Graphics Rendering Unit)のCFGに対する抽象化処理の結果を例示する説明図である。
第58図は表示ユニット(Display Unit)のCFGに対する抽象化処理の結果を例示する説明図である。
第59図はコマンドインタフェース(Command Interface)のCFGに対するTNFAへの変換の様子を順を追って示す説明図である。
第60図は第59図の続を示す説明図である。
第61図は第60図の続を示す説明図である。
第62図はグラフィック描画ユニット(Graphics Rendering Unit)のCFGに対するTNFAへの変換の様子を順を追って示す説明図である。
第63図は第62図の続を示す説明図である。
第64図は第63図の続を示す説明図である。
第65図は第64図の続を示す説明図である。
第66図は表示ユニット(Display Unit)のCFGに対するTNFAへの変換の様子を順を追って例示する説明図である。
第67図は第66図の続を示す説明図である。
第68図は第67図の続を示す説明図である。
第69図は第61図、第64図、第68図で求めたTNFAの積TNFAの構成例を示す説明図である。
第70図はパラメータに上限値を与えた時に、積TNFAを構成する段階で制約を満たさない遷移枝の削除過程を示す説明図である。
第71図は第70図の続を示す説明図である。
第72図は第71図の続を示す説明図である。
第73図は第72図の続を示す説明図である。
第74図は第73図の続を示す説明図である。
第75図は第74図の続を示す説明図である。
第76図は第75図の続を示す説明図である。
第77図はC−TNFA2TNFAでAbstraction of TNFAを適時コールした場合の処理の経過の一部を示す説明図である。
第78図は第77図の続を示す説明図である。
第79図は第78図の続を示す説明図である。
第80図は得られたパラメータ条件に対して目的関数を各パラメタ値の合計として、これを最小化するという線形計画問題を解いた結果を例示する説明図である。
第81図は第80図の結果に対し、kb1=2,kb2=1,kb3=1の制約を追加して得た解を例示する説明図である。
第82図は第81図の結果に対し更にkr1以外のパラメタ変数を1以上という制約を追加して得た解を例示する説明図である。
第83図はBasicBlockへの実行サイクルの割り当てを例示する説明図である。
第84図は固定優先度スケジューラを例示する説明図である。
第85図は第84図に示す固定優先度スケジューラの一部を用いて変形した後のCFGを例示する説明図である。
第86図は変形後のCommand InterfaceのCFGの一部を例示する説明図である。
第87図は第86図の続きを示す説明図である。
第88図は孤立ノードへのCFGの割り当てに関するCFGを例示する説明図である。
第89図は共有レジスタに関しCFG生成のためのインライン展開の対象になる記述を例示する説明図である。
第90図は共有レジスタに関する擬似C記述を例示する説明図である。
第91図は第90図の続を示す説明図である。
《設計方法の全体》
第1図には設計方法の全体が示される。設計対象とされるシステムはジャバ言語による記述(ジャバ言語記述)でモデル化される(S1)。ジャバ言語記述によるモデル化では、単一バス上のデバイスをジャバ言語のrun()メソッドを用いて記述する。run()メソッドはマルチスレッドを構成するスレッドにおいて実行させたいプログラムコードがその()内に記述される。クロックはバリア同期を用いて実現される。一般的にバリア同期とは複数のモジュールからのデータを受信する場合に同時刻に処理されるべき全てのデータを待つための同期手法として把握することができる。
次いで、S1で生成されたジャバ言語記述(ジャバコード)1を読み込み、中間表現に変換する(S2)。ここで、中間表現2は、コンカレントなコントロール・フロー・グラフ(以下、C−CFG)、コンカレントなパラメータ付き時間オートマトン(以下、C−TNFA)、パラメータ付き時間オートマトン(以下、TNFA)からなる。CFG(コントロール・フロー・グラフ)は一般に関数内部において制御の流れを示すグラムを意味する。TNFA(オートマトン)とは、有限の種類の入力を離散的な時刻に受け、過去から現在までに入力された入力の系列を、回路で決まった個数以下のクラスに分類して記憶し、それに基づいて有限の種類の出力を出す回路の論理的なモデルとして把握することができる。
中間表現2として得られたTNFAとRPCTL(Real Time Parametric Computation Tree Logic)3で記述された実時間制約を読み込み、パラメトリック・モデル・チェッキングを実行し(S3)、入力RPCTL等を満たすパラメータ条件4を導出する。
満足するパラメータ条件がなければ方式変更を行いジャバ言語記述を修正し、満足するパラメータ条件があれが、そのパラメータ条件をサイクル制約として、C−CFGを読み込んで高位合成(S4)によりHDL(hardware Description Language)による回路記述5へ変換する。回路記述は例えばRTL(Register Transfer Level)である。
上記開発方法はそれを実現するためのプログラムをコンピュータ装置で実行することによって行なわれる。ジャバ言語記述からHDLを得る為の開発支援プログラムはディジタル回路の設計支援プログラムとして位置付けることができる。
本設計手法により、単一バスシステムの上流工程でのモデル化、検証が可能となり、かつ実時間制約を満たすハードウェアの設計自動化が可能となる。上流工程での検証が可能なのは、設計対象システムはジャバ言語記述でモデル化され、その記述自身が実行可能にされるからである。
《ジャバ言語によるモデル化に対する制約》
ジャバ言語によるモデル化に際してのジャバ言語記述とバスシステムに対する制約について説明する。単一バス・システムのジャバ言語によるモデル化を目的とするため、ジャバ言語記述に対し、
1)ダイナミック・インスタンシエーションの禁止、
2)run()メソッドからのstart()メソッドコールの禁止、
の制約を置く。制約1)はLSIのプロセス変更に関するものであり、ここではハードウェアを扱っている事から、許容可能な制約であると考えられる。また、制約2)はバス・プロトコルの検証を目的とする限りに於いては、直接バス動作に関わる部分のみをモデル化すれば良い為、許容可能な制約であると考えられる。
また、パラメトリック・モデルチェッキング・ツールの制約から、モデルに対して、
3)単一双方向バス・システム、
4)バス権制御は固定優先度
5)バス上の各デバイスは一定周期で処理を終了、の制約を課す。上記制約の緩和は新たな課題として位置付けられる。
《ジャバ言語によるモデル化の為のデザインパターン》
第2図には単一バス・システムのジャバ言語によるモデル化の為のデザインパターンが例示される。単一バス・システムのジャバ言語によるモデル化はUML(Unified Modeling Language)で与えられる第2図のデザインパターンに沿って記述される。バス上の各デバイス動作をDeviceImpl Class内のrun()メソッドに実装し、バスを介してアクセスがあるデバイス内レジスタはRegister Class内のattribute(属性)として実装し、バスを介しての同期通信メソッドをRegister Classのメソッドとして実装する。また、バスに対応するBus Class、バスのロック管理を行うBusController Class、及びクロック同期を管理するClock Controller Classを実装する。バスのロック管理とはバスアービトレーションの制御を意味する。第2図の標記において、棒線を付した三角記号△は継承を意味し、例えばDeviceImpl ClassはDevice Classの子クラスであり、DeviceImpl ClassはDevice Classのメソッドを使用可能である。記号→はユース(use)を意味し、例えばDevice ClassはClock Controller Classのメソッドを利用する。
尚、ジャバ言語コードの再利用性を高めるため、下記方針
1)デバイスの追加・削除(DeviceImpl Classの追加・削除)、
2)デバイス動作の変更(DeviceImpl Classのrun()メソッドの変更)、
3)共有変数の追加・削除(Register Classのattributeの追加・削除)、
4)バスプロトコルの追加・変更(Register Classの同期通信メソッドの追加・変更)、
にて、ジャバ言語コードの変更が可能となるようデザイン・パターンを定義している。
第2図のデザインパターンにおける各クラス(Class)について説明する。
(1)Deviceクラス
デバイスに共通の要素をまとめた抽象クラスである。レジスタやバスは複数ある場合でも処理内容自体が異なることはないため、同じクラスオブジェクトを複数生成ことにより複数存在することを表現できるが、デバイスはデバイスごとにその処理内容が異なる。よって、並列動作を行なうためにThreadクラスを継承し、Clock controller Classのインスタンス、Register Classのインスタンス、Bus Classのインスタンスを表すメンバ変数、各デバイスがアクセス可能な共有レジスタの情報を登録する為のメンバ変数、及び各デバイスがアクセス可能な共有レジスタの情報を登録する為のメソッドといったようなデバイスに共通な要素をまとめたクラスとしてDeviceクラスを実装する。
(2)DeviceImplクラス
実際のデバイスにあたるクラスである。デバイスはデバイスごとに処理内容が異なるため、デバイスに必要な要素をまとめたDeviceクラスを継承し、その処理内容を記述する。つまり、Aという処理を行なうDeviceImplAクラス、Bという処理を行なうDeviceImplBクラスといったように処理ごとにDeviceクラスの実装クラスが存在することになる。
(3)Registerクラス
共有レジスタに対応するクラスである。レジスタの値を表すメンバ変数と、その値をリード/ライトするメソッドから成る。
(4)Busクラス
バスに対応するクラスである。バスが使用中であるか否かの状態を表すメンバ変数、そのバスに繋がっている共有レジスタをあらわすメンバ変数、及び、状態を変更するメソッドから成る。
(5)BusControllerクラス
バスを介した共有レジスタへのアクセス時のバスロックとバスのロック解放を行なうクラスである。バスのロック・ロック解放はこのクラスに対して依頼する。特に、バスに対して1つデバイスがアクセスを行うとフラグ変数を1に設定するメソッドを含む。このフラグをバスアクセス・フラグとしてメンバ変数として持ち、このメンバ変数により、同一クロック内での複数回のバスロック動作を回避している。
(6)ClockControllerクラス
クロック管理クラスである。バスシステム上の各デバイスにクロック同期動作を行なわせるために、1クロック分の処理終了の通知を集め、全デバイスの処理終了が認められたら、次のクロックの処理を行なってよいという通知を行うと同時にBusController Classのバスアクセス・フラグを0にリセットする。
《モデル化におけるクロック同期メカニズム》
クロック同期メカニズムについて説明する。第3図に示すバリア同期によるクロック同期メソッドを用いて、クロックを実現する。具体的には、1クロック分の処理終了の通知を集め、全デバイスの処理終了が認められたら、次のクロックの処理を行なってよいという通知を行う。
また、バスのロックが残っていない場合には、Bus Classのバスアクセス・フラグを0にリセットする。尚、クロック遷移はパラメトリック・モデル・チェッキングへの入力に際して、パラメータ化される為、必ずしも1クロック単位であるとは限らない。
このクロック遷移のパラメータ化により、サイクル精度でのモデル化よりも抽象度の高いモデル化を実現する。
レジスタへの値書き込みには1クロックを要する為、それを実現する必要がある。これは、consume_1_clockメソッド内で、第4図に例示されるRegister ClassのassignWriteValueメソッドをコールする事で実現している。
《モデル化におけるバス権獲得メカニズム》
バス権管理の同期メカニズムとして、先ずバス権獲得メカニズムについて説明する。バス権獲得メカニズムは、第5図に示すメソッドにより、バス権獲得を管理する。バス権の要求はgetBusLockメソッドにより行う。第6図には第5図の各メソッドの呼び出し関係を表すコールグラフが示される。第7図及び第8図には上記バス権獲得メカニズムのジャバ言語記述が例示される。
《モデル化におけるバス権解放メカニズム》
次にバス権解放メカニズムについて説明する。バス権解放メカニズムは第9図にに示すメソッドにより、バス権解放を管理する。バス権の解放はfreeBusLockメソッドにより行う。第10図には第9図の各メソッドの呼び出し関係を表すコールグラフが示される。第11図には上記バス権解放メカニズムのジャバ言語記述が例示される。
《モデル化における排他的同期リード・メソッド》
バスへの排他的同期アクセス方式として、排他的同期リード・メソッドについて説明する。排他的同期リード・メソッドには以下のシングルリードとバーストリードがある。シングルリードはsync_readメソッドをrun()でコールする事で実現される。バーストリードは、sync_burst_read、endBurstAccess、consume_clockメソッドをrun()の、synchronizedブロック内で用いる事で実現される。
第12図にはsync_readメソッドのジャバ言語コード、第13図にはrun()でのsync_readメソッド記述例が示される。run()での記述例に現れる未定義メソッド、即ち、do_something_w_or_wo_clock_boundary()はクロック境界を含んでもよい何らかの処理を意味し、do_something_wo_clock_boundary()はクロック境界を含まない何らかの処理を意味する。
第14図にはsync_burst_readのジャバ言語コード、第15図にはendBurstAccessのジャバ言語コード、第16図にはfreeBurstBusLockのジャバ言語コード、第17図にはrun()でのバーストリードの記述例が示される。バーストリードでは、バスのロックはコールする度に重ねて獲得し、バスの解放を行わないで値を返す。そして、バーストリード回数のリードが終了すると、重ねたロックを一気に解放するという実装方法となっている。この実装により、毎サイクル、リード値が返ってくるというバースト動作を実現している。
《モデル化における排他的同期ライト・メソッド》
バスへの排他的同期アクセス方式として、排他的同期ライト・メソッドについて説明する。排他的同期ライト・メソッドには以下のシングルリードとバーストリードがある。シングルライトはsync_writeメソッドをrun()でコールする事で実現される。バーストライトはsync_burst_write、endBurstAccess、consume_clockメソッドをrun()の、synchronizedブロック内で用いる事で実現される。
第18図にはsync_writeのジャバ言語コードが示され、第19図にはrun()でのsync_writeメソッド記述例が示される。
第20図にはsync_burst_writeのジャバ言語コードが示され、第21図にはrun()でのバーストライトの記述例が示される。バーストライトでは、バスのロックはコールする度に重ねて獲得し、書き込み処理終了後バスの解放を行わないで処理を終了する。そして、バーストライト回数のライトが終了すると、重ねたロックを一気に解放するという実装方法となっている。この実装により、毎サイクル、ライト値が書き込めるというバースト動作を実現している。
《ジャバ言語記述による実装例》
ジャバ言語記述による実装例を説明する。第22図には実装例の概略仕様が示される。ここでは、共有メモリ方式の2次元グラフィックス描画・表示システムを一例とする。同図に示されるシステムは、コマンドインタフェース(Command Interface)、ユニファイドメモリ(Unified Memory)、グラフィック描画ユニット(Graphics Rendering Unit)、及び表示ユニット(Display Unit)を有し、それらは双方向バス(Single bi−derection Bus)に共有する。
(1)Command Interfaceは、外部からの描画コマンドを受付け、バスを介して受け付けた描画コマンドをメモリへ転送する。
(2)Unified Memoryは、描画コマンド、描画ソースデータ、表示データを一元的に格納するメモリである。システムの低コスト化・部品点数削減に効果大。モデルを単純化する為、Javaでは配列で表現する。本デバイスはスレーブデバイスである。
(3)Graphics Rendering Unitは、Unified Memoryに描画コマンドがあるかをボーリングで調べ、存在する場合は、描画コマンド、描画データをバスを介してリードしながら描画処理を行い、描画結果を内部バッファに格納し、一気にUnified Memoryへバースト転送する。モデルを単純化する為、描画コマンド、描画データ転送は配列への連続アクセスで実現する。
(4)Display Unitは、表示データをリードしながら1ラインずつ表示を行う。モデルを単純化する為、垂直同期はモデル化しない。また、水平帰線期間はバスアクセスを行わないものとする。
上記コマンドインタフェース(Command Interface)、グラフィック描画ユニット(Graphics Rendering Unit)、及び表示ユニット(Display Unit)がバスマスタデバイスであり、ユニファイドメモリ(Unified Memory)がバススレーブデバイスである。バスマスタデバイスが同時にバス権獲得を行った場合の、バス権獲得の優先順位は、表示ユニット(Display Unit)>コマンドインタフェース(Command Interface)>グラフィック描画ユニット(Graphics Rendering Unit)とする。
次に、第22図の仕様に対するrun()methodの実装例について説明する。
(1)Command Interface
先ず、コマンドインタフェースに関するrun()methodの実装例を説明する。その実装例は第23図乃至第26図に例示される。外部入力write_req信号(具体的にはCPUからのライト信号)があり且つwait出力信号の値決定に用いる内部変数wait_flagがfalseだとコマンド受付を実行(一定サイクル消費)し、その後に先ずwait_flag変数をtrueとする。次いで、バス権取得を試み、取得できたらUnified Memoryのコマンドフラグ0,1をsync_burst_readで読み出し、値が0(描画コマンド処理済み)であるコマンドフラグに対応するメモリ領域に対して、バス権を取得した状態のままで、sync_burst_writeを実行し、コマンドフラグ、描画コマンド、描画ソースデータを転送し、wait_flag変数をfalseとする。但し、モデル簡略化の為、例えコマンドフラグが両方とも0であっても、コマンドフラグ0に対応するメモリ領域へのsync_burst_writeによる書き込みのみを実行するものとし、描画ソースデータの転送は省略する。
write_flag変数がtrueで、write_req入力信号がtrueの場合のみ、wait信号をtrueとし、それ以外はwait信号をfalseとする。特に、コマンド受付実行中はwait_flag変数をfalseとする。尚、wait信号、wait_flag変数ともに初期値はfalseとする。
また、Command Interfaceが受け付けるコマンドは、コマンドフラグ、描画コマンド、描画ソースデータ、テクスチャデータの格納開始・終了アドレスからなっており、テクスチャデータの格納開始・終了アドレスは描画コマンドに含まれているものとする。
(2)Unified Memory
ユニファイドメモリに関するrun()methodの実装例を説明する。その実装例は第27図に例示される。グラフィックス描画コマンド、描画ソース・グラフィックス・データ、描画後の表示用データを一元的に格納しているメモリ。モデル化を簡略化する為、何も実行しないスレッドとして実現。このメモリの実体はRegister Classのインスタンスとしてrun()メソッド内でアローケートされている。
尚、モデル簡略化の為、メモリ配列を下記
mem_con_reg.current_value[0]:コマンドフラグ0、
mem_con_reg.current_value[1]:描画コマンド0、
mem_con_reg.current_value[2]:コマンドフラグ1、
mem_con_reg.current_value[3]:描画コマンド1、
mem_con_reg.current_value[4]:描画ソース・データ、及び描画後の表示用データ、の構造としている。
実際には、描画ソース・データと描画後の表示データを格納している配列のなすメモリ空間を2分し(一方をBuffer0、他方をBuffer1とする)、フレーム表示毎にメモリ配列を、
(Buffer0,Buffer1)=(描画ソース・データ,描画後の表示用データ)(Buffer0,Buffer1)=(描画後の表示用データ,描画ソース・データ)となるように、交互に切り替えているとする。従って、描画ソース・データを描画後の表示用データで上書きする事はないとする。更に、モデル簡略化の為、描画ソース・データの転送は省略する。
また、モデル簡略化の為に、テクスチャ・データは省略しており、描画コマンドも最高で2つしか格納しないものとし、コマンド0,1の実行順番がどうであっても描画結果には影響しないものとする。
(3)Graphics Rendering Unit
グラフィック描画ユニットに関するrun()methodの実装例を説明する。その実装例は第28図乃至第32図に例示される。Unified Memoryのコマンドフラグ0,1をある一定周期毎にsync_burst_readにより読み出す(バス権獲得・解放動作)。何れか一方の値が1であった場合、内部状態変数render_startをtrueとし、バス権獲得を試み、獲得に成功したなら、描画コマンド、描画データをsync_burst_readで読み込みながら、描画処理を実行し、描画結果を内部バッファに書き込む(読み込み終了次第、コマンドフラグを0にクリアし、バス権解放する)。但し、モデル簡略化の為、例えコマンドフラグが両方とも0であっても、コマンドフラグ0に対応する描画コマンドのみを実行するものとし、描画ソースデータの転送は省略する。再び、バス権獲得を試み、獲得に成功したなら、描画結果をsync_burst_writeでUnified Memoryへ転送し、バス権を解放し、内部状態変数render_startをfalseとする。尚、内部状態変数render_startの初期値はfalseである。
(4)Display Unit
表示ユニットに関するrun()methodの実装例を説明する。その実装例は第33図及び第34図に例示される。Unified Memoryから描画後の表示用データを読み込みCRTへ出力する。但し、モデル簡略化の為、水平同期のみを扱うものとする。これは、水平帰線期間内に描画が開始・終了する為のサイクル制約をパラメトリック・モデルチェッキングで求める事を目的としているからである。
さて、Display Unitは、内部変数display_startをtureに設定し、Unified Memoryから描画後の表示用データをsync_burst_readにて読み込む。データ読み込み終了後に内部変数display_startをfalseとして、ライン表示を実行し、ライン表示終了後から水平帰線期間に相当する適当なサイクルを消費し、再び、ライン表示を同じ手順で行うものとする。また、転送サイクルのみをモデル化すれば良いので、メモリアドレスは簡略的に表現し、常に同一メモリ空間から読み出しているものとする。
《パラメトリック解析》
ここでパラメトリック解析の目標について説明する。本来、描画は1フレーム表示の表示期間及び、垂直帰線期間の間に1フレーム分の実行を終了しておれば良いと考えられるので、水平帰線期間での描画が満たすべき性質を勘案すると、検証内容としては下記条件を満たすサイクル制約の導出で十分である。即ち、「表示用データ取得終了後に描画を開始し、次の表示開始までに描画を終了する事がある。但し、描画開始・終了にデータ転送サイクルは含まれ、表示はnサイクル以内に終了する。」である。上記制約をRPCTL(Real Time Parametric Computation Tree Logic)で記述すると下記
EF{<display_end>(AF(<render_begin>true)
&&{AF(<render_end>true)AU(<display_begin>true)})}
&& AG{[display_begin](AF<=n([display_end]true))}
の3個の制約のアンド条件となる。尚、表示データ取得終了迄に未実行の描画コマンドがUnified Memory上に常に存在する事が仮定できるものとする。ここで、nは適当な正整数であり、各変数は下記の通り、display_begin:内部変数display_startの0から1への立ち上がりイベント
display_end:内部変数display_startの1から0への立ち下がりイベント
render_begin:内部変数render_startの0から1への立ち上がりイベント
render_end:内部変数render_startの1から0への立ち下がりイベント
を表す。
パラメトリック・モデルチェッキングを高速化する目的で、RPCTLを
AG{[display_begin](AF<=n([display_end]true))} (*)
と、それ以外の部分に分離し、例えば、
EF{<display_end>(EF(<render_begin>true)&&{EF(<render_end>true)AU(<display_begin>true)})}
から実行し、パラメータ条件を導出し、導出されたパラメータから(*)のnの上限を求め、既に求めたパラメータ条件に矛盾しないパラメータ条件が導出できるまで、nの値を減じて繰り返し、(*)のパラメトリック解析を実施するものとする。
RPCTLやそれを用いたパラメトリック・モデルチェッキングの詳細は次の文献、“Akio Nakata and Teruo Higashino:”Deriving Parameter Conditions for Periodic Timed Automata Satisfying Real−Time Temporal Logic Formulas”,Proc.of IFIP TC6/WG6.1 Int’l Conf.on Formal Techniques for Networked and Distributed Systems(FORTE2001),Cheju Island,Korea,Kluwer Academic Publishers,pp.151−166,Aug.2001.”に記載ある。
《中間表現への変換》
第35図には中間表現へ変換工程の詳細が全体的に例示される。バスシステムをモデル化して記述されたジャバ言語記述はC(concurrent)−CFGに変換され(Java2C−CFG)、C−CFGはC−TNFAに変換され(C−CFG2C−TNFA)、C−TNFAはTNFAに変換される(C−TNFA2TNFA)。パラメトリック・モデルチェッキングを経てC−CFGがHDLに変換される(C−CFG2HDL)。尚、上記Java2C−CFG等の標記において、数字“2”は“to”を意味するものと理解されたい。
《Java2C−CFG》
ジャバ言語記述からC−CFGへの変換アルゴリズムの概要を説明する。各run()メソッドに対応するCFGを生成する。特に、クロック同期メソッド(consume_clock)はクロック境界として識別し、呼び出しメソッドは呼び出し関係を表すノードを用いて表現する。各run()メソッドに対応するCFGが生成されると、forkノードを設け、そのノードから各CFGの開始ノードへのfork枝を付加する。特に、バス上の各デバイスにrun()メソッドが対応するものとしてJavaが記述されている事を前提とし、メモリデバイスに関しては、CFG生成対象外である事の指定を与えるものとする。
次いで、呼び出しメソッドのCFGを作成し、呼び出しメソッドがsynchronizedブロック内に存在する場合は、呼び出しメソッド内のsynchronizedをCFGから削除する。特に、呼び出しメソッドがRegisterクラス内の通信メソッドである場合はCFGの作成を行わず、インスタンス関係からどのデバイス内のどのレジスタへのアクセスかと通信メソッドの名前だけを識別し、その情報をCFGに保持する。但し、図ではどのレジスタへのアクセスかの情報は省略している。尚、通信メソッドが内部にクロック同期メソッドを含む場合は、その出力枝にクロック境界をマークする。更に、呼び出しメソッド全体のサイクル制約を導出する以外は、呼び出しメソッドをインライニングする。この例では、Rendersingメソッド、Displayメソッドはインライニングしない。
synchronizedを予め定めたCFGに展開し、ハード合成用の固定優先度スケジューラをFSM(Finite State Machine)の形式でスケルトンとして予め与えてあるライブラリと実際にCFGを生成したrun()メソッドの個数を用いて、自動生成する。ここで、CFGはハード合成用とパラメトリック・モデルチェッキング用の2種作成する。
尚、固定値伝播や、代入によるローカル変数消去等のコードレベル最適化をCFG上で実施する。特に、信号の入力・出力・入出力はメンバ変数で表し、端子方向に関しては、プログラム内での代入文で右辺にあるのか左辺にあるのかや条件文での変数の用いられ方を解析して決定する。入出力信号として識別された場合、データ依存性を考慮して、入力と出力に適当な信号のリネームを行って分離する。
Java2C−CFGに関し、以下で、Java記述例に沿って、各run()メソッドのCFG生成結果、C−CFG生成結果、及び固定優先度・スケジューラのFSMについて説明する。
先ずCFGの形式について説明する。第36図にはC−CFGの形式が例示される。各CFGは分岐枝の開始と終了を表すノードと、ループ枝の開始と終了を表すノードを含み、分岐条件、ループ終了条件を対応する枝に付加した形式とする。特に、クロック境界ノードを枝上に付加する事でクロック境界を表現する。また、メソッドコールに対応するノードを用いる事で、サブCFGとのリンクを表現する。各CFGの並列実行を表すforkノードはCFGへの頂点へ付加する事で表現する。
synchronizedの扱い(ハード合成用)について説明する。第37図に例示されるように、synchronizedの開始をCFG上でbegin_syncとラベル付けされたノードとして表し、synchronizedの終了をend_syncとラベル付けされたノードでし、CFGを生成。その後、その両ノードを夫々下図に示すように変換する。
synchronizedの扱い(パラメトリック・モデルチェッキング用)について説明する。第38図に例示されるように、synchronizedの開始をCFG上でBegin_syncとラベル付けされたノードとして表し、synchronizedの終了をEnd_syncとラベル付けされたノードでし、CFGを生成。その後、その両ノードを夫々第38図に示すように変換する。
上記に従うと、前記Command Interfaceの場合、CFGは第39図に示される。getWriteSignal()メソッドは、シミュレーションを実施する為に行った記述であり、処理系への入力では外部からの入力信号write_reqであるとして修正されているものとし、入力テストベクタの個数を表すdcom_indexを補正する記述も削除されているものとする。また、drawing_commandsも配列として表現されているが、これもシミュレーションを実施する為になされたものであり、内部変数input_commandに入力変数drawing_commandsが入力されている記述が処理系に入力されているのもとして扱う。
前記Command Interfaceに関し、ハード合成用のCFGは第40図に示され、パラメトリック・モデルチェッキング用のCFGは第41図に例示される。
前記グラフィック描画ユニット(Graphics Rendering Unit)に関し、第42図及び第43図にはそのCFGが例示され、第44図及び第45図にはそのパラメトリック・モデルチェッキング用のCFGが例示される。
前記表示ユニット(Display Unit)に関し、第46図にはそのCFGが例示され、第47図にはそのパラメトリック・モデルチェッキング用のCFGが例示される。
第48図にはコマンドインタフェース(Command Interface)のCFG、グラフィック描画ユニット(Graphics Rendering Unit)のCFG、及び前記表示ユニット(Display Unit)のCFGにおける夫々の開始ノードの結合状態が例示される。
固定優先度スケジューラ(Fixed Priority Scheduler)について説明する。実際にトップレベルのCFGを生成したrunメソッドの数を識別し、夫々のデバイスにバス権取得通知を行うための信号locked_iの組みからなるステートを作成する。単一バスシステムであるため、それらステートは、1つのlocked_iのみが1でその他が0であるものを構成すれば良い。また、全てのlocked_iが0であるステートも作成する。優先度情報に基づき、バス権要求信号lock_iを受けて行う状態遷移枝を設ければバス権管理用の固定優先度スケジューラが構成できる。特に、全てのlocked_iが0であるステートをリセット解除時の開始ステートとする。また、各状態遷移は1<=t<=klの時間制約が付加されているものとする。このパラメータは後のパラメトリック・モデルチェッキングで決定されるパラメータである。尚、例えば、kl=2とし、各遷移を2クロック遷移とした場合は、出力値は変化が起こるまで、前の値を保持しているものとして解釈するものとする。
第49図には本例に対応する固定優先度スケジューラが例示される。同図における信号の意味は、
lock_1:Command Interfaceからのバス権要求信号
lock_2:Graphics Rendering Unitからのバス権要求信号
lock_3:Display Unitからのバス権要求信号
locked_1:Command Interfaceへのバス権取得通知信号
locked_2:Graphics Rendering Unitへのバス権取得通知信号
locked_3:Display Unitへのバス権取得通知信号
である。尚、バス権取得の優先度が、
Display Unit>Command Interface>Graphics Rendering Unitであるので、遷移条件は、
lock_3:Display Unitへの遷移
!lock_3&&lock_1:Command Interfaceへの遷移条件
!lock_3&&!lock_1&&lock_2:Graphics Rendering Unitへの遷移条件
otherwise:全てのlocked_iが0であるステートへの遷移条件
となる。
《Abstraction of each CFG》
夫々のCFGの抽象化処理について説明する。先ず、そのアルゴリズムの概要を説明する。各BasicBlockに対して、0<=t<=kiなる時間遷移条件を付加し、Begin_syncノードとEnd_syncノードに対して0<=t<=klを付加し、通信メソッドを表すノードに対して、バースト開始に1<=t<=kb1、バースト動作に0<=t<=kb2、バースト終了に0<=t<=kb3を付加する。但し、通信メソッドを表すノードに対しては、バースト開始が2サイクル以上、バースト動作時は1サイクル以上、バースト終了が1サイクル以上を要すると考え、後述のノードのマージによる抽象化を行う際には、サイクル制約の補正を行う。Begin_syncとEnd_syncノード以外の制約を付加したノードをクロック境界と見做して抽象化を行う。
通信メソッドは動作内容を全て抽象化し、連続する場合は、1つのノードにまとめ、例えばバースト開始(1<=t<=kb1)、クロック境界(t=1)、(バースト動作(0<=t<=kb2)+クロック境界(t=1))3回、バースト終了(0<=t<=kb3)、クロック境界(t=1)とすると、
6<=t<=(kb1+1−1)+3(kb2+1−1)+(kb3+1−1)=kb1+3kb2+kb3(>=2+3*1+1=6)
なるサイクル制約を持つクロック境界として1つにまとめる。また、分岐ノードは全て非決定分岐であるとする。Basic Blockノードに関しては、入力RPCTLで用いる変数のみ残し他は抽象化する。分岐ノード下位に存在するBasic Blockに対応する部分が異なる分岐で同じ場合は、1つを残して他を削除する。
特にループノードに関しては、break、continueを含まない固定回数ループの場合はアンローリングを実施し、それ以外の場合は、ループを抜ける条件枝の直前に全体で0<=t<=kloopのサイクル制約を持つようなCFGノードの集合を設ける事でループを削除する。ここで、kloopの満たすべき条件を別に算出するものとする。更に連続するクロック境界はパーコレーション・ベースの移動を行う事で、1つに纏め、遷移サイクル制約を更新する。
ここで、各クロック境界のパラメータ化により、クロック境界に与えた遷移サイクル制約の意味は、クロック境界から次のクロック境界への遷移に対するサイクル制約である。
コマンドインタフェース(Command Interface)のCFGに対する抽象化の様子が順を追って第50図乃至第56図に例示される。第57図にはグラフィック描画ユニット(Graphics Rendering Unit)のCFGに対する抽象化処理の結果が例示される。第58図には表示ユニット(Display Unit)のCFGに対する抽象化処理の結果が例示される。
《C−CFG2C−TNFA》
C−TNFAからTNFAへの変換処理について説明する。TNFAとは時間オートマトンであり、各遷移が、
s−a@?t[P(t)]−>s’
の形式で表されるものである。ここで、各記号の意味は、
s,s’:状態、
a:動作(省略可能)、
@?t:状態sを訪れてから動作aを実行するまでの経過時間をtに代入、P(t):時間制約(tに関する線形不等式の論理結合)、
である。また、その意味は「sからt単位時間経過後に状態s’に遷移。ただし、tは時間制約P(t)を満たす場合に限る」である。
C−TNFAは、複数のTNFAが並列動作するモデルであり、動作syncは高々1つのTNFAしか実行できないモデルである。特に連続する動作syncに対しては他のTNFAが割り込めない。尚、各TNFAに対して、初期状態から初期状態への遷移に対して、上限を与える為の時間制約を課す事が可能である。
次にC−CFGからC−TNFAへの変換処理について説明する。先ず、その変換アルゴリズムの概要を説明する。Begin_sync、End_syncで挟まれた部分を識別し、syncブロックとする。Syncブロック内に存在しないクロック境界ノードにステート割り当て候補とし、またsyncブロック内であっても検証性質に必要となる信号がBasic Blockとして与えられている場合はその前後のクロック境界ノードにステートを割り当て候補とし、最後にBegin_sync、End_syncの変換で導入したクロック境界をステート割り当て候補とする。得られたステート割り当て候補を重複が無いようにし、ステート割り当てを行い、各ステートからステートまでをDFS(Depth First Search)でトラバースする事でTNFAへの変換を行う。得られたTNFAに対して、syncブロックに対応する遷移を検出し、sync遷移とする。連続するsync遷移でない遷移は1つの遷移に纏める事でステート数の削減を行う。
コマンドインタフェース(Command Interface)のCFGに対するTNFAへの変換の様子が順を追って第59図乃至第61図に例示される。
第62図乃至第65図にはグラフィック描画ユニット(Graphics Rendering Unit)のCFGに対するTNFAへの変換の様子が順を追って例示される。第65図において、検証性質は、「表示用データ取得終了後に描画を開始し、次の表示開始までに描画を終了する事がある。但し、描画開始・終了にデータ転送サイクルは含まれ、表示はnサイクル以内に終了する。」であり、これは、描画が開始される事がもしあればという前提にたった検証性質であるから、Graphics Rendering Unitに対応するTNFAにおいて、表示データ取得終了迄に未実行の描画コマンドがUnified Memory上に存在しない事を表すR2からR1への遷移はこの検証には不要となる。従って、これは削除されている。
第66図乃至第68図には表示ユニット(Display Unit)のCFGに対するTNFAへの変換の様子が順を追って例示される。
《C−TNFA2TNFA》
C−TNFAからTNFAへの変換アルゴリズムの概要を説明する。先ず、下記方針(1)〜(5)に従ってC−TNFAから積TNFAを構成する。
(1)sync動作とそれ以外の動作は互いにインタリーブされる。ここで、sync動作を行っている間にバス権をとる必要が無い動作、即ちsyncでない動作を(一般に複数)並行して実行できることを表現。但し、sync動作を1遷移実行する間の他のTNFAの並行遷移に遷移枝を通る回数に制限を設け、それを満たす各遷移の遷移時間の上限を導出する。特に、回数は1から始め、意味のある解が得られるまで、回数を1づつインクリメントするものとする。
(2)複数のsync動作が実行可能な場合は静的優先度が最も高いものによって遷移する。ここで、動いていない状態sに関してはage(s,t)(状態sで時間tだけが経過した状態)に遷移。ただし、連続するsync遷移の間には他の動作は割り込めない。
(3)age(s,t)以降の遷移に関しては、時間tに関して下記補正を行う。即ち、s−[P(t1)]−>s’ならばage(s,t)−[P(t+t1)]−>s’[t+t1/t1]、とする。ここで、s[e/t]:状態sからの遷移条件に現れる変数tを式eで置き換えることを表す。尚、再構成したP(t)が矛盾した式になっている場合、その遷移は削除し、その遷移へのみ到達する状態全てを削除するものとする。
(4)各遷移の時間変数tは下記に示すように、異なる名前に変更する。即ち、s−[P(t)]−>s’−[Q(t)]−>s’’はs−[P(t1)]−>s’−[Q(t2)]−>s’’に変更する。age(s,t)に関する補正によって、各遷移条件はそれ以前の遷移の時間変数も含む式になるため、それらを区別するために、この変更が必要となる。
(5)上限を与えたTNFAがある場合、構成後のTNFAでその初期状態を含む状態間の遷移がその上限を満たさない場合、その途中にある状態で上限を満たす遷移内に存在する状態を削除対象外とし、削除対象外とならなかった状態を削除する。
尚、Abstraction of each CFGのステップで抽象化対象から除外されたRPCTLに用いられている変数を伴う遷移が現れるとその次の状態まで構成し、上記構成方針での作成での切りの良いところで、Abstraction of TNFAをコールし、構成中のTNFAの抽象化を行う。
次にC−TNFAからTNFAへの変換処理を詳細に説明する。先ず、遷移回数の仮定による遷移時間の上限を決定する。即ち、各TNFAの強連結成分を求め、強連結成分内での遷移枝を1回のみ通る各遷移の下限遷移時間の総計が最大となる最長パスと、そのパス上の頂点でその後段の頂点への遷移時間の下限が最小の頂点を求め、最長パスにその後段頂点へのパスを追加したパスの2つを求める。次いで、夫々のパスの下限遷移時間の総計を求める。これにより、
Command Interface:22 23
Graphics Rendering Unit:28 29
Display Unit:11 12
が求まる。さて、各TNFAの2つ目の下限遷移時間の総計から1引いた値、
Command Interface:22
Graphics Rendering Unit:28
Display Unit:11
を求める。各TNFAの各遷移の上限時間を、他のTNFAに対して求めた値の最小値を与える事で決定し、得られた時間遷移の上限値が矛盾したものとなっていないかを、既に上限が与えられている遷移の上限値と比較する事で調べ、もし、矛盾がでたなら2回に増加させる。そうでなければ、上限が与えられていない遷移に求めた上限を与える事で線形不等式の論理結合を構成する。特に、回数を増加させる場合、最長パスの下限遷移時間の総計と回数の積を取った値と、その値に先に求めた最小の遷移時間を加えた値を算出すればよい。
尚、パラメトリック・モデルチェッキングを実施し、パラメータ条件が非負整数解を持たない場合にも回数の増加を行って処理をすすめる事とする。ここで、非負整数解の算出には、線形計画法を用いる。具体的には、フリーソフトLP−SOLVを用いて得られたパラメータ条件を満たす範囲で、パラメータの和が最小となる解を算出する。仮に、得られた解が意味をなさない場合は、パラメータの最小値を付加するなどして対処する。
さて、本例の場合、遷移枝を一回のみ遷移可能とした仮定では、各TNFAの遷移時間の上限として
Command Interface:11
Graphics Rendering Unit:11
Display Unit:22
が求まる。また、矛盾が起こることなく、以下に示す線形不等式の論理結合、
0<=k1+k2+kloop1<=7 && 5<=kb1+kb2+kb3+kl<=8 && 7<=kb1+3kb2+kb3+kl<=11 && 1<=kl<=11 && 1<=k1+k2+k3+kloop1+kl<=6 && 3<=k4<=11 && 5<=kb1+kb2+kb3+kl<=11 && 6<=kb1+4kb2+kb3+3kr1<=12 && 1<=3kr2+kl<=8 && 9<=kb1+5kb2+kb3+kl<=12 && kr1=kb2−1 && 8<=kb1+5kb2+kb3<=24 && 1<=kl+6kd<=19
が得られる。また、遷移枝を2回まで遷移可能とした場合、各TNFAの遷移時間の上限として
Command Interface:22
Graphics Rendering Unit:22
Display Unit:44
が求まり、以下に示す線形不等式の論理結合、
0<=k1+k2+kloop1<=18 && 5<=kb1+kb2+kb3+kl<=19 && 7<=kb1+3kb2+kb3+kl<=22 && 1<=kl<=22 && 1<=k1+k2+k3+kloop1+kl<=17 && 3<=k4<=2 && 5<=kb1+kb2+kb3+kl<=22 && 6<=kb1+4kb2+kb3+3kr1<=23 && 1<=3kr2+kl<=19 && 9<=kb1+5kb2+kb3+kl<=23 && kr1=kb2−1 && 8<=kb1+5kb2+kb3<=46 && 1<=kl+6kd<=41
が得られる。
この工程は、Assume Guarantee Reasoningと呼ばれる手法であり、パラメトリック解析での実施は公知ではない。
第69図には第61図、第64図、第68図で求めたTNFAの積TNFAの構成例が示される。これに基づいてTNFAを求める過程が第70図乃至第76図に示される。
《Abstraction of TNFA》
TNFAの抽象化処理について説明する。先ず、そのアルゴリズムの概要を説明する。TNFAで抽象化時に残した変数への代入を行っている遷移枝と、その遷移枝の始点ノード及び終点ノードのみを残し、残すべき頂点を始点として、次に残すべき頂点が現れるまで頂点と辺をトラバースしながら遷移時間を再計算する事で、その他の頂点を全て抽象化する。但し、葉に対応する状態は抽象化の対象から除外する。
先の例では抽象化の実施がまだ起こらない段階までしかTNFAを構成しなかったので、抽象化が必要となる様先の例を意図的に若干修正して、第77図乃至第79図ににC−TNFA2TNFAでAbstraction of TNFAを適時コールした場合の処理の経過の一部を示す。ここでは、klには具体的な値は与えないものとする。
《パラメトリック解析結果》
前記文献に述べられているアルゴリズムを用いて、遷移を2回以上通らない制約で、探索深さ最大値16として、以下の検証性質
EF(<displayend>((AF(<renderbegin>true))and((AF(<renderend>true))AU(<displaybegin>true))))に関してパラメタ条件を導出すると、以下の条件、
0<=kd && 0<=kr2 && 0<=kr1 && 0<=kb3 && 0<=kb2 && 0<=kb1 && 0<=kloop1 && 0<=k5 && 4<=k4 && 0<=k3 && 0<=k1 && 0<=k2 && 12<=kb1+9kb2+kb3 && 4 <=kl)
を得る。これと先に求めた、遷移を2回以上通らないという制約から得られたパラメータ条件
0<=k1+k2+kloop1<=7 && 5<=kb1+kb2+kb3+kl<=8 && 7<=kb1+3kb2+kb3+kl<=11 && 1<=kl<=11 && 1<=k1+k2+k3+kloop1+kl<=6 && 3<=k4<=11 && 5<=kb1+kb2+kb3+kl<=11 && 6<=kb1+4kb2+kb3+3kr1<=12 && 1<=3kr2+kl<=8 && 9<=kb1+5kb2+kb3+kl<=12 && kr1=kb2−1 && 8<=kb1+5kb2+kb3<=24 && 1<=kl+6kd<=19
との論理積を取って、得られたパラメータ条件に対して、目的関数を各パラメタ値の合計として、これを最小化するという線形計画問題をフリーソフトLP_SOLVEにて解かせると、第80図の解を得る。
第80図の結果では、バスアクセス終了通知が0サイクルで行われなければならず、また、描画サイクルkr2と表示サイクルkdが0であるので、意味のある解とは言えないので、kb1=2,kb2=1,kb3=1の制約を追加し、第81図の解を得た。
第81図の結果でも、描画サイクルkr2と表示サイクルkdが0であるので、意味のある解とは言えないので、kb1=2,kb2=1,kb3=1の制約に加えてさらに、kr1以外のパラメタ変数は1以上という制約を追加し、第82図の解を得た。以後、このパラメータ値を採用して議論を進める。
《ハード合成》
ハードウェア合成処理についてその概要を先ず説明する。(1)〜(11)の方針にてハードウェアの生成が行なわれる。
(1)事前にRegisterクラスに登録された通信メソッドの種類からバスコマンドの割り当てを行う。
(2)ユーザ情報として、どのデバイスにどの共有レジスタが存在するかを受付け、各デバイス内のレジスタ数に対応するデバイス内アドレスを割り当てる。
(3)共有レジスタが割付られたデバイス(run()メソッド)の数を取得し、共有レジスタが割り当てられたデバイスにグローバルなアドレスを割り当てる。
(4)インライニング(展開)を実施しなかった通信メソッド以外のメソッドのインライニングを行う。(通信メソッドと指定したメソッド以外のメソッドは事前にインライニングされている事に注意。)
(5)パラメトリック解析結果から得られた、Basic Blockの実行サイクルを各デバイスの合成用CFGに反映する。
(6)各デバイス夫々のCFGを変形し、通信メソッドとそれ以外のコントロールフロー部が互いに通信するモデルに変換する。
(7)前記(6)で得られた変換後のCFG内の通信メソッドに対応する部分に、バスコマンド生成記述を挿入する。通信メソッドは、グローバルアドレス、共有レジスタアドレス、バスコマンドを出力し、データ読み出し・書き込みの何れかを実行する記述からなるCFGとなり、それらの信号生成・受理に要するサイクルは、パラメトリック解析の結果により決定される。
(8)共有レジスタアドレスから、各デバイス内のレジスタの配列インデックスを生成するアドレスデコーダとグローバル・アドレスを識別するアドレスデコーダを共有レジスタが割り当てられたデバイス内に生成し、出力トライステートを共有レジスタの出力に接続し、トライステート・イネーブル信号として、各デバイスからのデータ入力ステージを表す信号の論理和を用いる。共有レジスタの入力に関しては、取り込み動作が起こらない限り内部変数は前の値を保持する為バスから信号を接続すれば良よく、各デバイスからのデータ入力ステージを表す信号の論理和を元にデータ取り込み判定を行う。但し、これらはCFGとして表現する。(自デバイス内に共有レジスタがあったとしても、この方式に従って、アクセスが行われているものとする。)
(9)変形等で得られた各CFGの信号通信関係(入力、出力)を識別し(バスは入出力)、夫々をモジュールとして識別する。
(10)各CFGを「サイクルアキュレートなプログラム記述からのハード合成」に従って、HDLへと変換する。
(11)バスに対してリピータ回路をHDLの形式で挿入する。
前記バスコマンドの割り当てに関し、本例で登録したバスアクセス・メソッドは、sync_read、sync_write、sync_burst_read、sync_burst_write、endBurstAccessであるが、各run()メソッドのCFGを解析すると、実際に用いられているバスアクセスメソッドは、sync_burst_read、sync_burst_write、endBurstAccessであるため、バスコマンドを
sync_burst_read 2’b00
sync_burst_write 2’b01
endBurstAccess 2’b10
NOP 2’b11
のように割り当てる。
上記アドレス割り当てに関しては、共有レジスタはUnified Memoryにのみ割り付けられ、Unified Memoryの仕様から割り付けられた共有レジスタは
mem_con_reg.current_value[0]:コマンドフラグ0、
mem_con_reg.current_value[1]:描画コマンド0、
mem_con_reg.current_value[2]:コマンドフラグ1、
mem_con_reg.current_value[3]:描画コマンド1、
mem_con_reg.current_value[4]:描画ソース・データ、及び描画後の表示用データ、
mem_con_reg.current_value[5]:描画ソース・データ、及び描画後の表示用データ、
mem_con_reg.current_value[6]:描画ソース・データ、及び描画後の表示用データ、
mem_con_reg.current_value[7]:描画ソース・データ、及び描画後の表示用データ、
mem_con_reg.current_value[8]:描画ソース・データ、及び描画後の表示用データ、
mem_con_reg.current_value[9]:描画ソース・データ、及び描画後の表示用データ、となる。尚、ユーザ情報から各レジスタのビット幅が指定されているものとし、それぞれ32ビット(unsigned int)であるとする。
バスアクセス・メソッドはレジスタ内のバイトアクセス等を行わないので、各レジスタのアドレスを
mem_con_reg.current_value[0]:4’b0000、
mem_con_reg.current_value[1]:4’b0001、
mem_con_reg.current_value[2]:4’b0010、
mem_con_reg.current_value[3]:4’b0011、
mem_con_reg.current_value[4]:4’b0100、
mem_con_reg.current_value[5]:4’b0101、
mem_con_reg.current_value[6]:4’b0110、
mem_con_reg.current_value[7]:4’b0111、
mem_con_reg.current_value[8]:4’b1000、
mem_con_reg.current_value[9]:4’b1001、のように決定する。
また、アドレス割り当てに関し、共有レジスタが割り当てられたデバイスはUnified Memoryしか存在しないため、グローバルアドレスの割付を行わない。
尚、本例では1つのデバイスのみに共有レジスタの割り当てを行っているが、以降の説明に於いてこれは一般性を欠くものではない。それは、以降に処理手順を示す事で明らかとなる。
前記BasicBlockへの実行サイクルの割り当てに関しては、ここでは、Command Interfaceのみ取り上げて説明を行う。特に、先に求めたパラメータ値から、kl=4,kb1=2,kb2=1,kb3=1、k1=k2=k3=1、として説明を行う。パラメータ条件から、各BasicBlockの下に割り当てられたサイクル数のクロック境界を挿入する。ここでは、バスアクセス・メソッドを扱う対象としていない事に注意。更に、与えたパラメータで、例を示しているが一般性を失わない事に注意。次ページに変形後のCFGを示す。尚、klの値は、直接各デバイスのハード合成用CFGには影響を与えない事にも注意。これは、固定優先度スケジューラにのみ影響する。第83図にはBasicBlockへの実行サイクルの割り当ての例が示される。
固定優先度スケジューラの修正に関しては、既に得られているFSM(Finite State Machine)の遷移サイクルをklに変更する、即ち、クロック境界を各遷移枝に4つ付加すれば良い。ここからのHDL生成は、各状態からの遷移を分岐ノードに表現し直し、かつ各状態での信号代入はその状態への遷移枝上での最後のクロック境界直下にBasicBlockを設け、そこにレジスタ代入文を記述する形式で置き換える事で、このFMS自体をCFGと見做す事で、「サイクルアキュレートな記述からのHDL生成」を用いる事で可能である。第84図に示す固定優先度スケジューラの一部を用いて変形後のCFGが第85図に示される。
CFGの変形に関しては、元のCFGからバスアクセス・メソッドの括りだしを行い、バスアクセス・メソッドと元のCFGとの通信ノードを設る。具体的には、下記を行う。
1)ハード合成用のCFG生成段階で、クロック境界を含むバスアクセス・メソッドのクロックをバスアクセス・メソッドを表すノードの直下にクロック境界を追加したが、これを削除する。
2)バスアクセス・メソッドを表すノードを下記処理を行うBasic Blockに置き換える。
▲1▼出力信号start_commに1を代入する。
▲2▼バスコマンドを出力信号bus_cmdに代入する。バースト転送の場合、初期サイクルでは、
〈1〉出力信号initの0を代入
〈2〉アクセスするデバイスのアドレスと共有レジスタのアドレスを連結して出力信号addressに代入
〈3〉クロック境界挿入×nbf
〈4〉リードメソッドなら、代入すべき変数に入力信号data_inを代入
〈5〉ライトメソッドなら、出力すべき値または変数を出力信号data_outに代入
〈6〉クロック境界×mbf、を行う。ここで、nbf+mbf=kb1である。この例では、nbf=mbf=1とする。
バースト転送の場合、転送終了では、
〈1〉クロック境界挿入×n、を行う。ここで、n=kb3である。ここでは、n=1とする。
バースト転送の場合、それ以外では、
〈1〉出力信号initに1を代入
〈2〉アクセスするデバイスのアドレスと共有レジスタのアドレスを連結して出力信号addressに代入
〈3〉クロック境界挿入×nb
〈4〉リードメソッドなら、代入すべき変数に入力信号data_inを代入
〈5〉ライトメソッドなら、出力すべき値または変数を出力信号data_outに代入
〈6〉クロック境界×mbを行う。ここで、nb+mb=kb2である。この例では、nb=0、mb=1とする。
シングル転送の場合、
〈1〉アクセスするデバイスのアドレスと共有レジスタのアドレスを連結して出力信号addressに代入
〈2〉クロック境界挿入×ns
〈3〉リードメソッドなら、代入すべき変数に入力信号data_inを代入
〈4〉ライトメソッドなら、出力すべき値または変数を出力信号data_outに代入
〈5〉クロック境界挿入×ms、を行う。ここで、ns+ms=ksである。
▲3▼出力信号start_commに0を代入する。
3)バスアクセスメソッドを表す孤立ノードを作成し、置き換えて生成したBasic Blockとの通信ノードを設ける。通信ノードとして、
start_comm:Basic Block→孤立ノード
bus_cmd:Basic Block→孤立ノード
address:Basic Block→孤立ノード
data_in:孤立ノード →Basic Block
data_out:Basic Block→孤立ノード、を設ける。
第86図及び第87図には変形後のCommand InterfaceのCFGの一部が示される。第87図において、クロック境界の傍らに記載された変数はパラメータであり、その数だけクロック境界を生成することを意味する。
孤立ノードへのCFGの割り当てに関しては、第88図のCFGを自動生成する。第88図において、特に、AD_BUSはアドレスバスを、D_BUSはデータバスを表し、data_in_en_iはデータ入力ステージを、data_out_en_iはデータ出力ステージを表す。ここで、iは各デバイスのインデックスを表す。また、アドレスバスのバス幅は、割り当てたバスコマンドのビット幅とアドレスのビット幅の合計とし、データバスはアクセスするレジスタのビット幅とする。また、クロック境界の傍にかかれた変数はパラメータであり、その数だけクロック境界を生成する事を意味する。尚、各変数の値は、CFGの変形過程で用いた変数の値と等しい。
共有レジスタに関しては、第89図の記述をインライン展開したものに対応するCFGの生成を行えばよい。但し、入出力変数であるAD_BUS、D_BUSの入力、出力への分離は行わず、またCFG上での最適化に於いては、AD_BUS、D_BUSに対する変数最適化は実施しないものとする。第89図、第90図及び第91図には共有レジスタに関する擬似C記述である。サイクルアキュレートな記述からのHDL生成に関しては本発明者による先の出願(特願2002−300073)を参照することができる。
以上本発明者によってなされた発明を実施形態に基づいて具体的に説明したが、本発明はそれに限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは言うまでもない。
例えば、積オートマトンの構成に関しては、TNFA積オートマトンを構成するとき、遷移枝の通過回数でAssume Guarantee Reasoningを実施したが、本来は、sync動作の通過回数で行うべきである。理由は、sync動作はバスアクセス動作を意味しており、並列に動いているTNFAが何回sync動作を実施したかは、そのTNFAに対応するデバイスがバスアクセスを何回行ったかに対応するからであり、Refinement及びパラメトリック・モデルチェッキングで得られるのは、遷移サイクルの条件のみならず、その検証性質を実施している間に各デバイスが高々どれだけバスアクセスを行うかの情報も得られるからである。但し、この手法であると、組み合わせ爆発を起し得るので、何らかの高速な枝切りが必要となる。
積オートマトンの構成に関しては、今回は、パラメトリック・モデルチェッキングの停止性を吟味せず、バウンデッド・モデルチェッキングとして、検証性質を満たす必要条件を求める事を行ったが、本来は十分を求める必要がある。その為、アルゴリズムの停止性に関する研究を更に行う必要がある。
バスモデルの拡張に関しては、単一双方向バスのみではなく、単方向バスや、ローカルバスを含むもの、またバス・ブリッジを介してバスが階層化されているような複数バスシステムを扱うようにしてもよい。
また、水平帰線期間のみを扱ったが、本来は垂直帰線期間もモデル化して、1フレームを表示している間に最低1フレーム分の描画が終了するための十分条件を求める必要がある。
Claims (3)
- コンピュータ装置がディジタル回路の設計支援プログラムを実行して、並列動作の記述が可能なプログラム言語を用いて複数のデバイスを定義したプログラム記述を前記コンピュータ装置が入力し、入力したプログラム記述を前記コンピュータ装置が中間表現に変換し、この中間表現に対し、実時間制約を満足するパラメータを前記コンピュータ装置が生成し、生成したパラメータに基づいてハードウェア記述言語による回路記述を前記コンピュータ装置が合成する処理を行ない、
前記中間表現は、コンカレントなコントロールフローフラグ、コンカレントなパラメータ付き時間オートマトン、又はパラメータ付き時間オートマトンであり、
前記パラメータ生成に、パラメトリック・モデルチェッキングを行い、
前記プログラム記述はrunメソッドを用いてデバイスの定義を行い、バリア同期を用いてデバイスのクロック同期を定義する、システム開発方法。 - 前記実時間制約はRPCTLで与えられる、請求項1記載のシステム開発方法。
- ディジタル回路の設計支援プログラムを実行するコンピュータ装置を備え、
前記コンピュータ装置は、前記設計支援プログラムを実行することによって、並列動作の記述が可能なプログラム言語を用いて複数のデバイスを定義したプログラム記述を入力する処理と、入力したプログラム記述を中間表現に変換する処理と、この中間表現に対し、実時間制約を満足するパラメータを生成する処理と、生成したパラメータに基づいてハードウェア記述言語による回路記述を合成する処理との各々を行ない、
前記プログラム記述はrunメソッドを用いてデバイスの定義を行い、バリア同期を用いてデバイスのクロック同期を定義する記述データである、データ処理システム。
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 JPWO2004038620A1 (ja) | 2006-02-23 |
JP3899104B2 true 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 |
TW200725412A (en) * | 2005-12-30 | 2007-07-01 | Tatung Co Ltd | Method for converting high-level programming language method into hardware component graph |
TW200725415A (en) * | 2005-12-30 | 2007-07-01 | Tatung Co Ltd | Method for automatically translating high level programming language into hardware description language |
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 | 株式会社東芝 | アーキテクチャ検証装置 |
US9027002B2 (en) | 2010-10-27 | 2015-05-05 | Hitachi, Ltd. | Method of converting source code and source code conversion program |
JP5770073B2 (ja) * | 2011-11-25 | 2015-08-26 | 株式会社ジャパンディスプレイ | 表示装置及び電子機器 |
CN102624476B (zh) * | 2012-01-10 | 2014-09-10 | 南京邮电大学 | 一种基于模型检测的无线传感器网络时间同步检验方法 |
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 |
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 |
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 US US10/533,062 patent/US20060015858A1/en not_active Abandoned
- 2003-10-07 JP JP2004546404A patent/JP3899104B2/ja not_active Expired - Fee Related
- 2003-10-07 WO PCT/JP2003/012840 patent/WO2004038620A1/ja active Application Filing
- 2003-10-07 AU AU2003272931A patent/AU2003272931A1/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
JPWO2004038620A1 (ja) | 2006-02-23 |
AU2003272931A1 (en) | 2004-05-13 |
US20060015858A1 (en) | 2006-01-19 |
WO2004038620A1 (ja) | 2004-05-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20210081258A1 (en) | Synthesis Path For Transforming Concurrent Programs Into Hardware Deployable on FPGA-Based Cloud Infrastructures | |
JP3899104B2 (ja) | システム開発方法及びデータ処理システム | |
US8417504B2 (en) | Conversion of circuit description to a transaction model | |
US8386973B2 (en) | Behavioral synthesis apparatus, method, and program having test bench generation function | |
JPH11213031A (ja) | ソフトウェアにおけるハードウェアの検証、およびその逆の検証 | |
Simpson | FPGA design | |
US7496869B1 (en) | Method and apparatus for implementing a program language description of a circuit design for an integrated circuit | |
Mulkers et al. | Analysis of shared data structures for compile-time garbage collection in logic programs | |
JP2008140405A (ja) | 電子回路と制御プログラムとのコバリデーション方法 | |
JP2002140379A (ja) | 高位合成方法および高位合成装置 | |
US20070271080A1 (en) | Model generation method for software/hardware collaboration design | |
US20070271533A1 (en) | System lsi verification system and system lsi verification method | |
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 | |
Ernst et al. | Hardware/software codesign of embedded systems the spi workbench | |
JP2007207120A (ja) | システム検証装置及びその検証方法 | |
Parri et al. | FaultFlow: A tool supporting an MDE approach for Timed Failure Logic Analysis | |
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 | |
Balboni et al. | Tosca: A pragmatic approach to co-design automation of control-dominated systems | |
Lisboa Malaquias et al. | A formal framework to design and prove trustworthy memory controllers | |
US20020170037A1 (en) | Apparatus and method for controlling event ordering in a mixed- language simulator | |
Ku et al. | Synthesis of asics with hercules and hebe | |
US6339751B1 (en) | Circuit design support apparatus and a method |
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 |