(57)【要約】【課題】設計品質チェック手法は設計全体の品質を数値化および可視化するのみで、基準となる品質レベルへの達成度を測る方法ではなく、単なるデータベースにとどまっている。また、設計者ごとに機能ブロックの品質レベルの差があり、客観的な評価が困難であった。【解決手段】カテゴリ選択工程１で検証結果ＶＲを分析しチェック対象となるカテゴリを選択し、ＨＤＬ構文チェック工程１９ではＨＤＬの構文チェック基準に基づいて分析し、機能検証チェック工程２０では機能検証チェック基準３ｂに基づいて分析し、物理設計容易化チェック工程２１では物理設計容易化チェック基準３ｃに基づいて分析し、テスト設計容易化チェック工程２２ではテスト設計容易化チェック基準３ｄに基づいて分析し、判定結果格納工程４では前記各チェック工程１９〜２２により判定された結果を品質記録情報として格納する。【選択図】  図１
2004362397.tif 000002
【特許請求の範囲】
【請求項１】
半導体集積回路の設計記述に対する検証結果からその設計記述が設計品質上の一定基準を満たしているかどうかを確認する半導体集積回路における設計品質チェックシステムであって、
前記検証結果を分析しチェック対象となるカテゴリのみを選択するカテゴリ選択工程と、
前記カテゴリ選択工程により選択された検証結果から品質チェック基準に基づいて分析する品質チェック工程と、
前記品質チェック工程により判定された結果を品質記録情報として格納する判定結果格納工程とを備えることを特徴とする半導体集積回路における半導体集積回路における設計品質チェックシステム。
【請求項２】
前記検証結果はハードウェア記述言語の構文チェック結果であり、前記品質チェック工程では、ハードウェア記述言語の構文チェック基準に基づいて分析することを特徴とする請求項１に記載の半導体集積回路における設計品質チェックシステム。
【請求項３】
前記検証結果は設計データの機能検証結果であり、前記品質チェック工程では、機能検証チェック基準に基づいて分析することを特徴とする請求項１に記載の半導体集積回路における設計品質チェックシステム。
【請求項４】
前記検証結果は設計データのタイミング検証結果であり、前記品質チェック工程では、物理設計容易化チェック基準に基づいて分析することを特徴とする請求項１に記載の半導体集積回路における設計品質チェックシステム。
【請求項５】
前記検証結果は設計データの故障検証結果であり、前記品質チェック工程では、テスト設計容易化チェック基準に基づいて分析することを特徴とする請求項１に記載の半導体集積回路における設計品質チェックシステム。
【請求項６】
半導体集積回路の設計記述に対する検証結果からその設計記述が設計品質上の一定基準を満たしているかどうかを確認する半導体集積回路における設計品質チェックシステムであって、
前記検証結果を分析しチェック対象となるカテゴリを選択するカテゴリ選択工程と、
前記カテゴリ選択工程により選択された検証結果から、
ハードウェア記述言語の構文チェック基準に基づいて分析するハードウェア記述言語構文チェック工程と、
機能検証チェック基準に基づいて分析する機能検証チェック工程と、
物理設計容易化チェック基準に基づいて分析する物理設計容易化チェック工程と、
テスト設計容易化チェック基準に基づいて分析するテスト設計容易化チェック工程と、
前記機能検証チェック工程と前記物理設計容易化チェック工程と前記テスト設計容易化チェック工程とにより判定された結果を品質記録情報として格納する判定結果格納工程とを備えることを特徴とする半導体集積回路における設計品質チェックシステム。
【請求項７】
半導体集積回路の設計記述に対する検証結果からその設計記述が設計品質上の一定基準を満たしているかどうかを確認する半導体集積回路における設計品質チェックシステムであって、
前記検証結果を分析しチェック対象となるカテゴリを選択するカテゴリ選択工程と、
重み付け基準に基づいてチェック基準に重み付けを行う工程と、
前記カテゴリ選択工程により選択された検証結果から、
ハードウェア記述言語の重み付け構文チェック基準に基づいて分析するハードウェア記述言語構文チェック工程と、
重み付け機能検証チェック基準に基づいて分析する機能検証チェック工程と、
重み付け物理設計容易化チェック基準に基づいて分析する物理設計容易化チェック工程と、
重み付けテスト設計容易化チェック基準に基づいて分析するテスト設計容易化チェック工程と、
前記機能検証チェック工程と前記物理設計容易化チェック工程と前記テスト設計容易化チェック工程により判定された結果を品質記録情報として格納する判定結果格納工程とを備えることを特徴とする半導体集積回路における設計品質チェックシステム。
【請求項８】
前記機能検証チェック工程と前記物理設計容易化チェック工程と前記テスト設計容易化チェック工程の組み合わせに代えて、前記機能検証チェック工程と前記物理設計容易化チェック工程と前記テスト設計容易化チェック工程のうち少なくとも１つ以上を備えることを特徴とする請求項６または請求項７に記載の半導体集積回路における設計品質チェックシステム。
【請求項９】
前記カテゴリ選択工程では、カテゴリを指定することによりチェック対象を選択することを特徴とする請求項６または請求項７または請求項８に記載の半導体集積回路における設計品質チェックシステム。
【請求項１０】
前記判定結果格納工程により格納された品質記録情報を指定された出力形式に従って出力する判定結果出力工程を備えることを特徴とする請求項１から請求項９までのいずれかに記載の半導体集積回路における設計品質チェックシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は半導体集積回路における設計品質チェックシステムに関するものである。
【０００２】
【従来の技術】
近年のシステムＬＳＩは高機能化、高速化が要望され、プロセスの微細化に伴ってますます大規模化の傾向にある。この大規模なシステムＬＳＩを効率的に開発するために、ＬＳＩを構成する機能ブロックごとに設計者が割り当てられ、機能設計が完了するまで担当する場合が多い。また、機能設計についてはハードウェア記述言語（ＨＤＬ）を用いてレジスタトランスファレベル（ＲＴＬ）で設計することが主流であり、このＲＴＬ設計における完成度が以降の物理設計の開発期間に大きく影響している。従来の設計品質チェック手法としては、設計担当者の口頭によって伝えられることが多く、検証完了報告書等の書面によって伝える場合でも設計品質の客観的な判断ができなかった。また、設計支援システムとして設計データや検証結果をデータベース化して設計全体を統一的に管理しているものもある（例えば、特許文献１参照。）。
【０００３】
【特許文献１】
特開２００１−１８４３８６号公報（第４頁、図１）
【０００４】
【発明が解決しようとする課題】
しかしながら、従来の設計品質チェック手法は設計全体の品質（設計の進捗度や設計内容の評価など）を数値化および可視化するのみであり、基準となる品質レベルへの達成度を測る方法ではないため、単なるデータベースにとどまっている。また、近年の大規模なシステムＬＳＩでは複数の設計担当者が分担して設計する場合が多く、それぞれが担当している機能ブロックの品質レベルの差を客観的にチェックし、把握することができなかった。
【０００５】
本発明は、このような事情に鑑みて創作したものであり、設計全体の効率向上および信頼性の向上を図るべく、各々の機能ブロックの品質レベルを客観的に把握管理できる半導体集積回路における設計品質チェックシステムを提供することを目的としている。
【０００６】
【課題を解決するための手段】
この目的を達成するために、本発明の半導体集積回路における設計品質チェックシステムは、半導体集積回路の設計記述に対する検証結果を分析しチェック対象となるカテゴリのみを選択するカテゴリ選択工程と、前記カテゴリ選択工程により選択された検証結果から品質チェック基準に基づいて分析する品質チェック工程と、前記品質チェック工程により判定された結果を品質記録情報として格納する判定結果格納工程とを備える。
【０００７】
この構成によれば、品質をカテゴリに分類し、それぞれの品質レベルを定めた基準に基づいて検証結果をチェックする。したがって、設計品質チェック対象の複数の機能ブロックの設計データが互いに担当設計者の相違するものであっても、その設計品質についてカテゴリごとに、そのカテゴリに特有のチェック基準を用いて品質チェックを行うので、設計プロジェクトで統一された品質基準を満たしているかどうかをカテゴリごとに客観的に判断することができる。このように、各機能ブロックの品質レベルを客観的に把握管理すれば、設計全体の効率向上および信頼性の向上を図る上で有利となる。
【０００８】
前記カテゴリ選択工程の第１の構成は、前記検証結果はハードウェア記述言語の構文チェック結果であり、前記品質チェック工程では、ハードウェア記述言語の構文チェック基準に基づいて分析することを特徴とする。
【０００９】
これによれば、ハードウエア記述言語の構文チェックツールの出力ファイルを用いて品質基準に基づいたチェックを行うことにより、設計者の異なる機能ブロックのハードウエア記述言語の構文の品質を客観的に判定することが可能となる。
【００１０】
前記カテゴリ選択工程の第２の構成は、前記検証結果は設計データの機能検証結果であり、前記品質チェック工程では、機能検証チェック基準に基づいて分析することを特徴とする。
【００１１】
これによれば、シミュレーション用テストパターンの重要度が定義されているシミュレーション結果ファイルや機能検証ツールの出力ファイルを用いて品質基準に基づいたチェックを行うことにより、設計者の異なる機能ブロックにおける機能完成度の品質を客観的に判定することが可能となる。
【００１２】
前記カテゴリ選択工程の第３の構成は、前記検証結果は設計データのタイミング検証結果であり、前記品質チェック工程では、物理設計容易化チェック基準に基づいて分析することを特徴とする。
【００１３】
これによれば、タイミング推定ツールの出力ファイルを用いて品質基準に基づいたチェックを行うことにより、設計者の異なる機能ブロックの物理設計に対する動作タイミングにおける品質を客観的に判定することが可能となる。なお、物理設計に対する品質は、タイミングに代えて、回路面積、消費電力としてもよい。
【００１４】
前記カテゴリ選択工程の第４の構成は、前記検証結果は設計データの故障検証結果であり、前記品質チェック工程では、テスト設計容易化チェック基準に基づいて分析することを特徴とする。
【００１５】
これによれば、テスト容易化検証ツールの出力ファイルを用いて品質基準に基づいたチェックを行うことにより、設計者の異なる機能ブロックにおけるテスト設計容易化度における品質を客観的に判定することが可能となる。
【００１６】
また、本発明による半導体集積回路における設計品質チェックシステムは、前記検証結果を分析しチェック対象となるカテゴリを選択するカテゴリ選択工程と、前記カテゴリ選択工程により選択された検証結果から、ハードウェア記述言語（ＨＤＬ）の構文チェック基準に基づいて分析するＨＤＬ構文チェック工程と、機能検証チェック基準に基づいて分析する機能検証チェック工程と、物理設計容易化チェック基準に基づいて分析する物理設計容易化チェック工程と、テスト設計容易化チェック基準に基づいて分析するテスト設計容易化チェック工程と、前記機能検証チェック工程と前記物理設計容易化チェック工程と前記テスト設計容易化チェック工程とにより判定された結果を品質記録情報として格納する判定結果格納工程とを備える。
【００１７】
これによれば、検証結果ファイルからどのカテゴリについての検証結果かを自動的に判断し、それぞれのカテゴリについての品質基準に基づいたチェックを行うことにより、設計者の異なる機能ブロックの設計データの設計品質をカテゴリごとに客観的に判定することが可能となる。
【００１８】
上記において、ハードウェア記述言語構文チェック工程では重み付け構文チェック基準に基づいて分析し、機能検証チェック工程では重み付け機能検証チェック基準に基づいて分析し、物理設計容易化チェック工程では重み付け物理設計容易化チェック基準に基づいて分析し、テスト設計容易化チェック工程では重み付けテスト設計容易化チェック基準に基づいて分析するのでもよい。
【００１９】
これによる作用は次のとおりである。近年の大規模システムＬＳＩの開発においては、設計途中段階で並行して次工程である論理合成やレイアウト設計を行う場合が多い。この途中段階で実際の物理設計が可能かどうか、目標チップサイズや動作周波数を満たすかどうかをゲートレベルでより詳細に推定する。物理設計の試行推定段階では必ずしも品質チェック基準をすべて満足する必要はない。そこで、物理設計の試行推定段階において、推定するカテゴリに対する品質基準に重み付けを行うことにより、設計者の異なる機能ブロックの前記試行推定段階における設計データの設計品質をカテゴリごとに客観的に判定することが可能となる。
【００２０】
なお、前記機能検証チェック工程と前記物理設計容易化チェック工程と前記テスト設計容易化チェック工程については、これらのうち少なくとも１つ以上を備えるのでもよい。
【００２１】
また、前記カテゴリ選択工程では、カテゴリを指定することによりチェック対象を選択するように構成することが好ましい。
【００２２】
さらに、前記判定結果格納工程により格納された品質記録情報を指定された出力形式に従って出力する判定結果出力工程を備える構成が好ましい。これによれば、品質記録（分析）情報を任意に引き出すことができる。
【００２３】
【発明の実施の形態】
以下、本発明の一実施形態における半導体集積回路における設計品質チェックシステムについて図面を参照しながら説明する。
【００２４】
図１は本発明の半導体集積回路における設計品質チェックシステムの概略フロー図である。
【００２５】
図１において、検証結果ＶＲをカテゴリ選択工程１に入力することにより、チェックするカテゴリの検証結果ＶＲのみが選択される。
【００２６】
品質チェック工程２では、対象となるチェック項目ごとに、カテゴリごとのチェック基準３に基づいて基準の達成度合いを判定する。
【００２７】
判定結果格納工程４では、それぞれの基準の達成度合いの判定結果が判定結果５に格納され、判定結果出力工程６から結果が出力される。
【００２８】
（第１の実施形態）
カテゴリ選択工程１に入力する検証結果ＶＲがハードウェア記述言語（ＨＤＬ）の構文チェック結果ＶＲ１の場合について図２を用いて詳細に説明する。
【００２９】
図２において、検証結果としての構文チェック結果ＶＲ１はＨＤＬの構文チェックツールの出力ファイルである。前記出力ファイルは、エラー番号またはワーニング番号に対する内容のメッセージおよびＲＴＬの修正箇所に関する情報が示されている。さらに、前記出力ファイルは構文チェック結果ＶＲ１であることを明示するために、ファイルの拡張子が定められている（例えば“．ｌｉｎｔ”）。
【００３０】
カテゴリ選択工程１にて、入力された検証結果ファイルの拡張子が“．ｌｉｎｔ”でなければエラーと判断する。前記検証結果ファイルの拡張子が“．ｌｉｎｔ”であれば、品質チェック工程２にてチェック基準３の１つであるＨＤＬ構文チェック基準３ａに基づいて品質がチェックされる。前記品質チェック工程２は、エラー番号チェック工程７、ワーニング番号チェック工程８、エラー数チェック工程９およびワーニング数チェック工程１０で構成されている。
【００３１】
前記ＨＤＬ構文チェック基準３ａは、文法的に不適切な記述や論理合成できない記述、論理合成後のネットリストによるシミュレーションで期待値が異なる可能性がある記述に対して、それぞれのエラー番号と修正の重要度が定義されている。また、可読性を下げる記述や論理合成後の物理設計ツールによっては修正しておいた方がよいと推測される記述に対してはワーニングとし、重要度も低く設定されている。重要度は数字で示されている（例えば、エラー番号１は重要度５、エラー番号３は重要度３、ワーニング番号８は重要度１）。更に、前記ＨＤＬ構文チェック基準３ａには、ＲＴＬの品質レベルを示す修正重要度、エラー数、ワーニング数に対する基準値も定義されている。例えば、修正重要度は２０以下、エラー数は３以下、ワーニング数は３０以下である。
【００３２】
前記エラー番号チェック工程７では、ＨＤＬ構文チェック基準３ａに基づいて重要度が定義されているエラー番号を抽出し、重要度の数値を掛け算して合計の修正重要度を算出する。
【００３３】
前記ワーニング番号チェック工程８では、同様にワーニング番号を抽出し、重要度の数値を掛け算して合計の修正重要度を算出する。エラーに対する修正重要度とワーニングに対する修正重要度の算出結果を前記ＨＤＬ構文チェック基準３ａに定義されている修正重要度の品質基準値と比較し、未達であれば、ＮＧの判定と算出情報を品質記録情報として保持する。
【００３４】
次に、エラー数チェック工程９では、前記構文チェック結果ＶＲ１のエラー番号を抽出し、合計数を算出する。ワーニング数チェック工程１０でも同様にワーニング番号を抽出し、合計数を算出する。エラー数およびワーニング数の算出結果を前記ＨＤＬ構文チェック基準３ａに定義されているそれぞれの品質基準値と比較し、同様に未達であれば、ＮＧの判定と算出情報を品質記録情報として保持する。
【００３５】
判定結果格納工程４では、前記品質チェック工程２で分析チェックされた判定結果と品質記録情報を判定結果５に格納する。
【００３６】
判定結果出力工程６では、判定結果５から情報を抽出して品質基準に対するＯＫまたはＮＧの判定結果を出力し、前記品質チェック工程２で分析チェックされた品質記録情報を出力する。
【００３７】
本システムでは、ＨＤＬの構文チェックツールの出力ファイルを用いて品質基準に基づいたチェックを行うことにより、設計者の異なる機能ブロックのＨＤＬ構文の品質を客観的に判定することが可能となる。
【００３８】
（第２の実施形態）
カテゴリ選択工程１に入力する検証結果ＶＲが設計データの機能検証結果ＶＲ２の場合について図３を用いて詳細に説明する。
【００３９】
図３において、検証結果としての機能検証結果ＶＲ２は機能検証ツールによる検証結果ファイルである。シミュレーション用の検証パターン番号と機能検証結果ＶＲ２、検証パターンの重要度、シミュレーションに対するＨＤＬ記述の活性度に関する情報が示されている。前記検証結果ファイルは、検証パターン番号と機能検証結果ＶＲ２が判別できればツールの出力ファイルでもよいし、検証パターンに対する重要度を示す情報やＨＤＬ記述の活性度を示す情報は別ファイルでもよい。検証ツールによるカバレッジ情報が示されていればツールの出力ファイルそのままでもよい。さらに、前記シミュレーション結果を示すファイルは機能検証結果ＶＲ２であることを明示するために、ファイルの拡張子が定められている（例えば“．ｆｕｎｃ”）。
【００４０】
カテゴリ選択工程１にて、入力された検証結果ファイルの拡張子が“．ｆｕｎｃ”でなければエラーと判断する。前記検証結果ファイルの拡張子が“．ｆｕｎｃ”であれば、品質チェック工程２にてチェック基準３の１つである機能検証チェック基準３ｂに基づいて品質がチェックされる。前記品質チェック工程２は、ダイナミックテストカバレッジチェック工程１１、スタティックテストカバレッジチェック工程１２およびソースコードカバレッジチェック工程１３で構成されている。
【００４１】
前記機能検証チェック基準３ｂは、ダイナミックテスト（例えば、テストベンチとテストパターンを作成し、動作シミュレーションを実行して仕様どおりに動作するかを検証する）に関するカバレッジ基準とスタティックテスト（例えば、ＲＴＬ記述中に動作の振る舞いを表現した記述を加えることにより、論理的に仕様どおりに動作するかを検証する）に関するカバレッジ基準およびＲＴＬのソースコードに関するカバレッジ基準が定義されている。ダイナミックテストのカバレッジ基準、スタティックテストのカバレッジ基準およびソースコードのカバレッジ基準はそれぞれ数字で示されている。例えば、ダイナミックテストカバレッジ基準は９５％、スタティックテストカバレッジ基準は１００％、ソースコードカバレッジ基準は９８％以上である。
【００４２】
前記ダイナミックテストカバレッジチェック工程１１では、機能検証チェック基準３ｂに基づいて、全テストパターンの重要度の総計に対するシミュレーションが行われたテストパターンに定義されている重要度の数値を掛けた値の合計値の比率からダイナミックテストにおけるカバレッジを算出する。シミュレーション実行用に準備されているすべてのテストパターンを実行し、すべてのシミュレーション結果がＯＫであればカバレッジは１００％である。また、シミュレーションツールでカバレッジが算出できるのであれば、シミュレーション結果ファイルからカバレッジの値を抽出して、その値をダイナミックテストカバレッジ基準と比較し、ＯＫ／ＮＧの判定とカバレッジ値を品質情報として保持する。
【００４３】
次に、スタティックテストカバレッジチェック工程１２では、スタティック検証ツールの検証結果ファイルからカバレッジの値を抽出して、同様にその値を比較し、ＯＫ／ＮＧの判定とカバレッジ値を品質情報として保持する。
【００４４】
次に、ソースコードカバレッジチェック工程１３では、同様にソースコードカバレッジ検証ツールの結果ファイルからカバレッジの値を抽出して、ＯＫ／ＮＧの判定とカバレッジ値を品質情報として保持する。
【００４５】
判定結果格納工程４では、前記品質チェック工程２で分析チェックされた判定結果と品質記録情報を判定結果５に格納する。
【００４６】
判定結果出力工程６では、判定結果５から情報を抽出して品質基準に対するＯＫまたはＮＧの判定結果を出力し、前記品質チェック工程２で分析チェックされた品質記録情報を出力する。
【００４７】
本システムでは、シミュレーション用テストパターンの重要度が定義されているシミュレーション結果ファイルや機能検証ツールの出力ファイルを用いて品質基準に基づいたチェックを行うことにより、設計者の異なる機能ブロックにおける機能完成度の品質を客観的に判定することが可能となる。
【００４８】
（第３の実施形態）
カテゴリ選択工程１に入力する検証結果ＶＲが設計データのタイミング検証結果ＶＲ３の場合について図４を用いて詳細に説明する。
【００４９】
図４において、検証結果としてのタイミング検証結果ＶＲ３はＲＴレベルのタイミング推定ツールの出力ファイルである。前記出力ファイルは、目標動作周波数に対してタイミングエラーが発生するパスとタイミングエラー値に関する情報が示されている。更に、前記出力ファイルはタイミング検証結果ＶＲ３であることを明示するために、ファイルの拡張子が定められている（例えば“．ｔｉｍ”）。
【００５０】
カテゴリ選択工程１にて、入力された検証結果ファイルの拡張子が“．ｔｉｍ”でなければエラーと判断する。前記検証結果ファイルの拡張子が“．ｔｉｍ”であれば、品質チェック工程２にてチェック基準３の１つである物理設計容易化チェック基準３ｃに基づいて品質がチェックされる。前記品質チェック工程２は、エラー値チェック工程１４とエラーパス数チェック工程１５で構成されている。
【００５１】
前記物理設計容易化チェック基準３ｃは、論理合成以降の物理設計の段階で特にタイミングが目標動作周波数を満たすために、ＲＴＬ設計の段階でどれくらいの値になればよいかの許容値が定義されている。ＲＴレベルのタイミング推定ツールは、実際の論理合成後のゲートレベルでのタイミング検証に比べて精度が劣るため、推定結果の値に必ず誤差が含まれる。この誤差をどれくらいの割合まで容認するかが基準値として定義されている。更に目標動作周波数に対するタイミングエラーが発生するパスの個数についても定義されている。例えば、タイミングエラー値は目標動作周波数の２０％以下、エラーパス数は１００以下である。あるいは、タイミングエラー値が目標動作周波数の２０％以下であるパス数が５０以下である。
【００５２】
前記エラー値チェック工程１４では、タイミングエラーが発生するパスのエラー値を抽出し、それぞれのエラー値を前記物理設計容易化チェック基準３ｃに定義されている品質基準値と比較し、基準を超えているパスが存在すれば、ＮＧの判定とそれぞれのパスのエラー値を品質記録情報として保持する。
【００５３】
次に、エラーパス数チェック工程１５では、タイミングエラーが発生しているパスの数の合計値を算出し、同様に前記物理設計容易化チェック基準３ｃのタイミングエラーパス数の基準値と比較する。また、目標動作周波数の基準を超えたエラーパス数の合計を算出し、同様に前記物理設計容易化チェック基準３ｃの基準値と比較する。基準に未達であれば、ＮＧの判定と算出情報を品質記録情報として保持する。
【００５４】
判定結果格納工程４では、前記品質チェック工程２で分析チェックされた判定結果と品質記録情報を判定結果５に格納する。
【００５５】
判定結果出力工程６では、判定結果５から情報を抽出して品質基準に対するＯＫまたはＮＧの判定結果を出力し、前記品質チェック工程２で分析チェックされた品質記録情報を出力する。
【００５６】
本システムでは、ＲＴレベルのタイミング推定ツールの出力ファイルを用いて品質基準に基づいたチェックを行うことにより、設計者の異なる機能ブロックの物理設計に対する品質（本実施例では動作タイミングにおける品質）を客観的に判定することが可能となる。
【００５７】
なお、ＲＴレベルで推定する物理設計に対する品質は、回路面積、消費電力の算出結果も基準として定義してもよい。
【００５８】
（第４の実施形態）
カテゴリ選択工程１に入力する検証結果ＶＲが設計データの故障検証結果ＶＲ４の場合について図５を用いて詳細に説明する。
【００５９】
図５において、検証結果としての故障検証結果ＶＲ４はＲＴレベルのテスト容易化検証ツールの出力ファイルである。前記出力ファイルは、故障検出率を下げる要因となる回路構成に対して、エラー番号またはワーニング番号とその内容のメッセージおよびＲＴＬの修正箇所が示されている。また、前記出力ファイルには、故障検出率の値も示されている。更に、前記出力ファイルは故障検証結果ＶＲ４であることを明示するために、ファイルの拡張子が定められている（例えば“．ｆａｕｌｔ”）。
【００６０】
カテゴリ選択工程１にて、入力された検証結果ファイルの拡張子が“．ｆａｕｌｔ”でなければエラーと判断する。前記検証結果ファイルの拡張子が“．ｆａｕｌｔ”であれば、品質チェック工程２にてチェック基準３の１つであるテスト設計容易化チェック基準３ｄに基づいて品質がチェックされる。前記品質チェック工程２は、エラー数チェック工程１６、ワーニング数チェック工程１７および故障検出率チェック工程１８で構成されている。
【００６１】
前記テスト設計容易化チェック基準３ｄは、回路の故障を検出できない可能性のある記述に対して、エラー番号と修正の重要度が定義されている。また、論理合成後の回路では必ず回路故障を検出できない記述に対してはエラーとし、合成ツールやゲートレベルでのテスト設計支援ツールに依存するような記述に対してはワーニングとして示されている。更に、前記テスト設計容易化チェック基準３ｄには、ＲＴＬの品質レベルを示すエラー数、ワーニング数に対する基準値、故障検出率に対する基準値も定義されている。例えば、エラー数は０、ワーニング数は１０以下、故障検出率は９５％以上である。
【００６２】
前記エラー数チェック工程１６では、前記故障検証結果ＶＲ４のエラー番号を抽出し、合計数を算出する。
【００６３】
ワーニング数チェック工程１７では、同様にワーニング番号を抽出し、合計数を算出する。エラー数およびワーニング数の算出結果を前記テスト設計容易化チェック基準３ｄに定義されているそれぞれの品質基準値と比較し、未達であれば、ＮＧの判定と算出情報を品質記録情報として保持する。
【００６４】
故障検出率チェック工程１８では、前記故障検証結果ＶＲ４から故障検出率の値を抽出して、その値を故障検出率の基準値と比較し、ＯＫ／ＮＧの判定と故障検出率の値を品質情報として保持する。
【００６５】
判定結果格納工程４では、前記品質チェック工程２で分析チェックされた判定結果と品質記録情報を判定結果５に格納する。
【００６６】
判定結果出力工程６では、判定結果５から情報を抽出して品質基準に対するＯＫまたはＮＧの判定結果を出力し、前記品質チェック工程２で分析チェックされた品質記録情報を出力する。
【００６７】
本システムでは、ＲＴレベルのテスト容易化検証ツールの出力ファイルを用いて品質基準に基づいたチェックを行うことにより、設計者の異なる機能ブロックにおけるテスト設計容易化度における品質を客観的に判定することが可能となる。
【００６８】
（第５の実施形態）
次に、カテゴリごとに品質チェック工程２を複数備えている設計品質チェックシステムについて説明する。図６は本発明のカテゴリごとに品質チェック工程２を複数備えている半導体集積回路における設計品質チェックシステムの概略フロー図である。
【００６９】
図６において、検証結果ＶＲをカテゴリ選択工程１に入力することにより、チェックするカテゴリの検証結果ＶＲが選択される。
【００７０】
品質チェック工程２では、対象となるカテゴリに対してチェック工程があり、カテゴリごとのチェック基準３に基づいて基準の達成度合いを判定する。
【００７１】
判定結果格納工程４では、それぞれの基準の達成度合いの判定結果が判定結果５に格納されると共に判定結果出力工程６から結果が出力される。
【００７２】
前記品質チェック工程２は、ＨＤＬ構文チェック工程１９、機能検証チェック工程２０、物理設計容易化チェック工程２１およびテスト設計容易化チェック工程２２で構成されている。
【００７３】
図６において、検証結果ＶＲについては、ＨＤＬの構文チェックツールの出力ファイル、機能検証ツールによる検証結果ファイル、ＲＴレベルのタイミング推定ツールの出力ファイル、ＲＴレベルのテスト容易化検証ツールの出力ファイルのいずれかである。本発明の第１から第４の実施形態にて説明したように、それぞれの検証結果ファイルはカテゴリごとに拡張子が異なっている。
【００７４】
前記カテゴリ選択工程１では、検証結果ファイルの拡張子からどのカテゴリの検証結果ＶＲかを判断し、それぞれのカテゴリに対応したチェック工程に選択分類される。
【００７５】
例えば、検証結果ＶＲがＨＤＬの構文チェック結果ＶＲ１の場合では、検証結果ファイルの拡張子が“．ｌｉｎｔ”なので、ＨＤＬ構文チェック工程１９に振り分けられる。前記ＨＤＬ構文チェック工程１９は図２に示すエラー番号チェック工程７、ワーニング番号チェック工程８、エラー数チェック工程９およびワーニング数チェック工程１０で構成されている。それぞれのチェック工程では、チェック基準３の１つであるＨＤＬ構文チェック基準３ａに基づいて品質がチェックされる。詳細な動作は、前述した第１の実施形態に示している。
【００７６】
判定結果格納工程４では、前記品質チェック工程２で分析チェックされた判定結果と品質記録情報を判定結果５に格納する。
【００７７】
判定結果出力工程６では、判定結果５から情報を抽出して品質基準に対するＯＫまたはＮＧの判定結果を出力し、前記品質チェック工程２で分析チェックされた品質記録情報を出力する。
【００７８】
本システムでは、検証結果ファイルの拡張子からどのカテゴリについての検証結果ＶＲかを自動的に判断し、それぞれのカテゴリについての品質基準に基づいたチェックを行うことにより、設計者の異なる機能ブロックのＲＴＬデータの設計品質をカテゴリごとに客観的に判定することが可能となる。
【００７９】
（第６の実施形態）
さらに、図７を用いて、重み付け基準２３に基づいて重み付けを行う重み付け工程２４を備えている半導体集積回路における設計品質チェックシステムについて説明する。
【００８０】
本実施形態は、第５の実施形態で説明した設計品質チェックシステムに重み付け基準２３と重み付け工程２４が付加されている。
【００８１】
重み付け工程２４において、カテゴリごとの重み付け基準２３に基づいてチェック基準に対し重み付けを行う。重み付け基準２３は、目標とするＲＴＬの品質に対して、カテゴリに対する重要度の割合が定義されている。例えば、ＨＤＬ構文チェック基準３ａに対する重み付けが８０％で、ＨＤＬ構文チェック基準３ａにＲＴＬの品質レベルを示す修正重要度は２０以下、エラー数は３以下、ワーニング数は３０以下と定義されている場合は、前記重み付け工程２４によりＨＤＬ構文チェック基準３ａの修正重要度は（２０÷８０％＝２５）で２５以下、エラー数は（３÷８０％＝３．７５）で４以下、ワーニング数は（３０÷８０％＝３７．５）で３８以下に設定される。検証結果ＶＲは、前記重み付け工程２４において重み付けされた新たなチェック基準３に基づいて、前記ＨＤＬ構文チェック工程１９にて品質がチェックされる。詳細な動作は、前述した第１および第５の実施形態に示している。
【００８２】
判定結果格納工程４では、前記品質チェック工程２で分析チェックされた判定結果と品質記録情報を判定結果５に格納する。
【００８３】
判定結果出力工程６では、判定結果５から情報を抽出して品質基準に対するＯＫまたはＮＧの判定結果を出力し、前記品質チェック工程２で分析チェックされた品質記録情報を出力する。
【００８４】
近年の大規模システムＬＳＩの開発において、ＲＴＬ設計の途中段階でＲＴＬ設計と並行して次工程である論理合成やレイアウト設計を行う場合が多い。この途中段階のＲＴＬを用いて実際の物理設計が可能かどうか、目標チップサイズや動作周波数を満たすかどうかをゲートレベルでより詳細に推定する。ＲＴＬ設計の完了時点では品質チェック基準をすべて満足していなければならないが、物理設計の試行推定段階では必ずしも品質チェック基準をすべて満足する必要はない。
【００８５】
本システムでは、物理設計の試行推定段階において、推定するカテゴリに対する品質基準に重み付けを行うことにより、設計者の異なる機能ブロックの前記試行推定段階におけるＲＴＬデータの設計品質をカテゴリごとに客観的に判定することが可能となる。
【００８６】
【発明の効果】
以上のように本発明によれば、品質をカテゴリに分類し、それぞれの品質レベルを定めた基準に基づいて検証結果をチェックするので、設計品質チェック対象の複数の機能ブロックが互いに担当設計者の相違するものであっても、その設計データの品質について、カテゴリごとに、そのカテゴリに特有のチェック基準を用いて品質チェックを行うことから、設計プロジェクトで統一された品質基準を満たしているかどうかをカテゴリごとに客観的に判断することができる。また、品質分析情報を任意に引き出すことができる。このように、各機能ブロックの品質レベルを客観的に把握管理すれば、設計全体の効率向上および信頼性の向上を図る上で有利となる。
【図面の簡単な説明】
【図１】本発明の半導体集積回路における設計品質チェックシステムの概略フロー図
【図２】本発明の第１の実施形態における半導体集積回路における設計品質チェックシステムのフロー図
【図３】本発明の第２の実施形態における半導体集積回路における設計品質チェックシステムのフロー図
【図４】本発明の第３の実施形態における半導体集積回路における設計品質チェックシステムのフロー図
【図５】本発明の第４の実施形態における半導体集積回路における設計品質チェックシステムのフロー図
【図６】本発明の第５の実施形態における半導体集積回路における設計品質チェックシステムのフロー図
【図７】本発明の第６の実施形態における半導体集積回路における設計品質チェックシステムのフロー図
【符号の説明】
１  カテゴリ選択工程
２  品質チェック工程
３  チェック基準
３ａ  ＨＤＬ構文チェック基準
３ｂ  機能検証チェック基準
３ｃ  物理設計容易化チェック基準
３ｄ  テスト設計容易化チェック基準
４  判定結果格納工程
５  判定結果
６  判定結果出力工程
７  エラー番号チェック工程
８  ワーニング番号チェック工程
９  エラー数チェック工程
１０  ワーニング数チェック工程
１１  ダイナミックテストカバレッジチェック工程
１２  スタティックテストカバレッジチェック工程
１３  ソースコードカバレッジチェック工程
１４  エラー値チェック工程
１５  エラーパス数チェック工程
１６  エラー数チェック工程
１７  ワーニング数チェック工程
１８  故障検出率チェック工程
１９  ＨＤＬ構文チェック工程
２０  機能検証チェック工程
２１  物理設計容易化チェック工程
２２  テスト設計容易化チェック工程
２３  重み付け基準
２４  重み付け工程
ＶＲ  検証結果
ＶＲ１  構文チェック結果
ＶＲ２  機能検証結果
ＶＲ３  タイミング検証結果
ＶＲ４  故障検証結果
【図１】
2004362397.tif 000003
【図２】
2004362397.tif 000004
【図３】
2004362397.tif 000005
【図４】
2004362397.tif 000006
【図５】
2004362397.tif 000007
【図６】
2004362397.tif 000008
【図７】
2004362397.tif 000009