[SystemVerilog] 1.2 검증 프로세스

1.2.1 검증의 목표

검증의 목표를 단순히 "버그를 찾는 것"이라고 생각할 수도 있지만, 이는 부분적으로만 맞는 이야기이다. 하드웨어 설계의 주요 목표는 DVD 플레이어, 네트워크 라우터, 레이더 신호 프로세서와 같은 특정 기능을 수행하는 장치를 만드는 것이다. 이는 설계 사양을 기반으로 이루어진다. 검증 엔지니어의 역할은 장치가 해당 작업을 성공적으로 수행할 수 있는지 확인하는 것이다. 즉, 설계가 사양을 정확하게 반영하는지 검증하는 것이다.

버그는 설계와 기대하는 동작 간의 불일치로 인해 발생한다. 하지만, 장치가 원래 의도된 목적이 아닌 환경에서 어떻게 동작하는지는 검증 엔지니어의 책임이 아니다. 다만, 이러한 한계를 알고 있는 것이 중요하다.

1.2.2 검증 과정

검증 과정은 설계 과정과 병행하여 이루어진다. 설계자는 특정 블록의 하드웨어 사양을 읽고, 이를 해석한 후, 기계가 읽을 수 있는 형태(보통 RTL 코드)로 변환한다. 이를 위해서는 입력 형식, 변환 기능, 출력 형식을 이해해야 한다. 하지만, 원본 문서의 애매한 표현, 누락된 정보, 또는 모순된 설명으로 인해 이 해석에는 항상 모호성이 존재할 수 있다.

검증 엔지니어는 이러한 사양을 읽고, 검증 계획을 수립하며, 이후 RTL 코드가 해당 기능을 올바르게 구현하고 있는지 확인하는 테스트를 작성해야 한다.

동일한 사양을 여러 명의 엔지니어가 해석하면 설계 과정에서 중복성이 추가된다. 검증 엔지니어의 역할은 동일한 하드웨어 사양을 읽고, 독립적으로 의미를 분석하며, 이를 검증하는 것이다. 테스트는 RTL 코드가 해당 해석과 일치하는지 검증하는 방식으로 이루어진다.

1.2.3 설계의 각 단계에서 발생하는 버그

설계에서 발생할 수 있는 버그의 유형은 다양하며, 일반적으로 다음과 같은 단계에서 나타난다.

1. 블록 레벨에서의 버그
   • 개별 모듈 내에서 발견되는 가장 쉬운 버그이다.
   • 예를 들어, ALU(산술 논리 연산 장치)가 숫자를 올바르게 더하는지, 버스 트랜잭션이 정상적으로 완료되었는지 등을 검사한다.
   • 네트워크 스위치에서 패킷이 특정 경로를 제대로 통과했는지 확인하는 것도 이에 해당한다.
   • 블록 레벨에서는 특정 테스트를 작성하여 버그를 쉽게 찾을 수 있지만, 이들 버그는 해당 블록 내에서만 존재하는 경우가 많다.
2. 블록 간 인터페이스에서의 버그
   • 두 명 이상의 설계자가 동일한 사양을 읽고 서로 다른 방식으로 해석할 경우, 블록 간 인터페이스에서 불일치가 발생할 가능성이 높다.
   • 예를 들어, 특정 프로토콜에서 신호가 언제 변경되는지에 대한 해석이 다를 수 있다.
   • 한 설계자는 버스 드라이버를 한 방식으로 구현하고, 다른 설계자는 리시버를 다른 방식으로 구현할 수 있다.
   • 검증 엔지니어는 이러한 불일치 영역을 찾아 논리적인 해결책을 모색해야 한다.
3. 저수준 블록의 시뮬레이션
   • 개별 블록을 시뮬레이션하려면 주변 블록들로부터 입력을 생성해야 한다.
   • 이러한 작업은 어렵지만, 저수준 블록 시뮬레이션은 일반적으로 빠르게 실행된다.
   • 하지만, 블록과 테스트벤치 모두에서 버그가 발생할 가능성이 있으며, 이로 인해 검증 과정이 더욱 복잡해진다.
4. 블록 통합 시 발생하는 문제
   • 블록들이 하나로 통합될 때, 서로를 자극하여 예상치 못한 버그를 유발할 수 있다.
   • 통합된 블록들이 서로 데이터를 주고받는 과정에서 예상치 못한 동작이 발생할 수 있으며, 이는 작업 부하를 증가시킬 수 있다.
   • 여러 블록이 동시에 실행되면, 서로 영향을 미칠 가능성이 있기 때문에 검증 과정에서 이를 고려해야 한다.
5. DUT(설계 대상 장치) 전체 수준에서의 검증
   • 최상위 레벨에서는 DUT 전체를 테스트하게 되는데, 이 단계에서는 성능이 크게 저하될 수 있다.
   • 검증 테스트는 모든 블록이 동시에 동작하도록 하여 현실적인 환경을 시뮬레이션해야 한다.
   • 예를 들어, 모든 I/O 포트가 활성화되고, 프로세서가 데이터를 처리하며, 캐시가 리필되는 등의 상황을 테스트해야 한다.
   • 데이터 정렬 및 타이밍 버그가 발생할 가능성이 크며, 이러한 상황을 고려한 검증이 필요하다.
6. 고급 기능 테스트
   • DUT가 여러 개의 작업을 동시에 실행하도록 하여 더욱 정교한 검증을 수행할 수 있다.
   • 예를 들어, MP3 플레이어가 음악을 재생하는 동시에 사용자가 새로운 음악을 다운로드한다고 가정하자.
   • 다운로드 도중 사용자가 버튼을 여러 번 누를 경우, 장치는 이를 어떻게 처리할 것인가?
   • 이러한 시나리오는 실제 제품이 사용되는 방식과 동일하므로, 검증을 통해 사전 테스트를 수행하는 것이 중요하다.
7. 에러 처리 및 복구 검증
   • DUT가 정상적으로 동작하는지 확인한 후, 오류가 발생하는 경우의 동작을 검증해야 한다.
   • DUT가 부분적으로 전송된 데이터나 손상된 제어 필드를 처리할 수 있는가?
   • 모든 가능한 문제를 나열하는 것은 어렵지만, 시스템이 어떻게 복구되는지를 검증하는 것이 필수적이다.
   • 오류 감지 및 처리 방식은 검증 과정에서 가장 어려운 부분이 될 수 있다.

1.2.4 새로운 검증 기법의 필요성

설계 추상화 수준이 높아질수록, 검증의 복잡도도 증가한다. ATM 라우터 블록을 통해 개별 셀의 흐름을 확인하는 것과 같이 세밀한 분석이 필요할 수도 있다. 또한, 여러 우선순위를 가진 데이터 스트림이 존재하는 경우, 어떤 셀을 우선적으로 처리할 것인지가 명확하지 않을 수도 있다.

마지막으로, 버그가 더 이상 존재하지 않는다는 것을 증명하는 것은 불가능하므로, 끊임없이 새로운 검증 기법을 개발하고 적용해야 한다. 검증 엔지니어는 지속적으로 새로운 방법을 연구하고 적용함으로써 제품의 신뢰성을 높여야 한다.

 

Chris Spear 저자님의

SystemVerilog For Verification

A Guide to Learning the Testbench Language Features

내용을 기본으로 작성되었습니다.