아래아 한글

아래아 한글을 안써본 사람이 있을까?
아래아 한글이란 것을 91년부터 쓰기 시작했으니, 정말 오래되었다.
하지만, 한글 2.0을 어린나이에 학생할인이 된다는 알량한 이유로 세뱃돈을 탈탈털어 샀던 나로서는 너무나 실망했고, 정품과 불법소프트웨어간의 아무런 차이를 느낄수도 없었으며.. (안된다고 전화해서 물어보면 아주 즐거운 취급을 받았었다..) 그 이후로 아래아 한글을 사지 않으리라 결심도 했었다.
그러던 어느날 아래아 한글이 망한다고, 어쩌구 하면서 815버젼을 사게 되었고 잘 사용했던것 같다..

나름대로 오래된 아래아 한글 사용자인지라, 키보드 매크로는 대부분 알고 있는데, 간혹 매크로가 바뀔때마다 배신감도 느끼고.. ^^;

여하튼.. 어느 순간 부터인가 버그 투성이 아래아 한글을 안쓰게 되었다.
어느 순간 부터 아래아한글의 불친절함이나 다른 툴과의 비교가 되기 시작했고..
회사 오면서는 회사에서 구매한 아래아 한글가 몇카피 안되어 안쓰게 되었다.
(뭐 정품 워드가 깔려 있지만, 지금이 이것도 많이 쓰지 않는다.. 거의 LaTeX을 쓰는지라..)

관공서나 이런곳에는 아직도 많은 곳에서 “국산”이라는 이유로 아래아 한글로 문서를 작성해야 하고, 아래아 한글 문서를 생산해낸다.. 좋은 방침이라고 생각한다.

하지만, 아래아 한글 문서를 보기 위한 방법인 무료 프로그램인 HWPviewer는 어떠한가?

한마디로 “이보다 더 나쁠 수 없다”

HWPviewer 2002버젼은 상위 버젼 문서라고 난리친다.  뭐 이해한다.. 세상이 변했으니..
HWPviewer 2005는 어떠한가?
내가 처음받은 HWP viewer 2005(한컴 홈페이지에 있는)는 윈도우 상에서 화일 연결이 불가능한 아주 생각없이 만든 프로그램이다. (즉, 문서를 열기 위해서 해당 문서를 더블클릭하는 방법은 안되고,  프로그램 띄우면 자동으로 뜨는 문서 열기를 통하여 문서를 열어야 한다.. 이게 뭐냐?)

그래서, 업데이트가 되었나보다.. HWP viewer 2005 6.7.5.978 버젼.. (한컴 홈에는 아직도 예전 버젼이 있지만..)
이제 문서 연결은 된다. 그런데, 더블클릭해서 문서를 열면 해당 문서가 열리는 건 좋은데, 프로그램이 수행되면서 자동으로 문서 열기 창이 띄고 하나의 문서를 추가적으로 더 열어야만 한다. (취소를 선택하면 프로그램이 종료된다)

그래, HWP viewer는 무료 프로그램이다.
고객지원 안하는 거 당연하다고 생각한다.
하지만, 생각은 하고 프로그램 만드시나? 노력했다고? 사용자의 입장에서 사용 한번만 해봤으면 이런 오류는 발생하지 않는다.

한컴에 계신 프로그래머 분들께서 낙심할까봐 차마 더 심한말은 못쓰겠지만…
아래아 한글이 점점 더 멀어지는 것은 마이크로소프트의 저가 공세가 아니라, 아래아 한글의 견고성이 떨어지기 때문이다.
아래아 한글이 과연 기능에 충실한가?

저전력 설계 기법..

아무래도 ASIC의 존재 이유가 월등한 성능이라는 측면보다는 비용과 전력소모라는 쪽으로 이동하고 있는 시대이다 보니, 저전력 설계라는 것이 중요한 이슈가 되고 있습니다.

저도 예전에 석사시절에 저전력 CAD도구를 주제로 논문을 썼었는데, 그때 제가 잠정적으로 내린 결론은 이미 만들어진 아키텍쳐에서 RTL수준에서 해낼 수 있는 저전력 설계란 제한적이다.. 라는 사실입니다.

즉, 설계 엔지니어가 항상 염두에 두어야 하는 사항은 이제 얼마나 저전력을 고려해서 아키텍쳐를 만들것인가.. 라는 질문입니다.
이때, 아키텍쳐를 만드는 사람은 CAD tool에서 어떤 형태의 모듈에 대하여 저전력화 시킬 수 있는지를 반드시 고려해서 아키텍쳐를 만들고, 이를 구현해야 한다는 점입니다.

아키텍트를 포함해서 front-end쪽 엔지니어가 아무리 circuit의 저전력을 고려해도 이를 합성툴을 비롯한 CAD툴에서 지원해주지 못하면 한마디로 말짱 꽝입니다.

아키텍트는

1) 전체적인 signal transition을 줄일 수 있는 아키텍쳐를 만들어야 하고,
2) 가능하다면, transition이 많은 신호들을 구분하여 따로 특정 지을 수 있어야 하며,
3) 각 모듈의 enable조건을 필수적으로 고려해야합니다.

이를 위해서는 우선, 각 동작에 따라 어떤 모듈이 어느정도 활성화될 것인지(다시 말하면, 전력소모를 할 것인지)에 대한 감이 있어야 합니다.
이러한 감은 많이 디자인해보면 쉽게 잡을 수 있습니다.

디자인 경험이 쌓이면 그림을 그리면서, 대략적으로 이 유닛은 몇 게이트 정도에 무슨 공정에서 몇 ns정도 나올것인지 하는 대략적인 감이 있습니다. 그리고, 해당 유닛이 어느정도 동작할 것인지에 대한 느낌도 오죠..
(물론, 이런 느낌을 얻으려면, 그 전에 설계와 분석을 몇번정도 철저히 해 봐야 합니다. 특히 분석이 중요하죠..)

이후에는 CAD툴에서 지원하는 automatic RTL clock gating기법을 위한 코드를 잘 생각해 보아야 합니다.

synopsys를 사용한다면 HDL compiler (design compiler가 아니고, 그 앞단에 있는 툴이죠.. 보통은 통합되어 있어서 잘 못느끼지만요..)에서 어떤 코딩 스타일을 어떻게 변환하는지에 대하여 잘 이해하고 있어야 합니다.
코딩이란 결국 (GTECH) gate level로 mapping되고, 이후에 tech library로 변환되는데, 초기에 gate level mapping이 잘되면 합성의 결과가 좋을 수 밖에 없겠죠..

저전력에서 사용하는 power compiler도 마찬가지 입니다.
좋은 gate level netlist가 있어야 좋은 결과가 나옵니다. (특히 HDL compiler단계는 중요합니다.)

따라서, 좋은 아키텍트 또는 ASIC designer가 되고 싶으시다면, 전반적인 기술에 대한 이해, 경험, 그리고, CAD툴에 대한 이해가 필요합니다.

verilog HDL, System Verilog, system C, e, vera.. PLI

대충 ASIC 엔지니어들이 사용하는 언어들이죠..

아니! VHDL을 빼 먹었잖아~! 하고  말 하시는 분도 있겠지만, 개인적으로 석사 3학기때 이후로 VHDL은 안쓰고 있는지라, 잘 몰라서 그렇다.. 라고 생각하셔도 좋겠습니다.
또한, 개인적으로는 VHDL이 verilog에 비하여 많은 부분에서 상당히 밀리고 있으며, 그것이 요즘 경향이라고 생각하고 있는 점도 없지않아 있습니다.

VHDL 사용자 분들은 VHDL의 유연함과 OOP적인 요소를 장점으로 꼽으시는데, 예 맞습니다. ^^;
근데, VHDL의 유연함과 OOP적인 장점은 검증이나 description에서는 편하지만, 설계 자체에 있어서는 그리 편하지 않지요..
verilog HDL의 장점은 말 그대로, 간단히 설계할 수 있다는 점 아니겠습니까.

96년도 정도에는 VHDL이 세상을 곧 지배할 것 같았지만, 사실 95년도에 verilog가 IEEE표준이 되고, 열약했던 시뮬레이션 툴들이 (네, verilog-XL이 있습니다만, 다른 대안이 없었지요..) 정비되면서, 실무쪽에서는 거의 verilog HDL로 정리된것 같습니다.

학교쪽에서야 아직 VHDL을 많이 사용합니다만.. ^^; 학교 이야기겠구요..

오늘 주절히 주절히 ASIC에서 사용되는 언어들을 제목으로 단 것은 바로, verilog의 약점인 검증 부분을 채우기 위한 노력들입니다.
verilog HDL은 verilog 2001이라는 새로운 표준에서 검증을 위한 다양한 기능과 좀더 편한 설계를 위하여 보강하고 있으며 (이 부분에 대해서는 예전 posting인 verilog HDL 2001을 보세요~), 좀더 강력한 기능으로 system verilog를 정의하였습니다.

system verilog는 강력한 assetion과 더불어 데이터 구조의 지원등으로 설계쪽 보다는 검증의 편의성을 노린 흔적이 역력합니다.
이는 최근에 역시 IEEE표준으로 지정된 검증계의 기린아 ‘e’ 언어를 노리고 있는 것이 거의 확실한듯 합니다.
아직은 e과 약간 다른 전장을 놓고 다투고 있습니다만, 거의 다가갔죠.. 전운이 감도는 시장입니다.
물론, e가 cadence를 위주로 지원되고 있다면, system verilog는 좀더 많은 EDA업계의 지원을 받고 있으니까 약간 더 유리하지 않을까 하는 생각입니다.

단, 그동안 e 언어가 가지고 있던 그 화려한 경력과 know-how가 가득담긴 코드들이 있으니, 최종 일전이 어떻게 될지는 모르겠습니다.

vera의 경우 synsopsys가 밀어주는 검증언어인데, 상대적으로 VCS가 약하니까 덩달아 사그러드는 느낌입니다. 몇년전 부터 vera spec을 open하고 openvera를 퍼트리려고 노력중인데, 아직 멀었습니다.
e 언어가 공개되기 전에 하지.. 아쉽…

한때 차세대로 불리우던 systemC가 있군요..
뭐, 아직도 차세대 system C라고 해야 할까요?
설계 언어로서는 좀 그런것 같구요.. (synthesiable subset만으로 설계하느니 verilog로 하는게 100만배 쉽습니다. ^^; 역시 각각에 분야에 맞는 것이 있는 것이죠) 최근에는 cadence에서 낼롬 기증한 SCV(예전의 testbuilder인데, 일부를 기증해서 표준화 했습니다.)를 필두로, 검증을 위한 환경으로는 폭넓게 받아들여지고 있는 듯 합니다.

아무래도, coverification의 관점에서도 C기반의 interface가 지원되는 것이 편하니까요..

system C와 verilog간의 co-simulation에 약간 그림 이쁘게 보여주고, 좀 쉽게 해주는 것에 여러 회사가 도전중입니다. CoWare도 있구요..
뭐, 전반적으로 회사들의 평은 거의 “악평일색”입니다.  놀라운 이야기입니다.
그림 나오고 다 좋은데, 잘 안돌죠.. 아직은 1~2년 정도 지나서 좀더 진화해야 할 듯 합니다.

차라리, PLI에 TCL/TK를 연결하는 것이 이쁘고 좋습니다. ^^; 무료인데다 자유롭죠..
PLI도 재미있고, TCL/TK도 재미있고..
아주 즐겁지 않습니까?

얼마전에 회사에서 재미삼아 virtual UART라는 시뮬레이션때 사용가능한 터미날 프로그램을 PLI와 TCL/TK로 만들었는데, 개인적으로 즐거운 작업이었습니다. ^^;

나중에 이 블로그로 공개될 기회가 있겠죠..