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이구요)
본문에 나왔듯이 캐시 효율로 봐도 이넘이 더 좋을 듯..
쓰고나서 덧글) 테터에서 코드 하일라이트 기능이 엉켰는지 짜증 지대로.. ㅠㅠ;
안녕하세요. 매일 여기를 들락날락하면서 좋은 글 감사히 읽고 있습니다.(덕분에 Verification에 빠져버렸습니다.ㅎㅎ)
오늘 별안간 문제를 내시길래 처음으로 글을 남기고 도망갑니다. ^^;;;
1. correct
2. 저같은 초보는 SystemVerilog for Verification이 더 나은거 같아요.
3. 어셈코드만 볼때마다 흥미(?)가 쑥쑥.. ^^ 코어설계할 때가 기억나서요..
엇. 제가 아는 형수님이시려나.. 🙂
금방 맞추시는군요.. ^^;
요즘에 이것 저것 치고 들어오는 일이 많아서 저는 언제나 verification에 빠질 수 있을지 모르겠군요. 어셈블리는 그냥 저넘이 보기에는 분명 포인터 상수처럼 작용할텐데..라는 생각때문에 함 봤어요 ^^;
글이 몇개 밀렸다 싶었는데 퀴즈도 있었군요. ^^ 위에 형수님 답글 쓰신 것 보고 자기가 풀고 자기 답이 correct하다는 얘기인줄 알았습니다. ^^;
3번은 포인터 개념을 처음 잡아가던 시기에 data size를 잘못 계산해서 위험한(?) 버그를 만들 수도 있다고, 그냥 포인터를 쓰라는 얘기를 들었던 것 같은데 하드웨어로 내려오면 얘기가 달라지는군요.
무시 무시한 버그를 만들 수 있다는 그 이야기는 아직도 유용한 이야기야요 ^^;
배열을 통해서 데이터 영역을 깰 수 있는 무시무시한 문법이니까요. 🙂
그거야 뭐 포인터를 써도 마찬가지가 아닐까 싶지만.. ㅋㅋ
이때는 assertion을 앞에 적어주는 센스가 있어야 겠지요. 안 그러면 버그 만들고 한참 고생할 수 있으니 말이지요.
참고적으로, 속도를 빠르게 하기 위한 테크닉은 대부분 잘못 사용하면 무시무시한 결과를 초래할 수 있어요. 그런 관점에서 좀 느리더라도 strict type checking을 해주는 것이 좋으냐, 아님 빠른 것이 좋은지를 선택해야 겠지요.