자가 점검 테스트벤치를 만드는 방법

프로세스 내의 마지막 두 코드 라인은 테스트를 정상적으로 종료하기 위한 것입니다. "Test:OK"라는 텍스트가 콘솔에 출력되고 VHDL-2008 키워드 "finish"를 사용하여 시뮬레이션이 중지됩니다.

기본 실행 버튼으로 ModelSim을 실행하면 Testbench가 성공적으로 완료된 후 ModelSim이 종료 대화 상자를 표시합니다. 이 동작은 스크립트나 명령줄에서 Vsim을 시작할 때 변경될 수 있습니다. ModelSim 명령 참조에 설명된 대로 "-onfinish stop" 스위치를 Vsim 명령에 추가합니다.

출력 확인

이제 DUT에 입력을 제공하지만 출력을 전혀 검사하지 않습니다. 테스트벤치는 출력이 정확한지 아닌지에 상관없이 "Test:OK"를 출력할 것입니다. 이에 대해 조치를 취하겠습니다.

검증 알고리즘을 생성할 때 항상 DUT와 다르게 테스트를 구현해야 합니다. 그렇지 않으면 DUT와 테스트벤치 알고리즘에 존재하기 때문에 로직의 근본적인 결함이 눈에 띄지 않을 수 있습니다.

이 원칙에 따라 우리는 그레이 코드가 올바른지 확인하는 것이 아니라 한 숫자에서 다음 숫자로 한 비트만 변경되는지 확인하여 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으로 평가되는 경우 , assertion이 발생하고 "Test:OK" 메시지가 출력되기 전에 시뮬레이터가 중지됩니다.

assert 문과 함께 선택적인 report 문을 포함하는 것이 현명합니다. 어설션이 실패하면 이 텍스트가 인쇄됩니다. 이 예에서는 테스트벤치를 실패하게 만든 이벤트에 대한 간략한 설명을 제공합니다.

테스트벤치 실행

이제 테스트 벤치를 실행하여 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 설계를 올바른 방법으로 성공적으로 생성하기 위한 모범 사례를 알려 드리겠습니다. 다년간 학계에서, 그리고 방위산업에서 하드웨어 엔지니어로 일하면서 얻은 지식을 여러분에게 전해드립니다.

Dot Matrix VHDL 및 FPGA 과정에 대한 자세한 내용은 여기를 참조하세요.

열기:

미정 .