JPH0916642A - データ処理装置のアーキテクチャ評価方法 - Google Patents

Abstract

(57)【要約】 【構成】 データ処理装置のシステム分割工程で設計さ
れたハードウエア構成を評価対象として入力する。デー
タ処理の要求仕様として与えられたアプリケーションプ
ログラムを設定する。アプリケーションプログラムを分
枝の発生が回避されたプログラム部分である各基本ブロ
ックまで分割する。ハードウエア構成の各構成が最大限
並列に動作できるように各構成をデータ転送経路を考慮
してスケジューリングして上記各基本ブロックの処理ス
テップ数をそれぞれ算出する。要求仕様に対応した入力
データを用いてハードウエア構成の動作をシミュレート
して、各基本ブロックの実行数をそれぞれ算出し、各処
理ステップ数と上記実行数とからハードウエア構成を評
価する。 【効果】 アーキテクチャ設計の初期段階にてハードウ
エア構成をより正確に評価できるので、アーキテクチャ
設計の最適化を迅速化できる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、要求仕様に応じたアー
キテクチャ設計の最適化を迅速にできるデータ処理装置
のアーキテクチャ評価方法に関するものである。

【０００２】

【従来の技術】一般に、データ処理装置は、汎用マイク
ロプロセッサや組み込み型専用プロセッサ等のＬＳＩの
ように、幾つかの演算装置、記憶装置とそれらを接続す
る転送経路で構成され、それらはデータ処理装置の外部
もしくは内部の制御装置によって制御されている。

【０００３】このようなデータ処理装置では、処理のデ
ータの流れにしたがって演算装置や記憶装置を転送経路
でハードウエア的に接続すれば単純な制御で目的のデー
タ処理を行うデータ処理装置は構成できるが、データ処
理が複雑化するにしたがって処理と同程度の複雑さを有
するハードウエアが必要になり、ハードウエア量が膨大
になる。

【０００４】プログラム制御方式では、目的とするデー
タ処理をより小さい処理（基本処理）に部品化して、部
品の組み合わせで処理を実現する。基本処理をそれぞれ
演算装置、記憶装置、転送経路といったハードウエアで
実現し、基本処理をどのような順序で組み合わせてデー
タ処理を行うかをデータ処理プログラムとしてのソフト
ウエアにて実現する（図１３参照）。

【０００５】通常、データ処理プログラムはコンパイラ
によって基本処理を用いた手順に変換され、各基本処理
を実行する命令で記述されたプログラム（オブジェクト
プログラム）になる。データ処理装置は手順にしたがっ
て演算装置や転送経路を制御することでデータ転送や演
算などの種々のデータ処理を行い、目的のデータ処理を
実現する。プログラム制御方式を用いることで、複雑な
データ処理を小さなハードウエアで実現することが可能
となる。

【０００６】このようなデータ処理装置の設計では、通
常、どのようなデータ処理をどのような処理速度で行う
かという要求仕様に基づいて図１０に示す設計手順にし
たがって装置設計が行われる。

【０００７】プログラム制御方式のデータ処理システム
では、要求仕様として与えられるデータ処理を、演算装
置、記憶装置、転送経路、制御装置などから構成される
ハードウエアと、そのハードウエアを制御するためのソ
フトウエアの組み合わせで実現する。ハードウエアとソ
フトウエアとは設計手法が大きく異なるため、通常、設
計の最初の段階にてシステム分割工程で分割され、それ
ぞれに対し詳細設計が行われる。

【０００８】この設計手順において、最初にシステムの
大まかな構成や実現方式を決定するのが、アーキテクチ
ャ設計である。アーキテクチャ設計工程では、システム
をどのようなハードウエア上でどのようなデータ処理プ
ログラムを用いて実現するかを設計する。そのため、以
下の手順で設計が進められる。

【０００９】（ａ）システム分割 データ処理装置をハードウエアで実現する部分とソフト
ウエアで実現する部分に分割する。プログラム制御方式
では、目的とするデータ処理をどのような基本処理の集
合に部品化するかを決定することで、データ処理装置を
どのようなハードウエアとソフトウエアとで実現するか
が決定される。基本処理の選択はすなわち、どのような
処理の部品を用いてデータ処理を実現するかを決定する
ことであり、それぞれの基本処理を実現するハードウエ
アを選択することである。

【００１０】このとき、基本処理として複雑な処理を選
べば、ハードウエアのコストは増加するが、複雑な処理
を１回で行うことができるので、ソフトウエアの実行ス
テップ数は減少し、処理性能は向上する。

【００１１】反対に基本処理として簡単な処理を選べ
ば、ハードウエアのコストは減少するが、多くの実行ス
テップ数が必要になり、性能は劣化する。したがって、
基本処理の選択は、データ処理の効率やハードウエア量
などのコストに大きな影響を与える重要な設計項目であ
る。

【００１２】ハードウエアの実現部分は、基本処理を実
現する演算装置や記憶装置と転送経路をどのような構成
に設定するかというハードウエア構成が仕様として決定
される。このレベルのハードウエア仕様では、演算装置
や記憶装置などの接続関係は、すでに設計されているが
レジスタ数などについては後に決定されることが多い。
一方、ソフトウエアの実現部分は、基本処理をどのよう
な手順で組み合わされて処理を実現するかがソフトウエ
ア仕様として設定される。

【００１３】（ｂ）ハードウエア設計 ハードウエア設計では、システム分割で決定されたハー
ドウエア仕様に対し、その制御をどのような仕組みで行
うかや、レジスタ数や記憶装置の容量などの詳細な設計
項目が決定される。また、この設計項目の重要な項目と
して命令セット設計が行われる。

【００１４】命令セットは、ハードウエア仕様として決
定したハードウエア構成の各要素を制御してデータ処理
を行うための様々な命令の集まりとして決定される。命
令セットは理想的にはハードウエアの各部が完全に並列
に制御できればハードウエアの能力を最大限に発揮させ
ることができるが、命令語長などの制限のため通常は命
令セットの設計において並列性に制限が加わる（図１４
参照）。

【００１５】図１４の例では、図１３に示すハードウエ
ア構成に対して、２つの形式の命令形式が与えられてい
る。ハードウエアを構成する要素は本来は並列に制御可
能である。（命令形式１）の命令セットでは演算装置１
・２、記憶装置１・２の制御には別々のフィールドが割
り当てられているため、並列に制御可能である。

【００１６】しかし、（命令形式２）の命令セットでは
命令語長を短くするため、演算装置、記憶装置の制御フ
ィールドが共有され、２つの演算装置１・２、記憶装置
１・２を並列に制御できない。このように同じハードウ
エア構成でも命令セット設計により並列実行度に差が生
じてくる。

【００１７】命令セット設計で命令セットの形状が決定
され、命令を解釈実行するためのハードウエア部分が設
計される。また、設計された命令セットはソフトウエア
設計側で利用するためにコンパイラ工程に渡される。ハ
ードウエアとして実現される部分は通常はハードウエア
記述言語で出力され、後の詳細設計に用いられる。

【００１８】（ｃ）ソフトウエア設計 ソフトウエア実現部分のアーキテクチャは、ソフトウエ
ア仕様からデータ処理プログラムとして実現される。こ
れは後の設計工程でハードウエア側で設計された命令セ
ットを用いたオブジェクトプログラムに変換される。オ
ブジェクトプログラムの生成は通常命令セットやハード
ウエアの情報をもとにコンパイラが設計され、それによ
って行われる。

【００１９】次に、上記データ処理装置のアーキテクチ
ャの評価方法について説明する。データ処理装置は、そ
の処理性能や必要なコストで評価される。性能は要求さ
れたデータ処理を要求された時間内に実行できる（ある
いはどれだけ速く実行できるか）の評価である。コスト
はデータ処理装置のハードウエア量や消費電力等で表さ
れる。

【００２０】アーキテクチャ設計工程ではシステムの基
本的な構成や実現方式が決定されるために、設計結果が
後の設計に大きな影響を与える。したがって、データ処
理装置の設計においてアーキテクチャ設計の最適化は重
要である。そのためには、アーキテクチャ設計工程で設
計したアーキテクチャを評価して、その結果をフィード
バックする必要がある。

【００２１】プログラム制御方式のデータ処理装置の場
合、アーキテクチャ設計工程では（ａ）システム分割、
（ｂ）ハードウエア設計、（ｃ）ソフトウエア設計が行
われる。システム分割工程において、基本処理を選択す
ることでハードウエア実現部分とソフトウエア実現部分
との切り分けが行われる。基本処理の選択によるハード
ウエア実現部分とソフトウエア実現部分との分割は最終
的な性能やコストに与える影響が大きい。アーキテクチ
ャの最適化を行うためには、システム分割が妥当である
か否かを評価して最適化することが非常に重要である。

【００２２】また、設計最適化のためには評価を設計の
各工程で行って、それを設計にフィードバックさせる必
要がある。各工程における評価が別々にできない場合に
は、複数の設計工程における設計の善し悪しの判断や、
要求仕様を満足しなかった場合にどの設計工程に原因が
あるかというボトルネックの解析が困難になる。また、
評価結果が不良の場合に生じる設計の後戻りが大きくな
り、設計期間の長期化を招くことになる。

【００２３】例えば、システム分割段階で本来必要な性
能に不足するハードウエア仕様を選択した場合には、命
令セットの設計をどのようにしても性能の不足を補うこ
とはできない。このような場合にはシステム分割段階で
選択したハードウエア構成を評価して、それが悪いとい
う評価ができれば、この段階でシステム分割を最適化可
能である。

【００２４】しかし、もし、これらの２つの段階を別々
に評価できず、アーキテクチャ設計後の評価で初めて要
求性能を満たしていないことが判明した場合に、システ
ム分割と命令セット設計の双方が評価結果に影響を及ぼ
すため、どちらの設計が原因なのかというボトルネック
が判別できない。

【００２５】このため、システム分割工程の設計が原因
であっても設計を最適化しようとして命令セットの最適
化を何度も繰り返し試みる結果となる可能性もあり、た
とえシステム分割の変更により最適化しても設計の後戻
りが大きくなり、設計が完了するまでの時間が長くな
る。

【００２６】したがって、アーキテクチャ設計を最適化
するためには、アーキテクチャ終了段階だけではなく、
システム分割工程以降の各工程でアーキテクチャを評価
することが必要であるという問題が存在する。しかし、
次の従来手法の節でも述べる通り、システム分割工程の
終了段階で確実にアーキテクチャ評価が行えるシステム
は今まで存在していない。

【００２７】次に、アーキテクチャ評価の従来手法につ
いて説明する。従来、アーキテクチャ設計を最適化する
ために、アーキテクチャの評価を行う手法がいくつか提
案されている。

【００２８】赤星ら（ＤＡシンポジウム、1993年）は、
アーキテクチャの評価を行う手法として評価システム
“ＣＯＡＣＨ”を提案している。上記評価システムで
は、評価部において命令セット（ハードウエアを制御す
るための命令の集合）を含むアーキテクチャ情報を与え
てコンパイラを生成し、データ処理の要求仕様であるア
プリケーションプログラムをオブジェクトコードプログ
ラムにコンパイルして実際のデータ処理を命令レベルで
実行し、処理ステップ数を求めることでアーキテクチャ
の評価を行っている。

【００２９】また、システムのハードウエア／ソフトウ
エア協調設計の研究分野では、最適なハードウエアとソ
フトウエアの分割を求めるためにアーキテクチャの性能
やコスト評価を行っているシステムとして、「ＡＳＩＰ
向きハードウエア／ソフトウエア・コデザインシステム
ＰＥＡＳ−１におけるハードウエア生成手法」（信学技
報ＶＬＤ93-93 ）や特開平5-216957号公報に開示された
「回路設計方式」で提案されたシステムを挙げることが
できる。

【００３０】これらのシステムにおけるアーキテクチャ
評価は、設計された命令セットを評価対象として評価用
コンパイラを用いてアプリケーションプログラムから完
全なオブジェクトプログラムを生成することで行うため
（図１５参照）、アーキテクチャ設計が完全に終了し、
図１０の左矢印Ｂにて示す命令セット設計まで終わった
段階において、アーキテクチャの評価を行っている。

【００３１】

【発明が解決しようとする課題】ところが、上記従来の
各手法では、1)命令セットを評価対象としているため、
システム分割設計の妥当性を評価できないこと、2)アー
キテクチャを実際にはオブジェクトプログラム設計まで
終了した後に評価しているため、評価結果にはオブジェ
クトプログラムを生成するための評価用コンパイラの品
質が大きく影響し、アーキテクチャ自身を評価できない
可能性があること、3)アーキテクチャ設計が完了する段
階まで評価が行えず、ボトルネック解析等に時間がかか
り、アーキテクチャ設計の最適化に手間取ることがある
という問題を生じている。

【００３２】本発明の目的は、アーキテクチャ設計が完
了してから評価を行うのではなく、システム分割直後か
らの各アーキテクチャ設計レベルで評価できる方法、つ
まりシステム分割段階以降の各工程の設計結果を別々に
評価可能なデータ処理装置のアーキテクチャ評価方法を
提供することにある。

【００３３】

【課題を解決するための手段】本発明の請求項１記載の
データ処理装置のアーキテクチャ評価方法は、以上の課
題を解決するために、システム分割工程で決定された演
算装置、記憶装置およびそれらを用いてデータ処理する
ためのデータ転送経路とからなるハードウエア構成をス
テップ数解析のためにモデル化する第１ステップと、デ
ータ処理の要求仕様として与えられるアプリケーション
プログラムを、分枝の発生が回避されたプログラム部分
である各基本ブロックまで分割する第２ステップと、ハ
ードウエア構成の各構成が最大限並列に動作できるよう
に上記各基本ブロックをデータ転送経路を考慮してスケ
ジューリングして上記各基本ブロックの処理ステップ数
をそれぞれ算出する第３ステップと、要求仕様に対応し
た典型的な入力データを用いて上記ハードウエア構成の
動作をシュミレートして、上記各基本ブロックの実行数
をそれぞれ算出する第４ステップと、上記各処理ステッ
プ数と上記実行数とからハードウエア構成を評価する第
５ステップとを含むことを特徴としている。

【００３４】本発明の請求項２記載のデータ処理装置の
アーキテクチャ評価方法は、請求項１記載のデータ処理
装置のアーキテクチャ評価方法において、さらに、第１
ステップでは、ハードウエア構成に制御装置設計や命令
セット設計の影響などによる並列化不可能な演算や転
送、制御の組み合わせを並列制約情報として付加し、第
３ステップでは、上記並列制約情報も考慮してスケジュ
ーリングすることを特徴としている。

【００３５】

【作用】上記請求項１記載の方法によれば、データ処理
の要求仕様として与えられるアプリケーションプログラ
ムを、分枝の発生が回避されたプログラム部分である各
基本ブロックまで分割することと、ハードウエア構成の
各構成が最大限並列に動作できるように上記各基本ブロ
ックをデータ転送経路も考慮してスケジューリングする
こととにより、上記各基本ブロックの処理ステップ数を
それぞれ算出することができることから、上記ハードウ
エア構成を、上記各処理ステップ数と、シュミレートに
よる各基本ブロックでの実行数とから評価できる。

【００３６】このことから、上記方法では、ハードウエ
ア構成の各構成が最大限並列に動作できるようにスケジ
ューリングすることにより、上記ハードウエア構成を評
価できるので、システム分割が終了してハードウエア構
成が決定した段階にて、上記ハードウエア構成の評価を
行うことができる。

【００３７】上記請求項２記載の方法によれば、さら
に、ハードウエア構成に対し制御装置や命令セットによ
る並列制約情報を加えてハードウエア構成を評価するこ
とにより、システム分割によるハードウエア構成を予め
最適化しておけば、制御装置設計や命令セット設計によ
るアーキテクチャ評価に対する影響のみを考慮可能であ
るので、上記制御装置や命令セットの評価を正確に行う
ことができる。

【００３８】

【実施例】本発明の一実施例について図１ないし図１
２、および図１５に基づいて説明すれば、以下の通りで
ある。データ処理装置のアーキテクチャ評価方法では、
要求仕様に応じたシステム分割工程の結果として、図２
に示すように、まず、複数の演算装置であるＭＵＬＴ
１、ＡＬＵ２や、複数の記憶装置であるＲＡＭ３、ＲＯ
Ｍ４や、それらを互いに接続するデータ転送経路５から
なるハードウエア構成が設定される。

【００３９】このようなハードウエア構成を、評価のた
めのコンピュータに入力できるように記述形式に書き換
えて上記コンピュータに入力する。続いて、データ処理
の要求仕様をプログラム形式で記述したアプリケーショ
ンプログラムを上記コンピュータに入力する。

【００４０】そして、上記方法では、図１に示すよう
に、下記の各ステップを含むことを特徴としている。ま
ず、ステップｉとして、データ処理の要求仕様として与
えられるアプリケーションプログラムを、分枝の発生が
回避されたプログラム部分である各基本ブロックまで分
割する。

【００４１】ステップiiとして、システム分割工程直後
の評価の場合にはアーキテクチャ設計のシステム分割工
程で設計される情報のみを用いて、また、ハードウエア
設計工程以降の評価では制御装置設計や命令セット設計
の影響を加味するための並列制約情報をさらに加えて、
ハードウエア構成の各構成が最大限並列に動作できるよ
うに簡易化したモデルを想定する。なお、ステップｉお
よびステップiiは、それらの作業の手順を互いに前後し
てもよく、また、同時に進行させてもよい。

【００４２】ステップiii として、上記各基本ブロック
をデータ転送経路も考慮してスケジューリングすること
により上記各基本ブロックの処理ステップ数をそれぞれ
算出する。

【００４３】ステップivとして、要求仕様に対応した典
型的な入力データを用いて上記ハードウエア構成の動作
をシミュレートして、上記各基本ブロックにおける繰り
返し実行される実行数をそれぞれ算出する。ステップｖ
として、上記各処理ステップ数と上記各実行数とからハ
ードウエア構成を評価する。

【００４４】上記簡易化したモデルは下記の各条件にし
たがって設定される。a) 全ての演算装置であるＭＵＬ
Ｔ１、ＡＬＵ２は並列に動作可能とする。b) 全ての記
憶装置であるＲＡＭ３、ＲＯＭ４は独立なアドレス空間
を有し、同時アクセス可能とする。

【００４５】c) 汎用レジスタとしてハードウエア構成
には現れないレジスタファイルの存在を仮定し、どこか
らでもアクセス可能とする（データ処理の中間変数の格
納に用いる）。ただし、レジスタファイルの同時アクセ
ス数には制限を有することとする。d) 各ハードウエア
装置間を接続する転送経路５は同時には高々１つのデー
タのみ転送するように設定される。

【００４６】そのハードウエア構成のグラフによるモデ
ル化は、リソースになるＭＵＬＴ１、ＡＬＵ２、ＲＡＭ
３、ＲＯＭ４、および転送経路５のうち複数データの衝
突の可能性を考慮する必要がある部分（バスやマルチプ
レクサ等）を頂点に対応させ、それらの間の転送経路５
を有向辺にて対応させる。図２のハードウエアの構成の
場合、例えば図３のグラフとしてモデル化される。

【００４７】また、ハードウエア構成が原因で生じる並
列実行の規約以外の理由による並列実行の制約、例えば
制御装置設計または命令セット設計が完了している場
合、必要に応じてハードウエア構成の並列制約情報を付
加する。この並列制約情報の付加により、例えば命令セ
ット設計による並列実行の制約付加をモデル化すること
ができる。

【００４８】図２に示すハードウエア構成の場合、ハー
ドウエア構成の並列制約情報として、例えば以下の制約
が考えられる。

【００４９】 演算−演算間制約の例 ＡＬＵ（ＡＤＤ）とＭＵＬＴ 演算−転送間制約の例 ＡＬＵとＲＡＭ→Ａ 転送−転送間制約の例 ＲＡＭ→ＸとＲＯＭ→Ｙ 上記方法では、並列動作できない演算や転送の組を制約
としてリストに保持し、静的解析における各動作のスケ
ジューリングにおいてリソース制約に加えて考慮する。
以下の説明では簡略化のため、付加されるハードウエア
並列実行の制約情報はないものとして説明を進める。

【００５０】次に、転送経路５におけるデータ転送手順
の抽出について説明すると、最初に、ＲＡＭ３、ＲＯＭ
４間のデータの転送経路５を各ペア毎に抽出する。ハー
ドウエア構成のグラフの最短経路問題を解くことによっ
て、出力記憶装置−入力記憶装置間の有向道を各ペアに
ついて求める。抽出された経路を用いて演算時の入出力
データは転送されるとする。図２のハードウエア構成の
場合では、例えば以下のデータ転送手順が抽出される。
ただし、ＭＵＬＴ１、ＡＬＵ２を通る経路は考慮しな
い。

【００５１】Ｐ→Ａ：Ｐ→ＢＵＳ→Ａ Ｐ→Ｂ：Ｐ→ＢＵＳ→Ｂ Ｐ→ＲＡＭ：Ｐ→ＢＵＳ→ＲＡＭ Ｃ→Ａ：Ｃ→ＢＵＳ→Ａ Ｃ→Ｂ：Ｃ→ＢＵＳ→Ｂ Ｃ→ＲＡＭ：Ｃ→ＢＵＳ→ＲＡＭ ＲＡＭ→Ａ：ＲＡＭ→ＢＵＳ→Ａ ＲＡＭ→Ｂ：ＲＡＭ→ＢＵＳ→Ｂ ＲＡＭ→Ｘ：ＲＡＭ→ＢＵＳ→Ｘ ＲＯＭ→Ｙ：ＲＯＭ→ＢＵＳ→Ｙ 続いて、アプリケーションプログラムから基本ブロック
の抽出について説明すると、アプリケーションプログラ
ムを基本ブロック（基本分枝のない部分）に分割して各
基本ブロックに対してＤＦＧ（データフローグラフ、Da
ta Flow Graph)を作成する。

【００５２】図４に簡単なアプリケーションプログラム
と基本ブロックの関係を示す。基本ブロックはアプリケ
ーションプログラムの構文解析を行ってif文や for文な
どの分枝制御ごとに分割することによって抽出すること
ができる。図４のプログラムでは、５個の基本ブロック
が抽出されている。

【００５３】このような基本ブロックの例として、高速
フーリエ変換のＦＦＴプログラムにおける１つの基本ブ
ロックを下記に示す。下記基本ブロックに対して作成さ
れたＤＦＧの例を図５に示した。以降ではこの基本ブロ
ックの例を元にしてプログラム静的解析を行う様子を実
施例として示す。

【００５４】 ｘ_j ⁺ ＝ｘ_i ＋（ｘ_j ×cos −ｙ_j ×sin) ｙ_j ⁺ ＝ｙ_i ＋（ｙ_j ×cos ＋ｘ_j ×sin) ｘ_i ⁺ ＝ｘ_j −（ｘ_j ×cos −ｙ_j ×sin) ｙ_i ⁺ ＝ｙ_j −（ｙ_j ×cos ＋ｘ_j ×sin) 次に、プログラム静的解析として、下記の各処理によ
り、各ＤＦＧに対してハードウエア構成における転送経
路５による制約を考慮したスケジューリングを行い、ア
プリケーションプログラムにおける各基本ブロックに対
する予想実行ステップ数を求める。

【００５５】１．ハードウエア構成において各演算を実
行する演算装置に入出力レジスタが存在する場合、入出
力レジスタへの転送をＤＦＧの一つの頂点として追加す
る（図６参照）。本実施例では乗算の前後にＭＵＬＴの
入出力レジスタであるＸ，Ｙ，Ｐレジスタ、ＡＬＵの前
後にＡＬＵの入出力レジスタＡ，Ｂ，Ｃレジスタへの転
送がそれぞれ頂点として追加されている。ただし、本実
施例では、変数ｘ，ｙ等はＲＡＭに格納し、定数sin, c
osはＲＯＭに格納されているものとしている。

【００５６】２．追加したレジスタ等の記憶装置間のデ
ータ転送を考慮するために、データ転送に必要な転送を
データ転送手順にしたがって追加する（図７参照）。例
では、ＭＵＬＴの出力レジスタＰからＡＬＵの入力レジ
スタＡ，Ｂへのデータ転送には少なくとも１度、転送経
路５としてのＢＵＳを経由する必要があるので、ＢＵＳ
への転送を示す頂点が追加されている。また、他の箇所
でも同様にＢＵＳを経由するための転送手順が追加され
ている。

【００５７】３．スケジューリングを行って実行ステッ
プ数を求める。スケジューリングではＭＵＬＴ、ＡＬＵ
やＢＵＳをリソース制約として考慮した並列制約を加
え、ステップ数ができる限り少なくなるように演算や転
送を行う時刻を決定する。

【００５８】ハードウエア構成上の本来のデータ処理で
は、計算途中の中間変数を記憶装置上に格納する必要が
生じるため、本来はその転送も考慮する必要が生じる。
しかし、汎用レジスタの構成などの設計が行われていな
い段階では、何らかのモデル化を行って処理を行う。モ
デル化は設計が進むに従って実際に近いものに順次置き
換えられれば、ハードウエア構成のより正確な評価が行
える。

【００５９】本実施例では、汎用レジスタのアクセス遅
延は無視するというモデル化を行う。このモデル化は、
どこからでも同時に瞬時にアクセス可能な無限の容量を
有する１つの大きな汎用レジスタが存在すると仮定する
モデル化である。スケジューリングの結果を図８に示
す。本実施例では、上記結果は、図８における各ステッ
プを示す引出し線の各数字にて示すように、１９ステッ
プで完了している。

【００６０】さらに、プログラム動的解析について説明
すると、入力データを用いてアプリケーションプログラ
ムを実行し、各基本ブロックについてそれぞれの実行回
数を求める。本実施例における図４に示した例での、各
基本ブロックにおける実行の結果を図９に、右矢印
（→）の左側にそれぞれ示した。

【００６１】続いて、プログラム動的解析における実行
ステップ数の算出について説明すると、プログラム静的
解析部による各基本ブロックの実行ステップ数と、プロ
グラム動的解析部による実行回数から以下の計算式で実
行ステップ数を算出する。

【００６２】基本ブロック数をｎとして、各基本ブロッ
クＢ_i （１≦ｉ≦ｎ）における動的解析結果による基本
ブロック実行数Ｘ_i 、静的解析のスケジュール結果によ
る実行ステップ数Ｓ_i とすると、全実行ステップ数Ｔは
以下の式で表される。

【００６３】

【数１】

【００６４】図４のアプリケーションプログラムにおい
て、基本ブロック５の処理が図４に示したプログラムの
処理であり、その他の基本ブロックに対する実行回数と
予測実行ステップ数が表１で示される値である場合に
は、全体の実行ステップ数は3458ステップであると算出
される。

【００６５】

【表１】

【００６６】最後に、解析結果出力部では、要求仕様に
応じてそれぞれ設定された各ハードウエア構成の各解析
結果と、それらを元にした情報の提示、解析結果から推
測される事項を元にした、例えばＭＵＬＴ１の使用率が
極度に小さいといった設計ガイダンスとを提示する。

【００６７】このように本発明の評価方法によれば、図
１０に示すデータ処理装置の設計の各工程において、ア
ーキテクチャ設計のシステム分割の設計段階（左矢印
Ａ）、命令セット設計等のハードウエア設計段階（左矢
印Ｂ）にて、設計したアーキテクチャをそれぞれ評価す
ることが可能になる。

【００６８】したがって、上記方法では、図１１にも示
すように、各設計段階での各評価に基づいて、アーキテ
クチャ設計のボトルネックがシステム分割にあるのか、
命令セット設計などのハードウエア設計にあるのか判別
することが可能になる。これにより、それぞれの個々の
アーキテクチャ設計の最適化が可能になる。

【００６９】また、図１２に示すように、従来生じてい
た個々の工程での最適化による設計の後戻りも、本願発
明では小さくできるので、データ処理装置の設計の最適
化を迅速化できる。

【００７０】本発明の評価法の結果を用いて、アーキテ
クチャ設計者はアーキテクチャを変更し、性能やコスト
の変化を観察することでアーキテクチャを改良すること
ができる。これによって、アーキテクチャ設計の各設計
段階を最適化し、ハードウエアやソフトウエアの詳細設
計工程に進む前に最適なシステムアーキテクチャの設計
を可能にする。したがって、本発明の評価法は、高速な
データ処理が可能となるデータ処理装置の最適化を確実
に行うことができ、かつ、迅速化できるものとなってい
る。

【００７１】また、上記方法では、従来手法と比較して
以下の利点も有する。

【００７２】1) 図１５に示すようにオブジェクトプロ
グラムを生成して評価する従来手法に比べ、コンパイラ
の影響がないため、アーキテクチャ設計そのものの評価
が可能である。

【００７３】2) アーキテクチャ設計の途中段階から評
価を行うことができるため、設計の速い段階から利用で
きる。

【００７４】3) コンパイラによるオブジェクトプログ
ラムの生成を省くことができるので、複雑なアーキテク
チャでも高速に評価できる。

【００７５】

【発明の効果】本発明の請求項１記載のデータ処理装置
のアーキテクチャ評価方法は、以上のように、システム
分割によって設定されたハードウエア構成が最大限並列
に動作できるように、アプリケーションプログラムにお
ける分枝の発生が回避されたプログラム部分である各基
本ブロックをデータ転送経路を考慮してスケジューリン
グすることにより上記各基本ブロックの処理ステップ数
をそれぞれ算出し、かつ、要求仕様に対応した典型的な
入力データを用いて上記ハードウエア構成の動作をシミ
ュレートして、上記各基本ブロックの実行数をそれぞれ
算出することにより、上記各処理ステップ数と上記各実
行数とからハードウエア構成を評価する方法である。

【００７６】それゆえ、上記方法は、要求仕様に応じた
システム分割によってハードウエア構成およびそれに準
じてデータ処理プログラムが設計され、ハードウエア構
成の各構成が最大限並列に動作できるようにスケジュー
リングすることにより上記ハードウエア構成を評価でき
るので、ハードウエア構成が得られた段階にて、上記ハ
ードウエア構成の評価を行うことができる。

【００７７】このため、上記方法では、命令セット設計
によるアーキテクチャ評価への影響や、従来のようなコ
ンパイラの影響を排除したアーキテクチャ評価を、シス
テム分割を行った段階にて可能となるので、ハードウエ
ア構成の最適化を迅速化できることから、得られるデー
タ処理装置の最適化の手間を軽減できるという効果を奏
する。

【００７８】本発明の請求項２記載のデータ処理装置の
アーキテクチャ評価方法は、請求項１記載のデータ処理
装置のアーキテクチャ評価方法において、さらに、ハー
ドウエア構成に制御装置設計や命令セット設計による並
列化不可能な演算や転送、制御の組み合わせを並列制約
情報として付加し、続いて、上記並列制約情報も考慮し
てスケジューリングする方法である。

【００７９】それゆえ、上記方法は、さらに、ハードウ
エア構成に対し命令セットによる並列制約情報を加えて
ハードウエア構成を評価することにより、例えば制御装
置設計や命令セット設計によるアーキテクチャ評価に対
する影響が考慮可能であるので、システム分割を予め評
価しておけば上記命令セット等の評価も正確に行うこと
ができる。

【００８０】そのため、上記方法では、アーキテクチャ
設計の各設計段階におけるアーキテクチャ評価がそれぞ
れ正確に可能となるので、アーキテクチャ設計工程にお
けるそれぞれの工程の最適化が、各段階での各評価結果
をフィードバックすることでそれぞれ可能になるので、
得られるデータ処理装置の最適化の手間をさらに軽減で
きるという効果を奏する。

【図面の簡単な説明】

【図１】本発明のデータ処理装置のアーキテクチャ評価
方法の手順を示すフローチャートである。

【図２】上記データ処理装置のハードウエア構成のブロ
ック図である。

【図３】上記ハードウエア構成のデータの流れを示す概
略図である。

【図４】上記データ処理装置に対するアプリケーション
プログラムの例を示す説明図である。

【図５】上記アプリケーションプログラムに対応するデ
ータフローグラフを示す説明図である。

【図６】上記データフローグラフに対し、上記ハードウ
エア構成における入出力レジスタをさらに考慮した他の
データフローグラフを示す説明図である。

【図７】上記の他のデータフローグラフに対し、上記ハ
ードウエア構成における転送経路であるＢＵＳを考慮し
たさらに他のデータフローグラフを示す説明図である。

【図８】上記のさらに他のデータフローグラフに対し、
スケジューリングを行った結果を示す説明図である。

【図９】上記アプリケーションプログラムのプログラム
動的解析結果を示す説明図である。

【図１０】上記データ処理装置の設計手順を示すフロー
チャートである。

【図１１】上記アーキテクチャ評価方法の効果を示す説
明図である。

【図１２】従来のアーキテクチャ評価方法を示す説明図
である。

【図１３】従来のプログラム制御方式のデータ処理装置
の説明図である。

【図１４】上記データ処理装置における命令セットの並
列性を示す説明図である。

【図１５】上記データ処理装置のアーキテクチャ評価の
手順を示すフローチャートであり、従来方法における評
価段階と、本願発明の方法における評価段階を示すもの
である。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 庁内整理番号 ＦＩ 技術表示箇所 Ｇ０６Ｆ 15/60 ６７２Ｚ

Claims (2)

【特許請求の範囲】
1. 【請求項１】システム分割工程で決定された演算装置、
   記憶装置およびそれらを用いてデータ処理するためのデ
   ータ転送経路とからなるハードウエア構成を、ステップ
   数解析のためにモデル化する第１ステップと、 データ処理の要求仕様であるアプリケーションプログラ
   ムを、分枝の発生が回避されたプログラム部分である各
   基本ブロックまで分割する第２ステップと、 ハードウエア構成の各構成が最大限並列に動作できるよ
   うに上記各基本ブロックをデータ転送経路を考慮してス
   ケジューリングすることにより上記各基本ブロックの処
   理ステップ数をそれぞれ算出する第３ステップと、 要求仕様に対応した典型的な入力データを用いて上記ハ
   ードウエア構成の動作をシミュレートして、上記各基本
   ブロックの実行数をそれぞれ算出する第４ステップと、 上記各処理ステップ数と上記各実行数とからハードウエ
   ア構成を評価する第５ステップとを含むことを特徴とす
   るデータ処理装置のアーキテクチャ評価方法。
2. 【請求項２】請求項１記載のデータ処理装置のアーキテ
   クチャ評価方法において、 さらに、第１ステップでは、ハードウエア構成に制御装
   置設計や命令セット設計による並列化不可能な演算や転
   送、制御の組み合わせを並列制約情報として付加し、 第３ステップでは、上記並列制約情報も考慮してスケジ
   ューリングすることを特徴とするデータ処理装置のアー
   キテクチャ評価方法。