[리벨리온] RTL Engineer 공고 분석

이 자리가 왜 생겼을까요

1하게 될 업무

• D2D interconnect subsystem을 설계하고 구현합니다. transaction management와 datapath, link-level reliability(retry/replay, CRC, FEC), built-in test·debug·monitoring 구조(traffic generation/comparison, loopback, per-port counters, performance monitors)가 들어갑니다(Interconnect RTL Design).

  이렇게 볼 수 있어요

  데이터를 옮기는 경로뿐 아니라 오류 복구와 디버그용 구조까지 설계 범위입니다. retry나 CRC 같은 링크 신뢰성 로직, 또는 카운터와 루프백 같은 디버그 구조를 RTL로 넣어 본 경험이 업무와 가장 가깝습니다.

• NPU SoC를 시스템 수준에서 바라보며 일합니다. D2D subsystem은 accelerator traffic을 실어 나르므로 microarchitecture가 compute, memory hierarchy, NoC의 데이터 이동 방식에 따라 정해집니다. 이 시야는 입사 뒤 architect와 함께 쌓아 갑니다(NPU SoC System View).

  이렇게 볼 수 있어요

  공고는 시스템 시야를 입사 전에 갖춰야 할 조건이 아니라 architect 옆에서 기르는 것으로 적었습니다. 자기가 만든 블록의 트래픽이 시스템 어디에서 와서 어디로 가는지 설명할 수 있다면 그것이 이 시야의 출발점입니다.

• 업계 표준(spec)이 다루지 않는 영역까지 포함해 architect와 함께 interconnect microarchitecture를 구체화합니다(Microarchitecture Definition).

  이렇게 볼 수 있어요

  표준 문서를 그대로 구현하는 데서 끝나지 않고 표준이 비워 둔 부분을 직접 정해야 합니다. 표준에 없는 동작을 팀 안에서 정의해 구현해 본 사례는 이 일을 미리 해 본 경험입니다.

• UCIe, CHI, CHI C2C 등 open standard에 맞춰 설계하고, vendor controller/PHY IP를 표준 interface(RDI/FDI/AXI 등)와 Rebellions in-house NoC interface로 통합합니다(Standard-Spec-Based Design).

  이렇게 볼 수 있어요

  외부에서 들여온 컨트롤러와 PHY IP를 사내 NoC와 연결하는 통합 작업이 들어 있습니다. 벤더 IP의 인터페이스 문서를 보고 자체 로직과 연결해 본 경험이 이 일과 직접 이어집니다.

• verification, SoC integration, firmware(register map / control interface), PSI 팀과 협업해 subsystem이 실제 시스템에서 동작하게 합니다(Cross-Functional Collaboration).

  이렇게 볼 수 있어요

  firmware 팀과는 register map과 control interface를 함께 정합니다. 레지스터 명세를 직접 정의하고 펌웨어 쪽과 맞춰 본 경험이 있으면 구체적으로 쓰는 편이 좋습니다.

• D2D link bring-up에 참여하고, 문제가 깊을 때는 RTL simulation까지 내려가 post-silicon debugging을 지원합니다(Silicon Bring-up).

  이렇게 볼 수 있어요

  칩이 나온 뒤 링크 문제를 RTL 시뮬레이션으로 재현해 원인을 찾는 일까지 맡습니다. 우대 사항에도 tape-out과 bring-up 경험이 있지만 공고는 이 경험을 필수로 두지 않고 이번 프로젝트에서 배울 수 있다고 적었습니다.

2자격 요건

• SystemVerilog/Verilog RTL 설계 경력이 합산 최소 6년 이상 필요합니다(M.S.는 2년, Ph.D.는 4년으로 셈). interconnect나 link-layer RTL에 뚜렷한 깊이가 있으면 연차가 이보다 적어도 이야기해 볼 만하다고 적었습니다.

  이렇게 볼 수 있어요

  석사 2년, 박사 4년을 경력에 더해 셉니다. 박사 학위가 있으면 실무 2년으로 6년 기준을 채우고, 연차가 모자라면 interconnect 쪽 깊이를 얼마나 보여 줄 수 있는지가 관건입니다.

• 단순하지 않은(non-trivial) 블록 하나 이상을 RTL로 처음부터 끝까지 맡아 본 경험이 필요합니다. architecture 정의 경험은 환영하지만 필수는 아니고, microarchitecture는 혼자가 아니라 architect와 함께 정의합니다(Block Ownership).

  이렇게 볼 수 있어요

  구조를 혼자 정의해 본 경험보다 한 블록을 끝까지 책임진 경험을 봅니다. 맡았던 블록의 규모와, 스펙 확정부터 마무리까지 어느 단계를 직접 했는지를 함께 적어야 합니다.

• logic simulation 도구(VCS 또는 Xcelium)에 능숙하고 복잡한 RTL 문제의 근본 원인을 찾을 수 있어야 합니다(Simulation & Debugging).

  이렇게 볼 수 있어요

  bring-up 단계의 문제를 RTL 시뮬레이션까지 끌고 내려와 풀어야 하므로 디버깅 능력은 업무와 직접 이어집니다. 칩에서 생긴 문제를 시뮬레이션으로 재현해 원인을 좁혀 간 경험이 이 요건에 대한 가장 직접적인 답입니다.

• 최소한 Lint, CDC, Synthesis 같은 업계 표준 quality flow에 익숙해야 합니다(Quality Toolchain).

  이렇게 볼 수 있어요

  Lint, CDC, Synthesis 세 가지가 최소 기준으로 적혀 있습니다. 여러 클럭 도메인을 오가는 링크 블록에서 CDC 문제를 정리해 본 경험이 있다면 함께 쓰는 것이 좋습니다.

• cross-functional 협업이 원활해야 합니다. chiplet 문제의 원인을 찾는 일은 architecture, verification, firmware, PSI, vendor 팀에 걸쳐 있어, 남을 탓하기보다 데이터로 디버그하고 자기 실수를 정직하게 인정하는 엔지니어를 중요하게 봅니다(Communication & collaboration).

  이렇게 볼 수 있어요

  협업을 일반론이 아니라 디버깅 태도로 구체화했습니다. 여러 팀이 얽힌 문제를 데이터로 원인을 밝혀 정리한 사례와, 자기 실수였던 경우를 어떻게 처리했는지가 면접에서 나올 수 있습니다.

3우대 사항

• tape-out을 거쳐 post-silicon debug까지 설계를 이어 간 경험을 우대합니다. 필수는 아니고, 이 역할에 bring-up이 들어 있어 이번 프로젝트에서 배울 수도 있다고 적었습니다(Tape-out & Silicon Bring-up).

  이렇게 볼 수 있어요

  tape-out 경험이 없다고 지원을 망설일 필요는 없다는 뜻입니다. 경험이 있다면 칩이 나온 뒤 발견한 문제와 그 해결 과정을 쓰면 우대 사항에 그대로 답할 수 있습니다.

• AMBA(AXI/ACE)나 CHI, 또는 packetized on-chip protocol에 대한 실무 지식을 우대합니다. transaction ordering, outstanding-transaction management, credit-based flow control이 함께 적혀 있습니다(Interconnect Protocols).

  이렇게 볼 수 있어요

  세 개념은 프로토콜 이름이 달라도 공통으로 쓰입니다. 다뤄 본 프로토콜에서 ordering 규칙이나 credit 관리를 직접 구현한 부분을 구체적으로 설명할 수 있으면 됩니다.

• multi-domain 설계에서 clock domain crossing, reset domain crossing, power/clock gating 경험을 우대합니다(Clock, Reset & Low-Power Infrastructure).

  이렇게 볼 수 있어요

  die 사이 링크는 여러 클럭과 전원 영역이 만나는 블록입니다. reset domain crossing까지 다뤄 본 경험은 CDC만 다룬 경험과 따로 쓰는 편이 낫습니다.

• scan insertion, compression, DFT-aware RTL practices를 우대합니다(DFT).

  이렇게 볼 수 있어요

  테스트를 고려해 RTL을 쓰는 습관을 우대합니다. scan 삽입 뒤 생긴 문제를 RTL에서 고쳐 본 경험이 있으면 구체적인 사례가 됩니다.

• SerDes 기반 high-speed link(PCS/PMA partitioning, equalization, clock/data recovery, link training)와 SerDes PHY에 연결되는 digital logic에 대한 실무 이해를 우대합니다(SerDes / high-speed PHY).

  이렇게 볼 수 있어요

  아날로그 PHY 설계가 아니라 PHY와 맞물리는 디지털 로직을 이해하는지가 기준입니다. link training 상태 머신 같은 PCS 쪽 로직을 다뤄 본 경험이 있으면 그 범위를 구체적으로 쓰는 것이 좋습니다.

4기타 사항

• 게시일 : 2026년 7월 24일
• 고용형태 : 해당 내용은 원본 공고에서 확인되지 않습니다.
• 근무지 : 경기도 성남시 분당구 정자일로156번길 6
• 경력 조건 : 경력 6년 이상
• 학력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.

쓰는 기술

공고 본문에 적힌 기술만 모은 목록입니다.

• SystemVerilog
• Verilog
• UCIe
• CHI
• CHI C2C
• AXI
• ACE
• RDI
• FDI
• VCS
• Xcelium
• Lint
• CDC
• Synthesis
• SerDes

전형과 지원

분석 시점 공고 42건 가운데 27건이 같은 여섯 단계를 적었습니다. Software와 System Software 공고는 전부 과제나 코딩테스트를 더했고, System Software 공고 9건 가운데 8건은 평판 조회도 거칩니다. 지원할 공고의 전형절차를 본문에서 따로 확인하는 편이 안전합니다.

지원 전 준비할 것

1. 1

   인접 경험을 D2D 업무에 맞춰 다시 정리하기

   공고는 다른 도메인에서 쌓은 탄탄한 IP 설계 경험도 지원할 바탕이 된다고 적었습니다. 해 본 블록을 업무 첫 항목의 세 부분인 transaction 관리와 datapath, 링크 신뢰성, 디버그와 모니터링 구조에 맞춰 다시 정리해 두세요.

2. 2

   UCIe와 CHI 문서 먼저 보기

   UCIe 경험은 필수가 아니지만 업무는 UCIe, CHI, CHI C2C를 기준으로 설계합니다. 면접 전에 UCIe의 RDI/FDI 인터페이스가 계층을 어떻게 나누는지 정도는 설명할 수 있게 미리 봐 두세요.

3. 3

   디버깅 사례를 데이터 중심으로 준비하기

   협업 요건에 남을 탓하기보다 데이터로 디버그하고 실수를 정직하게 인정하는 태도가 적혀 있습니다. 여러 팀이 얽혔던 버그 하나를 골라 어떤 데이터로 원인을 좁혔고 자기 쪽 실수는 무엇이었는지 정리해 둘 만합니다.