JP5262403B2 - 設計支援プログラム、設計支援装置、および設計支援方法 - Google Patents

Description

この発明は、ソフトウェアを実行するハードウェアモデル群からなるアーキテクチャを最適化する設計支援プログラム、設計支援装置、および設計支援方法に関する。

近年、システムＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）の開発時におけるシミュレーションによる設計技術が進められている。この技術は主にＥＳＬ（Ｅｌｅｃｔｒｏｎｉｃ Ｓｙｓｔｅｍ Ｌｅｖｅｌ）技術と呼ばれ、システムＬＳＩの設計を、段階ごとに詳細性（抽象性）を変えながら設計を行うシステム上流工程設計での高速シミュレーション技術である。一方で、抽象度の低い構成では、処理速度は遅いが、実際のハードウェアロジックに近い、ハード詳細設計の段階で用いられる（たとえば、下記特許文献１，２を参照。）。

ＥＳＬ技術では、詳細なクロック動作などを適宜スキップ、隠蔽することで高速動作を行うことができる。ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）のインストラクションシミュレータと連動させることで、ソフト動作可能なシミュレーション環境として利用されており、ＳｏＣ（Ｓｙｓｔｅｍ Ｏｎ ａ Ｃｈｉｐ）などの大規模システムＬＳＩ開発に適用される。

この技術を用いてシステム全体の挙動を開発の初期段階で見極め、詳細な動作は後工程で実施を行う。設計者は開発上流段階でのブロック図構成レベルの情報でハードウェアを表記することができる。ＥＳＬなどで用いられるシミュレーションでハードウェアを表現する場合、ＳｙｓｔｅｍＣおよびＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）スクリプトによるハードウェア記述によりハードウェアをプログラマブルに表現できるため、容易にシステム構成を変更した評価を行うことができる。またこれらのハードウェア表現は一般的なソフトウェアのプログラムと同様の表現がなされる。

特開２００１−２２８０８号公報 特開２００３−６７４３８号公報

しかしながら、上述した従来技術では、人手によりＥＳＬを用いてシステム構成を考えていたため、設計者の技量や経験が求められる一方、設計者の技量や経験により生成される設計結果が異なる。したがって、技量や経験が浅い設計者が設計すると、目標仕様に対して、性能、物量コスト、消費電力などを達成できない可能性があるという問題があった。

また、上流工程で十分な検証が行われなかった場合、後工程において再設計手戻りの作業が発生してしまい、開発工程遅延あるいはコスト高騰などの問題が発生する可能性があるという問題があった。

また、上述した従来技術により論理設計での回路最適化をおこなっても上流設計にて誤りがある場合、その論理設計段階の回路最適化が無駄になるという問題があった。また、抽象度の異なるシミュレーションレベルを相互に行き来する場合、また大規模シミュレーションにあたっては、シミュレーション時間が増大し、設計期間の長期化を招くという問題があった。

この発明は、上述した従来技術による問題点を解消するため、効率的かつ最適なアーキテクチャ設計を短期間で実現することができる設計支援プログラム、設計支援装置、および設計支援方法を提供することを目的とする。

上述した課題を解決し、目的を達成するため、この設計支援プログラム、設計支援装置、および設計支援方法は、ソフトウェアを実行するハードウェアモデル群からなるアーキテクチャを取得し、取得されたアーキテクチャ内のハードウェアモデルの分割または／および融合の可能性を判断し、判断結果に基づいて、前記アーキテクチャを再構築し、再構築後のアーキテクチャを出力することを要件とする。

この設計支援プログラム、設計支援装置、および設計支援方法によれば、効率的かつ最適なアーキテクチャ設計を短期間で実現することができるという効果を奏する。

以下に添付図面を参照して、この設計支援プログラム、設計支援装置、および設計支援方法の好適な実施の形態を詳細に説明する。本実施の形態では論理設計での回路最適化ではなく、さらに上流工程での全体トラフィックを概略的に探索追求していく技術である。特に抽象度の高いシミュレーションを対象とし、設計の上流工程においてシステムアーキテクチャを探求する際に最適なアーキテクチャ構成を求める技術である。

図１は、本実施の形態にかかる設計支援装置の概要を示す説明図である。図１において、設計支援装置１００は、最適化前のＳｙｓｔｅｍＣおよび接続情報を記したスクリプトコードで記述されたハードウェアモデルのソースコード群１０１、設計対象となるＳｏＣにおいて動作させる評価ソフトウェア１０２、および設計者により指定される最適化の優先度／実装制約情報１０３を入力する。

そして、これらの入力情報をもとに入力されたハードウェアモデル群からなるアーキテクチャをリストラクチャリング（再構築）する。そして、指定された優先度に応じた最適化結果１１０として、たとえば、ＳｙｓｔｅｍＣのハードウェアモデル群からなる最適化後のアーキテクチャを出力する。

ここで、ハードウェアモデルとは、設計対象であるＳｏＣの構成要素のモデルであり、たとえば、ＣＰＵやメモリ、ストレージ、ブリッジ、表示装置、通信ユニットなどのモデルがある。評価ソフトウェア１０２とは、ハードウェアモデル群からなるアーキテクチャに実行させるベンチマークプログラムである。したがって、評価ソフトウェア１０２に最適なリストラクチャリングが実行される。優先度／実装制約情報１０３とは、設計者によって指定される優先度および実装制約を記述した情報である。この実装制約により分割や融合が制限されることとなる。優先度とは、性能、物量コスト、消費電力の優劣であり、これらの優先順位に応じたリストラクチャリングが実行される。

設計支援装置１００は、コード解析部１０４とＥＳＬシミュレーション実行部１０６と最適化処理部１０９とを備える。コード解析部１０４は、入力されたハードウェアモデルのソースコード群１０１をコード解析によりグラフ化することでブロック化モデル群に変換する。ＥＳＬシミュレーション実行部１０６は、評価ソフトウェア１０２をブロック化ハードモデル群１０５からなるアーキテクチャ上で実行させることにより、シミュレーション結果１０７を出力する。このシミュレーション結果１０７は、ハードウェアモデル間のデータの依存関係をあらわす。

データベース（ＤＢ）１０８には、物量コストや消費電力を求めるための参照テーブルが保存されている。最適化処理部１０９は、シミュレーション結果１０７に基づいてブロック化ハードモデル群１０５からなるアーキテクチャをリストラクチャリングして、最適な構成を自動探求する。そして、このリストラクチャリングされた最適化後のアーキテクチャを出力する。この際、データベース１０８を参照して、最適化後のアーキテクチャの物量コストや消費電力を算出して、最適化結果１１０として出力する。

このようにして、設計対象となるＳｏＣを構成するハードウェアモデルのソースコード群１０１と、評価ソフトウェア１０２と、優先度／実装制約情報１０３を与えるだけで、評価ソフトウェア１０２に適合したアーキテクチャを自動探求することができる。これにより、抽象度の高いＥＳＬ設計段階において、設計者間でばらつきのない信頼性のあるＥＳＬ設計を短期間で実現することができる。

（設計支援装置１００のハードウェア構成）
図２は、実施の形態にかかる設計支援装置１００のハードウェア構成を示すブロック図である。図２において、設計支援装置１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１と、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３と、磁気ディスクドライブ２０４と、磁気ディスク２０５と、光ディスクドライブ２０６と、光ディスク２０７と、ディスプレイ２０８と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）２０９と、キーボード２１０と、マウス２１１と、スキャナ２１２と、プリンタ２１３と、を備えている。また、各構成部はバス２００によってそれぞれ接続されている。

ここで、ＣＰＵ２０１は、設計支援装置１００の全体の制御を司る。ＲＯＭ２０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ２０３は、ＣＰＵ２０１のワークエリアとして使用される。磁気ディスクドライブ２０４は、ＣＰＵ２０１の制御にしたがって磁気ディスク２０５に対するデータのリード／ライトを制御する。磁気ディスク２０５は、磁気ディスクドライブ２０４の制御で書き込まれたデータを記憶する。

光ディスクドライブ２０６は、ＣＰＵ２０１の制御にしたがって光ディスク２０７に対するデータのリード／ライトを制御する。光ディスク２０７は、光ディスクドライブ２０６の制御で書き込まれたデータを記憶したり、光ディスク２０７に記憶されたデータをコンピュータに読み取らせたりする。

ディスプレイ２０８は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ２０８は、たとえば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。

インターフェース（以下、「Ｉ／Ｆ」と略する。）２０９は、通信回線を通じてＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどのネットワーク２１４に接続され、このネットワーク２１４を介して他の装置に接続される。そして、Ｉ／Ｆ２０９は、ネットワーク２１４と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ２０９には、たとえばモデムやＬＡＮアダプタなどを採用することができる。

キーボード２１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス２１１は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などをおこなう。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。

スキャナ２１２は、画像を光学的に読み取り、設計支援装置１００内に画像データを取り込む。なお、スキャナ２１２は、ＯＣＲ（Ｏｐｔｉｃａｌ Ｃｈａｒａｃｔｅｒ Ｒｅａｄｅｒ）機能を持たせてもよい。また、プリンタ２１３は、画像データや文書データを印刷する。プリンタ２１３には、たとえば、レーザプリンタやインクジェットプリンタを採用することができる。

（データベース１０８の記憶内容）
図３は、データベース１０８に記憶されている物量コスト／消費電力テーブルを示す説明図である。物量コスト／消費電力テーブル３００は、ハードウェアごとに物量コスト（価格）および消費電力を記憶する。バスについては、リストラクチャリングにより帯域が変動するため固定値ではなく、変動値であらわす。このため、バスセッティング特性グラフへのポインタを記憶する。また、メモリについても、メモリサイズにより物量コストや消費電力が変動するため固定値ではなく、メモリ価格／消費電力テーブル５００へのポインタを記憶する。

図４は、バスセッティング特性グラフを示す説明図である。バスセッティング特性グラフ４００は、バスのセッティングによる消費電力特性を示している。横軸が帯域、縦軸が消費電力である。バスの帯域は、与える周波数により変化し、必要な帯域を確保する周波数を設定すれば、消費電力が一意に定まる。

図５は、メモリ価格／消費電力テーブル５００を示す説明図である。メモリ価格／消費電力テーブル５００は、単位メモリサイズ（ここでは、５０［Ｍｂ］）あたりの物量コストと消費電力を規定している。メモリは、利用するサイズによりコストと消費電力が変化するが、通常３２Ｍｂ／６４Ｍｂ／１２８Ｍｂ／２５６Ｍｂ…といった段階的な取り扱いを行うため、利用するサイズにより、段階的なコスト・消費電力値をもつ。本例では計算の簡略化のため、５０Ｍｂ単位としている。

（最適化処理部１０９の機能的構成）
図６は、図１に示した最適化処理部１０９の機能的構成を示すブロック図である。図６において、最適化処理部１０９は、記憶部６００と、取得部６０１と、判断部６０２と、再構築部６０３と、出力部６０４と、決定部６０５と、選択部６０６と、算出部６１０と、を備えている。

記憶部６００は、図１に示したデータベース１０８に相当する機能であり、図２に示したＲＯＭ２０２、ＲＡＭ２０３、磁気ディスク２０５、光ディスク２０７などの記録媒体によりその機能を実現する。また、制御部となる機能（取得部６０１〜算出部６１０）は、具体的には、たとえば、図２に示したＲＯＭ２０２、ＲＡＭ２０３、磁気ディスク２０５、光ディスク２０７などの記憶領域に記憶されたプログラムをＣＰＵ２０１に実行させることにより、または、Ｉ／Ｆ２０９により、その機能を実現する。

取得部６０１は、ソフトウェアを実行するハードウェアモデル群からなるアーキテクチャを取得する機能を有する。具体的には、たとえば、評価ソフトウェア１０２を実行するブロック化ハードモデル群１０５を読みこむ。以下、ブロック化ハードモデルを「ハードウェアブロック」と称す。

ここで、設計対象のアーキテクチャについて説明する。評価ソフトウェア１０２を実行した結果、各ハードウェアブロック間を通過するデータ流量が定義される。このとき、評価を行おうとしている設計対象がＮ個のハードウェアブロックで構成されているとき、各々のハードウェアブロックをＨＷｎ（ｎ＝１，２，３，…，Ｎ）と表記する。

図７は、設計対象のアーキテクチャの一例を示す説明図である。図８は、図７に示したアーキテクチャ７００のデータ依存関係を示すブロック構成図である。データ依存関係は、黒い矢印で示している（以下の図においても同様）。図７のアーキテクチャ７００において、ＨＷ１〜ＨＷ４、ＨＷｘおよびＨＷｙは、ハードウェアブロックであり、バスＢに接続されている。ここで、ＨＷ１はＣＰＵ、ＨＷ２はアクセラレータ、ＨＷ３は通信ユニット、ＨＷ４はファイル管理ユニット、ＨＷｘとＨＷｙはメモリをあらわしている。

図６に戻って、取得部６０１は、アーキテクチャ７００にソフトウェアを実行させることにより、ハードウェアブロック間のデータ依存情報を取得する機能を有する。具体的には、たとえば、ＥＳＬシミュレーション実行部１０６により図７に示したアーキテクチャに評価ソフトウェア１０２を実行させた結果得られるデータ依存情報を読み込む。

図７のアーキテクチャ７００の場合のデータ依存情報について説明する。データ依存情報とは、ハードウェアモデル間のデータの流れまたはそのデータ量である。アクセス先がメモリやレジスタ、ストレージである場合、メモリサイズで表現可能である。通常、ソフトウェアのブロック間依存はデルタ関数δで表記される。

本実施の形態ではＳｙｓｔｅｍＣなどのハードウェア記述言語で表現されたハードウェアモデルを一種のソフトウェアとみなしているので、この表記を利用してハードウェアブロックを表現していく。すなわち、ＨＷｍとＨＷｎとの間にデータ転送があった場合、そのデータの流れをδ（ＨＷｍ，ＨＷｎ)と表記する。

・ＣＰＵから第１のメモリへのアクセス
δ（ＨＷ１，ＨＷｘ）＝アドレス空間｛００２０〜０１３９｝＝サイズ：１２０

・アクセラレータから第１のメモリへのアクセス
δ（ＨＷ２，ＨＷｘ）＝アドレス空間｛０１３０〜０１４９｝＝サイズ：０２０

・通信ユニットから第１のメモリへのアクセス
δ（ＨＷ３，ＨＷｘ）＝アドレス空間｛００００〜０１２９｝＝サイズ：１３０

・ファイル管理ユニットから第１のメモリへのアクセス
δ（ＨＷ４，ＨＷｘ）＝アドレス空間｛０１４０〜０１５９｝＝サイズ：０１０

・ファイル管理ユニットから第２のメモリへのアクセス
δ（ＨＷ４，ＨＷｙ）＝アドレス空間｛０１６０〜０１６９｝＝サイズ：０１０

なお、δ（ＨＷａ，ＨＷｂ）のうちａ，ｂにおいてｘ，ｙを除く１〜４の組み合わせについては、すべてφ（空集合＝データの流れがなかった）であったとする。また、取得部６０１は、アーキテクチャの性能、物量コスト、または消費電力に関する優先度を取得する。具体的には、たとえば、図１に示した優先度／実装制約情報１０３を読み込む。たとえば、優先度／実装制約情報１０３がＨＷ１とＨＷ２との分割を禁止する記述である場合、リストラクチャリング後にＨＷ１とＨＷ２とを別の分割グループにする分割を禁止する。

図６に戻って、判断部６０２は、取得部６０１によって取得されたアーキテクチャ内のハードウェアモデルの分割または／および融合の可能性を判断する機能を有する。分割とは、ハードウェアモデルを２以上に分離することである。また、融合とは、２以上のハードウェアモデルを単一のハードウェアモデルにまとめることである。

ここで、分割／融合可能性判断について説明する。少なくとも２つ以上のハードウェアブロックからφではないデータ依存があるハードウェアブロックを共用リソースとする。本例では、ＨＷｘが共用リソースとなる。この共有リソースがアーキテクチャに存在する場合、共有リソースに相当するハードウェアモデルは分割可能であると判断される。

また、本例がＳｙｓｔｅｍＣで記述されているとすると、ＨＷｘ，ＨＷｙは同一のメモリを表現するライブラリにリンクされている。すなわち、ＨＷｘ，ＨＷｙは、設計者が求める最適アーキテクチャにおいて、同一のＩＰ（Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ）から生成されるハードウェアブロックである。したがって、ＨＷｘ，ＨＷｙは、融合可能でかつ分割可能なハードウェアブロックと判断される。このように、アーキテクチャ内に存在する同種のハードウェアブロックの個数により、アーキテクチャ内のハードウェアブロックの融合／分割の可能性を判断する。

再構築部６０３は、判断部６０２によって判断された判断結果に基づいて、アーキテクチャを再構築する機能を有する。具体的には、たとえば、分割可能ハードウェアモデルを分割するリストラクチャリングを実行する。また、融合可能なハードウェアモデルを融合するリストラクチャリングを実行する。ここで、リストラクチャリングの詳細について図７のアーキテクチャを用いて説明する。

まず、リストラクチャリングに先だって、図７のアーキテクチャ７００において、データ転送総量および、アクセス空間評価値を算出する。ＨＷｍとＨＷｎとの間にデータ転送があった場合、デルタ関数δ（ＨＷｍ，ＨＷｎ）と表記したが、その評価値としてデータ転送総量を定義することができる。ソフトウェアシミュレーションによって得られるこの数量をデータ転送総量ＤＴｍ，ｎとし、下記式（１）のように表記する。

δ（ＨＷｍ，ＨＷｎ）＝ＤＴｍ，ｎ・・・（１）

ここで、ＨＷｎが接続するバス経路のデータ流量総量ＤＴｎは下記式（２）のように表現されることになる。データ授受が行われないハードウェアブロックでは、δ（）＝０となる。

ＤＴｎ＝Σδ（ＨＷｋ，ＨＷｎ）・・・（２）
ただし、ｋ＝１，２，３，…，Ｎ

したがって、図７に示したアーキテクチャ７００の共用リソースであるＨＷｘに対するデータ転送総量ＤＴｘは、
ＤＴｘ＝Σδ（ＨＷｎ，ＨＷｘ）となり、ｎ＝１〜４であるから、
ＤＴｘ＝１２０＋０２０＋１３０＋０１０＝２８０となる。
同じく、図８に示したＨＷｙに対するデータ転送総量ＤＴｙは、ＤＴｙ＝１０である。

したがって、ＨＷｎが接続されるバス経路には高々式（２）を満たす帯域をもったバスを設定すればよいことになる。データ転送総量は高抽象度モデルであれば、大きさのみを表す絶対値表現を行う。

また、ＨＷｍがＨＷｎに対してアクセスを行った場合、ＨＷｎにおいてアクセスを行ったアドレス空間をアドレス空間評価値ＡＳ（ｍ，ｎ）と定義する。たとえば、ＨＷｎが何らかのペリフェラル素子であった場合はレジスタであり、ＨＷｎがメモリ素子であった場合はメモリ空間を指す。アドレス空間評価値ＡＳ（ｍ，ｎ）はアドレスの集合であり、集合演算を用いて評価を行う。

図８に示したアーキテクチャ７００において、δ（ＨＷｍ，ＨＷｘ）≠０となるｘ，ｙ、すなわちＨＷｍにアクセスを行うブロックすべてに対してアドレス空間評価値を算出する。アドレス空間評価値は以下のようになる。
ＡＳ（ｘ，１）＝|δ（ＨＷ１，ＨＷｘ）|＝１２０
ＡＳ（ｘ，２）＝|δ（ＨＷ２，ＨＷｘ）|＝２０
ＡＳ（ｘ，３）＝|δ（ＨＷ３，ＨＷｘ）|＝１３０
ＡＳ（ｘ，４）＝|δ（ＨＷ４，ＨＷｘ）|＝２０
ＡＳ（ｙ，４）＝|δ（ＨＷ４，ＨＷｙ）|＝１０
これ以外のアドレス空間評価値は０である。

つぎに、ハードウェアブロックＨＷｍ，ＨＷｎ（ｍ≠ｎ）に対して下記式（３）の依存評価値ＷＳ（ｍ，ｎ）を算出する。
ＷＳ（ｍ，ｎ）＝ＡＳ（ｍ，ｘ）∩ＡＳ（ｎ，ｘ） （ｍ≠ｎ）・・・（３）

式（３）の依存評価値ＷＳ（ｍ，ｎ）は、ハードウェアブロックＨＷｍ，ＨＷｎのアクセス領域の重なりの部分を表現しており、依存量関係を表している。式（３）の値が空集合φである場合、ＨＷｘにおけるＨＷｍ，ＨＷｎは互いに依存関係がなく、ＨＷｘをＨＷｍがアクセスする領域とＨＷｎがアクセスする領域を分割しても問題ないことになる。

図７に示したアーキテクチャにおいて、各依存評価値ＷＳ（ｍ，ｎ）は以下のようになる。
ＷＳ（１，２）＝δ（ＨＷ１，ＨＷｘ）∩δ（ＨＷ２，ＨＷｘ）
＝（２０〜１３９）∩（１３０〜１４９）＝（１３０〜１３９）＝１０
ＷＳ（１，３）＝δ（ＨＷ１，ＨＷｘ）∩δ（ＨＷ３，ＨＷｘ）
＝（２０〜１３９）∩（０〜１２９）＝（２０〜１２９）＝１１０
ＷＳ（１，４）＝δ（ＨＷ１，ＨＷｘ）∩δ（ＨＷ４，ＨＷｘ）
＝（２０〜１３９）∩（１４０〜１５９）＝０
ＷＳ（２，３）＝δ（ＨＷ２，ＨＷｘ）∩δ（ＨＷ３，ＨＷｘ）
＝（１３０〜１４９）∩（０〜１２９）＝０
ＷＳ（２，４）＝δ（ＨＷ２，ＨＷｘ）∩δ（ＨＷ４，ＨＷｘ）
＝（１３０〜１４９）∩（１４０〜１５９）＝（１４０〜１４９）
＝１０
ＷＳ（３，４）＝δ（ＨＷ３，ＨＷｘ）∩δ（ＨＷ４，ＨＷｘ）
＝（０〜１２９）∩（１４０〜１５９）＝０

つぎに、分割のリストラクチャリングについて説明する。分割対象となるハードウェアブロックは共用リソースである。図７の場合は、ＨＷｘを分割することになる。ＨＷｘと、ＨＷｘにデータ依存する４つのハードウェアブロックＨＷ１〜ＨＷ４を分割するパターンは、以下のように有限個が存在する。

４つのハードウェアブロックを２グループに分ける組み合わせのうち、１：３に分割するケース
｛ＨＷ４｝，｛ＨＷ１，ＨＷ２，ＨＷ３｝・・・図１３
｛ＨＷ３｝，｛ＨＷ１，ＨＷ２，ＨＷ４｝・・・図１４
｛ＨＷ２｝，｛ＨＷ１，ＨＷ３，ＨＷ４｝・・・図１５
｛ＨＷ１｝，｛ＨＷ２，ＨＷ３，ＨＷ４｝・・・図１６

４つのハードウェアブロックを２グループに分ける組み合わせのうち、２：２に分割するケース。
｛ＨＷ１，ＨＷ２｝，｛ＨＷ３，ＨＷ４｝
｛ＨＷ１，ＨＷ３｝，｛ＨＷ２，ＨＷ４｝・・・図９
｛ＨＷ１，ＨＷ４｝，｛ＨＷ２，ＨＷ３｝

４つのハードウェアブロックを３グループに分ける組み合わせのうち、１：１：２に分割するケース。
｛ＨＷ３｝，｛ＨＷ４｝，｛ＨＷ１，ＨＷ２｝・・・図１７
｛ＨＷ２｝，｛ＨＷ４｝，｛ＨＷ１，ＨＷ３｝・・・図１８
｛ＨＷ２｝，｛ＨＷ３｝，｛ＨＷ１，ＨＷ４｝・・・図１９
｛ＨＷ１｝，｛ＨＷ４｝，｛ＨＷ２，ＨＷ３｝・・・図２０
｛ＨＷ１｝，｛ＨＷ３｝，｛ＨＷ２，ＨＷ４｝・・・図２１
｛ＨＷ１｝，｛ＨＷ２｝，｛ＨＷ３，ＨＷ４｝・・・図２２

４つのハードウェアブロックを４グループに分ける組み合わせのうち、１：１：１：１に分割するケース。
｛ＨＷ１｝，｛ＨＷ２｝，｛ＨＷ３｝，｛ＨＷ４｝・・・図２３

以上のように、すべての組み合わせを総当りで分割することになる。図９は、図８に示したアーキテクチャの２：２分割による再構築後のアーキテクチャを示すブロック構成図である。なお、融合については、各分割パターンについて、ＨＷｘ，ＨＷｙを融合してもよい（図１０を参照）。

図１０は、図９に示した２：２分割による再構築後のアーキテクチャにおける融合による再構築後のアーキテクチャを示すブロック構成図である。また、リストラクチャリング前のＨＷｘ，ＨＷｙを融合してもよい。図１１は、図８に示したアーキテクチャの融合による再構築後のアーキテクチャを示すブロック構成図である。

出力部６０４は、再構築部６０３による再構築後のアーキテクチャを出力する機能を有する。具体的には、たとえば、最適化結果１１０として、再構築後のアーキテクチャを出力する。出力形式は、ディスプレイ２０８への表示、プリンタ２１３による印刷出力、他の装置への送信、記憶部６００への書込みなどがある。

決定部６０５は、アーキテクチャ内のハードウェアモデルの分割、融合、または、分割後の融合の中からアーキテクチャに可能な再構築種を決定する機能を有する。具体的には、アーキテクチャの性能、物量コスト、または消費電力に関する優先度（優先度／実装制約情報１０３）と判断結果とに基づいて、再構築種を決定する。この場合、再構築部６０３は、決定された再構築種に応じた再構築をおこなう。なお、「分割後の融合」とは、まず分割のリストラクチャリングをおこない、その再構築後のアーキテクチャに対して融合を施すリストラクチャリングである。

ここで、再構築種の決定について説明する。物量コストの観点でみると、回路分割を行うと回路の個数が増加するため、コスト増となる。消費電力の観点でみると、回路分割を行うことで、回路の個数増加に伴う消費電力が増加する反面、負荷分散によるクロック低下で消費電力が減少する。性能の観点でみると、回路分割を行うことで、負荷分散によりリソース衝突に起因する遅延が低減したり、帯域の優先利用率が高くなるため、性能が向上する。したがって、優先度と分割／融合は、以下の関係を有する。

物量コスト最優先の場合、再構築種は「融合」と「分割後の融合」に決定される。ただし、判断部６０２により分割不可である場合、再構築種は「融合」のみであり、融合不可である場合、リストラクチャリング自体ができないこととなる。

消費電力最優先の場合、再構築種は「融合」と「分割後の融合」に決定される。ただし、判断部６０２により分割不可である場合、再構築種は「融合」のみであり、融合不可である場合、リストラクチャリング自体ができないこととなる。

性能最優先の場合、再構築種は「分割」と「分割後の融合」に決定される。ただし、判断部６０２により分割不可である場合、リストラクチャリング自体ができない。一方、融合不可である場合、再構築種は「分割」のみである。

図６に戻って、選択部６０６は、データ依存量により特定される一対のハードウェアの集合のうち、データ依存量が最小となる一対のハードウェアから順次選択する機能を有する。依存評価値ＷＳ（ｍ，ｎ）はベクトル値であるため、ＷＳ（ｍ，ｎ）≠φの場合、データ依存量ＤＥＰ（ｍ，ｎ）は、下記式（４）であらわすことができる。

ＤＥＰ（ｍ，ｎ）＝｜ＡＳ（ｍ，ｘ）∩ＡＳ（ｎ，ｘ）｜・・・（４）

ＡＳ（ｍ，ｘ）∩ＡＳ（ｎ，ｘ）＝φの場合、ＤＥＰ（ｍ，ｎ）＝０となる。たとえば、ＨＷ１，ＨＷ２をグループ分割する場合、ＨＷ１，ＨＷ２のデータ依存量ＤＥＰ（１，２）を評価すると、
ＤＥＰ（１，２）＝｜ＷＳ（１，２）｜＝｜（１３０〜１３９）｜＝１０
となる。

また、たとえば、ＨＷ１，ＨＷ３をグループ分割する場合、ＨＷ１，ＨＷ３のデータ依存量ＤＥＰ（１，３）を評価すると、
ＤＥＰ（１，３）＝｜ＷＳ（１，３）｜＝｜（２０〜１２９）｜＝１１０
となる。

各ハードウェアモデルの組み合わせについてデータ依存量ＤＥＰ（ｍ，ｎ）を算出し、分割の場合には、昇順にソートし、融合の場合には降順にソートする。データ依存量ＤＥＰ（ｍ，ｎ）が小さいほど、分割に適しており、特に、ＤＥＰ（ｍ，ｎ）＝０については、分割により複数のブロック間のデータ依存が発生しないために、単純な分割をおこなってよい。また、データ依存量ＤＥＰ（ｍ，ｎ）が大きいほど、ＨＷｍがアクセスするＨＷｘとＨＷｎがアクセスするＨＷｙとは融合に適している。

たとえば、データ依存量ＤＥＰ（１，２）＝φの場合、
｛ＨＷ１｝，｛ＨＷ２，ＨＷ３，ＨＷ４｝
｛ＨＷ２｝，｛ＨＷ１，ＨＷ３，ＨＷ４｝
｛ＨＷ１，ＨＷ３｝，｛ＨＷ２，ＨＷ４｝
｛ＨＷ１｝，｛ＨＷ２｝，｛ＨＷ３，ＨＷ４｝
｛ＨＷ１｝，｛ＨＷ３｝，｛ＨＷ２，ＨＷ４｝
｛ＨＷ１｝，｛ＨＷ４｝，｛ＨＷ２，ＨＷ３｝
｛ＨＷ２｝，｛ＨＷ３｝，｛ＨＷ１，ＨＷ４｝
が、最も分割に適したグループ分けである。選択部６０６では、このようなＨＷｍとＨＷｎの組み合わせを順次選択することで、再構築部６０３が、選択されたＨＷｍとＨＷｎとをグループ分けするようなリストラクチャリングを実行することとなる。

算出部６１０は、コスト算出部６１１と帯域算出部６１２と消費電力算出部６１３とを備える。コスト算出部６１１は、記憶部６００に記憶されたテーブルを参照することにより、再構築後のアーキテクチャの物量コストを算出する機能を有する。具体的には、たとえば、該当するハードウェアの物量コストを物量コスト／消費電力テーブル３００から引く。メモリの場合は、メモリ価格／消費電力テーブル５００から物量コストを引く。

本例では、メモリは５０［Ｍｂ］を単位メモリサイズとしているため、再構築後のアーキテクチャにおいてメモリのサイズを直近の５０［Ｍｂ］の倍数に切り上げた後、メモリ価格／消費電力テーブル５００から物量コストを引く。たとえば、メモリサイズが１３０［Ｍｂ］の場合、１５０［Ｍｂ］とし、メモリ価格／消費電力テーブル５００から物量コストを引く。引かれた物量コストは、１０［＄］／５０［Ｍｂ］であるため、この場合の物量コストは、３０［＄］となる。

そして、各ハードウェアブロックの物量コストを合計することで、再構築後のアーキテクチャの物量コストが得られる。再構築後のアーキテクチャの物量コストは出力部６０４によって出力される。

帯域算出部６１２は、再構築後のアーキテクチャのバスの帯域をバスごとに算出する機能を有する。具体的には、たとえば、アーキテクチャを構成する分割グループごとに帯域を算出する。

図１３〜図２３は、再構築後のアーキテクチャを示すブロック構成図である。図中、ＨＷｚ＃（＃は番号）は、再構築後のメモリを示している。図９〜図１１、図１３〜図２３の分割または融合のアーキテクチャについて、楕円内の数値が、各ハードウェアブロックのメモリへのアクセスをあらわすデルタ関数の値であり、四角で囲われた数値が、そのデータ流量総量ＤＴとなる。

また、ＤＥＰ（ｍ，ｎ）≠０の場合は、分割したことにより依存関係にあるデータを転送するデータ転送が分割されたブロック間で発生する。すなわち、ＨＷｘが分割された場合、これらのデータはＨＷｘ上で共用していたデータであるため、ＤＥＰ（ｍ，ｎ）の新たなデータ流量が発生し、実装上の矛盾を解決する必要がある。

たとえば、図８に示したように、ＨＷｘへのバスのデータ量は分散される。分割前のＨＷｘへのアクセス総量は、
Σδ（ＨＷｎ，ＨＷｘ）＝１２０＋２０＋１３０＋１０＝２８０
となる。

一方、｛ＨＷ１，ＨＷ３｝，｛ＨＷ２，ＨＷ４｝の２つのグループに分けた場合、｛ＨＷ１，ＨＷ３｝のグループからのデータ総量は、ＨＷ１とＨＷ２の依存部分が新たに発生するデータ流量であるため、ＤＥＰ（１，２）を加味して、
Σδ（ＨＷｎ，ＨＷｘ）＋ＤＥＰ（１，２）＝（１２０＋１３０）＋１０＝２６０
となる。

また、ＨＷ２，ＨＷ４からのデータ総量は、
Σδ（ＨＷｎ，ＨＷｘ）＋ＤＥＰ（１，２）＝（２０＋２０）＋１０＝５０
となる。したがって、図９に示した再構築後のアーキテクチャについては、分割することによって、分割グループ９０１には２６０［Ｍｂｐｓ］、分割グループ９０２には５０［Ｍｂｐｓ］の帯域を持つバスを用意することになる。

このように、図９のほか、新たなデータ流量は、図１０、図１４〜図２３で発生している。図９、図１０、図１４〜図２３では、この新たなデータ流量を点線矢印で示すこととする。この新たなデータ流量ＤＥＰ（ｍ，ｎ）を加算することで、新たなデータ流量が発生した場合の実装上の矛盾を解決することができ、信頼性の高い帯域算出を実現することができる。

消費電力算出部６１３は、記憶部６００に記憶されたテーブルと帯域算出部６１２によって算出されたバスの帯域とに基づいて、再構築後のアーキテクチャの消費電力量を算出する機能を有する。具体的には、たとえば、該当するハードウェアの消費電力を物量コスト／消費電力テーブル３００から引く。メモリの場合は、メモリ価格／消費電力テーブル５００から消費電力コストを引く。

本例では、メモリは５０［Ｍｂ］を単位メモリサイズとしているため、再構築後のアーキテクチャにおいてメモリのサイズを直近の５０［Ｍｂ］の倍数に切り上げた後、メモリ価格／消費電力テーブル５００から消費電力を引く。たとえば、メモリサイズが１３０［Ｍｂ］の場合、１５０［Ｍｂ］とし、メモリ価格／消費電力テーブル５００から消費電力を引く。引かれた消費電力は、５０［＄］／５０［Ｍｂ］であるため、この場合の物量コストは、１５０［ｍＷ］となる。

また、図４のバスセッティング特性グラフ４００から、分割グループ９０１，９０２ごとにバスの消費電力を引く。分割グループ９０１のバスの帯域は２６０［Ｍｂｐｓ］であるため、分割グループ９０１のバスの消費電力は５０［ｍＶ］である。分割グループ９０２のバスの帯域は５０［Ｍｂｐｓ］であるため、分割グループ９０２のバスの消費電力は１０［ｍＶ］である。

図１２は、図８〜図１０の再構築前後のアーキテクチャの物量コスト／消費電力の比較表である。この比較表は出力部６０４から出力される。図８のアーキテクチャは、単一バスであるため、衝突による性能劣化が生じやすいことがわかる。図９の分割後のアーキテクチャは、分割によりバス上での衝突が回避され性能が出しやすいことがわかる。図１０の分割融合後のアーキテクチャでは、分割されているが、融合により図９と比べてグループ数が少ないため、バス上での衝突による性能劣化の可能性はやや高いことがわかる。

図２４は、図７に示したアーキテクチャ７００の分割または融合による再構築後のアーキテクチャの物量コストおよび消費電力を示す図表である。この図表もデータ化されて出力部６０４から出力される。図２４において、消費電力および物量コストともに最小となるアーキテクチャは、図１３に示した再構築後のアーキテクチャである。

（設計支援処理手順）
図２５および図２６は、本実施の形態にかかる設計支援処理手順を示すフローチャートである。図２５において、取得部６０１により、アーキテクチャと優先度／実装制約情報１０３を取得する（ステップＳ２５０１）。つぎに、判断部６０２により、同種のハードウェアブロックが複数あるか否かを判断する（ステップＳ２５０２）。

複数ある場合（ステップＳ２５０２：Ｙｅｓ）、そのハードウェアブロックを融合可能かつ分割可能なハードウェアブロックに決定する（ステップＳ２５０３）。一方、複数ない場合（ステップＳ２５０２：Ｎｏ）、融合不可能なハードウェアブロックに決定する（ステップＳ２５０４）。

また、取得部６０１により、ハードウェアブロック間におけるデータ依存情報を取得する（ステップＳ２５０５）。そして、判断部６０２により、共用リソースがあるか否かを判断する（ステップＳ２５０６）。共用リソースがある場合（ステップＳ２５０６：Ｙｅｓ）、その共用リソースを分割可能なハードウェアブロックに決定する（ステップＳ２５０７）。

一方、共用リソースでない場合（ステップＳ２５０６：Ｎｏ）、ステップＳ２５０３で分割可能と判断されたハードウェアブロックを除き、分割不可能なハードウェアブロックに決定する（ステップＳ２５０８）。そして、ステップＳ２５０９に移行する。

このあと、帯域算出部６１２による帯域算出処理（ステップＳ２５０９）、コスト算出部６１１による物量コスト算出処理（ステップＳ２５１０）、消費電力算出部６１３による消費電力算出処理（ステップＳ２５１１）を実行する。これにより、再構築前のアーキテクチャについての帯域、物量コスト、および消費電力を得ることができ、再構築後のアーキテクチャとの比較対象とすることができる。

図２６において、リストラクチャリングに先立って、データ依存量ＤＥＰ（ｍ，ｎ）を算出する（ステップＳ２６０１）。つぎに、決定部６０５により、再構築種を決定する（ステップＳ２６０２）。そして、分割または融合が可能なアーキテクチャであるか否かを判断する（ステップＳ２６０３）。不可能なアーキテクチャである場合（ステップＳ２６０３：Ｎｏ）、出力部６０４により、分割／融合不可出力をおこなう（ステップＳ２６０４）。これにより、一連の処理を終了する。

一方、分割／融合可能なアーキテクチャである場合（ステップＳ２６０３：Ｙｅｓ）、決定された再構築種を特定する（ステップＳ２６０５）。再構築種が「分割」である場合（ステップＳ２６０５：分割）、アーキテクチャに対して分割リストラクチャリング処理を実行する（ステップＳ２６０６）。そして、ステップＳ２６１０に移行する。また、再構築種が「融合」であった場合（ステップＳ２６０５：融合）、アーキテクチャに対して融合リストラクチャリング処理を実行する（ステップＳ２６０７）。そして、ステップＳ２６１０に移行する。

さらに、再構築種が「分割後の融合」である場合（ステップＳ２６０５：分割→融合）、アーキテクチャに対して分割リストラクチャリング処理を実行し（ステップＳ２６０８）、そのあと、分割リストラクチャリング後のアーキテクチャに対して融合リストラクチャリング処理を実行する（ステップＳ２６０９）。そして、ステップＳ２６１０に移行する。ステップＳ２６１０では、出力部６０４により、再構築後のアーキテクチャなどを含む最適化結果１１０を出力する（ステップＳ２６１０）。これにより、一連の処理を終了する。

図２７は、分割リストラクチャリング処理（ステップＳ２６０６（ステップＳ２６０８））の詳細な処理手順を示すフローチャートである。まず、データ依存量ＤＥＰ（ｍ，ｎ）を昇順にソートし（ステップＳ２７０１）、分割終了か否かを判断する（ステップＳ２７０２）。分割の終了基準としては、ＤＥＰ（ｍ，ｎ）≠０の出現、上位Ｎ番目までのＤＥＰ（ｍ，ｎ）に基づく分割リストラクチャリングの終了など、優先度／実装制約情報１０３により判断することができる。

分割終了でない場合（ステップＳ２７０２：Ｎｏ）、選択部６０６により、最上位のデータ依存量ＤＥＰ（ｍ，ｎ）を抽出して、ソートされたリストから削除しておく（ステップＳ２７０３）。そして、分割対象アーキテクチャに対して分割リストラクチャリングをおこなう（ステップＳ２７０４）。このあと、ステップＳ２５０９〜Ｓ２５１１と同様、帯域算出部６１２による帯域算出処理（ステップＳ２７０５）、コスト算出部６１１による物量コスト算出処理（ステップＳ２７０６）、消費電力算出部６１３による消費電力算出処理（ステップＳ２７０７）を実行する。

これにより、分割による再構築後のアーキテクチャについての帯域、物量コスト、および消費電力を得ることができる。そして、この再構築後のアーキテクチャや帯域、物量コスト、消費電力の算出結果を記憶部６００に保存しておく（ステップＳ２７０８）。そして、ステップＳ２７０２に戻る。ステップＳ２７０２において、分割終了となった場合（ステップＳ２７０２：Ｙｅｓ）、ステップＳ２６１０（またはステップＳ２６０９）に移行する。

図２８は、融合リストラクチャリング処理（ステップＳ２６０７（ステップＳ２６０９））の詳細な処理手順を示すフローチャートである。まず、データ依存量ＤＥＰ（ｍ，ｎ）を降順にソートし（ステップＳ２８０１）、融合終了か否かを判断する（ステップＳ２８０２）。融合の終了基準としては、ＤＥＰ（ｍ，ｎ）＝０の出現、上位Ｎ番目までのＤＥＰ（ｍ，ｎ）に基づく融合リストラクチャリングの終了など、実装制約情報１０３により判断することができる。

融合終了でない場合（ステップＳ２８０２：Ｎｏ）、選択部６０６により、最上位のデータ依存量ＤＥＰ（ｍ，ｎ）を抽出して、ソートされたリストから削除しておく（ステップＳ２８０３）。そして、融合対象アーキテクチャに対して融合リストラクチャリングをおこなう（ステップＳ２８０４）。このあと、ステップＳ２７０５〜Ｓ２７０７と同様、帯域算出部６１２による帯域算出処理（ステップＳ２８０５）、コスト算出部６１１による物量コスト算出処理（ステップＳ２８０６）、消費電力算出部６１３による消費電力算出処理（ステップＳ２８０７）を実行する。

これにより、融合による再構築後のアーキテクチャについての帯域、物量コスト、および消費電力を得ることができる。そして、この再構築後のアーキテクチャや帯域、物量コスト、消費電力の算出結果を記憶部６００に保存しておく（ステップＳ２８０８）。そして、ステップＳ２８０２に戻る。ステップＳ２８０２において、融合終了となった場合（ステップＳ２８０２：Ｙｅｓ）、ステップＳ２６１０に移行する。

以上説明したように、本実施の形態によれば、最適なアーキテクチャ構成を求めることにより、効率的かつ最適なアーキテクチャ設計を短期間で実現することができる。

なお、本実施の形態で説明した設計支援方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。またこのプログラムは、インターネット等のネットワークを介して配布することが可能な媒体であってもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）コンピュータを、
ソフトウェアを実行するハードウェアモデル群からなるアーキテクチャを取得する取得手段、
前記取得手段によって取得された前記アーキテクチャ内の前記ハードウェアモデルの分割または／および融合の可能性を判断する判断手段、
前記判断手段によって判断された判断結果に基づいて、前記アーキテクチャを再構築する再構築手段、
前記再構築手段による再構築後のアーキテクチャを出力する出力手段、
として機能させることを特徴とする設計支援プログラム。

（付記２）前記取得手段は、
前記アーキテクチャに前記ソフトウェアを実行させることにより、前記ハードウェアモデル間のデータ依存情報を取得し、
前記判断手段は、
前記取得手段によって取得された前記データ依存情報に基づいて、前記アーキテクチャ内の前記ハードウェアモデルの分割の可能性を判断することを特徴とする付記１に記載の設計支援プログラム。

（付記３）前記判断手段は、
前記アーキテクチャ内に存在する同種のハードウェアモデルの個数に基づいて、前記アーキテクチャ内の前記ハードウェアモデルの融合および分割の可能性を判断することを特徴とする付記１または２に記載の設計支援プログラム。

（付記４）前記コンピュータを、
前記アーキテクチャ内の前記ハードウェアモデルの分割、融合、または、分割後の融合の中から前記アーキテクチャに可能な再構築種を決定する決定手段として機能させ、
前記取得手段は、
前記アーキテクチャの性能、物量コスト、または消費電力に関する優先度を取得し、
前記決定手段は、
前記判断結果と前記取得手段によって取得された優先度とに基づいて、前記再構築種を決定し、
前記再構築手段は、
前記決定手段によって決定された再構築種に応じた再構築をおこなうことを特徴とする付記１〜３のいずれか一つに記載の設計支援プログラム。

（付記５）前記再構築手段は、
前記再構築種が分割を含む場合、前記アーキテクチャ内の複数の前記ハードウェアモデルが共通してアクセスする共通ハードウェアモデルを分割することにより、前記アーキテクチャを再構築することを特徴とする付記４に記載の設計支援プログラム。

（付記６）前記再構築手段は、
前記再構築種が融合である場合、前記アーキテクチャ内の複数の前記ハードウェアモデルがそれぞれアクセスする同種のハードウェアモデルを融合することにより、前記アーキテクチャを再構築することを特徴とする付記４に記載の設計支援プログラム。

（付記７）前記コンピュータを、
前記ハードウェアモデルの種別ごとの物量コストを有するテーブルを記憶する記憶手段、
前記記憶手段に記憶された前記テーブルを参照することにより、前記再構築後のアーキテクチャの物量コストを算出するコスト算出手段、として機能させ、
前記出力手段は、
前記コスト算出手段によって算出された算出結果を出力することを特徴とする付記１〜６のいずれか一つに記載の設計支援プログラム。

（付記８）前記コンピュータを、
前記ハードウェアモデルの種別ごとの消費電力量を有するテーブルを記憶する記憶手段、
前記再構築後のアーキテクチャのバスの帯域を算出する帯域算出手段、
前記記憶手段に記憶された前記テーブルと前記帯域算出手段によって算出されたバスの帯域とに基づいて、前記再構築後のアーキテクチャの消費電力量を算出する消費電力算出手段、として機能させ、
前記出力手段は、
前記消費電力算出手段によって算出された算出結果を出力することを特徴とする付記１〜７のいずれか一つに記載の設計支援プログラム。

（付記９）ソフトウェアを実行するハードウェアモデル群からなるアーキテクチャを取得する取得手段と、
前記取得手段によって取得された前記アーキテクチャ内の前記ハードウェアモデルの分割または／および融合の可能性を判断する判断手段と、
前記判断手段によって判断された判断結果に基づいて、前記アーキテクチャを再構築する再構築手段と、
前記再構築手段による再構築後のアーキテクチャを出力する出力手段と、
を備えることを特徴とする設計支援装置。

（付記１０）コンピュータが、
ソフトウェアを実行するハードウェアモデル群からなるアーキテクチャを取得する取得工程と、
前記取得工程によって取得された前記アーキテクチャ内の前記ハードウェアモデルの分割または／および融合の可能性を判断する判断工程と、
前記判断工程によって判断された判断結果に基づいて、前記アーキテクチャを再構築する再構築工程と、
前記再構築工程による再構築後のアーキテクチャを出力する出力工程と、
を実行することを特徴とする設計支援方法。

本実施の形態にかかる設計支援装置の概要を示す説明図である。 実施の形態にかかる設計支援装置のハードウェア構成を示すブロック図である。 物量コスト／消費電力テーブルを示す説明図である。 バスセッティング特性グラフを示す説明図である。 メモリ価格／消費電力テーブルを示す説明図である。 図１に示した最適化処理部の機能的構成を示すブロック図である。 設計対象のアーキテクチャの一例を示す説明図である。 図７に示したアーキテクチャのデータ依存関係を示すブロック構成図である。 図８に示したアーキテクチャの２：２分割による再構築後のアーキテクチャを示すブロック構成図である。 図９に示した２：２分割による再構築後のアーキテクチャにおける融合による再構築後のアーキテクチャを示すブロック構成図である。 図８に示したアーキテクチャの融合による再構築後のアーキテクチャを示すブロック構成図である。 図８〜図１０の再構築前後のアーキテクチャの物量コスト／消費電力の比較表である。 再構築後のアーキテクチャ（１：３）を示すブロック構成図（その１）である。 再構築後のアーキテクチャ（１：３）を示すブロック構成図（その２）である。 再構築後のアーキテクチャ（１：３）を示すブロック構成図（その３）である。 再構築後のアーキテクチャ（１：３）を示すブロック構成図（その４）である。 再構築後のアーキテクチャ（１：１：２）を示すブロック構成図（その１）である。 再構築後のアーキテクチャ（１：１：２）を示すブロック構成図（その２）である。 再構築後のアーキテクチャ（１：１：２）を示すブロック構成図（その３）である。 再構築後のアーキテクチャ（１：１：２）を示すブロック構成図（その４）である。 再構築後のアーキテクチャ（１：１：２）を示すブロック構成図（その５）である。 再構築後のアーキテクチャ（１：１：２）を示すブロック構成図（その６）である。 再構築後のアーキテクチャ（１：１：１：１）を示すブロック構成図である。 図７に示したアーキテクチャの分割または融合による再構築後のアーキテクチャの物量コストおよび消費電力を示す図表である。 本実施の形態にかかる設計支援処理手順を示すフローチャート（前半）である。 本実施の形態にかかる設計支援処理手順を示すフローチャート（後半）である。 分割リストラクチャリング処理（ステップＳ２６０６（ステップＳ２６０８））の詳細な処理手順を示すフローチャートである。 融合リストラクチャリング処理（ステップＳ２６０７（ステップＳ２６０９））の詳細な処理手順を示すフローチャートである。

符号の説明

１００ 設計支援装置
１０１ ソースコード群
１０２ 評価ソフトウェア
１０３ 優先度／実装制約情報
１０４ コード解析部
１０５ ブロック化ハードモデル群
１０６ ＥＳＬシミュレーション実行部
１０７ シミュレーション結果
１０８ データベース
１０９ 最適化処理部
１１０ 最適化結果
６００ 記憶部
６０１ 取得部
６０２ 判断部
６０３ 再構築部
６０４ 出力部
６０５ 決定部
６０６ 選択部
６１０ 算出部
６１１ コスト算出部
６１２ 帯域算出部
６１３ 消費電力算出部

Claims (5)

1. コンピュータを、
   ソフトウェアを実行するハードウェアモデル群からなるアーキテクチャを取得する取得手段、
   前記取得手段によって取得された前記アーキテクチャ内の前記ハードウェアモデルの分割または／および融合の可能性を全ての分割パターンについて判断する判断手段、
   前記判断手段によって判断された判断結果に基づいて、前記アーキテクチャを再構築する再構築手段、
   前記再構築手段による再構築後のアーキテクチャを出力する出力手段、
   として機能させることを特徴とする設計支援プログラム。
2. 前記取得手段は、
   前記アーキテクチャに前記ソフトウェアを実行させることにより、前記ハードウェアモデル間のデータ依存情報を取得し、
   前記判断手段は、
   前記取得手段によって取得された前記データ依存情報に基づいて、前記アーキテクチャ内の前記ハードウェアモデルの分割の可能性を判断することを特徴とする請求項１に記載の設計支援プログラム。
3. 前記判断手段は、
   前記アーキテクチャ内に存在する同種のハードウェアモデルの個数に基づいて、前記アーキテクチャ内の前記ハードウェアモデルの融合および分割の可能性を判断することを特徴とする請求項１または２に記載の設計支援プログラム。
4. ソフトウェアを実行するハードウェアモデル群からなるアーキテクチャを取得する取得手段と、
   前記取得手段によって取得された前記アーキテクチャ内の前記ハードウェアモデルの分割または／および融合の可能性を全ての分割パターンについて判断する判断手段と、
   前記判断手段によって判断された判断結果に基づいて、前記アーキテクチャを再構築する再構築手段と、
   前記再構築手段による再構築後のアーキテクチャを出力する出力手段と、
   を備えることを特徴とする設計支援装置。
5. コンピュータが、
   ソフトウェアを実行するハードウェアモデル群からなるアーキテクチャを取得する取得工程と、
   前記取得工程によって取得された前記アーキテクチャ内の前記ハードウェアモデルの分割または／および融合の可能性を全ての分割パターンについて判断する判断工程と、
   前記判断工程によって判断された判断結果に基づいて、前記アーキテクチャを再構築する再構築工程と、
   前記再構築工程による再構築後のアーキテクチャを出力する出力工程と、
   を実行することを特徴とする設計支援方法。

Images