ChatGPT에 물으면 틀리는 EDA 실무 질문: VCS -mfcu, Vivado hold 진단, 툴 버전 혼용 대처의 확인 순서

핵심 결론 생성형 AI는 EDA 툴 질문에서 문법보다 경계 조건에서 틀린다. 옵션의 존재가 아니라 그 옵션이 바꾸는 compilation unit의 범위, 툴 내부 단계의 공개 여부, 버전 조합의 재현 조건을 잘못 말한다. Vivado의 route_design 내부 phase를 중간에 멈추는 공개 Tcl API는 없으며, hold 문제는 라우팅을 멈춰서 보는 것이 아니라 hold fix 없이 라우팅해 비교하는 방식으로 진단한다. 단정할 수 없는 에러는 외울 것이 아니라 확인 순서를 고정해 두는 것이 답이다. 이 글의 세 사례는 모두 "AI 답변을 그대로 실행하지 않고, 무엇을 어떤 순서로 확인할 것인가"로 정리한다.

왜 EDA 질문에서 AI가 유독 자주 틀리는가

일반 프로그래밍 질문과 EDA 질문은 오류의 성격이 다르다. 프로그래밍에서는 공개 문서와 예제가 많고, 잘못된 답도 실행하면 바로 에러로 드러나는 경우가 많다. EDA에서는 상황이 반대다. 툴 문서의 상당 부분이 설치 후 제공되는 매뉴얼과 릴리스 노트 안에 있고, 같은 명령어라도 버전과 라이선스, 디바이스 패밀리에 따라 동작이 달라진다. 게다가 잘못된 스크립트가 에러 없이 돌아가면서 타이밍 결과만 조용히 달라지는 경우도 적지 않다.

AI가 만드는 전형적인 오류는 세 가지다. 없는 옵션을 있는 것처럼 조합하는 것, 존재하는 옵션의 기본값과 적용 범위를 뒤집는 것, 그리고 특정 버전에서만 성립하는 우회법을 모든 버전에 통하는 정석처럼 말하는 것이다. 아래 세 사례는 실무에서 반복해서 마주치는 대표 패턴이다. 각 사례마다 AI가 흔히 하는 답, 무엇이 틀렸는지, 그리고 현장에서 쓸 확인 순서를 함께 적는다.

사례 1 — VCS -mfcu: "여러 파일을 하나로 합쳐 주는 옵션"이라는 답의 함정

AI에게 VCS의 -mfcu를 물으면 "여러 파일을 한 번에 컴파일하는 옵션" 정도의 답이 돌아오는 경우가 많다. 틀린 말은 아니지만, 실무에서 필요한 핵심을 놓친 답이다. -mfcu는 multi-file compilation unit, 즉 명령행에 나열된 여러 파일을 하나의 compilation unit으로 취급하겠다는 선언이다. 반대 개념은 파일마다 별도의 compilation unit으로 보는 방식이다.

Compilation unit이 중요한 이유는 SystemVerilog의 가시성 규칙 때문이다. IEEE 1800은 compilation unit을 "함께 컴파일되는 소스 파일들의 집합"으로 정의하고, 정확한 구분 방식은 툴에 맡긴다. 하나의 unit 안에서는 순서가 의미를 가진다. 앞에 있는 파일에서 정의한 define 매크로가 뒤 파일에 영향을 주고, compilation-unit scope에 선언된 항목이 unit 안의 뒤쪽 파일에서 보이는 식이다. 반대로 unit이 파일별로 분리되면 매크로는 파일을 넘지 못하고, 각 파일은 필요한 패키지를 명시적으로 import하거나 필요한 파일을 include해야 한다.

실무 사고는 여기서 난다. 어떤 레거시 환경은 파일 순서에 의존해 동작한다. 공통 매크로 파일이 목록 맨 앞에 있다는 전제로 뒤 파일들이 define을 그냥 쓴다. 이 환경을 unit 분리 방식으로 바꾸면 그동안 숨겨져 있던 의존성이 한꺼번에 에러로 터진다. 반대로 -mfcu로 묶인 환경에서는 한 파일의 매크로 오염이 전체로 퍼진다. 같은 이름의 define이 파일마다 다른 값으로 재정의되어도 순서에 따라 조용히 덮이는 일이 생긴다. typedef도 마찬가지다. Compilation-unit scope의 선언에 기대는 코드는 unit 경계가 바뀌는 순간 깨지고, 패키지로 옮긴 코드는 경계가 바뀌어도 살아남는다.

확인 순서는 이렇다. 첫째, 지금 빌드가 어느 모드로 도는지 플래그와 파일 목록부터 확인한다. 둘째, 에러가 난 식별자가 define인지, typedef인지, 패키지 항목인지를 나눈다. 셋째, 그 선언이 어느 파일의 어느 scope에 있는지 찾는다. 넷째, 고칠 때는 전역 플래그를 뒤집기 전에 문제 파일이 명시적 include와 import로 자기 의존성을 선언하게 만드는 쪽을 먼저 검토한다. 툴과 버전에 따라 관련 옵션의 정확한 명칭과 기본값은 달라질 수 있으므로, 최종 확인은 사용 중인 버전의 User Guide에서 compilation unit 항목으로 한다. AI가 말한 기본값을 그대로 믿지 않는 것이 이 사례의 결론이다.

사례 2 — Vivado: "route 중간에 멈춰서 hold path를 보라"는 답이 불가능한 이유

두 번째로 자주 틀리는 질문은 이것이다. "Routing 도중 hold를 고치는 단계에서 멈추고, 그 시점의 hold path를 확인하려면 어떻게 하나요?" AI는 종종 그럴듯한 Tcl 명령어 조합이나 내부 단계 이름을 만들어 낸다. 그러나 route_design은 하나의 명령으로 실행되는 구현 단계이며, 그 내부 phase를 지정해 정지시키는 공개 Tcl API는 제공되지 않는 것으로 이해하는 것이 안전하다. 단계 앞뒤에 Tcl hook을 거는 것과 단계 내부를 멈추는 것은 다른 일이다. 전자는 가능하고, 후자는 공개 인터페이스가 아니다.

이 제한을 알아야 진단법이 바로 선다. AMD 문서 UG906이 제시하는 정석은 멈추는 방법이 아니라 비교하는 방법이다. Router는 hold를 setup보다 먼저 고치려는 성향이 있다. Hold 위반은 주파수를 낮춰도 해결되지 않지만 setup 위반은 그럴 수 있기 때문이다. 문제는 과도한 hold 수정이 routing detour를 만들어 setup을 망가뜨리는 경우다. 이때의 진단 흐름은 다음과 같다.

첫째, post-place 상태에서 hold 위반의 크기를 먼저 본다. 수백 ps를 넘는 비정상적으로 큰 위반은 대개 설계나 제약의 문제, 대표적으로 set_multicycle_path에 -hold를 빠뜨린 경우나 과도한 clock skew를 의심할 신호다. 둘째, 별도 실험으로 hold 검사를 비활성화하고 라우팅한다. UG906의 Method 1이 안내하는 방식은 set_false_path -hold 형태의 제약으로 hold check를 끈 채 route_design을 실행한 뒤 report_timing_summary의 WNS를 원래 결과와 비교하는 것이다. 이 제약은 진단 전용이며, 그대로 양산 설계에 남기면 절대 안 된다. 셋째, 차이가 크면 hold fix가 setup을 해치고 있다고 판단하고, 개별 경로에서는 report_design_analysis의 hold fix detour 정보나 worst setup path에 대한 hold 리포트로 원인을 좁힌다.

Pblock 남용도 이 지점에서 함께 짚어야 한다. Hold나 congestion 문제를 빨리 눌러 보려고 영역을 과도하게 좁게 잡거나, 관련 없는 모듈까지 한 영역에 묶으면 라우터의 자유도가 떨어져 detour와 congestion이 오히려 늘고, 다른 경로의 타이밍이 연쇄적으로 무너진다. Pblock은 배치 의도를 전달하는 도구이지 타이밍 수정의 만능 키가 아니다. 크기와 포함 범위를 정할 때는 floorplan 관점의 근거가 있어야 하고, 적용 후에는 대상 경로뿐 아니라 전체 WNS, WHS와 congestion 지표를 같이 봐야 한다.

사례 3 — 툴 버전 혼용: 에러 코드를 외우려 하면 반드시 틀린다

세 번째 사례는 synthesis, simulation, STA 툴의 버전이 서로 다른 환경에서 생기는 타이밍 에러다. AI에게 에러 메시지를 붙여 넣으면 특정 원인을 단정하는 답이 자주 돌아온다. 그러나 버전 혼용 환경에서는 같은 메시지가 셀 라이브러리의 타이밍 모델 차이, SDC 문법 해석 차이, 툴의 기본값 변경, 파일 포맷의 하위 호환 문제 등 서로 다른 원인에서 나올 수 있다. 여기서 필요한 것은 단정이 아니라 확인 순서다.

순서는 고정해 두면 된다. 1) 조합표 만들기: 각 단계의 툴 이름, 정확한 버전, 패치 수준, 라이브러리 버전을 한 표로 적는다. 기억이 아니라 파일로 적는 것이 중요하다. 2) 재현 최소화: 전체 설계가 아니라 문제가 된 경로와 셀이 포함된 최소 단위로 같은 에러가 재현되는지 본다. 3) 단일 버전 대조: 가능하다면 한 단계만 기준 버전으로 맞춰 다시 실행해 에러가 사라지는지 비교한다. 사라지면 원인은 로직이 아니라 조합에 있다. 4) 입력 동등성 확인: 두 환경에 들어간 netlist, SDC, 라이브러리가 실제로 같은 파일인지 해시와 생성 시각으로 확인한다. 의외로 많은 "버전 문제"의 실체는 구버전 산출물의 재사용이다. 5) 릴리스 노트 대조: 확인된 버전 쌍을 기준으로 알려진 타이밍 관련 변경과 deprecated 항목을 찾는다. 6) 벤더 지원 요청 시에는 위 조합표와 최소 재현 케이스를 함께 낸다. 이 순서 없이 메시지만 던지면 지원 쪽에서도 같은 추측을 반복하게 된다.

예방 원칙도 분명하다. Signoff에 쓰는 툴 조합은 프로젝트 단위로 고정하고, 중간 산출물에는 생성 툴과 버전을 파일명이나 헤더에 남기며, 버전 업그레이드는 전체 흐름을 한 번에 검증한 뒤에만 반영한다. "한 단계만 슬쩍 올리기"가 버전 혼용 사고의 가장 흔한 시작이다.

AI 답변을 실무에 쓰기 전에 거치는 검증 습관

세 사례의 공통 교훈은 같다. AI의 답은 가설로는 유용하지만 근거로는 부족하다. 옵션 이름이 나오면 사용 중인 버전의 매뉴얼에서 해당 옵션의 항목을 직접 열고, 기본값과 적용 범위를 확인한다. Tcl 명령이 나오면 툴의 도움말에서 그 명령과 하위 옵션이 실제로 존재하는지 확인한다. 절차가 나오면 작은 디자인이나 복사본에서 먼저 실행한다. 그리고 signoff에 영향을 주는 변경은 반드시 변경 전후 리포트를 나란히 놓고 비교한다. 이 네 단계를 거치면 AI는 위험한 자동화가 아니라 빠른 가설 생성기가 된다.

근거의 한계: 툴 옵션과 절차는 버전마다 달라질 수 있다. 본문은 특정 버전의 동작을 단정하지 않고 공개 문서로 확인되는 진단 원칙 중심으로 서술했으며, 실제 적용 시 사용 중인 버전의 공식 문서 대조가 필요하다.

FAQ

Q1. -mfcu를 켜면 컴파일이 빨라지나요? 본질은 속도가 아니라 compilation unit의 경계 설정이다. 부수적인 체감 차이가 있을 수 있어도, 선택 기준은 매크로와 선언의 가시성 규칙이어야 한다.

Q2. Vivado에서 단계 전후 hook은 쓸 수 있지 않나요? 단계 앞뒤에 Tcl을 실행하는 hook과 route_design 내부 phase에서 멈추는 것은 다르다. 전자는 공개된 사용법이고, 후자를 위한 공개 API는 없다는 것이 이 글의 요지다.

Q3. Hold 검사를 끄고 라우팅한 결과를 그대로 써도 되나요? 안 된다. UG906도 해당 제약을 진단 전용으로 명시한다. 비교로 원인을 확인한 뒤에는 제약을 제거하고 원래 흐름으로 다시 닫아야 한다.

Q4. Pblock은 쓰지 않는 것이 좋은가요? 아니다. 근거 있는 floorplan 의도를 전달할 때는 유효하다. 문제는 타이밍 문제를 누르기 위해 근거 없이 좁게 남용하는 경우이며, 적용 후 전체 지표를 함께 확인해야 한다.

Q5. 버전 혼용 에러는 AI에게 로그 전체를 주면 정확해지나요? 로그는 도움이 되지만 조합 정보가 없으면 단정은 여전히 위험하다. 버전 조합표와 최소 재현, 단일 버전 대조 결과를 함께 제시할 때 비로소 진단이 진단이 된다.

행동 체크리스트

• ☐ 툴 옵션을 실행하기 전에 사용 버전 매뉴얼에서 기본값과 적용 범위를 확인한다
• ☐ VCS 빌드의 compilation unit 모드와 파일 순서를 문서로 남긴다
• ☐ 공통 선언은 compilation-unit scope가 아니라 package로 옮기는 계획을 세운다
• ☐ Vivado hold 진단은 중단이 아니라 hold fix 없는 비교 라우팅으로 수행한다
• ☐ 진단용으로 넣은 false path 제약의 제거 여부를 체크리스트로 관리한다
• ☐ 프로젝트의 툴, 버전, 라이브러리 조합표를 만들고 signoff 조합을 고정한다
• ☐ AI가 제시한 명령과 절차는 복사본과 최소 케이스에서 먼저 검증한다

함께 읽으면 좋은 글

• OP-amp 피드백 계수 β=1일 때 왜 가장 불안정한가: loop gain과 phase margin으로 읽는 unity-gain의 직관

📩 VLSI Korea 뉴스레터 구독하기

매일 발행되는 반도체 심층 분석을 이메일로 가장 먼저 받아보세요. 구독은 무료입니다.

무료로 구독하기