将来直るかもしれないけどISE Simulator(Lite）は遅いしModelSimと同じデザインをシミュレーションしても結果が異なるし（ModelSimでは意図した通り動作してもISE Simulatorだとそうならない）問題多い。

論理合成後の内部信号もばらけてしまっていてレジスタだけみたいと思っても簡単にはいかない。ModelSimならレジスタは束ねられているのでそのまま波形表示に追加できる。

など様々な現状を見てもISE Simulatorを使うのは得策ではないしスターターキットの冊子とかにも書いてあるのはModelSimの使い方だし。

ISE 9.1iになってISE SimulatorやUIが大分改善されるまではModelSimということになるのかも。

あとAtlteraのQuartus IIとかはMax+Plus IIの流れをくんでいるもののどちらかというとISEの後追いの要素が多いがシミュレーターは良くできている。ただし古い世代の設計者向けにシミュレーションもタイムチャートをきっちり書いてという人向きなので新しい世代(HDL派）のようにテストベンチをHDLで書いてという場合にはどうすればよいかわからず。きっとやり方はあるに違いない。

RTL ViewなどはXilinxの方が先駆者的なところがあって使い易い感じがする。Alteraは昔から合成された式を見てというのではさすがにまずいということでRTL Viewerを提供してきたものの使い勝手はいまいち。

Alteraで動作確認済みのHDLソースはそのまま修正なしでXilinxのISEでCPLD/FPGAのどちらでもエラー無しでコンパイルできます。特にAltera固有のライブラリや機能に依存していないからです。

しかしまったく同じように動いてくれるわけではありませんでした。

XilinxのFPGA(Spartan2E：xa2s50e-6tq144）をターゲットにした場合は以下の１点を除きAlteraのFPGAと同様に動きます。

・コンフィグレーション後直後から100nsの間はグローバルシステムリセット期間なのでレジスタは０かデザイン時に指定された初期値に強制的にセットされるのでその間回路としては動作しない。シミュレーションの入力波形は少なくともこの期間の後に与える必要がある。

Xilinxの場合はUser Constrainで動作周波数をちゃんと指定しないと配線をさっと済ませてしまうので配線遅延が大きくなりAlteraよりも遅い回路になってしまいます。ちなにみFPGAの場合はCPLDと違って最大動作周波数とかを教えてくれないのでUser Constrainで指定するか実際にPost-Route Simulationをしてみるまでは意図したクロック周波数で動くかどうかはわかりません。

XilinxのCPLD(CoolRunner II:XC2C256-6-VQ100）をターゲットにした場合は、SRAMベースのFPGAとはアーキテクチャが異なるため以下の１点を除きAlteraのFPGAと同様に動きます。

・電源立ち上がりから100nsの間はグローバルプリロード期間なのでレジスタは０かデザイン時に指定された初期値に強制的に固定されるのでその間回路としては動作しない。シミュレーションの入力波形は少なくともこの期間の後に与える必要がある。

XilinxのCPLDの場合はUser Constrainを指定しなくてもきっちりそれなりの最大周波数で動くように配置配線してくれます。なにもしなくても最大動作周波数が50MHzを超えました。

最初GSRやらGPRLDとかのXilinx特有のアーキテクチャを知らなかったため意図した通りの動作をしてくれず悩みましたが、デザインを変更しなくてもシミュレーション上は同じように動いてくれることがわかって一安心。

そのまま動くといってもPost-Route Simulationした場合で、そのままですとCPLD/FPGAともBehavioral Simulationではカウンター値が不定になって意図した通りには動いてくれません。これはBehavioral Simulationが純粋にHDL記述情報のみでシミュレーションを行うためでデバイス固有の初期化にからんだ初期化動作は含まれないためです。

なのでVerilogの場合はinitialプロセスで少なくともカウンターの初期値は代入しておかないとカウンター値が不定のまま動かないことになります。

initialプロセスでレジスタを代入するとそのためのプロダクトタームが余分に消費されるのではという心配が沸きますが、RTL Viewerで見てもそれに該当する部分は見つかりません。レジスタの初期値は実はプロダクトターム外のCPLD/FPGAコンフィグレーションデータに反映されるからです。

ISEのUser Constraintsを作成する際にMiscのところのINIT ValueというところにFF等の初期値を設定するところがあります。これがおもしろくてデザインを入力すると自動的に該当するレジスタのリストが一覧で出てきます。各FFについて1か0を設定することが可能です。何も指定しないとデフォルトは0だと思われます。

実際にinitialプロセスでは何も代入せずにUser Constraintsで初期値を設定してPost-Route Simulationしてみるとレジスタの初期状態に設定した値が反映されていることが確かめられます。

このあたりの仕組みはXilinxの最新のCPLD/FPGAで確立したところのようでCPLDもFPGAもSRAM方式になりCPLDはFPGAとは少しアーキテクチャが違うFPGAとコンフィグレーションデバイスを一緒に内蔵したチップといった感じです。こうした傾向はALTERAもMAX IIから似たようなことをしてますね。ALTERAの場合はFPGAもCPLDもアーキテクチャはほぼ一緒ですが。

Xilinxの最新のデータシートを見るとCoolRunner-IIでもSpartan2Eでもレジスタの初期化にからんだ信号GSRは呼び名が一緒ですがそれ以前は違っていたようです。実際には今もCPLDとFPGAとでは少しアーキテクチャ上の差異があります。

Alteraの場合はいずれにせよinitialプロセス自身を論理合成ツールがサポートしていないのでレジスタは0リセットなのかなとふと疑問に思ってきました。もしかしたらXilinxのように設定できるのかもしれませんしできないのかもしれません。

XilinxのRTL viewerで見るとBCDの年月日時分秒の各桁毎にBCD->7segデコーダーが生成されているのが容易にわかる。

AlteraでもRTL Viewerはちょと信号がばらけてしまっていて見にくいがXilinxと基本的には同じで各桁ごとにデコードされた信号を最後にセレクタで一桁だけ出力するという論理になっている。

これは意図したのとは実は違っていてリソースが無駄に使っている。HDLの記述の仕方が悪いんだろうけど。

本当は最初に表示する桁のBCD出力を１桁だけセレクトしてそれを単一のBCD->7segデコーダーを介して出力するというシンプルなものを意図していた。

うごけばいいんだけど、今になって本当はもう少し小さくなるのかもと思い始めてきた。

たぶんHDLの書き方次第で意図した通り論理合成される可能性もあるので時間が出来たらやってみるつもり。

結局function内でcaseでbcddecode関数をいくつも書いてたのでそのまま論理合成されてbcdデコーダーがいくつもできてしまっていたようだ。

なので素直にそれをやめてbcdデコーダーの入力値だけセレクトする関数に書き直してそれを先に読んで戻り値をbcddecodeの引数として渡すようにしたところbcdデコーダーは１個だけになった。

年月日時分秒reg->mux->bcddecode->seg信号ピン

という意図した通りの論理が生成された。結果的に必要となるLUT数が減って少しコンパクトになった。

今までどれにもfitしなかったXC9500シリーズのCPLDでもXC95216-10-PQ160にぎりぎり入るようになった。これは結構うれしい。

まだ少し意図しない合成がされているところがあるやもしれない。

nDIGITの論理合成がかなり冗長である。

１４桁すべての信号生成に本来関係のない一部の桁のゼロサプレス表示の条件判定に使われる信号が入力に含まれたまったく同じ回路が１４桁分出来ている。実際には他の入力信号によってゼロサプレスするかどうかの条件が決まっているとは思うが。もったいないことだ。

どう書き直せば意図したような単純な回路が生成されるのだろうか。たかがcase文ひとつ含む関数とそれを呼ぶassign文だけしかないのに。

Xilinxの合成結果をRTL Viewerで見るとたいそう大規模なネットリストに見えるけど、Technology Viewerのゲートレベルのネットリストにして見るとそんなにたいそうなものではないというのが判明。Technology Viewerで１ページにネットリストを全部表示させてもそんなに大規模ではないこともわかる。

Alteraの合成結果をRTL Viewerで見ると意図した通りに4bitのdispsel値をデコードし16本のnDIGITイネーブル信号にしてそれを極性反転したものと月、日、時、分、秒のレジスタ値からゼロサプレス条件を比較した結果をそれぞれ該当するnDIGIT出力とORしている。Technology mapを見るとそれらはいくつかのLUTをチェインすることで構成されている。これはこれ以上圧縮のしようがないと思われる。

XilinxとAlteraとではRTL ViewerおよびTechnology Viewerと名前は同じでも表示の仕方はまるっきり違っていてどちらも似ていない。Xilinxに至ってはTechnology viewといってもLUTよりももっと低いゲートレベルのネットリスト表示になってしまっていてちょっと違う気もしないではないがこちらの方が論理を追いやすいのは確か。Alteraの場合はLUTベースまでだけどそっから先LUTの論理式を読んで追わなければならないのでちょっと直感的ではない感じ。それでも両者それぞれ違った表示機能や使い勝手があるので使い込んでみないとなんとも。Alteraの場合は関係のないネットリストは表示しないようにラブアウトすることができるのでそれを使って絞り込んでいけば追いやすいのかも。

Xilinxの合成結果を良くみると律儀にゼロサプレスのあり得る特定の桁の時だけゼロサプレスの論理生成されるようにわざわざ特定の桁を条件に入れている。よく考えればすべての桁のイネーブル信号はパラに出力されるのでゼロサプレスするかしないかは常にやってしまってもいいわけである。Aletaraの場合はするどくそれを読み取って論理を最適化している。

HDLを少し変更してcase文の外で年、月、日、時、分、秒がゼロサプレスする値ならば該当するnDIGIT信号bitを強制的にネゲートするようにしたところXilinxのRTL viewerの姿ががらっと変わった。記述通りにdispselのデコード信号それぞれに対して月、日、時、分、秒のそれぞれのゼロサプレスパターンでマスクして最終的なnDIGIT出力を得るような形になった。

しかしTechnology Viewerで見るとまったく変わってなかったりする。リソースの利用率も変わらないのでおそらく最初からAlteraのとほぼ等価な論理合成だったのだろう。XilinxのRTL Viewerは合成されたネットリストではなくあくまでHDL記述をネットリストに翻訳した結果を表示していると思ったほうが良いのかも。最終的にデバイスにmapされた結果はそれとは異なると。

それとAlteraとXilinxで微妙にVerilogのシンタックスが違っていた。function定義で複数の文を含む場合、Xilinxの場合は複数の文をbegin endで囲まないとエラーになってしまう。Alteraの場合はエラーにならない。よく見るとXilinxのテンプレートとかはfunctionだけでなくcaseやifまでbegin endを使うようになっている。確かにその方がいいんだけどね。

Xilinxの合成結果をRTL Viewerで見てみるとやっぱり納得いかない点がある。その最たるものはnDIGIT出力の生成でdispselのデコード出力とゼロサプレスの有無でビットをORする論理が冗長である点。たとえばゼロサプレスが行われない桁のnDIGITでも以下のようにゼロサプレスの有無の信号を入力とする論理が生成されている。



よく見るとわかる通りゼロサプレスを左右する信号の状態に無関係にdispselのデコード信号がそのまま出力になるだけの論理である。ただの信号中継的な意味しかない。

ゼロサプレスが関係する５つの桁については以下のような論理が入っていてゼロサプレスの条件が出力を左右している。



なのでdispselのデコード出力（１４本）とゼロサプレスのマスクを論理和するだけのために全部で5x14=70ものLUTが使われている勘定になる。７０のうち５つを除いては単に信号を中継してディレイをそろえているだけである。

やはり贅沢にLUTを使えることを前提にした論理合成と言える。

ALTERAの場合は、１４＋５＝１９のLUTしか使われていない。そのためXilinxよりも一見すると総LUT使用数は少ないように見える。

しかしXilinxのTechnology mapを見るとRTL Viewerで見たのとは似ても似つかぬネットリストを見ることができる。実際にデバイスにマップされる時点でdispselデコーダーとゼロサプレス論理はAlteraの場合とほぼ似たような感じで最小数のLUT上にマップされていることがわかる。基本的に4bitのdispselの値から各nDIGIT信号用のイネーブル信号が生成されそれと併せてゼロサプレス条件が必要なビットだけ加味されて最後全部インバーターを介して極性反転して出て行く感じになっている。

これはRTL Viewerで見たのとかかなりイメージが異なるので慣れないとXilinxのXSTはかなり頭悪いんじゃないのとあらぬ疑いをもってしまいそうである。最終的にTechnology mapを見ないと意図した通りになっているかどうかは判別つかないということで。

ふとゼロサプレスの特定の出力信号に1をセットしているのを14bitのマスク値の論理和演算ではなく直接ビットに1を代入するように以下の様に変えてみたところRTL Viewerの見た目はAlteraのとほとんど一緒になった。

function [13:0] digit;
input [3:0] sel;
begin
case (sel)
4'b0000:
digit = 14'b11111111111110;
4'b0001:
digit = 14'b11111111111101;
4'b0010:
digit = 14'b11111111111011;
4'b0011:
digit = 14'b11111111110111;
4'b0100:
digit = 14'b11111111101111;
4'b0101:
digit = 14'b11111111011111;
4'b0110:
digit = 14'b11111110111111;
4'b0111:
digit = 14'b11111101111111;
4'b1000:
digit = 14'b11111011111111;
4'b1001:
digit = 14'b11110111111111;
4'b1010:
digit = 14'b11101111111111;
4'b1011:
digit = 14'b11011111111111;
4'b1100:
digit = 14'b10111111111111;
4'b1101:
digit = 14'b01111111111111;
default:
digit = 14'b11111111111111;
endcase
if (MONTH[4]==1'b0) digit[4] = 1'b1;
if (DAY[5:4]==2'b00) digit[6] = 1'b1;
if (HOUR[5:4]==2'b00) digit[8] = 1'b1;
if (MINUTE[6:4]==3'b000) digit[10] = 1'b1;
if (SECOND[6:4]==3'b000) digit[12] = 1'b1;
end
endfunction

以前は
if (MONTH[4]==1'b0) digit = digit | 14'b00000000010000;
とか書いていた。意味的には一緒であるがRTL viewerで見ると前は意図したのとは大分違っていた。今度はだいぶRTL Viewがすっきりこじんまりした。Technology mapはまったく変わらない。

Alteraの場合はHDLの記述が違っても意味的に同じであればRTL Viewerは変わらないのでHDLでの記述の仕方で惑わされることはない。