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 언어가 사랑받는 것이겠죠.

요즘에 리퍼러 로그를 보니, 검색을 통하여 들어오시는 분들이 상당하시군요..
(덕분에 gzip 플러그인을 통해 전송량을 절반으로 줄여놨었지만, 다시 트래픽이 차오르고 있습니다. ㅠㅠ; 물론, 많은 분들이 찾아주시는 건 좋은 일이지요.. 이 분야에 관심 있는 분들이 많다는 것이니까요..)

이 포스팅은 리퍼러 로그에 남은 검색어를 통하여 살펴본, 제 블로그에 방문하시는 분들이 관심을 가지는 것에 대한 친절(?)한 답변들입니다. ^^;

verilog 관련
가장 많은 검색어는 verilog/VHDL 입니다. 요즘에 이걸로 수업받으시는 분들이 많고, 요즘이 term project 철이라서 검색 순위가 급증하고 있는 것이 아닌가 생각합니다.

* Verilog와 VHDL중에 어떤것이 더 좋은가..
둘 다 좋은 언어입니다. verilog가 "설계"라는 목적에 좀더 부합하고, VHDL이 "검증"에 더 편리한 기능을 제공합니다. 개인적으로 생각하기에 verilog가 설계만 따진다면 더 편하다고 생각합니다.

* VHDL -> verilog변환, verilog ->VHDL 변환
가끔 뉴스 그룹에서 이거 변환 프로그램 찾으시는 분들도 봤는데, vhdl2v 같은 전용 변환 프로그램이 있기는 합니다만, 시도해보시면 상당한 스트레스를 받을 것이라 생각합니다.  ESNUG에 나온 내용을 붙이자면, 잘 안된다! 입니다.

ESNUG내용보기

대안으로는 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이후에 값이 갱신되기 때문이죠.

이해 되시려나요?

* 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 관련 메뉴얼을 참조하세요.. 소스코드와 작성법이 다 있으니까요..^^;

찾아주신 분들 모두 감사드립니다.

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에 대한 이야기를 묻는 것이지요.. 정말 많이 물어보는 질문이기는 한가보군요..

테터보드나 WordPress에서 GeSHi라는 문법 강조기를 이용하여 code highlighting 모듈이 많이 만들어지고 있습니다. 제가 사용하고 있는 Lang-to-HTML도 그렇구요..

아쉬운 점은 제가 블로그상에 자주 포스팅하는 내용이 verilog HDL이라는 하드웨어 설계/기술 언어를 사용해서 설명되는 경우가 많은데.. GeSHi에는 verilog HDL code에 대한 하이라이팅 기능이 없다는 것이었습니다.
그래서, 그냥 GeSHi상에서 적용할 수 있는 verilog 문법 파일을 하나 만들어봤습니다.

GeSHi의 문법파일 지정 방식이 직관적이어서 처음 생각했던것 보다 빠르게 만들수 있었습니다. ^^;

적용은 간단합니다.
아래 파일의 압축을 해제하셔서,  플러그인의 geshi디렉토리에 올리시고, Language이름은 Verilog로 지정하시면 됩니다. 예를들어 Lang-to-html의 경우 code type=Verilog 으로 쓰시면 됩니다.

verilog.rar

예전에는 verilog동호회니 asic동호회니 나름대로 활발히 활동했었는데, 점점 숙제도와주기 동호회가 되가서 잘 안가게 되었습니다.

정말 오랫만에 오늘 verilog동호회에 갔는데, 위의 질문이 있더군요. 저 질문은 제가 대답한 것만 한 3번 정도이고.. 자세히 정리해서 쓴적도 한번 있을 정도로 verilog를 배우시는 분들에게 있어서 이해가 어려운 부분이듯 합니다. (이제와서야 이렇게 이야기하지만, 되집어 생각해보면 저도 처음 배울때 위의 것의 차이를 잘 몰랐던것 같구요.)

사실 verilog라는 언어자체보다는 설계가 우선인 것이고, verilog는 도구에 불과하지만, 도구를 잘 아는 것도 많은 도움이 되는 것이 사실입니다. 또한, verilog의 timing 정의라던지 신호의 driving에 대해서 어느정도 명확히 이해하면 PLI programming으로 좀 정교한 모델을 만들때 크게 도움이 됩니다.
저 역시도 프로세서 모델의 PLI모델을 만들면서 많은 부분을 좀더 정확히 알게 되었으니까요..

여하튼. 오늘 이야기 할 부분은 바로 wire와 reg, 정확히 이야기하자면 net과 reg라고 부르는 것이 더 맞을 듯 합니다.

우선, verilog를 정의하고 있는 IEEE 1364-2001 표준을 보면 net에 대해서(특히 wire에 대해서)는 다음과 같이 기술하고 있습니다.

The wire and tri nets connect elements. The net types wire and tri shall be identical in their syntax and functions; two names are provided so that the name of a net can indicate the purpose of the net in that model. A wire net can be used for nets that are driven by a single gate or continuous assignment. The tri net type can be used where multiple drivers drive a net.

Assignments to a reg are made by procedural assignments (see 6.2 and 9.2). Since the reg holds a value between assignments, it can be used to model hardware registers. Edge-sensitive (i.e., flip-flops) and level sensitive (i.e., RS and transparent latches) storage elements can be modeled. A reg needs not represent a hardware storage element since it can also be used to represent combinatorial logic.

지난번에 이야기하고, 너무 많은 시간이 지났군요..
acc_, tf_ 와 다르게 VPI는 handle이라는 데이터 구조체를 이용하여 verilog simulator의 데이터 구조체에 접근합니다.

acc_, tf_ 의 경우에도 handle(정확히는 handle이라 부를만한 것)이 없는 건 아니지만, verilog simulator의 실제적인 데이터 object에 직접 접근한다는 개념이 강했습니다. 따라서, 필요한 object의 형태, 크기등의 여러가지 정보를 하나 하나 챙겨봐야 했지요.
하지만, VPI는 handle이라 불리는 복합적인 데이터 구조체를 이용하고, 이를 기반으로 편하게 verilog simulator의 데이터에 접근할 수 있습니다.

verilog VPI의 handle은 다음과 같이 선언하면 됩니다. (이를 위해서 vpi_user.h 가 include되어야 하는 건 당연하겠죠?)

handle은 verilog simulator와 PLI루틴과의 관계를 정립할때 여러가지 형태를 가질 수 있도록 되어 있는데,  기본적으로 1-to-1 관계, 1-to-many관계, many-to-one의 관계로 나뉠수 있습니다.

각각은 말 그대로 verilog simulator의 객체를 PLI함수에서 볼때 어떻게 볼지에 대한 내용입니다. 이건 예제를 하나씩 보면서 배우면 되겠지요.

우선, verilog simulator에 접근해서 handle을 얻어와야 합니다.
이러한 동작은 vpi_handle(), vpi_iterate(), vpi_scan()과 같은 함수를 통하여 이루어집니다.
이 중에 vpi_handle()은 one-to-one관계를 만들어냅니다.

위의 함수는 형태와 대상 핸들명을 정하고 이에 맞는 핸들을 얻어오는 것입니다.
이때 형태를 vpiModule로 하면 verilog simulator의 모듈을 얻을 수 있겠고, callback 함수의 핸들을 얻으려면 vpiSysTfCall를 형태로 지정하면 되겠습니다.

vpiSysTfCall 의 경우 우리가 정의할 시스템 콜에 대하여 적용가능합니다.
즉, 우리가 시스템 콜을 정의하고, 이것을 verilog simulator에서 사용하는 경우에 이 형태가 vpiSysTfCall이 되는 것이겠죠. 따라서, 만일 우리가 verilog simulator에서 호출된 PLI함수에 어떤 전달 인자가 나왔는지 확인하려면 기본적으로 vpiSysTfCall이라는 형태의 handle을 받아야 합니다.

받아들인 핸들로부터 전달 인자(이것도 역시 핸들입니다.)를 추출하는 건 vpi_iterate() 함수를 사용합니다.
vpi_iterator는 여러개의 핸들을 몽창~ 추출하는 함수죠.(사실 핸들들을 몽창 이라기 보다, 여러 객체가 존재하는 하나의 핸들이라고 하는 것이 더 맞다고 생각합니다만...)

iterator는 C++, 특히 STL을 사용하시는 분들은 잘 아시겠지만, 반복자라 이야기하는 것은 여러 연속된 데이터를 순회하면서 데이터를 끄집어내는 형태의 데이터 구조를 뜻합니다. (뭐 예를 들어, linked list도 iterator요, array도 iterator죠.. 즉, 하나의 포인터로 순회하면서 여러개의 데이터에 접근 가능한 모든 데이터 형태를 일반화한 말..이라고 하면 좀 쉬울라나요? 더 어려울 라나요?)

자 간단하게 이 부분 까지의 코드를 만들어 볼까요?

이런식이죠.. 이제 다음에는 조금 더~ VPI의 모델에 대해서 알아보죠~

Verilog 사용자가 별로 없는지라(이 이야기에 발끈~하는 엔지니어 분들도 계시겠지만, 사실 C언어 사용자 보다는 적은거 맞잖습니까.., 우리나라 사람들중에 공학도 중에, 전자공학도 중에, verilog HDL을 쓰는 분을 따지면 별로 안되죠..^^) 국내에는 verilog PLI에 대하여 다루고 있는 페이지도 별로 없다.

개인적으로도 verilog PLI 관련 내용은 외국의 웹 페이지나, sutherland의 책을 참조하고 있는데, 국내의 많은 분들도 PLI를 적극적으로 이용하고 있음에 의심에 여지가 없건만 다들 숨기기만 하시니, 참조할 곳이 참 적기만 하다.

책이야기와 더불어 verilog PLI 이야기를 특히 VPI 이야기를 한번 해보려 한다.
뭐, 나도 PLI중의 tf_나 acc_는 좀 써봤지만, VPI는 얼마전에 처음 다루어 보았다.

그래서 공부 겸사 겸사.. 시간 될때 마다 정리해서 올려보려고한다.

우선 이번에는 PLI에 대한 대략적인 틀에 대해서~
(뭐 머리속에 있는 걸 쓰는 것이니 틀린것이 있을지도..)

PLI는 Programming Language Interface, 즉 verilog 에서 C/C++과 같은 언어와의 연동을 위하여 제공하는 일종의 API이다. 예전에 정의된 tf_, acc_(소위 PLI1.0)는 각각의 상황에 맞는 수많은 함수가 존재해서, 적절한 함수만 찾으면 쓰기는 쉽다는 장점이 있었다. (babyworm도 예전에 이걸 가지고 simulator와 verilog와 연동시킨 적이 있다..)

하지만, 함수가 너무 많아서 reference가 없으면 도저히 쓰기 어렵고, 명확히 정의되지 않았다는 단점이 있다(특히 verilog simulator와의 interfacing부분에 있어서 표준화 되어 있지 않다).

VPI는 다시 정의된 PLI함수로서 소위 PLI2.0으로 불린다. 예전에는 시뮬레이터 지원이 잘 안된다는 단점이 있었다지만, 요즘 시뮬레이터에서는 대부분 지원하고, 상당히 일관된 인터페이스를 지니고 있는 장점을 가지고 있다.

개인적으로는 acc_, tf_ 를 알면 verilog simulator가 어떻게 object들을 처리하는지 정말 잘~ 알게되는 장점(?)이 있는 반면, VPI는 그런 거 알 필요 없이 함수의 설정만 알아도 대부분 처리할 수 있다는 장점이 있다.
사용자 입장에서 어떤것이 편한 것인지는 말할 필요가 없다.