今度は、乗算器を設計してみましょう。RTLシミュレーション単に、入力A,BをFFで受けて、掛け算するだけのソースです。end`endifendmoduleテストベンチソースランダムな6ビット幅A,Bを発生させて入力としています。後で、論理合成したH/WとRTLの結果を比較するためにコンペアする記述も加えています。$dumpvars(1,mul_vcd_test);`endifendendmoduleRTLシミュレーション結果です。結果を得るまでに二つのFFを通過するので2CLOCK遅れで結果が出力されています。Quartusによる論理合成mul.vを論理合成して、下図の遅延情報を得ました。Quartusは解析し報告しています。Setup(8.648ns)よりも小さいので、テストベンチ上もClockSetupで駆動できる(コンペアエラーは発生しない)筈です。Cycleを下記のように変更してコンペアエラーがで発生しないことを確認してみましょう。(8.648/2)ところで、出力最大遅延7.536nsが発生している箇所は、比較的簡単に見つけることができました。Edgeから最後の変化がQuartasの報告通り、C[5]であること確認できました。コンペアエラーが発生しないことが確認できました。ところで、ゲートシミュレーション上、個々の時刻ではどれだけの余裕で動いているものでしょうか?この様子を見るために、SDOファイルのSETUPをエディタで変更してみると様子がわかります。エディタで(37:37:37)=>(100:100:100)一括置換して、再度走らせてみます。SPEC.を100psに変更したので、SETUPエラーが発生しています。Veritakでは、SETUPエラーが発生してもxにせず、シミュレーション結果になんの影響も与えない仕様になっています。Spec.100psMin.のところ、44psしかないと報告しています。それでも、37psよりは大きいので、DefaultのSpec.ではエラーにならなかった訳です。F:\altera\mul\mul_test.v(5)::mul_vcd_testVerilogのシミュレーションの準備が完了しました。スタートは,Goボタンを押してください。シミュレーションを開始します。$finishコマンドを実行します。シミュレーションを終了します。Errorが発生していますが、信号自体は、c256[10],C256[9]が多いです。このパスがクリティカルパスなのでしょう。確かにQuartusのClockSetupのレポートをみると、8.648nsのクリティカルパスに含まれています。Veritakのシミュレーションでは、最小値で44psになっており、本当の最小値の37psは発生していません。パターン数が少ないという指摘は当たっていますが、仮に全パターン遷移を行ったとしてもこのような結果は普通に起こりえます。深い論理においてQuartasの静的なTiming解析と動的なパス遅延(慣性遅延も含む)とで、最大値が一致するということはむしろまれです。動的なパス遅延が静的遅延を超えることはありません。従い、Quartasの報告する駆動周波数で、ゲートシミュレーションが動かないということは(設計上のエラーがない限り)ありません。Setup、Holdエラーの発生の原因の多くは、テストベンチとのIFにあります。このエラーが発生したときは、まず、テストベンチのIFを疑いましょう。**シミュレーション開始時の最初のクロックエッジでの報告は、シミュレータの過渡状態によるものですので、無視して構いません。