home Teknologi Manufaktur Peralatan Manufaktur
Manufaktur industri
Industri Internet of Things | bahan industri | Pemeliharaan dan Perbaikan Peralatan | Pemrograman industri |
home  MfgRobots >> Manufaktur industri >  >> Industrial programming >> VHDL

Cara membuat testbench pemeriksaan mandiri

Sebuah testbench self-checking adalah program VHDL yang memverifikasi kebenaran perangkat yang sedang diuji (DUT) tanpa bergantung pada operator untuk memeriksa output secara manual. Testbench yang memeriksa sendiri sepenuhnya berjalan sendiri, dan pada akhirnya mencetak pesan “OK” atau “Gagal”.

Setiap modul VHDL harus memiliki testbench self-checking terkait. Sangat penting untuk dapat memverifikasi bahwa semua modul memiliki perilaku yang diinginkan kapan saja. Misalnya, ketika Anda membuat perubahan pada DUT, sub-modul, atau modul antarmuka. Kita semua tahu bahwa hal-hal dapat rusak, dan alat terbaik Anda untuk mengatasi masalah ini adalah testbench pemeriksaan mandiri.

Perangkat sedang diuji

Mari kita langsung masuk dan membuat contoh testbench self-checking. Pertama, kita perlu sesuatu untuk diuji, sebuah DUT. Untuk itu saya telah membuat modul pada kode di bawah ini. Ini adalah pengonversi kode biner ke abu-abu.

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;

Kode abu-abu adalah skema pengkodean angka alternatif, berbeda dari pengkodean biner biasa. Properti utama dan tujuan kode Gray adalah bahwa hanya satu bit yang berubah saat menghitung antara nilai angka yang berdekatan.

Desimal Biner Abu-abu
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

Tabel di atas menunjukkan bagaimana kode Gray berbeda dari kode biner.

Meja ujian

Kita akan mulai dengan membuat testbench dasar dan membuat DUT di dalamnya. Kode di bawah ini menunjukkan file testbench dengan DUT yang dipakai dan semua impor yang diperlukan.

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;

Perhatikan bahwa kita mengimpor std.env.finish yang membutuhkan VHDL-2008. Jika Anda mencoba mengkompilasi testbench di ModelSim tanpa mengubah apa pun, Anda akan mendapatkan kesalahan berikut:

# ** Warning: gray_converter_tb.vhd(6): (vcom-1516)
Package "STD.ENV" does not exist in this language version.

Untungnya, ini dapat dengan mudah diperbaiki dengan mengatur versi VHDL untuk file testbench ke VHDL-2008. Klik kanan file .vhd testbench dan pilih Properties→VHDL→Use 1076-2008->OK.

Anda tidak perlu mengubah apa pun untuk DUT. Itu normal untuk menggunakan versi yang lebih tinggi dari VHDL untuk testbenches daripada untuk modul RTL. Anda selalu ingin dapat menggunakan konstruksi VHDL terbaru di testbench Anda, tetapi sebagian besar alat sintesis tidak mendukungnya.

Membuat masukan

Penambahan kami berikutnya ke testbench adalah proses yang menghasilkan input untuk DUT. Itu selalu yang terbaik untuk membuat tes lengkap, tes yang mencoba semua nilai input yang mungkin. Meskipun, jika terlalu banyak permutasi, Anda mungkin dibatasi untuk hanya melakukan kasus sudut.

Input dan output dari DUT kami adalah rentang yang tidak ditentukan. Namun, saya akan menebak bahwa pengujian dengan panjang vektor empat bit sudah cukup untuk mengungkap kemungkinan masalah dengan modul ini.

Kode di bawah ini berisi seluruh proses untuk menghasilkan urutan input.

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;

Potongan kode pertama adalah loop For yang menghasilkan urutan penghitungan dari nilai serendah mungkin hingga nilai setinggi mungkin. Di antara nilai-nilai tersebut, kami menunggu selama 10 nanodetik untuk memungkinkan DUT bereaksi. Meskipun, nilai nanodetik apa pun yang lebih besar dari 0 akan berhasil, karena logika di dalam DUT murni kombinasional.

Potongan kode kedua adalah untuk menguji situasi di mana penghitung input kembali ke 0, yang merupakan nilai input awal. Setelah itu, tidak perlu pengujian lebih lanjut karena DUT hanya akan terus memberikan hasil yang sama berulang-ulang.

Dua baris kode terakhir dalam proses adalah untuk mengakhiri tes dengan anggun. Teks “Test:OK” dicetak ke konsol, dan kemudian simulasi dihentikan dengan menggunakan kata kunci VHDL-2008 “selesai”.

Perhatikan bahwa jika Anda menjalankan ModelSim dengan tombol Run default, ModelSim akan meminta Anda dengan dialog keluar setelah testbench selesai dengan sukses. Perilaku ini dapat diubah saat meluncurkan Vsim dari skrip atau dari baris perintah. Tambahkan sakelar “-onfinish stop” ke perintah Vsim, seperti yang dijelaskan dalam referensi perintah ModelSim.

Memeriksa keluaran

Sekarang kami memasok DUT dengan input, tetapi tidak ada pemeriksaan output sama sekali. Testbench akan mencetak "Test:OK", terlepas dari apakah outputnya benar atau tidak. Ayo lakukan sesuatu tentang itu.

Saat membuat algoritme verifikasi, Anda harus selalu mencoba menerapkan pengujian secara berbeda dari pada DUT. Jika tidak, kelemahan mendasar dalam logika mungkin tidak diperhatikan karena ada di DUT dan juga di algoritme testbench.

Mengikuti prinsip ini, kita akan menguji keluaran DUT bukan dengan memeriksa apakah kode Gray benar, melainkan hanya satu bit yang berubah dari satu angka ke angka berikutnya. Bagaimanapun, itulah alasan utama untuk menggunakan kode Gray. Kode di bawah ini menunjukkan proses yang melakukan pemeriksaan semacam ini.

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;

Proses sensitif terhadap bin sinyal, masukan ke DUT. Kami dapat menggunakan daftar sensitivitas dengan hasil yang sama, tetapi saya lebih suka menggunakan pernyataan Tunggu saja dalam kode testbench. Ini adalah konvensi yang memudahkan untuk mengetahui apakah Anda berurusan dengan testbench atau modul RTL hanya dengan melihat cara penulisan kode.

Pada baris detik, kami menyalin output DUT sebelumnya. Ingat, ini adalah siklus delta pertama setelah bin sinyal telah berubah, dan DUT belum dapat bereaksi. Jadi, aman untuk menyalin output DUT dengan asumsi bahwa ini adalah nilai lama.

Kemudian, kami menunggu 1 nanodetik untuk memungkinkan semua logika kombinasional di DUT selesai. Sekarang, output DUT harus stabil, dan kita dapat memeriksa nilainya dengan aman.

Pada potongan kode berikutnya, kita menggunakan perulangan For untuk menghitung jumlah bit yang diubah pada keluaran DUT.

Terakhir, muncul pernyataan Assert yang memeriksa bahwa jumlah bit yang diubah adalah tepat 1. Pernyataan Assert bekerja dengan memeriksa kondisinya, yaitu count = 1 . Jika kondisi bernilai false , pernyataan akan dimunculkan, dan simulator akan berhenti sebelum pesan “Test:OK” dicetak.

Sebaiknya sertakan pernyataan laporan opsional dengan pernyataan tegas. Teks ini akan dicetak jika pernyataan gagal. Dalam contoh kami, saya memberikan penjelasan singkat tentang peristiwa yang menyebabkan testbench gagal.

Menjalankan testbench

Saatnya menjalankan testbench kami untuk memverifikasi bahwa DUT berfungsi dengan benar. Setelah memulai simulasi di ModelSim, dan menekan tombol “run -all”, kita melihat bahwa pesan “Test:OK” dicetak ke konsol.

VSIM 1> run -all
# ** Note: Test: OK
#    Time: 170 ns  Iteration: 0  Instance: /gray_converter_tb

Menguji testbench

Saya selalu suka membuat kondisi gagal di DUT hanya untuk melihat bahwa testbench berfungsi. Terkadang ini terjadi secara alami karena kesalahan aktual dalam DUT saat Anda mengembangkannya. Tetapi jika tidak, buat kesalahan sebentar saja untuk menguji testbench.

Untuk mencapai ini, saya akan mengedit kode DUT untuk membuat kesalahan macet di 0 pada bit nomor 3. Setelah tes ini, saya akan menghapus kesalahan dengan pengetahuan bahwa testbench mampu mendeteksi kesalahan tersebut. Kode di bawah ini menunjukkan proses DUT dengan baris kode tambahan.

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;

Saat kita menjalankan testbench sekarang, kita dapat melihat bahwa testbench berhenti, dan kesalahan dicetak sebelum baris "Test:OK" tercapai. Transkrip dari konsol ModelSim ditampilkan di bawah.

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

Memulai testbenches self-checking

Anda harus dapat membuat testbench self-checking dengan menggunakan apa yang telah Anda pelajari di artikel ini. Biasakan untuk selalu membuat testbenches self-checking untuk semua modul VHDL Anda. Ini akan menghemat waktu Anda dalam jangka panjang.

Tidak apa-apa untuk menjadi kreatif saat menulis testbenches. Lebih dari saat menulis modul RTL karena tidak semua konstruksi VHDL dapat disintesis, tetapi testbench tidak perlu disintesis. Harapkan untuk menghabiskan setidaknya waktu menulis tes sebanyak yang Anda habiskan untuk menulis DUT.

Jika Anda ingin serius tentang pengujian, Anda mungkin tertarik dengan * . saya kursus VHDL dan FPGA yang akan datang. Dalam kursus ini, saya akan memandu Anda melalui proses desain lengkap dari ide hingga prototipe FPGA yang berfungsi secara fisik. Kami akan membuat beberapa testbenches self-checking.

Diperbarui 12 Oktober 2020: Saya telah menyelesaikan kursus. Klik gambar di bawah untuk mempelajari lebih lanjut.

Saya akan mengajari Anda praktik terbaik untuk berhasil membuat desain VHDL dan FPGA dengan cara yang benar. Pengetahuan yang saya peroleh selama bertahun-tahun di dunia akademis dan setelah bekerja sebagai insinyur perangkat keras di industri pertahanan akan diteruskan kepada Anda.

Baca selengkapnya tentang kursus Dot Matrix VHDL dan FPGA di sini!

Buka:

Untuk diputuskan .


VHDL

  • Bahasa C
  • VHDL
  • Verilog
  • MATLAB
  • Python
  • java
    1. Cara Membuat Template CloudFormation Menggunakan AWS
    2. Bagaimana cara membuat pusat keunggulan cloud?
    3. Cara Membuat Strategi Cloud yang Dirancang dengan Hati-hati
    4. Cara Membuat UX Tanpa Gesekan
    5. Cara membuat daftar string di VHDL
    6. Cara membuat testbench berbasis Tcl untuk modul kunci kode VHDL
    7. Bagaimana menghentikan simulasi di testbench VHDL
    8. Cara membuat Daftar Tertaut di VHDL
    9. Cara membuat kota pintar yang berpusat pada manusia
    10. Cara Membuat Array Objek di Java