|
|
|
|
コメント(177)
> $dumpfile("ファイル.vcd");
> $dumpvars(0, モジュール名);
> でOKですね？
これやっちまうと、変化した点を全部拾うので、
比較という目的にはそぐわないかもです。
クロック毎に、strobe point を決めた方がええのでは...
> Verilogと新のVerilog両方をTopから呼び出して
> その入出力を比較します。 ” これ良いですね。
ベンチが同じならですが、普通はそうも行きません。
しかも、比較のためベンチを書き換えるわけで、
間違えて同じ信号を比較したら違いは出ません。
この辺の管理は、毎回起動時にバージョン情報を
出力させて比較するなど、工夫が必要です。
一昔前なら、同じシミュレータでもバージョンで動作が
ちがうということもあったのでつらかったです。
最近はさすがにそういう注意は要らないかも。
> $dumpvars(0, モジュール名);
> でOKですね？
これやっちまうと、変化した点を全部拾うので、
比較という目的にはそぐわないかもです。
クロック毎に、strobe point を決めた方がええのでは...
> Verilogと新のVerilog両方をTopから呼び出して
> その入出力を比較します。 ” これ良いですね。
ベンチが同じならですが、普通はそうも行きません。
しかも、比較のためベンチを書き換えるわけで、
間違えて同じ信号を比較したら違いは出ません。
この辺の管理は、毎回起動時にバージョン情報を
出力させて比較するなど、工夫が必要です。
一昔前なら、同じシミュレータでもバージョンで動作が
ちがうということもあったのでつらかったです。
最近はさすがにそういう注意は要らないかも。
marseeさん、
すでに、のぼしぇもんさんが解説されていますので、以下は冗長な私見です。
VerilogHDLは、言語仕様での強力なデバッグ機能があります。デバッグの各段階において、うまく使い分けたらよいと思います。2年前にトラ技に書いたまとめの図が、以下にあります。
http://www.cqpub.co.jp/toragi/TRBN/contents/2006/tr0608/0608digi3.pdf
この中で抜けているのがアサーションですが、概念的には、既に、皆さん独自の形式で記述されています。たとえば、自分で書いたメモリをXilinxにコンバートすると遅くなるのは、色々なSanityCheckが入っているためです。これも一種のアサーションです。また、OpecoresでのPCIコアやEthernetのソースを見るとやはり色々チェックが入っていて、ちょっとおかしいとすぐメッセージが出てきます。micronのメモリモデルにしてもDebugをONにすると色々と言ってくれます。アサーションの一種でしょう。
これらは、Verilogソース中に独自の記法で書かれていますが、それを統一的にgenericに、仕様を満たしているかチェックしましょうよ、というのがアサーション言語を用いたアサーションになると思います。SVのアサーションは、言語仕様のなかに組み込まれています。私も勉強中ですが、実装以前に使い方の習得の段階で難しいと感じます。記述も相応に面倒ですのでFPGA畑で浸透するかは不明ですが、IPを作っている人は特に必要ではないかと思いました。
すでに、のぼしぇもんさんが解説されていますので、以下は冗長な私見です。
VerilogHDLは、言語仕様での強力なデバッグ機能があります。デバッグの各段階において、うまく使い分けたらよいと思います。2年前にトラ技に書いたまとめの図が、以下にあります。
http://www.cqpub.co.jp/toragi/TRBN/contents/2006/tr0608/0608digi3.pdf
この中で抜けているのがアサーションですが、概念的には、既に、皆さん独自の形式で記述されています。たとえば、自分で書いたメモリをXilinxにコンバートすると遅くなるのは、色々なSanityCheckが入っているためです。これも一種のアサーションです。また、OpecoresでのPCIコアやEthernetのソースを見るとやはり色々チェックが入っていて、ちょっとおかしいとすぐメッセージが出てきます。micronのメモリモデルにしてもDebugをONにすると色々と言ってくれます。アサーションの一種でしょう。
これらは、Verilogソース中に独自の記法で書かれていますが、それを統一的にgenericに、仕様を満たしているかチェックしましょうよ、というのがアサーション言語を用いたアサーションになると思います。SVのアサーションは、言語仕様のなかに組み込まれています。私も勉強中ですが、実装以前に使い方の習得の段階で難しいと感じます。記述も相応に面倒ですのでFPGA畑で浸透するかは不明ですが、IPを作っている人は特に必要ではないかと思いました。
いやな思い出がいろいろよみがえってきたので ^_^;
自分のためのメモっす。
> クロック毎に、strobe point を決めた方が
どうせ後々、テスタ用のパターン出せとか、
どうも妙だから、ゲートで動かしてみてとか言ってくるので、
最初から、入力パターンにはそれなりの hold を持たせ、
出力を観測する point も加減できるように
テストベンチを作ったものでした。
最近やんないなあ。。。
> 一昔前なら、同じシミュレータでもバージョンで動作が
互換性二の次の速度競争やってくれたおかげで、
確かに、桁違いに速くはなりましたが、
割り食ったのは現場ですわなあ。
しかも、最早、設計規模の増大の方が速いので、
有り難味を実感することもなくなってしまいました。
自分のためのメモっす。
> クロック毎に、strobe point を決めた方が
どうせ後々、テスタ用のパターン出せとか、
どうも妙だから、ゲートで動かしてみてとか言ってくるので、
最初から、入力パターンにはそれなりの hold を持たせ、
出力を観測する point も加減できるように
テストベンチを作ったものでした。
最近やんないなあ。。。
> 一昔前なら、同じシミュレータでもバージョンで動作が
互換性二の次の速度競争やってくれたおかげで、
確かに、桁違いに速くはなりましたが、
割り食ったのは現場ですわなあ。
しかも、最早、設計規模の増大の方が速いので、
有り難味を実感することもなくなってしまいました。
たっくさん。
アサーションという意味では、うちのDDR2 SDRAMコントローラではデータを2回入れるので、2回入ってなかったらエラーとか。入力用、出力用FIFOのオーバーフローとかですかね。アドレスを入力してないのに、ライト・データを入れたとか、そんな感じでしょうか？
入れて見たいと思います。まとまった時間が取れるときにやろうと思っています。
仕事ではPCI-Xモジュールには十分ではないんですが、そういうようなアサーションを入れてみました。
のぼしぇもんさん。
$strobeは全部のデルタを行って確定した値になったのを出力するんですね。今はまだその段階ではありませんが、これで出力して合っているかどうかを比べてみたいと思っています。
アサーションという意味では、うちのDDR2 SDRAMコントローラではデータを2回入れるので、2回入ってなかったらエラーとか。入力用、出力用FIFOのオーバーフローとかですかね。アドレスを入力してないのに、ライト・データを入れたとか、そんな感じでしょうか？
入れて見たいと思います。まとまった時間が取れるときにやろうと思っています。
仕事ではPCI-Xモジュールには十分ではないんですが、そういうようなアサーションを入れてみました。
のぼしぇもんさん。
$strobeは全部のデルタを行って確定した値になったのを出力するんですね。今はまだその段階ではありませんが、これで出力して合っているかどうかを比べてみたいと思っています。
marseeさん、
アサーションを書くとは、正解の波形を書くということ、突き詰めると、仕様を書くということになるので、仕様に反した使い方は、全てアサーションで撥ねられるべきなんでしょう。そう考えると、書くことが難しいことが想像されますが、それを目指しているのだと思います。逆にいやでも仕様を明確にしなければいけなくなることがミソだと思います。「論よりRUN」の対極にある考え方ですね。以上は、SV設計スタートアップに書いてあることの、私なりの理解です。
$strobeについては、その通りです。以下の6章の最後の図をご参考に。
http://japanese.sugawara-systems.com/tutorial/verilog/framepage7.htm
<RAMDISK 141続きです>
PCのメモリを8GBにして、簡単な、しかし、長大なベンチを実行してみました。RDRIVEには、4.7GBのRAMDISKができました。ベンチは、DISPDISKが3.2GB位、Archiveが1GB位で、計4.7GBを超えないように調整しました。
C:DRIVE 25分(仮想メモリ)
R:DRIVE 27分(RAMDISK)
で、SIM時間では全く効果がありませんでした。最後までいったところで、拡大、縮小を行うと若干レスポンスがよいような感じですが、期待した効果は得られませんでした。CPUはCeleron1.6G E1200という最低ランク品です。
結果については私も意外です。アクセス方式・キャッシュ絡みがうまく働いている可能性もありますが深く考察できておりません。もしかしたら64ビットOS下では違う結果になるのもしれません。これも機会を見てやってみたいと思います。
アサーションを書くとは、正解の波形を書くということ、突き詰めると、仕様を書くということになるので、仕様に反した使い方は、全てアサーションで撥ねられるべきなんでしょう。そう考えると、書くことが難しいことが想像されますが、それを目指しているのだと思います。逆にいやでも仕様を明確にしなければいけなくなることがミソだと思います。「論よりRUN」の対極にある考え方ですね。以上は、SV設計スタートアップに書いてあることの、私なりの理解です。
$strobeについては、その通りです。以下の6章の最後の図をご参考に。
http://japanese.sugawara-systems.com/tutorial/verilog/framepage7.htm
<RAMDISK 141続きです>
PCのメモリを8GBにして、簡単な、しかし、長大なベンチを実行してみました。RDRIVEには、4.7GBのRAMDISKができました。ベンチは、DISPDISKが3.2GB位、Archiveが1GB位で、計4.7GBを超えないように調整しました。
C:DRIVE 25分(仮想メモリ)
R:DRIVE 27分(RAMDISK)
で、SIM時間では全く効果がありませんでした。最後までいったところで、拡大、縮小を行うと若干レスポンスがよいような感じですが、期待した効果は得られませんでした。CPUはCeleron1.6G E1200という最低ランク品です。
結果については私も意外です。アクセス方式・キャッシュ絡みがうまく働いている可能性もありますが深く考察できておりません。もしかしたら64ビットOS下では違う結果になるのもしれません。これも機会を見てやってみたいと思います。
marsee さん
> $strobeは全部のデルタを行って確定した値になったのを出力
なので、即席の期待値出力とかにはええんですけど、
遅延入りのシミュレーションとなると今一意味が無いという具合。
> データを2回入れるので、2回入ってなかったらエラーとか。
> 入力用、出力用FIFOのオーバーフローとかですかね。
> アドレスを入力してないのに、ライト・データを入れたとか
たっくさんが紹介しておられる教科書に詳しいと思いますが、
"A がアサートされたら、いつかは必ず B がアサートされる" とか、
あんまり HW では意識しないような記述がいろいろできて、
下手するとシミュレーションへの負荷も大きいし、
アサーション自体の保守もつらいということで、
やっと ? 仕様、実装、検証は分業する時代になった
ということなのでしょうか。
OVM なんか全員に勉強させようたってねえ。。。
> $strobeは全部のデルタを行って確定した値になったのを出力
なので、即席の期待値出力とかにはええんですけど、
遅延入りのシミュレーションとなると今一意味が無いという具合。
> データを2回入れるので、2回入ってなかったらエラーとか。
> 入力用、出力用FIFOのオーバーフローとかですかね。
> アドレスを入力してないのに、ライト・データを入れたとか
たっくさんが紹介しておられる教科書に詳しいと思いますが、
"A がアサートされたら、いつかは必ず B がアサートされる" とか、
あんまり HW では意識しないような記述がいろいろできて、
下手するとシミュレーションへの負荷も大きいし、
アサーション自体の保守もつらいということで、
やっと ? 仕様、実装、検証は分業する時代になった
ということなのでしょうか。
OVM なんか全員に勉強させようたってねえ。。。
原因について考えてみました。
基本的には、SIM中は、SEQ.アクセスなので、
A.HDDに対するSimatorのデータ生成レート
B.HDDのSEQアクセス速度(シークを含めたTotalとしての)
としたとき、
A<B
の関係だと、HDDの速度には依存せず、Simulatorのデータ生成レートで律速することになります。デザイン規模が大きくなるにつれAは小さくなっていきますが、実験に使った超軽のソースでさえ、上記の結果でしたので、大概の場合は、同様の結果になるものと思われます。一方、大きいWaveformの任意の波形部を拡大縮小するのは、Readランダムアクセスになりますから、RAMDISKの方が有利になります。
という解釈が妥当なような気がします。そのほかに、Veritakの場合、圧縮が入ってしまいCPU負荷がより高くなることも要因としてあるかもしれません。
基本的には、SIM中は、SEQ.アクセスなので、
A.HDDに対するSimatorのデータ生成レート
B.HDDのSEQアクセス速度(シークを含めたTotalとしての)
としたとき、
A<B
の関係だと、HDDの速度には依存せず、Simulatorのデータ生成レートで律速することになります。デザイン規模が大きくなるにつれAは小さくなっていきますが、実験に使った超軽のソースでさえ、上記の結果でしたので、大概の場合は、同様の結果になるものと思われます。一方、大きいWaveformの任意の波形部を拡大縮小するのは、Readランダムアクセスになりますから、RAMDISKの方が有利になります。
という解釈が妥当なような気がします。そのほかに、Veritakの場合、圧縮が入ってしまいCPU負荷がより高くなることも要因としてあるかもしれません。
marseeさん、
ブログを拝見しました。もと＠琵琶湖さんの方法が役にたったのですね。
もともとハードウェアは、オブジェクトそのものなので、単純にinstantiateできれば、それが、一番簡単なオブジェクト指向の実践になる例だと思います。
たとえば、UARTの受信をテストするのに、既にUARTの送信ポートのHARDがあったとしたら、テストベンチ上でinstantiateとconnectを行えば、簡単にベンチが出来てしまいます。新たに、送信ポートのモデリングベンチを書く必要はないですね。
SVの方は、壁にぶち当たっては、それを突破するのに何週間か費やしている状態を繰り返していて遅々して進んでいません。（SVは、CがC++になったようなもので全く別物のコンパイラです。）努力を惜しんではいませんが、期待には答えられないかもしれません。ごめんなさい。
ブログを拝見しました。もと＠琵琶湖さんの方法が役にたったのですね。
もともとハードウェアは、オブジェクトそのものなので、単純にinstantiateできれば、それが、一番簡単なオブジェクト指向の実践になる例だと思います。
たとえば、UARTの受信をテストするのに、既にUARTの送信ポートのHARDがあったとしたら、テストベンチ上でinstantiateとconnectを行えば、簡単にベンチが出来てしまいます。新たに、送信ポートのモデリングベンチを書く必要はないですね。
SVの方は、壁にぶち当たっては、それを突破するのに何週間か費やしている状態を繰り返していて遅々して進んでいません。（SVは、CがC++になったようなもので全く別物のコンパイラです。）努力を惜しんではいませんが、期待には答えられないかもしれません。ごめんなさい。
GUIとCompiler/Sim Engineは別プロセス(別EXE)です。
ですので、
１）$display->GUI コンソール (veritakwin.exe)
２）SIM進行 (veritak2.exe)
は、並列に行われます。大量にメッセージを出力するSIM(Opencores のPCIや、Ethernet のようなSIM)では、DUALの恩恵が少しだけあると思いますが、SIM自体のマルチスレッドについては対応していないので、現状のVeritakで3/4コアがよいということはありません。
SIM自体のマルチスレッド化については、学術的にも難しい問題です。アルゴリズムの構想はあるのですが、現在は、SVパーサの問題で手こずっておりfeasibility studyは、この問題の収束後に予定しています。CPUをQ9450(4コア12MBキャッシュ)に載せかえて実験します。(nehalemコアと大分雰囲気が違うと思いますがとりあえず..)
ですので、
１）$display->GUI コンソール (veritakwin.exe)
２）SIM進行 (veritak2.exe)
は、並列に行われます。大量にメッセージを出力するSIM(Opencores のPCIや、Ethernet のようなSIM)では、DUALの恩恵が少しだけあると思いますが、SIM自体のマルチスレッドについては対応していないので、現状のVeritakで3/4コアがよいということはありません。
SIM自体のマルチスレッド化については、学術的にも難しい問題です。アルゴリズムの構想はあるのですが、現在は、SVパーサの問題で手こずっておりfeasibility studyは、この問題の収束後に予定しています。CPUをQ9450(4コア12MBキャッシュ)に載せかえて実験します。(nehalemコアと大分雰囲気が違うと思いますがとりあえず..)
たっくさん、ありがとうございます。
>GUIとCompiler/Sim Engineは別プロセス(別EXE)です。
>ですので、
>１）$display->GUI コンソール (veritakwin.exe)
>２）SIM進行 (veritak2.exe)
>は、並列に行われます。
これだけでもDUAL買った甲斐がありました。
以前は、メッセージを出すと、シミュレーションが終わってからもずーとメッセージを出し続けていました。今ではシミュレーションと同時にすっぱり終わります。
SIM自体のマルチスレド化も予定していらっしゃるようですね。
私の関係している研究室でも、以前PCクラスタによるシミュレーションを研究してたようですが、今はやっていないようです。
理由は知らないのですが、マルチコアCPUでしたら、2nd キャッシュでプロセッサ同士の同期が取れるでしょうから、マルチスレッドでも性能の予定値と実測値の差が少なそうですね。
>GUIとCompiler/Sim Engineは別プロセス(別EXE)です。
>ですので、
>１）$display->GUI コンソール (veritakwin.exe)
>２）SIM進行 (veritak2.exe)
>は、並列に行われます。
これだけでもDUAL買った甲斐がありました。
以前は、メッセージを出すと、シミュレーションが終わってからもずーとメッセージを出し続けていました。今ではシミュレーションと同時にすっぱり終わります。
SIM自体のマルチスレド化も予定していらっしゃるようですね。
私の関係している研究室でも、以前PCクラスタによるシミュレーションを研究してたようですが、今はやっていないようです。
理由は知らないのですが、マルチコアCPUでしたら、2nd キャッシュでプロセッサ同士の同期が取れるでしょうから、マルチスレッドでも性能の予定値と実測値の差が少なそうですね。
＜FPGAの入門テキスト＞
KEKの内田さんが、書いてくださったようです。そのまま学校のテキストに使えるくらい懇切丁寧に書いています。
http://www-online.kek.jp/Seminar/KEKDTP_FPGA_Seminar_2008_Course1_Rev11.pdf
同筆者でHardwareBasedのTCP/IPプロセッサの紹介です。
http://www-online.kek.jp/Seminar/KEKDTP_FPGA_Seminar_2008_Course5.pdf
巻末にあるようにIEEEの論文も拝見できました。少ないLUT数でもワイヤレートで処理できるんですね。素晴らしいです。
KEKの内田さんが、書いてくださったようです。そのまま学校のテキストに使えるくらい懇切丁寧に書いています。
http://www-online.kek.jp/Seminar/KEKDTP_FPGA_Seminar_2008_Course1_Rev11.pdf
同筆者でHardwareBasedのTCP/IPプロセッサの紹介です。
http://www-online.kek.jp/Seminar/KEKDTP_FPGA_Seminar_2008_Course5.pdf
巻末にあるようにIEEEの論文も拝見できました。少ないLUT数でもワイヤレートで処理できるんですね。素晴らしいです。
- mixiユーザー
- ログインしてコメントしよう！
|
|
|
|
Veritak友の会 更新情報
-
最新のイベント
-
まだ何もありません
-
-
最新のアンケート
-
まだ何もありません
-
