JP2002230065A

JP2002230065A - システムｌｓｉ開発装置およびシステムｌｓｉ開発方法

Info

Publication number: JP2002230065A
Application number: JP2001027432A
Authority: JP
Inventors: Nobuo Matsui; 伸郎松井; Atsushi Mizuno; 水野　　淳; Ryuichiro Oyama; 隆一郎大山; Ai Tangoda; 愛丹後田; Katsuya Uchida; 勝也内田
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2001-02-02
Filing date: 2001-02-02
Publication date: 2002-08-16
Also published as: US6634017B2; US20050076314A1; US7340692B2; EP1229461A2; EP1229461A3; US20020147957A1

Abstract

(57)【要約】【課題】最適な性能のＬＳＩを開発設計すること
を可能にする。【解決手段】オプション命令が定義されたプロセ
ッサを含むシステムＬＳＩの開発設計に利用されるコン
ピュータシステム上で動作する複数のソフトウェアから
成るシステムＬＳＩ開発装置であって、システムＬＳＩ
の開発設計に関わる可変項目定義情報に基づいて前記ソ
フトウェアを動作させ、システムＬＳＩのハードウェア
記述、検証環境および開発設計ツールを生成するシステ
ムＬＳＩ開発環境生成部を具備し、可変項目定義情報
は、オプション命令情報、ユーザ定義モジュールおよび
マルチプロセッサ構成に関する情報の少なくとも１つを
含む。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、少なくともオプシ
ョン命令が定義されたcofigurableプロセッサを含むシ
ステムＬＳＩの開発設計に利用される、コンピュータシ
ステム上で動作する複数のソフトウェアから成るシステ
ムＬＳＩ開発装置およびそのシステムＬＳＩ開発方法に
関する。

【０００２】

【従来の技術】近年、マルチメディア処理等の組み込み
機器用ＬＳＩに対するニーズの多様化とその市場サイク
ルの短期化から、アプリケーションに最適なＬＳＩを短
期に開発するＬＳＩ設計開発システムが望まれている。

【０００３】一般に、ＬＳＩ内に汎用プロセッサを搭載
した場合、ハードウェアの設計コストはほとんどゼロに
等しいが、アプリケーションの性能をフルに引き出すこ
とはできない。このため、最近では、命令やメモリ構成
等が選択可能なcofigurableプロセッサが提供されるよ
うになり、また同時に、cofigurableプロセッサの提供
者は、コンフィグレーションを指定して論理合成可能な
ハードウェア記述を出力するシステムを提供している。
このようなプロセッサおよびシステムによれば、オプシ
ョン命令やメモリサイズを指定することによって、アプ
リケーションに最適な構成のプロセッサを短期間で入手
することが可能となる。

【０００４】一方、通常、命令セット等が変われば、コ
ンパイラやシミュレータ等のソフトウェア開発ツールも
変更しなければならない。このため、コンフィグレーシ
ョンを指定することにより、ハードウェア記述と同時
に、ソフトウェア開発ツールを生成するシステムも提供
されるようになっている。このようなシステムによれ
ば、ソフトウェア開発ツールの設計に要する労力および
時間を大幅に削減することができる。

【０００５】

【発明が解決しようとする課題】以上述べたように、co
nfigurableプロセッサによれば、アプリケーションに最
適なプロセッサ構成を短期間で入手することができると
同時に、ソフトウェア開発も従来通りのフローで行うこ
とが可能となる。しかしながら、アプリケーションの性
能をより十分に引き出すためには、アプリケーションの
一部をハードウェア化して、プロセッサ＋専用ハードウ
ェアというシステムＬＳＩ構成をとることも考えられ、
そして、この方が最適なＬＳＩ構成になることが多い。
ところが、従来の技術では、カスタマイズすることがで
きるのはプロセッサの構成だけであって、プロセッサの
周辺に追加するユーザ定義のハードウェアモジュールを
含めた構成を処理することができない。このため、現
在、プロセッサ＋専用ハードウェア構成を含めたシステ
ムＬＳＩ構成の検討、性能評価、設計検証およびソフト
ウェア開発を行うことができず、より最適な性能のＬＳ
Ｉを開発することが困難な状態となっている。

【０００６】本発明は、上記の技術的課題を解決すべく
なされたもであり、その目的は、最適な性能のＬＳＩを
開発設計することを可能にする技術を提供することにあ
る。

【０００７】

【課題を解決するための手段】本発明に係るシステムＬ
ＳＩ開発装置の特徴は、オプション命令が定義されたプ
ロセッサを含むシステムＬＳＩの開発設計に利用される
コンピュータシステム上で動作する複数のソフトウェア
から成るシステムＬＳＩ開発装置であって、システムＬ
ＳＩの開発設計に関わる可変項目定義情報に基づいてソ
フトウェアを動作させ、システムＬＳＩのハードウェア
記述、検証環境および開発設計ツールを生成するシステ
ムＬＳＩ開発環境生成部とを具備し、可変項目定義情報
は、オプション命令情報、ユーザ定義モジュールおよび
マルチプロセッサ構成に関する情報の少なくとも１つを
含むことにある。このような構成のシステムＬＳＩ開発
装置によれば、オプション命令、ユーザ定義モジュール
およびマルチプロセッサ構成の少なくとも１つを含む可
変項目定義情報の可能な全ての組み合わせについて、オ
プション命令が定義されたプロセッサを含むシステムＬ
ＳＩのハードウェア、検証環境、開発ツールを一貫して
網羅的／複数並列に作成することができるので、アプリ
ケーションに最適なシステムＬＳＩを短期間に開発する
ことが可能となる。

【０００８】

【発明の実施の形態】以下、図１〜図１９を参照して、
本発明の実施の形態のシステムＬＳＩ開発装置の構成お
よびその動作について説明する。

【０００９】《システムＬＳＩ開発装置の構成》始め
に、図１を参照して、本発明の実施の形態のシステムＬ
ＳＩ開発装置の構成について簡単に説明する。

【００１０】本発明の実施の形態のシステムＬＳＩ開発
装置１は、図１に示すように、設定ファイル生成部２、
ユーザ定義モジュール・ユーザ定義命令記憶部３、シス
テムＬＳＩ開発環境生成部４、性能評価部５、終了判定
部６、変更項目設定部７、入出力インタフェイス部８お
よび制御部９を有する。

【００１１】また、本発明の実施の形態のシステムＬＳ
Ｉ開発装置１は、装置１内に各種情報を入力するための
入力部１０と装置１からの各種情報を出力するための出
力部１１とに接続されている。ここで、入力部１０の形
態としては、例えばキーボード、マウスポインタ、テン
キー、タッチパネル等を採用することができ、また、出
力部１１の形態としては、例えばディスプレイ装置や印
刷装置等を採用することができる。

【００１２】次に、図２〜図１３を参照して、このシス
テムＬＳＩ開発装置内の各部の構成について順に詳しく
説明する。

【００１３】『設定ファイル生成部の構成』設定ファイ
ル生成部２は、図２に示すように、入力解析部２１、ロ
ーカルメモリマップ生成部２２、オプション情報記憶部
２３、デバイス構成記憶部２４、キャッシュ構成記憶部
２５およびローカルメモリマップ記憶部２６を備え、シ
ステムＬＳＩの設計上のコンフィグレーションを記述し
たコンフィグレーション指定ファイル、可変値設定情
報、最優先項目設定情報、目標性能指定情報（ハードウ
ェア性能、ソフトウェア性能の一方又は両方を含み、ハ
ードウェアの性能指標としては面積、周波数、消費電
力、ソフトウェアの性能指標としては、コードサイズ、
実効命令数、実行サイクル数を含む。）および変更項目
設定部７からの変更項目リスト情報に基づいて、システ
ムＬＳＩ設計上のコンフィグレーションを生成、格納す
る。

【００１４】以下、設定ファイル生成部２内のそれぞれ
の構成要素について説明する。

【００１５】〈入力解析部の構成〉入力解析部２１は、
コンフィグレーション指定ファイルの内容を解析し、コ
ンフィグレーション指定ファイル内に記述されたコンフ
ィグレーションの内容をオプション情報記憶部２３、デ
バイス構成記憶部２４およびキャッシュ構成記憶部２５
の各部に分割する。

【００１６】ここで、この実施の形態においては、コン
フィグレーション指定ファイル内には、オプション命令
の有無、デバイスの有無（デバイスには、命令メモリ、
データメモリ、コプロセッサが含まれ、命令メモリ、デ
ータメモリの可変項目には、サイズ、アドレスが含まれ
る）、キャッシュの有無、キャッシュサイズ、ユーザ定
義命令、ユーザ定義ハードウェアモジュール、ＬＳＩ内
部のメモリマップ（メモリマップには、外部メモリ領
域、内部メモリ領域、入出力領域が含まれ、外部メモリ
領域には、キャッシュアクセス領域の指定項目も含まれ
るものとする。また、各メモリ領域にはレイテンシ情報
も含まれる）、マルチプロセッサ構成（マルチプロセッ
サの数など）等の情報を記述するものとする。なお、ユ
ーザ定義命令やユーザ定義ハードウェアモジュールの記
述部分には、ユーザ定義命令やユーザ定義モジュールを
記述したファイル名の記憶位置（この実施の形態におい
ては、ユーザ定義モジュール・ユーザ定義命令記憶部３
の位置）を絶対パスや相対パス等の記述によって指定す
るようにする。

【００１７】また、コンフィグレーション指定ファイル
からシステムＬＳＩ設計上のコンフィグレーションを指
定する際は、ユーザは、設定ファイル生成部２内の各記
憶部２３〜２６で定義されている可変値の中から１つの
値を選択し、選択した値を、例えば図３に示すようなコ
ンフィグレーション指定ファイル内に記述する。

【００１８】すなわち、例えば、以下に示すＳＩＺＥ記
述においては、内蔵データメモリサイズが１,２,４,８,
１６,３２[ＫＢ]のいずれかが選択可能であり、このＳ
ＩＺＥ記述を省略した場合には、８[ＫＢ]になることを
示す。

【００１９】DMEM: SIZE Ptype={1,2,4,8,16,32},default=8,comment="内蔵
データメモリのサイズ"; また、以下に示すＩＳＡ＿ＤＥＦＩＮＥ記述において
は、ユーザ定義命令のＩＳＡ定義ファイル名として任意
の文字列を記述しなければならないことを示す。

【００２０】UCI: ISA_DEFINE Ptype=string,default="",comment="ユーザ
定義命令のＩＳＡ定義ファイル名"; なお、上記のコンフィグレーションの設定作業は、入出
力インタフェイス部８を介した対話的な処理によって行
うようにしても良い。コンフィグレーションの設定を対
話的に行うようにすることにより、ユーザは、コンフィ
グレーション指定ファイルの文法等を意識せずに、コン
フィグレーションを容易に設定することができ、直接フ
ァイルに記述する場合と比べてコンフィグレーションの
設定に要する時間を短縮することができる。さらに、全
てのコンフィグレーションの設定を対話的に行えるの
で、コンフィグレーションの１つ設定し忘れる等の間違
いを防止することができる。

【００２１】また、コンフィグレーションに可変値を設
定するようにしても良い。コンフィグレーションに可変
値を設定した場合には、設定ファイル生成部２は、基本
設定、可変値の測定用に作られたテンプレート、ユーザ
が設定した値のいずれかを用いて自動的に他のコンフィ
グレーションの設定値を導出するようにする。コンフィ
グレーションに可変値を設定することにより、ユーザ
は、コンフィグレーションの可変範囲に応じた複数の開
発環境、検証環境を同時に得ることができるので、ＬＳ
Ｉ開発サイクルの短縮を実現することが可能となる。

【００２２】さらに、コンフィグレーションの中で最優
先項目を設定するようにしても良い。コンフィグレーシ
ョンの中で最優先項目が設定された場合、設定ファイル
生成部２は、最優先項目以外の部分の設定値について
は、基本設定、最優先項目に基づいてテンプレート又は
ユーザが指定した設定値を用いて導出し、最優先項目が
最適となるようなコンフィグレーションを生成する。コ
ンフィグレーションの中に最優先項目を指定することに
より、ユーザはシステムＬＳＩの構成を考えることな
く、優先項目に適した構成を開発環境、検証環境を作成
し、その評価を行うことができる。

【００２３】〈ローカルメモリマップ生成部の構成〉ロ
ーカルメモリマップ生成部２２は、コンフィグレーショ
ン指定ファイルから指定されるグローバルマップ（全プ
ロセッサに共通のメモリ領域、例えば、図４（ａ）参
照）と、命令メモリ、データメモリ、命令キャッシュ、
データキャッシュといったシステムＬＳＩ内の個々のプ
ロセッサのローカルメモリ情報とを統合して、図４
（ｂ）に示すようなシステムＬＳＩ内のプロセッサ毎の
ローカルメモリマップを生成し、生成したローカルメモ
リマップをローカルメモリマップ記憶部２６内に格納す
る。ここで、プロセッサのローカルメモリ領域は、個々
のローカルメモリ毎に予約されているグローバルマップ
中のメモリ領域に対して、コンフィグレーション指定フ
ァイルにより指定されるメモリサイズを反映させること
によって生成することができる。また、予めグローバル
マップ中に各プロセッサのシャドウメモリ情報を指定し
ておくようにすれば、各プロセッサのローカルマップに
他のプロセッサのローカルメモリを含むシャドウメモリ
を作ることもできる。

【００２４】〈オプション情報記憶部の構成〉オプショ
ン情報記憶部２３は、入力解析部２１によるコンフィグ
レーション指定ファイルの解析結果に基づいて、システ
ムＬＳＩに内蔵されるプロセッサの命令セット内のオプ
ション命令のＯＮ／ＯＦＦ（オン／オフ）の種別に関す
る情報を格納する。

【００２５】〈デバイス構成記憶部の構成〉デバイス構
成記憶部２４は、入力解析部２１によるコンフィグレー
ション指定ファイルの解析結果に基づいて、システムＬ
ＳＩに内蔵されるデバイスのＯＮ／ＯＦＦの種別に関す
る情報とそのサイズに関する情報、アドレス情報、プロ
セッサの命令メモリやデータメモリに関する情報、コプ
ロセッサ等のオプションハードウェアに関する情報を格
納する。

【００２６】〈キャッシュ構成記憶部の構成〉キャッシ
ュ構成記憶部２５は、入力解析部２１によるコンフィグ
レーション指定ファイルの解析結果に基づいて、システ
ムＬＳＩのキャッシュのＯＮ／ＯＦＦの種別、キャッシ
ュのタイプ（direct, 2-way, 4-way, n-way）に関する
情報とそのサイズに関する情報を格納する。

【００２７】〈ローカルメモリマップ記憶部の構成〉ロ
ーカルメモリマップ記憶部２６は、ローカルメモリマッ
プ生成部２２が生成したローカルメモリマップに関する
情報を格納する。

【００２８】『ユーザ定義モジュール・ユーザ定義命令
記憶部の構成』ユーザ定義モジュール・ユーザ定義命令
記憶部３は、ユーザ定義のハードウェアモジュールおよ
びシステムＬＳＩに内蔵するプロセッサの命令セットに
おけるユーザ定義命令に関する情報を格納する。ここ
で、ユーザ定義のハードウェアモジュールに関する情報
はＲＴＬ記述、又は動作記述、命令の動作に関する情報
はＣモデルで記述して記憶部３内に格納することが望ま
しい。動作記述とＣモデル記述は同一のものでも良い。
また、ユーザ定義命令に関する情報は、コンフィグレー
ション指定ファイルから指定される、図４（ｃ）に示す
ようなＩＳＡ定義ファイルに記述して格納することが望
ましい。

【００２９】『システムＬＳＩ開発環境生成部の構成』
システムＬＳＩ開発環境生成部４は、図２に示すよう
に、ＲＴＬ生成部４１、シミュレータカスタマイズ部４
２、コンパイラカスタマイズ部４３、アセンブラカスタ
マイズ部４４および検証ベクトル生成部４５を備え、設
定ファイル生成部２内に格納されているコンフィグレー
ションの可能な全ての組み合わせについて、システムＬ
ＳＩのハードウェア、検証環境および開発設計ツールを
生成する。

【００３０】以下、このシステムＬＳＩ開発環境生成部
の内部構成について詳しく説明する。

【００３１】〈ＲＴＬ生成部の構成〉ＲＴＬ生成部４１
は、設定ファイル生成部２の記憶部内に記憶されている
コンフィグレーションに基づいて、システムＬＳＩに内
蔵されるプロセッサのＲＴＬ記述を生成する。

【００３２】具体的には、図６に示すように、ブロック
接続部４１ｄが、デバイス構成記憶部２４とキャッシュ
構成記憶部２５内に格納されたコンフィグレーションを
参照してユーザにより設定されたコンフィグレーション
に対応するＲＴＬテンプレート４１ａ,４１ｂを選択
し、プロセッサコア部のＲＴＬ記述４１ｃに対して、選
択したＲＴＬテンプレートと、高位合成処理部４１ｅが
ユーザ定義モジュール・ユーザ定義命令記憶部８内に格
納されたユーザ定義命令又はユーザ定義モジュールの仕
様である動作記述を高位合成することにより生成され
る、ＲＴＬ記述とを接続することにより、プロセッサの
ＲＴＬ記述を生成する。なお、記憶部８内の仕様がＲＴ
Ｌ記述である場合は、そのままインタフェイス信号が合
うように接続する。

【００３３】なお、マルチプロセッサ構成が定義された
場合には、ブロック接続部４１ｄは、複数のプロセッサ
記述を生成し、それらをバスで接続したマルチプロセッ
サのＲＴＬ記述を生成するものとする。

【００３４】また、ＲＴＬテンプレート４１ａ,ｂ内に
含まれる命令メモリ、データメモリ、オプションハード
ウェア、命令キャッシュおよびデータキャッシュについ
ては、ユーザが選択可能なメモリサイズの各々について
ＲＴＬ記述を予め用意し、指定されたコンフィグレーシ
ョンに応じてＲＴＬ記述を選択接続するようにする。ま
た、オプション命令については、オプション命令に対応
するハードウェアのテンプレートをオプション命令のＯ
Ｎ／ＯＦＦ全ての組み合わせについて用意する。

【００３５】例えば図７に示す例においては、除算オプ
ション命令（ＤＩＶ）、最大最小値オプション命令（Ｍ
ＩＮＭＡＸ）各々のＯＮ／ＯＦＦの組み合わせ４通りに
ついて、命令機能ユニットのＲＴＬ記述をそれぞれテン
プレートとして用意し、デバイス構成記憶部２４とキャ
ッシュ構成記憶部２５内に格納されたコンフィグレーシ
ョンに合わせて選択接続する。また、コプロセッサ等の
オプションハードウェアについても同様、コンフィグレ
ーションで有効と指定されている場合、既定義のＲＴＬ
記述を接続する。さらに、ユーザ定義のハードウェアが
ある場合、ユーザが記述したハードウェア記述を接続す
る。

【００３６】以上の接続処理によって、ＲＴＬ生成部４
１は、設定されたコンフィグレーションに対応したプロ
セッサのＲＴＬ記述を生成する。例えば、プロセッサコ
アに４[ＫＢ]の命令メモリと８[ＫＢ]のデータメモリを
追加したプロセッサを最初に構築する場合、ユーザはコ
ンフィグレーションのパラメータ指定のみを行えば、プ
ロセッサのＲＴＬ記述を自動的に得ることができる。ま
た、命令メモリ、データメモリのサイズを変更し、コプ
ロセッサと命令キャッシュ、データキャッシュを追加
し、さらに幾つかのオプション命令とユーザ定義命令を
持つプロセッサ２を構築する場合であっても、コンフィ
グレーションのパラメータ指定を変更し、ユーザ定義命
令に対応するハードウェアのＲＴＬ記述を与えるのみ
で、新たなプロセッサのＲＴＬ記述を得ることができ
る。また、複数のＲＴＬテンプレートを用意しておくの
ではなく、可変項目をパラメータ表現したＲＴＬテンプ
レートにコンフィグレーションで設定された値を反映さ
せることによっても同等の効果が得られる。さらに、こ
のようなパラメータ化されたＲＴＬテンプレートは、メ
モリ、キャッシュ等の部分モジュール毎でも良く、それ
らを含んだプロセッサ全体のものでも良い。全てのパラ
メータを包含した１つのＲＴＬテンプレートでも良い。

【００３７】〈シミュレータカスタマイズ部の構成〉シ
ミュレータカスタマイズ部４２は、コンフィグレーショ
ンに沿った命令動作を実行するシミュレータを生成す
る。

【００３８】具体的には、図８に示すように、再コンパ
イル部４２ｃが、シミュレータテンプレート４２ａにユ
ーザ定義モジュール・ユーザ定義命令記憶部３内に格納
されたユーザ定義ハードウェアのＣモデルを組み込んで
再コンパイルすることにより、シミュレータを再構築す
る。また、起動オプション情報抽出部４２ｄは、設定フ
ァイル生成部内のデバイス構成記憶部２４とキャッシュ
構成記憶部２５に格納されているデータを参照して、起
動時のオプションを指定するシミュレータ起動オプショ
ンファイル（図９（ａ）参照）を生成する。そして、組
み合わせ処理部４２ｅは、再構築したシミュレータとシ
ミュレータ起動オプションファイルとを組み合わせるこ
とにより、コンフィグレーションに沿った命令動作を実
行するシミュレータを生成する。

【００３９】なお、シミュレータは、特定アドレス通過
時に、デバッグ指令の実行結果を出力する手段を備える
ことが望ましい。従来、実行途中の誤りが起きた場合に
エラーを出力するアサーションエラープログラム等があ
ったが、正常に実行している時の途中経過を調べるため
には、途中結果を出力する命令をアプリケーションに埋
め込んでおくか、デバッガ等で実行を停止させて途中経
過を読み取るしかなかった。起動時に指定されるアドレ
スを通過した際に所定の情報を出力するようにすれば、
シミュレータでアプリケーションを実行している途中に
途中経過を調べることが可能となる。例えば、次に示す
ようなコマンドでシミュレータを起動する。

【００４０】sim -load test.hex -printx mem(0x400)
at 0x1200 ここで、sim,-load test.hex,-printx mem(0x400) at 0
x1200はそれぞれ、システムＬＳＩのシミュレータ、tes
t.hexというファイルをロードして実行するという命
令、0x1200番地を通過したときにメモリの0x400番地の
内容を１６進数で出力する命令を示す。

【００４１】シミュレータは、この引数で指定された指
示を記憶しておき、プログラムカウンタが0x1200番地を
通過する度に0x400番地の内容を１６進数でコンソール
に出力する。このとき、アプリケーションプログラムに
は観測用のコードが埋め込まれているわけではないの
で、命令数やサイクル数等の統計情報には全く影響を及
ぼさないで観測できることになる。また、特定アドレス
で実行を停止させ、人手を介してメモリの値を読み出し
表示させる等の作業を行う必要がないので、統計情報を
正確に取りながら、特に注目したい途中結果を確認しな
がらアプリケーションプログラムのシミュレーションを
することができるようになり、効率の良いＬＳＩ開発が
可能となる。

【００４２】また、シミュレータは、指定された以外の
領域のメモリアクセスが起きた場合に実行を停止するこ
とが望ましい。設定されたコンフィグレーションに従っ
てシミュレータを起動した時には、使用可能なメモリが
明確に与えられている。もし、実施の基板上で実装され
ていない領域のメモリをアクセスするとバスエラーにな
る等してそれ以後の動作は保証されない。動作が保証さ
れないプログラムは、シミュレータ実行時に間違いを指
摘される等して、早期に修正しておく必要がある。そこ
で、シミュレータは存在するメモリ領域をを指定され、
明示的に指定されない領域はアクセス禁止にして、違反
があったら警告する（且つ停止する）。また、シミュレ
ータが対話モードを有志、対話モード（デバッグモー
ド）に移行し、どこが原因だったのかが解析できるよう
になっている。また、シミュレータがデバッガと通信し
て動作している場合には、シミュレーション動作を中断
してデバッガのコマンド待ちに移行し、無効な領域をア
クセスしたというエラーを表示し、プログラムの誤りを
早期に確実にユーザに伝える。また、メモリのデコード
回路では、上位のアドレス信号線の接続を省略されて構
成される場合がある。この場合、ターゲットでアドレス
を間違えたプログラムを実行してもバスエラーにはなら
ないが、アクセスが書き込みだった場合には、意図しな
いアドレスの内容を書き換えてしまい、後の実行結果が
期待通りにならない時がある。この間違ったプログラム
をＲＴＬシミュレータで実行した場合でも、こういった
誤りはすぐには発見することができない。しかし、シミ
ュレータに正しいアドレスのみをアクセスできるように
正確なマッピング情報を与えて実行させたときには、指
定範囲以外のアドレスをアクセスしたことが即座に警告
されれば、ユーザは間違ったプログラムに早期に気付く
ことになり、無駄な解析をする時間を節約でき、開発サ
イクルの短縮が図れる。

【００４３】なお、デバッガについては、デバイス構成
記憶部２４とキャッシュ構成記憶部２５内に格納されて
いるデータを参照して、図９（ｂ）に示すようなデバッ
ガ起動オプションファイルを生成する。デバッガ起動オ
プションファイルを利用することにより、デバッガはコ
ンフィグレーションに沿った動作を行うことが可能とな
る。

【００４４】また、デバッガは、シミュレータの統計情
報を仮想的なレジスタ若しくは変数として読み出す手段
を有することが望ましい。デバッガは、$profileという
変数を特殊な変数として予約してある。統計情報は、領
域毎に管理されている。そして、デバッガの変数読み出
しコマンドprintによって表示させる。領域の３番目の
情報を表示させるためには、print $profile[3]のよう
に入力する。

【００４５】dbg> print $profile[3] profile3:Count=7 Inst=123 Cycle=145 dbg> さらに、言語ツールは、シミュレータ用のデバッグ用指
令をアドレスと共にシンボルやソース行と同等なデバッ
グ情報として出力する手段を有することが望ましい（タ
ーゲットの機械命令には反映されない）。コンパイラに
は、シミュレータ等で標準出力に途中結果等を出力する
ための拡張が施されている。#pragma cosoleoutに続く
文は、ターゲットの機械語には翻訳されずに、シンボル
名や行番号と同様、デバッグ情報としてファイルに格納
される。シミュレータは、デバッグ情報付きののオブジ
ェクトファイルを読み込んだとき、#pragma文が定義さ
れたアッドレス情報を記憶すると共に、デバッグ出力情
報であるprintf("a=%d\n",a)を記憶する。シミュレータ
が該当アドレスを実行しようとしたときに、デバッグ情
報を出力しなければならないと判断し、printf文をパー
サに送りデバッグ情報を出力する。

【００４６】このように、ターゲットの機械命令に影響
を与えずに、シミュレータ実行時にデバッグ情報を出力
し、シミュレータの実行も中断せずに内容を確認するこ
ともできる。このとき、シミュレータ実行時に収集され
る統計情報は、ターゲットで実行されるものと同一の情
報である。別の表現をすれば、ターゲットとシミュレー
タで同一のオブジェクトコードを用いることができるこ
とになる。したがって、実行環境の違いによる再コンパ
イルなどの時間が発生しなくなる分だけ開発サイクルも
短縮される。また、単一のオブジェクトファイルを共有
できるので、管理が容易になることは明白である。

【００４７】〈コンパイラカスタマイズ部の構成〉コンパイラカスタ
マイズ部４３は、オプション情報記憶部２３とユーザ定
義命モジュール・ユーザ定義命令記憶部３内に格納され
たデータを参照して、機械命令関数宣言を含む、図９
（ｃ）に示すような機械命令関数宣言ヘッダファイルを
生成する。なお、ここでいう機械命令関数宣言とは、プ
ロセッサ固有の命令を高級言語から直接指定するため
に、プロセッサ固有の命令を高級言語の関数宣言として
記述したものである。

【００４８】具体的には、図１０に示すように、機械命
令関数宣言抽出部４３ｃが、ユーザ定義モジュール・ユ
ーザ定義命令記憶部３内に格納されたユーザ定義命令を
参照して、対応する機械命令関数宣言を抽出する。ま
た、結合処理部部４３ｄが、オプション情報記憶部２３
内に格納されたデータを参照して、既定義のテンプレー
ト４３ｂから有効なオプション命令に対応する機械命令
関数宣言を選択する。そして、結合処理部４３ｄは、テ
ンプレート４３ｂと機械命令関数宣言抽出部４３ｃそれ
ぞれから抽出された機械命令関数宣言を結合することに
より、機械命令関数宣言ヘッダファイルが生成する。こ
の機械命令関数宣言ヘッダファイルには、コンフィグレ
ーションで有効になったオプション命令とユーザ定義命
令に対応する機械命令関数宣言が含まれる。

【００４９】これにより、ユーザは、高級言語プログラ
ムからコンフィグレーションで指定したオプション命令
とユーザ定義命令を直接指定し、利用することが可能と
なる。

【００５０】なお、コンパイラカスタマイズ部３３はオ
プション命令抽出部４３ａを有し、オプション命令抽出
部４３ａは、オプション情報記憶部２３内に格納された
データを参照して、最適化に利用することができるオプ
ション命令の情報を取得し、コンパイラ起動時のオプシ
ョンを指定するコンパイラ起動オプションファイル（図
１１（ａ）参照）を生成する。

【００５１】これにより、利用可能なオプション命令の
情報をコンパイラの最適化に反映させることができる。
また、コンパイラの関数ライブラリは、起動オプション
ファイルを使用してソースから再コンパイルされるの
で、利用可能なオプション命令を組み込んだライブラリ
を生成することができる。

【００５２】〈アセンブラカスタマイズ部の構成〉アセ
ンブラカスタマイズ部４４は、利用可能なオプション命
令とユーザ定義命令のニーモニックと命令形式の情報を
組み込んで、アセンブラを再構築する。このアセンブラ
カスタマイズ部４４によれば、利用可能な全ての命令の
任意の組み合わせからなるアセンブラプログラムについ
て、対応するオブジェクトコードを生成することができ
る。

【００５３】〈検証ベクトル生成部の構成〉検証ベクト
ル生成部４５は、設定ファイル生成部２内の各記憶部内
で指定されたコンフィグレーションを参照して、指定さ
れたシステムＬＳＩの構成を網羅的に検証する検証ベク
トルを生成する。ここで、システムＬＳＩの規模が大き
い場合等には、限られた時間の中で検証を終えるため
に、基本となる構成から変更された部分を重点的に検証
することが必要となる。そこで、指定されたオプション
命令や指定されたサイズのキャッシュ等を重点的に検証
するように、検証ベクトルは、命令セット記述に基づい
て、各命令に対応する検証ベクトル郡を生成することが
望ましい（図１１（ｂ）は検証ベクトル生成用のユーザ
定義命令ファイルの一例を示す）。

【００５４】『性能評価部の構成』性能評価部５は、ア
プリケーションのコードサイズ、実行命令数、実行サイ
クル数、チップのゲートサイズおよび消費電力を見積
る。以下では、この性能評価部による性能評価処理につ
いて詳しく説明する。

【００５５】・アプリケーションのコードサイズ評価性能評価部５は、アプリケーションのコードサイズを評
価することができる。

【００５６】今、アプリケーションとして図１２（ａ）
に示すようなＣ言語のプログラムがあるとする。図１２
（ａ）に示すアプリケーションは、システムＬＳＩ開発
環境生成部４が生成するコンパイラを利用して、以下の
ようにコンパイルすることができる。

【００５７】＞ＳＬＩＤＥ＿ｃｃｔｅｓｔ．ｃここで、ＳＬＩＤＥ＿ｃｃ、ｔｅｓｔ．ｃはそれぞれ、
コンパイラの起動コマンドおよびユーザが作成したアプ
リケーションのファイル名を示す。

【００５８】そして、コンパイルの結果得られるオブジ
ェクトファイルからアプリケーションのコードサイズに
関する情報を得ることができる。図１２（ａ）に示すＣ
プログラムの場合、そのコードサイズは６２となる。

【００５９】なお、ここではアプリケーションはＣ言語
で記述されたものを例としてあげたが、システムＬＳＩ
開発環境生成部４はアセンブラも生成することができる
ので、アプリケーションはアセンブリ言語で記述された
もの（あるいは混合されたもの）でも構わない。アプリ
ケーションがアセンブリ言語で記述された場合は、アセ
ンブルの結果としてオブジェクトファイルが得られる。
また、アプリケーションプログラムはＲＯＭ上に配置さ
れるため、ＲＯＭのサイズはアプリケーションプログラ
ムのコードサイズおよび初期値付き変数のデータサイズ
に依存することになる。ＲＯＭのサイズは、通常、１２
８[ＫＢ]や２５６[ＫＢ]のように２ｎ[ＫＢ]（ｎは自然
数を示す）となるため、コードサイズがこの境界にある
場合には、小さいサイズのＲＯＭに収まるようにアプリ
ケーションを変更すれば、ＲＯＭサイズが小さくなり、
コストの削減につながる。例えばコードサイズが１３０
[ＫＢ]の場合、ＲＯＭサイズは２５６[ＫＢ]となるが、
アプリケーションを改良してコードサイズが１２８[Ｋ
Ｂ]以下になるようにすれば、ＲＯＭサイズは１２８[Ｋ
Ｂ]になり、コストの削減につながる。

【００６０】また、システムＬＳＩ開発環境生成部４
は、シミュレータを生成することができるので、生成さ
れたシミュレータを利用して、実行ファイルをシミュレ
ートすることもできる。シミュレータは、シミュレーシ
ョン結果を表示するだけでなく、シミュレート時に実行
される命令を１つずつカウントすることで、アプリケー
ション全体の実行命令数を計測することができる。例え
ば図１２（ａ）に示すプログラムのコンパイルの結果得
られる実行ファイルの名前をｔｅｓｔとし、この実行フ
ァイルｔｅｓｔをシミュレータ（起動コマンドＳＬＩＤ
Ｅ＿ｓｉｍ）にかけることで、＞ＳＬＩＤＥ＿ｓｉｍｔｅｓｔｒｅｓｕｌｔ＝４５０プログラム停止。実行命令数：７０４のようにプログラムの実行結果（ｒｅｓｕｌｔ＝４５
０）と実行命令数（７０４）を得ることができる。

【００６１】実行命令数は単に実行される命令を種類に
関係なくカウントするだけで得られるので、短時間に測
定することができる。これによりユーザは大まかなアプ
リケーションの性能に短時間に知ることができ、ＬＳＩ
設計サイクルの短期化につながる。

【００６２】・アプリケーション実行時の開始から終了
までに実行される命令数の総和（実行命令数）の評価性能評価部５は、アプリケーション実行時のキャッシュ
ミスの測定、実行される各命令のサイクル数の計測を行
って、アプリケーション全体の正確なサイクル数を測定
することができる。例えば、図１２（ａ）のプログラム
のコンパイルの結果得られる実行ファイルの名前をｔｅ
ｓｔとし、この実行ファイルｔｅｓｔをシミュレータ
（起動コマンドＳＬＩＤＥ＿ｓｉｍ）にかけることで、＞ＳＬＩＤＥ＿ｓｉｍｔｅｓｔｒｅｓｕｌｔ＝４５０プログラム停止。実行サイクル数：１１９０のようにプログラムの実行結果（ｒｅｓｕｌｔ＝４５
０）と実行サイクル数（１１９０）を得ることができ
る。この性能見積もりにより、ユーザはＬＳＩの性能が
余っているのか不足しているのかを知ることができ、コ
ンフィグレーションの変更が容易となり、ＬＳＩ設計サ
イクルの短期化につながる。

【００６３】また、性能評価部５は、アプリケーション
プログラム内に実行命令数計測の開始点と終了点を意味
する命令を記述することにより、アプリケーションプロ
グラムの指定された２点間の実行命令数を測定する。
今、図１２（ａ）のプログラムの内側のｆｏｒループの
実行命令数を計測しようとする場合、プログラムに図１
２（ｂ）のように命令を書き加える。そして、コンパイ
ラが図１３のプログラムをコンパイルすると、＿ＳＴＡ
ＲＴと＿ＥＮＤが記述されたアドレスが保存され、シミ
ュレート時に保存されたアドレス間の実行命令数を測定
するようにしている。＿ＳＴＡＲＴ、＿ＥＮＤに続く括
弧内の数字が＿ＳＴＡＲＴと＿ＥＮＤの対応関係を示し
ている。図１２（ｂ）のアプリケーションのシミュレー
ト結果は、図１３（ａ）に示すように、内側のループ
（番号１の区間）の実行命令数が３７０であることが得
られる。

【００６４】このように、測定区間を限定することによ
り、実行命令数測定時間を短くすることができる。特
に、ループ変数の値によらず処理内容が変わらないルー
プの１回の実行命令数が知りたい場合は、そのループを
測定区間として指定し、ループが１回終わったところで
シミュレートを終了させれば、測定時間の短縮につなが
る。これにより、アプリケーションの特定の場所だけの
実行命令数を知ることができ、測定時間の短縮によるＬ
ＳＩ設計サイクルの短縮化だけでなく、アプリケーショ
ンの改良箇所の探索にも有効な手段となる。

【００６５】・アプリケーション実行時の開始から終了
までに実行されるサイクル数の総和（実行サイクル数）
の評価性能評価部５は、実行サイクル数の測定を実行すること
もできる。具体的には、区間指定の方法は上記の実行命
令数の場合と同様であり、たとえば図１２（ａ）のプロ
グラムの内側のｆｏｒループの実行サイクル数を測定し
ようとする場合、図１２（ｂ）に示すように、内側のｆ
ｏｒループの前後に＿ＳＴＡＲＴと＿ＥＮＤを書き加え
る。この結果、シミュレート結果として図１３（ｂ）に
示す結果が得られる。この処理により、実行サイクル数
の測定時間の短縮につながるので、ＬＳＩ設計サイクル
の短期化だけでなく、アプリケーションの改良個所の探
索、さらにキャッシュの設定にも有効な手段となる。

【００６６】なお、ユーザが指定した区間だけでなく、
指定した点を通過したときの実行命令数と実行サイクル
数を出力するようにしても良い。これにより、ユーザは
アプリケーションの実行開始時から任意の点までの実行
命令数と実行サイクル数を知ることができる。例えば、
ｍａｉｎ関数の中で呼び出される、ある関数内のループ
が終わった時点での実行命令数を知りたい場合を考え
る。この時、実施例４，５のような区間指定の実行命令
数では、関数をまたがって区間を指定することができな
いため、アプリケーションの最初からの実行命令数を知
ることができない。もし区間指定ではなく、プログラム
上の任意の場所という指定ができれば、この問題は解消
する。シミュレータは指定された点のアドレスを保持し
ておき、アプリケーション開始時からそのアドレス通過
時までの実行命令数を出力するようにすればよい。

【００６７】まず指定されたアドレスが条件付分岐命令
以外の命令、例えば加算を行うａｄｄ命令の場合を考え
る。シミュレータはこのａｄｄ命令を実行する前と後で
の、アプリケーション開始時からの実行命令数を出力で
きる。ａｄｄ命令の実行の前、後の選択はユーザが行う
ことができる。

【００６８】次に指定されたアドレスが条件付分岐命
令、例えばｂｅｑ命令の場合を考える。ｂｅｑＲ１，
Ｒ２，ＬＡＢＥＬ１という命令は、レジスタＲ１とＲ２
の値が等しいときにＬＡＢＥＬ１に記述されたアドレス
に分岐し、等しくないときは分岐命令の次の命令を実行
する（ここでは分岐命令の遅延は無いものと考えてい
る）。シミュレータはこのｂｅｑ命令の条件が成立した
ときと成立しないときの両方の、アプリケーション開始
時からの実行命令数が出力できる。条件成立／不成立の
選択はユーザが行うことができる。

【００６９】・消費電力、ゲートサイズの評価性能評価部５は、システムＬＳＩ開発環境生成部３から
出力されるＲＴＬ記述を参照して、ワットウォッチャ
（WattWatcher）等の市販ツールによって消費電力ある
いは消費電力に換算可能な数値を抽出する。また、ＲＴ
Ｌ記述を利用して、ゲートサイズあるいはゲートサイズ
に換算可能な数値を抽出する。ゲートサイズに関する情
報を抽出することにより、最適なチップ面積を決定で
き、ＬＳＩ製造時のコストを抑えることにつながる。

【００７０】なお、性能評価部５は、システムＬＳＩ開
発環境生成部３が生成したＲＴＬ記述、コンパイラ、シ
ミュレータ、検証環境を利用して、キャッシュのミス率
（あるいはヒット率）を抽出することもでき、例えば、
目的アプリケーションに対するキャッシュ性能の見積り
結果として図１３（ｃ）に示すような値を得ることがで
きる。この結果、キャッシュサイズに制約がなく、目的
アプリケーションの実行時間を短くしたい場合はキャッ
シュミス率が一番低い１６Ｋｂｙｔｅｓをキャッシュサ
イズとして設定することになる。また、キャッシュサイ
ズに制約がある場合は、キャッシュミス率の変更に伴う
目的アプリケーションの実行時間の変更とのトレードオ
フを考えることになる。

【００７１】また、性能評価部５は、生成したＲＴＬ、
コンパイラ、シミュレータ、検証環境に基づいて得たＲ
ＴＬのゲートサイズの消費電力などの見積もり情報や、
コンパイル、シミュレートの結果わかるアプリケーショ
ンの実行命令数や実行サイクル数といった見積もり情報
を内部に保持していることが望ましい。そして、これら
の情報をユーザが閲覧しようとする場合、すべての情報
を閲覧することも可能であるが、本ツールではユーザが
見たいと思う項目（最優先項目）を指定することで自動
的にその項目だけを閲覧することができる。たとえば、
ユーザがチップサイズを見積もり情報として知ろうとし
た場合、最優先項目としてチップサイズを指定すれば、
本ツールは生成したＲＴＬからチップサイズを計算して
ユーザに提出する。アプリケーションの実行サイクル数
を知ろうとした場合、シミュレート結果から判明した実
行サイクル数をユーザに提出する。

【００７２】このような構成によれば、ユーザは知りた
い見積もり情報を条件として指定することで、自動的に
その見積もり情報が得られることになり、見積もりの判
断が迅速に行えるようになる。

【００７３】なお、性能評価部５は、ＲＴＬシミュレー
ションを行った結果のサイクル情報をシミュレータの入
力として、変換できる。例えば、メモリアクセスといっ
ても、メモリには、いくつか種類がある。ＲＯＭやＲＡ
Ｍなどではアクセスサイクル数が異なってくる。このよ
うな時、シミュレータでは、シミュレータを生成する際
に大まかなサイクル数を設定することはできるが、それ
は実際の値に沿ったものではない。その値の修正を行う
ためにＲＴＬでシミュレーションを実行した結果のサイ
クル情報を利用する。シミュレータは、ＲＴＬシミュレ
ーションのサイクル情報または、サイクル情報をシミュ
レータの入力フォーマットに変換した情報を読み取り、
シミュレータ内部の値の変更が可能になる。これによ
り、より実際に近い値の見積もりを行うことができる。

【００７４】『終了判定部の構成』終了判定部６は、性
能評価部５による性能評価結果に基づいて、設計された
システムＬＳＩがユーザが予め設定した目標性能を満た
しているか否かを判別する。

【００７５】そして、目的性能を満たしていない場合に
は、変更項目設定部５が、性能評価部５による評価結果
に基づいて、次回以降の設定値を導出する。

【００７６】『変更項目設定部の構成』変更項目設定部
７は、性能評価部５による評価結果に基づいて、次回以
降のコンフィグレーションの設定値を導出する。性能評
価のための統計情報として、メモリ領域に対するアクセ
ス統計、アクセスサイクル数を有している。また、キャ
ッシュがついている場合は、キャッシュのヒット率も統
計情報として提供される。

【００７７】目的アプリケーションを実行した際の統計
情報を性能評価のための情報として利用することによ
り、目的アプリケーションの実行の特徴に沿った可変値
の設定値を導出することができる。

【００７８】メモリ領域（ＲＯＭ、ＲＡＭ、キャッシュ
など）は、アクセスサイクル数に基づき分類され、メモ
リ領域のアクセス統計とサイクル数計算部分とは分離さ
れている。

【００７９】アクセス統計とサイクル数計算を切り離し
ているのは、サイクル数補正の演算は必要なときのみに
行われるようにしたためである。ここで、キャッシュ付
システムにおいて１回では目的性能が得られなかった場
合を考える。性能評価の手段として、目的アプリケーシ
ョンのサイクル数が多い場合に、その部分を減らしたい
場合に、アクセス統計の情報を利用し、統合環境が持っ
ている、サイクル数を減らすためのテンプレートに従
い、キャッシュのサイズを大きくするなどの可変値の設
定を行う。

【００８０】（テンプレート）サイクル数が多い →メモリアクセスのサイクル数が多い →キャッシュのミス率が高い →ＡＮＳ：キャッシュサイズを増やす →その他の理由（省略）このように、メモリ領域をアクセスサイクルで分類し、
領域ごとに統計情報を持つことにより、より正確な見積
もりが得ることができ、また、目的アプリケーションの
実行時の統計情報を元にした評価を行うことにより、よ
り適正な可変値の設定値を導出できる。また、自動的に
可変値の設定値を導出できる手段を持つことにより、開
発時間を短縮することができる。

【００８１】また、変更項目設定部７は、性能評価のた
めの統計情報として、目的アプリケーションを実行した
結果のオプション命令の統計情報を有することが望まし
い。そして、この統計情報を利用して、使われていない
命令をはずしたオプションの構成に再編成をすることが
できる。例として、３２ビットの積和演算のオプション
命令をつけてＬＳＩを構成した場合を考える。この構成
で目的アプリケーションの実行させ、実行時の統計情報
をとる。その結果、３２ビットの積和演算のオプション
命令は使用しないことがわかり、そのオプション命令を
ＯＦＦにした構成を性能評価からのフィードバックとし
て、設定を変更し、再構築を行う。このように使用して
いない命令を除くための設定や再構築が自動的に行える
ことにより、開発時間を短縮し、かつコストの削減が可
能になる。

【００８２】さらに、変更項目設定部７は、評価結果に
より次回以降の可変値の設定値を導出する手段をもち、
また、性能評価のための統計情報として、目的アプリケ
ーションを実行した結果のオプション命令の統計情報を
有することが望ましい。これにより、この統計情報を利
用して、あらかじめ定められた出現回数または出現率以
下の命令をはずしたオプションの構成に再編成すること
ができる。例として、３２ビットの積和演算のオプショ
ン命令をつけてＬＳＩを構成して場合を考える。この構
成で目的アプリケーションの実行させ、実行時の統計情
報をとる。その結果、３２ビット積和演算のオプション
命令の使用頻度があらかじめ定められた出現回数または
出現率以下であることがわかったので、そのオプション
命令をＯＦＦにした構成を性能法科からのフィードバッ
クとして、再構築を行う。コンパイラは、そのオプショ
ン命令を使用せずに、コンパイルを行う。このように命
令の再構築、コンパイラの再構築、また、自動的な設定
の変更が行えることにより、開発時間を短縮し、かつコ
ストの削減が可能になる。

【００８３】さらに又、変更項目設定部７は、性能評
価により自動的に可変項目の設定変更を行った後で、再
度目的アプリケーションを実行して、設定変更の正当性
を判断する手段を有することが望ましい。また、性能評
価により自動的に可変項目の設定変更を行った後で再度
目的アプリケーションを実行して、設定変更が有効でな
いと判断した場合には、別の設定に変更して、これを、
有限実行回数の施行を繰り返し、得られた結果の中で適
切な設定を自動的に選択すると良い。

【００８４】『入出力インタフェイス部の構成』入出力
インタフェイス部８は、システムＬＳＩ開発装置１と入
力部１０、出力部１１との間の情報の入出力処理を支援
する機能を有し、例えば、グラフィカルユーザインタフ
ェイス（Graphical User Interface GUI）の利用が考え
られる。この入出力インタフェイス部８によれば、コン
ピュータに不慣れなユーザであっても、入出力インタフ
ェイス部８からの指示に従って、容易にシステムＬＳＩ
の開発を行うことができる。

【００８５】『制御部の構成』制御部９は、入出力イン
タフェイス部８を介したユーザからの指示に従って、シ
ステムＬＳＩ開発装置１内の構成要素の制御を行う。

【００８６】《システムＬＳＩ開発装置の動作》次に、
上記のシステムＬＳＩ開発装置を用いたシステムＬＳＩ
開発処理について説明する。

【００８７】上記のシステムＬＳＩ開発装置を用いてシ
ステムＬＳＩ開発を行う際には、ユーザは、まず始め
に、キャッシュサイズ等、性能に関して最大のコンフィ
グレーションをシステムＬＳＩ開発装置１に対して入力
する（Ｓ１０１）。コンフィグレーションが入力される
と、装置１内のシステムＬＳＩ開発環境生成部４が、コ
ンフィグレーションの可能な全ての組み合わせに対応し
たツールを生成し（Ｓ１０２）、ツール生成完了に応じ
てユーザはアプリケーションを実行させる（Ｓ１０
３）。そして、アプリケーション実行後、性能評価部５
が、アプリケーションの実行結果を参照して、アプリケ
ーションの性能を評価する（Ｓ１０４）。

【００８８】性能評価部５による性能評価が完了する
と、次に、終了判定部６が、最初のコンフィグレーショ
ンによる性能が所望の基準に達しているか否かを判別し
（Ｓ１０５）、達している場合には、性能を満足する最
小のシステム構成を抽出し（Ｓ１０８）、検証環境およ
びドキュメントをユーザに対して出力する（Ｓ１０
９）。ここで、ドキュメントには、指定されたコンフィ
グレーションを確認するための項目についての記述が含
まれているものとする。

【００８９】一方、性能が足りていない場合には、ユー
ザは、ユーザ定義のモジュールを設計し、開発ツール内
に組み込み（Ｓ１０６）、ユーザ定義モジュールを利用
するようにアプリケーションを書き換える（Ｓ１０
７）。そして、再びアプリケーションを実行し、書き換
えたアプリケーションが所望の性能を満たしているか否
かを判別する。

【００９０】（ユーザ定義モジュールの追加する処理の
例）ここで、ユーザ定義モジュールとしてＤＳＰを追加
する処理を例として挙げ、上記のユーザ定義モジュール
を追加する際の処理について説明する。なお、この例に
おいては、アプリケーションとして、メモリよりデータ
を読み出し、計算を行い、結果を書き戻すという処理を
繰り返し実行するものを考える。

【００９１】この例においては、プロセッサのみを用い
てアプリケーションの処理を実行すると、アプリケーシ
ョンでは、プロセッサの命令を使用して、図１５(ａ)に
示すようなプログラムを実行する。しかし、このままで
は目標性能を達成することはできないので、ユーザ定義
モジュールとして、計算を行うＤＳＰを追加する。ここ
で、ＤＳＰは制御バスによって制御され、コアのプロセ
ッサは制御バスにＤＳＰの制御のための数値を書き込め
ば良い。なお、この処理はＤＳＰ命令を定義して使用す
ることも可能であるが、ここでは、制御バスでＤＳＰの
実行を制御することとする。なお、図１５（ａ）中の_c
ulcは演算処理を行うサブルーチンを示す。

【００９２】また、ユーザ定義モジュールとして追加さ
れたＤＳＰは、図１５（ｂ）に示すプログラムに従って
動作する。すなわち、制御バスのcntlbus_addr1のアド
レスに、計算用のデータの開始アドレスをおき、cntlbu
s_addr2に計算用のデータの終了アドレスを置く。ま
た、cntlbus_addr3は、計算結果を収めるメモリの位置
の値を置く。cntlbus_addr4では、このアドレスに書き
込むことにより、ＤＳＰの動作の制御が行われる。具体
的には、このアドレスのあるビットに１を書き込むこと
により、ＤＳＰの処理を開始したり、停止したりする。
処理が開始されると、ＤＳＰは、開始アドレスや終了ア
ドレス、書き込み先のアドレスを決められた場所（cntl
bus_addr1,cntlbus_addr2,cntlbus_addr3）に読みにい
き、処理を開始する。

【００９３】ＤＳＰのようなユーザ定義モジュールを追
加する方法としては、以下の２つの方法が考えれる。す
なわち、（１）ユーザ定義モジュールの仕様として、動
作記述とＲＴＬ記述の双方を作成し、ユーザ定義モジュ
ール・ユーザ定義命令記憶部３内に格納する、又は、
（２）動作記述のみを作成し、ＲＴＬ生成部４１内の高
位合成処理部４１ｅにおいて、動作記述からＲＴＬ記述
を生成する。

【００９４】ここで、図１５（ｃ），１６を参照して、
上記の動作記述について説明する。図１５（ｃ）内のDS
P_HWEngineは、HWEngineの性質とcontrolbusの性質を有
し、クラスの定義をすることにより、動作モデルは、DS
PをHWEngineと認識する。また、コントロールバスにＤ
ＳＰ開始等の書き込みをした場合には、図１６に示すプ
ログラムに従って、DSP_HWEngineのwrite_controlbusが
呼び出され、ＤＳＰの処理を開始する。また、ユーザが
ＤＳＰに対して命令を記述したい時には、ＭＰＩのコン
フィグレーション時にユーザ定義の命令を記述市、コン
フィグレーション情報を受け取ったシステムＬＳＩ開発
装置が命令定義ヘッダファイルを作成し、コンパイラに
与える。コンパイラは、コンパイル処理を実行し、ユー
ザ定義命令の入った実行オブジェクトを出力する。な
お、シミュレータやＲＴＬにおいてその動作を実行する
ためには、その動作記述を与える必要性がある。また、
図１６に示す動作記述では、DSP_HWEngineクラスの中に
do_command関数に命令毎に記述を行う。

【００９５】上記のようにして追加されたユーザ定義モ
ジュールを用いて性能評価を行う。そして、追加したモ
ジュールが性能を満たしていれば終了。満たしていなけ
れば、さらにユーザ定義モジュールを作成し、追加す
る。ソフトウェアの性能評価は、ユーザアプリケーショ
ンを実行し、目標性能を満たしているか否かを調べる。
ハードウェアの性能評価は、コアプロセッサとユーザ定
義モジュールとを接続したＲＴＬ記述を論理合成し、ゲ
ート数計算、タイミング解析、消費電力解析等を実行す
る。ハードウェア検証は、ユーザが手書によって与えた
ベクトル、又は、検証用のベクトルを生成するツールを
使用して作成したベクトル等を用いて、コアとユーザモ
ジュールから成る動作モデル（シミュレータ）のベクト
ル実行結果とＲＴＬシミュレーションの結果が一致して
いるかどうかで行う。

【００９６】（マルチプロセッサ構成の処理例）以上の
説明においては、システム内にプロセッサを１つ設ける
例であったが、当然のことながら、システム内にプロセ
ッサを複数設け、マルチプロセッサ構成を構築すること
が可能である。このマルチプロセッサ構成においては、
オプション命令やキャッシュサイズ等の可変設定項目は
各プロセッサ毎に独立して設定することが可能である。
以下では、図１７，１８を参照して、マルチプロセッサ
構成の処理例について説明する。

【００９７】圧縮されたデータの復元処理やデータのデ
ィスプレイ表示処理等、近年の傾向としては、ハードウ
ェアで行っていた処理もコスト面や速度面からソフトウ
ェアで代用できるようになり、ソフトウェアの処理の割
合が増し、複雑化してきている。このような、複雑なア
プリケーションがターゲットである場合、１つのプロセ
ッサにユーザ定義モジュールを定義したり、コプロセッ
サをつけたりしても、目標性能を満たしそうにない時
は、マルチプロセッサ構成を採用する。また、速度向上
のためにコプロセッサをつけた場合でも、コプロプロセ
ッサへのロード等、コアプロセッサが行う処理は多い。
また、明らかに１プロセッサでは処理不可能な場合もあ
る。そのような場合は、複数のプロセッサでアプリケー
ションを実行することを考える。

【００９８】ここで、圧縮されたデータストリームを
（１）受信、（２）復元、（３）ディスプレイ表示用に
加工、（４）データ出力するというアプリケーションを
考える。ストリームの処理は、処理時間が決まっている
ので、まず、処理速度が大切である。これらを１つのプ
ロセッサで行った場合、複数の処理＋コプロセッサやユ
ーザ定義モジュールへの制御も行わなければならず、ど
うやっても目標性能を得ることができない。このような
場合、処理毎にプロセッサを割り当て、処理を分散させ
ると良い。例として、プロセッサ１で（１）と（４）の
処理、プロセッサ２で（２）の処理、プロセッサ３で
（３）というように処理を分散させることができる。ま
た、オプション命令やキャッシュ等も、例えば、プロセ
ッサ１は、命令キャッシュ無し、データキャッシュ無
し、オプション命令無し、プロセッサ２は、命令キャッ
シュ２ＫＢ、データキャッシュ１ＫＢ、ユーザ定義モジ
ュールとしてのＤＳＰ付き、コプロセッサ無し、プロセ
ッサ３は、命令キャッシュ２ＫＢ、データキャッシュ無
し、コプロセッサ有りというように、プロセッサ毎に設
定することができる。すなわち、今まで述べてきた、１
つのプロセッサへの可変項目設定を複数のプロセッサに
ついても行うことができる。そして、３つのプロセッサ
を使ってそれぞれの処理を行うアプリケーションで、そ
れぞれのプロセッサに対する、最小構成を求めることに
より、最適なＬＳＩを構築することができる。例えば、
最初、全てのプロセッサの命令キャッシュ、データキャ
ッシュを４ＫＢとしていたが、性能評価の結果、上記の
ような構成で目標性能が得られということがわかる等、
それぞれの可変項目について、性能評価からのフィード
バックを得ることができる。

【００９９】マルチプロセッサ構成のＬＳＩは、シング
ルプロセッサ構成の時と同様、コンフィグレーションを
指定することにより、システムＬＳＩ開発環境を生成す
ることができる（ただし、ユーザ定義モジュールがある
場合には動作記述を作成する必要がある）。コンパイラ
はマルチプロセッサに対しての変更はないが、個々のプ
ロセッサに対して１対１にコンパイラが生成される。シ
ミュレータ、デバッガ等は、マルチプロセッサに対応し
ているものが生成される。システムＬＳＩ開発環境がど
のようにしてマルチプロセッサのシミュレータを生成で
きるかであるが、これも、シングルプロセッサの時と同
様、プロセッサの設定や生成をコア毎にテンプレートを
使用して設定用の関数を生成する（図１７，１８に示す
プログラムコードがシミュレータ生成用のテンプレート
を使用して生成されたものである。なお、図１７(ａ)に
示すコードはシミュレータのコア用のクラスの例であ
る）。コア毎に生成された設定関数（図１７（ｂ））を
モジュール組み立ての関数（図１８(ａ)）がコールす
る。ここもコンフィグレーションによって呼ばれる関数
の数が異なってくるので、テンプレートを使用して生成
される。また、シミュレータを実行する部分は、図１８
（ｂ）に示すように、１クロック又は１ステップ（１命
令）実行のためコールされる関数中に、それぞれのプロ
セッサの１クロック又は１ステップ実行部分の関数がコ
ールされるようにされている。

【０１００】また、アプリケーションでは、プロセッサ
間の通信処理等も必要になるが、共有メモリやプロセッ
サ間ハードウェア割り込みや、ハードウェアセマフォ等
がある。上記のアプリケーションでは、計算が終了した
データをメモリに書き込み、他のコアとやり取りした
り、処理が終了したことをあるコアに知らせるために、
そのコアに対してハードウェア割り込みを起こしたり、
資源の競合を防ぐために、セマフォを利用したりする。
ＲＴＬもシミュレータと同様にテンプレートがあり、コ
アの個数の応じて、ＲＴＬ記述が生成される。

【０１０１】このように、この実施の形態のシステムＬ
ＳＩ開発装置においては、システムＬＳＩの設計上のコ
ンフィグレーションを１つのデータベース内に保持し、
このデータベース内の情報を参照して、ＲＴＬ記述、開
発ツールおよび検証環境の全てを一貫して生成するの
で、コンフィグレーションの変更に伴う再設計に要する
労力および時間を大幅に削減することができる。また、
このような構成によれば、設計→評価のプロセスを比較
的短時間に繰り返し、ユーザの目的に適した構成のシス
テムを容易に得ることが可能となる。さらには、最初に
最大構成の設定から評価を行うことにより、ユーザ定義
モジュールの必要性を判断し、システムＬＳＩの設計に
早期に着手することが可能となる。

【０１０２】《その他の実施の形態》本発明の実施の形
態のシステムＬＳＩ開発装置には、いわゆる汎用機、ワ
ークステーション、ＰＣ（Personal Computer）、ＮＣ
（Network Computer）等が含まれ、例えば、図１８に示
す構成のような概観を有し、フロッピー（登録商標）デ
ィスクドライブ５２および光ディスクドライブ５４を備
えている。そして、フロッピーディスクドライブ５２に
対してはフロッピーディスク５３、光ディスクドライブ
５４に対しては光ディスク５５を挿入し、所定の読み出
し操作を行うことにより、これらの記録媒体に格納され
たプログラムをコンピュータシステム内にインストール
することができる。また、所定のドライブ装置５７を接
続することにより、例えば、メモリ装置の役割を担うＲ
ＯＭ５８や、磁気テープ装置の役割を担うカートリッジ
５９を用いて、インストールやデータの読み書きを実行
することもできる。

【０１０３】また、本発明の実施の形態のシステムＬＳ
Ｉ開発装置は、プログラム化しコンピュータ読取り可能
な記録媒体に保存しても良い。そして、システムＬＳＩ
開発処理を行う際は、この記録媒体をコンピュータシス
テムに読み込ませ、コンピュータシステム内のメモリ等
の記憶部にプログラムを格納し、システムＬＳＩ開発プ
ログラムを演算装置で実行することにより、本発明のシ
ステムＬＳＩ開発装置およびその方法を実現することが
できる。なおここで言う記録媒体とは、例えば、半導体
メモリ、磁気ディスク、光ディスク、光磁気ディスク、
磁気テープ、伝送媒体等のプログラムを記録することが
できるようなコンピュータ読取り可能な記録媒体等が含
まれる。

【０１０４】《実施の形態の効果》以上述べてきたよう
に、この実施の形態のシステムＬＳＩ開発装置によれ
ば、オプション命令、ユーザ定義モジュールおよびマル
チプロセッサ構成の少なくとも１つを含む可変項目定義
情報の可能な全ての組み合わせについて、オプション命
令が定義されたプロセッサを含むシステムＬＳＩのハー
ドウェア、検証環境、開発ツールを一貫して網羅的／複
数並列に作成するので、アプリケーションに最適なシス
テムＬＳＩを短期間に開発することが可能となる。

【０１０５】また、１箇所で指定されたコンフィグレー
ションを各ツールで共有し、コンフィグレーションの可
能な組み合わせについて、システムＬＳＩのハードウェ
ア、検証環境、開発ツールを一貫して網羅的／複数並列
に作成するので、ツール間の連携をとることが可能とな
り、システムＬＳＩの開発期間を短縮することができ
る。また、マルチプロセッサシステムを構築する場合に
は、全てのハードウェアのローカルメモリ情報を一括し
て保持し、各プロセッサのローカルメモリマップを他の
プロセッサのローカルメモリへのアクセス領域を含めて
生成するので、システムＬＳＩ中に複数のプロセッサを
含めることが可能となる。

【０１０６】また、コンフィグレーションの各組み合わ
せについて、並列に性能評価を実行するので、人手によ
る各ツール出力の評価集約を行う必要がなくなり、シス
テムＬＳＩの開発期間を短縮することが可能となる。ま
た、アプリケーションのコードサイズ、実行命令数、実
行サイクル数、チップのゲートサイズ、消費電力を見積
もる機能を有し、見積もった性能と目標性能とを比較し
て評価するので、性能評価に要する労力を軽減し、シス
テムＬＳＩ開発期間の短縮を実現することが可能とな
る。

【０１０７】また、コンフィグレーション項目の設定を
対話的に行うことができるので、ユーザは設定ファイル
の文法を意識せずにコンフィグレーションを設定するこ
とが可能となり、直接設定ファイルを記述する場合と比
べて短時間に設定を行うことができる。また、全てのコ
ンフィグレーション項目の設定を対話的に行うことがで
きるので、コンフィグレーション項目の設定のし忘れの
防止にもなる。

【０１０８】また、コンパイラカスタマイズ部４３がコ
ンパイラを生成するので、目的アプリケーションのコー
ドサイズを知ることができ、システムＬＳＩの開発期間
を短縮することが可能となる。

【０１０９】また、シミュレータカスタマイズ部４２が
シミュレータを生成するので、目的アプリケーションの
性能を短時間で知ることができ、システムＬＳＩの開発
期間を短縮することができる。

【０１１０】また、性能評価部５がアプリケーションの
実行サイクル数を抽出するので、ユーザは、ＬＳＩの性
能が足りているのか、不足しているのかを容易に知るこ
とができ、コンフィグレーション項目の速やかな変更に
つながり、システムＬＳＩの開発期間を短縮することが
できる。

【０１１１】また、性能評価部５がゲートサイズを抽出
するので、最適なチップ面積を決定し、ＬＳＩ製造時の
コストを抑えることが可能となる。

【０１１２】さらに、ユーザが指定した可変値に基づい
てコンフィグレーションの設定およびその性能評価を行
うことができるので、複数の設定値に対応した結果を同
時に得ることが可能となり、ＬＳＩ開発サイクルの短縮
を実現することができる。

【０１１３】さらにまた、システムＬＳＩ開発上の最優
先項目を指定することができるので、構成を考えること
なく、優先項目に適した構成の見積を得ることができ
る。

【０１１４】また、メモリ領域をアクセスサイクルで複
数の領域に分類し、各領域に対して統計情報を持たせる
ので、より正確な見積を得ることができる。

【０１１５】また、目標性能を設定することができるの
で、目標性能に沿った見積を速やかに導出することがで
きる。また、アプリケーションが目標性能に到達しなか
った場合には、アプリケーションの実行時に記録した情
報に基づいてコンフィグレーション項目を変更（フィー
ドバック）するので、目標性能にあった構成を抽出する
ことが可能となる。さらに、自動変更されたコンフィグ
レーション項目に基づいて開発環境、検証環境を再度生
成し、アプリケーションの実行性能を測定しし、目標性
能と比較することで設定変更の妥当性を判断することが
できる。さらにまた、妥当性を判断した結果、設定変更
が妥当でないと判断された場合には、再度、コンフィグ
レーション項目を自動的に変更、アプリケーションの実
行性能の再測定、コンフィグレーション項目の設定変更
の妥当性を判断するので、変更を有限回数行うことがで
きる。これにより、システムＬＳＩ開発の工期を短縮す
ることができる。

【０１１６】

【発明の効果】本発明によれば、最適な性能のＬＳＩを
開発設計することができる。

【図面の簡単な説明】

【図１】本発明の実施の形態のシステムＬＳＩ開発装置
の構成を示すブロック図である。

【図２】本発明の実施の形態の設定ファイル生成部の構
成を示すブロック図である。

【図３】本発明の実施の形態のコンフィグレーションフ
ァイルを示す図である。

【図４】本発明の実施の形態のグローバルメモリマッ
プ、ローカルメモリマップおよびユーザ定義命令を示す
図である。

【図５】本発明の実施の形態のシステムＬＳＩ開発環境
生成部の構成を示すブロック図である。

【図６】本発明の実施の形態のＲＴＬ生成部の動作を説
明するための図である。

【図７】本発明の実施の形態のＲＴＬ生成部の動作を説
明するための図である。

【図８】本発明の実施の形態のシミュレータカスタマイ
ズ部の動作を説明するための模式図である。

【図９】本発明の実施の形態のシミュレータ起動オプシ
ョンファイル、デバッガ起動オプションファイルおよび
機械命令関数宣言ヘッダファイルを示す図である。

【図１０】本発明の実施の形態のコンパイラカスタマイ
ズ部の動作を説明するための模式図である。

【図１１】本発明の実施の形態のコンパイラ起動オプシ
ョンファイルおよび検証ベクトル生成用ユーザ定義命令
ファイルを示す図である。

【図１２】本発明の実施の形態のアプリケーションプロ
グラムを示す図である。

【図１３】実行命令数、実行サイクル数およびキャッシ
ュミス率を示す図である。

【図１４】本発明の実施の形態のシステムＬＳＩ開発装
置を用いたシステムＬＳＩ開発処理を示すフローチャー
ト図である。

【図１５】アプリケーションのプログラム例および動作
記述例を示す図である。。

【図１６】動作記述の例を示す図である。

【図１７】プログラムコードの例を示す図である。

【図１８】プログラムコードの例を示す図である。

【図１９】本発明の実施の形態のシステムＬＳＩ開発装
置の概観を示す模式図である。

【符号の説明】

１システムＬＳＩ開発装置２設定ファイル生成部３ユーザ定義モジュール・ユーザ定義命令記憶部３４システムＬＳＩ開発環境生成部５性能評価部６終了判定部７変更項目設定部８入出力インタフェイス部９制御部１０入力部１１出力部２１入力解析部２２ローカルメモリマップ生成部２３オプション情報記憶部２４デバイス構成記憶部２５キャッシュ構成記憶部２６ローカルメモリマップ記憶部４１ＲＴＬ生成部４１ａ、４１ｂＲＴＬテンプレート４１ｃコアＲＴＬ記述４１ｄブロック接続部４１ｅ高位合成処理部４２シミュレータカスタマイズ部４２ａオプション命令・Ｃモデルテンプレート４２ｂシミュレータテンプレート４２ｃ再コンパイル部４２ｄ起動オプション情報抽出部４２ｅ組み合わせ処理部４３コンパイラカスタマイズ部４３ａオプション命令情報抽出部４３ｂオプション命令・機械命令関数宣言テンプレー
ト４３ｃ機械命令関数宣言抽出部４３ｄ結合処理部４４アセンブラカスタマイズ部４５検証ベクトル生成部５０コンピュータシステム５１ディスプレイ５２フロッピーディスクドライブ５３フロッピーディスク５４光ディスクドライブ５５光ディスク５６キーボード５７ドライブ装置５８ＲＯＭ５９カートリッジ

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩテーマコート゛(参考）Ｇ０６Ｆ 11/26 Ｇ０６Ｆ 11/26 (72)発明者大山隆一郎神奈川県川崎市幸区小向東芝町１番地株式会社東芝マイクロエレクトロニクスセンター内 (72)発明者丹後田愛神奈川県川崎市幸区小向東芝町１番地株式会社東芝マイクロエレクトロニクスセンター内 (72)発明者内田勝也神奈川県川崎市幸区小向東芝町１番地株式会社東芝マイクロエレクトロニクスセンター内Ｆターム(参考） 5B046 AA08 BA02 JA04 5B048 AA17 AA20 DD14

Claims

【特許請求の範囲】

【請求項１】オプション命令が定義されたプロセッサ
を含むシステムＬＳＩの開発設計に利用されるコンピュ
ータシステム上で動作する複数のソフトウェアから成る
システムＬＳＩ開発装置であって、システムＬＳＩの開発設計に関わる可変項目定義情報に
基づいて前記ソフトウェアを動作させ、システムＬＳＩ
のハードウェア記述、検証環境および開発設計ツールを
生成するシステムＬＳＩ開発環境生成部を具備し、前記可変項目定義情報は、オプション命令情報、ユーザ
定義モジュールおよびマルチプロセッサ構成に関する情
報の少なくとも１つを含むことを特徴とするシステムＬ
ＳＩ開発装置。
【請求項２】ユーザ定義モジュールが指定された際に
は、ユーザ定義モジュールの仕様に対応するハードウェ
ア記述と前記プロセッサとを接続することにより、前記
システムＬＳＩのハードウェア記述を生成することを特
徴とする請求項１に記載のシステムＬＳＩ開発装置。
【請求項３】前記ユーザ定義モジュールの仕様に対応
するハードウェア記述は、ユーザ定義モジュールの仕様
に対応する動作記述を高位合成することにより生成する
ことを特徴とする請求項２に記載のシステムＬＳＩ開発
装置。
【請求項４】マルチプロセッサ構成が指定された際に
は、プロセッサ毎にハードウウェア記述を生成し、当該
ハードウェア記述をバスで接続したハードウェア記述を
生成することを特徴とする請求項１〜請求項３いずれか
１項に記載のシステムＬＳＩ開発装置。
【請求項５】前記設定ファイル生成部内に格納された
可変項目定義情報の可能な全ての組み合わせについて、
アプリケーションの性能を並列に評価する性能評価部を
具備することを特徴とする請求項１〜４いずれか１項に
記載のシステムＬＳＩ開発装置。
【請求項６】前記性能評価部は、アプリケーションの
コードサイズ、実行命令数、実行サイクル数、チップの
ゲートサイズおよび消費電力の少なくとも１つを評価す
ることを特徴とする請求項５に記載のシステムＬＳＩ開
発装置。
【請求項７】前記性能評価部による性能評価結果に基
づいて、前記可変項目定義情報を変更する変更項目設定
部を具備することを特徴とする請求項１〜請求項６いず
れか１項に記載のシステムＬＳＩ開発装置。
【請求項８】前記可変項目定義情報には、ユーザ定義
の命令に関する情報、デバイスのオン／オフ情報、デバ
イスのアドレス情報、デバイスのサイズ情報およびキャ
ッシュのサイズ情報に関する情報の少なくとも１つが含
まれることを特徴とする請求項１〜請求項７いずれか１
項に記載のシステムＬＳＩ開発装置。
【請求項９】オプション命令が定義されたプロセッサ
を含むコンピュータシステム上で動作する複数のソフト
ウェアを利用してシステムＬＳＩを開発設計するシステ
ムＬＳＩ開発方法であって、システムＬＳＩの開発設計に関わる可変項目定義情報を
入力するステップと、入力された可変項目定義情報に基づいて前記ソフトウェ
アを動作させ、システムＬＳＩのハードウェア、検証環
境および開発設計ツールを生成するステップとを有し、前記可変項目定義情報は、オプション命令情報、ユーザ
定義モジュールおよびマルチプロセッサ構成に関する情
報の少なくとも１つを含むことを特徴とするシステムＬ
ＳＩ開発方法。
【請求項１０】ユーザ定義モジュールが指定された際
には、ユーザ定義モジュールの仕様に対応するハードウ
ェア記述と前記プロセッサとを接続することにより、前
記システムＬＳＩのハードウェア記述を生成することを
特徴とする請求項９に記載のシステムＬＳＩ開発方法。
【請求項１１】前記ユーザ定義モジュールの仕様に対
応するハードウェア記述は、ユーザ定義モジュールの仕
様に対応する動作記述を高位合成することにより生成す
ることを特徴とする請求項１０に記載のシステムＬＳＩ
開発方法。
【請求項１２】マルチプロセッサ構成が指定された際
には、プロセッサ毎にハードウウェア記述を生成し、当
該ハードウェア記述をバスで接続したハードウェア記述
を生成することを特徴とする請求項９〜請求項１１いず
れか１項に記載のシステムＬＳＩ開発方法。
【請求項１３】入力された可変項目定義情報の可能な
全ての組み合わせについて、アプリケーションの性能を
並列に評価するステップを有することを特徴とする請求
項９〜請求項１２いずれか１項に記載のシステムＬＳＩ
開発方法。
【請求項１４】前記評価処理において、アプリケーシ
ョンのコードサイズ、実行命令数、実行サイクル数、チ
ップのゲートサイズおよび消費電力の少なくとも１つを
評価することを特徴とする請求項１３に記載のシステム
ＬＳＩ開発方法。
【請求項１５】前記性能評価結果に基づいて、前記可
変項目定義情報を変更するステップを有することを特徴
とする請求項９〜請求項１４いずれか１項に記載のシス
テムＬＳＩ開発方法。
【請求項１６】前記可変項目定義情報には、ユーザ定
義の命令に関する情報、デバイスのオン／オフ情報、デ
バイスのアドレス情報、デバイスのサイズ情報およびキ
ャッシュのサイズ情報に関する情報の少なくとも１つが
含まれることを特徴とする請求項９〜請求項１５いずれ
か１項に記載のシステムＬＳＩ開発方法。