임베디드 시스템 검증을 위한 C 테스트 사례 자동화

SoC(System-on-Chip) 설계가 점점 더 복잡해짐에 따라 시스템 수준 검증을 위한 수천 줄의 코드가 포함된 테스트 스위트는 계속 손으로 작성되고 있습니다. 언제든지 가능할 때." 이는 제조 전에 전체 장치를 검증하기 위해 SoC의 임베디드 프로세서에서 실행되는 C 테스트에 특히 해당됩니다.

가능한 경우 검증 테스트 구성을 자동화하면 SoC 개발의 여러 단계에서 생산성이 향상되는 것으로 나타났습니다. 예를 들어 UVM(Universal Verification Methodology) 테스트벤치에서 Constrained Random 기술은 특정 시나리오를 대상으로 하는 무작위 테스트 벡터를 사용하여 적용 범위를 늘립니다. 이것들이 하드웨어 블록 수준에서 검증 효율성을 높인 반면, 설계는 여전히 자극, 검사 및 커버리지 코드가 별도로 작성된 블랙박스로 인식되며 여전히 큰 블록의 경우 번거롭고 오류가 발생하기 쉬운 작업입니다.

종종 에뮬레이터나 프로토타입 시스템에서 실행되는 I/O 트랜잭션과 프로세서 테스트 코드를 결합해야 할 필요가 있기 때문에 이 방법론을 시스템 수준으로 확장하는 것은 어렵습니다. SoC를 적절하게 검증하려면 프로세서 자체를 실행해야 합니다. UVM 및 기타 제한된 무작위 접근 방식은 프로세서에서 실행되는 코드를 고려하지 않습니다. 사실, SoC에서 UVM을 사용하기 위해 프로세서는 종종 제거되고 SoC 버스의 가상 입력 및 출력으로 교체되어 하위 시스템에서 프로세서를 뺀 것을 확인할 수 있습니다.

SoC 검증 엔지니어는 제한된 무작위 테스트벤치의 한계를 인식하고 SoC 설계를 완전히 실행하는 데 제한이 있음에도 시뮬레이션 및 하드웨어 에뮬레이션 모두를 위해 프로세서에서 실행하기 위해 C 테스트를 손으로 작성하도록 합니다. 이러한 검증 플랫폼의 성능은 전체 운영 체제(OS)를 실행하기에 충분하지 않으므로 이러한 테스트는 구성 노력에 상당한 오버헤드를 추가하는 "베어메탈"을 실행합니다. 특히 OS 서비스의 도움 없이 필기 테스트가 다중 스레드를 활용하는 다중 코어 프로세서에서 조정된 방식으로 실행되는 것은 드문 일입니다. 그 결과 동시 작업 및 일관성과 같은 SoC 동작의 측면이 최소한으로 확인됩니다.

C 테스트 자동 생성

물론 자동으로 생성된 C 테스트는 엔지니어링 리소스를 보다 효율적으로 사용할 수 있습니다. 그들은 또한 적용 범위를 증가시킵니다. 생성된 C 테스트 케이스는 필기 테스트보다 SoC의 기능을 더 많이 실행할 수 있으며 상상하기 힘든 복잡한 코너 케이스를 찾습니다. 다중 스레드, 다중 프로세서 테스트 케이스는 동시성을 검증하기 위해 설계 내의 모든 병렬 경로를 실행할 수 있습니다. 메모리 세그먼트 간에 데이터를 이동하여 일관성 알고리즘을 강조하고 데이터를 칩의 입력으로 보내거나 출력에서 ​​읽어야 할 때 I/O 트랜잭션과 조정할 수 있습니다. 이것의 전반적인 효과는 시스템 기능 범위를 증가시키는 것입니다. 일반적으로 특징적으로 훨씬 낮은 수치에서 90% 이상입니다.

Test Suite Synthesis로 알려진 테스트 생성 소프트웨어는 의도한 설계 동작을 캡처하는 이해하기 쉬운 그래프 기반 시나리오 모델을 사용합니다. 이러한 모델은 기본 C++를 사용하여 Accellera Portable Stimulus Standard를 사용하여 작성하거나 시각적으로 설명할 수 있습니다. 시나리오 모델은 설계 사양의 일부를 설명하기 위해 화이트보드에 그릴 수 있는 기존 칩 데이터 흐름 다이어그램과 유사하기 때문에 설계 또는 검증 엔지니어가 SoC 개발의 자연스러운 일부로 생성합니다.

이러한 모델에는 기본적으로 자극, 검사, 적용 범위 세부 정보 및 디버그 정보가 포함되어 있으며 설계의 모든 측면을 강조하는 고품질 자체 검사 C 테스트 사례를 생성하는 데 필요한 모든 것을 생성기에 제공합니다. 계층적이고 모듈식이기 때문에 블록 수준에서 개발된 모든 테스트는 전체 SoC 모델의 일부로 완전히 재사용될 수 있으며 다른 팀과 프로젝트 간에 쉽게 공유할 수 있습니다. 마지막으로, 단일 의도 모델은 합성 도구에 의해 분해되어 스레드와 I/O 포트 전체에 동시 테스트를 제공하고 모두 함께 동기화될 수 있습니다.

테스트 스위트 합성의 장점

테스트 스위트 합성의 중요한 이점 중 하나는 의도 모델에서 커버리지 목표를 미리 정의할 수 있다는 것입니다. 의도가 지정되면 도구에서 이를 분석하여 생성할 수 있는 테스트의 수와 달성할 기능적 의도의 범위를 이해할 수 있습니다.

SoC의 경우 수천 개의 테스트를 수행할 수 있습니다. 그런 다음 테스트할 의도를 제한하고 도구를 핵심 영역에 집중하여 적용 범위 목표를 설정할 수 있습니다. 이 기능은 테스트를 설정하고, 검증 도구를 실행하고, 달성된 범위를 이해하고, 테스트를 계속해서 재설정하는 기존 접근 방식에서 발생하는 고통스러운 반복 루프를 저장합니다.

잘 알려진 반도체 회사에서 개발한 대규모 SoC에 대한 한 일반적인 프로젝트에서 검증 엔지니어는 테스트 구성 시간을 이전에 필기 테스트에 필요한 시간의 20%로 줄였습니다. 자동화 기술은 보다 엄격한 테스트 사례를 생성하여 적용 범위를 84%에서 97%로 늘렸습니다. 또한 모델은 휴대가 가능합니다.

단일 모델은 가상 플랫폼, 레지스터 전송 레벨(RTL) 시뮬레이션, 에뮬레이션, FPGA(Field Programmable Gate Array) 프로토타입 또는 실리콘 후 검증을 진행 중인 실험실의 실제 칩에 대한 테스트 사례를 생성할 수 있습니다.

디버그는 특히 SoC 수준에서 엔지니어를 위한 또 다른 시간 싱크입니다. 테스트 케이스가 숨어 있는 디자인 버그를 발견하면 검증 엔지니어는 어떤 테스트가 버그를 유발했는지 이해하여 소스를 추적해야 합니다. 테스트 케이스 실패는 시나리오 모델의 실수로 인해 발생할 수 있으므로 테스트 케이스를 설계 의도가 캡처된 그래프와 다시 연관시키는 것이 가능해야 합니다. 이 프로세스는 발견된 버그에 대해 실행된 테스트를 쉽게 볼 수 있도록 쉽게 분해되는 고도로 모듈화된 자체 포함 테스트를 생성합니다.

애플리케이션 시나리오

합성된 테스트 사례는 설계에 대해 응용 프로그램 시나리오라고 하는 실제 사용 사례를 실행할 수 있습니다. 예를 들어, 그림 1에 표시된 디지털 카메라 SoC를 고려하십시오.

더 큰 이미지를 보려면 클릭하세요.

그림 1:이미지 처리 SoC 예. (출처:브레이커 검증 시스템)

SoC 블록 수준 구성 요소에는 두 개의 프로세서, 즉 주변 장치와 메모리가 포함됩니다. SoC에 대한 간단한 그래프가 블록 다이어그램 아래에 나와 있습니다. 그래프에는 SoC 검증 프로세스에서 실행될 수 있는 가능한 높은 수준의 경로가 포함되어 있습니다. 예를 들어, 그래프의 상단 경로에 표시된 한 가지 가능한 시나리오는 SD 카드에서 JPEG 이미지를 읽고 메모리의 할당된 영역을 통해 사진 프로세서에 전달합니다. 이미지는 메모리의 두 번째 블록에 표시되고 로드될 수 있는 형식으로 처리됩니다. 거기에서 디스플레이 컨트롤러로 전달됩니다. 물론 이러한 상위 수준 블록 각각은 프로세스의 일부로 실행되는 많은 작업과 결정과 함께 본질적으로 계층적입니다.

합성 도구는 무작위 테스트를 수행하고 적절하게 일정을 잡습니다. 가장 간단한 형태의 테스트는 그림과 같이 단일 스레드로 스케줄링하고 다음 테스트 등이 뒤따를 수 있습니다. 그러나 SoC에 스트레스를 주는 테스트 케이스의 능력은 다중 스레드와 다중 프로세서에 걸쳐 애플리케이션을 인터리빙하는 데서 비롯됩니다. 이 도구는 설계 고유의 동시성이 지원하는 만큼 많은 응용 프로그램을 병렬로 실행하여 가능한 한 구불구불한 방식으로 메모리를 할당합니다. 이것은 또한 테스트가 3개의 스레드에 걸쳐 분산되어 SoC 메모리에 할당된 다양한 영역을 사용하는 그림에서 대안으로 표시됩니다.

물론 이 예제는 프로세스를 명확하게 하기 위해 높은 수준에서 제공됩니다. 실제로 계층적 그래프는 합성 도구에 의해 병합되어 많은 수의 작업과 연결이 생성됩니다. 여기에는 솔버 알고리즘을 통해 실행해야 하는 무작위 결정도 포함됩니다. 그래프가 진행됨에 따라 AI 계획 알고리즘이 사용되어 원하는 출력을 검사하고 이에 맞게 입력 테스트를 최적화합니다. 합성 도구에는 메모리를 할당하고, 주소 맵 액세스를 제공하고, 인터럽트를 처리하고, 테스트 구조를 완료하는 데 필요한 기타 작업을 제공하는 OS와 유사한 서비스가 포함됩니다. 그런 다음 테스트는 적절하게 할당된 저장소 및 기타 리소스와 함께 무작위로 예약됩니다.

결론

제한된 무작위 테스트벤치가 블록 검증을 위한 수동 작업을 제거한 것과 마찬가지로 임베디드 프로세서 기반 SoC에 대한 합성 테스트 콘텐츠는 시스템 수준 검증 노력을 줄이는 것으로 입증되었습니다. 또한 이 솔루션은 현재 블록 수준 및 실리콘 후 검증에 적용되고 있습니다. 이 예에서 자동화된 C 테스트 사례는 "가능한 경우 자동화"라는 격언을 적용하여 확인 일정을 단축하는 동시에 커버리지를 크게 향상시킵니다.