以下、実施形態の一例について図面を参照しつつ説明する。
[第1実施形態]
最初に、第1実施形態について説明する。第1実施形態では、ハードウェアIPを用いたチップの設計・検証作業の効率化を図る方法について説明する。
まず、ハードウェアIPの流通システムの一例について、ハードウェアIPのデータをチップ設計者に開示可能な場合と開示不可能な場合とに分けて説明する。
図1は、ハードウェアIPのデータをチップ設計者に開示することが可能な場合の流通システムの一例を示している。ハードウェアIPは、回路ブロックの機能単位でまとめられた、レイアウトデータ、ネットリスト、機能記述データなどのデータである。
ハードウェアIPのデータをチップ設計者に開示可能な場合には、IPプロバイダは、当該ハードウェアIPをチップ設計者に提供する。図1に示す例では、IPプロバイダA、BがハードウェアIP10A、10Bをチップ設計者に提供している。チップ設計者は、これらのハードウェアIP10A、10Bを用いてチップ設計を行う。例えば、チップ設計者は、ハードウェアIP10A、10Bのそれぞれのレイアウトデータを用いてチップのレイアウト設計を行い、チップのレイアウトデータ(以下、「チップレイアウトデータ」と称する)を作成する。この他にも、例えば、チップ設計者は、ハードウェアIP10A、10Bのそれぞれのネットリストを用いて、チップのネットリスト(以下、「チップネットリスト」と称する)を作成する。以下では、これらのチップレイアウトデータやチップネットリストなどのチップの設計データをまとめて「チップ設計データ」と称することとする。つまり、チップ設計者は、ハードウェアIP10A、10Bを用いてチップ設計を行うことで、チップ設計データPBDを作成する。
チップ設計者は、チップ設計で生成されたチップ設計データPBDに対し、EDA(Electronic Design Automation)などの設計検証装置を用いてデータ検証を行う。具体的には、チップ設計者は、チップ設計データPBD、チップの製造業者により提供されたコントロールファイル20を設計検証装置に入力する。コントロールファイル20には、データ検証の処理や判定基準などが記述されている。設計検証装置は、コントロールファイル20に従って、チップ設計データPBDに対してデータ検証を実施して、検証結果を出力する。データ検証としては、例えば、DRC(design rule checking)、LVS(layout versus schematic)やDFM(design for manufacturability)などの検証が挙げられる。DRC検証は、チップレイアウトデータがデザインルールを満足しているか否かを検証するものである。LVS検証は、チップレイアウトデータより導き出される回路データが論理回路設計段階において設計された回路データと一致しているか否かを検証するものである。DFM検証は、チップ設計データを基にチップが容易に製造可能か否かを検証するものである。設計検証装置は、これらの検証データにおける検証基準をチップ設計データPBDが満足しているか否かを検証して、その検証結果を出力する。
チップ設計者は、検証結果を基に、チップ設計データPBDが検証基準を満足していると判定した場合には、チップ設計データPBDを製造業者に出荷する。製造業者は、チップ設計データPBDをチップ設計者より受け入れる。
図1では、ハードウェアIPのデータをチップ設計者に開示することが可能な場合の流通システムについて示した。これに対し、IPプロバイダは、ハードウェアIPのデータをチップ設計者に開示したくない場合がある。この場合の流通システムの一例について図2を用いて説明する。
図2は、ハードウェアIPのデータをチップ設計者に開示不可能な場合の流通システムの一例を示している。
ハードウェアIPのデータをチップ設計者に開示不可能な場合には、IPプロバイダは、ハードウェアIPをボックス化したボックスIPをチップ設計者に供給する。ここで、ボックス化とは、ハードウェアIPのデータのうち、チップ設計者に開示可能なデータを抽出することである。つまり、IPプロバイダは、ハードウェアIPのデータのうち、チップ設計者に開示可能なデータを抽出し、抽出した開示可能なデータをボックスIPとしてチップ設計者に供給する。ここで、ボックスIPの作成方法の一例について図3を用いて説明する。
図3に示すように、ハードウェアIP10のレイアウトデータ10aより、例えば、開示可能な端子レイアウトの情報が抽出され、抽出された端子レイアウトの情報がボックスIP11のレイアウトデータ11aとされる。以下では、ボックスIP11のレイアウトデータを「ボックスレイアウトデータ」と称することとする。また、ハードウェアIP10のネットリスト10bより、例えば、端子の種別を示す識別子などの端子情報が抽出され、抽出された端子情報がボックスIP11のネットリストとされる。以下では、ボックスIP11のネットリストを「ボックスネットリスト」と称することとする。また、ハードウェアIP10の機能記述データ10cは、例えば、そのままボックスIP11の機能記述データたるボックス機能記述データ11cとされる。このように、ハードウェアIPの各データにおけるチップ設計者に開示可能なデータがボックスIPの各データとされる。
図2に戻り説明を続けると、IPプロバイダA、Bは、ハードウェアIP10A、10Bをボックス化してボックスIP11A、11Bを作成し、ボックスIP11A、11Bをチップ設計者に供給する。
チップ設計者は、これらのボックスIP11A、11Bを用いてチップ設計を行うことで、チップ設計データBCDを作成する。後に詳しく述べるが、例えば、チップ設計者は、ボックスIP11A、11Bのそれぞれのボックスレイアウトデータを用いてチップのレイアウト設計を行い、チップのレイアウトデータであるチップレイアウトデータを作成する。また、チップ設計者は、ボックスIP11A、11Bのそれぞれのボックスネットリストを用いて、チップのネットリストであるチップネットリストを作成する。
チップ設計者は、チップ設計で生成されたチップ設計データBCDに対し、設計検証装置を用いてデータ検証を行う。具体的には、図1で述べたのと同様、設計検証装置は、チップの製造業者により提供されたコントロールファイル20に従い、チップ設計データBCDに対し、DRC、LVS、DFMといったデータ検証を行う。チップ設計者は、データ検証の結果を基に、チップ設計データBCDが検証基準を満足していると判定した場合には、チップ設計データBCDを製造業者に出荷する。
製造業者は、IPプロバイダA、BよりハードウェアIP10A、10Bを受け入れている。製造業者は、チップ設計データBCDをチップ設計者より受け入れると、チップ設計データBCD中のボックスIP11A、11BをハードウェアIP10A、10Bに置き換えたチップ設計データHCDを作成する。そして、製造業者は、チップ設計データHCDに対し、再度、設計検証装置を用いてデータ検証を行う。具体的には、設計検証装置は、コントロールファイル20に従い、チップ設計データHCDに対し、DRC、LVS、DFMといったデータ検証を行う。製造業者は、データ検証の結果、チップ設計データHCDが検証基準を満足していると判定した場合には、チップ設計データHCDを基にチップの製造を開始する。
次に、図2に示した流通システムにおける設計・検証作業の流れについて図4を用いて詳細に説明する。図4は、図2に示した流通システムにおける設計・検証作業の流れの一例を示す図である。
なお、以下では、ハードウェアIP10Aのレイアウトデータ、ネットリストをそれぞれ、レイアウトデータ10aA、ネットリスト10bAと称する。また、ボックスIP11Aのボックスレイアウトデータ、ボックスネットリストをそれぞれ、ボックスレイアウトデータ11aA、ボックスネットリスト11bAと称する。ボックスレイアウトデータ11aAは、レイアウトデータ10aAの開示可能なデータが抽出されたものであり、ボックスネットリスト11bAは、ネットリスト10bAの開示可能なデータが抽出されたものである。
また、ハードウェアIP10Bのレイアウトデータ、ネットリストをそれぞれ、レイアウトデータ10aB、ネットリスト10bBと称する。また、ボックスIP11Bのボックスレイアウトデータ、ボックスネットリストをそれぞれ、ボックスレイアウトデータ11aB、ボックスネットリスト11bBと称する。ボックスレイアウトデータ11aBは、レイアウトデータ10aBの開示可能なデータが抽出されたものであり、ボックスネットリスト11bBは、ネットリスト10bBの開示可能なデータが抽出されたものである。
図4に示すように、作業の流れとしては、チップ設計、チップ設計者によるデータ検証、IP置き換え、製造業者によるデータ検証の順に行われる。以下、順に説明する。
チップ設計段階では、チップ設計者は、ボックスIP11A、IP11Bを用いて、チップ設計データBCDを作成する。例えば、チップ設計者は、ボックスIP11Aのボックスレイアウトデータ11aAと、ボックスIP11Bのボックスレイアウトデータ11aBとを用いて、チップのレイアウト設計を行い、チップレイアウトデータBLAを作成する。また、チップ設計者は、ボックスIP11Aのボックスネットリスト11bAと、ボックスIP11Bのボックスネットリスト11bBとを用いて、チップの回路データであるチップネットリストBNLを作成する。
チップ設計者によるデータ検証段階では、チップ設計者は、チップ設計段階で作成されたチップ設計データBCDについて、設計検証装置を用いてデータ検証を行う。具体的には、設計検証装置は、コントロールファイル20に記載された処理に従って、チップ設計データBCDについて、DRC、LVS、DFMといったデータ検証の処理を行う。設計検証装置は、このデータ検証の結果をハードウェアIPに対する検証結果30として出力する。チップ設計者は、出力された検証結果30を検討して、チップ設計データBCDを製造業者に出荷するか否かについて判定する。
ここで、設計検証装置の具体的なハードウェア構成について説明する。図5は、設計検証装置の一例である設計検証装置100の構成を示す構成図である。
図5に示すように、設計検証装置100は、例えばPC(Personal Computer)などのコンピュータであり、CPU(Central Processing Unit)81、ROM(Read Only Memory)82、RAM(Random Access Memory)83、ハードディスク84を有する。また、設計検証装置は、出力装置85、入力装置86、インターフェース87及びディスクドライブ88を有する。これらの構成要素は、バス80に接続されている。出力装置85は、例えばモニタやプリンタなどの出力装置であり、入力装置86は、例えばマウスやキーボードなどの入力装置である。インターフェース87は、例えばUSB(Universal Serial Bus)などの外部接続インターフェースである。ディスクドライブ88は、例えばDVD(Digital Versatile Disc)などのディスクを駆動させるためのディスクドライブである。CPU81がROM81に記憶されたプログラムを実行することによりデータ検証が実施される。
チップ設計者によるデータ検証段階における設計検証装置100の具体的な動作としては、まず、チップ設計データBCD及びコントロールファイル20が、インターフェース17などを介して設計検証装置100に入力される。そして、ROM81に記憶されたプログラムが実行されると、CPU81は、コントロールファイル20に記載された処理に従って、チップ設計データBCDについて、DRC、LVS、DFMといったデータ検証処理を行う。CPU11は、このデータ検証の結果をボックスIPに対する検証結果30として出力装置85に出力する。
IP置き換え段階では、製造業者は、チップ設計データBCDをチップ設計者より受け取り、受け取ったチップ設計データBCD中のボックスIP11A、11BをハードウェアIP10A、10Bに置き換えてチップ設計データHCDを作成する。例えば、製造業者は、チップレイアウトデータBLAにおけるボックスレイアウトデータをハードウェアIPのレイアウトデータに置き換えてチップレイアウトデータLAを作成する。具体的には、このとき、ボックスレイアウトデータ11aAは、ハードウェアIP10Aのレイアウトデータ10aAに置き換えられ、ボックスレイアウトデータ11aBは、ハードウェアIP10Bのレイアウトデータ10aBに置き換えられる。また、製造業者は、チップネットリストBNAにおけるボックスネットリストをハードウェアIPのネットリストに置き換えてチップネットリストNLを作成する。具体的には、このとき、ボックスネットリスト11bAが、ハードウェアIP10Aのネットリスト10bAに置き換えられ、ボックスネットリスト11bBが、ハードウェアIP10Bのネットリスト10bBに置き換えられる。
製造業者によるデータ検証段階では、製造業者は、IP置き換えが行われたチップ設計データHCDについて、設計検証装置を用いてデータ検証を行う。
具体的には、チップ設計者によるデータ検証の場合と同様、製造業者は、チップ設計データHCD及びコントロールファイル20を設計検証装置に入力する。そして、チップ設計者によるデータ検証のときと同様、設計検証装置は、コントロールファイル20に記載された処理に従って、チップ設計データHCDについて、DRC、LVS、DFMといったデータ検証の処理を行う。設計検証装置は、このデータ検証の結果をハードウェアIPに対する検証結果31として出力する。製造業者は、検証結果31を基に、チップ設計データHCDが検証基準を満足していると判定した場合には、チップ設計データHCDを基にチップの製造を開始する。
上述したことから分かるように、データ検証は、ボックスIP11A、11Bが用いられたチップ設計データBCDに対して行われる場合と、ハードウェアIP10A、10Bに置き換えられたチップ設計データHCDに対して行われる場合とがある。
次に、上述の設計・検証作業の流れについて図6に示すフローチャートを用いて説明する。図6は、上述の設計・検証作業の流れを示すフローチャートである。
まず、ステップS101において、チップ設計段階として、チップ設計者は、ボックスIPを用いてチップ設計データBCDを作成する。
ステップS102において、チップ設計者によるデータ検証段階として、チップ設計者は、チップ設計データBCDについて、設計検証装置を用いてDRC,LVS,DFMといったデータ検証を行い、ボックスIPに対する検証結果30を求める。
ステップS103において、チップ設計者は、ボックスIPに対する検証結果30を検討して、製造業者に出荷するか否かについて判定する。チップ設計者は、データ検証の結果、チップ設計データBCDが検証基準を満足していると判定した場合には、チップ設計データBCDを製造業者に出荷する(ステップS103:OK)。一方、チップ設計者は、チップ設計データBCDが検証基準を満足していないと判定した場合には、チップ設計に問題があるとして、チップ設計データBCDを出荷せずに(ステップS103:NG)、ステップS101のチップ設計に戻る。
ステップS104において、製造業者は、チップ設計データBCDをチップ設計者より受け入れる。続くステップS105において、IP置き換え段階として、製造業者は、チップ設計データBCD中のボックスIPをハードウェアIPに置き換えることでチップ設計データHCDを作成する。
ステップS106において、製造業者によるデータ検証段階として、製造業者は、チップ設計データHCDについて、設計検証装置を用いてDRC,LVS,DFMといったデータ検証を行い、ハードウェアIPに対する検証結果31を求める。
ステップS107において、製造業者は、ハードウェアIPに対する検証結果31を検討して、チップの製造を開始するか否かについて判定する。製造業者は、データ検証の結果、チップ設計データHCDが検証基準を満足していると判定した場合には、チップの製造を開始する(ステップS107:OK)。一方、製造業者は、チップ設計データHCDが検証基準を満足していないと判定した場合には、チップ設計に問題があるとして、チップの製造を開始せずに(ステップS103:NG)、ステップS101のチップ設計に戻る。
ここで、ステップS107において、ステップS101のチップ設計に戻る場合というのは、チップ設計者によるデータ検証の結果と、製造業者によるデータ検証の結果とが相違する場合である。別の言い方をすると、チップ設計者によるデータ検証の検証結果30は検証基準を満足したとされたのにもかかわらず、製造業者によるデータ検証の検証結果31は検証基準を満足していないとされた場合である。
このようなデータ検証の結果の相違が発生する一例として、パターンの隣接配置に対してDRC検証が行われた場合の例を用いて説明する。図7(a)は、ボックスレイアウトデータ11aを用いてチップ設計が行われたときのチップレイアウトデータの一例であり、図7(b)は、ハードウェアIP10のレイアウトデータ10aでボックスレイアウトデータ11aを置き換えたときのチップレイアウトデータの一例である。
図7(a)に示すチップレイアウトデータBLA0では、ゲートなどのパターン41がボックスレイアウトデータ11aの近傍に配置されている。ボックスレイアウトデータ11aは、その内部のゲートなどのパターンの配置に関する情報を開示していない。ここで、例えば「パターン間の距離はVal以上とること」というデザインルールが存在するとし、DRC検証として、このデザインルールを満足しているか否かの検証が行われたとする。
チップ設計者は、設計検証装置を用いて、図7(a)に示すチップレイアウトデータBLA0に対するDRC検証を行う。図7(a)に示すチップレイアウトデータBLA0では、ボックスレイアウトデータ11aはゲート配置情報を開示していないため、パターン41に隣接した他のパターンは存在していないことになる。そのため、DRC検証が行われると、図7(a)に示すチップレイアウトデータBLA0は、上述のデザインルールを満足しているという結果になる。
ここで、図7(b)に示すように、ボックスレイアウトデータ11aがハードウェアIP10のレイアウトデータ10aに置き換えられると、実際には、パターン41に対し距離LLだけ離れて隣接したパターン42が存在することが分かる。製造業者は、設計検証装置を用いて、図7(b)に示すチップレイアウトデータLA0に対して、同様のDRC検証を行う。すると、パターン41とパターン42との間の距離LLがValよりも小さくなっているため、図7(b)に示すチップレイアウトデータLA0は、上述のデザインルールを満たしていないという結果になる。つまり、チップ設計者によるデータ検証の結果と、製造業者によるデータ検証の結果とが相違することになる。
このように、ボックスレイアウトデータが用いられたチップレイアウトデータでは、パターンの隣接配置の状態を確認することが難しいため、DRC検証を充分に行うことが難しい。このため、チップ設計者によるデータ検証の結果と、製造業者によるデータ検証の結果とが相違することがある。同様に、パターンの隣接配置の状態を確認することが難しいため、OPC(Optical Proximity Correction)実施時の相互干渉やCMP(Chemical Mechanical Polishing)実施時の平坦性に関する検証についても充分に行うことが難しい。また、この他にも、ボックスIPが用いられたチップレイアウトデータでは、ボックスIPの対象となる回路ブロックと当該回路ブロックに接続された回路との間の整合性を充分に検証することが難しい。このような回路接続に関する検証例としては、タイミング解析、アンテナ効果、ストレスマイグレーションやエレクトロマイグレーションなどの信頼性に関する検証がある。これらの回路接続に関する検証が行われた際にも、チップ設計者によるデータ検証の結果と、製造業者によるデータ検証の結果とが相違することがある。
このようなデータ検証の結果の相違が発生すると、その度にチップ設計段階へ作業が戻ることになるため、なるべくデータ検証の結果の相違が発生しないようにすることが好ましい。
そこで、第1実施形態では、設計検証装置は、チップ設計者によるデータ検証段階において、ハードウェアIPにおける一部又は全部のデータが暗号化された暗号化IPを用いてデータ検証を行うこととする。以下、図8を用いて具体的に説明する。
図8は、暗号化IPの流通システムの一例について示す図である。
暗号化IPの流通システムでは、IPプロバイダは、ハードウェアIPをボックス化したボックスIPを作成するとともに、暗号化鍵EK1を用いて、ハードウェアIPにおける一部又は全部のデータを暗号化した暗号化IPを作成する。ここで、暗号化鍵EK1及び暗号化IPの復号化に用いられる復号化鍵DK1は、製造業者により作成される。
IPプロバイダは、例えば、EDAなどの装置を用いて、ボックスIP及び暗号化IPを作成する。以下では、EDAなどの、ボックスIP及び暗号化IPを作成する機能を有する装置をIP作成装置とする。IP作成装置は、例えばPCなどにおいて、CPUがプログラムを実行することにより実現される。
具体的には、図9の暗号化IPの作成方法のフローチャートにも示すように、まず、ハードウェアIPのデータ、例えば、レイアウトデータやネットリストなどのデータをIP作成装置が読み込む(ステップP101)。次に、IP作成装置は、暗号化鍵EK1を読み込み(ステップP102)、ハードウェアIPのデータの一部又は全部の暗号化処理を行うことで(ステップP103)、暗号化IPを生成する。一方、IP作成装置は、読み込まれたハードウェアIPのデータより、先に述べたボックスレイアウトデータやボックスネットリストなどのチップ設計者に開示可能なデータを抽出して(ステップP104)、ボックスIPを生成する。ボックスIP及び暗号化IPは、IPライブラリとして、チップ設計者に提供される。また、暗号化IPは、製造業者にも供給される。
図8に示す例では、ハードウェアIP10Aより、ハードウェアIP10Aにおける一部又は全部のデータが暗号化された暗号化IP12Aと、ハードウェアIP10Aにおける開示可能なデータが抽出されたボックスIP11Aとが生成される。また、ハードウェアIP10Bより、ハードウェアIP10Bにおける一部又は全部のデータを暗号化された暗号化IP12Bと、ハードウェアIP10Bにおける開示可能なデータが抽出されたボックスIP11Bとが生成される。
先にも述べたように、IPプロバイダA、Bは、ボックスIP11A、11B、暗号化IP12A、12Bをチップ設計者に提供する。また、IPプロバイダA、Bは、暗号化IP12A、12Bを製造業者に提供する。なお、IPプロバイダA、Bは、暗号化IP12A、12Bを製造業者に提供するとする代わりに、ハードウェアIP10A、10Bを製造業者に提供するとしても良い。
チップ設計者は、図2で述べたのと同様、ボックスIP11A、11Bを用いてチップ設計を行い、チップ設計データBCDを作成する。そして、チップ設計者は、設計検証装置を用いて、チップ設計データBCDに対し、DRC、LVS、DFMといったデータ検証を行う。
このとき、設計検証装置は、製造業者により提供されたコントロールファイル21に含まれる復号化鍵DK1を用いて、暗号化IPをハードウェアIPに復号化する。そして、設計検証装置は、コントロールファイル21に記述された処理によっては、チップ設計データBCD中におけるボックスIPを、復号化されたハードウェアIPに置き換えてデータ検証を行う。なお、ここで、設計検証装置は、暗号化IPの復号化からデータ検証までの処理を、設計検証装置の外部から隠蔽された記憶領域内、例えば、設計検証装置のRAMなどのメモリ内で行う。
チップ設計者は、データ検証の結果、チップ設計データBCDが検証基準を満足していると判定した場合には、チップ設計データBCDを製造業者に出荷する。
製造業者は、IPプロバイダより暗号化IPを受け入れている。製造業者は、復号化鍵DK1を用いて、暗号化IPをハードウェアIPに復号化する。なお、ここで、製造業者は、IPプロバイダよりハードウェアIPを受け入れるとしても良い。製造業者は、図2で述べたのと同様、チップ設計データBCD中のボックスIPをハードウェアIPに置き換えたチップ設計データHCDを作成する。そして、製造業者は、設計検証装置を用いて、再度、チップ設計データHCDに対し、DRC、LVS、DFMといったデータ検証を行う。製造業者は、データ検証の結果、チップ設計データHCDが検証基準を満足していると判定した場合には、チップ設計データHCDを基にチップの製造を開始する。
ここで、コントロールファイル21及びチップ設計者によるデータ検証について詳細に説明する。
図8に示すように、コントロールファイル21には、暗号化IPを復号化するための復号化鍵DK1が含まれている。また、コントロールファイル21では、処理のうち、復号化されたハードウェアIPに置き換えられたチップ設計データに対する実施可能な処理(以下、「実施可能処理」と称することもある)が製造業者により指定されている。ここで、復号化されたハードウェアIPに置き換えられたチップ設計データに対し、指定された実施可能処理以外の処理を行うことはできない。なお、指定された実施可能処理以外の処理は、ボックスIPが用いられたチップ設計データに対する処理(以下、「通常処理」と称することもある)である。ここで、製造業者は、暗号化鍵EK1及び復号化鍵DK1とは異なる鍵のペアとして、暗号化鍵EK2及び復号化鍵DK2を作成する。製造業者は、コントロールファイル21について、実施可能処理及び復号化鍵DK1の部分を暗号化鍵EK2で暗号化してチップ設計者に提供する。
コントロールファイル21について図10〜図12を用いて具体的に説明する。
図10、図11は、コントロールファイル記載例を示す図である。図10において、通常処理SB−1〜SB−n(nは整数)は、ボックスIPが用いられたチップ設計データに対する通常処理SBを示している。実施可能処理SA−1〜SA−m(mは整数)は、復号化されたハードウェアIPに置き換えられたチップ設計データに対する実施可能処理SAを示している。コントロールファイル21中の復号化鍵DK1及び実施可能処理SA−1〜SA−mは暗号化鍵EK2で暗号化される。図10では、暗号化鍵EK2で暗号化された部分が暗号化情報として示されている。この暗号化されたコントロールファイル21がチップ設計者に提供される。ここで、復号化鍵DK1及び実施可能処理SAが暗号化される理由は、チップ設計者などの第三者が、コントロールファイル21を改変して、暗号化IPのデータを引き出そうとするのを防ぐためである。つまり、暗号化IPに対する処理が製造業者によって限定され、かつ、暗号化されるとすることにより、ハードウェアIPの情報保護が行われる。
なお、製造業者は、コントロールファイル21に記載された処理のうち、一部の処理を実施可能処理SAとして指定しているが、これに限られるものではなく、全部の処理を実施可能処理SAとして指定しても良いのは言うまでもない。また、1ファイルとしてコントロールファイル21が作成されるとする代わりに、図11に示すように、複数のファイルに分離してコントロールファイル21が作成されるとしても良い。図11に示す例では、通常処理SBが記述されたファイル−1と、実施可能処理SA及び復号化鍵DK1が記述されたファイル−2とが分離されたコントロールファイル21が作成されている。この場合には、ファイル−2が丸ごと暗号化される。このようにすることで、ファイルの一部分を暗号化するよりも容易に暗号化することができる。
コントロールファイル21の作成方法について具体的に説明する。製造業者は、例えば、EDAなどの装置を用いて、コントロールファイル21を作成する。以下では、EDAなどの、コントロールファイルを作成する機能を有する装置をコントロールファイル作成装置とする。コントロールファイル作成装置は、例えばPCなどにおいて、CPUがプログラムを実行することにより実現される。
具体的には、図12のコントロールファイルの作成方法のフローチャートにも示すように、まず、復号化鍵DK1がコントロールファイル作成装置に入力されるとともに(ステップP201)、暗号化前のコントロールファイル21がコントロールファイル作成装置に入力される(ステップP202)。暗号化前のコントロールファイル21がコントロールファイル作成装置に入力された後、製造業者により実施可能処理SAが指定される(ステップP203)。そして、コントロールファイル作成装置は、暗号化鍵EK2を用いて、復号化鍵DK1及び実施可能処理SAの暗号化処理を行うことで(ステップP204)、暗号化されたコントロールファイル21を作成する。このように暗号化されたコントロールファイル21が復号化鍵DK2とともにチップ設計者に提供される。
先に述べた図8に示すように、チップ設計者は、データ検証を行う際に、復号化鍵DK2を設計検証装置に入力する。設計検証装置は、入力された復号化鍵DK2を用いて、コントロールファイル21における暗号化情報を復号化する。そして、設計検証装置は、暗号化情報に含まれる復号化鍵DK1を用いて、暗号化IPをハードウェアIPに復号化し、実施可能処理SAを行う際に、チップ設計データBCD中におけるボックスIPを、復号化されたハードウェアIPに置き換えて処理を行う。ここで、暗号化情報を復号化してから、ボックスIPをハードウェアIPに置き換えてデータ検証を行うまでの処理は、設計検証装置の外部から隠蔽された記憶領域内、例えば、設計検証装置のRAMなどのメモリ内で行われる。これは、暗号化IPからハードウェアIPに復号化したときに、復号化されたハードウェアIPのデータがチップ設計者などの第三者に取得されるのを防ぐためである。
次に、図8に示す流通システムにおける設計・検証作業の流れについて説明する。上述したことから分かるように、図8に示す流通システムにおける設計・検証作業の流れも、図2に示した流通システムにおける設計検証作業の流れと同様、チップ設計、チップ設計者によるデータ検証、IPの置き換え、製造業者によるデータ検証の順に行われる。従って、図8に示す流通システムにおける設計・検証作業の流れを示すフローチャートも、図6に示したフローチャートと同様となる。特に、IPの置き換え、製造業者によるデータ検証といった製造業者側の作業は、図6で述べたのと同様の作業が行われる。そこで、以下では、チップ設計、チップ設計者によるデータ検証といったチップ設計者側の作業に絞って説明する。
図13は、図8に示した流通システムにおける設計・検証作業の流れの一例を示す図である。図13では、チップ設計、チップ設計者によるデータ検証の各段階が示されている。
図13に示すように、チップ設計段階では、チップ設計者は、ボックスIP11Aのボックスレイアウトデータ11aAと、ボックスIP11Bのボックスレイアウトデータ11aBとを用いて、チップのレイアウト設計を行い、チップレイアウトデータBLAを作成する。また、チップ設計者は、ボックスIP11Aのボックスネットリスト11bAと、ボックスIP11Bのボックスネットリスト11bBとを用いて、チップの回路データであるチップネットリストBNLを作成する。
チップ設計者によるデータ検証段階では、チップ設計者は、設計検証装置を用いて、チップ設計データBCDについてデータ検証を行う。
図8に示す流通システムでは、チップ設計者は、IPプロバイダAより、ハードウェアIP10Aの暗号化IP12Aが提供される。例えば、レイアウトデータ10aAが暗号化された暗号化レイアウトデータ12aA、ネットリスト10bAが暗号化されたネットリスト12bAがチップ設計者に提供される。また、チップ設計者は、IPプロバイダBより、ハードウェアIP10Bの暗号化IP12Bが提供される。例えば、レイアウトデータ10aBが暗号化された暗号化レイアウトデータ12aB、ネットリスト10bBが暗号化されたネットリスト12bBがチップ設計者に提供される。ここで、ハードウェアIP、暗号化IP、ボックスIPの関係をまとめた図を図14に示す。
設計検証装置は、コントロールファイル21に従い、チップ設計データBCDに対するデータ検証を行う。設計検証装置が、実施可能処理SAを行う場合には、チップ設計データBCD中におけるボックスIPを、暗号化IPから復号化されたハードウェアIPに置き換えて処理を行う。なお、この処理は、先にも述べたように、情報保護の観点から、外部から隠蔽された記憶領域内、例えば、設計検証装置のRAMなどのメモリ内で行われる。
具体的には、設計検証装置は、復号化鍵DK1を用いて、暗号化レイアウトデータ12aA、12aBをレイアウトデータ10aA、10aBに復号化する。そして、設計検証装置は、チップレイアウトデータBLAにおけるボックスレイアウトデータ11aA、11aBを、復号化されたレイアウトデータ10aA、10aBに置き換える。また、設計検証装置は、復号化鍵DK1を用いて、暗号化ネットリスト12bA、12bBをネットリスト10bA、10bBに復号化する。そして、設計検証装置は、チップネットリストBNLにおけるボックスネットリスト11bA、11bBを、復号化されたネットリスト10bA、10bBに置き換える。
設計検証装置は、このように復号化されたハードウェアIPでボックスIPが置き換えられたチップレイアウトデータBLA及びチップネットリストBNLに対して実施可能処理SAを行い、検証結果32を出力する。この検証結果32は、IP置き換え段階を経た後の製造者によるデータ検証の結果と同じものとなる。従って、このようにすることで、チップ設計者によるデータ検証の結果と製造業者によるデータ検証の結果との間に相違が生じるのを防ぐことができ、チップ設計段階へ作業が戻るのを防ぐことができる。
次に、上述のデータ検証処理の一例について、図15のフローチャートを用いて説明する。図15のフローチャートに示すデータ検証処理では、通常処理SBが行われる場合と実施可能処理SAが行われる場合とで処理を行う対象が変えられる。具体的には、通常処理SBは、ボックスIPが用いられたチップ設計データに対して行われ、実施可能処理SAは、復号化されたハードウェアIPに置き換えられたチップ設計データに対して行われる。また、このデータ検証処理は、設計検証装置におけるCPUがプログラムを実行することにより実現されるとともに、外部から隠蔽された記憶領域内、例えば、設計検証装置のRAMなどのメモリ内で行われる。
まず、ステップS201において、設計検証装置は、コントロールファイル21を読み込む。このとき、設計検証装置は、暗号化されていない通常処理SBを取得する。続くステップS202において、設計検証装置は、コントロールファイル21内に暗号化情報が含まれているか否かについて判定する。設計検証装置は、コントロールファイル21内に暗号化情報が含まれていると判定した場合には(ステップS202:Yes)、ステップS203の処理へ進む。一方、設計検証装置は、コントロールファイル21内に暗号化情報が含まれていないと判定した場合には(ステップS202:No)、ステップS206の処理へ進む。
ステップS203において、設計検証装置は、復号化鍵DK2を読み込んで、コントロールファイル21内の暗号化情報を復号化する。ステップS204において、設計検証装置は、暗号化情報に含まれる復号化鍵DK1を取得する。ステップS205において、設計検証装置は、暗号化情報に含まれる実施可能処理SAの情報を取得する。この後、設計検証装置は、ステップS206の処理へ進む。
ステップS206において、設計検証装置は、チップ設計者により設計された、ボックスIPが用いられたチップ設計データを読み込む。続くステップS207において、設計検証装置は、先のステップS204にて復号化鍵DK1が取得されたか否かについて判定する。設計検証装置は、復号化鍵DK1が取得されたと判定した場合には(ステップS207:Yes)、ステップS208の処理へ進む。一方、設計検証装置は、復号化鍵DK1が取得されていないと判定した場合には(ステップS207:No)、ステップS211の処理へ進む。
ステップS208において、設計検証装置は、暗号化IPのデータを読み込み、復号化鍵DK1を用いて、暗号化IPをハードウェアIPに復号化する。続くステップS209において、設計検証装置は、ボックスIPが用いられたチップ設計データ内に、置き換え対象となるボックスIPが存在するか否かについて判定する。例えば、設計検証装置は、チップ設計データ内に、復号化されたハードウェアIPの名称と一致するものがあるか否かを確認することにより、置き換え対象となるボックスIPが存在するか否かについて判定する。もし、ボックスIPの名称がチップ設計データ内で別の名称で記述されている場合には、設計検証装置は、ボックスIPの名称の変換情報が記載されたファイルを読み込んだ上で、復号化されたハードウェアIPの名称と一致するものがあるか否かを確認する。なお、このようにする代わりに、設計検証装置は、復号化されたハードウェアIP及びボックスIPに埋め込まれた何らかの共通情報を確認することにより、置き換え対象となるボックスIPが存在するか否かについて判定するとしても良い。設計検証装置は、置き換え対象となるボックスIPが存在すると判定した場合には(ステップS209:Yes)、ステップS210の処理へ進む。一方、設計検証装置は、置き換え対象となるボックスIPが存在しないと判定した場合には(ステップS209:No)、ステップS211の処理へ進む。
ステップS210において、設計検証装置は、復号化されたハードウェアIPでボックスIPが置き換えられたチップ設計データを作成する。このとき、設計検証装置は、ボックスIPが用いられたチップ設計データと復号化されたハードウェアIPに置き換えられたチップ設計データとの両方を有することとなる。例えば、チップ設計データのうち、チップレイアウトデータの例をとると、図16(a)に示すように、設計検証装置は、2つのチップレイアウトデータを有することとなる。1つは、ボックスレイアウトデータ11aA、11aBが用いられたチップレイアウトデータBLA1であり、もう1つは、復号化されたレイアウトデータ10aA、10aBで置き換えられたチップレイアウトデータBLA2である。この後、設計検証装置は、ステップS211の処理へ進む。
ステップS211において、設計検証装置は、コントロールファイル21より読み込んだ検証処理、具体的には、通常処理SB及び実施可能処理SAを開始する。続くステップS212において、設計検証装置は、現在実行しようとしている処理が実施可能処理SAか否かについて判定する。設計検証装置は、現在実行しようとしている処理が実施可能処理SAであると判定した場合には、ステップS213の処理に進む。ステップS213において、設計検証装置は、復号化されたハードウェアIPに置き換えられたチップ設計データに対して処理を行い、ステップS215の処理へ進む。一方、ステップS212において、設計検証装置は、現在実行しようとしている処理が実施可能処理SAでない、即ち、通常処理SBであると判定した場合には、ステップS214の処理へ進む。ステップS214において、設計検証装置は、ボックスIPが用いられたチップ設計データに対して処理を行い、ステップS215の処理へ進む。例えば、図16(a)に示したチップレイアウトデータの例では、現在実行しようとしている処理が通常処理SBの場合には、ボックスレイアウトデータが用いられたチップレイアウトデータBLA1に対して処理が行われる。一方、現在実行しようとしている処理が実施可能処理SAの場合には、復号化されたレイアウトデータで置き換えられたチップレイアウトデータBLA2に対して処理が行われる。
ステップS215において、設計検証装置は、全ての検証処理が終了したか否かについて判定する。設計検証装置は、全ての検証処理が終了していないと判定した場合には、次の検証処理を行うべく、ステップS212の処理へ戻る。一方、設計検証装置は、全ての検証処理が終了したと判定した場合には、本検証処理を終了する。
上述したデータ検証処理をまとめると、コントロールファイル21に暗号化情報が含まれていない場合には、復号化処理が行われずに、ボックスIPが用いられたチップ設計データに対して通常処理SBが行われる。一方、コントロールファイル21に暗号化情報が含まれている場合には、復号化処理が行われ、ボックスIPが用いられたチップ設計データ、及び、復号化されたハードウェアIPが用いられたチップ設計データに対して選択的に処理が行われる。即ち、ボックスIPが用いられたチップ設計データに対して通常処理SBが行われ、復号化されたハードウェアIPが用いられたチップ設計データに対して実施可能処理SAが行われる。
なお、ステップS210で述べたチップレイアウトデータについて、設計検証装置は、図16(a)に示したように、2つのチップレイアウトデータを保持することには限られない。このようにする代わりに、図16(b)に示すように、設計検証装置は、ボックスレイアウトデータと復号化されたレイアウトデータとをライブラリとして保持することとし、それらをチップレイアウトデータにリンクで関連付けることとしても良い。この場合、設計検証装置は、検証処理毎に、対応するライブラリをチップレイアウトデータに対応づけることになる。例えば、実施可能処理SAの場合には、復号化されたレイアウトデータ10aAがリンクLiAと対応付けられ、復号化されたレイアウトデータ10aBがリンクLiBと対応付けられる。一方、通常処理SBの場合には、ボックスレイアウトデータ11aAがリンクLiAと対応付けられ、ボックスレイアウトデータ11aBがリンクLiBと対応付けられる。図16(b)に示す例によれば、図16(a)に示した例と比較して、冗長なデータが削減され、メモリ使用量の削減や処理時間の短縮化を図ることができる。
なお、上述の第1実施形態では、ハードウェアIPのレイアウトデータ、ネットリストを暗号化してデータ検証を行う場合の例について説明したが、これに限られない。このようにする代わりに、又は、加えて、ハードウェアIPにおけるレイアウトデータ、ネットリスト以外の他のデータを暗号化してデータ検証を行う場合にも第1実施形態を適用可能であるのは言うまでもない。
以上をまとめると、第1実施形態によれば、設計検証装置は、ボックスIPを用いて設計されたチップ設計データに対し、暗号化IPをハードウェアIPに復号化し、復号化されたハードウェアIPでボックスIPを置き換えてデータ検証を行う。これにより、チップ設計者によるデータ検証で、製造者によるデータ検証と同等のデータ検証を行うことが可能となり、チップ設計段階へ作業が戻るのを防ぐことができる。また、このとき、設計検証装置は、記憶されたデータが外部に対して隠蔽されるRAMなどの記憶領域内で暗号化IPの復号化及びデータ検証を行う。これにより、ハードウェアIPのデータがチップ設計者などの第三者に取得されることがない。また、このときの設計・検証の作業フローは、図6に示したのと同じ作業フローとなる。つまり、第1実施形態によれば、設計・検証の作業工程を増加させることなく、ハードウェアIPの情報保護とチップ設計者によるデータ検証の精度向上との両方を図ることができる。なお、このようにする代わりに、設計検証装置は、ボックスIPを用いて設計されたチップ設計データに対し、暗号化IPで置き換えてから、当該暗号化IPをハードウェアIPに復号化してデータ検証を行うとしても良いのは言うまでもない。
また、第1実施形態によれば、コントロールファイル21では、暗号化IPを復号化するための復号化鍵と、復号化されたハードウェアIPに置き換えられたチップ設計データに対して実施することができる実施可能処理とが暗号化されている。このようにすることで、チップ設計者などの第三者が、コントロールファイル21を改変して暗号化IPのデータを引き出そうとするのを防ぐことができる。
なお、第1実施形態では、暗号化IPとボックスIPとは別ファイルとして、チップ設計者に提供されるとしているがこれに限られない。このようにする代わりに、ハードウェアIPのデータが選択的に暗号化されたものがボックスIPとして作成されるとし、当該ボックスIPがチップ設計者に提供されるとしても良い。このようにすることで、ボックスIPが暗号化IPを兼ねることとなり、1ファイルでチップ設計者に提供することが可能となる。また、第1実施形態では、暗号化IPとコントロールファイル21とは別ファイルでチップ設計者に提供されるとしているがこれに限られない。このようにする代わりに、暗号化IPがコントロールファイル21に含まれて、即ち、暗号化IPがコントロールファイルの一部として提供されるとしても良い。
また、第1実施形態では、製造業者によるコントロールファイル21の作成はコントロールファイル作成装置によって行われ、チップ設計者によるデータ検証は設計検証装置で行われるとしている。しかしながら、このようにする代わりに、製造業者によるコントロールファイル21の作成とチップ設計者によるデータ検証とが同一の装置で行われるとしても良い。この場合には、コントロールファイル21の暗号化情報を復号化するための復号化鍵DK2は、情報保護及び運用の利便性の観点から、当該装置内で生成、保管されることが好ましい。つまり、復号化鍵DK2がチップ設計者に提供されず、チップ設計者は復号化鍵DK2を入力しなくてもデータ検証処理を行えるとした方が、情報保護及び運用の利便性の観点から好ましい。
[第2実施形態]
次に、第2実施形態について説明する。第1実施形態では、暗号化IPを用いることで、ハードウェアIPの情報保護を図りながら、チップ設計者によるデータ検証の精度を向上させるとしていた。しかしながら、チップ設計の仕方如何によっては、チップ設計者などの第三者が、データ検証実施時に、開示されていないハードウェアIPのデータを取得する可能性がある。以下では、これらを防止する方法として、DRC検証、LVS検証の例をとって説明する。
(DRC検証の場合)
まず、DRC検証の場合の例について説明する。チップ設計者は、チップレイアウトデータを作成する際に、外部パターンを適当に配置することにより、DRC検証時に、開示されていないハードウェアIPのレイアウトデータを取得する可能性がある。以下、図17を用いて具体的に説明する。
図17(a)は、パターンが配置されたチップレイアウトデータに対してDRC検証を行った場合の表示例を示す図である。図17(a)において、チップレイアウトデータでは、パターン51とパターン52とが距離LL1の間隔で配置されている。ここで、例えば「パターン間の距離はVal以上とること」というデザインルールが存在するとし、設計検証装置により行われるDRC検証として、このデザインルールを満足しているか否かの検証が行われるとする。設計検証装置は、距離LL1が距離Valよりも小さいと判定した場合には、デザインルールを満足していないパターンの部分についてエラーフラグを表示する。例えば、設計検証装置は、検証結果として、パターン51及びパターン52の位置にエラーフラグP1を表示する。
図17(b)は、ボックスレイアウトデータ上に外部パターンを配置したチップレイアウトデータに対してDRC検証を行った場合の表示例を示す図である。図17(b)において、チップレイアウトデータでは、ボックスレイアウトデータ11a上に外部パターン53が配置されている。ここで、ボックスレイアウトデータ11aは、何らのパターンも開示していないものとする。設計検証装置は、DRC検証として、先に述べたのと同様、「パターン間の距離はVal以上とること」というデザインルールを満足しているか否かの検証を行うものとする。なお、以下において、このDRC検証の処理は実施可能処理であるとする。
設計検証装置は、DRC検証を開始すると、第1実施形態で述べたように、チップレイアウトデータについて、復号化されたレイアウトデータ10aでボックスレイアウトデータ11aを置き換える。このときに、設計検証装置は、ボックスレイアウトデータ11aでは開示されていなかったパターン54が外部パターン53に対して間隔LL2で配置されていることを認識する。従って、設計検証装置は、置き換えが行われたチップレイアウトデータに対しDRC検証を行うと、距離LL2が距離Valよりも小さいため、デザインルールを満足していないとしてエラーフラグを求めて表示する。具体的には、設計検証装置は、検証結果として、パターン53及びパターン54の位置にエラーフラグP2を表示する。このとき、図17(b)に示すように、チップ設計者は、エラーフラグP2の位置や長さを観察することにより、パターン54のレイアウトの一部を知ることができてしまう。
つまり、チップ設計者などの第三者が、ボックスレイアウトデータの近傍に外部パターンを適当に配置して、設計検証装置にエラーフラグを出力させる作業を繰り返すことにより、開示されていないはずのパターンのレイアウトが取得される恐れがある。
そこで、設計検証装置は、DRC検証を行う場合において、復号化されたハードウェアIPのレイアウトデータについてエラーが発生した場合には、エラーフラグの形状を加工して出力することとする。以下、エラーフラグの形状を加工して出力する2つの方法についてそれぞれ説明する。
まず、エラーフラグの形状を加工して出力する第1の方法について説明する。第1の方法では、設計検証装置は、レイアウトデータ10aの領域内、または、予め決められた一部の領域内で発生したエラーフラグを加工して表示することとする。以下、図18を用いて具体的に説明する。
図18は、エラーフラグの形状を加工して出力する表示例の一例を示す図である。図17(b)の例で述べたのと同様、チップレイアウトデータでは、ボックスレイアウトデータ11a上に外部パターン53が配置されている。また、設計検証装置は、DRC検証として、「パターン間の距離はVal以上とること」というデザインルールを満足しているか否かの検証を行うものとする。設計検証装置は、図17(b)で述べたのと同様、チップレイアウトデータについて、復号化されたレイアウトデータ10aでボックスレイアウトデータ11aを置き換え、DRC検証を行い、エラーフラグP2を求める。
ここで、設計検証装置は、エラーフラグP2を表示せずに、エラーフラグP2が、レイアウトデータ10aについてのものか否かを判定する。そして、設計検証装置は、エラーフラグP2が、レイアウトデータ10aについてのものであると判定した場合には、エラーフラグP2を加工して表示する。例えば、設計検証装置は、検証結果1に示すように、レイアウトデータ10aを囲む形状(即ち、ボックスレイアウトデータ11aを囲む形状と同じ)のエラーフラグP3に加工して表示する。このようにすることで、開示されていないはずのパターンのレイアウトが、チップ設計者などの第三者に引き出されてしまうのを防ぐことができる。
ここで、ボックスレイアウトデータ11aの配置境界に関するエラーフラグについては、加工せずにチップ設計者に表示した方が良い場合もある。そこで、設計検証装置は、上述のようにする代わりに、レイアウトデータ10a内におけるエラーフラグが発生する領域に応じて、エラーフラグを加工して表示するとしても良い。例えば、図18の検証結果2に示す例では、設計検証装置は、レイアウトデータ10a内における領域Area1内で発生したエラーフラグについて加工するとしている。具体的には、設計検証装置は、レイアウトデータ10a内における領域Area1内で発生したエラーフラグについては、領域Area1を囲む形状のエラーフラグP3aに加工して表示する。一方、設計検証装置は、領域Area1外で発生したエラーフラグについては、レイアウトデータ10a内で発生したエラーフラグであっても加工せずに表示する。なお、領域Area1は、ハードウェアIPに含まれるデータなどにおいて、IPプロバイダや製造者により予め指定される。
次に、エラーフラグの形状を加工して出力する第2の方法について説明する。第2の方法では、設計検証装置は、レイアウトデータに置き換えられたチップレイアウトデータに対してDRC検証を実施するのに加えて、ボックスレイアウトデータが用いられたままのチップレイアウトデータにもDRC検証を実施することとする。そして、設計検証装置は、両者の検証結果を比較した比較結果に応じて、エラーフラグをそのまま表示するか、または、エラーフラグを加工して表示するか、を決めることとする。以下、図19、図20を用いて具体的に説明する。
図19、図20は、エラーフラグの形状を加工して出力する表示例の一例を示す図である。図19において、設計検証装置は、チップレイアウトデータについて、復号化されたレイアウトデータ10aでボックスレイアウトデータ11aを置き換えてDRC検証を行い、距離LL2が距離Valよりも小さいとして、エラーフラグP2を求める。それに加えて、設計検証装置は、ボックスレイアウトデータ11aが用いられたままのチップレイアウトデータに対してもDRC検証を行う。このとき、ボックスレイアウトデータ11aでは、パターン54が開示されていないので、設計検証装置は、デザインルールを満足しているとして、エラーフラグを求めない。
ここで、設計検証装置は、レイアウトデータ10aに置き換えられたチップレイアウトデータに対するDRC検証の検証結果と、ボックスレイアウトデータ11aが用いられたままのチップレイアウトデータに対するDRC検証の検証結果とを比較する。
設計検証装置は、両者の検証結果が一致しない場合には、レイアウトデータに置き換えられたチップレイアウトデータに対するDRC検証で求められたエラーフラグP2を加工して表示する。一方、設計検証装置は、両者の検証結果が一致する場合には、エラーフラグP2を加工せずにそのまま出力する。
図19に示す例では、両者の検証結果が一致しないので、設計検証装置は、エラーフラグP2を例えばエラーフラグP3に加工して表示する。なお、ここで、設計検証装置は、エラーフラグP2をエラーフラグP3に加工して表示する代わりに、図18で述べたのと同様にして、レイアウトデータ11a内の所定の領域を囲む形状のエラーフラグに加工して表示するとしても良いのは言うまでもない。
図20は、両者の検証結果が一致する場合の例である。図20に示す例では、ボックスレイアウトデータ11aでパターン54が開示されているとしている。この場合には、レイアウトデータに置き換えられたチップレイアウトデータに対するDRC検証の検証結果と、ボックスレイアウトデータが用いられたままのチップレイアウトデータに対するDRC検証の検証結果とは一致する。具体的には、どちらの検証結果においてもエラーフラグP2が求められる。従って、この場合には、設計検証装置は、エラーフラグP2を加工せずに出力する。
第2の方法によれば、ボックスレイアウトデータ11aで既に開示されているパターンに関するエラーフラグは、チップ設計者に表示され、ボックスレイアウトデータ11aで開示されていないパターンに関するエラーフラグは、チップ設計者に表示されない。このようにすることで、IPプロバイダや製造者がコントロールファイルなどで特に指定しなくても、ボックスレイアウトデータ11aで開示されていないデータについて、チップ設計者などの第三者から保護することが可能となる。
以上述べたようにすることで、DRC検証が行われた場合における、ハードウェアIPのレイアウトデータの情報保護を図ることが可能となる。
なお、上述の第1及び第2の方法では、設計検証装置は、外部パターンなどの外部レイアウトからの干渉によってレイアウトデータ10a内で発生するエラーを想定している。しかしながら、レイアウトデータ10a内で発生するエラーとしては、この外部レイアウトからの干渉により発生するエラーの他、これ以外の他の理由により発生するエラー(以下、「擬似エラー」と称する)もある。そのため、設計検証装置が、例えば、レイアウトデータ10a内で発生するエラーフラグを全て加工して表示すると、外部レイアウトからの干渉によるエラーと擬似エラーとを区別することができなくなる恐れがある。そこで、設計検証装置は、予め、このような擬似エラーを除去した上で、第1及び第2の方法を用いてDRC検証を行うのが好ましい。例えば、設計検証装置は、擬似エラー除去に必要な情報が含まれるファイルを予め読み込んでおき、当該ファイルを基に、擬似エラーを除去することが好ましい。
(LVS検証の場合)
次に、LVS検証の場合について説明する。以下では、DRC検証の場合で述べた第1及び第2の方法を応用して、LVS検証を行う場合におけるハードウェアIPの回路データ、具体的にはネットリストの情報を保護する仕組みについて述べる。
LVS検証では、チップレイアウトデータを基に抽出された回路データ、具体的にはチップネットリストと、チップの論理回路設計で設計された回路データとが一致するか否かが検証される。LVS検証が行われた場合には、エラー発生時のデバッグ容易性を鑑み、設計検証装置は、チップネットリストを出力することがある。ここで、設計検証装置が、ボックスレイアウトデータからハードウェアIPのレイアウトデータに置き換えられたチップレイアウトデータを基に、チップネットリストを出力した場合を考えてみる。このとき、設計検証装置は、当該チップレイアウトデータを基に、復号化されたハードウェアIPのネットリストを用いて、チップネットリストを生成する。従って、この場合には、チップ設計者などの第三者は、出力されたチップネットリストを基に、ハードウェアIPのネットリストを取得する可能性がある。
そこで、設計検証装置は、LVS検証を行う場合において、出力されるチップネットリストにおけるハードウェアIPのネットリスト部分について加工処理を行うこととする。
具体的には、第1の方法として、DRC検証の場合のところで述べた第1の方法と同様、設計検証装置は、出力されるチップネットリストにおけるハードウェアIPのネットリスト部分を削除する。もしくは、このようにする代わりに、設計検証装置は、出力されるチップネットリストにおけるハードウェアIPのネットリスト部分のうち、予め指定されたデータ以外を削除するとしても良い。または、第2の方法として、DRC検証の場合のところで述べた第2の方法と同様の方法と用いるとしても良い。即ち、設計検証装置は、出力されるチップネットリストにおけるハードウェアIPのネットリスト部分について、ボックスネットリストと比較して、ボックスネットリストと一致しないデータを削除するとしても良い。このようにすることで、ハードウェアIPのネットリストの情報保護を図ることが可能となる。
上述のLVS検証のフローについて図23を用いて説明する。図21は、LVS検証の処理を示すフローチャートである。
まず、設計検証装置は、コントロールファイル21を読み込む(ステップP301)。そして、設計検証装置は、コントロールファイル21に従い、チップレイアウトデータを読み込んで(ステップP302)、回路データ、具体的にはチップネットリストを抽出する(ステップP303)。また、設計検証装置は、コントロールファイル21に従い、チップの論理回路設計で設計された回路データを読み込む(ステップP304)。そして、設計検証装置は、チップレイアウトデータより抽出された回路データと論理回路設計で設計された回路データとが一致するか否かの検証を行う(ステップP305)。
次に、設計検証装置は、チップレイアウトデータより抽出された回路データの加工処理を行う(ステップP306)。例えば、第1の方法で述べたように、設計検証装置は、チップネットリストにおけるハードウェアIPのネットリスト部分について、全て削除するか、または、ハードウェアIPのネットリストのうち、予め指定されたデータ以外を削除する。この後、設計検証装置は、チップレイアウトデータより抽出された回路データ、具体的には、加工処理が施されたチップネットリストを出力して(ステップP307)、LVS処理を終了する。
以上述べたようにすることで、LVS検証が行われた場合における、ハードウェアIPのネットリストの情報保護を図ることが可能となる。
以上に述べたことをまとめると、第2実施形態では、第1の方法として、設計検証装置は、ハードウェアIPのデータを示すエラーフラグなどの情報がデータ検証の結果に含まれる場合には、当該情報を加工処理してから検証結果を出力する。これにより、ハードウェアIPの情報保護を図ることが可能となる。また、第2の方法として、設計検証装置は、ボックスIPが用いられたままのチップ設計データに対するデータ検証の第1の検証結果と、復号化されたハードウェアIPに置き換えられたチップ設計データに対するデータ検証の第2の検証結果とを比較する。そして、設計検証装置は、ハードウェアIPのデータを示すエラーフラグなどの情報が、第1の検証結果には含まれないのにもかかわらず、第2の検証結果に含まれる場合には、当該情報を加工処理してから検証結果を出力する。このようにすることで、IPプロバイダや製造者が特にコントロールファイルなどで指定しなくても、ボックスIPで開示されていないデータをチップ設計者などの第三者から保護することが可能となる。
なお、第2実施形態では、DRC検証、LVS検証の場合の例について述べたが、上述した第1又は第2の方法は、例えばDFMなどの他の検証の例においても適用可能である。具体的には、DFMなどの他のデータ検証が行われた際の結果にハードウェアIPのデータを示す情報が含まれる場合には、設計検証装置は、上述した第1又は第2の方法を用いて当該情報を加工してから結果を出力すればよい。
なお、実施形態は、上述した第1及び第2実施形態の例に限られるものではなく、特許請求の範囲及び明細書全体から読み取れる発明の要旨あるいは思想に反しない範囲で適宜変更可能である。