Category Archives: SoC & IP design

Low Power VMM 공개

가끔 올리는 짧은 소식 몇 가지.

1.

Synopsys에서 Low Power Verification Methodology Manual을 공개하였습니다
Solvnet ID가 있으시다면 누구라도 여기(http://www.vmmcentral.org/vmmlp)에서 다운 받으실 수 있습니다.

저는 다운만 받고 아직 훓어보지도 못해서 no comment입니다. ^^;

 

2.

Mentor가 OVM을 기반으로 VMM code를 지원하겠다고 발표했습니다. (실질적으로는 VMM의 function을 OVM 함수를 이용하여 구현한 것이겠습니다)
VMM을 기반으로 작업했던 사람을 OVM으로 끌고 오겠다는 셈이겠지요. (http://www.mentor.com/products/fv/methodologies/_3b715c/cb_rf.cfm 에서 Verification Cookbook을 다운받으실 수 있습니다.)

아래 posting에 댓글 달아주신 홍용재님의 글처럼, OVM은 e, SystemC로 지원할 계획을 가지고 있습니다. 대부분의 interface 함수를 공유하게 될 것이니, 기존의 작업은 그대로 둘 수 있고, e, SystemC를 HVL로 이용하여 모델링 하시던 분들을 역시 적극적으로 끌어들이겠다는 전략으로 해석됩니다.

 

3.

드디어 simulation 가능한 툴이 생겨서 OVM을 좀 보고 있습니다. SystemVerilog의 Class를 참 잘 이용한 것 같습니다. 제가 평소에 하는 프로그래밍이라는 것이 대부분 모델링이라 보통 프로그래밍을 할 때 속도 문제로 OOP는 잘 사용하지 않는데(특히 virtual function의 경우 상당히 느려집니다), 걍 편하게 살자는 마음과 Verification에 한정하니 머리가 편해지는군요. OOP라는 것이 처음에 class design(실제적으로는 상속의 남발 ^^;) 잘못하면 낭패를 보는 경우가 많은데, 대부분의 코드가 공유될 때 편하긴 편하지요.

 

4.

ABV를 여쭈어 보시는 분들이 많은데 SystemVerilog에서 출발해야 할 부분이라고 생각되어서, 취미 삼아 Verilog사용자를 위한 SystemVerilog Guide를 지난달부터 작성하고 있는데, 회사 일과 크게 관련이 없는지라 주말에 집에서 하는 작업으로 한정하고 생각하다 보니 진도가 아주 느립니다. 어느 정도 정리되면 올리겠습니다. (대부분 doulos.com의 Tutorial 자료를 참고하고 있고, 내용에서 빠지는 부분을 채우고, 제 생각에 별로 필요 없는 부분 – 그런게 있나요.. ^^; -은 제외하고 작성하고 있습니다.

  —

쓰고 보니 요즘 문서작업으로 바쁜데.. 그 와중에 또 글을 쓰는 건 뭐지… 라는 생각이 드는 군요. (시험 전달에 이상하게 몰아두었던 만화나 드라마나 심지어 논문이 재미있어지는 것과 비슷한 현상일지도..)

DVCon의 결과..

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

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라고 쓴건지 모르겠네요 ^^;

Visual Studio Express 2008에서 OpenGL 사용

간단한 것이지만, 포맷 할 때마다 까먹는 내용이라서..

 

  1. Freeglut와 GLUT를 받아서 압축을 푼다.
  2. 모든 h 파일은 C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include 에 복사한다.
  3. 모든 lib 파일은 C:\Program Files\Microsoft SDKs\Windows\v6.0A\Lib 에 복사한다.
  4. 모든 dll 파일은 C:\Windows\system32 에 복사한다.

 

* 당연히 설치되어 있는 Microsoft SDK 버전이나 설치 경로에 따라 디렉토리는 약간씩 다를 수 있다.

 

OpenVG 관련되서 이런 저런 일을 하다보니 OpenGL을 사용할 일이 많습니다. 참조 구현(reference implementation)이 OpenGL 기반(이라고 하기도 그렇지요. 윈도우 띄우고 점 찍는데만 쓰고 있으니..)이라 관성이 생겨서 계속 쓰게 됩니다. Visual Studio Express는 MS에서 무료로 제공되는 툴이고, OpenGL도 이곳 저곳에 무료 구현이 많이 개발에 필요한 모든 것은 무료로 얻을 수 있지요.

일단 알고리즘 만들고, 검증차원에서 RI와 같이 돌리면서 이것 저것 헤집고 있는데, OpenVG RI는 일부러 이렇게 만든 것인지 몰라도, 정말 이해하기 쉽게 기본 알고리즘만으로 만들어져서 비효율적입니다. ^^; RI니까 기본적인 알고리즘에 충실하고 결과를 잘 보여주는 것이 목적이었을 테고, 그래서 소기의 목적을 달성한 것이지만, 가끔은 좀 심하다는 생각도 들죠. 혹시라도 이대로 구현하는 분이 있으면 망할 것 같다는 생각.

이미지 처리 알고리즘도 마찬가지.

사실 이미지 처리 하드웨어는 많은 회사에서 하고 있기는 한데, 가끔은 알고리즘을 그대로 구현하는 경우가 있습니다. 하드웨어에는 하드웨어에 적합한 알고리즘과 아키텍쳐가 있기 마련인데, 그냥 좋은 알고리즘이니 좋은 하드웨어가 나올 것이라 생각하는 경우가 예상외로 상당히 있습니다(특히 요즘엔, CAD툴들이 좋아져서 behavioral 기술에 아주 가까운 HDL코드도 잘 컴파일을 하니까 이런 경향이 커지는 것이겠지요). 예를 들어 많은 이미지 필터링과 관련 처리가 systolic array같은 간단한 아키텍쳐만 고려해서 알고리즘을 변경하면 상당히 효율적인 경우가 많은데, 프로세서로 처리하듯 연산기를 사용하고, 메모리 접근을 반복하도록 만드는 경우가 생각보다 많습니다. (생각하기야 간단 간단하게 만드는 것이 편하니 이렇게 하는 것이겠지만, 요구되는 메모리 대역폭과 하드웨어 소모를 생각하면 알고리즘을 이해하고 하드웨어로 최적화 할 수 있는 엔지니어를 채용하거나, 알고리즘 작성하시는 분들에게 다양한 하드웨어 아키텍쳐를 이해하도록 하는 것이 필요하겠습니다.

에구.. 항상 제목과 관계없는 이야기네..

 

에.. 엇나간 김에 하나 더.. 괜찮은 무료 음악 사이트… 인디 음악이긴 하지만, 좋은 곡이 많습니다. http://www.blayer.co.kr/