Monthly Archives: April 2007

LaTeX을 이용한 문서 작업

6 Replies

대부분의 회사에서 MS office를 기반으로 문서 작업을 하실텐데요. 저희 회사도 별다르지 않습니다. 그런데, 회사에서 “워드”로 문서 작업할 때 고생을 많이 하는 것이, 그림이 많아지면 열 때 한참 시간이 걸린다거나, 다른 부분의 내용을 갖다 붙이면 열심히 붙여둔 제목 순서가 어긋나 버린다던지.. 그런 일이 빈번합니다.


개인적으로 CVS의 열성적인 사용자인데, [wp]CVS[/wp]에서 binary형식의 word파일은 사실 버전 관리가 정상적으로 이루어진다고 볼 수 없죠(수많은 카피본을 만들뿐이니까요.). 그래서, 한 2년 전부터 간단한 문서는 MS word로, 매뉴얼과 Technical report는 [wp]LaTeX[/wp]으로 작성하고 있는데 아주 성공적으로 정착했다고 개인적으로 자평합니다.


많은 분들께서 LaTeX를 들어보셨을텐데, 많이들 힘들어 하는 이유가 “한글 사용이 어려워서..”, “설치 운용이 어려워서”입니다. 텍스트 창에서 명령을 써야 한다는 점은 적어도 프로그래밍 언어를 많이 사용하는 사람들한테는 별로 단점은 아닌 것 같습니다. (가끔 귀찮을 때는 있지만 말입니다.). 그런데, 이런 설치/운용에 대한 문제는 KTUG에서 제작한 KC2006을 기점으로 사라졌다고 생각합니다. 팀의 후배들한테 소개해주었는데, 다들 쉽게 설치/운용하고, 어렵지 않게 적응하더군요.


이제, 저희 팀에서는 내부적으로 [wp]LaTeX[/wp]/KC2006(실제적으로는 KC2006-2)을 기반으로 하는 환경에서 작업을 하려고 합니다. 이렇게 함으로써 작업 있어서 몇 가지 장점이 생기는데요..



  1. PDF writer가 필요 없다. (LaTeX은 양질의 PDF를 만들어 줍니다!)

  2. 공동 작업에 있어서 CVS를 이용하고, 이에 따라 문서의 버전 관리가 쉬워진다

  3. 자유로운 comment 사용이 가능하기 때문에 좀더 명확한 문서 작성이 가능하다.

  4. 일관된 문서 형식을 유지하기가 수월하다

  5. 조건부 문서 작성이 쉽다. (어떤 peripheral이 포함되는지, 어떤 feature가 포함되는지에 따라 compile time에 문서를 포함하는.. single sourcing이라고 하신 거 같은데..)

  6. 소소하지만.. 제가 회사 문서를 위하여 작성한 Acroedit 스크립트, 회사 문서 스타일등을 사용할 수 있습니다. verilog 소스 코드를 위한 스크립트 라던지.. ^^;

위의 장점은 워드로도 가능합니다만, LaTeX을 사용하면 더 효과적이 되는 부분이지요. 물론, 단점도 존재합니다. 어찌보면 제가 LaTeX을 사용하면서 느끼는 문제일 수도 있습니다.



  1. 표 작성이 어렵다.
    하드웨어쟁이들은 비트당 뭐뭐뭐 하는 걸 표로 많이 표시하는데, LaTeX로 작성하면 좀 귀찮아집니다. 이럴때는 Excel로 표를 만들고 OLETeX를 이용해서 그림으로 변환한 다음에 TeX에 삽입하는 편법을 사용합니다. [1]OLETeX는 OLE기능을 위하여 사용할 수도 있습니다만, 저는 개인적으로 EPS 생성 프로그램으로만 사용합니다. ^^; WMF2EPS를 원래 썼었는데, shareware이기도 하고.. OLETeX가 떨어지는 부분을 잘 모르겠더군요.

  2. 다른 사람들의 저항감이 있다
    특히 관리부터 사람들과 윗분들…

그래서, 내부적으로만 일단 사용할 예정이죠. 사실 이런 문제는 굳이 말로 떠들어봤자 힘만 들거든요. 직접 보여주는 것이 최선이라 생각합니다.


혹시 관심 있으신 분은 http://www.ktug.or.kr/에 방문해 보십시요.

Notes & References

Notes & References
↑1 OLETeX는 OLE기능을 위하여 사용할 수도 있습니다만, 저는 개인적으로 EPS 생성 프로그램으로만 사용합니다. ^^; WMF2EPS를 원래 썼었는데, shareware이기도 하고.. OLETeX가 떨어지는 부분을 잘 모르겠더군요.

뭔가 좀 지저분해졌습니다.

Leave a reply

Daum에서 Adclix라는 것이 나왔다고 해서 한번 달아봤습니다.
올블로그에서 워낙에 난리라서 뭔가 하고 시험삼아 달아보기는 했는데, 구글 애드센스보다는 약간 더 깔끔해보이지만, 광고의 특성상 별로입니다. ^^;
게다가, EDA 업체의 제품광고나 Fabless 업체들의 구인 광고 같은 것이 올라오면 또 모를까, 시험삼아 달아본 광고중에서 이 블로그와 그나마 연관성 있는건 AMD cpu 광고 정도일까요..(하긴, 구글 에드센스도 국외에서는 해당 부분 광고가 도움이 많이 됩지만 국내에서는 이런 업체에서 광고를 낼리 없으니까요..)

전반적으로 광고의 효과가 있을거라는 별 기대는 하지 않습니다만, 호스팅/도메인 비용정도만 나와도 뭐 좋겠죠.

Coverage와 Assertion

2 Replies

검증에 있어서 고려되어야 하는 사항중에 하나는 “언제 검증을 그만 둘 것인가”입니다.


너무나도 쉬운 질문이지요? 뭐, 검증할 부분을 다하면 검증을 그만 두면 되죠. 그럼 질문을 바꿔보겠습니다. “검증할 부분에 대하여 모두 검증했는지는 어떻게 알지요?”


그것이 오늘 말씀드릴 coverage에 대한 부분입니다.


사실 이쪽 계통에서 coverage라는 이름으로 검색하면 처음에 나오는 것은 아마도 falut coverage/test coverage일 것입니다. [wp]DFT[/wp]/Testing 부분에서 사용하는 용어인데, 만들어진 test vector가 얼마나 많은 tr. 을 천이시켜 볼 수 있느냐를 나타내는 말이죠(값을 천이시킬 수 있어야지만, stuck-at-0/stuck-at-1 fault를 잡아낼 수 있으니까요). 여하튼.. 이때 test coverage는 입력된 테스트 벡터에 의하여 천이 시킬 수 있는 transistor의 비율을 나타냅니다.


검증에 있어서 coverage도 마찬가지 입니다.


기본적으로 두 가지 coverage는 충족해야 하는데, 아주 기초적인 값이 code coverage, 약간 더 복잡하지만 반드시 체크해야 하는 부분이 functional coverage입니다.


이 중 code coverage는 주어진 RTL 코드 중에 검증 벡터에 의하여 활성화 되는 코드의 비율 정도로, functional coverage는 “점검해야 할 기능 요소 대비 주어진 벡터로 잡아낼 수 있는 기능 요소의 수” 정도로 요약 될 수 있습니다. Code coverage는 그나마 좀 자동화하기 쉽습니다.


이미 존재하는 RTL 코드가 시뮬레이션 도중에 사용되는지를 확인하면 되는 문제니까 말입니다. 물론, 여기서 말한 [wp]code coverage[/wp]는 가장 기초적인 line coverage를 의미합니다만… ^^;
여하튼, 이 code coverage는 검증에 있어서 가장 기본적인 요소가 됩니다. 적어도 자기가 만든 RTL 코드가 검증 벡터에 의하여 모두 확인되었는지는 알고 지나가야 할 문제니까요.  


다시 처음 질문으로 돌아가서 “점검해야 할 기능 요소의 수”는 어떻게 알수 있겠습니까???  물론, 설계자의 spec안에 있습니다. RTL 코드란 궁극적으로 spec안에 제시된 기능을 구현한 것이니까요. 그런데, 이걸 검증 과정에서 빼놓지 않고 검증 했는지를 알기란 상당히 어렵고, 자동화 대상이 되기 어렵습니다. 그래서 assertion이 등장합니다.


[wp]assertion[/wp]은 software부분에서는 이미 폭넓게 사용되던 개념입니다. 코딩에 있어서는 어떤 가정(이 조건은 절대 들어오지 않는다던지.. 어떤 변수는 어느 구간안에서는 절대 어떤 값을 지니지 않는다던지..)을 하는 경우가 있는데, 이런 가정하지 않은 경우가 온다면 구현된 코드가 “절대” 안전 할 수 없으며, 정의되지 않은 동작을 시도하면서 프로그램이 오동작하게 됩니다. 이런 경우를 확실히(assert)  하기 위해서 assertion이라는 것을 사용합니다. 즉, 가정하지 않은 경우가 발생하면 동작 과정에서 “조용히 버그를 발생시키기보다는 경고 메시지와 함께 끝나자”는 것입니다. (여기에 대한 주요한 내용은 이 분야의 선구자(?)인 Foster의 “Assertion-based Design”이라는 책을 보면 잘 나와 있습니다.) 이 책의 내용을 기반으로 OVA라는 라이브러리도 있고, 실무에서 많이 사용된다고 합니다. [wp]PSL[/wp]/Sugar라는 표준 언어가 제정되기도 했지요. (systemverilog에서는 언어수준에서 assertion이 제공됩니다.)


이 assertion 기능을 좀 더 전향적으로 사용하면, spec을 정의할 수도 있습니다. 즉, 어떤 기능에 대하여 assetion으로 지정해 두는 것이지요. 이런 assertion은 테스트 벡터에 의하여 지정된 기능 요소가 검증되었는지 나타내는 기능으로 사용되는 것입니다. 이걸 바꿔 말하면, 주어진 assertion의 수 대비 테스트 벡터에 의하여 점검된 assertion의 수로써 우리가 원하던 “spec에 정의된 기능을 테스트 벡터가 얼마나 수행하였는지”를 나타내게 되며, 이는 달리 말하면 functional coverage를 나타내게 됩니다. !!!


드디어 전혀 관계 없어 보였던 두 개의 기능이 만나 하나의 art가 되는 순간이죠. ^^;


몇 번 적었습니다만, Lint, code coverage, assertion의 개념은 모두 소프트웨어 공학쪽의 개념이었는데, 이제는 하드웨어 설계로 넘어오고 있습니다(사실 다 넘어왔죠..) 참 재미있습니다.