[Digital 회로 설계] SystemVerilog로 Testbench 설계하기 1편

 

Verilog를 사용해본 유저들이라면, SystemVerilog가 생소하지는 않을 것이다. SystemVerilog는 설계를 위해 사용되는 언어라기보다는 검증에 최적화되어 있다. 오로지 설계를 위해서라면, Verilog2001까지의 문법만으로도 대부분의 logic을 구현하기에 전혀 무리가 없다. 그러나 검증의 세계에 첫발을 디디면 완전히 새로운 세상이 펼쳐진다. Verilog라는 단일 언어로는 복잡한 logic을 효율적으로 검증하기에는 한계가 있다. 특히 Verilog로 OOP(객체지향) 관점에서의 Testbench를 꾸미기에는 무리가 있으며, 이를 위해서 탄생한 것이 오늘 소개할 SystemVerilog이다.

 

일단, 본인은 logic 검증 엔지니어가 아님을 밝혀두는 바이다.

 

솔직히 말해 IP 설계자로서 스스로 만든 block을 검증하기 위해 이 코드 저 코드 끌어다 쓴 경험만 있다. 이번 기회를 통해 여러 기술지나 논문을 통해 배운 내용을 함께 공유하고, 직접 SystemVerilog를 사용해서 간단한 Testbench를 꾸며보는 것을 목표로 할 것이다. 

 

 

 

모로 가도 서울로 가면 된다? 나는 아니라고 생각한다. 언어를 제대로 알려면 먼저 그 역사를 살펴보라고 했다. 자칫 딱딱해질 우려가 있으니, 여기서는 간략히 알아보고 넘어가자.

 

- 2002년. Accelera에 기부된 Superlog와 2005년에 Synopsys의 OpenVera 언어를 기반으로 발전 (SystemVerilog 3.0)

- 2003년. SystemVerilog 3.1 release

- 2005년. IEEE 표준 1800-2005로 공식 채택

 

처음부터 SystemVerilog라는 언어가 온전했던 것은 아니었고, 여러 검증 언어들이 춘추전국시대처럼 혼재했었던 시절이 있었다. 나도 그 시대의 사람이 아니기 때문에, 다만 풍문으로 들었을 뿐이다. Superlog, OpenVera, Specman E 등은 말로만 들었지, 나의 짧은 설계 경험 가운데 단 한 번도 실제로 본 적은 없다.

 

이제는 구시대의 유물이 된 specman E

 

어차피 약육강식의 논리에 따라, 강자 아래서 무림은 평정되기 마련이다. 그것이 강호의 세계인 법. 암, 그렇고말고. SystemVerilog가 IEEE 표준으로 채택됨에 따라, 수많은 검증 언어들은 자취를 감추게 되었다.

 

 

 

1. 객체 지향(Object-Oriented Programming, 이하 OOP)

 

SystemVerilog를 강력한 검증 언어로 만드는 일등 공신이자, 대부분의 설계 엔지니어들이 SystemVerilog의 문턱을 넘지 못하는 가장 큰 이유이다. 특히 높은 추상화 수준의 시스템 레벨 검증을 하기 위해서는 이 객체 지향이라는 개념이 빠질 수 없다. 이 개념은 소프트웨어 쪽에서 발전된 것이므로, 관련된 학습을 하지 않은 하드웨어 엔지니어에게는 다소 생소할 수 있다.

 

객체(Object)

: 실존하거나 생각할 수 있는 대상을 객체(object)라고 한다.

 

일단 이 개념을 이해하기가 어려운 것은 객체라는 말 자체가 한국어로도 너무 애매모호하기 때문이다. 예를 들어 설명하기 위해 우리 집 뽀삐와 옆집 땡칠이의 사례를 가져왔다. 이름에서도 유추할 수 있듯이, 뽀삐와 땡칠이는 개(dog) 이름이다. 이 '개'라는 특성을 가지는 집단을 하나의 class로 모으고, 여러 특성을 정의해보자. 

 

1) 짖기

2) 꼬리 흔들기

3) 물기

...

 

우리 집 뽀삐도 개(dog)라는 특성을 가진 객체(object)이며, 옆 집 땡칠이도 마찬가지로 개(dog)의 특성을 갖는 하나의 객체(object)이다. 즉 class를 instance(실체)화 한 것이 객체(object)이다. SystemVerilog에서는 검증을 위한 여러 기능들을 class를 통해 정의하고 instance로 사용할 수 있다. 이는 reusability 측면에서 SV가 갖는 상당히 유용한 특징이다.

 

초심자들이 간단히 이해하기에는 조금 어려운 내용이니, 대략적으로 감만 잡고 넘어가자.

 

아래 코드는 https://www.verificationguide.com/p/systemverilog-classes.html에서 가져온 class example이다. sv_class라는 이름의 class를 정의하고, integer 값을 x라는 변수에 담는 task와 담긴 x를 반환하는 function을 구현했다. 아래 module을 보면, class_1, class_2라는 객체가 선언된 것을 확인할 수 있으며, 각각의 객체들은 class의 메소드인 set()과 get()을 사용할 수 있다는 것을 알 수 있다. 

 

class sv_class;
  //class properties
  int x;
 
  //method-1
  task set(int i);
    x = i;
  endtask
 
  //method-2
  function int get();
    return x;
  endfunction
endclass
 
module sv_class_ex;
 sv_class class_1; //Creating Handle
 
  initial begin
    sv_class class_2 = new(); //Creating handle and Object
    class_1 = new(); //Creating Object for the Handle
 
    //Accessing Class methods
    class_1.set(10);
    class_2.set(20);
    $display("\tclass_1 :: Value of x = %0d",class_1.get());
    $display("\tclass_2 :: Value of x = %0d",class_2.get());
  end
endmodule

아마도 simulation 결과는 아래와 같을 것이다.

 

class_1 :: Value of x = 10
class_1 :: Value of x = 20

 

2. 인터페이스, 사용자 정의 data type, 연산자 오버로딩 등의 C-like 한 문법들 지원
3. Assertion과 random stimulus, coverage 등의 지원

하나의 포스팅에 SV의 모든 특징을 설명하는 것은 불가능한 일이다. 오늘은 간단히 이러이러한 기능을 지원한다는 것만 명기하고, 차후에 직접 Testbench를 같이 꾸며보면서 자세한 내용을 설명하려 한다. 이 포스팅도 상당히 긴 연작으로 진행될 것 같다는 느낌이 드는 것은 기분 탓일까?

 

 

 

학부 시절에 실습하면서 사용했던 순차적으로 입력을 전달하는 형태의 Testbench로는 복잡한 block을 검증하기에는 무리가 있다. 그래서, 검증에 특화된 SystemVerilog의 장점을 최대한 살리면서, 재사용이 가능하도록 검증 환경을 꾸미려고 한다. 물론, 내가 선택한 방법이 정답이라는 것은 아니다. 검증하는 사람의 철학(?)에 따라, 얼마든지 형태는 변할 수 있으며 여기서는 최대한 간단한 구성으로 만들고자 한다.

 

 

간단한 Testbench의 block diagram. 최소한의 구성으로 random regression이 가능한 형태이다.

 

Testbench는 내가 검증하고자 하는 design의 입력을 만들어줘야 하며, reference model과 동일하게 동작하는지 출력을 체크하는 부분으로 이루어져 있다. 보통 reference model은 C 알고리즘으로 구현되는 것이 일반적이다. 동작 시나리오를 기반으로 test case의 constraint를 만들고 그 안에서 무작위(random) 입력을 C와 RTL에 넣어준다. 이를 scoreboard에서 체크하여, RTL이 알고리즘과 동일하게 구현되었는지 정합성을 검사한다. IP의 모든 부분이 구석구석 터치되었는지 확인하기 위해 coverage를 체크하는 부분도 빠져서는 안 된다. 

 

참 쉽죠...?

 

희대의 사기꾼 밥로스 옹. 안 쉬워요. 하나도 안 쉽다고요...

 

오늘은 간단히 SystemVerilog에 대해서 알아보고, 우리가 앞으로 만들 Testbench의 구성에 대해서 알아보았다. 나는 설계자가 본인의 IP를 검증할 수 없다면, 그건 반쪽짜리 설계자라고 생각한다. 실력 있는 설계자가 되기 위해서는 검증에 까막눈이 되어서는 안 된다. 서두에도 밝혔듯이 SystemVerilog는 매우 강력한 검증용 언어이다. SystemVerilog를 익히고 스스로 IP를 검증할 수 있는 힘을 길러, TAT(Turn Around Time)도 줄이고 검증 엔지니어에게도 인정받는 설계자가 되기를 희망한다. 나도 그리고 이 글을 읽는 여러분도 전천후 설계자가 되기를 소원하며 이만 글을 줄인다. 다음 포스팅에서는 clock과 reset generator를 포함한 driver 관련 내용을 업로드할 예정이다. 

 

To be continued!