검증 작업은 SoC 설계만큼이나 디지털 IP 설계에서 차지하는 비중이 크다. 목표는 소요시간을 최소화하면서 RTL코드 및 기능 커버리지(functional coverage) 모두를 100% 검증하는 것이다.
널리 사용되는 방법은 RTL 코드에 무게를 두고 기능 커버리지의 트랙을 유지하면서 비교적 단시간에 복잡한 테스트 구성을 허용하는 범용 검증 방법론(Universal Verification Methodology, UVM)의 제한적 무작위 테스트(System Verilog나 e Language 중 하나)에 기반하고 있다.
일부 검증 엔지니어들은 표준 인터페이스와 같은 블록 전용 부분을 검증하기 위해 정형 방법론(Formal methodology)을 활용하기도 하며 이를 통해 IP검증을 완성한다.
이 글은 속성들(properties)의 정의를 통해 기능들을 철저히 검증하는 정형 방법론에 기반을 둔 디지털 IP 검증의 다양한 접근방법을 설명한다. 정형 기법은 테스트 벤치 개발을 하지 않아도 되는 이점이 있다. 이 새로운 절차는 디지털 IP 설계시 사용돼 왔으며 검증 시간을 상당히 단축시켰다.
일반적인 검증 절차
현재 디지털 IP 및 시스템 온 칩(System on Chip, SoC)의 검증을 위해 가장 보편적으로 사용되는 절차는 비표준 프로토콜이 사용될 경우 서드 파티(third party)로부터 제공받거나 새롭게 개발된 검증 컴포넌트(Verification Components, VC)를 통한 UVM에 기반한다.
테스트 벤치는 자체 데이터 확인을 위한 스코어보드(scoreboards), 설계의 특정 부분을 검증하기 위한 어서션(assertion), 기능 커버리지들을 추적하기 위한 커버리지들(covers)로 완성된다.
최근 몇 년 사이 정형 검증은 SoC와 IP의 검증 절차에 적용되기 시작했다.
SoC에서는 SoC 주변장치(peripheral)들과 패드(pad) 사이의 연결성 검증에 상당히 일반화되고 있는데 특히 주변장치 몇 개와 개수가 줄어든 패드로 머싱 스킴(muxing scheme)을 구성할 때와 같이 검증이 필요한 조합이 늘어날 때에 해당한다. IP검증에서는 정형 방법론이 버스 프로토콜 인터페이스와 레지스터 액세스 정책을 확인하기 위해 가끔씩 사용된다.
디지털IP의 검증를 집중적으로 요약한다면 그 절차를 [그림 1]과 같이 나타낼 수 있다. RTL의 첫 번째 버전이 준비되면 유효한 검증 절차의 제1단계는 검증 정의와 테스트 플랜으로 시작한다. 이 단계에서는 확인하고자 하는 기능과 테스트의 구조를 정의 내린다.
다음 단계는 UVM 테스트 벤치를 개발하는 것이다. 맞춤형 UVM블록은 특정 IP기능의 검증용으로 내장된다. 반면 서드 파티 UVM VC는 RTL에 인스턴스화 되거나 바인딩 된다.
그 다음 검증 계획에 따라 UVM테스트를 개발할 수 있다. 모든 검증 엔지니어가 명심해야 할 것은 테스트 자체 확인을 반드시 해야 한다는 것이다. 검증 계획에 포함된 모든 포인트를 스코어보드, 체커(checker), 어서션을 사용해 자동으로 확인해야 한다. 그러면 커버리지 구조를 광범위하게 사용해서 이 테스트가 얼마나 양호한지 정량화 할 수 있다.
때로는 이 절차에 정형 검증을 포함할 수 있으며 작업 중 어떤 지점에서 IP의 특정 블록을 확인할 수도 있다.
예를 들어 어서션 기반 검증 IP(Assertion-Based Verification IP, ABVIP)를 사용해 버스 프로토콜 인터페이스를 확인하거나 어서션 작성에 의한 유한상태기계(Finite State Machine, FSM)로 구현된 정확한 기능을 확인할 수 있다. 알다시피 검증 작업은 ▲RTL 버그 수정 ▲기능 및 코드 커버리지 등 2가지 루프백을 가진 반복적인 프로세스다.
기능 스펙과 IP동작 사이가 불일치하면 설계자에게 버그일 가능성을 신호로 보낸다. 이는 RTL을 수정해 새로 수정된 버전을 내보낼 필요가 있음을 의미한다. 이제 (초기에 부분적일지라도) 회귀 자가 점검 테스트(regressive self-checking tests)를 하는 것이 핵심이다. 이는 RTL코드가 회귀하지 않았는지 확인할 수 있게 한다. 물론 버그가 수정됐다는 것도 확인할 수 있다. 이 루프백은 정형 검증에서도 진행된다.
테스트가 충분하게 진행되면 기능과 코드 커버리지 측정에도 좋다. 일반적으로 기능과 코드에 대한 목표치는 모두 100%이지만 도달하는데 걸리는 소요시간도 고려해야 한다. 만약 100%의 목표를 유지하면서 시간을 최소화하려 한다면 검증을 위한 방법론과 절차를 개선해야 한다.
정형 검증에서 유래한 좋은 제안 중 하나는 코드 도달 불가능성 분석(code unreachability analysis)인데 이것은 도달할 수 없고 전체 코드 커버리지 수에서 제거할 수 있는 RTL 부분을 찾을 수 있도록 도와준다.
여기에 한 가지 좋은 경험법칙이 있다. 코드에서 실행하지 않은 한 부분이 있다면 버그가 거기에 있을 가능성이 제일 높다. 따라서 코드의 노툴을 자극하기 위해 상당한 시간을 들이는데, 미리 도달할 수 없는 코드라는 것을 안다면 시간과 노력을 줄일 수 있는 것이다.
이제 목표하는 커버리지는 유지하면서 디지털 IP 검증에 소요되는 시간을 단축하는 새로운 절차를 설명하겠다.
새로운 검증 절차
철저한 검증 방법인 정형 기법은 더 짧은 시간 내에 모든 조건에서의 블록 기능을 검토할 수 있다. 일반적인 동적 시뮬레이션으로는 이것이 어려울 때가 있다.
최근에는 정형 엔진과 연결돼 [그림1]의 검증절차를 [그림2]와 같이 변경할 수 있는 툴도 판매되고 있다. 가장 큰 변경 사항은 정형 검증을 전체 절차의 첫 번째 단계로 소개를 한 것이다.
실질적인 초기 검사는 데드 코드(dead code)와 초기화되지 않은 레지스터의 분석이다. 이는 별도의 코드가 필요 없기 때문에 전혀 품이 들지 않는 일로 필요한 것은 정형 툴로 RTL을 컴파일 하는 작업뿐이다. 때문에 노력이 필요 없는 작업이며 단지 정형 툴로 RTL의 컴파일만을 필요로 한다.
뒤 이은 피드백도 유용하다. 닿지 않는 부분까지 강조해 RTL 코드의 총청소(gross-clean)를 할 수 있고 불명확한 전달(X propagation)의 원인이 되는 초기화되지 않은 플립플롭(Flip-Flops) 목록을 만들 수도 있다.
마이크로프로세서 버스 인터페이스와 같은 표준 프로토콜은 전용 어서션 기반 VIP(ABVIP)를 사용해 단기간에 검증을 완벽하게 끝낼 수 있다. 정형 절차를 위한 이런 검증 부품들은 프로토콜을 기술한 어서션을 기반으로 한다. 검증 엔지니어는 테스트 벤치와 속성 개발에 시간을 낭비하지 않고 잘못된 속성(properties)의 디버깅에 초점을 맞출 수 있다. UVM 절차를 사용하면 수 주가 아닌 수 일 내로 완벽히 검증된 인터페이스를 확보할 수 있는 것이다.
IP의 특정 블록의 경우 맞춤형 속성들을 작성하는 방식으로 구현 기능들의 유효성을 검사할 수 있다. UVM 스코어보드와 동일한 컨셉으로 잘 알려진 정형 스코어보드를 도입하는 옵션도 생각해 볼 수 있지만 정형 엔진의 힘을 이용한다. 이는 FIFO 검증에 사용될 수 있으며 일반적으로 데이터 경로 플로우에서 작동하지만 연산 데이터 플로우(예컨대 가산기, 승산기)가 아닌 모든 블록에 사용된다.
최근 주요 EDA회사들은 ‘앱(APP)’이라는 기술 유행어를 붙인 정형 절차 기반 툴을 제공한다. 컨셉은 특정 기능의 디버깅을 위한 ‘사용이 편리한(ready to use)’ 환경을 제공한다는 것이다. 이 앱들은 자동으로 어서션을 생성하고 검증 엔지니어가 RTL디버깅에 집중할 수 있도록 돕는다.
가장 유용한 앱 중 하나는 구성 레지스터들의 액세스 정책 검증을 위한 것이다. 정형 절차를 통해 모든 레지스터를 철저히 검증할 수 있는데 특히 보통 HW 상태 또는 특별한 입력 조건에 의존해 검증이 까다로운 상태 비트(status bits)를 철저히 검증할 수 있다.
일반적으로 이 절차는 IPXACT 에 기반하며 다른 단계의 설계 개발에서 재사용할 수 있다. 더불어 이런 종류의 검증은 ‘고전적’ UVM 제한적 무작위 기법과 관련해 많은 시간을 절약할 수 있다.
사용 가능한 앱의 수는 급속히 증가하고 있으며 이를 통해 커버리지를 개선하고 검증 시간을 단축할 수 있어 검증 업무를 ‘동적’에서 ‘정적’인 업무로 바꿀 수 있다. 물론 정형 절차도 한계가 있어서 최근에는 모든 것을 검증하도록 쓸 수 없다. 분석된 상태(state)의 수(정형 복잡도 지수, 정규적인 복잡도 지수)가 너무 클 때 엔진들은 철저하게 코드를 수용하고 분석할 수 없다.
이는 새로운 알고리즘 도입과 연산 능력을 통해 가까운 미래에 극복해야 할 과제다. 결국 정형 절차가 동적 시뮬레이션을 능가할 것이라고 주장할 수 없는 단순한 이유는 다음과 같다.
‘assume’ 스테이트먼트를 사용하는 것은 숨겨진 버그의 위험성이 있고 만일 속성이 성공하면 assume 조건이 실제 애플리케이션에서 충족되지 않을 경우에 RTL 동작이 잘못된 것이라고 할 수도 있다.
이것은 전체적으로 정적 타이밍 분석(Static Timing Analysis, STA) 및 게이트 레벨 시뮬레이션과 유사하다. 만약 타이밍 제약이 잘못되면 STA는 타이밍 위반이 설계 내에 없다고 하지만 이 설계는 결국 어떤 코너 케이스(corner case)에서 작동하지 않는다. 동적 시뮬레이션은 STA 제약뿐 아니라 정형 ‘assume’ 스테이트먼트의 유효성도 확인할 수 있다.
검증 절차의 다음 단계로는 정형 단계들에 성공하고 또한 현재 동적 시뮬레이션에서 재사용되는 속성 어서션(property assertion)에 의해 부스팅된 UVM시뮬레이션을 진행해야 한다. 이러한 절차로 개발된 테스트의 수는 [그림 1]에 나타낸 절차를 이용해 개발된 것보다 더 적을 것이다.
왜냐하면 우리가 그것으로 분석된 부분에 대해서는 제한된 테스트를 개발하고 정형 절차에 의해 노출된 부분에 집중할 수 있기 때문이다. [그림2]에 나타낸 절차의 최종 단계는 기본적으로 동일하다. 우리는 도달할 수 없는 코드를 제거하기 위해 도달 불가능성 분석을 실행하고 나서 코드 및 기능 커버리지를 분석한다.
결론
절차의 제1단계로서 정형 검증 기법의 사용은 정형(the Formal)의 이점과 유효성을 더 잘 활용하는 차별화된 방법론을 보여준다. 테스트 벤치를 구축하고 철저히 RTL을 검증하는 데는 시간이 소요되지 않기 때문이다.
또 이 방법을 사용하기 위한 학습 속도(learning curve)는 UVM보다 더 빠르다. 어서션 작성에 사용되는 언어(PSL이나SVA중 하나)는 콤팩트하고 사용하기 쉽다. 가장 어려운 작업은 우리가 증명하고자 하는 기능을 가장 잘 기술한 정확한 속성들을 인간의 언어로 정의하는 것이다. 그 다음 SVA나 PSL로의 번역은 쉬운 일이다.
RTL검증의 초기 단계에서 정형 방법론을 사용하는 가장 큰 이점은 많은 기능들이 이미 철저히 검증되고 일부 버그는 수정된 보다 깨끗한 코드로 동적 시뮬레이션에 착수할 수 있다는 것이다. 정형 방법론으로 기능 검증에 소요되는 시간을 단축할 수 있기 때문에 전체적인 검증 시간을 대폭 절감할 수 있다.
우리는 설정 및 데이터 교환을 위한 AMBA인터페이스와 함께 IP의 검증을 위해 이 새로운 절차를 사용했고 결과적으로 RTL 코드를 검증하기 위해 소요되는 시간이 30% 이상 감소됨을 경험했다.
데이비드 빈센조니(David Vincenzoni) ST마이크로일렉트로닉스 R&D 설계 매니저
자료제공 : ST마이크로일렉트로닉스(www.st.com)
그래도 삭제하시겠습니까?