JP2018200634A - ＳｙｓｔｅｍＣモデル生成方法およびＳｙｓｔｅｍＣモデル生成プログラム - Google Patents

Abstract

【課題】ＨＤＬ動作モデルを論理回路設計に使えるようにすることができるＳｙｓｔｅｍＣモデル生成方法およびＳｙｓｔｅｍＣモデル生成プログラムの提供を図る。【解決手段】ＨＤＬのシミュレーション構文で設計したＨＤＬ動作モデルＢＭから、高位合成が可能なＳｙｓｔｅｍＣモデルＳＣＭを生成するＳｙｓｔｅｍＣモデル生成方法であって、前記ＨＤＬ動作モデルを解析して構文木モデルを生成し(ＰＡ)、前記構文木モデルを解析して解析情報(ＡＩ)を取り出し(ＰＭＡ０１，ＰＭＡ０２)、前記構文木モデルおよび前記解析情報に基づいて前記構文木モデルを再構成し(ＰＭＲ０１，ＰＭＲ０２)、前記ＳｙｓｔｅｍＣモデルを生成する(ＰＳＣＧ)。【選択図】図７

Description

本発明は、ＳｙｓｔｅｍＣモデル生成方法およびＳｙｓｔｅｍＣモデル生成プログラムに関する。

近年、例えば、ＬＳＩやＦＰＧＡ(Field-Programmable Gate Array)の論理回路を設計する場合、Ｖｅｒｉｌｏｇ−ＨＤＬやＶＨＤＬといったハードウェア記述言語(ＨＤＬ：Hardware Description Language)が利用されている。そして、ＨＤＬ(言語)によるレジスタ転送レベル(ＲＴＬ：Register Transfer Level)設計が主流になっている。

ＲＴＬ設計とは、ＨＤＬ言語を用いてレジスタ転送レベルの抽象度で設計したモデル(ＲＴＬモデル)を、論理合成ツールでゲートレベルのネットリスト(ゲート回路)に変換する設計手法のことである。ここで、ＨＤＬ言語でシーケンス処理回路を設計する場合、論理合成が可能なＲＴＬで設計するには、例えば、状態遷移回路(ステートマシン)と組み合わせ回路に分離した構造で設計を行う。

ところで、従来、ＨＤＬ言語によるＲＴＬ設計の手法としては、様々な提案がなされている。

特開２０１３−０２０３２９号公報

前述したように、ＨＤＬ言語によるＲＴＬ設計は、例えば、状態遷移回路と組み合わせ回路に分離した構造で設計を行うが、状態遷移回路のＲＴＬ設計は、論理が複雑になるため設計難易度が高く、設計に要する工数(時間および費用)が嵩むことになる。さらに、設計が複雑になると、それに伴って、不具合も生じ易いことにもなる。

また、ＨＤＬ言語のシミュレーション構文で設計した動作モデル(ＨＤＬ動作モデル)は、作成は容易に行えても、ネットリストに変換するための論理合成ツールは提供されておらず、動作モデルを使用してネットリストに変換するのは難しい。なお、本明細書において、ＨＤＬ動作モデルは、例えば、高位合成が可能なＳｙｓｔｅｍＣモデルを含まず、Ｖｅｒｉｌｏｇ−ＨＤＬやＶＨＤＬといった純然たるＨＤＬ言語のシミュレーション構文で設計した動作モデルとして使用している。

一実施形態によれば、ＨＤＬのシミュレーション構文で設計したＨＤＬ動作モデルから、高位合成が可能なＳｙｓｔｅｍＣモデルを生成するＳｙｓｔｅｍＣモデル生成方法が提供される。

前記ＳｙｓｔｅｍＣモデル生成方法は、前記ＨＤＬ動作モデルを解析して構文木モデルを生成し、前記構文木モデルを解析して解析情報を取り出す。さらに、前記ＳｙｓｔｅｍＣモデル生成方法は、前記構文木モデルおよび前記解析情報に基づいて前記構文木モデルを再構成し、前記ＳｙｓｔｅｍＣモデルを生成する。

開示のＳｙｓｔｅｍＣモデル生成方法およびＳｙｓｔｅｍＣモデル生成プログラムは、ＨＤＬ動作モデルを論理回路設計に使えるようにすることができるという効果を奏する。

図１は、論理回路設計手法の一例を模式的に示す図である。 図２は、図１に示す論理回路設計におけるＲＴＬ設計の一例を説明するための図(その１)である。 図３は、図１に示す論理回路設計におけるＲＴＬ設計の一例を説明するための図(その２)である。 図４は、動作レベル設計の一例を説明するための図である。 図５は、論理回路設計手法における課題を模式的に示す図である。 図６は、本実施形態に係るＳｙｓｔｅｍＣモデル生成方法を適用した論理回路設計手法の一例を模式的に示す図である。 図７は、本実施形態に係るＳｙｓｔｅｍＣモデル生成方法の全体構成を説明するためのフローチャートである。 図８は、ＳｙｓｔｅｍＣモデル生成方法の一実施例を説明するためのフローチャート(その１)である。 図９は、ＳｙｓｔｅｍＣモデル生成方法の一実施例を説明するためのフローチャート(その２)である。 図１０は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法のフローチャートにおけるそれぞれの処理内容を説明するための図である。 図１１は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法のフローチャートにおけるそれぞれの処理の依存関係を説明するための図である。 図１２は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法のフローチャートにおけるそれぞれの処理を説明するための図(その１)である。 図１３は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法のフローチャートにおけるそれぞれの処理を説明するための図(その２)である。 図１４は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法のフローチャートにおけるそれぞれの処理を説明するための図(その３)である。 図１５は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法のフローチャートにおけるそれぞれの処理を説明するための図(その４)である。 図１６は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法のフローチャートにおけるそれぞれの処理を説明するための図(その５)である。 図１７は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法のフローチャートにおけるそれぞれの処理を説明するための図(その６)である。 図１８は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法のフローチャートにおけるそれぞれの処理を説明するための図(その７)である。 図１９は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の一例を説明するための図(その１)である。 図２０は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の一例を説明するための図(その２)である。 図２１は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の一例を説明するための図(その３)である。 図２２は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の一例を説明するための図(その４)である。 図２３は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の一例を説明するための図(その５)である。 図２４は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の一例を説明するための図(その６)である。 図２５は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の一例を説明するための図(その７)である。 図２６は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の一例を説明するための図(その８)である。 図２７は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の一例を説明するための図(その９)である。 図２８は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の一例を説明するための図(その１０)である。 図２９は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の一例を説明するための図(その１１)である。 図３０は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の一例を説明するための図(その１２)である。 図３１は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の他の例を説明するための図(その１)である。 図３２は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の他の例を説明するための図(その２)である。 図３３は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の他の例を説明するための図(その３)である。 図３４は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の他の例を説明するための図(その４)である。 図３５は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の他の例を説明するための図(その５)である。 図３６は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の他の例を説明するための図(その６)である。 図３７は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の他の例を説明するための図(その７)である。 図３８は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の他の例を説明するための図(その８)である。

まず、本実施例のＳｙｓｔｅｍＣモデル生成方法およびＳｙｓｔｅｍＣモデル生成プログラムを詳述する前に、図１〜図５を参照して、論理回路設計手法の例およびその課題を説明する。

図１は、論理回路設計手法の一例を模式的に示す図である。図１に示されるように、論理回路設計手法の一例は、例えば、ＲＴＬモデル(レジスタ転送レベルモデル)１に対して論理合成ツール２を適用し、ネットリスト(ゲート回路)３に変換する。

ところで、現在、ＬＳＩやＦＰＧＡの論理回路設計は、Ｖｅｒｉｌｏｇ−ＨＤＬやＶＨＤＬといったＨＤＬ言語(ハードウェア記述言語)によるＲＴＬ設計(レジスタ転送レベル設計)が主流である。前述したように、ＨＤＬ言語でシーケンス処理回路を設計する場合、論理合成が可能なＲＴＬで設計するには、例えば、ステートマシンと組み合わせ回路に分離した構造で設計を行う。

図２および図３は、図１に示す論理回路設計におけるＲＴＬ設計の一例を説明するための図であり、図２(a)は、シーケンス処理のＲＴＬ設計の一例を示し、図２(b)は、ステートマシンを示す。また、図３(a)は、ＲＴＬで記述したステートマシンを示し、図３(b)は、ＲＴＬで記述した組み合わせ回路を示す。図２(a)に示されるように、この例では、リクエスト信号ｒｅｑを受信したら、６クロックのデータ信号ｄａｔａ『１００１１０』と、そのデータｄａｔａの最後にアクノリッジ信号ａｃｋを返す。

すなわち、図２(a)のＲＴＬ設計を行う場合、図２(b)のステートマシンで、図３(a)のｒｅｑを受信したら６クロック分をカウントするカウンタを設計し、図３(b)のカウンタの値に従って、出力するデータ値を定義する。

しかしながら、このステートマシンのＲＴＬ設計は、論理が複雑になるため設計難易度が高く、設計に要する時間および費用も嵩むことになり、さらに、設計が複雑になるのに伴って、不具合も生じやすくなる。すなわち、シーケンス処理のＲＴＬ設計を行う場合、考慮することが多くて面倒であり、また、分かり難いため、間違え易くて修正し難いといった課題がある。

図４は、動作レベル設計の一例を説明するための図であり、図４(a)は、前述した図２(a)と同様のものであり、図４(b)は、シーケンス処理の動作モデル設計の一例を示す。図４(b)に示されるように、例えば、ＨＤＬ動作モデル等の動作モデル設計は、図４(a)に示すタイムチャート(動作仕様)に基づいて、クロック毎の動作を定義すればよいため、簡単で分かり易く、間違え難くて修正し易いといった利点がある。すなわち、動作レベル設計は、シーケンス制御回路を容易に作成することができる。

図５は、論理回路設計手法における課題を模式的に示す図である。図５に示されるように、ＲＴＬモデル１は、論理合成ツール２を適用することにより、ネットリスト３に変換することが可能である。しかしながら、論理合成ツール２は、例えば、ＨＤＬ言語のシミュレーション構文には対応しておらず、ＨＤＬ言語のシミュレーション構文で設計した動作モデル４は、論理シミュレータ上では動作しても論理合成を行うのが困難であった。すなわち、動作モデル４は、論理合成ツール２を適用してネットリスト３に変換することが難しいといった課題がある。

以下、ＳｙｓｔｅｍＣモデル生成方法およびＳｙｓｔｅｍＣモデル生成プログラムの実施例を、添付図面を参照して詳述する。図６は、本実施形態に係るＳｙｓｔｅｍＣモデル生成方法を適用した論理回路設計手法の一例を模式的に示す図である。

図６と、前述した図１の比較から明らかなように、本実施形態のＳｙｓｔｅｍＣモデル生成方法およびＳｙｓｔｅｍＣモデル生成プログラムは、図６におけるＳｙｓｔｅｍＣモデル生成部４１に対応する。すなわち、ＳｙｓｔｅｍＣモデル生成部４１は、ＨＤＬ動作モデル(ＢＭ)４０からＳｙｓｔｅｍＣモデル(ＳＣＭ)４２を生成(変換)する。さらに、ＳｙｓｔｅｍＣモデル生成部４１は、合成スクリプト４３(ＳＳ)を生成してもよい。そして、ＳｙｓｔｅｍＣモデル４２および合成スクリプト４３に対して、高位合成ツール４４を適用することにより、ＲＴＬモデル１を生成する。なお、生成されたこのＲＴＬモデル１に対しては、前述した図１と同様に、論理合成ツール２を適用することで、ネットリスト３に変換(生成)することができる。すなわち、本実施形態のＳｙｓｔｅｍＣモデル生成方法およびＳｙｓｔｅｍＣモデル生成プログラムによれば、ＨＤＬ動作モデルを論理回路設計に使えるようにすることが可能になる。

ここで、ＳｙｓｔｅｍＣは、既に、提供および使用されており、Ｃ／Ｃ⁺⁺言語をベースにした言語による高位合成設計を行うためのものである。このＳｙｓｔｅｍＣは、例えば、純然たるＨＤＬであるＶｅｒｉｌｏｇ−ＨＤＬやＶＨＤＬに比べて、動作レベルモデリング等が、よりシステムに近寄った記述言語である。

本実施形態のＳｙｓｔｅｍＣモデル生成方法は、ＨＤＬのシミュレーション用構文で設計した動作モデルを、高位合成可能なＳｙｓｔｅｍＣモデルに変換(生成)するためのものである。そして、例えば、高位合成でＲＴＬに変換することにより、ＨＤＬ言語のシミュレーション構文で設計した動作モデルをネットリストに変換し、論理回路設計に活用することが可能になる。なお、本実施形態は、コンピュータのＬｉｎｕｘ（登録商標）やＷｉｎｄｏｗｓ（登録商標）等のＯＳ(Operating System)上で実行させるＳｙｓｔｅｍＣモデル生成プログラムとして提供することもできるのはいうまでもない。

そして、本実施形態のＳｙｓｔｅｍＣモデル生成方法およびＳｙｓｔｅｍＣモデル生成プログラムによれば、ＨＤＬ言語のシミュレーション構文で設計した動作モデルを論理合成の設計に使えるようにすることができる。その結果、シーケンス制御処理回路を、シミュレーション構文を用いた動作モデルで簡潔かつ容易に設計することが可能になり、例えば、ＲＴＬ設計と比較して、設計工数(設計期間および費用)の低減および不具合実装リスクの削減等を行うことができる。

図７は、本実施形態に係るＳｙｓｔｅｍＣモデル生成方法の全体構成を説明するためのフローチャートである。図７において、参照符号ＢＭはＨＤＬ動作モデル、ＳＦは設定ファイル、ＡＩは解析情報、ＳＣＭはＳｙｓｔｅｍＣモデル、そして、ＳＳは合成スクリプトを示す。これらＨＤＬ動作モデルＢＭ、設定ファイルＳＦ、解析情報ＡＩ、ＳｙｓｔｅｍＣモデルＳＣＭおよび合成スクリプトＳＳは、例えば、ＤＲＡＭ(Dynamic Random Access Memory)等のメモリに格納されて保持される。

ここで、ＨＤＬ動作モデルＢＭは、Ｖｅｒｉｌｏｇ−ＨＤＬやＶＨＤＬ等のＨＤＬ言語のシミュレーション構文で設計した動作モデルである。また、ＳｙｓｔｅｍＣモデルＳＣＭは、例えば、高位合成ツールを適用して論理合成可能なＲＴＬを生成(ＲＴＬモデルに変換)する高位合成が可能なものである。なお、図６および図１を参照して説明したように、ＲＴＬモデル(１)は、論理合成ツール(２)を適用することで、ネットリスト(３)に変換することができる。また、前述したように、ＨＤＬ動作モデルＢＭは、例えば、高位合成が可能なＳｙｓｔｅｍＣモデルを含まず、Ｖｅｒｉｌｏｇ−ＨＤＬやＶＨＤＬといった純然たるＨＤＬ言語のシミュレーション構文で設計した動作モデルを表している。

図７に示されるように、本実施形態のＳｙｓｔｅｍＣモデル生成方法は、ＨＤＬ動作モデルＢＭを解析して構文木モデルＳＴＭ０１を生成し(ＰＡ)、さらに、構文木モデルＳＴＭ０１，ＳＴＭ０２を解析して解析情報ＡＩを取り出す(ＰＭＡ０１，ＰＭＡ０２)。ここで、ＨＤＬ動作モデルＢＭを解析して構文木モデルＳＴＭ０１を生成する処理ＰＡは、ＨＤＬ動作モデルＢＭの字句および構文を解析して行う。

そして、構文木モデルＳＴＭ０１，ＳＴＭ０２および解析情報ＡＩに基づいて構文木モデルを再構成し(ＰＭＲ０１，ＰＭＲ０２)，再構成された構文木モデルＳＴＭ０２，ＳＴＭ０３を生成する。この構文木モデルおよび解析情報に基づいた構文木モデルの再構成処理(ＰＭＲ０１，ＰＭＲ０２)は、必要に応じて複数回行われ、最終的な構文木モデル(最終構文木モデル)ＳＴＭｆが生成される。

構文木モデルの再構成処理ＰＭＲ０１，ＰＭＲ０２，…は、それぞれの処理の依存関係に基づいた順番に従って構文木モデルＳＴＭ０１，ＳＴＭ０２，…の異なる解析情報ＡＩを取り出し、その異なる解析情報に基づいて構文木モデルの異なる再構成を行う。すなわち、構文木モデル(モデル)の再構成処理には、それぞれの処理に対する依存関係があるため、依存関係を考慮した処理の順番で、異なる内容のモデル解析処理とモデル再構成処理を実施する。

そして、最終構文木モデルＳＴＭｆを生成し、最終的なモデル解析を行って(ＰＭＡｆ)最終的な解析情報を取得し、その最終的な解析情報を使用してＳｙｓｔｅｍＣ(コード)を生成し(ＰＳＣＧ)し、ＳｙｓｔｅｍＣモデルＳＣＭを生成する。最終的なモデル解析処理ＰＭＡｆは、ＳｙｓｔｅｍＣコード生成に必要な情報の事前調査であり、例えば、高位合成時に問題のある記述のチェック等を行う。

なお、設定ファイルＳＦは、例えば、クロック、リセット信号およびメモリ指定といった様々なデータを含み、そのデータは、構文木モデルの再構成処理ＰＭＲ０１，ＰＭＲ０２等で使用されるだけでなく、合成スクリプトＳＳの生成処理ＰＳＳＧでも使用される。すなわち、合成スクリプトの生成処理ＰＳＳＧは、最終構文木モデルＳＴＭｆの情報および設定ファイルＳＦからの情報(様々なデータ)に基づいて、合成スクリプトＳＳを生成する。なお、ＳｙｓｔｅｍＣモデルＳＣＭ(４２)および合成スクリプトＳＳ(４３)に対して、高位合成ツール４４を適用することでＲＴＬモデル(１)を生成するのは、図６を参照して説明した通りである。

図８および図９は、ＳｙｓｔｅｍＣモデル生成方法の一実施例を説明するためのフローチャートであり、上述した図７に示すＳｙｓｔｅｍＣモデル生成方法の一例をより詳細に説明するためのものである。

まず、設定ファイルＳＦは、例えば、ユーザーが次のような情報を設定する。すなわち、設定ファイルＳＦの情報(データ)としては、例えば、入力ソースファイル、トップモジュール名、トップモジュールのクロック情報、トップモジュールのリセット情報、対象高位合成ツール、および、高位合成の合成制約等が含まれる。ここで、トップモジュールのクロック情報としては、ポート名および動作エッジ等であり、トップモジュールのリセット情報としては、ポート名、同期リセットか非同期リセットかの情報、および、極性等である。また、高位合成の合成制約としては、メモリの指定、および、その他の制約(例えば、クロック周期等)である。

次に、解析情報ＡＩとしては、アトリビュート情報ＡＩ１、モジュール情報(定義、入れ子関係)ＡＩ３、クロック／リセット情報ＡＩ５、および、タスク／ファンクション(ｔａｓｋ／ｆｕｎｃｔｉｏｎ)情報ＡＩ６１１が含まれる。さらに、解析情報ＡＩとしては、変数情報ＡＩ６１２、メモリ情報ＡＩ６２、および、信号線アクセス情報ＡＩ６３が含まれる。

アトリビュート情報ＡＩ１は、例えば、各アトリビュート記述について、アトリビュート名、値および適用対象等の情報を格納したテーブルとして形成することができる。また、モジュール情報ＡＩ３は、例えば、各モジュールについて、モジュール名、ポート情報、パラメータ情報、内部でインスタンスしているモジュールおよび抽象構文木内のノード等の情報を格納したテーブルとして形成することができる。

クロック／リセット情報ＡＩ５は、例えば、各モジュールについて、モジュール名、クロック信号名およびリセット信号名等の情報を格納したテーブルとして形成することができる。さらに、ｔａｓｋ／ｆｕｎｃｔｉｏｎ情報ＡＩ６１１は、例えば、各タスク／ファンクションについて、定義されているモジュール、名前、引数および戻り値の情報、並びに、抽象構文木内のノード等の情報を格納したテーブルとして形成することができる。

変数情報ＡＩ６１２は、例えば、各変数について、定義されているスコープ、変数名、種別および型情報等の情報を格納したテーブルとして形成することができる。ここで、種別としては、例えば、出力(ｏｕｐｕｔ)、入力(ｉｎｐｕｔ)、レジスタ(ｒｅｇ)および配線(ｗｉｒｅ)のどれかである。また、型情報としては、例えば、符号あり／なし、ビット幅、配列の次元数および配列の各次元の要素数等が含まれる。

メモリ情報ＡＩ６２は、例えば、メモリになる変数について、定義されているスコープ、変数名およびメモリ構成の情報を格納したテーブルとして形成することができる。ここで、メモリ構成としては、メモリのポート数およびレイテンシ等が含まれる。そして、信号線アクセス情報ＡＩ６３は、例えば、各プロセスについて、定義されているモジュール名、プロセス名、ライトしている信号線名およびリードしている信号線名の情報を格納したテーブルとして形成することができる。

図１０は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法のフローチャートにおけるそれぞれの処理内容を説明するための図である。図１０に示されるように、アトリビュート取得＆ノード削除処理ＰＭＲ１(ＰＭＡ１)では、アトリビュートの情報を取得し、構文木からは削除する。モジュール定義正規化処理ＰＭＲ２では、モジュール定義のポート宣言およびパラメータ(parameter)宣言の形式を合わせ、モジュール定義解析処理ＰＭＡ３では、モジュール定義の取得および各モジュールがインスタンスしているサブモジュールの取得を行う。

未使用モジュール削除処理ＰＭＲ３では、インスタンスされていないモジュール定義を構文木から削除し、インスタンス記述正規化処理ＰＭＲ４では、サブモジュールのインスタンスの形式を合わせる(ポート接続、および、パラメータオーバーライド等)。また、クロック／リセット解析処理ＰＭＡ５では、クロック信号およびリセット信号の特定を行う。ここで、トップモジュールのクロックおよびリセット信号は、設定ファイルＳＦから取得し、サブモジュールのクロックおよびリセット信号は、信号線の接続から取得する。

さらに、インスタンス記述修正処理ＰＭＲ５では、サブモジュールのインスタンス記述の変更(ＳｙｓｔｅｍＣ用にポートの型を合わせ、例えば、wire変数およびassign文の追加を行う)。assign文をalways@*に変換する処理ＰＭＲ６では、assign文をalways@*に変換し、各種定義(変数／task／function)の取得処理ＰＭＡ６１では、各種定義(変数/task/function)の取得を行う。

また、メモリ情報取得処理ＰＭＡ６２では、設定ファイルＳＦからメモリ情報の取得およびメモリになる変数の特定を行い、信号線アクセスの解析処理ＰＭＡ６３では、各プロセス(initial文、always文)の信号線アクセスの解析を行う。さらに、always@*のセンシティビティリスト解決処理ＰＭＲ７では、例えば、always@*のような記述をalways@(a or b)のような記述に変換する。

そして、高位合成ツール別変換処理ＰＭＲ８では、高位合成ツール別の変換を行い、高位合成用のチェック処理ＰＭＡｆでは、高位合成用のチェックを行う。ここで、高位合成用のチェックには、例えば、initial文は指定の形式になっているか、always文でセンシティビティリスト抜けはないか、不定値を使っていないか、および、組み合わせ回路alwaysからメモリへアクセスしていないか等の様々なチェックが含まれる。

図１１は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法のフローチャートにおけるそれぞれの処理の依存関係を説明するための図である。図１１において、各ブロックは、図８および図９における各処理を示し、各ブロックを結ぶ接続線(矢印付き直線)Ｄ１〜Ｄ２４は、それぞれの処理における依存関係を示す。

接続線Ｄ１に示されるように、モジュール定義正規化処理ＰＭＲ２は、構文木に対する操作であるため、構文木モデルの生成(字句解析／構文解析)処理ＰＡに依存する。同様に、Ｄ１０に示されるように、アトリビュート取得＆ノード削除処理ＰＭＲ１も、構文木に対する操作であるため、字句解析／構文解析処理ＰＡに依存する。また、Ｄ２に示されるように、モジュール定義解析処理ＰＭＡ３は、モジュール定義が１つの形式に統一されていた方が解析し易いため、モジュール定義正規化処理ＰＭＲ２に依存する。さらに、Ｄ３に示されるように、インスタンス記述正規化処理ＰＭＲ４は、順番による接続を名前による接続に変換する際に、モジュール定義情報を参照するため、モジュール定義解析処理ＰＭＡ３に依存する。また、Ｄ４に示されるように、クロック／リセット解析処理ＰＭＡ５は、クロック信号／リセット信号の接続関係を調べる際に、接続先が明確な形式(名前による接続)になっている方が解析し易いため、インスタンス記述正規化処理ＰＭＲ４に依存する。

次に、Ｄ５に示されるように、インスタンス記述修正処理ＰＭＲ５は、クロック信号／リセット信号の接続が他と違う方法で接続(例えば、wireを経由せずに接続)するように、インスタンス記述修正するため、クロック／リセット解析処理ＰＭＡ５に依存する。同様に、Ｄ６に示されるように、assign文をalways@*に変換する処理ＰＭＲ６は、インスタンス記述の修正でassign文が追加されるため、インスタンス記述修正処理ＰＭＲ５に依存する。

さらに、Ｄ１７に示されるように、各種定義の取得処理ＰＭＡ６１は、インスタンス記述の修正でwriteが追加されるため、インスタンス記述修正処理ＰＭＲ５に依存する。また、Ｄ１８に示されるように、メモリ情報取得処理ＰＭＡ６２は、どの変数がメモリかを特定するために変数の情報を使用することになるため、各種定義の取得処理ＰＭＡ６１に依存する。同様に、Ｄ２０に示されるように、信号線アクセスの解析処理ＰＭＡ６３は、各プロセスがどの信号線をアクセスしているかを解析するために、変数の情報や呼び出しているtask/functionの情報を使用するため、各種定義の取得処理ＰＭＡ６１に依存する。

また、always@*のセンシティビティリスト解決処理ＰＭＲ７は、Ｄ７に示されるように、always文が追加されるため、assign文をalways@*に変換する処理ＰＭＲ６に依存し、さらに、Ｄ２１に示されるように、信号線アクセスの解析処理ＰＭＡ６３にも依存する。すなわち、always@*のセンシティビティリスト解決処理ＰＭＲ７は、センシティビティリストの導出に各プロセスがどの信号線にアクセスしているかの情報を使用するため、assign文をalways@*に変換する処理ＰＭＲ６だけでなく、信号線アクセスの解析処理ＰＭＡ６３にも依存することになる。

さらに、Ｄ８に示されるように、高位合成ツール別変換処理ＰＭＲ８は、最終的な構文木モデルで高位合成ツール別の変換を実施したいため、always@*のセンシティビティリスト解決処理ＰＭＲ７に依存するのが好ましい。例えば、変換中の構文木でＰＭＲ８の処理を実施すると、高位合成ツール別に変換したものが途中で適合しない形に変換されてしまう、或いは、途中の変換で高位合成ツール用に変換しなければならないような構文木に変換されてしまうといった虞がある。すなわち、接続線Ｄ８は、高位合成ツール別変換処理ＰＭＲ８が、always@*のセンシティビティリスト解決処理ＰＭＲ７によるセンシティビティリストの導出を必要とするということではなく、この処理(変換)以外の変換が全て完了しているのが求められるということを意味する。

そして、Ｄ１９に示されるように、ＳｙｓｔｅｍＣ生成処理ＰＳＣＧは、メモリになる変数と信号線になる変数では、ＳｙｓｔｅｍＣで生成するコードが変わるため、メモリ情報取得処理ＰＭＡ６２に依存する。また、Ｄ１３に示されるように、未使用モジュール削除処理ＰＭＲ３は、未使用モジュールを特定する際に、モジュール定義情報を参照するので、モジュール定義解析処理ＰＭＡ３に依存する。さらに、Ｄ９に示されるように、ＳｙｓｔｅｍＣ生成処理ＰＳＣＧは、全ての変換が完了したものに対して、ＳｙｓｔｅｍＣの生成を行いたいので、高位合成ツール別変換処理ＰＭＲ８にも依存する。さらに、Ｄ１４に示されるように、ＳｙｓｔｅｍＣ生成処理ＰＳＣＧは、未使用モジュールはＳｙｓｔｅｍＣ(コード)に含めないため、未使用モジュール削除処理ＰＭＲ３に依存する。また、Ｄ１１に示されるように、ＳｙｓｔｅｍＣ生成処理ＰＳＣＧは、ＳｙｓｔｅｍＣの生成でアトリビュート情報を使用するため、アトリビュート取得＆ノード削除処理ＰＭＲ１にも依存する。すなわち、ＳｙｓｔｅｍＣ生成処理ＰＳＣＧは、メモリ情報取得処理ＰＭＡ６２、高位合成ツール別変換処理ＰＭＲ８、未使用モジュール削除処理ＰＭＲ３およびアトリビュート取得＆ノード削除処理ＰＭＲ１の４つの処理に依存することになる。

また、Ｄ２３に示されるように、高位合成用のチェック処理ＰＭＡｆは、全ての変換が完了したものに対して、高位合成が可能かどうかの最終的な判断を行いたいので、高位合成ツール別変換処理ＰＭＲ８に依存する。さらに、Ｄ１５に示されるように、高位合成用のチェック処理ＰＭＡｆは、未使用モジュールに対しては高位合成用のチェックは不要なので、未使用モジュール削除処理ＰＭＲ３にも依存する。すなわち、高位合成用のチェック処理ＰＭＡｆは、高位合成ツール別変換処理ＰＭＲ８および未使用モジュール削除処理ＰＭＲ３の２つの処理に依存することになる。

そして、Ｄ２４に示されるように、合成スクリプト生成処理ＰＳＳＧは、全ての変換が完了したものに対して、合成スクリプトを生成したいので、高位合成ツール別変換処理ＰＭＲ８に依存する。さらに、Ｄ１６に示されるように、合成スクリプト生成処理ＰＳＳＧは、未使用モジュールに対しては高位合成スクリプトの生成は不要なので、未使用モジュール削除処理ＰＭＲ３にも依存する。また、Ｄ２２に示されるように、合成スクリプト生成処理ＰＳＳＧは、メモリ合成制約の生成にメモリ情報を使用するため、メモリ情報取得処理ＰＭＡ６２にも依存する。そして、Ｄ１２に示されるように、合成スクリプト生成処理ＰＳＳＧは、合成スクリプトの生成でアトリビュート情報を使用するため、アトリビュート取得＆ノード削除処理ＰＭＲ１にも依存する。すなわち、合成スクリプト生成処理ＰＳＳＧは、高位合成ツール別変換処理ＰＭＲ８、未使用モジュール削除処理ＰＭＲ３、メモリ情報取得処理ＰＭＡ６２およびアトリビュート取得＆ノード削除処理ＰＭＲ１の４つの処理に依存することになる。

このように、本実施形態のＳｙｓｔｅｍＣモデル生成方法において、それぞれの処理は、相互に依存しているため、この各処理の間の依存関係を考慮して処理(変換)を行うことが求められる。すなわち、構文木モデルおよび解析情報に基づいて構文木モデルを再構成する様々な処理は、それぞれの処理の依存関係に基づいた順番に従って、構文木モデルの異なる解析情報を取り出し、その異なる解析情報に基づいて構文木モデルの異なる再構成を行う。そして、最終的な構文木モデル(最終構文木モデル)を生成し、ＳｙｓｔｅｍＣモデルＳＣＭおよび合成スクリプトＳＳを生成する。

図１２〜図１８は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法のフローチャートにおけるそれぞれの処理を説明するための図である。ここで、図１２は、アトリビュートの削除(アトリビュート取得＆ノード削除処理ＰＭＲ１(ＰＭＡ１))を説明するためのものであり、図１３は、未使用モジュール削除処理ＰＭＲ３を説明するためのものである。また、図１４および図１５は、インスタンス記述正規化処理ＰＭＲ４を説明するためのものであり、図１６は、always@*のセンシティビティリスト解決処理ＰＭＲ７を説明するためのものである。そして、図１７および図１８は、高位合成ツール別変換処理ＰＭＲ８を説明するためのものである。

図８および図９に示すＳｙｓｔｅｍＣモデル生成方法のフローチャートにおいて、まず、字句解析／構文解析処理ＰＡは、入力ソース(ＨＤＬ動作モデルＢＭ)に対して、字句および構文の解析を行って、抽象構文木モデル(構文木モデルＳＴＭ１)を生成する。次に、図１２を参照して、アトリビュート取得＆ノード削除処理ＰＭＲ１(ＰＭＡ１))を説明する。ここで、図１２(a)は、抽象構文木を走査して、アトリビュートを使用している個所を見つける様子の一例を示し、図１２(b)は、アトリビュートを削除している様子の一例を示す。

図１２(a)に示されるように、抽象構文木(構文木モデルＳＴＭ１)を走査して、アトリビュートを使用している個所ＵＰ１を検出し、アトリビュートの情報をテーブル(アトリビュート情報ＡＩ１)に追加する。図１２(a)に示す例では、アトリビュート情報ＡＩ１に追加するアトリビュート情報は、例えば、次の通りである。
アトリビュート名： dont_touch
値： "true"
適用対象： test.debug

また、図１２(b)に示されるように、アトリビュートのノードを構文木モデル(抽象構文木)ＳＴＭ１から削除(モデル再構成)し、構文木モデルＳＴＭ２を生成する。なお、図１２(a)以降の各図において、削除個所は、消し線で示し、追加個所は、アンダーラインで示す。

モジュール定義正規化処理ＰＭＲ２は、モジュール定義においてＶｅｒｉｌｏｇ−ＨＤＬでは、例えば、ポートの宣言、および、パラメータの宣言の項目について、複数の記述方法があるが、構文木モデル上の表現を１つの形式に統一する。すなわち、構文木モデルＳＴＭ２に対して、モジュール定義正規化処理ＰＭＲ２を行って構文木モデルＳＴＭ３を生成する。次に、モジュール定義解析処理ＰＭＡ３では、構文木モデルＳＴＭ３を走査して、モジュール情報を取得し、テーブル(モジュール情報ＡＩ３)に追加する。

未使用モジュール削除処理ＰＭＲ３は、インスタンスされていないモジュール定義を構文木モデルＳＴＭ３から削除して構文木モデルＳＴＭ４を生成(再構成)するもので、例えば、次の手順により行う。
(1) 設定ファイルＳＦからトップモジュール名を取得する。
(2) モジュール情報を使用して、トップモジュールからインスタンスされているモジュールをすべて列挙する。ここで、列挙するモジュールは、例えば、間接的にインスタンスされているモジュールを含む。なお、間接的にインスタンスされているモジュールとは、トップモジュールからインスタンスされているモジュールの中でインスタンスされているモジュール、或いは、そのモジュールからさらにインスタンスされているモジュール等である。
(3) モジュール情報に登録されているモジュールで、(2)で列挙したモジュールに含まれないものを未使用モジュールとする。
(4) 未使用モジュールの定義を構文木モデルＳＴＭ３から削除する。

すなわち、未使用モジュール削除処理ＰＭＲ３は、構文木モデルＳＴＭ３の情報および解析情報ＡＩに基づいて、構文木モデルＳＴＭ４を生成する。なお、後に、図１９〜図３０を参照して説明する処理の一例(第１変換例)、並びに、図３１〜図３８を参照して説明する処理の他の例(第２変換例)を説明するが、ここでは、第１変換例における未使用モジュールの判定処理を説明する。すなわち、第１変換例におけるモジュール情報は、図１３のようになっており、図１３では、モジュール情報の内、第１変換例の処理に必要な情報のみ記載している。具体的に、未使用モジュール削除処理ＰＭＲ３は、例えば、次の手順により行う。
(1) 設定ファイルＳＦからトップモジュール名topを取得する。
(2) モジュール情報より、topがインスタンスしているモジュールはmul、add。
(3) モジュール情報より、mulがインスタンスしているモジュールはなし。
(4) モジュール情報より、addがインスタンスしているモジュールはなし。

したがって、インスタンス化されているモジュールは、top、mul、addの３つであり、unusedモジュールは、インスタンス化されていないので未使用モジュールとする。

また、インスタンス記述正規化処理ＰＭＲ４は、モジュールのインスタンスにおいて、例えば、Ｖｅｒｉｌｏｇ−ＨＤＬでは、ポートの接続、および、パラメータのオーバーライドの項目について、複数の記述方法がある。そこで、構文木モデルＳＴＭ４における表現を１つの形式に統一する。具体的に、インスタンス記述正規化処理ＰＭＲ４は、例えば、順番によるポートの接続／パラメータのオーバーライドを、名前によるポートの接続／パラメータのオーバーライドに変更することで行う。すなわち、インスタンス記述正規化処理ＰＭＲ４は、構文木モデルＳＴＭ４の情報および解析情報ＡＩに基づいて、構文木モデルＳＴＭ５を生成する。

ここで、図１４は、変換前の構文木モデル(ＳＴＭ４)のＶｅｒｉｌｏｇ−ＨＤＬ記述の一例を示し、図１５(a)は、この記述でのモジュール情報を示し、図１５(b)は、再構成(正規化，変換)された構文木モデルＳＴＭ５を示す。ただし、図１５(a)では、モジュール情報のうち、この変換に必要な項目のみを示す。図１５(a)に示されるように、topにおけるmulモジュールのインスタンス化の記述では、順番によるポートの接続／パラメータのオーバーライドが使用されている。モジュール情報よりmulのポートはＡ，Ｂ，Ｃ、パラメータはＷであることが分かるので、m_mulのポートＡにはＡを接続、ポートＢにはＢを接続、ポートＣにはｍを接続、パラメータＷには８をオーバーライドしていることが分かる。

これにより、mulモジュールのインスタンス化の記述を名前によるポートの接続／パラメータのオーバーライドに修正(再構成)すると、例えば、「mul#(8) m_mul(A, B, m);」を、『mul#(.W(8)) m_mul(.A(A), .B(B), .C(m));』に書き換える。すなわち、図１５(b)に示されるように、『mul#(8) m_mul(A, B, m);』を削除(消し線個所は、削除)して、『mul#(.W(8)) m_mul(.A(A), .B(B), .C(m));』を追加(アンダーライン個所は、追加)することになる。

さらに、クロック／リセット解析処理ＰＭＡ５は、各モジュールのクロック信号およびリセット信号を特定する。具体的に、クロック／リセット解析処理ＰＭＡ５は、例えば、次の手順により行う。
(1) 設定ファイルＳＦに記載されているクロック信号名およびリセット信号名から、トップモジュールのクロック信号およびリセット信号を特定する。
(2) (1)信号が下位のモジュールのポートに接続されていた場合、そのポートをクロック信号およびリセット信号であると判定する。

また、インスタンス記述修正処理ＰＭＲ５は、ＳｙｓｔｅｍＣでのポート接続の制限を満たすようにインスタンス記述を修正する。すなわち、インスタンス記述修正処理ＰＭＲ５は、構文木モデルＳＴＭ５の情報および解析情報ＡＩに基づいて、構文木モデルＳＴＭ６を生成する。具体的に、インスタンス記述修正処理ＰＭＲ５は、例えば、ポートの型とポートに接続する信号線の型を合わせるように修正することで行う。さらに、各種定義(変数／task／function)の取得処理ＰＭＡ６１は、構文木モデルＳＴＭ６を走査して、変数／task／functionの情報を取得することで行う。そして、メモリ情報取得処理ＰＭＡ６２は、設定ファイルＳＦで指定されたメモリになる変数を特定し、また、信号線アクセスの解析処理ＰＭＡ６３は、各プロセスが読み出し(リードし)ている信号および書き込み(ライトし)ている信号を特定する。

さらに、assign文をalways@*に変換する処理ＰＭＲ６は、assign文をalways@*に変換し、always@*のセンシティビティリスト解決処理ＰＭＲ７は、always文のセンシティビティリストを明示的に示さない記述(always@*またはalways@(*))を、明示的に示す記述に変換(修正)する。すなわち、always@*のセンシティビティリスト解決処理ＰＭＲ７は、構文木モデルＳＴＭ７の情報および解析情報ＡＩに基づいて、構文木モデルＳＴＭ８を生成する。図１６は、always@*のセンシティビティリスト解決処理ＰＭＲ７を説明するためのものであり、図１６(a)は、具体的な一例の記述を示し。図１６(b)は、信号線アクセス情報の例を示し、そして、図１６(c)は、図１６(a)の記述を修正したものを示す。

図１６(a)に示す記述では、mulモジュールのalways文はセンシティビティリストを明示的に示さない記述になっている。また、図１６(b)に示されるように、信号線アクセス情報において、always_0は、プロセスを識別するためにツールがつけた名前になっている。この信号線アクセス情報により、mulモジュールのalways文がリードしている信号はＡとＢであることが分かる。これより、always文を、センシティビティリストを明示的に示す記述に修正すると、図１６(c)のようになる。すなわち、図１６(a)と、図１６(c)の比較から明らかなように、「always@(*) C = A*B;」は、『always@(A or B) C = A*B;』に修正される。

また、高位合成ツール別変換処理ＰＭＲ８は、ターゲットの高位合成ツールに適合するように、構文木モデルＳＴＭ８を変換(修正)して構文木モデルＳＴＭ９(最終構文木モデルＳＴＭｆ)を生成する。すなわち、高位合成ツール別変換処理ＰＭＲ８は、構文木モデルＳＴＭ８の情報、解析情報ＡＩおよび設定ファイルＳＦの情報に基づいて、最終構文木モデルＳＴＭｆを生成する。なお、ターゲットの高位合成ツールによって様々な変換が考えられるが、一例として一部の高位合成ツールの制限である「出力信号(ＳｙｓｔｅｍＣではsc_out)からのリードは禁止」を回避するように修正する例を示す。すなわち、図１７および図１８は、高位合成ツール別変換処理ＰＭＲ８を説明するためのものであるり、「出力信号(ＳｙｓｔｅｍＣではsc_out)からのリードは禁止」を回避する例を示す。

ここで、図１７(a)は、修正前の構文木モデル(ＳＴＭ８)を示し、図１７(b)および図１７(c)は、信号線アクセス情報および変数情報を示し、そして、図１８は、修正後の構文木モデル(ＳＴＭ９(最終構文木モデルＳＴＭｆ))を示す。なお、図１７(a)(図１８)では、出力信号からのリードを行う記述が含まれているが、ここでは、「C <= C+ A;」において出力信号Ｃからのリードが行われている。次に、高位合成ツール別変換処理ＰＭＲ８の具体的な手順を示す。
(1) リードされている出力信号を特定する。なお、信号線アクセス情報よりリードされている信号はＡとＣであり、変数情報よりＡはinputなので除外し、そして、Ｃはoutputなので対象になる。
(2) 中間変数(ここでは、tmpC)を導入して、Ｃへのリード／ライトを中間変数へのリード／ライトに変更し、tmpCをＣへライトするalways文を追加する。すなわち、図１７(a)に示す記述(構文木モデル(ＳＴＭ８))は、図１８に示す記述(構文木モデルＳＴＭ９(ＳＴＭｆ))のように修正されることになる。

さらに、高位合成用のチェック処理ＰＭＡｆは、高位合成可能な記述であるかどうかをチェックする。具体的に、高位合成用のチェック処理ＰＭＡｆでは、例えば、initial文は指定の形式になっているか、always文でセンシティビティリスト抜けはないか、不定値を使っていないか、および、組み合わせ回路alwaysからメモリへアクセスしていないか等の様々なチェックが行われる。

そして、ＳｙｓｔｅｍＣ生成処理ＰＳＣＧは、構文木モデルＳＴＭ９(最終構文木モデルＳＴＭｆ)を走査しながらＳｙｓｔｅｍＣコードの生成を行う。ここで、ＳｙｓｔｅｍＣ生成処理ＰＳＣＧでは、ＳｙｓｔｅｍＣコード生成がし易いように構文木の変換が行われているので、ＳｙｓｔｅｍＣコードの生成処理は、単純な操作で行うことが可能である。すなわち、ＳｙｓｔｅｍＣ生成処理ＰＳＣＧは、最終構文木モデルＳＴＭｆの情報および解析情報に基づいて、ＳｙｓｔｅｍＣモデルＳＣＭを生成する。なお、合成スクリプト生成処理ＰＳＳＧは、最終構文木モデルＳＴＭｆおよび設定ファイルＳＦの情報(データ)に基づいて、高位合成用の合成スクリプトＳＳを生成する。

このようにして得られたＳｙｓｔｅｍＣモデルＳＭＣは、例えば、高位合成ツールを適用して論理合成可能なＲＴＬモデルに変換することができ、そのＲＴＬモデルに対して、論理合成ツールを適用することで、ネットリストに変換することができる。すなわち、本実施形態のＳｙｓｔｅｍＣモデル生成方法によれば、ＨＤＬ動作モデルを論理回路設計に適用することが可能になる。

以下、上述したＳｙｓｔｅｍＣモデル生成方法の一実施例を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する２つの処理の例を、図１９〜図３０、並びに、図３１〜図３８を参照して説明する。すなわち、図１９〜図３０は、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の一例を説明するための図である。なお、図１９〜図３０(図３１〜図３８も同様)において、例示した処理内容は、特別な意味を持つものではなく、単なる例に過ぎない。

図１９は、ＨＤＬ動作モデルＢＭの一例を示すものであり、図２０は、図１９に示すＨＤＬ動作モデルＢＭに対して、字句解析／構文解析処理ＰＡを行って変換(生成、モデル再構成)した後の構文木モデルＳＴＭ１を示す。すなわち、図１９に示すＨＤＬ動作モデルＢＭは、前述した字句解析／構文解析処理ＰＡを行うことにより、図２０のような構文木モデルＳＴＭ１に変換(生成)されるのが分かる。

図２１は、構文木モデルの一例を示し、図２１(a)は、ブロック図形式で表したものであり、図２１(b)は、記述形式(Ｖｅｒｉｌｏｇ−ＨＤＬ：テキスト)で表したものである。すなわち、図２１(a)に示すブロック図形式の構文木モデルは、図２１(b)の記述形式として示すことができ、両者は同じものを表している。なお、本明細書では、理解を容易化するために、構文木モデルをテキストにより説明しているが、ブロック図形式或いは他の記述形式等を用いて表現することも可能なのはいうまでもない。

図２２は、アトリビュート取得＆ノード削除処理ＰＭＲ１(ＰＭＡ１)を説明するためのものであり、構文木モデルＳＴＭ２を示す。なお、アトリビュートの削除に関しては、図１２(a)および図１２(b)を参照して説明したのと同様である。すなわち、図２２では、前述した図１２(b)と同様に、アトリビュート取得＆ノード削除処理ＰＭＲ１により、「(* dont_touch = "true" *)」が削除され、構文木モデルＳＴＭ２が生成されるのが分かる。

図２３は、モジュール定義正規化処理ＰＭＲ２を説明するためのものであり、構文木モデルＳＴＭ３を示す。すなわち、図２３では、モジュール定義正規化処理ＰＭＲ２により、構文木モデル(ＳＴＭ２)上の表現が１つの形式に統され、構文木モデルＳＴＭ３が生成されるのが分かる。ここで、入力信号および出力信号は、モジュール内で定義され(ＳＴＭ２の「module top(input … output reg DONE);」は、ＳＴＭ３では、『module top(CLK, XRESET, START, A, B, DONE); … output reg DONE;』に変換され)、１つの宣言文では、１つの変数のみ宣言する(ＳＴＭ２の「input [7:0] A, B,」は、ＳＴＭ３では、『input [7:0] A;』および『input [7:0] B;』の２つに分割される)ようになっている。さらに、パラメータ(parameter)は、モジュール内で定義する(ＳＴＭ２の「module mul#(parameter W = 32) … output reg [W-1:0] C;」は、ＳＴＭ３では、『module mul(A, B, C); … output reg [W-1:0] C;』に変換される)ようになっている。

図２４は、未使用モジュール削除処理ＰＭＲ３を説明するためのものであり、構文木モデルＳＴＭ４を示す。すなわち、図２４では、未使用モジュール削除処理ＰＭＲ３により、インスタンスされていないモジュール定義が構文木モデルＳＴＭ３から削除され、構文木モデルＳＴＭ４が生成されるのが分かる。具体的に、構文木モデルＳＴＭ３の「module unused(A, B, C); … endmodule // unused」が削除され、構文木モデルＳＴＭ４が生成される。

図２５は、インスタンス記述正規化処理ＰＭＲ４を説明するためのものであり、構文木モデルＳＴＭ５を示す。ここで、インスタンス記述正規化処理ＰＭＲ４は、図１４および図１５を参照して説明した通りであり、図２５は、前述した図１５(b)に対応する。すなわち、図２５に示されるように、インスタンス記述正規化処理ＰＭＲ４を行うことにより、parameter、入力信号および出力信号は名前で接続され、ＳＴＭ４の「mul#(8) m_mul(A, B, m);」は、『mul#(.W(8)) m_mul(.A(A), .B(B), .C(m));』に変換されて、ＳＴＭ５が生成される。

図２６は、インスタンス記述修正処理ＰＭＲ５を説明するためのものであり、構文木モデルＳＴＭ６を示す。ここで、ＳｙｓｔｅｍＣでは、同じ型のsc_signalでなければ接続できないため、ポートと同じ型のwireを経由して接続する。すなわち、ＳＴＭ５の「mul#(.W(8)) m_mul(.A(A), .B(B), .C(m));」および「add#(.W(4)) m_add(.A(m[7:4]), .B(m[3:0]), .C(n));」は、それぞれ『localparam m_mul_W_ = 8; … mul#(.W(m_mul_W_)) m_mul(.A(m_mul_A_), .B(m_mul_B_), .C(m_mul_C_));』および『localparam m_add_W_ = 4; … add#(.W(m_add_W_)) m_add(.A(m_add_A_), .B(m_add_B_), .C(m_add_C_));』に変換されて、ＳＴＭ６が生成される。

図２７は、assign文をalways@*に変換する処理ＰＭＲ６を説明するためのものであり、構文木モデルＳＴＭ７を示す。すなわち、assign文をalways@*に変換する処理ＰＭＲ６は、assign文をalways@*に変換する。具体的に、ＳＴＭ６の「wire [m_mul_W_-1:0] m_mul_A_; assign m_mul_A_ = A;」および「wire [m_add_W_-1:0] m_add_A_; assign m_add_A_ = m[7:4];」は、それぞれ『reg [m_mul_W_-1:0] m_mul_A_; always@(*) m_mul_A_ = A; … wire [m_mul_W_-1:0] m_mul_C_; always@(*) m = m_mul_C_;』および『reg [m_add_W_-1:0] m_add_A_; always@(*) m_add_A_ = m[7:4]; … wire [m_add_W_-1:0] m_add_C_; always@(*) n = m_add_C_;』に変換されて、ＳＴＭ７が生成される。

図２８は、always@*のセンシティビティリスト解決処理ＰＭＲ７を説明するためのものであり、構文木モデルＳＴＭ８を示す。ここで、always@*のセンシティビティリスト解決処理ＰＭＲ７は、always文のセンシティビティリストを明示的に示さない記述(always@*またはalways@(*))を、明示的に示す記述に変換する。すなわち、例えば、ＳＴＭ６の「reg [m_mul_W_-1:0] m_mul_A_; always@(*) m_mul_A_ = A;」および「always@(*) C = A*B;」等の記載は、『reg [m_mul_W_-1:0] m_mul_A_; always@(A) m_mul_A_ = A;』および『always@(A or B) C = A*B;』等に変換されて、ＳＴＭ８が生成される。なお、図２８の一部は、前述した図１６(c)に対応する。なお、高位合成ツール別変換処理ＰＭＲ８は、例えば、高位合成ツールによっては合成不可となる記述があるので、合成可能となるように構文木モデルＳＴＭ８を処理して、構文木モデルＳＴＭ９(最終構文木モデルＳＴＭｆ)を生成するものであるが、ここでは、その説明を省略する。

図２９および図３０は、ＳｙｓｔｅｍＣ生成処理ＰＳＣＧを説明するためのものであり、ＳｙｓｔｅｍＣモデルＳＭＣを示す。ここで、図２９は、ＳｙｓｔｅｍＣモデルＳＭＣのヘッダファイルを示し、図３０は、ＳｙｓｔｅｍＣモデルＳＭＣのソースファイルを示す。上述したように、図１９に示すＨＤＬ動作モデルＢＭに対して、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用することにより、図２９および図３０に示されるようなＳｙｓｔｅｍＣモデルＳＭＣを生成することが可能なのが分かる。なお、このようにして得られたＳｙｓｔｅｍＣモデルＳＭＣは、例えば、高位合成ツールを適用して論理合成可能なＲＴＬを生成(ＲＴＬモデルに変換)することができ、そのＲＴＬモデル(１)に対して、論理合成ツール(２)を適用することで、ネットリスト(３)に変換することができるのは前述した通りである。

次に、図３１〜図３８を参照して、ＨＤＬ動作モデルからＳｙｓｔｅｍＣモデルを生成する処理の他の例を説明する。図３１は、シーケンス処理の一例を示し、リクエスト信号ｒｅｑを受信したら、２バイト(１６ビット)のデータ０ｘａｂ，０ｘｃｄを各バイトの回から１ビット単位で出力し、終了したらアクノリッジ信号ａｃｋを返すものを示す。図３２は、図３１に示すシーケンス処理に対応したＨＤＬ動作モデルＢＭの一例を示すものである。

まず、アトリビュート取得＆ノード削除処理ＰＭＲ１(ＰＭＡ１)を行うが、図３２に示すＨＤＬ動作モデルＢＭでは、アトリビュートの削除処理を行っても構文木モデルは変化しない。すなわち、構文木モデルＳＴＭ２は、構文木モデルＳＴＭ１と同じものになっている。図３３は、モジュール定義正規化処理ＰＭＲ２を説明するためのものであり、構文木モデルＳＴＭ３を示す。すなわち、図３３では、モジュール定義正規化処理ＰＭＲ２により、構文木モデル(ＳＴＭ２)上の表現が１つの形式に統され、構文木モデルＳＴＭ３が生成されるのが分かる。ここで、入力信号および出力信号は、モジュール内で定義され(ＳＴＭ２の「module seq(input clk, xrst, … output out);」および「module serializer(input CLK, output reg O);」は、ＳＴＭ３では、それぞれ『module seq(clk, xrst, req, ack, out); … output out;』および『module serializer(CLK, O); … output reg O;』に変換され)るようになっている。なお、未使用モジュール削除処理ＰＭＲ３を行っても構文木モデルは変化せず、構文木モデルＳＴＭ４は、構文木モデルＳＴＭ３と同じものになっている。

図３４は、インスタンス記述正規化処理ＰＭＲ４を説明するためのものであり、構文木モデルＳＴＭ５を示す。ここで、インスタンス記述正規化処理ＰＭＲ４は、例えば、モジュール情報からポート名を取得し、名前による接続に修正する。すなわち、図３４に示されるように、ＳＴＭ４(ＳＴＭ３)の「m_serializer(clk, out);」は、『m_serializer(.CLK(clk), .O(out));』に変換されて、ＳＴＭ５が生成される。また、図３５は、インスタンス記述修正処理ＰＭＲ５を説明するためのものであり、構文木モデルＳＴＭ６を示す。ここで、ポートと同じ型のwireを経由して接続させるために、ＳＴＭ５の「serializer#(.W(8)) m_serializer(.CLK(clk), .O(out));」は、『localparam m_serializer_W = 8; … m_serializer(.CLK(clk), .O(m_serializer_O));』に変換されて、ＳＴＭ６が生成される。

図３６は、assign文をalways@*に変換する処理ＰＭＲ６を説明するためのものであり、構文木モデルＳＴＭ７を示す。すなわち、assign文をalways@*に変換する処理ＰＭＲ６は、assign文をalways@*に変換するが、具体的に、ＳＴＭ６の「assign out = m_serializer_O;」は、『always@* out = m_serializer_O;』に変換されて、ＳＴＭ７が生成される。

図３７は、always@*のセンシティビティリスト解決処理ＰＭＲ７を説明するためのものであり、構文木モデルＳＴＭ８を示す。ここで、always@*のセンシティビティリスト解決処理ＰＭＲ７は、always文でセンシティビティリストを明示的に指定するように変換するもので、具体的に、ＳＴＭ６の「always@* out = m_serializer_O;」は、『always@(m_serializer_O) out = m_serializer_O;』に変換されて、ＳＴＭ８が生成される。なお、always文でリードされている信号は、例えば、信号線アクセス情報から取得することができる。また、高位合成ツール別変換処理ＰＭＲ８を行っても構文木モデルは変化せず、構文木モデルＳＴＭ９(最終構文木モデルＳＴＭｆ)は、構文木モデルＳＴＭ８と同じものになっている。

図３８は、ＳｙｓｔｅｍＣ生成処理ＰＳＣＧを説明するためのものであり、ＳｙｓｔｅｍＣモデルＳＭＣを示す。上述したように、図３２に示すＨＤＬ動作モデルＢＭに対して、図８および図９に示すＳｙｓｔｅｍＣモデル生成方法を適用することにより、図３８に示されるようなＳｙｓｔｅｍＣモデルＳＭＣを生成することが可能なのが分かる。ここで、得られたＳｙｓｔｅｍＣモデルＳＭＣは、例えば、高位合成ツールを適用して論理合成可能なＲＴＬモデルに変換することができ、そのＲＴＬモデルに対して、論理合成ツールを適用することで、ネットリストに変換することができる。なお、上述した図１９〜図３０、並びに、図３１〜図３８を参照して説明した変換例は、単なる例であり、本実施形態のＳｙｓｔｅｍＣモデル生成方法は、様々なＨＤＬ動作モデルＢＭに対して幅広く適用することが可能である。さらに、本実施形態は、コンピュータのＬｉｎｕｘ（登録商標）やＷｉｎｄｏｗｓ（登録商標）等のＯＳ上で実行させるＳｙｓｔｅｍＣモデル生成プログラムとして提供することもできる。

以上、実施形態を説明したが、ここに記載したすべての例や条件は、発明および技術に適用する発明の概念の理解を助ける目的で記載されたものであり、特に記載された例や条件は発明の範囲を制限することを意図するものではない。また、明細書のそのような記載は、発明の利点および欠点を示すものでもない。発明の実施形態を詳細に記載したが、各種の変更、置き換え、変形が発明の精神および範囲を逸脱することなく行えることが理解されるべきである。

以上の実施例を含む実施形態に関し、さらに、以下の付記を開示する。
（付記１）
ＨＤＬのシミュレーション構文で設計したＨＤＬ動作モデルから、高位合成が可能なＳｙｓｔｅｍＣモデルを生成するＳｙｓｔｅｍＣモデル生成方法であって、
前記ＨＤＬ動作モデルを解析して構文木モデルを生成し、
前記構文木モデルを解析して解析情報を取り出し、
前記構文木モデルおよび前記解析情報に基づいて前記構文木モデルを再構成し、前記ＳｙｓｔｅｍＣモデルを生成する、
ことを特徴とするＳｙｓｔｅｍＣモデル生成方法。

（付記２）
前記ＨＤＬ動作モデルを解析して前記構文木モデルを生成するのは、
前記ＨＤＬ動作モデルの字句および構文を解析して行う、
ことを特徴とする付記１に記載のＳｙｓｔｅｍＣモデル生成方法。

（付記３）
前記構文木モデルおよび前記解析情報に基づいて前記構文木モデルを再構成するのは、
それぞれの処理の依存関係に基づいた順番に従って、前記構文木モデルの異なる解析情報を取り出し、
前記異なる解析情報に基づいて前記構文木モデルの異なる再構成を行い、最終構文木モデルを生成する、
ことを特徴とする付記１または付記２に記載のＳｙｓｔｅｍＣモデル生成方法。

（付記４）
さらに、
前記最終構文木モデルを解析して最終解析情報を取り出し、
前記最終構文木モデルおよび前記最終解析情報に基づいて、前記ＳｙｓｔｅｍＣモデルを生成する、
ことを特徴とする付記３に記載のＳｙｓｔｅｍＣモデル生成方法。

（付記５）
前記構文木モデルおよび前記解析情報に基づいて前記構文木モデルを再構成するのは、
インスタンスされていないモジュール定義を構文木から削除する未使用モジュール削除処理、
サブモジュールのインスタンスの形式を合わせるインスタンス記述正規化処理、
前記サブモジュールのインスタンス記述を変更するインスタンス記述修正処理、
assign文をalways@*に変換するalways@*のセンシティビティリスト解決処理、および、
高位合成ツール別の変換を行う高位合成ツール別変換処理の少なくとも１つの処理を含む、
ことを特徴とする付記１乃至付記４のいずれか１項に記載のＳｙｓｔｅｍＣモデル生成方法。

（付記６）
前記未使用モジュール削除処理は、
未使用モジュールを特定する際に、モジュール定義情報を参照するのため、モジュール定義解析処理、および、前記構文木モデルに依存する、
ことを特徴とする付記５に記載のＳｙｓｔｅｍＣモデル生成方法。

（付記７）
前記インスタンス記述正規化処理は、
順番による接続を名前による接続に変換する際に、モジュール定義情報を参照するため、モジュール定義解析処理、および、前記構文木モデルに依存する、
ことを特徴とする付記５に記載のＳｙｓｔｅｍＣモデル生成方法。

（付記８）
前記インスタンス記述修正処理は、
クロック信号およびリセット信号の接続が他と違う方法で接続するようにインスタンス記述修正するため、クロック／リセット解析処理、および、前記構文木モデルに依存する、
ことを特徴とする付記５に記載のＳｙｓｔｅｍＣモデル生成方法。

（付記９）
前記センシティビティリスト解決処理は、
always文が追加されると共に、センシティビティリストの導出に各プロセスがどの信号線にアクセスしているかの情報を使用するため、assign文をalways@*に変換する処理、信号線アクセスの解析処理、および、前記構文木モデルに依存する、
ことを特徴とする付記５に記載のＳｙｓｔｅｍＣモデル生成方法。

（付記１０）
前記高位合成ツール別変換処理は、
最終構文木モデルで高位合成ツール別の変換を実施するため、前記always@*のセンシティビティリスト解決処理、および、前記構文木モデルに依存する、
ことを特徴とする付記５に記載のＳｙｓｔｅｍＣモデル生成方法。

（付記１１）
前記高位合成は、前記ＳｙｓｔｅｍＣモデルから高位合成ツールを使用して論理合成可能なＲＴＬを生成し、
生成された前記ＲＴＬに対して、論理合成ツールを適用してネットリストに変換する、
ことを特徴とする付記１乃至付記１０のいずれか１項に記載のＳｙｓｔｅｍＣモデル生成方法。
（付記１２）
前記ＨＤＬ動作モデルは、Ｖｅｒｉｌｏｇ−ＨＤＬまたはＶＨＤＬである、
ことを特徴とする付記１乃至付記１１のいずれか１項に記載のＳｙｓｔｅｍＣモデル生成方法。

（付記１３）
ＨＤＬのシミュレーション構文で設計したＨＤＬ動作モデルから、高位合成が可能なＳｙｓｔｅｍＣモデルを生成するＳｙｓｔｅｍＣモデル生成プログラムであって、
コンピュータに、
前記ＨＤＬ動作モデルを解析して構文木モデルを生成し、
前記構文木モデルを解析して解析情報を取り出し、
前記構文木モデルおよび前記解析情報に基づいて前記構文木モデルを再構成し、前記ＳｙｓｔｅｍＣモデルを生成する、処理を実行させる、
ことを特徴とするＳｙｓｔｅｍＣモデル生成プログラム。

（付記１４）
前記構文木モデルおよび前記解析情報に基づいて前記構文木モデルを再構成する処理は、
それぞれの処理の依存関係に基づいた順番に従って、前記構文木モデルの異なる解析情報を取り出し、
前記異なる解析情報に基づいて前記構文木モデルの異なる再構成を行い、最終構文木モデルを生成する、処理を含む、
ことを特徴とする付記１３に記載のＳｙｓｔｅｍＣモデル生成プログラム。

（付記１５）
さらに、
前記コンピュータに、
前記最終構文木モデルを解析して最終解析情報を取り出し、
前記最終構文木モデルおよび前記最終解析情報に基づいて、前記ＳｙｓｔｅｍＣモデルを生成する、処理を実行させる、
ことを特徴とする付記１４に記載のＳｙｓｔｅｍＣモデル生成プログラム。

（付記１６）
前記構文木モデルおよび前記解析情報に基づいて前記構文木モデルを再構成する処理は、
インスタンスされていないモジュール定義を構文木から削除する未使用モジュール削除処理、
サブモジュールのインスタンスの形式を合わせるインスタンス記述正規化処理、
前記サブモジュールのインスタンス記述を変更するインスタンス記述修正処理、
assign文をalways@*に変換するalways@*のセンシティビティリスト解決処理、および、
高位合成ツール別の変換を行う高位合成ツール別変換処理の少なくとも１つの処理を含む、
ことを特徴とする付記１３乃至付記１５のいずれか１項に記載のＳｙｓｔｅｍＣモデル生成プログラム。

１ ＲＴＬモデル
２ 論理合成ツール
３ ネットリスト(ゲート回路)
４ 動作モデル
４０，ＢＭ ＨＤＬ動作モデル
４１ ＳｙｓｔｅｍＣモデル生成部
４２，ＳＣＭ ＳｙｓｔｅｍＣモデル
４３，ＳＳ 合成スクリプト
４４ 高位合成ツール
ＡＩ 解析情報
ＰＭＡ０１，ＰＭＡ０２，ＰＭＡ３，ＰＭＡ５，ＰＭＡ６，ＰＭＡ６１，ＰＭＡ６３ モデル解析処理
ＰＭＡｆ 高位合成用のチェック処理
ＰＭＲ０１，ＰＭＲ０２，ＰＭＲ１〜ＰＭＲ８ モデル再構成処理
ＰＳＣＧ ＳｙｓｔｅｍＣ生成処理
ＰＳＳＧ 合成スクリプト生成処理
ＳＦ 設定ファイル
ＳＴＭ０１〜ＳＴＭ０３，ＳＴＭ１〜ＳＴＭ９ 構文木モデル
ＳＴＭｆ 最終構文木モデル

Claims (7)

1. ＨＤＬのシミュレーション構文で設計したＨＤＬ動作モデルから、高位合成が可能なＳｙｓｔｅｍＣモデルを生成するＳｙｓｔｅｍＣモデル生成方法であって、
   前記ＨＤＬ動作モデルを解析して構文木モデルを生成し、
   前記構文木モデルを解析して解析情報を取り出し、
   前記構文木モデルおよび前記解析情報に基づいて前記構文木モデルを再構成し、前記ＳｙｓｔｅｍＣモデルを生成する、
   ことを特徴とするＳｙｓｔｅｍＣモデル生成方法。
2. 前記ＨＤＬ動作モデルを解析して前記構文木モデルを生成するのは、
   前記ＨＤＬ動作モデルの字句および構文を解析して行う、
   ことを特徴とする請求項１に記載のＳｙｓｔｅｍＣモデル生成方法。
3. 前記構文木モデルおよび前記解析情報に基づいて前記構文木モデルを再構成するのは、
   それぞれの処理の依存関係に基づいた順番に従って、前記構文木モデルの異なる解析情報を取り出し、
   前記異なる解析情報に基づいて前記構文木モデルの異なる再構成を行い、最終構文木モデルを生成する、
   ことを特徴とする請求項１または請求項２に記載のＳｙｓｔｅｍＣモデル生成方法。
4. さらに、
   前記最終構文木モデルを解析して最終解析情報を取り出し、
   前記最終構文木モデルおよび前記最終解析情報に基づいて、前記ＳｙｓｔｅｍＣモデルを生成する、
   ことを特徴とする請求項３に記載のＳｙｓｔｅｍＣモデル生成方法。
5. 前記構文木モデルおよび前記解析情報に基づいて前記構文木モデルを再構成するのは、
   インスタンスされていないモジュール定義を構文木から削除する未使用モジュール削除処理、
   サブモジュールのインスタンスの形式を合わせるインスタンス記述正規化処理、
   前記サブモジュールのインスタンス記述を変更するインスタンス記述修正処理、
   assign文をalways@*に変換するalways@*のセンシティビティリスト解決処理、および、
   高位合成ツール別の変換を行う高位合成ツール別変換処理の少なくとも１つの処理を含む、
   ことを特徴とする請求項１乃至請求項４のいずれか１項に記載のＳｙｓｔｅｍＣモデル生成方法。
6. 前記高位合成は、前記ＳｙｓｔｅｍＣモデルから高位合成ツールを使用して論理合成可能なＲＴＬを生成し、
   生成された前記ＲＴＬに対して、論理合成ツールを適用してネットリストに変換する、
   ことを特徴とする請求項１乃至請求項５のいずれか１項に記載のＳｙｓｔｅｍＣモデル生成方法。
7. ＨＤＬのシミュレーション構文で設計したＨＤＬ動作モデルから、高位合成が可能なＳｙｓｔｅｍＣモデルを生成するＳｙｓｔｅｍＣモデル生成プログラムであって、
   コンピュータに、
   前記ＨＤＬ動作モデルを解析して構文木モデルを生成し、
   前記構文木モデルを解析して解析情報を取り出し、
   前記構文木モデルおよび前記解析情報に基づいて前記構文木モデルを再構成し、前記ＳｙｓｔｅｍＣモデルを生成する、処理を実行させる、
   ことを特徴とするＳｙｓｔｅｍＣモデル生成プログラム。

Images