JP2005157849A - システムｌｓｉ設計装置、システムｌｓｉ設計用処理プログラム、及び整合性検証方法 - Google Patents

Abstract

【課題】 構成変更可能なプロセッサを含むシステムＬＳＩの設計装置における一連の処理プログラム（設計ツール）の整合性を保つこと。
【解決手段】 目的に応じて構成変更可能なプロセッサを含むシステムＬＳＩの設計に用いられる一連の処理プログラムからなり、各処理プログラムは、先行する処理プログラムが出力するファイルを入力し、後続の処理プログラムの入力となるファイルを出力するように構成される。各処理プログラムは、（ａ）処理プログラム間の整合性情報を記憶する整合性情報記憶部、（ｂ）入力したファイルに含まれる整合性情報を識別する整合性情報識別部、（ｃ）識別した整合性情報と整合性情報記憶部に記憶された整合性情報とを比較して整合性が保たれているか否かを検証する整合性情報検証部、（ｄ）出力するファイルに整合性情報を付加して出力する整合性情報付加部を備える。
【選択図】 図１

Description

本発明は、目的に応じて構成変更可能なプロセッサを含むシステムＬＳＩの設計装置、システムＬＳＩ設計用処理プログラム、及び整合性検証方法に係り、特に、システムＬＳＩ設計装置に用いられる一連の処理プログラムの整合性を保つための技術に関する。

従来、目的に応じて命令を追加したり、構成を変更したりできるプロセッサを搭載したＳｏＣ（System on Chip）などのシステムＬＳＩ設計では、設計者は、開発対象のシステムに求められるアルゴリズムをＣ言語などのプログラミング言語で記述して、上位レベルでのシステムシミュレーションを行って、システムとしての機能の確認を行うことが不可欠になっている。

具体的には、図１１に示すように、プログラミング言語でアルゴリズムをソースプログラムとして記述し（ステップS901）、搭載するプロセッサの構成を選択して、コンパイラやシミュレータ等の処理プログラム（設計ツール）を生成し（ステップS902）、ソースプログラムのコンパイルやシミュレーション等を実行し（ステップS903）、所望する性能を達成したか否かを検証する（ステップS904）。

検証の結果、所望の性能を達成していない場合は、評価すべきプロセッサの構成の組み合わせが残っていたら（ステップS905）、ステップS902へ戻って、プロセッサの構成の選択から再実行する（ステップS902〜S904）。評価すべきプロセッサの構成の組み合わせ全てについて選択が終了していたら、ハードウェア化すべき（ボトルネックとなっている）箇所を選択し、ソースプログラムに記述された機能のうちハードウェアに置き換える部分を分割する（ステップS906）。そして、ソースプログラムのコンパイルやシミュレーション等を実行して（ステップS907）、所望の性能が達成されたか否かを検証する（ステップS908）。検証の結果、所望の性能を達成していない場合は、アルゴリズム選択を含め再設計し、ステップS901に戻る。

ステップS908もしくはステップS904検証の結果、所望の性能が達成された場合は、ソフトウェアのチューニング、高位合成、人手による設計等、実装するための作業が行われる（ステップS910）。

ここで、上記ステップS903あるいはステップS907の処理においては、一般に、複数の段階からなる処理手順（例えば、コンパイル、アセンブル、リンケージ、シミュレーション等の複数の処理プログラム）を経て行われる。各段階における処理プログラム（設計ツール）は、前の段階の処理プログラムで生成されたデータ（ファイル）を入力するとともに、各段階の目的に応じて、必要なデータを入力したり、設定された起動オプションを入力したりして、データを処理する。

各段階において処理プログラムによるデータ処理が正常に終了し、処理結果がターゲットとなるシステムＬＳＩの仕様を満たしていれば、この処理プログラムが生成したデータ（ファイル）を用いて、次の段階の処理プログラム（設計ツール）がデータ処理を実行する。処理プログラムによるデータ処理でエラーを検出したり、処理結果がターゲットとなるシステムＬＳＩの仕様を満たしていないことが見込まれたりするときには、必要に応じて前段階に戻って、入力データ等の修正などを行い、処理プログラムを再実行する。

このように、設計のためのデータは複数の処理プログラム（設計ツール）により順次処理されて設計が行われるが、特に、構成変更可能なプロセッサを含むシステムＬＳＩの設計の場合、例えば、キャッシュメモリサイズやオプション命令の有無など選択するプロセッサの構成を変更した際には、それに応じて各処理プログラム（設計ツール）も変更する必要がある。

そこで、プロセッサの構成を変更した後に、その構成に応じて一貫して処理可能な設計ツール群を生成するシステムＬＳＩ設計装置が開示されている（例えば、特許文献１参照）。
特開２００２−２３００６５号公報

このような従来の設計装置を用いてシステムＬＳＩを設計する場合、図１１に示したフローチャートのステップS902〜ステップS905の処理手順（あるいはステップS906〜ステップS908の処理手順）により、システムＬＳＩの仕様が記述されたソースプログラムの機能や性能を検査し、評価する。

この段階で、コンフィグレーション情報により指定される構成の異なるプロセッサでの検査や評価が行われるため、図１２に例示するように、コンフィギュレーション毎にそれぞれ異なる処理プログラム（設計ツール）群が生成され用いられることになる。ところが、こうした検査や評価といった作業は、しばしば複数の人員で分担して行われるため、処理プログラム（設計ツール）の変更に伴う作業者間の連絡が滞りがちになる。そのため、図１４に例示するように、ソースプログラム（foo.c）をコンパイルするためのコンパイラ（C([A]T1-001)）のコンフィグレーション情報［A］と、コンパイル結果（foo.s）をアセンブルするためのアセンブラ（A([B]T1-1a)）のコンフィグレーション情報［B］が異なるといったミスが発生し、その結果、正しく実行されずに実行エラーや誤動作を引き起こしてしまう。

また、図１３に例示するように、例えば、性能向上やバグ対策等のために処理プログラム（設計ツール）群を生成する生成ツールのバージョン（Ver. T1）を新たなバージョン（Ver. T2）に更新したといったケースでも、図１５に例示するように、コンパイラ（C([A]T1-001)）、アセンブラ（A([A]T1-1a)）、リンカ（L([A]T1-10)）のバージョン（Ver. T1）と、シミュレータ（S([A]T2-X)）のバージョン（Ver. T2）とが食い違ったまま実行してしまうといったミスが発生すると、その結果、実行エラーや誤動作に陥ってしまう。

このように、構成変更可能なプロセッサを含むシステムＬＳＩを設計する場合、選択するプロセッサの構成変更等に伴って、処理プログラム（設計ツール）群が数多く生成され、実行環境に応じて使い分ける必要があるため、バージョンや環境等の管理などに多大なコストや時間が掛かるといった問題があった。また、上記のように、誤ったバージョンの処理プログラム（設計ツール）を実行した場合、実行エラーや誤動作が生じるため、その原因の解明や再実行などに要するコストや時間も多大な負担となっていた。

本発明は、このような問題に鑑みてなされたものであって、構成変更可能なプロセッサを含むシステムＬＳＩの設計装置における一連の処理プログラム（設計ツール）の整合性を保つことができるシステムＬＳＩ設計装置、システムＬＳＩ設計用処理プログラム、及び整合性検証方法を提供することを目的とする。

上記課題を解決するため、本発明に係るシステムＬＳＩ設計装置の特徴は、目的に応じて構成変更可能なプロセッサを含むシステムＬＳＩの設計に用いられる一連の処理プログラムからなり、各処理プログラムは、先行する処理プログラムが出力するファイルを入力し、後続の処理プログラムの入力となるファイルを出力するように構成されるシステムＬＳＩ設計装置であって、処理プログラムは、（ａ）各処理プログラム間の整合性情報を記憶する整合性情報記憶部と、（ｂ）入力したファイルに含まれる整合性情報を識別する整合性情報識別部と、（ｃ）識別した整合性情報と整合性情報記憶部に記憶された整合性情報とを比較して整合性が保たれているか否かを検証する整合性情報検証部と、（ｄ）出力するファイルに整合性情報を付加して出力する整合性情報付加部とを備えることにある。

また、本発明に係るシステムＬＳＩ設計用処理プログラムの特徴は、目的に応じて構成変更可能なプロセッサを含むシステムＬＳＩの設計装置に用いられる一連の処理プログラムであって、先行する処理プログラムが出力するファイルを入力し、後続の処理プログラムの入力となるファイルを出力するように構成され、（ａ）入力したファイルに整合性情報が含まれているか否かを識別する処理と、（ｂ）識別した整合性情報と予め処理プログラム毎に記憶していた整合性情報とを比較して、整合性が保たれているか否かを検証する処理と、（ｃ）出力するファイルに整合性情報を付加して出力する処理とを含む処理をシステムＬＳＩの設計装置に実行させることにある。

また、本発明に係る整合性検証方法の特徴は、目的に応じて構成変更可能なプロセッサを含むシステムＬＳＩの設計装置に用いられる一連の処理プログラムの整合性を検証する方法であって、（ａ）先行する処理プログラムが出力したファイルを入力し、入力したファイルに整合性情報が含まれているか否かを識別する段階と、（ｂ）識別した整合性情報と予め処理プログラム毎に記憶していた整合性情報とを比較して、整合性が保たれているか否かを検証する段階と、（ｄ）後続の処理プログラムの入力となるファイルに整合性情報を付加して出力する段階とを含むことにある。

本発明によれば、構成変更可能なプロセッサを含むシステムＬＳＩの設計装置で用いられる、一連の処理プログラムの整合性を保つことができるシステムＬＳＩ設計装置、システムＬＳＩ設計用処理プログラム、及び整合性検証方法を提供することができる。

以下、本発明の実施形態を図面に基づいて説明する。尚、各図面を通じて同一もしくは同等の部位や構成要素には、同一もしくは同等の参照符号を付し、その説明を省略もしくは簡略化する。

［システムＬＳＩ設計装置の構成］
本実施形態におけるシステムＬＳＩ設計装置は、ターゲットシステムに応じて、命令を追加したり、構成（コンフィグレーション）を変更したりすることができる構成変更可能なプロセッサ（コンフィグラブル・プロセッサ）を含むシステムＬＳＩ等を設計するための設計装置であり、例えば、中央処理装置、記憶装置、入力装置、出力装置などを備えたコンピュータシステムにより実現される。

図１に示すように、本実施形態におけるシステムＬＳＩ設計装置は、目的に応じて構成変更可能なプロセッサを含むシステムＬＳＩの設計に用いられる一連の処理プログラム（設計ツール）２０ａ，２０ｂ，…，２０ｎを含んでいる。各処理プログラム２０ａ，２０ｂ，…，２０ｎは、プロセッサの構成を指定するコンフィグレーション情報１１とテンプレート１２に基づいて設計ツール生成ソフト１０により生成される。

各処理プログラム２０ａ，２０ｂ，…，２０ｎは、先行する処理プログラムが出力するファイルを入力し、後続の処理プログラムの入力となるファイルを出力するように構成される。例えば、処理プログラム２０ａは、設計データ２２ａ（及び整合性情報２３ａ）を入力して、後続の処理プログラム２０ｂの入力となる設計データ２２ｂ及び整合性情報２３ｂを出力する。処理プログラム２０ｂは、先行する処理プログラム２０ａが出力した設計データ２２ｂ及び整合性情報２３ｂを入力して、後続の処理プログラム（図示せず）の入力となる設計データ２２ｃ及び整合性情報２３ｃを出力する。同様に、処理プログラム２０ｎは、先行する処理プログラム（図示せず）が出力した設計データ及び整合性情報（図示せず）を入力して、設計データ２２ｍ及び整合性情報２３ｍを出力する。

また、各処理プログラム２０ａ，２０ｂ，…，２０ｎは、必要に応じて、起動オプション２１ａ，２１ｂ，…，２１ｎをそれぞれ入力し、指定された起動オプションに応じた処理を実行する。更に、各処理プログラム２０ａ，２０ｂ，…，２０ｎは、整合性が保たれていないと判定した場合、エラー情報２４ａ，２４ｂ，…，２４ｎをそれぞれ出力する。

図２は、処理プログラム２０ａ，２０ｂ，…，２０ｎのうち、処理プログラム２０ａを例に、その内部構成例を示しており、処理プログラム２０ａは、設計ツール処理部２０１、整合性情報識別部３０１、整合性情報記憶部３０２、整合性検証部３０４、整合性情報付加部３０３などを備えている。

設計ツール処理部２０１は、入力したファイルに含まれる設計データ２２ａを処理（例えば、コンパイルやリンケージ等の処理）して処理結果の設計データ２２ｂを後続の処理プログラムのために出力する。

整合性情報識別部３０１は、入力したファイルに含まれる整合性情報２３ａを識別する。

整合性情報記憶部３０２は、各処理プログラム間の整合性情報を記憶する。ここで記憶される整合性情報は、コンフィグレーション情報３３１、起動オプション情報３３２、バージョン情報３３３などの情報のうち、少なくとも１つ以上の情報を含む。コンフィグレーション情報３３１には、設計ツール生成ソフト１０が処理プログラム２０ａを生成する際に入力したコンフィグレーション１１の情報（プロセッサの構成情報）が格納され、バージョン情報３３３には、処理プログラム２０ａが生成された際のバージョン情報が格納される。また、起動オプション情報３３２には、処理プログラム２０ａが起動される際に指定される起動オプション２１ａの情報が格納される。

整合性検証部３０４は、整合性情報識別部３０１にて識別された整合性情報２３ａと整合性情報記憶部３０２に記憶されている整合性情報３３１，３３２，３３３とを比較して、処理プログラム間の整合性が保たれているか否かを検証し、整合性が保たれていないと判定した場合、エラー情報２４ａを出力する。

整合性情報付加部３０３は、整合性検証部３０４により整合性が保たれていると判定された場合に、出力ファイルに整合性情報２３ｂを付加して出力する。

［システムＬＳＩ設計装置の処理動作］
図３は、システムＬＳＩ設計装置における各処理プログラム（設計ツール）２０ａ，２０ｂ，…，２０ｎによる整合性検証処理手順を例示している。尚、図２に示す処理手順をコンピュータプログラムにして、コンピュータ読み取り可能な記憶媒体に格納し、コンピュータシステムにより実現されるシステムＬＳＩ設計装置に読み取らせ、読み取らせたコンピュータプログラムに記述されている各処理を、このシステムＬＳＩ設計装置に実行させることができる。

図３に示すように、まず、ステップS101において、整合性情報識別部３０１は、入力したファイルに整合性情報２３ａが付加されているか否かを判別する。判別の結果、入力したファイルに整合性情報２３ａが付加されている場合はステップS102に進み、付加されていない場合はステップS110に進む。

ステップS102において、整合性検証部３０４は、入力したファイルに付加されている整合性情報２３ａにコンフィグレーション情報が含まれているか否かを判別し、コンフィグレーション情報が含まれている場合、ステップS103において、判別したコンフィグレーション情報と、整合性情報記憶部３０２に記憶されているコンフィグレーション情報３３１（つまり、当該設計ツールが生成されたときに設定されたコンフィグレーション情報１１）とが一致するか否かを判別する。判別の結果、一致しない場合は、ステップS108へ進んでエラー処理を実行する。

ステップS102の判別の結果、入力したファイルに付加されている整合性情報にコンフィグレーション情報が含まれていない場合、もしくは、ステップS103の判別の結果、入力したファイルに付加されているコンフィグレーション情報と、整合性情報記憶部３０２に記憶されているコンフィグレーション情報３３１とが一致する場合は、ステップS104に進む。

ステップS104において、整合性検証部３０４は、入力したファイルに付加されている整合性情報２３ａに起動オプション情報が含まれているか否かを判別し、起動オプション情報が含まれている場合、ステップS105において、判別した起動オプション情報と、整合性情報記憶部３０２に記憶されている起動オプション情報３３２（つまり、設計ツールが起動されたときに設定された起動オプション情報２１ａ）とを比較し、処理許可範囲内であるか否かを判別する。判別の結果、処理許可範囲内でない場合は、ステップS108へ進んでエラー処理を実行する。

ステップS104の判別の結果、入力したファイルに付加されている整合性情報に起動オプションが含まれていない場合、もしくは、ステップS105の判別の結果、入力したファイルに付加されている起動オプション情報が処理許可範囲内である場合は、ステップS106に進む。

ステップS106において、整合性検証部３０４は、入力したファイルに付加されている整合性情報２３ａにバージョン情報が含まれているか否かを判別し、バージョン情報が含まれている場合、ステップS107において、判別したバージョン情報と、整合性情報記憶部３０２に記憶されているバージョン情報３３３（つまり、設計ツールが生成されたときのバージョン）とを比較し、処理許可範囲内であるか否かを判別する。判別の結果、処理許可範囲内でない場合は、ステップS108へ進んでエラー処理を実行する。

ステップS103、ステップS105、ステップS107のうち少なくとも１つで不整合を検知した場合、整合性検証部３０４は、ステップS108において「整合性エラー」の情報をエラー情報ファイル２４ａに出力し、ステップS109において、エラーレベルを判別する。そして、処理続行可能なエラーレベルであれば、ステップS110に進み、処理続行不可能なエラーレベルであれば、この一連の処理を終了する。

一方、ステップS106の判別の結果、入力したファイルに付加されている整合性情報にバージョンが含まれていない場合、もしくは、ステップS107の判別の結果、入力したファイルに付加されているバージョン情報が処理許可範囲内である場合は、ステップS110に進む。

ステップS110において、設計ツール処理部２０１は、入力したファイルの設計データ２２ａについて所定の処理を実行する。

ステップS111において、整合性情報付加部３０３は、入力したファイルに含まれていた整合性情報２３ａと整合性情報記憶部３０２の情報に基づいて、後続する処理プログラム（設定ツール）で用いる整合性情報２３ｂを作成し、ステップS112において、作成した整合性情報２３ｂを設計データ２２ｂに付加して出力ファイルに出力する。

尚、ステップS102〜ステップS107に示した整合性情報（コンフィグレーション情報、起動オプション情報、バージョン情報）の検証処理の順番は、図３に示した処理順に限定されず、どのような順番に処理しても良いし、それぞれの検証処理を並行に処理しても良い。

以上に説明した処理を各処理プログラム（設計ツール）２０ａ，２０ｂ，…，２０ｎがそれぞれ実行することで、例えば、図４に示すように、処理プログラム２０ａであるコンパイラ（C([A]T1-001)）は、ソースプログラム（foo.c）を入力し、コンパイル結果（foo.s）にコンフィグレーション情報［A］を付加して出力する。そして、処理プログラム２０ｂであるアセンブラ（A([A]T1-1a)）は、コンパイラ（C([A]T1-001)）が出力したコンパイル結果（foo.s）及びコンフィグレーション情報［A］と、設定された起動オプション２１ｂを入力して、上記の一連の処理を実行し、後続の処理ステップに係る処理プログラム（図示せず）のためにアセンブル結果（foo.o）及び整合性情報２３ｃを出力するといった流れになる。

また、例えば、図５に示すように、コンパイラ（C([A]T1-001)）のコンフィグレーション情報［A］とアセンブラ（A([B]T1-1a)のコンフィグレーション情報［B］とが食い違う場合は、処理プログラム２０ｂであるアセンブラ（A([B]T1-1a)）は、「整合性エラー」の情報をエラー情報ファイル２４ａに出力し、エラーレベルに応じて、処理を終了するか、もしくは後続の処理ステップに制御を移行する。

ここで、各処理プログラム（設計ツール）２０ａ，２０ｂ，…，２０ｎが出力ファイルに整合性情報２３ｂ，２３ｃ，…，２３ｍを付加する場合、各処理プログラム２０ａ，２０ｂ，…，２０ｎが出力する設計データ２２ｂ，２２ｃ，…，２２ｍのデータ形式に応じて予め決められた書式に変換されて行われる。

例えば、Ｃ言語によるソースプログラムコンパイラのように、出力するファイルのデータ形式がテキスト形式の場合は、図６に例示するように、整合性情報（“8f00a301”）をコメント記述欄として出力する。

また、アセンブラやリンカなどのように、出力ファイルがバイナリー形式の場合は、図７に例示するように、コメントフィールドに整合性情報（0x8f00a301）を付加する。尚、図８（ａ）に示すように、整合性情報を付加するためのコメントフィールドを、出力する設計データの先頭部に設けても良いし、あるいは図８（ｂ）に示すように、出力する設計データの末尾部にコメントフィールドを設けても良い。後続する処理プログラムは、先行する処理プログラムが出力したファイルの先頭などに示されている出力ファイルのデータサイズやコメントフィールドのデータサイズ等を参照して、付加された整合性情報を識別し、処理することができる。

尚、図６〜図８に例示した整合性情報は、例えば図９に示すようなデータ構造となっており、オプション命令Ａ（opt A）がＯＮ（“1”）で、オプション命令Ｂ（opt B）がＯＦＦ（“0”）であることを示しており、命令キャッシュ（I$）はＯＮ（“1”）で、データキャッシュ（D$）はＯＦＦ（“0”）である。また、末尾の８ビットは、バージョン情報（Version）が“0.1”であることを示している。

以上、説明したように、各処理プログラム（設計ツール）は、処理を施した設計データに、コンフィグレーション情報、オプション情報、バージョン情報等の整合性情報を付加して出力ファイルに出力するようにしている。また、各処理プログラム（設計ツール）は、入力ファイルに付加されている整合性情報を検証して、整合性が保たれていないと判断した際にはエラー情報を出力し、エラーレベルに応じて処理を終了するか、あるいは処理を続行するようにしている。従って、処理プログラム（設計ツール）間の整合性が保たれていないことに起因するトラブルを未然に検知し、防止することができるため、原因の解明などに要していたコストや時間等を大幅に削減することができる。

［変形例］
以上、本発明の実施の形態について詳細に説明したが、本発明は、その精神または主要な特徴から逸脱することなく、他の色々な形で実施することができる。

例えば、図１０に示すように、整合性情報識別部３０１、整合性情報記憶部３０２、整合性情報付加部３０３、整合性検証部３０４を、整合性検証ツール３０として処理プログラムから独立させて生成し、共通化しても良い。独立して生成された整合性検証ツール３０は、各処理プログラムの内部に組み込んでも良いし（整合性検証ツール３０ａ）、各処理プログラムの外側に設置しても良い（整合性検証ツール３０ｂ）。このように構成することで、生成される各処理プログラム（設計ツール）２０ａ，２０ｂ，…，２０ｎの本体のサイズをコンパクトにすることができ、取扱いが容易になる。

また、各処理プログラムの起動オプション２１ａで、独立化した整合性検証ツール３０を動作させるか否かを設定できるようにしても良い。例えば、同一の設計データを繰り返し使用するような処理プログラム（設計ツール）の場合は、起動オプション２１ａの変更だけで、整合性検証ツール３０の実行をスキップすることができ、設計時間を短縮することができる。

また、各処理プログラムの起動オプション２１ａで、コンフィグレーション情報やオプション情報、バージョン情報等の整合性情報を出力しないように設定できるようにしても良い。この場合も、同一の設計データを繰り返し使用するような処理プログラム（設計ツール）においては、起動オプション２１ａの変更だけで、出力ファイルのデータ量を低減することができ、設計時間を短縮することができる。

このように、前述の実施例はあらゆる点で単なる例示に過ぎず、限定的に解釈してはならない。本発明の範囲は、特許請求の範囲によって示すものであって、明細書本文には何ら拘束されない。更に、特許請求の範囲の均等範囲に属する変形や変更は、全て本発明の範囲内のものである。

本発明の一実施形態における、構成変更可能なプロセッサを含むシステムＬＳＩの設計装置の構成例を示す概略ブロック図である。 図１に示したシステムＬＳＩの設計装置に搭載される処理プログラム（設計ツール）の内部構成例を示す概略ブロック図である。 図１に示したシステムＬＳＩの設計装置において各処理プログラム（設計ツール）による整合性検証処理手順を例示するフローチャートである。 図１に示したシステムＬＳＩの設計装置において実行される処理プログラムの一例を示す図である。 図１に示したシステムＬＳＩの設計装置において実行される処理プログラム間で整合性エラー時の一例を示す図である。 出力するファイルがテキスト形式の場合に整合性情報を付加する例を示す図である。 出力するファイルがバイナリー形式の場合に整合性情報を付加する例を示す図である。 （ａ）は、整合性情報を付加するためのコメントフィールドを、出力する設計データの先頭部に設けた例を示した図であり、（ｂ）は、出力する設計データの末尾部に整合性情報を付加するためのコメントフィールドを設けた例を示した図である。 図６〜図８に例示した整合性情報のデータ構造の一例を示す図である。 構成変更可能なプロセッサを含むシステムＬＳＩの設計装置の変形例を示す概略ブロック図である。 構成変更可能なプロセッサを含むシステムＬＳＩの一般的な設計処理手順を示すフローチャートである。 コンフィギュレーション毎にそれぞれ異なる処理プログラム（設計ツール）群が生成される例を示す図である。 設計ツール生成ツールのバージョン毎にそれぞれ異なる処理プログラム（設計ツール）群が生成される例を示す図である。 図１２に示した処理プログラム（設計ツール）間で整合性が保たれないまま実行した例を示すフローチャートである。 図１４に示した処理プログラム（設計ツール）間で整合性が保たれないまま実行した例を示すフローチャートである。

符号の説明

１０…設計ツール生成ソフト
１１…コンフィグレーション情報
１２…テンプレート
２０ａ，２０ｂ，…，２０ｎ…処理プログラム
２１ａ，２１ｂ，…，２１ｎ…起動オプション
２２ａ，２２ｂ，２２ｃ，…，２２ｍ…設計データ
２３ａ，２３ｂ，２３ｃ，…，２３ｍ……整合性情報
２４ａ，２４ｂ，…，２４ｎ…エラー情報
３０，３０ａ，３０ｂ…整合性検証ツール
２０１…設計ツール処理部
３０１…整合性情報識別部
３０２…整合性情報記憶部
３０３…整合性情報付加部
３０４…整合性検証部
３３１…コンフィグレーション情報
３３２…起動オプション情報
３３３…バージョン情報

Claims (5)

1. 目的に応じて構成変更可能なプロセッサを含むシステムＬＳＩの設計に用いられる一連の処理プログラムからなり、各処理プログラムは、先行する処理プログラムが出力するファイルを入力し、後続の処理プログラムの入力となるファイルを出力するように構成されるシステムＬＳＩ設計装置であって、
   前記処理プログラムは、
   各処理プログラム間の整合性情報を記憶する整合性情報記憶部と、
   入力した前記ファイルに含まれる整合性情報を識別する整合性情報識別部と、
   識別した前記整合性情報と前記整合性情報記憶部に記憶された前記整合性情報とを比較して整合性が保たれているか否かを検証する整合性情報検証部と、
   出力するファイルに整合性情報を付加して出力する整合性情報付加部と
   を備えることを特徴とするシステムＬＳＩ設計装置。
2. 前記整合性情報は、設計対象のシステムＬＳＩのコンフィグレーション情報と、前記処理プログラムの起動オプションと、前記処理プログラムのバージョン情報のうち、少なくとも１つ以上の情報を含むこと
   を特徴とする請求項１に記載のシステムＬＳＩ設計装置。
3. 整合性情報検証部は、前記比較の結果、整合性が保たれていないと判定した場合、エラー情報を出力すること
   を特徴とする請求項１または請求項２のいずれかに記載のシステムＬＳＩ設計装置。
4. 目的に応じて構成変更可能なプロセッサを含むシステムＬＳＩの設計装置に用いられる一連の処理プログラムであって、先行する処理プログラムが出力するファイルを入力し、後続の処理プログラムの入力となるファイルを出力するように構成され、
   入力した前記ファイルに整合性情報が含まれているか否かを識別する処理と、
   識別した前記整合性情報と予め処理プログラム毎に記憶していた整合性情報とを比較して、整合性が保たれているか否かを検証する処理と、
   出力するファイルに整合性情報を付加して出力する処理と
   を含む処理を前記システムＬＳＩの設計装置に実行させることを特徴とするシステムＬＳＩ設計用処理プログラム。
5. 目的に応じて構成変更可能なプロセッサを含むシステムＬＳＩの設計装置に用いられる一連の処理プログラムの整合性を検証する方法であって、
   先行する処理プログラムが出力したファイルを入力し、入力した前記ファイルに整合性情報が含まれているか否かを識別する段階と、
   識別した前記整合性情報と予め処理プログラム毎に記憶していた整合性情報とを比較して、整合性が保たれているか否かを検証する段階と、
   後続の処理プログラムの入力となるファイルに整合性情報を付加して出力する段階と
   を含むことを特徴とする整合性検証方法。
   
   

Images