Monthly Archives: May 2007

근황 몇개

프로세서 개발 이후 한달 넘게(두달도 넘었나?) 매뉴얼 작업.. 교육 자료 작업, 벤치마크 결과 정리…
다음 프로세서의 스펙 정리..

계속된 문서 작업으로 지쳐서 사실 blog에 글 쓸 엄두가 안났습니다.
내일 부터 교육인데 이거야 원.. 잘 할 수 있을지 모르겠습니다.
—-

사운드 카드는 실험삼아 USB형 DAC인 Optoplay를 중고로 구매했는데.. “음질 짱이에요”
새 버젼보다 좋은 DAC이 있다는 정보에 그냥 장터를 둘러보던 중 둔에 띄었고.. 사용 결과는 대 만족입니다.

이제 사운드 카드에서 잡음 생기면 그냥 USB형 사운드를 쓸랍니다.. 음감용이 아니라면.. ^^;
참고적으로 Optoplay는 음감용으로도 괜찮은 듯 해요.. 근데, 가끔 미칠때가 있어요… 한 2주에 한번 정도 “뷁”하면서 죽는 거죠..(농담이 아니고 정말 죽을 때 소리가 “뷁”입니다. ) 허브에 몇개를 몰아쓸때 그런걸로 봐서 USB 전원이 부족한지도 모르겠다는 생각도 듭니다..
뭐, 전력 많이 쓸만한 거 뽑은 다음에 USB 사운드 카드를 뽑았다 끼우면 됩니다.
—-

더위에 미쳐가고 있는 babyworm이었습니다.

Acrobat없이 pdf 다루기.

요즘은 많은 회사에서 pdf 파일을 만들어내고 있습니다.

pdf 생성 프로그램으로 가장 유명한 건 Acrobat인데, 국내 법인이 아주 “바보” 같은 관계로 회사에서도 저는 Acrobat을 되도록 사용하지 않고 있습니다.
Word문서를 Hyperlink가 가능한 PDF로 만들때만 문서 편집용 PC에 깔린 넘을 쓰기는 합니다만, 요즘들어서는 이런 목적으로도 Acrobat을 사용하는 일이 없어져 버렸습니다.

가장 큰 이유는 저희 팀 내부적으로 LaTeX을 문서화 도구로 사용하면서, 고품질의 PDF 문서를 LaTeX를 통하여 얻을 수 있게 되었다는 점이겠습니다.

LaTeX의 사용만이 PDF를 얻을 수 있는 방법은 아닙니다.
Hyperlink가 그리 큰 문제가 되지 않는 파워포인트나, 엑셀의 경우 그냥 프린터에 PS 출력이 가능한 프린터(저는 대부분 Apple LaserWriter 시리즈중의 하나를 선택합니다) 드라이버를 설치하고, 파일로 출력 포트를 지정하여 PS 파일을 얻을 수 있지요. (일반적으로 파일로 출력하면, XXX.prn 형식으로 나오는데 이를 그냥 XXX.ps로 바꾸면 됩니다.)
여기에 cygwin을 설치하면 설치되는 ps2pdf 유틸리티를 이용하면, 상당한 수준의 PDF파일을 얻을 수 있지요..

ps2pdf xxx.ps

그래도, 가끔 Acrobat이 필요한 경우가 있었는데, 바로 PDF파일을 합칠때 였습니다.
하지만, 이것도 더 이상 사용하지 않게 되었으니, 바로 gsview32를 이용하여 pdf를 합칠 수 있다는 문서를 보게 되었기 때문입니다.
ghostscript는 PS파일을 보기 위하여 거의 필수적으로 설치해야 하니, 뭐 다들 설치하셨겠지요.

다음 예는 위의 페이지에서 가지고 온 예제로써, 1.pdf, 2.pdf, 3.pdf를 순서대로 합쳐서 Merged.pdf를 만드는 예입니다.

gswin32 -dNOPAUSE -sDEVICE=pdfwrite -sOUTPUTFILE=Merged.pdf -dBATCH 1.pdf 2.pdf 3.pdf

Acrobat이 점점 멀어지는 군요..
회사에 와서 “Acrobat없이 어떻게 PDF를 만드냐! 나는 그런것 들어본적도 없다”고 무식을 자랑하던 한국 Adobe의 법률 대행사가 기억나는군요..

검증 계획 작성하기

사실 검증이란 걸 처음 시작하면 정신이 아득해집니다. 도대체 뭘 어떻게 검증해야 하며, 언제 끝을 내야지만 하는가.. 이런 부분에 대한 교육이 부족했기 때문이겠지요


그래서, 이런걸 체계적으로 정리하자는 것이 “검증 계획(verification plan)”입니다. 설계 계획에 해당하는 spec. 작업이 설계에 있어서 가장 중요하듯, 검증에 있어서도 spec과 더불어 검증 계획이 중요합니다. 좀더 세분화된 검증 계획이 나중에 경험하게 될 인간 좀비가 될 시간을 줄여주는 거죠.


사실, 제가 처음 검증을 시작할 때, 단순히 “최대한 자동화해서 검증을 해야겠다. “라고 처음 생각을 가진지가 2002년이니 상당히 오랜 기간이 지났는데, 아직도 지지 부진합니다. 물론, 그 동안 설계니 뭐니 시간 문제로 띄엄 띄엄 손을 대었고, 회사내에서 본격적인 프로젝트로 launching은 아직도 못하고 있습니다만.. 제가 관리할 수 있는 입장이 되었으니, 이제야 비로소 verification쪽에 시간을 가질 수 있을 것이라 생각했습니다 (라고 이야기가 끝나면 얼마나 행복하겠습니까?) 만 설계가 부진한 부분을 보면 아직도 뛰어들어서 이것 저것 하느라고, 별로 진척이 없습니다. 여하튼.. 체계적인 계획 없이는 윗분들을 설득시키기도 저 자신을 노력하게 하기도 어렵지요. 검증이란 일이 저에게 있어서는 “맨땅에 헤딩”수준이라 잠시만 마음을 놓아버리면 바로~ 인간 좀비 모드로 변신해서 일을 하는 것도 아니고 아닌 것도 아닌 상황이 되죠.


여담으로 들어왔다가 엄청 돌았습니다.. 다시 본론으로 들어와서


검증계획이란 무엇이냐!


말 그대로, 스펙을 어떻게 분석할 것이며, 어떤 부분에 주의해야 할 것인가, 디렉토리 구조는 어떻게 가져갈 것이며, 스크립팅은 어떤 식으로 할 것인가에 대한 정의를 내리고, 각 부분에 대한 action item을 정의한 후, 해당 item을 어느 순간에 어떤 기준으로 완료할 것인가에 대하여 적어둠으로써, 이후의 검증을 어떻게 진행하고 어떤 기준으로 종결하고, 어떻게 마무리 할 것인가에 대하여 기술하는 문서입니다.


이러한 문서 기술은 우리나라 엔지니어들이 극히 싫어하는 일입니다만(저를 포함해서..^^;), 반드시 필요합니다.
체계적인 문서화는 반드시 작업 중에 발생할 수 많은 오류를 좀더 빨리 찾아내게 해주며, 좀더 쉽게 고칠 기회를 제공합니다. 좀더 좋은 엔지니어가 되시려면, 이 말을 항상 기억해야 한다고 생각합니다. 저도 물론 아직은 별로지만요..^^;


검증 계획 자체에 대하여 가장 체계화된 문서는 Peet James의 “the Five-Day verification plan” 입니다. 물론, 같은 제목의 책도 있습니다만, 저는 별 4개 이상은 주기 어려웠습니다. 첫 번째로 책의 내용이 이 on-line 문서를 좀더 체계화하고 예를 풍부하게 든것에 불과하기 때문에(전적으로 제 느낌입니다), 오히려 온라인 문서를 주욱 읽어보는 것이 더 도움이 되었습니다(미안해요 Peet! 책은 잘 읽었어요~ ). 책은 제 영어 실력의 한계 때문일지도 모르겠으나 상당한 가격을 주고 살만하진 않더군요.


이 문서의 내용은 각 날자별로 해야 하는 일과 빠지기 쉬운 오류(Gotchas)를 적어둔 문서입니다.


예를들면 첫째날은



  • 주요 인터페이스를 살펴보고, 누가 쓸것인지, 중요한 기능이 뭔지, 가장 많이 사용되는 모드가 뭔지 살펴볼 것

  • 각 인터페이스에 대하여 살펴보고, 어떤 BFM을 적용해야 하는지 볼 것

  • 사용 가능한 검증 인프라가 있나?

  • Behavioral model에 대해서 살펴보고 golden모델에 대하여 생각하고, 어떻게 비교할지 생각할 것

  • 어떤 검증 언어를 쓸껀가요?

  • 어떤 장비를 쓸건가?

  • 어떤 방식의 random 기반 검증이 가능한지 생각할 것

뭐 이런 식인거죠. 그리고, 이에 대한 예를 주욱~ 적어두고.. 이런 생각할 때 주의해야 할 사항들을 적어두고.. 이런식으로 풀어둔 책입니다. 뭐 자세히 설명할 필요 없이 위의 문서를 읽어보는 것이 좋겠죠.


그리 어렵지도, 그리 획기적이지도 않습니다만, 생각보다 처음 검증을 시작하시는 분들에게는 도움이 될 거라고 생각합니다. 저도 생각보다 많이 도움을 받은 문서이면서 책이거든요.^^; 자! 검증 엔지니어 지망하시는 분들 혹은 검증의 중요성을 느끼시는 분들이라면, 검증 계획을 한번 적어봅시다. (참고적으로.. 이 검증 계획 적는 일을 해보시면, 생각보다 쉽지 않다는 걸 깨닿는데 1시간이 채 걸리지 않습니다. 그런데, 꾸욱~ 참고 몇 프로젝트에 대해서 적어보면 점점 나아지니까 처음엔 적응기라 생각하고 버티세요..)