Evolving Capabilities Module (전반적인 overview)

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

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

1.
Veripage 라는 곳에서 느닷 없이 뉴스레터를 보내왔는데(그동안 왔을 텐데, 스팸 처리 되었을 가능성이 더 높지만..), 거기에 아래와 같은 문제가 있습니다.

다음에서 Z의 값은 어떻게 될까요?

bit c, e, o, r, t;
bit [2:0] v, w;
bit [5:0] x, y;
bit [6:0] z;

v = {<<{c,e,r}};
w = {<<{r,o,c}};
x = {>>{v,w}};
y = {<<3{x}};
z = {>>{y,t}};


SystemVerilog를 써 보신 분들은 보신 적이 있으실 streaming concatenation 연산입니다.
간단히 설명드리면, 병합 연산을 수행하되 << 는 병합 순서에 있어서 right-to-left로, >>는 left-to-right로 병합하라는 연산이지요.
<<N{}은 N단위로 블록을 잡으라는 의미이구요.
그다지 쓸일은 없습니다만, 가끔 복잡한 assign문을 적어야 할 때 편합니다.
저는 합성해야 할 코드는 호환성 문제를 고려해서 verilog95-가끔 2001 문법도 씁니다만-를 사용하고, 이런 귀찮은 assign은 vi의 매크로를 사용합니다만, 검증만 목적으로 하는 모델링에는 편하겠죠.

여하튼, 그래서 답이 어떻게 될까요? ㅎㅎ


2.
Veripage를 오랫만에 가보니 검증 관련 책 추천이 새롭게 많이 되어 있더군요. http://www.project-veripage.com/books.php 참고해보세요.

3.
구독하고 있는 blog중에 art.oriented 님의 블로그에 올라온 글입니다. (지난번에 alt.oriented 라고 잘못 적는  우를 범했습니다. 다시 한번 죄송합니다. newgroup인줄 알았는지 ^^;)

typedef struct tagWHATTHE {
  int    data1;
  int    data2;
  char   data[1];
} WHATTHE;

여기서 char data[1]의 의미는 무엇일까요?
정답은 위의 글을 참조하시고..

저도 simulator를 만들때 위와 비슷한 동작이 필요한 경우가 종종(이라고 쓰고 '많이'라고 읽는) 있는데, 유용한 테크닉이군요.

참고로 EISC 상에서 disassemble 해보니 다음과 같이 접근합니다.  (변수명은 tt, typedef는 test로 했고, malloc은 걍 100 했습니다.) 어떻게 나올지 짐작하는데 대충 도움이 될 것 같아서 올립니다.

test* tt = (test*)malloc(sizeof(test)+100);
c0000046:       70 a8           ldi     0x70    %R8
c0000048:       4d df           jal     c00000e4 <_malloc>
c000004a:       98 e4           lea     ( %R8     ) %R9

c000004c <.LM3>:
  tt->data1 = sizeof(test) + 100;
c000004c:       70 a8           ldi     0x70    %R8
c000004e:       09 18           st      %R8     , ( %R9  + 0x0 )

c0000050 <.LM4>:
  tt->data2 = 1;
c0000050:       01 a8           ldi     0x1     %R8
c0000052:       19 18           st      %R8     , ( %R9  + 0x4 )

c0000054 <.LM5>:
  for (i = 0; i < 100; i++) {
c0000054:       00 a0           ldi     0x0     %R0
c0000056:       89 e4           lea     ( %R9     ) %R8
c0000058:       c8 c8           addq    0x8,    %R8

c000005a <.L5>:
    tt->data[i] = i;
c000005a:       08 30           stb     %R0     , ( %R8  + 0x0 )

ldi은 load immediate, jal 은 call과 동일하고, st는 store, lea는 레지스터간의 move, addq는 add immediate입니다.  (stb는 store byte이구요)
본문에 나왔듯이 캐시 효율로 봐도 이넘이 더 좋을 듯..


쓰고나서 덧글) 테터에서 코드 하일라이트 기능이 엉켰는지 짜증 지대로.. ㅠㅠ;

가끔 올리는 짧은 소식 몇 가지.

1.

Synopsys에서 Low Power Verification Methodology Manual을 공개하였습니다
Solvnet ID가 있으시다면 누구라도 여기(http://www.vmmcentral.org/vmmlp)에서 다운 받으실 수 있습니다.

저는 다운만 받고 아직 훓어보지도 못해서 no comment입니다. ^^;

2.

Mentor가 OVM을 기반으로 VMM code를 지원하겠다고 발표했습니다. (실질적으로는 VMM의 function을 OVM 함수를 이용하여 구현한 것이겠습니다)
VMM을 기반으로 작업했던 사람을 OVM으로 끌고 오겠다는 셈이겠지요. (http://www.mentor.com/products/fv/metho ··· b_rf.cfm 에서 Verification Cookbook을 다운받으실 수 있습니다.)

아래 posting에 댓글 달아주신 홍용재님의 글처럼, OVM은 e, SystemC로 지원할 계획을 가지고 있습니다. 대부분의 interface 함수를 공유하게 될 것이니, 기존의 작업은 그대로 둘 수 있고, e, SystemC를 HVL로 이용하여 모델링 하시던 분들을 역시 적극적으로 끌어들이겠다는 전략으로 해석됩니다.

3.

드디어 simulation 가능한 툴이 생겨서 OVM을 좀 보고 있습니다. SystemVerilog의 Class를 참 잘 이용한 것 같습니다. 제가 평소에 하는 프로그래밍이라는 것이 대부분 모델링이라 보통 프로그래밍을 할 때 속도 문제로 OOP는 잘 사용하지 않는데(특히 virtual function의 경우 상당히 느려집니다), 걍 편하게 살자는 마음과 Verification에 한정하니 머리가 편해지는군요. OOP라는 것이 처음에 class design(실제적으로는 상속의 남발 ^^;) 잘못하면 낭패를 보는 경우가 많은데, 대부분의 코드가 공유될 때 편하긴 편하지요.

4.

ABV를 여쭈어 보시는 분들이 많은데 SystemVerilog에서 출발해야 할 부분이라고 생각되어서, 취미 삼아 Verilog사용자를 위한 SystemVerilog Guide를 지난달부터 작성하고 있는데, 회사 일과 크게 관련이 없는지라 주말에 집에서 하는 작업으로 한정하고 생각하다 보니 진도가 아주 느립니다. 어느 정도 정리되면 올리겠습니다. (대부분 doulos.com의 Tutorial 자료를 참고하고 있고, 내용에서 빠지는 부분을 채우고, 제 생각에 별로 필요 없는 부분 – 그런게 있나요.. ^^; -은 제외하고 작성하고 있습니다.

  ---

쓰고 보니 요즘 문서작업으로 바쁜데.. 그 와중에 또 글을 쓰는 건 뭐지… 라는 생각이 드는 군요. (시험 전달에 이상하게 몰아두었던 만화나 드라마나 심지어 논문이 재미있어지는 것과 비슷한 현상일지도..)

연일 30도를 넘나드는 더위가 계속되고 있습니다.

이럴때 항상 문제가 되는 것이 집중력이 떨어진다는 건데요.. 저도 마찬가지 입니다.
(실은 개인적으로 좋은 일이 생겨서 그럴지도 모르겠습니다만 ^^;)

오늘만해도 gcc-MinGW에서 mti vpi 연결시키는 거 때문에 잠깐 modelsim userguide를 보다가, 딴짓을 하기 시작해서 대략한 5시간동안 딴짓을 했습니다.

뭐 딴짓이라고 해도 모레쯤이나 하려던 processor market forecasting자료 정리였는데, 어짜다보니 하고 있더군요. 이건 뭐, 원래 하려던 일은 까맣게 잊고 나중에 하려던 일을 한참하다가 "아.. 내가 오늘 하려던 일은 이게 아닌데.. " 뭐 이런 시나리오라고나 할까요.

VPI 이야기가 나와서 그러는데요.. (또또.. 옆길로 빠집니다요) 회사 툴이 System Verilog-verification feature를 지원해주지 않아서, C/PLI나 만들어야 겠다는 이야기를 했었죠? 요즘 teal library를 분석하고 있는 중인데, 이거야 원.. 보면서 몇 번을 감탄한 것인지 모르겠습니다.

사실 뭐 PLI 연결하는 것이야 별 차이있겠습니까? 뭐 thread를 사용하는 것도 그렇다치구요.. 근데, PLI 연결 부분을 teal_synch.cpp라는 몰아두고, 이걸 class로 덮어씌우고 연산자 오버로딩을 해버리니 예술적인 경지에 이르르더군요. 사용하는 사람 입장에서는 이 부분이 verilog랑 붙기 때문에 어쩌구 저쩌구 생각할 필요가 거의 없도록 만들어졌더군요.

아쉽게도 저는 유연성 보다는 빠른 동작을 즐기기 때문에 teal을 그대로 이용하지는 않겠지만, (처음에는) 재미삼아 분석해 본 라이브러리인데 아주 많은 걸 배웠습니다. 천재성이 담긴 코드에요.. 저에겐 '이 정도쯤은 해야 verification engineer가 되는 건가.. 에효..' 라는 상념에 빠지게 하더군요..

C++에 익숙하시고, PLI를 공부중인 분들은 상당히 도움을 받으실 수 있을 것 같습니다. 혹시라도 관심있으신분은 http://www.trusster.com/ 에서 다운 받아보실 수 있습니다. 이거 관련된 책도 있는데, 아직은 저도 본 상태가 아니라 뭐라 말씀드리기는 어렵습니다. (TRUSS도 아직 사용해보지 못했습니만, Teal만으로도 괜찮습니다 ^^;)

아.. 그러고보니 관련 기사도 있었군요.. EETimes Korea의 기사입니다.

---
위의 부분까지는 MS Writer에서 썼는데, 평소처럼 publish하려니 좀 허전하네요.. ^^;

혹시라도 PC환경에서 cygwin/modelsim하에서 사용하시는 분들을 위하여 몇 가지만

1) Makefile.Windows를 만듭니다. 이 파일은 Makefile.linux를 복사하시는 것이 편합니다.
2) 아래와 같이 고칩니다. (필요에 따라 더 고치셔도 됩니다.)

3) Makefile을 수정합니다.

대략적인 힌트만 드렸습니다만, 이 정도면 필요한 부분을 추가적으로 수정하셔서 verification_top()함수를 작성하신 다음에 linking하시는데 문제 없을듯 합니다.

Automated Functional Verification 방법에는 여러 가지가 있지만, testvector 발생 유닛(보통 Directed Random방식을 사용하지요?)과 golden model을 이용한 checker model을 만들어서 DUV(Design Under Verification)의 결과와 비교하는 것이 가장 편한 방법 중에 하나임은 부정할 수 없습니다. (여담입니다만, 국내에서는 많은 경우 golden model없이 설계하는 경우가 많아서 검증을 위하여 작성한 golden model이 실제로 RTL보다도 정확성이 떨어지는 경우가 있다는 것이 문제가 종종 발생합니다. 여기서는 golden모델의 확보에 대한 이야기는 나중으로 미루죠.)보통 golden model은 C model을 이용하게 되는데, C 모델을 Verilog와 동시에 simulation하는 것은 그리 녹녹한 일이 아닙니다.

저는 프로세서를 대부분 다루기 때문에 C모델이라 함이 대부분 ISS simulator가 됩니다. 이후에 Simulator와 C모델은 그냥 섞어 쓸 가능성이 높은데, 보시는 분께서 편하신 대로 생각하시면 되겠습니다.

우선 Simulator를 만들 때 그 목적을 정확히 할 필요가 있습니다. 초기에 Simulator의 목적은 executable spec.의 의미가 가장 중요한 의미였을 것입니다. 그래서, 대부분 function level의 정확성을 가지지요. 프로세서의 경우 보통 이야기하는 ISS(Instruction Set Simulator)정도의 수준일 것입니다.

이때 고려하는 사항은 동작의 정확성, 빠른 동작 속도, 유연한 변경 가능성(design space exploration을 해야 하니까요)과 같은 것을 고려하게 됩니다.

그런데, 아시다시피 Verilog와 Simulation을 한다던지, Verilog Model대신 사용하려고 할 경우에는 ISS level뿐만 아니라, BFM 수준, 간혹은 Pin-level accuracy를 필요하게 됩니다. 통신이나 영상쪽의 모델은 뭐 Functional model이나 BFM이나 큰 어려움이 없습니다. Latency가 거의 정의되어 있기 때문이지요.

프로세서의 경우 약간 복잡해지는데, hazard의 발생, instruction issue rate의 변화, exception의 발생을 고려해야 하는데, 이 경우 bus function이 발생하는 Instruction Fetch와 Data Access stage의 동작을 모사하기 위해서는 대부분의 pipeline을 표현해내야 합니다. 예전에 pipeline 수준의 accuracy를 가지는 simulator를 만들고, pin-level interface를 붙여서 나름대로 쓸만한 PLI model을 만든 적이 있지요. 단지 문제는 pipeline수준의 accuracy를 가지다 보니, 너무 너무 느려져 버린거지요.

쉽게 쉽게 만들려면 functional model로 simulator를 만들고, Verilog Model(DUV)상에 하나의 명령이 retire되는 순간에 register들의 값을 비교하는 방법도 가능합니다. 하지만, 해당 model이 불필요한 hazard 발생은 없는지, Instruction Fetching에 불필요한 사항이 추가되지는 않았는지 확인 할 수는 없습니다. (당연하죠.. reference model이 functional model이니 timing spec.을 만족시켰는지는 알수 없는것이지요)

흠.. 많이 옆으로 샜는데요..

C Model과 Verilog와 붙이는 방법이 Verilog-PLI (Programming Language Interface)를 이용하는 겁니다. Simulator는 clock단위로 동작하므로, 느낌상 아래와 같이 동작시키면 될 것 같습니다. 이런 경우에 verilog에서 C function을 호출할 때 가장 많이 사용되는 건 calltf()를 이용하는 방법입니다.

즉, run_sim()을 calltf()의 callback function으로 등록하는 겁니다. 그리고, 매 클럭 calltf()를 불러주는 것이지요.

근데, simualtor의 이전 상태를 계속적으로 보존해야 하는 경우에는 매 클럭 새롭게 호출되는 calltf()를 이용할 때 문제가 있을 수 있습니다. (사실 그리 어려운 일은 아닙니다만, 예를 들기 위하여 ^^ ) 그래서, 내용을 보존하고 싶을 때는 misctf()를 사용하는 것도 괜찮습니다. misctf()는 원래 verilog simulation의 이런 저런 정리 작업을 하는데 사용하는 목적으로 만드는 건데요. 아래와 같이도 사용할 수 있습니다.

뭐 이런 느낌입니다. misctf()의 경우 시뮬레이터의 초기 시에 simulator에 연결된 이후에 simulator의 종료 시까지 계속 머무르면서 파라미터의 값이 변경 될 때 마다 제어권을 가집니다. 이 파라미터의 변화시마다 클럭이 변화되었는지 확인하고, 클럭이 변화하였을 때 값을 호출하면 되겠습니다.

아래는 한 4년 전에 만든 PLI 모델중의 misctf부분인데요.. 실제 구현은 없으니 공개해도 별 문제 없을 것입니다. ^^; 대략 이런 느낌으로 만드시면 됩니다. :)
다음 번에는 좀 더 재미난 PLI 함수를 다루어보죠.. (아.. VPI는 초반에 좀 다루지 않네요. ^^; Blog의 예제를 위해서라도 예전에 acc_와 tf_를 이용해서 만든 PLI 모델을 업그레이드해야겠군요. )

뭐랄까요.. 요즘 이런 저런 일로 바쁘다보니, 사람이 좀 얇팍하게 글을 쓰게되네요. :)
(퇴고 없이 그냥 온라인에서 쓰는 글이라 앞뒤가 없을지도 모르겠습니다.)

오늘은 여러분들께서 perl을 이용해서 Verilog HDL을 위한 testbench를 작성할 때 간단히 명령어 해석기를 만들어 사용하는 방법을 알려드리죠.

이 방법은 제가 JTAG을 위한 protocol을 만들다가 생각해낸 방법인데요.. 아주 유용하게 쓰고 있습니다.
얼마전 AXI FileReader와 같은 간단한 명령어 해석기가 필요할 때도 쉽게 적용할 수 있구요.

예를들어, JTAG을 위한 몇몇 명령을 만들고, 이 명령을 이용해서 HDL model을 위한 신호 입력으로 변환시키는 과정을 생각해 봅시다.

1. 필요한 함수를 정합니다.
대충 다음과 같은 함수를 쓸 수 있겠지요?

2.
해당 함수를 perl에서 subroutine으로 만들어갑니다.
뭐, subroutine을 만드는 방법은 쉽죠?

3.
이 부분이 제일 중요한데요..

이런식으로 처리하려면, 중간에 다음과 같은 루틴을 넣어줍니다.

위의 한 행은 해당 파일($ARGV[0])에 지정된 "perl" 명령어들을 읽어와서 해석하는 부분입니다.
즉, 여러분께서 "filename.input" 이라는 입력 파일에 앞에서 작성한 subroutine을 "명령어 사용하듯" 적어두면, 이것이 perl script에서 읽혀서, "명령어를 해석하듯" 동작하게 됩니다.
이렇게 함으로써, 파싱하는 부분을 생략하고도, 그럴듯하게 명령어 해석기처럼 하나의 perl 스크립트를 만드는 것이 가능합니다.


이제 이러한 perl script에서 어떻게 HDL 테스트 벡터를 만들어내는지 생각해 봅시다.
간단히 생각할 수 있는 것은 두 가지 인데요.
첫번째는 ROM file형태로 만들어버리고, verification을 위한 testbench에서는 $readememh()를 써서 읽은 다음에 한 클럭에 하나의 신호 그룹을 뿌리는 방법이구요..
두번째는 각 subroutine에 printf FOUT 과 같은 file output을 사용해서, 간단한 verilog testvector를 만들어내고, 이를 verification을 위한 testbench에서 `include "xxx" 명령을 이용해서 읽어들이는 방법입니다.

둘 다 간단하죠?

한 마디로, perl을 이용하면 C로는 어렵게 해야 할 일이 아주 아주 편해지는 일이 많습니다. 그래서 verification engineer들에게 perl과 같은 scripting 언어가 사랑받는 것이겠죠.

"추상화 수준", "추상화 단계"라 불리는 용어이지요. 아마도 C++를 다루실 때 많이 접하셨을 것이라 생각합니다. ^^; 추상화 수준이라는 것은 말 그대로 추상화의 정도입니다. 추상화의 반대가 구체화라는 것은 아실 것이고, 추상화는 생각에, 구체화는 사물에 가깝다는 것도 아실 것이라 생각합니다.

모든 작품(?)이 다들 그렇지만, 머리 속의 관념이(ASIC에서는 알고리즘) 표현 도구를 통하여 구체화되는 과정을 거쳐서 하나의 작품이 됩니다. 이때 머리속의 관념은 추상화 단계에서 점차 구체화되는데요.. 칩쟁이들이 잘 하는 말로 algorithm level, architecture level, register transfer level, gate level, physical implement level 뭐 이 정도 표현할 수 있겠습니다.

ASIC에 있어서 보통 RTL이라고 하는 register transfer level에서부터 physical impelmentation level(즉, GDSII라는 완성된 그림이 나오는 단계)까지는 EDA툴이라 부르는 CAD툴에 거의 전적으로 의존하게 됩니다. (아날로그 하시는 분들이 빼고요.. 그 분들은 직접 그림을 그리시는 artist잖아요~ ^^;)

즉, 설계라는 분야란 기계적으로 말하자면 algorithm을 RTL로 변환하는 과정을 의미합니다. "기계적"이란 용어를 사용한 건 말이 그렇다는 것을 알려드리고 싶어서입니다. ^^;
실무에서 보면, algorithm을 전공하신 분과 computer architecture/ASIC을 전공하신 분이 실무에서 어느 정도 일하다가 동일한 작업을 수행하기 위하여 RTL을 만들때 보면 전혀 다른 RTL을 만들어낼때가 있는데, 가장 큰 이유는 어느 추상화 수준에 초점을 맞추었느냐에 차이가 있고, 두 번째는 ASIC 전공자들은 알고리즘 자체를 볼때 하드웨어 구현을 고려하여 하드웨어에 최적화된 알고리즘을 생각하는 반면, 많은 알고리즘 전공자 분들께서는 software적인 최적화 알고리즘을 많이 생각해 내십니다. (에고.. 그냥 이야기하다가 너무 벗어났네요..여하튼.. 저는 각 전공분야에서 보는 관점이 다르다..라는 이야길 하고 싶었는데.. 쩝. ^^;)

검증에서는 약간 더 많은 추상화 단계를 지닙니다. 사실 검증이라기 보다는 modeling이라는 표현이 맞겠습니다. 이건 model의 정확성과 수행 시간간의 상관관계 때문에 아주 정확하지 않아도 되는 부분은 추상적으로 표현해서 속도를 빠르게 할 수 있기 때문이지요.

예를 들어, gate 수준으로 구현된 netlist simulation보다 RTL simulation이 훨씬 빠른 것이 당연하고, RTL simulation보다 대략적인 functional model을 이용하는 것이 더 빠르니까요.

이 functional model은 약간 더 세분하면

• Transaction level model; 사실 각 모듈 간의 동작만을 정의하는 것이지요. 내부 동작 자체를 구현할 수도 안할 수도 있는데, 일반적으로 '추상화 수준이 높다'고 이야기 할때는 내부 동작은 구현하지 않고 모듈의 transaction만을 나타낼 때입니다.
• Untimed functional model; transaction level도 untimed와 timed로 나뉘는데 시간에 대한 정보 포함 여부에 따라 나눕니다. 그냥 읽고/쓰고.. 이런식으로 하면 untimed이고, 가장 추상화 수준이 높다고 봅니다.
• Timed functional model; timed는 transaction의 time정보가 있으므로, 약간은 더 구체화 된 수준입니다.

대략 이런식으로 나눕니다. 물론, 이것 이외에도 behavior level을 나누는 형태로

• bus functional model(BFM) - bus functional model은 사실 transaction level model과 별 차이 없다고 생각되는데 많은 경우 pin accuracy가 있느냐를 가지고 나눕니다. 말 그대로 모듈의 출력/버스 수준에서의 동작만을 기술한 것입니다. 알고리즘이 들어간 블럭의 경우 이런거 만들기 쉽습니다. 
• bus cycle accurate model - timed functional model과 유사하죠.
• cycle accurate model - 시스템 클럭 수준에서의 동작을 맞추어 주는 수준입니다.

둘 사이에 많은 유사점이 있는데, 큰 사항은 transaction을 추상화 할 것이냐 차이겠습니다.

사실 pipelined processor와 같은 control 위주의 모델에서는 transaction model이 크게 편하지 않습니다. 어짜피 명령어 fetching 이후에 몇번째 사이클에서 data bus에 어떤 종류의 transaction이 발생할지를 알아내기 위해서는 어느 정도 구체화를 해야하니까요. 하지만, 통신 모델이라던지 연산 모델에서는 이게 상당히 쉽습니다. latency정도만 알면 연산하고 latency이후에 결과를 내놓는 형태로 구현되니까요. 그래서 알고리즘, 통신 쪽에서 transaction model이 각광받고 있고, ASIC에서 이쪽 분야가 차지하는 비중을 생각할때 이 모델들이 중요시 되는 것이겠지요. ^^;

추가적으로 검증에서는 어떤 수를 써서라도 추상화 레벨을 높여주는 것이 필요합니다. 왜냐하면, 더 정확한 검증이란 더 많은 검증 벡터를 기존 벡터가 cover하지 못한 부분에 generation해 주어야 하고, 많은 검증 벡터를 주어진 시간안에 수행하여 coverage를 높이기 위해서는 모델이 더 빨라져야 하며, 이를 가장 보장해주는 방법이 추상화 수준을 높이는 것이기 때문입니다.  ^^;

p.s. system verilog의 verification feature(class나 dynamic array, queue같은..)가 지원되는 "저가" simualtor 좋은 거 없나요? ㅎㅎ

Tapeout 직전에 발생한 여러가지 문제들이 좋은 방향으로 해결되었습니다.
칩쟁이들한테 칩이란 항상 엔지니어의 피와 땀을 요구한다더니만, 별거 아닌 칩이라고 피와 땀까지는 아니더라도 잠과 자유시간을 요구하더군요.

결과적으로 책임감을 가지고 매단계에서 좀더 꼼꼼하게 챙기지 못한 저에게 일차적인 책임이 있다는 것이 사실이겠지요. 같이 일하는 친구들이 처음하는 일이라 이런 저런 사항을 놓칠 수 있다는 걸 충분히 인지했어야 했는데, 저의 나태함으로 Tapeout 직전에서야 비로서 이것 저것 챙겨보고, 그로 인하여 문제를 인지하는 시점이 늦어버렸다는 것이 비극의 시작이었던 것입니다.

그런거 잘 챙겨보라고 회사에서 직급을 높이는 것일텐데, 아직 역할 모델에 적응하지 못한 탓이겠지요.

이번에 정말 많은것을 배웠습니다.
설계에 있어서도 그렇고, 여러가지 관련 사항으로도 그렇고..
처절하게 배운점은 나태해지는 순간 문제가 생긴다는 점입니다.

거의 한 달동안 자유 시간없이 열심히 따라와준 팀원들에게 감사합니다.

이제 불 끄는 역할이 끝났으니, 다시 검증쪽으로 집중하겠습니다. ^^;
글도 좀 더 많아지리라 생각합니다.

DVCon Best Seller 10 보기

DAC06 Best Seller 10 보기

ICCAD06 Best Seller 10 보기

이번달 들어서면서 포스팅이 갑자기 적어졌습니다.

직접적인 이유는 검증 일을 시작하면서, 배경 지식을 쌓아두기 위해서 보는 책과 기사들이 너무 늘어나서 머리속에서 정리가 되기 전에 이 부분에 대하여 포스팅 할 엄두가 안나구요..게다가, 검증 작업을 flow에 맞추어 한번 제대로 해 보려고 시작했는데, 일이 끝나기 전에 어설픈 것을 올리기도 뭐해서 그냥 그냥 시간만 흐르고 있습니다.

주말에 MPR이나 EEtimes news라도 보면 posting할 것인데, 요즘에 주말에도 검증쪽만 파고 있어서요..
게다가, 초기에는 HVL에 대해서도 고민이 많았는데, C와 systemverilog를 이용하는 것으로 방향을 잡았고.. system verilog에 대해서는 저 자신에게 많은 공부가 필요하다고 생각하고 있어서 열심히 파고 있는 중입니다. verification에서는 design과는 달리, language가 가진 모든 힘을 끌어내야지 좋은 검증 환경이 될테니까요.

제대로 해 보려고, Verification Plan을 짜고, DITL document를 쓰고, Breakout document를 작성하면서 checker model, coverage model 같은 것을 구상하고 있는데..

예전에 해 봤던 pseudo random verification이란 것이 얼마나 단순하게 생각해서 한 것인지 자신을 질책하게 됩니다. 그때 조금만 더 앞으로 나갔었다면 지금은 좀 더 좋은 verification infrastructure상에서 일을 하고 있을텐데 말입니다.
개인적으로 이번 프로젝트를 통해서 얻으려고 하는 것 중에 제대로된 검증 환경이 포함되어 있고, 이를 사내에 퍼트리기.. 라는 계획이 있으니까.. 좀더 general하게 만들려고 하는데.. 생각보다 이것이 쉽지 않네요..

처음 한 걸음 부터 너무 크게 내딛을려 하는 것이 아닌가.. 하는 생각도 없잖아 있지만, 이 프로젝트에만 적용될 수 있는 검증 인프라가 되더라도 generalize에 대한 고민을 하면서 작성하면 나중에 확장이 좀더 쉬워지지 않을까 생각됩니다.

머리속이 정리되거나, 약간 더 시간이 된다면 포스팅이 더 많아지겠지요..^^;

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

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

verilog 표준에서 정의된 동작에 대해서 어느정도는 알고 있다고 자부하고 있었는데, 좀더 깊이 알게 되는 기회가 되고 있는 것 같습니다. 얼마전 gil님께서 class와 비슷한 verilog를 말씀하신 이유도 납득이 가구요..

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

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

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

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

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