예전에 PLI에서 윈도우 제어 하려고 별짓을 다했었는데, 그 중에 PLI에서 TK 윈도우를 바로 부른 것도 있었습니다. PLI에서 TK를 부르는(C-TK interwork을 이용한) 방법은 TK 스크립을 거의 직접 쓸 수 있다는 점에서 편리하긴 한데, NCVerilog에서 너무 버전을 심하게 탄다는 단점(TK의 버전도 맞춰 줘야 합니다. -_-;)이 있어서 환경이 바뀌면서 잘 안쓰게 되더군요.

게다가 시뮬레이션 돌리면서 이런 저런것을 실시간 출력할때 UNIX/Linux/Windows 안가리는 인터페이스를 고민하다보니, TCP/IP와 Perl 만한게 없더군요. Simulator에서 이런 저런 GUI 부분이 귀찮아서 socket 기반으로 만들었던 기억을 되살려 하나 만들어봤습니다. PLI에서 TCP/IP 패킷을 전송하는 부분을 하나 만들어봤습니다.

별 내용은 없고, 그냥 verilog code에서 cosim_hello()를 호출하면 loop돌면서 값을 출력하는 예제입니다.

------
#include <stdio.h> #include <arpa/inet.h> #include <netinet/in.h> #include <sys/socket.h> #include <sys/types.h> #include "vpi_user.h" #define DEST_IP "127.0.0.1" #define DEST_PORT 7890 static struct sockaddr_in dest_addr; static int count = 0; static int sockfd; int counta; PLI_INT32 cosim_hello_calltf(PLI_BYTE8 *userdata) { char buf[1024]; s_vpi_time ctime; ctime.type = vpiScaledRealTime; vpi_get_time(NULL, &ctime); vpi_printf("[%2.2f] Hello VPI: %d, %d\n", ctime.real, count, counta); sprintf(buf, "\n##[%2.2f] Hello VPI: %d, %d\n", ctime.real, count, counta); send(sockfd, &buf, sizeof(buf), 0); count++; counta++; return(0); } PLI_INT32 cosim_hello_init() { int len, result; counta = 100; sockfd = socket(AF_INET, SOCK_STREAM, 0); dest_addr.sin_family = AF_INET; dest_addr.sin_port = htons(DEST_PORT); dest_addr.sin_addr.s_addr = inet_addr(DEST_IP); len = sizeof(dest_addr); result = connect(sockfd, (struct sockaddr *)&dest_addr, len); if (result == -1) { fprintf(stderr, "socket open error\n"); exit(1); } return(0); } void cosim_register_hello() { s_vpi_systf_data tf_data; tf_data.type = vpiSysTask; // make as task tf_data.sysfunctype = 0; tf_data.tfname = "$cosim_hello"; tf_data.calltf = cosim_hello_calltf; tf_data.compiletf = cosim_hello_init; tf_data.sizetf = NULL; tf_data.user_data = NULL; vpi_register_systf(&tf_data); } void (*vlog_startup_routines[])() = {cosim_register_hello, 0};
-----
[이 코드 틀은 다이나릿의 기안도 박사님 IDEC 강좌 자료에 있는 "HW/SW 동시 협조 시뮬레이션"이란 강좌의 첫번째 PLI 예제에서 따왔으며, 저는 이 함수에 TCP/IP 전송이 가능하도록 수정하였습니다.]

컴파일은 다음과 같이 일반적인 NCVerilog 컴파일과 다르지 않지요. (Windows에서 Modelsim 사용하시는 분은 gcc보다는 visual c++의 cl 을 사용하시는 것이 속 편합니다. MingW 버전의 gcc가 되기는 하는데, Modelsim에서 버전을 상당히 심하게 탔던 것으로 기억됩니다. 요즘 버전은 어떨지 모르겠습니다만. )

$gcc -I$CDS_HOME/tools/inca/include -c cosim_hello.c
$ld -shared -o cosim.so cosim_hello.o

$ ncvlog -work worklib test_hello.v
$ ncelab worklib.test_hello -loadvpi ./cosim:cosim_register_hello
$ ncsim worklib.test_hello

이런 식으로 사용하면 되는데, 위의 패킷을 받아줄 서버는 간단히 perl로 짜주면 됩니다. Perl-TK로 GUI를 작성하는 것도 가능하구요.

이때 한가지 주의해야 할 점은 perl의 IO::INET 의 accept() 함수가 blocking type이기 때문에 이것을 non-blocking type으로 해 주시고 loop을 돌려야지만 DoOneEvent() 함수가 정상적으로 수행된다는 점이지요.
(설마 MainLoop()로 돌리실 분은 없을 테니 ^^;) 저도 처음엔 DoOneEvent함수가 좀처럼 동작을 안하는 것처럼 느껴져서 헤맸습니다. 결론은 accept()함수 문제더군요.

perl 함수의 주요 부분만간단히 정리하자면(예제를 위해서 perl script를 하나 더 만들기가 귀찮고, 전체 내용은 회사 작업이라 공개할 수 없고.. 라는 어려움 때문에 별로 문제 안되는 부분만 올립니다. )

------


use strict; use IO::Socket; use Tk; use encoding 'utf-8'; # 한글 쓰시려면.. use Fcntl qw(F_GETFL F_SETFL O_NONBLOCK); my $portnum = 7890; # make a socket my $mw = MainWindow->new(-title=>"Terminal"); ..... my $sock = IO::Socket::INET->new( LocalHost => 'localhost', LocalPort => $portnum, Proto => 'tcp', Listen => 10, # SOMAXCONN 으로 해도 됩니다. Reuse => 1, TimeOut => 1, ); .... my($new_sock, $c_addr, $buf, $flag); ... # NonBlocking으로 만듭시다. $flag = fcntl($sock, F_GETFL, 0) or die "Can not get flag: $!\n"; $flag = fcntl($sock, F_SETFL, $flag | O_NONBLOCK) or die "Can not set flag: $!\n"; while(1) { while (($new_sock, $c_addr) = $sock->accept()) { ... 소켓에서 읽어서 일하세요.... DoOneEvent(0); }

요런 식이라는 것이지요. 중간 중간에 엄청 생략되어 있음은 유의하세요..

Technorati : PLI, TCP/IP, Verilog, perl

연일 30도를 넘나드는 더위가 계속되고 있습니다.

이럴때 항상 문제가 되는 것이 집중력이 떨어진다는 건데요.. 저도 마찬가지 입니다.
(실은 개인적으로 좋은 일이 생겨서 그럴지도 모르겠습니다만 ^^;)

오늘만해도 gcc-MinGW에서 mti vpi 연결시키는 거 때문에 잠깐 modelsim userguide를 보다가, 딴짓을 하기 시작해서 대략한 5시간동안 딴짓을 했습니다.

뭐 딴짓이라고 해도 모레쯤이나 하려던 processor market forecasting자료 정리였는데, 어짜다보니 하고 있더군요. 이건 뭐, 원래 하려던 일은 까맣게 잊고 나중에 하려던 일을 한참하다가 "아.. 내가 오늘 하려던 일은 이게 아닌데.. " 뭐 이런 시나리오라고나 할까요.

VPI 이야기가 나와서 그러는데요.. (또또.. 옆길로 빠집니다요) 회사 툴이 System Verilog-verification feature를 지원해주지 않아서, C/PLI나 만들어야 겠다는 이야기를 했었죠? 요즘 teal library를 분석하고 있는 중인데, 이거야 원.. 보면서 몇 번을 감탄한 것인지 모르겠습니다.

사실 뭐 PLI 연결하는 것이야 별 차이있겠습니까? 뭐 thread를 사용하는 것도 그렇다치구요.. 근데, PLI 연결 부분을 teal_synch.cpp라는 몰아두고, 이걸 class로 덮어씌우고 연산자 오버로딩을 해버리니 예술적인 경지에 이르르더군요. 사용하는 사람 입장에서는 이 부분이 verilog랑 붙기 때문에 어쩌구 저쩌구 생각할 필요가 거의 없도록 만들어졌더군요.

아쉽게도 저는 유연성 보다는 빠른 동작을 즐기기 때문에 teal을 그대로 이용하지는 않겠지만, (처음에는) 재미삼아 분석해 본 라이브러리인데 아주 많은 걸 배웠습니다. 천재성이 담긴 코드에요.. 저에겐 '이 정도쯤은 해야 verification engineer가 되는 건가.. 에효..' 라는 상념에 빠지게 하더군요..

C++에 익숙하시고, PLI를 공부중인 분들은 상당히 도움을 받으실 수 있을 것 같습니다. 혹시라도 관심있으신분은 http://www.trusster.com/ 에서 다운 받아보실 수 있습니다. 이거 관련된 책도 있는데, 아직은 저도 본 상태가 아니라 뭐라 말씀드리기는 어렵습니다. (TRUSS도 아직 사용해보지 못했습니만, Teal만으로도 괜찮습니다 ^^;)

아.. 그러고보니 관련 기사도 있었군요.. EETimes Korea의 기사입니다.

---
위의 부분까지는 MS Writer에서 썼는데, 평소처럼 publish하려니 좀 허전하네요.. ^^;

혹시라도 PC환경에서 cygwin/modelsim하에서 사용하시는 분들을 위하여 몇 가지만

1) Makefile.Windows를 만듭니다. 이 파일은 Makefile.linux를 복사하시는 것이 편합니다.
2) 아래와 같이 고칩니다. (필요에 따라 더 고치셔도 됩니다.)

3) Makefile을 수정합니다.

대략적인 힌트만 드렸습니다만, 이 정도면 필요한 부분을 추가적으로 수정하셔서 verification_top()함수를 작성하신 다음에 linking하시는데 문제 없을듯 합니다.

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 모델을 업그레이드해야겠군요. )

예전에 99년에 학교에서 첫 버젼의 EISC를 만들때는 검증에 별 생각이 없었습니다.
뭐, 프로그램 몇개 돌리면 되겠지.. 이런 느낌이랄까요..

생각해보면, 학교에서 만드는 것은 "학술적으로" 의미가 있는 부분에 대해서는 뭔가 이런 저런 시도를 해 보는데, 실제 중요한 동작 자체는 "벤치 마크 프로그램이 돌아가는" 정도로 그치고 말았었습니다. 그러다보니, 다양한 상황에 대한 검증이나 인터럽트 쪽은 아무래도 부족했었습니다.

학생 시절과 비교하였을때 회사에 와서 가장 많이 발전한 부분이라 생각하는 것은 "설계의 질"입니다. 특히, 검증의 질이 많이 향상되어가고 있고, 이를 바탕으로 설계의 질이 향상하는 것이겠지요.
회사에서 "검증의 중요성"을 심각하게 느끼게 되었고 몇년동안 이런 저런 검증 기법들을 적용하기도 했는데, 아무래도 실무에서 의미있는 결과가 나오기에는 미흡한 상태였습니다.
게다가 국내에서는 검증을 업으로 삼으시는 분은 상당히 적으신듯해서 여러 분들과 만나서 의견을 나눠봐도 "검증의 중요성"은 인식하지만, 검증을 업으로 삼는 분(소위 verification engineer)은 아직 만나보지 못했습니다. 음.. S사나 L사 같은데는 있을지도 모르겠습니다만.. 외부로 노출이 안되는 것인지.. 논문도 그렇고.. 설계하시는 분이 검증도 같이 하는 경우가 더 많죠.. (혹시 검증을 업으로 하시는 분계실까요?)

여하튼.. 이번 프로젝트에서는 제가 수행하는 설계 분량을 최대한 줄이고, specification과 verification쪽으로 집중하려고 하고 있습니다. 하지만, 프로젝트라는 것이 항상 그렇듯(^^) 잡은 일정보다 스펙 작성이 오래걸렸고..이런 저런 일을 하다보니, 이번달에 들어서야 이 프로젝트에서 제 관심의 대상이었던 verification쪽에 집중해서 verification plan을 짜고 있습니다. (사내 정보 보안 관계로 ^^; 일반론 이상을 이야기를 할 수는 없습니다만..)

이런 과정에서 Verilog PLI이니 assertion이니, SCV와 같은 것을 다룰 수 있는 기회가 많아지겠지요..^^;

요즘에 리퍼러 로그를 보니, 검색을 통하여 들어오시는 분들이 상당하시군요..
(덕분에 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 관련 메뉴얼을 참조하세요.. 소스코드와 작성법이 다 있으니까요..^^;

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

지난번에 이야기하고, 너무 많은 시간이 지났군요..
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는 그런 거 알 필요 없이 함수의 설정만 알아도 대부분 처리할 수 있다는 장점이 있다.
사용자 입장에서 어떤것이 편한 것인지는 말할 필요가 없다.