Alteraでは問題なくコンパイルできる某リファレンスデザインをXilinxでコンパイルしてみたらエラーが出る。

どうもユーザー定義タイプが一部見あたらないらしい。

ちゃんと定義しているのに。

よく見たら定義は小文字で参照は大文字だった。

XilinxのVHDLは大文字と小文字を区別して扱うのか。

定義の方を大文字になおしたらコンパイルが通った。

小規模のデザインを試したところで何もわからないが、わかったことは。

・Xilinxの論理合成はHDL記述に忠実である。反面解析が浅いので大局的な最適化はしてくれない。
・Xilinxの場合、論理圧縮はほとんどデバイスへのマッピング以降で行われる。といってもこの段階ではもう大局的な圧縮はできないので局所的なものになる。
・Xilinxの場合、CPLDとFPGAとでデバイスのアーキテクチャが異なるので最適化方法がデバイス毎に異なるため最適化が後回しにせざるを得ないのかも。
・Alteraの場合最新のCPLDとFPGAはほぼアーキテクチャが似ているのでネットリスト生成時に共通の最適化をやってしまっている。対局的な最適化も行ってしまうのでHDL記述に忠実とは言えないネットリストができあがる。
・Xilinxの場合はある程度HDL記述で回路の奥行きが広がらないようにしてやらないと忠実に冗長なネットリストを生成してあとで圧縮がきかなくなってしまいかねない。

VHDL版の万年時計をXilinxでコンパイルしてみるとVerilog版で書いたものよりもX9500XLをターゲットにした場合スピードが出ない。X9500の時と同じしかでない。

Verilog版でもX9500は23MHzぐらい、X9500XLだと大分速くなって84MHzぐらいまでいく。

それにVerilog版だとXC95288XL-6-TQ144にFitしているのにVHDL版は何故か大きなXC95288XL-6-CS280でないと入らない。どうも必要とするFB数が多すぎるようだ。

何故だろう。

謎がまた。

VHDL版とVerilog版でそれぞれ合成されたネットリストをRTL Viewerで見比べてみても目立った違いは見あたらない。

レジスタ構成は同じ、加算器と比較器やMUXの数も同じ。多少RTL Viewer上での配置の位置関係は違うけれども基本的には同一構成に見える。

あとは小いさなMUXやAND/OR論理の違いだろうか。

と思って論理合成レポートを見比べてみたら一個ROMの幅が違うのを発見。

VHDL版だと

Found 8x1-bit ROM for signal <$mux0002> created at line 168.

なのが、Verilog版だと

Found 8x2-bit ROM for signal <$rom0000>.

になっているしかしVerilog版の方がROMサイズが大きいのに逆にプロダクトタームは少ないというのはどういうことだろう。

しかしそれ以外はレポート内容はまったく同一。

問題となる8x2のROMは年から閏年判定を行う論理の一部を構成するがVerilog版とVHDL版とで明らかに合成結果が違う。

Verilog版では3入力2出力のROMになっているが実際には３入力１出力のMUXで出力がその先の論理で正負２つの入力論理に枝分かれしていた。ちょっと釈然としない表示のされかたではある。

VHDL版では３入力１出力のMUXとしてVerilo版と同じ論理で合成されていて実質はVerilog版とまったく同じ。

少なくともHDLからの論理合成したネットリストは意味的にはまったく同じだと言ってよい。するとデバイスへのマッピングおよびFit時に微妙なネットリスト構成の違いが違いが出たとしか言いようがない。

Technology Schematicで見比べてみても寸分違わず同一だった。

ということは何かFiting時に差異が加わっているのだろうか。

気になるのはVHDL版の方で以下の警告とエラーが出ている点。

Warning]:Cpld:868 - Cannot fit the design into any of the specified devices with the selected implementation options.
[Error]:Cpld:886 - Function block FB10 was too congested to route successfully. This occurs due to excessive (>= 50) product term input fanins to this function block. Consider moving output signals in this function block to less congested function blocks, buffering output signals that must remain in this function block, or selecting a larger package.

Verilog版だと自動的にCLOCK1MがGCLK1に割り当てられているがVHDL版ではそれが無い。

よく見たらFitが失敗しているレポートになっている...orz

どのデバイスにも入り切らないということだったのか。

もしかしてバグにあたってしまったのだろうか？

Verilog版はX9500やCoolrunner 2をターゲットにするぶんにはVerilog版よりもむしろ使用リソース数が少しちいさくなるがX9500XLをターゲットにするとリソース数が増大してFitに失敗するという違った結果になることが判明。

やはりバグか。なぜ記述言語の違いで結果がこうも違うことになるのか謎

VHDLはかなり記述に忠実にネットリストが合成されるがVerilogだと少し意図しない形になっている、その分Verilogで書いたほうがプロダクトターム数が増えている。しかしTechnologu Schematicで見比べる限りは頭からしっぽまでネットリスト的にはまったく同一。

デバイスへのFit時に言語の違いが影響するように見える。

よく見るとX9500XLへのFitの際にはログに出てくるメッセージの内容がX9500の時とかなり違っている。特にequationの数が何故かX9500の時は129だったのがX9500XLになると135に増加している。どうもFit時のデバイス固有の最適化が悪さしているように見える。

Compiler optionのFit時のImplementation TemplateをOptimize BalanceからOptimize Densityに変えてやってみたらなにもしないVerilog版の時よりも一回り小さいXC95144XL-5-TQ100に収まってしまった。

最高動作周波数はVerilog版のなにもしないVerilog版の84MHzよりも劣る50MHzになった。

equation数はなにもしない時よりもむしろ多い139。Optimaize Balance指定だと余裕が少ないと一回り大きなものにしてしまうようだ。

しかし納得がいかない。VHDL記述をなんとかすればVerilog版と同じ結果になるのだろうか？

先ほどのはVHDL版で合成されたネットリスト(NGC)を入力とする新しいプロジェクトを作成しそれでFitをさせてみた場合の話でした。

今度はVHDL版でFit時の最適化方法をOptimize BalanceからOptimize Densityに変えてやってみるとやはりXC95144XL-5-TQ100にぎりぎり収まる。

しかし最高動作周波数がネットリスト入力の時よりも低い33MHzという違った結果になった。

Verilog版も同様にやってみるとこちらは34MHzとほぼ一緒の結果。

一度ネットリストを吐き出させてそれをデザイン入力とするプロジェクトを作成してデバイスにFitさせると言語入力時よりも高速に動作するという裏技がある？

また新しい謎が...

先にFit時の最適化をDensityにして合成したVHDL版のネットリストを入力としてコピーし直してやってみたところ今度はVHDL入力のプロジェクトと同一の結果になった。これが当たり前である。

いろいろやってみたけれどももう再現しなくなった。
なんだったんだろう。

新にわかったのはVerilog版とVHDL版とで最終的にFitさせようとしたequationを見比べると大分見た目が違うという点である。

基本的には同じなはずだが記述言語によって生成される式の順序とかが違ってくるからだろう。

Technology Schematicが同一に見えるというのがそもそもバグなのだろうか？

皆目わからなくなってきた。

どうにも難解なのでデザインのHDLソースを丹念に一行一行見直していたらやぶ蛇でバグを発見。

１０月かどうか判定するのにBCDコードではなくて１６進数で10.と比較していた...orz

修正して再コンパイルしたらVHDL版と同じようにどのCPLDにもFitしなくなった...orz