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

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

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

사실 이쪽 계통에서 coverage라는 이름으로 검색하면 처음에 나오는 것은 아마도 falut coverage/test coverage일 것입니다. DFT/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 코드가 시뮬레이션 도중에 사용되는지를 확인하면 되는 문제니까 말입니다. 물론, 여기서 말한 code coverage는 가장 기초적인 line coverage를 의미합니다만... ^^;
여하튼, 이 code coverage는 검증에 있어서 가장 기본적인 요소가 됩니다. 적어도 자기가 만든 RTL 코드가 검증 벡터에 의하여 모두 확인되었는지는 알고 지나가야 할 문제니까요.  

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

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

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

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

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

예전에 99년에 학교에서 첫 버젼의 EISC를 만들때는 검증에 별 생각이 없었습니다.
뭐, 프로그램 몇개 돌리면 되겠지.. 이런 느낌이랄까요..

생각해보면, 학교에서 만드는 것은 "학술적으로" 의미가 있는 부분에 대해서는 뭔가 이런 저런 시도를 해 보는데, 실제 중요한 동작 자체는 "벤치 마크 프로그램이 돌아가는" 정도로 그치고 말았었습니다. 그러다보니, 다양한 상황에 대한 검증이나 인터럽트 쪽은 아무래도 부족했었습니다.

학생 시절과 비교하였을때 회사에 와서 가장 많이 발전한 부분이라 생각하는 것은 "설계의 질"입니다. 특히, 검증의 질이 많이 향상되어가고 있고, 이를 바탕으로 설계의 질이 향상하는 것이겠지요.
회사에서 "검증의 중요성"을 심각하게 느끼게 되었고 몇년동안 이런 저런 검증 기법들을 적용하기도 했는데, 아무래도 실무에서 의미있는 결과가 나오기에는 미흡한 상태였습니다.
게다가 국내에서는 검증을 업으로 삼으시는 분은 상당히 적으신듯해서 여러 분들과 만나서 의견을 나눠봐도 "검증의 중요성"은 인식하지만, 검증을 업으로 삼는 분(소위 verification engineer)은 아직 만나보지 못했습니다. 음.. S사나 L사 같은데는 있을지도 모르겠습니다만.. 외부로 노출이 안되는 것인지.. 논문도 그렇고.. 설계하시는 분이 검증도 같이 하는 경우가 더 많죠.. (혹시 검증을 업으로 하시는 분계실까요?)

여하튼.. 이번 프로젝트에서는 제가 수행하는 설계 분량을 최대한 줄이고, specification과 verification쪽으로 집중하려고 하고 있습니다. 하지만, 프로젝트라는 것이 항상 그렇듯(^^) 잡은 일정보다 스펙 작성이 오래걸렸고..이런 저런 일을 하다보니, 이번달에 들어서야 이 프로젝트에서 제 관심의 대상이었던 verification쪽에 집중해서 verification plan을 짜고 있습니다. (사내 정보 보안 관계로 ^^; 일반론 이상을 이야기를 할 수는 없습니다만..)

이런 과정에서 Verilog PLI이니 assertion이니, SCV와 같은 것을 다룰 수 있는 기회가 많아지겠지요..^^;

Transaction Level Modeling(이후 TLM)이라는 것이 한 2-3년전부터 SoC설계 분야에서 논문/책/툴을 쏟아내고 있습니다. 그만큼 이제 시장 상황이 익어간다는 것이겠지요.

하지만 설계라는 분야에서 RTL에서 TLM 수준으로 추상화 수준이 이동할 것이라고 믿었던 사람들도 이제는 거의 TLM 수준에서 설계가 이루어질 것이라 믿고 있지 않습니다. 그 이유는 무엇일까요?

예전에 schematic capture수준에서 HDL을 기반으로 하는 RTL수준으로 설계가 옮겨 갈수 있었던 가장 큰 이유는 logic synthesis 기술의 혁신적인 발전에 있습니다.
(저가 처음 digital logic 설계를 배우던 시절이 이 개념이 한창 바뀌던 시절이었던것 같습니다. 학부 3학년때는 schematic capture툴로 설계를 했는데, 학부 4학년때는 VHDL을 시작했거든요.. 개인적으로는 schematic capture툴로 설계를 시작한 것이 설계의 기본기를 많이 배울수 있었던 기회였기에 아주 행운이었다고 생각합니다. )
초기에 logic synthesis는 사실 (전문가가 한) schematic 설계보다는 못하지만, 그 생산성에 있어서 비교할 수 없이 훌륭했고, 어느정도 시간이 흐른 이후에는 설계의 질 또한 훌륭한 수준이 되면서 대부분의 설계가 RTL에서 이루어지게 되었습니다. (물론, 아직도 schematic capture를 이용하여 설계하시는 분들이 계십니다. 몇년전에 일본에서 온 할아버지 엔지니어였던 야노상.. HDL도 잘 모르고, STA도 몰라서 같이 일하는데 아주 괴롭고, 걱정스러웠습니다만.. 동작 잘하는 칩을 만드는 엔지니어였습니다. ^^; 일면 부럽기도 하고요..그 나이까지 엔지니어를 한다는 것이요..)

TLM 수준에서 설계가 이행되지 못하고 있는 큰 이유는 구현(implementation)을 위하여, 손으로 재설계를 해야 하기 때문입니다. 즉, TLM으로 만들고 난 이후에 이를 RTL로 이전시킬 만한 (괜찮은) CAD 툴이 아직 없다는 것이 문제입니다.

뭐, 여러가지 시도가 있기는 합니다만.. 99년에 제가 한창 CAD 알고리즘을 공부할때 behavioral synthesis라는 논문들을 보고.. 이거 돈 되겠다.. 라고 생각했었는데..^^; 사실 이 분야에서 제대로 된 CAD툴이 아직도 못나오고 있는 실정입니다. (비슷한 것으로 자연어 통역기.. 70년대부터 계속 연구되었지만.. 아직까지 못나오고 있습니다... 인공 지능 분야에서 나오지 못할것으로 예상되는 프로젝트 중의 하나로 나와있더군요..^^; 아직 연구는 많이 하지만요..)
여하튼.. TLM 수준에서 RTL로 가는 건 앞에 말한 예보다는 쉬운 것이니 향후 몇년 내에 나올것이라 예상됩니다만.. 아직은 아닌 것이지요..

그럼.. TLM 수준의 설계는 이대로 사망하는 건가요?


TLM은 검증을 싣고..

TLM이 새로운 개념이 아니라는 것은 verification engineer쪽에서는 기본입니다.
왜냐.. 예전부터 검증계에서는 TLM이 좋은 방법이었거든요..
SystemC는 이제 설계 언어라기 보다 검증언어입니다. 물론, architectural simulation하려고 할때 timed model을 예전 C++만을 이용할때 보다 아주 편하게 해주기는 합니다만, 이것이 설계는 아니지 않습니까...

이런 모습을 반영하듯, 초기 systemC는 synopsys에서 synthesizable subset을 지정하고 했습니다만.. 설계 언어로는 대부분 아무도 사용하지 않습니다. (정말 불편하죠..)

이제 SystemC에 추가되고 있는 기능은 대부분 검증 관련입니다. HVL(Hardware verification language)로의 확장에 역점을 두는 것이지요..

SystemVerilog도 마찬가지 입니다. verilog 2001에서 확장되어 발표된 SystemVerilog는 System설계 언어라기 보다 현재로서는 Verilog+HVL이라 할 수 있습니다. (많이 약합니다만..)

TLM기반의 SystemC, systemVerilog의 확장 라이브러리들

SystemC에서는 Cadence의 TestBuilder(이제는 CVE), 그리고, 이를 기반으로 한 SCV가 있습니다.
또한, 최근 멘토에서 AVM(Advanced Verfication Method)라는 검증 methodology(실은 라이브러리)가 나왔습니다. (http://www.mentor.com/products/fv/_3b71 ··· load.cfm). 아마도 Cadence가 donation한 SCV(SCV good to go. Sir! ^^;)에 대한 대항마로 생각되는 부분이 많은데요.. 둘다 무료이고, 공개된 library이니까 설계하는 저희들이야 고맙죠.
국내에서는 CoSOC이라는 서울대 사업단에서 SCV기반의 검증 라이브러리가 나왔는데..  저는 사실 교육을 받고 왔지만 아직도 목적성을 잘 모르겠더군요.. 아무래도 업체가 아니고, 학교 연구소에서 국책 과제로 수행하는 것이다보니 완성도가 아직은 부족한 것 같습니다. (흠..이름을 잊어서 홈페이지에 가봤는데 없는 걸 보니 그냥 접었나보군요)

두 라이브러리 모두 역점을 두고 있는 부분이 assertion, functional coverage, constrant random vector generation입니다. 사실 검증에 있어서 coverage directed constrant random testing이 대세니까요..

요즘에 검증쪽 일을 할라고 슬슬 작업중인데.. 음.. 삽질을 많이 할듯 해서 걱정입니다.