VHDL
산업 제조
제한된 무작위 검증은 테스트 대상 장치(DUT)에 대한 의사 무작위 트랜잭션 생성에 의존하는 테스트벤치 전략입니다. 목표는 DUT와의 무작위 상호 작용을 통해 미리 정의된 여러 이벤트의 기능 범위에 도달하는 것입니다.
OSVVM(Open Source VHDL Verification Methodology)은 제한된 무작위 테스트벤치를 생성하기 위한 여러 편리한 패키지를 포함하는 무료 VHDL 라이브러리입니다. 우리는 특히 이 기사에서 사용할 RandomPkg 및 CoveragePck에 관심이 있습니다. 이 라이브러리의 기능에 대해 자세히 알아보려면 OSVVM GitHub 페이지를 방문하는 것이 좋습니다.
나는 제약이 있는 무작위 테스트벤치가 지시 테스트를 사용하는 클래식 테스트벤치와 어떻게 다른지 더 잘 설명하기 위해 예제로 바로 뛰어들 것입니다. 이 블로그의 이전 기사에서 링 버퍼 FIFO를 만들었지만 모듈의 정확성을 확인하기 위한 자체 검사 테스트벤치를 만들지 않았습니다.
제한된 무작위 검증을 사용하는 링 버퍼 FIFO에 대한 적절한 테스트벤치를 만들 것입니다.
entity ring_buffer is
generic (
RAM_WIDTH : natural;
RAM_DEPTH : natural
);
port (
clk : in std_logic;
rst : in std_logic;
-- Write port
wr_en : in std_logic;
wr_data : in std_logic_vector(RAM_WIDTH - 1 downto 0);
-- Read port
rd_en : in std_logic;
rd_valid : out std_logic;
rd_data : out std_logic_vector(RAM_WIDTH - 1 downto 0);
-- Flags
empty : out std_logic;
empty_next : out std_logic;
full : out std_logic;
full_next : out std_logic;
-- The number of elements in the FIFO
fill_count : out integer range RAM_DEPTH - 1 downto 0
);
end ring_buffer;
링 버퍼 모듈의 엔터티는 위의 코드에 나와 있습니다. 우리는 DUT를 블랙박스로 취급할 것입니다. 즉, DUT가 구현되는 방법에 대한 지식이 없다고 가정합니다. 결국 이 기사는 링 버퍼 FIFO가 아니라 테스트벤치에 관한 것입니다.
엔티티 인스턴스화 방법을 사용하여 테스트벤치에서 DUT를 인스턴스화합니다. 인스턴스화는 간단하므로 지금은 코드를 생략하지만 이 문서의 뒷부분에서 다운로드할 수 있습니다.
DUT 제네릭은 다음 값에 매핑됩니다.
구현을 시작하기 전에 테스트 전략을 살펴보겠습니다. 아래 이미지는 우리가 만들려고 하는 테스트벤치의 주요 개념을 보여줍니다.
DUT의 입력 측에서 임의 쓰기 트랜잭션을 수행합니다. 입력 데이터는 모든 클록 주기에서 임의의 값으로 설정되며 쓰기 활성화 입력의 스트로브는 임의 지속 시간이 됩니다.
마찬가지로 무작위로 읽기를 수행합니다. 임의의 클록 주기 동안 지속되는 버스트에서 읽기 활성화 신호를 어설션할 것입니다.
DUT와 병렬로 행동 모델이 있을 것입니다. 이것은 DUT에서 사용되는 링 버퍼와 다르게 구현되지만 여전히 동일한 인터페이스를 갖는 FIFO입니다. DUT와 달리 행동 모델은 합성할 필요가 없습니다. 이를 통해 고급 VHDL 프로그래밍 기능을 자유롭게 사용할 수 있습니다.
DUT의 출력을 별도의 프로세스에서 행동 모델의 출력과 비교할 것입니다. 이 프로세스는 assert 문을 사용하여 모든 클록 주기에서 이 비교를 수행하는 데 단독 책임이 있습니다. 두 FIFO 구현이 언제든지 다르게 작동하는 경우 어설션 실패로 인해 시뮬레이션이 오류와 함께 종료됩니다.
마지막으로 DUT로 들어오고 나가는 트랜잭션을 관찰하여 기능적 적용 범위 데이터를 수집합니다. 기능적 적용 범위는 예를 들어 동시 읽기 및 쓰기 또는 FIFO가 한 번 이상 채워지는 것을 의미할 수 있습니다. 우리는 주요 테스트벤치 시퀀서 프로세스에서 이러한 이벤트를 모니터링할 것입니다. 모니터링 중인 모든 기능적 적용 범위 이벤트가 발생하면 시뮬레이션이 중지됩니다.
OSVVM 라이브러리는 VHDL-2008을 지원하는 모든 시뮬레이터와 함께 사용할 수 있습니다. 시뮬레이터와 함께 제공되는 기본 라이브러리에 이미 포함되어 있을 수 있습니다. Mentor Graphics에서 무료로 다운로드할 수 있는 ModelSim PE 학생용 에디션에 포함되어 있습니다.
ModelSim은 이전 버전의 OSVVM과 함께 제공되지만 괜찮습니다. 필요한 모든 것이 있습니다. 다음과 같이 무작위 및 적용 범위 패키지를 가져올 수 있습니다.
library osvvm; use osvvm.RandomPkg.all; use osvvm.CoveragePkg.all;
최신 버전의 OSVVM 라이브러리는 항상 GitHub 페이지에서 다운로드할 수 있습니다. 시뮬레이터에 포함되어 있지 않거나 라이브러리의 최신 기능을 사용하려면 이 작업을 수행하십시오.
OSVVM 라이브러리에는 보호된 유형의 패키지가 포함되어 있습니다. 이들로 생성된 변수는 해당 변수가 정의된 프로세스의 범위가 제한됩니다. 따라서 아래 코드와 같이 테스트벤치 아키텍처의 선언적 영역에서 공유 변수로 대신 선언합니다.
-- OSVVM variables shared variable rv : RandomPType; shared variable bin1, bin2, bin3, bin4, bin5, bin6 : CovPType;
rv RandomPType 유형의 변수 임의의 값을 생성하기 위한 것입니다. 무작위 값을 생성해야 하는 모든 프로세스에서 동일한 객체를 사용할 수 있기 때문에 이 중 하나만 필요합니다. 마지막 코드 줄은 CovPType 유형의 변수 6개를 선언합니다. .
우리는 6개의 커버리지 목표를 가질 것이기 때문에 6개의 커버리지 변수를 선언했습니다. 우리는 이 객체들을 «bins»라고 부를 것입니다. 공유 변수는 커버리지 데이터 수집에 사용되기 전에 초기화되어야 합니다. AddBins을 호출하여 이를 수행합니다. 각 CovPType에 대한 절차 쓰레기통.
-- Set up coverage bins
bin1.AddBins("Write while empty", ONE_BIN);
bin2.AddBins("Read while full", ONE_BIN);
bin3.AddBins("Read and write while almost empty", ONE_BIN);
bin4.AddBins("Read and write while almost full", ONE_BIN);
bin5.AddBins("Read without write when almost empty", ONE_BIN);
bin6.AddBins("Write without read when almost full", ONE_BIN);
커버리지 빈의 문자열 설명을 AddBins의 첫 번째 매개변수로 제공합니다. 절차. 이 문자열은 각 커버리지 빈에 대한 통계를 인쇄할 때 시뮬레이션이 끝날 때 다시 나타납니다. 텍스트 설명에서 알 수 있듯이 우리는 특정 코너 케이스가 발생했는지 여부를 확인하기 위해 빈을 사용할 것입니다.
AddBins bin 변수 내에서 여러 스코어보드를 생성하는 데 사용할 수 있는 오버로드된 절차입니다. 그러나 각 빈과 연결된 스코어보드는 하나만 있습니다. 따라서 편의상 상수 ONE_BIN을 제공합니다. AddBins에 대한 매개변수로 절차. 그러면 CovPType가 초기화됩니다. 각각 하나의 빈이 있는 변수. 빈으로 표시되는 스코어보드는 모니터링하는 이벤트가 한 번 이상 발생한 경우 포함된 것으로 간주됩니다.
DUT에 대한 입력 데이터를 생성하는 프로세스를 만드는 것으로 시작하겠습니다. 링 버퍼 FIFO는 덮어쓰기 및 읽기 시도를 무시하도록 설계되었습니다. 따라서 무작위 기간의 버스트에서 무작위 데이터를 간단히 쓸 수 있습니다. DUT가 실제로 데이터를 흡수할 준비가 되었는지 여부에 대해 생각할 필요가 없습니다.
PROC_WRITE : process
begin
wr_en <= rv.RandSlv(1)(1) and not rst;
for i in 0 to rv.RandInt(0, 2 * RAM_DEPTH) loop
wr_data <= rv.RandSlv(RAM_WIDTH);
wait until rising_edge(clk);
end loop;
end process;
이 프로세스에서 고려해야 할 유일한 사항은 DUT가 재설정되지 않는다는 것입니다. 이 프로세스의 첫 번째 줄에서 쓰기 활성화 신호를 무작위로 활성화하거나 비활성화하지만 rst인 경우에만 활성화됩니다. '0'입니다. .
후속 for 루프는 활성화 신호가 활성화되지 않은 경우에도 임의의 클록 주기 동안 DUT에 임의의 데이터를 기록합니다. DUT가 wr_data를 무시해야 하기 때문에 이렇게 할 수 있습니다. wr_en이 아닌 경우 포트 신호는 '1'입니다. . for-loop 후에 프로그램은 프로세스의 시작 부분으로 루프백하여 또 다른 임의의 쓰기 트랜잭션을 트리거합니다.
DUT에서 데이터를 읽는 프로세스는 쓰기 프로세스와 유사합니다. 무작위로 rd_en를 활성화할 수 있습니다. DUT는 비어 있을 때 읽기 시도를 무시하도록 설계되었기 때문에 언제든지 신호를 보낼 수 있습니다. rd_data에 나타나는 데이터 포트는 실제로 확인되지 않습니다. 이 프로세스는 읽기 활성화 신호만 제어합니다.
PROC_READ : process
begin
rd_en <= rv.RandSlv(1)(1) and not rst;
for i in 0 to rv.RandInt(0, 2 * RAM_DEPTH) loop
wait until rising_edge(clk);
end loop;
end process;
테스트벤치 내에서 DUT의 동작 모델을 구성하여 동작을 확인합니다. 이것은 잘 알려진 테스트벤치 전략입니다. 먼저 DUT와 동일한 입력으로 행동 모델을 동시에 공급합니다. 그런 다음 둘의 출력을 비교하여 DUT가 올바른 동작을 하는지 확인할 수 있습니다.
위의 이미지는 이러한 테스트벤치의 기본 레이아웃을 보여줍니다. 행동 모델은 DUT와 병렬로 작동합니다. DUT의 출력을 비교하기 위한 청사진으로 사용합니다.
우리는 행동 모델을 구현하기 위해 연결 목록을 사용할 것입니다. 연결 목록은 합성할 수 없지만 테스트벤치에는 완벽합니다. VHDL에서 연결 목록을 만드는 방법을 기억할 것입니다. 이 블로그의 일반 독자라면 이 기사를 참조하십시오. 이 코드를 사용하여 링 버퍼 FIFO에 대한 동작 모델을 구현합니다.
package DataStructures is
type LinkedList is protected
procedure Push(constant Data : in integer);
impure function Pop return integer;
impure function IsEmpty return boolean;
end protected;
end package DataStructures;
Linked List FIFO에 대한 패키지 선언은 위의 코드에 나와 있습니다. 세 가지 기능을 가진 보호된 유형입니다. 푸시, 팝 및 IsEmpty. 이들은 FIFO에서 요소를 추가 및 제거하고 요소가 0으로 남아 있는지 확인하는 데 사용됩니다.
-- Testbench FIFO that emulates the DUT shared variable fifo : LinkedList;
보호된 형식은 VHDL의 클래스와 유사한 구조입니다. 위의 코드와 같이 테스트벤치의 선언적 영역에 공유변수를 선언하여 연결리스트의 객체를 생성합니다.
링 버퍼 FIFO의 동작을 완전히 에뮬레이트하기 위해 DUT의 출력 신호를 미러링하는 두 개의 새로운 신호를 선언합니다. 첫 번째 신호는 행동 모델의 출력 데이터를 포함하고 두 번째는 연결된 유효한 신호입니다.
-- Testbench FIFO signals signal fifo_out : integer; signal fifo_out_valid : std_logic := '0';
위의 코드는 행동 모델의 두 출력 신호 선언을 보여줍니다. DUT에 연결된 신호와 동일하기 때문에 행동 모델에 대한 전용 입력 신호가 필요하지 않습니다. 신호를 사용하여 DUT 출력을 에뮬레이트하는 이유는 이 기사의 뒷부분에서 살펴보겠지만 커버리지 데이터를 쉽게 수집할 수 있기 때문입니다.
PROC_BEHAVIORAL_MODEL : process
begin
wait until rising_edge(clk) and rst = '0';
-- Emulate a write
if wr_en = '1' and full = '0' then
fifo.Push(to_integer(unsigned(wr_data)));
report "Push " & integer'image(to_integer(unsigned(wr_data)));
end if;
-- Emulate a read
if rd_en = '1' and empty = '0' then
fifo_out <= fifo.Pop;
fifo_out_valid <= '1';
else
fifo_out_valid <= '0';
end if;
end process;
링 버퍼 FIFO의 동작 모델을 구현하는 프로세스는 위의 코드에 나와 있습니다. 리셋 신호가 활성화되지 않은 경우 이 프로세스는 클록의 모든 상승 에지에서 트리거됩니다.
행동 모델은 wr_en이 발생할 때마다 테스트벤치 FIFO에 새 값을 푸시합니다. 신호는 full 동안 어설션됩니다. 신호는 '0'입니다. . 유사하게, 행동 모델 프로세스의 읽기 로직은 rd_en 및 empty 신호. 후자는 DUT에 의해 제어되지만 우리가 만들 다음 프로세스에서 작동하는지 확인할 것입니다.
DUT의 출력을 확인하는 모든 로직은 «PROC_VERIFY»라는 프로세스에 수집됩니다. DUT의 출력이 행동 모델의 출력과 일치하는지 확인하기 위해 assert 문을 사용하고 있습니다. 또한 FIFO가 비어 있을 때 DUT와 행동 모델이 일치하는지 확인합니다.
검증 프로세스를 위한 코드는 아래와 같습니다.
PROC_VERIFY : process
begin
wait until rising_edge(clk) and rst = '0';
-- Check that DUT and TB FIFO are reporting empty simultaneously
assert (empty = '1' and fifo.IsEmpty) or
(empty = '0' and not fifo.IsEmpty)
report "empty=" & std_logic'image(empty)
& " while fifo.IsEmpty=" & boolean'image(fifo.IsEmpty)
severity failure;
-- Check that the valid signals are matching
assert rd_valid = fifo_out_valid
report "rd_valid=" & std_logic'image(rd_valid)
& " while fifo_out_valid=" & std_logic'image(fifo_out_valid)
severity failure;
-- Check that the output from the DUT matches the TB FIFO
if rd_valid then
assert fifo_out = to_integer(unsigned(rd_data))
report "rd_data=" & integer'image(to_integer(unsigned(rd_data)))
& " while fifo_out=" & integer'image(fifo_out)
severity failure;
report "Pop " & integer'image(fifo_out);
end if;
end process;
프로세스는 첫 번째 코드 라인에서 볼 수 있듯이 클럭의 상승 에지에 의해 트리거됩니다. DUT는 클럭 프로세스이며 DUT에 연결된 다운스트림 로직도 클럭 신호와 동기화될 것으로 예상됩니다. 따라서 상승 클록 에지에서 출력을 확인하는 것이 좋습니다.
두 번째 코드 블록은 empty DUT에서 오는 신호는 테스트벤치 FIFO가 비어 있는 경우에만 어설션됩니다. 이 테스트를 통과하려면 DUT와 행동 모델 모두 FIFO가 비어 있는지 여부에 동의해야 합니다.
그런 다음 읽기 데이터 유효 신호를 비교합니다. DUT와 행동 모델은 동시에 데이터를 출력해야 합니다. 그렇지 않으면 문제가 있는 것입니다.
마지막으로 DUT의 출력 데이터가 테스트벤치 FIFO에서 팝한 다음 요소와 일치하는지 확인합니다. 물론 이것은 rd_valid rd_data 신호를 샘플링할 수 있습니다.
테스트벤치의 주요 흐름을 제어하기 위해 시퀀서 프로세스를 생성합니다. 이 프로세스는 커버리지 빈을 초기화하고, 테스트를 실행하고, 모든 커버리지 목표가 충족되면 테스트벤치를 중지합니다. 아래 코드는 완전한 «PROC_SEQUENCER» 프로세스를 보여줍니다.
PROC_SEQUENCER : process
begin
-- Set up coverage bins
bin1.AddBins("Write while empty", ONE_BIN);
bin2.AddBins("Read while full", ONE_BIN);
bin3.AddBins("Read and write while almost empty", ONE_BIN);
bin4.AddBins("Read and write while almost full", ONE_BIN);
bin5.AddBins("Read without write when almost empty", ONE_BIN);
bin6.AddBins("Write without read when almost full", ONE_BIN);
wait until rising_edge(clk);
wait until rising_edge(clk);
rst <= '0';
wait until rising_edge(clk);
loop
wait until rising_edge(clk);
-- Collect coverage data
bin1.ICover(to_integer(wr_en = '1' and empty = '1'));
bin2.ICover(to_integer(rd_en = '1' and full = '1'));
bin3.ICover(to_integer(rd_en = '1' and wr_en = '1' and
empty = '0' and empty_next = '1'));
bin4.ICover(to_integer(rd_en = '1' and wr_en = '1' and
full = '0' and full_next = '1'));
bin5.ICover(to_integer(rd_en = '1' and wr_en = '0' and
empty = '0' and empty_next = '1'));
bin6.ICover(to_integer(rd_en = '0' and wr_en = '1' and
full = '0' and full_next = '1'));
-- Stop the test when all coverage goals have been met
exit when
bin1.IsCovered and
bin2.IsCovered and
bin3.IsCovered and
bin4.IsCovered and
bin5.IsCovered and
bin6.IsCovered;
end loop;
report("Coverage goals met");
-- Make sure that the DUT is empty before terminating the test
wr_en <= force '0';
rd_en <= force '1';
loop
wait until rising_edge(clk);
exit when empty = '1';
end loop;
-- Print coverage data
bin1.WriteBin;
bin2.WriteBin;
bin3.WriteBin;
bin4.WriteBin;
bin5.WriteBin;
bin6.WriteBin;
finish;
end process;
먼저 AddBins을 호출하여 Coverage bin 객체를 초기화합니다. 이 문서의 앞부분에서 이미 논의한 대로 절차를 수행합니다. 그런 다음 재설정이 릴리스된 후 적용 범위 데이터를 수집합니다. 시계의 모든 상승 에지에서 루프 구조 내부의 코드가 실행됩니다.
루프 내부의 첫 번째 코드 블록은 커버리지 데이터를 수집하기 위한 것입니다. ICover 표시하는 커버리지 포인트에 적중을 기록하기 위해 빈에 대한 절차. 정수 매개변수 0를 제공하면 , 호출은 효과가 없습니다. 정수 매개변수 1를 사용하는 경우 , 조회수로 계산됩니다.
ONE_BIN을 사용하여 초기화했기 때문에 각 Coverage bin 객체 내부에는 «bin»이 하나만 있습니다. 끊임없는. 이 단일 빈은 ICover(1)을 호출하여 도달할 수 있습니다. . Boolean 표현식을 정수 1로 변환하여 커버리지 포인트에 적중 또는 누락을 등록할 수 있습니다. 또는 0 to_integer 사용 기능
커버리지 데이터가 기록된 후 IsCovered을 호출하여 모든 커버리지 목표가 충족되었는지 확인합니다. 모든 빈에서 기능합니다. 그런 다음 모든 적용 범위 목표가 충족되면 루프를 종료합니다.
테스트를 종료하기 전에 DUT가 비어 있는지 확인합니다. 이를 달성하기 위해 우리는 wr_en '0'에 신호 및 rd_en '1'에 신호 .
마지막으로 WriteBin를 호출하여 각 커버리지 목표가 달성된 횟수에 대한 통계를 출력합니다. 각 커버리지 빈에 대한 기능. finish 프로세스 마지막에 키워드를 입력하면 시뮬레이터가 시뮬레이션을 중지합니다.
아래 양식을 사용하여 모든 VHDL 파일이 포함된 전체 ModelSim 프로젝트를 다운로드할 수 있습니다.
Zip에 포함된 do-file을 실행하여 프로젝트를 로드한 후 ModelSim 콘솔에 «runtb»를 입력하기만 하면 테스트벤치를 실행할 수 있습니다. 커버리지 목표가 무작위로 적중되기 때문에 테스트벤치의 실행 시간은 무작위입니다. 그러나 실제로 사용되는 의사 난수 시퀀스이기 때문에 테스트 결과를 재현할 수 있습니다.
코드에서 시드를 초기화하지 않았습니다. 즉, 기본 시드 값이 의사 난수 생성기에 사용됩니다. InitSeed를 호출하여 다른 시드를 설정할 수 있습니다. RandomPType의 절차 개체, 이것은 다른 임의의 시퀀스를 생성합니다.
«runtb» 명령을 제공한 후 ModelSim 콘솔에 인쇄된 출력은 아래와 같습니다. 시뮬레이션이 실행되는 동안 테스트벤치 FIFO에 무작위로 푸시하거나 터지는 경우가 많습니다.
VSIM 2> runtb # ** Warning: Design size of 15929 statements or 2 leaf instances exceeds # ModelSim PE Student Edition recommended capacity. # Expect performance to be quite adversely affected. # ** Note: Push 34910 # Time: 790 ns Iteration: 0 Instance: /ring_buffer_tb ... # ** Note: Pop 37937 # Time: 83100 ns Iteration: 0 Instance: /ring_buffer_tb # ** Note: Pop 13898 # Time: 83110 ns Iteration: 0 Instance: /ring_buffer_tb # %% WriteBin: # %% Write while empty Bin:(1) Count = 2 AtLeast = 1 # # %% WriteBin: # %% Read while full Bin:(1) Count = 3 AtLeast = 1 # # %% WriteBin: # %% Read and write while almost empty Bin:(1) Count = 106 AtLeast = 1 # # %% WriteBin: # %% Read and write while almost full Bin:(1) Count = 1 AtLeast = 1 # # %% WriteBin: # %% Read without write when almost empty Bin:(1) Count = 1 AtLeast = 1 # # %% WriteBin: # %% Write without read when almost full Bin:(1) Count = 3 AtLeast = 1 # # Break in Process PROC_SEQUENCER at C:/crv/ring_buffer_tb.vhd line 127
모든 적용 범위 목표가 충족되면 모든 적용 범위 빈에 대한 통계가 인쇄됩니다. 일부 빈은 한 번만 적중된 반면 하나는 106번 적중되었습니다. 그러나 결국 각 빈은 적어도 한 번은 적중되었습니다. 따라서 적용 범위를 정의한 모든 이벤트가 테스트 및 검증되었음을 알 수 있습니다.
테스트벤치가 수행한 작업에 대한 아이디어를 얻기 위해 파형을 살펴보겠습니다. 아래 이미지는 fill_count가 있는 파형을 보여줍니다. 아날로그 값으로 표시되는 신호. FIFO는 이 신호에 대한 트레이스가 상단에 있을 때 가득 차고 하단에 있을 때 비어 있습니다.
파형에서 볼 수 있듯이 링 버퍼는 임의로 채워지고 비워집니다. 그러나 우리는 채우기 수준에서 이러한 경사와 감소를 명시적으로 프로그래밍하지 않았습니다. 그럼에도 불구하고 우리는 DUT와 상호작용하는 유기적인 패턴을 보고 있습니다.
제한된 무작위 검증은 테스트 벡터가 완전한 테스트를 실행하기에 너무 많은 순열을 가질 때 좋은 테스트벤치 전략입니다. 무작위 상호 작용은 정확성을 희생하지 않으면서 방향 코너 케이스 테스트보다 더 자연스러운 동작을 나타냅니다.
커버리지 데이터 수집을 올바르게 설정하기만 하면 모든 코너 케이스가 충족되었음을 확신할 수 있습니다. 추가 이점은 무작위 테스트가 특별히 테스트하지 않는 DUT의 약점을 노출할 가능성이 더 높다는 것입니다. 모든 코너 케이스를 알고 있는 한, 이에 대한 지시 테스트를 생성할 수 있습니다. 그러나 코너 케이스는 쉽게 간과되며, 이때 제한된 무작위 검증 방법론의 이점을 얻을 수 있습니다.
이 기사는 제한된 무작위 검증으로 수행할 수 있는 작업의 표면만 긁었습니다. 주제에 대해 더 자세히 알아보려면 OSVVM GitHub 페이지에서 문서를 읽는 것이 좋습니다.
나는 또한 내가 제휴하지 않은 SynthWorks의 Advanced VHDL Testbenchs and Verification 과정을 추천합니다. 그러나 나는 이 물리 과정의 5일 버전에 참석했습니다. 이 과정은 VHDL 분석 및 표준화 그룹(VASG) 의장인 Jim Lewis가 진행합니다. 전반적으로 VHDL 테스트벤치를 한 단계 끌어올리고자 하는 모든 회사에 큰 투자입니다.
VHDL
오늘날 빠르게 변화하는 산업 및 소비재 제품에서 집적 회로(IC) 설계 회사는 경쟁력 있는 성공을 유지하거나 획득하는 데 일정보다 빨리 또는 미리 설계를 출시하는 것이 중요하다는 것을 알고 있습니다. 그러나 그들은 또한 시장에 출시된 후 제품의 성능이 똑같이 중요하다는 것을 알고 있습니다. 제품을 시장에 내놓는 것은 광고에서 약속한 성능이나 제품 수명을 제공하지 못하는 것뿐입니다. 이는 기업이 결코 갖고 싶지 않은 악몽입니다. 이러한 이유로 신뢰성 검증은 이제 IC 설계 및 검증 흐름의 필수적인 부분이 되었습니다. ESD(정전기
제조 엔지니어링: 귀사는 최근 Vericut을 위한 새로운 적층 제조 모듈을 출시했습니다. 이 버전에서 추가 기능의 새로운 기능은 무엇입니까? 진 그라나타: Vericut 8.1에는 모든 브랜드의 NC 기계에서 순서에 상관없이 사용되는 적층 및 하이브리드 가공 프로세스를 시뮬레이션하는 새로운 적층 제조[AM] 모듈이 포함되어 있습니다. AM은 성숙 단계에 도달했으며 제조 전략에 가치 있는 추가 요소로 입증되었습니다. Vericut은 오랫동안 모든 유형의 기존 가공을 시뮬레이션하는 것으로 알려져 있으며, 적층 모듈은 재료 증착을 정