Tag Archives: 검증

Modelsim에서의 Code Coverage

6 Replies

예전에 후배가 한 세미나 자료에서 그림을 많이 발췌합니다.

 

항상 검증을 언제 끝낼 것인가 하는 문제는 어렵습니다. 그래서, 검증할 때 coverage를 측정하여 검증을 언제 마칠것이냐 하는 것을 참고하게 됩니다. Functional verification때 고려하는 coverage로는 code coverage와 function coverage라는 것이 있는데, code coverage는 RTL 코드에 대한 분석을 기반으로 해당 문장이나 표현, 가능한 데이터 흐름이 현재 사용하고 있는 test program(혹은 stimulus) 에 의하여 어느 정도 수행되었는지 측정하는 것입니다.

즉, 여러분께서 RTL 코드를 만들었으니, 적어도 검증 중에 여기에 기술된 문장/표현/데이터 흐름은 모두 검증하는 것이 필요하다는 것이지요.

Functional coverage의 경우 사용자가 어떤 동작(function)을 수행하기 위하여 RTL 코드를 만들었으니, 이 stimulus에 의하여 해당 동작이 수행되었는지 확인하는 것입니다. 그런데, 툴은 이 RTL이 어떤 동작을 위하여 만들어진 것인지 알지 못하므로 assertion과 같은 방법을 이용하여 functional coverage를 잡아야 합니다.

 

여하튼, 본론으로 들어와 code coverage, 특히 line coverage에 있어서는 Modelsim이 상당히 편합니다. Modelsim에서 code coverage를 측정하는 건 상당히 쉽습니다. Modelsim 콘솔에서 다음과 같이 하면 되지요.

 

  1. vsim –coverage [Top Module Name]
  2. view_coverage
  3. code coverage –file [File Name] –lines
  4. coverage reload [File Name]

 

예를 하나 들어볼까요? 아래와 같은 4bit ALU를 코드가 있다고 하면, 의미 있는 동작이 있는 코드는 박스를 친 부분들일 것입니다.

 

이것을 다음과 같은 테스트 벡터로 동작시켜 봅시다.

 

 

이 경우 모든 line에 대하여 cover가 되므로, coverage가 100%가 되고, 해당 RTL에서 그 문장이 몇번 동작하였는지 보여줍니다.

간단하죠.

 

Cadence의 경우도 비슷한 code coverage툴이 있습니다. 전용 툴도 몇 개 있구요. 요즘엔 위와 같은 Line coverage이외에 앞에 설명한 path, toggle등의 복잡한 coverage도 잡아주므로 많은 도움이 되지요.

 

참, 일반적으로 line coverage는 반드시 100%를 충족시켜야 하며, path coverage의 경우도 100%에 근접하도록 해야하는 것으로 알려져 있습니다. ^^;

 

 

검증의 대세는 system verilog?

2 Replies

검증 작업을 시작했다는 포스팅을 얼마전에 했었습니다.
뭐, 일단 검증 시나리오 짜고, function coverage 전략 세우고.. 이런것 부터 시작했습니다만..

verilog로 약간 검증 마인드로 이런 저런 것을 작성하다보니, synthesizable subset의 틀이 얼마나 옭죄고 있었나라는 생각이 심각히 들더군요..

verilog 표준에서 정의된 동작에 대해서 어느정도는 알고 있다고 자부하고 있었는데, 좀더 깊이 알게 되는 기회가 되고 있는 것 같습니다. 얼마전 gil님께서 class와 비슷한 verilog를 말씀하신 이유도 납득이 가구요..
사용자 삽입 이미지
하지만, verilog는 추상화 레벨을 높이기에 약간 무리가 있기는 하더군요.. 물론, 어짜피 regression vector쪽에는 PLI위주로 가게될 것으로 구상해두었지만, 일반적인 경우에는 PLI사용을 꺼리시는 분들도 있는 관계로 왠만하면 verilog만으로도 어느정도 coverage를 보일 수 있도록 구상하고 있는데… 약간 까다로운 점이 있습니다.

그래서, 대안 처럼 생각하고 있는 부분이 SystemVerilog인데, 아직 제가 본격적으로 공부해본것이 아니라 스펙 수준에서 표준 문서만 한번 훓어본 정도에서 멈추어 있던 상태라 약간 깨름직 했었습니다.
그런데, verification guild에서도 그렇고, comp.lang.verilog도 그렇고 system verilog에 대한 내용과 비중이 점점 높아가는 것을 알 수 있겠더군요.

사실 verification guild의 guild master가 vmm-sv의 저자이기도 하니까 그렇겠지요..
하지만, writing testbench 책이 HVL이 아닌 system verilog만을 이용해서 다시 작성할 수 있을 정도로 system verilog의 verification기능이 강력하다는 것은 아무래도 끌리는군요.
(옆에 보이는 책이 writing testbenches using systemverilog책이 바로 예전에 제가 다시 읽고 있다는 writing testbenches의 새 버젼이지요. 요즘에 가장 사고 싶은 책입니다. 하지만, 가격이… 가격이.. orz)

Verification Methodolgy Manual for SystemVerilog와 같은 책이 나온것도 사실 system verilog가 대세가 되는 것 아냐? 라는 생각을 가지게 하는 이유이기도 하지만 말입니다. (또한권의 가장 사고 싶은 책입니다. 역시 가격이.. 에휴… ) 사용자 삽입 이미지이 책의 홈페이지에는 system verilog를 이용한 verification에 대한 개략적인 정보는 얻을 수 있습니다.

사실 초기에 저는 cadence의 SCV를 필두로한 systemC에 대항하기 위해서 synopsys가 선택한 카드가 system verilog일 것이라는 곱지 않은 시선을 가지고 있었습니다.
하지만, 요즘에 와서는 system verilog를 native로 지원하는 simulator들이 속속 등장하고 verilog표준에 system verilog가 포함될 것으로 예정되어 있는 상태이니.. 정말 systemverilog가 HVL을 대체할 정도로 강력하다면, 대세가 될 확률이 높아지겠지요.

여하튼, 지금 가지고 있는 system verilog for design(stherland저)책이라도 한번 봐둘 필요는 있을 것 같습니다. ^^;
사실 예전에 이 책 봤을때는 systemverilog에 대해서 약간 실망을 했었는데, 검증의 측면에서는 어떨지 한번 공부해 봐야겠습니다.

이 부분은 역시 작업 마치면 한번 정리하죠..나~~~중에

TLM으로 설계가 이동할 것인가?

4 Replies

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이 새로운 개념이 아니라는 것은 [wp]verification[/wp] 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의 확장 라이브러리들

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

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

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