Tag Archives: AMD

Verilog 관련 검색에 대한 친절한(?) 답변과 리퍼러 로그..

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

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

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

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

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

[#M_ESNUG내용보기|less..|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
_M#]

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

[CODE]b = a;
c = b;
d = c;

b <= a;
c <= b;
d <= c;[/CODE]

이해 되시려나요?

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

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

AMD Quad Core 소식

MPF fall에서 여러가지 재미난 소식들이 전달되고 있습니다.
이번에 전해드릴 소식은 EEtimes에 나온 AMD Quad Core processor( codename: barcelona) 관련 소식입니다.

[[Intel]]에서 core 2 quad를 2007년 상반기에 내놓겠다고 IDF에서 큰소리 빵빵쳤더랬습니다.
이에 질새라 AMD는 true quad core processor인 barcelona에 관한 소식을 MPF fall에서 발표했습니다.
사실 AMD의 quad코어 전략은 desktop에서는 4×4를 기반으로, 즉  dual core processor 두개를 하나의 칩에 내장하는 형태로 공략하고, 이후에 QUAD코어로 간다는 것이었습니다.
서버쪽은 바로 true quad코어로 간다는 전략이구요.

TRUE quad core라고 강조하는 것은 사실 AMD의 전략(?)이라고 보이는데, 비교적 열등한 형태의 인텔 [[CMP]]의 형태를 겨냥한 느낌이 다분합니다.
인텔의 core 2 duo의 경우 사실 single core가 대규모 L2 cache에 merging되어 있는 형태라 전통적인 MP의 형태와는 좀 다른 면이 있습니다.

거기에 비해서 [[AMD]]의 quad core는 4개의 분리된 single core가 Direct Connect된 corssbar switch형태의 버스로 연결된 형태를 지니고 있습니다.

”]MPF fall에 발표된 바에 의하면(저는 EETimes의 내용을 재인용합니다.^^; 자세한 사항은 역시 다음주 MPR이 기대됩니다.) 이 프로세서는 65nm공정에서 만들어지는 AMD의 첫번째 코어입니다.
또한, 각각 128bit dataflow multimedia unit을 지니고 있다고 합니다. (이건 intel에서도 이러니 특별할건 없군요)

[[Multiprocessor]]환경에서 결국 중요한건 Bus bandwidth인데 AMD는 이점을 역시 잘 인지하고 있습니다.
이에 따른 중요한 업데이트는 intergrated memory controller부분인데요.. DDR2, DDR3, Fully Buffered-DIMM을 지원하게 된다고 합니다.
관련된 주요 사항으로는 각 코어마다 64KB의 L1, 512KB L2 cache를 내장하고, 비교적 작지만 2MB의 L3 캐쉬를 지원합니다. 캐쉬의 용량은 적절히 조절된 버젼이 또 나올것이라 생각됩니다. 첫공정이니 수율 조정 측면에서 메모리를 많이 넣기는 힘들겠죠.

AMD quad core프로세서의 서버 버젼부터는 지난번에 포스팅했던 Torrenza를 위한 socket F (1207핀)을 사용해서 메모리 대역폭을 극대화 것으로 예고가 되어 있었는데, 얼마나 성능을 보여줄지 상당히 궁금합니다.

AMD Torrenza: 서버 통합의 방법을 모색하다.

AMD에서 비지니스 환경을 위한 “Torrenza”, “Trinity”, “Raiden”의 세 가지 신기술을 발표했습니다. 보도자료를 보면 거의 마케팅적인 용어로 도배로 되어 있습니다만, Torrenza는 AMD64 프로세서와 이종(혹은 동종) 프로세서간의 서버 버스/소켓에 대한 공개 규약이고, Trinity는 보안,가상기술,관리를 통합하는 하나의 공개 전략이며, 코드명 “Radien”은 일종의 클라이언트 기술로 파악됩니다.
(보도자료 전문은 http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_543~109409,00.html)

하지만, Torrenza, Trinity, Raiden 모두 선언적 의미가 강했었으며 실체를 파악하기 힘들었는데, MPR에서 Torrenza에 대해서 어느정도 궁금증을 해소하게 해주는군요.

”]

MPR에 따르면, 토렌자 기술은 서버 환경을 위한 공개 버스/소켓 아키텍쳐로서 HyperTransport 2, HyperTransport 3 그리고, HTX 에드인 카드 인터페이스, HT3 기반의 1207 소켓을 구성요소로 취하고 있다고 합니다.
AMD는 이 토렌자 기술이 서버들에 있어서 표준 인터페이스 기술이 되도록 하기 위해서, 다른 파트너사들과 함께 Opteron Rev F에서 사용된 1207핀 소켓에 기반을 둔 Torrenza Innovation Socket(TIS)라는 공통 소켓 표준을 같이 개발하고 있다고 하네요.

현재 Common interface partner사로는 Tarari, RMI(알케미 인수한 회사죠?), Bay microsystems, DRC, Celoxica(셀록시카가 들어있다는 건 좀 의외네요..), XtremeData, Qlogic과 같은 많은 분야의 회사들이 망라되어 있고, Common Socket Partner사로는 IBM, Cray, Sun Microsystems가 있습니다 (인텔의 제외한 서버용 프로세서 규모가 있는 서버용 프로세서 회사는 다 모인거 아닌가요? ^^;)

토렌자 표준에 따르면, AMD의 opteron프로세서가 1207 소켓에 장착되어 HT 버스로 연결되는 것과 같이 타사의 프로세서 역시 1207핀 소켓에 장착되어 HT버스로 서로 직접 통신이 가능하고 (코프로세서로 인식되겠습니다만), 그 이외의 프로세서 역시  HTX를 이용하여 장착 가능하게 된다고 합니다.

즉, 토렌자가 실현되는 경우 서로 다른 이종간 멀티 프로세서 환경이 아주 쉽게 구축 가능하다는 장점이 있겠습니다. 이종간 멀티프로세서 시스템의 구축을 통한 가장 큰 장점은 아마도 virtualization이 아닐까 생각도 되는데, 한 시스템에 두가지 이종간 CPU를 설치하고 해당 CPU의 applicaiton을 자유롭게 실행시킨다는 점이 실현 가능하겠습니다.

소프트웨어가 어떻게/얼마나 지원해 줄지 미지수입니다만.. 아마도 Tirinity라는 플랫폼이 이러한 이종간의 시스템에서 자유로운 보안, 가상화, 관리을 해결하기 위한 방법론이 아닐까 생각됩니다. (AMD도 생각이 있을테니까요..)

처음으로 발표된 x86기반의 공개 소켓/인터페이스 표준이니 기대가 됩니다.
(인텔의 반격도 기대되는 건 사실입니다만, 인텔의 “플랫폼 맘대로 바꾸기”에는 나름의 철학이 있으니.. ^^;)