(57)【要約】  【課題】大規模集積回路の開発方法及び開発ツールに関し、アーキテクチャ検討、論理設計・検証、論理合成、インプリメント設計をコンカレントに行なう大規模集積回路の開発方法及び該大規模集積回路の開発方法を実施するための大規模集積回路の開発ツールを提供する。   【解決手段】回路アーキテクチャ検討と大規模集積回路チップのフロアプランニングをコンカレントに進め、回路アーキテクチャ検討においてチップを機能的に分割したブロックのポート情報と、チップのポート情報とからポート間の接続情報としてのブロック間ネットリストを生成して大規模集積回路を開発する。【選択図】図１
2005353079.tif 000002
【特許請求の範囲】
【請求項１】
回路アーキテクチャ検討と大規模集積回路チップのフロアプランニングをコンカレントに進め、
回路アーキテクチャ検討においてチップを機能的に分割したブロックのポート情報と、チップのポート情報とからポート間の接続情報としてのブロック間ネットリストを生成し、上記ブロック間ネットリストを、論理設計・検証、論理合成、レイアウト及びタイミング検証の共通データとし、
該論理設計・検証、該論理合成、該レイアウト及びタイミング検証をコンカレントに進める
ことを特徴とする大規模集積回路の開発方法。
【請求項２】
請求項１に記載のブロック分割に引き続いて、ブロック内のクロックツリー作成とフロアプランニングを行ない、
論理設計に先立ってクロックスキューの調整を行なう
ことを特徴とする大規模集積回路の開発方法。
【請求項３】
請求項１に記載のブロック分割の結果とブロック間ネットリストとを使用して、
該ブロックはブラックボックスのままでチップにおけるブロックの配置とブロック間の配線をするレイアウトを行ない、
ブロック間の配線数、ファンアウト及び配線によって生ずる負荷を算出し、
ブロック内部の論理合成の条件とする
ことを特徴とする大規模集積回路の開発方法。
【請求項４】
請求項２に記載のクロックツリーと、請求項３に記載の論理合成の条件とを使用して、
論理設計が完了したブロックから順に論理合成を行ない、請求項１に記載のブロック間ネットリストに填め込む
ことを特徴とする大規模集積回路の開発方法。
【請求項５】
論理合成が完了したブロックから順にブロック内レイアウトを行ない、
チップのレイアウトをビルディングブロック方式で進める
ことを特徴とする大規模集積回路の開発方法。
【請求項６】
設計者が操作して論理設計を行なう設計端末と、
該論理設計の結果であるＲＴＬソースを格納するファイルサーバと、
該ＲＴＬソースを常時監視する監視サーバと、
該ネットワークを介して種々のメールを配信するメールサーバと、
該ＲＴＬ設計が終了したブロックについて論理合成を行なう合成サーバと
上記設計端末、ファイルサーバ、監視サーバ及び合成サーバを収容するネットワークと
を備えることを特徴とする大規模集積回路の開発ツール。
【請求項７】
請求項６に記載の大規模集積回路の開発ツールにおいて、
上記監視サーバは、
上記設計端末からの監視開始依頼コマンドによって監視を開始する監視サーバである
ことを特徴とする大規模集積回路の開発ツール。
【請求項８】
請求項６に記載の大規模集積回路の開発ツールにおいて、
上記合成サーバは、
上記設計端末又は監視サーバからの合成依頼コマンドによって論理合成を開始する合成サーバである
ことを特徴とする大規模集積回路の開発ツール。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、大規模集積回路の開発方法及び開発ツールに係り、特に、回路アーキテクチャ検討とインプリメント設計の一部であるフロアプランニングをコンカレントに行ない、論理設計・検証、論理合成とインプリメント設計の一部であるレイアウト及びタイミング検証をコンカレントに行なう大規模集積回路の開発方法及び該大規模集積回路の開発方法によって大規模集積回路を開発するための大規模集積回路の開発ツールに関する。
【背景技術】
【０００２】
通信装置、情報処理装置の高機能化、高速処理化及び小型化の要請は強いものであり、それらを実現するためには大規模集積回路によって回路を実現することが必須である。
【０００３】
特に、通信装置においては、ＡＳＩＣ（Application Specific Integrated Circuit)と呼ばれる通信装置特有の機能を実現するための大規模集積回路が適用されることが多く、しかも、ＡＳＩＣの大規模化が急速に進んでおり、所謂メガゲートＡＳＩＣの時代に突入している。
【０００４】
もとより、集積回路の大規模化は設計を困難なものにするため、設計品質を確保するためには必然的に設計手番の長期化を招く。
【０００５】
しかし、一方では通信装置の短納期化の要求が一層強くなっている。従って、通信装置メーカーがＡＳＩＣを開発・適用するにしても、専業の集積回路メーカーがＡＳＩＣを開発・供給するにしても、或いはソフトベンダーが集積回路を開発するにしても、市場競争力維持のためには短納期での開発が必須になる。
【０００６】
しかも、ＡＳＩＣは通信装置特有の機能を実現するものであり、標準的な回路構成を適用できないことが多いので、新しい通信装置の開発の度に新規の構成による設計を行なう必要がある上、開発の作業量はＡＳＩＣの大規模化の比率より高い比率で増加してゆくため、開発に要する人員も大幅に増加している。このようなＡＳＩＣ開発の環境にあっても開発された物の信頼度は絶対に維持しなければならない。
【０００７】
このように、短納期の開発と開発された物の信頼度維持という矛盾した要求を満足させつつＡＳＩＣを開発することが、通信装置メーカーとしても、集積回路専業メーカーとしても、ソフトベンダーとしても必須事項となり、この問題を解決したメーカーだけが厳しい競争を勝ち抜いてゆくことができる。
【０００８】
現在、ＡＳＩＣを初めとする大規模集積回路は、ＶＨＤＬ、Ｖｅｒｉｌｏｇ等による機能記述言語設計と論理合成を組み合わせた方法によって開発するのが主流であるが、このような大規模集積回路開発の全工程は大きく分けると以下の工程に分けることができる。
【０００９】
即ち、
ａ．回路構造を検討する回路アーキテクチャ検討
ｂ．機能記述言語によるＲＴＬ（Register Transfer Level)設計とその検証を行なう論理設計・検証
ｃ．回路を論理的に合成して最適化する論理合成
ｄ．フロアプランニング、レイアウト、タイミング調整・検証を行なうインプリメント設計
の４つの工程である。
【００１０】
図２０は、従来の大規模集積回路開発の流れを示す。
【００１１】
ここで、図２０における太い矢印付実線は順方向の設計の流れを示し、細い矢印付実線は設計の手戻りを示している。
【００１２】
図２０に明確に示されているように、従来の大規模集積回路開発においては、上記回路アーキテクチャ検討、論理設計・検証、論理合成及びインプリメント設計が時系列的にシリアルになっており、前の工程が終了しなければ後の工程に移ることはない。この意味で時間的に順方向の作業だけで開発を終了させることができるなら、開発工程は単純である。
【００１３】
図２１は、従来の大規模集積回路の開発手順をもう少し詳細に示したものである。ここで、太い矢印付実線は開発の流れを示し、細い矢印付破線はデータの流れを示す。
【００１４】
以降、図２１の各開発段階に付した符号に沿って、従来の大規模集積回路の開発手順を説明する。  
【００１５】
Ｓ１５１．要求仕様、要求検討項目を元に、回路の構造を検討して全体回路を機能的なブロックに分割し、要求検証項目をブロック単位に分解する。
【００１６】
Ｓ１５２．ステップＳ１５１の回路アーキテクチャ検討で分割したブロック単位に機能記述言語を用いて回路設計してＲＴＬ（Registor Transfer Level)リストを出力すると共に、対象ブロックの機能確認項目をステップＳ１５１の回路アーキテクチャ検討で分割した検証項目に従って細分化し、更に、ブロック固有の機能確認項目を検証項目に追加する。
【００１７】
そして、この段階でブロックの端子同士及びブロックの端子と大規模集積回路のチップの端子の接続情報であるブロック間ネットリストの草案を生成する。
【００１８】
Ｓ１５３．該ＲＴＬリストと該検証項目を使ってブロック単位に論理検証を行なう。
【００１９】
Ｓ１５４．該論理検証の結果に問題があるか否かを判断する。問題がある（Ｙｅｓ）と判断された場合には、ステップＳ１５２のＲＴＬ設計に戻って回路設計を更新し、問題がないと判断されるまでステップＳ１５２及びステップＳ１５３を繰り返す。
【００２０】
Ｓ１５５．ステップＳ１５４で問題がない（Ｎｏ）と判断された場合には、全ブロックについてＲＴＬ設計と論理検証が終了したか否かを判断する。この判断結果が全ブロックで終了していない（Ｎｏ）と判断された場合には、ステップＳ１５２のＲＴＬ設計に戻り、全ブロックが終了したと判断されるまでステップＳ１５２及びステップＳ１５３を実施する。
【００２１】
Ｓ１５６．ステップＳ１５６の判断結果が全ブロック終了（Ｙｅｓ）の場合には、ステップＳ１５２の結果であるＲＴＬリストを使用して論理合成を行い、ステップＳ１５２のＲＴＬ設計で草案を作成していたブロック間ネットリストを確定し、該ブロック間ネットリストに論理合成結果を填め込むことで、全体のネットリストを生成する。
【００２２】
Ｓ１５７．上記論理合成に問題があるか否かを判断する。この判断結果が問題あり（Ｙｅｓ）の場合には、ステップＳ１５２のＲＴＬ設計又はステップＳ１５１の回路アーキテクチャ検討に戻って設計を更新し、問題なしと判断されるまで論理合成までを繰り返す。
【００２３】
Ｓ１５８．ステップＳ１５７の判断結果が問題なし（Ｎｏ）の時は、ステップＳ１５６の論理合成の出力であるネットリストを元にチップのフロアプランニングを行なう。
【００２４】
Ｓ１５９．上記フロアプランニングの結果に問題があるか否かを判断する。この判断結果が問題あり（Ｙｅｓ）の場合には、ステップＳ１５６の論理合成又はステップＳ１５２のＲＴＬ設計又はステップＳ１５１の回路アーキテクチャ検討に戻り、この判断結果が問題なしとなるまで設計を更新する。
【００２５】
Ｓ１６０．ステップＳ１５８の判断結果が問題なし（Ｎｏ）の時は、レイアウトを行い、ＳＤＦ（Standard Delay File)を生成する。
【００２６】
Ｓ１６１．ステップ１６０の出力であるＳＤＦを元にタイミング検証をする。
【００２７】
Ｓ１６２．上記タイミング検証の結果に問題があるか否かを判断する。この判断結果が問題あり（Ｙｅｓ）の場合には、ステップＳ１５８のフロアプランニング又はステップＳ１５６の論理合成又はステップＳ１５１の回路アーキテクチャ検討に戻り、この判断結果が問題なしとなるまで設計の更新を行なう。
【００２８】
そして、上記判断の結果が問題なし（Ｎｏ）の場合には設計を終了する。
【００２９】
尚、上記設計工程の区分を示すアルファベット小文字を図２１中に記載してある。即ち、ステップＳ１５１が上記回路アーキテクチャ検討ａであり、ステップＳ１５２からステップＳ１５５までが上記論理設計・検証ｂであり、ステップＳ１５６及びステップＳ１５７が上記論理合成ｃであり、ステップＳ１５８以降が上記インプリメント設計ｄである。
【００３０】
つまり、図２１の開発手順では、図２０の開発工程の流れに示したように、回路アーキテクチャ検討、論理設計・検証、論理合成及びインプリメント設計がシリアルに行なわれている。
【発明の開示】
【発明が解決しようとする課題】
【００３１】
しかし、大規模集積回路の開発において各設計ステップが１回で終わることは稀で、仕様変更、設計ミス、タイミングエラーなどが発生する。このため、往々にして後の設計工程から前の設計工程に後戻りすることが起こる。
【００３２】
例えば、図２１のステップＳ１５４で論理検証の結果に問題あり（Ｙｅｓ）と判断された場合には、ステップＳ１５２のＲＴＬ設計を再度行なうことになる。
ただ、これは論理設計と論理検証という表裏一体の工程であるので、設計工程を混乱させることはない。
【００３３】
問題になるのは、それより後の工程から前の工程への後戻りである。
【００３４】
即ち、ステップＳ１５６の論理合成の後で、ステップＳ１５７で論理合成に問題あり（Ｙｅｓ）と判断された場合には、ステップＳ１５２のＲＴＬ設計又はステップＳ１５１の回路アーキテクチャ検討に後戻りし、ステップＳ１５８のフロアプランニングの後のステップＳ１５９でフロアプランニングに問題あり（Ｙｅｓ）と判断された場合には、ステップＳ１５６の論理合成又はステップＳ１５２のＲＴＬ設計又はステップＳ１５１の回路アーキテクチャ検討に後戻りし、ステップＳ１６１のタイミング検証の後のステップＳ１６２でタイミング検証に問題あり（Ｙｅｓ）と判断された時は、ステップＳ１５７のフロアプランニング又はステップＳ１５５の論理合成又はステップＳ１５１の回路アーキテクチャ検討に後戻りする。そして、こういう後戻りが幾度となく繰り返される。
【００３５】
尚、図２０にも上記の後戻りが起こり得る箇所に矢印付実線を描いている。
【００３６】
それらの後戻りは単に終結した筈の工程を再度繰り返すだけではなく、各々の後戻りの原因に矛盾があることが多いので、特定の工程間で後戻りして設計を更新すると他の工程間でも後戻りしなくてはならないということになって、開発のための作業がなかなか収斂しないという事態にもつながる。
【００３７】
このような場合には、大規模集積回路開発の効率を著しく低下させ、開発工程も極めて長期に及ぶ。これにより、通信装置メーカーであっても、大規模集積回路メーカーであっても、ソフトベンダーであっても競争力の低下を免れることができなくなる。
【００３８】
今迄は、これに対して
ＣＡＤマシンの高性能化、即ち、サーバなどのＣＡＤマシン自体の処理能力アップ
ＣＡＤツールの高速化、即ち、ＣＡＤツールに搭載されているソフトウェアによる処理速度アップ（例えば、シリアル処理をパラレル処理にして処理速度をアップすること等）
繰り返しチェックすることによるミスの逓減
等によって開発効率の低下と工程の長期化を防止すべく努めてきたが、大規模集積回路の一層の大規模化によって、ＣＡＤマシンの高性能化、ＣＡＤツールの高速化及び繰り返しチェックによるミスの逓減だけでは開発効率の低下と工程の長期化を防止することは不可能に近くなってきた。
【００３９】
本発明は、かかる問題に鑑み、回路アーキテクチャ検討、論理設計・検証、論理合成、インプリメント設計をコンカレントに行なう大規模集積回路の開発方法及び該大規模集積回路の開発方法によって大規模集積回路を開発するための大規模集積回路の開発ツールを提供し、大規模集積回路開発を効率化することと、開発された大規模集積回路の品質を向上させることを目的とする。
【課題を解決するための手段】
【００４０】
図１は、本発明の大規模集積回路の開発工程の流れである。ここで、図１における太い矢印付実線は順方向の工程を示し、細い矢印付実線及び細い矢印付破線は後戻りの工程を示している。
【００４１】
図１に明確に表現されているように、本発明の特徴は、
回路アーキテクチャ検討とインプリメント設計の一工程であるフロアプランニングを並行して行い、回路アーキテクチャ検討が終了した時にはフロアプランニングも確定している点、
回路アーキテクチャ検討の工程とフロアプランニングの工程において生成された設計条件や設計データを、後続の論理設計・検証（ＲＴＬ設計、論理検証）、論理合成及びレイアウトの工程で共通に使用するデータとし、全ての工程間で設計条件や設計データに矛盾が生ずることを防止する点
にある。
【００４２】
図２は、本発明の大規模集積回路開発の原理的手順で、本発明による大規模集積回路の開発工程の流れを若干詳細に示している。尚、図２において、太い矢印付実線は開発の流れを示し、細い矢印付破線はデータの流れを示している。
【００４３】
以降、図２の各開発段階に付した符号に沿って、本発明の大規模集積回路開発の原理的手順について説明する。
【００４４】
Ｓ１．要求仕様と要求検証項目を入力として、大規模集積回路を機能的なブロックに分割すると共に該ブロック単位に下記の（イ）から（チ）の項目を見積もったり設定して、回路構造を検討する。
【００４５】
（イ）ブロックに収容可能か否かを判断するためのフリップフロップ数
（ロ）チップの入出力ポート情報及びブロックの入出力ポート情報
（ハ）実現規模
（ニ）クロック駆動能力判定のための、入力クロック種類毎のフリップフロップのグループ数
（ホ）クロックツリー
（ヘ）チップ面積推定のための読み出し専用メモリ（ＲＯＭ）とランダムアクセスメモリ（ＲＡＭ）の使用個数と規模
（ト）動作速度
（チ）ブロック単位の機能検証項目
上記（イ）から（チ）を見れば明らかな如く、この段階でフロアプランニングの草案が検討されている。
【００４６】
Ｓ２．ステップＳ１の回路アーキテクチャ検討の結果出力されるチップの入出力ポート情報とブロック単位の入出力ポート情報を入力として、ブロック間ネットリストを作成する。具体的には、同じ名称のポート同士を接続するという作業を行ない、接続情報をリスト化する。
【００４７】
ここで作成されたブロック間ネットリストは、ブロックの中はブラックボックスになっていて、ブロック間及びブロックとチップの間の配線情報だけを含んだもので、後で説明するように、論理設計とインプリメント設計双方の共通のデータとなる。
【００４８】
Ｓ３．ステップＳ１の回路アーキテクチャ検討における上記（イ）から（チ）までの見積り結果又は設定結果と、ステップＳ２において作成されたブロック間ネットリストを入力として、ブロック内部はブラックボックスのままでチップ上でブロックのレイアウトをして、ブロック間配線が可能な面積を見積ってブロック間配線の実現性を検証する。
【００４９】
Ｓ４．ステップＳ３のフロアプランニングの結果に問題があるか否か、即ち、全てのブロックの配置と、ブロック間及びブロック・チップ間の配線に問題がないか否かを判断する。
【００５０】
問題がある（Ｙｅｓ）と判定された場合にはステップＳ１の回路アーキテクチャ検討に戻り、ブロック分割を変更して、ステップＳ２及びステップＳ３を繰り返す。ステップＳ１の説明の最後尾に記載した如く、ステップＳ１の回路アーキテクチャ検討においてフロアプランニングの草案を検討しているので、ここでステップＳ１に戻ることは実質的には少ない。
【００５１】
このように、フロアプランニングを早期に行って確定することにより、従来はレイアウトの後で行なうタイミング検証で初めて判るタイミングエラーによってＲＴＬ設計又は回路アーキテクチャ検討に後戻りしていたのを回避できる。
【００５２】
そして、回路アーキテクチャ検討、ブロック間ネットリスト生成及びフロアプランニングを並行して行なうために、これらを同時に確定することができる。
【００５３】
Ｓ５．ステップＳ４で問題なし（Ｎｏ）と判断された場合には、ステップＳ２で生成されたブロック間ネットリストと、後述のステップＳ６で生成されるＲＴＬソースを入力として、ブロック内及びブロック間のタイミングやファンアウトなどの論理合成を行なう際の合成制約条件を抽出する。
【００５４】
Ｓ６．一方、ステップＳ１で分割したブロック単位に機能記述言語を用いて回路設計（ＲＴＬ設計）を行ってＲＴＬソースを生成する。
【００５５】
これを、早い段階で論理合成のデータとすることで、論理設計・検証と論理合成の間の矛盾を回避することができ、早い段階でＲＴＬソースの品質、信頼度を確保することが可能になる。
【００５６】
そして、ＲＴＬ設計の後、対象ブロックの機能検証項目をステップＳ１で分割した検証項目に従って細分化すると共に、対象ブロック固有の動作確認項目を該検証項目に追加する。
【００５７】
これによって、要求仕様、対象ブロックの機能及び動作に関する検証の漏れを防止することができる。
【００５８】
Ｓ７．ステップＳ２で生成されたブロック間ネットリストと、ステップＳ５で生成された合成制約条件と、ステップＳ６で生成されたＲＴＬソースを入力として、ブロック単位に論理合成を実施して、当該ブロックの実現規模を算出・確認し、該ブロック間ネットリストに当該ブロックの設計情報を填め込むことによりネットリストをビルディングブロック方式で生成してゆく。
【００５９】
Ｓ８．ステップＳ７で算出されたブロックの実現規模に問題がある（Ｙｅｓ）と判断された場合にはステップＳ６のＲＴＬ設計に戻って設計を更新し、問題なしと判断されるまでＲＴＬ設計と論理検証を繰り返す。
【００６０】
Ｓ９．一方、ステップＳ１とステップＳ６とから生成される検証項目と、ステップＳ１でのブロック分割結果を入力として、論理検証対象のブロック及びチップに対する入力信号を発生する機能、及び出力信号とその期待値との照合機能を備えたテストベンチを生成する。
【００６１】
Ｓ１０．ステップＳ６で生成したＲＴＬソースと、ステップＳ９で生成したテストベンチと、ステップＳ２で生成したブロック間ネットリストを入力として、ブロック単位及びチップで機能及び動作を確認する。
【００６２】
これは、ＲＴＬソースが想定通りか否かを、遅延時間を考慮しないで静的に検証するものである。
【００６３】
このプロセスによってＲＴＬソースの要求仕様に対する妥当性がブロック単位で確認されてゆくのにつれて、必要に応じて確認済の複数のブロックの組合せに対する機能及び動作の確認が可能になる。つまり、ビルディングブロック方式で大規模集積回路の機能及び動作の確認が可能になる。
【００６４】
Ｓ１１．ステップＳ１０の結果に問題があるか否かを判断する。もし、問題がある（Ｙｅｓ）と判断された場合には、ステップＳ６のＲＴＬ設計を更新して、問題なしと判断されるまでステップＳ６のＲＴＬ設計とステップＳ１０の論理検証を繰り返す。
【００６５】
Ｓ１２．一方、ステップＳ８で論理合成の結果に問題なし（Ｎｏ）と判断された場合には、ステップＳ７で生成されたネットリストを入力として、フロアプランに従ってブロック内部とブロック間の配置・配線、即ち、レイアウトを行なう。
【００６６】
そして、レイアウト後にＳＤＦ（Standard Delay File ）を生成する。具体的には、ブロックにおいて使用されているセル毎に、配線による遅延も含めて入出力間の遅延を算出する。これは、後で説明するタイミング検証及び必要に応じてゲート検証において使用される。
【００６７】
Ｓ１３．ステップＳ１１で問題なし（Ｎｏ）と判断された場合には、ステップＳ２で生成されたブロック間ネットリストと、ステップＳ７で生成されたネットリストと、ステップＳ９で生成されたテストベンチを入力として、動作確認を行なう。
【００６８】
これは、論理合成結果のネットリストを使って、遅延を考慮せずに静的に検証するものである。
【００６９】
Ｓ１４．ステップＳ１３でのゲート検証の結果に問題があるか否かを判断する。もし、問題がある（Ｙｅｓ）と判断された場合には、ステップＳ６、ステップＳ１０、ステップＳ１１及びステップＳ１３を繰り返して行なう。
【００７０】
そして、このステップで問題なし（Ｎｏ）と判断された場合には、論理設計とインプリメント設計の間で論理の整合がとれたことになる。従って、仕様変更や論理合成結果との不一致がない限り、ＲＴＬ設計への後戻りはなくなる。
【００７１】
Ｓ１５．ステップＳ１４でゲート検証の結果に問題なし（Ｎｏ）と判断された場合には、ステップＳ７で生成したネットリストと、ステップＳ９で生成したテストベンチと、ステップＳ１２で生成したＳＤＦを入力としてタイミング検証を行なう。
【００７２】
これは、レイアウト後に求められたＳＤＦを使い、セルと配線の遅延時間まで含めて動的に検証するものである。
【００７３】
Ｓ１６．ステップＳ１５でのタイミング検証に問題があるか否かを判断して、フロアプラン及びレイアウトの妥当性を確認する。
【００７４】
もし、問題がある（Ｙｅｓ）と判断された場合には、ステップＳ７の論理合成に戻って、ステップＳ７、ステップＳ８及びステップＳ１２の間を繰り返す。  
【００７５】
そして、ステップＳ１６で問題なし（Ｎｏ）と判断された場合には大規模集積回路の設計が終了する。
【００７６】
さて、図２において各設計ステップを示す長方形の右肩に、従来の技術において説明した大規模集積回路の設計工程に付したａ乃至ｄの符号を記載して、図２の各設計ステップと大規模集積回路の大まかな設計工程との関係を明示している。
【００７７】
即ち、ステップＳ１の回路アーキテクチャ検討がａの回路アーキテクチャ検討に対応し、ステップＳ６のＲＴＬ設計、Ｓ１０の論理検証及びＳ１３のゲート検証がｂの論理設計・検証に対応し、ステップＳ７の論理合成がｃの論理合成に対応し、ステップＳ２のブロック間ネットリスト生成、ステップＳ３のフロアプランニング、ステップＳ５の合成制約条件抽出、ステップＳ１２のレイアウト及びステップＳ１５のタイミング検証がｄのインプリメント設計に対応する。
【００７８】
そして、ステップＳ２のブロック間ネットリスト生成とステップＳ３のフロアプランニングがｄでいうフロアプランニングに対応するので、図１に示した如く、回路アーキテクチャ検討とフロアプランニングが並行して行われ、この間では設計結果に問題があれば回路アーキテクチャ検討に戻って再検討がなされる。
【００７９】
このように、フロアプランニングを早期に行なって確定することにより、従来はレイアウトの後で行なうタイミング検証で初めて判るタイミングエラーによってＲＴＬ設計又は回路アーキテクチャ検討に後戻りすることがあったのを回避できる。即ち、回路アーキテクチャ検討とフロアプランニングの品質及び信頼度を高めることができる。
【００８０】
更に、回路アーキテクチャ検討、ブロック間ネットリスト生成及びフロアプランニングを並行して行なうために、これらを同時に確定して後続の設計工程の共通のデータにすることができる。即ち、回路アーキテクチャ検討とフロアプランニングを早期に確定することができるために、後続の工程における矛盾をなくすことができ、後続の工程において高い設計の品質及び信頼度を確保することが可能になる。
【００８１】
又、ステップＳ６のＲＴＬ設計がｂの論理設計に対応し、ステップＳ１０の論理検証とステップＳ１３のゲート検証がｂの論理検証に対応するので、これらは図１に示す如く並行して行なわれてＲＴＬソースが生成され、更に、そのＲＴＬソースを入力としてステップＳ７の論理合成が並行して行なわれるので、品質の高いＲＴＬソースとネットリストがビルディングブロック方式で確定されてゆく。
【００８２】
そして、ステップＳ７の論理合成の結果によってステップＳ１２のレイアウトが行なわれてＳＤＦが生成され、上記ネットリストと該ＳＤＦを入力としてタイミング検証が行なわれる。ここで問題があればステップＳ７の論理合成に戻って設計の更新が行なわれて、ネットリストの品質及び信頼度が高められてゆく。
【００８３】
その上、回路アーキテクチャ検討とフロアプランは確定しているために、回路アーキテクチャ検討とフロアプランニングにまで遡って後戻りすることはなく、ＲＴＬ設計、論理検証、論理合成、レイアウト及びタイミング検証が並行して行なわれることで、論理設計・検証、論理合成及びレイアウトとタイミング検証を早期に収束させることができる。
【００８４】
かくの如く、大規模集積回路の開発に必要な時間を短縮し、且つ、設計結果の品質及び信頼度を高めることができる。
【発明の効果】
【００８５】
本発明により、回路アーキテクチャ検討、論理設計・検証、論理合成、インプリメント設計をコンカレントに行なう大規模集積回路の開発方法が提供される結果、大規模集積回路の設計効率と設計品質を向上させることができる。
【００８６】
又、本発明の開発ツールによって、大規模集積回路の開発において、回路アーキテクチャ検討、論理設計・検証、論理合成、インプリメント設計をコンカレントに行なうことができるようになる。
【００８７】
これにより、本発明は大規模集積回路の開発に大きく貢献することができる。
【発明を実施するための最良の形態】
【００８８】
＜実施例＞
図３は、本発明の大規模集積回路開発の詳細手順で、図２で説明した大規模集積回路開発の原理的手順を更に詳細に示すものである。尚、図３における各開発段階には、図２において各開発段階に付した符号に対応する符号を付してある。
即ち、符号の数字が等しい開発段階同士が対応する開発段階であり、図３における符号の数字の後の小文字アルファベットは図２では単一の段階で示されている開発段階が複数の段階に分割されていることを示す。
【００８９】
以降、図３の各開発段階に付した符号に沿って、本発明の大規模集積回路開発の詳細手順について説明する。尚、図３において、太い矢印付実線は開発の流れを示し、細い矢印付破線はデータの流れを示している。
【００９０】
Ｓ１ａ．要求仕様を入力として、機能の分割、ブロックの分割及び実現回路の構造の検討と、インプリメント設計に必要な下記データ又は情報の見積り及び設定を行なう。
【００９１】
（イ）ブロックに収容可能か否かを判断するためのフリップフロップ数
（ロ）チップの入出力ポート情報及びブロックの入出力ポート情報
（ハ）実現規模
（ニ）クロック駆動能力判断のための、入力クロック種類毎のフリップフロップのグループ数
（ホ）クロックツリー
（ヘ）チップ面積推定のための読み出し専用メモリ（ＲＯＭ）とランダムアクセスメモリ（ＲＡＭ）の使用個数と規模
（ト）動作速度
ところで、チップ内の平均動作速度は電源バスの幅を決めるファクターであり、ブロック毎の動作速度はフロアプランニングにおける配置場所の目安を与え、ブロックの論理合成の制約条件となる。
【００９２】
（チ）ブロック単位の機能検証項目
上記（イ）から（チ）を見れば明らかな如く、この段階でフロアプランニングの草案が検討されている。
【００９３】
Ｓ１ｂ．ステップＳ１ａの検討結果を盛り込んだ機能説明、回路構造などのブロック設計仕様を検討し、設計仕様を記載したドキュメントを作成する。
【００９４】
Ｓ１ｃ．要求検証項目を入力として、各項目をステップＳ１ａで検討したブロック分割の結果を元に、チップ検証項目として細分化し、要求検証項目に対応する機能を明確にする。そして、このステップで要求検証項目にはない、ブロック固有の検証項目の追加を行なう。
【００９５】
Ｓ１ｄ．上記ステップＳ１ｃで作成したチップ検証項目を入力として、ステップＳ１ｃと同様に、ブロック単位にブロック検証項目として細分化する。
【００９６】
以上三つの検証項目、即ち、要求検証項目、ブロック検証項目及びチップ検証項目を階層化することで、要求仕様から実現回路の機能までが有機的につながるため、機能検証の漏れを防止することができるようになる。
【００９７】
Ｓ２．ステップＳ１の回路アーキテクチャ検討の結果出力されるチップの入出力ポート情報とブロック単位の入出力ポート情報即ちピンデータを入力として、ブロック間ネットリストを作成する。具体的には、同じ名称のポート同士を接続するという作業を行ない、接続情報をリスト化する。
【００９８】
ここで作成されたブロック間ネットリストでは、ブロックの中はブラックボックスになっていて、ブロック間及びブロックとチップの間の配線情報だけを含んだもので、後で説明するように、論理設計とインプリメント設計双方の共通のデータとなる。
【００９９】
Ｓ３．ステップＳ１の回路アーキテクチャ検討における見積り及び設定結果と、ステップＳ２において作成されたブロック間ネットリストを入力として、ブロック内部はブラックボックスのままでチップ上でブロックのレイアウトをして、ブロック間配線が可能な面積を見積り、ブロック間配線の実現性を検証する。
【０１００】
Ｓ４．ステップＳ３のフロアプランニングの結果に問題があるか否かを判断する。問題がある（Ｙｅｓ）と判断された場合にはステップＳ１の回路アーキテクチャ検討に戻り、ブロック分割を変更して、問題なしと判断されるまでステップＳ１乃至ステップＳ３を繰り返す。
【０１０１】
しかし、ステップＳ１ａにおいてフロアプランの草案を検討しているので、ステップＳ３のフロアプランニングに問題ありとしてステップＳ１ａに戻ることは実質的には極めて少ない。
【０１０２】
このように、フロアプランニングを早期に行って確定することにより、従来はレイアウトの後で行なうタイミング検証で初めて判るタイミングエラーによってＲＴＬ設計又は回路アーキテクチャ検討に後戻りすることがあったのを回避できる。
【０１０３】
そして、回路アーキテクチャ検討、ブロック間ネットリスト生成及びフロアプランニングを並行して行なうために、これらを同時に確定することができ、しかも、これらの間の矛盾を回避することができる。
【０１０４】
Ｓ５ａ．ステップＳ４で問題なし（Ｎｏ）と判断された場合には、ステップＳ２で生成されたブロック間ネットリストと、ステップＳ１ａで生成されるクロックツリーを入力として、ブロック内のタイミング、ファンアウト及びブロック面積という、論理合成のための合成制約条件を抽出する。
【０１０５】
Ｓ６．一方、ステップＳ１ａで分割したブロック単位に機能記述言語を用いて回路設計（ＲＴＬ設計）を行ってＲＴＬソースを生成する。
【０１０６】
これを早い段階で論理合成のデータとすることで、論理設計・検証と論理合成の間の矛盾を回避することができ、早い段階でＲＴＬソースの品質、信頼度を確保することが可能になる。
【０１０７】
そして、ＲＴＬ設計の後、対象ブロックの機能検証項目をステップＳ１で分割した検証項目に従って細分化すると共に、対象ブロック固有の動作確認項目を該検証項目に追加する。これによって、要求仕様、対象ブロックの機能及び動作に関する検証の漏れを防止することができる。
【０１０８】
Ｓ７ａ．ステップＳ２で生成されたブロック間ネットリストと、ステップＳ６で生成されたＲＴＬソースを入力として、ブロック単位に論理合成を実施して、当該ブロックの実現規模を算出・確認し、該ブロック間ネットリストに当該ブロックの設計情報を填め込むことによりネットリストをビルディングブロック方式で生成してゆく。
【０１０９】
具体的には、電子メールを利用した開発ツールで論理合成を行なうが、この詳細は後で説明する。
【０１１０】
Ｓ７ｂ．ステップＳ５ａで抽出したブロック内制約条件を入力として、ステップＳ７ａの論理合成で生成されたブロック単位のネットリストに対してタイミング調整などをして、ブロックの最適化合成を行なう。
【０１１１】
Ｓ１２ｃ．次いで、最適化合成が済んだブロックから順にブロックレイアウトを行なう。
【０１１２】
Ｓ１２ｄ．全てのブロックについて論理合成及び最適化合成を終了したか否かを判断する。全てのブロックについて論理合成及び最適化合成を終了していない（Ｎｏ）と判断された場合には、ステップＳ７ａのブロック自動論理合成に戻り、全てのブロックについて終了するまで最適化合成までのステップを繰り返す。
【０１１３】
Ｓ８．ステップＳ７ｂまでに算出されたブロックの実現規模に問題がある（Ｙｅｓ）と判断された場合にはステップＳ６のＲＴＬ設計に戻って設計を更新し、問題なしと判断されるまで以降のステップを繰り返す。
【０１１４】
Ｓ５ｂ．ステップＳ８で問題なし（Ｎｏ）と判断された場合には、ブロック間での論理合成制約条件であるタイミング条件を抽出する。
【０１１５】
Ｓ７ｃ．ステップＳ５ｂで抽出したチップ制約条件を用いて、チップ全体のタイミングの最適化を行なう。
【０１１６】
尚、上記ステップＳ５ａ、ステップＳ５ｂ及びステップＳ７ｃは、ブロック単位のＲＴＬ設計が終了する度に実施する必要はない。何故なら、ステップＳ５ａで行なうことは、ブロック規模の大幅な増減がない限り変化がないし，ステップＳ５ｂで行なうことは、ブロックの入出力ポートの増減がない限り変化がないし、ステップＳ７ｃで行なうことは、ブロックの入出力ポートの増減或いはフリップフロップ数の増減がない限り変化がないからである。
【０１１７】
Ｓ９ａ．一方、ステップＳ１ｄとステップＳ６とから生成されるブロック検証項目と、ステップＳ１ａでのブロック分割結果を入力として、論理検証対象のブロックに対する入力信号を発生する機能及び出力信号とその期待値との照合機能を備えたブロック単位のテストベンチ（図３ではブロックＴＢと標記している。
）を生成する。
【０１１８】
Ｓ９ｂ．又、ステップＳ１ｃで生成されるチップ検証項目と、ステップＳ１ａでのブロック分割結果を入力として、チップに対する入力信号を発生する機能及び出力信号とその期待値との照合機能を備えたチップのテストベンチ（図３ではチップＴＢと標記している。）を生成する。
【０１１９】
Ｓ１０ａ．ステップＳ６で生成したＲＴＬソースと、ステップＳ９ａとステップＳ９ｂで生成したテストベンチと、ステップＳ２で生成したブロック間ネットリストを入力として、ブロック単位で機能及び動作を確認する。
【０１２０】
これは、ブロックのＲＴＬソースが想定通りか否かを、遅延時間を考慮しないで静的に検証するものである。
【０１２１】
このプロセスによってＲＴＬソースの要求仕様に対する妥当性がブロック単位に確認されてゆくので、必要に応じて確認済の複数のブロックの組合せに対する機能及び動作の確認が可能になる。つまり、ビルディングブロック方式で大規模集積回路の機能及び動作の確認が可能になる。
【０１２２】
Ｓ１１ａ．ステップＳ１０ａの結果に問題があるか否かを判断する。もし、問題がある（Ｙｅｓ）と判断された場合には、ステップＳ６のＲＴＬ設計に戻って設計を更新して、問題なしと判断されるまでステップＳ１０ａのブロック論理検証までを繰り返す。
【０１２３】
Ｓ１３．ステップＳ１１ａで問題なし（Ｎｏ）と判断された場合には、ステップＳ２で生成されたブロック間ネットリストと、ステップＳ７ａで生成されたネットリストと、ステップＳ９で生成されたテストベンチを入力として、動作確認を行なう。
【０１２４】
これは、ブロックの論理合成結果のネットリストを使って、遅延を考慮せずに静的に検証するものである。
【０１２５】
Ｓ１４．ステップＳ１３でのゲート検証の結果に問題があるか否かを判断する。もし、問題がある（Ｙｅｓ）と判断された場合にはステップＳ６に戻り、ステップＳ６、ステップＳ１０、ステップＳ１１及びステップＳ１３の間の処理を問題なしと判断されるまで繰り返して行なう。
【０１２６】
そして、このステップで問題なし（Ｎｏ）と判断された場合には、論理設計とインプリメント設計の間で論理の整合がとれたことになる。
【０１２７】
Ｓ１０ｂ．ステップＳ９ｂで生成されたチップのテストベンチと、ステップＳ６で生成されたＲＴＬソースを入力として、チップとしての論理検証を行なう。
【０１２８】
これは、チップの配線も含めて論理設計が想定通りであるか否かの検証を行なうもので、遅延時間を考慮しない静的な検証である。
【０１２９】
Ｓ１１ｂ．ステップＳ１０ｂのチップ論理検証に問題があるか否かを判断する。もし、問題がある（Ｙｅｓ）と判断された場合にはステップＳ６に戻り、ステップＳ６、ステップＳ１０、ステップＳ１１、ステップＳ１３及びステップＳ１０ｂの間の処理を問題なしと判断されるまで繰り返して行なう。
【０１３０】
そして、このステップで問題なし（Ｎｏ）と判断された場合には、論理設計とインプリメント設計の間でチップとして論理の整合がとれたことになる。従って、仕様変更や論理合成との不一致がない限り、ステップＳ６のＲＴＬ設計への後戻りはなくなる。
【０１３１】
Ｓ１２ａ．一方、ステップＳ２の出力であるブロック間ネットリストと、ステップＳ１ａで作成されたクロックの接続情報であるクロックツリーを入力として、クロックドライバの駆動能力の制約とクロックスキューの削減を考慮してクロックツリー配線をする。この際、クロックスキューの削減はクロック配線を等長配線にすることで実現する。
【０１３２】
この段階でクロックスキューが生じないようにできるのは、ブロック間ネットリストとフロアプランが先に決定されているためである。
【０１３３】
このように、ブロック間でクロックスキューが生じないようにできるために、ブロック間とブロック内の設計を独立にできて、ブロック内のレイアウトが進め易くなる。
【０１３４】
Ｓ１２ｂ．高速で動作してタイミングの調整が難しい高速ブロックのレイアウトを行ない、レイアウトデータを生成する。
【０１３５】
Ｓ１２ｅ．ステップＳ１２ｃで低速動作のブロックのレイアウトが行なわれ、ステップＳ１２ｂで高速動作のブロックのレイアウトが行なわれて、レイアウトデータに蓄積されているので、フロアプランに従ってブロックの配置とブロック間の配線を行ない、チップレイアウトの結果をレイアウトデータに蓄積する。
【０１３６】
そして、レイアウト後にＳＤＦ（ＳＤＦ；Standard Delay File ）を生成する。
【０１３７】
これは、配線の影響も含めたセルの入出力の遅延時間を蓄積したもので、後で説明するタイミング検証に使用され、必要に応じてステップＳ１３のゲート検証においても使用される。
【０１３８】
このように、高速動作をするブロックのレイアウトと低速動作をするブロックのレイアウトを並行して行なうのは、レイアウト設計のターンアラウンドタイムを短縮するためで、既にブロック間ネットリストとフロアプランが確定している結果、これが可能になる。
【０１３９】
即ち、従来は、高速動作をするブロックについては自動による配置・配線が困難であるので、設計者によるマニュアルでの配置・配線を優先して行ない、低速動作をするブロックについては、高速動作をするブロックの配置・配線が終了した後で自動で配置・配線を行なっていたが、これでは高速ブロックの配置・配線が終了するまで低速動作をするブロックの配置・配線に着手できない。
【０１４０】
しかし、本発明の開発方法によれば、この段階でブロック間ネットリストとフロアプランが確定しているので、高速動作をするブロックの配置・配線の結果を待たなくても低速動作をするブロックの配置・配線に着手できる。
【０１４１】
繰り返しになるが、従来の開発方法では、ブロック間ネットリストとフロアプランはレイアウト段階以前に確定できず、往々にしてレイアウトやタイミング検証の結果によってブロック間ネットリストとフロアプランを変更せざるを得ず、大規模集積回路開発のターンアラウンドタイムが長かったのに対して、上記の開発方法によってレイアウトのターンアランドタイムが短縮され、ひいては、大規模集積回路開発のターンアラウンドタイムが短縮されることが容易に理解できる。
【０１４２】
Ｓ１５．ステップＳ１１ｂでチップ論理検証の結果に問題なし（Ｎｏ）と判断され、ステップＳ１２ｅのチップレイアウトが終了した場合には、ステップＳ２で生成したブロック間ネットリストと、ステップＳ７で生成したネットリストと、ステップＳ９ｂで生成したチップのテストベンチと、ステップＳ１２ｅで生成したＳＤＦを入力としてタイミング検証を行なう。
【０１４３】
これは、レイアウト後に求められたＳＤＦを使い、セルと配線の遅延時間まで含めて動的に検証するものである。
【０１４４】
Ｓ１６．ステップＳ１５でのタイミング検証に問題があるか否かを判断して、フロアプラン及びレイアウトの妥当性を確認する。
【０１４５】
もし、問題がある（Ｙｅｓ）と判断された場合には、ステップＳ７ａに戻り、ステップＳ７ａ、ステップＳ７ｂ、ステップＳ７ｃの論理合成と、ステップＳ１２ａ、ステップＳ１２ｂ、ステップＳ１２ｃのレイアウトの間を問題なしと判断されるまで繰り返して行なう。
【０１４６】
そして、ステップＳ１６で問題なし（Ｎｏ）と判断された場合には大規模集積回路の設計が終了する。
【０１４７】
全体としては、回路アーキテクチャ検討と並行して行なうブロック間ネットリスト生成とフロアプランニングの出力を論理設計・検証、論理合成及びインプリメント設計の共通のデータとして、論理設計・検証、論理合成及びインプリメント設計を同時に進めてゆく。
【０１４８】
まず、論理設計では、インプリメント設計を意識したブロック間ネットリスト、フロアプランに沿って、ブロック単位に要求仕様に対する回路アーキテクチャの妥当性を確認しながらＲＴＬ設計と論理検証を進めてゆく。
【０１４９】
又、論理合成では、ブロック単位にＲＴＬ設計されたＲＴＬソースを入力として論理合成し、その結果をブロック間ネットリストの中に填め込んでネットリストを生成し、更にブロック及びチップの最適化合成をする。
【０１５０】
一方、インプリメント設計では、ＲＴＬ設計開始までに完結させたフロアプランとブロック間ネットリストを基準に、ブロック単位のレイアウトとチップのレイアウトを逐次進めてゆく。この際、高速ブロックと低速ブロックのレイアウト設計を並行して行なって、レイアウト設計のターンアラウンドタイムの短縮を計っている。
【０１５１】
このコンカレントな設計作業により、設計工程中のフィードバックループが短くなる。特に、最終工程であるタイミング検証の結果によって、最初の工程である回路アーキテクチャ検討へのフィードバックが生ずることがなくなるため、フィードバックによる設計作業の混乱、輻輳を防止できる。
【０１５２】
ここまでは、大規模集積回路開発の全体工程を通した説明をしてきたが、以降は、その主要工程の説明と、論理合成に適用する開発ツールについて個別に説明する。
【０１５３】
図４は、回路アーキテクチャ検討の詳細手順である。
【０１５４】
回路アーキテクチャの検討では、図４のフローチャート中の左側に配置してある、両サイドが丸い形状のブロック中に記載されている複数の制約条件を与えて検討し、制約条件が全て満足されるまで検討を繰り返す。
【０１５５】
以降、図４の各ステップに付した符号に沿って回路アーキテクチャ検討の詳細手順について説明する。尚、図４において、太い矢印付実線は開発の流れを示し、細い矢印付破線はデータの流れを示し、細い矢印付実線は制約条件の参照を意味している。
【０１５６】
Ｓ２１．要求仕様より、開発対象の大規模集積回路の位置づけを明確にして、求められている機能を漏れなく抽出する。
【０１５７】
Ｓ２２．チップ全体として機能を満足させるための機能構成（機能の組合せ）を検討して、機能毎に大きく分割する。
【０１５８】
Ｓ２３．動作速度、機能、ブロック間ネット数を制約条件として、ステップＳ２２のチップ機能分割の結果を更に細かく分割して、チップをブロックに分割する。
【０１５９】
この際、動作速度に関しては、高速動作部と低速動作部を分割し、機能については、共通化できる機能と個別機能に分割し、ブロック間ネット数については、ブロック間ネット数が最小になるように分割する。
【０１６０】
Ｓ２４．ブロック内のゲート規模を制約条件に、ブロックの規模を見積もる。
【０１６１】
このゲート規模見積りは、ブロック単位の論理合成の実現性、レイアウト設計のターンアラウンドタイムの短縮及びフロアプランニングの融通性（ブロックの移動可能性）のために行なう。
【０１６２】
Ｓ２５．ステップＳ２４のゲート規模見積りの結果に問題があるか否かを判断する。問題がある（Ｙｅｓ）場合には、ステップＳ２３のブロック分割に戻って、分割を変更して問題なしと判断されるまでステップＳ２３及びステップＳ２４を繰り返す。
【０１６３】
Ｓ２６．ステップＳ２５で問題なし（Ｎｏ）と判断された場合、これまでに確定したブロックについて、ブロック間の配線可能性のためにブロック間ネット数を制約条件とし、又、クロックの駆動可能性のためにステップＳ２４で算出したフリップフロップ群を規定数以内でグループ化して、クロックポートを含むブロックのポートを定義する。
【０１６４】
特に、クロックポートへのフリップフロップの割付を説明する図である図５を使って、クロックポートの定義に関して説明する。
【０１６５】
図５（イ）は、ステップＳ２４で得たフリップフロップ群の見積り結果で、この場合、２０個のフリップフロップが必要という結果を得ており、一種類のクロックが供給されるものとして図示している。
【０１６６】
そして、クロック線１本でのフリップフロップの駆動能力が５個であると仮定すると、２０個のフリップフロップ群を５個ずつ４つのグループに分割して、１つのグループに１本のクロック配線を接続すればよい。
【０１６７】
これを行なった結果を図５（ロ）に示す。
【０１６８】
Ｓ２７．ステップＳ２６の結果に問題があるか否かを判断する。問題がある（Ｙｅｓ）と判断された場合には、ステップＳ２３のブロック分割に戻り、ステップＳ２３、ステップＳ２４及びステップＳ２６を繰り返す。
【０１６９】
Ｓ２８．ステップＳ２７で問題なし（Ｎｏ）と判断された場合には、クロックの駆動能力に関するテクノロジー毎のクロックバッファの制約条件に基づいて、クロックツリーを作成する。ここで作成されるクロックツリーは、クロックの接続情報である。
【０１７０】
Ｓ２９．ステップＳ２８で得たクロックツリーに問題があるか否かを判断する。問題がある（Ｙｅｓ）と判断された場合には、ステップＳ２３のブロック分割に戻り、ステップＳ２３、ステップＳ２４、ステップＳ２６を問題なしと判断されるまで繰り返し、クロックツリーを完成させる。
【０１７１】
この段階でクロックツリーを完成させることにより、論理設計に先行してブロックへのクロック分配を確定でき、論理設計とインプリメント設計設計の間でのクロックに関する矛盾発生を防止することができる。
【０１７２】
Ｓ３０．ステップＳ２９で問題なし（Ｎｏ）と判断された場合には、ステップＳ２３のブロック分割の結果、ステップＳ２４のゲート見積りの結果、ステップＳ２６のブロックポートの定義及びステップＳ２８で作成されたクロックツリーを入力としてフロアプランニングを行なう。
【０１７３】
この段階で、机上検討したフロアプランの草案ができあがる。
【０１７４】
Ｓ３１．ステップＳ３０で得られたフロアプランの整合性に問題があるか否か、即ち、ブロック間配線領域も考慮してブロックをチップに敷詰めることができるか否かを判断する。もし、整合性に問題がある（Ｙｅｓ）と判断された場合には、ステップＳ２３に戻り、問題なしと判断されるまで以降の検討を繰り返す。
【０１７５】
Ｓ３２．ステップＳ３１で問題なし（Ｎｏ）と判断された場合には、テクノロジーから決まる同時スイッチング数の制約を考慮して大規模集積回路の端子配置を定義する。
【０１７６】
Ｓ３３．ステップＳ３２で定義された端子配置に問題があるか否かを判断する。もし、端子配置に問題がある（Ｙｅｓ）、即ち、同時スイッチング数に関する制約違反があると判断された場合には、ステップＳ３０のフロアプランニングに戻って、テクノロジーの制約を満足する端子配置が可能なようにフロアプランニングを繰り返し行なう。
【０１７７】
このステップで問題なし（Ｎｏ）と判断された場合には、回路アーキテクチャの検討が終了する。
【０１７８】
図６は、物理インタフェース情報の生成手順、即ち、ブロック間ネットリストの生成手順である。
【０１７９】
以降、図６の各ステップに付した符号に沿って物理インタフェース情報の生成手順を説明する。尚、図６において、太い矢印付実線は開発の流れを示し、細い矢印付破線はデータの流れを示している。
【０１８０】
Ｓ４１．このステップは、図２、図３などで説明した回路アーキテクチャ検討のステップで、ポートの名称、入出力情報、ビット幅のブロックポート情報を定義する。
【０１８１】
Ｓ４２．ステップＳ４１で生成したブロックポート情報を入力として、ブロック単位のポートリストを生成する。
【０１８２】
このブロック単位のポートリストはＲＴＬ設計でも使用される。
【０１８３】
Ｓ４３．ステップＳ４２で生成したブロック単位のポートリストと大規模集積回路の端子配置情報を入力として、同一名称のポートを接続してブロック間ネットリストを生成する。
【０１８４】
図７は、ブロック間ネットの生成を概念的に示す図である。
【０１８５】
図７において、小さい丸印はブロックのポート（図７（イ）に示す。）、小さい三角印は表した大規模集積回路（チップ）のポート（図７（ロ）に示す。）である。そして、ブロックポート間とブロックポートとチップポートを接続してブロック間ネット（図７（ハ）に示す。）を生成する。このブロックポート間の接続情報とブロックポートとチップポートの接続情報をリスト化したものがブロック間ネットリストである。
【０１８６】
ここで生成されるブロック間ネットリストは、論理検証、ゲート検証、タイミング検証の共通のデータ、即ち、論理設計とインプリメント設計の共通のデータとして使用される。
【０１８７】
このため、論理設計とインプリメント設計を並行して行なっても、例えば、ブロック間のインタフェースの矛盾がなくなり、並行して行なう論理設計とインプリメント設計の結果の品質または信頼度を向上させることができる。
【０１８８】
次いで、論理合成に関して説明するが、それに先立って論理合成に使用する開発ツールについて説明した後で、その開発ツールを使用する論理合成について説明する。
【０１８９】
図８は、本発明の大規模集積回路の開発ツールの構成である。
【０１９０】
図８において、１は開発ツールの構成要素を接続するネットワークで、例えば図８に記載してある如く、イーサネットを適用する。２は監視サーバで、ＲＴＬ設計の結果であるＲＴＬソースを常時監視するプログラムを搭載している。３ａ及び３ｂはＲＴＬ設計する設計者が操作する設計端末である。４はメールサーバで、開発ツール内を転送される種々のメールを配信する。５はファイルサーバで、ＲＴＬソースを格納する。６は合成サーバで、ＲＴＬ設計が終了したブロックについて論理合成を行なう。
【０１９１】
図８の開発ツールの動作モードには、ＲＴＬ監視モードと、論理合成モードとがある。その概要は下記の通りである。
【０１９２】
まず、ＲＴＬ監視モードの場合には、設計端末３ａ及び３ｂから監視サーバ２にＲＴＬ監視コマンドを電子メールすると、該監視サーバ２は受信メール内のコマンドをチェックし、規定のフォーマットのコマンドであれば監視プログラムを起動してＲＴＬ監視を開始し、新規作成又は更新されたＲＴＬソースの有無と版数を確認し、該当するＲＴＬソースがあれば設計端末及び合成サーバに電子メールで通知する。設計端末では、このメールによって論理合成対象のＲＴＬソースとその版数を確認でき、誤った版数のＲＴＬソースが論理合成されることや、版数の更新漏れを回避できる。
【０１９３】
次に、論理合成モードの場合には次のように動作する。即ち、ブロック毎に新規にＲＴＬ設計が終了したり、ＲＴＬ設計の更新が完了すると、監視サーバ２から合成サーバ６に合成依頼のメールが送信される。該合成依頼メールを受信した合成サーバ６はメールが正しい内容であることを確認すると論理合成を実行する。論理合成完了後は該合成サーバ６は論理合成の結果をレポートとして設計端末に送信する。（正確には、論理合成の結果のレポートは設計端末に直接送信されるのではなく、設計者固有のメール箱に送信され、設計者がそのメール箱を見にゆくというプロセスが取られるが、ここでは一貫して「設計端末に送信」という表現を用いることにする。）これにより、設計端末側では論理合成の妥当性を確認することができる。論理合成の妥当性が確認できなかった場合にはＲＴＬ設計
をやり直して、論理合成の妥当性が確認されるまで論理合成を繰り返す。又、設計端末から合成サーバにＲＴＬソースをメールすると、受信メールからＲＴＬソースを切り出してファイルサーバに格納する。格納されたＲＴＬソースは、ＲＴＬソースを常時監視している監視サーバ２によって新規ファイルと認識され、上記のフローによって論理合成できるようになる。
【０１９４】
図９は、ＲＴＬ監視モードの機能を説明する図である。
【０１９５】
図９において、１は開発ツールの構成要素を接続するネットワークで、例えば図８に記載してある如く、イーサネットを適用する。２は監視サーバで、ＲＴＬ設計の結果であるＲＴＬソースを常時監視するプログラムを搭載している。３ａ及び３ｂはＲＴＬ設計する設計者が操作する設計端末である。４はメールサーバで、開発ツール内を転送される種々のメールの送受信を司る。５はファイルサーバで、設計結果のＲＴＬソースを格納する。
【０１９６】
そして、該監視サーバは新規又は更新されたＲＴＬソースが該ファイルサーバ内に格納されている場合に、該メールサーバを経由して設計端末に電子メールによって通知する他に、ＲＴＬソースの更新に対応してＲＴＬソースの版数を管理する機能を備えている。
【０１９７】
該設計端末３ａ及び３ｂは、該監視サーバ２に対して電子メールを送信して、該監視サーバ２に搭載されている監視プログラムを起動する。
【０１９８】
又、該メールサーバが司るメールは、該監視サーバ２の監視機能を実現するメール、該監視サーバ２が監視した結果を設計端末３ａ又は３ｂに送信するメール、及び、該設計端末３ａ又は３ｂからの監視開始コマンドメールなどである。
【０１９９】
図３によって詳細に説明した如く、ＲＴＬ設計と論理検証がブロック単位に並行して行なわれてゆき、ＲＴＬソースに設計ミスがあれば随時更新され検証されてゆくため、新規または更新されたＲＴＬソースがあるか否かとその版数を確実に管理しないと、誤った版数のＲＴＬソースによって論理合成が行なわれたり、特定のブロックについて論理合成の実行が漏れてしまうことがあり、結果として論理設計とインプリメント設計の間に不整合が生ずる恐れがある。
【０２００】
そこで、ＲＴＬソースを監視するサーバを配置して監視することによって、この不整合を回避することが可能になるために、設計者が最新のＲＴＬソースについて論理合成が行なわれているか否かを意識しなくても、正しいＲＴＬソースについて論理合成を実行することができる。
【０２０１】
図１０は、ＲＴＬソース監視の概略手順である。
【０２０２】
以降、図１０の各ステップに付してある符号に沿ってＲＴＬ監視の手順を説明する。尚、図１０における太い矢印付実線は監視サーバにおけるＲＴＬソース監視の流れを示し、細い矢印付実線は他の構成要素との間の処理の関係を示し、細い矢印付破線はデータの流れを示している。
【０２０３】
まず、設計端末３ａ又は３ｂからＲＴＬ監視開始コマンドメールが送信される。
【０２０４】
Ｓ５１．監視サーバがメールの受信を待機している。
【０２０５】
Ｓ５２．もし、メールの受信がない（Ｎｏ）場合には、ステップＳ５１に戻ってメール受信の待機を継続する。
【０２０６】
Ｓ５３．ステップＳ５２において、メールの受信があった（Ｙｅｓ）場合には、受信コマンドをチェックする。
【０２０７】
Ｓ５４．もし、予め定めたフォーマットのコマンドではない（Ｎｏ）と判断した場合には、ステップＳ５１に戻ってメール受信の待機に入る。
【０２０８】
Ｓ５５．ステップＳ５４で予め定めたフォーマットのコマンドである（Ｙｅｓ）と判断した場合には、監視プログラムを起動して、ＲＴＬソースの格納アドレス、プロジェクト名及び大規模集積回路名より成るＲＴＬ監視データを生成する。
【０２０９】
Ｓ５６．新規設計のＲＴＬソース又は更新されたＲＴＬソースがあるか否かをチェックする。
【０２１０】
Ｓ５７．ステップＳ５６のチェックの結果、新規又は更新ＲＴＬソースがない（Ｎｏ）と判断された場合には、ステップＳ５６に戻ってチェックを続ける。
【０２１１】
Ｓ５８．ステップＳ５６のチェックの結果、ステップＳ５７で新規又は更新ＲＴＬソースがある（Ｙｅｓ）と判断された場合には、該ＲＴＬ監視データを設計端末３ａ及び３ｂと、合成サーバ６に電子メールで送信して、ＲＴＬ監視手順を終了する。
【０２１２】
これにより、設計端末側では該当するＲＴＬソースが存在すること、及びその版数を確認することができる。
【０２１３】
又、新規に設計されたか更新されたＲＴＬソース即ち最新のＲＴＬソースが存在すると監視サーバは合成サーバに論理合成を依頼するので、最新のＲＴＬソースについて漏れなく論理合成を実行することができる。
【０２１４】
図１１は、上記ＲＴＬ監視の概略手順における、設計端末３ａ又は３ｂからＲＴＬ監視開始コマンドメールを受信した後に監視サーバが行なうＲＴＬ監視データ生成の手順、図１２はＲＴＬ監視開始コマンドの例である。
【０２１５】
以降、図１２のＲＴＬ監視開始コマンドを参照しながら、図１１の各ステップに付した符号に沿ってＲＴＬ監視データの生成手順について詳細に説明する。尚、図１１の太い実線はＲＴＬ監視データ生成の流れを示し、細い矢印付破線はデータの流れを示している。
【０２１６】
Ｓ６１．電子メールの受信を待機している。
【０２１７】
Ｓ６２．電子メールを受信したか否かを判断する。もし、電子メールの受信がない（Ｎｏ）と判断された場合には、ステップＳ６１に戻って受信待機を継続する。
【０２１８】
Ｓ６３．ステップＳ６２で電子メールの受信があった（Ｙｅｓ）と判断された場合には、受信した電子メールに搭載されているコマンドを解析する。
【０２１９】
正規のＲＴＬ監視開始コマンドメールには、図１２に例示する如く、ヘッダ部に配信先のメールアドレス、ＲＴＬ監視開始コマンドである“ｍｏｎｉｔｏｒ  ｏｎ”が、ボディ部にＲＴＬソースの格納アドレス、ＲＴＬソースを特定する名称であるプロジェクト名及び大規模集積回路名が搭載されている。
【０２２０】
尚、プロジェクト名と大規模集積回路名のように階層化した名称情報を搭載するのは、同一名称の大規模集積回路が異なるプロジェクトで使われていても、正しく特定できるようにするためである。
【０２２１】
Ｓ６４．正規のＲＴＬ監視開始コマンド“ｍｏｎｉｔｏｒ  ｏｎ”が搭載されているか否かを判断する。
【０２２２】
Ｓ６５．ステップＳ６３でのコマンド解析の結果、正規のＲＴＬ監視開始コマンド“ｍｏｎｉｔｏｒ  ｏｎ”が搭載されていない（Ｎｏ）と判断された場合には、エラーであることを示すエラーメールを設計端末に送信し、ステップＳ６１に戻って電子メール受信待機を継続する。
【０２２３】
これにより、無関係な電子メールによる誤処理を防止することができる。
【０２２４】
Ｓ６６．ステップＳ６４で正規のＲＴＬ監視開始コマンド“ｍｏｎｉｔｏｒ  ｏｎ”が搭載されている（Ｙｅｓ）と判断された場合には、受信したメールからＲＴＬソースの格納アドレスとＲＴＬソースの名称情報を抽出する。
【０２２５】
Ｓ６７．ステップＳ６６で抽出したＲＴＬソースの格納アドレスとＲＴＬソースの名称情報をキーに、ＲＴＬ監視データを検索する。
【０２２６】
Ｓ６８．当該ＲＴＬソースが既に監視中のＲＴＬソースであるか否かを判断する。もし、当該ＲＴＬソースが既に監視中のＲＴＬソースである（Ｙｅｓ）と判断される場合には、何も処理せずにステップＳ６１に戻り、電子メール受信の待機に入る。
【０２２７】
これにより、複数の設計者が独立にＲＴＬ監視を要求しても、監視動作自体の重複を避けることができるようになる。
【０２２８】
Ｓ６９．ステップＳ６８で当該ＲＴＬソースが監視中のＲＴＬソースでない（Ｎｏ）と判断された場合には、指定された格納アドレスを検索する。
【０２２９】
Ｓ７０．指定された格納アドレスが実在するか否かを判断する。
【０２３０】
Ｓ７１．ステップＳ７０で指定された格納アドレスが実在しない（Ｎｏ）と判断された場合には、エラーメールを送信してステップＳ６１に戻り、電子メール受信の待機に入る。
【０２３１】
Ｓ７２．ステップＳ７０で指定された格納アドレスが実在する（Ｙｅｓ）と判断された場合には、プロジェクト名と大規模集積回路名の如く階層を持たせた名称で監視サーバ内に監視用のＲＴＬソース格納場所を確保し、指定格納アドレス間でＲＴＬソースを比較してＲＴＬ監視を実行する。
【０２３２】
Ｓ７３．指定されたデータを監視データに格納する。
【０２３３】
Ｓ７４．受け付けたデータを全ての設計端末に送信してＲＴＬ監視データ生成の手順を終了する。
【０２３４】
図１３は、上記ＲＴＬ監視データによるＲＴＬソース監視の手順、図１４はＲＴＬ監視結果返信メールの例である。
【０２３５】
以降、図１４のＲＴＬ監視結果返信メールを参照しながら、図１３の各ステップに付した符号に沿ってＲＴＬ監視の手順を説明する。尚、図１３において、太い矢印付実線はＲＴＬ監視の流れを示し、細い矢印付破線はデータの流れを示している。
【０２３６】
Ｓ８１．図１１中に示した監視データからプロジェクト名、大規模集積回路名、格納アドレスを抽出する。
【０２３７】
Ｓ８２．監視サーバ内に対象となる上記データが存在するか否かを判断する。
【０２３８】
Ｓ８３．ステップＳ８２で上記データが存在しない（Ｎｏ）と判断された場合には、ファイルサーバ内の格納アドレスから対象となるＲＴＬソースをファイルサーバから監視サーバに複写する。
【０２３９】
Ｓ８４．ステップＳ８２で上記データが存在する（Ｙｅｓ）と判断された場合と、ステップＳ８３でＲＴＬソースを複写した後には、ＲＴＬソースファイル数の増減判断をするために、監視対象のＲＴＬソースファイル名リストを配列Ｌに格納し、監視サーバ内のＲＴＬソースファイル名リストを配列Ｍに格納する。
【０２４０】
Ｓ８５．配列Ｌと配列Ｍの大きさを比較する。配列Ｌと配列Ｍの大きさに差分がない（便宜的にＬ＝Ｍと標記している。）場合には、直ちに処理ループ内のステップＳ８８に移行する。
【０２４１】
Ｓ８６．配列Ｌと配列Ｍの大きさに差分があり、配列Ｌが配列Ｍより大きい（便宜的にＬ＞Ｍと標記している。）場合には、新規ＲＴＬソースが追加されたことを意味するので、新規ファイル名を配列Ｎ１に格納し、処理ループ内のステップＳ８８に移行する。
【０２４２】
Ｓ８７．配列Ｌと配列Ｍの大きさに差分があり、配列Ｌが配列Ｍより小さい（便宜的にＬ＜Ｍと標記している。）場合には、格納されるＲＴＬソースが削除する必要があることを意味するので、削除するファイル名を配列Ｎ２に格納し、処理ループ内のステップＳ８８に移行する。
【０２４３】
Ｓ８８．ファイル名が一致するＲＴＬソースの内容の差分を抽出する。
【０２４４】
Ｓ８９．ＲＴＬソース内容に差分があるか否かを判断する。差分がない（Ｎｏ）と判断された場合には、ステップＳ９０以降ステップＳ９４の処理を飛び越してループさせる。即ち、ステップＳ８８に戻る。
【０２４５】
Ｓ９０．ステップＳ８９でＲＴＬソース内容に差分がある（Ｙｅｓ）と判断された場合には、版数を比較する。
【０２４６】
Ｓ９１．ステップＳ９０の版数比較の結果、版数が同一であるか否かを判断する。
【０２４７】
Ｓ９２．ステップＳ９１で版数が同一である（Ｙｅｓ）と判断された場合には、ＲＴＬソースに差分があって版数が同一ということはありえないので、設計端末に対して警告メールを送信して、ステップＳ９３及びステップＳ９４を飛び越してループさせる。即ち、実質的にはステップＳ８８に戻る。
【０２４８】
これにより、版数更新がされていないことが設計者に伝えられるので、版数の更新漏れを防止することが可能になる。
【０２４９】
Ｓ９３．ステップＳ９１で版数が同一ではない（Ｎｏ）と判断された場合には、差分を差分ファイルに格納すると共に、版数を版数管理表に記録する。
【０２５０】
Ｓ９４．差分があるファイル名を配列Ｎ２に格納する。
【０２５１】
ステップＳ９３及びステップＳ９４を実行することによって、版数管理を自動化することが可能になると共に、必要な場合には上記差分ファイルを用いて必要な版数のＲＴＬソースを復元することが可能になる。
【０２５２】
以上のステップをその時のＲＴＬソースについて実行して終了すれば、処理ループ内の処理が終了する。
【０２５３】
Ｓ９５．ステップＳ８６、ステップＳ８７及びステップＳ９４での処理に応じて、監視サーバ内のファイルを更新する。
【０２５４】
即ち、新規にＲＴＬソースが追加された場合にはファイルサーバの格納アドレスから新規ＲＴＬソースを複写し、新規にＲＴＬソースが追加されなくてもＲＴＬソースに差分がある場合にもファイルサーバの格納アドレスから新規ＲＴＬソースを複写し、ファイルサーバからＲＴＬソースが削除された場合には、監視サーバから当該ＲＴＬソースを削除して、監視サーバ内のファイルを更新する。
【０２５５】
Ｓ９６．上記配列Ｎ１、Ｎ２及びＮ３のデータをＲＴＬ監視結果返信メールで設計端末に送信してＲＴＬソース監視の手順を終了する。
【０２５６】
尚、ＲＴＬ監視結果返信メールは図１４に示す構造例のようになっており、ヘッダ部に配信先のメールアドレス、論理合成受付を示すメッセージ、ボディ部に新規に格納したファイルの大規模集積回路名、ＲＴＬソースファイル名、設計端末メールアドレス、版数変更情報、更新したファイルの大規模集積回路名、ＲＴＬソースファイル名、設計端末メールアドレス、版数変更情報、削除したファイルの大規模集積回路名、ＲＴＬソースファイル名が搭載されている。
【０２５７】
これで論理合成のためのＲＴＬ監視に関する説明を終わり、以降はメールオーダーによる論理合成に関する説明に移る。
【０２５８】
図１５は、論理合成モードの機能を説明する図である。
【０２５９】
図１５において、１は開発ツールの構成要素を接続するネットワークで、例えばイーサネットを適用する。２は監視サーバで、ＲＴＬソースを常時監視するプログラムを搭載している。３ａ及び３ｂはＲＴＬ設計する設計者が操作して設計・検証を行なう設計端末である。４はメールサーバで、開発ツール内を転送される種々のメールを配信する。５はファイルサーバで、新規ＲＴＬソース又は更新されたＲＴＬソースを格納する。６は合成サーバで、ＲＴＬ設計が終了したブロックについて論理合成を行なう。
【０２６０】
機能の概略は下記の通りである。即ち、該監視サーバ２は常時ファイルサーバ５に格納されているＲＴＬソースを監視しており、ＲＴＬソースの追加、更新が行なわれると該合成サーバ６にメールを送信して最新のＲＴＬソースが存在していることを通知する。該合成サーバ６は監視サーバから上記メールを受信すると、メールから合成に必要な情報を抽出して論理合成を実行し、回路チェックの後に設計端末に合成結果レポートを送信する。
【０２６１】
図１６は、論理合成の手順、図１７は合成依頼メールの例である。
【０２６２】
以降、図１７の合成依頼メールを参照しながら、図１６の論理合成の手順を説明する。
【０２６３】
Ｓ１０１．設計端末３ａ又は３ｂがＲＴＬの新規設計又はＲＴＬの更新設計を行なう。
【０２６４】
Ｓ１０２．監視サーバ２が新規ＲＴＬソース又は更新ＲＴＬソースを確認すると、合成依頼メールを合成サーバ６に送信して、論理合成の実行を依頼する。
【０２６５】
該合成依頼メールは図１７に示すような構造になっていて、ヘッダ部に配信先のメールアドレス、論理合成依頼コマンドを、ボディ部に第一キーワード“Ｓｙｎｔｈ”とそれに付随する大規模集積回路名、対象ブロック名及び設計端末のメールアドレス、第二キーワード“ＲＴＬ”及びＲＴＬソースが搭載されている。
【０２６６】
Ｓ１０３．合成依頼メールを受信した合成サーバ６は、メールに搭載されている情報を解析して、大規模集積回路名、対象ブロック名及び設計端末のメールアドレスを抽出して、予め準備されている汎用スクリプトに填め込んで定義済スクリプトを生成すると共に、起動コマンドを生成する。
【０２６７】
尚、汎用スクリプトは全ブロック共通の合成制約条件が記載されており、そこに特定ブロック固有の合成制約条件と大規模集積回路名、対象ブロック名及び設計端末のメールアドレスを填め込んで定義済スクリプトが形成される。
【０２６８】
Ｓ１０４．定義済スクリプトに応じて論理合成を実行する。
【０２６９】
Ｓ１０５．論理合成が終了した後でＲＴＬの解析結果、回路規模、タイミング情報、使用セルより成る合成結果レポートを作成する。
【０２７０】
Ｓ１０６．該合成結果レポートを設計端末に送信する。
【０２７１】
Ｓ１０７．該合成結果レポートを受信した設計端末では該合成結果レポートを解析する。
【０２７２】
Ｓ１０８．該合成結果レポートに問題がある場合には、ＲＴＬ論理設計のステップに戻ってＲＴＬソースの更新を行なわせる。そして、ＲＴＬソースが更新されたことを監視サーバが確認すると、ステップＳ１０２から処理を開始する。
【０２７３】
該合成結果レポートに問題がない場合には、論理合成を終了する。
【０２７４】
このようにして、ブロック単位にＲＴＬソースと論理合成結果を確定させることが可能になる。
【０２７５】
又、第二キーワードにＲＴＬソースを付して設計端末からメールを送信することにより、合成サーバ６は受信したメールからＲＴＬソースの切り出しを行ない、ファイルサーバ５に格納する。こうして格納されたＲＴＬソースファイルサーバ上に確認すると監視サーバ２はステップＳ１０２の論理合成の依頼をするので、上記手順によって論理合成が実行される。従って、図８では設計端末、監視サーバ、合成サーバ等が同一ネットワークに接続されている構成を示したが、開発ツールのネットワーク同士が接続されていれば、設計端末が遠隔地に設置されていてもＲＴＬソースの転送と論理合成が可能である。
【０２７６】
図１８は、受信メールの処理手順である。
【０２７７】
以降、図１８の各ステップに付した符号に沿って受信メールの処理手順について説明する。尚、図１８において、太い矢印付実線は受信メール処理の流れを示し、細い矢印付破線はデータの流れを示している。
【０２７８】
Ｓ１１１．合成サーバ６は監視サーバ２又は設計端末３ａ又は３ｂからのメールの受信を待機している。
【０２７９】
Ｓ１１２．メールを受信したか否かを判断する。メールを受信していない（Ｎｏ）と判断した場合には、ステップＳ１１１に戻って受信待機を継続する。
【０２８０】
Ｓ１１３．メールを受信した（Ｙｅｓ）と判断した場合には、受信したメールをテキスト処理プログラムに入力して正規表現とのマッチングによって定義されているキーワードの検索を行なう。
【０２８１】
Ｓ１１４．ステップＳ１１３の検索の結果、第一キーワードが抽出されたか否かを判断する。
【０２８２】
Ｓ１１５．ステップＳ１１４で第一キーワードが抽出できなかった（Ｎｏ）と判断された場合にはメールの発信元にエラーメールを送信して処理を終了する。
【０２８３】
Ｓ１１６．ステップＳ１１４で第一キーワードを抽出できた（Ｙｅｓ）と判断された場合には、第一キーワードに続く大規模集積回路名、ブロック名、設計端末のメールアドレスを抽出する。
【０２８４】
Ｓ１１７．ステップＳ１１３の検索の結果、第二キーワードが抽出されたか否かを判断する。
【０２８５】
Ｓ１１８．ステップＳ１１７で第二キーワードが抽出された（Ｙｅｓ）と判断された場合には、第二キーワード以降に搭載されているＲＴＬソースを切り出してＲＴＬソースファイルに格納して処理を終了する。
【０２８６】
Ｓ１１９．ステップＳ１１７で第二キーワードが抽出されなかった（Ｎｏ）と判断された場合には、予め準備している、全ブロックに共通な合成制約条件を記載している汎用スクリプトの所定の箇所にステップＳ１１６で抽出した大規模集積回路名、ブロック名を填め込んで定義済スクリプトを作成する。
【０２８７】
Ｓ１２０．該定義済スクリプトのファイル名を引数として論理合成を起動して実行する。
【０２８８】
Ｓ１２１．論理合成終了後に回路チェックをする。
【０２８９】
Ｓ１２２．そして、合成結果レポートを作成して、合成依頼メールの発信元に送信する。この際、ステップＳ１１６で抽出されたメールアドレスを参照して発信元を特定する。
【０２９０】
これで受信メールの処理手順を終了し、以降は、ＲＴＬ監視の結果による合成依頼メールの受信待機に入る。
【０２９１】
図１９は、ブロックレイアウトの手順である。
【０２９２】
大規模集積回路を機能毎にブロック分割して論理設計・検証及び論理合成を行ない、それらが完了したブロックについてレイアウトを行なうという手法で、チップのレイアウトをビルディングブロック方式で進めてゆく。この際、論理設計・検証及び論理合成が完了していないブロックについてはブラックボックスとして扱う。しかし、内部はブラックボックスであっても、ポートは定義されているのでブロック間の配線は可能であり、ブロック間の配線が決まっているので各ポートの負荷容量を見積もることが可能である。従って、ブロック間のタイミング検証を行なうことが可能である。
【０２９３】
以降、図１９の各ステップに付した符号に沿って、ブロックレイアウトの手順について説明する。尚、図１９において、太い矢印付実線はブロックレイアウトの流れを示し、細い矢印付破線はデータの流れを示す。又、太い実線で囲んだステップがブロックレイアウトでの処理事項で、細い実線で囲んだステップはブロックレイアウト以前に行なわれる処理事項である。
【０２９４】
Ｓ１．開発手順の最初に回路アーキテクチャの検討が行なわれ、その結果、フロアプランの草案及びクロックツリーが得られており、その後にブロック間ネットリストが得られている。
【０２９５】
ブロックレイアウトはこの状態からスタートする。
【０２９６】
Ｓ１３１．回路回路アーキテクチャ検討の結果得られているフロアプラン、クロックツリー及びブロック間ネットリストを入力としてブロック間のクロックスキューを調整し、予めクロックスキューを除去する。
【０２９７】
Ｓ１３２．ステップＳ１３１でのクロックスキューがＯＫか否かを判断する。
問題がある（Ｎｏ）と判断された場合には、ステップＳ１の回路アーキテクチャ検討に戻って、主としてクロックツリーとフロアプランニングの草案を検討しなおしてクロックスキューの調整をするという処理を、ＯＫと判断されるまで行なう。
【０２９８】
Ｓ１３３．ステップＳ１３２でＯＫ（Ｙｅｓ）と判断された場合には、ブロック間配線の負荷容量、抵抗という合成制約条件の考慮の下にブロック間配線を行なう。この際、ブラックボックスのブロックに接続される配線についてもタイミングの妥当性を確認するために、ブロックの入出力ポートにはフリップフロップを配置する。
【０２９９】
Ｓ１３４．ブロック間のタイミングの妥当性を確認し、タイミングが妥当でない（Ｎｏ）であると判断された場合にはステップＳ１の回路アーキテクラャ検討に戻って、再度フロアプラン、クロックツリー及びブロック間ネットリストの検討を行ない、ステップＳ１３１、ステップＳ１３３を実行する。
【０３００】
Ｓ１３５．ステップＳ１３４でタイミングが妥当（Ｙｅｓ）であると判断された場合には、ブロック間配線を確定する。
【０３０１】
Ｓ１３６．ブロック内合成をする際のファンアウトやタイミング調整のための合成制約条件の抽出を行なう。
【０３０２】
Ｓ１３７．ＲＴＬ設計が完了したブロックから、ステップＳ１３６で抽出した合成制約条件を元に論理合成を行ない、ブラックボックスと差し替える。
【０３０３】
Ｓ１３８．ブラックボックスと差し替えたブロック内部の配置・配線を行なう。
【０３０４】
Ｓ１３９．ステップＳ１３８で配置・配線をしたブロック内のタイミング検証を行なう。タイミングが妥当でない（Ｎｏ）と判断された場合には、ステップＳ１３７に戻ってブロック内の論理合成をやり直して、ステップＳ１３７、ステップＳ１３８、ステップＳ１３９を実行する。
【０３０５】
Ｓ１４０．ステップＳ１３９でタイミングが妥当である（Ｙｅｓ）と判断された場合には、ブロック内の配線を確定する。
【０３０６】
Ｓ１４１．全てのブロックについて設計が完了したか否かを判断して、設計済でないブロックが残っている（Ｎｏ）と判断された場合には、ステップＳ１３６以降を繰り返す。
【０３０７】
一方、全てのブロックについて設計が完了している（Ｙｅｓ）と判断された場合には、この処理手順を終了する。
【０３０８】
このように、事前にブロック間ネットリストを確定し、論理設計・検証及び論理合成が完了したブロックから順に配置・配線を行なうことにより、チップの設計をビルディングブロック方式で進めてゆくことができ、チップの設計段階から回路アーキテクチャ検討に後戻りすることはないので、チップの設計の効率と設計品質を向上させることができる。
【図面の簡単な説明】
【０３０９】
【図１】本発明の大規模集積回路の開発工程の流れ。
【図２】本発明の大規模集積回路開発の原理的手順。
【図３】本発明の大規模集積回路開発の詳細手順。
【図４】回路アーキテクチャ検討の詳細手順。
【図５】クロックポートへのフリップフロップの割付を説明する図。
【図６】物理インタフェース情報生成の手順。
【図７】ブロック間ネット生成を概念的に示す図
【図８】本発明の開発ツールの構成。
【図９】ＲＴＬ監視モードの機能を説明する図。
【図１０】ＲＴＬ監視の概略手順。
【図１１】ＲＴＬ監視データ生成の手順。
【図１２】ＲＴＬ監視開始コマンドの例。
【図１３】ＲＴＬソース監視の手順。
【図１４】ＲＴＬ監視結果返信メールの例。
【図１５】論理合成モードの機能を説明する図。
【図１６】論理合成の手順。
【図１７】論理合成依頼メールの例。
【図１８】受信メールの処理手順。
【図１９】ブロックレイアウトの手順。
【図２０】従来の大規模集積回路の開発工程の流れ。
【図２１】従来の大規模集積回路開発の手順。
【符号の説明】
【０３１０】
１  ネットワーク
２  監視サーバ
３ａ  設計端末
３ｂ  設計端末
４  メールサーバ
５  ファイルサーバ
６  合成サーバ
【図１】
2005353079.tif 000003
【図２】
2005353079.tif 000004
【図３】
2005353079.tif 000005
【図４】
2005353079.tif 000006
【図５】
2005353079.tif 000007
【図６】
2005353079.tif 000008
【図７】
2005353079.tif 000009
【図８】
2005353079.tif 000010
【図９】
2005353079.tif 000011
【図１０】
2005353079.tif 000012
【図１１】
2005353079.tif 000013
【図１２】
2005353079.tif 000014
【図１３】
2005353079.tif 000015
【図１４】
2005353079.tif 000016
【図１５】
2005353079.tif 000017
【図１６】
2005353079.tif 000018
【図１７】
2005353079.tif 000019
【図１８】
2005353079.tif 000020
【図１９】
2005353079.tif 000021
【図２０】
2005353079.tif 000022
【図２１】
2005353079.tif 000023
【手続補正書】
【提出日】平成17年7月26日(2005.7.26)
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
大規模集積回路を機能分割した単位であるブロックに対応してＲＴＬ設計を行う大規模集積回路の開発ツールにおいて、
前記ＲＴＬ設計の結果を機能記述言語で記述したＲＴＬソースとして格納するファイルサーバと、
前記ファイルサーバに格納されている前記ＲＴＬソースの更新前後の差分をチェックする監視サーバと、
前記監視サーバにより更新前後に差分があると判断された前記ＲＴＬソースに対して論理合成を行う合成サーバと、
前記ファイルサーバ、前記監視サーバ、及び前記合成サーバの間の処理連携を行うためのデータを受け渡すネットワークとを備える
ことを特徴とする大規模集積回路の開発ツール。
【請求項２】
請求項１に記載の大規模集積回路の開発ツールにおいて、
前記監視サーバは、更新後のＲＴＬソースと更新前のＲＴＬソースとの差分をチェックする差分チェック手段と、前記ＲＴＬソースの版数をチェックする版数チェック手段と、前記差分チェック手段と前記版数チェック手段の結果を基に版数の更新漏れをチェックする手段とを備える
ことを特徴とする大規模集積回路の開発ツール。
【請求項３】
請求項１に記載の大規模集積回路の開発ツールにおいて、
前記監視サーバは、前記ＲＴＬソースの更新前後に差分があると判断した場合は合成依頼コマンドを前記合成サーバへ送信して論理合成を依頼する手段を備え、
前記合成サーバは、前記監視サーバからの前記合成依頼コマンドの受信によって論理合成を行う手段を備える
ことを特徴とする大規模集積回路の開発ツール。
【請求項４】
請求項３に記載の大規模集積回路の開発ツールにおいて、
前記合成依頼コマンドは論理合成の対象となる対象ブロック名を含み、
前記合成サーバは、全ブロック共通の合成制約条件情報を含んだ汎用スクリプトと、前記汎用スクリプトに前記対象ブロック名が示すブロックに固有の合成条件情報を付加して定義済スクリプトを生成する手段と、前記定義済スクリプトに基づいて論理合成を行う手段とを備える
ことを特徴とする大規模集積回路の開発ツール。
【請求項５】
請求項１ないし請求項４に記載の大規模集積回路の開発ツールにおいて、
前記ファイルサーバへ格納する前記ＲＴＬソースの入力と、前記監視サーバの監視結果の出力と、前記合成サーバの論理合成結果の出力とを行う１以上の設計端末を備える
ことを特徴とする大規模集積回路の開発ツール。
【請求項６】
請求項５に記載の大規模集積回路の開発ツールにおいて、
前記ファイルサーバ、前記監視サーバ、前記合成サーバ、及び前記１以上の設計端末の間の処理連携を行うためのデータの受け渡しは、メールサーバを介した電子メールにより行う
ことを特徴とする大規模集積回路の開発ツール。