design

Open Source Hardware

우리가 흔히 사용하는 컴퓨터의 운영체제는 윈도우 입니다. 이 윈도우는 마이크로소프트 회사에서 개발한 운영체제입니다. 다양한 하드웨어를 지원하면서도 버그는 거의 없는, 정말 잘 만들어진 운영체제죠.

윈도우, 그 다음으로 사용자가 많이 쓰는 운영체제는 애플회사에서 만든 macOS일 듯 합니다. 한국에서야 맥북 보기는 어렵진 않아도 맥을 쓰는 사람을 보기는 (맥북에 윈도우를 설치...) 어렵지만, 이곳 미국에서는 윈도우 쓰는 사람들 찾는게 더 어려울 정도로 많은 사람들이 맥을 사용하고 있는 듯 합니다. 저 또한 맥 운영체제를 쓰는 랩탑이 집에 있구요. 얼마 전까지만해도 회사 랩탑으로 맥북프로를 사용하고 있었습니다.

그리고, 조금은 특별한 운영체제가 그 다음을 잇죠. 개인용 컴퓨터로는 아마도 세번째 위치겠지만, 전 세계 서버 컴퓨터를 다 추려본다면 당당히 1위를 차지하고 있는 운영체제인 리눅스입니다. 아마 모바일까지 포함한다면 안드로이드가 1위겠지만, 안드로이드도 기반은 리눅스 운영체제 위에서 돌아가고 있죠. 제가 사용하고있는 회사 랩탑도 리눅스이고, 회사 데스크탑도 리눅스입니다.

이렇게 당당히 1위를 차지하고 있는 리눅스의 핵심 운영 소프트웨어, 리눅스 커널은 오픈소스입니다. 즉, 내부 코드가 완전히 공개되어있습니다. 누구나 개발에 참여할 수 있고 누구나 소프트웨어를 수정해서 재배포할 수 있죠.

언듯 들으면, 아무나 개발하는데 어떻게 소프트웨어가 잘 돌아가지? 버그 투성이 이진 않을까 생각이 듭니다. 그러나 이 부분은, 많은 사람이 참여할 수 있다는 데에서 큰 장점이 생깁니다. 마치 위키피디아 같이, 집단 지성으로, 더 많은사람이 코드를 보게되고 잘못 된 코드는 여러 사람이 써보고 버그 리포트를 만들어내면서 수정되게 됩니다.

이 리눅스 커널이 리누스 토발즈씨가 1991년에 세상에 내놓았으니, 이제 28년이 넘었네요. 그 사이에 제 개인적인 생각으로는 세상에 큰 영향력을 끼친 운영체제가 되었다고 생각하네요.

OSS (Open Source Software)가 각광을 받고, 여러 오픈소스 소프트웨어가 나오고 사라지곤 합니다. 맥에서 사용할 때만 봐도 제가 쓰던 개발도구, 프로그래밍언어, 그 모든게 다 오픈소스였습니다. 마음만 먹고, 실력만 된다면 언제든 소스코드를 수정해서 프로그램을 개선하고 패치를 보낼 수 있죠.

반면, 하드웨어 개발은 여전히 소스코드가 철저히 감춰진 채로 개발이 되어왔습니다. 가장 쉬운 예로는 인텔 CPU가 있겠네요. 인텔CPU는 윈도우 운영체제와 마찬가지로, CPU를 만드는 소스코드 HDL (Hardware Description Language)이 공개되어있지 않습니다. ISA (Instruction Set Architecture)라고 CPU가 이해할 수 있는 명령어가 어떤 것이 있는지 설명해 놓은 것만 공개되고, 그 조차도 사용하는 것에만 쓸 수 있고 ISA가 동일한 CPU 설계는 할 수 없게 지적재산권 보호를 해 두었습니다.

제가 참여했던 모든 프로젝트도 죄다 소스코드가 비공개였죠. 심지어 참여하는 하드웨어 프로젝트의 일부분의 소스는 개발자인 저도 볼 수 없었습니다. IP (Intellectual Property)를 다른 회사에서 구입하는 경우, 소스코드가 비공개 되어서 전달됩니다. 암호화 되어있어서, 동작한단는 것을 일단은 믿고 가는 수 밖에 없었죠. 심지어 핵심이라 생각되는 프로세서 (ARM 코어)도 베일에 쌓인 블랙박스였습니다.

그러던 와중에 하드웨어에도 오픈소스 개발이 조금씩 생겨납니다. 20여년 전, 거의 취미수준의 개발자들이 소스코드를 올려놓았던 opencores.org 사이트도 기억이 나는데, 실제로 오픈소스 하드웨어 개발이 주목을 받기 시작한 것은 RISC-V 개발부터였던 것 같네요.

이에 관해서 제가 이전 2016년에 쓴 글도 있습니다. 그 때에 버클리에서 RISC-V를 공개하면서 ISA를 오픈했습니다. 누구나 같은 ISA로 동작하는 코어를 만들 수 있게 허용했죠. 그 이후로 지금까지, 정말 많은 RISC-V 코어가 만들어졌습니다. 사이트에서 보면 SoC를 제외하고서라도 코어만 42개가 현재 있네요. 그만큼 많은 곳에서 관심을 가지고 있다는 뜻이고, 제 예상이 틀렸다는 말이기도 하지요. 그래서 더 다행입니다.

아쉬운 점은, 위의 코어 개발이 대부분 대학에서 이뤄진 부분이 많고, 실제 코드를 보면 합성은 잘 되지만 깔끔하게 구현된 것 같은 코드는 아닌 것이 많습니다. 게다가, 코어 소스는 공개되어있지만, 실제 검증했던 검증 환경 부분은 거의 공개되어있지 않아 이 코어를 얼마나 신뢰할 수 있는지 측정할 만한 데이터도 없죠. 그냥 FPGA위에서 돌려보고 믿는 수 밖에 없습니다.

다행인 점은, 이 부분이 조금씩 개선되어가고 있다는 것이겠네요. 올해 6월 RISC-V Summit에서 여러 회사가 협력해서 [CHIPS Alliance][]를 만들었습니다. 여기에선 개발과 검증을 모두 공개하는 것을 목표로 합니다. 저희 그룹에서 일하는 엔지니어는 UVM 환경에서 동작하는 RISC-V Stream Generator를 공개했죠. 코어를 꼼꼼하게 검증할 수 있어서 논리적인 동작은 이상이 있는 지 확인해 볼 수 있습니다.

이 CHIPS Alliance는 LSF (Linux Software Foundation) 의 일부로 활동하게 됩니다. LSF 멤버이면 개발에 참여할 자격이 주어지는 걸로 아는데 확실히는 아직 모르겠네요. 소스코드는 CHIPS Alliance 깃헙에 공개되어 있습니다. (RISC-V Stream Generator는 구글 깃헙에 공개되어 있습니다.)

그리고 오늘 또 다른 오픈소스 프로젝트가 공개되었습니다. [OpenTitan][ext:opentitan] 프로젝트인데 lowRISC가 중심이 되어, 구글, Western Digital, G+D, Nuovoton이 같이 참여해서, 오픈소스 개발방식으로 소스코드에서부터 실제 칩을 받는데까지 전 과정을 투명하게 공개해서 개발하는 것을 목표로 합니다. 실제 실리콘 프로세스 라이브러리는 공개할 수는 없겠지만, 현재 업계에서 최대한 공개할 수 있는 부분은 공개해서 개발하려고 합니다.

완성된 버전을 공개하는 것은 아닙니다. 아직은 기본적인, 다르게 보면 취미활동이라고 불러도 별반 다를 것 같지 않은 기본적인 peripheral IP와 코어, 그리고 그 사이를 엮어주는 스크립팅등이 공개되어 있습니다. 앞으로 만들어야 할 부분이 더욱 많죠.

목표는 투명하게 공개된 시큐리티 칩을 만드는 겁니다. 투명하게 공개된 코드를 기반으로 칩을 제작함으로써 신뢰를 높이고 취약한 부분을 조기에 발견할 수 있게 될 것입니다.

오픈소스 소프트웨어도 그렇지만, 관심을 받지 못하면 언제 그랬냐는 듯 소리소문없이 사장될 지도 모릅니다. 그래서 걱정이 큰 것도 사실입니다. 저에겐 큰 도전이지만 (제가 만든 개판 오분전 소스코드를 공개해야 하니 더욱...) 대부분의 사람들은 그냥 한번 스윽 보고 잊어버리게 될 프로젝트일 수도 있겠죠.

Specification Language

그동안 글이 뜸했었네요. 최근에 이직을 하게 되어서 정신이 없기도 했었고 (그런 것 치고는 3월 이후로 글이 없긴 했네요 :) ) 회사노트북만 사용하면서 글을 쓸 환경을 만드는 게 여의치 않았기도 했네요. 웹 브라우저를 켜고 바로 글을 쓸수 있는 환경이 아니라 haskell도 설치해야 하고, static site generator도 컴파일 해야 하고, 키도 만들어야 하고, 이미지 파일 싱크도 해야 하고 여러 복잡한 준비과정이 필요하다 보니 아예 처음부터 발걸음이 떼지지 않았다고 할까요?

얼마 전 날 잡고 작업을 했습니다. 이미지는 구글 드라이브에서 싱크하던 걸 아예 도메인을 새로 파서 이미지는 따로 CDN 을 통해서 불러오게 바꿨구요. 회사 노트북 보안 단계도 한단계 낮춰서 [Homebrew][]를 사용할 수 있게 해뒀네요.

이런 과정을 거치고 나니 무언가 글을 하나라도 써야겠다는 의무감이 좀 생깁니다. 그래서 오늘은 지인들과 모여서 이야기 했던걸 풀어놓을까 합니다.

이전 회사에서 일할 때에는 문서를 작성할 상황이 많지 않았는데, 이직을 하고 난 후 문서 작성, 그중에서 스펙문서(Specification)를 작성하는 경우가 많네요. 회사 분위기가 다르다보니 일하는 방법도 많이 다르네요. 제가 영어권 사람이 아니다보니 스펙 문서를 쓰는게 항상 부담이 많이 됩니다. 말도 제대로 못하는 외노자인데, 문서로 다른사람을 이해하게 하는 글을 써야 하는게 정말 어렵더라구요.

영어권 사람들과 스펙을 보완하고 수정해 가는게 정말 기나긴 시간이 걸립니다. 하드웨어 디자인은 순식간에 만들었는데, 문서를 보완해가다보니 두달이 지나도 문서가 완성될 기미가 안보이더라구요. 그러다 보니 힘들기도 하고, 지치기도 하고, 무슨 좋은 방법이 없을까 지인들과 이야기를 하게 되었네요.

그런 부분을 해결할 방법을 찾아보게 되면서 자연스레 영어 기술을 효과적으로 하는 방법을 궁리하기 시작했습니다. 가장 중요한 것은 표현을 제약하는 것이더군요. 스펙을 작성하거나 읽다보면 항상 접하는 조동사가 몇개 있는데, 이런 조동사는 스펙에서 정해진 의미로만 쓰인다고 암묵적으로 합의 되어 있습니다. 그 조동사는 shall, should, may 등이 있는데, 강제(mandatory)하는 것에서부터 점점 추천(recommendation)하는 것까지 표현하려고 사용됩니다. shall은 반드시 지켜야 하는 조건을 이야기하지요.

이게 어디서 나왔는지 알아보니, IETF RFC 2119에서 제안된 내용이더군요. 그런데 이 RFC를 만들 때 왜 조동사만 정의 했을까 의문이 들더군요. 이 제안을 할 때 문서의 작성 규칙이나, 아니면 다른 부분까지 제한하는 것은 왜 하지 않았는지 궁금해집니다.

그래서 그런 규칙을 만들어야 하나.. 고민하면서 이야기 하다보니, 차라리 Esperanto 언어같이 단순한 규칙을 가지고 하나의 단어가 하나의 뜻만을 가지고 있는 언어로 기술하는 것도 낫겠다.. 라는 생각도 해보고, 그러면 Esperanto와 1:1로 매칭되는 단어사전을 이용해서 그 단어만 가지고 영어로 기술하는 것도 괜찮지 않을까? 하는 이야기도 했네요.

그러다 링크를 하나 받았는데, 이미 20년 전에 그에 관해 토의가 꽤 있었더군요. 꽤 다양한 스펙 언어가 이미 공개되어 있었네요. 대략 훑어보니 저희가 의도한 것과 비슷하게 단어와 표현법을 제약하는 게 주된 방법인 것 같습니다.

그중에 Attempo Controlled English가 꽤 눈길을 끕니다. 이제 문서를 읽어보기 시작하는데, 저희의 의도와 비슷한 말을 하고 있다보니 더 관심이 가나봅니다.

제 메니져에게 지나가는 듯이 말했더니, 아니나 다를까 영어 네이티브인 메니져는 아무런 관심이 없군요. 영어로 글을 쓰는게 물 흐르듯이 되다보니 이런 것에 관심이 갈 리가... 그래서 그런지 ACE도 스위스 취리히 대학에서 만든거군요.

역시 영어 네이티브가 아니여야 이런 궁리를 하는거구나... 싶네요.

개발자의 평생공부

임백준님의 칼럼 글이 좋아서 공유합니다. 최신 트렌드를 알아야 할 필요가 있긴 하지만, 그것보다 중요한 것이 끈기, 집중력, 문제를 알아채는 감각 이라는 겁니다. [이전 글][pitfall-of-design-change]에서도 언급한 것이지만, 꼼꼼함이 정말 중요하다는 거죠.

일을 하다보면, 창의적인 능력이 중요한 분야도 더러 있지만, 실수없이 해내야 하는 일이 더 많다는 것을 느낍니다. 이 글을 쓴 임백준님도 비슷한 생각이신 것 같네요.

Pitfall of Design Change

하드웨어 설계는 한번 실수에 대한 비용이 정말 큰 것 같습니다. 공정이 세밀화 되면서 실수 하나로 인해 작게는 Metal ECO에서 크게는 Re-synthesis 까지 가게 되면 비용은 수십억이 소요될 수도 있죠.

최근에 겪었던 일화를 하나 소개할까 합니다.

새로운 프로젝트가 진행되면서 기존에 있던 디자인을 개선을 하게 되었습니다. 이 모듈은 주변의 몇몇 모듈과 서로 신호를 주고 받고 있었죠. 개선을 하면서, 내보내는 신호의 특성을 바꾸게 되었는데, 이 수정되는 부분을 통신하는 반대편 모듈에도 적용을 하였습니다. 이상없이 잘 동작하는 것을 보고 칩을 Tape-out했죠.

문제는 다른데서 터집니다. 또다른 개선버전 프로젝트가 Original project에서 갈라져 나오게 되었는데, 이 프로젝트에서 개선된 디자인을 하나만 가져다 쓰게 된거죠. 서로 바뀐 프로토콜을 이해하고 수정된 디자인이 아니니, 기존 디자인은 예전 방식으로 신호가 올 것이라 기대를 하고 새로운 디자인은 새로 정의된 방식으로 신호를 주게 됩니다.

일반적인 상황에서는 이 부분이 보이지 않았으나 예외의 상황 -- 버퍼가 가득찼다던지, 버퍼가 비었다던지 -- 에서 문제가 발생합니다. 결국 이 프로젝트도 칩이 이미 나와버려서, 이 부분을 수정하려면 Metal ECO 외에는 선택지가 없었고 큰 비용을 지불하고 새로운 마스크를 만들어야만 했습니다.

어떻게 미리 막을 수 있을까요?

어떻게 이런 불상사를 미리 막을 수 있을까요?

Design Stage

일단, 디자인 단계에서부터 차근차근 방법을 생각해 봅시다. 디자인을 할 때, 양쪽 어디든 한 곳에서 SVA(System Verilog Assertion)을 사용 해, 기대하는 신호의 특성을 기술했었다면 디자인을 검증하는 단계에서 이 문제를 미리 찾을 수 있었을 겁니다. 예를 들면, 신호가 req/grant 방식에서 pulse 방식으로 바뀌었다고 하면, 양쪽의 SVA는 이렇게 달랐을 겁니다.

// Old Design (In)
property p_req_grant;
    @(posedge clk) disable iff (!rst_n) I_REQ |-> ##[1:3] I_REQ && O_GRANT;
endproperty
ap_req_grant: assert property (p_req_grant);

// New Design (Out)
property p_pulse;
    @(posedge clk) disable iff (!rst_n) O_REQ |-> ##1 !O_REQ;
endproperty
ap_pulse: assert property (p_pulse);

그러면, 받는 쪽에서 의도하지 않은 신호가 왔을 경우 Assertion Error가 났을겁니다.

다른 한 방법은 신호의 특성이 바뀌었으니 port 이름도 바꾸었다면 두 디자인을 엮을 때 발견할 수도 있었을 겁니다. 위의 예를 들면 O_REQ가 O_REQ_PULSE 로 바뀌는 것을 예로 들 수 있겠네요.

IP Verification, SoC Verification

만일 디자인 단계에서 이 부분을 걸러내지 못했다면, 그 다음에 있을 검증 단계에서는 어떻게 찾을 수 있었을까요? IP 검증이나 SoC 검증에서 Functional Coverage가 잘 기술되어 있었다면, 이 문제를 발견할 수 있었으리라 봅니다. 너무나 단순한 실수임에도 불구하고, 그 상황이 예외적인 상황이었다면 그 문제를 발견하지 못하고 진행될 경우가 많습니다.

그러나 시작은 이 한 부분이었을지라도 그것에 영향을 끼치는 부분은 꽤 많이 있습니다. 위에서 예를 들었던, 버퍼가 가득찬 상태를 보죠.

만일 covgroup이 buffer full 상태를 포함하고 있었다면, 검증 엔지니어가 coverage report에서 부족한 부분을 발견하고 해당 testcase를 추가했을 겁니다. 그러면 문제가 조기 발견될 수 있었겠죠.

covergroup buffer @(posedge push_req);
    full: coverpoint buf_full {
        bins not_full = {0};
        bins full     = {1};
    }
    empty: coverpoint buf_empty {
        bins not_empty = {0};
        bins empty     = {1};
    }
endgroup

Closing

디자인을 할 때에나, 디자인을 수정할 때에 엔지니어에게 가장 중요한 것은 아무리 봐도 꼼꼼함 인 것 같습니다. 저도 시간에 쫓기며 워낙에 덜렁대다보니 이런 저런 실수를 종종 해왔는데요. 저부터 반성을 많이 하게 됩니다.

하드웨어 디자인 엔지니어 대부분이 systemverilog의 assertion 이나 covergroup을 들어본 적도 없다는 사실에 깜짝 놀랄 때가 많습니다. 이미 수십년간 하드웨어 디자인 언어가 발전해 오면서 가장 빈번하게 발생하는 사람에 의한 실수를 막을 수 있는 많은 방법이 언어에 녹아들어있습니다. 이런 새롭게 추가된 기능을 툴이 허용하는 한도 내에서 충분히 활용한다면, 꼼꼼함이 부족한 저같은 사람에게 큰 도움이 될 것 같네요.

새로운 기능을 시도할 때 주의할 점은, 이 기능이 현재의 디자인 프로세스에 모두 적용될 수 있는 지 검토하는 것 일것 같습니다. SystemVerilog 가 Hardware Description 기능도 많이 추가되었는데, 그 중 몇몇은 현행 버전 도구에서도 아직 지원하지 않는 것이 있습니다. 이게 Design Compiler가 지원을 하지 않으면 합성 전에 수정이 되어 괜찮은데, Design Compiler는 지원을 하고, FPGA Synthesis 도구는 지원을 하지 않거나, LEC(Logic Equivalent Check) 도구가 지원을 하지 않게 되면 나중에 이러지도 저러지도 못하는 상황이 발생할 수 있습니다.

모두 꼼꼼함을 최 우선 덕목으로 삼고 버그 없는 칩을 잘 만들어 봐요.

Reference

• SystemVerilog Assertions
• Functional Coverage

SystemVerilog for Design

SystemVerilog를 RTL(Register Transfer Level) 디자인에 쓴다는 것은 듣고 있었지만, 써봤자 'logic', 'always_ff' 같은 것 정도만 생각하고 있었다가 각잡고 "SystemVerilog for Design" 책을 읽기 시작했습니다.

정말 알찬 내용이 많네요. 너무 기술적으로 도태되어있었다는 생각이 듭니다.

참고하시라고 링크

1. Read.Pudn
2. Sutherland 논문

Assertion (SVA)

Assertion에 대한 좋은 논문도 있네요. 역시 같은 저자입니다.

1. Sutherland 발표자료
2. SNUG 논문

하드웨어 디자인 코드리뷰

소프트웨어 분야는 하루가 다르게 새로운 기술이 쏟아져 나옵니다. 특히 웹 관련 기술은 최근에 트렌드가 정신없이 계속 바뀌고 있죠. 오죽하면 자바스크립트 기술 변화에 대한 유머까지 등장했겠어요.

이런 발빠른 변화를 쫓아가는 게 정말 벅찰 듯 합니다. 그런데 하드웨어 분야는 기술은 계속 바뀌어 가는데 개발 플로우는 십수년 째 전혀 바뀌지 않고 있어요. 개발 언어인 Verilog HDL 언어도 구닥다리 1995 버전을 쓰는 경우가 태반이고, 실제 칩 디자인에 SystemVerilog 2012를 사용하는 걸 본 적이 없네요. 검증은 대부분 SystemVerilog로 넘어가긴 했지만, 아직 설계는 여전히 Vim으로 한땀 한땀 정성들여 Verilog 포맷으로 코딩합니다. 수백개가 넘는 port를 연결하는 걸 보고 있으면 마치 수공예를 보는 것 같기도 하고, 어셈블리 코딩을 하는 것과 비슷한 느낌을 받기도 합니다.

사실 하드웨어는 한번 버그가 발생하면 수정하는 데 비용이 상당히 많이 들기에 항상 조심스러운 접근을 할 수 밖에 없다는 게 이해가 안되는 것은 아닌데, 그 정도가 심해도 너무 심하다는 생각이 듭니다.

Version Control System

이전 회사에 근무할 때에는 소스 코드 관리를 Clearcase라고 상용 툴을 썼는데, 거의 SVN과 유사한 시스템이었습니다. SVN만 되어도 사실 감사할 따름인데, 이 CC를 그냥 branch도 없고 tag도 없고 그냥 fetch, commit만 하는 수준으로 사용하고 있었어요. 거의 백업을 위해서 쓰는 정도였죠.

게다가 IP 디자인은 Clearcase도 아니고 초창기 파일 기반 버전 관리 도구인 CVS를 사용하고 있었습니다. CVS를 보았던 그때의 충격과 공포는 아직도 생각 나네요.

옮긴 회사는 더 충격적이게도 CVS에 GUI를 입힌 것 같은 도구를 사용합니다. 태그와 브랜치 기능이 있긴 한데 사용하기 까다롭고 한눈에 들어오지 않아서, 주변에서 브랜치를 쓰는 걸 본 적이 없네요. 파일 별로 버전관리가 따로 되다보니 하나의 IP가 여러 프로젝트에 쓰일 경우 점점 서로 뒤엉켜가는 걸 보게 됩니다.

Code Review

상황이 이런 지경인데, RTL (Register Transfer Level) 코드를 기술하고 소스코드 저장소에 업데이트 할 때 멤버라면 아무나 올릴 수 있습니다. 브랜치도 아니고, main에 올릴 수 있게되서, 하나의 잘못된 커밋이 전체 테스트를 fail 하게 되는 경우도 가끔 봅니다.

이런 일련의 경험을 하면서, '왜 하드웨어 디자인은 소프트웨어의 기법을 적용하지 않을까?' 하는 의구심이 계속 듭니다.

소프트웨어는 일찌감치 코드 리뷰에 대해 많은 고민을 해 왔습니다. 심지어 CVS 를 사용할 때에도 maintainer가 patch를 받아서 CVS에 업데이트 하는 것이 일반적이었고, 그래서 코드 리뷰는 자연스럽게 usenet이나 email 을 통해 이뤄지곤 했습니다.

그것조차 비효율 적이라 코드리뷰를 편하게 하기위한 시스템이 등장했지요. [Gerrit][ext:gerrit]은 구글이 코드리뷰를 하고자 Git 기반으로 만들어진 코드리뷰 도구이고, Github의 Pull Request는 email로 주고 받던 패치를 시스템상에서 간편하게 적용할 수있게 만든 도구입니다.

이 두 시스템 모두 main 저장소에 업데이트 할 수 있는 사람은 몇 안되고 나머지 사람은 각자의 branch나 저장소에서 작업 후 메인에 반영하기 위해 코드를 리뷰해야만 합니다. 이로 인해 약간의 지연이 발생하긴 하지만, 결과적으로 깔끔한 코드가 유지될 수 있습니다. 급한 경우엔 Gerrit은 main에도 곧장 업데이트 할 수 있도록 하고 있구요.

그러나 하드웨어는 이런 과정이 거의 없다고 봐도 무방합니다. 저장소에서 이러한 기능을 지원하지도 않을 뿐더러, 코드 리뷰를 한다고 하면 (리뷰하는 일도 거의 드물지만) 회의실에 모여서 소스코드 창을 띄우고 한줄 한줄 보는게 보통입니다. 시간을 가지고 코드를 깊게 볼 기회가 거의 없다고 봐도 되죠.

How to Improve?

일단은 코드리뷰가 가능하도록 저장소와 코드 리뷰 도구를 재정비하는 게 필요한 것 같아요. 지금은 웍스테이션 안에서만 코딩이 가능하다보니, JIRA와도 연동이 되지 않는게 보통입니다. 즉, 이슈와 실제 디자인 수정을 연결할 방법이 거의 없다고 봐도 되죠. (로그도 파일별로 남다보니..)

가장 우선은 Git based 저장소로 바꾸고 gerrit이나 pull-request가 가능한 GitLab이라도 써야 할 것 같아요. Subversion도 나쁘지 않은 선택이나, branch를 빈번하게 사용하고 코드 리뷰 요청을 넣는 flow에서는 조금 비효율적이라 git이나 mercurial이 더 나은 선택인 것 같아요.

여기에 더해서 Continuous Integration 을 이용해 바로 small set regression test를 돌릴 수 있게 설정해 둔다면 더욱 좋겠죠. (라이센스 비용은 좀 나가겠네요) pull request 전에 이 small regression을 통과하고 (아니면 적어도 compile과 elab까지만이라도) 그 후에 merge되는 게 정말 중요한 부분인 것 같습니다.

외부에서 받는 IP 같은 경우는 코드를 수정할 일이 거의 없다보니, IP는 release에 두던지 하고 configuration만 저장소에 두어서 리뷰를 할 수 있게 해야 합니다. 파라미터 세팅을 잘못 해서 빈번하게 실수가 발생하는 것을 봐서 (NIC CDAS scheme이라던지, outstanding capability라던지) 세팅 리뷰는 반드시 필요합니다.