セルフチェック テストベンチの作成方法
セルフチェック テストベンチは、オペレータが出力を手動で検査することに依存せずに、被試験デバイス (DUT) の正確性を検証する VHDL プログラムです。セルフチェック テストベンチは完全に単独で実行され、最後に「OK」または「失敗」メッセージを出力します。
すべての VHDL モジュールには、関連付けられたセルフチェック テストベンチが必要です。すべてのモジュールが意図した動作をしていることをいつでも確認できることが重要です。たとえば、DUT、サブモジュール、またはインターフェイス モジュールに変更を加える場合です。壊れる可能性があることは誰もが知っています。これらの問題を検出するための最良のツールは、セルフチェック テストベンチです。
被試験デバイス
早速、セルフチェック テストベンチの例を作成してみましょう。まず、テストするもの、DUT が必要です。そのために、以下のコードでモジュールを作成しました。バイナリからグレイ コードへのコンバーターです。
library ieee;
use ieee.std_logic_1164.all;
entity gray_converter is
port (
bin : in std_logic_vector;
gray : out std_logic_vector
);
end gray_converter;
architecture rtl of gray_converter is
begin
process(bin) is
begin
gray(gray'high) <= bin(bin'high);
for i in bin'high - 1 downto bin'low loop
gray(i) <= bin(i + 1) xor bin(i);
end loop;
end process;
end architecture;
グレイ コードは、通常のバイナリ エンコーディングとは異なる代替数値コーディング スキームです。グレイ コードの主な特性と目的は、隣接する数値の間をカウントするときに 1 ビットだけ変化することです。
| 10 進数 | バイナリ | グレー |
|---|---|---|
| 0 | 0000 | 0000 |
| 1 | 0001 | 0001 |
| 2 | 0010 | 0011 |
| 3 | 0011 | 0010 | 4 | 0100 | 0110 | 5 | 0101 | 0111 | 6 | 0110 | 0101 | 7 | 0111 | 0100 | 8 | 1000 | 1100 | 9 | 1001 | 1101 | 10 | 1010 | 1111 | 11 | 1011 | 1110 | 12 | 1100 | 1010 | 13 | 1101 | 1011 | 14 | 1110 | 1001 | 15 | 1111 | 1000 |
上の表は、グレイ コードとバイナリ コードの違いを示しています。
テストベンチ
まず、基本的なテストベンチを作成し、その中で DUT をインスタンス化します。以下のコードは、インスタンス化された DUT と必要なすべてのインポートを含むテストベンチ ファイルを示しています。
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use std.env.finish;
entity gray_converter_tb is
end gray_converter_tb;
architecture sim of gray_converter_tb is
signal bin : std_logic_vector(3 downto 0) := (others => '0');
signal gray : std_logic_vector(3 downto 0);
begin
DUT : entity work.gray_converter(rtl)
port map (
bin => bin,
gray => gray
);
end architecture;
std.env.finish をインポートしていることに注意してください これには VHDL-2008 が必要です。何も変更せずに ModelSim でテストベンチをコンパイルしようとすると、次のエラーが発生します:
# ** Warning: gray_converter_tb.vhd(6): (vcom-1516) Package "STD.ENV" does not exist in this language version.
幸いなことに、これはテストベンチ ファイルの VHDL バージョンを VHDL-2008 に設定することで簡単に修正できます。テストベンチ .vhd ファイルを右クリックし、[プロパティ] → [VHDL] → [1076-2008 を使用] → [OK] を選択します。
DUT を変更する必要はありません。 RTL モジュールよりも高いバージョンの VHDL をテストベンチに使用するのが普通です。テストベンチで常に最新の VHDL コンストラクトを使用できるようにしたいと考えていますが、ほとんどの合成ツールはそれらをサポートしていません。
入力の生成
テストベンチへの次の追加は、DUT の入力を生成するプロセスです。可能なすべての入力値を試すテストである、徹底的なテストを作成することが常に最善です。ただし、順列が多すぎると、まれなケースのみに制限される場合があります。
DUT の入力と出力の範囲は指定されていません。ただし、このモジュールで発生する可能性のある問題を明らかにするには、4 ビットのベクトル長でテストするだけで十分であると推測します。
以下のコードには、入力シーケンスを生成するプロセス全体が含まれています。
PROC_SEQUENCE : process
begin
-- Test all possible input values
for i in 0 to 2**bin'length - 1 loop
bin <= std_logic_vector(to_unsigned(i, bin'length));
wait for 10 ns;
end loop;
-- Finally, test the wrapped value
bin <= (others => '0');
wait for 10 ns;
report "Test: OK";
finish;
end process;
最初のコード チャンクは、最小値から最大値までのカウント シーケンスを生成する For ループです。値の間で、DUT が反応できるように 10 ナノ秒待機します。ただし、DUT 内のロジックは純粋に組み合わせであるため、0 より大きいナノ秒値は機能します。
コードの 2 番目のチャンクは、入力カウンターが最初の入力値である 0 に戻る状況をテストするためのものです。その後、DUT は同じ結果を何度も出し続けるため、さらにテストする必要はありません。
プロセス内の最後の 2 つのコード行は、テストを正常に終了するためのものです。テキスト「Test:OK」がコンソールに出力され、VHDL-2008 キーワード「finish」を使用してシミュレーションが停止されます。
デフォルトの実行ボタンで ModelSim を実行すると、ModelSim はテストベンチが正常に完了した後に終了ダイアログを表示することに注意してください。スクリプトまたはコマンド ラインから Vsim を起動すると、この動作が変更される場合があります。 ModelSim コマンド リファレンスで説明されているように、「-onfinish stop」スイッチを Vsim コマンドに追加します。
出力の確認
ここで、DUT に入力を供給していますが、出力のチェックはまったく行われません。テストベンチは、出力が正しいかどうかに関係なく、「Test:OK」と出力します。なんとかしましょう。
検証アルゴリズムを作成するときは、常に DUT とは異なる方法でテストを実装するようにしてください。そうしないと、テストベンチ アルゴリズムだけでなく DUT にも存在するため、ロジックの根本的な欠陥が見過ごされる可能性があります。
この原則に従って、グレー コードが正しいことを確認するのではなく、ある数値から次の数値に 1 ビットだけが変化することを確認することによって、DUT 出力をテストします。結局のところ、それがグレイ コードを使用するそもそもの理由なのです。以下のコードは、この種のチェックを実行するプロセスを示しています。
PROC_CHECKER : process
variable prev : std_logic_vector(gray'range);
variable count : integer;
begin
wait on bin;
prev := gray;
-- Wait for all delta cycles to propagate
wait for 1 ns;
-- Count the number of changed bits
count := 0;
for i in gray'range loop
if gray(i) /= prev(i) then
count := count + 1;
end if;
end loop;
assert count = 1
report integer'image(count) & " bits changed, should have been 1"
severity failure;
end process;
プロセスは bin に敏感です 信号、DUT への入力。センシティビティ リストを使用して同じ結果を得ることもできましたが、テストベンチ コードでは Wait ステートメントのみを使用することをお勧めします。これは、コードの書き方を見るだけで、テストベンチを扱っているのか、RTL モジュールを扱っているのかを簡単に判断できる規則です。
秒行では、前の DUT 出力をコピーします。これは bin の後の最初のデルタ サイクルであることを思い出してください。 信号が変化し、DUT がまだ反応できない可能性があります。したがって、これが古い値であるという前提で DUT 出力をコピーしても安全です。
次に、DUT 内のすべての組み合わせロジックが完了するまで 1 ナノ秒待ちます。これで、DUT 出力は安定し、その値を安全に調べることができます。
コードの次のチャンクでは、DUT 出力で変更されたビット数をカウントするために For ループを使用します。
最後に、変更されたビット数が正確に 1 であることを確認する Assert ステートメントが続きます。Assert ステートメントは条件をチェックすることで機能します。この場合は count = 1 です。 .条件が false と評価された場合 、アサーションが発生し、「Test:OK」メッセージが出力される前にシミュレーターが停止します。
オプションのレポート ステートメントを assert ステートメントに含めることをお勧めします。このテキストは、アサーションが失敗した場合に出力されます。この例では、テストベンチが失敗する原因となったイベントについて簡単に説明します。
テストベンチの実行
テストベンチを実行して、DUT が正しく動作していることを確認します。 ModelSim でシミュレーションを開始し、「run -all」ボタンを押すと、「Test:OK」というメッセージがコンソールに表示されます。
VSIM 1> run -all # ** Note: Test: OK # Time: 170 ns Iteration: 0 Instance: /gray_converter_tb
テストベンチのテスト
テストベンチが機能することを確認するためだけに、DUT で障害状態を作成するのが好きです。これは、開発中の DUT の実際のエラーが原因で自然に発生する場合があります。しかし、そうでない場合は、簡単にエラーを作成してテストベンチをテストしてください。
これを実現するために、DUT コードを編集して、ビット番号 3 でスタック アット 0 エラーを作成します。このテストの後、テストベンチがそのようなエラーを検出できるという知識を持ってエラーを削除します。以下のコードは、コード行を追加した DUT プロセスを示しています。
process(bin) is
begin
gray(gray'high) <= bin(bin'high);
for i in bin'high - 1 downto bin'low loop
gray(i) <= bin(i + 1) xor bin(i);
end loop;
-- Emulate a stuck at zero error
gray(3) <= '0';
end process;
ここでテストベンチを実行すると、テストベンチが停止し、「Test:OK」行に到達する前にエラーが出力されることがわかります。 ModelSim コンソールからのトランスクリプトを以下に示します。
VSIM 2> run -all # ** Failure: 0 bits changed, should have been 1 # Time: 81 ns Iteration: 0 Process: /gray_converter_tb/PROC_CHECKER File: gray_converter_tb.vhd # Break in Process PROC_CHECKER at ray_converter_tb.vhd line 61
セルフチェック テストベンチの使用開始
この記事で学んだことを使用して、セルフチェック テストベンチを作成できるはずです。すべての VHDL モジュールに対して常にセルフチェック テストベンチを作成する習慣をつけてください。長期的には時間を節約できます。
テストベンチを作成するときに創造的であることは問題ありません。すべての VHDL コンストラクトを合成できるわけではありませんが、テストベンチは合成可能である必要はないため、RTL モジュールを作成する場合よりもそうです。少なくとも DUT の作成に費やすのと同じくらいの時間をテストの作成に費やすことを期待してください。
テストに真剣に取り組みたい場合は、私の * に興味があるかもしれません 今後のVHDLおよびFPGAコース。このコースでは、アイデアから実際に動作する FPGA プロトタイプまでの完全な設計プロセスについて説明します。複数のセルフチェック テストベンチを作成します。
2020 年 10 月 12 日に更新: コースを修了しました。詳細については、下の画像をクリックしてください。
VHDL および FPGA デザインを正しく作成するためのベスト プラクティスを紹介します。学界での長年の経験と、防衛産業でハードウェア エンジニアとして働いた後に得た知識があなたに伝えられます。
ドット マトリックス VHDL および FPGA コースの詳細については、こちらをご覧ください!
開く:
未定 .
VHDL