1.

확실히 작년과 이번 시즌 EPL은 리버풀과 아스널이 가장 재미있습니다.

경쾌한 경기는 아스널, 끝가지 기대하게 만드는 건 리버풀..

아스널.. 약팀만 만나면 양민 학살 모드

2.

소소하지 않은 지름.

차를 한대 샀습니다. 기존에 차는 안사람이 거의 타고 다니는 관계로 출퇴근 전용 차를 하나 샀습니다.

차종은 모닝! LPG!!!

용인-수원 고속도로가 생기면서 출근때 운전에 대한 스트레스가 줄어들게 되었다는 점이 차를 가지고 다녀야 겠다는 생각을 하게 만들어주었고, 차를 사게 된 계기는 경차 할인 + LPG 가격을 생각하면 버스 타고 다니는 것과 별 차이가 없다는 계산이 섰기 때문이죠.

일주일 타고 다녔는데, 흠.. 버스보다 하루에 한 300원 정도 더 쓰는 것 같아요. 시간은 왕복 시간 기준으로 대략 1시간 ~1시간 30분 정도 줄었습니다.

요즘 회사에서 늦게 퇴근해서 버스 막차 시간에 신경을 좀 썼었는데(도대체 몇 시에 퇴근한단 거냐?), 걱정이 없다는 부분이 가장 큰 장점이죠.

3.

몇 가지 새로운 일을 하고 있다고 했는데, 많이 바뀐건 아니고 GP 에서 DSP로 바뀐거죠.

예전에 DSP를 했다고 하더라도 GP 기반에 DSP 확장을 위주로 했기 때문에, “어떻게 하면 하나의 명령어로 더 많은 DSP kernel을 지원할 수 있느냐?”가 주된 관심사였다면, 이번엔 specialized DSP에 가깝기 때문에 “어떻게 하면 이 domain의 응용 프로그램을 더 유연하게 가속할 수 있을 것이냐?”가 문제로 바뀌었습니다.

예전에는 DSP kernel과 메모리 접근 패턴 등이 주된 관심이었다면, 이번엔 Data flow에 좀 더 집중하고 있다는 것이 다르달까요. 여하튼, 새로운 일은 좋은 자극이 되고 있다는 장점이 있지만, 보아야 할 것이 태산이라는 단점도 있습니다.

4.

완전 초심자들이 하드웨어(logic design, microprocessor)를 입문할때 그냥 저냥 소설책을 대신하여 잠자리에서 숙면을 취할 수 있도록 도와주는 책을 하나 잡고 번역 중인데, 역시 번역 작업이란 참 오묘합니다.

어려운 것도 없고, 문장도 그다지 어렵지 않은데, 한국말로 바꾸는 작업은 완전히 다른 이야기가 되기 때문에 참.. 한글을 못해서리..

사실 집에서 그동안 빈둥거리면서 TV 보면서 멍~때리고 있던 시간을 좀 더 적극적으로 쓰자는 생각에 시작했는데, 그것보다는 시간을 좀 더 많이 쓰고 있는 것이 사실입니다.

5.

그럼에도 불구하고, WOW도 시작했습니다.

이런 저런 이유가 있습니다만, 회사 동호회의 꼬심에 홀라당~ 넘어가 버린 거죠. (사실은 다시 한번 해볼까라는 생각이 없었다면 거짓말이겠지만, 흠.. 문제는 시간.. 애기가 없었을 때는 자주 하기도 했었는데.. )

일주일에 한번 정도 할 것 같습니다. 달라란 섭에 계신 분들의 많은 지원을~

1.

읽어야 할 책은 점점 쌓여 가는데, 읽는 속도는 점점 느려지고 있습니다.

예전에는 전공서가 아닌 경우에 한글로 된 책인 경우에는 하루에 한권도 읽을 수 있었는데, 요즘은 일주일이 걸려도 못읽는 경우가 허다하군요.

예전에는 놓치고 지나던 문구들이 와서 박힌다던지, 문장 하나 하나가 의미를 가지고 있는 것처럼(물론 의미가 있습니다.) 느껴집니다.

예전에는 훓어 보던 글들이 점점 훓어 볼 수 없게 되는 것이지요.

글을 좀 더 음미하면서 읽을 수 있게 되었다고 생각하면 장점(실제로 음미하고 있는지는 모르겠습니다. 다분히 자기 방어적인 이야기라)입니다만, 저의 허영심(?)을 채워줄 만큼 책을 못 읽으니 참 문제이긴 합니다.

이러한 영향이 전공서를 볼때도 적용되는데, 읽을 수 있는 시간은 한정되어 있는데, 읽어야 하는 분량이 늘어나다 보니 머리속에 팍~! 하고 와서 박히는 부분이 줄어드는 반면에, 눈으로 들어와서 머리 위로 모락 모락 피어나는 한줄기 김으로 사라지는 부분은 늘어나는 것 같습니다.

참, 인간 머리도 큰데 그걸 다 못담고 있는가.. 라는 생각도 들고, 분명 머리에도 기름이 끼어버린 걸게야..그러기도 하고 있습니다.

2.

요즘 회사에서 Agile 기법을 적용해 나가는 중인데, 이 Agile 기법에서 중요시하는 테스트 주도의 개발이나 unit 단위의 테스트라는 것을 H/W 쪽으로 옮기면 assertion/functional coverage와 약간의 접점이 있는 것 같습니다.

그런데, H/W에 있어서는 assertion이나 functional coverage나 모두 해당 부분에 대한 verification goal을 지정하고, 외부의 요인인지 내부의 요인인지를 밝히는데는 도움을 주지만, 결정적으로 testbench와 엮이지 않으면 그 어떤 것도 할 수 없다는 점이 아픔이지요.

그렇다면 H/W team에 scrum이 적용되면, 자동화 혹은 매우 간단하게 각 unit의 testbench를 생성해 낼 수 있어야 하는데, 이 부분이 실질적인 문제가 되겠습니다.

이 문제에 대한 해답은 실은 가까운데 있을지도 모르는데요..

잘 알려진 순서인 software에서 출발해서, H/W – S/W partitioning을 하고, H/W 부분에 대하여 적절하게 C modeling을 하고 이를 refining 하는 과정에서 H/W를 얻어나가면 되는 거죠.

이런 순서로 진행해가면 scrum에서 강조하는 sprint 주기에 항상 구동 가능한 뭔가가 나와야 한다는 생각도 만족 시킬 수 있겠습니다.

PLI나 DPI를 쓰면 이런 과정이 좀더 편해질 것으로 보이고, SCV(cadence사용자라면 CVE를 같이 쓰는 것이 좋겠지요?)를 쓰는 것도 나쁘지 않아 보입니다. 그런데, SCV에 대한 저의 인식이 아직은 그다지.. 라서..( 제가 예전에 했을 때는 버전에 너무 민감했습니다. )

3.

예전에 (도대체 언제적 이야긴지..) SystemVerilog 에 대한 간단한 글을 올리겠다고 했는데, 그간 잊고 있었다는 걸 깨달았습니다.  ^^;

어제 live space에 오랫만에 접속했다가 draft 버전을 보고 깜짝!

역시 예전 글은 민망하더군요.. 여하튼, 교정좀 보고 올리도록 하겠습니다. 아마 10월쯤?

4.

책을 읽는 건 좋은 일인데, 잘못된 정보를 담고 있는 책을 보는 건 정말 큰일 납니다.

예전에 교양을 쌓으려(?) 보았던 video 관련 책에서, 인간이 구분할 수 있는 intensity의 level이 8비트 resolution이라서 RGB 24비트를 사용하면 true color가 된다는 식의 글을 본 적이 있는데.. (아 이런 잘못된 지식을 여지껏 주워 섬기고 있던 난 또 뭐야..)

오늘 자료를 보니 생 뻥~!!!! 이었습니다.

이 부분은 실은 DCI의 요청으로 SMPTE에서 수행한 2003년의 실험에 근거하고 있는데..과연 몇 비트 resolution까지 인간이 구분할 수 있는지에 대한 실험이었지요.

여기에 따르면,

• 8비트 해상도까지는 모든 사람이 구분할 수 있었다
• 10비트까지는 대부분의 사람이 구분할 수 있었다
• 약 40%의 사람들이 11비트까지는 구분할 수 있었다
• 현실적으로 12비트까지 구분할 수 있는 사람은 없었다. (1%가 구분했으나, 제대로 구분한건지. )
• 반복적으로 보여주면, 점점 더 민감하게 골라내더라..

뇌가 처음보는 것에 대하여 다양한 자극을 처리하다보니 받아들인 정보의 양 만큼 길이 길게 느껴지는 것이라고 합니다. 그리고, 점점 새로운 정보가 없다보니 자극을 적게 받게되고 길도 짧게 느껴지게 되는 것이지요.

일을 하는 것도 이와 다르지 않은 것 같습니다. 어느 순간 모든 것이 좀 익숙해지고, 새로운 도전에 대해서 시들해지게 되면 일을 하는 것이 그야 말로 일이 되는 것이지요. 이때 가장 중요한 것이 self-motivation이라는 것입니다. 계속해서 뭔가에 도전하고 안주하지 않기 위한 힘이 되는 것 같습니다.

요즘엔 제 생활에 변화를 약간 주었습니다. 사실 변화 이전에 오만가지 생각(?)이 있었습니다만, 해보니 역시 잘했다는 생각이 드는군요. 제가 생각했던것보다 더 제가 도전적인 성향을 가지고 있었던 것 같습니다. 아주 즐겁습니다.

근데, 변화와 더불어 제가 가져가야 할 책임을 생각하면.. 흠.. ^^