問題のシミュレーション波形を調べてみるとhold timeバイオレーションというよりはFFのCLK立ち上がりの後に入力が変化しているということが判明。

今までテストベンチ波形作成時のデフォルトsetup時間、15nsのままでXC9500以外では問題なかったが、XC9500は他のデバイスと比べて数倍動作が遅いのでそれでは内部遅延によってCLKに追い越されてしまうのでもっと余裕をもって先に確定していないとだめだということが判明。

テストベンチをRescale timingでsetup時間を50nsに変更してやり直してみたら今度はhold time違反は起きなくなり問題なく動作することが確認された。

今度からテストベンチを作る際には注意しないと。

XilinxのCPLD XC9500シリーズにも収まることは収まるのですが、実際にPost-Fit Simulationをしてみたところどうやら一部の年月日時分秒のFF内でhold timeバイオレーションが出て誤動作する可能性が濃厚です。

# ** Error: C:/Xilinx/verilog/src/simprims/X_FF.v(94): $hold( posedge CLK:702500 ps, posedge I &&& (in_clk_enable1 == 1):704 ns, 3500 ps );
# Time: 704 ns Iteration: 7 Instance: /test/UUT/\YEAR<7>.REG\

以前Coolrunner-IIでしかPost-Fit Simulationは問題なかったのと今までCPLDではやってなかったので気づきませんでした。

なぜholt timeが足らなくなるのかFFのシミュレーションモデルの内部信号を見ると確かにCLKが立ち上がってすぐに内部の入力が変化しているため出力が不定になってしまっています。プリセットシーケンスで入力が変化するというのはおかしな話ですが謎です。

Verilog版でもVHDL版どちらもXC9500シリーズはだめでした。
XC9500XLシリーズはどれも入りません。XC9500XVシリーズだとXC95288XV-6-CS280で容量的にもスピード的にも余裕でCoolrunner-IIと同じようにPost-Fit Simulationも通ります。

デバイスに収まるけどまともに動かないという事態に陥ったら手もつけられないですね。

XC95260-10-PQ160にVerilog版とVHDL版が収まったところでXilinx対応は収束ということに。

Xilinx用に修正したソースをAlteraのQuartus IIに食わせると使用LE数が１個増加します。function内のreg使用をやめると元に戻ります。

それとXilinxのVerilogの場合はcase文のdefault行で設定する値をall 1にするかall 0にするかでも合成結果が大きく変化します。一概にall 1にすればいいとかall 0にすればいいとかというわけではなく他のケースとのかねあいなようです。

Alteraの場合はHDLを多少見た目を変えたとしても意味的に変化なければ合成される結果に影響をほとんど与えませんでした。

ほんのちょっとの違いでFitするデバイスががらっと変わるのもこまりものですね。

菅原システムさんとこのVerlogシミュレータVeritakのVHDL->Verlog変換機能を使って万年カレンダーのVHDLソースをVerilog HDLに変換してみた。

ものの見事に瞬時に綺麗な意図した通りのソースコードができあがった。最初からそうすればよかった。でも最初に書いたのはVerlog HDL版だったような気がする。それをVHDLにハンドコンバージョンしたはず...

できたVerilog HDLソースをコンパイルしてみるとVHDL版と同じようにXC95216-10-PQ160に入った。しかもVHDL版より高速!

VHDL版が23.810MHzなのに対してVeritakで変換したVerilog版だと32.258MHz。

泣けてくる。

拙作オリジナルのVerilog版とVeritakでVHDL版からコンバートしたものを見比べると著しい違いは以下のようなものしかない。

・出力信号と同じ名前でwireが宣言されている
・function isleapyearの戻り値の長さが明示的に1bitに宣言されている
・function定義が参照より後に置かれている（後方参照）
・function定義内ではreg変数を介して戻り値をセットしている。
・出力信号の継続的代入で代入先が{}でくくられている
・関数戻り値の評価を明示的に同じ長さの定数と比較して行っている
・論理和(||)や論理積(&&)の代わりにbitwiseOR(|)やbitwiseAND(&)演算子を使っている

もしかして最初と最後が秘密のKnowhowなのかも。

そこでまたオリジナルVerilog版ソースに戻してます出力信号に関するwire宣言を追加してみたが宣言してもしなくても結果は同じでこれはあまり意味がない模様。

次にfunction戻り値の長さを明示的に宣言してみた。これも影響無し。

後方参照も変わらず。

最後function内でのreg変数を使った間接的な戻り値の代入をやってみた。これによって論理合成に差異があらわれた、今まで閏年判定用のROMが8x2だったのがVHDL版と同じに8x1に圧縮された。

しかし結果は変わらず。

残り論理演算をbitwiseに書き換えても変わらず。

なんなんだ、と思ってVeritakで変換してソースを見てみるとselbcd functionのところのdefaultが空行になっている。

同じようにしてみたらやっとXC95216-10-PQ160に収まってくれた。

ということはキーポイントはcase文のdefault行で0〜13以外のdispselカウンター値の際の表示bcd値を固定値にしていたのをやめるだけでだいぶ論理が減ったということになる。むやみやたらdefault行を付けるのは考え物なのだろうか。

最高動作周波数はVHDL版と同じデフォルトの最適化指定でもやはり速くなる。

それで元々のVerilog版のソースでselbcdのdefault行を空行にすると新しい警告が出るが同じ大きさのデバイスに収まった。たったこれだけのことだったのか。

ただ警告が出ている通り最大動作周波数は遅くなっている。

何度も繰り返しコンパイルしているとどうやらISEがおかしくなってソースコードがエディタ上で変更できなくなってしまう。おろらくバグだろう。

ISEを立ち上げ直して今度はselbcdを内部でreg変数を使った間接的な戻り値代入に変えたところ驚くべき結果となった。

なんと一回り小さいXC95144-7-PQ100に収まってしまった上に更に39.216MHzと高速に動作するようになった。

この時点でまだ気になる警告が依然として残っている。

WARNING:Xst:737 - Found 1-bit latch for signal <$old_selbcd_/1/selbcd_3>.

WARNING:Cpld:310 - Cannot apply TIMESPEC TS1000 = PERIOD:PERIOD_Mrom_bcddecode_1_bcddecode__cmp_eq0015$BUF2.CLKF:0.000 nS because of one of the following: (a) a　signal name was not found; (b) a signal was removed or　renamed due to optimization; (c) there is no path between the FROM node and TO node in the TIMESPEC.

結局他のfunctionもreg変数間接で戻り値を代入しても警告は出てXC95216-10-PQ160に収まる程度。これはもしかしたらあの盲腸みたいなゲート配列のことを指すのかな。

Verilog版が今度はCPLDにDensity優先の最適化をしない限り入りきらなくなった謎のほかにもうひとつ謎があった。

それはVHDL版のRTL viewerをみるとでてくる出力側方向にある入力はつながっているが出力がなにもつながっていない11個のゲートがあること。



ちょっと見づらいがRTL Viewを一枚に表示したもの。信号は左側から入って右側に出ていく。右側の下半分あたりに出力がつながっていないゲート配列（強調表示）がいくつかあることがわかる。

これはなんだろう。

Technology Schematicにはそうした盲腸的なゲートは現れないのでXSTのバグかRTL Viewerのバグなのかもしれない。

・１０月末の月替わりロジックに誤りがあったので修正。
・VerilogおよびVHDL版では少し少ないLE数で済むようにデザインを一部変更


久々にMAX+PLUS IIを使ってコンパイルし直そうとしたらライセンス期限が切れていた（´Д｀；）

ライセンス取り直そうとALTERA JapanのWebから申請しようとしたらDisk Serial ID固定の申請ページが現れた。おかしい３月に最初に取得したときはNetwork固定のはずだったのが。改めてaltera.comからライセンス申請ページに行ってみるとちゃんとNetwork固定だった、以前のライセンスファイル中にあるhostid値(Ethernet MACアドレス)を入れてポチっとやると即メールでライセンスファイルが届けられる。また何ヶ月かしたら切れるのか。

１０月の判定部分をなおしたところどちらもX9500XLではSpeed優先だとどのパッケージにもFitしなくなった。

X9500ではVerilog版はXC95288-10-HQ208にVHDL版はXC95216-10-PQ160にFitした。今度はVerilog版が少しがさばる結果となった。

確かに今度はRTL Viewerでみると少し様子が違う。

けれどもTechnology Schematicだとまったく同一に見える。

XilinxのXSTはHDLからの論理合成時に最初からfan outを低く抑えるようなネットリストを生成しているように見える。Alteraの場合はそのあたりはお構いなしで圧縮するだけ圧縮してあとはFit時にどうにかするという感じ。考え方がまるで似てない。

やはりこれだけ言語によって違うが出る理由が依然として謎。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

また新しい謎が...