JP2001067384A - 集積回路装置の設計用データベース及び集積回路装置の設計方法 - Google Patents

Abstract

(57)【要約】 【課題】 再設計の無駄な繰り返しや設計不能を回避す
るためのデータベース及びこれを用いた設計方法を提供
する。 【解決手段】 集積回路装置の各要素を設計するために
必要なデータを少なくとも仕様ＶＣとＲＴＬ−ＶＣとに
分けて格納するＶＣクラスタと、仕様ＶＣに格納され、
その仕様に対するＲＴＬ−ＶＣの性能に関するデータで
ある実現容易性判定用情報とを含むデータベースを用い
る。各要素に対応する仕様ＶＣをエントリーした後、仕
様ＶＣの実現容易性判定用情報に基づいて、エントリー
した仕様ＶＣを用いた集積回路装置の設計の容易性を判
定する。設計の上流側で、各ＶＣが要求性能を容易に満
たせるのか、あるいは満たすことが困難なのかを判定で
きるので、無理な要求を出すことに起因する再設計の頻
繁な繰り返しや設計不能に陥る事態がなくなる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、集積回路装置の設
計方法やその設計に用いるデータベースに係り、特にシ
ステムＬＳＩ等の大規模な集積回路装置を設計する際の
高効率化対策に関する。

【０００２】

【従来の技術】従来より、集積回路装置の設計の手順と
しては、上流側から、仕様設計，アーキテクチャ設計
（動作レベルの設計），ＲＴ（レジスター・トランスフ
ァ）設計などにおける要素に置き換えるべきブロック
（又はコア）などの生成を行ない、最終的にそれらの論
理合成を行なって、実際の集積回路装置の構成を作り上
げるのが一般的である。

【０００３】図１６は、一般的なＬＳＩの設計手順を示
すフローチャート図である。その際、仕様設計において
は、設計者が経験的に机上で設計の仕様を生成し、仕様
設計又はアーキテクチャ設計が終了した時点で、機能検
証（機能シミュレーション）を行なって、当該仕様によ
るシステムの機能を確認することが多い。また、下流側
のＲＴ設計においては、さらに性能解析を行なって、最
適なブロックがあればそのブロックを採用し、なければ
上流側に戻って再設計を行なうというループの繰り返し
によって次第に最適なシステムに近づいてゆき、最終的
に最適なシステムを構築している。

【０００４】

【発明が解決しようとする課題】しかしながら、システ
ムＬＳＩのようにきわめて多くの要素が複雑に構成され
た集積回路を設計する際に、設計の上流側で非常に過剰
な要求（オーバースペックな要求）を出すと、設計の手
順で再設計のループの頻繁な繰り返しによって設計の完
了に多大な時間を費やしたり、設計が完了しないつまり
設計不能に陥るなどの不具合がある。

【０００５】ところが、実際にはそれほど厳しいスペッ
クは必要としないことも多いにもかかわらず、当初はで
きるだけ高い性能を要求するのが設計者の常であり、下
流側の設計で行き詰まってから初めて要求性能を落とす
などの措置を講じているのが現状である。その結果、現
実の性能と遊離した性能の要求は、システムＬＳＩのよ
うに１つ１つのブロックの設計に多大の工数を費やすも
のを設計するのに対する障害となっている。

【０００６】本発明の目的は、設計のスタート時にでき
るだけ現実の性能に沿った要求をなし得る手段を講ずる
ことにより、再設計の無駄な繰り返しや設計不能を回避
するためのデータベース及びこれを用いた設計方法を提
供することにある。

【０００７】

【課題を解決するための手段】本発明の第１の集積回路
装置の設計用データベースは、複数の要素からなる集積
回路装置を設計するために必要なデータを格納するデー
タベースであって、上記各要素を設計するために必要な
データを、少なくとも仕様ＶＣ（バーチャル・コア）
と、ＲＴＬ−ＶＣとに分けて格納するＶＣクラスタと、
上記仕様ＶＣに格納され、その仕様に対する当該ＶＣク
ラスタ中のＲＴＬ−ＶＣの性能に関するデータである実
現容易性判定用情報とを備えている。

【０００８】これにより、設計の上流側である仕様レベ
ルにおいて、集積回路装置が要求性能を容易に満たせる
のか、あるいは満たすことが困難なのかを判定するのに
役立つデータベースを提供することができる。

【０００９】上記第１の集積回路装置の設計用データベ
ースにおいて、上記実現容易性判定用情報は、処理時
間，レイアウト面積，消費電力及びテストコストのうち
少なくともいずれか１つに関するデータを含んでいるこ
とが好ましい。

【００１０】上記第１の集積回路装置の設計用データベ
ースにおいて、上記実現容易性判定用情報は、処理時間
とデータの入出力に要する時間とに関するデータを少な
くとも含んでいることにより、データ転送に要する時間
をも含めた処理時間についての実現容易性の判定に供す
ることができる。

【００１１】上記第１の集積回路装置の設計用データベ
ースにおいて、上記実現容易性判定用情報は、その仕様
に対するＲＴＬ−ＶＣが複数個ある場合には、上記デー
タを各ＲＴＬ−ＶＣの最小値，平均値，最大値及び最適
値のうち少なくともいずれか１つとして含んでいること
が好ましい。

【００１２】上記第１の集積回路装置の設計用データベ
ースにおいて、上記仕様ＶＣに格納され、その仕様に対
するＶＣの新規開発に要する工数と、その仕様に対する
ＶＣの再利用に要する工数とに関するデータである工数
見積り用情報をさらに備えていることが好ましい。

【００１３】本発明の第２の集積回路装置の設計用デー
タベースは、複数の要素からなる集積回路装置を設計す
るために必要なデータを格納するデータベースであっ
て、上記各要素を設計するために必要なデータを、少な
くとも、仕様ＶＣ（バーチャル・コア）と、ＲＴＬ−Ｖ
Ｃとに分けて格納するＶＣクラスタと、上記仕様ＶＣに
格納され、その仕様に対するＶＣの新規開発に要する工
数と、その仕様に対するＶＣの再利用に要する工数とに
関するデータである工数見積り用情報とを備えている。

【００１４】これにより、設計の上流側で設計に要する
工数を一定の精度で見積もることができるので、工数と
納期とを考慮して必要な設計者の数などを把握すること
が可能になる。

【００１５】上記第１及び第２の集積回路装置の設計用
データベースにおいて、上記仕様ＶＣは、仕様・動作Ｖ
Ｃとして動作ＶＣと一体化されていてもよい。

【００１６】本発明の集積回路装置の設計方法は、複数
の要素からなる集積回路装置の各要素を設計するために
必要なデータを少なくとも仕様ＶＣ（バーチャル・コ
ア）とＲＴＬ−ＶＣとに分けて格納するＶＣクラスタ
と、上記仕様ＶＣに格納され、その仕様に対するＲＴＬ
−ＶＣの性能に関するデータである実現容易性判定用情
報とを含むデータベースを用いた集積回路装置の設計方
法であって、上記各要素に対応する仕様ＶＣをエントリ
ーするステップ（ａ）と、上記仕様ＶＣの実現容易性判
定用情報に基づいて、上記エントリーした仕様ＶＣを用
いた集積回路装置の設計の容易性を判定するステップ
（ｂ）とを含んでいる。

【００１７】この方法により、集積回路装置の設計の上
流側で、各ＶＣが要求性能を容易に満たせるのか、ある
いは満たすことが困難なのかを判定できるので、無理な
要求を出すことに起因する再設計の頻繁な繰り返しや設
計不能に陥る事態を回避できる。したがって、大規模な
集積回路装置であっても、その設計の容易化を図ること
ができる。

【００１８】上記集積回路装置の設計方法において、上
記実現容易性判定用情報に、処理時間，レイアウト面
積，消費電力及びテストコストのうち少なくともいずれ
か１つに関するデータを含ませておき、上記ステップ
（ｂ）における判定を、処理時間，レイアウト面積，消
費電力及びテストコストのうち少なくともいずれか１つ
について行なうことが好ましい。

【００１９】上記集積回路装置の設計方法において、上
記実現容易性判定用情報に、処理時間とデータの入出力
に要する時間とに関するデータを少なくとも含ませてお
き、上記ステップ（ｂ）における判定を、データ転送に
要する時間と処理時間とについて行なうことが好まし
い。

【００２０】上記集積回路装置の設計方法において、上
記実現容易性判定用情報に、上記データを各ＲＴＬ−Ｖ
Ｃの最小値，平均値，最大値及び最適値のうち少なくと
もいずれか１つとして含ませておき、上記ステップ
（ｂ）における判定を、上記パラメータの最小値，平均
値，最大値及び最適値のうち少なくともいずれか１つに
ついて行なうことが好ましい。

【００２１】上記集積回路装置の設計方法において、上
記ステップ（ｂ）における判定を、上記性能の要求値
と、上記仕様ＶＣの実現容易性判定用情報から得られる
ＶＣの性能とを比較することにより行なうことができ
る。

【００２２】その場合、上記ステップ（ｂ）における判
定を、上記性能の要求値を１００としたときの，上記Ｖ
Ｃの性能のパーセンテージを指標として行なうことによ
り、設計者の経験だけでなく客観的な指標に基づく実現
容易性の判定が可能になる。

【００２３】また、上記ステップ（ｂ）における判定
を、複数のＶＣのうちある性能についてもっとも実現容
易性が低いＶＣをボトルネックとして抽出しながら行な
うことにより、新規に開発すべきＶＣや要求性能を落と
す必要のあるＶＣが明確になるので、上流側における再
設計をスムーズに行なうことができる。

【００２４】上記ステップ（ｂ）では、上記複数の要素
のうち再利用可能な要素についてはその要素に対応する
ＶＣクラスタのＲＴＬ−ＶＣの性能を用い、他の要素に
ついてはその要素に対応するＶＣクラスタの仕様ＶＣの
上記実現容易性判定用情報中の性能を用いることによ
り、実現容易性の判定をきわめて簡易に行なうことが可
能になる。

【００２５】また、設計実現例のある機能モデルを再利
用し、その一部の要素を変更して機能モデルを作成する
場合に、上記ステップ（ｂ）では、上記複数の要素のう
ち再利用可能な要素については、設計実現例で使用され
たＶＣクラスタのＲＴＬ−ＶＣの性能を用いることによ
り、実現容易性の判定をきわめて簡易に行なうことが可
能になる。

【００２６】上記ステップ（ｂ）の後、全体の要求性能
を上記複数の要素に対応する各ＶＣごとに、重み付けし
て分割するステップをさらに備えることにより、下流側
の設計において各ＶＣそれぞれが満たすべき性能が明確
になり、下流側の設計の迅速化を図ることができる。

【００２７】上記ステップ（ｂ）の後、全体の要求性能
を上記複数の要素に対応する各ＶＣごとに、均等に分割
するステップをさらに備えても同様である。

【００２８】また、上記データベースの仕様ＶＣに、そ
の仕様に対するＶＣの新規開発に要する工数と、その仕
様に対するＶＣの再利用に要する工数とに関するデータ
である工数見積り用情報とがさらに格納されている場合
には、上記性能を分割するステップの後、各要素に対応
する仕様ＶＣの工数見積り情報から各要素の工数を見積
もるステップをさらに備えることにより、設計の納期管
理などが円滑に行なわれる。

【００２９】上記集積回路装置の設計方法において、上
記ステップ（ａ）を行なった後、上記ステップ（ｂ）を
行なう前に、全体の要求性能を上記各ＶＣごとに分割す
るステップをさらに備え、上記ステップ（ｂ）における
判定を、各要素に対応する仕様ＶＣの実現容易性判定用
情報から各要素の分割された性能を満たす実現例の割合
が所定値以上か否かによって行なうこともできる。

【００３０】上記全体の要求性能の分割を、各ＶＣごと
に重み付けして行なってもよいし、各ＶＣごとに均等に
行なってもよい。

【００３１】その場合にも、上記ステップ（ｂ）におけ
る判定を、複数のＶＣのうちある性能についてもっとも
実現容易性が低いＶＣをボトルネックとして抽出しなが
ら行なうことが好ましい。

【００３２】上記データベースの仕様ＶＣに、その仕様
に対するＶＣの新規開発に要する工数と、その仕様に対
するＶＣの再利用に要する工数とに関するデータである
工数見積り用情報とがさらに格納されている場合には、
上記ステップ（ｂ）の後、各要素に対応する仕様ＶＣの
工数見積り情報から各要素の工数を見積もるステップを
さらに備えることが好ましい。

【００３３】

【発明の実施の形態】まず、本発明の各実施形態におい
て採用するＶＣＤＳ（バーチャル・コア・デザインシス
テムの一般的な構成について説明する。

【００３４】−ＶＣの説明− 本発明におけるＶＣ（バーチャル・コア）とは、ＩＰ
（機能ブロック）としばしば同義に使用されるバーチャ
ルコンポーネントとしての”ＶＣ”とは異なる概念であ
って、１つのまとまったブロックで構成されるシステム
ＬＳＩの設計を対象としており、その中でも、再利用が
可能なハードウェア，ソフトウェアを含むデータを指す
ものとする。そして、ＶＣＤＳ（バーチャル・コア・デ
ザイン・システム）とは、このＶＣを利用してシステム
ＬＳＩのハード，ソフトを最適化するためのシステム全
体を指すものとする。また、ＶＣＤＢ（バーチャル・コ
ア・データベース）とは、ＶＣを利用した設計のために
用いられるデータベースを指すものとする。

【００３５】−ＶＣＤＳの概略構成− 図１は、本発明の実施形態に係るシステムＬＳＩ設計の
ためのデザインシステム（ＶＣＤＳ）の構成を概念的に
示す図である。

【００３６】図１に示すように、本実施形態に係るデザ
インシステムは、システムの設計のためのデータの格納
層であるＶＣＤＢ１（ＶＣデータベース）と、ＶＣＤＢ
１の最適化などを行うための制御システムであるＶＣＤ
ＢＭＳ２（ＶＣＤＢマネージメントシステム）とにより
構成されている。

【００３７】ＶＣＤＢ１には、ＶＣの集合体として捉え
られるＶＣクラスタ３と、このＶＣクラスタ３中のＶＣ
の構造を決定するためのアーキテクチャ情報４とが含ま
れている。ＶＣクラスタ３には、仕様レベルで記述され
るデータを格納するバーチャル・コアである仕様ＶＣ５
と、動作レベルで記述されるデータを格納する動作ＶＣ
６と、ＲＴレベル（レジスター・トランスファレベル）
で記述されるデータを格納するバーチャル・コアである
ＲＴＬ−ＶＣ７と、各ＶＣの性能を評価するための性能
指標８とが存在する。

【００３８】ここで、“仕様”とは、関数とでもいうべ
き，基本的な入出力関係を規定するものである。“動
作”とは１つの仕様に対してソフトウェア，ハードウェ
アの割り当てを定めたものであって、一般的には１つの
仕様に対して複数の動作がある。“ＲＴ”（レジスター
・トランスファ）とは、動作に対してハードウェア的に
実現できるものであって、一般的には１つの動作に対し
て、重視するパラメータの相違などに応じた何種類かの
実現方法がある。すなわち、後に詳しく説明するよう
に、１つの仕様ＶＣに対して複数の動作ＶＣを、１つの
動作ＶＣに対して複数のＲＴＬ−ＶＣをそれぞれ階層的
に有しているのが一般的である。ただし、仕様と動作と
はいずれも機能的な概念を表すものともいえるので、そ
の区別が困難な場合もあり、その場合には、仕様・動作
ＶＣとしてデータベースを持っておくことも可能であ
る。

【００３９】また、性能指標８とは、例えば面積，スピ
ードなどのパラメータをいい、例えばＲＴレベルでは、
ある値をかなり正確に算出することができる。また、実
際にあるＲＴレベルでハードを実現したことがあれば、
その結果も性能指標８に組み込んでおくことができる。

【００４０】アーキテクチャ情報４には、実際にそれぞ
れのＶＣをどう使用するかということの情報が含まれて
いる。例えばあるタスクをソフトウェアで実現する場合
には、「それを実行するプロセッサはなにを使用するの
か」、「バス（インターフェイス）はなにを使用するの
か」、「電源，クロック供給方式はどうするか」、「論
理合成する際のテスト方式はなにを用いるか」、「命名
規則の制約（ツールの制約や重複防止のための規則）は
どうか」など、そのシステムＬＳＩに必要な種々の情報
が含まれている。

【００４１】一方、ＶＣＤＢＭＳ２は、ＶＣＤＢ１に対
する登録や、ＶＣＤＢ１の外方からの検索，インスタン
スの生成などを行なう。登録には、新たなコアとして登
録するほか、既存ＶＣを参照して新たなＶＣを生成し、
そのＶＣの機能を改変したり、ＶＣ内のデータの追加登
録を行なったり，差分管理情報を格納したりすることが
含まれる。検索とは、どのレベルのＶＣでどういう種類
の情報が欲しいかということの検索である。これらの詳
細についても後述する。

【００４２】図２は、本実施形態のＶＣＤＳにおける設
計の基本的な流れを示す図である。同図に示すように、
仕様レベル，動作レベル及びＲＴレベルのいずれにおい
ても、記述，検証，評価，合成の手順によりＶＣの生
成，改変などが行なわれる。その際、図中矢印に示す方
向に沿ってデータが流れて、データの記述，検証，評価
が行なわれ、評価はフィードバックされる。例えば、仕
様ＶＣであるＳ１，Ｓ２が選び出されたり、新たなＶＣ
であるＳ３が生成されたりする。また、動作レベルで
は、各仕様ＶＣであるＳ１，Ｓ２，Ｓ３に対応した動作
ＶＣであるＤ１，Ｄ２，Ｄ３が生成されるが、各ＶＣは
ハードウェア，ソフトウェアに機能分割される。また、
ＲＴレベルでは、各動作ＶＣであるＤ１，Ｄ２，Ｄ３に
対応するＲＴＬ−ＶＣであるＲ１，Ｒ２，Ｒ３が生成さ
れるとともに、これらを接続するバス，ＣＰＵ，メモリ
等が生成される。つまり、より具体化されることにな
る。

【００４３】ただし、図２には示されていないが、仕様
レベルにおいては、後述するように、実現容易性判定が
行なわれ、その判定結果はフィードバックされる。この
実現容易性判定が本発明の特徴部分であり、具体的な内
容については、後に詳細に説明する。

【００４４】各々のタスクは、外部入出力部及び仕様Ｖ
Ｃと状態遷移などで記述されている。仕様ＶＣは、状態
遷移，論理，真理値表などを表現できる言語あるいは図
形で記述されている。

【００４５】このように、各階層にＶＣを配置してこれ
らを総合的に管理することにより、従来の機能ブロック
とは異なり、フレキシブルに利用できるデータベースの
提供を図ることができる。

【００４６】−ＶＣクラスタの構成− 次に、図３は、図１に示すシステムの機能部分を抜き出
して示すブロック回路図である。同図において、ＶＣク
ラスタ３を格納しているデータベース格納層１０に情報
を入力するための入力部１１と、データベース格納層１
０からの出力情報を受ける出力部１２と、データベース
格納層１０，入力部１１及び出力部１２を制御する制御
部１３とを有する。ＶＣクラスタ３には、仕様ＶＣを生
成する仕様層と動作ＶＣを生成する動作層とを含む仕様
動作層１４と、ＲＴＬ−ＶＣを生成するＲＴ層１５とい
う機能が存在する。このうち、仕様層と動作層とは必ず
しも明確に区分できない場合があるので、仕様動作層１
４と一括して示されている。

【００４７】図４は、ＶＣクラスタの機能を詳細に説明
する図である。同図に示すように、仕様層においてある
機能を表現する仕様ＶＣがあり、その下流側の動作層に
おいてはそれを実現するための複数の動作ＶＣ１，動作
ＶＣ２が一般的には存在し、さらに下流側のＲＴ層にお
いては各動作ＶＣ１，動作ＶＣ２を実現するためのそれ
ぞれ複数のＲＴＬ−ＶＣ１ａ，ＲＴＬ−ＶＣ１ｂ，ＲＴ
Ｌ−ＶＣ２ａ，ＲＴＬ−ＶＣ２ｂが一般的には存在す
る。例えば、”乗算”という１つの仕様に対し、”乗
算”を実現するための動作は複数の足し算とシフトなど
の動作の組み合わせからなるので、複数通りの動作が存
在するのが一般的である。もちろん、下流側に１つのＶ
Ｃしか存在しないこともあり得る。図４に示す例では、
例えば”乗算”という１つの仕様ＶＣに対し、遅延を重
視した実現方法が動作層ＶＣ１であり、（占有）面積を
重視した実現方法が動作層ＶＣ２である。そして、各層
ごとにインスタンスＶＣを生成して付加する機能が備わ
っており、図４には、例としてＲＴＬ−ＶＣ１ａ，ＲＴ
Ｌ−ＶＣ１ｂ，ＲＴＬ−ＶＣ２ａ，ＲＴＬ−ＶＣ２ｂに
おいて、それぞれ１又は複数のインスタンスＶＣを生成
する機能が表わされている。

【００４８】図５は、本実施形態における各ＶＣの構造
を示す図である。仕様層，動作層，ＲＴ層などの各階層
のＶＣには、後述する設計データ（図）と、テストベク
タなどの検証データと、面積，遅延，消費電力などの性
能情報と、対象ＶＣの上位概念を持つ上位層ＶＣ，下位
概念を持つ下位層ＶＣなどに関するリンク情報となる上
下層（親子）情報と、ＶＣ作成時に参照した同一層のＶ
Ｃや参照されたＶＣなどに関する派生情報と、同一層
（例えばいずれも動作層にある場合など）に属するＶＣ
間で共有する情報があればその共有情報と、追加や修正
があった場合にはその改変内容と、例えばパラレル又は
シリアル又はＰＣＩパスなどのバスを生成するためのイ
ンターフェイス情報とが備えられている。また、仕様層
には、実現容易性判定用情報が備えられている。

【００４９】図６は、設計の各層におけるＶＣのデータ
及び性能情報の相違点を示すための図である。同図の右
側には、（占有）面積と遅延とを性能評価のパラメータ
として採用したときの各層の性能情報の例が示されてい
るが、同図の左側には、各層の設計データや検証データ
が存在するが、図６においては説明を簡単にするために
図示を省略する。

【００５０】仕様層は機能とでもいうべき基本的な入出
力関係を規定する部分であるので、仕様層内の設計デー
タには、入出力信号の種別や、テキストベースのデー
タ，プロトコルなどの規格、ある規格に合わせるための
目標性能などの性能、ドキュメントとして与えられてい
る機能仕様がある。仕様検証モデルは、ＦＳＭ（状態遷
移），ＣＦＧ（コントロールフローグラフ），ＤＦＧ
（データフローグラフ）などで表現されている仕様記述
（言語又は図）である。具体的なフォーマットの例とし
ては、例えばＶＨＤＬ，ＳＤＬ，ＬＯＴＯＳ，Ｃ／Ｃ＋
＋などというものである。

【００５１】動作層は、アーキテクチャ情報と、ハード
ウェア部と、ソフトウェア部とに分かれている。アーキ
テクチャ情報は、対象プロセッサ名、ＯＳ名、ハードウ
ェア，ソフトウェアの通信方法などを含んでいる。例え
ば、プロセッサとＯＳとシミュレーションとを組み合わ
せる場合には、使用するプロセッサはＳｐａｒｃ，Ｐｅ
ｎｔｉｕｍなどで、使用するＯＳはＵＮＩＸ，Ｗｉｎｄ
ｏｗｓなどで、使用するハードウェア，ソフトウェアの
通信方法はＩＰＣ，ＰＬＩなどであって、これらの適当
な組み合わせを記述すると共に、必要な前提条件などを
記述しておく。ただし、ＣＰＵはなくてもよい場合があ
る。また、ハードウェア部には、仕様層に対して具体化
した機能がドキュメントとして残されており、具体的に
は、仕様になかった詳細な動作モードが記述されてい
る。

【００５２】次に、ＲＴ層も基本的には、上述の動作層
と同様に、アーキテクチャ情報と、ハードウェア部と、
ソフトウェア部とを備えている。ただし、ＲＴ層におい
ては、ハードウェア部（ＨＷ）と、ＣＰＵと、メモリ
（ＭＥＭ）と、ソフトウェア部（ＳＷ），ＯＳとを接続
するバスが形成されている。つまり、通信方法について
も、どのように接続するのかというレベルまで具体化さ
れ、ハードウェアに確実に具現化できる，つまり論理合
成できるものになっている。

【００５３】ＲＴ層内のアーキテクチャ情報としては、
以下のような情報がある。まず、プロセッサ（ＣＰＵ）
情報として、動作層及びＲＴ層で使用する協調検証モデ
ルがある。これはプロセッサごとに存在する。次に、バ
ス（ＩＦ）情報として、バスの信号の種別や幅などの情
報や、バスのプロトコル（タイミング）がある。これら
は、プロセッサを各ハードウェアを接続するための内容
が含まれている。

【００５４】仕様層において、図４に示す仕様ＶＣがあ
る場合、この仕様ＶＣの性能を面積と遅延で表すと図６
の右上部に示す範囲（ハッチング部）である。そして、
この仕様ＶＣに対して、図４に示すような遅延を重視し
た実現方法である動作ＶＣ１と、面積を重視した実現方
法である動作ＶＣ２とがあった。図６の右中央部に示す
ように、動作ＶＣ１，動作ＶＣ２の範囲は、それぞれハ
ッチングが施された遅延の小さい領域及び面積の小さい
領域である。さらに、ＲＴ層には、図４に示すように、
動作ＶＣ１に対するＲＴＬ−ＶＣ１ａ，ＲＴＬ−ＶＣ１
ｂと、動作ＶＣ２に対するＲＴＬ−ＶＣ２ａ及びＲＴＬ
−ＶＣ２ｂとがあった。図６の右下部に示すように、各
ＶＣの面積及び遅延は具体的な曲線状のある点として定
まる。

【００５５】ここで、性能情報には多数のパラメータが
あることから、各層の性能情報は実際には図６のような
平面座標系ではなく、多次元座標系で表されることにな
る。したがって、性能情報は、ＲＴ層においては多次元
空間内のある範囲又は点として、仕様層又は動作層にお
いては多次元空間内のある範囲として、それぞれ表され
ることになる。

【００５６】ここで、上述のように、本発明の目的は、
設計のスタートにできるだけ実現性の高い仕様を生成
し、又は、システム全体を各部分の機能に切り分ける際
に、より精度の高い要求仕様を作り出すことにある。設
計の当初にある程度妥当な仕様を作成しておくと、上述
のようなオーバースペックな仕様の要求に起因する設計
の非能率化や設計不能という事態を回避できるからであ
る。つまり、ある部分は厳しいスペックが必要だが、あ
る部分は緩やかなスペックでよいというように、システ
ムの各部分ごとに適切な仕様を生成するのである。以
下、そのための具体的な手法について説明する。

【００５７】（第１の実施形態） −実現容易性判定を含む仕様層の設計手順− 次に、上述のＶＣＤＳを利用した本実施形態におけるシ
ステムＬＳＩの仕様層の設計方法について説明する。図
７は、本実施形態における実現容易性判定を含む仕様層
の設計手順を示すフローチャート図である。

【００５８】まず、ステップＳＴ１で、データベースか
ら仕様ＶＣをエントリーして、仕様が明確になったモデ
ルを組み合わせ、それを組み合わせた形としてシステム
ＬＳＩが要求する仕様のモデル（以下、“機能モデル”
という）を開発（生成）する。このような機能モデルの
例としては、後に説明する図９に示すようなデジタルス
チルカメラ用ＬＳＩの機能モデルなどがある。ＶＣＤＢ
内の仕様ＶＣをエントリーして、各仕様ＶＣを配置し、
その間にどういうデータを流すかという依存関係を定義
することにより、システム全体の機能モデルを生成する
のが、このステップＳＴ１における処理の内容である。

【００５９】次に、ステップＳＴ２において、ステップ
ＳＴ１で組み合わされて生成された機能モデルの機能を
シミュレーションする仕様，機能検証を行ない、ステッ
プＳＴ３で、この機能モデルが、正しく要求通りに機能
しているか否かを判定する。ただし、この時点での仕
様，機能は定性的なものであって、後に判定する“性
能”というような定量的なものではない。このステップ
ＳＴ２，ＳＴ３の処理は、ステップＳＴ４の後で行なっ
てもよい。

【００６０】次に、要求機能を満足する機能モデルが生
成されていることを確認してから、ステップＳＴ４で、
そのシステムの実現容易性を判定する。つまり、システ
ムＬＳＩの要求する性能及びコスト（処理時間，スルー
プット，消費電力，レイアウト面積，テストコストな
ど）に応じ、この要求に対応しうるＶＣ（設計例）があ
るかないかによって実現容易性を判定する。そのとき、
後述するような判断指標を用いて、システムに対する要
求を実現することが容易か否かを判定する。なお、要求
を満足しうるＶＣがない場合には、ステップＳＴ１に戻
って、要求に応じたＶＣを生成するか、新たなＶＣは生
成せずに要求のレベルを下げた後、ステップＳＴ２〜Ｓ
Ｔ４の処理を繰り返す。また、要求を満足するＶＣの生
成が容易かどうかをも実現容易性の判定に含めることも
できる。

【００６１】このようにして、ステップＳＴ１〜ＳＴ４
を繰り返すことにより、一応実現が容易であろうと推定
されるシステムが生成される。

【００６２】次に、ステップＳＴ４の判定で実現容易性
が十分あると判定された場合は、ステップＳＴ５に進
み、コストを含む要求性能の分割を行なう。すなわち、
全体の要求が与えられているが、それぞれのＶＣが満た
せばよい性能をシステム全体が要求される性能から分割
して決定する。そして、この処理によって決定された性
能を有する各ＶＣを生成するように、その後の設計を進
めるのである。この処理の具体例については、後述す
る。

【００６３】なお、既存のＶＣの再利用が容易な場合は
短い工数でできるし、新たなＶＣの生成を伴う場合に
は、多くの工数が必要である。そこで、任意のステップ
として、ステップＳＴ６で、新たに生成の必要なＶＣの
数に応じて、ある程度の工数の見積りを行なった後、ス
テップＳＴ７で、その見積り結果が予定工数内か否かを
判定して、予定工数内でなければステップＳＴ１に戻る
ようにしてもよい。このように、工数見積り結果に応じ
て仕様を作成し直すこともあり得る。

【００６４】以下、図７に示すフローの流れに沿って、
本発明の特徴的な部分について、詳細に説明する。

【００６５】−データベースの構造ー 図８は、本実施形態におけるデータベースの特徴的な部
分を抜き出して示す図である。仕様ＶＣには、純粋な機
能と入出力とを定義する部分があって、それを実際に検
証するためのシミュレーションモデルを持っている。本
実施形態においては、さらに、実現容易性判定用情報を
備えている。この実現容易性判定用情報は、クラスタ内
の実現例の性能情報である。仕様ＶＣには、その仕様に
対する動作ＶＣ，ＲＴＬ−ＶＣの実現例に関するデータ
が格納されている。ただし、仕様・動作層を１まとめに
してＶＣクラスタを構成する場合には、仕様・動作層に
実現容易性判定用情報が格納されている。

【００６６】そして、クラスタ内の実現例の性能情報
は、例えば、図８中の表に示すように、ＲＴＬ−ＶＣの
実現例によって得られる処理時間，スループット，消費
電力，（レイアウト）面積，テストコストの最大値ＭＡ
Ｘ，最小値ＭＩＮ，平均値ＡＶＥ，最適値ＯＰＴ，…な
どである。最適値ＯＰＴとは、性能を評価する各パラメ
ータのトレードオフを考慮した上で最適な値である最適
値ＯＰＴである。例えば、レイアウト面積，処理時間，
消費電力は、互いにトレードオフになっており、それら
の各パラメータを掛け合わせた値が最小のときに最適と
なる。つまり、この場合には、この３つのパラメータの
積の最小値を与えるレイアウト面積，処理時間，消費電
力が最適値ＯＰＴである。

【００６７】−機能モデル− 図９は、機能モデルの一例を示す図であって、デジタル
スチルカメラ用ＬＳＩの機能モデルを示すブロック図で
ある。たとえば、ＣＣＤの入力信号ｉ１を受けてこれを
信号を処理する要素に対応するＣＣＤ信号処理ＶＣ−Ｓ
１と、このＣＣＤ信号によって生成される画像を圧縮す
る要素に対応する画像圧縮ＶＣ−Ｓ２と、圧縮された画
像データを出力Ｏ１としてメディアに出力するための要
素に対応するメディア出力ＶＣ−Ｓ３と、圧縮された画
像データを出力Ｏ２として外付けメモリに出力するため
の要素に対応する外付けメモリ出力ＶＣ−Ｓ４と、圧縮
された画像データを伸長するための画像伸長ＶＣ−Ｓ５
と、伸長された画像データを出力Ｏ３としてモータに出
力するための要素に対応するモータ出力ＶＣ−Ｓ６とが
生成されている。なお、データベースＶＣＤＢ内には、
仕様層，動作層，ＲＴ層に亘るデータを有するＶＣクラ
スタが登録されている。図９の下方には、画像圧縮ＶＣ
クラスタの構造が例示されている。

【００６８】−実現容易性判定のための性能を表すパラ
メータ− 実現容易性の判定は、システムに対する要求と、エント
リーしたＶＣクラスタ内の仕様ＶＣに格納されている実
現容易性情報から算出される性能値とを比較して、要求
が性能値の範囲内に収まっていれば実現性があると判定
するように行なうのが原則である。この性能を表すパラ
メータとしては、処理時間，スループット，レイアウト
面積，消費電力，テストコストなどがある。ここでは、
“性能”を、コストも含む概念として定義するものとす
る。

【００６９】また、本実施形態における実現容易性判定
は、なるべく性能を表す数値が小さいほど集積回路装置
にとって有利と考えられるように、性能を評価するパラ
メータを設定して行なうものとする。例えば、データの
処理速度と処理時間とについてみると、両者は掛け合わ
したときにデータの処理量となるもので互いに反比例す
るパラメータである。そして、処理速度が大きいほど集
積回路装置にとっては有利だが、処理時間は小さいほど
有利である。したがって、この場合には処理時間を実現
容易性判定のための１つのパラメータとする。

【００７０】もちろん、処理速度を１つのパラメータと
して判断してもよいが、その場合にはＶＣから算出され
る性能値が要求よりも大きいほど実現容易性が高くなる
と判断することはいうまでもない。

【００７１】一方、データベースのＶＣクラスタの実現
容易性情報には、上述のように、ＲＴレベルのＶＣによ
って得られた性能の最大値ＭＡＸ，平均値ＡＶＥ，最小
値ＭＩＮ，最適値ＯＰＴが記述されている。そして、実
現容易性の判定は、ＭＡＸ，ＭＩＮ，ＡＶＥ，ＯＰＴの
いずれを用いても行なうことができるが、複数のＶＣに
ついての性能を合計する際には、すべてがＭＡＸ，ＭＩ
Ｎ，ＡＶＥ又はＯＰＴに統一されている必要がある。た
だし、小さいほど有利なパラメータに関しては最大値Ｍ
ＡＸはあまりにも余裕を持った判断を行なってしまうの
で、性能のＭＩＮの値によって実現容易であるにもかか
わらず実現不可能と判定してしまうおそれがある。この
ような場合には、最小値ＭＩＮ，平均値ＡＶＥ又は最適
値ＯＰＴを用いるのが好ましいといえる。ただし、大き
いほど有利なパラメータ例えばスループットなどを用い
るときには、最大値ＭＡＸ，平均値ＡＶＥ又は最適値Ｏ
ＰＴを用いるのが好ましい。

【００７２】ここで、以下の説明では、小さいほど有利
なパラメータを用いることを前提とする。この場合、最
小値ＭＩＮを採用して実現できるかどうかを判断した場
合には、１つのパラメータだけについての性能は確保さ
れることになるが、他のパラメータとのトレードオフを
考慮すると、必ずしも実現できるという保証はない。つ
まり、厳密な意味で“実現可能か否か”を判断している
ことになる。一方、平均値ＡＶＥを採用して実現できる
かどうかを判断すると、余裕を持って判断しているの
で、各パラメータ間のトレードオフを考慮して“実現容
易か否か”を判定することができる。ただし、実現でき
るものまで排除することもあり得る。この段階では、Ｒ
Ｔレベルにおける性能評価のような厳密な性能評価を行
うわけではなく、数値的にある程度の予想ができればよ
いだけであるので、最小値を採用するにしても、平均値
を採用するにしても、要求値とＶＣの性能値とをそのま
ま比較するのではなく、何らかの補正を行なった上で評
価するのが好ましい。

【００７３】−実現性容易性判定のための指標の作成− ここで、実現容易性を数値化して、実現容易性がどの程
度あるかを迅速に判定するための数値的な指標を作成し
ておく一例について説明する。

【００７４】ここでは、各要求の性能値を１００として
指標化し、エントリーした各仕様ＶＣの実現容易性判定
用情報に記述されている性能の合計値がその何％になる
かによって実現容易性を判定するものとする。

【００７５】図９に示すシステムにおいて、ＶＣＳ１，
Ｓ２，Ｓ３という直列に接続されたパスの処理時間を例
にとって説明する。要求の処理時間（転送時間を含まな
い）が９０サイクルであるのに対し、ＶＣＳ１，Ｓ２，
Ｓ３のＶＣクラスタ内に格納されている実現可能性判定
用情報から得られる処理時間（ＭＩＮ）が、それぞれ５
０サイクル，１０サイクル，１０サイクルであったとす
ると、合計の処理時間の要求に対するパーセンテージ
は、 １００×｛（５０＋１０＋１０）／９０｝＝１００×
｛７０／９０｝＝６７（％） である。このとき、処理時間の最小値を採用しているこ
となどを考慮して、一定のマージンをあらかじめ定めて
おく。例えば、マージンを２０％とすると、このマージ
ンを上のパーセンテージ（６７％）に加算した合計のパ
ーセンテージ（８７％）を実現可能性判定指標とする。
この場合は、合計パーセンテージが１００％以下である
ので、実現可能と判定する。このマージンのパーセンテ
ージは、設計品種ごとに指定される。なお、経験的なマ
ージンの情報を仕様ＶＣの情報と対応づけてデータベー
ス化することも可能である。

【００７６】以上の処理を整理すると、「小さいほど有
利な特性となるように性能を設定し、エントリーしたＶ
Ｃクラスタの最小の性能値に一定のマージンを加えたも
のが、要求性能値に対して１００％以下のパーセンテー
ジであれば、実現可能性ありと判定する」ことになる。

【００７７】このように、実現容易性という数値化され
た指標を設定しておくことにより、設計者が指標１００
に対してどの程度の範囲であれば実際に設計が容易であ
るかを、経験的に把握していくので、設計者がそのシス
テムに応じて適正なマージン（％）を設定することがで
きる。

【００７８】ただし、実現容易性を判定するためにこの
指標を必ず用いなければならないわけではない。また、
上述のように、ＶＣクラスタ内に格納されている実現容
易性情報から平均値ＡＶＥを取り出して実現容易性判定
のための指標を作成してもよい。

【００７９】−処理時間と消費電力とからみた実現容易
性判定の例− 例えば図１０に示すように、入力ｉ１についてある要素
（以下、説明を単純化するために要素はすべてＶＣに置
き換わったとして説明を進める）−Ｓ１による処理を施
した後、分岐してＶＣ−Ｓ２，Ｓ３による処理を施した
後、それぞれ出力Ｏ１，Ｏ２として外部にデータを出力
するシステムがあるとする。このとき、各ＶＣ−Ｓ１，
Ｓ２，Ｓ３がエントリーされたとする。そして、ＶＣ−
Ｓ１のＶＣクラスタ内の実現容易性判定用情報（実現
例）から、処理時間は５０サイクルで消費電力は１００
ｍＷであることがわかり、ＶＣ−Ｓ２のＶＣクラスタ内
の実現容易性判定用情報（実現例）から、処理時間は２
０サイクルで消費電力は２００ｍＷであることがわか
り、ＶＣ−Ｓ１のＶＣクラスタ内の実現容易性判定用情
報（実現例）から、処理時間は４０サイクルで消費電力
は１００ｍＷであることがわかったとする。この処理時
間，消費電力の値は、いずれも最小値ＭＩＮであるとす
る。

【００８０】ここでは、上述のような要求１００に対す
るＶＣの実現容易性情報から得られる性能（最小値）の
パーセンテージがマージンを考慮して１００以下か否か
によって、実現容易性を判定するものとする。

【００８１】処理時間についての要求が、「入力ｉ１か
ら出力Ｏ１までの処理時間が１００サイクル以下で、入
力ｉ１から出力Ｏ２までの処理時間が５０サイクル以下
であること」であったとする。ＶＣクラスタ内の実現例
から算出される入力ｉ１から出力Ｏ１までの処理時間
は、５０＋２０＝７０（サイクル）（ＡＶＥ）となり、
要求１００に対するパーセンテージは７０（％）であ
る。これにマージン２０（％）を加えると９０（％）に
なる。これは、１００以下であるので、実現容易であ
る。一方、各ＶＣクラスタ内の実現例から算出される入
力ｉ１から出力Ｏ２までの処理時間は、５０＋４０＝９
０（サイクル）となり、要求に対するパーセンテージ
は、１８０（％）である。これにマージン２０％を加え
ると２００（％）になる。これは１００をはるかに越え
てしまうので、実現困難である（つまり実現容易でな
い）。その結果、処理時間というパラメータについての
実現容易性の判定は、「実現容易性は低い。ボトルネッ
ク：入力ｉ１から出力Ｏ２への処理時間９０サイクル」
というように行なわれる。

【００８２】また、消費電力についての要求が、「消費
電力が全体で７００ｍＷ以下であること」であったとす
る。このとき、各ＶＣクラスタ内の実現例から算出され
るシステム全体の消費電力は、１００＋２００＋１００
＝４００（ｍＷ）となり、要求７００ｍＷに対するパー
センテージは、約７１．４（％）である。これにマージ
ン２０（％）を加えると、９１．４（％）になる。この
数値は１００以下であるので、消費電力というパラメー
タについての実現容易性の判定は、「実現性が高い」と
いうように行なわれる。

【００８３】一方、消費電力についての要求が、「消費
電力が全体で２００ｍＷ以下であること」あったとす
る。このとき、各ＶＣクラスタ内の実現例から算出され
るシステム全体の消費電力は４００（ｍＷ）であるか
ら、要求２００ｍＷに対するパーセンテージは２００
（％）になる。これにマージン２０（％）を加えると、
２２０（％）になる。この値はもちろん１００をはるか
に超えるので、消費電力というパラメータについての実
現容易性の判定は、「実現容易性は低い。ボトルネッ
ク：ＶＣ−Ｓ２の消費電力２００ｍＷ」というように行
なわれる。

【００８４】−データ転送を考慮した実現容易性判定の
例− 上述の説明では、処理時間について、各ＶＣ−Ｓ１，Ｓ
２，Ｓ３における処理時間のみを考慮し、データ転送に
要する処理時間は無視している。およそ各ＶＣけるデー
タの入出力に要する時間が均一であれば、要求自体もデ
ータ転送に要する時間を含まなければ、上述の例で不具
合はない。しかし、現実のシステムにおいては、データ
転送に要する処理時間が各ＶＣによって不均一なことも
多い。そこで、この例では、データ転送時間に要する処
理時間を考慮した実現容易性判定について説明する。こ
こでは、ＶＣの性能を平均値ＡＶＥに基づいて算出し、
これをマージンを設定せずに要求性能と直接比較するこ
とにより、実現容易性を判定する方法について説明す
る。

【００８５】例えば図１１に示すように、入力ｉ１につ
いてあるＶＣ−Ｓ１を施し、さらにＶＣ−Ｓ２を施した
後、出力Ｏ１として外部にデータを出力するシステムが
あるとする。このとき、各ＶＣ−Ｓ１，Ｓ２のＶＣがエ
ントリーされたとする。そして、ＶＣ−Ｓ１のＶＣクラ
スタ内の実現容易性判定用情報（実現例）から、処理時
間は５０サイクルで、データの入力に要する時間は１０
サイクルで、データの出力に要する時間が２０サイクル
でことがわかり、ＶＣ−Ｓ２のＶＣクラスタ内の実現容
易性判定用情報（実現例）から、処理時間は２０サイク
ルで、データの入力に要する時間は１０サイクルで、デ
ータの出力に要する時間が１０サイクルでことがわかっ
たとする。この処理時間の値は、いずれも平均ＡＶＥの
値を示している。

【００８６】このとき、処理時間についての要求が、
「入力ｉ１から出力Ｏ１までの処理時間が１００サイク
ル以下であること」であったとする。このとき、各ＶＣ
クラスタ内の実現例から算出される入力ｉ１から出力Ｏ
１までの処理時間は、１０＋５０＋２０＋２０＋１０＝
１１０（サイクル）となる。これは、要求１００サイク
ルに対して１０％大きい（１１０％）ので、実現容易で
はない。その結果、処理時間というパラメータについて
の実現容易性の判定は、例えば「実現容易性は低い。ボ
トルネック：ＶＣ−Ｓ１の処理時間５０サイクル」とい
うように行なわれる。

【００８７】−要求性能分割− 重み付けによる分割 次に、図７のフローチャートにおけるステップＳＴ５の
要求性能分割処理について説明する。

【００８８】図１１に示すシステムにおいて、処理時間
に対する要求が、「入力ｉ１から出力Ｏ１までの処理時
間が１００サイクル以下であること」であったとする。
それに対して、ＶＣクラスタの実現容易性情報から得ら
れるＶＣ−Ｓ１の処理時間が５０サイクル（平均値ＡＶ
Ｅ）で、ＶＣ−Ｓ２の処理時間が４０サイクル（平均値
ＡＶＥ）であったとする。このとき、各ＶＣ−Ｓ１，Ｓ
２の要求性能を Ｓ１： １００×｛５０／（５０＋４０）｝＝５６（サイクル） Ｓ２： １００×｛４０／（５０＋４０）｝＝４４（サイクル） の比に分割する。つまり、ＶＣ−Ｓ１，Ｓ２に対して、
それぞれ処理時間が５６（サイクル），４４（サイク
ル）というＶＣを生成すればよいことになる。

【００８９】 均等分割 この方法では、ＶＣ−Ｓ１，Ｓ２に対する要求性能を５
０（サイクル）と５０（サイクル）とに均等に分割す
る。つまり、ＶＣ−Ｓ１，Ｓ２に対して、それぞれ処理
時間が５０（サイクル），５０（サイクル）というＶＣ
を生成すればよいことになる。

【００９０】 データ転送を含めた分割 上述の図１１について説明したデータ転送を含めた処理
時間についての実現容易性の判定に用いたデータを用い
て説明する。

【００９１】この場合、ＶＣ−Ｓ１についてのデータの
入出量を含めた処理時間は、５０＋１０＋２０＝８０
（サイクル）である。ＶＣ−Ｓ２についてのデータの入
出力を含めた処理時間は２０＋１０＋１０＝４０（サイ
クル）である。このとき、各ＶＣ−Ｓ１，Ｓ２の要求性
能を Ｓ１： １００×｛８０／（８０＋４０）｝＝６６．７（サイクル） Ｓ２： １００×｛４０／（８０＋４０）｝＝３３．３（サイクル） の比に分割する。つまり、ＶＣ−Ｓ１，Ｓ２に対して、
それぞれ処理時間が６６．７（サイクル），３３．３
（サイクル）というＶＣを生成すればよいことになる。

【００９２】また、レイアウト面積，消費電力などの他
のパラメータについても、上述の処理時間における性能
分割と同様の処理を行なって、その後の設計において各
ＶＣが満たすべきレイアウト面積，消費電力などのパラ
メータを決定する。

【００９３】−仕様変更の例− ここでは、上記図９に示すシステムの実現性判定におい
て、実現容易性がない（実現困難）と判定されたとき
に、仕様を変更する例について説明する。

【００９４】処理時間に対する要求が、「入力ｉ１から
メディア出力Ｏ１までの処理時間が５００サイクル以下
で、入力ｉ１からメモリ出力Ｏ２までの処理時間が５０
０サイクル以下で、入力ｉ１からモータ出力Ｏ３までの
処理時間が１００サイクル以下であること」であったと
する。

【００９５】一方、各ＶＣ−Ｓ１〜Ｓ６に格納されてい
る実現容易性判定用情報から得られる処理時間のＭＩＮ
などに基づいて、実現容易性を判定した結果、「入力ｉ
１からメディア出力Ｏ１までの処理時間は実現容易であ
り、入力ｉ１からメモリ出力Ｏ２までの処理時間は実現
容易であり、入力ｉ１からモータ出力Ｏ３までの処理時
間は実現困難である」と判定されたとする。

【００９６】このとき、ステップＳＴ１に戻り、「ＶＣ
−Ｓ１からＶＣ−Ｓ６に至る信号経路については、ＶＣ
−Ｓ２，Ｓ５を省略する」（図９の点線参照）というよ
うに仕様そのものを変更する。この仕様の変更により、
ＶＣ−Ｓ１の処理を行なった後直接ＶＣ−Ｓ６の処理を
行なうことで、処理時間の要求に対して実現容易と判定
されることになる。この例では、ＶＣ−Ｓ２で画像圧縮
を行なった後、ＶＣ−Ｓ５でその圧縮された画像を伸長
し直して確認するという機能を果たしている。しかし、
このような確認処理を行なっていたのでは、要求性能を
満たせないことが明らかになったので、確認処理をあき
らめて直接画像データをモータ出力Ｏ３に送るという次
善の設計に変更するのである。このように変更しても、
別段不都合は生じない。

【００９７】このように、実現容易性の結果をみて可能
な範囲で仕様の変更を行うことにより、過剰な仕様によ
って設計が不可能な自体に陥るのを予め予見できる。特
に、システムＬＳＩの規模が大きくなると、下流側の設
計まで行なって試行錯誤した後に設計不可能と判定する
ような無駄な設計を行なってしまうおそれが増大する。
それに対し、この例のように、上流側での実現容易性の
判定結果によっては、要求性能を１ランク下げるなどの
仕様変更を行なうことにより、無駄な設計を回避するこ
とができる。

【００９８】−再利用を含む実現容易性判定− 今までの説明においては、システム内のいずれのＶＣに
ついても、新たに設計するという前提から、各ＶＣを新
たにＶＣＤＢ内からエントリーするものとして、実現容
易性判定について説明してきた。ここでは、システム中
の各ＶＣのうちほとんどのＶＣがすでに決まっていて、
あるＶＣのみを修正するような場合における実現容易性
の判定方法について説明する。

【００９９】例えば、図９に示すデジタルスチルカメラ
用ＬＳＩというシステムの設計において、画像圧縮処理
のＶＣ−Ｓ２のみ新たなＶＣ−Ｓ２’に置き換える。そ
して、他のＶＣ−Ｓ１，Ｓ３〜Ｓ６についてはすでに決
まっているＶＣを再利用するものとする。

【０１００】図１２は、このシステムにおける入力ｉ１
からモータ出力Ｏ３までの処理時間についての実現容易
性判定を行なう際の計算方法を示す図である。同図に示
すように、ＶＣＤＢ内には、すでに決まっているＶＣ−
Ｓ１〜Ｓ６があり、各ＶＣクラスタのＲＴ層内には設計
例データベースがあり、各ＶＣ−Ｓ１〜Ｓ６の処理時間
のデータも記述されている。そして、変更しないＶＣ−
Ｓ１，ＶＣＳ３〜Ｓ６については、各ＶＣ−Ｓ１，ＶＣ
Ｓ３〜Ｓ６にすでに登録されているデータを再利用する
ことになる。

【０１０１】そこで、入力ｉ１からモータ出力Ｏ３まで
の処理時間についての実現容易性を判定する際、修正し
ないＶＣ−Ｓ１，Ｓ５，Ｓ６については、図７のステッ
プＳＴ１では、ＶＣ−Ｓ１，Ｓ２’Ｓ５，Ｓ６をＶＣＤ
Ｂからエントリーするとともに、図７のステップＳＴ４
においては、ＶＣ−Ｓ１，Ｓ５，Ｓ６各内のＲＴ層に記
述された処理時間の値Ｘ１，Ｘ５，Ｘ６を取り込む。一
方、修正するＶＣ−Ｓ２については、新たにＶＣＤＢ内
からエントリーしたＶＣ−Ｓ２’の仕様層に格納されて
いる実現容易性判定用情報のデータＹ２を用いる。そし
て、例えば、この経路の処理時間の合計値（Ｘ１＋Ｙ２
＋Ｘ５＋Ｘ６）と要求される処理時間とを比較して、実
現容易性を判定する。

【０１０２】その場合、上述の各種の方法を採用するこ
とができる。例えば、処理時間のデータＹ２として平均
値ＡＶＥを採用して、その合計値が要求される処理時間
以下か否かによって判定してもよい。あるいは、処理時
間のデータＹ２として最小値ＭＩＮを採用して、この合
計値の要求される処理時間に対するパーセンテージを求
め、これにマージンを加えた値が１００（％）以下であ
れば実現容易と判定するようにしてもよい。また、デー
タの入出力に要する時間を考慮する場合も、ＶＣ−Ｓ２
のデータ入力に要する時間と、ＶＣ−Ｓ２自体の処理時
間と、データの出力に要する時間とを、ＶＣ−Ｓ２’の
実現容易性判定用情報から取り出してくればよい。

【０１０３】（第２の実施形態）次に、要求分割による
実現容易性判定を行なうようにした第２の実施形態につ
いて説明する。図１３は、本実施形態における仕様レベ
ルの設計手順を示すフローチャートである。

【０１０４】まず、ステップＳＴ１１〜ＳＴ１３では、
上記第１の実施形態におけるステップＳＴ１〜ＳＴ３と
同様の処理を行なう。

【０１０５】次に、ステップＳＴ１４で、事前の要求性
能分割を行なう。例えば、図１４に示すように、入力ｉ
１から出力Ｏ１までの処理時間に対する要求が１００サ
イクルである場合に、第１の実施形態におけるステップ
ＳＴ５の処理について行なった分割と同様にして、Ｓ
１：Ｓ２＝５６（サイクル）：４４（サイクル）に分割
されたものとする。

【０１０６】次に、ステップＳＴ１５で、各ＶＣ−Ｓ
１，Ｓ２の仕様ＶＣに対して、分割された要求性能を満
足する実現例を探索する。そして、例えばＶＣ−Ｓ１の
仕様ＶＣの実現容易性判定用情報に記述されている処理
時間の最小値が６０サイクルで、ＶＣ−Ｓ２の仕様ＶＣ
の実現容易性判定用情報に記述されている処理時間の最
小値が４３サイクルであったとする。このときには、Ｖ
Ｃ−Ｓ１に対して要求される処理時間５６サイクルを実
現した例はなく、ＶＣ−Ｓ２に対しては要求される処理
時間４４サイクルを実現した例があることになる。

【０１０７】次に、ステップＳＴ１６で、実現例の割合
が所定値以上か否かを判定する。ＶＣ−Ｓ１，Ｓ２に対
する実現例の割合は５０％である。そこで、判定のため
の所定値を例えば６０％とすると、実現容易性はない
（つまり実現困難）ことになる。その結果、実現容易性
の判定は、例えば「実現容易性なし。ボトルネック：Ｖ
Ｃ−Ｓ１の処理時間６０サイクル」というように表示さ
れる。

【０１０８】その後、実現容易性がなければ、ステップ
ＳＴ１１に戻って、要求に応じたＶＣを生成するか、新
たなＶＣは生成せずに要求のレベルを下げた後、ステッ
プＳＴ１２〜ＳＴ１６の処理を繰り返す。また、要求を
満足するＶＣの生成が容易かどうかをも実現容易性の判
定に含めることもできる。

【０１０９】このように、ステップＳＴ１１〜ＳＴ１６
を繰り返すことにより、一応実現が可能であろうと推定
されるシステムが生成される。

【０１１０】その後、任意のステップとして、ステップ
ＳＴ１６で、新たに生成の必要なＶＣの数に応じて、あ
る程度の工数の見積りを行なった後、ステップＳＴ１７
で、その見積り結果が予定工数内か否かを判定して、予
定工数内でなければステップＳＴ１１に戻るようにして
もよい。このように、工数見積り結果に応じて仕様を作
成し直すこともあり得る。

【０１１１】図１５は、ＶＣＤＢ内の工数見積り用情報
を説明するための図である。同図に示すように、ＶＣＤ
Ｂ内に、仕様ＶＣの工数データとして、新規にＶＣを開
発した場合の工数（人・月）と、すでに存在するＶＣを
再利用する場合の工数（人・月）とが格納されている。
そして、実現容易性判定を行なう際には、各ＶＣに対し
て実現例があれば再利用を図り、実現例がなければ新規
にＶＣを開発するものとする。この新規にＶＣを開発す
るのに必要な工数の見積り値は、仕様ＶＣのクラスタ内
の既存のＲＴＬ−ＶＣを新規設計した際の工数をデータ
ベース化したものであり、再利用する場合の工数の見積
り値は、仕様ＶＣのクラスタ内のＲＴＬ−ＶＣを再利用
した際の工数をデータベース化したものである。

【０１１２】ここで、図１４に示すシステムの設計に関
する例では、ＶＣ−Ｓ１の分割された要求５６サイクル
に対して、ＶＣ−Ｓ１については、ＶＣＤＢ内の仕様Ｖ
Ｃの実現容易性判定用情報に記述されている処理時間６
０サイクルからみて実現例はなく、ＶＣ−Ｓ２について
は、ＶＣＤＢ内の実現容易性判定用情報に記述されてい
る処理時間４３サイクルからみて実現例があった。そし
て、ＶＣ−Ｓ１については、ステップＳＴ１１に戻った
ときに、要求性能を下げるのではなく、ＶＣを新規に開
発することが決まっていたものとすると、工数は３０人
・月と見積もられる。一方、ＶＣ−Ｓ２については、既
存のＶＣを再利用できるので、工数は１５人・月と見積
もられる。その結果、トータルの工数は、４５人・月と
見積もられることになる。

【０１１３】このような工数の見積りを行なうことによ
って、納期と工数とを比較して必要な設計者の数を把握
することもできる。

【０１１４】なお、すべてのＶＣに対して、既存のＶＣ
を用いる場合、あるいはすべてのＶＣを新規に開発する
場合も、工数の見積りを行なうようにしてもよい。な
お、工数見積りに応じて仕様を作成し直すこともあり得
る。

【０１１５】なお、以上の説明では、工数見積りを図１
３のフローチャートのステップＳＴ１７において行なっ
たが、この工数見積りの手順は、図７のフローチャート
のステップＳＴ６においても行なうことができる。この
場合にも、ステップＳＴ１に戻った処理において、ある
処理については新規にＶＣを開発することが決まってい
ることがある。なお、すべてのＶＣに対して、既存のＶ
Ｃを用いる場合、あるいはすべてのＶＣを新規に開発す
る場合も、工数の見積りを行なうようにしてもよい。

【０１１６】

【発明の効果】本発明の集積回路装置の設計のためのデ
ータベース又は設計方法によると、仕様レベルという上
流側の設計において、要求性能の実現容易性を判定する
ためのデータベースを準備し、あるいはこのデータベー
スを用いて実現容易性を判定するようにしたので、無理
な要求性能の設定などによる再設計の繰り返しや設計不
可能に陥る事態を回避することができ、大規模な集積回
路装置の設計の容易化を図ることができる。

【図面の簡単な説明】

【図１】本発明の実施形態に係るシステムＬＳＩ設計の
ためのデザインシステム（ＶＣＤＳ）の構成を概念的に
示す図である。

【図２】本発明の各実施形態のＶＣＤＳにおける設計の
基本的な流れを示す図である。

【図３】図１に示すシステムの機能部分を抜き出して示
すブロック回路図である。

【図４】ＶＣクラスタの機能を詳細に説明する図であ
る。

【図５】本発明の各実施形態における各ＶＣの構造を示
す図である。

【図６】設計の各層におけるＶＣのデータ及び性能情報
の相違点を示すための図である。

【図７】第１の実施形態における実現容易性判定を含む
仕様層の設計手順を示すフローチャート図である。

【図８】第１の実施形態におけるデータベースの特徴的
な部分を抜き出して示す図である。

【図９】機能モデルの一例として、デジタルスチルカメ
ラ用ＬＳＩの機能モデルを示すブロック図である。

【図１０】第１の実施形態における処理時間と消費電力
とからみた実現容易性判定の例を説明するためのシステ
ムのブロック回路図である。

【図１１】第１の実施形態におけるデータ転送を考慮し
た実現容易性判定の例を説明するためのシステムのブロ
ック回路図である。

【図１２】第１の実施形態における再利用を含む実現容
易性判定の例を説明するためのシステムのブロック回路
図である。

【図１３】第２の実施形態における仕様レベルの設計手
順を示すフローチャートである。

【図１４】第２の実施形態における事前の要求性能分割
の例を説明するためのシステムのブロック回路図であ
る。

【図１５】第１又は第２の実施形態におけるＶＣＤＢ内
の工数見積り用情報を説明するための図である。

【図１６】一般的なＬＳＩの設計手順を示すフローチャ
ート図である。

【符号の説明】 １ ＶＣＤＢ（ＶＣデータベース） ２ ＶＣＤＢＭＳ（ＶＣデータベースマネージャ） ３ ＶＣクラスタ ４ アーキテクチャ情報 ５ 仕様ＶＣ ６ 動作ＶＣ ７ ＲＴＬ−ＶＣ １０ データベース格納層 １１ 入力部 １２ 出力部 １３ 制御部 １４ 仕様動作層 １５ ＲＴ層

Claims (24)

【特許請求の範囲】
1. 【請求項１】 複数の要素からなる集積回路装置を設計
   するために必要なデータを格納するデータベースであっ
   て、 上記各要素を設計するために必要なデータを、少なくと
   も仕様ＶＣ（バーチャル・コア）と、ＲＴＬ−ＶＣとに
   分けて格納するＶＣクラスタと、 上記仕様ＶＣに格納され、その仕様に対する当該ＶＣク
   ラスタ中のＲＴＬ−ＶＣの性能に関するデータである実
   現容易性判定用情報とを備えていることを特徴とする集
   積回路装置の設計用データベース。
2. 【請求項２】 請求項１記載の集積回路装置の設計用デ
   ータベースにおいて、 上記実現容易性判定用情報は、処理時間，レイアウト面
   積，消費電力及びテストコストのうち少なくともいずれ
   か１つに関するデータを含んでいることを特徴とする集
   積回路装置の設計用データベース。
3. 【請求項３】 請求項１又は２記載の集積回路装置の設
   計用データベースにおいて、 上記実現容易性判定用情報は、処理時間とデータの入出
   力に要する時間とに関するデータを少なくとも含んでい
   ることを特徴とする集積回路装置の設計用データベー
   ス。
4. 【請求項４】 請求項１〜３のうちいずれか１つに記載
   の集積回路装置の設計用データベースにおいて、 上記実現容易性判定用情報は、その仕様に対するＲＴＬ
   −ＶＣが複数個ある場合には、上記データを各ＲＴＬ−
   ＶＣの最小値，平均値，最大値及び最適値のうち少なく
   ともいずれか１つとして含んでいることを特徴とする集
   積回路装置の設計用データベース。
5. 【請求項５】 請求項１〜４のうちいずれか１つに記載
   の集積回路装置の設計用データベースにおいて、 上記仕様ＶＣに格納され、その仕様に対するＶＣの新規
   開発に要する工数と、その仕様に対するＶＣの再利用に
   要する工数とに関するデータである工数見積り用情報を
   さらに備えていることを特徴とする集積回路装置の設計
   用データベース。
6. 【請求項６】 複数の要素からなる集積回路装置を設計
   するために必要なデータを格納するデータベースであっ
   て、 上記各要素を設計するために必要なデータを、少なくと
   も、仕様ＶＣ（バーチャル・コア）と、ＲＴＬ−ＶＣと
   に分けて格納するＶＣクラスタと、 上記仕様ＶＣに格納され、その仕様に対するＶＣの新規
   開発に要する工数と、その仕様に対するＶＣの再利用に
   要する工数とに関するデータである工数見積り用情報と
   を備えていることを特徴とする集積回路装置の設計用デ
   ータベース。
7. 【請求項７】 請求項１〜６のうちいずれか１つに記載
   の集積回路装置の設計用データベースにおいて、 上記仕様ＶＣは、仕様・動作ＶＣとして動作ＶＣと一体
   化されていることを特徴とする集積回路装置の設計用デ
   ータベース。
8. 【請求項８】 複数の要素からなる集積回路装置の各要
   素を設計するために必要なデータを少なくとも仕様ＶＣ
   （バーチャル・コア）とＲＴＬ−ＶＣとに分けて格納す
   るＶＣクラスタと、上記仕様ＶＣに格納され、その仕様
   に対するＲＴＬ−ＶＣの性能に関するデータである実現
   容易性判定用情報とを含むデータベースを用いた集積回
   路装置の設計方法であって、 上記各要素に対応する仕様ＶＣをエントリーするステッ
   プ（ａ）と、 上記仕様ＶＣの実現容易性判定用情報に基づいて、上記
   エントリーした仕様ＶＣを用いた集積回路装置の設計の
   容易性を判定するステップ（ｂ）とを含む集積回路装置
   の設計方法。
9. 【請求項９】 請求項８記載の集積回路装置の設計方法
   において、 上記実現容易性判定用情報は、処理時間，レイアウト面
   積，消費電力及びテストコストのうち少なくともいずれ
   か１つに関するデータを含んでおり、 上記ステップ（ｂ）における判定を、処理時間，レイア
   ウト面積，消費電力及びテストコストのうち少なくとも
   いずれか１つについて行なうことを特徴とする集積回路
   装置の設計方法。
10. 【請求項１０】 請求項８又は９記載の集積回路装置の
    設計方法において、 上記実現容易性判定用情報は、処理時間とデータの入出
    力に要する時間とを少なくとも含んでおり、 上記ステップ（ｂ）における判定を、データ転送に要す
    る時間と処理時間とについて行なうことを特徴とする集
    積回路装置の設計方法。
11. 【請求項１１】 請求項８〜１０のうちいずれか１つに
    記載の集積回路装置の設計方法において、 上記実現容易性判定用情報は、上記データを各ＲＴＬ−
    ＶＣの最小値，平均値，最大値及び最適値のうち少なく
    ともいずれか１つとして含んでおり、 上記ステップ（ｂ）における判定を、上記パラメータの
    最小値，平均値，最大値及び最適値のうち少なくともい
    ずれか１つについて行なうことを特徴とする集積回路装
    置の設計方法。
12. 【請求項１２】 請求項８〜１１のうちいずれか１つに
    記載の集積回路装置の設計方法において、 上記ステップ（ｂ）における判定を、上記性能の要求値
    と、上記仕様ＶＣの実現容易性判定用情報から得られる
    ＶＣの性能とを比較することにより行なうことを特徴と
    する集積回路装置の設計方法。
13. 【請求項１３】 請求項１２記載の集積回路装置の設計
    方法において、 上記ステップ（ｂ）における判定を、上記性能の要求値
    を１００としたときの，上記ＶＣの性能のパーセンテー
    ジを指標として行なうことを特徴とする集積回路装置の
    設計方法。
14. 【請求項１４】 請求項１２又は１３記載の集積回路装
    置の設計方法において、 上記ステップ（ｂ）における判定を、複数のＶＣのうち
    ある性能についてもっとも実現容易性が低いＶＣをボト
    ルネックとして抽出しながら行なうことを特徴とする集
    積回路装置の設計方法。
15. 【請求項１５】 請求項１２〜１４のうちいずれか１つ
    に記載の集積回路装置の設計方法において、 上記ステップ（ｂ）では、上記複数の要素のうち再利用
    可能な要素についてはその要素に対応するＶＣクラスタ
    のＲＴＬ−ＶＣの性能を用い、他の要素についてはその
    要素に対応するＶＣクラスタの仕様ＶＣの上記実現容易
    性判定用情報中の性能を用いることを特徴とする集積回
    路装置の設計方法。
16. 【請求項１６】 請求項１２〜１４のうちいずれか１つ
    に記載の集積回路装置の設計方法において、 設計実現例のある機能モデルを再利用し、その一部の要
    素を変更して機能モデルを作成する場合に、上記ステッ
    プ（ｂ）では、上記複数の要素のうち再利用可能な要素
    については、設計実現例で使用されたＶＣクラスタのＲ
    ＴＬ−ＶＣの性能を用いることを特徴とする集積回路装
    置の設計方法。
17. 【請求項１７】 請求項１２〜１６のうちいずれか１つ
    に記載の集積回路装置の設計方法において、 上記ステップ（ｂ）の後、全体の要求性能を上記複数の
    要素に対応する各ＶＣごとに、重み付して分割するステ
    ップをさらに備えていることを特徴とする集積回路装置
    の設計方法。
18. 【請求項１８】 請求項１２〜１６のうちいずれか１つ
    に記載の集積回路装置の設計方法において、 上記ステップ（ｂ）の後、全体の要求性能を上記複数の
    要素に対応する各ＶＣごとに、均等に分割するステップ
    をさらに備えていることを特徴とする集積回路装置の設
    計方法。
19. 【請求項１９】 請求項１７又は１８記載の集積回路装
    置の設計方法において、 上記データベースの仕様ＶＣには、その仕様に対するＶ
    Ｃの新規開発に要する工数と、その仕様に対するＶＣの
    再利用に要する工数とに関するデータである工数見積り
    用情報とがさらに格納されており、 上記性能を分割するステップの後、各要素に対応する仕
    様ＶＣの工数見積り情報から各要素の工数を見積もるス
    テップをさらに備えていることを特徴とする集積回路装
    置の設計方法。
20. 【請求項２０】 請求項８〜１１のうちいずれか１つに
    記載の集積回路装置の設計方法において、 上記ステップ（ａ）を行なった後、上記ステップ（ｂ）
    を行なう前に、全体の要求性能を上記各ＶＣごとに分割
    するステップをさらに備え、 上記ステップ（ｂ）における判定を、各要素に対応する
    仕様ＶＣの実現容易性判定用情報から各要素の分割され
    た性能を満たす実現例の割合が所定値以上か否かによっ
    て行なうことを特徴とする集積回路装置の設計方法。
21. 【請求項２１】 請求項２０記載の集積回路装置の設計
    方法において、 上記全体の要求性能の分割を、各ＶＣごとに重み付けし
    て行なうことを特徴とする集積回路装置の設計方法。
22. 【請求項２２】 請求項２０記載の集積回路装置の設計
    方法において、 上記全体の要求性能の分割を、各ＶＣごとに均等に行な
    うことを特徴とする集積回路装置の設計方法。
23. 【請求項２３】 請求項２０〜２２のうちいずれか１つ
    に記載の集積回路装置の設計方法において、 上記ステップ（ｂ）における判定を、複数のＶＣのうち
    ある性能についてもっとも実現容易性が低いＶＣをボト
    ルネックとして抽出しながら行なうことを特徴とする集
    積回路装置の設計方法。
24. 【請求項２４】 請求項２０〜２３のうちいずれか１つ
    に記載の集積回路装置の設計方法において、 上記データベースの仕様ＶＣには、その仕様に対するＶ
    Ｃの新規開発に要する工数と、その仕様に対するＶＣの
    再利用に要する工数とに関するデータである工数見積り
    用情報とがさらに格納されており、 上記ステップ（ｂ）の後、各要素に対応する仕様ＶＣの
    工数見積り情報から各要素の工数を見積もるステップを
    さらに備えていることを特徴とする集積回路装置の設計
    方法。