기술 면접에 대한 짧은 생각

오늘은 면접에 대해서 제가 생각하는 것을 써보려고 합니다.
어차피 제가 경험한 면접이란 것이 개인적인 경험일 수 밖에 없겠지만, 혹시 도움이 될까.. 하는 생각에 씁니다.

좋든 싫든 면접이란 것을 종종 들어가게 됩니다. 작은 회사일수록 인력 채용이란 것이 중요하다보니, 제가 다니는 회사 역시 기술 면접 과정이 까다롭다고 알려져 있습니다. 일단 상당히 오랜시간 상당히 깊숙히 들어가는 면이 있어서 그렇기도 하고, 하드웨어 엔지니어를 뽑는 회사치고는 드물게 실기 면접을 병행하고 있기 때문이기도 할 것 같습니다.

첫 번째로 실기 면접의 경우 많은 경우에 아주 간단한 설계 + 이를 검증하기 위한 테스트 벤치로 구성되는데요.
실기 시험이란 것의 특성상 1) 문제를 읽고 설계 스펙을 구체화시켜 간단한 아키텍처를 만들어 내는 능력, 2) 이를 RTL(혹은 C)로 구현하는 능력, 3)구현된 부분을 검증하기 위한 테스트 벤치를 작성하는 능력, 4) 테스트 벤치에 맞는 테스트 시나리오를 만들고 이를 테스트 케이스로 만드는 능력, 5) 설계물과 설계 과정에 대해서 설명하는 능력을 보려고 하는 것이죠.
이 이야기는 정상적으로 동작하는 것을 만드는 것도 중요하지만, 이걸 어떤 방식으로 검증해야 하는지, 그리고 어떻게 분석해서 왜 이렇게 만들었는지를 논리적으로 설명하는 과정 역시 매우 중요하다는 것입니다.
즉, 실수한 부분이 있더라도 이걸 논리적으로 설명하려 노력하는 것이 중요합니다. 가끔은 실기 시험이란 것이 이야기를 풀어나가기 위한 시작점으로 사용되기 때문입니다.

두 번째로 경력 사항에 대한 설명이 있는데요.
경력자(혹은 석/박사)는 당연히 그 동안 했던 프로젝트 중 지원자가 생각하기에 가장 참여도가 높거나 가장 기억에 남는 주요 프로젝트 한 두가지를 가지고, 내용에 대해서 설명하고 질문에 답을 하는 것입니다.
(물론, 면접 위원들에게 특별히 눈이 가는 프로젝트가 있다면 (예를 들어, 저희 회사 같은 경우는 Video Codec) 이 부분에 대한 질문이 추가되기는 합니다. )
이때, 가장 fancy 해 보이는 프로젝트를 선택하지 마시고 가장 자신 있는 프로젝트를 선택하시는 것이 좋습니다.
보통 면접위원들은 프로젝트 자체에 대해서는 대부분 별로 관심이 없습니다. 다만, 어떤 식으로 일을 했는지 살펴보기 위한 “이야기꺼리”로 프로젝트를 사용하는 것뿐이죠.
따라서, 보통 상당히 긴 시간동안 프로젝트에 대해서 이야기하게 되는데, 이런 종류의 일을 할 때 반드시 알고 있어야 할 것이라 생각하는 다양한 사항들을 물어보며, 스펙부터 설계, 기법까지 다양한 부분에 대해서 질문과 답을 나누게 됩니다.

이 부분에서 중요한 건 틀려도 되니까, 당황하지 않고 논리적으로 이야기가 진행되는 것이 중요합니다.
예를 들어, bandwidth등을 물어봤을 때 실제 수치가 중요한 것이 아니라 논리적으로 어떤 방법으로 계산을 진행했으며, 이런 이런 파라미터가 왜/어떻게 사용된다가 중요한 것이지 정확한 숫자를 기억해 내기 위해서 노력할 필요까지는 없습니다. (보통은 말이죠. 다만 그 수치 자체가 중요한 경우도 있기는 합니다. – 이 일을 하는데 당연히 알아야만 하는 숫자라면 말이죠. )
또한, 앞에도 언급했지만 이런 종류의 일을 하기 위해서 반드시 알아야 하는 사항들이 이 이야기 프로젝트 이야기에 질문으로 나오게 됩니다. (보통 하드웨어 엔지니어, 검증 엔지니어, 소프트웨어 엔지니어의 기본적인 면접 질문을 포함해서..)

[image from https://www.pexels.com/]

가끔 상당히 괜찮아 보이는데, 면접 과정에서 계속된 질문으로 심하게 당황하셔서 당연히 아실 것이라 생각되는 질문조차 답을 못하는 경우가 있습니다.
이런 경우에는 면접위원으로 들어갔음에도 제가 더 안타깝습니다.  조금만 보고 왔다면 당황하지 않을텐데.. 하는 생각이 들기도 하고요.
(사실 이 글을 쓰게 된 직접적인 원인이기도 합니다.)

마지막으로, 글의 성격에 맞게 기술 면접 전에 챙겨보면 도움이 될 만한 것을 이야기하자면..

  1. 구글에서 일반적인 “하드웨어 설계 엔지니어/하드웨어 검증 엔지니어/ 소프트웨어 엔지니어 ” 인터뷰 질문을 대충 한번 훓어보고 오면 도움이 됩니다. 예를 들어 하드웨어 엔지니어라면 metastable/CDC 문제는 아주 기본입니다. (http://babyworm.net/archives/150 )
  2. 경력 사항 중 중요한 프로젝트에 대해서 한번 보면서, 당시에 “어떻게” 스펙을 정했는지, “어떻게” 일을 진행해 나갔는지, “어떻게” 검증 시나리오를 작성했는지, “어떻게” 합성 조건을 잡았는지 등을 기억해 보는 것도 도움이 됩니다. “어떤”일을 했는지도 중요하긴 한데 “어떻게”가 더 중요합니다.
  3. 목적으로 하는 회사에서 원하는 것이 어떤 것인지 확인해 보는 것도 중요합니다. 보통 필수 부분과 우대 부분이 있는데, 이 부분에서 대해서 강조하는 것이 좋습니다.
  4. 면접이란 것이 ‘지원자’가 이 회사를 선택하지 않으면 이루어질 수 없습니다. 따라서, 면접 과정에서 이 회사에서 나에게 어떤 것을 원하는지를 탐색해 보는 것도 잊으면 안될 것 같습니다. (물론, 국내에서는 이게 허용되지 않는 곳도 있습니다만…)

진짜 마지막으로, 인터뷰는 누구를 배제하기 위한 과정이 아니라, 뽑기 위한 과정이기 때문에 질문이 반복되더라도 ‘공격받는다’라고 생각하셔서 당황하실 필요가 없다고 봅니다.

면접 보시는 분들께 좋은 결과가 있길 바랍니다.

DVCON 2017 간략 리뷰

바로 밑에 DVCON 2016리뷰가 있는 걸 보니, blog에 얼마나 무관심했는지 약간 죄책감이 듭니다만 꺼리가 생겼으니 써야겠죠.

DVCON(Design & Verification Conference)은 산업계에서 주도해서 열고 있는 회의로, DVCON을 주최하고 있는 Accellra(http://accellera.org/)가 SystemC, VHDL, SystemVerilog, UVM, IP-XACT, UPF등의 굵직굵직한 산업계의 주요 표준을 만들고, IEEE-SA와의 협력을 통해서 국제 표준으로 등록하고 있는 단체라는 점을 고려하면 그 성격을 파악할 수 있을 것입니다.

현재 active한 Accellera 표준들

사실 업계나 학계에서는 DAC나 ICCAD가 더 큰 이벤트라 할 수 있겠습니다만, 여기서는 학계의 연구 성과를 폭넓게 다루는 반면, DVCON은 산업계에서 지금 사용하게 될 표준에 대해서 다루고, 이걸 어떻게 효과적으로 적용해야 하는가에 집중하고 있다고 할 수 있어서, 실무에서 검증 다루는 엔지니어들이 바로 혹은 몇 년 내에 적용할 만한 기술들에 대해서 살펴보기에 가장 좋은 자리라 할 수 있겠습니다.

이번에 DVCON에서는 작년에 이어서 최근에 만들어지고 있는 Portable Stimulus Specification(PSS) 표준에 대해서 이야기가 많았습니다. 튜토리얼들에 이어서 패널 토론에서도 지속적으로 다루어지고 사용자의 피드백을 받고 있었습니다.

PSS의 출발은 비슷한 검증을 IP 수준, SoC 하드웨어 검증, 소프트웨어 수준에서 반복해서 하고 있으니, 하나의 언어 검증 의도(시나리오와 커버리지 목표)를 기술하면 이 의도에 부합되는 커버리지를 갖춘 소프트웨어와 하드웨어를 위한 검증/테스트 벡터(정확히는 테스트 케이스)들을 뽑아주겠다는 것입니다. 이렇게 하면 일단 아키텍처 단계에서부터 하드웨어, 소프트웨어 설계, 검증 단계로 가면서 관련된 검증 의도를 기술하게 되고, 요걸 다른 수준에서도 재사용하겠다는 겁니다. PSS는 (SystemC처럼) C++에서 구현될 수 있는 subset 처럼 정의되고 있는 중이며, action, object, resource등을 정의해서 각 모듈이 어떤 동작을 하고 어떻게 연결되는지 기술하는 방법을 쓰고 있습니다.

이때 주의할 건 검증 의도(verification intent)를 표현해서 공유하는 것이지 벡터 자체를 공유하는 게 아니라는 것이기 때문에 실제 동작을 만들어낼 트랜젝션에 대한 기술은 각 언어에 맞게 진행되는 것은 변함이 없다는 점입니다.

언어의 정의는 진행되고 있는데, portable stimulus라는 것 자체가 툴을 통해서 각 툴에 대한 의존성이 당연히 있기 때문에 아직은 실제로 정말 유용할 지에 대해서는 잘 모르겠습니다.

UVM의 경우 작년에 IEEE-1800.2로 표준화되면서 몇가지 변화가 있었는데, 변경된 걸 짧게 정리하자면, 다음과 같이 정리할 수 있겠습니다.

  • 표준답지 않은 부분은 없애거나 정리했다.
  • 불필요한 함수들은 통합되었다.
  • Policy class가 대부분의 policy class들의 base가 되었고, factory 함수들 대부분이 이 class를 extend하고 있기 때문에 하나의 policy로 제어할 수 있게 되었다.

이외에 몇몇 IEEE-SA와 Accellera의 역할이나 Accellera의 입장에서 고려하고 있는 것들을 이야기 했지만, 별로 중요한 것 같지는 않고요. 재미있는게 Go2UVM(http://www.go2uvm.org/) 이란 아주 간단한 툴에 대한 소개가 있었는데요. UVM이 복잡하다고 생각하는 하드웨어 엔지니어들이 쓸 수 있는 라이브러리(?), 유틸리티(?)라고 보면 될 것 같습니다.

테크니컬 세션에서 대해서는 몇몇 볼만한 것들만 이야기하겠습니다. (볼만한 것 많았습니다만… )

  • Trends in Functional Verification: A 2016 Industry Study; 이젠 거의 매년 어떤 형식으로든 발표되고 있는 검증 관련 동향에 대한 발표입니다. (데이터는 매년 업데이트되는 게 아니지만..) 이미 많은 분들이 Verification Academy에서 이 내용을 읽으셨을 거라고 생각합니다.
  • Keynote: Tomorrow’s Verification Today
    • 각 단계 별로 유효한 검증 방법을 설명했습니다. 예를 들어 IP 검증의 경우 앞으로 어떤 형태에서 검증될지 모르기 때문에 다양햔 configuration에서 검증해야 하며, 비교적 크기가 작아서 formal 먼저 하는게 좋답니다.
      • 여기서 나온 이야기가 아니라 formal 부분을 이야기하는 세션에서 나온 이야기입니다만, 겸사 겸사.. formal의 경우 속도 문제로 30K 이하에서는 pure formal을 사용하지만, 그 이상에서는 constraint에 대해서 회로를 풀어가는 방법(bug hunting)을 사용한답니다. 이때 constraint를 적절하게 적어주지 못하면 Corn of Influence가 너무 제한적이라서 검증이 안되는 부분이 생길 수 있는데 요걸 줄이기 위한 방법이 많이 이야기 되었습니다.

    • 반면에 SoC 검증에는 parallel simulation이나, emulation으로 다양한 시나리오를 검증하는 것이, Software bringup 단계에서는 emulation, FPGA prototyping이 중요하다는 이야기였죠.
    • 아마 검증도 deep learning을 사용하게 될 것이다 (verification hole을 찾고 coverage를 높이는 벡터를 만들기 위해서).. 라는 이야기를 했는데.. 요 내용이 이번 conference에서 나옵니다.
  • Panel: SystemVerilog Jinxed Half My Career: Where Do We Go From Here?
    • 제목자체가 재미있는데요 (공감도 되고..) Verilog를 만든 Mooby를 비롯한 이쪽 분야의 Guru들이 모여서 이후에는 어떻게 될까 라는 주제로 이야기를 나누었습니다. Panel 중 한명이었던 Dave Rich(Verification Academy 포럼의 moderator이자 로봇이 아닐까 의심이 될 정도로 빠르게 답변을 달아주는 걸로도 유명하죠)의 글이 패널 토론의 앞부분 내용과 상당히 겹칩니다.
  • 이번 Best paper는 Coverage Optimization에서 나왔습니다. (개인적으로도 가장 재미있게 보았습니다.)
    • 첫 번째 내용이 일정 단위로 시뮬레이션 check point를 잡고(시뮬레이터 기능이죠), 일정 단위동안 coverage가 올라가지 않으면 저장한 check point로 되돌아가 seed를 바꾼 후 다시 검증을 진행하고, 요걸 반복한다는 내용이었습니다. 이렇게 하면 하드웨어가 바뀐 경우(즉, coverage 측정을 다시해야 하는 경우) 짧은 시뮬레이션 타임으로 높은 coverage를 얻을 수 있다는 거죠. Seed를 바꾸는 건 누구나 하는 건데, 시뮬레이션 런을 다시 돌리는 게 아니라 checkpoint를 잡고 바꾸는 것이 특이하죠. 요 paper가 best paper 2등을 했습니다.
    • 두 번째는 조금 더 재미있는데, coverage를 찾아가는 것에 machine learning을 사용하자는 거죠. (앞의 formal 세션이나 keynote, 튜토리얼에서 이야기된 거죠.) regression을 반복하면서 분석해보면 테스트의 양(volume)과 이 테스트가 건드리는 bin들의 양(여기서는 breadth라 표기했습니다.), 그리고 특정 테스트에 의해서만 건드려지지는 bin들의 수(rarity)로 구분한 다음 요걸 Machine learning을 통해서 clustering으로 구분하는 거죠. 이렇게 되면, 서로 다른 test더라도 같은 그룹에 있는 테스트는 굳이 regression에 포함시킬 필요가 없어서 더 적은 테스트 벡터로 더 좋은 효과를 얻을 수 있다는 것입니다. 이 논문이 이번의 best paper였습니다.

아.. 잊을뻔 했는데, parallel simulation에 대해 Cadence(Rocketsim 기반의 Xcelium)와 Synopsys(VCS parallel)에 대해 서로 은근하게 까는 것도 재미있었는데요. 강도로 봤을 때 Xcelium이 조금 더 빠르지 않을까.. 하는 느낌이 들었습니다만, 느낌일 뿐이죠(근거 없습니다.). 서로 발표한 자료에 나온 speedup이 워낙 설계에 따라 달라서요.  DVCON 참가자들 사이에서도 ‘벤치마크 수치 서로 공개하지 못하게 하고 있는데, 그냥 Accellera에서 주도해서 공정하게 테스트하고 open하면 안되냐.. ‘라는 이야기도 나왔죠. (Parallel simulation 이야기하다가 나온건 아니지만요..)

그러고보니, 희안하게 PSS에 대한 이야기는 활발한 반면 HLS를 위한 SystemC에 대한 이야기는 별로 못들었습니다. 어찌된 일인지 모르겠는데요.. 제가 해당 세션에 들어가지 않아서 그런지도 모르겠네요. (그쪽에 들어간 분께 나중에 물어봐야 할 것 같습니다.)

참고로 DVCON은 친절하게 모든 논문과 자료를 1년 지나면 공개하고 있습니다. 아래 페이지에서 예전 자료들을 보시면 될 것 같습니다. https://dvcon.org/history (지금도 유효한 내용이 많으니 도움이 되실 거에요.)

올해 배운걸 어떻게 적용할 수 있을지도 고민이 되네요. (Formal은 이제 해볼만 할 것 같으니, 슬슬 evaluation해 봐야 할 것 같습니다. )

내년 DVCON도 기대되네요.

 

p.s. 요 글은 MS word로 써서 wordpress로 보내봤습니다. 예전에는 그림 삽입 문제가 있었는데, 이젠 잘되네요!

DVCON 2016 간략 리뷰

DVCON2016(https://dvcon.org/) 에 다녀왔습니다.

DAC15때 Draft만 적고 publish를 못한 전력이 있어서, 되도록 빨리 쓰고 올릴려고 했습니다만, 쉽지 않았습니다.

DVCON은 처음 다녀왔는데요. 일단 주제가 Verification이라는 부분으로 한정되어 있어서 내용에 대한 집중이 좋았다는 측면에서 DAC보다 괜찮았습니다. (물론, DAC의 경우 설계, 검증, 공정, 소프트웨어를 포괄하는 더 다채로운 행사와 폭넓은 내용을 포괄하고 있습니다만, 실제로 수많은 섹션이 동시에 열리면서 제가 직접 볼 수 있는 건 아주 제한적이라는 점이 안타까웠거든요.)

DVCON2016의 내용은 요약하자면..

일단 UVM을 빼놓고 이야기하기 어렵습니다. 실제 발표된 대부분의 내용이 UVM을 기반으로 설명할 정도로 UVM이 검증 분야에서는 널리퍼졌다는 점과 UVM1.2가 IEEE1800.2으로 들어간다는 점.

두번째로 HLS를 위해서 SystemC synthesizable subset이 정의되고 있다는 점과 생각했던 것보다 HLS의 기반이 커지고 있다는 것.

세번째로 Portable stimulus에 대한 정의가 진행되고 있다는 점. 이건 stimulus를 하나 만들어서 만들때 system firmware, emulation, top level simulation(&  subblock level simulation)등의 검증에 적용시킬 수 있었으면 좋겠다는 의도가 있습니다.  접근 방법은 별도의 언어를 정의하는 것과 이전에 만들어진 걸 conversion하는 툴을 만드는 방식이 동시에 진행되면서 어떤것이 좋을지 테스트하고 있는 중입니다.

논문 발표의 경우 여러 부분으로 분리되어 진행되었는데, 많은 부분이 UVM의 활용과 개발에 할애되었고, 저도 관심분야라 이쪽 위주로 들어갔습니다. UVM에서 디자인 패턴을 활용하자는 이야기는 그전에도 나왔는데(사실 UVM 자체에서 몇몇 디자인패턴 – 대표적으로 factory pattern – 이 이용되었죠), 이를 조금 더 폭넓게 사용할 수 있도록 제안 + 라이브러리가 발표되었습니다 (best paper도 이쪽에서 나왔죠). UVM의 경우 다양한 회사에서 적용 예와 자신들의 필요에 따라 새로운 class를 만들고 개선해서 github에 올리고 공유하는 활동이 이어졌습니다.

이외에 다양한 tutorial과 on-site meeting들이 있었습니다만, 자세히 적기는 그렇고.. 인상적인 것만 이야기하자면..

Software 부분에서는 일반적이라 할 수 있는 TDD와 Design Pattern이 하드웨어 검증 부분에서도 급격하게 도입되고 있다는 점이 볼만합니다. 이쪽 사람들이 하드웨어 + 소프트웨어의 background를 가졌기 때문일 것 같습니다.  여튼, TDD를 위해서 unit testing environment (심지어 assertion에대한 unit test framework까지도..) 에 대한 이야기들이 많이 언급되었습니다.

Emulation + formal verification이 simulation을 대체할 수 있을것인가에 대한 패널토론이 있었는데, simulation에 대한 보조적인 방식에 머무를 것이라는 것이 ‘모든’ 패널들의 의견이었습니다. 다만 위의 기법이 점차 중요해진다는 점도 동의하기는 했지만, ‘여전히 보조적인 수단’이라는 점은 명확히 하더군요. automatic formal verification app의 성장세도 눈여겨 볼만합니다. 

음.. DAC나 DVCON이나 가보면 참 부러운 것이 나이 많으신 어르신 분들과 젋은 친구들이 섞여서 기술적인 이슈에 대해서 비교적 자유롭게 토론한다는 점입니다. 이게 이쪽 업계가 오래 지속된 곳의 특징일 것이고, 우리도 한 20년쯤 지나면 이랬으면 좋겠네요.