Verilog full_case·parallel_case, 왜 '악마의 쌍둥이'로 불리는가

🔬 Verilog full_case·parallel_case 어트리뷰트의 메커니즘과 설계상 위험성

디지털 논리 설계 | Synthesis Directive | Simulation-Synthesis Mismatch 심층 분석

디지털 회로를 설계할 때 Verilog의 case 문은 가장 빈번하게 사용하는 다중 분기 구문입니다. 그런데 이 단순해 보이는 구문에 full_case와 parallel_case라는 합성 지시어(Synthesis Directive)를 붙이는 순간, 시뮬레이션과 실제 하드웨어 사이에 보이지 않는 균열이 생깁니다. Clifford E. Cummings 교수가 이 둘을 "Evil Twins of Verilog Synthesis"라고 불렀을 정도로, 업계에서는 오래전부터 경고해 온 고위험 요소입니다. 이 글에서는 두 지시어의 정확한 동작 원리, 불일치가 발생하는 구조적 원인, 그리고 현대적 대안까지 하나씩 파헤쳐 봅니다.

📐 Case 문의 표준 동작 원리 (IEEE 1364)

본격적으로 지시어를 분석하기 전에, Verilog 표준이 정의하는 case 문의 원칙 두 가지를 명확히 짚고 넘어가겠습니다.

▶ 우선순위 평가 (Priority Evaluation)

case 문은 위에서 아래로 순차적으로 평가됩니다. 여러 아이템이 동시에 매칭되더라도 가장 먼저 나오는 구문만 실행됩니다. 즉, 기본적으로 Priority Encoder 구조를 내포하고 있습니다.

▶ 미완성 처리 (Incomplete Case)

가능한 비트 조합이 모두 나열되지 않고 default도 없으면, 매칭되지 않는 입력에 대해 출력이 이전 값을 유지합니다. 조합 회로 문맥에서 이는 곧 의도치 않은 Latch 생성을 의미합니다.

🏷️ 핵심 용어 정의

용어	정의	핵심 키워드
Full Case	모든 가능한 입력 조합(2ⁿ개)이 명시되었거나 default가 포함된 상태	완전성 (Completeness)
Parallel Case	나열된 case 아이템들이 서로 겹치지 않아(Mutually Exclusive) 동시에 둘 이상이 참이 될 수 없는 상태	배타성 (Exclusivity)

⚙️ full_case 어트리뷰트 상세 분석

💡 무엇을 하는가

설계자가 합성 도구에게 이렇게 선언하는 것입니다: "나열하지 않은 나머지 케이스는 절대 발생하지 않으니 Don't Care로 처리해도 된다." 합성기는 이 약속을 믿고 missing case에 대해 값을 보존하는 로직을 생략합니다.

📝 코드 예시

case (sel) // synopsys full_case

  2'b00: out = a;

  2'b01: out = b;

  // 2'b10, 2'b11 → 합성기는 Don't care 처리

endcase

→ 합성 결과: default가 없어도 Latch를 만들지 않고 순수 조합 회로로 최적화합니다. 게이트 수가 줄고 타이밍이 개선되지만, 이 약속이 거짓이라면 재앙의 시작입니다.

⚡ parallel_case 어트리뷰트 상세 분석

💡 무엇을 하는가

합성 도구에게 이렇게 지시합니다: "case 아이템 간에 겹치는 부분이 없으니 우선순위 로직(Priority Encoder)을 만들지 말고 병렬 로직(Multiplexer)으로 구성하라."

📝 코드 예시

case (state) // synopsys parallel_case

  3'b1??: out = a;

  3'b?1?: out = b;

  3'b??1: out = c;

endcase

→ 합성 결과: Priority Encoder 대신 병렬 MUX 구조로 합성하여 면적과 지연 시간을 줄입니다.

⚠️ 함정: 위 코드에서 3'b111 입력 시 세 조건 모두 매칭됩니다. 시뮬레이터는 상단의 a를 선택하지만, 합성된 하드웨어는 세 경로가 동시에 활성화되어 예측 불가능한 출력을 내놓습니다.

🔥 핵심: Simulation-Synthesis Mismatch의 구조적 원인

이 두 지시어가 "Evil Twins"로 불리는 결정적 이유는 바로 여기에 있습니다. 시뮬레이터는 주석(// synopsys...)을 완전히 무시하지만, 합성기는 이를 절대적인 설계 지시로 받아들입니다. 동일한 RTL 코드에서 두 도구가 서로 다른 해석을 하게 되는 것입니다.

🔴 full_case 불일치 시나리오

→ 시뮬레이션: 명시되지 않은 입력(2'b10, 2'b11)이 들어오면 out의 이전 값을 유지 (Hold)

→ 실제 HW: 합성기가 Don't care로 처리한 결과, 게이트 최적화에 따라 0 또는 1 중 예측 불가능한 값이 출력

🔴 parallel_case 불일치 시나리오 (더 치명적)

→ 시뮬레이션: Verilog 표준에 따라 우선순위를 지켜 최상단 매칭 항목만 실행

→ 실제 HW: 병렬 MUX 구조이므로 겹치는 입력 시 여러 경로가 동시에 활성화되어 논리적 충돌 발생 → 예측 불가 출력

🧠 핵심 요약

RTL 시뮬레이션을 100% 통과했더라도, full_case/parallel_case가 붙은 코드에서 합성기가 만든 실제 게이트 네트리스트(Gate-Level Netlist)는 전혀 다른 동작을 할 수 있습니다. 이는 Post-Synthesis 시뮬레이션이나 실제 FPGA/ASIC에서야 비로소 드러나는, 가장 디버깅하기 어려운 종류의 버그를 만들어냅니다.

📊 불일치 비교 한눈에 보기

구분	🖥️ 시뮬레이션	🔧 합성 후 HW	위험도
full_case 미선언 입력 시	이전 값 유지 (Latch 동작)	임의 값 출력 (Don't care)	⚠️ 높음
parallel_case 겹치는 입력 시	최상단 매칭 실행 (Priority)	다중 경로 활성화 (충돌)	🚨 매우 높음

💥 설계 품질에 미치는 실질적 영향

🟡 디버깅 비용 급증

RTL 시뮬레이션에서 잡히지 않는 버그가 보드 테스트나 Post-Synthesis 시뮬레이션 단계에서 처음 발견됩니다. 설계 단계가 뒤로 갈수록 수정 비용은 기하급수적으로 증가하며, ASIC의 경우 Respin(재제작)으로 이어질 수 있습니다. 한 번의 Respin은 수백만 달러의 손실과 수개월의 일정 지연을 초래합니다.

🟡 시스템 안정성 결여

full_case를 남용하여 Latch를 강제로 제거하면, 설계 시 예상하지 못한 입력 조합이 들어올 때 시스템이 Unknown State에 빠질 수 있습니다. 특히 FSM(유한 상태 기계)에서 이 문제가 발생하면, 상태 머신이 예측 불가능한 상태로 전이하여 전체 시스템 오동작으로 이어집니다.

🟡 검증 신뢰도 훼손

시뮬레이션 Pass가 더 이상 하드웨어 정상 동작을 보장하지 못합니다. 이는 검증 팀의 커버리지 데이터 자체를 무의미하게 만들며, 프로젝트 전체의 품질 게이트(Quality Gate)에 구멍을 냅니다.

✅ 현대적 대안 및 Best Practices

현대 디지털 설계에서는 주석 기반의 위험한 지시어 대신, 코딩 스타일과 언어 기능 자체로 의도를 명확히 전달하는 방법을 권장합니다.

🟢 full_case 대안: 항상 default 문을 사용하라

default: out = 'x; 형태로 명시하면, 합성기는 Don't care로 최적화하면서 시뮬레이션에서는 X 전파(propagation)를 통해 문제를 조기에 감지할 수 있습니다. 시뮬레이션과 합성 모두가 동일한 의도를 이해하므로, Mismatch가 구조적으로 발생하지 않습니다.

case (sel)
  2'b00: out = a;
  2'b01: out = b;
  default: out = 'x; // 안전한 Don't care 표현
endcase

🟢 parallel_case 대안: 코드 구조로 배타성을 보장하라

→ 아이템들이 실제로 겹치지 않도록 설계하고, 우선순위가 필요하면 if-else 문을 사용

→ 병렬성이 확실하면 와일드카드 없이 명확한 값으로 case 아이템을 작성하여, 합성기가 스스로 배타성을 판단하게 두는 것이 안전합니다.

🟢 SystemVerilog의 unique/priority case 활용

SystemVerilog(IEEE 1800)에서는 unique case와 priority case라는 언어 수준의 키워드를 제공합니다. 이들은 주석이 아닌 공식 구문이므로, 시뮬레이터와 합성기 모두 동일하게 해석합니다. unique case는 조건 겹침이나 누락 시 런타임 경고를 발생시켜, 설계 검증 단계에서 문제를 즉시 포착할 수 있습니다.

🔍 실무 체크리스트: 이 코드, 안전한가?

기존 프로젝트에서 full_case/parallel_case를 발견했을 때 점검할 항목들입니다.

✓ full_case가 붙은 case 문에 default를 추가할 수 있는가? → 가능하면 default를 추가하고 지시어를 제거

✓ parallel_case가 붙은 case 아이템들이 정말 겹치지 않는가? → 와일드카드(?, z)가 있다면 겹칠 가능성 높음

✓ Gate-Level 시뮬레이션으로 확인했는가? → RTL 시뮬레이션만으로는 불일치를 잡을 수 없음

✓ 합성 경고 메시지를 확인했는가? → 대부분의 합성 도구가 Incomplete case 경고를 출력함

✓ SystemVerilog 전환이 가능한가? → 가능하면 unique case로 마이그레이션

📌 결론: 주석이 아닌 코드로 의도를 전달하라

"full_case와 parallel_case는 설계자가 합성 도구에 거짓말을 할 수 있게 허용하는 도구다."

— Clifford E. Cummings, SNUG 1999

full_case와 parallel_case는 1990년대 ASIC 설계에서 게이트 하나가 아쉬웠던 시절의 유산입니다. 당시에는 면적과 타이밍의 미세한 차이가 칩의 성패를 좌우했기에, 이런 위험을 감수할 만한 가치가 있었을 수 있습니다. 하지만 트랜지스터가 수십억 개에 달하는 현재, 이 지시어들로 아끼는 게이트 몇 개는 미미하고 대신 시뮬레이션과 합성 간의 논리적 괴리라는 치명적 리스크만 남깁니다.

현대 디지털 설계에서 올바른 접근은 명확합니다. 주석(Comment) 속에 숨긴 지시어가 아니라, Verilog/SystemVerilog 언어 자체의 문법으로 설계 의도를 표현하십시오. default문과 SystemVerilog의 unique case는 시뮬레이터와 합성기 모두가 이해하는 공용어입니다. 도구가 아닌 코드가 진실의 원천(Single Source of Truth)이 될 때, 비로소 시뮬레이션 결과를 믿을 수 있고, 칩은 의도한 대로 동작합니다.

References

→ Clifford E. Cummings, "full_case parallel_case, the Evil Twins of Verilog Synthesis" (SNUG 1999)

→ IEEE Standard for Verilog Hardware Description Language (IEEE 1364-2005)

→ IEEE Standard for SystemVerilog (IEEE 1800-2017)

→ Xilinx Vivado Design Suite User Guide: Synthesis (UG901)

본 콘텐츠는 정보 제공 목적으로 작성되었으며, 특정 도구나 벤더의 공식 입장을 대변하지 않습니다. 실제 설계 시에는 사용 중인 합성 도구의 공식 문서를 반드시 확인하시기 바랍니다.

📄 Raw Data

**[종합 리서치 보고서] Verilog full_case 및 parallel_case 어트리뷰트의 메커니즘과 설계상 위험성**

## 1. 질문 파악 및 연구 배경
디지털 논리 설계 시 Verilog의 `case` 문은 다중 분기 로직을 구현하는 핵심 도구입니다. 그러나 표준 Verilog 시뮬레이터와 합성 도구(Synthesis Tool)가 `case` 문을 해석하는 방식에는 미묘한 차이가 존재합니다. 특히 `full_case`와 `parallel_case`는 설계자가 합성 도구에 직접적인 최적화 지시를 내리는 'Synthesis Directives(혹은 Pragmas)'로 사용되지만, 이를 잘못 사용할 경우 시뮬레이션 결과와 실제 하드웨어 동작이 달라지는 치명적인 'Simulation-Synthesis Mismatch'를 유발합니다. 본 리서치에서는 두 개념의 기술적 정의, 코드 구현 방식, 그리고 불일치가 발생하는 구조적 원인을 심층 분석합니다.

---

## 2. 기초 정보 (Foundation)

### 2.1 Case 문의 표준 동작 원리 (IEEE Std 1364)
Verilog 표준에서 `case` 문은 위에서 아래로 순차적으로 평가됩니다. 
1. **우선순위(Priority)**: 만약 여러 `case` 아이템이 일치할 경우, 가장 먼저 매칭되는 상단의 구문이 실행됩니다. 이는 기본적으로 'Priority Encoder' 구조를 암시합니다.
2. **미완성(Incomplete) 처리**: 모든 가능한 비트 조합이 나열되지 않고 `default` 문도 없다면, 매칭되지 않는 입력에 대해 하드웨어는 이전 값을 유지(Latch 형성)하거나 정의되지 않은 동작을 수행하게 됩니다.

### 2.2 용어 정의
- **Full Case**: 모든 가능한 입력 조합(2^n개)이 명시적으로 나열되었거나 `default`가 포함된 상태를 의미합니다.
- **Parallel Case**: 나열된 `case` 아이템들이 서로 겹치지 않아(Mutually Exclusive), 동시에 두 개 이상의 아이템이 참이 될 수 없는 상태를 의미합니다.

---

## 3. 현황 및 기술 데이터 (Technical Details)

### 3.1 full_case 어트리뷰트
- **개념**: 설계자가 합성 도구에 "나열되지 않은 나머지 케이스는 절대 발생하지 않거나(Don't Care), 무시해도 좋다"라고 선언하는 것입니다.
- **코드 입력 방식**:
  ```verilog
  case (sel) // synopsys full_case
    2'b00: out = a;
    2'b01: out = b;
    // 2'b10, 2'b11이 없어도 합성기는 이를 Don't care로 처리하여 Latch를 만들지 않음
  endcase
  ```
- **합성 결과**: `default` 문이 없더라도 missing case에 대해 출력값을 고정하지 않으므로 순차 회로(Latch) 대신 조합 회로로 최적화됩니다.

### 3.2 parallel_case 어트리뷰트
- **개념**: 합성 도구에 "아이템 간에 겹치는 부분이 없으므로 우선순위 로직(Priority Encoder)을 만들지 말고 병렬 로직(Multiplexer)으로 구성하라"고 지시하는 것입니다.
- **코드 입력 방식**:
  ```verilog
  case (state) // synopsys parallel_case
    3'b1??: out = a;
    3'b?1?: out = b;
    3'b??1: out = c;
  endcase
  ```
- **합성 결과**: 시뮬레이션에서는 `3'b111` 입력 시 최상단의 `a`가 선택되지만, 이 지시어를 본 합성기는 병렬 MUX 구조로 설계하여 면적과 지연 시간을 줄이려 시도합니다.

---

## 4. 원인 분석: Simulation-Synthesis Mismatch (불일치의 근원)

이 어트리뷰트들이 위험한 이유는 **시뮬레이터는 주석(`// synopsys...`)을 무시하지만, 합성기는 이를 금과옥조로 여기기 때문**입니다.

### 4.1 'full_case'에서의 불일치 원인
시뮬레이션에서는 명시되지 않은 값(`2'b10`, `2'b11`)이 들어오면 `out` 변수의 값이 변하지 않습니다(Hold). 하지만 합성기는 `full_case` 지시어를 보고 "이 값들은 안 들어온다며? 그럼 아무 값이나 나와도 상관없겠네"라고 판단하여 로직을 최소화합니다.
- **차이점**: 시뮬레이션에서는 이전 값을 유지하려 하지만, 하드웨어는 로직 게이트 최적화 결과에 따라 0 혹은 1 중 임의의 값이 출력됩니다. 이는 디버깅이 불가능한 간헐적 오류를 만듭니다.

### 4.2 'parallel_case'에서의 불일치 원인
가장 심각한 오류를 유발하는 지점입니다. 
- **시뮬레이션**: Verilog 표준에 따라 '우선순위'를 지킵니다. 겹치는 조건이 있어도 가장 위쪽 코드만 실행됩니다.
- **합성**: `parallel_case`를 보면 우선순위 로직을 제거하고 모든 조건을 평등하게 처리하는 병렬 구조를 만듭니다. 만약 실제로 조건이 겹치는 입력(`3'b111` 등)이 들어오면, 여러 경로가 동시에 활성화되어 논리적 충돌(OR 결합 등)이 발생하거나 예측 불가능한 값이 출력됩니다.
- **결과**: RTL 시뮬레이션은 Pass 하지만, 실제 칩(Gate Level)에서는 엉뚱한 동작을 하게 됩니다.

---

## 5. 영향 및 파급 효과 (Impact)

### 5.1 설계 품질에 미치는 영향
- **디버깅 비용 급증**: 시뮬레이션에서 잡히지 않는 버그가 실제 보드 테스트나 Post-Synthesis 시뮬레이션에서만 발견됩니다.
- **안정성 결여**: `full_case`를 남용하여 Latch를 강제로 제거하면, 의도치 않은 입력 시 시스템이 'Unknown State'에 빠질 수 있습니다.

### 5.2 대안 및 권장 사항 (Best Practices)
현대적인 고신뢰성 설계에서는 이러한 '위험한 지시어' 대신 코딩 스타일로 해결할 것을 권장합니다.
1. **full_case 대신**: 항상 `default` 문을 사용하십시오. `default: out = 'x;`라고 명시하면 합성기도 최적화를 수행하면서 시뮬레이션 시 오류를 감지하기 용이합니다.
2. **parallel_case 대신**: 아이템들이 실제로 겹치지 않게 설계하고, 우선순위가 필요하다면 `if-else` 문을, 병렬성이 확실하다면 단순 `case` 문을 사용하는 것으로 충분합니다.

---

## 6. 결론 및 시사점 (Conclusion)

리서치 결과, `full_case`와 `parallel_case`는 90년대 ASIC 설계에서 게이트 하나라도 아쉬웠던 시절의 유산에 가깝습니다. **Clifford E. Cummings**의 유명한 논문 "full_case parallel_case", "the Evil Twins of Verilog Synthesis"에서 경고하듯, 이 지시어들은 '설계자가 거짓말을 할 수 있게 허용'하는 도구입니다.

- **핵심 결론**: 지시어를 통한 강제 최적화는 시뮬레이션과 합성 간의 논리적 괴리를 만들며, 이는 칩 설계 실패(Respin)로 이어지는 고위험군 요소입니다.
- **최종 시사점**: 주석 기반의 지시어 사용을 지양하고, Verilog 언어 자체의 문법(특히 `default`와 `unique case` - SystemVerilog 도입 시)을 통해 의도를 명확히 전달하는 것이 현대 설계의 정석입니다.
---

## References

- [Clifford E. Cummings](http://www.sunburst-design.com/papers/CummingsSNUG1999Boston_FullParallelCase.pdf)
- [IEEE Standard for Verilog Hardware Description Language](https://standards.ieee.org/standard/1364-2005.html)
- [Xilinx Vivado Design Suite User Guide](https://docs.xilinx.com/r/en-US/ug901-vivado-synthesis/Full-Case-and-Parallel-Case-Attributes)