|
'verilog HDL'에 해당되는 글 12건
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()를 이용하는 방법입니다.
always @(posedge clk or negedge rst_x) begin
$run_sim_calltf(xxxx);
end
즉, run_sim()을 calltf()의 callback function으로 등록하는 겁니다. 그리고, 매 클럭 calltf()를 불러주는 것이지요.
근데, simualtor의 이전 상태를 계속적으로 보존해야 하는 경우에는 매 클럭 새롭게 호출되는 calltf()를 이용할 때 문제가 있을 수 있습니다. (사실 그리 어려운 일은 아닙니다만, 예를 들기 위하여 ^^ ) 그래서, 내용을 보존하고 싶을 때는 misctf()를 사용하는 것도 괜찮습니다. misctf()는 원래 verilog simulation의 이런 저런 정리 작업을 하는데 사용하는 목적으로 만드는 건데요. 아래와 같이도 사용할 수 있습니다.
initial begin
$run_sim_misctf(data, reason, paramvc);
end
뭐 이런 느낌입니다. misctf()의 경우 시뮬레이터의 초기 시에 simulator에 연결된 이후에 simulator의 종료 시까지 계속 머무르면서 파라미터의 값이 변경 될 때 마다 제어권을 가집니다. 이 파라미터의 변화시마다 클럭이 변화되었는지 확인하고, 클럭이 변화하였을 때 값을 호출하면 되겠습니다.
아래는 한 4년 전에 만든 PLI 모델중의 misctf부분인데요.. 실제 구현은 없으니 공개해도 별 문제 없을 것입니다. ^^; 대략 이런 느낌으로 만드시면 됩니다. :)
다음 번에는 좀 더 재미난 PLI 함수를 다루어보죠.. (아.. VPI는 초반에 좀 다루지 않네요. ^^; Blog의 예제를 위해서라도 예전에 acc_와 tf_를 이용해서 만든 PLI 모델을 업그레이드해야겠군요. )
int misctf_proc(int data, int reason,int paramvc) {
static int reset_called = FALSE;
int POInt;
switch (reason) {
case reason_paramvc : { // 파라미터의 값 변화로 인한 호출의 경우
if (tf_getp(PIN_RST_X) == 0) { // reset state
// 아래의 형태는 초기 조건에서의 리셋 호출을 위하여 사용된다.
if (reset_called == FALSE || paramvc == PIN_RST_X) {
io_printf("$AE32KB_RUN : CORE RESET CONDITION\n");
// 실제적인 reset을 수행한다.
reset_called = TRUE;
POInt = 0;
if (tf_getp(PIN_OSIEN) == 1) {
POInt = POInt | OSIEN;
if (tf_getp(PIN_OSIROM) == 1) {
POInt = POInt | OSIROM;
}
}
ResetCore(POInt);
}
}
else if ( paramvc == PIN_CLK ) {
if (is_posedge(PIN_CLK,paramvc) == TRUE) {
// 변경된 모든 입력 값을 받아서 반영한다.
apply_input();
io_printf("%s : CLOCK POSEDGE\n", tf_strgettime());
EndClock();
// end_clock함수
StartClock();
// start clock 함수
// 변경된 데이터를 기반으로 핀과 레지스터를 변경시킨다.
}
}
break;
}
// case
default :
break;
}
// apply outputs
apply_output();
return 0;
}
이제 EISC processor도 어느 정도 정비를 마치고, 빠른 미래에 좀 더 공격적인 마케팅을 시작할 예정입니다. ^^; 많이 기대를 해 주세요.. 특히 학생분들께 좋은 기회가 많이 돌아가도록 노력 중입니다.
2007/06/11 23:45
2007/06/11 23:45
Trackback Address :: http://babyworm.net/tatter/trackback/177
뭐랄까요.. 요즘 이런 저런 일로 바쁘다보니, 사람이 좀 얇팍하게 글을 쓰게되네요. :)
(퇴고 없이 그냥 온라인에서 쓰는 글이라 앞뒤가 없을지도 모르겠습니다.)
오늘은 여러분들께서 perl을 이용해서 Verilog HDL을 위한 testbench를 작성할 때 간단히 명령어 해석기를 만들어 사용하는 방법을 알려드리죠.
이 방법은 제가 JTAG을 위한 protocol을 만들다가 생각해낸 방법인데요.. 아주 유용하게 쓰고 있습니다.
얼마전 AXI FileReader와 같은 간단한 명령어 해석기가 필요할 때도 쉽게 적용할 수 있구요.
예를들어, JTAG을 위한 몇몇 명령을 만들고, 이 명령을 이용해서 HDL model을 위한 신호 입력으로 변환시키는 과정을 생각해 봅시다.
1. 필요한 함수를 정합니다.
대충 다음과 같은 함수를 쓸 수 있겠지요?
rtnval = get_id();
do_intest(serin);
do_extest(serin);
2.
해당 함수를 perl에서 subroutine으로 만들어갑니다.
뭐, subroutine을 만드는 방법은 쉽죠?
3.
이 부분이 제일 중요한데요..
xxx.pl <filename.input>
이런식으로 처리하려면, 중간에 다음과 같은 루틴을 넣어줍니다.
do "$ARGV[0]";
위의 한 행은 해당 파일($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 언어가 사랑받는 것이겠죠.
2007/06/04 23:46
2007/06/04 23:46
Trackback Address :: http://babyworm.net/tatter/trackback/175
EEtimes를 보니 VHDL 2006 표준이 Accellera에서 승인되어서 IEEE standard 승인을 기다리게 되었다고 합니다. VHDL은 제 블로그에서도 몇번 다루었듯이, 초반의 열광적인 지지와는 반대로 설계 언어로서는 Verilog에 비하여 점유율을 높이지 못하고 있었지요. (Gartner Dataquest의 EDA 분석책임자인 Gary Smith 씨에 의하면 오늘날 하이엔드 디자인에서 VHDL 사용이 줄고있다고 합니다. [데이터 출처: EETimes]) Verilog의 경우 system verilog에서 assertion과 같은 검증 기능과 더불어 몇몇 검증에 관련된 좋은 기능들이 추가 되었으며, verilog 2005 표준에서 system verilog(IEEE-1800)와 기존의 verilog 표준(IEEE-1364 2001)을 합쳐서 IEEE-1364 2005로 개정한 것이지요. 지금 verification guild와 같은 곳을 가보면 verification의 많은 부분이 system verilog 위주로 진행되는 분위기가 감지됩니다. (comp.lang.verilog에서도 그렇구요..) 이러한 verilog의 강공에 대적하기 위해서, VHDL은 assertion language의 표준인 PSL(예전에 sugar로 불리웠던)을 VHDL 표준에 과감히 포함시켜 버렸습니다. ! 또 다른 주목할 만한 부분은 IP 보호 기능입니다. 사실 이 기능의 경우 verilog에서는 cadence verilog-XL 시절 부터 있었던 기능이지만, tool dependent하기 때문에 약간 문제이기는 했습니다.(verilog simulation에 있어서 verilog-XL이나, NC-verilog와 같은 툴이 거의 표준처럼 사용되고 있는 상황이니 큰 문제는 없겠습니다만..(ESNUG참조)) 과연 점점 사용자 계층이 엷어져가는 VHDL이 이번 표준으로 얼마나 사용자를 되 찾아올지 의문입니다. 왜냐하면, Verilog에서는 기본적으로 강력한 구조적 설계 기능에 검증 기능을 더하는 방향으로 확장되고 있는 반면, VHDL은 기본적으로 behavioral design/verification에 (verilog에 비해)적합한 형태였기 때문이지요. 즉, 설계 부분의 편의성에 있어서는 그리 향상된 것이 없어보인다는 것이 좀 아쉽네요..
babyworm
2006/11/16 20:38
2006/11/16 20:38
Trackback Address :: http://babyworm.net/tatter/trackback/104
요즘에 리퍼러 로그를 보니, 검색을 통하여 들어오시는 분들이 상당하시군요..
(덕분에 gzip 플러그인을 통해 전송량을 절반으로 줄여놨었지만, 다시 트래픽이 차오르고 있습니다. ㅠㅠ; 물론, 많은 분들이 찾아주시는 건 좋은 일이지요.. 이 분야에 관심 있는 분들이 많다는 것이니까요..) 이 포스팅은 리퍼러 로그에 남은 검색어를 통하여 살펴본, 제 블로그에 방문하시는 분들이 관심을 가지는 것에 대한 친절(?)한 답변들입니다. ^^;
verilog 관련
가장 많은 검색어는 verilog/VHDL 입니다. 요즘에 이걸로 수업받으시는 분들이 많고, 요즘이 term project 철이라서 검색 순위가 급증하고 있는 것이 아닌가 생각합니다.
* Verilog와 VHDL중에 어떤것이 더 좋은가..
둘 다 좋은 언어입니다. verilog가 "설계"라는 목적에 좀더 부합하고, VHDL이 "검증"에 더 편리한 기능을 제공합니다. 개인적으로 생각하기에 verilog가 설계만 따진다면 더 편하다고 생각합니다.
* VHDL -> verilog변환, verilog ->VHDL 변환
가끔 뉴스 그룹에서 이거 변환 프로그램 찾으시는 분들도 봤는데, vhdl2v 같은 전용 변환 프로그램이 있기는 합니다만, 시도해보시면 상당한 스트레스를 받을 것이라 생각합니다. ESNUG에 나온 내용을 붙이자면, 잘 안된다! 입니다. ESNUG내용보기 http://www.deepchip.com/items/0386-11.html
Hello John,
I'm scrambling my head over this...
I am using VHDL-2-Verilog translator by ASC. I could not translate my
functions from VHDL to Verilog -- they are simply skipped!
My VHDL source code has a package which has some function declarations
(eg. calculate_lrc(data)) and definitions in it. The problem is when I try
to convert the package or code from VHDL to Verilog, the functions are
skipped. So the verilog file just has constants and no "function", as if
there was no function declaration in the original file.
I tried using -Function_Map option but it would only allow me to keep the
original function call but the parameters are skipped. Also no function
conversions.
So does ASC's vhdl2v not support function and procedure conversions from
VHDL to Verilog?
- Rakesh Mehta
Nortel Networks
대안으로는 verilog나 vhdl이나 동일한 중간 포맷으로 해석해서 사용하는 툴을 쓰는 건데..
제가 사용해본 것은 Summit design의 visual HDL로 변환하는 것이었는데, 역시 structural 설계는 잘되는데 약간 behavioral하게 설계된건 잘 안되었습니다.
만일 동작만 보면되고, 안의 내용은 필요없다! 라고 생각하신다면, synopsys에서 합성한 후에 원하는 format으로 netlist를 출력해서 시뮬레이션에 사용하는 것이 제일 속편합니다. 물론, simulation용 라이브러리를 물어야 하지만 말입니다.
(뭐, 요즘엔 ncsim이나 modelsim이나 모두 VHDL/Verilog를 single kernel에서 시뮬레이트해서 이런 필요는 없겠지만.. 라이센스 문제가 아닌 이상엔 말이죠..)
* verilog에서의 #
위의 문법은 원하는 만큼 지연을 발생시키는 것입니다. 합성시에는 무시됩니다.
* verilog에서의 <=과 = 의 차이
blocking assignment와 non-blocking assignment를 혼동하시는 분들이 생각보다 많은데요..(저도 verilog 처음에 잘 몰랐습니다.) blocking assignment는 "시간이 흐르지 않는 상태(흐르지 않게 block하면서)에서 값이 저장된다"이구요.. non-blocking assignment는 "시간이 흐르면서 값이 저장된다" 입니다.
즉, 아래와 같은 연속된 assign의 경우 위의 blocking을 사용하였을때 d는 a의 값을 가지게 됩니다. 값의 할당 자체에 시간이 소모되지 않도록 하나의 할당이 끝날때까지 시간을 멈추기 때문입니다...
그런데, 밑의 nonblocking 예에서는 "값을 할당하자"라는 것은 현 시점에서, 값이 갱신되는 것은 delta delay이후에 이루어지게 됩니다. 왜냐하면, 값이 할당되든 안되든 값을 할당하겠다는 3개의 문장을 모두 보고나서 delta delay이후에 값이 갱신되기 때문이죠. b = a;
c = b;
d = c;
---
b <= a;
c <= b;
d <= c;
이해 되시려나요?
* verilog PLI 관련
예전에 계속쓰려다 잠시 중단되었는데, PLI 관련 내용은 요즘에 제 작업 관계로 앞으로 1~2개월동안 자주 올라올 확률이 높습니다. 테스트 벤치 생성 유닛과 scoreboard를 C로 만들고 이걸 verilog PLI로 연결할 예정이거든요..
기대하셔도 좋을듯..
다른 검색을 통한 리퍼러 로그..
Design Compiler와 VCS, Modelsim에 대한 검색이 많았습니다.
사실, 툴에 대해서는 소개나, 새소식만 하고 있어서 별다른 내용이 없었는데 말이죠.. ^^;
참.. 시뮬레이션 하는 방법은 quick reference guide를 살펴보시면 쉽게 하실 수 있습니다. ^^;
프로세서에 대한 검색으로 들어오신 분들도 많았습니다. intel, AMD, ARM, calmRISC, M-Core, EISC(감사합니다.)
블로그에 좀더 프로세서에 관련된 좋은 내용을 적을까 싶기도 한데.. 이쪽 분야 하시는 분이 워낙 적어서 누가 관심이 있을까.. 라는 씨니컬한 마음이 될때도 있습니다. ^^;
아.. 특이한것이 virtual UART를 검색해서 들어오신 분이 계시던데..
제가 이 블로그에서 PLI + TCL/TK를 조합한 virtual UART라는 걸 만든적이 있다고 말씀을 드린적이 있는데, 검색해서 들어오신분은 아마 회사분이 아니실까 생각합니다. 회사분이시라면 인트라넷에 올라간 virtual UART 관련 메뉴얼을 참조하세요.. 소스코드와 작성법이 다 있으니까요..^^;
찾아주신 분들 모두 감사드립니다. .gif)
2006/11/10 17:26
2006/11/10 17:26
Trackback Address :: http://babyworm.net/tatter/trackback/97
verilog news group에는 여러가지 verilog 관련 이야기가 나오는데.. 몇가지만 옮겨 봅니다.
1. Implicit Zero Padding?
verilog의 bit 확장에 대한 부분인데요.. 간략히 써보면 다음과 같은 질문입니다. verilog가 큰 수에 작은수를 대입할때 '0'으로 채우는 것으로 알고 있어. module tilde (output reg[7:0] z, input [3:0] a);
always @* begin
z = ~a;
end
endmodule
위의 예에서도 상위 4비트는 '0'이 되어야 겠지? 하위 4비트는 당연히 a의 반전이겠지만 말야.. 근데, 적어도 modelsim에서는 상위 4비트가 항상 1이 된다! 내가 잘못 이해한거야? 아님 모델심 문제야? 여기에 대해서 여러가지 대답들이 있는데.. 대답을 보기전에 우선 몇가지 정리해 보시지요..^^;
기본적으로 큰 값에 대한 assign시에 RHS의 값이 LHS값보다 작은 경우 그 값은 확장되면서 상위값은 '0'으로 채워집니다. 왜냐하면 verilog에서 기본적으로 다루어지는 수치형은 'unsigned'이기 때문이죠.
verilog 2001에서는 signed라는 예약어가 들어가서 signed 수로 인식되기도 합니다만, 위의 예에서는 관련이 없겠지요? 질문자는 assign 동작이 ~(inversion)보다 늦게 일어나므로, inversion 이후에 assign이 일어나야 하며, assign과정에서 확장 동작이 일어나야 하는데, 왜 동작은 inversion이전에 크기 확장이 일어난것 같이 동작하느냐는 것이 가장 중요한 질문의 요지입니다. 그런데, 위의 예에서는 왜 '1'로 채워지는 것일까요? 이것은 verilog에서 연산을 처리하는 rule과 관계가 있습니다.
이 문제에 대하여 지존급의 대답을 해준 케이던스의 sharp님의 글을 보면 아주 명확히 설명하고 있습니다. Verilog first determines the width of an expression based on the largest operand in it, including the LHS of any assignment. Then it extends all operands (actually, all context-determined operands) to the width of their expression before performing any operations. All extensions are done as early as possible, in an attempt to avoid overflows in intermediate results. 가장 중요한 verilog 연산에서의 크기 확장 법칙이 위의 법칙입니다. 즉, 연산 이전에 LHS를 포함한 모든 연산 요소를 살펴보아서 가장 큰 값에 맞추어 값을 확장하는 것입니다. 이는 "C"언어에서의 type casting rule과 완전히 다르기 때문에 많은 분들이 헷깔리게 되는 것이지요. sharp님이 추가적으로 설명한 부분은 사실 저도 정확히는 모르고 있던 부분인데.. (경험으로는 알고 있었습니다만, 명확한 이론은 없었습니다.) 연산에 따른 확장에 대해서 알려주고 있습니다. When the result of an operation will have a fixed width regardless of the width of its operand, there is no reason for the operand to care about the width of the context. This is true of the reduction operators. The result will always be 1 bit, no matter what the operand width is. There is no point in extending the operand. Instead, the 1-bit result will be extended to the width of the expression as soon as it is produced. The operand of a reduction operator is
self-determined.
On the other hand, all the bits of a bitwise NOT will be available to the expression containing it, and may be assigned or used in another bitwise operation. So the operand of a bitwise NOT is context-determined. But one has a self-determined operand and the other has a context-determined operand. The Verilog LRM fully specifies this for all the operands of all the operators. They generally follow a logical scheme that makes sense. And again, in most cases they are designed to give reasonable results, so that most users don't have to worry about them.
상당히 어려운 이야기인 것으로 보입니다만, 실은 같은 width를 보장해야 하는 연산과 그렇지 않은 연산이 있고, 이에 따라 확장을 하는 부분이 있다.. 라고 요약하시면 되겠습니다. 위의 룰은 처음 설명 드린 룰의 보충내용이므로 그리 중요하지는 않습니다.
이러한 문제는 "고민을 시작하면" 엄청나게 신경쓰이는 문제이므로, 일반적인 coding style을 따져서 문제가 될만한 부분을 초기에 잡아나가는 것이 현명하겠습니다.
즉, 1) verilog coding시에서 width 지정을 정확히 하고, 확장이 필요한 경우 명시적으로 concat operation을 쓰자. 2)일반적으로 width를 지정하지 않은 상수는 verilog에서 32bit으로 처리되므로, 이로 인해 원하지 않는 동작을 피하고 싶으시다면, 항상 상수를 지정할때 width를 지정하는 하자.
이런 일반 룰만 지키신다면 머리 아플일이 없겠지요..^^; 좋은 Coding Style의 존재 이유가 "불명확한 코드로 나중에 머리 아프지 말고 코딩 부터 잘하자.."이런 것이니까요..^^;
추가적으로..
comp.lang.verilog에 인터뷰에서 asynchonous설계시 주의할점에 대해서 물어봤는데.. 대답을 못했다는 내용도 있네요.^^; 얼마전에 이야기한 metastable에 대한 이야기를 묻는 것이지요.. 정말 많이 물어보는 질문이기는 한가보군요.. |
