CDC 검증 가정: 깨끗한 파형이 실제 경계의 안전성을 다 말할까
클록 주파수를 여러 조합으로 바꾸고, 위상도 흔들어 CDC 테스트를 돌렸다. 데이터는 모두 맞았다. 이제 두 클록 영역의 경계가 안전하다고 말할 수 있을까. CDC 검증 가정은 테스트가 보여 준 성공과, 그 성공을 실제 회로에서도 기대하게 하는 조건 사이의 간격을 드러내는 문서다.
보통 RTL 시뮬레이터는 플립플롭을 디지털 상태의 갱신 규칙으로 다룬다. 입력이 setup·hold 경계에서 바뀌었을 때 아날로그 내부 노드가 얼마나 오래 중간 전압에 머무는지 직접 계산하지 않는다. 깨끗한 파형은 그런 현상이 발생하지 않는다는 실험 증거가 아니다.
기능 모델에서 무엇을 볼 수 있나
10ns 주기 목적지 에지 사이에 2–6ns의 짧은 펄스를 넣으면, 일반 RTL 모델에서도 첫 동기화 FF가 그 펄스를 놓치는 현상을 볼 수 있다. 이벤트가 샘플링 시점을 지나지 않았기 때문이다. 이것은 준안정성 모델이 없어도 찾을 수 있는 정보 손실이다.
반면 에지 근처의 변화가 실제 셀에서 첫 단계의 안정화를 지연시키는 확률과 지속 시간은 같은 테스트만으로 측정되지 않는다. Altera의 동기화 레지스터 설명은 단계 사이의 실제 안정화 시간을 MTBF 계산과 연결한다. 논리 모델의 지연 횟수와 구현에서 확보된 안정화 시간은 같은 증거가 아니다.
따라서 기능 검증에서는 전달된 정보의 의미를, 구조 검증에서는 비동기 경로의 형태를, 구현 검증에서는 동기화 단계와 물리 제약을 각각 확인해야 한다. 어느 검사도 나머지 검사의 성공을 자동으로 포함하지 않는다.
정확히 두 사이클 뒤라는 기대를 느슨하게 하기
설명용 handshake에서 원천이 request를 바꾸고 payload를 유지한다고 하자. 목적지는 동기화된 request를 보고 데이터를 받는다. 테스트벤치가 request 변경 후 정확히 두 목적지 사이클에 수신해야 한다고 강제하면, 실제 동기화가 한 사이클 더 늦게 관측되는 상황을 정상 지연이 아닌 오류로 처리할 수 있다.
반대로 테스트 모델이 언제나 같은 두 사이클로 전달하면, DUT가 payload를 너무 일찍 덮어쓰는 오류가 가려질 수 있다. 가상의 예에서 원천은 25ns에 payload를 바꾸고 목적지 샘플링은 항상 20ns에 일어나도록 모델링했다면 테스트는 맞는다. 그러나 관측이 30ns로 늦어질 수 있는 프로토콜에서는 유지 계약을 어긴다.
기능 모델에 불확실한 관측 지연을 넣을 때는 임의의 거짓 거래를 만드는 것이 아니라, 실제 전달 구조가 허용하는 지연과 순서를 표현해야 한다. request와 payload의 관계, 확인까지의 유지, 새로운 요청 간격을 함께 적용한다. 무엇을 가정하고 무엇을 검사하는지 섞지 않는 것이 중요하다.
환경의 친절함이 버그를 숨길 때
원천이 busy 동안 새 요청을 보내지 않는다는 조건은 환경의 합법적인 사용 규칙일 수 있다. 그렇다면 그 조건을 문서화하고 상위 블록이 지키는지 검사해야 한다. CDC 내부 테스트에서 조건을 가정해 놓고 시스템에서도 저절로 지켜진다고 믿으면 증명이 끊어진다.
payload를 확인까지 유지하는 조건 역시 누가 지키는지 명확히 해야 한다. CDC 모듈이 수락 에지에 payload를 내부 저장한다면 외부는 수락 뒤 바꿀 수 있다. 내부 저장이 없는 구조라면 외부의 유지 책임이 더 길다. 두 구조를 같은 테스트 가정으로 쓰면 정상 사용을 금지하거나 실제 위반을 허용할 수 있다.
PULP의 2-phase CDC는 원천 데이터 저장과 요청·확인의 관계뿐 아니라 reset 지원 조건도 공개한다. 정상 handshake의 입력 규칙과 warm reset 비지원 조건을 따로 확인할 수 있는 사례다. 테스트 환경도 모듈이 실제로 지원하는 기능 범위에 맞아야 한다.
reset과 멈춘 클록을 정상 클록 실험에 섞지 않기
클록 주파수 두 개를 고르는 테스트만으로 한쪽 정지와 재시작을 검증했다고 말할 수 없다. 모든 거래가 결국 확인된다는 요구에는 상대 클록이 계속 진행한다는 조건이 숨어 있을 수 있다. 상대가 영원히 멈추면 확인을 기다리는 것은 정상적인 안전 동작일 수도 있다.
reset은 더 강한 상태 변화다. 한쪽의 request나 포인터가 초기값으로 돌아가면 동기화 지연 모델만으로는 그 의미를 표현하기 어렵다. 운용 중 reset을 지원하는 모듈이라면 격리·clear 순서를 검사해야 하고, 지원하지 않는 모듈이라면 그 사용이 시스템에서 발생하지 않는다는 근거가 필요하다.
지연이 다양하다는 이유로 데이터 버스를 비트마다 임의로 뒤섞는 모델도 조심해야 한다. 그것이 실제 구조에서 가능한 혼합인지, 안정된 bundled-data의 보장 조건을 깨뜨린 환경인지 구분해야 한다. 비현실적인 모델이 만든 실패를 고치다 보면 정상적인 계약을 흐릴 수 있다.
거래 단위의 검사가 남겨야 하는 것
검사기의 중심은 수락된 거래가 정확히 어떤 결과로 끝나는지다. 정상 전달에서는 유실·중복·순서 위반이 없어야 하고, 취소를 지원한다면 취소된 거래가 나중에 다시 나타나지 않아야 한다. stall된 출력 데이터의 유지와 source 수락 조건도 관측 대상이다.
여기에 짧은 펄스, 경계 위상, 빠른 원천과 느린 목적지, reset 사건을 지원 범위에 맞춰 배치한다. 구조 분석에서 발견한 경로와 구현 제약의 대상이 실제 테스트의 신호와 일치하는지 확인한다. 가정만 많은 테스트가 아니라, 각 가정의 책임자가 드러나는 테스트가 필요하다.
처음의 성공한 파형은 기능 계약을 확인하는 유용한 증거다. 다만 실제 셀의 실패 확률까지 보여 준 것은 아니다. CDC 검증 가정의 역할은 성공의 범위를 줄여 말하는 데 그치지 않고, 남은 조건을 구조·환경·구현의 검사에 정확히 연결하는 데 있다. 그 연결이 있으면 시뮬레이션 통과가 무엇을 의미하는지 분명해진다.