@Vengineerの戯言 : Twitter
SystemVerilogの世界へようこそ、すべては、SystemC v0.9公開から始まった
Mentorの検証関連のブログで、Neil Johnsonさんのブログがいろいろと書いてあって読むべきものかな？と思った。
Mentorの検証関連のブログ、
— Vengineer＠アマゾンプライムで映画三昧 (@Vengineer) 2020年5月5日
読んだ方がいいかも？
Verification Methodology Resethttps://t.co/CbPm1FSad5
Tools In A Methodology Toolboxhttps://t.co/vFErcbDRS8
The Ideal Verification Timelinehttps://t.co/2J6ePny1Qj
Tools In A Methodology Toolbox
この中で、下図(URLを組み込み引用しています)では、デザインの抽象度とテストの抽象度の2次元の関係とそれを検証するための手法がマッピングされています。オレンジがフォーマルツール、青がシミュレーションベース。
これから、フォーマルツールは、bus レベルの検証ぐらいまでしかできない。あたし的には、フォーマルツールは設計をサポートするためのツールなのかな？とずーと思っていて、まー、だいたいそんな感じということもツールベンダーも認識しているということなのかな？
検証での、
- Constrained Random Test
- Goal-driven Stimulus
- Constrained Random Closure
- Systematic Closure
で非常に似た言葉だけど、
Goal-Driven Stimulus – Constrained Random Testing
Comprehensive, very high effort techniques at the feature level are goal-driven stimulus and constrained random testing. The increase in effort corresponds to the addition of infrastructure for self-checking and stimulus generation. Goal-driven stimulus comprehensively covers a specified feature space; likewise for constrained random with randomization that takes a design beyond the known feature space. The primary objectives of both are bug finding. Tests cover multiple transactions with variability across those transactions. Moderate to expert level experience is required.
DeeLによる翻訳(ちょっと変更しています)
フィーチャーレベルでの包括的で非常に高い努力が必要なテクニックは、ゴールドリブン型のスティミュラスと制約付きランダムテストです。努力の増加は、自己チェックとスティミュラス生成のためのインフラストラクチャの追加に対応しています。ゴールドリブン型のスティミュラスは、指定された特徴空間を包括的にカバーします。同様に、既知の特徴空間を超えて設計を行う無作為化を伴う制約付きランダムテストも同様です。両者の主な目的はバグ発見です。テストは、複数のトランザクションをカバーし、それらのトランザクション間で変動性があります。中程度からエキスパートレベルの経験が必要です。
Systematic Closure – Constrained Random Closure
Similar description to goal-driven stimulus and constrained random test, except closure implies design quality stabilized such that effort moves beyond bug hunting and into coverage closure. Same infrastructure required with additions for functional coverage, more rigorous stimulus and longer running and/or more targeted tests. Systematic closure incorporates intelligent randomization through the addition of portable stimulus. Both techniques focus on exhaustively exercising integrated feature sets while systematic closure stretches into the system abstraction.
DeepLによる翻訳(ちょっと変更しています)
ゴールドリブン型のスティミュラスや制約付きランダムテストと似たような説明ですが、クロージャは、バグハンティングを超えてカバレッジのクロージャへと努力が移るように設計品質が安定化することを意味しています。機能カバレッジ、より厳格なスティミュラス、より長い実行時間、および/またはよりターゲットを絞ったテストのために追加された、同じインフラストラクチャが必要となります。系統的なクロージャは、ポータブルな刺激を追加することでインテリジェントなランダム化を組み込んでいます。どちらの技術も、統合された機能セットを徹底的に行使することに焦点を当てていますが、システマティッククロージャーはシステムの抽象化にまで踏み込んでいます。
ざっくり、機能カバレッジを取ってテストを追加していくのが、後者のSystematic Closure – Constrained Random Closureって感じですかね？
で、The Ideal Verification Timelineにある下図(URLを組み込み引用しています)では、開発フェーズでのどんな手法を使っていくのかを示しています。
Directed Tests が Sanity のところと、Closureのところにあるんですよね。
最初は、Directed Testsでテストケースを書いて、その後は、Constrained Randam Test、Constrained Random Coverageに移行していきますが、最後にCoverageのために Directed Tests は必要になります。
