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이구요)
본문에 나왔듯이 캐시 효율로 봐도 이넘이 더 좋을 듯..


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

어떤 것을 하던지 방법론이라는 것이 중요합니다. 잘 짜여진 방법론은 이후의 모든 일에 영향을 주기 때문이지요.

SystemVerilog 기반의 검증은 현재 VMM, AVM 등 여러가지 방법론을 지니고 있습니다(사실 방법론이라기보다 verification library라는 표현이 맞을 지 모르겠습니다만..). 그런데, 문제는 이러한 verification library들이 tool dependent할 요소가 거의 없음에도 불구하고, 실제적으로는 tool dependent하게 만들어졌다는데 있습니다.

예를 들어, VMM을 사용하시려면 synopsys 툴을 구매해야 합니다. 다른 툴에서 VMM을 사용하시려면, 역시 synopsys에서 해당 라이브러리를 결코 적지 않은 돈을 주고 구매해야 합니다. 당연한 이야기일지도 모르겠지만, verification methodology라는 부분을 사용자 편의보다 각 사의 market share를 늘리는 방편으로 사용하고 있는 것이겠지요.

표준화된 sugar가 있는 Assertion 분야에서 OVL이 아직도 힘을 얻고 있는 이유는 tool이 해당 부분을 따로 지원할 필요없이 간단히 `include 구문으로  assertion이 가능하다는데 있지 않을까요. (상대적으로 sugar는 tool에서 지원하지 않으면 쓸 수 없지요)

이번에 Cadence와 Mentor가 OVM(Open Verification Methodology)를 만들기 위한 기구를 설립했는데, 문제는 synopsys가 참여하지 않았다는 것이지이요. (혹은 cadence와 mentor가 상대적으로 systemverilog기반의 검증에서 선두를 달리고 있는 Synopsys를 견재하려고 한 짓일 확률도 높습니다만.. 여하튼)

결과적으로 OVM은 또 다시 반쪽이 될 확률이 높아졌습니다. 그나마 다행인것은 OVM의 implementation은 open source의 형태를 취할 것이라는 점입니다만.. 향후에 어떻게 흘러갈 것인지는 알 수 없겠지요.

등록은:  http://www.synopsys.com/news/events/sem ··· sem.html




≫ Primary Multi Track Agenda

Track A1 Abstract
Introduction to SystemVerilog testbench with the VMM Methodology
- Making the move from directed tests to constrained-random verification
- SystemVerilog testbench basics
- Strategies for adopting SystemVerilog testbench and the Verification Methodology Manual (VMM)

Debug and Analysis with DVE
- An overview of DVE (Discovery Visualization Environment)
- Using DVE for assertion, testbench and SystemC debug
- Using DVE with analog simulatioins

Track A2 Abstract
Formal Verification with Megellan
- Making the move from directed tests to constrained-random verification
- SystemVerilog testbench basics
- Strategies for adopting SystemVerilog testbench and the Verification Methodology Manual (VMM)

Verification of Low Power Designs
- An overview of DVE (Discovery Visualization Environment)
- Using DVE for assertion, testbench and SystemC debug
- Using DVE with analog simulatioins

Track B1 Abstract
Introduction to VMM Applications
- Register modeling and verification
- Block-to-system reuse and memory allocation techniques
- Data stream scoreboarding

Using Verification IP in a VMM Environment
- Using transaction-level SystemC models in a SystemVerilog environment
- Transaction-level Interface techniques in VCS
- Debugging mixed-abstraction, mixed-language environments in DVE

Track B2 Abstract
SystemC and SystemVerilog Design Verification with VCS
- Using transaction-level SystemC models in a SystemVerilog environment
- Transaction-level Interface techniques in VCS
- Debugging mixed-abstraction, mixed-language environments in DVE

Accelerating Verification using the VMM Hardware Abstraction Layer with ZeBu
- Introduction to hardware-assisted acceleration with the EVE ZeBu platform
- Using the VMM HAL to reuse a common testbench for simulation and acceleration
- Implementing acceleration-friendly checkers, monitors and data generators

Track C1 Abstract
Verifying Performance and Reliability of Nanometer Designs with HSIMplus
- Solutions for post-layout analysis with millions of extracted RC parasitics
- Verifying performance and reliability for IR drop effects and electromigration

Mixed-Signal Verification (MSV) challenges and solutions
- Bottom-up, mixed-signal Verification w/ Verilog, VHDL, & SPICE
- Mixed-language / Mixed-level simulation top down design and verification
- Transistor-level sign-off: why is this important?

Track C2 Abstract
Advanced high-accuracy circuit simulation with HSPICE
- Performing faster simulations
- Ensuring silicon accuracy with advanced models
- Improving productivity with behavioral modeling
- Employing high-speed signal integrity analysis capabilities
- Simulating process variability effects
- Accurately predicting PLL and VCO performance

"추상화 수준", "추상화 단계"라 불리는 용어이지요. 아마도 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 좋은 거 없나요? ㅎㅎ

요즘에 프로젝트 마무리 관계로 약간 바빠서 이 책을 읽는건 좀 뒤로 미루어야 할 것 같습니다만..

아기다리 고기다리던 책이 왔습니다. ^^;

여기에서 기대하고 있다고 말씀드렸던,writing testbenches using systemverilog와 Verification Methodolgy Manual for SystemVerilog 입니다.

이 책은 한 2주일후 쯤에 아시는 분은 아실(^^;) 건대 아저씨께 맡겨두겠습니다.
필요하신 분은 2주쯤 후에 건대 아저씨께 문의하세요~

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를 말씀하신 이유도 납득이 가구요..