(57)【要約】【課題】  従来のＤＲＣ実行装置では、ＤＲＣを並列処理する際の最適化が困難であった。【解決手段】  半導体集積回路の構造を規定したレイアウトパターンに対して、検証用の複数の設計規則を適用してデザインルールチェックを実行するデザインルールチェック実行装置１００であって、複数の設計規則の各設計規則の基準検証時間を保持する検証時間データベース１と、半導体集積回路に対して適用される複数の設計規則の各設計規則の検証時間を基準検証時間に基づいて推定する検証時間推定部４と、検証時間推定部の推定した各設計規則の検証時間に基づいて複数の設計規則の検証を複数の検証実行部に分配するルール分配部と５、ルール分配部によって分配された設計規則の検証を実行する複数の検証実行部７とを有している。【選択図】  図１
2006024125.tif 000002
【特許請求の範囲】
【請求項１】
半導体集積回路の構造を規定した検証対象となる第1のレイアウトパターンに対して、検証用の複数の設計規則を適用してデザインルールチェックを実行するデザインルールチェック実行装置であって、
前記複数の設計規則の各設計規則の基準検証時間を保持する検証時間データベースと、
前記半導体集積回路に対して適用される前記複数の設計規則の各設計規則の検証時間を前記基準検証時間に基づいて推定する検証時間推定部と、
前記検証時間推定部の推定した各設計規則の検証時間に基づいて前記複数の設計規則の検証を複数の検証実行部に分配するルール分配部と、
前記ルール分配部によって分配された前記設計規則の検証を実行する複数の検証実行部とを有するデザインルールチェック実行装置。
【請求項２】
前記デザインルールチェック実行装置は、さらに前記デザインルールチェックの実行結果を保持するログファイル記憶部を有し、
前記検証時間推定部は前記基準検証時間および前記ログファイル記憶部に保持された実行結果に基づいて各設計規則の検証時間を推定することを特徴とする請求項1に記載のデザインルールチェック装置。
【請求項３】
前記デザインルールチェック実行装置は、さらに前記第1のレイアウトパターンと第２のレイアウトパターンとを比較し、その差分データを出力するパターン比較部と、
前記差分データに基づいて、検証ルールデータベースに保持されたデータから検証すべきルールを抽出する検証ルール判定部とを有することを特徴とする請求項１あるいは請求項２のいずれか１項に記載のデザインルールチェック実行装置。
【請求項４】
前記デザインルールチェック装置は、パターンデータ記憶部をさらに有し、前記第２のレイアウトパターンは前記パターンデータ記憶部に保持されたレイアウトパターンであることを特徴とする請求項３に記載のデザインルールチェック実行装置。
【請求項５】
半導体集積回路の構造を規定した検証対象となる第1のレイアウトパターンに対して、検証用の複数の設計規則を適用してデザインルールチェックを実行するデザインルールチェック実行方法であって、
前記第1のレイアウトパターンに基づいて、検証時間データベースから前記複数の設計規則の各設計規則の基準検証時間を読み出して各設計規則ごとの検証時間を推定し、
前記推定された検証時間に基づいて前記複数の設計規則の検証を複数の検証実行部に分配し、
前記分配された前記設計規則の検証を複数の検証実行部で並列に実行するデザインルールチェック実行方法。
【請求項６】
半導体集積回路の構造を規定した検証対象となる第1のレイアウトパターンに対して、検証用の複数の設計規則を適用してデザインルールチェックを実行するデザインルールチェック実行方法であって、
検証対象の半導体装置に関しての検証結果の有無を判別し、
前記検証結果が存在しない場合は、検証時間データベースから前記複数の設計規則の各設計規則の基準検証時間を読み出して各設計規則ごとの検証時間を推定し、
前記検証結果が存在する場合は、前記検証結果に対応した第２のレイアウトデータと前記第１のレイアウトデータを比較して差分データを生成し、
前記差分データに基づいて、検証対象となる設計規則を抽出し、
前記検証対象となる設計規則に基づいて、前記検証結果および検証時間データベースから検証対象となる各設計規則の基準検証時間を読み出して各設計規則ごとの検証時間を推定し、
前記推定された検証時間に基づいて前記複数の設計規則の検証を複数の検証実行部に分配し、
前記分配された前記設計規則の検証を複数の検証実行部で並列に実行するデザインルールチェック実行方法。
【請求項７】
前記検証時間データベースは、各設計規則ごとの平均検証時間が保持されたデータベースであることを特徴とする請求項６あるいは請求項７のいずれか１項に記載のデザインルールチェック実行方法。
【請求項８】
前記分配は推定された検証時間の大きいものから行われることを特徴とする請求項６乃至８のいずれか１項に記載のデザインルールチェック実行方法。
【請求項９】
前記分配は前記複数の検証実行部の検証に要する時間が、略同一となるように行われることを特徴とする請求項６乃至９のいずれか1項に記載のデザインルールチェック実行方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は半導体集積回路のレイアウト設計データのレイアウト検証に関する。特に、デザインルールチェックのチェック項目を複数のグループに分割し、その項目グループごとにデザインルールチェックを行う並列処理方法とその実行装置に関するものである。
【背景技術】
【０００２】
近年の集積回路の大規模化、高密度化に伴い、レイアウト設計データのレイアウト検証の検証時間は増加の一途をたどっている。このため、レイアウト検証をより高速で行う方法が検討されている。このレイアウト検証の高速化のために、チェック項目を細分化し並列処理することによってデザインルールチェックに要する時間を短縮することが行われている。
【０００３】
しかし、高密度化に伴いチェック項目も増加するため、人手でチェック項目を選択するには限界がありぬけも生じるため並列処理を行う各項目のスケジューリングを、正確に最適化する必要が生じている。特許文献１に記載の技術では、並列処理を行うときに、検証時間に応じてタスクを分配して並列処理することにより、検証時間の均一化を図ることが示されている。
【特許文献１】特開２００２―２９６０１６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
従来のデザインルールチェックの並列処理では、初回のデザインルールチェックで各チェック項目の検証時間を人為的に予測した上でスケジューリングを行っていたため、検証時間の均一化を計ることは困難であった。特許文献1に記載の技術においても、それぞれのタスクの実行時間は人為的な設定に頼らざるをえなかった。
【０００５】
従来の並列処理装置ではデザインルールチェックのエラーなどによる再チェックにかかる工数などが考慮されておらず、再チェックが必要となった場合は、再度スケジューリングをしなおさなければならなかった。
【課題を解決するための手段】
【０００６】
半導体集積回路の構造を規定した検証対象となる第1のレイアウトパターンに対して、検証用の複数の設計規則を適用してデザインルールチェックを実行するデザインルールチェック実行装置であって、前記複数の設計規則の各設計規則の基準検証時間を保持する検証時間データベースと、前記半導体集積回路に対して適用される前記複数の設計規則の各設計規則の検証時間を前記基準検証時間に基づいて推定する検証時間推定部と、前記検証時間推定部の推定した各設計規則の検証時間に基づいて前記複数の設計規則の検証を複数の検証実行部に分配するルール分配部と、前記ルール分配部によって分配された前記設計規則の検証を実行する複数の検証実行部とを有している。
【０００７】
さらに、前記デザインルールチェック実行装置は、さらに前記デザインルールチェックの実行結果を保持するログファイル記憶部を有していてもよい。前記検証時間推定部は前記基準検証時間および前記ログファイル記憶部に保持された実行結果に基づいて各設計規則の検証時間を推定することが可能となる。
【０００８】
さらに、前記デザインルールチェック実行装置は、前記第1のレイアウトパターンと第２のレイアウトパターンとを比較し、その差分データを出力するパターン比較部と、前記差分データに基づいて、検証ルールデータベースに保持されたデータから検証すべきルールを抽出する検証ルール決定部とを有していてもよい。
【０００９】
さらに、前記デザインルールチェック装置は、パターンデータ記憶部を有していてもよい。前記第２のレイアウトパターンは前記パターンデータ記憶部に保持されたレイアウトパターンであるとすることが出来る。
【００１０】
本発明は、半導体集積回路の構造を規定したレイアウトパターンに対して、検証用の複数の設計規則を適用してデザインルールチェックを実行するデザインルールチェック実行方法であって、検証時間データベースから前記複数の設計規則の各設計規則の基準検証時間を読み出して各設計規則ごとの検証時間を推定し、前記推定された検証時間に基づいて前記複数の設計規則の検証を複数の検証実行部に分配し、前記分配された前記設計規則の検証を複数の検証実行部で並列に実行する。
【００１１】
また、本発明は、半導体集積回路の構造を規定したレイアウトパターンに対して、検証用の複数の設計規則を適用してデザインルールチェックを実行するデザインルールチェック実行方法であって、検証対象の半導体装置に関しての検証結果の有無を判別し、前記検証結果が存在しない場合は、検証時間データベースから前記複数の設計規則の各設計規則の基準検証時間を読み出して各設計規則ごとの検証時間を推定し、前記検証結果が存在する場合は、前記検証結果に基づいた第１のレイアウトデータと検証対象となる第２のレイアウトデータを比較して差分データを生成し、前記差分データに基づいて、検証対象となる設計規則を抽出し、前記検証対象となる設計規則に基づいて、前記検証結果および検証時間データベースから検証対象となる各設計規則の基準検証時間を読み出して各設計規則ごとの検証時間を推定し、前記推定された検証時間に基づいて前記複数の設計規則の検証を複数の検証実行部に分配し、前記分配された前記設計規則の検証を複数の検証実行部で並列に実行する。
【００１２】
ここで、前記検証時間データベースは、各設計規則ごとの平均検証時間が保持されたデータベースであるとすることが可能である。
【００１３】
さらに、前記分配は推定された検証時間の大きいものから行われるとすることが可能である。
【００１４】
さらに。前記分配は前記複数の検証実行部の検証に要する時間が、略同一となるように行われることが可能である。
【発明の効果】
【００１５】
本発明により、デザインルールチェックを並列処理する際の、ルール分配が最適化され、設計検証に要する工数が削減される。
【発明を実施するための最良の形態】
【００１６】
本発明におけるデザインルールチェック（以降、ＤＲＣと称する）について説明する。半導体集積回路を設計する場合、各層の配線や拡散層の配置を規定するレイアウトパターンが設計される。このレイアウトパターンには、各層や回路要素によって、その配線幅や配線面積などの様々な設計規則（デザインルール）が存在する。ＤＲＣとは、半導体集積回路を設計する際に、設計したレイアウトパターンがこのデザインルールを満たしているかどうかを検証することである。
【００１７】
このデザインルールは、半導体集積回路の層や回路要素に応じて細分化して規定されている。1つの半導体集積回路には、この細分化されたデザインルールが数十個以上適用されている。レイアウトパターンは、各デザインルールの全てに合致しているかどうかがチェックされ、合致していないデザインルールに関してはエラーと判断される。以降、この細分化された各項目を単にルールと称する。また、数十個中のある1つルールであることを説明するためには、適宜数字を付して説明する場合もある。
【００１８】
本発明のＤＲＣ実行装置では、この複数のルールのチェックを検証実行部である複数のＣＰＵで並列に実行している。この検証を実行するためのスクリプト（命令）はＣＰＵ毎に生成され、ＣＰＵはその命令に基づいて検証を実行する。このように複数のルールに関しての検証動作を複数のＣＰＵを用いて分散処理させることが本発明のＤＲＣに相当する。
【００１９】
実施の形態1
以下、図面を参照して本発明の実施の形態１のＤＲＣ実行装置１００について説明する。図1に示すように、本発明のＤＲＣ実行装置１００は、検証時間データベース１、ＤＲＣログファイル記憶部２、ＤＥＣ実行制御部３および複数のＣＰＵ７を有している。ＤＲＣ実行制御部３は、検証時間推定部４、ルール分配部５、ＤＲＣスクリプト生成部６を有している。
【００２０】
検証時間データベース１には、細分化された複数のルールと、各ルールに対応する基準検証時間が記憶されている。このルールと対応する基準検証時間は、ＤＲＣ実行のたびに更新され記憶されている。したがって、検証時間データベース１に記憶されている基準検証時間は、過去にＤＲＣ実行装置１００によって行われたＤＲＣに基づいて、ＣＰＵがそれぞれのルールのチェックに必要とする平均的な処理時間を記憶したものである。
【００２１】
詳細には、このデータベースには総配線長、チップサイズ、プロセスシリーズごとに分類して、各ルールのチェックに要した検証時間を示すテーブルが保持されている。例えば、総配線長の範囲をＡ，Ｂ，Ｃと分けて、それぞれの範囲内の総配線長のときにルール１のチェックに要した時間、ルール２のチェックに要した時間、ルール３のチェックに要した時間がテーブルとして記憶されている。同様なテーブルがチップサイズ、プロセスシリーズなどに関しても記憶されている。図２はこの検証時間データベース１の様子を模式的に表したものである。図２に示すようにこの検証時間データベース１は各ルールの基準検証時間が、検証時間に関わる条件ごとに分類された複数のテーブルからなるものである。
【００２２】
ＤＲＣログファイル記憶部２は、ＤＲＣ実行装置１００が行ったＤＲＣのチェック結果が保持されている記憶部である。ＤＲＣの結果としては例えばＤＲＣを行ったチップの種類、そのチップにおける各層の総配線長、各層における配線が占める面積率、またＤＲＣにおいてエラーが起こったルールの種類とエラーの数、そのルールを検証するのに要した検証時間などが記憶されている。
【００２３】
ＤＲＣ実行制御部３は、このＤＲＣ実行装置１００が行うＤＲＣ全体の動作を制御する部分である。ＤＲＣ実行制御部３はＤＲＣ実行装置１００の動作に応じて、検証時間データベース１およびＤＲＣログファイル記憶部２のデータの読み出し、書き込みなどを行う。ＤＲＣ実行制御部３は、ＤＲＣを行う半導体集積回路に適用された複数のルールに基づいて、検証時間データベース１、ＤＲＣログファイル記憶部２に記憶されたデータを読み出す。
【００２４】
検証時間推定部４は、ＤＲＣで適用される全てのルールに関して、細分化されたルールごとのチェックに要する時間を予測する。
【００２５】
ルール分配部５は検証時間推定部４が予測した各ルールの検証時間に基づいて、複数のＣＰＵ７がチェックするルールを分配する。ルール分配部５は、各ＣＰＵがチェックするルールの種類とその順番を決定する部分である。
【００２６】
実行スクリプト生成部６は、ルール分配部５が決定した各ＣＰＵがチェックするルールに合わせて、各ＣＰＵにチェックを実行させる命令を生成する部分である。
【００２７】
以下に図３に示すフローチャートを参考にして、この実施の形態のＤＲＣ実行装置１００の動作について説明する。
【００２８】
あるひとつの半導体チップに関して、ＤＲＣの実行が開始されると、ＤＲＣ実行制御部３は、ＤＲＣ実行装置１００が過去に同一チップのＤＲＣを行っているかどうかを確認する。つまり、ＤＲＣログファイル記憶部２の内容を確認する。（ステップＳ１参照）ここで、現在ＤＲＣを行おうとしているチップと同一チップについてのＤＲＣログファイルがあった場合は、Ｓ２に進み、ＤＲＣログファイルがなかった場合はＳ３へと進む。
【００２９】
同一チップのＤＲＣログファイルがなかった場合、ＤＲＣ実行制御部３は検証時間データベース１の内容を読み込む。（ステップＳ３）その後ステップＳ４において、検証時間推定部４が検証時間データベース１のテーブルから、ルールごとのチェックに要する時間を予測する。この予測は、ＤＲＣを行おうとしているチップの各ルールについて、過去に同一のルールをチェックした際の検証時間に基づいて行われる。
【００３０】
このルールごとの基準検証時間は検証時間データベース１に、チップサイズやプロセスに応じて分類されて記憶されている。この記憶されたデータから、現在ＤＲＣを行おうとしているチップのルールごとにその処理に必要な時間の予測が可能である。
【００３１】
例えば、複数のルールの中のひとつが「１層目に用いられるアルミ配線の間隔が所定値以上なければならない」というものであったとする。この場合、ＤＲＣ実行制御部３（検証時間推定部４）では、検証時間データベース１から、このアルミ配線の面積に関するルール検証に要する基準検証時間を抽出し、このルールの検証に要する時間を予測する。この予測する時間はチップサイズやプロセスなどの条件が、ＤＲＣを行おうとしているチップに最も近いときの基準検証時間を用いても良いし、テーブルに保持されている基準検証時間に何らかの補正処理を行った結果でも良い。検証時間推定部４では、このように個々のルールが他のチップのＤＲＣで検証されたときの検証時間を元に現在のＤＲＣにおける同一ルールの検証時間を予測する。
【００３２】
ステップＳ１で、ＤＲＣログファイルがあった場合は、ステップＳ２に進む。ステップＳ２で、ＤＲＣ実行制御部３は、ＤＲＣログファイル内にエラー情報が含まれているかどうかを判定する。ＤＲＣログファイルが存在するということは、現在ＤＲＣが行われているチップに関しては２回目以降のＤＲＣが行われているということである。ここで、ＤＲＣログファイルにエラー記録が存在しない場合は、このチップのレイアウト検証は済んでいるものとし、ステップＳ１０に進み、ＤＲＣを終了する。
【００３３】
ＤＲＣログファイルにエラーが存在した場合はステップＳ５に進む。ここでＤＲＣ実行制御部３はＤＲＣログファイルを読み込み、過去のエラーデータからエラーが起きたルールやそのルールのチェックに要した時間などが読み込まれる。その後ステップＳ６において、各ルールのチェックに要する時間の予測が行われる。この予測は基本的にＳ５同様、ＤＲＣ実行制御部３が検証時間データベース１を読み込み、このデータベースに保持されたルールごとの基準検証時間を元に予測される。ただし、ＤＲＣログファイルにエラーが記録されていたルールに関しては、ＤＲＣログファイルに記録されていたルールのチェックに要した時間と、検証時間データベース１に記憶されていた基準検証時間との比較が行われる。
【００３４】
ここでデータベースに記憶されていた基準検証時間とＤＲＣログファイルに記録されていた検証時間との差が大きい場合、ＤＲＣ実行制御部３は、前回のＤＲＣでは、エラーによりそのルールの検証時間が変化したものと判断する。ここでは、２回目以降のＤＲＣであるため、エラー訂正後のＤＲＣと判断する。そこで、データベースに記憶されていた基準検証時間とＤＲＣログファイルに記録されていた検証時間との差が大きい場合、推定される検証時間としては、検証時間データベース１に記憶されていた基準検証時間をそのルールのチェックに要する時間として推定する。ここでデータベースに記憶されていた基準検証時間とＤＲＣログファイルに記録されていた検証時間との差が小さい場合は、ＤＲＣログファイルに記録されていた時間をそのルールのチェックに要する時間として推定する。検証時間推定部４が各ルール関しての検証時間を推定した後にステップＳ７へと進む。
【００３５】
ステップＳ７ではＳ６あるいはＳ４で推定された各ルールに対応する予測検証時間に基づいて、検証時間の大きいと推定されるルールから小さいと推定されるルールへの降順の並べ替えが行われる。このように推定された検証時間に基づいて並べ替えられたルールはルール分配部５で各ＣＰＵにその処理を実行させるためのルールの振り分けが行われる。
【００３６】
ルール分配部５ではステップＳ８が実行される。ステップＳ８では、予測される検証時間について降順に並べられたルールを複数のＣＰＵ７へと振り分けていく。図４は例えば１０個のルールに関するチェックを３つのＣＰＵ７−１〜７−３に振り分ける場合を示した図である。
【００３７】
図４に示す例では、検証時間が大きいと予測される上位から３つのルールのチェックは、各ＣＰＵ７−１〜７−３がそれぞれ１つずつ実行するように分配される。チェックに要する検証時間が４番目に長いとされたルールに関してはＣＰＵ７−１〜７−３の中で、合計検証時間のもっとも小さいと予測されるＣＰＵで処理が実行されるように分配される。図４に示す例ではルール１の検証にＣＰＵ７−１で１００分、ルール２３の検証にＣＰＵ７−２で５５分、ルール７の検証にＣＰＵ７−３で５０分かかるとしている。したがって、４番目に検証時間の長いルール１９に関しては、予測検証時間の合計がもっとも短いＣＰＵ７−３に分配される。ＣＰＵ７−３の予測検証時間の合計は７９分となり、予測検証時間の合計がもっとも短いのはＣＰＵ７−２となる。そのため、５番目に検証時間の長いルール１５に関しては、ＣＰＵ７−２に分配される。以降、同様の手順を繰り返してＣＰＵ７−１〜７−３に検証するルールを分配していく。
【００３８】
全てのルールに関して分配が終了した後、ＤＲＣスクリプト生成部６では、各ＣＰＵ７が実行するＤＲＣに対応したスクリプトが生成される。（ステップＳ８参照）各ＣＰＵ７にその命令が伝達されることでＤＲＣ実行装置１００のＤＲＣが実行される。図４に示した例では各ＣＰＵ７ともに約１００分でＤＲＣが終了する。
【００３９】
ＤＲＣ実行後、ステップＳ１０においてＤＲＣログファイルが生成される。ここでＤＲＣ実行制御部３は、ＤＲＣログファイルをＤＲＣログファイル記憶部２に記録する。一方、ＤＲＣ実行制御部３では、検証時間データベース１から与えられた基準検証時間と、現在実行されたＤＲＣの検証時間から、ルール毎の平均検証時間を算出する。算出されたルール毎の平均検証時間は新たな基準検証時間として、検証時間データベース１のテーブルの対応する部分に書き込まれる。
【００４０】
以上、詳細に説明したように、実施の形態１のＤＲＣ実行装置１００では、細分化されたルール毎にその基準検証時間が蓄積されている。そのため、新たなＤＲＣを実行するときでも、その処理にＣＰＵが要する時間を予測することが可能である。新たなＤＲＣを行う場合にはルール毎に保存された基準検証時間から、並列処理を行う場合の負荷の均等化を図ることが出来る。
【００４１】
また、図1のＤＲＣ実行装置１００ではＣＰＵ７を３つとし、ＤＲＣ実行制御部３を１つとして説明したが、図５に示すような構成であっても良い。図５に示す構成では５１がサーバであり、この中に検証時間データベース１、ＤＲＣログファイル記憶部２を有している。このシステムに対し複数のＣＰＵ７−１〜７−ｎが接続されるとともに、複数のクライアント５２が接続されている。ここで各クライアント５２は、ＤＲＣ実行制御部３を有している。ここで、クライアント５２ではＤＲＣ実行に際して使用するＣＰＵの個数を指定できるものとする。例えば、図５に示したＤＲＣ実行装置５０において、クライアント５２−１が４個のＣＰＵ７−１〜７−４を指定してＤＲＣを実行するとする。このとき、クライアント５２−１とサーバ５１、ＣＰＵ７−１〜７−４を用いて上述と同様の動作でＣＰＵ４つを用いたＤＲＣが実行される。一方、このときクライアント５２−２においても、ＣＰＵ７−５〜７−ｎ、サーバ５１、クライアント５２−２を用いて他のＤＲＣ実行が可能である。このように複数のＣＰＵ７とクライアント５２を接続し、クライアント側でＤＲＣ実行に使用するＣＰＵ数を指定することで、検証時間データベース１とＤＲＣログファイル記憶部２に保持されたデータをより効果的に利用することが可能である。
【００４２】
実施の形態２
図６は本発明の実施の形態２に関わるＤＲＣ実行装置２００の構成を示す図である。なお第１の実施の形態と同一の構成に対しては同一の符号を付し、その説明を省略する。
【００４３】
実施の形態２のＤＲＣ実行装置２００では実施の形態１の構成に加えてパターンデータ記憶部１０、検証ルールデータベース１１を有している。またＤＲＣ実行制御部３は、パターン比較部８および検証ルール判定部９を有している。
【００４４】
パターンデータ記憶部１０は、レイアウトパターンのデータを保持している記憶部である。例えばあるひとつのチップに対してＤＲＣが実行されＤＲＣログファイルが形成された場合、そのＤＲＣログファイルに対応するチップのレイアウトパターンが記憶されている。パターンデータ記憶部１０は、このようなレイアウトパターンを複数保持している記憶部であるとする。
【００４５】
検証ルールデータベース１１は後述する差分データに対応して検証するルールが記憶されているテーブルを有している。つまり、レイアウトの変更箇所に応じてどのルールを検証するかを示すテーブルが保持されている。
【００４６】
パターン比較部８はＤＲＣが実行されているチップのレイアウトパターン（第1のレイアウトパターン）とパターンデータ記憶部１０から読み出されたレイアウトパターン（第２のレイアウトパターン）とのデータを比較し、その差に相当する差分データを出力する部分である。この差分データとは比較されたレイアウトパターンのどの部分がどのように異なっているかを示すデータに相当する。
【００４７】
検証ルール判定部９は差分データ、検証ルールデータベース１１のデータからＤＲＣ実行装置２００が検証するべきルールを決定する部分である。
【００４８】
このように構成された実施の形態２のＤＲＣ実行装置２００の動作について図７を用いて説明する。
【００４９】
ＤＲＣがスタートされると、実施の形態１と同様に、ステップＳ１でＤＲＣ実行装置２００は現在ＤＲＣが実行されようとしているチップに関してのＤＲＣログファイルが存在しているかどうかを参照する。ＤＲＣログファイルが存在しなかった場合の動作については実施の形態１と同様であるため以後の説明は省略する。またステップＳ２において、ＤＲＣログファイルが存在するが、ＤＲＣログファイルにエラーの記録がない場合も、実施の形態１と同様の動作となるのでその説明を省略する。
【００５０】
ＤＲＣログファイルが存在し、エラー記録が残っている場合はステップＳ５へと進む。ステップＳ５では実施の形態１と同様にＤＲＣログファイルの読み込みが行われる。ＤＲＣログファイルを読み込んだ後、実施の形態２ではステップＳ７１へと進む。
【００５１】
ここで、ステップＳ７１へと進むＤＲＣは同一チップに対する２回目以降のＤＲＣである。２回目以降のＤＲＣでは、必ずしも全てのルールに関して検証を行う必要はない。例えば前回（仮に1回目とする）のＤＲＣのエラーに基づいて１層目のメタル配線の幅が変更されたのであれば、５層目、６層目などのレイアウトパターンまでは検証しなくてもすむ場合も考えられるからである。一方、２回目以降のＤＲＣでは、原則的には１回目のＤＲＣのエラーに基づいたレイアウトパターンの変更が行われている。
【００５２】
そこで、読み出されたＤＲＣログファイルに対応する修正前のレイアウトパターン（第２のレイアウトパターン）のデータが、ステップＳ７１で読み込まれる。このレイアウト変更前のパターンデータはパターンデータ記憶部１０に記憶されている。
【００５３】
ステップＳ７２では、パターンデータ記憶部１０から読み出された変更前のパターンデータと、検証対象となるパターンデータ（第１のレイアウトパターン）の比較が行われる。つまりパターン比較部８では1回目のパターンデータと２回目のパターンデータの比較が行われる。ここで、１回目のレイアウトパターンのデータは、１回目のＤＲＣログファイルと関連付けされて、パターンデータ記憶部１０に保持されているものとする。
【００５４】
ステップＳ６２で、パターンの修正前と修正後のレイアウトパターンが比較される。この結果、パターン比較部８からは差分データが出力される。つまり、どの部分のレイアウトパターンがどのように変更されたのかという部分に関するデータが出力される。
【００５５】
検証ルール判定部９では差分データに基づいて、検証ルールデータベース１１から検証すべきルールを抽出する。検証ルール判定部９で差分データに基づいて、検証の必要なルールが全て抽出され、決定される。（ステップＳ７３）
【００５６】
検証すべきルールを決定したした後は、ステップＳ６に進み検証すべきルールのそれぞれに対しての検証時間が予測される。この予測は実施の形態1のＳ６と同様にＤＲＣログファイルのエラー記録および検証時間データベースの基準検証時間に基づいて行われる。実施の形態1と異なる点は、上述のステップＳ７１〜Ｓ７３で、レイアウト変更に基づいて検証すべきルールの絞込みが行われている点である。
【００５７】
この検証時間が予測された後は実施の形態1と同様のステップＳ７〜Ｓ１０が行われる。
【００５８】
以上詳細に説明したように、実施の形態２のＤＲＣ実行装置では、ステップＳ７１〜Ｓ７３において、検証するべきルールの絞込みが行われている。この絞込みは前回、ＤＲＣが行われたときのパターンデータと、今回ＤＲＣを行うパターンデータとの差に基づいて決定される。したがって、パターン変更を伴った２回目以降のＤＲＣを実行する場合に全てのルールに関しての再検証を行う必要がなくなり、検証に必要とする時間を大幅に短縮できる。
【００５９】
また、実施の形態２ではパターンデータ記憶部１０に前回のＤＲＣ実行時のパターンデータが記憶されているとしている。しかし、必ずしも記憶されている必要はなく、必要に応じて第1のレイアウトパターンと第２のレイアウトパターンを同時に入力するようにしても良い。
【００６０】
また、実施の形態２では前回のＤＲＣログファイルを読み出した後にパターンデータの比較を行い、検証すべきルールを抽出しているが、検証すべきルールの抽出はそれより前に行われても良い。
【００６１】
実施の形態２についても実施の形態1の図５と同様に複数のＣＰＵとクライアントが接続される構成とすることが可能である。
【００６２】
以上詳細に説明したように本発明のＤＲＣ実行装置によれば、ＤＲＣ実行装置が並列に処理して実行する各ルールの検証を最適にスケジューリングすることが可能である。また、実施の形態２のＤＲＣ実行装置では同一チップに対する再検証の時間を大幅に短縮することが可能となる。
【００６３】
また、実施の形態では、検証時間データベース１に、ＣＰＵによる処理速度の差は含まれていないが、複数のＣＰＵの処理速度がそれぞれ異なる場合は、さらにＣＰＵ毎の処理時間テーブルを用意して最適化を図ることも可能である。また実施の形態では検証時間推定部４、ルール分配部５、ＤＲＣ実行スクリプト生成部６として記載されているが、各部はソフトウェア上で構成されていても良い。
【図面の簡単な説明】
【００６４】
【図１】本発明の実施の形態１のＤＲＣ実行装置の構成を示す図である。
【図２】本発明の検証時間データベースの概要を示す図である。
【図３】実施の形態1のＤＲＣ実行方法を示すフローチャートである。
【図４】ルール分配の様子を示す図である。
【図５】実施の形態1のＤＲＣ実行装置の他の構成を示す図である。
【図６】本発明の実施の形態２のＤＲＣ実行装置の構成を示す図である。
【図７】実施の形態1のＤＲＣ実行方法を示すフローチャートである。
【符号の説明】
【００６５】
１    検証時間データベース
２    ログファイル記憶部
３    実行制御部
４    検証時間推定部
５    ルール分配部
６    実行スクリプト生成部
７    ＣＰＵ
８    パターン比較部
９    検証ルール判定部
１０    パターンデータ記憶部
１１    検証ルールデータベース
【図１】
2006024125.tif 000003
【図２】
2006024125.tif 000004
【図３】
2006024125.tif 000005
【図４】
2006024125.tif 000006
【図５】
2006024125.tif 000007
【図６】
2006024125.tif 000008
【図７】
2006024125.tif 000009