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の場合は関係のないネットリストは表示しないようにラブアウトすることができるのでそれを使って絞り込んでいけば追いやすいのかも。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

そのまま動くといっても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のように設定できるのかもしれませんしできないのかもしれません。

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

将来直るかもしれないけど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を提供してきたものの使い勝手はいまいち。

ターゲットデバイスをSpartan2Eに変更しコンパイル後にGenerate Post-Synthesis ModelとかGenerate Post-Map ModelとかGenerate Post-Route Modelとかが？マークがついていたのでそれをクリックして実行して再度シミュレーションをやったところ、今度はちゃんと内部信号もリストに全部出てくるようになった。

ということはデフォルトでは内部の信号はみれないということか。
いちいち合成後のモデルを生成しなおさないといけないのはなんとかならないのだろうか。

Spartan2EにしたのがよかったのかBehavior Simulationもハングせずに出来るようになった。

ISE Simulatorの場合は合成後のモデルを用いたシミュレーションはPost-Route Simulationしか無いのでそれを実行すると、最初ModelSimから変更した影響かタイミング違反が起きたとかでシミュレーションがしょっぱなで停止した。

もう一度やり直すと今度は嘘のように先へ進んだ。なんだったんだろう。

どうやらCPLDだとシミュレーションはいろいろ難がありそうなのかもしれない。

シミュレーションに要する時間はAlteraの時とそんなに感覚的に変わらない程度。ちょっと開始時にかなり長い時間だんまりになるのが精神衛生上良くない。本当にrunしたのか我を疑ってしまう。

性能的にはModelSimの方がシミュレーション速度が目に見えて速い。ISE Simulatorだとシミュレーションが終わる間にたっぷり食事とかが出来てしまう。

なので普通は面倒でもModelSimをインストールしてライセンス申請をして使うのが正解だろう。ライセンスは自動で即時交付されるので待ち時間は無い。

最初に表示される桁が正しくデコードされない原因はXilinxのレジスタ固有の問題だったらしい。

ALTERAの場合はレジスタは単純にD-FFなのでクロックに同期して出力が更新される。

それに対してXilinxのレジスタはD-FF内部の後段の出力ラッチをCE(Chip Enableというらしい）によって更新するかしないかを制御できる。これによって高速なクロックを用いていても後段のラッチが変化するのは必要な条件だけにすることができる。

実際RTL Viewerで見るとCEは条件付きでそれぞれenbaleになるように論理合成されている。おそらくその条件として表示桁の変化や秒替わりが含まれているだろう。



ならば表示桁制御のカウンター初期値を最初のクロックの立ち上がりで表示桁が更新されるようにすれば誤った値が表示されるのは最初のクロックの立ち上がりまでの間に限定される。

実際にデザインをそのように修正してみたところ意図した通りに動くようになった。



最初シミュレーション時間が早いだろうとBehavior Simulationをしようとしたら永遠に応答が無いので使えないということが判明。

ISE SimulatorのBehavior Simulationは本当にモジュールの入出力しか見ることができないのでほとんど使えない。

Post-fit Simulationは内部のレジスタや変数だけは見ることはできるがそれ以外の内部信号は見ることができないのでAlteraと比べるとかなり使えない。

たぶんModelSimならば任意のネットリストを見ることができるとは思うが。とりあえずCドライブをなんとか用意しないとライセンスが...コンパクトフラッシュを買ってこようかな。

結局ISE SimulatorはいくらEnd timeを長くしてもどうやら一定時間以降は入力信号が変化しなくなるという制限があるらしい。



End Timeは101msでTBWを作成したのだが生成されるテストベンチコードを見てもEnd Timeまではクロックを生成するコードになっているのでシミュレーター内部でどうやら一定時間(3?ms程度）以降は変化しなくなるような制限処理を行っていると思われる。

仕方がないのでデザインを修正して１秒の分周値を１０分の１に減らしてクロック周期を２０倍(20MHz)にすることで１秒を２００倍に短縮し5msで秒替わりが来るようにしたところ制限内で何度か秒替わりの動作を確認できた。



本来はデザインを修正せずに確認したいところだが致し方ない。ハングするように見えるのはTBWのグラフィック描画が異常に時間がかかるためで、最初は短いEnd Timeで作成して後で生成されたテストベンチソースコードをエディタで修正してEnd Timeを書き換えるのがよさそうである。シミュレーション結果の波形の表示は長いEnd Timeでも問題ないので今度からそうしよう。


それとやはり最初にデコードされ表示されるべき年の最上位桁が年レジスタの初期値（initialブロックで初期化しないと不定、初期化するとその値）のままである。プリセットによってレジスタには設定入力がロードされているのだがその出力が変化しないのはおかしい。レジスタの実装はFDCEになっているので更新されれば出力も変化してしかるべきである。



これは実際どうなのかは実機で検証するしかない。もしかしたらシミュレーターの問題なのかもしれない。

それとSimulation結果の表示の仕方もUIがおかしい。横にスクロールしようとしてもすぐ隣のタイミングではなくかなり離れたタイミングまで一気に飛んでしまう。なのでその間のタイミングは見ることができない。なんだこれは。使えない。

なんとか見るためにはズームイン・アウトしながらみたい時間帯がうまく画面に収まるようにするしかない。一旦画面から外れてしまうとスクロールしても見ることはできない。