2017

2017년도 지름 결산

매년 계속 되는 지름보고 입니다.

• 2015년 지름결산
• 2016년 지름결산

임의 순서로 중요한 것만 추려보았습니다.

1. AKG K702

   년초에 영국 아마존 (영마존이라 부르죠)에서 아주 저렴한 가격에 풀려서 회사일 하면서 들어보려 구입한 헤드폰입니다. 백오더라 받는데 한달이 걸리긴 했지만, 3대 레퍼런스 헤드폰으로 불리는 녀석이라 기다릴만한 가치가 있었습니다.

   다만 저에겐 좀 착용이 불편하고 귀가 아파서 얼마 듣지 못하고 지인에게 선물했네요.

2. Code & Quill Origin Notebook

   기존 Clairefontaine Agebag Clothbound 노트북이 실제본에서 떡제본으로 바뀌면서 좍~ 펼쳐지지 않아서 물색한 노트북입니다. 일단 디자인은 정말 깔끔해서 좋아요. 백색 인조가죽같은 하드커버도 마음에 듭니다. 다만 커버가 너무 두꺼워서, 다음에는 Traveler Notebook 버전으로 구매해 볼까 합니다.

   종이 재질은 클레르퐁텐 노트북에 비해 약간 아쉽습니다. 만년필이 뒤에 비치는 것은 아닌데, 좀 잘 번지네요. 그러나 그것보다 아쉬운 것은 선이 그려진 버전인데 선 간격이 너무 조밀합니다. 몰스킨같이 조밀해서 한 출 쓰고 한줄을 띄어야 하나 고민될 정도네요. 결국 다시 클레르퐁텐으로 돌아왔습니다. 고민하고 있는 것은 클레르퐁텐 Essential 을 사용하느냐 아니면 돈을 좀 더 주고 로디아 Webnote를 쓰느냐네요.

   Baron Fig Confidant라는 노트북도 있긴 한데 이것도 종이 질이 클레르퐁텐에 미치지는 못하다고 합니다.

3. iRobot Roomba 805

   이전, 삼성 로봇 청소기에 데인 터라 로봇청소기는 거들떠 보지도 않았는데, 바닥 진공청소기는 자주 돌리는 게 좋겠다 싶어서 대충이라도 이물질을 청소해 줬으면 하는 바람으로 구입한 로봇청소기 입니다. 그 사이에 많이 발전한 것 같네요. 일단 자기가 한번에 다 빨아들일 수 없다는 걸로 생각하고, 반복적으로 여러번 같은 곳을 지나갑니다. 그러다 보니 일단 어느정도는 바닥이 청소가 되는 것 같네요. 다만, 바닥에 걸리적 거릴만한 게 없어야 할 거 같네요. 비닐봉지 빨아들여서 에러를 내뱉는 경우가 많아요.

4. Xbox One S

   도서관에서 무료로 빌릴 수 있는 DVD가 많아서, 아이들 DVD 플레이어 용도로 구입한 녀석입니다. 예상은, DVD + 게임 이었는데, 게임이 너무 비싸서 살 수가 없네요. 여전히 DVD 플레이로만 사용되고 간간히 아이들이 마인크래프트 플레이 하는 용도로 사용 중입니다. 100% 활용을 하고 있지 못해서 아쉽지만, 100% 활용하자고 게임마다 60달러를 쏟아붓기에는 Steam 이 너무 매력적이네요.

5. [BenQ HT-2050 Projector][benq-ht2050]

6. [Onkyo S7800 Sound System][onkyo-s7800]

7. Elitescreen 120" Motorized Projector Screen

8. Ikea SEKTION Kitchen Cabinets

   이사온 집에 주방이 좁아서 식기 놔둘 공간도 마땅치 않았습니다. 그래서 벽을 좀 손보고 이케아에서 캐비닛을 사서 설치했네요. DIY로 했는데, 작업하면서 이케아가 정말 시스템을 잘 만들었구나.. 생각이 들었어요. suspension rail을 이용해서 벽에 거는 걸 쉽게 만든 점이나, 문 설치를 위해 미리 구멍을 뚫어놓아서 먼지 날릴 일이 없다는 점등 다양한 부분에서 쉽게 조립할 수 있게 만들어놨더군요. 덕분에, 부담스러웠던 주방 캐비닛 설치를 그래도 우여곡절끝에 잘 마칠 수 있었습니다.

9. Ryobi Cordless Pole Saw

   뒷마당에 있는 나무의 높은 가지를 쳐내려고 구입한 장대 전기톱입니다. 보통 전기톱을 살까 하다가 너무 저에겐 과분한 것 같아서 좀 더 활용이 큰 이 장대 전기톱으로 선택했는데, 두개 다 필요한 것 같네요. 이걸로 낮은 나무 기둥을 자를려고 하면 자세가 정말 어정쩡하게 나옵니다. 그래도 두꺼운 나뭇가지를 사다리타고 올라가 톱질하고 있는 것 보다는 낫죠!

10. Ego Electric Lawn Mower

    기존 개스 잔디깎이가 이사 후로 사망 선고가 내려지는 바람에 기화기(carburetor)를 새로 사서 바꿀까 하다 넘어간 (금액이 열배?) 무선 전기 잔디깎이 입니다. 유선은 선을 잘 짤라먹는다고 해서 무조건 무선으로 갈 생각이었고, 그 중에 DeWalt가 있었다면 샀겠지만 아니라서 그 다음으로 평이 좋은 녀석으로 구입했습니다.

    정말 엔진 잔디깎이만큼 강력하고, 가솔린 냄새도 안나고 덜 시끄럽고 아주 만족하는 제품입니다. 비싸긴 한데, 참고 1년만이라도 내가 앞마당, 뒷마당 잔디 관리하면 이득! 이라는 생각으로 잘 쓰고 있습니다. 의외로 마당 관리하는게 일이 많은데 재밌습니다. :)

11. DeWALT 20V MAX Leaf Blower

    렌트로 살았던 집에서는 가을에 떨어지는 낙엽을 일일히 빗자루로 쓸어댔습니다. 뒷마당이 정말 컸던 집이라, 한번 쓸기 시작하면 한시간은 기본이었구요. 이사 후론 절대 그렇게 뙈약볕에서 빗자루질을 하진 않겠노라 다짐하며 블로워를 구입했습니다.

    대만족, 20V Max (그냥 일반적인 18V짜리에요) 임에도 바람이 강력해서 휘발유 엔진 블로워랑 별 차이도 없고 조용하네요. 배터리도 정말 오래 갑니다. 뒷마당 앞마당 다 청소해도 반은 넘게 남아있는 것 같네요 (LED 3칸중 2칸 뜹니다) 덕분에 DeWalt 에 대한 신뢰도가 급상승해서 String Trimmer, Hedge Trimmer도 구입하게 되었네요. :)

12. DeWalt 20V MAX String Trimmer & Hedge Trimmer

    잔디의 가장자리를 깎기 위해 유용한 string trimmer와 자잘한 가지를 반듯하게 쳐낼 수 있는 hedge trimmer는 마당 꾸미기에 필수품이 아닐까 합니다. DeWalt string trimmer의 단점이라고 하면 가장자리를 편하게 자르기 위한 롤러가 장착이 안된다는 건데, 그럼에도 불구하고 cordless 치고 강력한 절삭능력을 보여줘서 마음에 듭니다.

13. Dyson V7 Cordless Vacuum

    기존에 사용하던 다이슨 무선 청소기 (DC56)가 사망하시는 바람에 (왜 이사 후 이리 고장나는게 많은지..) 새로 구입한 무선청소기 입니다. 무선임이도 유선을 대체할만 하겠더군요. 청소도 정말 쉽고 흡입력도 유선 다이슨과 비교해도 떨어지지 않고, 벽걸이까지 같이와서 충전하기도 편하고, 만족하며 사용중입니다.

14. Rubbermaid 5ft x 2ft storage shed

15. Rachio Smart Sprinkler Controller + Wireless Rain Sensor

    날씨와 레인센서를 이용해서 잔디의 물을 알아서 주는 시스템입니다. 물 리베이트가 있어서 사서 쓰게되었는데, 알아서 물양을 늘였다 줄였다 하니 좋더군요. 다만, 처음에 잔디가 좀 말라가서 보니, 세팅을 꼼꼼하게 해야 물을 적절하게 줄 것 같더라구요. 일반적인 상황에서는 문제가 안되는데, 저희 집은 잔디에 물을 rotor head로 주다보니 물 양이 rachio가 생각하는 양보다 훨씬 적게 들어가게 되서 잔디가 물이 부족해졌네요. 사서 몇달간은 잔디 상태 보아가며 적절한 세팅을 찾아야 하지만, 그게 끝나고 나면 잔디에 신경을 끌 수 있어서 좋은 것 같아요.

16. Samsung Smartthings + Phillips Hue + Google Home Mini + GE Z-wave Light Switch + Motion Sensor + Leak Sensor

    집 장만 후 스마트폰으로 또는 음성으로 집을 제어해보고자 블랙프라이데이에 할인할 때 장만했는데, 만족중입니다. 특히 Scene이 있어서 특정 상황에서 집안 전체 또는 특정 지역의 전등을 한번에 바꿀 수 있는 것은 매우 유용하네요. 집 밖에 크리스마스 전등을 달아두었는데, 기존 타이머를 이용한 것 뿐만이 아니라, 다른 상황에서도 유용하게 쓰여서 좋습니다. 기존 등을 활용하기 위해 필립스 휴 보다는 GE Z-wave Light switch를 구입해 집안 전등 스위치를 바꿨는데, 이게 더 나은 선택같네요.

    구글 홈 미니는 거의 공짜로 구매할 수 있는 딜이 떠서 샀는데, 기존에 구글홈을 방에만 두었다가 구글홈미니가 거실과 주방을 담당하게 되니 사용 폭이 훨씬 늘어났습니다. 마음 같아서는 더 구입해서 아이방에 두고 싶은데, 딜이 두개가 끝이라 아쉽네요.

    Smartthings로 연동되는 기능이 워낙에 많다보니, 이것 저것 추가하는 재미가 있네요. 누수 센서도 추가하고, 모션센서, 도어 열림 센서도 추가해서 Home security까지 구축이 가능하니 꽤 유용하네요. 조만간 Arlo Pro 카메라도 장만해서 좀 더 사용처를 늘려볼 생각입니다.

17. Turf & Needle Pillow

18. Purple Platform Base

    미국에 와서 지금까지 매트리스를 침대도 없이 바닥에 두고 썼는데, 이사와서 그래도 바닥에서는 좀 띄워서 써야겠기에 장만한 Platform base입니다. 광고에 삐걱대지 않는다고 광고해서 비싼 금액을 주고 샀는데, 조립하고보니 삐걱대네요. 고객센터와 이야기 한 후에 보니 설명서에 나와있는 부분 외에 추가로 나사를 조여야 하는 곳이 꽤 있어서, 그 부분을 조정하고 나니 삐걱소리가 사라졌습니다. 지진이 와서 지붕이 무너져도 버텨낼 것 같은 튼튼함에 마음이 듭니다.

첫 집 장만

렌트를 2년 연장한 게 몇달 되지 않았는데 다른 집으로 이사하게 생겼네요. 어쩌다 보니 시장이 뜨겁게 달아오른 이 때에 집을 사게 되었네요.

집을 보기 시작한 건 아마 미국을 오자마자부터 였던것 같네요. :) 주말에 놀러다니기 바쁘기도 했지만, 짬 날 때 근처에 Open House가 있으면 가서 보는 걸 많이 했어요. 그 때에는 보는 눈이 없다보니, 아무 집이나 보면 마음에 들더군요. 타운하우스도 좋고, 야드 거의 없는 싱글하우스도 좋고, 학군은 뭐 별로 상관 없어서 Santa Teresa까지도 돌아보고 그랬었죠.

그런데 [싱글 하우스를 렌트][renting-a-single-house]한 뒤로 집을 보는 게 조금 달라졌어요. 넓은 뒷마당이 있고, 아이들이 따로 독립된 공간에서 놀 수 있는 공간 (저흰 놀이방이라고 부르지만 Den 같은 공간이에요)이 있는 집에서 살다보니, 이 두가지가 집을 정하는 데에 큰 부분을 차지하게 되더군요. 게다가 지금 살고 있는 캠브리안 지역이 마음에 들다보니, '이곳 근처로 구해야 겠다..' 라는 생각도 계속 들었구요.

그래도 작년 5월엔 집을 20% 다운할 돈도 없어서 대출 가승인 (preapproval)을 받지도 않았어요. 그러다 올해 초가 되서 loan broker도 만나고 은행 융자하시는 분도 만나서 preapproval letter를 받았지요. 그럼에도 불구하고 시장이 뜨거운 봄에는 살 생각이 없었고, 열기가 조금이나마 식는 가을, 겨울에 집을 구해볼 생각이었어요.

그러면서 마음에 드는 집을 하나, 둘 오퍼를 써보기 시작했죠. 시험삼아서요. 그런데 두번째 집에서 덜컥 되어버렸네요. 열심히 편지를 쓴 덕분인지, 같은 금액이 3개가 카운터 오퍼로 들어갔는데, 더 안올리고 저희걸 선택했네요.

갑작스레 집 준비에, 이사 준비에 정신없는 날을 보내고 있지만, 그래도 이젠 더 이상 렌트비 신경 쓰지 않고 살 수 있게되어 스트레스는 조금은 덜 해질 것 같아요. 대출 갚는 데 30년이란 세월이 필요할 만큼 무지막지한 대출 금액이지만, 이곳 실리콘 벨리의 뜨거운 주택시장 상황을 보고 있으면, 살 수 있는 것 만으로도 감사해야 할 상황이네요.

오퍼가 선택되고 나면 그 다음부터 무척이나 바빠지는 것 같아요. 서브프라임 사태 이후로 은행 대출이 매우 깐깐해져서, 필요한 서류도 많고, 요구하는 정보도 많아서 융자 하시는 분과 빈번히 연락하고 해결하고 해야 하더라구요. 그 승인 받는 기간이 집을 다시 사고싶지 않을만큼 힘들더라구요.

기회가 되면 융자가 어떻게 진행되는지 간단히 알려드릴게요~

개발자의 평생공부

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

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

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

TK 졸업

6월이 되니 이제 대부분의 학교가 방학을 하게 됩니다. 알마덴 지역은 어제, 쿠퍼티노는 오늘, 그리고 제가 살고 있는 지역은 내일 방학을 하게 되네요.

첫째가 공립 유치원을 들어가고 벌써 10개월이 지났나봅니다. 그래서 Kindergarten을 들어가기 전, 경험했던 TK(Transitional Kindergarten)에 대해 간단히 기록을 남겨볼까 합니다.

일단, TK는 Kindergarten을 가기 전, 몇몇 아이들에게 제공되는 공립교육프로그램입니다. 킨더 입학 기준일이 12월에서 9월로 당겨지면서 원래 킨더를 들어갔어야 하는데 못 들어가게된 아이들을 위해 TK 프로그램을 만들게 됩니다. 그래서 킨더는 각 초등학교 별로 따로 있는데, 저희 지역에서는 교육청 내에 단 한 곳의 TK만 있습니다. 프리스쿨 비용이 워낙 비싸다 보니, TK를 갈 수 있게 되어서 좋았었네요.

TK 교육 프로그램은 킨더와 거의 유사하다고 하네요. 알파벳 교육, 미술 교육 같은 프로그램이 있지만 킨더에선 본격적으로 배우는데 반해 여기서는 놀이와 함께 배우고, 그 중요성이 크게 부각되지는 않는 것 같아요.

거의 보면, 학교에서 그리고, 뛰어놀고, 간식먹고 오는 것 같습니다. 그래서 아이가 적응하는 데에 그나마 부담이 덜 한 것 같네요. 처음부터 교육에만 집중되었다면 영어를 못 하는 첫째가 지금보다 더 힘들어 했을 것 같아요. 물론, 지금도 영어 때문에 힘들어하긴 합니다.

제가 살고 있는 지역은 아이들이 많다보니 TK, 킨더가 오전, 오후 두 반으로 나뉘어 있습니다. 그래서 교육시간이 3시간 20분으로 매우 짧아요. 주변 다른 교육청은 오후 1시 ~ 2시까지 하는 곳이 보통이더군요. 짧은 시간 덕분에 처음에 적응이 그나마 낫다는 점은 있지만, 영어에 충분히 노출되지 못해, 1년이 지난 지금도 영어는 아직 못하고 있습니다. 그만큼 아이가 학교가는 스트레스가 있게되는 것 같구요. (이건 아이 성향에 따라 다르니 개인차가 있겠습니다)

그럼에도 불구하고, 프리스쿨보다 나은 교육환경을 고려하면 잘 보냈다는 생각이 듭니다. 이제 8월 중순에 킨더를 가게 될텐데, 거기서도 지금처럼 잘 적응하면 좋겠네요. 킨터가 끝날 무렵 다시 한번 글을 써볼게요.

Lexington 저수지 낚시

이번 주 Lake Pinecrest로 캠핑을 가려고 계획했었습니다. 가서 토요일에 호수에서 낚시를 하기로 계획했었죠.

몇 달 전부터 지인 가족과 예약해 두고 설레며 준비하고 있었는데, 막상 출발 할 날짜가 되니 파인크레스트 캠핑장 날씨가 심상찮아졌네요. 가는 날 눈이 오고 이박삼일 내내 밤에 영하 5도까지 떨어지는 강추위가 이어진다고 예보가 나옵니다. 따뜻한 5월 봄날이라 전혀 생각지 못했다가 어린 아이들도 있고 해서 추운 날씨에 결국 캠핑 계획을 접었습니다.

캘리포니아에서는 [Crabbing at Half Moon Bay][crabbing-at-half-moon-bay] 글에서 언급한 바와 같이, Pier가 아닌 곳에서 낚시를 하려면 면허가 필요합니다. 파인크레스트 호수도 Pier가 있긴 하지만, 카약과 보트가 주변에 많아 낚시하기가 껄끄러워 1-Day 라이센스를 구입했었는데, 그게 그대로 허공에 날아가 버릴 참이었죠. 하루짜리 라이센스는 날짜가 명시되어 있어서 변경도 안되거든요.

예전에 낚시 용품 판매점에서 직원에게 들은 바 있어, Fremont에 있는 Quarry 호수로 낚시를 갈까 하다, 좀 더 가까운 곳인 렉싱턴 저수지(Lexington Reservoir)로 가보기로 합니다. Quarry 호수는 봄, 여름 격주 단위로 송어(trout)를 방류하기에 실리콘 벨리 근처에서 낚시가 재미있는 곳이라 합니다. 렉싱턴 저수지는 송어 방류는 거의 없어서 고기가 잘 잡히진 않는다고는 하는데, 그래도 꽤 큰 저수지 이다보니 자연산 배스가 꽤 잡힌다고 합니다.

집에서 15분 거리에 있는 렉싱턴 저수지는 제가 미국에 처음 와서 그 주말 산타크루즈를 가며 보았던 곳인데, 가뭄이 절정인 때라 물이 참 없었던 기억이 나는 곳입니다. 작년에는 극심해서 거의 호수 바닥이 보일 지경이었죠.

그러던 호수가 올 겨울 비가 풍족히 내린 덕분인지, 나무가 잠길정도로 물이 가득차고 넘치지 않기 위해 물을 방류할 만큼 상황이 좋아졌습니다. 그래서 그런지, 호수에는 이전에 자랐던 나무가 물에 잠겨 낚시하는 데 애로가 있네요. 릴을 감으면 세번 중 한번은 나무에 걸려 바늘을 끊어먹기 일쑤입니다.

결국 두시간 반을 나무와 사투하다 한마리도 잡지 못하고 점심 먹으러 내려갔네요.

이대로는 안되겠다 싶어, 저녁 5시 즈음 다시 한번 가 봅니다. 파크 레인저가 말해준 것이 기억이 나서 이번에는 댐에서 낚시를 해 보기로 합니다.

댐에는 몇 사람이 낚시를 하고 있었고 한두마리 이미 잡은듯 해 보였습니다. 그 옆에 자리 깔고 낚시대를 드리우는데, 나무에 걸리는 건 매 한가지지만, 오전에 비해선 양호하더군요.

8시 해 질때까지 낚시를 했는데, 입질 두번 온 것 외에는 별다른 성과가 없네요. 그 사이 옆에서 낚시하던 낚시꾼은 5파운드 쯤 되어보이는 송어와, 10파운드는 족히 넘을 것 같은 잉어(carp)를 낚고 얼굴에 웃음을 띄며 집으로 돌아갔습니다.

역시, 제 낚시 실력이 문제네요.

부산행 자동차

보통은 대놓고 정치이야기를 하지 않는 편입니다.. 그러나 오늘 본 이 글은 정치에 국한된 것만이 아니라, 변화를 바라는 많은 상황에 항상 보이는 일이라 공유해 봅니다.

변화는 점진적인 것이지 도약일 수 없다는 것. 느릴지라도 꾸준히 앞으로 나아가다보면 언젠가는 도달할 수 있습니다.

부산행 자동차와 "일부" 진보주의자의 탈현실적 행태

나는 원리주의적인 이념의 소유자이지만 동시에 과정주의자이기도 하다. (이 사실이 내게는 일종의 균형감각으로 역할을 한다.) 이 대목에서 과정주의라 함은 무엇인가 목표에 도달하기 위해서는 그 목표를 향하는 움직임이 필요함과 동시에 그 목표 달성을 위한 단계가 물리적으로 존재함을 인지하고 그 각각의 단계를 존중하는 방식의 사유를 뜻한다. 예컨대, 서울에서 부산을 가기 위해서는 부산으로 향하는 움직임도 중요하지만, 출발한 지점이 부산에서 수백킬로 떨어진 서울이라는 사실과 가장 빠른 길을 선택한다 하더라도 천안과 대전, 대구를 거쳐야한다는 사실을 분명하게 인식하고, 그 물리적 현실을 받아들이는 것이 과정주의적 사유에 해당한다.

그런데 분명히 자동차가 서울에서 출발해서 부산으로 이동하고 있는데, 왜 아직도 천안이냐며 불만 섞인 목소리를 내면서 차에서 내리겠다고 선언하는 이들이 있다. 기억을 되돌이켜 보면 초등학생이던 시절, 부모님과 함께 외가집에 가던 길에서 내가 그랬다. 외가가 부산은 아니었고 대전이었는데, 나는 차가 막히면 대충 오산 쯤 부터 그런 땡깡을 부렸었던 것 같다. 나는 철이 없는 어린아이였고, 외가집에 가기 싫었던 것은 아니었지만 직접 자동차를 운전해야할 의무나 책임을 느끼지 못했기 때문에 그런 땡깡을 부렸던 것이다. 그렇기 때문에 나는 '지금 자동차가 위치해 있는 곳이 부산이 아니라는 이유로' 움직이는 자동차에서 내리겠다고 선언하는 이들의 사유를 초등학생 시절 내가 부렸던 땡깡과 거의 차이가 없는 '어린아이식 탈현실주의'로 이해한다. 더불어 그런 '어린아이식 탈현실주의'적 사유의 소유자들이 말하는 부산에 대한 의지, 그러니깐 직접 차를 운전하지 않는 상태에서 부산에 가야한다는 그 의지를 그다지 신뢰하지 않는다.

지금 우리에게 중요한 것은 서울에 머무르지 않고, 또 개성이나 평양으로 향하지 않고 실제로 부산으로 가는 것이다. 부산에 가기 위해서는 차가 막혀도, 도로가 비포장 도로여도, 아직 겨우 천안을 지나고 있을 뿐이라도 차에서 내리지 않고 계속해서 부산으로 움직여야 한다. (내 최종 목적지는 부산이 아니라 부산에서 다시 배를 타고 가야하는 대마도이기는 하다.)

<문재인의 낙선을 바란다는 '스스로를 진보주의자라 인식하는 이들'에 대한 상념>

출처: Min-soo Kwack on Facebook

총기사고와 차별

오늘은 충격적인 사건이 두가지가 발생했습니다.

한 사건은, 2015년에 총기 테러가 일어났었던 샌 버나디노에서 발생했는데 공교롭게도 총기사고입니다. 이번엔 초등학교내에서 총기 사고가 발생해서 어른 2명이 사망하고 아이 두명은 병원에 실려갔네요.

같은 캘리포니아 안에서 일어난 사고라 그런지, 아이들 걱정이 많이 됩니다. 출근길에 항상 총기 판매상을 지나가는데, 이런 일련의 사건들이 꾸준히 발생하는 데도 총기 규제가 좀처럼 안되고 있어서 정말 아쉽습니다.

두번째 사건은 유나이티드 항공사에서 승객을 물건취급하듯이 비행기에서 끌어내린 사건인데요. 항공사 직원을 태우기 위해 이미 탑승한 승객을 하차시키려고, 완력을 사용해서 끌어내렸는데 그 영상이 인터넷에 오르면서 심각해 진 것 같습니다.

New York Times 기사 참고

링크에 있는 영상을 보면, 다치신 분은 의사이고 루이스빌에 그 다음날 진찰할 환자가 있어서 못내린다고 거부했는데 강제로 끌어내려진 것 같습니다. 그 과정에서 입술이 터지게 되었구요.

이미 탑승한 상태에서 하차를 시키는 것도 문제지만, 하차할 승객을 선택하는 과정에서도 논란이 일어나는 것 같네요. 컴퓨터로 추첨한 것이 아니라 승무원이 적당히 아시안 3명을 선택했다고 하는데, 이부분은 확인되지 않아서 좀 더 지켜봐야할 것 같습니다.

다만 여기 미국에 살다보면, 은근한 인종차별을 가끔 겪게되는 것 같아요. 이런 사소한 것이 모여서 불신의 사회가 되어가는 것 같아 안타깝습니다.

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라던지) 세팅 리뷰는 반드시 필요합니다.