図面 (/)

技術 論理装置の動作シミュレーション方法並びに論理装置の動作シミュレーションプログラム及び同プログラムを記録したコンピュータ読み取り可能な記録媒体

出願人 富士通株式会社
発明者 松田明男朱強松崎和浩土居武史
出願日 2001年12月20日 (19年0ヶ月経過) 出願番号 2001-387198
公開日 2002年9月27日 (18年3ヶ月経過) 公開番号 2002-279011
状態 特許登録済
技術分野 マルチプログラミング CAD
主要キーワード 性能検証 到着順位 調停ルール スレッドマネージャ C言語 時間概念 ライトフラグ スレッド群
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2002年9月27日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

論理装置の設計の初期段階において、動作シミュレーションを行なって、機能の確認,アーキテクチャの評価を行なえるようにするとともに、アーキテクチャの変更に対しても最小限の記述の変更で柔軟に対応できるようにする。

解決手段

スレッドマネージャ11が、論理装置の動作完了までに必要となる機能を表したスレッド13の実行に必要なハードウェアリソース14をリソースマネージャ12が要求に応じて割り当て、さらに、スレッドマネージャ11がその割り当て結果に応じてスレッド13の実行状態を制御するとともに、スレッド13の実行が完了するまでスレッドマネージャ11とリソースマネージャ12とが連携してリソース要求リソース割り当て及びスレッド制御を繰り返し実行することにより、論理装置の動作完了までの動作をシミュレーションする。

概要

背景

従来、論理装置の設計はHDL(Hardware Description Language)を用いてRT(Register Transfer)レベルから設計を開始することが多い。しかし、RTレベルクロックサイクル精度のハードウェアを意図した技術なので、ハードウェアとソフトウェアが明確に分離していない設計初期段階の論理装置を表現して機能を検証したり性能を評価したりすることは困難である。

そこで、RTレベルよりも抽象度の高い設計の初期段階で論理装置を記述する言語〔例:C/C++,UML(Unified Modeling Language),SDL(Sp ecification and Description Language)など〕を用いる設計手法が数多く提案されている。例えば、以下に列記する文献がある。
「Hardware-Software Co-design of Embedded Systems - The POLIS approach」(F.Balarin,E.Sentovich,M.Chiodo,P.Giusto,H.Hsieh,B.Tabbara and A.Jurecska,L.Lavagno,C.Passerone,K.Suzuki and A.Sangiovanni-VinCentelli,Kluwer Academic Publishers,1997.)
「Coware - a design environmentfor heterogeneous hardware/software partitioning problem」(K.Rompaey,D.Verkest,I.Bolsens and H.De Man,Proceedings EuroDAC,1996.)
「An Object Oriented Programming Approach for Hardware Design」(S.Vernalde,P.Schaumont and I. Bolsens,IEEE Computer Society Workshop onVLSI,April,1999.)
「A Methodology and Design Environment for DSPASICFixed Point Refinement」(R.Cmar,L.Rijnders, P.Schaumount,S.Vernalde and I.Bolsens,Proceedings Design and Test in Europe Conference, pp. 271-276,March,1999.)
「Hardware Reuse at the Behavioral Level」(P.Schaumont,R.Cmar,S.Vernalde,M.Engels and I.Bolsens,The proceedings of 36th Design AutomationConference.ACM,1999,pp. 784-789,June 1999.)
「An Efficient Implementation of Reactivity for Modeling Hardware in the SCENIC Design Environment」(Stan Liao,Steve Tijang and Rajesh Gupta,Proceedings of the Design Automation Conference DAC'97,pp. 70-75, June 1999.)
「SpecC System-Level Design Methodology Applied to the Design of a GSMVocoder」(A.Gerstlauer,S.Zhao,A.Horak and D.Gajski,Proceedings of the Workshop on Synthesis And System Integration ofMIxed Technologies,April,2000.)
「On the use of C++ for system-on-chip design」(DiederikVerkest,Johan Cockx and Freddy Potargent,Proceedings of the IEEE Workshop on VLSI (IWV),pp.42-47,April,1999.)

これらの設計手法では論理装置の並列並行処理を実現するためにソフトウェアのスレッド技術〔参考文献「並列オペレーティングシステム」(福田晃,(株)コロナ社,pp.30,1997.),「Javaスレッドプログラミング」(Scott Oaks,Henry Wong共著,戸豊和,西利浩訳,(株)オーム社,1997.)など〕を導入している。

即ち、各スレッドを1つの処理ブロックマッピングして、ブロック間には「通信」機能を定義することで論理装置のシミュレーションを実現している。ここで、論理装置の設計コストに影響する大きな要素は二つ存在している。1つは手戻り作業の有無であり、もう1つは設計の再利用性である。即ち、手戻り作業が多いほど、設計コストは増加する。特に、設計仕様書(以下、単に「仕様」という)からいきなりHDLを用いてRTレベルの設計を始める場合に、仕様の確認を行なわず、実装設計を開始すると、実装した結果が要求されている仕様を満たさない場合に、仕様の見直しが必要となり、実装設計の再設計を行なわなければならないケースが多い。これは設計工数設計期間を大きく増大させる原因である。これを改善するために、早期に正確なパフォーマンス見積もりを行なうことが重要である。

もう一方、設計の再利用性に関しては、二種類の再利用の可能性があげられる。一つは以前設計したモジュールの再利用であり、もう一つは設計を段階化したときの途中段階の記述(ソースコード)の再利用である。例えば、設計の途中からパフォーマンスを見積もった結果によって、再設計になった場合に、ソースコードを変更しなければならないことは設計コストに影響する。この視点から、仕様書から直接RTレベルを設計する手法は設計コストが高い。なぜなら、設計を変更すると、最悪の場合、全てのRTレベルでの記述を再記述しなければならないことがあるからである。

以上のように、仕様から直接RTレベルで設計プロセスを開始することは設計コストの増大につながることがわかる。そこで、これを解決するために、システムの上位設計の手法が提案されている。例えば図30(A)及び図30(B)に示すような、段階的詳細化による設計アプローチである。この段階的詳細化による設計アプローチは、概略して、以下のような手順によって設計が行なわれる。

・仕様100から機能(ブロック)を抽出してブロック図化する〔図30(A)のステップA1〕。そして、そのブロック図に基づいて、例えば、C言語などによって、「UnTimed」レベルの機能モデル、つまり、時間概念を考慮しない機能モデルを構築(記述)する〔図30(A)のステップA2,図30(B)のステップB1〕。なお、このとき、機能(ブロック)間に依存関係があれば、その間には「通信」機能が定義(記述)され、それらの機能(ブロック)はシーケンシャルに実行される。

アーキテクチャの設計によって、ハードウェアにマッピングする機能ブロックの記述をBCA(Bus Cycle Accurate)に変更し〔図30(B)のステップB2〕、「通信」機能はバス通信プロトコルになる〔図30(B)のステップB3〕。この段階(レベル)でパフォーマンスの見積もりを行ない〔図30(A)のステップA3〕、仕様の確認を行なう。

・さらに記述をFCA(Full Cycle Accurate)に変更して〔図30(B)のステップB4〕、実際のRTレベルの記述に変更する〔図30(A)のステップA4〕。このとき、「通信」機能も記述に組み込む〔図30(A)のステップA5〕。以上のような段階的な詳細化によって、早期に仕様の確認ができ、実行可能な仕様を実現することができる。

概要

論理装置の設計の初期段階において、動作シミュレーションを行なって、機能の確認,アーキテクチャの評価を行なえるようにするとともに、アーキテクチャの変更に対しても最小限の記述の変更で柔軟に対応できるようにする。

スレッドマネージャ11が、論理装置の動作完了までに必要となる機能を表したスレッド13の実行に必要なハードウェアリソース14をリソースマネージャ12が要求に応じて割り当て、さらに、スレッドマネージャ11がその割り当て結果に応じてスレッド13の実行状態を制御するとともに、スレッド13の実行が完了するまでスレッドマネージャ11とリソースマネージャ12とが連携してリソース要求リソース割り当て及びスレッド制御を繰り返し実行することにより、論理装置の動作完了までの動作をシミュレーションする。

目的

本発明は、このような課題に鑑み創案されたもので、論理装置の設計の初期段階において、動作シミュレーションを行なって、機能の確認,アーキテクチャの評価を行なえるようにするとともに、アーキテクチャの変更に対しても最小限の記述の変更で柔軟に対応できるようにすることで、論理装置の設計コストを大幅に削減できるようにすることを目的とする。

効果

実績

技術文献被引用数
4件
牽制数
2件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

プログラム実行単位であるスレッドの制御を行なうスレッドマネージャが、論理装置設計仕様に応じて該論理装置の動作完了までに必要となる機能を表したスレッドの実行に必要なハードウェアリソースを、当該ハードウェアリソースを管理するリソースマネージャに要求するリソース要求テップと、該リソースマネージャが、該要求に応じたハードウェアリソースを予め規定されたルールに従って該スレッドに割り当てるリソース割り当てステップと、該スレッドマネージャが、該リソースマネージャによる割り当て結果に応じて該スレッドの実行状態を制御するスレッド制御ステップとを有するとともに、該スレッドの実行が完了するまで該スレッドマネージャと該リソースマネージャとが連携して上記の各ステップを繰り返し実行することにより、該論理装置の動作完了までの動作をシミュレーションすることを特徴とする、論理装置の動作シミュレーション方法

請求項2

該リソースマネージャが、該リソース要求ステップによるリソース要求を監視し、その監視結果に基づいて複数スレッド間のリソース要求のデッドロック状態を判定することを特徴とする、請求項1記載の論理装置の動作シミュレーション方法。

請求項3

該リソースマネージャが、該リソース要求ステップによるリソース要求によって割り当てられたハードウェアリソースに対するリードライト要求を監視し、その監視結果に基づいて複数スレッドのハードウェアリソースに対するリード/ライト動作競合状態を判定することを特徴とする、請求項1記載の論理装置の動作シミュレーション方法。

請求項4

該リソースマネージャが、該ハードウェアリソースに対するリソース要求数を監視し、その監視結果に基づいて該スレッドのボトルネックを検出することを特徴とする、請求項1記載の論理装置の動作シミュレーション方法。

請求項5

該リソースマネージャが、該ハードウェアリソースに対するリソース要求数を監視し、その監視結果に基づいて該リソース要求のブロッキングを検出することを特徴とする、請求項1記載の論理装置の動作シミュレーション方法。

請求項6

該スレッドに、該リソースマネージャによって割り当てられたハードウェアリソースを占有する時間についての予算を与えておくことを特徴とする、請求項1記載の論理装置の動作シミュレーション方法。

請求項7

該スレッドに、該機能の実行制限時間を与えておくことを特徴とする、請求項1記載の論理装置の動作シミュレーション方法。

請求項8

請求項1〜7のいずれか1項に記載の動作シミュレーション方法によるシミュレーション結果と、該論理装置の動作予測値とを比較する比較ステップと、該比較ステップでの比較結果を外部装置へ出力する出力ステップとを有することを特徴とする、論理装置の動作シミュレーション方法。

請求項9

論理装置の動作シミュレーションプログラムを記録したコンピュータ読み取り可能な記録媒体であって、該コンピュータを、プログラムの実行単位であるスレッドの制御を行なうスレッドマネージャ及び該スレッドの実行に必要なハードウェアリソースを管理するリソースマネージャとして機能させるとともに、該スレッドマネージャが、論理装置の設計仕様に応じて該論理装置の動作完了までに必要となる機能を表したスレッドの実行に必要なハードウェアリソースを該リソースマネージャに要求するリソース要求ステップと、該リソースマネージャが、該要求に応じたハードウェアリソースを予め規定されたルールに従って該スレッドに割り当てるリソース割り当てステップと、該スレッドマネージャが、該リソースマネージャによる割り当て結果に応じて該スレッドの実行状態を制御するスレッド制御ステップとを実行するとともに、該スレッドの実行が完了するまで該スレッドマネージャと該リソースマネージャとが連携して上記の各ステップを繰り返し実行することにより、該論理装置の動作完了までの動作をシミュレーションするためのプログラムが記録されていることを特徴とする、論理装置の動作シミュレーションプログラムを記録した記録媒体。

請求項10

論理装置の動作シミュレーションプログラムを記録したコンピュータ読み取り可能な記録媒体であって、該コンピュータに、請求項1〜7のいずれか1項に記載の動作シミュレーション方法によるシミュレーション結果と該論理装置の動作予測値とを比較する比較ステップと、該比較ステップでの比較結果を外部装置へ出力する出力ステップとを実行させるための動作シミュレーションプログラムが記録されたことを特徴とする、論理装置の動作シミュレーションプログラムを記録したコンピュータ読み取り可能な記録媒体。

請求項11

論理装置の動作シミュレーションプログラムであって、コンピュータを、プログラムの実行単位であるスレッドの制御を行なうスレッドマネージャ及び該スレッドの実行に必要なハードウェアリソースを管理するリソースマネージャとして機能させるとともに、該スレッドマネージャが、論理装置の設計仕様に応じて該論理装置の動作完了までに必要となる機能を表したスレッドの実行に必要なハードウェアリソースを該リソースマネージャに要求するリソース要求ステップと、該リソースマネージャが、該要求に応じたハードウェアリソースを予め規定されたルールに従って該スレッドに割り当てるリソース割り当てステップと、該スレッドマネージャが、該リソースマネージャによる割り当て結果に応じて該スレッドの実行状態を制御するスレッド制御ステップとを実行するとともに、該スレッドの処理が完了するまで該スレッドマネージャと該リソースマネージャとが連携して上記の各ステップを繰り返し実行することにより、該論理装置の動作完了までの動作をシミュレーションすることを特徴とする、論理装置の動作シミュレーションプログラム。

請求項12

論理装置の動作シミュレーションプログラムであって、コンピュータに、請求項1〜7のいずれか1項に記載の動作シミュレーション方法によるシミュレーション結果と該論理装置の動作予測値とを比較する比較ステップと、該比較ステップでの比較結果を外部装置へ出力する出力ステップとを実行させることを特徴とする、論理装置の動作シミュレーションプログラム。

技術分野

0001

本発明は、LSI(Large Scale Integrated circuit)やIC(IntegratedCircuit)などの論理装置を設計する上でその機能や性能の検証を目的として動作シミュレーションを行なうのに用いて好適な、論理装置の動作シミュレーション方法並びに論理装置の動作シミュレーションプログラム及び同プログラムを記録したコンピュータ読み取り可能な記録媒体に関する。

背景技術

0002

従来、論理装置の設計はHDL(Hardware Description Language)を用いてRT(Register Transfer)レベルから設計を開始することが多い。しかし、RTレベルクロックサイクル精度のハードウェアを意図した技術なので、ハードウェアとソフトウェアが明確に分離していない設計初期段階の論理装置を表現して機能を検証したり性能を評価したりすることは困難である。

0003

そこで、RTレベルよりも抽象度の高い設計の初期段階で論理装置を記述する言語〔例:C/C++,UML(Unified Modeling Language),SDL(Sp ecification and Description Language)など〕を用いる設計手法が数多く提案されている。例えば、以下に列記する文献がある。
「Hardware-Software Co-design of Embedded Systems - The POLIS approach」(F.Balarin,E.Sentovich,M.Chiodo,P.Giusto,H.Hsieh,B.Tabbara and A.Jurecska,L.Lavagno,C.Passerone,K.Suzuki and A.Sangiovanni-VinCentelli,Kluwer Academic Publishers,1997.)
「Coware - a design environmentfor heterogeneous hardware/software partitioning problem」(K.Rompaey,D.Verkest,I.Bolsens and H.De Man,Proceedings EuroDAC,1996.)
「An Object Oriented Programming Approach for Hardware Design」(S.Vernalde,P.Schaumont and I. Bolsens,IEEE Computer Society Workshop onVLSI,April,1999.)
「A Methodology and Design Environment for DSPASICFixed Point Refinement」(R.Cmar,L.Rijnders, P.Schaumount,S.Vernalde and I.Bolsens,Proceedings Design and Test in Europe Conference, pp. 271-276,March,1999.)
「Hardware Reuse at the Behavioral Level」(P.Schaumont,R.Cmar,S.Vernalde,M.Engels and I.Bolsens,The proceedings of 36th Design AutomationConference.ACM,1999,pp. 784-789,June 1999.)
「An Efficient Implementation of Reactivity for Modeling Hardware in the SCENIC Design Environment」(Stan Liao,Steve Tijang and Rajesh Gupta,Proceedings of the Design Automation Conference DAC'97,pp. 70-75, June 1999.)
「SpecC System-Level Design Methodology Applied to the Design of a GSMVocoder」(A.Gerstlauer,S.Zhao,A.Horak and D.Gajski,Proceedings of the Workshop on Synthesis And System Integration ofMIxed Technologies,April,2000.)
「On the use of C++ for system-on-chip design」(DiederikVerkest,Johan Cockx and Freddy Potargent,Proceedings of the IEEE Workshop on VLSI (IWV),pp.42-47,April,1999.)

0004

これらの設計手法では論理装置の並列並行処理を実現するためにソフトウェアのスレッド技術〔参考文献「並列オペレーティングシステム」(福田晃,(株)コロナ社,pp.30,1997.),「Javaスレッドプログラミング」(Scott Oaks,Henry Wong共著,戸豊和,西利浩訳,(株)オーム社,1997.)など〕を導入している。

0005

即ち、各スレッドを1つの処理ブロックマッピングして、ブロック間には「通信」機能を定義することで論理装置のシミュレーションを実現している。ここで、論理装置の設計コストに影響する大きな要素は二つ存在している。1つは手戻り作業の有無であり、もう1つは設計の再利用性である。即ち、手戻り作業が多いほど、設計コストは増加する。特に、設計仕様書(以下、単に「仕様」という)からいきなりHDLを用いてRTレベルの設計を始める場合に、仕様の確認を行なわず、実装設計を開始すると、実装した結果が要求されている仕様を満たさない場合に、仕様の見直しが必要となり、実装設計の再設計を行なわなければならないケースが多い。これは設計工数設計期間を大きく増大させる原因である。これを改善するために、早期に正確なパフォーマンス見積もりを行なうことが重要である。

0006

もう一方、設計の再利用性に関しては、二種類の再利用の可能性があげられる。一つは以前設計したモジュールの再利用であり、もう一つは設計を段階化したときの途中段階の記述(ソースコード)の再利用である。例えば、設計の途中からパフォーマンスを見積もった結果によって、再設計になった場合に、ソースコードを変更しなければならないことは設計コストに影響する。この視点から、仕様書から直接RTレベルを設計する手法は設計コストが高い。なぜなら、設計を変更すると、最悪の場合、全てのRTレベルでの記述を再記述しなければならないことがあるからである。

0007

以上のように、仕様から直接RTレベルで設計プロセスを開始することは設計コストの増大につながることがわかる。そこで、これを解決するために、システムの上位設計の手法が提案されている。例えば図30(A)及び図30(B)に示すような、段階的詳細化による設計アプローチである。この段階的詳細化による設計アプローチは、概略して、以下のような手順によって設計が行なわれる。

0008

・仕様100から機能(ブロック)を抽出してブロック図化する〔図30(A)のステップA1〕。そして、そのブロック図に基づいて、例えば、C言語などによって、「UnTimed」レベルの機能モデル、つまり、時間概念を考慮しない機能モデルを構築(記述)する〔図30(A)のステップA2,図30(B)のステップB1〕。なお、このとき、機能(ブロック)間に依存関係があれば、その間には「通信」機能が定義(記述)され、それらの機能(ブロック)はシーケンシャルに実行される。

0009

アーキテクチャの設計によって、ハードウェアにマッピングする機能ブロックの記述をBCA(Bus Cycle Accurate)に変更し〔図30(B)のステップB2〕、「通信」機能はバス通信プロトコルになる〔図30(B)のステップB3〕。この段階(レベル)でパフォーマンスの見積もりを行ない〔図30(A)のステップA3〕、仕様の確認を行なう。

0010

・さらに記述をFCA(Full Cycle Accurate)に変更して〔図30(B)のステップB4〕、実際のRTレベルの記述に変更する〔図30(A)のステップA4〕。このとき、「通信」機能も記述に組み込む〔図30(A)のステップA5〕。以上のような段階的な詳細化によって、早期に仕様の確認ができ、実行可能な仕様を実現することができる。

発明が解決しようとする課題

0011

しかしながら、上述したような従来手法では、各レベルでの変更を全て手作業で行なうため、上記の「UnTimed」レベルからBCAレベルに変更する際に余計な設計コストが必要となる。さらに、その段階でのパフォーマンスの見積もり(上記のステップA3)において、設計の見直しが必要になった場合、記述を変更しなければならない。

0012

また、従来手法では、機能(ブロック)の構成にアーキテクチャが反映されているため、アーキテクチャの変更が必要になった場合、その機能(ブロック)の構成を変更しなければならず、これに伴ってその記述も変更しなければならなくなる。

0013

例えば図31に示すように、BCA記述により、ハードウェア資源リソース)「A」を用いて機能「1」が実現(ハードウェア資源「A」に機能「1」がマッピングされる)とともに、ハードウェア資源「B」を用いて機能「2」が実現され、且つ、これらの機能「1」,「2」間に「通信」機能が定義された状態で、さらに、ハードウェア資源「A」を複数用いて上記と同じ機能「1」を追加実現する必要があった場合を想定する。

0014

この場合、追加分の機能「1」のBCA記述をハードウェア資源「A」の個数分だけ用意しなければならず、さらに、機能「1」と機能「2」との間の「通信」機能を既に定義済みの分も含めて再定義しなければならない。このように、従来手法では、機能(ブロック)の構成にアーキテクチャが反映されているため、アーキテクチャの変更が必要になる度に機能(ブロック)の記述を全て変更する必要があり、設計コストが大幅に増大し、設計効率が悪くなる。

0015

本発明は、このような課題に鑑み創案されたもので、論理装置の設計の初期段階において、動作シミュレーションを行なって、機能の確認,アーキテクチャの評価を行なえるようにするとともに、アーキテクチャの変更に対しても最小限の記述の変更で柔軟に対応できるようにすることで、論理装置の設計コストを大幅に削減できるようにすることを目的とする。

課題を解決するための手段

0016

上記の目的を達成するために、本発明の論理装置の動作シミュレーション方法(請求項1)は、プログラムの実行単位であるスレッドの制御を行なうスレッドマネージャが、論理装置の設計仕様に応じてその論理装置の動作完了までに必要となる機能を表したスレッドの実行に必要なハードウェアリソースを、そのハードウェアリソースを管理するリソースマネージャに要求するリソース要求ステップと、上記のリソースマネージャが、その要求に応じたハードウェアリソースを予め規定されたルールに従って上記スレッドに割り当てるリソース割り当てステップと、上記のスレッドマネージャが、このリソースマネージャによる割り当て結果に応じて上記スレッドの実行状態を制御するスレッド制御ステップとを有するとともに、上記スレッドの実行が完了するまで上記のスレッドマネージャとリソースマネージャとが連携して上記〜の各ステップを繰り返し実行することにより、論理装置の動作完了までの動作をシミュレーションすることを特徴としている。

0017

なお、上記のリソースマネージャは、上記のリソース要求ステップ()によるリソース要求を監視し、その監視結果に基づいて複数スレッド間のリソース要求のデッドロック状態を判定するようにしてもよい(請求項2)。

0018

また、上記のリソースマネージャは、上記のリソース要求ステップ()によるリソース要求によって割り当てられたハードウェアリソースに対するリードライト要求を監視し、その監視結果に基づいて複数スレッドのハードウェアリソースに対するリード/ライト動作競合状態を判定するようにしてもよい(請求項3)。

0019

さらに、上記のリソースマネージャは、上記のハードウェアリソースに対するリソース要求数を監視し、その監視結果に基づいてスレッドのボトルネックを検出するようにしてもよい(請求項4)。また、上記のリソースマネージャは、上記のハードウェアリソースに対するリソース要求数を監視し、その監視結果に基づいてリソース要求のブロッキングを検出するようにしてもよい(請求項5)。

0020

さらに、上記のスレッドには、上記のリソースマネージャによって割り当てられたハードウェアリソースを占有する時間についての予算を与えておいてもよいし(請求項6)、上記の機能に実行制限時間を与えておいてもよい(請求項7)。また、本発明の論理装置の動作シミュレーション方法(請求項8)は、上記の動作シミュレーション方法によるシミュレーション結果と、上記論理装置の動作予測値とを比較する比較ステップと、この比較ステップでの比較結果を外部装置へ出力する出力ステップとを有していることを特徴としている。

0021

次に、本発明の論理装置の動作シミュレーションプログラム(請求項11)は、コンピュータを、プログラムの実行単位であるスレッドの制御を行なうスレッドマネージャ及び上記スレッドの実行に必要なハードウェアリソースを管理するリソースマネージャとして機能させるとともに、上記のスレッドマネージャが、論理装置の設計仕様に応じて該論理装置の動作完了までに必要となる機能を表したスレッドの実行に必要なハードウェアリソースを上記のリソースマネージャに要求するリソース要求ステップと、上記のリソースマネージャが、その要求に応じたハードウェアリソースを予め規定されたルールに従って上記スレッドに割り当てるリソース割り当てステップと、上記のスレッドマネージャが、上記のリソースマネージャによる割り当て結果に応じて上記スレッドの実行状態を制御するスレッド制御ステップとを実行するとともに、上記スレッドの実行が完了するまで上記のスレッドマネージャとリソースマネージャとが連携して上記〜の各ステップを繰り返し実行することにより、論理装置の動作完了までの動作をシミュレーションすることを特徴としている。

0022

さらに、本発明の論理装置の動作シミュレーションプログラム(請求項12)は、コンピュータに、上記の動作シミュレーション方法によるシミュレーション結果と論理装置の動作予測値とを比較する比較ステップと、この比較ステップでの比較結果を外部装置へ出力する出力ステップとを実行させることを特徴としている。

0023

そして、本発明の論理装置の動作シミュレーションプログラムを記録したコンピュータ読み取り可能な記録媒体(請求項9,10)は、上記の請求項11,12記載の動作シミュレーションプログラムを記録したものである。

発明を実施するための最良の形態

0024

以下、図面を参照して本発明の実施の形態を説明する。
(A)第1実施形態の説明
図1は本発明の第1実施形態に係るパーソナルコンピュータなどの計算機情報処理装置)の構成を示すブロック図で、この図1に示す計算機1は、計算機本体2とディスプレイ表示装置)3とをそなえており、計算機本体2(以下、単に「本体2」と略記することがある)には、例えば、CPU(Central Processing Unit)4,主記憶部(メモリ)5,二次記憶装置ハードディスク)6,フロッピー登録商標ディスクFDドライブ7などがそなえられており、これらのコンポーネントPCI(Peripheral Component Interconnect)バスなどの内部バス8を介して相互に通信可能に接続されている。

0025

ここで、上記のCPU4は、計算機1としての動作を統括制御するためのもので、メモリ5やハードディスク6に内部バス8を介してアクセスして必要なソフトウェア(アプリケーション)プログラム(以下、単に「プログラム」ともいう)やアプリケーションデータなどを読み込んで動作することによって、計算機1として必要な機能(本実施形態では、特に、論理装置の動作シミュレーション装置としての機能)が発揮されるようになっている。なお、その動作結果(論理装置の動作シミュレーション結果を含む)は、適宜、ディスプレイ3に表示(出力)される。

0026

また、ハードディスク6は、上記のプログラムやアプリケーションデータなど(以下、説明の便宜上、単に「各種データ」と総称することがある)を予め、あるいは、インストールなどによって記憶しておくためのもので、ここに記憶されている各種データが、適宜、CPU4からのアクセス速度が高速なメモリ5に読み出されて、CPU4によるプログラムの実行が高速に行なわれるようになっている。

0027

さらに、FDドライブ7は、フロッピーディスク(FD;記録媒体)9に記録されている各種データをCPU4の制御のもとに読み出してハードディスク6に記憶することによって、各種データのインストールを可能にする機能を提供するもので、例えば、FD9に、論理装置の動作シミュレーションプログラム10が記録されていれば、このFD9からその動作シミュレーションプログラム10をインストールする(ハードディスク6に記憶する)ことによって、計算機1(CPU4)を論理装置の動作シミュレーション装置として機能させることが可能である。

0028

なお、上記の論理装置の動作シミュレーションプログラム10(以下、単に「シミュレーションプログラム10」、もしくは、「プログラム10」という)がハードディスク6あるいはメモリ5に記憶された時点で、そのプログラム10を保持したハードディスク6あるいはメモリ5が上記シミュレーションプログラム10を記録した記録媒体となることはいうまでもない。

0029

また、このプログラム10は、勿論、FD9以外の記録媒体〔例えば、CD−ROM光磁気ディスク(MO)など〕に記録されていてもよく、対応するドライブなどが本体2に装備されていれば、上記と同様に、それらの記録媒体からのインストールが可能である。さらに、記録媒体からのインストールだけでなく、例えば、インターネットなどの所望の通信回線ネットワーク)を介したオンラインでのインストールも可能である。つまり、プログラム10は、FD9やCD−ROM,MOなどの記録媒体として提供されてもよいし、インターネットなどの所望の通信回線を介して提供されてもよい。

0030

さて次に、以下では、上記のシミュレーションプログラム10の詳細について説明する。本実施形態のシミュレーションプログラム10は、例えば図2に示すようなOMT(Object-oriented Modeling Technique)に基づいて記述(オブジェクト指向プログラミング)されており、その要部に着目すると、この図2に示すように、スレッドマネージャ11,リソースマネージャ12,スレッド13,リソース14,テストベンチ15,テストデータ16,入力キュー17,実行待ちキュー18,(リソース)要求19,回答21,リソース回答キュー22などが定義されている。なお、「OMT」については、例えば、文献「オブジェクト指向方法論OMT」(J.ランボー,M.ブラハ,W.プレラニ,F.エディ,W.ローレンセン共著,羽生田栄一訳,(株)トッパン,1995.)になどに詳しく解説されている。

0031

ここで、まず、テストベンチ15は、論理装置の動作シミュレーションを行なうのに必要なテストデータ16を所定のデータ生成ルールに従って生成してから実行権利を入力キュー17に譲るという機能を提供するもので、このテストベンチ15で生成されたテストデータ16がテストベンチ15の所有する入力キュー17に順次格納されたのち、スレッドマネージャ11によって順次取り出されて、スレッド13の生成に使用されるようになっている。

0032

次に、上記のスレッド13は、「実行権利を譲る」,「実行する」,「停止する」,「停止する」,「再開する」,「開始する」,「消滅する」,「生成する」などの関数(OMTでは「メソッド」と呼ばれる)が定義されることにより、スレッドマネージャ11から実行権利を譲り受けた場合にスレッド13の実行状態が制御されるようになっている。

0033

このスレッド13は、プログラムの実行単位を表し、本実施形態では、実現したい論理装置の設計仕様に応じて必要となる論理装置の入力から出力(動作完了)までの処理(機能)を表した(定義した)逐次フローとして記述される。仮に、論理装置の入力から出力までに必要な処理(機能)を処理A→処理B→処理Cとし、これらを1つのスレッド13に表すとすると、例えばC++記述スタイルを用いた場合、図5に示すように記述される。なお、以降の説明においても、シミュレーションプログラム10の具体的な記述例については、特に断らない限り、C++記述スタイルを適用するものとする。

0034

そして、上記のスレッド13は、実行状態になると、その進行(即ち、上記の処理A,B,Cなどの「メソッド」の実行)のためにリソース14を確保する必要がある場合はそれを要求する要求(リソース要求)19を、確保したリソース14を解放する場合にはそれを要求する要求(解放要求)19を、それぞれ、自立的発行してリソース要求キュー20に順次格納してゆくようになっている。

0035

なお、ここでいうリソース14とは、本実施形態では、ハードウェア資源(ハードウェアリソース)に関する情報を意味し、例えば、プロセッサ,ASIC(Application Specific IntegratedCircuit),演算器などがそれぞれリソースデータとして定義される。

0036

次に、実行待ちキュー18は、複数のキューのそれぞれに実行待ちのスレッド13を格納する機能を提供するもので、この実行待ちキュー18は、スレッドマネージャ11に集約されている。

0037

つまり、本実施形態のスレッドマネージャ11は、実行待ちキュー18と1つ以上のスレッド13から構成され、スレッド13の進行(生成,実行,停止,再開,消滅などの「メソッド」)及び複数のスレッド13の実行スケジュール順序)を管理する(即ち、スレッド13の制御を行なう)タスクとして機能する。なお、スレッド13の次回の動作は、このスレッドマネージャ11が、リソースマネージャ12の発行する回答21をリソース回答キュー22から取り出して参照することで決定される(詳細については後述する)。

0038

さらに、リソースマネージャ12は、スレッド13が進行するのに(「メソッド」の実行に)必要なリソース14(種類及び個数)を管理し、予め規定された上記「調停ルール」に従って単位時間当たりのリソース要求19をリソース14の種類毎に調停しながら、リソース要求19に応じたリソース14を要求元のスレッド13に割り当てるものである。

0039

なお、このリソースマネージャ12によるリソース14の割り当て結果は回答21として発行され、一旦、リソース回答キュー22に格納(追加)されたのち、スレッドマネージャ11によって取り出されて参照される。また、上記の「単位時間」とは、リソースマネージャ12がリソース14の調停を行なう最小の時間単位を意味する。

0040

ここで、本リソースマネージャ12を、上記のスレッド13と同様にC++記述スタイルで記述すると、例えば図6に示すようになる。即ち、リソースマネージャ12が管理するリソース(R)14の種類を例えば“R1”,“R2”とし、上記のリソース要求キュー20とリソース回答キュー22とを定義する。

0041

そして、要求メソッド31a、リソース14の解放を行なう解放メソッド31b、リソース14の調停を行なう調停メソッド31cをそれぞれ定義する。ここで、要求メソッド31aは、どの種類のリソース14(“R1”or“R2”)を要求するのかをパラメータとして明確に指定し、要求したリソース14とその要求19を出したスレッド13のスレッドIDとを要求メッセージとしてリソース要求キュー20に登録する操作を行なうための関数である。

0042

また、解放メソッド31bは、リソース14の解放を行ない、解放したリソース14の個数を1つ増やす操作を行なう関数であり、調停メソッド31cは、リソース14の種類(“R1”,“R2”)毎にそれぞれの「調停ルール」に従ってリソース割り当ての調停を行なうための関数で、破線枠311内の記述により、リソース要求キュー20が空でない限り、リソース要求キュー20から1つずつ要求19が取り出され、例えば、リソース14の種類が“R1”の場合は破線枠312及び313内の記述が実行され、リソース14の種類が“R2”の場合は破線枠314及び315内の記述が実行される。

0043

なお、破線枠312,314内の記述は、要求されたリソース14(“R1”もしくは“R2”)の個数がその時点で0以下であれば、割り当てられるリソース14が無いので、リソース割り当て結果の回答21として“False”をリソース回答キュー22に格納することを意味する。また、破線枠313,315内の記述は、上記以外の場合、即ち、要求されたリソース14(“R1”もしくは“R2”)の個数が1以上であれば、割り当て可能なので、そのリソース14の調停ルールに従ってリソース14の割り当てを行なって、その調停(割り当て)結果(“True”)を回答21としてリソース回答キュー22に格納することを意味する。

0044

以上のような構成により、本実施形態のシミュレーションプログラム10は、計算機1(CPU4)を、次のように動作(機能)させることが可能である。即ち、図3に模式的に示すように、まず、テストベンチ15が規定の「テスト生成ルール」に従ってテストデータ16を生成して(ステップS1)、入力キュー17に追加する(ステップS2)。

0045

テストベンチ15は、全てのテストデータ16を生成した後、スレッドマネージャ11に実行権利を譲る(ステップS3)。実行権利を譲り受けたスレッドマネージャ11は、入力キュー17からテストデータ16を取り出して(ステップS4)、それに対応するスレッド13を生成し(ステップS5;スレッド生成ステップ)、実行待ちキュー18に追加する(ステップS6)。なお、この時点でのスレッド13は何も実行していない未開始状態にある。

0046

そして、スレッドマネージャ11は、入力キュー17が空になってから実行待ちキュー18から実行待ちのスレッド13を取り出し、そのスレッド13が未開始状態であれば実行させて「実行状態」にする(ステップS7)。「実行状態」となったスレッド13は、リソースマネージャ12に対して最初の「メソッド」に必要なリソース14の確保を要求する(例えば、リソース「A」〜「C」のうちのリソース「B」に対するリソース要求19を発行する;ステップS8;リソース要求ステップ)。このリソース要求19は、スレッドマネージャ11によって、リソース要求キュー20に追加される。また、このリソース要求19を発行したスレッド13は、実行待ちキュー18の最後に追加される。

0047

その後、スレッドマネージャ11は、実行待ちキュー18に格納されている全てのスレッド13の処理(実行)が終了すると、実行権利をリソースマネージャ12に譲る(ステップS9)。実行権利を譲り受けたリソースマネージャ12は、リソース要求キュー20の先頭から、順次、リソース要求19を取り出して(ステップS10)、現在の「調停ルール」に従ってリソース14の割り当て調停を行ないながら、要求されたリソース14のスレッド13への割り当てを行ない、その結果(割り当てられたか否か;“True” or “False”)を回答21として発行し、リソース回答キュー22に追加してゆく(ステップS11;リソース割り当てステップ)。

0048

そして、リソース要求キュー20に格納されている全ての要求19に対するリソース割り当て処理が終了してから、リソースマネージャ12は、実行権利をスレッドマネージャ11に譲る(ステップS12)。実行権利を譲り受けたスレッドマネージャ11は、リソース回答キュー22から回答21を、順次、取り出して(ステップS13)、その回答21の内容が“True”(割り当てOK)であれば、スレッドIDに対応するスレッド13(この時点で、実行待ちキュー18の先頭に位置している)を実行させて(スレッド制御ステップ)、次の「メソッド」の実行に必要なリソース要求19を発行し、これをリソース要求キュー20に追加してから、実行したスレッド13を再び実行待ちキュー18の最後に追加する。

0049

なお、リソース回答キュー22から取り出した回答21が“False”(割り当てNG)であった場合、スレッドマネージャ11は、現在の(前回発行した)リソース要求19を再びリソース要求キュー20に追加してから、スレッド13を、「待ち状態」として再度、実行待ちキュー18の最後に追加する(スレッド制御ステップ)。また、全ての処理を終えた(リソース14の割り当てが完了した)スレッド13は消滅させて、実行待ちキュー18からそのスレッド13を削除する。

0050

以上のようにして、スレッドマネージャ11とリソースマネージャ12とが連携して、全てのスレッド13の実行(全ての「メソッド」の実行)が完了するまでリソース要求,リソース割り当て及び回答21に応じたスレッド13の実行状態の制御を繰り返し実行することによって、論理装置の動作シミュレーションを実施する。

0051

つまり、本実施形態のスレッドマネージャ11及びリソースマネージャ12は、それぞれ、図4に模式的に示すように、以下の各機能部を有しており、スレッド13の実行が完了するまで、これらのスレッドマネージャ11とリソースマネージャ12とが連携して上記のリソース要求19及びスレッド13の実行状態の制御を繰り返し実行して、その実行結果を例えばディスプレイ3に出力することによって、論理装置の動作完了までの動作をシミュレーションするようになっているのである。

0052

スレッドマネージャ11・テストデータ16の入力により、論理装置の設計仕様に応じてその論理装置の動作完了までに必要となる機能(処理)を表したスレッドを生成するスレッド生成手段110としての機能
・スレッド13の実行に必要なリソース14をリソースマネージャ12に要求するリソース要求手段111としての機能
・このリソース要求手段111による要求19に対するリソースマネージャ12による割り当て結果(回答21)に応じてスレッド13の実行状態を制御するスレッド制御手段112としての機能
リソースマネージャ12
・リソース要求19に応じたリソース14を予め規定された「調停ルール」に従ってスレッド13に割り当てるリソース割り当て手段121としての機能

0053

換言すれば、本実施形態では、論理装置に実装すべき「処理(機能)」が必要とするハードウェア資源に関する記述はスレッド13(「メソッド」)には行なわず、そのスレッド13の「メソッド」が実行されるときに、その都度、必要なリソース14がリソースマネージャ12によって動的に割り当てられるようになっているのである。つまり、従来のように実現すべき「機能」にアーキテクチャは反映されていないのである。

0054

従って、論理装置の設計初期段階における動作シミュレーションが実現できて設計初期段階において、仕様によって要求される「機能」を正確に実現できているかといった機能(アルゴリズム)の検証が行なえるとともに、アーキテクチャに変更が必要になった場合でも、「機能」の記述変更は殆ど行なわずに、リソース14やリソース14の「調停ルール」,スレッド13のスケジューリング,リソース14に対する要求などを、その変更に応じて変更するだけで、簡単に設計の再検証を行なうことが可能になる。

0055

なお、このようにリソース14やリソースの「調停ルール」,スレッドのスケジューリング,リソースに対する要求などを変更するだけで設計の再検証を行なえるということは、「機能」に適したアーキテクチャの探索や、「機能」をアーキテクチャへマッピングする際のアーキテクチャの性能評価,設計初期段階におけるタイミングの検証なども行なえることを意味する。

0056

(A1)第1実施形態の具体例の説明
さて次に、以下では、上述したシミュレーション方法について、具体例を挙げて、より詳細に説明する。即ち、ここでは、QoS(Quality of Service)システムの設計とその動作シミュレーションを行なう場合について説明する。なお、ここでいう「QoSシステム」とは、IP(Internet Protocol)ルータなどのパケット転送装置において、例えば図7に模式的に示すように、入力(受信)パケット41を或るルールに従ってクラス分けして複数のパケットキュー45に格納し、最終的に、これらの各キュー45から規定のサービスレート満足するよう〔規定のサービスレートに応じた重み付け(W0〜W3など)に応じて〕パケット41を出力するというものである。「QoS」の詳細については例えば、文献「インターネットQoS」(Paul Ferguson,Geoff Huston 共著,戸田 巖監訳,(株)オーム社,2000.)に記載されている。

0057

仕様からの機能の抽出
まず、最初のステップとして、図8に示すように、仕様40から実現すべきQoSシステムの「機能」を抽出する必要がある(ステップS20)。即ち、この場合は、以下の(a)〜(c)に示す機能が最低限必要になる。
(a)パケット41のクラス分け機能42(図7参照):Classify( )
この機能42は、パケットヘッダの「IP Precedenceフィールド」の値によってクラス分けする機能で、本実施形態では、例えば次表1に示すルールに従ってクラス分けを行なうものと仮定する。

0058

0059

(b)パケットをキュー45に格納する(キューイング)機能43:Queuing()
この機能43は、上記のクラス分け機能42によってクラス分けされたパケット41を対応するキュー45に格納する機能である。ここで、各キュー45には格納できる最大パケット数(以下、最大サイズという)が予め決められており、最大サイズを超える分のパケット41については廃棄されるものとする。

0060

(c)キュー45からパケットを取り出す(デキュー)機能44:Dequeuing()
このデキュー機能44は、各キュー45からパケット41を取り出す(出力する)機能であるが、各キュー45には予め「サービスレート」が定められており、この「サービスレート」によってキュー45からパケット41を出力するか否かを決定する。

0061

「機能」のスレッド化
次に、上記の各機能42〜44を「メソッド」としてスレッド化する(図8のステップS21)。即ち、前記の処理A→処理B→処理Cという一連の処理(機能)を、図5により前述したように次のような1つのスレッド13として表す。
Classify( ) → Queuing( ) → Dequeuing( )
ここで、このスレッド13の状態は次表2に示すように3種類とする。

0062

0063

なお、上記の各状態はリソース14の確保状況(割り当て結果),キューイング機能42〔Queuing( )〕,デキュー機能43〔Dequeuing( )〕の結果に依存する。例えば、Queuing( )を実行しようとしたときに、キュー45が既にいっぱいになっていて、パケット41を廃棄しなければならない場合には、スレッド13は「実行状態」から「終了状態」に変わる。また、リソース14が確保できない場合は、そのスレッド13は図3により上述したように実行待ちキュー18の最後に追加されて「待ち状態」となる。

0064

仕様40からのアーキテクチャの設計
さて、上記の一方で、仕様40を基にQoSシステムのアーキテクチャを設計する必要がある(ステップS22)。即ち、例えば、上記のClassify( )とQueuing( )とを或るリソース14(仮に、R1とする)の上に実現し、Dequeuing( )を別のリソース14(仮に、R2とする)の上に実現する。

0065

ここで、上記のClassify( )がリソースR1上に実現されているとき〔つまり、Classify( )がリソースR1を確保して実行中〕の実行遅延時間をT1c、同様に、Queuing( )がリソースR1上で実現されているときの実行遅延時間をT1q、Dequeuing( )がリソースR2上で実現されているときの実行遅延時間をT2dとする。

0066

また、リソースR1の競合が発生した場合は、Classify( )からの要求を優先し、リソースR2の競合が発生した場合は、要求の到着順位でリソースを割り当てるものとする。さらに、上記Dequeuing( )の性能をアップするため、リソースR2の数を例えば2つとする。

0067

アーキテクチャからのリソースの抽出
以上により、リソース14(R1,R2)の個数及び調停ルールが次表3に示すように定義される(図8のステップS23)。

0068

0069

スレッド13へのリソース要求の取り込み
次に、上記のClassify( ),Queuing( )およびDequeuing( )を実行するために、上記のリソースR1とR2を確保しなければならない(スレッド13にリソース要求を組み込む;図8のステップS24)。即ち、以下の手順(1)〜(5)を実現(記述)する必要がある。

0070

(1)パケット41が到着したら、スレッド13が動的に生成され、スレッド13が実行状態になる。
(2)Classify( )を実行するために、リソースR1を確保しようとする(リソースR1についての要求19を発行する)。確保できたら、次へ進む〔Classify( )を実行する〕。確保できなかったら、そのスレッド13は「待ち状態」になる。次のステップで(次に、スレッド13が「実行状態」となったときに)、再度、リソースR1の確保を行なう。

0071

(3)Classify( )を実行した後、Queuing( )を実行するために、リソースR1を確保しようとする。確保できたら、次へ進む〔Queuing( )を実行する〕。確保できなかったら、スレッド13は「待ち状態」となり、次のステップで(次にスレッド13が「実行状態」となったときに)、再度、リソースR1の確保を行なう。

0072

(4)Queuing( )を実行した後、Dequeuing( )を実行するために、リソースR2を確保しようとする。確保できたら、次へ進む〔Dequeuing( )を実行する〕。確保できなかったら、スレッド13は「待ち状態」となり、次のステップで(次にスレッド13が「実行状態」となったときに)、再度、リソースR2の確保を行なう。
(5)全ての処理が終了したので、スレッド13を終了させる。

0073

リソース調停ルールの記述
次に、複数のスレッド13が同じリソース14(R1又はR2)に対して要求した場合、リソース14の競合が起きるため、「調停ルール」を定義する必要がある(図8のステップS25)。

0074

まず、リソースR1の「調停ルール」(図6に示した破線枠313内における「R1の調停ルール」に相当)は以下の手順が実現されるように記述する。
(1)現在、リソースR1が空いているかどうかを判別する。空いていなければ、全ての要求19に対して、割り当てられない旨の回答21を発行する。空いていれば、次へ進む。

0075

(2)単位時間内の要求19の中にClassify( )を実行するためのリソース要求があれば、そのスレッド13(複数ある場合は最先に要求19を出したスレッド13)にリソースR1を割り当てる。Classify( )を実行するためのリソース要求19がなければ、最先に要求19を出したスレッド13にリソースR1を割り当てる。それ以外の要求19に対しては割り当てられない旨の回答21を発行する。

0076

一方、リソースR2の「調停ルール」(図6に示した破線枠314内における「R2の調停ルール」に相当)は以下の手順が実現されるように記述する。
(1)現在、リソースR2が空いているかどうかを判別する。空いていなければ、全ての要求19に対して、割り当てられない旨の回答21を発行する。空いていれば、次へ進む。

0077

(2)単位時間内の要求19の中で最先に要求を出したスレッド13にリソースR1を割り当てる。それ以外の要求19に対しては割り当てられない旨の回答21を発行する。

0078

シミュレーション
以上のようにしてQoSシステムに必要な「機能」をプログラミングし(シミュレーションプログラム10を構築し)、計算機1(CPU4)上で実行させることで、QoSシステムの動作シミュレーションを実施する(図8のステップS26)。即ち、計算機1(CPU4)が、図3及び図4により前述したように、スレッドマネージャ11及びリソースマネージャ12として動作することにより、QoSシステムの動作シミュレーションが実施される。

0079

シミュレーション結果と予測値の比較
上記のシミュレーションにより或るシミュレーション結果が得られる。即ち、例えば、パケット41が或るレートで出力されることが分かる。そして、このシミュレーション結果と、仕様40から予測される動作結果(予測値)40′とを比較する(図8のステップS27;比較ステップ)ことにより、設計したアルゴリズムが正しい(ステップS27のYESルートからステップS28)か否(設計ミス)か(ステップS27のNOルートからステップS29)が判断され、その結果が、例えば外部装置としてのディスプレイ3などに出力(表示)される(出力ステップ)。

0080

つまり、図8に破線枠51内に示す部分は、上述した論理装置のシミュレーション方法によるシミュレーション結果と、その論理装置の動作予測値とを比較する比較ステップ(S27)と、この比較ステップ(S27)での比較結果をディスプレイ3などの外部装置へ出力する出力ステップとを、計算機1(CPU4)に実行させて、論理装置の機能検証を行なうための(動作シミュレーション)プログラムとして機能する。

0081

なお、本プログラム51も、例えばFD9やCD−ROM,MOなどの記録媒体に記録することができ、その記録媒体に記録されたプログラム51を計算機1にインストールする(ハードディスク6に記憶する)ことで、計算機1(CPU4)を上述のごとく動作させることが可能になる。

0082

そして、設計ミス(例えば、廃棄されてしまうパケット41の数が規定よりも多いなど)であれば、キュー45のサイズを変える〔キュー45(リソース14)に関する記述を変更する〕などして、最適なアーキテクチャが得られるまで、上記のシミュレーションを行なって、QoSシステムに最適なアーキテクチャを探索する。

0083

なお、上記の予測値は、上記の例の場合、前述したClassify( )の実行遅延時間T1c,Queuing( )の実行遅延時間T1qおよびDequeuing( )の実行遅延時間T2dを基に算出できる。また、上記のシミュレーション結果や予測値との比較結果は、ディスプレイ3だけでなく、プリンタなどの周辺機器に出力することも可能である。

0084

以上のようにして、論理装置としてのQoSシステムの機能検証(システムとしての要求を満足しているか否かの検証)を、システムの設計初期段階で実施することができる。また、アーキテクチャに変更が必要になった場合でも、使用するリソース14(R1,R2)やリソース14の「調停ルール」,スレッド13のスケジューリング,リソース14に対する要求などを、その変更に応じて変更するだけで、簡単に設計(アルゴリズム)の再検証を行なうことができる。従って、手戻り、記述スタイルの変更が少ない柔軟性の高い設計手法(つまり、再利用性に優れた記述スタイル)を実現することが可能となり、システムの設計コストを大幅に削減することができる。

0085

(B)第1変形例の説明
ところで、上述したリソースマネージャ12には、例えば図9に示すように、デッドロック検出機構122を追加してもよい。このデッドロック検出機構122は、複数のスレッド13がリソース14を取り合うことによって「デッドロック」に陥る可能性があるか否かを検出するためのものである。

0086

なお、ここでいう「デッドロック」とは、2つ以上のスレッド13が互いに相手が占有しているリソース13を要求して解決しない特定の状態になっていることを意味する。「デッドロック」については、例えば、文献「現代オペレーティングシステムの基礎」(萩原宏,津田孝夫,大久保英嗣共著,(株)オーム社,pp.63,1995.)で説明されている。

0087

例えば、それぞれ図10に示すように記述されたスレッド13が2つ(仮に、スレッド“1”,“2”とする)存在していた場合を考える。ただし、ここでのリソース14(“A”)の数は3個、リソース14(“B”)の数は2個と仮定する。また、この図10において、「リソースA.要求( )」などの関数(括弧)内に表示された数値(この場合は“2”)はスレッドIDを表し、以降の説明においても同様とする。

0088

そして、このような場合、各スレッド“1”,“2”のそれぞれのリソース割付けグラフ(resource allocation graph)は、図11(A)に示すようになる。この図11(A)に示す状態を簡約(reduce)して表すと、図11(B)に示すような状態となるが、この状態で既にそれ以上の簡約が不可能(irreducible)な状態であることが分かる。

0089

これは、スレッド“1”とスレッド“2”との間で「デッドロック」が発生する可能性があることを意味する。デッドロック検出機構122は、このようにリソース割付けグラフを基に「デッドロック」の発生可能性を判断する。こうすることで、設計の初期段階において「デッドロック」の発生可能性を検出することが可能となり、論理装置の機能検証を行なうことが可能となる。

0090

(C)第2変形例の説明
さて、上記のリソースマネージャ12には、例えば図12に示すように、リード/ライト検出機構123を追加してもよい。ここで、このリード/ライト検出機構123は、次のような事象(1)〜(3)を監視(検出)することにより、リード/ライトエラーの発生可能性を検出するためのものである。

0091

(1)同一リソース14に対するリード要求とライト要求の同一単位時間内の発生
(2)既にライト要求によって占有されているリソース14に対するリード要求の発生
(3)既にリード要求によって占有されているリソース14に対するライト要求の発生

0092

つまり、このリード/ライト検出機構123の検出結果をみれば、複数のスレッド13がリソース14に対してシーケンシャルに書き込み動作もしくは読み出し動作を行なう時に、その順序が正しいか否かを判定(つまり、複数スレッド13間のリソース14に対するリード/ライト動作の競合状態を判定)して、設計した論理装置が正しく動作するか否かを検証することができるのである。

0093

これを実現するには、要求19の記述を例えば図13に示すように拡張する。即ち、次表4に示すような意味をもつ「リード/ライトフラグ」を定義する。

0094

0095

加えて、リソース14の記述を例えば図14に示すように拡張する。即ち、リソース14の解放が行なわれた場合には、必ず「カレントフラグ(CurrentFlag)」を“0”にするようにしておき(破線枠316参照)、この「カレントフラグ」が“0”でないときに、要求19の「リード/ライトフラグ」とリソース14側の「カレントフラグ」とが一致しなければ、「リード/ライトエラーの発生可能性がある」といったエラー情報がディスプレイ3などに出力される(破線枠317参照)ようにするのである。

0096

(D)第3変形例の説明
さらに、上記のリソースマネージャ12には、例えば図15に示すように、ボトルネック検出機構124を追加してもよい。ここで、このボトルネック検出機構124は、スレッド13の実行結果やリソース14に対するアクセス状況を基に「ボトルネック」の検出を行なうためのもので、例えば、リソース14の個数と種類を制限した環境下でシミュレーションを行なって、各リソース14に対するアクセス回数やリソース14を割り当てられなかった時の待ち時間などを確認することによって、論理装置の「ボトルネック」となっている部分を検出することが可能となる。

0097

具体的には、例えば図16に示すように、リソース14の記述に、要求の数(アクセス数)を計数する「メソッド」を加えるとともに、その計数結果を「要求合計メンバ関数〔要求合計( )〕」によって呼び出せるようにしておけば、リソース14のアクセス回数を監視する仕組みがリソースマネージャ12において実現される。

0098

つまり、ボトルネック検出機構124によって、各リソース14の「要求合計メンバ関数」を呼び出せば、それまでの各リソース14に対するアクセス頻度を調べることができ、例えば、アクセス頻度が最も多いリソース14は論理装置の「ボトルネック」になっている可能性があると推測することができる。従って、論理装置の設計初期段階で論理装置の性能検証(ボトルネックの有無の検証)を行なうことができる。

0099

(E)第4変形例の説明
また、上記のリソースマネージャ12には、例えば図17に示すように、ブロッキング検出機構125を追加してもよい。ここで、このブロッキング検出機構125は、スレッド13からのリソース14の要求19が所定の制限数を超えた場合の「ブロッキング」の発生状況を調べる機能を提供するもので、リソース14に例えば図18に示すような記述を加えることで実現される。

0100

そして、リソース14の「個数」を制限した(予め定めておく)環境下でシミュレーションを行なうことで、割り当てられるリソース数を超える要求19があった場合〔if文の条件(「個数」<0)を満足する場合〕には「ブロッキング」が発生したと考えられ、例えば「リソースAの要求はブロッキングする必要がある。」といったエラー情報をディスプレイ3などに出力する。

0101

このようにして、本変形例では、ブロッキング検出機構125により、リソース14の「個数」を制限した環境下でのスレッド13からのリソース要求が制限数を超えた場合のブロッキングの発生可能性を調べることで、論理装置の性能を評価することができる。

0102

なお、上述した第1〜第4変形例におけるデッドロック検出機構122,リード/ライト検出機構123,ボトルネック検出機構124,ブロッキング検出機構125は、論理装置の検証項目に応じて、全てあるいは一部の組み合わせでそなえられていてもよい。

0103

(F)第5変形例の説明
ところで、上記のスレッド13には、そのスレッド13に記述されている一連の処理(「機能」;「メソッド」)に必要な実行時間の見積もり値(つまり、リソースマネージャ12によって割り当てられたリソース14を占有する時間についての予算)である「タイムバジェット」を各「機能」に対してそれぞれ設定してもよい。

0104

即ち、図8により前述したようにアーキテクチャからリソース14を抽出して各リソース14に処理をマッピングする際に(ステップS24にてスレッド13にリソース要求を組み込んだ後)、各処理の見積もり時間(タイムバジェット)をスレッド13に追加する(図19のステップS25′)。

0105

例えば図20に示すように、スレッド13に記述される「機能」を処理1,処理2とすると、それぞれに対してdelay(処理1のタイムバジェット),delay(処理2のタイムバジェット)を設定するのである。そして、仕様40から論理装置がn個の入力データを処理する際の実行時間の制限をTとし(図19のステップS26b)、テストベンチ15からn個のデータを生成させて、前述したごとくシミュレーションを実行する(ステップ26a)。

0106

その後、全てのスレッド13が消滅されるまでの時間tを計測し、その計測時間tが制限時間T内であれば正しい設計と判断できる(図19のステップS27′のYESルートからステップS28′)。逆に、計測時間tが制限時間Tよりも大きい場合には仕様40の性能要件を満たしていないと判断できる(図19のステップS27′のNOルートからステップS29′)。

0107

このようにして、各種「機能」の組み合わせで構成される論理装置が、仕様40により要求される性能要件を満たしているか否かを、設計の初期段階にて確認することができる。

0108

(G)第6変形例の説明
なお、上記のスレッド13には、例えば図21に示すように、上記のステップS24にてスレッド13にリソース要求を組み込む前に、図22に示すようにして「ライフタイム」を設定してもよい(ステップS21′)。なお、ここでいう「ライフタイム」とは、「機能」の実行制限時間を表す。

0109

そして、第5変形例にて上述したようにスレッド13に「タイムバジェット」を設定(ステップS25′)した上で、シミュレーションを実行し(ステップS26″)、スレッド13が消滅する前にJudgeLifeTime( )関数(図22参照)を(例えばリソースマネージャ12から)呼び出せば、上述した「タイムバジェット」による論理装置の性能検証に加えて、そのスレッド13に設定した「ライフタイム」が切れたか否か、つまり、「ライフタイム」内に処理が完了したか否かを判定することができる(ステップS27″)。

0110

この判定の結果、「ライフタイム」内にそのスレッド13の処理が完了していれば、論理装置が仕様40により要求されるリアルタイム性に関する性能要件を満足している(正しい設計である)と判断でき(ステップS27″のYESルートからステップS28″)、逆に、「ライフタイム」内に処理が完了していなければ、リアルタイム性に関する性能要件を満足していないと判断できる(ステップS29″)。

0111

このように、本変形例では、スレッド13に「タイムバジェット」と「ライフタイム」とを設定することで、各種「機能」の組み合わせで成る論理装置全体としての処理時間に関する性能要件とリアルタイム性に関する性能要件とを、論理装置の設計初期段階において検証することが可能となる。なお、本変形例では、「タイムバジェット」と「ライフタイム」の双方を設定しているが、勿論、「ライフタイム」のみを設定して、論理装置のリアルタイム性のみを検証するようにしてもよい。

0112

また、これらの「タイムバジェット」,「ライフタイム」は、上述した例ではスレッド13に記述しているが、リソース14に記述することも可能である。例えば、メモリやバッファなどの記憶素子でのデータ保持時間が規定されるケースであれば、その記憶素子(リソース)に対して「タイムバジェット」や「ライフタイム」もしくはその両方を記述してもよい。

0113

(H)第7変形例の説明
上述した実施形態では、論理装置の動作完了までに必要な一連の処理(機能)を1つのスレッド13に表した場合について説明したが、上記「一連の処理」は、例えば図23に模式的に示すように、複数の逐次的なスレッド13(スレッド“1”〜スレッド“n”)に表されていてもよい。

0114

この場合の動作は次のようになる。即ち、外部入力(テストデータ16の入力)によりスレッドマネージャ11が最初のスレッド“1”を生成する。すると、スレッド“1”は処理“1”を実行して、処理“1”に必要なリソース14をリソースマネージャ12に要求する。

0115

これにより、スレッド“1”にリソース14が割り当てられてスレッド“1”が処理“1”を完了し、スレッドマネージャ11によって消滅させられる際に、次のスレッド“2”を生成する。なお、リソース14が割り当てられなかった場合は、この場合も、そのスレッド13はスレッドマネージャ11によって「待ち状態」に制御される。

0116

以降、スレッド“i”(ただし、i=1〜n−1)が消滅する際にそのスレッド“i”が次のスレッド“i+1”を生成する。このようにして、論理装置の入力から動作完了までの一連の処理を一連の逐次的なスレッド13に表現する。つまり、本変形例は、スレッドマネージャ11が行なうスレッド13の生成を、スレッド13からも生成できるようにしたものである。

0117

具体的に、これを実現するには、例えば図24に示すように、スレッド13に対して「終了を待つ( )」と言う「メソッド」を追加するとともに、処理“1”,処理“2”,処理“3”,…に対応したスレッド“1”,スレッド“2”,スレッド“3”,…を追加する。

0118

これにより、各処理“1”,“2”,“3”,…に対して1つずつスレッド13が生成され、それぞれのスレッド13の生成タイミングは前のスレッド13が処理を終了した後になる。これにより、スレッド13間の依存関係が前述した実施形態よりもさらに明確になる。

0119

そして、このように構成したスレッド13を図3により前述したシステムに組み込んで設計の初期段階における論理装置のシミュレーションを行なう。即ち、この場合も、全てのスレッド13の処理が完了(全てのスレッド13が消滅)するまで、スレッドマネージャ11とリソースマネージャ12とが連携して、リソース14の要求,リソース14の割り当て及びリソース14の割り当て結果に応じたスレッド13の実行状態の制御を繰り返すことによって、論理装置の動作シミュレーションを実現する。

0120

このように、本変形例では、論理装置の入力から動作完了までの一連の処理を一連の逐次的なスレッド13に表現して、シミュレーションを行なうので、論理装置に必要な処理の依存関係を明確にした上で、その機能検証を設計初期段階において行なうことができる。

0121

(I)第8変形例の説明
なお、上記の論理装置の動作完了までの一連の処理は、例えば図25に模式的に示すように、複数の逐次的または並行に実行されるスレッド13で表してもよい。即ち、第7変形例にて上述したようにスレッド13が消滅する際に、そのスレッド13が複数のスレッド13を同時に生成して各スレッド13を並列に実行させ、これら複数のスレッド13が消滅する際に、さらに次のスレッド13を逐次的に生成するようにしてもよい。

0122

この場合の動作は次のようになる。即ち、外部入力(テストデータ16の入力)によりスレッドマネージャ11が最初のスレッド“1”を生成する。スレッド“1”は処理“1”を実行して、処理“1”に必要なリソース14をリソースマネージャ12に要求する。これにより、スレッド“1”にリソース14が割り当てられてスレッド“1”が処理“1”を完了すると、スレッドマネージャ11によって消滅させられる際に、次のスレッド“2”〜“n”を同時に生成する。なお、リソース14が割り当てられなかった場合は、この場合も、そのスレッド13はスレッドマネージャ11によって「待ち状態」に制御される。

0123

その後、各スレッド“2”〜“n”が並行して処理を進めてそれぞれの処理が完了し、これらの各“2”〜“n”がスレッドマネージャ11によって消滅させられる際に、次のスレッド“n+1”を生成する。以降は、上述した第7変形例と同様にして、順次、前のスレッド13が消滅する際に、次のスレッド13が生成されて処理が実行される。

0124

例えば、処理Aと処理Bの実行結果を処理Cが使う場合、スレッド13の構成例は図26に示すようになる。そして、このように構成したスレッド13を、この場合も、図3により前述したシステムに適用して設計の初期段階における論理装置のシミュレーションを行なう。

0125

即ち、全てのスレッド13の処理が完了(全てのスレッド13が消滅)するまで、スレッドマネージャ11とリソースマネージャ12とが連携して、リソース14の要求,リソース14の割り当て及びリソース14の割り当て結果に応じたスレッド13の実行状態の制御を繰り返すことによって、論理装置の動作シミュレーションを実現する。

0126

このように、本変形例では、スレッド13に並列性を導入して処理の並列化を図ることにより、上述した実施形態や第7変形例よりも複雑な「機能」をもった論理装置の動作シミュレーションを実現することができる。

0127

(J)第9変形例の説明
次に、上述したリソースマネージャ12は、リソース14の種類に関係無く全てのリソース14を共通で管理していたが、例えば図27に模式的に示すように、複数種類のリソース14−1〜14−n毎にリソースマネージャ12−1〜12−nを設けて、それぞれが1種類のリソース14−j(j=1〜n)を独立して(ローカルに)管理して、要求19に応じたリソース14−jをローカルな「調停ルール」に従って要求元のスレッド13に割り当てるようにしてもよい。

0128

この場合は計算機1(CPU4)を次のように動作させることが可能になる。即ち、外部入力(テストデータ16の入力;ステップS31)によりスレッドマネージャ11がスレッド13を生成する(ステップS32)。この場合も、スレッド13は独立して進行するが個々の実行順序はスレッドマネージャ11に管理されている。そして、スレッド13は処理を進めるためにリソース14−jを確保する必要がある時は、そのリソース14−jの確保をスレッドマネージャ11経由で対応するリソースマネージャ12−jに要求する(ステップS33;リソース要求ステップ)。

0129

リソースマネージャ12−jは単位時間内のリソース要求19をリソース14−j毎にローカルに調停して、リソース14−jの割り当て結果をスレッドマネージャ11に回答21を発行する(ステップS34;リソース割り当てステップ)。スレッドマネージャ11はリソースマネージャ12−jからの回答21に基づいてスレッド13の実行状態を制御する(スレッド制御ステップ)。

0130

そして、この場合も、全てのスレッド13の処理が完了するまで、図3により前述したごとく、スレッドマネージャ11とリソースマネージャ12−jとが連携して、リソース要求,リソース割り当て及びスレッド13の制御とを繰り返すことによって、実行結果を出力して(ステップS35)、論理装置の動作シミュレーションを実現する。

0131

ここで、具体的に、リソース種類をA,B,Cの3種類(以下、リソースA,B,Cと表記する)とした場合、リソースマネージャ12−jが管理(参照)するリソースAは、C++記述スタイルで構成(記述)すると例えば図28に示すように構成される。即ち、前述したリソース要求キュー20とリソース回答キュー22とを定義するとともに、要求メソッド31a′、リソースAの解放を行なう解放メソッド31b′、リソースAの調停を行なう調停メソッド31c′をそれぞれ定義する。

0132

ここで、要求メソッド31a′は、要求したリソースAとその要求19を出したスレッド13のスレッドIDとを要求メッセージとしてリソース要求キュー20に登録する操作を行なうための関数であり、解放メソッド31b′は、リソースAの解放を行ない、解放したリソースAの個数を1つ増やす操作を行なう関数である。

0133

また、調停メソッド31c′は、リソースAの割り当て調停を独立して(ローカルに)行なうための関数で、破線枠311′内の記述により、リソース要求キュー20が空でない限り、リソース要求キュー20から1つずつ要求19が取り出され、要求されたリソースAの個数がその時点で0以下であれば破線枠312′内の記述が実行され、要求されたリソースAの個数がその時点で1以上であれば破線枠313′内の記述が実行されるようになっている。

0134

即ち、要求されたリソースAの個数がその時点で0以下であれば、新たに割り当てられるリソースAが無いので、リソース割り当て結果の回答21として“False”をリソース回答キュー22に格納し、要求されたリソースAの個数が1以上であれば、割り当て可能なので、そのリソースAの調停ルールに従って割り当てを行なって、その調停(割り当て)結果(“True”)を回答21としてリソース回答キュー22に格納するのである。なお、リソースB,リソースCについても上記(図28)と同様に記述できる。つまり、この場合は、図6に示すものに比して記述量は増えるものの構成は簡単になる。

0135

そして、このように構成したリソースA,B,Cを図3に示すシステムに適用すれば、リソース種類毎のリソースマネージャ12−jによって、互いに依存関係の無いローカルな「調停ルール」に従ったリソース割り当てが行なわれて、リソースA,B,Cの種類間に依存関係が存在しない論理装置のシミュレーションが可能となる。

0136

(K)第10変形例の説明
なお、上述した第9変形例は、リソース種類に互いに依存関係が無い場合であるが、依存関係がある場合は、上述したローカルな調停では不十分である。例えば、「CPU」というリソースが、「論理演算装置ALU;Arithmetic Logic Unit),「バス(BUS)」,「レジスタ(REGISTER)」などのリソースから構成され、「ALU」というリソースが、さらに、「加算器(ADDER)」,「減算器SUBTRACTER)」,「論理積回路(AND)」,「論理和回路(OR)」などのリソースから構成されているような場合、「CPU」というリソースをスレッド13に割り当てるには、下位階層の「ALU」,「BUS」,「REGISTER」,「ADDER」,「AND」,「OR」といったリソースも空いていなければならない。

0137

このように、リソースに14−jに依存関係がある場合には、例えば図29に模式的に示すように、その依存関係に応じてリソースマネージャ12−jを階層化する。即ち、この図29の場合は、リソース14−1とリソース14−2との間には依存関係が無いため、それぞれリソースマネージャ12−1,12−2がローカルにリソース14−1,14−2を管理するが、リソース14−1,14−2とリソース14−3との間にはそれぞれ依存関係が存在するため、上位階層のリソースマネージャ12−3が、下位階層のリソースマネージャ12−1,12−2も管理することで下位階層のリソース14−1,14−2の管理も行なえるようにするのである。

0138

同様にして、リソースマネージャ12−3やリソースマネージャ12−(n−1)は、互いに独立してリソース14−3や14−(n−1)の管理をローカルに行なうが、それぞれ上位階層のリソース14−nと依存関係があるため、上位階層のリソースマネージャ12−nが下位階層のリソースマネージャ12−3や12−(n−1)も管理する。

0139

このようにして、リソース14−jに依存関係があり前述したようなローカルなリソース調停で解決できない場合はリソース14−jの階層化を行なってグローバルなリソース調停を行なう。なお、この場合、計算機1(CPU4)は、次のように動作することになる。即ち、外部入力(テストデータ16の入力;ステップS41)によりスレッドマネージャ11がスレッド13を生成する(ステップS42)。この場合も、スレッド13は独立して進行するが個々の実行順序はスレッドマネージャ11に管理されている。

0140

そして、スレッド13は処理を進めるためにリソース14−jを確保する必要がある時は、そのリソース14−jの確保を、スレッドマネージャ11経由でそのリソース種類に対応するリソースマネージャ12−jに要求する(ステップS43;リソース要求ステップ)。

0141

リソースマネージャ12−jは、単位時間内の個々のリソース要求に対する割り当てをリソース14−j毎にローカルに調停する。ローカルなリソース14−jの割り当て結果は上位階層のリソースマネージャ12−k(k=j+1)に伝わり、上位階層のリソースマネージャ12−kは、他の関連する(依存関係のある)種類のリソース12−kの割り当て結果を考慮してその階層のリソース割り当てを決定する。

0142

以降、同様にして、下位階層のリソース割り当て結果が、順次、上位階層に伝搬してゆき、最終的に、最上位階層のリソースマネージャ12−nが最後の割り当て結果をスレッドマネージャ11に回答する(ステップS44;リソース割り当てステップ)。

0143

つまり、本変形例では、リソース割り当てステップS44において、上位階層のリソースマネージャ12−kが、自身の管理するリソース14−kと下位階層のリソースマネージャ12−jの管理するリソース14−jとの依存関係を考慮してリソース割り当てを行なうのである。

0144

そして、スレッドマネージャ11は、このリソースマネージャ12−jからの回答21に基づいてスレッド13の実行状態を制御する(スレッド制御ステップ)。その後、全てのスレッド13の処理が完了するまで、スレッドマネージャ11とリソースマネージャ12−jとが連携して、上記のリソース要求,リソース割り当て及びスレッド13の制御とを繰り返すことにより、実行結果(シミュレーション結果)を出力して(ステップS45)、論理装置のシミュレーションを実現する。

0145

このように、本変形例では、リソース14−jの依存関係に応じてリソース14−j及びリソースマネージャ12−jを階層化することで、上位階層のリソースマネージャ12−jが下位階層のリソースマネージャ12−jの管理するリソース14−jも考慮してリソース14−jの割り当てを行なうことができるので、リソース種類間のグローバルな調停を行なうことができ、より複雑なリソースの依存関係を持つ論理装置の動作シミュレーションを実現して、設計初期段階で機能や性能検証を行なうことができる。

0146

なお、上述した第7〜第10変形例は、勿論、前述した第1〜第6変形例のいずれに適用してもよく、それぞれ、組み合わせによる利点ないし効果が得られる。以上のように、本実施形態及びその各変形例の論理装置の動作シミュレーション方法によれば、論理装置の設計初期段階において機能レベルのシミュレーションを行なって、「機能」の確認,「機能」を実現するアーキテクチャの妥当性を設計の初期段階で確認して論理装置の機能検証と性能評価を行なうことができる。

0147

また、設計の初期段階に「機能」を正確に実現できたか否かを確認することができるとともに、設計の安全性を確認することができる。その上、アーキテクチャに変更が必要となった場合でも、「機能」の記述の変更は殆ど行なわずに、リソース14(14−j),「調停ルール」,リソース要求などを変更するだけで、簡単に設計の再検証を行なえるので、従来のように「機能」の記述の変更による設計コスト増加を回避することができる。

0148

(L)その他
上述した実施形態及びその各変形例では、シミュレーションプログラム10の記述の具体例としてC++記述スタイルを例にしたが、勿論、Javaなどのなどの他のプログラミング言語に基づく記述スタイルを適用しても、上記と同様の作用効果が得られることはいうまでもない。そして、本発明は、上述した実施形態及びその各変形例に限定されず、上記以外にも、本発明の趣旨を逸脱しない範囲で種々変形して実施することができる。

0149

(M)付記
(付記1)プログラムの実行単位であるスレッドの制御を行なうスレッドマネージャが、論理装置の設計仕様に応じて該論理装置の動作完了までに必要となる機能を表したスレッドの実行に必要なハードウェアリソースを、当該ハードウェアリソースを管理するリソースマネージャに要求するリソース要求ステップと、該リソースマネージャが、該要求に応じたハードウェアリソースを予め規定されたルールに従って該スレッドに割り当てるリソース割り当てステップと、該スレッドマネージャが、該リソースマネージャによる割り当て結果に応じて該スレッドの実行状態を制御するスレッド制御ステップとを有するとともに、該スレッドの実行が完了するまで該スレッドマネージャと該リソースマネージャとが連携して上記の各ステップを繰り返し実行することにより、該論理装置の動作完了までの動作をシミュレーションすることを特徴とする、論理装置の動作シミュレーション方法。

0150

(付記2) 上記の一連の機能が、複数の逐次的なスレッドに表されていることを特徴とする、付記1記載の論理装置の動作シミュレーション方法。
(付記3) 上記の一連の機能が、複数の逐次的または並行に実行されるスレッドに表されていることを特徴とする、付記1記載の論理装置の動作シミュレーション方法。

0151

(付記4) 該リソースマネージャが、該ハードウェアリソースの種類に対応して複数設けられるとともに、該リソース割り当てステップにおいて、上記の各リソースマネージャが、それぞれ、自身が管理するハードウェアリソースを予め規定されたローカルなルールに従って該スレッドに割り当てることを特徴とする、付記1〜3のいずれか1項に記載の論理装置の動作シミュレーション方法。

0152

(付記5) 該リソースマネージャが、該ハードウェアリソースの種類に対応して複数設けられるとともに、各リソースマネージャが、該ハードウェアリソースの依存関係に応じて階層化され、該リソース割り当てステップにおいて、該リソースマネージャが、自身の管理するハードウェアリソースと下位階層のリソースマネージャの管理するハードウェアリソースとの依存関係を考慮して該ハードウェアリソースの割り当てを行なうことを特徴とする、付記1〜3のいずれか1項に記載の論理装置の動作シミュレーション方法。

0153

(付記6) 該リソースマネージャが、該リソース要求ステップによるリソース要求を監視し、その監視結果に基づいて複数スレッド間のリソース要求のデッドロック状態を判定することを特徴とする、付記1〜5のいずれか1項に記載の論理装置の動作シミュレーション方法。
(付記7) 該リソースマネージャが、該リソース要求ステップによるリソース要求によって割り当てられたハードウェアリソースに対するリード/ライト要求を監視し、その監視結果に基づいて複数スレッドのハードウェアリソースに対するリード/ライト動作の競合状態を判定することを特徴とする、付記1〜5のいずれか1項に記載の論理装置の動作シミュレーション方法。

0154

(付記8) 該リソースマネージャが、該ハードウェアリソースに対するリソース要求数を監視し、その監視結果に基づいて該スレッドのボトルネックを検出することを特徴とする、付記1〜5のいずれか1項に記載の論理装置の動作シミュレーション方法。
(付記9) 該リソースマネージャが、該ハードウェアリソースに対するリソース要求数を監視し、その監視結果に基づいて該リソース要求のブロッキングを検出することを特徴とする、付記1〜5のいずれか1項に記載の論理装置の動作シミュレーション方法。

0155

(付記10) 該スレッドに、該リソースマネージャによって割り当てられたハードウェアリソースを占有する時間についての予算を与えておくことを特徴とする、付記1〜5のいずれか1項に記載の論理装置の動作シミュレーション方法。
(付記11) 該スレッドに、該機能の実行制限時間を与えておくことを特徴とする、付記1〜5のいずれか1項に記載の論理装置の動作シミュレーション方法。

0156

(付記12) 付記1〜11のいずれか1項に記載の動作シミュレーション方法によるシミュレーション結果と、該論理装置の動作予測値とを比較する比較ステップと、該比較ステップでの比較結果を外部装置へ出力する出力ステップとを有することを特徴とする、論理装置の動作シミュレーション方法。

0157

(付記13)プログラムの実行単位であるスレッドの制御を行なうスレッドマネージャと、該スレッドの実行に必要なハードウェアリソースを管理するリソースマネージャとをそなえるとともに、該スレッドマネージャが、論理装置の設計仕様に応じて該論理装置の動作完了までに必要となる機能を表したスレッドの実行に必要なハードウェアリソースを該リソースマネージャに要求するリソース要求手段と、該リソース要求手段による該要求に対する該リソースマネージャによる割り当て結果に応じて該スレッドの実行状態を制御するスレッド制御手段とをそなえ、且つ、該リソースマネージャが、該要求に応じたハードウェアリソースを予め規定されたルールに従って該スレッドに割り当てるリソース割り当て手段をそなえ、該スレッドの実行が完了するまで該スレッドマネージャと該リソースマネージャとが連携して上記のリソース要求及びスレッドの実行状態の制御を繰り返し実行することにより、該論理装置の動作完了までの動作をシミュレーションすることを特徴とする、論理装置の動作シミュレーション装置。

0158

(付記14)論理装置の動作シミュレーションプログラムを記録したコンピュータ読み取り可能な記録媒体であって、該コンピュータを、プログラムの実行単位であるスレッドの制御を行なうスレッドマネージャ及び該スレッドの実行に必要なハードウェアリソースを管理するリソースマネージャとして機能させるとともに、該スレッドマネージャが、論理装置の設計仕様に応じて該論理装置の動作完了までに必要となる機能を表したスレッドの実行に必要なハードウェアリソースを該リソースマネージャに要求するリソース要求ステップと、該リソースマネージャが、該要求に応じたハードウェアリソースを予め規定されたルールに従って該スレッドに割り当てるリソース割り当てステップと、該スレッドマネージャが、該リソースマネージャによる割り当て結果に応じて該スレッドの実行状態を制御するスレッド制御ステップとを実行するとともに、該スレッドの処理が完了するまで該スレッドマネージャと該リソースマネージャとが連携して上記の各ステップを繰り返し実行することにより、該論理装置の動作完了までの動作をシミュレーションするためのプログラムが記録されていることを特徴とする、論理装置の動作シミュレーションプログラムを記録したコンピュータ読み取り可能な記録媒体。

0159

(付記15) 上記の一連の機能が、複数の逐次的なスレッドに表されていることを特徴とする、付記14記載の論理装置の動作シミュレーションプログラムを記録したコンピュータ読み取り可能な記録媒体。
(付記16) 上記の一連の機能が、複数の逐次的もしくは並行に実行されるスレッドに表されていることを特徴とする、付記14記載の論理装置の動作シミュレーションプログラムを記録したコンピュータ読み取り可能な記録媒体。

0160

(付記17) 該リソースマネージャが、該ハードウェアリソースの種類に対応して複数設けられるとともに、該リソース割り当てステップにおいて、上記の各リソースマネージャが、それぞれ、自身が管理するハードウェアリソースを予め規定されたローカルなルールに従って該スレッドに割り当てることを特徴とする、付記14〜16のいずれか1項に記載の論理装置の動作シミュレーションプログラムを記録したコンピュータ読み取り可能な記録媒体。

0161

(付記18) 該リソースマネージャが、該ハードウェアリソースの種類に対応して複数設けられるとともに、各リソースマネージャが、該ハードウェアリソースの依存関係に応じて階層化され、該リソース割り当てステップにおいて、該リソースマネージャが、自身の管理するハードウェアリソースと下位階層のリソースマネージャの管理するハードウェアリソースとの依存関係を考慮して該ハードウェアリソースの割り当てを行なうことを特徴とする、付記14〜16のいずれか1項に記載の論理装置の動作シミュレーションプログラムを記録したコンピュータ読み取り可能な記録媒体。

0162

(付記19) 該リソースマネージャが、該リソース要求ステップによるリソース要求を監視し、その監視結果に基づいて複数スレッド間のリソース要求のデッドロック状態を判定することを特徴とする、付記14〜18のいずれか1項に記載の論理装置の動作シミュレーションプログラムを記録したコンピュータ読み取り可能な記録媒体。

0163

(付記20) 該リソースマネージャが、該リソース要求ステップによるリソース要求によって割り当てられたハードウェアリソースに対するリード/ライト要求を監視し、その監視結果に基づいて複数スレッドのハードウェアリソースに対するリード/ライト動作の競合状態を判定することを特徴とする、付記14〜18のいずれか1項に記載の論理装置の動作シミュレーションプログラムを記録したコンピュータ読み取り可能な記録媒体。

0164

(付記21) 該リソースマネージャが、該ハードウェアリソースに対するリソース要求数を監視し、その監視結果に基づいて該スレッドのボトルネックを検出することを特徴とする、付記14〜18のいずれか1項に記載の論理装置の動作シミュレーションプログラムを記録したコンピュータ読み取り可能な記録媒体。

0165

(付記22) 該リソースマネージャが、該ハードウェアリソースに対するリソース要求数を監視し、その監視結果に基づいて該リソース要求のブロッキングを検出することを特徴とする、付記14〜18のいずれか1項に記載の論理装置の動作シミュレーションプログラムを記録したコンピュータ読み取り可能な記録媒体。

0166

(付記23) 該スレッドに、該リソースマネージャによって割り当てられたハードウェアリソースを占有する時間についての予算を与えておくことを特徴とする、付記14〜18のいずれか1項に記載の論理装置の動作シミュレーションプログラムを記録したコンピュータ読み取り可能な記録媒体。
(付記24) 該スレッドに、該機能の実行制限時間を与えておくことを特徴とする、付記14〜18のいずれか1項に記載の論理装置の動作シミュレーションプログラムを記録したコンピュータ読み取り可能な記録媒体。

0167

(付記25)論理装置の動作シミュレーションプログラムを記録したコンピュータ読み取り可能な記録媒体であって、該コンピュータに、付記1〜11のいずれか1項に記載の動作シミュレーション方法によるシミュレーション結果と該論理装置の動作予測値とを比較する比較ステップと、該比較ステップでの比較結果を外部装置へ出力する出力ステップとを実行させるための動作シミュレーションプログラムが記録されたことを特徴とする、論理装置の動作シミュレーションプログラムを記録したコンピュータ読み取り可能な記録媒体。

0168

(付記26)論理装置の動作シミュレーションプログラムであって、コンピュータを、プログラムの実行単位であるスレッドの制御を行なうスレッドマネージャ及び該スレッドの実行に必要なハードウェアリソースを管理するリソースマネージャとして機能させるとともに、該スレッドマネージャが、論理装置の設計仕様に応じて該論理装置の動作完了までに必要となる機能を表したスレッドの実行に必要なハードウェアリソースを該リソースマネージャに要求するリソース要求ステップと、該リソースマネージャが、該要求に応じたハードウェアリソースを予め規定されたルールに従って該スレッドに割り当てるリソース割り当てステップと、該スレッドマネージャが、該リソースマネージャによる割り当て結果に応じて該スレッドの実行状態を制御するスレッド制御ステップとを実行するとともに、該スレッドの処理が完了するまで該スレッドマネージャと該リソースマネージャとが連携して上記の各ステップを繰り返し実行することにより、該論理装置の動作完了までの動作をシミュレーションすることを特徴とする、論理装置の動作シミュレーションプログラム。

0169

(付記27) 上記の一連の機能が、複数の逐次的なスレッドに表されていることを特徴とする、付記26記載の論理装置の動作シミュレーションプログラム。
(付記28) 上記の一連の機能が、複数の逐次的もしくは並行に実行されるスレッドに表されていることを特徴とする、付記26記載の論理装置の動作シミュレーションプログラム。

0170

(付記29) 該リソースマネージャが、該ハードウェアリソースの種類に対応して複数設けられるとともに、該リソース割り当てステップにおいて、上記の各リソースマネージャが、それぞれ、自身が管理するハードウェアリソースを予め規定されたローカルなルールに従って該スレッドに割り当てることを特徴とする、付記26〜28のいずれか1項に記載の論理装置の動作シミュレーションプログラム。

0171

(付記30) 該リソースマネージャが、該ハードウェアリソースの種類に対応して複数設けられるとともに、各リソースマネージャが、該ハードウェアリソースの依存関係に応じて階層化され、該リソース割り当てステップにおいて、該リソースマネージャが、自身の管理するハードウェアリソースと下位階層のリソースマネージャの管理するハードウェアリソースとの依存関係を考慮して該ハードウェアリソースの割り当てを行なうことを特徴とする、付記26〜28のいずれか1項に記載の論理装置の動作シミュレーションプログラム。

0172

(付記31) 該リソースマネージャが、該リソース要求ステップによるリソース要求を監視し、その監視結果に基づいて複数スレッド間のリソース要求のデッドロック状態を判定することを特徴とする、付記26〜30のいずれか1項に記載の論理装置の動作シミュレーションプログラム。
(付記32) 該リソースマネージャが、該リソース要求ステップによるリソース要求によって割り当てられたハードウェアリソースに対するリード/ライト要求を監視し、その監視結果に基づいて複数スレッドのハードウェアリソースに対するリード/ライト動作の競合状態を判定することを特徴とする、付記26〜30のいずれか1項に記載の論理装置の動作シミュレーションプログラム。

0173

(付記33) 該リソースマネージャが、該ハードウェアリソースに対するリソース要求数を監視し、その監視結果に基づいて該スレッドのボトルネックを検出することを特徴とする、付記26〜30のいずれか1項に記載の論理装置の動作シミュレーションプログラム。
(付記34) 該リソースマネージャが、該ハードウェアリソースに対するリソース要求数を監視し、その監視結果に基づいて該リソース要求のブロッキングを検出することを特徴とする、付記26〜30のいずれか1項に記載の論理装置の動作シミュレーションプログラム。

0174

(付記35) 該スレッドに、該リソースマネージャによって割り当てられたハードウェアリソースを占有する時間についての予算を与えておくことを特徴とする、付記26〜30のいずれか1項に記載の論理装置の動作シミュレーションプログラム。
(付記36) 該スレッドに、該機能の実行制限時間を与えておくことを特徴とする、付記26〜30のいずれか1項に記載の論理装置の動作シミュレーションプログラム。

0175

(付記37)論理装置の動作シミュレーションプログラムであって、コンピュータに、付記1〜11のいずれか1項に記載の動作シミュレーション方法によるシミュレーション結果と該論理装置の動作予測値とを比較する比較ステップと、該比較ステップでの比較結果を外部装置へ出力する出力ステップとを実行させることを特徴とする、論理装置の動作シミュレーションプログラム。

発明の効果

0176

以上詳述したように、本発明によれば、論理装置に実装すべき「機能」が必要とするハードウェアリソース(以下、単に「リソース」という)に関する記述はスレッドには行なわず、そのスレッドが実行されるときに、その都度、必要なリソースをリソースマネージャによって動的に割り当てながら、スレッドの実行が完了するまでスレッドマネージャとリソースマネージャとが連携してスレッドの実行状態の制御を繰り返し実行することにより、論理装置の動作完了までの動作をシミュレーションするので、次のような利点が得られる。

0177

論理装置の動作予測値との比較により、「機能」の確認,「機能」を実現するアーキテクチャの妥当性を設計の初期段階で確認して論理装置の機能検証と性能評価を行なうことができる。
論理装置の動作予測値との比較により、設計の初期段階に「機能」を正確に実現できたか否かを確認することができる。

0178

アーキテクチャに変更が必要になった場合でも、「機能」の記述変更は殆ど行なわずに、リソースやリソースの割り当てルール,スレッドのスケジューリング,リソース要求などを、アーキテクチャの変更に応じて変更するだけで、簡単に設計の再検証を行なうことが可能になり、「機能」の記述の変更による設計コスト増加を回避することができる。

0179

「機能」に適したアーキテクチャの探索や、「機能」をアーキテクチャへマッピングする際のアーキテクチャの性能評価,設計初期段階におけるタイミングの検証などが行なえる。なお、論理装置の動作完了までに必要な一連の「機能」は、複数の逐次的なスレッド群に表されていてもよいし、複数の逐次的または並行に実行されるスレッド群に表されていてもよい。前者の場合は、論理装置の「機能」の依存関係をより明確にした上での動作シミュレーションが可能になり、後者の場合はより複雑な「機能」構成をもった論理装置の動作シミュレーションが可能になる。

0180

また、上記のリソースマネージャは、リソースの種類に対応して複数設けられていてもよく、例えば、それぞれが管理するリソースを予め規定されたローカルなルールに従ってスレッドに割り当てたり、各リソースマネージャをリソースの依存関係に応じて階層化して、それぞれの管理するリソースと下位階層のリソースマネージャの管理するリソースとの依存関係を考慮してリソースの割り当てを行なったりすることも可能である。

0181

前者の場合は簡単な記述(構成)でリソースに依存関係のない論理装置のシミュレーションが可能となり、後者の場合はリソースの依存関係をも考慮したグローバルなリソースの割り当て調停が可能となる。さらに、上記のリソースマネージャは、リソース要求を監視し、その監視結果に基づいて複数スレッド間のリソース要求のデッドロック状態を判定することもでき、この場合は、設計の初期段階においてデッドロック状態の発生可能性を検出することが可能となり、論理装置の機能検証を行なうことが可能となる。

0182

また、上記のリソースマネージャは、リソース要求によって割り当てられたリソースに対するリード/ライト要求を監視し、その監視結果に基づいて複数スレッドのリソースに対するリード/ライト動作の競合状態を判定することもでき、この場合は、複数のスレッドがリソースに対してシーケンシャルに書き込み動作もしくは読み出し動作を行なう時に、その順序が正しいか否かを判定して、設計した論理装置が正しく動作するか否かを検証することができる。

0183

さらに、上記のリソースマネージャは、リソースに対するリソース要求数を監視し、その監視結果に基づいてスレッドのボトルネックを検出することもでき、この場合は、アクセス頻度が最も多いリソースは論理装置のボトルネックになっている可能性があると推測することができ、論理装置の設計初期段階で論理装置の性能検証(ボトルネックの有無の検証)を実現することができる。

0184

また、上記のリソースマネージャは、リソースに対するリソース要求数を監視し、その監視結果に基づいてリソース要求のブロッキングを検出することもできる。この場合は、リソース要求のブロッキングの発生可能性を検出することで、論理装置の性能を評価することができる。

0185

さらに、上記のスレッドには、リソースマネージャによって割り当てられたリソースを占有する時間についての予算を与えておいてもよい。このようにすれば、各種「機能」の組み合わせで構成される論理装置が、設計仕様により要求される処理時間に関する性能要件を満たしているか否かを、設計の初期段階にて確認することができる。

0186

また、上記のスレッドには、上記機能の実行制限時間を与えておいてもよく、このようすれば、設計の初期段階においてリアルタイム性に関する性能要件を論理装置が満足しているかを検証することが可能となる。さらに、上述した動作シミュレーション方法は、コンピュータを上述のごとく動作させる動作シミュレーションプログラム及びこれを記録したコンピュータ読み取り可能な記録媒体によって提供されてもよく、このようすれば、コンピュータに上記プログラムを読み取らせれば(インストールすれば)、そのコンピュータを上述したような論理装置の動作シミュレーション方法を実行する装置(論理装置の動作シミュレーション装置)として機能させることができるので、その普及に大きく寄与する。

図面の簡単な説明

0187

図1本発明の第1実施形態に係るパーソナルコンピュータなどの計算機(情報処理装置)の構成を示すブロック図である。
図2本発明の第1実施形態に係る動作シミュレーションプログラムを説明するためのオブジェクトモデル図である。
図3図2に示す動作シミュレーションプログラムに基づく計算機の動作(論理装置の動作シミュレーション方法)を説明するための図である。
図4図1に示す計算機の要部に着目した構成を示すブロック図である。
図5第1実施形態に係るスレッドの記述例を示す図である。
図6第1実施形態に係るリソースマネージャの記述例を示す図である。
図7第1実施形態に係る論理装置(QoSシステム)に必要な「機能」を説明するためのブロック図である。
図8第1実施形態に係る論理装置(QoSシステム)の設計手順(動作シミュレーション方法)を説明するためのフローチャートである。
図9第1実施形態の第1変形例に係る計算機の要部に着目した構成を示すブロック図である。
図10第1変形例に係るスレッドの記述例を示す図である。
図11(A)及び(B)はそれぞれ第1変形例に係るスレッドのデッドロックの検出を説明するためのリソース割付けグラフである。
図12第1実施形態の第2変形例に係る計算機の要部に着目した構成を示すブロック図である。
図13第2変形例に係るリソース要求の記述例を示す図である。
図14第2変形例に係るリソースの記述例を示す図である。
図15第1実施形態の第3変形例に係る計算機の要部に着目した構成を示すブロック図である。
図16第3変形例に係るリソースの記述例を示す図である。
図17第1実施形態の第4変形例に係る計算機の要部に着目した構成を示すブロック図である。
図18第4変形例に係るリソースの記述例を示す図である。
図19第1実施形態の第5変形例に係る論理装置の設計手順(動作シミュレーション方法)を説明するためのフローチャートである。
図20第5変形例に係るスレッドの記述例を示す図である。
図21第1実施形態の第6変形例に係る論理装置の設計手順(動作シミュレーション方法)を説明するためのフローチャートである。
図22第6変形例に係るスレッドの記述例を示す図である。
図23第1実施形態の第7変形例に係るスレッドの生成方法を説明するための模式図である。
図24第7変形例に係るスレッドの記述例を示す図である。
図25第1実施形態の第8変形例に係るスレッドの生成方法を説明するための模式図である。
図26第8変形例に係るスレッドの記述例を示す図である。
図27第1実施形態の第9変形例に係る計算機の要部に着目した構成を示すブロック図である。
図28第9変形例に係るリソースの記述例を示す図である。
図29第1実施形態の第10変形例に係る計算機の要部に着目した構成を示すブロック図である。
図30(A)及び(B)はいずれも従来の論理装置の設計手順を説明するためのフローチャートである。
図31従来の論理装置の設計手順による課題を説明するための図である。

--

0188

1計算機(情報処理装置;論理装置の動作シミュレーション装置)
2 計算機本体
3ディスプレイ(表示装置;外部装置)
4 CPU
5主記憶部(メモリ)
6二次記憶装置(ハードディスク)
7フロッピーディスク(FD)ドライブ
8内部バス
9 フロッピーディスク(コンピュータ読み取り可能な記録媒体)
10,51 論理装置の動作シミュレーションプログラム
11スレッドマネージャ
12,12−1〜12−nリソースマネージャ
13スレッド
14,14−1〜14−nリソース(ハードウェア資源)
15テストベンチ
16テストデータ
17入力キュー
18実行待ちキュー
19 要求
20リソース要求キュー
21回答
22 リソース回答キュー
31a,31a′要求メソッド
31b,31b′解放メソッド
31c,31c′調停メソッド
41パケット
42クラス分け機能
43キューイング機能
44デキュー機能
45 キュー
110スレッド生成手段
111 リソース要求手段
112スレッド制御手段
121リソース割り当て手段
122デッドロック検出機構
123リード/ライト検出機構
124ボトルネック検出機構
125ブロッキング検出機構

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ