작성
·
14
1
섹션 2 SystemVerilog Testbench 구조 살펴보기 중 program 개념 설명에 질문이 있어 질문 드립니다
그림에서는 DUT <-> interface <-> program 으로 구성이 되어 있는데
Verilog Testbench 구조와 비교를 해보게 된다면 program 의 역할은 Verilog 의 top module 의 역할이라고 볼 수 있을까요?
아니면, top module 이 DUT, interace, program 을 모두 감싸는 wrapper 역할을 하고, program 은 tb 안의 oop component 들을 감싸는 top hierarchy 역할을 하는건가요?
가끔 SystemVerilog 예제들을 보면 program 을 사용 않고 module 을 top hierarchy 로 쓰는 경우가 왕왕 있는데, program 사용시 TB 와 Design 사이의 상호작용에서 race condition 제거는 이제 실제 제조 과정(SDC?) 에서 야기될 수 있는 문제를 방지해주는건가요?
궁금한게 많네요ㅜㅜ 답변 감사합니다! 강의 잘 듣고 있습니다!
답변 2
0
0
원숭이 알러지 바나나님,
수강해 주시고 질문도 주셔서 감사합니다.
SystemVerilog의 program 블록은 testbench 동작을 정의하는 블록으로, Verilog에서의 top module과 동일한 역할을 하는것은 아닙니다.
Verilog에서는 일반적으로 top module이 Design과 testbench의 모든 구성요소를 포함하는 최상위 계층으로 동작합니다. 즉, stimulus generation, DUT instance, simulation test run의 구동점이 모두 하나의 모듈, 최상위 top module 내부에 작성되게 됩니다.
이 구조에서는 testbench와 DUT가 같은 simulation time slot 내에서 실행되기 때문에, signal 업데이트나 event scheduling 과정에서 race condition이 발생할 수 있습니다.
SystemVerilog의 program 블록은 이러한 문제를 해결하기 위해 도입된 개념입니다.
Program은 testbench의 procedural part를 감싸는 최상위 컨테이너 역할을 합니다.
Program은 DUT와 같은 시간 단계에서 신호를 업데이트하지 않도록 scheduler 상에서 별도의 region에서 실행됩니다. 즉, program 블록은 testbench가 DUT의 신호를 읽을 때 이미 안정된 값을 받게 됩니다. 이로 인해 race condition이 자연스럽게 제거됩니다.
따라서 program은 DUT와 testbench 간의 타이밍 독립성을 보장하기 위한 상위 procedural 컨테이너 블록이라고 보는 것이 정확합니다.
또한 program을 사용하지 않고 단순히 module로 testbench를 구성할 수도 있지만, 이 경우 scheduler 상에서 DUT와 동일한 region에 위치하게 되므로 race condition 발생 가능성을 완전히 배제할 수 없습니다.
실제 프로젝트에서는 대부분 class-based testbench(OOP 구조)를 사용하면서 interface와`program을 함께 구성하고, tool vendor의 권장 가이드에서도 program 블록 사용을 권장하는 이유가 바로 이 race-free 동작에 있습니다.
하지만 이러한 개념은 EDA tool 회사마다 가이드가 조금씩 다릅니다. Race condition 유발에 크게 영향이 없다는 주장도 있고 해서, 현재 program 을 쓰는 경우와 안 쓰는 경우가 혼재되어 사용되고 있습니다. 사용자가 경우에 맞게 적용해서 사용하시면 됩니다.
그리고, program block 에는 interface 와 module 을 instance 할 수 없기 때문에 완전한 top container 로 사용은 할 수 없지만, procedural block 들과 oop test 용으로 사용할 때는 내부에 module instance 가 없고, interface instance 가 없다면 top container 로 simulator 에 입력으로 줄 수도 있습니다.
마지막으로, program의 사용은 SDC나 실제 제조 단계의 timing constraint 와는 관련이 없는 개념 입니다. 이는 RTL 설계의 timing synthesis 과정이 아닌 simulation 단계에서의 event scheduling 레벨의 race 방지이기 때문입니다.
답변이 되었는지요?