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

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

PDF 다운로드

글/PING YEUNG PH.D., MENTOR GRAPHICS

블록 레벨 CDC 검증

① 구조적 검증을 정적 분석과 함께 실행한다. 이 단계에서는 대상 설계의 netlist를 만들고, netlist에 대한 정적 분석을 수행하고, 계획 단계에서 수집한 정보를 사용하여 정확한 결과를 생성한다. 모든 클럭 도메인과 모든 I/O 신호 속성의 보고서를 받게 되며, 무엇보다도 설계에 있는 모든 CDC 경로에 대한 요약 보고서가 다음과 같은 범주로 분할되어 제공된다.

- 올바르게 구현된 싱크로나이저

- 누락된 싱크로나이저와 잘못 구현된 싱크로나이저

- 프로토콜 검증이 필요한 복잡한 싱크로나이저

- 잠재적 재수렴 문제

이 레벨에서는 설계 설명이 적기 때문에 대부분의 CDC 경로가 올바른 범주와 잘못된 범주에 속해 있다. 이 결과는 GUI 환경에서 볼 수 있다. 문제를 쉽게 디버깅할 수 있도록 CDC 경로의 회로도를 생성할 수 있다.

② 프로토콜 검증을 포멀 분석과 함께 실행한다. 구조적 검증은 CDC 전송 프로토콜에 대한 모니터 집합을 생성한다. 이 레벨에서는 시뮬레이션을 실행할 수 있는 테스트벤치 환경이 없기 때문에 포멀 검증을 사용하여 CDC 프로토콜 모니터를 검증할 수 있다. 포멀 검증[8]은 간단한 리셋 시퀀스를 사용하여 설계를 초기화한다. 그런 다음에 비동기 클럭의 지정된 클럭 기간을 바탕으로 설계에 대한 사이클 기반 분석을 수행한다. 한 모니터가 검증되면 CDC 프로토콜이 항상 준수된다는 의미이다. 나머지 모니터들이 시스템 레벨 시뮬레이션으로 올라갈 수 있다. 이 결과를 같은 GUI 환경에서 제공되는 정적 분석 결과와 결합할 수 있다.

[그림 9] 블록 레벨 CDC 검증 플로우. 숫자는 텍스트 번호에 해당함

최상위 레벨 CDC 검증

① 구조적 검증을 정적 분석과 함께 실행한다. 설계의 최상위 레벨에서 정적 분석을 실행하기 전에 합성 불가능한 논리와 비기능적 논리를 제외하는 것이 중요하다. CDC 툴은 대상 설계의 netlist를 처음부터 새로 만들고 netlist에 대한 정적 분석을 수행한다. 계획 단계에서 수집한 CDC 요구 사항(동작 모드, 클럭 구조, 인터페이스 신호 및 동기화 규칙)은 검증 프로세스에서 정확한 결과를 찾아내기 위해 필수적이다. 모든 클럭 도메인과 모든 I/O 신호 속성의 보고서를 받게 되며, 무엇보다도 설계에 있는 모든 싱크로나이저에 대한 요약 보고서가 다음과 같은 범주로 분할되어 제공된다.

- 올바르게 구현된 싱크로나이저

- 누락된 싱크로나이저와 잘못 구현된 싱크로나이저

- 프로토콜 검증이 필요한 복잡한 싱크로나이저

- 잠재적 재수렴 문제

이 레벨에서는 설계 설명에 많은 모듈과 많은 비동기 클럭 도메인이 포함되어 있기 때문에 대부분의 CDC 경로가 복잡한 범주와 재수렴 문제에 속해 있다. CDC 경로가 여러 레벨의 계층 구조와 여러 모듈에 분산되어 있을 수 있기 때문에 이 경우에는 GUI 환경이 특히 유용하다.

② 프로토콜 검증을 시뮬레이션과 함께 실행한다. 기능적 검증에 테스트벤치 환경을 사용할 수 있는 상태이므로 시뮬레이션 환경 내에서 CDC 프로토콜 모니터를 실행할 수 있다. 이 모니터는 CDC 신호가 보내는 도메인에서 받는 도메인으로 이동할 때 안정적이도록 한다. 다중 비트 CDC 데이터는 그레이 코딩되거나, 샘플링될 때 안정적이다. 모니터에 의해 발견된 assertion 오류는 CDC 프로토콜 위반이 발생했으며 수정이 필요하다는 것을 의미한다. 기능적 시뮬레이션은 CDC 신호에 대해 긴 여유를 제공한다. 대체로 클럭 도메인을 통과할 때 충분히 안정적이다. 이 접근 방식은 CDC 경로의 타이밍을 압박하는 데는 비효율적이다. 따라서 CDC 프로토콜을 기능적 시뮬레이션과 함께 실행할 때는 프로토콜 모니터의 코너 케이스 커버리지를 조사하는 것이 중요하다. 통과하는 모니터는 전체 회귀 집합의 결과를 모두 병합할 때 커버리지가 적절해야 한다. CDC 경로의 타이밍에 명시적인 압박을 가하기 위해 몇 가지 직접 테스트를 회귀 집합에 추가할 수 있다. 제한된 랜덤 검증 환경에서는 스티뮬러스 생성기의 타이밍을 좁힐 수 있다.

[그림 10] 최상위 레벨 CDC 검증 플로우. 숫자는 텍스트 번호에 해당함

③ 준안정성 검증을 시뮬레이션 및 효과 주입과 함께 실행한다. 수동 조사 이후에 미심쩍은 잠재적 재수렴 위반이 설계에 포함되어 있는 경우에는 Questa CDC 툴[7]을 사용하여 준안정성 효과를 동적으로 주입함으로써 재수렴 문제를 파악할 수 있다. 시뮬레이션에서 준안정성 효과 주입기는 싱크로나이저를 통해 지연 시간을 변경한다. 따라서 싱크로나이저의 출력 간에 고정된 타이밍 관계를 가정하는 논리는 실패할 가능성이 높다. 시뮬레이션을 효과 주입기와 함께 실행하는 것이 기능적 검증 중에 CDC 준안정성 효과를 모방하는 가장 비용 효율적인 방법이다. 하드웨어를 만들기 전에 모든 잠재적 문제를 빠르게 발견할 수 있다.

CDC 위반 디버깅

이 섹션에서는 몇 가지 흔한 CDC 위반 사항 그리고 실제 설계 문제인지 여부를 판단하는 데 사용할 수 있는 기법에 대해서도 설명한다.

누락된 싱크로나이저 위반

구조적 검증 중에 보고되는 가장 흔한 위반 사항은 동기화되지 않은 CDC 신호이다. 예를 들어 그림 11 에서는 클럭 주파수에 따라 수신 레지스터가 입력 신뢰성을 샘플링하지 못할 수도 있다. 이것은 실제 문제이다. 이외에도 다음과 같은 예외로 인한 위반이 발생할 수도 있다.

[그림 11] 누락된 싱크로나이저 위반

잠재적 예외:

• 동기화되지 않은 경로가 거짓 경로이다. 예를 들어 그림 11의 멀티플렉서는 표시된 동기화되지 않은 경로를 정상 작동 중에 절대로 선택하지 않다. 미래의 분석에서 이를 수정하기 위해서는 계획 2단계의 동작 모드를 사용하여 멀티플렉서를 구성해야 한다.

• 송신 레지스터에 안정적인 값이 포함되어 있다. 따라서 싱크로나이저가 필요하지 않다. 이 경우에는 계획 3단계의 알려진 예외를 사용하여 송신 레지스터를 검증할 수 있다. 결과가 참이면 이 안정적 레지스터를 툴을 통해 사용 가능한 것으로 판단할 수 있다.

• 동기화되지 않은 신호가 동기화된 신호를 통해 샘플링된다. 예를 들어 그림 11의 멀티플렉서는 동기화된 신호에 의해 제어된다. 따라서 동기화되지 않은 신호가 샘플링되는 동안 안정적이라면 클럭 도메인을 제대로 통과한다. Questa CDC 툴[7]은 이러한 경우를 확인할 수 있도록 개선되어 왔다.

• 동기화되지 않은 경로가 임시 동기화 체계의 일부분일 수 있다. 이러한 임시 체계가 설계 정책에 따라 허용되는 경우에는 추후에 이 경로를 무시하도록 툴에 지시한다.

조합 논리 위반 

동기화 경로에서 조합 논리는 동기화된 신호에 중요한 문제이다. CDC 경로에서 허용되는 고장률을 결정하는 데 사용되는 데이터가 각 클럭 기간 내에 단일 전환을 가정하기 때문이다. 하지만 그림 12처럼 조합 논리가 경로에 있는 경우에는 결함이 발생한다. 따라서 오류 발생률이 크게 증가한다. 이 문제를 해결하기 위해서는 논리 경로에서 모든 조합 논리를 제거해야 한다. 때로는 예외가 있다.

[그림 12] 조합 논리 위반

잠재적 예외:

• 조합 논리가 정상 작동 중에 일정하기 때문에 결함이 발생하지 않다. 이것을 이후의 분석에 통합하기 위해서는 계획 2단계의 동작 모드를 사용하여 조합 논리를 구성해야 한다.

• 조합 논리가 클럭당 한 번만 전환된다. 예를 들어 그림 12에서, 조합 논리에 대한 입력은 송신 레지스터를 제외하고는 모두 안정적이다. 따라서 조합 논리의 출력에 결함이 발생할 가능성이 낮다. 이후의 분석을 위해 이 정보를 툴에 제공할 수 있다.

• 조합 논리가 단순히 버퍼일 경우가 매우 많다. 이것은 문제가 아니다. Questa CDC 툴은 버퍼와 인버터를 무시하도록 설계되었다.

재수렴 위반

재수렴은 서로 다른 클럭 도메인의 따로 동기화된 CDC 신호 두 개가 플립플롭의 팬인(fan-in)에 포함되어 있을 때 발생한다. 동기화된 CDC 신호가 재수렴되면 상대적 타이밍이 예측 불가능하다. 두 CDC 경로의 데이터가 동시에 도착하지 않을 수 있다. 이 신호를 수신하는 논리는 잠재적 사이클 왜곡을 고려해야 한다. 그렇지 않으면 다운스트림 논리에 대해 잘못된 데이터가 생성될 수 있다. 그림 13처럼 한 CDC 경로의 값이 다른 값보다 먼저 도착할 경우 멀티플렉서는 동기화되지 않고 잘못된 값이 수신 레지스터에 클러킹된다.

잠재적 예외:

• 재수렴된 CDC 경로가 상호 배타적이다. 예를 들어 그림 13에서 CDC 경로는 동시에 켜지지 않는 두 인터페이스에서 온 것일 수도 있다. 그럴 경우에는 이들 간의 상대적 타이밍에 대해 걱정할 필요가 없다. 배타적 동작을 검증하려면 assertion[6]을 시뮬레이션 또는 포멀 검증과 함께 사용하면 된다.

[그림 13] 재수렴 위반

• 재수렴된 CDC 경로가 변경 간에 긴 가드 타임을 가질 수 있다. 이것은 배타성과 비슷하다. 이 경우에는 준안정성 검증으로 미룰 수 있다. 재수렴 위반의 심각도는 준안정성 검증을 통해 정확하게 파악할 수 있다. 준안정성 효과 주입 시 시뮬레이션이 실패하면 재수렴 위반이 하드웨어에서 심각한 문제를 일으킬 것이라는 의미이다.

준안정성 주입기의 효과를 시각화할 수 있는 가장 좋은 방법은 파형 비교 툴을 사용하는 것이다. 그림 14는 원래의 시뮬레이션을 준안정성 검증을 사용한 시뮬레이션과 비교한 것이다. CDC 경로에서 랜덤 지연을 일으켰기 때문에 CDC 신호는 한 클럭 사이클만큼 빨라지거나 느려진다. 이것은 파형에서 1-사이클 차이로 강조되어 있다(그림 14의 가운데 섹션). 설계가 이러한 1-사이클 왜곡을 처리할 수 있으면 파형이 다시 빠르게 일치하게 된다. 설계가 이러한 왜곡을 처리할 수 없는 경우에는 잘못된 값이 수신 논리를 통해 전파되어 두 파형이 큰 차이를 보이게 된다(그림 14의 위쪽 섹션).

[그림 14] 원래 시뮬레이션과 준안정성 효과 시뮬레이션 비교

CDC 검증 결과

우리는 5단계 계획 프로세스를 많은 설계에 대해 추천하였고 적용하였다. 그중에 몇 개를 이 섹션에서 집중적으로 소개한다. 블록 레벨에서는 일반적으로 클럭 도메인이 많지 않다. 대부분의 경우 두세 개의 클럭 도메인밖에 없다. 무선 애플리케이션(표 1)은 다수의 비동기 인터페이스가 있는 블록이다. 따라서 여덟 개의 클럭 도메인이 있다. CDC 신호 수가 관리 가능한 정도이기 때문에 디버깅이 간단하다. 결과를 살펴보면 대부분의 문제가 싱크로나이저와 관련된 것임을 알 수 있다.

최상위 레벨에서는 훨씬 더 까다롭다(표 2). 클럭 도메인 수는 설계 구성에 따라 다르다. 따라서 가능한 동작 모드 조합을 신중히 정의하고 각 조합에 대해 개별적으로 CDC 검증을 수행해야 한다. CDC 신호 수가 많다. 우리는 5단계 계획 프로세스를 신중히 따랐다. 동작 모드 외에도 자세한 분석을 실행하기 전에 설계 팀과 함께 클럭 구조를 개략적으로 설정하고 검토했다. 블록 레벨에서는 동기화 규칙이 간단하다. 설계자가 통상적으로 한두 개의 동기화 체계만 사용한다. 하지만 최상위 레벨에서는 여러 소스의 블록이 있다. 그중 일부는 외부 IP이다. 그리고 동기화 체계가 혼합되어 있다. CDC 신호가 여러 소스에서 오기 때문에 재수렴 문제가 나타난다. 두 설계 모두에서 재수렴 문제가 발견되었다. 그중 일부는 회로도를 신중히 분석한 후에 확인되었다. 나머지에 대해서는 준안정성 검증을 수행했다.

[표 1] 블록 레벨 결과 요약

[표 2] 최상위 레벨 결과 요약

결론

오늘날의 ASIC에서 포괄적 CDC 검증을 수행하지 않을 경우의 위험은 너무나 크다. CDC 검증은 오늘날의 검증 테스트 계획에서 체크리스트에 올라 있어야 한다. 5단계 계획 프로세스와 EDA CDC 툴[7]을 사용하면 이제 레지스터 전송 레벨에서 CDC 검증을 수행할 수 있다. 따라서 더 일찍 검증을 시작하고 좀 더 쉽게 디버깅할 수 있는 레벨에서 CDC 문제를 잡아낼 수 있다.

CDC 검증의 5단계 계획 프로세스는 임시 검증 프로세스를 극복하기 위해 개발되었다. 정보 수집 프로세스를 형식화하며 설계 팀이 이 정보를 설계 문서에 캡처할 것을 장려한다. 다섯 가지 단계는 다음과 같다.

① 잠재적 후보 블록 식별

② CDC 요구 사항 문서화

③ 알려진 예외 형식화

④ 커버리지 목표 정의

⑤ 검증 전략 선택

포괄적인 CDC 검증 전략에는 구조적 검증과 정적 분석, 프로토콜 검증과 시뮬레이션, 준안정성 검증과 효과 주입이 포함되어야 한다. 설계의 블록 레벨 및 최상위 레벨 모두에서 이를 적용함으로써 CDC 검증을 검증 플로우에 원활하게 통합할 수 있다. 

[참고 문헌]

[1] Clifford E. Cummings, “Synthesis and Scripting Techniques for Designing Multi-Asynchronous Clock

Designs,” SNUG-2001. www.sunburst-design.com/papers에서 다운로드 가능

[2] Tai Ly, “The Need for an Automated Clock Domain Crossing Verification Solution,” 백서, www.mentor.com/fv에서 다운로드 가능

[3] Chris Kwok, et al, “Using Assertion-Based Verification to Verify Clock Domain Crossing Signals,” DVCon2003

[4] Tai Ly, et al, “Formally Verifying Clock Domain Crossing Jitter Using Assertion-Based Verification,” DVCon2004

[5] Tai Ly, et al, “A Methodology for Verifying Sequential Reconvergence of Clock Domain Crossing Signals,” DVCon 2005

[6] Harry Foster, et al, “Assertion-Based Design,” Kluwer Academic Publishers, 2003

[7] Mentor Graphics, “CDC Compiler User Guide V2.5,” 2007년 2월

[8] Mentor Graphics, “Formal Verification User Guide V2.5,” 2007년 2월

[9] Accellera, “Accellera Standard OVL Library Reference Manual,” 2006년 6월

[10] Mentor Graphics, “QuestaTM Verification Library Checkers Data Book V6.2f,” 2007년 1월

[11] Mentor Graphics, “CheckerWare Data Book Assertion Library V2.5,” 2007년 2월

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