JP2004086786A

JP2004086786A - System design support method and system design support apparatus

Info

Publication number: JP2004086786A
Application number: JP2002249910A
Authority: JP
Inventors: Hiroyuki Yagi; 八木　浩行
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2002-08-29
Filing date: 2002-08-29
Publication date: 2004-03-18

Abstract

<P>PROBLEM TO BE SOLVED: To freely switch a share between hardware and software. <P>SOLUTION: Based on a functional processing block model in which a stationary response processing and an event drive processing are selectively selected for operation, operation specifications describing the operation of the stationary response processing are inputted and edited (step S12), and the operation specifications of the event drive processing are inputted and edited (step S13). Next, a partitioning for allocating the functional processing block in which the operation specifications are prepared to the hardware or the software is inputted (step S14). Then, based on the operation specifications of the partitioned functional processing block, the function is evaluated (step S15). As the result of the evaluation, if necessary, the step is returned to step S14, the partitioning is reset, and the evaluation is performed again. <P>COPYRIGHT: (C)2004,JPO

Description

【０００１】
【発明の属する技術分野】
本発明はシステム設計支援方法およびシステム設計支援装置に関し、特にシステムの処理機能を機能処理ブロックに分割し、この機能処理ブロックをハードウェアとソフトウェアに分担してシステムの設計を行なうシステム設計支援方法およびシステム設計支援装置に関する。
【０００２】
【従来の技術】
近年、ＳＯＣ（Ｓｙｓｔｅｍ　ｏｎ　ａ　Ｃｈｉｐ）　やＳＩＰ　（Ｓｙｓｔｅｍ　ｉｎ　ａ　Ｐａｃｋａｇｅ）　、ＳＯＰ（Ｓｙｓｔｅｍ　ｏｎ　ａ　Ｐａｃｋａｇｅ）　などと呼ばれる半導体チップあるいは半導体パッケージ内に、命令セットを持ち演算実行を行なうプロセッサ、メモリや独自の命令セットを持つかプロセッサによって制御されるコ・プロセッサおよびディジタル周辺回路等のディジタル回路、場合により変調回路、増幅回路等のアナログ回路から構成される複合演算処理システム開発の要求が高まっている。
【０００３】
このような半導体装置の開発においては、実現すべき機能をハードウェアとソフトウェアとの最適の組み合わせとして短時間に実現するため、ハード・ソフト協調設計環境の構築が重要な課題となっている。システム設計の処理手順について説明する。図１８は、システム設計の処理手順のフローチャートである。
【０００４】
システム設計では、まずシステム全体の処理動作の仕様を決定する（ステップＳ０１）。次に、ステップＳ０１で決定されたシステム全体の動作仕様を機能処理ブロックに分割し（ステップＳ０２）、機能処理ブロックごとに処理の動作仕様を決定し（ステップＳ０３）、機能処理ブロックをモデル化する（ステップＳ０４）。続いて、各々の機能処理ブロックをＡＳＩＣなどのハードウェア、あるいはプロセッサなどで実行されるソフトウェアに分割するパーティショニングを行なう（ステップＳ０５）。次に、パーティショニングされたシステム全体の性能、面積などのコストの見積もりを算出して検証を行ない（ステップＳ０６）、見積もりの結果、システム設計者によって与えられる制約を満たしているかどうかを判定する（ステップＳ０７）。満たしていない場合は、ステップＳ０５へ戻ってパーティショニングからの処理を繰り返す。一般に、１回のパーティショニングで求められる制約が満たされることは稀であり、通常はハードウェアとソフトウェアの分担箇所を繰り返し変更し、システム全体の性能、面積などを見積もりながら制約を満たすパーティショニングを決定する。続いて、決定されたパーティショニングに基づいて、ハードウェア、ソフトウェアの詳細設計が開始される（ステップＳ０８）。
【０００５】
このパーティショニング決定の工程は、半導体装置開発上、非常に重要であり、パーティショニングの際には、プロセッサ、メモリ、コ・プロセッサ、ディジタル周辺回路等のディジタル回路あるいは変調回路、増幅回路等のアナログ回路のすべてを含むシステム全体の性能、面積などのコストを見積もり、システム設計者によって与えられる制約を満たすハードウェアとソフトウェアの分担を決定しなければならない。パーティショニングに使用する機能処理ブロックのモデルの精度が低く、正確に見積もれなかった場合、ハードウェア、ソフトウェアの詳細設計において、制約が満たされなくなることがある。この結果、システム設計者の要求する制約を満たすために、初期システム検討からやり直すか、制約自体を緩和しなければならない等、設計の長期化あるいは製品性能の劣悪化を招くおそれがある。
【０００６】
このように、設計の効率化および製品性能を向上させるためには、正確な見積もりを行なう必要があり、正確な見積もりには、パーティショニングに使用する機能処理ブロックのモデルが一定の精度を持っていなければならない。例えば、初期システム検討の段階では、少なくとも処理シーケンスレベルの精度を持たねばならないし、使用半導体プロセスや使用プロセッサ等が決定した後期システム検討段階では、ハードウェア・ソフトウェアおよびそれぞれの間を結ぶインタフェース部分について、ディジタル回路ではサイクル精度、ディジタル−アナログ・ミックス回路ではさらに信号レベル精度を持たなければならない。このため、このモデリング手法について、様々な手法が提案されている。
【０００７】
例えば、ハードウェアブロックのモデリング手法として、特開平１１−３３６７号、あるいは特開２０００−１１３０２６号公報記載の発明では、拡張ライブラリを使用して機能合成を行なう手法が開示されている。
【０００８】
また、システムレベルの記述言語を用いたものとして、例えば特開２０００−５７１９９号公報、あるいは、Ｄａｎｉｅｌ　Ｄ．　Ｇａｊｓｋｉ他著「ＳｐｅｃＣ仕様記述言語と方法論」、ＣＱ出版社、ＩＳＢＮ４−７８９８−３３５３−４、に詳しくそのモデリング手法が述べられている。このようなシステムレベル記述言語を用いたモデリングでは、データフロー（ＤＦＧ：Ｄａｔａ　Ｆｌｏｗ　Ｇｒａｐｈ）や、コントロールフロー（ＦＳＭ：Ｆｉｎｉｔｅ　Ｓｔａｔｅ　Ｍａｃｈｉｎｅ）や、その組み合わせを使用してモデルが構築される。図１９は、データフローおよびコントロールフローによるモデル記述の一例である。（１）は、データフローでの記述、（２）はコントロールフローでの記述の一例である。（１）データフローでは、動作処理がデータの流れ図で示されている。また、（２）コントロールフローでは、動作処理が事象によって状態を遷移する有限状態機械によって示されている。
【０００９】
同様に、ハード・ソフト協調設計手法のモデルとして、Ｆｅｌｉｃｅ　Ｂａｌａｒｉｎ他著、「Ｈａｒｄｗａｒｅ−Ｓｏｆｔｗａｒｅ　Ｃｏ−ｄｅｓｉｇｎ　ｏｆ　ｅｍｂｅｄｄｅｄ　Ｓｙｓｔｅｍｓ，　Ｔｈｅ　ＰＯＬＩＳ　Ａｐｐｒｏａｃｈ」、Ｋｌｕｗｅｒ　Ａｃａｄｅｍｉｃ　Ｐｕｂｌｉｓｈｅｒｓ、ＩＳＢＮ　０−７９２３−９９３６−６、のＣＦＳＭ（Ｃｏｄｅｓｉｇｎ　ＦＳＭ：協調設計有限状態機械）モデルがある。
【００１０】
【発明が解決しようとする課題】
しかし、従来のモデリング手法を用いたシステム設計方法では、システム設計時に使用したモデルを終始一貫して使用することができないという問題がある。
【００１１】
一般に、パーティショニング段階におけるハード・ソフトの分担決定は、制約に応じて変更が繰り返される。例えば、ある機能はハードまたはソフトの何れでも作ることができるが、高速化などの点ではハードが有利であり、設計変更などに対する自由度が高いという点ではソフトが有利である場合、どちらが最適であるかは、使用半導体プロセスや使用プロセッサなどの使用半導体テクノロジーが決定していない初期システム検討の段階と、これらが決定した後期システム検討の段階では異なることもある。このため、機能処理ブロックモデルは、ハードウェアおよびソフトウェアのいずれにも対応できるものであることが望ましい。また、設計の効率を考えると、パーティショニングに使用する機能処理ブロックのモデルは、次段階のハードウェア、ソフトウェアの詳細設計においても使用できることが望ましい。
【００１２】
しかしながら、従来の拡張ライブラリを使用して機能合成を行なうハードウェアブロックのモデリング手法は、ハードウェアの機能合成を目的とするものであり、ソフトウェアを含むシステム全体のモデリングを目的としたものでない。このため、動的処理シーケンスに対応できてなく、ソフトウェア分担に割り当てを変更することができない。
【００１３】
また、システムレベル記述言語を用いてモデルを構築するモデリング手法では、特別な言語およびシミュレーション環境を用いて動的処理シーケンス、すなわち、機能処理ブロックの並行動作に対応している。しかしながら、動作分割後、ハードウェアあるいはソフトウェアの詳細設計を行なう際には、モデルを書き直す工程を必要とし、システム設計時に使用したモデルが終始一貫して使用することができないという問題がある。例えば、ハードウェアブロックの場合、システム記述言語で記述されたモデルを、ＨＤＬ（Ｈａｒｄｗａｒｅ　Ｄｅｓｃｒｉｐｔｉｏｎ　Ｌａｎｇｕａｇｅ：ハードウェア記述言語）に書き直さなければならない。
【００１４】
さらに、現在のＳＯＣ内の演算処理は非常に高度化、複雑化されている。設計システム検討段階で必要とされる処理シーケンスについてさえ、静的シーケンス、静的スケジューリングなどのみで目的の演算処理が行なわれることは極めてまれである。例えば、映像、画像、音声など、広く情報処理と呼ばれる大多数の演算処理が動的シーケンス、動的スケジューリングなどによって達成されており、その処理シーケンスを正確に見積もり、次段階のシステム設計に繋げることが必要となっている。
【００１５】
本発明はこのような点に鑑みてなされたものであり、ハードウェアとソフトウェアの分担を自在に切替えることができるとともに、システム設計時に使用したモデルを終始一貫して使用することが可能なシステム設計支援方法およびシステム設計支援装置を提供することを目的とする。
【００１６】
【課題を解決するための手段】
本発明では上記課題を解決するために、コンピュータを用いて、システムの処理機能を機能処理ブロックに分割し、この機能処理ブロックをハードウェアとソフトウェアに分担して前記システムの設計を行なうシステム設計支援方法において、内部状態あるいは前記内部状態とその時点での入力値とによって定まる定常応答処理と、所定のイベントに応じて駆動される事象駆動処理とから成る機能処理ブロックモデルに基づいて、前記定常応答処理および前記事象駆動処理の動作を記述した動作仕様を入力・編集するステップと、作成された前記動作仕様に基づいて前記機能処理ブロックがハードウェアとソフトウェアに分担されるステップと、ハードウェアとソフトウェアに分担された前記機能処理ブロックの動作仕様についての評価を行なうステップと、を有することを特徴とするシステム設計支援方法、が提供される。
【００１７】
このような手順のシステム設計支援方法では、コンピュータを用いて、定常応答処理と事象駆動処理とから構成される機能処理ブロックモデルに基づいて、定常応答処理と事象駆動処理の動作を記述した動作仕様を入力・編集する。次に、作成された動作仕様に基づいて設定される機能処理ブロックのハードウェアとソフトウェアの分担を入力する。次に、ハードウェアとソフトウェアに分担された機能処理ブロックの動作仕様についての評価を行なう。
【００１８】
また、上記課題を解決するために、システムの処理機能を機能処理ブロックに分割し、前記機能処理ブロックをハードウェアとソフトウェアに分担して行なう前記システムの設計を支援するシステム設計支援装置において、内部状態あるいは前記内部状態とその時点での入力値とによって定まる定常応答処理と、所定のイベントに応じて駆動される事象駆動処理とから成る機能処理ブロックモデルに基づいて、前記定常応答処理および前記事象駆動処理の動作を記述した動作仕様の入力と編集を行なう動作仕様編集手段と、前記動作仕様編集手段により作成された前記動作仕様を記録する設計情報記録手段と、前記動作仕様が作成された前記機能処理ブロックをハードウェアとソフトウェアに分担する分担手段と、ハードウェアとソフトウェアに分担された前記機能処理ブロックの動作仕様についての評価を行なう機能処理ブロック評価手段と、を具備することを特徴とするシステム設計支援装置、が提供される。
【００１９】
このような構成のシステム設計支援装置では、動作仕様編集手段は、定常応答処理と事象駆動処理とから構成される機能処理ブロックモデルに基づいて、定常応答処理と事象駆動処理の動作を記述した動作仕様を入力し、編集作業を支援する。さらに、作成された動作仕様を設計情報記録手段に記録する。分担手段は、動作仕様に基づいて作成された機能処理ブロックをハードウェアとソフトウェアに分担する設定の支援を行なう。機能処理ブロック評価手段は、ハードウェアとソフトウェアに分担が設定された機能処理ブロックの評価を行なう。
【００２０】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照して説明する。
まず、実施の形態に適用される発明の概念について説明する。図１は、本発明の実施の形態に適用される発明の概念図である。本発明のシステム設計支援方法では、コンピュータを用いて、以下の手順で実行されるシステム設計の支援を行なう。
【００２１】
本発明に係るシステム設計支援方法を用いたシステム設計では、システム全体の動作仕様が決定した後、機能処理ごとに分割される機能処理ブロックモデルとして、従来のモデリング手法に加え、システムの状態に着目し、定常応答処理と事象駆動処理とが択一に選択されて実行されるモデル構造を使用する。定常応答処理は、内部状態あるいは内部状態とその時点での入力値とによって決定される動作であり、有限状態機械の形で記述することができる。事象駆動処理は、所定のイベントが発生した場合、イベントに応じて駆動されて動作を行なう。
【００２２】
ここで、システム設計の支援を行なうコンピュータは、情報を表示するモニタ１１０と、動作記述や指令などを入力するキーボード１２０を初めとする入力装置、および生成された動作仕様情報の記録や、性能評価時の使用データあるいは動作記述の入力や編集を支援するための情報を含む、設計情報を記録した設計情報データベース１３０に接続する。
【００２３】
このようなコンピュータによるシステム設計支援装置を用いて、上記の説明の機能処理ブロックモデルに基づくシステム設計が行なわれる。以下、システム全体の仕様が決定され、システム全体の動作仕様が機能処理ブロックに分割された以降のシステム設計の手順を説明する。これは、図１８に図示したシステム設計手順のステップＳ０４以降のステップに相当する。
【００２４】
まず、所定の機能処理ブロックにおいて実行される処理動作を定常応答処理と事象駆動処理に分割する（ステップＳ１１）。
次に、分割された定常応答処理についての動作を記述した動作仕様をコンピュータに入力し、編集作業を行なう（ステップＳ１２）。図１の例では、コンピュータは、キーボード１２０より入力する動作記述を処理し、モニタ１１０に表示する。設計者は、モニタ１１０で動作記述を確認し、必要であれば編集作業を行なう。ここでは動作記述をキーボード１２０より入力するとしたが、予め設計情報データベース１３０に登録されている部品を呼び出して使うなどの手法で動作記述を行なうこともできる。作成された動作仕様は、設計情報データベース１３０に記録される。
【００２５】
次に、分割された事象駆動処理についての動作仕様をコンピュータに入力し、編集作業を行なう（ステップＳ１３）。ステップＳ１２と同様に動作記述の編集処理が行なわれ、設計情報データベース１３０に記録される。事象駆動処理の動作記述と定常応答処理の動作記述の順番は、どちらが先に行なわれてもよいし、機能処理に応じて交互に実行することもできる。
【００２６】
ここまでの手順で、機能処理ブロックの動作仕様が決定され、設計情報データベース１３０に保存される。この動作仕様は、システムの状態に着目して記述されており、ハードウェア、ソフトウェアのどちらにも適用することができる。
【００２７】
次に、この機能処理ブロックをハードウェアかソフトウェアに割り当てるパーティショニング設定が入力される（ステップＳ１４）。図１の例では、入力されたパーティショニング設定は、機能処理ブロックごとに設計情報データベース１３０に記録される。
【００２８】
次に、パーティショニングによりハードウェアあるいはソフトウェアが割り当てられた機能処理ブロックの動作仕様について評価が行なわれる（ステップＳ１５）。評価では、システム設計の段階に応じて必要な情報を設計情報データベース１３０より取得し、動作仕様に基づいて模擬動作させ、見積もりを算出して行なう。例えば、使用半導体プロセスや使用プロセッサなどの仕様半導体テクノロジーが決定していない初期システムの検討段階では、動作仕様に基づく処理シーケンスを再現させ、これが制約を満たすかどうかの評価を行なう。
【００２９】
評価の結果、制約を満たすためにハードウェアとソフトウェアの割り当てを変更する場合、ステップＳ１４のパーティショニング設定からの処理を繰り返す。ここで、本発明の機能処理ブロックモデルは、システム状態に着目したモデルであるため、ソフトウェアおよびハードウェアいずれにも適用することができる。すなわち、ソフトウェアとハードウェアの分担を自在に切替えることができる。
【００３０】
このように、ソフトウェアあるいはハードウェアといった区別なしにシステムが構築可能であり、自在に分担を切替えながらパーティショニングを検討することができることから、システムの性能見積もりを容易にすることができる。
【００３１】
ここで、本発明で使用する機能処理ブロックモデルについて説明する。図２は、本発明の実施の形態である機能処理ブロックモデルの概念図である。
本発明の実施の形態で用いる機能処理ブロックモデルは、従来のモデリング手法に加え、システムの状態に着目している。すなわち、本発明に係るモデルでは、定常状態で実行される定常応答処理２１０と、イベント発生時に駆動される事象駆動処理２２０とを境界２３０によって明確に分離する。ここで、境界２３０は、定常応答処理２１０と事象駆動処理２２０とを分離する仮想的な境界を示しており、特別な演算を示すものではない。ここでは、定常応答処理２１０と事象駆動処理２２０とが明確に分離されることを示すため、図示されている。
【００３２】
ここで定常応答処理２１０は、従来のモデリング手法におけるデータフローとコントロールフローの組み合わせで記述することができる。また、事象駆動処理２２０は、データフローとコントロールフローで記述されるが、好ましくはデータフローのみで記述される。
【００３３】
この機能処理ブロックモデルでは、定常応答処理２１０と事象駆動処理２２０が択一に選択され、同時に並行に動作する。
ところで、コンピュータにより構成されるシステム設計支援装置では、システム設計を支援するためのデータ処理機能を有している。図３は、システム設計支援装置のハードウェア構成を示す図である。システム設計支援装置１００は、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０７を介してＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）１０２、ハードディスクドライブ（ＨＤＤ：Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）１０３、グラフィック処理装置１０４、が接続されている。ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。ＨＤＤ１０３には、ＯＳやアプリケーションプログラムが格納される。グラフィック処理装置１０４には、モニタ１１０が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１１０の画面に表示させる。入力インタフェース１０５には、キーボード１２０やマウス１４０が接続されている。入力インタフェース１０５は、キーボード１２０やマウス１４０から送られてくる信号を、バス１０７を介してＣＰＵ１０１に送信する。
【００３４】
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。
続いて、このようなシステム設計支援装置１００におけるシステム設計支援機能について説明する。図４は、システム設計支援装置の機能を示すブロック図である。図１と同じものには同じ番号を付し、説明は省略する。
【００３５】
本発明に係るシステム設計支援装置は、定常応答処理の動作仕様を入力・編集する定常応答処理動作仕様エディタ部１５１、事象駆動処理の動作仕様を入力・編集する事象駆動処理動作仕様エディタ部１５２、パーティショニングを設定するパーティショニング部１５３、機能処理ブロックの評価を行なう機能処理ブロック評価部１５４および設計情報データベース１３０から構成される。
【００３６】
設計情報データベース１３０は、定常応答処理動作仕様エディタ部１５１および事象駆動処理動作仕様エディタ部１５２から入力する動作仕様と、パーティショニング部１５３から入力するパーティショニングの設定を機能処理ブロックに対応させて記録して管理するとともに、機能処理ブロック評価部１５４による評価の際に必要な情報を記憶している。
【００３７】
定常応答処理動作仕様エディタ部１５１および事象駆動処理動作仕様エディタ部１５２は、それぞれの処理の動作を記述した動作仕様を作成するための入力・編集作業を支援する動作仕様編集手段である。キーボードやマウスを介して入力される動作の記述あるいは動作記述の編集指示を処理し、動作仕様として設計情報データベース１３０に記録する。
【００３８】
パーティショニング部１５３は、動作仕様が作成された機能処理ブロックのハードウェアとソフトウェアの分担を設定する分担手段である。設計情報データベース１３０に記録された機能処理ブロックの動作仕様をモニタ等に表示し、キーボードやマウス等を介して入力する設計者による分担の設定に基づいて、該当する機能処理ブロックのソフトウェアまたはハードウェアの設定を決定し、設計情報データベース１３０に登録する。
【００３９】
機能処理ブロック評価部１５４は、パーティショニングがされた機能処理ブロックを設計情報データベース１３０に記録された動作仕様に基づいて再現し、評価を行なう機能処理ブロック評価手段である。
【００４０】
以下、このようなシステム設計支援装置を用いたシステム設計支援方法について、具体例で説明する。
最初に、説明で用いる機能処理ブロックモデルを仮想的に具現化した表記について説明する。図５は、本発明の実施の形態である機能処理ブロックモデルの表記例である。この図は、発明モデルの便宜上の表記であり、本発明のモデル構造をわかりやすくするための図である。
【００４１】
図５に示した機能処理ブロック２０１は、ブロックが定常応答処理部２１１と事象駆動処理部２２１とから構成されることを示している。また、機能処理ブロック２０１で示される枠は、機能処理ブロックのパーティショニングが完了しているかどうかを表すこととする。ここでは、機能処理ブロック２０１の枠内が塗りつぶされていない場合、割当未完であるとする。一方、機能処理ブロック２０１の枠内が所定の色で塗りつぶされている場合、割当完了であるとする。すなわち、図５に示した機能処理ブロック２０１はパーティショニング前であり、割当未完である。
【００４２】
さらに、階調２４０で示される枠は、パーティショニングの結果、ソフトウェアあるいはハードウェアのいずれかが選択されたことを表すこととする。ここでは、階調２４０の枠内が塗りつぶされていない場合、ソフトウェアが割り当てられているとする。一方、階調２４０の枠内が所定の色で塗りつぶされている場合、ハードウェアが割り当てられているとする。階調２４０で示される枠による表記は、機能処理ブロック２０１の枠内が塗りつぶされている場合、すなわちパーティショニングが完了の場合のみ有効である。
【００４３】
続いて、パーティショニングによりソフトウェアが割り当てられた場合と、ハードウェアが割り当てられた場合の機能処理ブロックの表記の例について説明する。
【００４４】
まず、ソフトウェアが割り当てられた場合について説明する。図６は、ソフトウェアが割り当てられた機能処理ブロックの表記例である。図５と同じものには同じ番号を付し、説明は省略する。機能処理ブロック２０２は、定常応答処理部２１１と事象駆動処理部２２１とから構成されており、機能処理ブロック２０２の枠内は塗りつぶされて割当完了であることを表しており、階調２４１の枠内は塗りつぶされておらずソフトウェア割当であることを表している。
【００４５】
次に、ハードウェアが割り当てられた場合について説明する。図７は、ハードウェアが割り当てられた機能処理ブロックの表記例である。図５と同じものには同じ番号を付し、説明は省略する。機能処理ブロック２０３は、定常応答処理部２１１と事象駆動処理部２２１とから構成されており、機能処理ブロック２０３の枠内は塗りつぶされて割当完了であることを表しており、階調２４２の枠内は塗りつぶされてハードウェア割当であることを表している。
【００４６】
このように、システム仕様から機能処理を分割された機能処理ブロックモデルは、定常応答処理（データフローとコントロールフローの組み合わせで表現される）と、事象駆動処理（好ましくはデータフローのみで表現される）を択一に選択し、すべてのシミュレーション工程において同時かつ並行に動作される。定常応答処理と事象駆動処理の切り替えは、多くは、ブロック内部変数によって伝達される、このブロック内部のイベント、あるいは、このブロックが外部に公開しているブロック内部変数への書き込みによって伝達される該ブロックの外部イベントによって行なわれる。
【００４７】
次に、機能処理ブロックの動作仕様の記述例について説明する。まず、定常応答処理、続いて事象駆動処理の動作記述について説明する。
図８は、本発明の実施の形態である定常応答処理の動作記述例である。ここでは、プログラミング言語により記述されており、定常応答処理部８０１は、有限状態機械の形で記述されている。図８の例では、定常応答処理は、ブロック０の状態を示すＢＬＯＣＫ０＿ＳＴＡＴＥの値によって分岐処理を行なっており（８０２）、ＢＬＯＣＫ０＿ＳＴＡＴＥがＢＬＯＣＫ０＿ＳＴ＿ＩＮＴの場合（８０３）、ＢＬＯＣＫ０＿ＳＴ＿ＩＤＬＥの場合（８０４）およびＢＬＯＣＫ０＿ＳＴ＿ＲＵＮの場合（８０５）の各動作が記述されている。ここで、動作記述は、使用するプログラム言語に依存しておらず、分岐処理記述を持ったプログラミング言語であれば、同様の動作記述を行なうことができる。
【００４８】
図９は、本発明の実施の形態である事象駆動処理の動作記述例である。駆動応答処理部分は、データフローあるいはコントロールフローで記述することが可能であるが、好ましくは、データフローのみで記述する。図９の例では、発生する事象それぞれに対応する副処理ブロック９０１と９０２とに分割され、副処理ブロック９０１、９０２ごとに、その事象に応じて駆動される動作が記述される。
【００４９】
なお、本発明の機能処理ブロックモデルを使用したシステムの構築には、モデル記述内で使用される変数のいわゆるスコープを明確にしなければならない。このモデルは、定常応答処理部と事象駆動処理部から成り、モデル記述中に使用される変数はすべてこのモデル内にスコープを閉じることが要求される。すなわち、好ましくは、モデル記述内に使用される変数はすべてユニークな変数名であり、さらに、使用するプログラミング言語のスコープ指定により完全に他ブロックの影響を遮断することが望ましい。本発明のモデルの定常応答処理部と事象駆動処理部との関連処理は、このスコープを閉じた変数によって行なう。図８と図９の例では、ブロック０の状態変数（ＢＬＯＣＫ０＿ＳＴＡＴＥ）によって行なう。言い換えると、モデルで記述されるブロックとその外部ブロックとの通信は、呼び出される（いわゆるスレーブ側）ブロックモデルの事象駆動処理部に、呼び出す側（いわゆるマスター側）からイベント（事象）与えることによって行なわれる。
【００５０】
ここで、図８に示した定常応答処理部は、ソフトウェア割り当てではメインルーチンとなり、ハードウェア割り当てでは順序回路として機能することが自明である。また、図９に示した事象駆動処理部は、ソフトウェア割り当てでは割り込み処理部分となり、ハードウェア割り当てでは組み合わせ論理回路として機能することが自明である。また、事象駆動処理にコントロールフローでの記述が含まれている場合、順序論理回路が含まれる。図９の例では、事象駆動処理部（副処理ブロック９０１，９０２）はすべて、ブロック０がスレーブとしてイベントを受ける場合に起動され、かつその信号の方向（入力側なのか出力側なのか）にまったく無関係であることがわかる。
【００５１】
このように、本発明の機能処理ブロックモデルでは、ハードウェアとソフトウェアの入れ替えが容易であるばかりでなく、システム設計時のパーティショニングを決定する前に実際のインプリメントごとのソフトウェア、あるいはハードウェア形態を容易に予測することができる。
【００５２】
以上のように、本発明では、ハードウェアとソフトウェアを同一の機能処理ブロックモデルで表現することができることから、ハードウェアあるいはソフトウェア分担を相互に入れ替えながらシステム設計を行なうことが可能となる。さらに、性能、面積などコスト見積もり後にシステムアーキテクチャが決定した後、機能処理ブロックがハードウェア、ソフトウェアのどちらに割り当てられている場合であっても、モデルの抽象度を詳細化するのみであり、割り当てによりモデルを書き直す必要はまったく生じず、終始一貫したモデル構造の使用が可能となる。また、システム設計者の意図を示すモデル記述は、どの抽象レベルにいても完全に保持することができる。
【００５３】
次に、機能評価を行なう際のシミュレーション工程について説明する。図１０は、本発明の実施の形態であるシミュレーション工程を示すフローチャートの例である。図１０に示したシミュレーション工程では、動作仕様の記述が行なわれた機能処理ブロックをタスク（図ではタスク０からタスク３）に割り当て、シミュレーション処理を起動する。具体的には、シミュレーション処理が開始されると、まずブロック０に割り当てられたタスク０が起動され（Ｓ１５１）、続いて、ブロック１に割り当てられたタスク１が起動され（Ｓ１５２）、ブロック２に割り当てられたタスク２が起動され（Ｓ１５３）、ブロック３に割り当てられたタスク３が起動される（Ｓ１５４）。それぞれのタスク処理が起動されると、タスク０からタスク３まで順に、イベント発生の有無をチェックし、イベント発生が発生していれば、これに応じたシミュレーション処理が行なわれる。どのタスクについての処理も同じであるので、タスク０の場合で説明する。シミュレーション処理では、イベントが発生したかどうかの判定が行なわれ（Ｓ１５１１）、判定結果に応じて事象駆動処理（Ｓ５１１２）、または定常応答処理（Ｓ１５１３）が実行される。これらの処理は、あらかじめ設定された単位時間などに到達するまで繰り返される。
【００５４】
このように、すべての機能処理ブロックを同時並行に動作させることが可能であるため、実際の動作を再現することが可能であり、この結果検証が容易に行なえるようになる。
【００５５】
なお、図１０の例では、イベント処理部１００１は厳密なイベント発生順を再現できていない。すなわち、複数のイベントが同一ループ内で発生した場合のシーケンスは正しく再現せず、同一のループ内での唯一のイベントが発生した場合のみ正しく表現できる。これは、シミュレータのイベント処理部１００１は、シミュレータを実行するコンピュータ環境に依存しているためである。これについては、たとえば、オペーレーティングシステム（ＯＳ）のイベントキューを使用し、ファーストイン・ファーストアウトの概念でタスクスイッチを行なうなどの種々の変形例が考えられる。このように、イベント発生シーケンスに忠実であることが好ましい。シミュレータの定常応答処理部１００２も同様にシミュレータを実行するコンピュータ環境に依存し、機能処理ブロックがアイドル状態にあるときの空回りを抑制するシミュレーション機構を構築し、シミュレーション時間の短縮を図るなどの変形例が考えられる。
【００５６】
このように、動的処理シーケンスを正確にシミュレーションすることが可能であり、従って性能、面積などのコストを正確に見積もることが可能となる。また、システム検証時の不具合検出率の向上にも寄与することができる。
【００５７】
以下、本発明を適用した具体例として、一般的な１プロセッサシステムＬＳＩ、プロセッサを含まないＬＳＩ、マルチプロセッサシステム、マルチタスクシステムおよびシステム内システムに本発明を適用した場合について図を用いて順に説明する。以下の説明に用いる図は、図５、図６および図７で用いた機能処理ブロックモデルの表記例を用いている。
【００５８】
第１に、一般的な１プロセッサシステムＬＳＩの場合について説明する。図１１は、一般的な１プロセッサシステムＬＳＩに適用した場合のシステム構成図の例である。図１１の例では、所定の処理機能を実行する機能処理ブロック１１０１、１１０２、１１０３、１１０４、１１０５、１１０６、１１０７、１１０８が相互に接続するシステム構成であり、機能処理ブロック１１０１にはソフトウェアが割り当てられており、他の機能処理ブロック１１０２、１１０３、１１０４、１１０５、１１０６、１１０７、１１０８にはハードウェアが割り当てられている。ソフトウェアが割り当てられている機能処理ブロック１１０１は、プロセッサによりソフトウェア処理を実行するブロックであり、定常応答処理部１１２１と事象駆動処理部１１２２とから構成されている。同様に、ハードウェアが割り当てられている機能処理ブロック１１０２も、定常応答処理部１１２３と事象駆動処理部１１２４とから構成されている。明らかに、ソフトウェアあるいはハードウェア割り当てによってモデル構成が変化することなく、共通のモデルによって表現される。また、どちらに割り当てても、実際のインプリメント後のブロック構成の予測性を損なうことがない。
【００５９】
第２に、プロセッサを含まないＬＳＩ（いわゆるＡＳＩＣ）の場合について説明する。図１２は、プロセッサを含まないＬＳＩに適用した場合のシステム構成図の例である。図１２の例は、図１１と同様に、機能処理ブロック１２０１、１２０２、１２０３、１２０４、１２０５、１２０６、１２０７、１２０８が相互に接続するシステム構成であり、すべての機能処理ブロックにハードウェアが割り当てられている。このハードウェアが割り当てられた機能処理ブロックも、定常応答処理部１２２１と事象駆動処理部１２２２とから構成されている。このように、本発明では、プロセッサを含まず、すべてがハードウェア割り当て機能処理ブロックで構成されるシステムも、図１１に示したソフトウェア割り当て機能処理ブロックを含む場合と同様に動作を記述することができる。
【００６０】
第３に、マルチプロセッサシステム（いわゆる並列コンピューティング）の場合について説明する。図１３は、マルチプロセッサシステムに適用した場合のシステム構成図の例である。図１３の例は、図１２と同様に、機能処理ブロック１３０１、１３０２、１３０３、１３０４、１３０５、１３０６、１３０７、１３０８が相互に接続するシステム構成であるが、すべての機能処理ブロックにはソフトウェアが割り当てられている。このソフトウェアが割り当てられた機能処理ブロックも、定常応答処理部１３２１と事象駆動処理部１３２２とから構成されている。このように、本発明では、すべてがソフトウェア割り当て機能処理ブロックで構成されるシステムも、図１１に示したソフトウェア割り当て機能処理ブロックとハードウェア割り当て機能処理ブロックが混合された場合、あるいは、図１２に示したすべてがハードウェア割り当て機能処理ブロックで構成される場合と同様に動作を記述することができる。
【００６１】
第４に、マルチタスクシステムの場合について説明する。図１４は、マルチタスクシステムに適用した場合のシステム構成図の例である。図１４の例のマルチタスクシステムは、階層構造をとっており、すべての機能処理ブロック１４０１、１４０２、１４０３、１４０４にはソフトウェアが割り当てられている。プロセッサ上のカーネルプログラムに相当する機能処理ブロック１４０１が最上位階層となり、カーネルプログラム支配下の各タスクに相当する機能処理ブロック１４０２、１４０３、１４０４が下の階層になる。カーネルプログラムに相当する機能処理ブロック１４０１も、定常応答処理部１４２１と事象駆動処理部１４２２とから構成され、その支配下の各タスクも定常応答処理部と事象駆動処理部とから構成されている。カーネルプログラムは、いわゆるＯＳの使用が一般的である。その場合にも、カーネルプログラムと支配下の各タスクとの関係、および各タスクとの関係は保持されるため、モデル構成を変更する必要がない。
【００６２】
また、図１５は、マルチタスクシステムに適用した場合の動作仕様の記述例である。動作仕様は、最上位階層の機能処理ブロック１４０１のものであり、記述の最上位階層に相当する動作記述部１５０１は、カーネルプログラムを意味する。続く、動作記述部１５０２では、タスクの生成処理が記述され、次の動作記述部１５０３では、タスクを実行状態にする処理が記述されている。すなわち、各タスクに相当する機能処理ブロック１４０２、１４０３、１４０４は、動作記述部１５０２において生成され、動作記述部１５０３において実行状態となる。この動作記述部１５０１は、システム設計の後期にはＯＳに置き換えられ、タスク生成の動作記述部１５０２およびタスク実行の動作記述部１５０３は、一般にＯＳのサービスルーチンコールとして置き換えられる。置き換えの際には、モデルの抽象度を詳細化するのみであり、モデルを書き直す必要がまったく生じない。すなわち、終始一貫したモデル構造の使用が可能となる。
【００６３】
このように、階層化構造を有するシステムも、同様に動作記述することが可能であり、階層化構造に対するモデル構造のロバスト性が高い。
第５に、システム内システム（いわゆるＳＩＰ、ＳＯＰ）の場合について説明する。図１６は、システム内システムに適用した場合のシステム構成図の例である。図１６の例のシステム内システムは、階層構造をとっており、機能処理ブロック１６０１、１６０２、１６０３にはハードウェアが割り当てられ、機能処理ブロック１６０４、１６０５、１６０７、１６０８にはソフトウェアが割り当てられている。システム構成の最上位階層となる機能処理ブロック１６０１は、ハードウェアによるシステム全体の制御回路を想定しているが、単にサブシステムが合体した構成でもよい。この場合、機能処理ブロック１６０１は省略可能である。機能処理ブロック１６０２、１６０３は、サブシステムを示している。ここで、機能処理ブロック１６０１上のサブシステムは、すべてプロセッサを含んだＳＯＣを想定しているが、まったくプロセッサを含まなくとも、プロセッサを含むものと含まないものとの双方が混在していようとも、システム構築、シミュレーションによる検証ともに可能である。さらに、サブシステムがアナログ回路であってもモデル上何ら問題は生じず、単にアナログ−ディジタルレベルコンバータブロックモデルを、アナログ−ディジタル界面に挿入することのみで表現、実行可能となる。これは、発明モデルの抽象度（あるいは計算粒度）に制限がないことを証明しており、異なる抽象度のモデルを混在させて性能や面積などのコストを見積もることが可能であることを意味する。
【００６４】
また、図１７は、システム内システムに適用した場合の動作仕様の記述例である。動作記述部１７０１は、最上位階層を示している。動作記述部１７０２は、サブシステムの初期化処理を記述しており、動作記述部１７０３は、サブシステムの有効化処理を記述している。
【００６５】
なお、本発明は以上の適用例にのみ限定されるものではなく、例えば、第１の適用例と第４の適用例の組み合わせ、第３の適用例と第４の適用例の組み合わせというような種々の変形が考えられる。
【００６６】
以上の説明のように、本発明は、現在考慮されるあらゆるシステム構成に対応することが可能である。例えば、プロセッサ上のハードウェアシステムが、今後本格的な一般化が期待されるハードウェア部追加による拡張命令セットの使用が可能なプロセッサシステムのシステムモデルを意味するなど、現在一般化していない構成の検討および性能見積もりが可能となる。さらに、動作記述は一般的なプログラミング言語全般で行なうことができるため、特別なシミュレーション環境を必要としない。このように、一般的なプログラミング言語全般でのモデル構築が可能であることから、一旦構築したモデルあるいはシステムの再利用が容易にできる。
【００６７】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、システム設計支援装置が有すべき機能の処理内容を記述したプログラムが提供される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。
【００６８】
また、プログラムを実行するコンピュータは、たとえば、可搬型記録媒体に記録されたプログラムを、自己の記憶装置に格納する。そして、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。
【００６９】
【発明の効果】
以上説明したように本発明のシステム設計支援方法では、従来のモデリング手法に加え、システムの状態に着目し、定常応答処理と事象駆動処理の択一モデル構成に拡張した機能処理ブロックモデルを用いており、ハードウェアおよびソフトウェアの双方に適用することができる。このため、システム設計の際に必須となるパーティショニング検討時に、ハードウェアとソフトウェアの分担を自在に切替えながら検討できることとなり、システムの性能見積もりを容易にすることができる。また、詳細設計においては、機能処理ブロックモデルの抽象度を詳細化するのみでよく、ハードウェア、ソフトウェアのどちらに割り当てられても、終始一貫したモデルを使用することができる。
【００７０】
また、本発明のシステム設計支援装置では、従来のモデリング手法に加え、システムの状態に着目し、定常応答処理と事象駆動処理の択一モデル構成に拡張した機能処理ブロックモデルに従って、処理機能の動作を記述した動作仕様を入力し、パーティショニングの設定に応じて機能処理ブロックの評価を行なう。このとき、パーティショニングにおいて、ハードウェアとソフトウェアの分担を自在に切替え、評価を行なうことができるため、システムの性能見積もりを容易にすることができる。また、次段の詳細設計では、同一の機能処理ブロックモデルを用いて、モデルの抽象度を詳細化する動作記述を入力・編集することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態に適用される発明の概念図である。
【図２】本発明の実施の形態である機能処理ブロックモデルの概念図である。
【図３】システム設計支援装置のハードウェア構成を示す図である。
【図４】システム設計支援装置の機能を示すブロック図である。
【図５】本発明の実施の形態である機能処理ブロックモデルの表記例である。
【図６】ソフトウェアが割り当てられた機能処理ブロックの表記例である。
【図７】ハードウェアが割り当てられた機能処理ブロックの表記例である。
【図８】本発明の実施の形態である定常応答処理の動作記述例である。
【図９】本発明の実施の形態である事象駆動処理の動作記述例である。
【図１０】本発明の実施の形態であるシミュレーション工程を示すフローチャートの例である。
【図１１】一般的な１プロセッサシステムＬＳＩに適用した場合のシステム構成図の例である。
【図１２】プロセッサを含まないＬＳＩに適用した場合のシステム構成図の例である。
【図１３】マルチプロセッサシステムに適用した場合のシステム構成図の例である。
【図１４】マルチタスクシステムに適用した場合のシステム構成図の例である。
【図１５】マルチタスクシステムに適用した場合の動作仕様の記述例である。
【図１６】システム内システムに適用した場合のシステム構成図の例である。
【図１７】システム内システムに適用した場合の動作仕様の記述例である。
【図１８】システム設計の処理手順のフローチャートである。
【図１９】データフローおよびコントロールフローによるモデル記述の一例である。
【符号の説明】
１１０・・・モニタ、１２０・・・キーボード、１３０・・・設計情報データベース、１５１・・・定常応答処理動作仕様エディタ部、１５２・・・事象駆動処理動作仕様エディタ部、１５３・・・パーティショニング部、１５４・・・機能処理ブロック評価部、２１０・・・定常応答処理、２２０・・・事象駆動処理、２３０・・・境界[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a system design support method and a system design support apparatus, and more particularly, to a system design support method for dividing a processing function of a system into functional processing blocks, and sharing the functional processing blocks between hardware and software to design a system. The present invention relates to a system design support device.
[0002]
[Prior art]
2. Description of the Related Art In recent years, a processor, a memory, an original processor, which has an instruction set and performs execution in a semiconductor chip or semiconductor package called SOC (System on a Chip), SIP (System in a Package), SOP (System on a Package), etc. There is an increasing demand for developing a complex arithmetic processing system comprising a digital circuit such as a co-processor and a digital peripheral circuit having an instruction set or controlled by a processor, and possibly an analog circuit such as a modulation circuit and an amplification circuit.
[0003]
In the development of such a semiconductor device, construction of a hardware-software cooperative design environment is an important issue in order to realize a function to be realized as an optimal combination of hardware and software in a short time. The processing procedure of the system design will be described. FIG. 18 is a flowchart of the processing procedure of the system design.
[0004]
In the system design, first, the specifications of the processing operation of the entire system are determined (step S01). Next, the operation specifications of the entire system determined in step S01 are divided into function processing blocks (step S02), and operation specifications of processing are determined for each function processing block (step S03), and the function processing blocks are modeled. (Step S04). Subsequently, partitioning for dividing each functional processing block into hardware such as an ASIC or software executed by a processor or the like is performed (step S05). Next, an estimate of the cost, such as the performance and area, of the entire partitioned system is calculated and verified (step S06), and as a result of the estimation, it is determined whether or not the constraints given by the system designer are satisfied (step S06). Step S07). If not, the process returns to step S05 to repeat the processing from partitioning. In general, it is rare that a single partitioning satisfies the constraints. Normally, the allocation of hardware and software is repeatedly changed, and partitioning that satisfies the constraints is estimated while estimating the performance and area of the entire system. decide. Subsequently, detailed design of hardware and software is started based on the determined partitioning (step S08).
[0005]
The process of determining partitioning is very important in the development of semiconductor devices. In partitioning, digital circuits such as processors, memories, co-processors, and digital peripheral circuits or analog circuits such as modulation circuits and amplifier circuits are used. It is necessary to estimate the performance, area, and other costs of the entire system including all the circuits, and determine the sharing of hardware and software that satisfies the constraints imposed by the system designer. If the accuracy of the model of the functional processing block used for partitioning is low and cannot be estimated accurately, the constraints may not be satisfied in the detailed design of hardware and software. As a result, in order to satisfy the constraints required by the system designer, it is necessary to start over from the initial system examination or to relax the constraints themselves, which may lead to a prolonged design or deterioration of product performance.
[0006]
As described above, accurate estimation must be performed in order to improve design efficiency and product performance, and a model of the functional processing block used for partitioning has a certain degree of accuracy. There must be. For example, at the stage of studying the initial system, accuracy must be at least at the processing sequence level. At the stage of studying the late system where the semiconductor process to be used and the processor to be used have been determined, the hardware and software and the interface between them have to be considered. Digital circuits must have cycle accuracy, and digital-analog mix circuits must have further signal level accuracy. For this reason, various techniques have been proposed for this modeling technique.
[0007]
For example, as a hardware block modeling method, Japanese Patent Application Laid-Open Nos. 11-3367 and 2000-113026 disclose a method of performing function synthesis using an extended library.
[0008]
In addition, as an example using a system-level description language, Japanese Patent Application Laid-Open No. 2000-57199 or Daniel D. Gajski et al., "SpecC Specification Language and Methodology", CQ Publishing Company, ISBN4-7898-3353-4, describe the modeling method in detail. In modeling using such a system level description language, a model is constructed using a data flow (DFG: Data Flow Graph), a control flow (FSM: Fine State Machine), or a combination thereof. FIG. 19 is an example of a model description using a data flow and a control flow. (1) is an example of a description in a data flow, and (2) is an example of a description in a control flow. (1) In the data flow, the operation process is shown by a data flow diagram. In the (2) control flow, the operation process is represented by a finite state machine that transitions states according to events.
[0009]
Similarly, as a model of the hardware-software co-design method, Felice Balarin et al., "Hardware-Software Co-design of embedded Systems, The POLIS Approach", Kluwer Academic0-36- There is a Codesign FSM (Cooperative Design Finite State Machine) model.
[0010]
[Problems to be solved by the invention]
However, the conventional system design method using the modeling technique has a problem that the model used at the time of system design cannot be used consistently.
[0011]
In general, the determination of the assignment of hardware and software in the partitioning stage is repeatedly changed according to the restrictions. For example, a function can be created with either hardware or software, but if hardware is advantageous in terms of speeding up, and software is advantageous in terms of high degree of freedom for design changes, etc. In some cases, there may be a difference between the stage of the initial system study where the semiconductor technology to be used such as the semiconductor process and the processor to be used is not determined, and the stage of the late system study where these are determined. For this reason, it is desirable that the functional processing block model can support both hardware and software. Considering the design efficiency, it is desirable that the model of the functional processing block used for partitioning can be used in the detailed design of hardware and software at the next stage.
[0012]
However, a conventional hardware block modeling method for performing function synthesis using an extended library is for the purpose of hardware function synthesis, and is not for modeling the entire system including software. For this reason, it is not possible to cope with the dynamic processing sequence, and it is not possible to change the allocation for software allocation.
[0013]
Further, a modeling technique for constructing a model using a system-level description language supports a dynamic processing sequence, that is, a parallel operation of functional processing blocks, using a special language and a simulation environment. However, when the detailed design of hardware or software is performed after the operation is divided, a step of rewriting the model is required, and there is a problem that the model used at the time of system design cannot be used consistently. For example, in the case of a hardware block, a model described in a system description language must be rewritten in HDL (Hardware Description Language).
[0014]
Further, the arithmetic processing in the current SOC is very sophisticated and complicated. Even for the processing sequence required in the design system study stage, it is extremely rare that the target arithmetic processing is performed only by a static sequence, static scheduling, or the like. For example, the vast majority of computations, such as video, images, and audio, which are widely referred to as information processing, are achieved by dynamic sequences, dynamic scheduling, etc., and the processing sequences must be accurately estimated and linked to the next system design. Is needed.
[0015]
The present invention has been made in view of such a point, and it is possible to freely switch the allocation of hardware and software, and to use a system design that can consistently use a model used at the time of system design. It is an object to provide a support method and a system design support device.
[0016]
[Means for Solving the Problems]
In the present invention, in order to solve the above problem, a computer is used to divide a processing function of a system into functional processing blocks, and to assign the functional processing blocks to hardware and software to design the system. The method according to claim 1, wherein the steady-state response is determined based on an internal state or the internal state and an input value at that time, and an event-driven process driven in response to a predetermined event. Inputting and editing an operation specification describing a process and an operation of the event-driven process; and a step in which the functional processing block is shared by hardware and software based on the created operation specification; and An evaluation of the operation specifications of the functional processing blocks assigned to the software was performed. System design support method characterized by comprising cormorants steps, a, is provided.
[0017]
In the system design support method of such a procedure, an operation specification that describes the operations of the steady-state response processing and the event-driven processing based on a functional processing block model composed of the steady-state response processing and the event-driven processing using a computer. Enter and edit. Next, the assignment of the hardware and software of the function processing blocks set based on the created operation specifications is input. Next, the operation specifications of the functional processing blocks assigned to hardware and software are evaluated.
[0018]
In order to solve the above-mentioned problem, a system design support apparatus which divides a processing function of a system into function processing blocks, and supports the design of the system by sharing the function processing blocks with hardware and software. The steady-state response processing and the event processing are performed based on a functional processing block model including a steady-state response processing determined by a state or the internal state and an input value at that time, and an event drive processing driven in response to a predetermined event. An operation specification editing unit for inputting and editing an operation specification describing an operation of the elephant driving process; a design information recording unit for recording the operation specification created by the operation specification editing unit; Sharing means for sharing the function processing block into hardware and software; and hardware and software. Shared by said functional processing system design support apparatus for a function processing block evaluation means for evaluation of the operation specifications of the block, characterized by comprising, are provided.
[0019]
In the system design support apparatus having such a configuration, the operation specification editing means performs the operation describing the operation of the steady-state response processing and the event-driven processing based on the functional processing block model composed of the steady-state response processing and the event-driven processing. Enter specifications and support editing work. Further, the created operation specifications are recorded in the design information recording means. The sharing means supports setting for sharing the function processing blocks created based on the operation specifications to hardware and software. The functional processing block evaluation means evaluates a functional processing block in which the assignment of hardware and software is set.
[0020]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
First, the concept of the invention applied to the embodiment will be described. FIG. 1 is a conceptual diagram of the invention applied to the embodiment of the present invention. In the system design support method of the present invention, a computer is used to support system design executed in the following procedure.
[0021]
In the system design using the system design support method according to the present invention, after the operation specifications of the entire system are determined, attention is paid to the state of the system in addition to the conventional modeling method as a function processing block model divided for each function processing. Then, a model structure is used in which the stationary response process and the event driven process are selected and executed. The steady-state response process is an operation determined by an internal state or an internal state and an input value at that time, and can be described in the form of a finite state machine. In the event driving process, when a predetermined event occurs, the event driving process is driven and operated according to the event.
[0022]
Here, a computer for supporting system design includes a monitor 110 for displaying information, an input device such as a keyboard 120 for inputting an operation description and instructions, etc., recording of generated operation specification information, and performance evaluation. A connection is made to a design information database 130 that records design information, including information for supporting input and editing of usage data or behavioral description at the time.
[0023]
Using such a computer-based system design support apparatus, a system is designed based on the functional processing block model described above. Hereinafter, the procedure of the system design after the specification of the entire system is determined and the operation specifications of the entire system are divided into functional processing blocks will be described. This corresponds to the steps after step S04 of the system design procedure shown in FIG.
[0024]
First, a processing operation executed in a predetermined functional processing block is divided into a steady response processing and an event driving processing (step S11).
Next, an operation specification describing the operation of the divided steady-state response process is input to the computer, and editing is performed (step S12). In the example of FIG. 1, the computer processes the operation description input from the keyboard 120 and displays it on the monitor 110. The designer confirms the operation description on the monitor 110 and performs an editing operation if necessary. Here, the operation description is input from the keyboard 120. However, the operation description can be performed by a method such as calling and using components registered in the design information database 130 in advance. The created operation specifications are recorded in the design information database 130.
[0025]
Next, the operation specifications for the divided event drive processing are input to the computer, and editing is performed (step S13). The process of editing the operation description is performed in the same manner as in step S12, and is recorded in the design information database 130. Either the order of the operation description of the event-driven process and the order of the operation description of the steady-state response process may be performed first, or they may be alternately performed according to the function process.
[0026]
The operation specifications of the function processing block are determined by the above procedure, and are stored in the design information database 130. This operation specification is described focusing on the state of the system, and can be applied to both hardware and software.
[0027]
Next, a partitioning setting for allocating the functional processing block to hardware or software is input (step S14). In the example of FIG. 1, the input partitioning settings are recorded in the design information database 130 for each functional processing block.
[0028]
Next, the operation specification of the functional processing block to which the hardware or the software is allocated by the partitioning is evaluated (Step S15). In the evaluation, necessary information is obtained from the design information database 130 according to the system design stage, simulated operation is performed based on the operation specifications, and an estimate is calculated. For example, in a stage of studying an initial system in which specifications semiconductor technology such as a semiconductor process to be used and a processor to be used are not determined, a processing sequence based on an operation specification is reproduced, and whether or not this satisfies a constraint is evaluated.
[0029]
As a result of the evaluation, when the allocation of hardware and software is changed to satisfy the constraint, the processing from the partitioning setting in step S14 is repeated. Here, the functional processing block model of the present invention is a model focusing on the system state, and thus can be applied to both software and hardware. That is, the assignment of software and hardware can be freely switched.
[0030]
As described above, a system can be constructed without discrimination between software and hardware, and partitioning can be considered while freely switching the assignment, thereby facilitating estimation of system performance.
[0031]
Here, a functional processing block model used in the present invention will be described. FIG. 2 is a conceptual diagram of a functional processing block model according to an embodiment of the present invention.
The functional processing block model used in the embodiment of the present invention focuses on the state of the system in addition to the conventional modeling method. That is, in the model according to the present invention, the steady-state response process 210 executed in the steady state and the event drive process 220 driven when an event occurs are clearly separated by the boundary 230. Here, the boundary 230 indicates a virtual boundary separating the steady response processing 210 and the event driving processing 220, and does not indicate a special operation. Here, it is illustrated to show that the steady response process 210 and the event drive process 220 are clearly separated.
[0032]
Here, the stationary response process 210 can be described by a combination of a data flow and a control flow in a conventional modeling method. The event driven process 220 is described by a data flow and a control flow, but is preferably described only by a data flow.
[0033]
In this functional processing block model, the stationary response processing 210 and the event driving processing 220 are selected as alternatives, and operate in parallel at the same time.
By the way, a system design support device constituted by a computer has a data processing function for supporting system design. FIG. 3 is a diagram illustrating a hardware configuration of the system design support apparatus. The whole system design support apparatus 100 is controlled by a CPU (Central Processing Unit) 101. To the CPU 101, a RAM (Random Access Memory) 102, a hard disk drive (HDD: Hard Disk Drive) 103, and a graphic processing device 104 are connected via a bus 107. The RAM 102 temporarily stores at least a part of an OS (Operating System) program and application programs to be executed by the CPU 101. Further, the RAM 102 stores various data necessary for processing by the CPU 101. The OS and application programs are stored in the HDD 103. A monitor 110 is connected to the graphic processing device 104. The graphic processing device 104 displays an image on the screen of the monitor 110 according to a command from the CPU 101. A keyboard 120 and a mouse 140 are connected to the input interface 105. The input interface 105 transmits signals transmitted from the keyboard 120 and the mouse 140 to the CPU 101 via the bus 107.
[0034]
With the above hardware configuration, the processing functions of the present embodiment can be realized.
Next, a system design support function in such a system design support apparatus 100 will be described. FIG. 4 is a block diagram illustrating functions of the system design support apparatus. The same components as those in FIG. 1 are denoted by the same reference numerals, and description thereof is omitted.
[0035]
The system design support apparatus according to the present invention includes a stationary response processing operation specification editor section 151 for inputting / editing the operation specification of the stationary response processing, an event driven processing operation specification editor section 152 for inputting / editing the operation specification of the event driven processing, It comprises a partitioning section 153 for setting partitioning, a functional processing block evaluation section 154 for evaluating functional processing blocks, and a design information database 130.
[0036]
The design information database 130 records the operation specifications input from the steady response processing operation specification editor section 151 and the event driven processing operation specification editor section 152 and the partitioning settings input from the partitioning section 153 in association with the function processing blocks. The information necessary for the evaluation by the function processing block evaluation unit 154 is stored.
[0037]
The steady response processing operation specification editor section 151 and the event driven processing operation specification editor section 152 are operation specification editing means for supporting input / edit work for creating operation specifications describing the operation of each processing. The description of the operation or the editing instruction of the operation description input through the keyboard or the mouse is processed and recorded in the design information database 130 as the operation specification.
[0038]
The partitioning unit 153 is a sharing unit that sets the sharing between hardware and software of the function processing blocks for which the operation specifications have been created. The operating specifications of the function processing blocks recorded in the design information database 130 are displayed on a monitor or the like, and the software or hardware of the corresponding function processing block is set based on the assignment setting by the designer input via a keyboard, a mouse, or the like. Is determined and registered in the design information database 130.
[0039]
The function processing block evaluation unit 154 is a function processing block evaluation unit that reproduces and evaluates the partitioned function processing blocks based on the operation specifications recorded in the design information database 130.
[0040]
Hereinafter, a system design support method using such a system design support apparatus will be described with a specific example.
First, a description will be given of a notation that virtually embodies a functional processing block model used in the description. FIG. 5 is a notation example of a functional processing block model according to the embodiment of the present invention. This diagram is a notation for convenience of the invention model, and is a diagram for making the model structure of the invention easy to understand.
[0041]
The function processing block 201 illustrated in FIG. 5 indicates that the block includes a steady response processing unit 211 and an event drive processing unit 221. The frame indicated by the function processing block 201 indicates whether or not the partitioning of the function processing block has been completed. Here, when the inside of the frame of the function processing block 201 is not painted out, it is assumed that the assignment is not completed. On the other hand, when the inside of the frame of the function processing block 201 is painted with a predetermined color, it is determined that the assignment is completed. That is, the function processing block 201 shown in FIG. 5 is before the partitioning and the assignment is not completed.
[0042]
Further, the frame indicated by the gradation 240 indicates that either software or hardware is selected as a result of the partitioning. Here, when the inside of the frame of the gradation 240 is not painted, it is assumed that software is assigned. On the other hand, when the inside of the frame of the gradation 240 is painted with a predetermined color, it is assumed that hardware is assigned. The notation by the frame indicated by the gradation 240 is valid only when the inside of the frame of the function processing block 201 is painted, that is, when the partitioning is completed.
[0043]
Next, examples of notation of functional processing blocks when software is allocated by partitioning and when hardware is allocated will be described.
[0044]
First, a case where software is assigned will be described. FIG. 6 is a notation example of a function processing block to which software is assigned. The same components as those in FIG. 5 are denoted by the same reference numerals, and description thereof will be omitted. The function processing block 202 includes a steady response processing unit 211 and an event drive processing unit 221. The frame of the function processing block 202 is painted out to indicate that the assignment is completed. The inside is not painted and indicates that the software is allocated.
[0045]
Next, a case where hardware is allocated will be described. FIG. 7 is a notation example of a function processing block to which hardware is assigned. The same components as those in FIG. 5 are denoted by the same reference numerals, and description thereof will be omitted. The function processing block 203 includes a steady response processing unit 211 and an event drive processing unit 221. The frame of the function processing block 203 is painted out to indicate that the assignment is completed. The inside is painted out to indicate hardware assignment.
[0046]
As described above, the functional processing block model obtained by dividing the functional processing from the system specifications includes a stationary response processing (represented by a combination of a data flow and a control flow) and an event-driven processing (preferably represented only by a data flow). ) To operate simultaneously and in parallel in all simulation steps. Switching between the steady-state response process and the event-driven process is mostly transmitted by an internal variable of the block, or transmitted by an event inside the block or by writing to a block internal variable that the block discloses to the outside. Performed by an external event of the block.
[0047]
Next, a description example of the operation specification of the function processing block will be described. First, the operation description of the steady-state response process and subsequently the event-driven process will be described.
FIG. 8 is an operation description example of the steady-state response processing according to the embodiment of the present invention. Here, it is described in a programming language, and the steady-state response processing unit 801 is described in the form of a finite state machine. In the example of FIG. 8, in the steady response processing, branch processing is performed based on the value of BLOCK0_STATE indicating the state of block 0 (802). Each operation of (805) is described. Here, the behavior description does not depend on the programming language to be used, and the same behavior description can be performed in a programming language having a branch processing description.
[0048]
FIG. 9 is an operation description example of the event drive processing according to the embodiment of the present invention. The drive response processing part can be described by a data flow or a control flow, but is preferably described only by a data flow. In the example of FIG. 9, the operation is divided into sub-processing blocks 901 and 902 corresponding to the occurring events, and an operation driven according to the event is described for each of the sub-processing blocks 901 and 902.
[0049]
In constructing a system using the functional processing block model of the present invention, the so-called scope of variables used in the model description must be clarified. This model consists of a steady-state response processor and an event-driven processor, and all variables used in the model description are required to close the scope in this model. That is, preferably, all variables used in the model description are unique variable names, and it is desirable to completely block the influence of other blocks by specifying the scope of the programming language used. The related processing between the steady-state response processing unit and the event drive processing unit of the model of the present invention is performed by using a variable whose scope is closed. In the example of FIG. 8 and FIG. 9, this is performed by the state variable of block 0 (BLOCK0_STATE). In other words, communication between the block described by the model and its external block is performed by giving an event (event) from the calling side (so-called master side) to the event drive processing unit of the called (so-called slave side) block model. It is.
[0050]
Here, it is obvious that the steady-state response processing unit shown in FIG. 8 functions as a main routine in software allocation and functions as a sequential circuit in hardware allocation. In addition, it is obvious that the event drive processing unit shown in FIG. 9 functions as a combinational logic circuit when assigned by software and becomes an interrupt processing unit when assigned by software. When the event-driven process includes a description in the control flow, a sequential logic circuit is included. In the example of FIG. 9, all of the event driven processing units (sub-processing blocks 901 and 902) are activated when block 0 receives an event as a slave, and in the direction of the signal (input side or output side). It turns out to be completely unrelated.
[0051]
As described above, according to the functional processing block model of the present invention, it is not only easy to replace hardware and software, but also to determine software or hardware form for each actual implementation before determining partitioning at the time of system design. It can be easily predicted.
[0052]
As described above, according to the present invention, hardware and software can be represented by the same functional processing block model, so that it is possible to perform system design while exchanging hardware or software sharing. Furthermore, after the system architecture is determined after estimating the performance, area, etc., regardless of whether the functional processing blocks are assigned to hardware or software, only the level of abstraction of the model is refined. Does not require any rewriting of the model and allows the use of a consistent model structure from start to finish. Further, the model description indicating the intention of the system designer can be completely retained at any level of abstraction.
[0053]
Next, a simulation process for performing a function evaluation will be described. FIG. 10 is an example of a flowchart showing a simulation process according to the embodiment of the present invention. In the simulation process shown in FIG. 10, the function processing block in which the operation specification is described is assigned to a task (task 0 to task 3 in the figure), and the simulation process is started. Specifically, when the simulation process is started, first, the task 0 assigned to the block 0 is activated (S151), and subsequently, the task 1 assigned to the block 1 is activated (S152). The assigned task 2 is activated (S153), and the task 3 assigned to the block 3 is activated (S154). When the respective task processes are started, the presence or absence of the occurrence of an event is sequentially checked from task 0 to task 3, and if an event has occurred, a simulation process corresponding to the event is performed. Since the processing for all tasks is the same, the case of task 0 will be described. In the simulation process, it is determined whether or not an event has occurred (S1511), and an event driving process (S5112) or a steady response process (S1513) is executed according to the determination result. These processes are repeated until a preset unit time or the like is reached.
[0054]
As described above, since all the function processing blocks can be operated at the same time, it is possible to reproduce the actual operation, and as a result, the verification can be easily performed.
[0055]
In the example of FIG. 10, the event processing unit 1001 cannot reproduce a strict order of event occurrence. That is, a sequence in the case where a plurality of events occur in the same loop is not correctly reproduced, and can be correctly expressed only when only one event occurs in the same loop. This is because the event processing unit 1001 of the simulator depends on the computer environment for executing the simulator. Regarding this, various modifications such as, for example, using an event queue of an operating system (OS) and performing a task switch based on the concept of first-in first-out can be considered. Thus, it is preferable to be true to the event generation sequence. Similarly, the steady-state response processing unit 1002 of the simulator also depends on the computer environment in which the simulator is executed, and forms a simulation mechanism that suppresses idle rotation when the functional processing block is in an idle state, thereby reducing the simulation time. Can be considered.
[0056]
As described above, it is possible to accurately simulate the dynamic processing sequence, and thus it is possible to accurately estimate costs such as performance and area. In addition, it can contribute to an improvement in the defect detection rate during system verification.
[0057]
Hereinafter, as a specific example to which the present invention is applied, a case where the present invention is applied to a general one-processor system LSI, an LSI not including a processor, a multiprocessor system, a multitask system, and a system in the system will be sequentially described with reference to the drawings. I do. The drawings used in the following description use the notation examples of the function processing block models used in FIGS. 5, 6, and 7.
[0058]
First, the case of a general one-processor system LSI will be described. FIG. 11 is an example of a system configuration diagram when applied to a general one-processor system LSI. In the example of FIG. 11, the function processing blocks 1101, 1102, 1103, 1104, 1105, 1106, 1107, and 1108 that execute predetermined processing functions are connected to each other, and software is assigned to the function processing block 1101. The hardware is allocated to the other function processing blocks 1102, 1103, 1104, 1105, 1106, 1107, and 1108. The function processing block 1101 to which software is assigned is a block for executing software processing by a processor, and includes a steady-state response processing unit 1121 and an event driving processing unit 1122. Similarly, the functional processing block 1102 to which the hardware is assigned also includes a steady response processing unit 1123 and an event drive processing unit 1124. Obviously, the model configuration is not changed by software or hardware allocation, and is represented by a common model. Also, no matter which one is assigned, the predictability of the block configuration after the actual implementation is not impaired.
[0059]
Second, a case of an LSI (so-called ASIC) not including a processor will be described. FIG. 12 is an example of a system configuration diagram when applied to an LSI that does not include a processor. The example of FIG. 12 is a system configuration in which functional processing blocks 1201, 1202, 1203, 1204, 1205, 1206, 1207, and 1208 are interconnected, as in FIG. 11, and hardware is allocated to all the functional processing blocks. Have been. The function processing block to which the hardware is assigned also includes a steady-state response processing unit 1221 and an event drive processing unit 1222. As described above, according to the present invention, the operation of a system including no processor and entirely including hardware-assigned function processing blocks can be described similarly to the case of including the software-assigned function processing blocks illustrated in FIG. it can.
[0060]
Third, a case of a multiprocessor system (so-called parallel computing) will be described. FIG. 13 is an example of a system configuration diagram when applied to a multiprocessor system. The example in FIG. 13 is a system configuration in which functional processing blocks 1301, 1302, 1303, 1304, 1305, 1306, 1307, and 1308 are interconnected, as in FIG. Have been assigned. The function processing block to which this software is assigned also includes a steady response processing unit 1321 and an event drive processing unit 1322. As described above, according to the present invention, the system including all the software allocation function processing blocks is also used when the software allocation function processing block and the hardware allocation function processing block shown in FIG. The operation can be described as in the case where everything shown is constituted by hardware allocation function processing blocks.
[0061]
Fourth, a case of a multitask system will be described. FIG. 14 is an example of a system configuration diagram when applied to a multitask system. The multitask system in the example of FIG. 14 has a hierarchical structure, and software is assigned to all the function processing blocks 1401, 1402, 1403, and 1404. The function processing block 1401 corresponding to the kernel program on the processor is the highest hierarchy, and the function processing blocks 1402, 1403, and 1404 corresponding to the tasks under the control of the kernel program are the lower hierarchy. The function processing block 1401 corresponding to the kernel program also includes a steady-state response processing unit 1421 and an event-driven processing unit 1422, and each task under its control also includes a steady-state response processing unit and an event-driven processing unit. The kernel program generally uses an OS. Also in this case, the relationship between the kernel program and each task under control and the relationship with each task are maintained, so that there is no need to change the model configuration.
[0062]
FIG. 15 is a description example of an operation specification when applied to a multitask system. The operation specification is for the function processing block 1401 at the highest level, and the operation description part 1501 corresponding to the highest level of the description means a kernel program. Subsequently, the operation description unit 1502 describes a task generation process, and the following operation description unit 1503 describes a process of putting a task into an execution state. That is, the function processing blocks 1402, 1403, and 1404 corresponding to the respective tasks are generated in the operation description unit 1502, and are executed in the operation description unit 1503. The operation description unit 1501 is replaced with an OS in a later stage of system design, and the task generation operation description unit 1502 and the task execution operation description unit 1503 are generally replaced as service routine calls of the OS. At the time of replacement, only the level of abstraction of the model is refined, and there is no need to rewrite the model. That is, a consistent model structure can be used throughout.
[0063]
As described above, the operation of a system having a hierarchical structure can be similarly described, and the robustness of the model structure with respect to the hierarchical structure is high.
Fifth, a case of a system in a system (so-called SIP, SOP) will be described. FIG. 16 is an example of a system configuration diagram when applied to a system in the system. The system in the system in the example of FIG. 16 has a hierarchical structure, in which hardware is allocated to the function processing blocks 1601, 1602, and 1603, and software is allocated to the function processing blocks 1604, 1605, 1607, and 1608. I have. Although the functional processing block 1601 which is the highest hierarchy of the system configuration is assumed to be a control circuit of the entire system by hardware, it may have a configuration in which subsystems are simply combined. In this case, the function processing block 1601 can be omitted. Functional processing blocks 1602 and 1603 indicate subsystems. Here, all the subsystems on the function processing block 1601 assume an SOC including a processor. However, the subsystem including the processor at all and the processor including and not including the processor may be mixed. , System construction, and simulation verification are both possible. Further, even if the subsystem is an analog circuit, no problem occurs in the model, and the analog-digital level converter block model can be expressed and executed simply by inserting it into the analog-digital interface. This proves that there is no restriction on the abstraction level (or calculation granularity) of the invention model, which means that it is possible to estimate the cost such as performance and area by mixing models with different abstraction levels. .
[0064]
FIG. 17 is a description example of operation specifications when applied to a system in a system. The operation description part 1701 indicates the highest hierarchy. The operation description section 1702 describes the initialization processing of the subsystem, and the operation description section 1703 describes the activation processing of the subsystem.
[0065]
Note that the present invention is not limited to the above-described application examples, but includes, for example, a combination of the first application example and the fourth application example, and a combination of the third application example and the fourth application example. Various modifications are possible.
[0066]
As described above, the present invention can support any system configuration currently considered. For example, a hardware system on a processor means a system model of a processor system that can use an extended instruction set by adding a hardware part, which is expected to be fully generalized in the future. Examination and performance estimation are possible. Further, since the operation description can be performed in general programming languages in general, a special simulation environment is not required. As described above, since models can be constructed in general programming languages in general, the models or systems once constructed can be easily reused.
[0067]
Note that the above processing functions can be realized by a computer. In this case, a program is provided which describes the processing contents of the functions that the system design support apparatus should have. The program describing the processing content can be recorded on a computer-readable recording medium.
[0068]
Also, the computer that executes the program stores, for example, the program recorded on a portable recording medium in its own storage device. Then, it reads the program from its own storage device and executes processing according to the program. The computer can also read the program directly from the portable recording medium and execute processing according to the program.
[0069]
【The invention's effect】
As described above, in the system design support method of the present invention, in addition to the conventional modeling method, attention is paid to the state of the system, and the function processing block model extended to the alternative model configuration of the steady response processing and the event driven processing is used. And can be applied to both hardware and software. For this reason, when examining partitioning, which is essential when designing the system, it is possible to study while freely switching the assignment of hardware and software, and it is possible to easily estimate the performance of the system. Further, in the detailed design, it is only necessary to refine the degree of abstraction of the functional processing block model, and a consistent model can be used regardless of whether it is assigned to hardware or software.
[0070]
In addition, the system design support apparatus of the present invention focuses on the state of the system in addition to the conventional modeling method, and operates the processing functions in accordance with a function processing block model expanded to an alternative model configuration of steady-state response processing and event-driven processing. Is input, and the function processing block is evaluated according to the partitioning setting. At this time, in partitioning, the assignment of hardware and software can be freely switched and evaluated, so that the performance estimation of the system can be easily performed. Further, in the next detailed design, it is possible to input and edit an operation description for refining the abstraction of the model by using the same functional processing block model.
[Brief description of the drawings]
FIG. 1 is a conceptual diagram of the invention applied to an embodiment of the present invention.
FIG. 2 is a conceptual diagram of a functional processing block model according to an embodiment of the present invention.
FIG. 3 is a diagram illustrating a hardware configuration of a system design support apparatus.
FIG. 4 is a block diagram illustrating functions of a system design support apparatus.
FIG. 5 is a notation example of a functional processing block model according to an embodiment of the present invention.
FIG. 6 is a notation example of a function processing block to which software is assigned.
FIG. 7 is a notation example of a function processing block to which hardware is assigned;
FIG. 8 is an operation description example of a steady-state response process according to the embodiment of the present invention.
FIG. 9 is an operation description example of an event driving process according to an embodiment of the present invention.
FIG. 10 is an example of a flowchart showing a simulation process according to the embodiment of the present invention.
FIG. 11 is an example of a system configuration diagram when applied to a general one-processor system LSI.
FIG. 12 is an example of a system configuration diagram when applied to an LSI that does not include a processor.
FIG. 13 is an example of a system configuration diagram when applied to a multiprocessor system.
FIG. 14 is an example of a system configuration diagram when applied to a multitask system.
FIG. 15 is a description example of an operation specification when applied to a multitask system.
FIG. 16 is an example of a system configuration diagram when applied to a system in the system.
FIG. 17 is a description example of an operation specification when applied to a system in a system.
FIG. 18 is a flowchart of a processing procedure of a system design.
FIG. 19 is an example of a model description using a data flow and a control flow.
[Explanation of symbols]
110 ... monitor, 120 ... keyboard, 130 ... design information database, 151 ... steady response processing operation specification editor, 152 ... event driven processing operation specification editor, 153 ... partitioning Section, 154: functional processing block evaluation section, 210: steady-state response processing, 220: event driving processing, 230: boundary

Claims

Using a computer, a system design support method for dividing the processing functions of the system into function processing blocks and sharing the function processing blocks between hardware and software to design the system,
Based on a functional processing block model consisting of an internal state or a steady-state response process determined by the internal state and an input value at that time, and an event-driven process driven in response to a predetermined event, the steady-state response process and the previous Inputting and editing an operation specification describing the operation of the event-driven process;
The function processing block is divided into hardware and software based on the created operation specification, and
Evaluating an operation specification of the functional processing block shared by hardware and software;
A system design support method comprising:

2. The system design support method according to claim 1, wherein said steady response processing is described using a finite state machine.

2. The system design support method according to claim 1, wherein the event-driven processing is divided into sub-processing blocks corresponding to respective events, and an operation is described for each of the sub-processing blocks.

The functional processing block model has a structure in which the steady-state response processing and the event-driven processing are selectively selected, and the step of performing the evaluation includes the step of performing the evaluation based on the operation specification. 2. The system design support method according to claim 1, wherein the driving process is selectively executed.

In a system design support apparatus that divides a processing function of a system into function processing blocks and supports the design of the system performed by dividing the function processing blocks into hardware and software,
Based on a functional processing block model consisting of an internal state or a steady-state response process determined by the internal state and an input value at that time, and an event-driven process driven in response to a predetermined event, the steady-state response process and the previous Operation specification editing means for inputting and editing an operation specification describing the operation of the event-driven process;
Design information recording means for recording the operation specifications created by the operation specification editing means,
Sharing means for sharing the function processing block in which the operation specifications are created with hardware and software,
Function processing block evaluation means for evaluating an operation specification of the function processing block shared by hardware and software,
A system design support device comprising: