Verification Engineerの戯言
Verification New 2008のタイトル、Requirements Based Verificationとは、はたして、どんなものか？
どうやら、2つのプロセスとして、
どうやら、2つのプロセスとして、
Process 1: Requirements Extraction
Process 2: Requirements Prioritization
があるようです。Requirements Extraction、要求抽出ですよね！ では、要求はどこから来るのか！
・Techniques for understanding a designとあります。確かにデザインを理解する技術は必要ですね！
でも、要求仕様書が必要では？
ソフトウェアでは要求仕様書というものを作ります。
それは、実際に使う人と作る人は違うからです。
ソフトウェアでは要求仕様書というものを作ります。
それは、実際に使う人と作る人は違うからです。
検証では、機能および実装仕様書が要求仕様書に対応するのでしょう！
機能仕様書だけでは、実装に依存する部分を検証できないので、やっぱり実装仕様書が必要です。
実装仕様書が無いとたぶん、Black-Box検証のみになり、
実装に対して検証(テスト、スティミュラス)が不足し、Bugが残ります！
機能仕様書だけでは、実装に依存する部分を検証できないので、やっぱり実装仕様書が必要です。
実装仕様書が無いとたぶん、Black-Box検証のみになり、
実装に対して検証(テスト、スティミュラス)が不足し、Bugが残ります！
機能仕様書から機能として検証する部分を抽出し、
実装仕様書からは実装ではほんとうにそのように実装されているかを検証することになります。
実装仕様書からは実装ではほんとうにそのように実装されているかを検証することになります。
こう考えてみると、やっぱり、機能仕様書と実装仕様書があれば、実装コードはいらないですね。
つまり、自動生成すればいいのでしょう！
まだ、そのようなツールは一般的ではないですが、いずれ、出てくるでしょう！
CソースコードからHDLを生成できるのですから、実装仕様書から実装コードは出せるでしょう！
つまり、自動生成すればいいのでしょう！
まだ、そのようなツールは一般的ではないですが、いずれ、出てくるでしょう！
CソースコードからHDLを生成できるのですから、実装仕様書から実装コードは出せるでしょう！
でも、実装仕様書は誰が読んでも、一義的になっていなければ、自動生成できないですね！うー。大変だ！
1つのヒントとしては、レジスタに関するものは、SpectaRegのようなツールを使えば、実装コードばかりでなく、
テストベンチや文書なども自動生成してくれます。でも、レジスタだけではないんですよね？ 困った。
テストベンチや文書なども自動生成してくれます。でも、レジスタだけではないんですよね？ 困った。
話は戻りますが、いろいろやって、
・ Writing requirements
・ Why detail is important
とあります。おー、検証者が要求仕様書を書くんだ。おまけに、詳細も重要なんだよね！前半の私の考えと、要求仕様書を書き、詳細も重要であるというポイントでは、同じだが、
要求仕様書を書く人は、実装者(設計者)ではなく、検証者なのがいまいち、理解できない。
要求仕様書を書く人は、実装者(設計者)ではなく、検証者なのがいまいち、理解できない。
この点をセミナーでは、しっかり聞いてこよう！
検証、Verification
