Verification

약간 정신이 없는 상태에서 일을 했더니만 결국은 삽질로 빠지는 경우가 많습니다. 오늘의 삽질은 perl 에서 ord의 사용에 관한 것이지요. 그 동안 compiler에 의하여 생성된 elf 파일을 objcopy utility로 binary file을 생성하고, 이걸 perl에서 $hexval = ord(getc(INHANDLE)); 과 같은 방법으로 verilog HDL에서 읽을 수 있는 파일 형식(readmemh()를 이용하는 거죠..)으로 변경해서 사용해 왔는데, 오늘 갑자기 이걸 sub routine으로 만들고 돌렸더니만 값이 이상하더군요.

VMM에 맞은 편에 존재하던 mentor의 AVM이 있었습니다만, 무게감이 떨어지는 듯 했었지요. 얼마전에 Cadence와 Mentor가 같이 OVM을 위하여 작업을 한다는 이야기가 솔솔 흘러나왔고, Synopsys의 합류를 권장했지만 거절당했다는 이야기도 있었지요. 그 OVM이 공개되었군요.. (언제 공개된거지?) 음.. 뉴스란을 보니 얼마되지는 않은것 같습니다만.

예전에 PLI에서 윈도우 제어 하려고 별짓을 다했었는데, 그 중에 PLI에서 TK 윈도우를 바로 부른 것도 있었습니다. PLI에서 TK를 부르는(C-TK interwork을 이용한) 방법은 TK 스크립을 거의 직접 쓸 수 있다는 점에서 편리하긴 한데, NCVerilog에서 너무 버전을 심하게 탄다는 단점(TK의 버전도 맞춰 줘야 합니다. -_-;)이 있어서 환경이 바뀌면서 잘 안쓰게 되더군요.

OVL(Open Verification Library)은 상당히 오래전부터 보아왔던 assertion library인데요. 제 기억이 맞다면 거의 최초의 ABV (assertion -based verification)쪽 라이브러리가 아닌가 기억됩니다. Foster라는 분이 박사 논문으로 작성한 것이, 발전을 거듭해서 ABV라는 것까지 발전한 것으로 기억되는데, 정확한 사실인지는 찾아보지 않고 기억에 의존한 것이라 틀릴 수도 있습니다. 여하튼 OVL의 출발은 상당히 오래된 거죠 ^^;

별 다른 내용은 아닙니다만, 기억해두기 위해서 적습니다. JTAG을 이용한 디버거를 만들고, PC상에서 테스트 하는데 소프트웨어 팀에서 만든 비주얼 스튜디오 기반의 프로그램은 제가 고칠수가 없어서(VS 라이센스가 한정되어 있다보니..), cygwin상에서 간단하게 제어하는 프로그램을 만들게 되었습니다. 제가 알기로는 linux의 경우 /port/prn 을 이용해서 간단하게 printer port를 제어할 수 있었던 것으로 기억합니다만(물론, permio같은 것을 써야 겠습니다만..), cygwin에서는 이 방법은 안되더군요.

연일 30도를 넘나드는 더위가 계속되고 있습니다. 이럴때 항상 문제가 되는 것이 집중력이 떨어진다는 건데요.. 저도 마찬가지 입니다. (실은 개인적으로 좋은 일이 생겨서 그럴지도 모르겠습니다만 ^^;) 오늘만해도 gcc-MinGW에서 mti vpi 연결시키는 거 때문에 잠깐 modelsim userguide를 보다가, 딴짓을 하기 시작해서 대략한 5시간동안 딴짓을 했습니다.

Automated Functional Verification 방법에는 여러 가지가 있지만, testvector 발생 유닛(보통 Directed Random방식을 사용하지요?)과 golden model을 이용한 checker model을 만들어서 DUV(Design Under Verification)의 결과와 비교하는 것이 가장 편한 방법 중에 하나임은 부정할 수 없습니다. (여담입니다만, 국내에서는 많은 경우 golden model없이 설계하는 경우가 많아서 검증을 위하여 작성한 golden model이 실제로 RTL보다도 정확성이 떨어지는 경우가 있다는 것이 문제가 종종 발생합니다. 여기서는 golden모델의 확보에 대한 이야기는 나중으로 미루죠.) 보통 golden model은 C model을 이용하게 되는데, C 모델을 Verilog와 동시에 simulation하는 것은 그리 녹녹한 일이 아닙니다.

뭐랄까요.. 요즘 이런 저런 일로 바쁘다보니, 사람이 좀 얇팍하게 글을 쓰게되네요. 🙂 (퇴고 없이 그냥 온라인에서 쓰는 글이라 앞뒤가 없을지도 모르겠습니다.) 오늘은 여러분들께서 perl을 이용해서 Verilog HDL을 위한 testbench를 작성할 때 간단히 명령어 해석기를 만들어 사용하는 방법을 알려드리죠. 이 방법은 제가 JTAG을 위한 protocol을 만들다가 생각해낸 방법인데요.. 아주 유용하게 쓰고 있습니다. 얼마전 AXI FileReader와 같은 간단한 명령어 해석기가 필요할 때도 쉽게 적용할 수 있구요.

사실 검증이란 걸 처음 시작하면 정신이 아득해집니다. 도대체 뭘 어떻게 검증해야 하며, 언제 끝을 내야지만 하는가.. 이런 부분에 대한 교육이 부족했기 때문이겠지요 그래서, 이런걸 체계적으로 정리하자는 것이 “검증 계획(verification plan)”입니다. 설계 계획에 해당하는 spec. 작업이 설계에 있어서 가장 중요하듯, 검증에 있어서도 spec과 더불어 검증 계획이 중요합니다. 좀더 세분화된 검증 계획이 나중에 경험하게 될 인간 좀비가 될 시간을 줄여주는 거죠.

검증에 있어서 고려되어야 하는 사항중에 하나는 “언제 검증을 그만 둘 것인가”입니다. 너무나도 쉬운 질문이지요? 뭐, 검증할 부분을 다하면 검증을 그만 두면 되죠. 그럼 질문을 바꿔보겠습니다. “검증할 부분에 대하여 모두 검증했는지는 어떻게 알지요?” 그것이 오늘 말씀드릴 coverage에 대한 부분입니다. 사실 이쪽 계통에서 coverage라는 이름으로 검색하면 처음에 나오는 것은 아마도 falut coverage/test coverage일 것입니다. DFT /Testing 부분에서 사용하는 용어인데, 만들어진 test vector가 얼마나 많은 tr. 을 천이시켜 볼 수 있느냐를 나타내는 말이죠(값을 천이시킬 수 있어야지만, stuck-at-0/stuck-at-1 fault를 잡아낼 수 있으니까요). 여하튼.. 이때 test coverage는 입력된 테스트 벡터에 의하여 천이 시킬 수 있는 transistor의 비율을 나타냅니다.