1.2 SystemVerilog의 특징
SystemVerilog의 특징은 크게 OOP(Object-Oriented Programming), Random Stimulus, Coverage-Driven 3가지로 볼 수 있다.
OOP(Object-Oriented Programming, 객체지향 프로그래밍)
OOP는 소프트웨어 엔지니어들이 고수준의 시스템 레벨 어플리케이션을 개발하기 위해 사용하는 방법론이다. 이것은 대부분의 RTL 설계 엔지니어들이 SystemVerilog에 입문하고 처음으로 좌절을 맛보는 가장 큰 이유가 된다. 하지만, OOP는 SystemVerilog를 강력한 검증 언어로 만드는 일등 공신이며, Testbench를 효율적으로 구축하기 위해서 반드시 알아야 하는 개념이다.
OOP는 컴퓨터 프로그램을 명령어의 나열로 보는 것이 아닌, 여러 개의 독립된 단위, 즉 객체(Object)로 보는 것이다. 객체는 실제 사물을 프로그램으로 가져와 모델링하는 것으로 속성(Property)과 행위(Method)가 있다. 속성은 객체의 상태, 성질 등을 의미하고, 행위는 기능이나 연산을 의미한다.
클래스(Class)는 객체를 만들어내기 위한 설계도, 틀이다. 흔히 붕어빵 틀을 클래스, 붕어빵을 객체로 비유한다.
OOP의 특징은 추상화(Abstraction), 캡슐화(Encapsulation), 상속성(Inheritance), 다형성(Polymorphism)이 있다.
(1) 추상화: 어떠한 존재가 가지고 있는 가장 특징적인 속성을 파악해가는 것. 공통적 특성을 묶는 것.
(2) 캡슐화: 객체의 속성(data fields)과 행위(methods)를 하나로 묶고, 내부 로직을 외부로부터 감추는 것.
(3) 상속성: 하위 클래스가 상위 클래스의 속성을 물려받아 확장하는 것.
(4) 다형성: 각각의 객체에서 같은 함수에 대해 다른 동작을 하는 것.
여기서 OOP의 자세한 내용을 설명하기엔 무리가 있다. SystemVerilog는 Java의 특성을 가진 언어이기 때문에 OOP의 특징을 가진다. 언뜻 보면 왜 필요한지 이해가 안 될 것이다. 하지만 Code의 재사용(Reusability)과 유지보수를 위해서 꼭 사용해야 하는 방법론이다.
OOP의 특징들을 모두 반영하고 있는 것이 바로 클래스이다. 클래스의 개념은 앞에서 설명했다. 실제로 코드 상에서 클래스는 사용자가 정의하는 데이터 타입이다. 기본적으로 데이터 타입은 데이터의 성질을 의미한다. 예를 들어, C에서 int는 정수형 데이터 타입이고, float은 실수형 데이터 타입이다. 클래스는 다른 데이터 타입들의 집합이 될 수 있으며, 함수 또한 포함할 수 있다.
클래스가 포함하는 데이터형 들의 집합을 멤버 변수(속성)라고 하며, 함수를 멤버 메서드(행위, 동작)라고 한다. 생성자는 클래스로부터 객체가 생성될 때 객체의 초기화 과정을 기술하는 특수한 메소드이며 객체가 생성될 때 무조건 수행된다.
다음 클래스 예제를 통해 감을 익혀보자.
[그림9] 코드에는 하나의 클래스와 하나의 모듈이 기술되어 있다. 먼저 클래스는 멤버 변수로 int형 데이터 타입의 x를 가지고 있고, 멤버 메서드로 task와 function이 있다.
task는 입력되는 i 값을 x에 대입하는 동작을 한다.
function은 x를 반환하는 동작을 한다.
시뮬레이션 결과
class_1 :: Value of x = 10
class_2 :: Value of x = 20
Random Stimulus
SystemVerilog의 두번째 특징은 Random Stimulus이다. 쉽게 말해, 대부분의 소프트웨어 언어에서 제공하는 랜덤 함수를 의미한다. 무작위로 생성한 Random Test Vector는 설계된 IP의 많은 Case를 검증하는 것을 가능케한다.
Verilog에서 제공하던 랜덤 함수를 포함하여 SystemVerilog에서는 다양한 랜덤 함수를 제공한다.
Coverage-Driven
마지막으로 SystemVerilog에서 가장 중요한 특징 중 하나인 Coverage이다. SystemVerilog에서 말하는 Coverage는 시뮬레이터가 제공하는 Code Coverage와는 다른 의미이다.
Code Coverage는 Testbench에서 생성된 테스트 시나리오에서 얼마나 많은 디자인 코드가 실행되는지 수치적으로 보여준다. Code Coverage의 한계는 설계의 모든 의도된 기능이 검증되고 있는지 여부를 알 수 없고, 작성된 디자인 코드가 완전히 실행되었는지 여부만 알려준다. 다시 말해, Code Coverage는 100%이더라도 설계자가 의도한대로 기능이 수행할 것인지는 알 수 없다.
SystemVerilog에서 Coverage는 바로 Functional Coverage이다. Testbench 또는 검증 환경에서 얼마나 많은 설계 기능이 실행(커버)되었는지 알려주는 지표이다.
예를 들어, 2개의 1bit 값을 연산하는 adder가 있다. 이 adder가 수행할 수 있는 모든 경우의 수는 0 + 0, 0 + 1, 1 + 0, 1 + 1로 총 4가지이다. 기능적으로, 4개의 경우의 수를 모두 확인했다면 Functional Coverage는 100%가 된다.
실제로 우리가 설계하는 IP는 매우 복잡하기 때문에, IP에서 발생하는 모든 경우의 수를 확인하는 것은 사실상 불가능하다. 설계자가 Verification Plan을 적절히 세우고, Coverage Point로 조건을 설정하여 최종 Functional Coverage가 몇 퍼센트가 넘으면 될지 정해야 한다. 이 과정은 온전히 설계자의 몫이 된다.
시뮬레이션 중에 Cover Point의 특정 조건이 충족되면 해당 Bin(조건)이 커버되고 검증 진행 상황을 측정할 수 있다. 하나의 Coverage Group에서 Cover Point 수를 캡처할 수 있으며, Cover Group 수의 모음을 일반적으로 Functional Coverage Model이라고 한다.
'VLSI > Verification' 카테고리의 다른 글
| [SystemVerilog] 1.1 SystemVerilog란? (0) | 2023.10.22 |
|---|
댓글