죄송합니다. 더 이상 지원되지 않는 웹 브라우저입니다.

고급 CDC 검증을 위한 다섯 가지 단계 ①

PDF 다운로드

글/PING YEUNG PH.D., MENTOR GRAPHICS

서론

오늘날의 복잡한 ASIC 설계에서 클럭 도메인 수가 늘어남에 따라 CDC(Clock Domain Crossing)를 철저히 검증할 수 있는 능력이 더 중요해졌다. 기능적 검증과 마찬가지로 CDC 문제를 철저히 검증하기 위해서는 포괄적인 테스트 계획이 필수적이다. 많은 고객과 함께 작업한 경험을 바탕으로 Mentor는 CDC 검증을 위한 5단계 계획 프로세스를 개발했다.
CDC 테스트 계획을 세운 이후 효과적인 CDC 검증 방법론은 구조적 검증, 프로토콜 검증 및 준안정성 검증을 포함해야 한다. 이는 CDC 신호가 설계 단계에서 안정적으로 처리되도록 함으로써 제조 후에 비용이 많이 드는 리스핀을 방지한다. 이러한 요소들이 블록 레벨 및 최상위 레벨 RTL 모듈에 어떻게 적용되는지를 대략적으로 살펴보겠다. 몇 가지 흔한 CDC 위반 사항과 이러한 위반 사항이 실제 설계상 문제인지 여부를 판단하는 데 사용되는 기법에 대해서도 설명한다. 마지막으로, 이 방법론을 몇 가지 설계에 적용한 결과를 요약하고 강조한다.

준안정성

단일 비트 CDC 신호가 다른 클럭 도메인에 있는 레지스터에 의해 샘플링될 때는 수신 레지스터의 클럭에 따라 레지스터의 출력이 언제든지 변경될 수 있다. 하드웨어에서는 레지스터의 setup 또는 hold 시간 동안 CDC 신호 값이 변경될 경우 레지스터가 0에서 1 사이의 전압 레벨을 출력할 수 있다. 그럴 경우 레지스터를 준안정적(metastable)이라고 한다[1, 2]. 준안정적 레지스터의 출력은 결국 0 또는 1로 결정된다. 하지만 레지스터가 둘 중 어떤 값으로 결정될 것인지는 실질적으로 예측 불가능하다.

[그림 1] 준안정성

■ CDC 싱크로나이저
CDC 싱크로나이저는 준안정 값이 나머지 설계[1, 2]에 전파되지 않도록 CDC 신호를 조절하는 부가 회로이다. 일반적인 2-레지스터 싱크로나이저가 그림 2에 나와 있다.
CDC 싱크로나이저는 준안정 신호의 가능성을 줄이는 데 사용된다. 예측 불가능한 준안정 신호를 사용하여 예측 가능한 동작을 생성함으로써 준안정 값이 수신 클럭 도메인에 도달하지 못하도록 한다.

[그림 2] 2-레지스터 CDC 싱크로나이저

■ 준안정성 효과
모든 CDC에 대해 적절한 CDC 싱크로나이저를 사용하고 모든 CDC 프로토콜이 올바르게 구현된 경우에도 준안정성은 예측 불가능한 사이클 레벨 타이밍으로 이어질 수밖에 없다[4, 5]. 기존의 RTL 시뮬레이션은 준안정성을 모델링하지 않다. 따라서 하드웨어에서 준안정성이 나타날 때 발생할 수 있는 기능적 문제를 찾는 데 사용될 수 없다. RTL 시뮬레이션의 사이클 레벨 타이밍이 준안정성이 나타날 때 실제 하드웨어의 사이클 레벨 타이밍과 다른 두 가지 시나리오를 살펴보자.
그림 3에서는 수신 CDC 신호인 cdc_d가 레지스터 setup 시간을 위반한다. RTL 시뮬레이션에서는 올바르게 샘플링되지만 레지스터는 준안정적이며 출력은 0이 된다. 따라서 하드웨어 전환이 한 사이클 지연된다.

[그림 3] Setup 시간 위반: 하드웨어 전환이 한 사이클 지연됨

그림 4에서는 수신 CDC 신호인 cdc_d가 레지스터 hold 시간을 위반한다. RTL 시뮬레이션에서는 다음 사이클까지 샘플링되지 않는다. 하지만 레지스터는 준안정적이며 출력은 1이 된다. 따라서 하드웨어 전환이 시뮬레이션보다 한 사이클 앞당겨지게 된다.

[그림 4] Hold 시간 위반: 하드웨어 전환이 한 사이클 앞당겨짐

CDC 검증

많은 설계자들은 CDC 신호에 싱크로나이저를 사용함으로써 준안정성을 제어할 수 있다는 것을 알고 있다. 가장 일반적인 솔루션은 2-DFF(Two D Flip-Flops) 이상으로 구성된 싱크로나이저를 차례로 사용하여 크로싱의 MTBF(Mean Time Between Failure)를 크게 높이는 것이다. 해당 신호에 싱크로나이저를 사용하는 것이 필수조건이기는 하지만 충분조건은 아니다. CDC 검증의 세 가지 측면을 신중하게 다뤄야 한다.
• 구조적 검증: 각 싱크로나이저에는 클럭 도메인 간에 전송되는 신호 유형에 대한 올바른 구조가 있어야 한다. 예를 들어 2-DFF 싱크로나이저는 일반적으로 단일 비트 신호에 대한 최상의 솔루션이지만, 한 번에 한 비트만 변경되도록 그레이 코딩된 경우를 제외하고는 다중 비트 신호에 사용되어서는 안된다[1, 2]. 다중 비트 신호는 별도의 제어 신호, 비동기 FIFO 또는 다른 방법을 사용하여 도메인 간에 동기화될 수도 있다. 또한 싱크로나이저 내부나 앞에 조합 논리가 없어야 한다.
• 프로토콜 검증: 각 동기화는 클럭 도메인 간에 CDC 신호가 올바르게 전송되도록 전송 프로토콜이라는 일련의 규칙을 따라야 한다. 예를 들어 가장 간단한 2-DFF 싱크로나이저도 수신 도메인에서 신호를 캡처하기 위해서는 충분한 시간 동안 전송 신호가 안정적으로 유지되어야 한다. 전송 클럭이 수신 클럭보다 빠를 경우에는 그것이 불가능할 수 있다. 다중 비트 신호를 위한 동기화 구조는 더 복잡한 프로토콜 검사를 필요로 한다[2, 3]. CDC 전송 프로토콜을 위반하면 시뮬레이션 중에는 오류가 발생하지 않더라도 실제 하드웨어에서 결국 발생하게 된다.
• 준안정성 검증: CDC 신호 재수렴과 관련된 문제를 피해야 한다. 재수렴은 여러 신호가 한 클럭 도메인에서 다른 클럭 도메인으로 따로 동기화된 후 수신 도메인에서 같은 논리에 의해 사용될 때 발생한다(그림 5). 해당 논리는 신호 간에 타이밍 관계가 있다고 가정하지만 설계가 준안정성을 허용하지 않기 때문에 결국에는 실패한다[4, 5]. 이것은 싱크로나이저의 목적이 수신 논리에서 예측 불가능한 값이 인식되지 않도록 하기 위해 준안정성의 “둘레에 울타리를 치는 것”이기 때문이다. 그래도 각 싱크로나이저 내에서는 준안정성이 발생하여 CDC 신호에 예측 불가능한 지연을 일으킨다.
기존의 CDC 검증 방법에는 RTL 코드에서 싱크로나이저의 존재 여부를 수동으로 조사하고, 전체 타이밍 시뮬레이션을 실행하고, 클럭을 서로 간에 스윕하고, 특수 시뮬레이션 모델을 사용하여 싱크로나이저 간의 지연 시간을 무작위로 변경하는 것이 포함된다. 이러한 방법은 해당 설계에서 일부의 오류만 찾아낸다. 다행히 이제는 Mentor Graphics QuestaⓇ CDC 툴 및 방법론[7]을 사용하여 RTL을 철저하게 분석할 수 있으며, 시뮬레이션과 통합할 경우 지금까지 기술한 모든 유형의 CDC 문제를 찾아낼 수 있다.

[그림 5] CDC 신호의 재수렴

5단계 계획 프로세스

기업들은 CDC 검증의 중요성을 깨닫기 시작함에 따라 이 복잡한 문제를 해결하기 위한 자동화된 솔루션을 구현하고 있다. 하지만 어떠한 계획도 없이 검증 팀이 곧바로 툴을 사용할 때는 보통 매우 불만족스러운 결과를 얻게 된다.
설계 지식이 필수적이며 검증 접근 방식을 클럭 구조에 맞춰 조정해야 한다. 모든 CDC 경로를 과도하게 단순화하여 분석하면 많은 문제와 위반이 발생할 수 있다. ‘노이즈’ 레벨이 높기 때문에 잠재적 문제를 쉽게 간과할 수 있다. 많은 고객들과 함께 작업한 경험을 바탕으로 Mentor Graphics는 이러한 초기 노이즈를 해결하고 최소화할 수 있는 5단계 계획 프로세스를 개발했다.
실제 CDC 검증을 수행하기 전에 이 계획 프로세스를 따라 잠재적 후보 블록을 식별하고, CDC 요구 사항을 문서화하고, 예외를 형식화하고, 커버리지 목표를 정의하고, 검증 전략을 선택해야 한다. 이 단계에 필요한 정보는 이미 설계 사양에 포함되어 있어야 한다. 아니면 설계 개요 회의를 열어야 한다. 다섯 단계를 회의 안건으로 사용함으로써 실제 CDC 검증에 들어가기 전에 필요한 정보를 수집할 수 있다.

[그림 6] CDC 검증을 위한 5단계 프로세스

■ 잠재적 후보 블록 식별
CDC 검증을 적용해야 하는 경우와 그렇지 않은 경우를 파악하는 것이 중요하다. 이상적인 후보는 여러 개의 비동기 클럭이 있는 블록이다. 구조적 검증을 수행하려면 툴이 설계의 내부 구조를 이해해야 한다. 합성 불가 논리(패드, 클럭 생성기, 메모리 모듈 등)와 비기능적 논리(JTAG, BIST, 스캔, 전력 제어 등)는 전체를 건너뛰거나 CDC 검증에 대해 블랙박스로 레이블링되어야 한다. 따라서 동작 모델이 너무 많은 경우에는 칩 레벨에서 CDC 검증을 실행하는 것이 적합하지 않다.
이러한 이유로, RTL로 표현된 설계가 CDC 검증에 가장 적합하다. 모든 다중 비트 레지스터 및 버스는 명시적으로 식별될 수 있다. 데이터 및 제어 신호를 위한 CDC 요구 사항이 서로 다르기 때문에 따로 분석할 수 있다. 반대로, 게이트 레벨 표현의 경우에는 모든 버스가 단일 비트 와이어로 합성된다. 데이터 신호와 제어 신호를 구분하는 것이 불가능하다. 따라서 CDC 체계의 하위 집합만 적용할 수 있다.
또한 성공적인 CDC 검증을 위해서는 설계 내부 구조에 대한 지식이 필수적이다. 타사 IP 블록이나 기존 설계에서 CDC 분석을 수행하는 것은 별다른 장점이 없다. 설계 지식이 없으면 버그를 확인할 수 없거나 위반을 걸러낼 수 없다. 원래의 설계자에게 접근이 필요한다. 결과를 이해하기 위해서는 설계에 대한 지식이 필수적이다.

[그림 7] CDC 검증을 실행하기에 적합한 블록은 A, C 및 D

■ CDC 요구 사항 문서화
이 단계는 중요하다. 결과의 품질에 가장 큰 영향을 미치기 때문이다. CDC 검증이 모든 관련된 설계 특성, 클럭 관계 및 외부 환경을 고려하도록 해야 한다. 일련의 CDC 규칙이 이미 툴에 정의되어 있지만 이 추가적인 정보를 통해 더 많은 설계 규칙 및 필터가 활성화된다. 따라서 결과가 더 정확해지고 완벽해진다. 설계의 동작 모드를 정의하고, 클럭 구조를 개략적으로 기술하고, 인터페이스 신호에 대한 도메인을 문서화하고, 허용되거나 허용되지 않는 동기화 규칙을 결정해야 한다.
동작 모드 정의. 일부 사용자들은 설계가 스캔 모드일 때 모든 레지스터가 테스트 클럭에 의해서만 구동되는지를 검증하는 데 관심이 있을 수도 있다. 하지만 일반적으로는 설계가 정상 작동 중일 때 CDC 검증을 수행한다. 비기능적 모드(테스트, BIST, JTAG 등)을 비활성화하고 툴에 대해 의미 있는 작동 모드 및 구성을 정의해야 한다(그림 8). 설계의 일부분을 절전 또는 전원 꺼짐 모드로 놓을 수 있는 경우도 많다. 조합은 무수히 많다. 따라서 중요한 조합에 대한 CDC 검증에 초점을 맞추는 것이 중요하다.

[그림 8] CDC 검증을 위한 의미 있는 모드 정의

클럭 구조의 개략적 기술. 다중 클럭 설계에서 기본 클럭, 클럭 분배 구조, 내부 클럭 생성기, 분할기 그리고 클럭 게이팅 체계는 중요하므로 문서화되어야 한다. Questa CDC 툴[7]은 이러한 구조를 이해하고 클럭 트리(clock tree) 정보를 자동으로 추출할 수 있다. 추출된 클럭 구조를 통해 원래의 설계 의도를 검증하는 데 유용하다. 비동기 클럭 간의 크로싱만 분석해야 하며, 올바르게 설정해야 하는 클럭 게이팅 조건이 있을 수도 있다. CDC 경로 수는 클럭 도메인 수와 비례하기 때문에 관련 클럭 도메인으로만 분석을 한정하는 것이 훨씬 더 효율적이다.
• 인터페이스 신호의 문서화: CDC 검증은 어떤 클럭 도메인에서 와서 어디로 분산되는지를 알지 못하면 인터페이스 신호를 확인하지 못한다. 각각의 기능적 인터페이스 및 클럭 도메인에 대해 신호를 그룹화해야 하고, 모든 클럭 도메인에 대해 비동기적인 입력 신호를 명시적으로 식별해야 한다. 그러면 툴이 입력 신호가 사용되기 전에 동기화가 필요한지 여부를 판단한다. 비동기 및 동기 리셋 신호는 따로 레이블링해야 한다. 리셋 신호에 사용되는 동기화 체계는 일반 인터페이스 신호와 다르기 때문이다.
• 동기화 규칙 정의: 어떤 기업에서는 특정 CDC 체계(예: 3-레벨 DFF) 또는 맞춤형 동기화 셀로 모든 CDC 신호를 동기화할 것을 요구한다. Questa CDC 툴[7]은 여러 CDC 체계를 인식한다. 해당 체계를 먼저 검토하는 것이 중요하다. 그런 다음에 적절한 동기화 체계와 부적절한 동기화 체계로 분류하고, 사용되지 않는 체계를 해제하고, 동기화 셀 또는 모듈의 특성을 캡처할 수 있다.
어떤 세밀한 설계자들은 클럭 도메인 정보를 명시하고 CDC 경로를 설계 문서에 캡처한다. 그렇게 하는 것이 바람직한다. 이 정보가 있으면 지정된 CDC 경로가 제대로 처리되도록 특별히 주의를 기울일 수 있기 때문이다.

■ 알려진 예외 형식화
단순한 CDC 오류가 많은 위반을 일으키는 경우가 종종 있다. 특히 CDC 신호가 여러 비동기 도메인에 분산되는 경우 그렇다. 따라서 안정적인 것으로 간주되어 동기화가 필요하지 않은 레지스터를 사전에 모두 파악하는 것이 좋다. 설계가 정상 가동되기 전에 소프트웨어에 의해 프로그래밍되는 구성 레지스터, 상태 레지스터 또는 제어 레지스터의 경우 특히 그렇다. 주로 이 정보는 설계 사양에 있다. 종종 이러한 제어 레지스터는 모두 단일 모듈 안에 있거나 공통된 명명 방식을 따른다. CDC 검증에 이 정보를 활용하는 것이 유용하다.
레지스터 외에도 일부 인터페이스 또는 내부 신호는 정상 작동 중에 안정적인 것으로 알려져 있다. 내부에서 생성된 리셋 신호, 전원 끄기 신호, 칩 선택, 기능 활성화 및 비활성화 신호가 대표적인 예이다. 이들은 CDC 검증의 효율성을 높이는 데 모두 유용하다. 마지막으로, 이전 버전의 칩에는 잘 알려진 CDC 버그 혹은 수동 또는 게이트 레벨 방법론을 사용하면서 발생한 이슈가 있을 수 있다. 이것은 검증 계획에서 캡처해야 하는 값비싼 교훈이다. CDC 검증 중에 해당 CDC 경로가 분석되고 모든 문제가 제대로 수정되도록 해야 한다.

■ 커버리지 목표 정의
경험에 비추어 보면, 기존의 기능적 검증은 CDC 경로를 제대로 검증하지 못한다. 기능적 시뮬레이션 환경에서는 클럭 기간이 상수로 정의되고, 클럭 왜곡 및 관계가 고정되고, 클럭 신호가 버퍼 또는 전파 지연 없이 제대로 작동하기 때문이다. CDC 경로에서의 준안정 효과를 더 효과적으로 검증하기 위해, 기업들은 다양한 임시 접근 방식을 사용한다. 일부는 클럭 기간을 무작위로 줄이거나 늘린다. 일부는 여러 비동기 클럭 간의 왜곡 및 관계를 무작위로 변경한다.
사용된 기술에 관계없이 시뮬레이션에서 CDC 전송 프로토콜을 검증할 때는 CDC 경로가 적절히 검증되고 있는지를 확인하기 위해 프로토콜 커버리지를 모니터링하는 것이 중요하다. 그러려면 assertion 라이브러리[9, 10, 11]의 체커(checker)를 사용하여 프로토콜의 의미론을 캡처하면 된다. 체커는 커버리지 정보를 수집하여 각 CDC 프로토콜이 완벽하게 실행되고 있는지를 확인한다. 커버리지가 부족하면 설계에 발견되지 않은 버그가 포함되어 있을 수 있다는 것을 의미한다.

CDC Handshake:
- Assertion:
   i. multiple requests violation
   ii. acknowledge without request violation
   iii. request drop violation
   iv. acknowledge timeout violation
- Coverage:
   i. #request asserted
   ii. #acknowledge asserted
CDC FIFO:
- Assertion:
   i. FIFO overflow violation
   ii. FIFO underflow violation
   iii. Simultaneous push and pop violation
- Coverage:
   i. #push asserted
   ii. #pop asserted
   iii. maximum FIFO entry

먼저 CDC 경로에 사용된 프로토콜을 항목화하고, 가장 중요한 것부터 가장 덜 중요한 순서로 정렬하고, 커버리지가 필요한 프로토콜을 식별한다. 위에 나온 코드에서처럼 각 CDC 프로토콜에 대해 assertion 및 커버리지 항목을 결정한다. 시뮬레이션이 준안정성 효과를 얼마나 잘 검증하는지 측정하려면 수신 및 송신 클럭의 정렬도 모니터링해야 한다.

■ 검증 전략 선택
각각의 블록을 완전하게 검증하게끔 선택할 수도 있고, 칩의 전체적인 최상위 레벨에서 계층 구조적 접근 방법으로 선택할 수도 있다. 최상위 레벨은 설계에서 패드 링, 테스트 논리, 전력 제어 등은 제외한 가장 높은 기능적 계층 구조를 나타냅니다. 알려진 버그를 찾거나 실험실에서 나타난 문제를 추적할 수 있다. 선택하는 전략에 따라 CDC 분석 툴을 실행하는 방법이 결정된다. 경험에 비추어 보면, 네 가지 일반적인 전략이 있다.
• 블록 레벨 검증: 블록 레벨 설계 중에는 CDC 구조의 정적 분석이 RTL 코드를 확인하기 전에 실행되어야 한다. 그래야 CDC 체계가 엄격히 준수된다. 문제가 발견되는 경우 이 레벨에서 빠르게 식별하고 디버그할 수 있다. 생성된 CDC 프로토콜 모니터는 포멀 검증[8] 및 시뮬레이션과 같은 블록 레벨의 기능적 검증 방법론에도 사용될 수 있다. 그러면 데이터 손실 없이 CDC 프로토콜을 따를 수 있다.
• 최상위 레벨 검증: 최상위 레벨 통합 중에는 CDC 구조의 정적 분석을 다시 실행하여 여러 개의 블록이 서로 통합될 때 생성된 새로운 CDC 신호를 확인해야 한다. CDC 신호의 개수는 최상위 레벨에서 기하급수적으로 증가한다. 따라서 위에 설명된 5단계 계획 프로세스를 따르는 것이 중요하다. 크고 복잡한 설계의 경우, 특히 IP 모듈이 많은 설계의 경우 계층 구조적 검증 방식을 사용할 수 있다. 생성된 CDC 프로토콜 모니터는 시스템 레벨 기능적 검증의 회귀에 포함되어야 한다.
• 버그 헌팅 및 분류: 이 전략은 설계에서 이미 알고 있거나 의심스러운 CDC 문제를 파악하기 위해 수행된다. 타이밍 문제와 CDC 문제를 구분하는 것이 중요하다. 타이밍 문제는 칩에서 일관되게 장애를 일으키는 경향이 있다. 클럭의 주파수나 일부 신호를 변경하면 문제가 영구적으로 사라질 수 있다. 반면에 준안정성은 예측 불가능하기 때문에 CDC 문제가 무작위로 칩에서 장애를 일으킨다. 경험에 비추어 볼 때, 시스템 또는 칩 레벨에서 CDC 문제를 찾는 것은 매우 어렵다. 잠재적 후보가 너무나 많기 때문이다. 따라서 첫 번째 할 일은 문제를 블록 또는 서브시스템 레벨로 좁히는 것이다. 비동기 클럭 도메인이 있는 블록에 초점을 맞춰야 한다. CDC 재수렴이 있는 블록을 특히 의심해야 한다. 서로 다른 CDC 경로의 랜덤 지연으로 인해 데이터가 잘못 샘플링되거나 완전히 손상될 수도 있다. 후보 클럭을 식별한 후에는 블록 레벨 검증 전략을 적용할 수 있다.
• 커버리지 대상 설정: 이것은 블록 레벨 또는 최상위 레벨 검증 전략의 확장일 수 있다. 목표는 모든 CDC 프로토콜이 완벽하게 실행되고 모든 CDC 경로에서 준안정성 효과가 완벽하게 검증되도록 하는 것이다. CDC 프로토콜 모니터의 커버리지를 조사하고, 커버리지 홀(hole)을 채우기 위한 추가적인 테스트를 생성해야 한다. 시스템 레벨 회귀의 버그 발생률이 안정화되면 준안정성을 시뮬레이션에 주입할 수 있다. 준안정성 효과는 CDC 경로의 타이밍을 변경한다. 블록이 CDC 경로의 랜덤 지연을 처리하도록 설계되지 않은 경우에는 기능적으로 실패할 수 있다. 쉽게 디버깅하기 위해서는 대표적인 회귀 하위 집합부터 시작하는 것이 좋다.
다음 두 섹션에서는 가장 흔히 사용되는 전략인 블록 레벨 검증과 최상위 레벨 검증에 대해 자세히 설명한다.

leekh@seminet.co.kr
(끝)
<저작권자(c) 반도체네트워크, 무단 전재-재배포 금지>