最近、移動中とかに読んでいるのがこの本。
VHDLによるマイクロプロセッサ設計入門 。
こじんまりしたＶＨＤＬはなんとなく書けるように
なった気がするので、もっと大きなもの作るとか
テストするとか、その辺の知識が欲しいなと思って
見つけた本。
ＶＨＤＬを全く知らない状態で読んだらチンプン
カンプンだったろうけど、一応キホンのキの縦棒
程度は解ったつもりなので、読んでて困ることは
とくに無し。
この本は、ＶＨＤＬでマイクロプロセッサを
フルスクラッチで書いていくっていうゴールを
目指しているので、おおよそ今知りたいことが
纏まって書かれているっぽいので、ＶＨＤＬの
文法書の次に読む本としては良い選択では
ないかと…
まぁ、完成品はCOMETなんだけど、COMET自体は
情報処理試験用の仮想マシンなので、実用云々
というもんじゃないんだけど、COMET程度の
モノが作り上げられるようになれば
イロイロ応用は出来そう。
あとは読む時間と、理解する脳細胞があれば
問題は無いんだけどな…
それにしても、ＶＨＤＬ関係の本を読んでいて
いつも思うこと。
テストベンチ書くっていうのはなんとなく今まで
オイラがお勉強してきた文化とはやっぱり異質な
感じがするんだよな…
なんなんだろう？
|
おすすめブログ
@goo_blog
製品だと、テストベンチのコードは、製品コードの10～100倍書きますよ。
なにしろ、一コケ1億円の世界ですから。
動作検証だけで、タイミング検証は別ベンチ
どうやら私の意図と違う内容で伝わっているっぽいので補足して置きたいと思います。
私がテストベンチになんとなく違和感を感じているのは、ＶＨＤＬ自体に手を加えてテストベンチを作るというその「造り」というか「方法」というか、その部分についてです。
成果物に1文字でも変更を加えたら、その修正物に対してどんなテストを行っても、元の成果物の品質を保証することは一切できないという文化で育ったので、成果物（スクリプト）自体に手を加えて作るテストベンチというモノがなんとなく恐ろしく感じるからです。
ソースに手を加える云々だけでなく、リコンパイルや再リンク、ＯＳの入れ替え、ライブラリのアップデートなども同様です。
実行されるバイナリイメージが1ビットでも変化すれば、それぞれ然るべきテストが必要になると思っています。
変更内容に対し微に入り細を穿ちテスト項目を挙げて確認をしていく必要があります。一般には「バージョン管理」と言われるテーマだと思います。
これは、一般にソフトウェアの言語仕様やＯＳの仕様、ミドルウェアやライブラリといった仕様がＩＳＯなどで厳密に規定されていないことによるのかもしれません。
一方ハードウェア記述言語ではテストベンチを記述してテスト確認をするということが前提になっているようなので、最初からそれを使ってきた文化の人たちには違和感は無いのかも知れませんし、それ以前にそこを担保する方法が存在しているのかも知れませんし、もしくはテストベンチという形でしか詳細なテストは行えない特性をもっているのかも…（寡聞のためその辺りが良く解ってません）
この辺が私が経験してきた文化と大きく異なるのでそこになんとなく違和感を感じた次第です。
あ、ちなみにマイコン関係のサイトでよく使われている様な「シリアルＩ／Ｏを流用したデバッグ」的な方法…言うまでも無く私の環境ではご法度でした。全くテストの意味を成さないので。
ソフトウェアがお気楽という根拠はよく良く判りませんが、私が体感してきたような「社会インフラ」に近い業務分野で開発を行ってきた人間にとってはお気楽さは微塵も感じませんし、いざトラぶれば1億程度では全然間に合いませんし…（ニュースや新聞をにぎわす大事件になります）
僕はゲーム業界のようなゆるい動けばいい的なソフト開発しか知らなかったこと
を晒してしまったようです。
業務によっては、確実性のレベルが違って当然で、厳密な世界には、厳密な対応の方法があって当然ですね。すみませんでした。
テストベンチについていくつか。
まず基本的すべての回路を同期設計します。
これで、スキューさえ追い込めれば、論理的に動作することが確認できれば、
どの状態でも、クロック単位には同じ動作をすることが保障されます。
このときに動作を検証する、仮の外部回路(ターゲットブロックに対するテスト用のmain()に相当するようなモノ)をシミュレーションテストベンチと言います。
この状態で論理回路を確定することをRTLフィックスと言います。
次にこのRTLを実際の実際のNANDなどの基本ゲートに置き換えます、これを合成とかMAPとか呼びます。
このときの遅延は、仮配線と呼ばれる、ほぼ一定配線遅延(容量)を追加して、スキューが追い込めるか、すべてのパスで確認します。同期回路なら、理論的に可能でしょ?
さらに、その部分を実際のチップに配置して、配線してみて、実際の遅延を付加して、再度遅延計算してみて、電圧や温度、ジッタをを振ってもスキューが最大tsu/thに収まるかを確認します。
これで、使用範囲では、同期部分はRTLと同じ動作をすることが確認できます。
また、各階層で、RTLと合成/配置後の論理が一致するか調べるツールがあって、それで一致を確認します。
(シミュレーション)テストベンチというのは、基本的に最初のRTLを確認するためのツールです。(遅延を入れてシミュレーションすることもできます。)
僕はVHDLはよく知りませんが、Verilogでは、各階層の各ネットに強制的にレベルを突っ込むforce文というコマンドがあって、これを使って信号を書き込んで細部検証します。RTLを直接書き直すのは、最終手段です。
一般にforceはビヘイビアのみで合成はできません(複雑すぎて、コンパイラが対応しない)
基本的には、デバッガに近いことが出来ます。(ブレークポイントから、初期値を変えて再投入みたいなのは苦手ですが。)
（１）まずはＲＴＬ（つまり論理レベル）での動作を確認・保証する→これがシミュレーションベンチ？
（２）論理レベルが保証できたもの（ＲＴＬフィックスしたもの）について合成を行い、回路に落としてもスキューが悪影響を出さない範囲内になることをシミュレーション上でフルパス確認
（３）実機に流し込んで動かし、電源電圧変動や温度変動などを含めてスキューが悪影響を出さない範囲内になることを確認
のような3段階で確認を行っていくという感じと理解しましが合ってるでしょうか？
Quartus2の使い方もそもそも良く解っているわけじゃないんですが、これらをどのように行うのかとか良く解ってなかったりします（TへT)
xilinx-iseはもーっと不明。
＞(シミュレーション)テストベンチというのは、基本的に最初のRTLを確認するためのツールです。(遅延を入れてシミュレーションすることもできます。)
そうそう。このあたりで、遅延を指定する記述とか、外部テキストファイルに記述したテスト用入力信号を取り込んだり、出力信号を出力したりするファイルの指定を行うために、ＶＨＤＬでは元のスクリプトにそういう指定を書き込んでテストベンチ作るみたいです。（と理解している）
そういうのってＶＨＤＬだけなのかどうなのかその辺もよく解ってないのですが…
あと遅延の考え方も今ひとつ解ってないんですよね。
ＲＴＬは論理の世界なので遅延計算は合成してからじゃないと判らないモノなのかとか、一般にどんなロジック組むと遅延が悪影響出すのかとか、書いたＨＤＬで遅延が問題になったらどう対処するのかとか、その辺は本読んだだけではチンプンカンプンでした。
まぁ、ちょっとずつお勉強です。
知り合いにゲーム業界人がいないので実体は良く知らないのですが、あの業界にも固有のキビシイ環境が有るっぽいみたいです。
ゲームバランスの調整の為にコロコロ仕様変更入ったり、windowsの品質や各社のグラフィックドライバの微妙な仕様差異にも悩まされたり…
完成してもゲームが面白くなければ売れませんから…やむを得ずスケジュールと仕様取り込みを優先、みたいな感じなのでしょうかねぇ…。
スケジュール、品質、コストのトリレンマは業態によってプライオリティーの付け方がそれぞれ違うってことなのかもしれません。