요즘 MPSoC쪽 버스 문제 때문에 GALS(Globally asynchronous Locally synchronous)를 다시 들여다보고 있는데, circuit design을 배제하고 verilog netlist 수준에서 기존의 합성 툴을 이용할 수 있도록 생각하다 보니 자꾸만 생각이 제한됩니다. 조막만한 아이디어가 있긴 한데, 이게 구현 가능한 것인지 생각해 보는 것 자체가 고역인걸 보니 그간 머리를 안 돌리긴 안 돌렸나봐요.
GALS중에 Pausible clock control에서 아이디어를 가지고 오되, 귀찮은 부분은 던져 버려서 latency를 줄이는 것에 주안점을 두고 있는데.. 흠 쉽지 않네요..

요즘 회사에서 superscalar microprocessor/SMT 쪽 강좌(?) 세미나(?) 뭐 이런걸 진행하고 있습니다. 컴퓨터 아키텍쳐란 과목에만 한정되는 이야기는 아닙니다만, 이런 종류의 과목이 비교적 편한 과목이지요. (동의하지 않을 분들도 많을 것이지만. ^^;)
물론, 이런 저런 복잡한 배경과 논리들이 얽혀 들어가지만, 신이 만든 것을 연구하는 생물학이나 화학, 물리학에 비하면 컴퓨터 아키텍쳐 같은 것은 예전 사람들이 만들어놓은 걸 논리적으로 풀어가서 발전시키는 형태의 학문이기 때문에 일종의 퀴즈와 같다는 느낌을 많이 받습니다. (안사람이 분자 생물학쪽을 전공하고 있는데, 이야기 듣다보면 정신이 멍~ 해지지요..) 감탄. 또 감탄! 세상엔 똑똑한 사람이 끝도 없이 있단 말이죠. 젠장..

Android의 Dalvik VM[참고자료]이 공개되었습니다. (원래 되어 있던 건가요? 소스공개는 오늘 되었다네요.. 여하튼). 특징적인건 이 VM에서 사용하는 bytecode가 java와는 동떨어진 형태네요. register 기반의 bytecode니까 말이죠. 아주 좋아요. ^^; 단, 호환성 문제는 어쩔라고 그러는지(살펴보니 .class는 .dex로 바꿔야 한다네요.).. JavaME에서의 Sun license를 피하기 위한 방법이라는데, register 기반이기 때문에 전반적인 성능은 java보다 좋을 확률이 좀 있군요.

SIMD/Vector machine에 관심이 없던 건 아닌데, 좀 의외에 상황에서 건드려야 하는 상황이 발생했습니다. 인력의 문제로 사실 할까 말까를 한 2달 동안 고민했는데, 그냥 고민하고 앉아있는 시간이면 요상한 형태의 SIMD machine은 벌써 하나 만들었겠다라는 생각이 들었어요. 이것 저것 처한 상황 때문에 빠르게 진행될 가능성은 없지만, 간단하게 하나 만들어 봐야겠습니다. 대충 틀만 잡고 누구한테 떠넘겨 버릴지도. ㅋㅋ

회사차원에서 open source진영에 대한 지원을 고려하여, EISC 프로세서 관련 사이트 하나를 개설할까 개인적으로 생각중입니다. EISC processor/system시뮬레이터는 그냥 open source로 공개할 생각이고요. 예전에 작업된 이런 저런 시뮬레이터나 환경, 벤치마크 등도 같이 open해 버릴까.. 하는 생각입니다. 감추어두고 죽느니, 열어두고 살리는 것이 좋겠지요. IDEC과 공동으로 작업하는 MPW 지원 프로그램도 거의 정식 release 직전이고.. 이런 저런 "잡일"로 바쁘네요.

ARM에서 Cortex-A9을 발표하였다고 합니다 [ZDNet 기사]. 일단 저에게 있어서는 한숨 쉬어지는 일이고(ARM의 행보가 점차 빨라지니, 저희같은 업체가 따라잡을 수 있는 여지가 줄어들고 있는 것이 사실이니 말입니다.), 업계에 있어서는 환영할 만한 일이겠습니다. Cortex-A9의 경우 4개 까지 MP로 구성이 가능하다고 하니(MP 구성을 따지는 것으로 보아, cache snooping이 고려된 SMP겠지요..), 대단한 성능을 기대할 수 있겠습니다.

여기서 재미있는 것이 Intel의 대응인데요. 기존에 ARM 기반의 프로세서를 만들다가 해당 부분을 과감히 정리하였지요. 근데, EETimes에 의하면 Intel이 ARC의 프로세서를 라이센스했다고 합니다[EETimes 기사]. ARM 기반을 정리할 때는 x86기반의 embedded processor쪽으로 무게를 둔다고 생각했는데, 범용쪽은 x86기반, 저전력이 요구되는 application specific한 부분은 configurable processor인 ARC쪽에 무게를 두는 느낌입니다. 그래도, x86기반에서도 충분히 configurable하게 만드는데 어려움이 없을 것인데.. 저전력을 위해서 이런 결정을 내린 것이 아닌가 하는 생각입니다.

이러한 행보에 맞추어 저희 회사에서는 Heterogeneous MPSoC쪽에 무게를 두고, 여기에 적합한 lightweight/low power processor와 interconnection에 무게를 두고 있습니다[네이버]. 몇 가지 재미있는 아키텍처적인 시도를 구상하고 있는데, 보도 자료에는 좀 이상하게 나간 느낌이 있습니다. 물론, 마케팅적인 측면을 위해서 빠른 프로세서를 만들어야 겠다는 생각은 변함이 없습니다만.. 실제로 MPSoC에서 중요한 것은 적절한 성능의 작은 footprint를 지닌  low power 프로세서들이니까요. (적절한 성능이란 것이 task에 따라 바뀌는 것이므로, 아주 강력한 프로세서를 개발해야 할 필요성도 있는 것이지요)

뭔가 흥미 진진해질 것 같아요.

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

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

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

기사보기

[전자 엔지니어에서 퍼왔습니다.]
ETRI(한국전자통신연구원)는 USN용 고성능 제어장치(MCU) 칩 개발에 성공했다고 6일 밝혔다.

이 칩은 기존의 8비트 프로세서 칩 성능을 32비트로 4배 개선시켰고 메모리도 기존 128KB 수준을 256KB 수준으로 2배 업그레이드 한 것이며 어플리케이션도 다양한 응용분야에서 사용가능 하다고 ETRI는 말했다. 또한 이번 개발을 계기로 USN관련 연구개발에 탄력이 붙을 것으로 전망했다.

기존의 USN 센서노드는 일상생활에서 흔히 볼 수 있는 온도, 습도의 증감, 화재발생 여부 등 단순신호만을 감지하여 전달 처리할 수밖에 없었지만, 이번에 ETRI가 개발한 칩을 센서노드에 적용시키면 영상정보 전달 및 음성신호 감지 처리까지도 가능하다. 이에 따라 복잡한 센싱 데이터를 센서노드에서 가공 처리하여 전달할 수 있어 다양한 USN 응용서비스 제공이 가능한 게 특징이다.

즉, 응급상황시 비명을 지르면 주변의 센서가 이를 인식, 센서노드에 정보를 전달해 도움을 청할 수 있고 또는 CCTV의 음영지역에서 센서노드의 설치로 위험신호가 감지되면(호루라기(Whistle)를 불면) 가까운 경찰서에 알려줄 수도 있어 ‘안전귀가 서비스’ 등에도 유용하게 활용될 수 있다.

ETRI는 정보통신부 “RFID/USN용 센서태그 및 센서노드 기술개발” 사업을 통해 에이디칩스와 공동으로 “USN용 고성능 32비트 MCU TMA2560”을 개발하는데 성공했으며, 상용화 시점은 2007년 하반기로 전망했다.

아울러 내년에는 개발된 프로세서와 통신기능 칩을 하나의 칩으로 즉, SoC(System-on- Chip)화 할 계획이여서 통합 칩의 크기 또한 계속 줄게 될 것이다고 밝혔다.

ETRI는 11월 7일부터 코엑스에서 개최되는 ‘RFID/USN KOREA 2006’ 국제 전시회 및 컨퍼런스에 TMA2560 및 본 칩을 이용한 위험감지인식과 산업현장 감시제어 응용 서비스를 옥타컴과 태광이엔시와 공동으로 각각 시연해 보일 예정이다.

오늘자 전자신문에 제가 개발하고 있는 EISC 프로세서 관련 기사가 전자신문에 나왔네요..

사실 이 컴파일러 최적화 작업은 회사내(적어도 프로세서팀)에서는 숙원사업과 같은건데.. 아쉽게도 국내 컴파일러 전공 교수님들께서는 "논문 주제가 되기 힘들기 때문에" 연구를 잘 맏아주시지 않았습니다. 저희 내부 컴파일러 팀은 자체적으로 스트레스를 엄청 받고 있었구요..

다행이 GCC에 정통하신 고려대 김선욱 교수님께서 이 프로젝트를 맡아주셔서(사실 예전에 뵙고 말씀 나눈이후에 이분이 맡아주시길 내심 기대하고 있었습니다..), 좋은 결과가 나왔습니다.
아직은 개선해야 할 부분이 상당히 많다고 생각하고 있지만, 프로세서 만드는 입장에서는 컴파일러의 개선보다 좋은 소식이 없습니다. ^^;
어셈블리로 작성해서 비교했을때는 분명히 아주 좋다고 생각하는데.. 컴파일 해보면 컴파일러 성능 때문에 벤치마크 결과가  생각보다 안나오는 경우가 종종 있었거든요..

저희 회사 GCC나 linux port된 소스는 아마도 저희 회사 ftp에서 쉽게 구할 수 있을것이라 생각됩니다. (공개 커뮤니티 지원 인력 문제로.. 적극적으로 공개하고 있지는 않습니다만..) ^^;

[기사 출처: http://www.etnews.co.kr/news/detail.htm ··· 10200152]

기사보기..

얼마전에 다나와라는 사이트에서 국산 마이크로 프로세서에 대한 이야기가 오고 간적이 있습니다.
이런 저런 이야기가 많이 오고 갔지만, 물끄러미 보고 있자니 사용자들의 국산 프로세서에 대한 열망이 느껴지더군요..

저도 그리 깊이 아는 것은 아니지만, 제가 아는 한도내에서 국산 마이크로 프로세서에 대해서 이야기해 보고자 합니다.

국산 마이크로 프로세서에 대한 연구는 대학 연구실과 국가 연구소들에서 지속적으로 관심의 대상이었습니다만, 상용화 된 경우는 제가 알고 있기로 없습니다.

국내 연구실중에서 상용 수준에 가장 근접했던 곳은 아마도 KAIST에서 수행된 x86 호환칩(펜티엄 호환칩까지 나왔습니다)이 아닌가 생각됩니다. 물론, 이를 후원하던 현대전자가 사라지면서 이 프로젝트는 사실상 사라졌습니다만...

KAIST 경종민 교수님 연구실에서 개발한 Marcia 프로세서(펜티엄 호환칩)

CalmRISC 이미지 컷[삼성전자]

EISC가 탑재된 그래픽 프로세서, 게임기에서 많이 사용됩니다.

SoC 로봇워 경기장면, 원통의 색이나, 벽의 패턴을 인식해서 공격이나 동작을 선택합니다.

EISC라는 프로세서를 접하고 시작한지 올해로 벌써 8년째다.

학교에서 있을때 대한민국에 변변한 프로세서가 없다는 것에, 그리고 아키텍쳐와 마이크로 아키텍쳐가 없다는 것에 낙담하고 있던차에 SystemIC2010사업으로 embedded microprocessor사업이 있다는 것도 알게 되고 그리고, 아시아 디자인(지금은 ADChips라는 이름으로 바뀌었다)이라는 회사에서 EISC라는 들어보지 못한 프로세서를 만든다는 말을 들었다.

연구실에서 32bit EISC 담당하고, 분석하고, 설계하면서 얼마나 즐거웠던가.

그동안 나의 공부 부족을 한탄하기도 하고, 팀원들을 탓하기도 하면서 몇개의 프로세서를 만들었다.
내가 담당하고 있는 제품군은 32bit EISC processor, 소위 main stream이라 불리는 분야의 내장형 마이크로 프로세서군이다.
우리회사에서 부르는 공식적인 명령어 체계 이름으로는 AE32000.

이번에 AE32000의 이름을 걸고 4번째 프로세서를 만들고 있다. 사실 major change로 보면 3번째 설계를 계승하는 것인데, 2년전에 해야 했을 일을 나 자신의 방황으로 2년이 지난 지금에야 하고 있다.

설계가 예상처럼 된다면, 이제 5단 파이프를 가지는 스칼라 프로세서 중에서는 가장 높은 IPC를 지니고 있는 프로세서이자 저전력 프로세서가 될것이라 자신한다.

그 이후에는 8~9단 파이프를 지니는 고속 프로세서를 만들 예정이다. superscalar도 고려중이지만, 현재는 시장에서 가장 유망한 프로세서를 만들어 두고, 팔릴 수 있도록 만드는 것이 중요하다.

아직도 나는 내가 다니는 회사의 무모한 도전에 박수를 보낸다.
대한민국만큼 유행에 민감한 시장에(한마디로, ARM이 유행하면 ARM이외의 embedded microprocessor는 모르는 환경이 되는) 매년 많은 인력을 투자하며 싸워 나가는 회사가 자랑스럽다.

단지, 가끔은 나 자신이 '이걸 만들어서 어떻게 ARM과 경쟁하나.. ARM은 속도를 위해서 공정도 조작하고, OS들도 많고.. '라는 생각으로 나약해 질때가 있지만..
후배들에게 내가 학교에서 느꼈던 생각이 들지 않도록 하기 위해서라도 반드시 경쟁력이 있는 것을 만들고 말리라..

다짐..