Tag Archives: ABV

Mentor의 Verification Academy

2 Replies

OVM과 AVM을 밀고 있는 mentor에서 verification academy를 열었습니다. [여기]

현재는 아래의 세개 모듈로 구성되어 있으며, Flash 기반으로 구성되어 있어서 왠만한 웹브라우저에서는 모두 접근 가능하다는 장점이 있습니다. 단, 현재는 회사 메일로만 가입을 받고 있다고 적혀 있는데, 학생들도 가능할지는 모르겠습니다.

Evolving Capabilities Module (전반적인 overview)

Assertion-Based Verification Module (ABV에 대한 설명)

(CDC) Clock-Domain Crossing Verification Module (CDC 부분의 검증 방법)

상당히 넓은 내용을 알려주고 있는데요.. mentor에서하는 강좌이다보니 Questa나 0-in 과 같은 툴을 사용한다는 점이 특징적이겠습니다.

홈페이지에서 등록 신청하시면 하루 정도 이내에 registration 관련 메일을 보내줍니다.
메일을 받은 후에 login 계정을 activation 시키면 되는 거죠. 검증 특히 ABV에 관심 있으신 분들께는 좋은 강좌일 것같습니다.

책 몇가지

3 Replies
ASIC/processor 관련 책을 많이 보시라는 이야기를 해 드리고 있습니다만, 책이 워낙에 비싸죠.
모모 사이트와 당나귀를 적절히 이용하면 왠만한 책은 pdf로 구할 수도 있습니다만..
클리앙에서 http://www.scribd.com/ 라는 곳에 대한 소개가 있어서 가 봤는데, 괜찮은 책이 많군요. Google 검색을 통해서 갔을때는 그냥 단순히 리포트같은거 모아둔 사이트라고 생각했는데..
잠깐 검색해서 보이는 책 몇권 소개해 드릴께요.
시납시스 툴을 이용하여 합성하고 STA 하는 방법에 대하여 나와있는 책이죠. 예전에 본 책입니다만, 아직도 유효한 부분이 많고, 처음 ASIC flow를 사용해 보시는 분은 한번 읽어두면 좋습니다. 간단한 예제 스크립트도 쓸만하구요.
물론, Synopsys Tool에 있어서 가장 좋은 책은 Manual이에요.. 워낙에 잘쓰여져 있으니까요. 이 책은 메뉴얼 보기에 시간이 없을 때 보시면 좋습니다. 분량도 적고…
아마도 이책 모르시는 분은 없으실 거라 생각됩니다. 설계 방법에 대하여 Verilog/VHDL 을 모두 사용하여 설명한 아주 훌륭한 책입니다. 제가 예전에 처음 VHDL만 사용하다가 verilog쓰기 시작하면서 처음 본 책이고, 가장 많이 참고한 책중에 하나입니다.
Assertion based verification에 대하여 관심을 가지시는 분들이 반드시 보여야 한다고 생각하는 책입니다. 이 책의 저자인 Foster에서부터 ABV가 정착되었다고 해도 과언이 아니니까요(제가 알기로는 그런데, 실제로 그런지는 잘 몰라요 ^^; 논문 Survey를 해본건 아니니까요.. 이런 무책임한 ㅋㅋ)
ARM System Developers Guide-Designing and Optimizing System Software(http://www.scribd.com/doc/6654432/ARM-System-Developers-GuideDesigning-and-Optimizing-System-Software)
상당히 유명한 책이죠. 제가 본 느낌으로는 약간은 Application note의 집합과 같다는 생각이 들었습니다만, ARM 프로세서를 ‘사용하시는 분께’ 아주 유용한 책이라는 느낌입니다. 사용하시는 분이라는 점을 강조한 이유는 최적화 프로그래밍 방법에 방점이 찍혀 있는 책이기 때문입니다. 국내에 번역서도 제 생각으로는 괜찮은 수준으로 번역되어 있습니다. (몇몇 눈에 띄는 부분이 있습니다만, 그래도 몇몇 번역서에 비하면 아~주 잘한 번역입니다.)
이외에도 좋은 문서와 책이 널려 있군요. 가끔 시간되면 몇권 더 소개해드리죠. 제가 읽은 책이 검색 되는 경우에만 소개해 드릴 수 있다는 것이 문제지만요 ^^;
아.. 요즘 보고 있는 책 중에서는 processor design: System on Chip Computing for ASIC and FPGA라는 책이 괜찮더군요. 이에 반해서, 기대를 많이 하고 봤던 Designing Embedded Microprocessor; Low power perspective 는 기대를 많이하고 구입한 책이라 그런지 기대에는 좀 못미치는 책이었습니다.

Coverage와 Assertion

2 Replies

검증에 있어서 고려되어야 하는 사항중에 하나는 “언제 검증을 그만 둘 것인가”입니다.


너무나도 쉬운 질문이지요? 뭐, 검증할 부분을 다하면 검증을 그만 두면 되죠. 그럼 질문을 바꿔보겠습니다. “검증할 부분에 대하여 모두 검증했는지는 어떻게 알지요?”


그것이 오늘 말씀드릴 coverage에 대한 부분입니다.


사실 이쪽 계통에서 coverage라는 이름으로 검색하면 처음에 나오는 것은 아마도 falut coverage/test coverage일 것입니다. [wp]DFT[/wp]/Testing 부분에서 사용하는 용어인데, 만들어진 test vector가 얼마나 많은 tr. 을 천이시켜 볼 수 있느냐를 나타내는 말이죠(값을 천이시킬 수 있어야지만, stuck-at-0/stuck-at-1 fault를 잡아낼 수 있으니까요). 여하튼.. 이때 test coverage는 입력된 테스트 벡터에 의하여 천이 시킬 수 있는 transistor의 비율을 나타냅니다.


검증에 있어서 coverage도 마찬가지 입니다.


기본적으로 두 가지 coverage는 충족해야 하는데, 아주 기초적인 값이 code coverage, 약간 더 복잡하지만 반드시 체크해야 하는 부분이 functional coverage입니다.


이 중 code coverage는 주어진 RTL 코드 중에 검증 벡터에 의하여 활성화 되는 코드의 비율 정도로, functional coverage는 “점검해야 할 기능 요소 대비 주어진 벡터로 잡아낼 수 있는 기능 요소의 수” 정도로 요약 될 수 있습니다. Code coverage는 그나마 좀 자동화하기 쉽습니다.


이미 존재하는 RTL 코드가 시뮬레이션 도중에 사용되는지를 확인하면 되는 문제니까 말입니다. 물론, 여기서 말한 [wp]code coverage[/wp]는 가장 기초적인 line coverage를 의미합니다만… ^^;
여하튼, 이 code coverage는 검증에 있어서 가장 기본적인 요소가 됩니다. 적어도 자기가 만든 RTL 코드가 검증 벡터에 의하여 모두 확인되었는지는 알고 지나가야 할 문제니까요.  


다시 처음 질문으로 돌아가서 “점검해야 할 기능 요소의 수”는 어떻게 알수 있겠습니까???  물론, 설계자의 spec안에 있습니다. RTL 코드란 궁극적으로 spec안에 제시된 기능을 구현한 것이니까요. 그런데, 이걸 검증 과정에서 빼놓지 않고 검증 했는지를 알기란 상당히 어렵고, 자동화 대상이 되기 어렵습니다. 그래서 assertion이 등장합니다.


[wp]assertion[/wp]은 software부분에서는 이미 폭넓게 사용되던 개념입니다. 코딩에 있어서는 어떤 가정(이 조건은 절대 들어오지 않는다던지.. 어떤 변수는 어느 구간안에서는 절대 어떤 값을 지니지 않는다던지..)을 하는 경우가 있는데, 이런 가정하지 않은 경우가 온다면 구현된 코드가 “절대” 안전 할 수 없으며, 정의되지 않은 동작을 시도하면서 프로그램이 오동작하게 됩니다. 이런 경우를 확실히(assert)  하기 위해서 assertion이라는 것을 사용합니다. 즉, 가정하지 않은 경우가 발생하면 동작 과정에서 “조용히 버그를 발생시키기보다는 경고 메시지와 함께 끝나자”는 것입니다. (여기에 대한 주요한 내용은 이 분야의 선구자(?)인 Foster의 “Assertion-based Design”이라는 책을 보면 잘 나와 있습니다.) 이 책의 내용을 기반으로 OVA라는 라이브러리도 있고, 실무에서 많이 사용된다고 합니다. [wp]PSL[/wp]/Sugar라는 표준 언어가 제정되기도 했지요. (systemverilog에서는 언어수준에서 assertion이 제공됩니다.)


이 assertion 기능을 좀 더 전향적으로 사용하면, spec을 정의할 수도 있습니다. 즉, 어떤 기능에 대하여 assetion으로 지정해 두는 것이지요. 이런 assertion은 테스트 벡터에 의하여 지정된 기능 요소가 검증되었는지 나타내는 기능으로 사용되는 것입니다. 이걸 바꿔 말하면, 주어진 assertion의 수 대비 테스트 벡터에 의하여 점검된 assertion의 수로써 우리가 원하던 “spec에 정의된 기능을 테스트 벡터가 얼마나 수행하였는지”를 나타내게 되며, 이는 달리 말하면 functional coverage를 나타내게 됩니다. !!!


드디어 전혀 관계 없어 보였던 두 개의 기능이 만나 하나의 art가 되는 순간이죠. ^^;


몇 번 적었습니다만, Lint, code coverage, assertion의 개념은 모두 소프트웨어 공학쪽의 개념이었는데, 이제는 하드웨어 설계로 넘어오고 있습니다(사실 다 넘어왔죠..) 참 재미있습니다.