JP4570638B2 - オブジェクト指向方法 - Google Patents

Description

本発明は、再利用可能な回路設計コンポーネントに関する。特に、本発明は、システムオンチップ（ＳｏＣ）設計を含む回路設計に容易に盛り込むことができる設計コンポーネントを作成し管理するシステム及び方法に関する。

集積回路の設計及び製造は、信じがたいほど複雑な作業である。回路論理の基本的な記述から始まる回路設計は、半導体シリコンダイ上の導体、半導体、及び、絶縁体のエリアから形成された、トランジスタ、抵抗器、コンデンサ、及び、接続配線のような回路コンポーネントに変換しなければならない。論理から物理的な回路への変換の際の各ステップは、回路が設計された論理を適切に実現することを保証するため、検証されなければならない。

実際の回路は、理想的、理論的なコンポーネントのようには振舞わないので、モデルとして機能する設計は、実際の装置として製造されたときに巧く機能しない。例えば、隣接する導体間の容量は、電子信号が回路の素子間を移動するために時間を要するので、回路動作に影響を与える。回路論理が回路設計に変換され、次に、実際の回路に変換されるときに、大規模なテスト及び解析が行われる。

集積回路（ＩＣ）製造プロセスの能力が高まるのに伴って、半導体チップに載せることができるトランジスタ及び論理ゲートの個数は、指数関数的に増加する。現在の集積回路は、一つのチップ上に数千万個の論理ゲートを含む。企業は、プロセッサ、デジタル・シグナル・プロセッサ（ＤＳＰ）、メモリ、及び、周辺インタフェースを含む従来のシステムの全ての機能を単一のチップ内に組み合わせることによって、最新シリコンプロセスを巧く利用する。

ムーアの法則は、集積回路内のフィーチャー（特徴部分）の数に依存するコンピュータの計算能力が、１８ヶ月毎に倍増することを示している。この倍増は、回路フィーチャーのサイズを縮小する製造の進歩に起因する。フィーチャーのサイズが減少する結果として、回路構成のため使用できるシリコンダイ上で利用可能な空間（スペース）の量が増加し続ける。新製品ができるだけ素早く市場に出回るようにするため、短い設計時間を維持することは重大な課題であるため、スペースを埋めるために余分な時間を利用できない。設計された回路の生産性は、毎年約２０％ずつ増加していることが推定されるが、市場の需要の期限までにチップ上で利用可能なスペースを有効に活用するには不十分である。

設計者数は増加していない。設計者は、チップの収容能力の増加についていくのが困難である。例えば、多数の半導体ハウスは、チップ上に２０００万個以上の論理ゲートを置くためにシリコンプロセスを複雑化させている。しかし、現在の平均的な特定用途向け集積回路（ＡＳＩＣ）は、およそ５０万ゲートを組み込んでいる。現在の電子設計自動化（ＥＤＡ）ツールと、現在のシリコンプロセスにおいて１個のダイ上で利用可能なゲート数との間には、生産性格差が存在することが広く認識されている。

この格差を解決するため、設計者は、ブロックベースの方法論において、インテレクチュアル・プロパティ（ＩＰ）又は設計資産と称される既存の事前検証された設計ブロックを再利用することにより、マルチミリオンゲート・システムオンチップ（ＳｏＣ）設計を作成しようとしている。

電子産業では、設計再利用の価値はかなり以前から十分に理解されている。このような理解にもかかわらず、今までのところ、設計再利用は制限されている。設計（設計情報）再利用の一つの妨げは、設計グループの間で設計資産を共有することに係る技術的な課題である。設計は、単一のファイルにはとどまらない。設計は、典型的に、種々のフォーマットの多数のパーツにより構成され、多数のパーツは様々なツールで作成され編集されている。一部の個別の設計グループが異なるファイルタイプに対して標準化されたディレクトリフォーマットを作成しているとしても、産業界全体の標準規格や、殆どの企業の間の標準規格は存在しない。設計が他の設計者へ与えられるとき、ファイルの命名法や編成法に関する標準規格は無いので、必要なファイルが全て存在するかどうかを判定することは困難になる。

問題を更に複雑化する点として、設計再利用を生産性課題は、設計作成の格差だけではない。それは、設計検証の格差でもある。広範囲に及ぶ合成の使用は、設計者が、実行されるべき論理演算の記述から論理回路又はゲートを自動的に生成することを可能にさせる。合成ステップの出力が要求された論理結果を生ずるかどうかを検証することが必要である。

設計は時間の経過に伴って変化するので、設計を構築する様々なファイルは改正される。個別のファイルの変更によって、ファイルのバージョンが変更される。現在設計に使用されているファイルがどのファイルであるかを追跡するために多数のファイルの異なるバージョンを全て記録しておくことは困難である。

設計データを共有するエンジニアのグループについては、互換性のないツールや、コミュニケーションの不足のような問題が存在する。ある設計ファイルを作成するツールのバージョンのような情報は保持されない。ある設計者が他の設計者によって作成された設計を使用したい場合、ツールの違い、或いは、ツールのバージョンの相違は、ファイルを再処理する際に誤りを生じさせる。原設計者が設計ファイルを説明できない場合、あるテクノロジーから次のテクノロジーへ継承される遺産ブロックを再度巧くまとめることは非現実的であり、場合によっては、禁止される。

設計再利用に対する技術的障害を超えて、設計再利用を初期導入するには非常に現実的な経済的障害も存在する。例えば、設計マネージャは、ＳｏＣ設計スケジュールを維持しようと努めながら、再利用のための新しいブロックの設計を正当化することは困難であることに気付く。設計を再利用可能にするために必要な余分な仕事は、限られたリソースを使い果たし、既存のプロジェクトを危うくする。同時に、既存の設計グループは、不確実な報いのため既知の危険のうちの一つを再利用するため設計する選択を行って、このブロックを再利用することは決してない。新しいブロックを使用可能な態様で設計するために要する努力を埋め合わせるよりもＳｏＣ設計における既存のブロックを再利用する方が時間が節約される場合に限り克服され得る。

設計再利用のその他の妨げは、本質的に文化である。全てのエンジニアリング組織は固有の設計文化をもっている。その文化の中の多数のエンジニアは、検証よりも創作を好み、再設計よりも革新の方を好む。更に、従来の企業インセンティブプログラムは、革新に対して設計者に報いる傾向がある。しかし、設計再利用は、設計創作及び革新が抽象化のレベルに格上げされることを要求する。

ある特定の組織内でも、再利用を試みる設計者は、互換性の無い配布フォーマット、一致しないブロックインタフェース、不完全な文書、及び、一貫しないツールフローに気付くであろう。更に、殆どの場合に、ブロックを再利用可能にすることが何を意味するかについて明確な定義がない。更に、問題を複雑にする事項として、「再利用可能」の定義は、設計者、組織、及び、設計要件の間で異なる。その上、チップ複雑性の増大に伴って、機能的検証は、設計再利用に対する大変な阻害要因である。設計者がブロックを検証するためにコンポーネントの細部に詳細に精通しなければならない場合、設計再利用において殆ど時間は節約されない。

本発明の目的は、回路設計者による設計資産（ＩＰ）の再利用を容易にするシステムを提供することである。

本発明のシステムは、標準化されたコンポーネントタイプと、「デリバラブル」の概念を使用する設計環境を提供する。デリバラブルは、共通の機能を実行し、標準化された態様でシステムによって表されるファイル、若しくは、ファイルのディレクトリ、又は、ファイル若しくはディレクトリのグループにより構成される。設計ファイルをデリバラブルに抽象化することによって、システムは、あらゆるソースから生じ、異なる構造を有する設計ファイルと連携することが可能であり、これらの設計ファイルは、事前審査されたコンポーネントの効率的な再利用のための均一的な様式で他の設計者によって使用できるようにされる。

コンポーネントは、「デリバラブル」と「アトリビュート（属性）」とにより構成される。アトリビュートは、コンポーネントを記述するメタデータであり、コンポーネントはそのデリバラブルを含む。コンポーネントのタイプ毎の属性、デリバラブル、及び、クォリフィケーション（適格性審査）標準は、システムで制御される。かくして、コンポーネントを再利用することを望む設計者は、コンポーネントがその属性及びクォリフィケーションに関して均一に表されることが約束される。コンポーネントタイプ項目を定義し、次に、コンポーネントをインスタンス化するオブジェクト指向の局面は、オブジェクトのインスタンスバージョンとアソシエーションを容易に作成することができる拡張可能性のあるシステムを提供する。システムは設計者に標準的なフレームワークを提供すると共に、新しいコンポーネントタイプ、標準、属性、及び、デリバラブルが容易に定義され、システム管理者によってシステムに追加され得る点でフレキシブルである。

標準化されたデリバラブルの概念を使用し、設計ファイルとは別のデータベース内のメタデータを使用して各デリバラブルを特徴付けることにより、他の設計者がファイルを理解し再利用できるようにさせる効率的な態様で、多数の様々なタイプの設計ファイルを管理するシステムを提供することが可能である。

デリバラブルの概念の使用によって、システムは、コンポーネントの階層を維持することにより階層コンフィギュレーション管理を行うことが可能になり、デリバラブル及びコンポーネントのサブコンポーネント毎にバージョンを与え、コンポーネント自体に一つのバージョンを与えるバージョン制御を行うことが可能になる。コンポーネントモデルと、設計ファイル及びメタデータファイルのデータ構造との組み合わせは、拡張性のある知識ベースを維持するため適した知識管理システムを生成する。

以上の説明では、本発明の特徴及び技術的効果をかなり広範に概説しているので、以下の本発明の詳細な説明が十分に理解されるであろう。本発明の更なる特徴及び効果は後述される。開示された概念及び特定の実施例は、本発明の同じ目的を実現するため他の構成を変更若しくは設計するための基礎として容易に利用されるであろう。当業者には明らかであるように、このような等価的な構成は、特許請求の範囲に記載されている本発明の精神並びに範囲に包含される。

本発明の実施例は、これらの実施例を例示する以下の説明及び添付図面を参照することによって十分に理解されるであろう。

再利用可能なＩＰ（設計資産）設計を作成・管理し、他のＩＰ及びシステムオンチップ設計でＩＰを使用するシステムを説明する。以下の記述では、説明の目的のため、多数の具体的な細部が本発明の完全な理解が得られるように開示されている。しかし、当業者には明らかであるように、本発明はこれらの具体的な細部を用いなくても実施することができる。

本発明の理解を助けるため、最初に、用語を定義し、本発明の一部の局面をより詳細に説明する。

定義・概念・構造
〔設計資産（ＩＰ）〕
一般的に使用される用語「設計資産（ＩＰ）」は、ＣＰＵ、タイマー、或いは、完全なＳｏＣ（システムオンチップ）のような特定の再利用可能設計ブロックを表現する。本発明は、単にＩＰコンポーネントをサポートするだけではなく、実質的にあらゆるタイプのコンポーネントを保存するように構成することが可能である。

〔コンポーネント〕
用語「コンポーネント」は、典型的に、メタデータファイルと設計データファイルの両方によってサポートされた再利用可能設計ブロックを表すために使用される。典型低には、回路設計の再利用可能ブロックであるコンポーネントは、実際にはどのようなものでもよく、例えば、ソフトウェアや筐体用のプラスチックでもよい。メタデータは、ユーザが、単純な属性のように、これまでは設計データファイルに保存されることがなかったコンポーネントに関する情報を指定できるようにさせる。メタデータとして保存されたコンポーネント情報は、コンポーネントをそのメタデータによって検索可能にさせる。

各コンポーネントは、特定の「コンポーネントタイプ」をもつように定義される。特定のコンポーネントタイプをもつ全てのコンポーネントは、コンポーネントタイプによって示される同じ標準規格によって制限される。これにより、コンポーネント間の一貫性が保証され、ユーザがこれらのコンポーネントを検索し管理する能力を高める。

〔コンポーネント属性〕
コンポーネントのメタデータの大半は、属性（アトリビュート）の形式で添付される。属性は、例えば、「ゲート数：１００」のように、「名前(name)：値(value)」のペアとして定義される。コンポーネントは、特定の属性名に対する属性値に基づいて検索することも可能である。例えば、「カテゴリー」という名前の属性がある場合、ユーザは、全コンポーネントに対して、カテゴリー＝ＣＰＵという条件で検索をすることによって、全てのＣＰＵコンポーネントを見つけることができる。属性は、コンポーネントのある局面を特徴付けるため、システム管理者によっても作成され得る。

属性名の標準化は、広範囲のリポジトリの検索をサポートする。従来技術において、設計者が異なると、異なる属性名が使用されていた。例えば、同じ概念を表現するために、あるコンポーネントは属性名「カテゴリー」を使用し、別のコンポーネントは属性名「キャット」を使用し、更に別のコンポーネントは属性名「グルーピング」を使用する。設計者は異なる属性名を使用し、属性名が等価であるかどうかを知る方法がないので、コンポーネントの枠を越えて検索することは不可能であった。本発明のシステムの場合、属性名は、コンポーネントのコンポーネントタイプに連携された標準属性名のリストの中から選択しなければならない。

属性名の標準化は、コンポーネントタイプの使用に重大な利益がある。コンポーネントタイプの作成者は、そのタイプのコンポーネントが使用しなければならない全ての属性名を選択することができる。属性名「カテゴリー」を使用する場合、例えば、ユーザは、この属性名を所定のリストから選択し、次に、値を入力すればよく、データ入力エラーの結果として異なる属性名を取り除く。

〔コンポーネントデリバラブル〕
デリバラブルは、一つ以上の設計データファイル又はファイルのディレクトリの集まりとして定義される。デリバラブルは、例えば、文書（ドキュメンテーション）、ＲＴＬソースコード、ネットリスト、又は、合成制約などである。デリバラブルは、再利用されるべき作業生産物である。各デリバラブルのタイプ及び特徴付けは、システムによって標準化されているので、デリバラブルの標準化は、設計者の間で、交換対象についての共通の理解を生じさせる。デリバラブルは、コンポーネント設計の特定の部分に関するファイルをグループ分けするための強力な方式を提供する。例えば、ユーザが設計のため全てのＲＴＬファイルを要求する場合、設計者は、それらの全てのファイルを格納するＲＴＬデリバラブルを要求するだけでよい。

用語デリバラブルが示すように、デリバラブルは、他の設計者へ配布することが予定されたデータユニットを表現する。デリバラブルは、特に、設計ファイルのネーミングや構成法に関して異なる標準規格をもつ設計者間での、設計データの交換に関連した問題を取り扱う。

コンポーネントは、多数のデリバラブルにより構成され得る。各デリバラブルは、コンポーネントのコンポーネントタイプによって規定されるような有効なデリバラブルタイプの標準化リストからの一つのデリバラブルである。例えば、ＩＰコンポーネントタイプは、ＲＴＬ、ネットリスト、及び、文書のようなデリバラブルタイプ項目を定義するときに、ユーザが「ＩＰコンポーネント」タイプの「高速ＣＰＵ」と称されるコンポーネントを設計する場合を考える。高速ＣＰＵの設計者は、ＲＴＬタイプのデリバラブルを作成し、全てのＲＴＬファイルをそのデリバラブルの下に置くことができる。ネットリストや文書の場合にも同様である。ＩＰコンポーネントを作成する全ての設計者は、同じデリバラブル標準規格のセットに従うので、設計者は、コンポーネントを効率的に交換し再利用することが可能である。

デリバラブルタイプの標準化には、クォリフィケーション標準規格の開発がデリバラブルタイプに限定され、標準フローがこれらのデリバラブルタイプに基づいて作成され得る、というその他の利点がある。

各デリバラブルは、高々１個のコンポーネントだけに結び付けられる。そのコンポーネントは、多数のコンポーネントの中でサブコンポーネントとして使用できるが、デリバラブル自体は一つのコンポーネントに関連付けられる。異なるバージョンのコンポーネントは、異なるコンポーネント内でサブコンポーネントとしてインスタンス化される。設計者が新しいデリバラブルのバージョンを作成した場合、デリバラブルを保持するコンポーネントの新しいバージョンが作成される。以前のバージョンのコンポーネントを使用した設計は変更されずに、以前のバージョンを使用し続ける。

〔コンポーネントタイプ〕
コンポーネントタイプは、そのタイプに属する全てのコンポーネントが準拠しなければならない標準規格のセットを規定する。これらの標準規格の中には、
属性名
デリバラブルタイプ
デリバラブルセット
フローテンプレート
クォリフィケーション標準規格
の項目が含まれる。

各コンポーネントは、所定のコンポーネントタイプのいずれかである。コンポーネントタイプの中の一部のタイプは限定される。例えば、あるコンポーネントタイプは、バージョンが無いタイプ項目として定義され、或いは、サブコンポーネントをインスタンス化できないタイプ項目として定義される。

〔設計階層〕
典型的な設計アプローチの場合、設計コンポーネントは多数のサブブロックに区分される。各サブブロックは、それ自体、サブブロックに区分され得る。このことは、設計階層（構造）として知られている。好ましいシステムは、ユーザがコンポーネントを他のコンポーネントの下にインスタンス化すること、すなわち、コンポーネントがサブコンポーネントを含むこと、を許容する。コンポーネントが他のコンポーネントの内部にインスタンス化されたとき、同じコンポーネント内の別のインスタンスとの間で個別に識別できるように固有のインスタンス名が与えられる。

〔バージョン制御〕
好ましい一実施例によれば、コンポーネントを作成する第１ステップは、バージョンの無いコンポーネントの表現を作成することである。これにより、システムは、バージョンとは無関係にコンポーネントを参照することができる。また、無バージョンに関連した属性がコンポーネントに割当てられる。無バージョン属性は、作成されたコンポーネントのバージョンによって自動的に継承される。

コンポーネント上の設計を実際に開始するため、コンポーネントのバージョンは作成されるべきである。好ましい一実施例によれば、全ての設計作業はコンポーネントバージョンに作用する。これにより、２世代以上のバージョンに対する作業が同時に行われることが許される。用語「コンポーネントバージョン」は、コンポーネントのバージョン付きインスタンス化を参照する。

コンポーネントバージョンは、完全に独立ではなく、コンポーネントバージョン間でデータを共有する。例えば、２世代のバージョン間のデリバラブルの一部は同一でもよい。その場合、２個のコンポーネントバージョンは、同じデリバラブルバージョンを参照することになる。

システムは、コンポーネントだけにではなく、デリバラブル、及び、デリバラブルに含まれるファイルにもバージョンを割当てる。デリバラブルにバージョンを割当てることにより、デリバラブルファイルは１ユニットとして取り扱えるようになり、これにより、設計者は、デリバラブルのコンフィギュレーションを非常に簡単に調べることができる。ファイルバージョンは、典型的に、表に出ないバージョンであり、抽象化されたデリバラブルだけを取り扱うコンポーネントのユーザには関係が無い。用語「デリバラブルバージョン」は、デリバラブルのバージョン付きのインスタンス化を意味する。

〔コンポーネントの分析〕
コンポーネントは、デリバラブルとデリバラブルのバージョンとの両方の集まりを表現する。デリバラブルは、ファイルとファイル自体のバージョンとの両方の集まりを意味する。ファイルは、ファイル自体のバージョンの集まりを意味する。

コンポーネントのデリバラブルのバージョニングは、コンポーネントのバージョンとは独立に維持される。同様に、デリバラブルのファイルのバージョニングは、デリバラブルとコンポーネントの両方のバージョニングとは独立して行われ、たとえ、設計者がデリバラブルのバージョンを取り扱うとしても、ファイルのバージョニングは表に出ないシステム機能である。コンポーネントのユーザは、設計ファイルの標準化されたデリバラブル表現だけを取り扱い、標準化されていないファイル自体は取り扱わない。かくして、ファイルの原本若しくは形式とは無関係に、ファイルはデリバラブルに抽象化され、システムはこのデリバラブルを用いて均一な態様で機能することができる。

したがって、システムは、コンポーネント階層構造にバージョン制御とコンフィギュレーション管理を提供する。バージョンは、階層のレベル毎に制御され、コンポーネントの全コンポーネントバージョンに対して制御される。システムの中心はデリバラブルであり、デリバラブルは再利用されるべき作業生産物である。

コンポーネントのバージョンは、デリバラブルバージョンへの照会先の固有セットに過ぎない。同様に、単一のファイルバージョンは、任意の個数のデリバラブルバージョンから参照され得る。このため、ファイルバージョンをコピーする必要がなく、ファイルバージョンへの参照しか行われないので、記憶効率が著しく高くなる。

コンポーネントの階層構造の管理と、コンポーネントのバージョン制御とを組み合わせることにより、再利用を促進する階層コンフィギュレーション管理が実現される。

コンポーネントバージョンは、他のコンポーネント、若しくは、デリバラブルのバージョンを含む他のコンポーネントバージョンへの参照先を格納する。第１のコンポーネントバージョンが第２のコンポーネントバージョンを参照するとき、第２のコンポーネントバージョンは第１のコンポーネントのサブコンポーネントであると考えられる。

例えば、ＣＰＵと称されるコンポーネントがデリバラブルＲＴＬ及びネットリストを収容する場合、ＣＰＵのバージョン１．１はＲＴＬデリバラブルとネットリストデリバラブルの両方のバージョン１．１を参照する。ＣＰＵのバージョン１．２は、ＲＴＴデリバラブルの同じバージョンを参照し続けるが、ネットリストのバージョン１．２を参照しない。最後に、ＣＰＵのバージョン１．３は、両方のデリバラブルの新しいバージョンであるＲＴＬデリバラブルのバージョン１．２と、ネットリストデリバラブルのバージョン１．３を参照する。同じ種類の参照が、デリバラブルとファイルの間でも行われる。ＣＰＵは、サブコンポーネントをもつことができる。ユーザは、サブコンポーネントのバージョン、或いは、コンポーネントを構成するデリバラブルのバージョンに関心がある場合もあるが、ユーザは、典型的に、コンポーネント自体のバージョンにしか関心が無い。

〔データ編成〕
メタデータを組み込み、Ｏｒａｃｌｅ（登録商標）リレーショナルデータベースのようなデータベースを用いてメタデータを管理し、上述のコンポーネントモデルと連結することによって、知識管理システムが得られる。

多数のオブジェクトを収容し得るシステムと同様に、これらのオブジェクトを編成する能力が不可欠である。Ｕｎｉｘ（登録商標）若しくはWindows（登録商標）のようなオペレーティングシステムは、ファイルを階層的に構造化し、編成する方式を得るため、ディレクトリと呼ばれるものを使用する。本発明は、ドメインと呼ばれるユーザ、チーム、コンポーネント、作業（タスク）、フローなどを編成するため同じ方法を提供する。ドメインはサブドメインを含むことがあり、各サブドメインはそれ自体がサブドメインを収容することが可能であり、これにより、作成されるべきドメインの階層構造が得られる。これは、ドメインツリーとして知られている。

ドメインツリーは、ユーザ、チーム、コンポーネントなどを編成する目的のためだけに役立つのではなく、システム内で各エレメントを個別に識別する方式を規定する。各ＩＰコンポーネントは、ドメインツリー内でのその位置に基づく固有識別子をもつ。これは、完全に適格である名前とも呼ばれる。完全に適格である名前は、ドメインツリーの最上部から開始して、下方のコンポーネントに達するまでの全てのドメイン名を連結し、ドメイン名とドメイン名の間、並びに、最後のドメイン名とコンポーネント名の間にピリオド（．）を挿入することによって形成される。

〔マルチサイトデータ〕
本発明の一つの利点は、全社的協調及び共有を促進する能力を備えていることである。このことは、屡々、システムはグローバルに広がり、世界中に展開したユーザにアクセスできるようにする必要がある、ということを意味する。

これは、単独のサーバー装置を用いて実現することも可能であるが、遠隔ユーザのネットワーク応答時間が著しく遅くなるであろう。この問題を解決するため、システムは、各サーバーが会社の主要なサイトに設置された場合に、多数のサーバーをサポートするアーキテクチャを採用する。定期的な間隔で、サーバーは、サーバー間でデータを同期させる。各サーバーは、データが最初にどこから入力されたかにかかわらず、システムに入力された全データのコピーを保持する。この処理はデータベース複製として知られている。サポートすることが可能な実際のサーバーの台数はサーバー間のネットワーク収容能力に依存する。

メタデータのデータベースはシステム全体で複製されるが、設計ファイルは複製しない方が好ましい。設計ファイルは、個別の「保管サーバー」又は「保管部」に置かれる。ユーザがデリバラブルを要求したとき、システムは、ローカル保管部内でそのデリバラブルを自動的に見つける。デリバラブルの実際の場所はユーザにはわからない。システムは、高速アクセスのため、設計ファイルのローカルコピー又はキャッシュを作成する。別のユーザがそのファイルへのアクセスを要求し、そのユーザのアクセスはキャッシュされたコピーを使用することによって高速化される場合、システムは、オリジナルではなく、ローカルキャッシュへ自動的にアクセスする。

〔フロー、タスク、フローテンプレート、及び、タスクテンプレート〕
一部の実施例のフローシステムの局面は、設計フローを定義し、追跡することを可能にさせる。標準的なフローは、ユーザが、コンポーネントを設計若しくはクォリファイするため矛盾の無い、反復可能なプロセスを作成することを可能にさせると同時に、設計プロセス中に必要に応じてフローに変更を加える柔軟性を保ち続ける。フローシステムは、２段式であり、フローとタスクとを含む。タスクは、入力と出力を有するジョブに特有のものであり、フローは、タスクの系列である。フローテンプレートは、コンポーネントタイプに特有の設計プロセスを定義するが、特定のコンポーネントには依存しない。フローテンプレートは、別のフローテンプレート又はタスクテンプレートをインスタンス化することが可能である。フローテンプレートはバージョン制御される。標準化フローを準備することは、システムに入るコンポーネント及びデリバラブルが標準規格を充たすことを保証する。

システム機能
次に、システムによってシステム内で実行される種々の機能を説明する。機能は、対象エリアによって概略的にリスト化される。様々な役割のユーザが異なる機能にアクセスする。例えば、設計は、コンポーネントをクォリファイするためクォリフィケーションツールを使用するが、クォリフィケーション管理者だけが新しいクォリフィケーション要求を作成可能である。好ましい一実施例によれば、全ユーザ及び管理機能は、データベースにアクセスするため、エンタープライズＪａｖａ（登録商標）ビーンズ(EJBs)のアプリケーションプログラミングインタフェース（ＡＰＩ）に構築されたアプリケーションを介してアクセスされる。アプリケーションは、ＡＰＩを使用してアプリケーションサーバーにアクセスするプレゼンテーション層を表現する。ＥＪＢｓは、アプリケーションサーバー上で動き、データベースサーバー上のデータベースにアクセスする。本発明は、特定のアーキテクチャに限定されない。例えば、プレゼンテーション層のその他の実現例は、ＥＪＢｓとは無官気に作成することができる。

〔ロール（役割）〕
システムの種々の機能は、便宜上、ユーザのタイプ別に分割することが可能であり、ユーザの各タイプは特定の「役割」を想定する。３種類の主要な役割は、システム若しくはプラットフォームの管理部と、標準規格の管理部と、設計者である。設計者は、新しいコンポーネントを作成し、以前に作成され、システムに蓄積されているコンポーネントを使用する。システム管理部は、システムデータベースを組み込み、サーバーを組み込み、ユーザ、チーム、及び、ユーザのドメインを管理し、様々な権限をユーザ、チーム、及び、ドメインに与える責任を担う。ドメインは、ユーザのグループであり、典型的に、共通の場所に居るユーザのグループである。標準規格管理部は、設計部がコンポーネントを作成する際に使用する標準的な選択対象を用意する役割を担う。例えば、標準規格管理部は、設計部がファイルのフォーマットを指定するときに選択するフォーマットのリストを設定する。標準規格管理部は、標準コンポーネントタイプ、デリバラブル及びフローテンプレートを定義する。

管理機能は、ある設計者によって作成されたコンポーネントが他の設計者によって容易に理解され、かつ、使用されることを保証するために、データベース及びサーバーのセットアップと、システムの種々のパーツが準拠しなければならない標準規格の提供と、を必然的に伴う。

〔システム管理機能〕
システム管理機能には、ドメイン及びチームの管理の組織化と、ユーザへの権利の付与とが含まれる。プラットフォーム管理機能は、システム設計データが、「保管部」と呼ばれるデータベースに保持されることを可能にする。設計データファイルは、典型的に非常に大規模であるため、これらのファイルは、そのファイルに責任をもつ設計者のサイトに置いておく方が効率的である。ファイルを他の場所からもアクセスできるべきであるならば、設計ファイルのコピーは、長時間のダウンロードを避けるため、他の場所にキャッシュされる。システム管理部は、保管部及びリモート保管部を作成することが可能である。

〔単位管理〕
標準的な管理部の一つの機能は、種々のコンポーネント属性を記述することが許される測定単位を定義することである。例えば、「ゲート幅」の属性に対する単位は、「ミクロン」であり、周波数に対する単位はメガヘルツであり、バス幅に対する単位はビット数である。単位を標準化することによって、設計者は、他の設計者によって作成されたコンポーネントの属性を適切に解釈することが可能である。

〔フォーマット管理〕
標準的な管理部のもう一つの機能は、デリバラブルに使用されるフォーマットを標準化することである。フォーマットは、例えば、異なるタスクから入力若しくは出力することができるデリバラブルを判定するために、プロセスフローツールと共に使用される。例えば、設計ファイル用のフォーマットは、「Verilog バージョン１．１」である。「合成」タスクは、入力として、有効な設計フォーマットだけを受け付ける。標準規格管理部は、新しいフォーマットや、既存のフォーマットの新しいバージョンを作成し得る。設計者は、コンポーネントをシステムに入力する際には、標準規格管理部に新しいフォーマットを追加させていない限り、既存のフォーマットを使用するように制限される。

〔ツール管理〕
効率的なタスク立案と再生可能設計フローを可能にするため、ツール情報を追跡する必要がある。ツールには、設計自動化ツール、シミュレーションツール、検証ツール、文書ツールなどが含まれる。ツールは、システムに登録され、ツール情報が追跡される。設計者は、限定的なタスク及びフローでツールを使用することができ、種々のデリバラブルを作成するため使用されたツールを追跡することができる。

〔フロー及びタスク管理〕
システムは、新しいＩＰ（設計資産）の作成を追跡記録する。新しいＩＰを作成するため要求されるステップは、一体として、「フロー」と呼ばれる。フローはタスクにより構成される。標準規格管理部は、設計者が設計用のフローを作成するため寄せ集めることができる標準規格タスクを定義する。一般的なタスクには、例えば、合成、ＲＴＬコーディング、静的時間解析、プロトタイプ化、要求仕様書の作成などが含まれる。標準規格管理部は、各タスクの入力及び出力を指定し、特定の入力又は出力のうちの複数のものが許容されるかどうかを指定する。合成スクリプトのような外部ファイルは、タスク管理部によってタスクにアップロードされる。

〔デリバラブルタイプ管理〕
デリバラブルタイプ管理機能は、新しいデリバラブルをシステムに追加する。デリバラブルタイプ管理機能は、典型的に独立にアクセスされるものではなく、コンポーネントタイプ管理部若しくはフロー管理部のようなその他のアプリケーションを介してアクセスされる。デリバラブルタイプ管理部を使用することにより、設計者は、デリバラブルを作成、削除、或いは、編集できる。

デリバラブルタイプは、名前、作成者、及び、コメントのような特性によって特徴付けられる。デリバラブルを作成する場合、そのデリバラブルのためのフォーマットが選択される。フォーマットは、上述のフォーマット管理機能を使用して管理部によって以前に入力されたそのデリバラブルタイプに対して利用可能なフォーマットのテーブルから選択される。

デリバラブルタイプは、属性によっても特徴付けられる。属性はそのデリバラブルタイプのため利用可能な属性のリストから選択される。例えば、ＲＴＬファイルデリバラブルの属性は「ゲート」である。属性は、タイプ「個数」の値をとり、デフォルト値は、１０，０００でもよい。

〔コンポーネントタイプ機能〕
コンポーネントタイプは、ＩＰ又はＳｏＣのような役に立つ設計のタイプを形成するデリバラブルのグループと、そのグループに関する情報として定義される。コンポーネントタイプ機能は、コンポーネントタイプを定義し、それらの特性と、定義タイプのコンポーネントのインスタンスを作成するためのユーザ機能を指定する管理機能を含む。

コンポーネントタイプは、タイプの名前、コメント、及び、作成者情報のような特性をもつ。タイプの作成者は、当該タイプのコンポーネントが保有する属性を定義する。属性には、名前と値が含まれ、値は、値のタイプ（例えば、数若しくは文字列）、デフォルト値、有効な値のリストなど、並びに、属性が当該タイプのあらゆるコンポーネントから要求されているかどうかの指摘、及び、属性の説明によって更に定義される。ユーザは、当該タイプのコンポーネントと関連したデリバラブルを定義する。便宜上、ユーザは、デリバラブルを組にグループ分けすることが許される。組は、処理されている設計のタイプを精緻化するために有用である。

コンポーネントタイプを使用することは、本システムのオブジェクト指向的な局面である。様々なタイプが、バージョニング、アソシエーション、及び、インスタンス化のコンポーネントモデルの異なる局面を作動（オン）させたり、停止（オフ）させたりすることができる。

コンポーネントタイプは、標準規格を作成する能力を高めるので、コンポーネントタイプの下で作成されたコンポーネントは標準規格に準拠する。システムは、コンポーネントタイプを作成する能力を与えることによって、柔軟性（フレキシビリティ）が得られる。このように、システム自体は、標準規格を指定せずに、システム標準規格を作成するためのツールをユーザに提供する。

コンポーネントタイプは階層的に組織化される。例えば、親のコンポーネントタイプの特性を継承するコンポーネントタイプが定義される。

〔フロー機能〕
フロー機能は、コンポーネント及びデリバラブルを作成する作業を制御する設計フローを作成し編集するため使用され、タスク機能によって定義されるようなタスクから構築される。フローは階層的でもよく、すなわち、他のフローに包含されるフローが存在していても構わない。タスクの入力及び出力と、対応したフォーマットは、タスクテンプレートのため定義され、テンプレートがフローテンプレート内でインスタンス化されるときに継承される。これにより、ユーザは、コンポーネントタイプのデリバラブルセットからのフォーマットに基づいてタスクの入力又は出力毎に、デリバラブルを選択できるようになる。ユーザはタスクの入力と出力を接続することができる。

コンポーネントに対するフローが定義された後、設計者は、作業の進捗に応じて、例えば、フローは、実行準備完了、実行準備中、進行中、正常終了、或いは、異常終了のようにフローの状態を指定することができる。異常終了は、全てのタスクが完了したが、出力デリバラブルの一部が発生していない、ということを意味する。

ユーザは、各タスク及びデリバラブルの依存性を示すフローテンプレートのグラフィカル描写を見ることができる。タスクは、概要図又はフローチャートに類似した様式で入力デリバラブル及び出力デリバラブルを表すことによって、他のタスクへの依存性を表示するグラフィカル・アイコンを用いて表される。タスクに対する必須の入力デリバラブルが準備され、デリバラブル・バージョニング・システム（ＤＶＳ）へ入れられた場合、ユーザは、これらのデリバラブルをプロジェクトディレクトリに入れる。同時に、フローテンプレートは、ＤＶＳから出される。

全ての入力デリバラブル及びフローテンプレートが出されたとき、ユーザはタスクを呼び出すことができる。タスクは、フローに関して上述と同じ状態、すなわち、準備中、準備完了、進行中、正常終了、或いは、異常終了の状態をとる。

タスク及びタスクテンプレートは、名前、ランバージョン、及び、このタスクの責任を負うユーザの名前のような特性を含む。タスクテンプレートは、特性として、タスクテンプレートの名前、タスクテンプレートのバージョン、及び、テンプレートの作成者を更に含む。タスク設定メニューは、特定のタスクのための入力デリバラブル及び出力デリバラブルの割当を可能にさせる。例えば、合成タスク用の入力デリバラブルは、ＲＴＬファイル、合成スクリプトファイル、及び、制約条件ファイルを含み、一方、出力デリバラブルは、ネットリストを含む。ユーザは、デリバラブルフォーマット若しくはツールを活用することによって異なるデリバラブルを含む多数のタスクを構築することが可能である。

〔クォリフィケーション標準機能〕
クォリフィケーション機能には、クォリフィケーション標準規格を定義する管理機能と、設計者がデリバラブル若しくはコンポーネントのクォリフィケーションを記録するため使用するユーザ機能と、が含まれる。

クォリフィケーションは、典型的に、コンポーネントタイプと関連付けられるが、関連付けなくてもよい。ユーザがコンポーネントタイプのため利用可能なクォリフィケーション標準規格のリストを要求するとき、データベースは、エンタープライズＪａｖａ（登録商標）ビーンズ(Enterprise Java（登録商標）Beans)を介して問い合わせを受け、階層ツリーモードで表示される。標準規格は、公開しても公開しなくてもよい。公開された標準規格はコンポーネントをクォリファイするため使用できるが、非公開標準規格は使用できない。標準規格は削除してもよいが、公開から非公開に変更することはできない。コンポーネントは、コンポーネント管理機能を使用して、標準規格の新しいバージョンに限定してもよい。標準規格の２世代以上のバージョンが公開されてもよく、設計マネージャは、特定のコンポーネントをクォリファイするため、公開された標準規格の中でどのバージョンを使用するかを指定しなければならない。標準規格は、標準規格の名前及び説明を含む特性によって特徴付けられる。標準規格は、α、β、又は、プロダクションのようなクォリフィケーションレベルをもつように定義してもよい。

クォリフィケーション機能は、設計者が自分のコンポーネントを標準規格に適格とするために回答しなければならない質問のリストを、管理者が構築できるようにする質問構築機能を含む。質問は、識別子、質問テキスト、クォリファイするために正しい回答、質問が適用されるレベル、及び、質問に対するある種の制限、質問を適用できない事情によって特徴付けられる。オプション的な検索機能は、標準規格管理者が他のクォリフィケーション標準規格から質問を見つけ、コピーできるようにさせる。

設計者は、システム内のコンポーネントを特定のバージョンの標準規格に適合させるため、クォリフィケーション・ユーザ・ツールを使用する。コンポーネントタイプは、選択されたコンポーネントタイプを編成するデリバラブルの階層ツリーと共に表示される。ユーザは、各々のデリバラブルに関するクォリフィケーション質問に回答する。例えば、ＲＴＬコードデリバラブルを有するコンポーネントタイプＳｏＣの場合、クォリフィケーション質問は、「ソースはエラーなしでコンパイルされましたか？」である。クォリフィケーション質問は、デリバラブルではなく、タスクについての問い合わせでもよい。

〔コンポーネントツール機能〕
コンポーネントツールは、ユーザがコンポーネントに関する情報を編集できるようにさせる。コンポーネントに含まれる情報は、例えば、名前、タイプ、説明、並びに、作成情報及び変更情報のような履歴情報である。コンポーネントは属性に関連付けられる。「ゲートクロック」のようなある種の属性は、フラグ型であり、その属性がコンポーネントに適用されるかどうかを示すチェックボックスを有する。「ピンアウト」のような別の属性は、選択型であり、ユーザは適切な値を選択するためメニューをプルダウンする。他の属性は、値型であり、ユーザは数値を入力する。値型の属性は、単位管理者によって指定されたミクロン或いはメガヘルツのような単位で記述される。

ユーザは、コンポーネントへの相対的なアクセス度を様々なユーザ若しくはチームに付与する。例えば、あるユーザは、ファイルに読み書きする許可が与えられ、他のユーザに許可を与えることができる管理上の特権が与えられる。許可は、ユーザ又はチームに付与され、チームのメンバーはそのチームの許可を継承する。

コンポーネント機能は、新しいバージョンのコンポーネントの作成と、旧いバージョンの除去とを可能にさせる。改定は、通常、連続的な番号が与えられ、小規模の改定には小数が使用される。

コンポーネントバージョンツール・デリバラブル・メニューは、既存のデリバラブルを提示する。デリバラブルは、デリバラブル・バージョニング・システム（ＤＶＳ）を使用して作成される。コンポーネントと関連付けられた各デリバラブルは、デリバラブル名とデリバラブルバージョンをもつ。新バージョンのコンポーネントを作成するとき、ユーザは、新しい改定版と共に使用するため既存のデリバラブルを選択可能である。ユーザは、以前に定義されたデリバラブルの組を指定してもよい。例えば、フロント・エンド・デリバラブルの組は、ＲＴＬソース、テストベクトル、仕様書、テストベンチ、シミュレーションなどを含む。ユーザは、コンポーネントの多数のバージョンで同じデリバラブルを使用することが可能であるが、ユーザは異なるコンポーネントで同じデリバラブルを使用することはできない。異なるコンポーネントでデリバラブルを使用するためには、ユーザは、固有の識別情報をもつ第２のデリバラブルを作成するために、デリバラブルをコピーする必要がある。

ユーザは、コンポーネントバージョンに収容するため特定の改定レベルのサブコンポーネントを選択してもよい。ユーザは、組み込まれるべき特定のコンポーネントを検索することができる。ユーザは、コンポーネントバージョンに対応させるため設計フローバージョンを選択することも可能である。

〔通信機能〕
本発明の一部の実施例には、設計チームのメンバー間の通信用の通信システムが含まれる。通信システムは、組織が結束した設計環境を得るため協調した通信を行えるようにする。設計者は、設計イベントに関する企業内通信を構成し、維持し、受け取ることができる。設計イベントとは、システム内のユーザによって行われたある種の行動の結果としての設計に関するイベントである。リポジトリへの新しい設計の公開、又は、発見されたバグのような設計イベントは、影響を受ける他の設計者への通信をトリガーする。典型的な設計イベントは、コンポーネントのための「新クォリフィケーションレベル到達」である。ユーザは、自分が関心を持っているイベントに加入することによって、このようなイベントが発生したとき、自分に通知するようにシステムを設定することができる。ユーザは、ある種のイベントが公開されるか、又は、他のユーザへ自動的に送信されるように指定することも可能である。ユーザは、加入済みメッセージ及び公開メッセージを受信し、再検討するため、個人用受信トレイが与えられている。また、システムの全ユーザへ送信されたメッセージを閲覧することができる公開受信トレイも存在する。

通信システムは、通信管理部と、通信セットアップと、通信受信トレイの三つのサブアプリケーションを含む。通信管理部は、管理者が通信環境全体を設定できるようにする。通信セットアップは、各ユーザがイベント若しくはプロファイルに基づいてメッセージを予約、公開できるようにする。通信プロファイルは、各ユーザが、申込又は公開のためある頻度で使用される特性を設定し、それらを再利用できるようにする。通信個人受信トレイは、ユーザが、ユーザの申し込んだ設計イベント、又は、コンポーネント所有者によって公開されて設計イベントによってトリガーされたメッセージを読むことを可能にさせる。また、通信公開受信トレイは、全てのグローバルシステムメッセージを表示する。

〔課題追跡機能〕
課題追跡システムの目的は、組織が、コンポーネントに関する問題、或いは、場合によってはデリバラブルシステムに関する問題などの種々の設計問題を報告し、この設計課題を解決するため行われる後続のステップを記録できるようにすることである。これらの課題は、一般設計コミュニティに報告される必要があり、他のユーザがその課題を解決するため助けることを要求する。システム内で、「課題」は、品質、機能性、製造価値、或いは、再利用性に影響を与える設計データにおける何らかの矛盾であり、他のユーザへの報告及び解決が求められる。ある課題に関して追跡記録される情報には、影響される対象のタイプ、すなわち、課題は、コンポーネント、ツール、フローなどのどのタイプの対象に影響を与えるかという情報、コンポーネントのタイプ、名前及びバージョン、デリバラブル及びそのバージョン、課題の簡単な説明を含むタイトル、課題の詳細な説明、課題の優先度レベル、（例えば、ペンディング中、進行中、クローズ中、再オープン中のような）課題の状態、課題を報告した人の名前、課題に責任を担う人、並びに、一般的な注意事項、が含まれる。

課題追跡システムは、課題管理部と課題追跡アプリケーションの二つのアプリケーションを含む。課題管理部は、管理者が課題追跡環境の全体を設定できるようにさせる。課題追跡アプリケーションによって、各ユーザが課題を提出し、他のユーザによって課題が割当てられるようになる。

ユーザは、一般的な注意事項を追加することが可能であるが、状態、優先度、又は、課題タイプを設定できるのは管理者だけである。現在の課題受託者は状態を変更することが可能であり、起案者又は現在の受託者は、課題を再割当することが可能である。履歴は、夫々の課題に関して行われた行動を追跡するため維持される。

〔監査証跡機能〕
監査証跡システムは、組織が共有設計の起源を追跡できるようにする。監査証跡システムによって、設計者は、階層又は系譜のいずれかの観点で起源を追跡することにより、再利用設計内で共通設計要素（例えば、バグ）を検索し、発見できるようになる。設計者は、新しいコンポーネントの作成につながるイベントのシーケンスを再トレースするため設計履歴を閲覧可能である。これを実現するため、監査証跡システムは、設計階層と、設計系譜と、設計進捗と、設計使用法のサブアプリケーションに分割される。設計階層アプリケーションは、ユーザが、所与のコンポーネントでインスタンス化されたのはどのコンポーネントであるか、所与のコンポーネントを構成するコンポーネントはどのコンポーネントであるか、を決定できるようにする。設計系譜アプリケーションによって、ユーザは、所与のコンポーネントの起源、すなわち、所与のコンポーネントはどのコンポーネントに基づいているか、或いは、どのコンポーネントからコピーされたか、並びに、新しいコンポーネントはどのコンポーネントに基づいているか、或いは、どのコンポーネントからコピーされたか、を決定できる。設計進捗アプリケーションは、所与のコンポーネントとそのサブコンポーネントに関する設計進捗の状態及びクォリフィケーションレベルを追跡するため使用される。また、ユーザは、ユーザの指定した検索条件に基づいて、多数のコンポーネントに対する設計進捗を取得可能である。設計使用法アプリケーションは、ユーザが所与のコンポーネントを使用する人を追跡できるようにする。この所与のコンポーネントには、全てのコピー及び調査されたコンポーネント、並びに、インスタンス化されたコンポーネントが含まれる。システム内の他のアプリケーションと同様に、監査証跡アプリケーションは、データベースリポジトリとの通信のため、エンタープライズＪａｖａ（登録商標）ビーンズを大量使用する。

図１は、本発明の実施例を具体化するシステムを例示するブロック図である。図１には、設計者がユーザ・インタフェース・ソフトウェア１０４を実行するため使用する多数の設計者ワークステーション１０２を含むシステム１００が示されている。システム１００は、ユーザ・インタフェース・プログラム１０８を実行する管理者ワークステーション１０６を更に含む。設計者及び管理者には役割があり、同一個人が設計者と管理者の両方の役割を果たしてもよく、管理者ワークステーション１０６は、設計者ワークステーション１０２と実際には同一のコンピュータでも構わない。ユーザ・インタフェース・プログラム（ソフトウェア）１０４及び１０８は、ネットワーク１１６を介して通信を行い、アプリケーション・サーバー１２０のアプリケーション・プログラミング・インタフェース（ＡＰＩ）１１８の機能を呼び出す。ＡＰＩ機能は、ネットワーク１３０を経由してメタデータデータベース１３２へアクセスするため、エンタープライズＪａｖａ（登録商標）ビーンズ（ＥＪＢｓ）を使用する。メタデータデータベース１３２は、コンポーネントの特定のバージョンのようなインスタンス化オブジェクト１３６に関するデータと、オブジェクトのインスタンス化を構造化し制約する抽象コンポーネントタイプ及びフローテンプレートを定義するデータのような標準化データ１４０と、を格納する。システム１００は、デリバラブル、ファイル１５２を格納する保管(vault)サーバー１５０を更に有する。保管サーバーに格納されたファイルは、データベースに関連したメタデータを有する。メタデータは、ファイルバージョン及びバージョン情報毎に固有の識別子を含む。デリバラブルは、保管サーバーに保持されたファイルを収容するデータベースに格納されたオブジェクトを表す抽象概念である。

図２は、本発明の実施例によるメモリ用のコンポーネントタイプの一例の説明図である。図２に示されるように、メモリコンポーネントタイプ２０２は、デリバラブル２１２と属性２１４とを含む。メモリコンポーネントタイプ２０２用のデリバラブル２１２は、設計文書２０４と、ユーザガイド文書２０６と、レジスタ・トランスファー・レベル（ＲＴＬ）ソースコード２０８と、テストベクトル２１０と、を含む。メモリコンポーネントタイプ２０２用の属性２１４は、物理サイズ２１６、速度２１８及び記憶スペース２２０を含む。したがって、メモリコンポーネントタイプ２０８のコンポーネントが作成されるか、データベースに記憶するためインスタンス化されるとき、コンポーネントは、図２に示されるように、リスト化されたデリバラブル及び属性を含む。図２に示されたデリバラブル及び属性は、例示であり、限定のためではなく、本発明の実施例に従って、その他のデリバラブル及び属性を様々なコンポーネントタイプに組み込むことが可能である。

図３は、本発明の好ましい一実施例のステップを説明するフローチャートである。ステップ３０２では、コンポーネントタイプが定義される。上述の通り、コンポーネントタイプは、そのコンポーネントタイプのコンポーネントバージョンのインスタンス化のため属性及びデリバラブルを指定する。コンポーネントタイプ及びデリバラブルタイプのようなタイプは、設計者ではなく、管理者によって作成される。勿論、個別のユーザは、設計者の役割と管理者の役割の両方で機能してもよい。

ステップ３０４において、一つ以上のデリバラブルタイプが定義される。上述のように、デリバラブルタイプは、典型的に、デリバラブルと、デリバラブルの要求属性のためのフォーマットを指定する。デリバラブルタイプは、管理者の役割のユーザによって作成される。ステップ３０８において、クォリフィケーション標準規格がコンポーネントタイプのため定義される。上述の通り、クォリフィケーション標準規格はコンポーネントタイプと関連付けられ、クォリフィケーション標準規格はバージョン制御される。

ステップ３１０において、第１のコンポーネントタイプをもつ無バージョンのコンポーネントが作成される。無バージョンのコンポーネントは、コンポーネントの全てのバージョンに対して同一であり、継承された特性を定義するため便利である。ステップ３２２において、このコンポーネントタイプのコンポーネントバージョンが作成される。ステップ３２４において、コンポーネントバージョンに関連付けられたデリバラブルが作成され、見つけられ、購入され、保管サーバーに格納される。ステップ３３０において、コンポーネントバージョンは、クォリフィケーション標準規格を使用してクォリファイされる。ステップ３３６において、コンポーネントは、適切なレベルで適格であることが判明した場合、コンポーネントは、製品若しくは他の設計で自由に使用することが可能である。なお、コンポーネントは、それ自体で、ＳｏＣのような最終製品でもよく、或いは、コンポーネントは他の設計に組み込んでもよい。ステップ３４０において、コンポーネントは製品として生産される。ステップ３４２では、コンポーネントバージョンが、同じコンポーネントタイプ、若しくは、他の第２のコンポーネントタイプをもつ第２のコンポーネントバージョンの階層に組み込まれる。

ステップ３３６において、コンポーネントバージョンは適格ではないと判明した場合、そのコンポーネントバージョンのデリバラブルは、コンポーネントバージョンが適格となるまで変更される。デリバラブルに重大な変更が加えられた場合、設計者は、ステップ３２２から再開して、コンポーネントの変更を追跡する能力を高めるため、新しいコンポーネントバージョンを作成する。図３は、単純化されたフローを表しており、上述の多数のオプションは、このフローチャートには描かれていない。例えば、コンポーネントに対するクォリフィケーション（資格審査）には多数のレベルが存在し、各コンポーネントバージョンは、他のコンポーネントバージョンに組み込むことができるようになるまでに幾つかのレベルを進む。

コンポーネントの集積化のための好ましいツールは、１９９９年６月１４日に出願され、発明の名称が”再利用可能ＩＰのためのソケットベースド設計方法及び装置(Method and Apparatus for Socket-Based Design for Reusable IP)”である係属中の米国仮特許出願第６０／１３９，１４６号、及び、２０００年３月３１日に出願され、発明の名称が”再利用可能ＩＰのためのソケットベースド設計方法及び装置(Method and Apparatus for Socket-Based Design for Reusable IP)”である米国特許出願第０９／５４０，７８４号、に詳述され、これらの文献は参考のためここに引用される。

上述の通り、本発明の実施例は、ＩＰ（設計資産）設計再利用のためのデータ・デリバラブル中心の方法論を提供する。更に、本発明の実施例は、ＩＰデリバラブルを使用するため、ＩＰコンシューマ用のシステム及び機構を提供する。本発明の実施例は、電子ＩＰ及びＳｏＣ設計に関して記述されている。しかし、本発明の実施例はこれらに限定されるものではなく、このような実施例は他の分野でも具体化することが可能である。例えば、本発明の実施例は、ソフトウェアコンポーネントにおいて具体化される。

本発明は、回路設計の環境に関して説明されているが、本発明は、実際には、回路設計以外の多数の分野で使用される知識管理用のシステムである。

本発明と本発明の効果は、詳細に説明されているが、多数の変更、置換、及び、代替は、特許請求の範囲に記載されているような発明の精神及び範囲を逸脱することなくなし得ることが認められよう。さらに、本発明の範囲は、明細書中で説明されたプロセス、装置、製造、事物の組み合わせ、手段、方法、及び、ステップの特定の実施例に限定されることを意図していない。当業者は、本発明の開示から、明細書に記載された対応した実施例と実質的に同じ機能を実行し、実質的に同じ結果を達成する、既存の、又は、後で開発される、プロセス、装置、製造、事物の組み合わせ、手段、方法、及び、ステップが本発明にしたがって利用できることが容易に理解されるであろう。以上の通り、特許請求の範囲に記載された事項は、このようなプロセス、装置、製造、事物の組み合わせ、手段、方法、及び、ステップを包含することが意図されている。

以下、本発明により教示される手段を例示的に列挙する。

（１） 再利用可能な設計コンポーネントを使用して集積回路を設計するコンピュータ組込み型のシステムであって、
様々なタイプの再利用可能コンポーネントに対応する多数のコンポーネントタイプ定義項目が設けられ、
コンポーネントタイプ定義項目はコンポーネントタイプと関連付けられた属性を含み、
各々が一つのコンポーネントタイプである多数のコンポーネントと、
多数のコンポーネントの各々に対する多数のコンポーネントバージョンと、
が設けられ、
各コンポーネントバージョンは一つのコンポーネントであり、
少なくとも一つのコンポーネントバージョンは、メタデータ及びデリバラブルバージョンを含み、
メタデータは、コンポーネントの種々のバージョンを追跡するコンポーネントバージョン番号、及び、コンポーネントの属性を記述する属性値を含み、
デリバラブルバージョンは、共通機能を実行し、デリバラブルバージョン番号によって記述された一つ以上の設計ファイルを含む、
システム。

（２） デリバラブルバージョン番号をコンポーネントバージョン番号に関連付けるメタデータが更に設けられている第１項記載のシステム。

（３） コンポーネントバージョンに対応したメタデータは、デリバラブルファイルが格納されるデータベースとは別のデータベースに格納される、第１項記載のシステム。

（４） ユーザがメタデータデータベースを作成し変更するためにデータベースへアクセスする際に用いられるアプリケーション・サーバーが更に設けられている第３項記載のシステム。

（５） デリバラブルの様々なタイプと対応する多数のデリバラブルタイプ定義項目が更に設けられている第１項記載のシステム。

（６） 少なくとも一つのデリバラブルタイプはクォリフィケーション要求項目と関連付けられ、
クォリフィケーション要求項目には、当該デリバラブルタイプのデリバラブルバージョンがクォリフィケーションレベルに適格であるための要求項目が定義されている、
第５項記載のシステム。

（７） 少なくとも一つのデリバラブルタイプは、多数の関連付けられたクォリフィケーション要求項目を含み、
クォリフィケーション要求項目には、当該デリバラブルタイプのデリバラブルバージョンが多数のクォリフィケーションレベルに適格であるための要求項目が定義されている、
第６項記載のシステム。

（８） コンポーネントタイプと関連付けられた設計フローテンプレートが更に設けられ、
設計フローテンプレートは当該コンポーネントタイプのコンポーネントを設計する設計タスクを指定する、
第１項記載のシステム。

（９） 設計フローテンプレートのインスタンス化であり、コンポーネントバージョンに対応している設計フローバージョンが更に設けられている第８項記載のシステム。

（１０） コンポーネントバージョンと連結された設計問題を追跡する情報が更に設けられ、
当該情報は、各設計問題を解決する責任を負う人と、各設計問題を解決するために行われる、又は、行われるべきステップと、を含む、
第１項記載のシステム。

（１１） 少なくとも一つのコンポーネントバージョンは、第２のコンポーネントタイプをもつ第２のコンポーネントバージョンをインスタンス化し、
第２のコンポーネントバージョンは少なくとも一つの第２のデリバラブルバージョンを含む、
第１項記載のシステム。

（１２） コンポーネントタイプはシステムオンチップに対応する、第１１項記載のシステム。

（１３） 第２のコンポーネントタイプは再利用可能な設計ブロックに対応している、第１２項記載のシステム。

（１４） ユーザ名項目が更に設けられ、
ユーザ名項目の少なくとも一部はチームにグループ分けされている、
第１項記載のシステム。

（１５） ユーザ及びチームは、コンポーネントを作成、閲覧、又は、変更するため、並びに、他のユーザに対してコンポーネントを作成、閲覧、又は、変更する権限を付与するため、選択的に制御可能なアクセス権限が与えられている、第１４項記載のシステム。

（１６） ユーザ及びチームは、コンポーネントバージョンを作成、閲覧、又は、変更するため、並びに、他のユーザに対してコンポーネントバージョンを作成、閲覧、又は、変更する権限を付与するため、選択的に制御可能なアクセス権限が与えられている、第１４項記載のシステム。

（１７） コンポーネントバージョンを作成、閲覧、又は、変更するため、並びに、他のユーザに対してコンポーネントバージョンを作成、閲覧、又は、変更する権限を付与するためのアクセス権限は、チームから当該チームのメンバーへ継承される、第１６項記載のシステム。

（１８） ユーザが関心のある設計イベントのタイプを指定することができ、ユーザは当該タイプの設計イベントの出現を自動的に通知されるか、又は、ユーザが設計イベントの出現を他のユーザへ通知させるように指定することができる、通信システムが更に設けられた第１項記載のシステム。

（１９） 設計イベントはコンポーネントバージョンのクォリフィケーションである、第１８項記載のシステム。

（２０） 通信システムは、一般に関心がもたれている情報を受信するための公開メール受信トレイと、個別のユーザが要求したイベント情報、又は、別の個別のユーザが当該個別のユーザへ送信されることを要求したイベント情報を受信するため当該個別のユーザに関連付けられた個人メール受信トレイと、を含む、第１８項記載のシステム。

（２１） 共有設計情報を追跡することができるように系譜及び履歴情報を含み、コンポーネントバージョンの由来を記述する、メタデータが更に設けられた第１項記載のシステム。

（２２） 集積回路を設計する方法であって、
デリバラブルタイプを定義し、
第１のコンポーネントタイプのコンポーネントに関連付けられた属性及び一部のデリバラブルタイプを指定して第１のコンポーネントタイプを定義し、
第１のコンポーネントタイプと関連付けられたクォリフィケーション標準規格を定義し、
デリバラブルタイプと関連付けられたクォリフィケーション質問を定義し、
第１のコンポーネントタイプの第１のコンポーネントを作成し、
第１のコンポーネントの第１のコンポーネントバージョンを作成し、
第１のコンポーネントタイプと関連付けられたデリバラブルタイプのデリバラブルバージョンを作成し、
デリバラブルバージョンの適格性を審査し、
第１のコンポーネントバージョンの適格性を審査する、
方法。

（２３） 第２のコンポーネントのコンポーネントと関連付けられる属性及び一部のデリバラブルタイプを指定して第２のコンポーネントタイプを更に定義し、
第２のコンポーネントタイプと関連付けられたクォリフィケーション標準規格を定義し、
第２のコンポーネントタイプの第２のコンポーネントバージョンを作成し、
第２のコンポーネントバージョンの一部として第１のコンポーネントバージョンをインスタンス化し、これにより、第１のコンポーネントバージョンを再利用する、
第２２項記載の方法。

（２４） 第１のコンポーネント階層を記述する第２のコンポーネントと関連した情報を維持する、第２３項記載の方法。

（２５） デリバラブルタイプのデリバラブルバージョンを作成することに関連付けられたタスクリストを含むフローを作成し、
タスクリストは各タスクの要求された入力及び出力を表し、
各入力及び出力はデリバラブルタイプと関連付けられている、
第２２項記載の方法。

本発明の実施例を具体化するシステムを例示するブロック図である。 本発明の実施例によるメモリ用のコンポーネントタイプのテーブルの説明図である。 本発明尾実施例による命令のセットが格納された機械読み取り可能な媒体を含むコンピュータシステムの説明図である。

Claims (1)

1. コンポーネントを含む設計資産を異なる回路設計の間で共有する、コンピュータシステムで使用されるオブジェクト指向方法であって、
   前記コンピュータシステムは、１つ以上のコンピュータワークステーションと、該コンピュータワークステーションにネットワークを介して接続された保管サーバ及びメタデータデータベースとを有し、当該方法は、
   （ａ）コンピュータワークステーションのユーザインターフェースを使って、コンピュータの人的オペレータにより、コンポーネントを用意するステップであって、
   前記コンポーネントは、所定のコンポーネントタイプの内の何れかのタイプに該当し、設計ファイル及びメタデータにより指定され、
   前記設計ファイルは、該タイプの回路要素の物理的設計内容を規定する文書を少なくとも含み、
   前記メタデータは、前記コンポーネントの検索に使用される属性名を少なくとも含み、該属性名は所定のリストの中から選択され、
   前記設計ファイルは前記保管サーバに格納され、前記メタデータは前記メタデータデータベースに格納される、ステップと、
   （ｂ）システム管理者が作成した質問リストの各質問に前記人的オペレータが回答することで、第１の回路設計に使用されたコンポーネントが、該コンポーネントのタイプに共通の適格性基準に合致しているか否かを判定し、合致していた場合、該コンポーネントは前記コンピュータシステムで再利用可能である、ステップと、
   （ｃ）コンピュータワークステーションのユーザインターフェースを使って、前記第１の回路設計と少なくとも一部が異なる第２の回路設計を行う人的オペレータが、前記メタデータとともにコンポーネントを検索するステップと、
   （ｄ）前記第１の回路設計に使用され且つ前記検索するステップで発見されたコンポーネントを、前記第２の回路設計に使用するステップと、
   を有するオブジェクト指向方法。

Images