有限状態マシン検証

みなさんこんにちは！ この記事は、Verilog（設計）およびSystem Verilog（検証）で説明されている自動販売機の設計の検証に専念します。

一般に、この出版物の基礎は私のコースプロジェクトであり、Habréで出版物を作成する提案をしてくれた私の先生に感謝されました。

私が注目したい主なことは、典型的な多層テストベンチブロックの説明と、SystemVerilog言語の基本的な構成のいくつかと検証の適用です。 私が使用したアプローチは、プロジェクトの開発を簡素化し、個人的には便利な変更を加えた、いわゆるOpen Verification Methodology（OVM）に基づいています。

さあ、行こう！

デバイスの仕様とその動作原理

以下の資料は、デバイスの仕様とはほとんど言えませんが、試みられました。 そして、これはそれから来たものです。

検証済みのデバイスはムーアの有限状態マシンであり、その目的は自動販売機を操作することです。

デバイスインターフェイス：7つの入力信号/バスと6つの出力信号/バス。 信号の目的、その分解能、および便宜上の方向は表形式で示されています。

信号/バス名	方向	収容人数	予定
i_clk	入力	1	同期信号
i_rst_n	入力	1	アクティブローリセット
i_money	入力	4	通貨単位のコードが送信されるバス
i_money_valid	入力	1	i_moneyバスのコード有効性信号
i_product_code	入力	4	製品コードが送信されるバス
i_buy	入力	1	購入確認信号
i_product_ready	入力	1	製品の出荷準備ができたことを示す信号（入力、別のデバイスが製品の準備に従事していることを受け入れたため）
o_product_code	休み	4	バイヤーへの発行の製品コード
o_product_valid	休み	1	o_product_codeバス上の情報有効性信号
o_busy	休み	1	ステートマシンが現在の注文の処理でビジーであることを示すシグナル
o_change_denomination_code	休み	4	配信、または通貨単位の金種のコード
o_change_valid	休み	1	o_change_denomination_codeバス上の有効性信号
o_no_change	休み	1	変更完了の合図

合計で、ステートマシンには4つの状態があります：CHOOSE_PRODUCT、ENTER_MONEY、GIVE_PRODUCT、GIVE_CHANGE。

名前から、原則として、何が明確であると思います。


また、この奇跡のある種の図に注意することをお勧めします。


→ Verilogの説明はこちらにあります

検証自体

このセクションを2つの部分に分けたいと思います。 最初に、テストベンチの構造を示し、それを構成する各機能ブロックについて説明します。 2番目では、いわゆるコードと機能のカバレッジ、およびアサーションについて説明します。

テストベンチ構造

テストベンチの構造を示す図から始めましょう。



各ブロックを個別に検討してください。

DUT （テスト対象設計）-このブロックは、テストブロックブロックがインターフェイスを使用して相互にやり取りできるようにする短いラッパーの形式で、1つの小さなリビジョンを持つステートマシンデバイスの説明です。

一般に、 インターフェイスはSystemVerilog言語のような構造であるため、シグナルをグループ化して開発者の作業を簡素化できます。 これにより、言語の標準で読むことができる多くのクールなことを行うことができます。この記事では少し説明します。

DUTリファレンス

アサーション -ここでは、設計の動作がデバイスの仕様とどの程度一致するかを信号レベルで確認します。

これでは、 assert 、 property 、 sequenceなどの構成体が役立ちます 。 カバーコンストラクトを使用して、機能カバレッジの定義にモデルの動作をテストした結果を含めることもできます。

→ アサーションへのリンク

環境 -条件付きで、検証を実装する他のすべてのブロックが存在するコンテナ、つまりソフトウェア検証環境と呼ぶことができます。

それを記述するとき、 プログラム構成が使用されます。 なぜそうなのか、答えるのは難しいです。私にとってもこれは発見の質問です。 おそらくこれはSystemVerilogシミュレーターのシミュレーションの領域に起因しますが、これはまだ当て推量です。

→ 環境へのリンク

環境内には、設計のための刺激を生成し、さまざまな検証シナリオを実装し、出力で受信したデータの正確性を検証し、コードと機能カバレッジを評価する他の多くのエンティティがあります。 それでは、それらに移りましょう：

シーケンサー -検証が行われるシナリオを記述するブロック。 これらの記述は非常に高レベルであり、 Transactorが提供するメソッドに依存しています。 ここで注目すべきことは、このブロックの主力は通常randsequenceコンストラクトであることです。 その主なタスクは、 Transactorメソッドの一連の呼び出しの形式でスクリプトを整理する便利な方法を提供することです。 randsequenceの使用方法を説明するリンクを 次に示します。

→ しかし、私に起こったこと（シークエンサー）

Transactorは、実際にスクリプトの基盤として機能するメソッドを実装するブロックです。 この段階で、情報の生成も行われ、それが設計への入力として送信されます。 そして、SystemVerilogのパワーがシーンに入ります。

SystemVerilogでは、クラスフィールド値をランダムに生成できます。 これは、検証を大幅に高速化できるため、非常に便利です。 実際には、フィールドをランダムに生成するには、 キーワード randまたはrandcを使用する必要があります。

しかし、それだけではありません。 int変数を作成したが、厳密な範囲で定義するために必要な値が必要であると仮定します（たとえば、特定のアドレスのみがバスに表示されます）。 SystemVerilogには、この点であなたに贈り物があります：ランダム変数が持つプロパティに制限を課すことを可能にする制約構造。 プロジェクトの例：

rand logic [ 3:0] product_code; constraint c_product_code { product_code inside { [ 1 : 8 ] }; } 

ここで、 c_product_codeを使用して間隔[1; 8]に制限した変数product_codeを作成しました。

しかし、一つだけありますが。 クラスがインスタンス化されると、変数randおよびrandcはランダムな値で初期化されません。 これは、組み込みインスタンスメソッドrandomize（）が呼び出されたときに発生します。

Transactorに戻る。 randフィールド、 randomize（）メソッド、およびその拡張機能randomize（）の使用は、 Transactor で自然に発生します。 randomize（）とは異なり、 randomize（）を使用すると、 randフィールドが呼び出されたときに追加の制限を課すことができます。 この詳細については、SystemVerilog言語標準を参照してください 。

→ そしてもちろんTransactor

ここで本当に働くのはドライバーだけです。 彼の仕事は、 Transactorから受け取った情報を入力設計信号に変換することです。 彼と一緒に、すべてがシンプルで明確です。 したがって、 インターフェースの設計について少しお話します 。

これらは、通常のプログラミング言語で見られる構造ではありません。 ここでのインターフェイスは、ユーザーにとって便利な方法で、方向に関係なく信号をグループ化できる設計です。 このプロジェクトには、dut_interface、vm_in_interface、vm_out_interfaceの3つのインターフェース構造しかありません。 1つ目は同期およびリセット信号、2つ目はvending_machine入力、3つ目はその出力です。 だから、すべてが見えます。

→ そしてもちろん-ドライバー

INモニターとOUTモニター -これらのブロックは、正確性をさらに検証するために、 DUTに出入りする情報を読み取ります。 短い情報がDUTに届くのはなぜですか？ ドライバーロボットおよび上記のすべてのスタンディングブロックのエラーを避けるために、すべてが簡単です。

→ INおよびOUTモニター

チェッカー-IN モニターから受信したデータとOUTモニターから受信したデータに基づいて計算される参照データの適合性をチェックするブロック。

スコアボード/機能カバレッジは最後のブロックであり、異なる機能を実行する2つの別個のブロックのハイブリッドです。 スコアボード自体は、シミュレーションの最後に参照データを生成し、レポートを生成する必要がありますが、このプロジェクトは小さいため、あまり便利ではありません。 機能カバレッジ自体は、デバイス仕様に組み込まれているすべての可能な機能のカバレッジチェックを行います。

そして、ここでは、ジュース自体、 機能的なカバレッジの実行方法について説明します。 このため、SystemVerilogには特別なカバーグループ設計があります。 各カバーグループでは、いわゆるカバーポイントを定義します。このカバーポイントでは、特定の信号またはバスへのバインドが行われ、データのすべての可能なバリエーションが設計によって受信されたかどうか、すべての可能なデータが出力に表示されたかどうかがチェックされます。

一般に、 機能カバレッジの結果へのアクセスは実行時に発生するため、後でいつでも評価できる特別な機能があります。

それらの1つは、組み込み関数$ get_coverageです。これは、すべてのカバー構造（ cover 、 covergroup 、 coverpoint ）に基づいて計算された0〜100の値を返します。

ランタイムへのアクセスに加えて、グラフィカルシミュレーション環境で機能カバレッジのアイデアを取得することもできます（ModelSimを非常に正確に保証できます）。

コードカバレッジに進みましょう。 このインジケータは、私たちが書いたコードがどれだけ使用されたか、そしてテストがどれだけ完了しているかを理解させてくれます。 何らかの理由でコードカバレッジが許容レベルに達していない場合、2つのオプションがあります。より良いテストを作成するか、コードが過剰です。 いずれにせよ、これは修正する必要があります。 確かに、テストが良好で設計コードが良好な場合があることを別に言及する価値がありますが、それでもコードカバレッジが私たちに合わない場合は、スキャンから何かを除外する必要があります。

通常、 コードカバレッジをチェックします 。

• ステートメント -シミュレーション中に実行された行と実行されなかった行
• ブランチ -その他の場合、ケースの構造をチェックします
• 条件 -結果がTrueまたはFalseでなければならない論理条件をチェックします
• トグル -0から1への論理的な遷移をチェックします。

これら、およびその他のチェック（ステートマシンのチェックおよびいわゆるFEC条件 ） は、プロジェクトのコードカバレッジのアイデアを提供します 。

コードカバレッジアセスメントを有効にするには、 コードカバレッジアセスメントが実行されるファイルに適切なコンパイラ設定を設定する必要があります。

→ まあ、もちろん、私はほとんど忘れていました（スコアボード/機能カバレッジ）
→ さて、プロジェクト全体へのリンク

それだけです。 ご清聴ありがとうございました。 この記事が何かに役立つことを願っています。

また会うまで。