Assertion

OVM과 AVM을 밀고 있는 mentor에서 verification academy를 열었습니다. [여기] 주소가 바뀌어서 https://verificationacademy.com/ 로 바꿨습니다. 현재는 아래의 세개 모듈로 구성되어 있으며, Flash 기반으로 구성되어 있어서 왠만한 웹브라우저에서는 모두 접근 가능하다는 장점이 있습니다. 단, 현재는 회사 메일로만 가입을 받고 있다고 적혀 있는데, 학생들도 가능할지는 모르겠습니다.

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

예전에 99년에 학교에서 첫 버젼의 EISC 를 만들때는 검증에 별 생각이 없었습니다. 뭐, 프로그램 몇개 돌리면 되겠지.. 이런 느낌이랄까요.. 생각해보면, 학교에서 만드는 것은 “학술적으로” 의미가 있는 부분에 대해서는 뭔가 이런 저런 시도를 해 보는데, 실제 중요한 동작 자체는 “벤치 마크 프로그램이 돌아가는” 정도로 그치고 말았었습니다. 그러다보니, 다양한 상황에 대한 검증이나 인터럽트 쪽은 아무래도 부족했었습니다.

Transaction Level Modeling(이후 TLM)이라는 것이 한 2-3년전부터 SoC설계 분야에서 논문/책/툴을 쏟아내고 있습니다. 그만큼 이제 시장 상황이 익어간다는 것이겠지요. 하지만 설계라는 분야에서 RTL에서 TLM 수준으로 추상화 수준이 이동할 것이라고 믿었던 사람들도 이제는 거의 TLM 수준에서 설계가 이루어질 것이라 믿고 있지 않습니다. 그 이유는 무엇일까요?