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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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時に微妙なネットリスト構成の違いが違いが出たとしか言いようがない。

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

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

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

何故だろう。

謎がまた。

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

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

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

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

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

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

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

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

ふとゼロサプレスの特定の出力信号に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での記述の仕方で惑わされることはない。

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を見ないと意図した通りになっているかどうかは判別つかないということで。

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を使うようになっている。確かにその方がいいんだけどね。