2008/08/22(金)[ISE] Verilog Simulation(ISim)
概要とか問題とか
今回，試行錯誤して遊んだメモなので，ワークフローではありません．いじくっているうちに慣れたり覚えたりしますよねぇ？．基礎知識が不足しているからこうして下積みを・・・(^^;
Post Route Simulationにて，配置配線で問題が生じたかを確認する．
Timing Constraintsの設定はClockしかしていない．設定不足か？
また，behavior simulationで得られた期待どおりの波形が見えない（出力信号）．
ざっとまわして，いくつか出てきた．どれもこれもsetup time/hold time違反の模様．コレを見て，配置配線前にエラーが出ていなかったので，おかしいなぁと思いつつ，Warningのとり方を調べていた．
WARNING:Simulator:29 - at 6.000350773 ms: Warning: Timing violation in /TST_BSC/uut/\TPU_1/TADD_buf_14 / $setuphold<setup>( I:6.000350768 ms, CLK:6.000350773 ms,132.000 ps,48.000 ps) WARNING:Simulator:29 - at 6.000350773 ms: Warning: Timing violation in /TST_BSC/uut/\TPU_1/TADD_buf_15 / $setuphold<setup>( I:6.000350736 ms, CLK:6.000350773 ms,132.000 ps,48.000 ps) WARNING:Simulator:29 - at 6.000380773 ms: Warning: Timing violation in /TST_BSC/uut/\RAM1K_1/RAMB16_S18_inst / $setuphold<setup>( ADDR:6.000380571 ms, CLK:6.000380773 ms,377.000 ps,131.000 ps) WARNING:Simulator:29 - at 6.000380839 ms: Warning: Timing violation in /TST_BSC/uut/\RAM1K_1/RAMB16_S18_inst / $setuphold<hold>( CLK:6.000380773 ms, ADDR:6.000380839 ms,377.000 ps,131.000 ps)
半日以上うろうろしていたけれども，最終的には問題ないという見解に落ち着く．おそらくskewにより，使用しない信号を拾うタイミングで発生していると思われる．ポートから受けたデータをDFFでラッチし，その次のサイクルで内部の所望のレジスタへと転送するように実装してある．ところが，今回の箇所は，ポートからラッチするタイミングでviolation警告が出る．DFFにラッチするタイミングがわずかに早くなり，その後段にあるDFFへと信号が先行してしまって，posedge CLKが入ったのではないだろうか．
裏づけを取るにはシミュレーション時に該当信号をモニタする必要があるわけだが，その手段についてもわからなかった（現在進行形）．
とりあえず，検証モジュール(タスク)で，インスタンス名をドットでつないで内部信号をassignして観測しようとしています．が，なんだか調子悪いような・・・．DCMを使っているせいもあり，5mSec強の待ち時間を作りこんでしまった．当該回路を取り去ると挙動が変わる恐れもあり，実行していない．*1
Warningの意味
合成/シミュレーションデザイン ガイド
WARNING:Simulator:29 - at 6.000350773 ms: Warning: Timing violation in /TST_BSC/uut/\TPU_1/TADD_buf_15 / $setuphold<setup>( I:6.000350736 ms, CLK:6.000350773 ms,132.000 ps,48.000 ps)
clock skewによるwarningと判断する．SHからのWRアサート→ネゲートを検出して，データをラッチして，次のCLKでTPU moduleに書き込み要求を出す．(module向けのWRはネゲートされたまま．DFFの貫通が起きればその限りではない？が，次のCLKで書きにいくのでおｋ．bufferにしてあるから1clk間化けても大丈夫)
少し解決
シミュレーションに時間を要していた件，DCM出力が出てこないのは時間のせいと思い込んでいましたが，リセットがかかっていなかった模様．
リセット信号がnegedgeなのにt=0から0で100nSecおいて1にしてました．そりゃ非同期リセットかからない罠('A`．
次に，timing violation．下位モジュールで別クロックを作ってしまっていました．同じクロックと期待して表示させたのに0.7nSecもずれている．10nSec周期なので，7%誤差ですね．コレを削ればviolationも消えるかもしれませんし，そもそも非同期になっていては設計想定が崩れます．
DCMにするか，クロックバッファを通してやるのが無難でしょうかねぇ．DCMもったいないかな・・・？分周して同窓にあわせようとすれば，これしかないか．出力にDFFかましても位相ずれるには変わりないしねぇ．
ISE 10.1のmanual類
日本語版は，ここらへんに落ちてます．
2008/08/13(水)[ISE] Behavioral Simulation
Verilog Test Fixture新規作成
Sourcesウィンドウにて, 右クリック → 新規ファイル → Verilog Test Fixtureと選択すれば, テスト対象モジュールを指定することができます.
インスタンス名をuutとして, 自動的にテンプレートを作ってくれるので手を抜くには便利です.
とはいえ, テキストエディタで先にパターン作っていたので, 殆ど流用できずに終わりましたが...
記述
テストを行うmodule宣言では, 引数の宣言は不要です.
ex. module TST_BSC;
モジュールの入力に対しては regで変数を作成, 出力に対してはwireで変数を作成. bidirectionalについては, reg/wireを作ってassign文でtri-stateを作っておきます(これでいいんだよなぁ?)
wire [15:0] D; reg SH_OE ; reg [15:0] SH_DATA_OUT ; // OUT means from test-module to FPGA assign D = (SH_OE ? SH_DATA_OUT : 16'hZZZZ);
SH2-7144の外部バスタイミング
データシート(Rev.4.0 2008年3月27日, rjj09b0026_sh7144.pdf)を参照し,
26.3.4 バスタイミングのあたりを注視します.
ちなみに, どこぞのIF誌で外部SRAMのタイミング検討はアクセスサイクルが十分だからOKといった記述がありましたが,個人的には納得できません.
RD/WR信号とデータ・アドレスのアサートタイミング、セットアップ・ホールドタイムについての検討が説明されていないからです.
動作クロックφ(CK)との関連が示されていますが, このクロックに同期させればOKというわけではなさそうです.
最大遅延25nSecとか28nSecとか, すでに1クロック過ぎているじゃありませんが... どう考えても1waitは必須です.
詳細は割愛しますが, とりあえず 1wait必須, 場合によっては連続アクセスウェイトも入れてやる必要がありそうです.
CSアサートの遅延機能は使用せずにすみそうですね.
さて, コレを元にWRITE時の試験データを作りましょう.イロイロと考えてパターンをふるべきですが, とりあえずイチバンきつそうなWRアサート期間の短いものを作ってみましょう.
条件
- BUS wait cycle = 1
- CSアサート期間拡張機能無効
このとき, テストはこんな感じになるハズ.. と, datasheetと睨めっこしていると 少し疑問が.悪いほう悪いほうに考えて居れば良いだろうナ.
# 0 // CK upedgeとみなす. SH_OE <= 0; # 25 SH_ADR <= 22'h000088; // "t_AD" ADR fixed Max.25nSec from 1st CK-up SH_DATA <= 16'h0008; // こっちはついで. # 3 //+28 // "t_CSD1" CS assert Max. 28nSec from 1st CK-up SH_nCS <= 0; # 7 //+35 // (SH_CLK/2) + Max.25 // "t_WSD" WR assert Max. from 1st CK-down + 25nSec SH_nWRH <= 0; SH_nWRL <= 0; # 5 //+40 // (SH_CLK/2) + Max.30 // "t_WDD" Data drive Max. from 1st CK-down + 30nSec SH_OE <= 1; # 10 //+50,75 // WR disassert "t_WSD2"<25 => (1.5+1)*20 +0/+25 = 50-75 from 1st CLK-up T2終了までにdisassertされるのが普通? 75だと+15.. SH_nWRH <= 1; SH_nWRL <= 1; # 5 //+55,80(Tidle挿入せよ) // "t_WR" >5 CS disassert (FPGAでサンプリングできない?ケース) SH_nCS <= 1; # 5 //+60, 3cycle終了 SH_OE <= 0; // T2終了時+0以上でdisassert
XSTのシミュレーションで確認すると, 下記のような結果を得ることができました.波形を出すまでに module群の修正を行っていたので, 結構な時間を要しました...
途中で別の記事(書評/AA作成/LIVE FORMULA鑑賞)なんぞを平行していたせいもありますが.
配置配線後のまっとうな(?)シミュレーションではないので, あくまでも記述上問題がないという確認だったはず.
配置配線後のシミュレーションをやっておかないと, SetUp/Hold timeの不足がある場合は不定にしてくれたはず...ろくすっぽmanualも見ずにかなり昔の記憶で触っているのが酷いかな. XC9500シリーズで遊んでいた頃まで遡るわけで.
時間も時間なので, ひとまずここまで. 本当に手ぶらで行くことになりそうだなぁ. それは非常に負けた感がするな.
おちまくるXST-Sim
process explorerでisimwavedata.xwvを探してみます. _pn.exeが掴んだままのようですね.
おｋ. 把握. 通常のタスクマネージャでも_pnを殺せばメモリも開放される模様です. 同じようにはまった方はコレで解決..
2008/08/12(火)[ISE] 久しぶりのHDL, WebPackISE, 初めてのFPGA
WebPackISE v10.1sp2上で, Verilog記述を行い, おもちゃを作ろうとしている.久しぶりにHDLに触れたのと, CPLDとは規模が違いすぎるので, 真面目に検証しておこうと思う.途中ツールの使い方や設計自体に問題がありそうなので, メモを記しておくことにする.
識者の方にツッコミを入れてもらえると非常にありがたい...
また, 検索したりアンサーを探したり, 本を見たりと参照先がややこしくなっているので,可能な限りリンクを貼って残したいと思います. リンク先が消える可能性もあるから,せめてローカルには保存しておきたいと思うけれども, blog形式だと管理が面倒ですよねぇ...とりあえず, FPGAの部屋のまとめサイトは外せなさそうです.ほかにもあるけれど, 今開いているページだけ貼っておきました.
タイミング制約(timing constraints)について
Synthesize - XST
ISEWebPackにて, Synthesisを行ってレポートを見る.なんだかタイミング間に合ってないような書き方されているが, Synthesisだけで判断しないほうがいいのかな.だんだんとイヤになってきたしｗ.
summaryは以下のとおり. 結果としてClockは127MHzまでokよと言われていると考えていいのだろうか.
Timing Summary: --------------- Speed Grade: -4 Minimum period: 7.824ns (Maximum Frequency: 127.815MHz) Minimum input arrival time before clock: 9.067ns Maximum output required time after clock: 11.857ns Maximum combinational path delay: 14.951ns
Detailを少し引用してみるが, この遅延が支配して, 上限が確定してしまっているように見受けられる. DCMで２逞倍にしたクロックで内部ロジックをまわしているのだけれども, 100MHz想定だからOK??配置配線完了すると, route timeとか logic timeに変動があるかもしれないけれど. setup time/hold timeを加味した上での値, と見ていいのかしらねぇ？
Timing constraint: Default period analysis for Clock 'CLKOUT_DCM1/CLKFX_BUF' Clock period: 7.824ns (frequency: 127.815MHz) Total number of paths / destination ports: 10190 / 330 .... (4.609ns logic, 3.215ns route)
まぁ, こう書いてあることだし, とりあえず保留...
TIMING REPORT
NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE.
FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT
GENERATED AFTER PLACE-and-ROUTE.
Implement Design / Translate
Checking Constraint Associations... WARNING:NgdBuild:1011 - The constraint <TIMESPEC TS_CLKOUT_DCM1_CLKFX_BUF_5 = PERIOD "CLKOUT_DCM1_CLKFX...> is overridden by the constraint <TIMESPEC TS_CLKOUT_DCM1_CLKFX_BUF_5 = PERIOD "CLKOUT_DCM1_CLKFX...>. WARNING:NgdBuild:1011 - The constraint <TIMESPEC TS_CLKOUT_DCM1_CLKFX_BUF_5 = PERIOD "CLKOUT_DCM1_CLKFX...> is overridden by the constraint <TIMESPEC TS_CLKOUT_DCM1_CLKFX_BUF_5 = PERIOD "CLKOUT_DCM1_CLKFX...>. WARNING:NgdBuild:1011 - The constraint <TIMESPEC TS_CLKOUT_DCM1_CLKFX_BUF_6 = PERIOD "CLKOUT_DCM1_CLKFX...> is overridden by the constraint <TIMESPEC TS_CLKOUT_DCM1_CLKFX_BUF_6 = PERIOD "CLKOUT_DCM1_CLKFX...>. WARNING:NgdBuild:1011 - The constraint <TIMESPEC TS_CLKOUT_DCM1_CLKFX_BUF_6 = PERIOD "CLKOUT_DCM1_CLKFX...> is overridden by the constraint <TIMESPEC TS_CLKOUT_DCM1_CLKFX_BUF_6 = PERIOD "CLKOUT_DCM1_CLKFX...>.
検索した. 1011は場所かな? と判断して, メッセージ部分をAND指定すればOK. *1
アンサーに登録されている, 10.1 NGDBUILD - 制約の優先順位での問題というのが該当しそうだ. 抽出した部分, 長すぎてはしょられてしまっているので, 制約が読み取れないけれど...
しかし, ucfでは該当しそうな制約条件を記述していない. CLKFXは DCMの出力クロックだと思われる. FPGAの部屋では, DCM入力クロックの制約事項を記述しておけば, 出力クロックの制約を自動生成するようだ, と書かれていた.
少し気がかりだが, 致命的ではなさそうなのでおいておこう...
Place and Route Report
ここが気になる英文. 英語赤点できたのと, 仕事でも添削してもらわないと送れないレベルの儂惨状*2
WARNING:Route:455 - CLK Net:CLKFX_OUT may have excessive skew because
0 CLK pins and 2 NON_CLK pins failed to route using a CLK template.
=> ～は, 極端なスキューを持つ. NON_CLK pin２つがCLK temlateを使った配線で失敗している(?)
なんか調子悪そうにみえる... のだけれど.
大きすぎて引用をためらったが, ヘンにはしょるのもよろしくなさそうなので貼り付け.
Derived Constraint Report Derived Constraints for TS_clk_in +-------------------------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------+ | | Period | Actual Period | Timing Errors | Paths Analyzed | | Constraint | Requirement |-------------+-------------|-------------+-------------|-------------+-------------| | | | Direct | Derivative | Direct | Derivative | Direct | Derivative | +-------------------------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------+ |TS_clk_in | 20.000ns| 4.972ns| 19.983ns| 0| 0| 336| 10214| | TS_CLKOUT_DCM1_CLKFX_BUF | 6.667ns| N/A| N/A| 0| 0| 0| 0| | TS_CLKOUT_DCM1_CLKFX_BUF_0 | 6.667ns| N/A| N/A| 0| 0| 0| 0| | TS_CLKOUT_DCM1_CLKFX_BUF_1 | 6.667ns| N/A| N/A| 0| 0| 0| 0| | TS_CLKOUT_DCM1_CLKFX_BUF_2 | 6.667ns| 6.661ns| N/A| 0| 0| 10214| 0| | TS_CLKOUT_DCM1_CLKFX_BUF_3 | 6.667ns| N/A| N/A| 0| 0| 0| 0| | TS_CLKOUT_DCM1_CLKFX_BUF_4 | 5.000ns| N/A| N/A| 0| 0| 0| 0| | TS_CLKOUT_DCM1_CLKFX_BUF_5 | 10.000ns| N/A| N/A| 0| 0| 0| 0| | TS_CLKOUT_DCM1_CLKFX_BUF_6 | 10.000ns| N/A| N/A| 0| 0| 0| 0| | TS_CLKOUT_DCM1_CLKFX_BUF_7 | 10.000ns| N/A| N/A| 0| 0| 0| 0| +-------------------------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------+
おそらく自動生成された制約だろう. DCM入力50MHz(20nSec)に対して, x2の100MHz(10nSec)という制約が...
おかしいやん.. 6.6nSecとか5nSecて, ３倍４倍じゃね？しかも負荷ぶら下がってるし.見方が悪いのかナァ. それにしてもErrorの項はゼロだしなぁ...
動くものと信じて検証しておきますか. シミュレータでの確認がまだだったりします...
DCMのリセット
なひたふ先生のblogにて、Spartan3E DCMからクロックが出てこないというエントリがありました. DCMの使用例を探していてヒットしたのです.
ここにあるように, 入力クロックが心配であれば, DCMの出力が安定してなければ再度リセットを行うような回路を入れるべきという提案に賛同します.コメント欄で いくら先生も引っかかったようですので, 先人の経験をありがたく授受しようかと思います.
で, この回路は比較的簡単に実装できたので, module testの練習(思い出し)を兼ねて実施. XSTを使い, パターンをふって, 17mSec程度まわしたら アプリケーションが落ちた...しかもメモリをガメたまま. ファイルもロックしたまま. ＼(^o^)／
ModelSimだと遅いから, とりあえずの動作確認としてXSTを使ったのが敗因か?本気でHDLで遊ぶなら, Veritakの購入も考えたほうがいいのかしら...下手なゲームソフトを買うより安いものネェ. その上実用的だし：）
本日の結論
reportの見方が判らないが, エラーとして明示されていないので, とりあえず疑問点を挙げて記録したから満足.検証を済ませてマイコンとの配線を済ませるつもりだったが全く進捗が無い. これはかなり厄介だ...
N:TMに途中成果を持っていけない臭いがぷんぷんするぜ...
2008/03/29(土)久しぶりにHDL
ALTERA
EPM7032VLC44, EPM7128ELC88を拾ってきたのだが、開発ツールが対応していない模様... orz Xilinxに戻るか...
Xilinx
WebPack ISEを使う. 不慣れだがやるしかない.
parameter文
`defineと違って、パラメタ化のために用いる。ただしmoduleの内側でないとだめぽい。一度ハマった... orz詳しいことは後日調べるとしよう。
補足：`defineだと、変数名の頭にアクサンが必要となる模様。ただしglobalな扱い。parameterはmodule内での宣言が必要 == includeで共通外部ファイルを拾ってくるとかしないと、ファイルをまたがって共通化できない。みたい。
例題
とりあえず作ったのはシリパラ変換。しょぼいｗ
module top(SCLK, SDI, SDO, SLAT, RST_N, PD); parameter DF_BIT_MSB = 28; input SCLK; input SDI; output SDO; reg SDO ; input SLAT; input RST_N; output [DF_BIT_MSB:0] PD; reg [DF_BIT_MSB:0] PD; reg [DF_BIT_MSB:0] DFF; always @ (posedge SCLK or negedge RST_N) begin if (RST_N == 1'b0) begin DFF <= 0; SDO <= 0; end else begin DFF <= DFF[DF_BIT_MSB-1:0],SDI; SDO <= DFF[DF_BIT_MSB] ; end end always @ (posedge SLAT or negedge RST_N) begin if (RST_N == 1'b0) begin PD <= 0; end else begin PD <= DFF; end end endmodule
さらにadiaryネタ. pre記法は使いづらい. というか, エスケープの仕方や変換のされ方の理解が浅い. >|～|<を使うと、綺麗にpreタグをつかってくれる。>～<だと、変換プロセスが走るようだ。説明とレイが乗っていた気がするが、理解できてなかったようだな。実際に"こう使いたい"と、手を動かし、体で覚えていくしかないわ。何でもかんでもそうだな・・・。