검증 작업을 시작했다는 포스팅을 얼마전에 했었습니다.
뭐, 일단 검증 시나리오 짜고, 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에 대해서 약간 실망을 했었는데, 검증의 측면에서는 어떨지 한번 공부해 봐야겠습니다.

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

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이 대세니까요..

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

 개인적으로 SoC에서 가장 재미있게 생각하는 부분이 검증/디버깅입니다.
처음부터 버그없는 넘을 만들면 좋겠지만, 그럴수 없다면 효과적인 검증과 디버깅은 "비용을 소모하는 부수적인 일"이 아니라 이미 필수적인 일인 것입니다.

간혹 몇몇 경영자분들께서 "자신이 실수를 하고 자신이 디버깅하는데 시간과 돈을 소모하는 건 전적으로 엔지니어의 부주의다."라고 말씀하시곤 하는데, 50%는 납득하지만, 50%는 절대 납득할 수 없습니다.
부주의에의 해서 생긴 버그, 스팩 이해에 문제로 인한 버그, 전달 과정에서의 버그, 초기 아키텍쳐에 의한 버그.. 이 모든 것이 발생하지 않게 완벽한 스팩과 작업을 할 수 있는 사람이 있으리라 생각하지 않기 때문입니다.

아.. 오늘의 이야기에 들어가서.. 디버깅하시는 스타일을 보면 참 여러가지 부류가 있습니다.

검증/디버깅의 기본은 "원인의 파악"이겠죠?
그런데, 그 원인 파악이 아주 아주 어려울때가 있습니다. 수많은 로직들에 연관 관계가 있고, 게다가 타이밍에 의한 영향까지 받는경우 말입니다.

간혹 이런 경우에, 좀 찾으시다가.. 재미난 이유를 대시는 분들이 있습니다.
마치 "고양이가 코드를 먹어버리는 바람에 코드가 사라졌어요" [이 문장은 제가 어느 책에서 본 문장입니다.] 라던지 "낮에는 죽는데 밤에는 안죽네요.." 같은 이유 말입니다.

아.. 얼마나 고생했으면 그런 생각이 다 들겠습니까?
하지만, 신화속에 들어가는 순간 버그는 절대 사라지지 않습니다.

적어도 디지털 회로에서 신화속에 사는 버그란 없습니다. (아날로그 회로에는 아날로그 행운의 신이 있다고 믿는 분들이 많으시고.. 저도 일부 믿습니다.. ^^; )

자.. 디버깅/검증에서 또 한가지 주의해야 할 사항이 있습니다.  바로 "이 일은 절대 일어날 수 없어 " 라는 것입니다. 이런 신념은 눈앞에서 지나가는 벌레를 그냥 못보고 지나치게 할 수 있습니다.
네.. 바로 눈앞에서 일어나고 있는 일을 그냥 모른채 할 뿐인거죠..
여러분은 "절대 일어날 수 없는 일"을 디버깅하는 것이 아니라 "지금 그 일이 일어났으니까.." 디버깅 하는 겁니다.
현실에서 도망가지맙시다.

이제 튼튼한 올가미 몇개를 준비할 차례입니다.
몇몇 책에서는 shot-gun이라 말하기도 하더군요... [verification plan (james저)]
여하튼 의심나는 곳, 절대 일어날 수 없다고 생각하는 곳 모두에 던져 봅시다.
그리고, 선입관을 버리고 찾아나가다 보면 결국 찾을 수 있을 것입니다.
점점 확신을 얻어가게 될때도 항상 "다른 가능성"을 열어두면서, 범위를 좁혀가면 얼마 시간이 지나지 않아서 올가미에 벌레가 딸려 올라오는 걸 보게 될 것입니다.

잡기 어려운 버그일수록 잡았을때 기쁘지 않겠습니까?

버그찾기란 그런것이니까요..

자! 즐깁시다....

p.s. 요즘 버그잡기에 한창입니다. 신화에 빠지지 않으려 써봤습니다.