Tag Archives: verilog HDL

DVCon의 결과..

5 Replies

질문 게시판의 내용이지만, 답변은 여기에 ^^;

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

Notes & References
↑1 어짜다 SystemVerilog라고 쓴건지 모르겠네요 ^^;

PLI와 Simulator의 연결(I)

Leave a reply

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도 어느 정도 정비를 마치고, 빠른 미래에  좀 더 공격적인 마케팅을 시작할 예정입니다. ^^; 많이 기대를 해 주세요.. 특히 학생분들께 좋은 기회가 많이 돌아가도록 노력 중입니다.

Perl을 이용해서 검증할때 유용한 팁

Leave a reply

뭐랄까요.. 요즘 이런 저런 일로 바쁘다보니, 사람이 좀 얇팍하게 글을 쓰게되네요. 🙂
(퇴고 없이 그냥 온라인에서 쓰는 글이라 앞뒤가 없을지도 모르겠습니다.)

오늘은 여러분들께서 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 언어가 사랑받는 것이겠죠.