SystemVerilog

 SystemVerilog는 검증에 최적화되어 있는 언어이다. 설계만을 위해서라면 Verilog로 충분하지만 복잡한 로직을 효율적으로 검증하기에는 부족하다. Verilog로 OOP 관점의 TestBench를 설계하기에는 한계가 있으며 이를 위해 개발된 것이 SystemVerilog이다.

 

 앞으로 chipverify에 있는 관련 내용들을 보며 천천히 글을 작성해보고자 한다. 영어가 짧은 관계로 틀릴수도 있지만 앞으로 틀린부분은 수정하며 진행하고자 한다.

 

SytemVerilog TestBench

Component	Description
Generator	DUT를 구동하기 위한 입력 신호 생성 클래스
Interface	DUT를 구동하거나 모니터링 할 수 있는 신호를 포함하고 있는 클래스
Driver	DUT를 위해 생성된 입력 신호를 구동하는 클래스
Monitor	DUT의 입력 출력 동작을 모니터링하고 캡쳐하는 클래스
Scoreboard	기대되는 출력을 점검하는 클래스
Environment	위에서 언급한 모든 컴포넌트들을 포함하는 클래스
Test	다른 설정으로 수정될수 있는 환경을 포함하는 클래스

 

  Interface

 만약 설계하고자 하는 디자인이 수백개의 신호를 포함하고 있다면 신호간의 연결 관리면에서 복잡하고 재사용하기도 힘들것이다. 대신 모든 입/출력을 하나의 컨테이너안에 정리함으로써 이것이 해결될수 있으며 그것이 Interface이다. 디자인의 신호들은 Interface를 통하여 관리될수 있다.

 

  Driver

 드라이버는 입력신호를 구동해야 할 때 Interface안에 미리 정의된 task를 신호들의 타이밍에 상관없이 call 할 수 있어야 한다. task 안에 정의되어 있는 타이밍 정보들은 Interface에 의해 제공된다. 이러한 개념은 TestBench를 유연하고 확장 가능하도록하는 추상화 수준의 작업이다. 만약 추후에 Interface가 변경된다면 새로운 Driver가 기존의 task를 call 할 수 있으며 다른 방법으로 신호들을 전송할 수 있다.

 

  Generator

 Generator는 유효한 데이터 트랜잭션을 생성하고 드라이버로 전송할 수 있는 검증 컴포넌트이다. Driver는 간단하게 Generator에 의해 생성된 데이터를 Interface로 전송할 수 있다. 데이터 트랜잭션은 Class objects로써 위 그림의 파란색 박스들로 나타내어져있다. Driver가 하는일은 데이터 객체를 받고 DUT가 이해할 수 있도록 변경하는 것이다.

 

  Monitor

 위에서 지금까지 데이터가 어떻게 DUT에 전송되는지에 대해 알아보았다. 그러나 이것들은 모든일에 절반정도에 해당하며 우리의 주된 목적은 디자인을 검증하는것이다. DUT는 입력 데이터를 처리하고 결과를 출력으로 보낸다. Monitor는 처리된 데이터를 객체로 전환시키고 Scoreboard로 전송한다.

 

  Scoreboard

 Scoreboard 참조 모델을 가질수 있으며 참조 모델은 DUT와 같은 방식으로 구동된다. DUT로 보내어진 입력은 참조 모델로도 보내어진다. 그래서 만약 DUT의 어떤 기능에 문제가 생기면 DUT의 출력은 참조모델의 출력과 다른 값을 가지게 되며 DUT와 참조 모델 출력 비교를 통하여 우리에게 DUT의 기능에 문제가 생겼음을 알려주게 된다. 이것이 주로 Scoreboard가 수행하는 역할이다.

 

  Environment

 Environment는 검증을 더욱 유연하고 확장가능하도록 만들어준다. 왜냐하면 추 후 프로젝트에 더 많은 컴포넌트들이 같은 Environment에 연결될 수 있기 때문이다. 

 

  Test

 Test는 Environment의 객체를 인스턴스화하고 테스트 하고자 하는 방향으로 구성된다. 우리는 아마도 수백개의 테스트를 해야 할 것이고 그 테스트들의 각각 테스트를 위한 환경을 직접적으로 구성 및 변경하는 것은 불가능하다. 대신 우리는 각각의 테스트 환경에서 수정이 가능한 확실한 파라미터들을 필요로 할 것이다. 이러한 방법의 테스트는 신호 생성에 있어 더욱 안전하고 효과적일 것이다. 

 

 우리가 알고 있는 간단한 테스트벤치들은 실제의 프로젝트에서는 더 높은 수준의 추상화에서 다양한 작업을 수행하기 위하여 그러한 요소들이 더욱 많이 연결될 것이다. 만약 우리가 간단한 50을 카운트하는 카운터를 검증해야 한다면 간단한 테스트벤치로 가능 할 것이다. 하지만, 더욱 복잡해진다면 그것들을 제어하기 위한 더 높은 추상화 작업이 필요 할 것이다.