Qflow tutorial
Qflow 1.1デジタル合成フローのチュートリアル
内容
デジタルフローの例
次の節で使う例のためにファイルをダウンロード
map9v3.vは簡単なVerilogのソースファイルの例です。これは、MultiGiG社が作成したチップのためのコンフィグレーション作成用ロジックブロックですが、それだけでは全く使い道はなく、不可解なものであるのはいうまでもなく、だから例としてちょうど良いのです。OSUのスタセルライブラリイのダウンロード先にあるverilogソースの１つを使おうかとおもったのですが、１つのファイルに複数のモジュールが入っており、そのverilogでは特殊用途のセルが使われてました。そういう複雑なものは（いつか）別のチュートリアルでカバーします。
| File | Revision | Size | Date |
| ———————————————————————————————————————————- | ———— | ——- | ———————- |
| map9v3.v | 1 | 2.0KB | May 11, 2013 |
| load.tcl | 0 | 215B | May 11, 2013 |
| map9v3.tcl | 0 | 306B | May 11, 2013 |
| map9v3.cel2 | 0 | 866B | August 24, 2016 |
| osu035_stdcells.gds2 | 0 | 339kB | June 6, 2013 |
| map9v3_gates_tb.v | 0 | 717B | April 28, 2015 |
| osu035_stdcells.v | 0 | 24kB | April 28, 2015 |
| setup.tcl | 0 | 162B | March 14, 2017 |
| map9v3_cosim_tb.spi | 0 | 953B | June 6, 2017 |
yosysやOdin-IIのような合成フロントエンドツールで理解可能なVerilogのサブセットでは、特定のタイミング情報（例えば”#”の構造、とはいえある種のものは構文解析されて無視される）が使えません。これは、シミュレーションに使われるverilog（testbench用verilog）と合成に使われるverilog（合成用verilog）の違いを反映しています。verilogの定義は、両方のスタイルを取り込んでいるので、テストベンチ型のverilogを合成ツールに渡さないよう注意しなくてはなりません。
以下は、Verilogソースからレイアウトまでのデジタルフローの一例です。
設定
qflow-1.1 qflow reference pageに書かれている必須要件をインストールしてください。この例では、デフォルトのOSU035 テクノロジを使えますので、そのほかのテックライブラリをダウンロードする必要はありません。
あなたの作業領域のどこかに作業用ディレクトリを作ってください。この例のために、例へのディレクトリパスは、${project_dir}という変数名に保持し、この例ではずっとプロジェクトの最上位のディレクトリを指すのに使います。
${project_dir}のサブディレクトリをsource, synthesis, layoutという名前で作ります。
map9v3.v という例題のファイルを${project_dir}/sourceディレクトリにコピーします。
注意：これらのディレクトリを定義しなくても、qflowはそれでも動作しますが、すべてを現在の作業ディレクトリに吐き出すので不便です。フラットの作業領域は一部には受けるかもしれませんが．．．
このチュートリアルのすべての指示は、上述のようなディレクトリ構造を想定しています。
実行
プロジェクトのディレクトリで、
qflow synthesize place route map9v3
を実行します。
(注意：上記コマンドは、qflow version 1.1用です; qflow version 1.0では、 “qflow synthesize place buffer route map9v3”を使うこと。)
このコマンドは、作業ディレクトリに３つのファイルを生成します。
qflow_vars.sh は、テクノロジについての情報を一箇所にあつめてデジタル合成フローの各々のツールに渡すファイルです。
qflow_exec.shは合成、配置、配線に実行される一連のコマンドを含んだファイルです。単にqflow コマンドをプロジェクト名以外オプションを与えずに実行するとすべてのコマンドがコメントアウトされます。
project_vars.sh は一度だけ作成されて上書きされることは決してありません。合成フローをあなたのニーズに合わせるための特定のオプションはここに設定します。このチュートリアルでは、デフォルト以上のことにはあまり触れませんので、このファイルはとりあえず無視して構いません。
通常、 “qflow map9v3“ のようにオプションを与えずに実行し、そしてフローの各ステップを、各部のコメントを１回に１つずつ外しながら、その部分のフローを実行し結果をチェックし、それから次の部分に移るというやり方で、通して行います。各部で必要なファイルは作業ディレクトリに保存されるので、qflowは前のステップで残されたものを拾い上げることができます。
結果
すべてのツールが正しくインストールされていれば、この例は、最後まで実行が完了し、配線結果が得られるよう検査済みです。
電源バスのストライプ
qflow version 1.1.54以降、 qflowには電源バスのストライプ作成機能が組み込まれています。電源バスのストライプには、特定のプロセスに対応したメタルのバックエンドスタックを選択する必要があるので、デフォルトでは未定義になっています。そのため、レイアウトはメタルのそ れぞれの行に分離した電源とグランドのラインを持ったものになります。しかし、OSUのスタセルは、固定のメタルのバックエンドスタックを持ってお り、すべての配線レイヤは、同じファイルの中でスタンダードセルのマクロと同じに定義されているので、自動の電源バスストライプ作成を設定するのは簡単です。適当なテキストエディタで、プロジェクトのトップディレクトリにある “project_vars.sh“を編集してください。古いバージョンのqflowをお持ちの場合、 “addspacers“というツールに渡す推奨オプションでコメントアウトされたものはないかも知れません。しかし、 qflow version 1.1.54 以降の場合、
# set addspacers_options = "-stripe 5 200 PG -nostretch"
という行が見つかるはずです。この行のコメントを外し、セルが小さく電源のレールを狭く詰めないとセルにまったく入らないかも知れないので、”200” を “100”に変更してください。 “-stripe” の後に渡される値は、ストライプの幅、ピッチ、パターンの順です。幅とピッチはミクロン単位（つまり、5ミクロン幅の電源バスが200ミクロン間隔）です。パターンというのは、それぞれの行がどのように接続されるかを表し、”P” が “power” 、 “G” が “ground”です。通常、”PG”にしますが、これは電源とグランドが交互に入れ替わるという意味です。”-nostretch” オプションは、電源バスが既存のレイアウトを覆うことを意味します。このオプションが無いと、そのセルは埋め合せるセルが電源バスの下に来るように延長され、信号配線に入って邪魔することが（いくぶん）無いようにします。
project_vars.shの入力は以下のようになります：
set addspacers_options = “-stripe 5 100 PG -nostretch”
一度この変更を行い、qflowを再度実行すると、電源バスが自動的に挿入されスタセルに接続されるはずです。
Netgenを使ってレイアウトを検証する
合成された回路は、コレクトバイデザイン（つまり正しくなるよう設計されている）が想定されていますが、回路をLVSとシミュレーションの両方で検証するのはいつでも良い考えです。
このチュートリアルを実行するには、システムに netgen 1.5をインストールする必要があります。Tcl/Tkサポート付きでそれがコンパイルされていることを確認してください。でないと、比較の実行に、”lvs” コマンドが使えずnetgenのドキュメントを参照するハメになります。
qflowを詳細配線まで実行した後は、Magicを使って回路を読み込んでください。このレイアウトツールには、スタセルの配置のためのLEFファイルに定義されたセルの外形の箱は理解するが、標準的なデータベースのフォーマットにはこの理解は伝達されないという制限があります。物理的なレイアウトビューが抽象的なLEFビューと合致していることを保証する最も良い方法は、以下を実行することです：
Magicは、OSU035スタセルで使われているプロセスのテクノロジーファイル、それはMOSISのスケーラブルCMOSルールを少しだけ変更したもの、にアクセスする必要があります。この変更したテクノロジーファイルはqflowの配布物に含まれています。最新のqflow（1.0.13以降）はlayoutディレクトリに”.magicrc“という初期設定スクリプトをインストールします。この初期設定スクリプトは、qflowのインストールディレクトリから正しいテクノロジーファイルをロードします。qflow 1.0.13以前のバージョンの場合、SCN4M_SUBM.20.techというテクノロジーファイルを、qflowのインストールディレクトリ（/usr/local/share/qflow/tech/osu035/）からローカルのlayoutディレクトリに自分でコピーする必要があります。
Magicを例えば “magic -d OGL”のように layout ディレクトリで起動します(OpenGLがサポートされてない場合は、単に”magic” です)。
lef read /usr/local/share/qflow/tech/osu035/osu035_stdcells.lef コマンドを使って、抽象的なLEFビューをロードします。magicの LEFリーダが処理できないというようなウォーニングメッセージが大量にでますが、無視してください。
配線済みの DEFファイルを
def read map9v3.def
コマンドでロードします。
配線グリッドを見たければ、
grid 1.6um 2.0um
としてください。”lef read”コマンドから、”grid”コマンド まではすべて “load.tcl“ というチュートリアルの先頭のダウンロードセクションにあるスクリプトに入っています。このファイルをダウンロードしたなら、layoutディレクトリに置いてください。そして、Magicをスタートし、コンソールに、
source load.tcl
とタイプして次のステップに進みます。
トップレベルの設計をセーブします。抽象ファイルを別のディレクトリのデータベースに取っておいて”addpath”コマンド（以下を参照）を使って抽象ビューと物理ビューを切り替えるのは便利ですが、この場合、抽象ビューを保存したくはないでしょう。データベースにトップレベルのセルだけを書き出すには、
writeall force map9v3
を実行します。
上の回路は、 qflow version 1.1.55で、電源ストライプを上述のようにし、最初の３つのレイヤーだけを使って配線しました。
ここで、Magicを終了し、（you really do want to exit!というプロンプトに対し、”Yes”と入力して）抽象セルビューは投げ捨てます。
すでにOSUのスタセルセットをダウンロード済みなら、このステップは飛ばして次にいってください。でなければ、osu035_stdcells.gds2 というファイルをページトップのダウンロードリストの中からダウンロードしてください(layout というサブディレクトリに置きます)。OSUスタセルセットをOSU websiteからダウンロードすることをお勧めします。とはいっても、チュートリアルにはここにあげたバージョンで十分です。
スタセルはたくさんあるので、これらのレイアウトビューを layoutディレクトリのサブディレクトリに置きたいでしょうね。その場合、layoutディレクトリで、以下を実行願います：
mkdir digital
cp .magicrc digital
cd digital
magicをロードするファイルを指定せずに、
magic -d OGL
のように起動します。そして、以下のように、GDSファイルをロードし、すべてのスタセルをセーブします。
gds read osu035_stdcells.gds2
writeall force
quit
上の文では、magicがファイルを見つけることができるようにするために、 osu035_stdcells.gds2をフルパスで指定するのに注意してください。上述のコマンド群では、GDSファイルは、digital というサブディレクトリにあると想定してます。
ここでlayout ディレクトリに戻ります。.magicrc スクリプトには、すでに “addpath digital”というコマンドが加わっているので、すべてのスタセルレイアウトビューを見つけることができます。次のステップはスキップします。
OSUスタセルセットをダウンロード済みなら、”addpath”コマンドを実行し、スタセルのMagicデータベースビューにアクセスできるようにしましょう。例えば、もしOSUの配布物を~/osuに置いたら、コマンドは、
addpath ~/osu/cadence/lib/source/magic
です。この文を”.magicrc”スクリプトに入れれば、magicがlayoutディレクトリで実行するたびに適用されます。
プロジェクトのトップレベルのlayoutビュー（抽象的LEFビューではなく、物理的レイアウトビュー）をロードします：
magic -d OGL map9v3
チュートリアルの最初に述べたように、qflow version 1.1.54には レイアウトのすべての行に自動的に電源とグランドを挿入し接続する”addspacers“という拡張ツールが用意されています。このバージョンのqflowをお持ちの場合、project_vars.shファイルに適切なオプションを追加すれば、以下のスクリーンショットに示すようにレイアウトの真ん中あたりに下に向かって２つの幅の広いmetal4のストライプが電源とグランドを完全に接続するようになります。これで人生が少し楽になり、おかげでこのステップの残りをスキップして次に進むことができます。そうでない場合、以下を続けてお読みください。
もう一度繰り返しますが、ここからこの記事の最後までの操作指示は、電源バスストライプの自動生成ができないqflowの古いバージョンに対するものです。もしレイアウトの真ん中あたりに下に向かって２つの幅広のメタルラインが走ってなければ、電源バスは接続されていないということなので、以下の操作指示に従わなくてはなりません。
qflowの初期のバージョンは電源バスを配置しません。スタセルのすべてのvddとgndが接続されていることを確認するには、magicレイアウトエディタを使ってvdd のmetal1ラインを右側に延長し縦方向に metal1 (最も簡単) かmetal2を使って接続してください。同じことを左側でgnd metal1に対し行います。そしてvdd metal1バスの上にカーソルボックスを置いて
label vdd n m1
とタイプします。同様に、gnd metal1 busの上にカーソルボックスを置いて、
label gnd n m1
とタイプし、
writeall force map9v3
を使って再度保存します。
２
これでこのレイアウトは、正しく動作するデジタル回路になったはずです。オプションの選択をどうするかによりますが、上の図と正確に同じではないかも知れません（この図はqflowの最新版に合わせて時々更新してますが、動きが違うこともあります。上の図は、高さ固定で6行という指定で流したものなので、デフォルトのオプションでの結果とはアスペクト比が異なります。）
この設計に対し以下のコマンド系列を使ってSPICEネットを生成します。
extract all
ext2spice hierarchy on
ext2spice scale off
ext2spice renumber off
ext2spice cthresh infinite
ext2spice rthresh infinite
ext2spice
このステップは、この回路のトランジスタレベルまで階層的した記述ファイル”map9v3.spice“を生成します。これは配線の接続関係から抽出された、物理的ビューです。これを合成によって作り出されたもともとのネットリストと比較したいと思います。
“cthresh infinte” と”rthresh infinite” を使うと、寄生素子の生成が無効になることに注意してほしいですが、これはLVS比較では不要なものです。そうしないと、レイアウトのネットリストに容量素子(“c”)が入って、スケマのネットリストと一致しなくなります。
これをやっている間に、IRSIMシミュレーションのために.sim形式のファイルを次のようにして作りましょう：コマンドは、
ext2sim
Magicを終了—-こいつの仕事は終わりです
Qflowの合成と再合成のスクリプトはBLIFフォーマットのネットリストから直にSPICEネットを作りますので、こいつに対して比較を行います。それはsynthesisサブディレクトリで見つけることができ、”map9v3.spc”という名前です。
“setup.tcl“というファイルを上記のダウンロードリストからダウンロードし、プロジェクトのトップレベルディレクトリに置いてください。このファイルは、netgenにテクとロジーとスタセルのセットについて重要な情報を教えるものです。特に、それは、回路図と一致させるために何かが必要な時にレイアウトの詰物のセルの数を数えたりしなくて済むようにするために必要です。
プロジェクトのトップのディレクトリでnetgen version 1.5を走らせます:
netgen
BLIFネットから生成されたSPICEネットは、スタセルの配布物からもってきたスタセルのサブサーキットのSPICEネットを直接使います。これらがレイアウトから抽出したスタセル回路と比較されます。スタセルの配布物から読み込んだレイアウトビューが同じ配布物のネットリストと一致するのは当然と思うでしょうが、スケーリングやウェルやサブストレートの入れ間違い、一般的な書式設定ミスに対する良い検証となります。
スタセルは一致しても、SPICEネットの書式の違いを何とかしなくてはなりません。回路は上位レベル（例えばチップのトップレベル）のどこかにつながらなければならいので、抽出したビューは、ポートについての情報を持ちません。一方、BLIFネットやスタセルのネットリストライブラリから作られたSPICEネットはすべてトップレベルセルに対してポート情報を持っていて、”.subckt”の記述をそれに対して持っています。これをnetgenで扱うやり方では、第２の回路についてSPICEネットのファイル名とサブサーキット名からなるリストをつけて”lvs”コマンドを呼びます（下図参照）。
抽出した回路と、スタセルのネットリストライブラリの両方とも同じ素子モデルを参照しているので、どちらのSPICEネットも低レベルの部品（例えば”nfet” や”pfet”）については同じ名前を使っているはずです。
netgenで実行するコマンドは：
lvs {layout/map9v3.spice map9v3} {synthesis/map9v3.spc map9v3}
ext2spiceについてmagicの動作は version 8.1.166で変更されたので注意してください。その前は、デフォルト動作ではレイアウトの内容をトップレベルのネットリストに書き出しました。 .subckt行が無い場合、どのネットがどのピンかを指定する方法が無いので、サブサーキット間でピンを比較することはできません。その場合、レイアウトのネットリストに指定するサブサーキット名はなく、LVSの呼び出しは：
lvs layout/map9v3.spice {synthesis/map9v3.spc map9v3}
です。
今度もすべて計画通りに行ったとすると、netgen出力の最後の2行は：
Result: Circuits match uniquely
LVS Done.
もしもこうならない場合は、LVSエラーの詳細なレポートがcomp.outという名前のファイルに書き出されます。いずれにしても、比較のまとめとして
comp.out
というファイルは、見る価値があります。
例えば、寄生無しで抽出し損なった場合、レイアウトの素子としてスケマビューには存在しない多くの容量素子が表示されます。
netgenは、コンソールを使わなくても以下の形式でコマンド行からnetgen完璧に呼び出すことができることに注意してください：
netgen -batch lvs “layout/map9v3.spice map9v3” “synthesis/map9v3.spc map9v3”
(そして同様に、magicのバージョンが8.1.166以前の場合レイアウトのネットリストにはサブサーキットの定義がないので、正しい構文は：’netgen -batch lvs layout/map9v3.spice “synthesis/map9v3.spc map9v3”‘です。)
レイアウトをiverilogでシミュレーションする
LVSによるネット比較は、設計における配置と配線内部の整合性を検証するに過ぎません（それ自体複雑であり、それゆえ高価な商用ツールでもエラーが起きやすいですが）。しかし、LVSは合成段階で生成されたスケマに対しレイアウトを比較するものであり、ゲートレベルのネットリストの機能の正しさについては何も教えてくれません。ゲートレベルのネットリストの機能検証はveilogシミュレータで行うのが賢いです。qflowは合成結果の出力としてゲートレベルのverilogネットリストを生成するので、verilogシミュレーションをもともとのverilogソースコードでも、構造をもった（ゲートレベルの）verilogネットでも実行は簡単です。
version 1.0.94 (April, 2015)以前は、構造的なverilogネットリスト “project_name**.rtlnopwr.v“は定義されていない”vdd“ と “gnd“を参照することがあったので、正しくシミュレーションするためには、”wire gnd = 1’b0;“ と”wire vdd = 1’b1;**”というverilog文を手作業でネットリストに追加しなくてはならなかったことに注意してください。qflowバージョン1.0.94以降は、これら２つの文が自動的に出力ファイルに書かれます。
verilogテストベンチの “map9v3_gates_tb.v” を上のダウンロードセクションからダウンロードしてください。また、スタセル (“osu035_stdcells.v”)のverilogも欲しいでしょうが、これは上のセクションか、OSUのスタセルダウンロードか、qflowのインストール済みのtechfileディレクトリ (デフォルトでは /usr/local/share/qflow/tech/osu035/osu035_stdcells.v*)にあります (そしてもともとIRSIMで書かれたテストベンチをverilog用に変換してくれたLeandro Marsóに感謝！)*
構造的なverilogはどんなverilogシミュレータでもシミュレートできます。Icarus verilog (“iverilog“)を選択すると良く、私のお薦めの１つです。テストベンチを走らせるには、iverilogに次の３つのverilogファイルを渡してあげるだけで良いです：
iverilog osu035_stdcells.v map9v3.rtlnopwr.v map9v3_gates_tb.v
Icarus verilogはコンパイラなので、デフォルトで、”a.out“という実行ファイルを生成します。テストベンチのシミュレーション結果を得るには、
./a.out
と実行します。
もし（gtkwaveやちょっと古いですがdinotraceのような）波形ビューアを使って出力波形を見たければ、このテストベンチは、”map9v3_tb.vcd“という出力ファイルを生成します。しかし、回路が期待通り動いていることを示すだけならそれが生成する診断出力で十分です。
VCD info: dumpfile map9v3_tb.vcd opened for output.
At time 0, counter = 00 (0), sr = 00 (0), dp = 000 (0)
At time 530000, counter = 94 (148), sr = 00 (0), dp = 000 (0)
At time 550000, counter = 93 (147), sr = 01 (1), dp = 000 (0)
… At time 3490000, counter = 00 (0), sr = 33 (51), dp = 000 (0)
At time 3510000, counter = ff (255), sr = 67 (103), dp = 000 (0)
At time 3530000, counter = ff (255), sr = 67 (103), dp = 0ce (206)
….
上記の最後の行は、dpの最初にラッチされた値が（十進の）206であり、期待通りの出力であることを示しています。dinotraceを使ったmap9v3_tb.vcdの波形ビューを以下に示します。
レイアウトをIRSIMでシミュレーションする
前述のようにicarusのようなverilogコンパイラ/シミュレータを走らせれば、もともとのソースコード（かまたは合成ツール）が生成したゲートレベルのネットリストの機能を検証できます。レイアウト対回路図の比較ツール（LVS）はゲートレベルのネットリストとレイアウトのトポロジー的な同一性を検証します。一般的に言って、これら２つを一緒に使えば、レイアウトの正しさを証明するには十分です。
しかしながら、最終的には物理的なレイアウトの正しさを直接的に、一番下位（すなわちトランジスタ）レベル、特に物理的なレイアウトの中の（そこそこ正確な）寄生容量と抵抗を抽出したネットリストを使って実行したいでしょう。
最良の方法は、Magic(上記参照）から “.sim” ネットリストを抽出しIRSIMを使ってシミュレーションすることです。IRSIM (IRSIM のWebサイト opencircuitdesign.com参照) には、Verilogのテストベンチと正確に一致するシミュレーションを構築するのに使える大変便利なコマンドがあります。
そこで、IRSIMを使ってシミュレーションし、アナライザの結果を例えば iverilogとdinotraceの結果に対して検証することができます。別の方法では、SPICEネットをMagicから抽出し、 ng-spice のようなSPICEシミュレータを使って検証します（そういうSPICEネットは、上記でnetgenのLVS用に作成したものとは異なることに注意してください。なぜなら、LVSのためのネットリストは寄生素子を含みませんから)。しかしながら、SPICEシミュレーションは、非常に正確ですが回路規模に対してスケールしません。中程度に複雑なverilogモジュールでもSPICEでのシミュレーションには、数時間、数日、あるいは数週間がかかります。それに対しIRSIMはトランジスタ、抵抗キャパシタのような同じレベルの部品（但しモデルは単純化してますが）で動作し、精度とシミュレーション性能の間で絶妙なバランスを実現しています。
簡単のために、 qflowのテクノロジーディレクトリからIRSIMのパラメータファイルを、あなたのローカルのディレクトリにコピーしてください：
cd layout
cp /usr/local/share/qflow/tech/osu035/osu035.prm
IRSIMのコマンドファイル”map9v3.tcl“ を上記のダウンロードのリストからダウンロードし、それをlayoutディレクトリにおいてください。
irsim osu035.prm map9v3.simのように、IRSIMを実行します。
IRSIMのコマンドウィンドウが出てきてネットリストがロードされたら、テストベンチのシミュレーションを実行するためコンソールに
source map9v3.tcl
とタイプします。
このスクリプトは、自動的にロジックアナライザのウィンドウを生成します。アナライザのウィンドウで左下の隅にあるターゲットのアイコンをクリックして、シミュレーションをすべて見ることができるように展開してください。あなたの確認することは、シミュレーションで、回路にスタートパルスが入り、クロックサイクルごとにカウンターとシフトレジスタが変化し始め、ほぼ１００クロック後に”done”信号がハイになって出力の”dp”がラッチすることです。このシミュレーションでは、Nの入力値は（十進の）220、そしてdpの出力値は（十進の）410になります。これらの数値が観測できるなら、回路は（最低限ですが）機能していることが検証されたことになります！
XSPICEを使ってレイアウトをシミュレーションする
最終的に、この例のような（アナログとディジタルの）ミックスモードのために使われる回路は、完全なアナログシミュレーション、つまりSPICEでシミュレーションしなくてはなりません。高速に変化する信号のエッジによりスピードが低下するのはSPICEの固有の限界であり、基本的に高速にスイッチする多くの信号の集まりであるデジタルシステムは、まるで這ってるかの如くSPICEを遅くします。
イベント駆動の同時並行シミュレーション環境であるXSPICEは、SPICEがデジタル回路をロジックゲートのレベルでヂジタル論理機能をトランジスターレベルでシミュレーションするオーバーヘッドを引き起こすことなくシミュレーションできる方法を提供することで、この問題を克服すべく開発されました。 XSPICEは、BerkeleyのSPICE3の中に開発されていますが、ngspiceにコンパイルされて組み込まれるので、その一部であるといえます。奇妙なことに、XSPICEはそれに値するほどの賞賛を受けておりません。その理由の一部は、XSPICEのモデルはC言語で書いてコンパイルしてSPICEに組み込まなくてはならないことにあります。XSPICEのソースにバンドルされているデジタルモデル群は通常のデジタルスタンダードセルを表現できるほど完全ではありません。しかし、フリップフロップやラッチ、そのほかの品揃えはあります。スタセルに新しい機能を実現するたびに新しいデバイスモデルをC言語で書く必要は無しに、任意の組み合わせロジックの機能を表現できる方法だけが必要でした。そこで私は、 XSPICEのモデルの拡張として、 それだけを行う”d_lut” と”d_genlut”と呼ばれるものを書きました。これらは、任意の組み合わせロジックの式をルックアップテーブル（LUT)の出力としてエンコードすることができます。これを使うには、”d_lut” と “d_genlut”のモデルをC言語でコンパイルするだけで良く、そのためにそれをサポートするngspiceのあるバージョンが必要です（この記述時点では、それは ngspiceの開発用ブランチである “scope-inpcom-8”だけにありますが、いずれ近いうちにメインの配布物に組み込まれるでしょう。）
qflowのソースの中に私は”spi2xspice.py”というスクリプトを書きましたが、それはスタセルを記述するLiberty形式のファイルとスタセル論理からなる回路のSPICEネットを読み込み、フリップフロップやラッチについてはもともとのプリミティブを使い、すべての組み合わせゲートに対しては新しいLUTモデルを使って、すべてのデジタルゲートをXSPICEのプリミティブで表現したネットリストを生成します。
qflowのバージョン1.1.52以降では、XSPICE用ネットリストを自動的に生成します（スクリプトの実行にはpython3が必要）。Qflowはngspiceのバージョンを検査しませんが、もちろんXSPICEのネットリストを使ったシミュレーションには、XSPICEにLUTモデルを組み込んだngspiceが必要です。XSPICEの（”.xspice”という拡張子を持ち、”synthesis”ディレクトリに置かれた）ネットリストは、いかなる互換性のあるSPICEシミュレーションにおいて、サブサーキットを直に置き換えることができます。この回路は、もちろん、単純化したやり方でシミュレーションを行うものであり、デジタルのタイミング検証には適しませんが、非常に高速であり、ミックスシグナルシステムの機能検証シミュレーションに最適です。
上記のダウンロードセクションからSPICE用テストベンチ”map9v3_cosim_tb.spi” をダウンロードしてください。このテストベンチは、SPICEのプリミティブ（つまり独立電源）を使って対象の回路のテスト対象素子にパワーを供給し、クロック、リセット、スタート信号を加え、入力値を適用します。それは、過渡解析を実行し主要な制御信号をプロットするために、ngspiceの制御ブロックを使います。XSPICEのシミュレーションにおける制御信号の図を以下に示します。
比較のために、SPICEテストベンチファイルの先頭にある”include”文を、トランジスタレベルのSPICEネット”map9v3.spc”に置き換え、再度実行してみてください。このことから、XSPICEのネットリストは、まさにトランジスタレベルのネットリストのかわりにすぐに使え、そしてXSPICEのモデル（トランジスタレベルのシミュレーションが終了するのを待つのはつらいでしょうが）を使うといかにパフォーマンスが改善するかわかります。
| email: | |
Last updated: June 26, 2017 at 11:49am