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이구요)
본문에 나왔듯이 캐시 효율로 봐도 이넘이 더 좋을 듯..
쓰고나서 덧글) 테터에서 코드 하일라이트 기능이 엉켰는지 짜증 지대로.. ㅠㅠ;
Tag Archives: SystemVerilog
DVCon의 결과..
질문 게시판의 내용이지만, 답변은 여기에 ^^;
http://theasicguy.com/2009/01/27/dvcon-survey-results-what-do-they-mean/ 에 DVCon Survey 결과가 있었습니다. DVCon은 가끔 언급했지만, verification 부분에서 가장 큰 행사 중의 하나이지요. ESNUG에서도 곧 여러가지 설문 결과나 행사 기간동안 가장 많이 팔린 책들에 대한 언급이 있을 텐데요.. 올 한해 책 지름의 기반이 되겠지요.
여하튼, 설문의 결과는 예상대로.. 라고 말씀드릴 수 있습니다.
Design Language로는 Verilog HDL 이 대세
검증에 있어서는 SystemVerilog가 대세
요약하면 이렇게 되는 거죠..
사실 SystemVerilog가 다음 Verilog HDL에 통합될 예정이기 SystemVerilog가 Verilog HDL로 통합 되었기 때문에 전체적으로 VerilogHDL이 휩쓸고 있다고 볼 수 있습니다.
설계 언어로서 Verilog HDL이 각광 받는 건 사용하기 편해서이기도 하고, 많은 검증된 툴이 존재한다는 점 때문이기도 합니다.
SystemVerilog가 검증 언어로서 각광 받는 이유는 verilog로 부터 물려받은 design 부분의 feature이외에 검증을 위한 assertion, coverage, interface에 대한 지원이 이루어져 있기 때문입니다.
특히 high level modeling에 있어서는 C를 따라갈 수 없겠지만, assertion에 있어서는 완전히 PSL을 밀어내버린 거죠.
이렇게 verilog HDL family가 전체 설계/검증 flow를 장악한 이유는 자명합니다. 한가지로 통합하여 사용할 수 있는 언어가 있으면 다른 언어를 배우고자 하는 사람이 적어지는 건 당연하죠.. 게다가 기존에 알고 있던 문법에 몇 가지 불편했던 부분이 추가되고 , 새로운 개념은 완전히 새롭게 문법이 들어오는 형태로 개선되고 있으니 기존 사용자를 잘 흡수한 것이죠.
매년 나온 Survey Result를 생각하면 나중에 좀더 다양한 아이템에 대한 Survey 결과가 나올 것이라고 봅니다만, 설계나 검증에 종사하시고자 하시는 많은 분들께 verilog HDL을 권할 수 있겟습니다.
(추가)
근데, 더 흥미로운 설문은 (아직 샘플의 수가 너무 적어서 뭐라 말씀드리기 힘듭니다만..), 어떤 Verification methodology를 사용할 예정이냐.. (http://www.doodle.com/participation.html?pollId=u5ust5s73h8y9r62 )는 설문이네요.
제 개인적으로 VMM은 좀 툴에 대해서 까다로워서 원래 좀 그랬고, Teal/Truss는 PC에서 돌리기 힘들어서 확산은 힘들것 같았고..(게다가 PLI/DPI 기반이라는 건 컴파일 할때 험난한 여정을 의미하죠..뭐 system verilog SystemC[1]어짜다 SystemVerilog라고 쓴건지 모르겠네요 ^^;도 마찬가지지요.. 이런 C/C++ 기반의 방법들은 gcc 버전에 민감하게 만들어지면 고생길이 열립니다..특히 C++과의 연결은.. )..
여하튼 생각보다 OVM이 지지를 많이 받고 있군요.. 시뮬레이션에 많이 사용되는 cadence와 mentor의 연합이니 그럴 수 있겠다는 생각이 (반면에 약간 툴 버젼을 가리는 것은 아깝습니다. – 물론 지원되는 system verilog 문법 때문에 어쩔 수 없겠습니다만..)
p.s.
2월 들어 첫 딸 돌잔치 준비를 열심히 하느라 집에서 블로그에 들어올 시간이 없었습니다. ^^;
돌 사진 찍은 거 보정하는 것과 성장 동영상 만드는 것을 미뤄두고 있다가 2월 내내 꼬박 퇴근 후 시간을 투자해야 했으니까요.
이제 좀 여유로워졌으니 다시 글이 올라갈 것이라고 생각 해 봅니다. (천성이 양치기 소년이라.. 믿을 수 있을지는..)
Notes & References
↑1 | 어짜다 SystemVerilog라고 쓴건지 모르겠네요 ^^; |
---|
잘하는 짓들이다..
어떤 것을 하던지 방법론이라는 것이 중요합니다. 잘 짜여진 방법론은 이후의 모든 일에 영향을 주기 때문이지요.
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의 형태를 취할 것이라는 점입니다만.. 향후에 어떻게 흘러갈 것인지는 알 수 없겠지요.