(57)【特許請求の範囲】
【請求項１】
複数の論理回路構成ブロックを接続することによって構成される論理集積回路の構成ブロックの入出力信号の仕様に対する正しさを検査するインタフェース検査ブロックの合成に用いるための合成可能なハードウエア動作記述を生成するハードウエア記述生成方法であって、該インタフェース検査ブロックの合成の対象とするブロックのクロック・サイクル精度のタイミング・インタフェース情報を読み込み、構文を解析するステップと、タイミング・インタフェース情報を非決定性有限状態機械に変換するステップと、非決定性有限状態機械を決定性有限状態機械に変換するステップと、決定性有限状態機械を簡単化するステップと、簡単化された決定性有限状態機械の動作を表すハードウエア記述を生成するステップとを有することを特徴とするハードウエア記述生成方法。
【請求項２】
前記簡単化された決定性有限状態機械の状態数を複雑さの指標とし、複雑さに応じて課金する請求項１に記載のハードウエア記述生成方法。
【請求項３】
前記簡単化された決定性有限状態機械の状態数を複雑さの指標とし、通信回線を通じて該指標を課金情報管理機関に送信し、該課金情報管理機関から認証情報を受信したことを確認した上でインタフェース検査ブロックの合成に用いるための合成可能なハードウエア動作記述を生成する請求項１に記載のハードウエア記述生成方法。
【請求項４】
前記複雑さの指標を通信回線を通じて課金情報管理機関に送信し、該課金情報管理機関では送信された複雑さの指標に基づいて課金情報を生成し、課金し、認証情報を返信する請求項３に記載のハードウエア記述生成方法。
【請求項５】
複数の論理回路構成ブロックを接続することによって構成される論理集積回路の構成ブロックの入出力信号の仕様に対する正しさを検査するインタフェース検査ブロックの合成に用いるための合成可能なハードウエア動作記述を生成するハードウエア記述生成方法であって、該インタフェース検査ブロックの合成の対象とするブロックのクロック・サイクル精度のタイミング・インタフェース情報を読み込み、構文を解析するステップと、タイミング・インタフェース情報内の機能ごとにタイミング・インタフェース情報を非決定性有限状態機械に変換するステップと、機能ごとの非決定性有限状態機械を機能ごとの決定性有限状態機械に変換するステップと、機能ごとの決定性有限状態機械を簡単化するステップと、機能を一覧表示するステップと、一覧された機能からユーザに機能を選択させるステップと、ユーザが選択した全ての機能の決定性有限状態機械を一つの新たな非決定性有限状態機械に合成するステップと、一つに合成された非決定性有限状態機械を決定性有限状態機械に変換するステップと、該決定性有限状態機械を簡単化するステップと、簡単化された一つに合成された決定性有限状態機械の動作を表すハードウエア記述を生成するステップとを有することを特徴とするハードウエア記述生成方法。
【請求項６】
前記機能ごとに簡単化された決定性有限状態機械の状態数をその機能の複雑さの指標とし、複雑さに応じて機能ごとの課金情報を生成するステップと、機能を一覧表示する際、機能ごとに課金情報を伴って表示するステップと、ユーザが選択した機能の課金情報を総計して課金するステップとを有する請求項５に記載のハードウエア記述生成方法。
【請求項７】
前記機能ごとに簡単化された決定性有限状態機械の状態数を複雑さの指標とし、通信回線を通じてユーザによって選択された機能の該指標を課金情報管理機関に送信するステップと、該課金情報管理機関から課金情報を受信するステップと、機能を一覧表示する際、機能ごとに課金情報を伴って表示するステップと、ユーザが選択した機能を該課金情報管理機関へ送信するステップと、該課金情報管理機関から認証情報を受信するステップと、認証情報を受信したことを確認した上でインタフェース検査ブロックの合成に用いるための合成可能なハードウエア動作記述を生成する請求項５に記載のハードウエア記述生成方法。
【請求項８】
前記複雑さの指標を通信回線を通じて課金情報管理機関に送信し、該課金情報管理機関では送信された複雑さの指標に基づいて課金情報を生成し、課金し、認証情報を返信する請求項７に記載のハードウエア記述生成方法。
【請求項９】
前記通信回線として交換通信網、インターネット、専用回線のいずれかを利用する請求項３または７に記載のハードウエア記述生成方法。
【請求項１０】
前記課金情報管理機関にユーザ認証機構を持つ請求項３、７、および９のいずれかに記載のハードウエア記述生成方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は複数の論理ブロックにより構成される論理集積回路やシステムＬＳＩ、及びその設計方法、及びその量産方法に関わる。
【０００２】
【従来の技術】
従来、論理集積回路やシステムＬＳＩを設計する際、いくつかの機能ブロックに分割し、ブロックごとに設計し、全体を結合することにより設計する方法が用いられている。近年、予め設計しておいた機能ブロック、すなわちＩＰ（Intellectual Property）を再利用する設計手法も知られている。さらにＩＰは自社で設計したもののみならず、他社から購入することもある。
【０００３】
機能ブロックを組み合わせてシステム全体を構築する際、機能ブロックの入出力信号のやり取りをインタフェースと呼び、機能ブロックを正しく機能させるためにはそのインタフェース仕様に適合した信号を入出力する必要がある。機能ブロックに入出力される信号がそのインタフェース仕様に適合しているか否かを判定する方法として、システムＬＳＩ全体の論理シミュレーションを行う際、機能ブロックの入出力信号を監視し、仕様とつき合わせて正しいか否かを論理シミュレーション中に判定するブロックを論理シミュレーション・モデルに付加し、これを合わせて論理シミュレーションを行う方法が知られている。
【０００４】
一方、機能ブロックのインタフェース仕様を記述する方法として、例えば、特開２０００−１２３０６４がある。この発明では機能ブロックのインタフェース信号の信号値の組合せをアルファベットとし、そのインタフェースをアルファベットの系列の集合として定義する。系列の表現方法及びその集合の表現方法として正規表現を用いることにより、小さな記述量で多彩なインタフェースの表現を可能としている。以下ではこの記法を特開２０００−１２３０６４のインタフェース記法と呼ぶ。
【０００５】
また、ＬＳＩに製造上の不良や製造後の故障がないかを調べる手法として組込み自己テスト（ＢＩＳＴ:Build-In Self Test）やオンライン・テストという手法が知られている。これは、ＬＳＩ自身にそのＬＳＩが正しく動作しているか否かをテストする機能を持たせる手法である。組込み自己テストは通常の動作とは異なるテスト専用の動作モードを設け、ＬＳＩをこのモードにして動作させることにより、故障の有無を判定する。一方、オンライン・テストでは、通常の動作中に故障の有無を判定する機能を持つ。これらによりＩＰそのものに故障がある場合は摘出することができる。
【０００６】
【発明が解決しようとする課題】
複数の機能ブロックを組み合わせてシステムＬＳＩ全体を構成し、その機能を検証する際、従来、論理シミュレーションを用いているが、論理シミュレーションには膨大な時間が必要であり、全ての機能を検証しきれないという問題がある。このため、ＬＳＩ製造後にＬＳＩが誤動作する危険性が残される。ＬＳＩが誤動作したとき、ＬＳＩの誤動作の原因がどこにあるのかを特定し、修正する必要がある。このとき、ある機能ブロックが期待通りの動作をしていないと思われる場合、機能ブロックの設計不良なのか、機能ブロックの使用方法を間違えたことにより、機能ブロックの仕様外の動作をひき起こしたのかを特定し、修正すべき対象が機能ブロックなのか、機能ブロックを使用している機能ブロック外部なのかを判断する必要がある。
【０００７】
このため、ＬＳＩの製造以前に行う論理シミュレーションにおいて、機能ブロックのインタフェースに現れる信号を監視し、機能ブロックの仕様通りに入出力信号がやりとりされているかを検査する、インタフェース検査ブロックを付加して論理シミュレーションを実施することが行われるが、上述の通り、論理シミュレーションに多大な時間を要するため、起こりうる全ての論理パターンについての論理シミュレーションを実施することは不可能である。そのため、インタフェースの検査も完全とはいえない。
【０００８】
一方、このインタフェース検査ブロックは論理シミュレーションの効率を向上させるため、ＬＳＩ内に実装するための論理合成を無視し、シミュレーションの効率のみに着目した記述が用いられている。そのため、この記述に対応した論理回路をＬＳＩ内に組み込むことができず、従って、製造後のシステムＬＳＩに含まれる設計不良が、上述した機能ブロックの不良なのか、機能ブロックを使用している機能ブロック外部の不良なのかを弁別して判断する手段がなかった。
【０００９】
本発明の課題は、システムＬＳＩが製造後に誤動作を起こしたときに機能ブロックそのものに設計不良があるのか、機能ブロックの使用法が誤っているのかを判断する手段を与えることである。
【００１０】
また、前述の通り、システムＬＳＩ製造後の誤動作を摘出する手段としてＢＩＳＴやオンライン・テストがあるが、これらが用いるテストデータは設計データを元に作られる。このため、設計不良があり、設計データそのものに誤りがある場合も、テストデータはそれが正しいものと考えて作成されるため、ＢＩＳＴやオンライン・テストでは設計不良に起因する誤動作を摘出できないという問題がある。
【００１１】
【課題を解決するための手段】
機能ブロックのインタフェース仕様記述を入力として、その機能ブロックの入出力信号がその仕様を満たしているか否かを判定するインタフェース検査ブロックを、論理合成可能なハードウェア記述で生成することにより、製造後のシステムＬＳＩ内にインタフェース検査ブロックを作りこむことのできる手段を提供する。
【００１２】
【発明の実施の形態】
図１は本発明の一実施例を説明するための図である。図１において、６０は本発明の対象となる半導体集積回路を示す。この例では、半導体集積回路６０は機能ブロック（ＩＰ）６０1および６０2が集積された形で模式的に示され、両者の間で信号のやり取りがなされるとともに、周辺に、適宜、入出力ピンが配置されている。図では、ＩＰ６０1は設計データＡを基礎に設計されたものであり、ＩＰ６０2は設計データＢを基礎に設計されたものであることを示すためにそれぞれの設計データの記憶装置５０および９０から各ＩＰ向きに太い矢印が描かれている。半導体集積回路６０には、さらに、本発明の特徴とする設計データＡのインタフェース・チェッカ７０が集積される。この構成については、後述するが、この実施例では、ＩＰ６０1の不良なのか、ＩＰ６０1を使用している機能ブロック外部の不良なのかを弁別して判断することを目的とした例とされているので、インタフェース・チェッカ７０は設計データＡのインタフェース・チェッカとされる。８０はインタフェース・チェッカ７０による合否判定を外部に知らせるための外部出力ピンである。
【００１３】
１０は設計データＡのインタフェース記述を格納した記憶装置、２０は合成可能インタフェース・チェッカ生成プログラム、３０は合成可能インタフェース・チェッカのハードウェア記述を格納した記憶装置である。４０は論理合成プログラムであり、記憶装置３０のハードウェア記述から論理構成を合成する。ここで記憶装置５０に格納されている設計データＡは記憶装置１０に格納されている設計データＡのインタフェース記述を基礎に作成されるものである。
【００１４】
前述の設計データＡのインタフェース・チェッカ７０は、半導体集積回路６０内に作りこまれた論理回路からなるものである。この論理回路は、記憶装置１０に格納された設計データＡのインタフェース記述を基礎として、合成可能インタフェース・チェッカ生成プログラム２０により生成されるインタフェース・チェッカのハードウェア記述から、論理合成プログラム４０により生成されるものである。ここで「合成可能」と言うのは、論理回路によるハードウエアとして生成できると言う意味である。これは、本発明のインタフェース・チェッカが、従来のインタフェース検査ブロックは論理シミュレーションの効率を向上させるため、ＬＳＩ内に実装するための論理合成を無視し、シミュレーションの効率のみに着目した記述であったのに反し、ＬＳＩ内に組み込めるものであることを意味する。
【００１５】
インタフェース記述１０は設計データＡのインタフェースを表すデータである。データの記述に用いる言語によって表現は異なるが、例えば前述の特開２０００−１２３０６４のインタフェース記法などを用いる。インタフェース記述１０に含まれる一つのインタフェース機能の例を図９に示す。通常、インタフェース記述が表すのは図９のようにクロックに同期したタイミング情報である。図９は、メモリの読み出しを実行する際の各信号のクロックごとの変化の様子を表しているが、図９が表すのはあくまでプロトコルを制御する各信号の変化状況のみであり、この信号変化状況からだけでは、メモリの読み出しという機能が実現されることは分からない。ただし、設計データＡがこのインタフェースに則った動作を行うことは分かるため、設計データＡと信号をやり取りする設計データＢもまたこのインタフェースを実現している必要がある。
【００１６】
インタフェース記述１０には、図９に示すような、設計データＡが実現しているあらゆるインタフェース機能が記載されている。合成可能インタフェース・チェッカ生成プログラム２０は、このインタフェース記述１０を読み込み、合成可能インタフェース・チェッカのハードウェア記述を生成、出力する。このハードウェア記述は記憶装置３０に格納される。合成可能インタフェース・チェッカのハードウェア記述とは、論理合成プログラム４０で論理合成できる範囲のハードウェア記述であり、設計データＡの入出力信号を監視し、設計データＡのインタフェース記述１０と合致しているか否かを判定する機能が記述されている。なお、論理合成可能な範囲のハードウェア記述とは、例えばIEEE Standard for VHDL Register Transfer Level (RTL) Synthesis, IEEE Std 1076.6-1999に定義されている。インタフェース・チェッカ生成プログラム２０の内容については後述する。
【００１７】
記憶装置３０に格納された合成可能インタフェース・チェッカのハードウェア記述は、論理合成プログラム４０により、ハードウェアとして実現されるゲートレベル記述へと合成される。これにより、設計データＡのインタフェース・チェッカをハードウェアの中に実装することが可能となり、インタフェース・チェッカ７０を持つＬＳＩ６０を実現できる。インタフェース・チェッカ７０は、設計データＡのインタフェース記述１０と合致しない波形が設計データＡの入出力信号に現れたとき、それを外部に知らせるために外部出力ピン８０をドライブする。この値は正常動作時の値を０とすれば、異常時の値を１とすればよい。
【００１８】
一方、図２に示すように、記憶装置３０に格納された合成可能インタフェース・チェッカのハードウェア記述はそのままシミュレーション可能な記述でもあるため、記憶装置１００に格納されたテストベンチ記述と記憶装置５０に格納された設計データＡ、記憶装置９０に格納された設計データＢとともに、論理シミュレータ／論理エミュレータ用モデルにより論理シミュレーションを実行することもできる。また、従来、インタフェース・チェッカはシミュレーションの効率を重視するため合成可能性が無視されたものであったため、専用ハードウェアである論理エミュレータ用の実行モデルとしては使用できなかったが、本発明では、合成可能インタフェース・チェッカのハードウェア記述は論理回路として合成可能であるため、論理エミュレータ用実行モデルに組込むこともでき、高速な論理検証が可能となる。
【００１９】
次に合成可能インタフェース・チェッカ生成プログラム２０の内容を説明する。最も簡単な場合のフローの実施例をパッド図で図３に示す。プログラム２０は、まずインタフェース記述１０を読みこみ構文解析を行う（ステップ３０１）。インタフェース記述１０に記述されるべき情報は、下記の通りである。
（１）：インタフェースに使用される信号名の宣言。
（２）：各信号の方向（入力方向か、出力方向か、双方向か）。
（３）：各信号の幅（ビット数）。
（４）：クロック信号の指定。
（５）：制御信号の指定。
（６）：データ信号の指定。
（７）：機能名。
（８）：機能ごとの、制御信号の値のクロック・サイクルごとの系列。
（９）：機能ごとの、データ信号の有効なクロック・サイクルの範囲の指定と、双方向の場合は信号の方向。
【００２０】
例えば特開２０００−１２３０６４のインタフェース記法はこれを満たす。特開２０００−１２３０６４のインタフェース記法を用いると、例えば図９の波形は図１０のように表現される。図１０では図９の波形にｂｙｔｅ＿ｒｅａｄという名称をつけて表現している。インタフェース記述には様々な記法が考えられるが、本発明の実施では、上記（１）ないし（９）の内容を持つ記述であれば他の記法でも構わない。
【００２１】
図９および図１０では単純なメモリのインタフェースのうち、読み出し動作について記述しており、メモリ読み出し時の各信号の取るべき値を時系列に沿って示している。
【００２２】
プログラム２０は図１０のインタフェース記述を読みこみ構文解析を行う。以下の説明では、出力する合成可能インタフェース・チェッカ記述にVerilogハードウェア記述言語を用いるが、他の言語でも同等の記述が可能である。まず、alphabetに記載された各信号値をそれぞれalphabet名をマクロ名に用いてマクロ記述を生成する。たとえば、図１０において、NOPというalphabetは次の信号値の組合せを表している。
clk = posedge, rst_n = 1, en_n = 1, rw = *,
addr = *, wait_n = 1, d = Z
これをVerilogハードウェア記述言語のマクロに変換すると次のようになる。
｀define NOP(nstate) if ((clk == 1’b1) && (rst_n == 1’b1) && (en_n == 1’b1) && (wait_n == 1’b1)) begin state <= nstate; end else
ここで、信号値posedgeは０から１への立上りを示すが、マクロでは変化後の値１を記述する。posedgeは原則として、port部でclock属性の信号に対してのみ許される。また、マクロ中には信号値が＊やＺの信号は記述しない。全てのalphabetに対してマクロを生成し終わったら、特別なマクロREJECTを下記のように生成しておく。
｀define REJECT begin reject <= 1’b1; state <= ｀reject_state; end
また、有限状態機械の状態もマクロで定義しておく。このとき、特別な状態を表すマクロ名initial_stateを値０、reject_stateを全ビット１の値として定義する。すなわち、例えば図１２の有限状態機械であれば、５状態であるので、上記の特別な２状態を合わせて７状態であるから、３ビットあればよいので、
｀define initaial_state 3’h0
｀define reject_state 3’h7
｀define s1 3’h1
｀define s2 3’h2
以下同様に
｀define s5 3’s5
となる。以上の結果を図１３に示す。なお、マクロを使用するのは、後で人の目で読みやすくするためであり、マクロを展開した記述をはじめから生成してもよい。
【００２３】
インタフェース記述のword部は正規表現であるため、等価な非決定性の有限状態機械に変換することができ、例えば図１０の記述を非決定性の有限状態機械に変換する（ステップ３０２）と図１１のようになる。この有限状態機械は一つの入力系列に対して複数の経路があり得る非決定性であるため、これを決定性の有限状態機械に変換（ステップ３０３）し、簡単化する（ステップ３０４）。正規表現から非決定性の有限状態機械に変換したり、非決定性の有限状態機械から決定性の有限状態機械に変換したり、簡単化するアルゴリズムは、例えば岩波書店「岩波講座情報科学  ６オートマトン・形式言語理論と計算論」に記載されている。ただし、簡単化は有限状態機械の動作を変えるわけではないので、実施してもよいし実施しなくともよい。図１１の非決定性有限状態機械を決定性有限状態機械に変換し、簡単化すると図１２に示す有限状態機械となる。
【００２４】
決定性有限状態機械はVerilogハードウェア記述言語などのハードウェア記述言語やＣ言語などのソフトウェア・プログラミング言語に容易に変換できる。
【００２５】
以下ではVerilogハードウェア記述言語を例にとり、図１０のインタフェース記述から図１３のハードウェア記述言語表現への変換の方法を詳細に記す。
【００２６】
図１２の決定性有限状態機械を、図１３のマクロ定義を使用してVerilogハードウェア記述言語で表したものを図１４に示す。まずalphabet部の記述からマクロを作成する部分については既に述べた。これにより図１３のマクロ定義が生成される。
【００２７】
次にmodule本体の作成方法を述べる。モジュール名はインタフェース記述のinterface宣言部の名前を用いる。ポート信号として、インタフェース記述のport宣言部の信号の全てとrejectを並べる。例えば、図１０では、clk、rst_n、rw、en_n、addr、wait_n、dの７つの信号が記述されているので、モジュール名とポート信号を並べて書くと、
module simple_memory(clk, rst_n, rw, en_n, addr, wait_n, d, reject);
となる。次に、同じくport宣言部の信号を全てinputとして並べる。これにより次の行が生成される。
input clk、rst_n、rw、en_n、addr、wait_n、d;
さらに、この記述で幅を持たない信号はwire型、幅を持つ信号（ここではaddrとd）はwire [n:m]型とする。ただし、n、mはport宣言部で宣言された通りの値（ここではaddrもdもnが７、mは０）とする。これにより次の行が生成される。
wire clk, rst_n, rw, en_n, wait_n;
wire[7:0] addr, d;
次に状態を保持するレジスタstateを宣言する。この際、ビット幅を有限状態機械の状態数に２を加えた値の２を底とする対数より小さくない最小の整数とする。図１２の有限状態機械では５状態であるから、５＋２＝７の２を底とする対数より小さくない最小の整数は３であるから、
reg [2:0] state;
となる。
【００２８】
次にインタフェースに従わない信号が現れたことを表す信号rejectをoutputおよびregで宣言する。この信号は図１あるいは図２のピン８０に出力される信号となる。
output reject;
reg reject;
さらに、モジュール内部の動作記述を作成する。このモジュールに含まれるプロセスは一つだけであり、portでクロック属性で宣言された信号の値が、alphabetでposedgeの場合はクロックの立上り変化ごとに、negedgeの場合はクロックの立下り変化ごとに実行する。図１０のインタフェース記述の場合はposedgeであるから、
always @(posedge clk) begin
を生成する。alphabetがnegedgeの場合は、上文のposedgeをnegedgeに変更すればよい。
【００２９】
次に、状態遷移の動作を表す記述を生成する。有限状態機械は状態に応じて動作が変わるため、まず状態をチェックする記述を生成する。
case(state)
次に、初期状態の動作を記述するが、図１２の有限状態機械の初期状態１とは異なる初期状態｀initial_stateを作成する。ただし、この初期状態を始点とする遷移は、図１２の初期状態１を始点とする遷移と同じとする。すなわち、図１２の初期状態１はalphabet RSTにより状態２へ遷移するため、
初期状態｀initial_stateもalphabet RSTにより状態２へ遷移するようにする。
この状態｀initial_stateを終点とする遷移は存在しない。
この状態｀initial_stateの動作は出力信号rejectを値０に初期化することである。以上から、図１３のマクロを用いると、次の文が生成できる。
｀initial_state: begin
reject <= 1’b0;
｀RST(｀s2)
begin end
end
次に、図１２の有限状態機械の各状態について状態遷移を記述する。これは各状態について、各状態を始点とする遷移を記述し、最後にマクロ｀REJECTを記述することで達成される。例えば、状態２であれば、alphabet RST、NOPで状態２へ、RREQであれば状態３へ遷移するので、次のようになる。
｀s2: begin
｀RST(｀s2)
｀NOP(｀s2)
｀RREQ(｀s3)
｀REJECT
end
全ての状態に対して記述を生成した後、次の行を生成する。
default: begin
state <= ｀initial_state;
reject <= 1’b0;
end
以上でこのプロセス、及びモジュールの動作の記述を終わるため、最後に
end
endmodule
を生成して、記述を完了する。すなわち、決定性有限状態機械の動作をチェックするハードウエア記述への変換（ステップ３０５）ができる。
【００３０】
このようにして、図１２の有限状態機械から図１３のマクロ定義、及び図１４の動作記述が生成できる。なお、図１４の動作記述は合成可能である。
【００３１】
以上により、インタフェース記述から合成可能なインタフェース・チェッカを生成することができる。
【００３２】
本発明はインタフェース・チェッカを内蔵したＬＳＩの製造、販売のビジネスのみならず、合成可能インタフェース・チェッカのハードウエア記述を提供するビジネスとしても展開することができる。すなわち、ＬＳＩの製造、販売を業とするもの（以下ユーザと言う）に対して提供できる設計データあるいは設計データインタフェースを提示し、これに対応してユーザが希望する設計データのインタフェースを明示して要求するときには、設計データに対応する合成可能インタフェース・チェッカのハードウエア記述を提供することにより、ユーザから対価を得るビジネスとすることができる。勿論、提供者側は対応できる設計データあるいは設計データインタフェースのラインナップをユーザに提示してユーザが欲している設計データあるいは設計データインタフェースを指定できるようにするのが良い。
【００３３】
先に、図３に例示したように、記述されるべき情報を持つインタフェース記述は合成可能インタフェース・チェッカ生成プログラムにより合成可能インタフェース・チェッカのハードウエア記述を得ることができるから、インタフェース記述の複雑さ、言い換えれば、ユーザに提供される合成可能インタフェース・チェッカのハードウエア記述の複雑さに対応してユーザに課金するビジネスとすることができる。
【００３４】
一般に、プログラムを販売する場合には、プログラム単位に課金されているが、本発明のプログラムの場合には、生成されるインタフェース・チェッカの動作が複雑なほど自動的に生成される合成可能インタフェース・チェッカのハードウエア記述の恩恵をユーザが得ることになる。従って、生成される記述の複雑さに応じて、プログラムの使用料金を得ることとするビジネスが成り立つ。課金方法の一つの実施形態として、生成したインタフェース・チェッカの行数、あるいは生成したインタフェース・チェッカの実現している有限状態機械の状態数を複雑さの指標とした課金を行うビジネスとすることができる。
【００３５】
図４は、図３のプログラムに、ユーザに設計データのインタフェースに対応して生成される合成可能インタフェース・チェッカのハードウエア記述を提供するための課金を行う機能を組込んだ場合の本発明の実施例としてのプログラムの処理手順を表すパッド図である。４０１から４０４は、図３で説明したインタフェース記述の読み込み、構文解析から決定性有限状態の簡単化のステップである。４０５は簡単化された決定性有限状態機械の状態数を数え状態数が多いほど課金を多くする課金のためのステップ、４０６は、図３で説明した決定性有限状態機械の動作をチェックするハードウエア記述への変換（ステップ３０５）に対応するステップである。この実施例では、合成可能インタフェース・チェッカのハードウエア記述の複雑さに応じた代価で提供することができる。プログラム中に課金機能を組込んだ場合、料金体系の変更を行うには、料金情報をプログラム外のファイルに保持しておき、そのファイルを置き換えることとするのが簡便である。
【００３６】
図５は本発明の他の実施例を示すフロー図で、課金機能を専門とする課金認証プログラムを別に作成した例である。この実施例によれば料金体系の変更について考慮する必要は無く課金認証プログラムに任せておける。
【００３７】
合成可能インタフェース・チェッカ生成プログラム５００は、図４で説明したステップ４０５の課金の処理が課金認証プログラム５２０との通信に置換された点を除き、全体としては同じである。すなわち、インタフェースの記述の読み込み・構文解析（ステップ５０１）、非決定性有限状態機械への変換（ステップ５０２）、決定性有限状態機械への変換（ステップ５０３）、決定性有限状態機械の簡単化（ステップ５０４）を経て、合成可能ハードウエア記述を生成する（ステップ５０５）。図４に示す実施例では、合成可能インタフェース・チェッカ生成プログラム内に簡単化された決定性有限状態機械の状態数に応じた課金のためのステップ４０５を設けたのに対して、図５に示す実施例では、ステップ５０４で行なわれた決定性有限状態機械の簡単化の結果を評価して、複雑さ指標を計算するステップ５１１と、その指標を課金認証プログラム５２０へ転送するステップ５１２、及び、課金認証プログラム５２０から転送される認証情報を受信するステップ５１３に置き換えられる。課金認証プログラム５２０はインターネットや専用回線などの通信回線を通して合成可能インタフェース・チェッカ生成プログラム５００と交信し、合成可能インタフェース・チェッカ生成プログラム５００から送られてきた複雑さ指標を受信するステップ５２１と、その複雑さを元に課金情報を生成するステップ５２２と、実際の課金を行うステップ５２３と、課金を終了したことを確認し、実際の合成可能インタフェース・チェッカ記述の生成を許可する認証情報を生成し、合成可能インタフェース・チェッカ生成プログラム５００へ転送するステップ５２４を持つ。このような構成をとることにより、課金情報をプログラム提供元あるいは課金サービス提供元で管理できるため、課金の変更を行い易くなる。
【００３８】
図６は、合成可能インタフェース・チェッカでチェックする機能を選択する手段をユーザに与える方法を示している。設計データのインタフェース記述は、機能ブロックのあらゆるインタフェース機能が記載されているが、その全てをインタフェース・チェッカでチェックする必要がない場合がある。そのような場合は、ユーザがチェックしたい機能のみを選択し、選択された機能のチェック機能のみを実現すれば、生成されるチェッカ記述の記述量も削減され、シミュレーション速度やＬＳＩとして実装する際の面積などのオーバヘッドを削減することができる。
【００３９】
図１０に示すように特開２０００−１２３０６４のインタフェース記法は、機能ごとに別々の正規表現で記述される。従って、機能ごとに有限状態機械に変換、簡単化することができる。このとき、機能一覧をユーザに提示し、ユーザに機能の選択する機会を与えることができる。選択された機能は、最終的には一つの合成可能インタフェース・チェッカにまとめる必要があるため、選択された機能の簡単化された有限状態機械を一つの有限状態機械にまとめ、さらに決定性有限状態機械へ変換し、再び簡単化した後、上述の変換方法に従って、合成可能インタフェース・チェッカの記述を生成すればよい。なお、複数の有限状態機械を一つにまとめるには、新たな状態を一つ初期状態として生成し、複数の有限状態機械の各初期状態へのイプシロン遷移を生成し、また、新たな状態を一つ終端状態として生成し、複数の有限状態機械の各終端状態から新たな一つの終端状態へのイプシロン遷移を生成すればよい。以上により、ユーザによる機能選択の手段が提供される。
【００４０】
図６において、６０１はインタフェース記述の読み込み・構文解析のステップ、６０２から６０４はインタフェース記述の機能ごとに行なわれる正規表現から非決定性有限状態機械への変換のステップ、非決定性有限状態機械から決定性有限状態機械への変換のステップおよび決定性有限状態機械の簡単化のステップである。６０５はインタフェース記述の機能の一覧表示のステップ、６０６はユーザによる機能の選択のステップである。６０７は選択された機能の非決定性有限状態機械を一つの非決定性有限状態機械に統合するステップであり、その生成方法の一例は上述した通りである。６０８および６０９は統合された一つの非決定性有限状態機械についての非決定性有限状態機械から決定性有限状態機械への変換のステップおよび決定性有限状態機械の簡単化のステップである。６１０は簡単化された決定性有限状態機械の動作をチェックするハードウエア記述への変換とユーザへの提供のステップである。
【００４１】
さらに、このプログラムの使用に課金する場合、図４に示したように最終的な簡単化された有限状態機械の状態数や最終的に生成されたハードウェア記述の行数を複雑さの指標として課金することも考えられるが、よりきめ細かく、選択した機能ごとに課金することもできる。その方法の一例を図７に示す。図７では、機能ごとに簡単化した決定性有限状態機械の複雑さ、すなわち状態数に応じて課金情報を生成し、機能一覧をユーザに提示する際、同時に機能ごとに課金情報も提示する。これにより、ユーザは課金情報を参照しながら機能を選択することができるようになる。図７において７０１から７０４は、図６におけるステップ６０１から６０４と同様に、インタフェース記述の読み込み・構文解析のステップから決定性有限状態機械の簡単化のステップである。７０５は簡単化された決定性有限状態機械の状態数に応じた課金情報を生成するステップである。７０６は、図６におけるインタフェース記述の機能の一覧表示のステップであるが、本実施例では、これに加えて課金情報も表示される。７０７は、図６におけるユーザによる機能の選択のステップである。７０７は選択された機能の分だけの課金を行なうステップである。７０９から７１２は、図６におけるステップ６０７から６１０と同様に、選択された機能の非決定性有限状態機械を一つの非決定性有限状態機械に統合するステップから簡単化された決定性有限状態機械の動作をチェックするハードウエア記述への変換とユーザへの提供のステップである。
【００４２】
図７の実施例の場合も、課金情報の生成をプログラム内では行わず、外部の課金認証プログラムに分離することができる。その場合の処理手順を図８に示す。図８の合成可能インタフェース・チェッカ生成プログラム８００は、大きな流れは図７の方法と同じであるが、各機能単位に機能ごとの複雑さの指標を基礎に課金情報を生成する処理を全ての機能について行うため繰り返しの処理をする形になっている点で、複雑になっているように見える。８０１はインタフェース記述の読み込み・構文解析のステップ、８０２は全ての機能の変換処理が完了したか否かを監視するステップであり、完了していないときはステップ８０２へ、完了したときはステップ８１０へ進めるものである。８０３はインタフェース記述の機能ごとに行なわれる正規表現から非決定性有限状態機械への変換のステップ、８０４は非決定性有限状態機械から決定性有限状態機械への変換のステップ、８０５は決定性有限状態機械の簡単化のステップである。８０６は機能単位の複雑さ指標を計算するステップ、８０７はその指標を課金認証プログラム９００へ転送するステップである。
【００４３】
課金認証プログラム９００はインターネットや専用回線などの通信回線を通して合成可能インタフェース・チェッカ生成プログラム８００と交信する機能を持つものであり、２段構成となっており、その前段は合成可能インタフェース・チェッカ生成プログラム８００から送られてきた複雑さ指標を受信するステップ９０１と、その複雑さを元に課金情報を生成するステップ９０２と、課金情報を合成可能インタフェース・チェッカ生成プログラム８００に転送するステップ９０３よりなる。
【００４４】
合成可能インタフェース・チェッカ生成プログラム８００は、転送された課金情報を受け取る（ステップ８０８）とステップ８０２に処理を戻す。ここで、上述したように、全ての機能についての変換処理が終わっているかどうかをチェックして、終わっていなければ、上述したステップ８０３からステップ８０８までの処理を繰り返す。終わっていれば、ステップ８１０に進み、ユーザに機能一覧を示す。８１１はユーザによる機能選択ステップである。ユーザにより機能が選択されると、図７におけるステップ７０９と同様の、非決定性有限状態機械に統合するステップ８２１に選択された機能についての情報を伝送するが、実際の合成操作は、図５で説明した認証情報受信のステップ５１３と同様、認証情報受信のステップ８２０の信号を待って行なわれることになる。一方、ユーザによる機能選択が行なわれると、ステップ８１２において選択された機能の情報が課金認証プログラム９００の後段の選択された機能の情報を受信するステップ９０４に送られる。課金認証プログラム９００は選択された機能に応じた課金処理を行い（ステップ９０５）、課金が正当に行なわれた旨の認証情報を合成可能インタフェース・チェッカ生成プログラム８００に転送する（ステップ９０６）。
【００４５】
認証情報が受信されると、図６で説明したステップ６０７から６１０と同様、ステップ８２１からステップ８２４までの過程を経て、簡単化された決定性有限状態機械の動作をチェックするハードウエア記述への変換とユーザへの提供が行なわれる。
【００４６】
以上に述べたいずれかの方法により、合成可能インタフェース・チェッカ記述が生成される。この記述は合成可能であるから、従来の方法により論理合成を行い、最終的なＬＳＩ内にその機能を実装できる。インタフェース・チェッカが実装されたＬＳＩは論理シミュレーションや論理エミュレーションによる模擬動作より高速に動作するため、このＬＳＩにより量産テストや突発不良テストを行うことにより、論理シミュレーションや論理エミュレーションでは検査し切れなかった設計不良を、量産出荷前に摘出したり、どの機能ブロックに不良が存在するかを特定したりすることが可能となる。
【００４７】
上述の実施例の図１、図２では、説明を簡単にするために、二つの設計データによる集積回路とし、この内の一つの設計データのインタフェースを基礎にインタフェースをチェックする機能についてのみ説明したが、図６から図８で説明したように、集積回路には、実際は多数の機能ブロックが集積されるから、前記インタフェース検査ブロックが論理回路構成ブロックごとに異なる指標を与えられるものとして、前記構成ブロックの各々の仕様で定められた入出力信号パタンに実際の入出力信号が適合しないブロックが発見されたとき、該ブロックの指標とともに、外部入出力ピンを通して仕様に適合しないことをユーザに知らせる機能を持たせることにより実用上充実した機能のインタフェース検査ブロックを持つ論理集積回路とできる。
【００４８】
なお、この合成可能インタフェース・チェッカ記述が実装されたＬＳＩが使用され、十分な検証も終了したと判断される時期に、インタフェース・チェッカを取り外し、より高速、より小さな面積のＬＳＩを製造することも可能となる。
【００４９】
【発明の効果】
システムＬＳＩが誤動作し、その原因が設計不良に起因するものだった場合、インタフェース・チェッカを回路内に実装しておく手段を提供することにより、どの機能ブロックに設計不良が存在するかを特定することが可能となる。これにより、不具合修正、保証の責任を明確にすることができる。
【図面の簡単な説明】
【図１】本発明の一実施例を説明するための図。
【図２】本発明の応用の構成を示す概念図。
【図３】本発明の実施例のフローを示すパッド図。
【図４】図３のプログラムに課金を行う機能を組込んだ実施例のフローを示すパッド図。
【図５】課金機能を専門とする課金認証プログラムを備える実施例を示すフロー示すパッド図。
【図６】合成可能インタフェース・チェッカでチェックする機能を選択する手段をユーザに与える実施例を示すフロー示すパッド図。
【図７】合成可能インタフェース・チェッカでチェックした機能ごとに課金する実施例を示すフロー示すパッド図。
【図８】課金情報の生成を外部の課金認証プログラムに分離した実施例を示すフロー示す図。
【図９】機能モジュールのインタフェース例を示す図。
【図１０】図９のインタフェースを持つ機能モジュールのインタフェース記述例を示す図。
【図１１】図１０のインタフェース記述を非決定性の有限状態機械に変換した状態遷移グラフの例を示す図。
【図１２】図１１の状態遷移グラフの簡単化された状態遷移グラフの例を示す図。
【図１３】図１０のインタフェース記述の合成可能なインタフェース・チェッカのマクロ定義部を示す図。
【図１４】図１３の定義に対応する合成可能なインタフェース・チェッカのハードウェア記述例を示す図。
【符号の説明】
１０：インタフェース記述を格納した記憶装置、２０：合成可能インタフェース・チェッカ生成プログラム、３０：合成可能インタフェース・チェッカのハードウェア記述を格納した記憶装置、４０：論理合成プログラム、５０：回路ブロックＡの設計データを格納した記憶装置、６０：半導体集積回路、７０：半導体集積回路中に集積された設計データＡのインタフェース・チェッカ、８０：インタフェース・チェッカの合否判定を外部に知らせるための外部出力ピン、９０：回路ブロックＢの設計データを格納した記憶装置、１００：テストベンチ記述を格納した記憶装置、２００，５００，８００：合成可能インタフェース・チェッカ生成プログラム、３０１，４０１，５０１，６０１，７０１，８０１：インタフェース記述の読み込み、構文解析機能、３０２，４０２，５０２，６０２，７０２，８０３：非決定性有限状態機械構築機能、３０３，４０３，５０３，６０３，６０８，７０３，７１０，８０４：決定性有限状態機械構築機能、３０４，４０４，５０４，６０４，６０９，７０４，７１１，８０５：決定性有限状態機械簡単化機能、４０５：簡単化された決定性有限状態機械の状態数に応じた課金機能、５１１：複雑さ指標計算機能、５１２：複雑さ指標転送機能、５１３，８２０：認証情報受信機能、３０５，４０６，５０５，６１０，７１２，８２４：合成可能ハードウェア記述生成機能、５２０，９００：課金認証プログラム、５２１：複雑さ指標受信機能、５２２，９０２：課金情報生成機能、５２３，９０５：課金機能、５２４，９０６：認証情報転送機能、８０２：機能単位繰り返し機能、８０６：機能単位の複雑さ指標計算機能、８０８：課金情報受信機能、８１０：機能一覧表示機能、８１１：機能選択機能、８１２：選択機能転送機能、６０７，７０９，８２１：決定性有限状態機械の合成機能、９０３：課金情報転送機能、９０４：選択機能受信機能。
【図１】
0004078435.tif 000002
【図２】
0004078435.tif 000003
【図３】
0004078435.tif 000004
【図４】
0004078435.tif 000005
【図５】
0004078435.tif 000006
【図６】
0004078435.tif 000007
【図７】
0004078435.tif 000008
【図８】
0004078435.tif 000009
【図９】
0004078435.tif 000010
【図１０】
0004078435.tif 000011
【図１１】
0004078435.tif 000012
【図１２】
0004078435.tif 000013
【図１３】
0004078435.tif 000014
【図１４】
0004078435.tif 000015