어느새 Testbench 연재 3번째 포스팅이다. 크게 생각해보면, 아래 3가지 정도 내용이 더 남았고 Random configuration Reference model Monitor & Scoreboard Test case나 coverage, 그리고 regression 환경(Tcl, Script 등)은 일단 뒤로 미루어 두려고 한다. DUT에 맞게 stimulus를 넣어주는 부분을 소개하자니, 어플리케이션에 따라 천차만별일 것이라는 생각이 들었다. CPU, AP처럼 OP code와 Bus 입력 등이 필요할 수도 있고, display, sensor처럼 영상 바탕의 입력이 요구될 수도 있다. 여기서는 간단히 특정 프로토콜에 맞춰서 영상 스트림을 뒤로 출력하는 image driver를 구현해 보았다. 대부분..
Testbench의 기본이란 무엇일까? 검증하고자 하는 target에 spec에 맞는 입력을 제대로 넣어줄 수 있어야 한다. 랜덤 한 입력을 넣어주게 되지만, 검증력을 높이기 위해서는 적절한 constraints를 설정하여, 유의미한 값들이 생성되어야 한다. 검증 환경의 구현에 대해 이야기해보자면, 말마따나 정답이 없는 세계라고 할 수 있다. 검증 엔지니어의 취향이나 본인만의 신념대로 환경이 꾸려지기 때문에 같은 IP를 검증한다 해도 다양한 형태의 testbench가 가능하다. 어떤 것이 효율적인가에 대한 물음은 항상 검증 엔지니어들을 따라다니는 숙제이다. 좋은 검증 환경이란 유연하고 확장성이 좋아야하며, 재사용성도 보장되어야 한다. 그리고 언제나 검증에 있어서 빠른 처리 시간의 충족이라는 현실적인 문제..
Verilog를 사용해본 유저들이라면, SystemVerilog가 생소하지는 않을 것이다. SystemVerilog는 설계를 위해 사용되는 언어라기보다는 검증에 최적화되어 있다. 오로지 설계를 위해서라면, Verilog2001까지의 문법만으로도 대부분의 logic을 구현하기에 전혀 무리가 없다. 그러나 검증의 세계에 첫발을 디디면 완전히 새로운 세상이 펼쳐진다. Verilog라는 단일 언어로는 복잡한 logic을 효율적으로 검증하기에는 한계가 있다. 특히 Verilog로 OOP(객체지향) 관점에서의 Testbench를 꾸미기에는 무리가 있으며, 이를 위해서 탄생한 것이 오늘 소개할 SystemVerilog이다. 일단, 본인은 logic 검증 엔지니어가 아님을 밝혀두는 바이다. 솔직히 말해 IP 설계자로서..