[테크월드=이나리 기자]
포터블 스티뮬러스란?
지난 수년간 설계 검증의 생산성과 결과품질(QoR)을 개선하기 위해 많은 노력이 투입됐다. 대부분의 노력은 블록 레벨에서 적용하기에 가장 좋은 기법들에 집중됐고, 제한적 무작위 트랜잭션 생성, 기능 커버리지, UVM 등이 검증 품질과 생산성을 극적으로 향상시켜왔다. 하지만 이런 기법들이 블록 레벨에서는 성공적이었을지 몰라도 서브시스템과 SoC 레벨에서의 검증은 갈수록 더 힘들어지면서 새로운 접근방법이 요구되고 있다.
최근 검증의 생산성과 효율성을 개선시키기 위한 상용 툴과 자체 툴의 개발이 활발하다. 상용 툴의 한 예로, 멘토그래픽스(이하, 멘토)의 퀘스타 인팩트(Questa inFact)는 추상화 수준을 높이고(생산성 향상) 테스트 생성 효율성을 증대시키면서 매우 다양한 검증 환경 전반에 적용할 수 있다.
또 트랜잭션 지향적인 블록 레벨 이외의 환경에 자동화된 테스트 구현에 관심이 증가하면서 이런 테스트들을 명시하기 위한 표준화된 입력 명세 언어 확보가 주목된다. 이런 추세에 따라 아셀레라(Accellera)는 PSWG(Portable Stimulus Working Group)라는 워킹 그룹을 출범했다. 이 워킹 그룹은 필수 요건을 수집하고, 기술 기여를 유도하며, 다양한 검증 플랫폼의 테스트 목적의 명시에 이용할 수 있는 표준화된 입력 언어를 지정하고 있다.
멘토는 PSWG의 활동에 참여하면서 이를 추진해왔으며, 그 기술과 전문지식으로 표준화 프로세스에 기여하고 있다.
포터블 스티뮬러스의 목표는 [그림 1]에서 보여주는 바와 같이 테스트를 단일하게 서술하는 것이다(포터블 스티뮬러스 서술). 이 같은 단일 서술은 IP, 서브시스템, SoC 등의 레벨 검증을 대상으로 하며, 테스트 목적을 해당 검증 유형에 사용되는 검증 엔진에 적합한 방식으로 구현할 수 있다.
포터블 스티뮬러스 서술은 반드시 모든 서술이 단일한 추상화 수준을 갖도록 하거나 모든 테스트 목적이 하나의 제한된 방식으로 수행되도록 강요하지 않는다. 일례로, 현재 PSWG에서 개발 중인 포터블 스티뮬러스 사양에는 여러 요소들이 있는데, 사용자는 자신들의 테스트 목적을 검증 작업에 가장 자연스러운 방식으로 서술할 수 있는 유연성을 갖는다. 여기서 주의해야 할 점은, PSWG에서 포터블로 구현하는 것이 고도의 자동화 테스트 작성이라는 것이다.
포터블 스티뮬러스는 단순히 모든 검증 엔진 전반에 걸쳐 손쉽게 지원할 수 있는 ‘최소 공통 분모’ 기법의 모음이 아니다. 게다가 아세렐라 PSS(Portable Stimulus Specification)는 C/C++나 시스템베리로그(SystemVerilog)와 같은 기존의 절차적 언어를 대체하기 위한 것이 아니다. 이런 기존 언어에서는 코드의 재사용이 극히 중요하기 때문에, 아세렐라 PSS는 다양한 언어들로 서술된 행위를 재사용하기 위한 메커니즘을 제공한다.
포터블 스티뮬러스의 기본
포터블 스티뮬러스가 추구하는 것은 사용자들이 추상화 수준을 넘어 서브시스템 레벨 검증과 SoC 레벨 검증에서 나타나는 복잡한 시나리오의 테스트를 자동화할 수 있도록 하는 것이다. 그러나 아세렐라 PSWG가 개발 중인 PSS는 제약사항 기반의 트랜잭션 레벨 검증을 기반으로 하고 있는데, 이 검증 방식은 오늘날 이미 잘 알려졌고, 널리 구축돼 있다.
이 외에도 아세렐라 PSS는 사용자가 복잡한 SoC 레벨의 시나리오를 생산적으로 캡처해 효율적으로 실현할 수 있는 기능을 제공한다. 따라서 아세렐라 PSS는 무작위 또는 비 무작위 데이터 필드와 구조, 익숙한 시스템베리로그(SystemVerilog) 제약사항, 그리고 객체 지향 언어를 통해 익숙해져 있는 상속 패턴을 지원한다.
시스템베리로그에서의 시나리오 작성은 제약조건을 갖는 무작위 생성(Constrained-random generation)을 절차적 코드와 혼용함으로써 수행된다. 이는 시나리오를 재사용하고 원본 코드의 변경 없이 맞춤화 할 수 있는 능력을 제한한다. 또 아세렐라 PSS는 행위의 원시 요소뿐만 아니라 복잡한 행위를 손쉽게 재사용하거나 맞춤화할 수 있는 방식으로 동작(Action)을 제공한다. 복잡한 동작 내에 하위 동작(Sub-action)의 순차적 실행과 병렬 실행뿐 아니라 하위 동작의 반복도 지정할 수 있다. 동작 내의 행위는 선언적 방식으로 지정돼 고도의 자동화와 정적 분석이 가능해진다.
아세렐라 PSS는 동작의 자원 요건을 모델화 하기 위한 전용 구성물과 시나리오 내 동작들 간의 데이터 교환 기능도 제공한다. 이를 통해 사용자는 합법적인 시나리오를 제한하는 규칙을 서술하고, 툴이 이런 규칙을 토대로 복잡하지만 합법적인 시나리오를 자동 생성할 수 있다. 다만 데이터 제약사항에 의해 합법적인 거래 범위가 명시되는데, 이를 통해 제약사항 솔버(Constraint solver)가 수많은 합법적 거래의 생성을 자동화할 수 있다.
블록 레벨의 포터블 스티뮬러스
포터블 스티뮬러스를 블록 레벨의 검증 환경에서 적용할 경우 여러 이점이 따른다. 포터블 스티뮬러스 툴은 선별적인 테스트 생성을 필요로 하는데, 이는 SoC 레벨의 환경을 위한 테스트를 효율적으로 생성해야 하기 때문이다.
블록 레벨 환경에서는 효율적인 테스트 생성을 통해 기능 커버리지 목표가 보다 신속하게 달성되며, 버그도 검증 주기 초반에 발견된다. 예를 들어 멘토의 Questa inFact 사용자들이 일반적으로 알게 되는 사실은, 이 툴이 커버리지 목표를 달성하는 데 있어서 무작위로 생성할 때보다 10~100배 더 효율적이어서 시뮬레이션 자원을 늘리지 않고도 버그를 보다 신속하게 찾아내고 커버리지 범위를 확장할 수 있다는 것이다.
앞에 언급된 예제는 다채널 DMA 엔진이다. 이런 종류의 DMA 엔진에서 메모리 전송 오퍼레이션을 특징 짓는 전송 서술자는 전송 크기, 소스, 목적지 주소, 주소 증분 설정, 전송 세부 옵션을 나타낸다. 우리는 블록 레벨에서 전송 서술자 필드들의 조합을 포괄적으로 이용해 DMA 구현물을 철저하게 검증하고자 한다.
이 IP를 에워싸고 있는 UVM 테스트벤치의 간단한 모습은 [그림 2]와 같다. DMA 엔진은 UVM 시퀀스를 이용해 실행되며, 이 시퀀스를 통해 DMA 엔진 내의 레지스터들을 DMA 서술자 클래스에 따라 프로그램 한다.
SV 제약사항의 재사용
DMA 서술자 클래스에는 유효 DMA 전송을 정의하는 필드와 제약사항들이 들어있다. 이런 기존 서술내용을 포터블 스티뮬러스 서술로부터 이용할 수 있는 능력은 중요하다. 엔지니어는 제약사항을 올바르게 캡처하기 위해 시간을 투자했으며, 환경의 나머지 부분이 이 클래스에 의해 움직이기 때문이다. 다행히도 아세렐라 PSS의 트랜잭션 레벨 부분집합은 상당부분이 시스템베리로그의 제약사항과 중첩되기 때문에 시스템베리로그의 수많은 제약사항 기반 서술 내용을 PSS 서술내용으로 변환할 수 있다.
Questa inFact는 이런 목적을 위한 임포트 툴을 제공한다. [표 1]은 시스템베리로그 class와 PSS struct를 비교해 나타냈다. 시스템베리로그 서술내용을 임포트해 PSS 서술내용 내부에서 사용할 수 있게 하면, 시스템베리로그의 시퀀스 레벨 서술내용을 작성하는데 쏟은 노력을 고스란히 이용할 수 있게 된다. 더불어 PSS를 활용해 시작하기가 보다 쉬워지고, PSS 서술내용이 시스템베리로그 측의 시퀀스 아이템에 대한 어떤 변경사항이 생겨도 동기화 상태를 유지하게 된다.
기본적인 오퍼레이션의 명시
이제는 가장 기본적인 DMA 오퍼레이션인 DMA 전송에 대해 설명해보자. 포터블 스티뮬러스 서술에서 임의의 오퍼레이션의 데이터와 행위는 동작 내에 캡슐화 된다.
[표 2]를 보면, 동작은 컴포넌트(Component) 내에 선언되고, 이런 컴포넌트에는 여러 동작들이 공유하는 자원들이 캡슐화 됐다. 이런 기본적인 블록 레벨의 검증에서는 wb_dma_c 컴포넌트에 어떤 특별한 것도 필요 없다. do_dma 동작은 단지 무작위적인 wb_dma_descriptor struct 필드를 캡처할 뿐이다.
시나리오 설명
테스트의 관점에서 제일 먼저 해야 할 일 중 하나는 단순히 일련의 단일 DMA 전송을 생성하는 것이다. 테스팅 시나리오는 기본적인 오퍼레이션과 마찬가지로 동작 내에 서술한다. 테스트 시나리오 자체가 동작들로 구성돼 있으므로 Activity Graph(키워드: activity)를 추가해 하위 동작들 간의 관계를 명시한다[표 3].
컴포넌트 내에 simple_xfer 동작을 선언하고 있음에 유의하자. 이 컴포넌트는 do_dma 동작을 선언하는 wb_dma_c 컴포넌트의 인스턴스를 포함하고 있다. simple_xfer 동작은 단지 do_dma 동작을 256회 반복 실행할 뿐이다.
2회의 연속(Back-To-Back) DMA 전송을 수행하기 위해 테스트를 약간 확장해야 할 수 있다. 이때의 제약사항은 두 전송에 사용되는 채널이 서로 달라야 한다는 것이다. 이는 DMA 컨트롤러 내부에 보다 흥미로운 활동을 일으키게 된다. 앞에서 동작 인스턴스의 무작위 필드를 어떻게 제한할 수 있는지에 유의하자. 이는 통제된 무작위 시퀀스로 수행하기에는 까다로운 일이다.
환경 인터페이스의 명시
이제까지는 동작이 UVM 테스트벤치 환경에 어떻게 연결될지에 대해 크게 신경 쓰지 않았다. PSS가 제공하는 타입 확장(Type extension) 기능을 이용하면 앞서 설명한 바 있는 동작이나 컴포넌트를 전혀 변경하지 않고도 인터페이스 층을 손쉽게 환경에 구축해 넣을 수 있다[표 4].
UVM 테스트벤치에서 스티뮬러스는 wb_dma_descriptor 시퀀스 아이템을 생성하는 UVM 시퀀스에 의해 구동된다. 우리가 원하는 것은 PSS 서술내용을 UVM 시퀀스 내부에 통합하고 wb_dma_descriptor 시퀀스 아이템을 생성하도록 하는 것이다. 단, 필드 값은 전형적인 시스템베리로그의 제한적 무작위 값을 사용하는 대신에 포터블 스티뮬러스 툴이 선택하는 값들을 사용해야 한다.
PSS 패키지는 환경 세부사항을 캡슐화하기에 훌륭한 방법을 제공하므로, 여기에서는 패키지를 사용해 do_dma 동작이 어떻게 UVM 시퀀스에 통합되는지에 대한 세부사항을 포함시킨다. 일례로, 이 시퀀스가 do_item이라는 태스크를 제공한다고 가정하면, 이 태스크는 wb_dma_descriptor 시퀀스 아이템을 수용해 실행하고, import 명령문은 이런 외부적 방법의 시그니처를 명시한다[그림 5].
그 다음에는 do_dma 동작이 이 임포트된 방법을 어떻게 사용할 것인지 명시해야 한다. PSS가 제공하는 exec 블록은 PSS 엔티티(Entities)와 외부 코드 간의 관계를 명시한다. exec 블록의 body 타입은(UVM 시퀀스의 body 태스크와 마찬가지로) 실행시간 행위(Execution-Time Behavior)를 명시한다. 이 경우에는 do_dma 행동의 실행시간 행위가 wb_dma_descriptor 필드를 do_item 태스크로 넘겨주도록 명시한다.
이것으로 작업은 완료된다. 새로운 PSS 구동 UVM 시퀀스는 이제 UVM 테스트벤치를 구동할 수 있으며, DMA 전송 모드를 훨씬 더 효율적으로 실행할 수 있다는 이점을 갖게 된다.
서브시스템과 SoC 레벨의 포터블 스티뮬러스
서브시스템과 SoC 레벨에서는 검증 대상과 검증 방법이 모두 달라진다. 이제는 DMA 엔진의 구현을 검증하는 데 집중하는 대신에 해당 DMA 엔진이 서브시스템이나 SoC 내의 다른 블록들과 어떻게 통합되는지가 보다 큰 관심사이다. 특히 SoC 레벨에서 또 한 가지 달라진 점은, 임베디드 프로세서가 있으며 이 프로세서에서 실행되는 코드를 가지고 최소한 어느 정도의 테스트를 수행해야 한다는 점이다.
서브시스템 레벨의 환경에서는 [그림 4]와 비슷한 블록도를 갖고 시작할 수 있다.
DMA 엔진은 이제 프로세서(버스 기능 모델로 스텁아웃(Stubbed Out)되는)와 다른 IP를 포함하는 서브시스템의 맥락 내에 포함돼 있다.
PSS 서술내용을 다음의 두 단계를 통해 서브시스템/SoC 환경으로 가져올 수 있다:
① 시나리오 레벨 테스트의 요건을 모델화 한다
② 새로운 환경 통합을 명시한다
앞서 언급했듯이, 이 환경의 목표는 서브시스템 내 다른 IP와의 통합을 검증하는 것이다. 이를 위해 다수의 병렬 DMA 전송을 실행한다. 제일 먼저 할 일은 dma_c 컴포넌트를 확장해 사용할 수 있는 자원들을 명시해야 한다. 예시 경우에는 31개의 DMA 채널이 해당된다. 또한 DMA 채널을 소비하고 그 데이터 흐름 요건을 명시하는 새로운 동작 타입을 생성할 것이다.
업데이트된 DMA 컴포넌트와 동작은 다음 사항들을 명시한다:
• DMA는 31개의 채널 자원을 갖는다(자원 풀 이용)
• 각각의 DMA 오퍼레이션은 소스 메모리 버퍼를 필요로 하며, 목적지 메모리 버퍼를 생성한다.
• 각각의 do_mem2mem_dma 오퍼레이션(do_dma로부터 상속되는)은 DMA 채널을 액세스해야 한다(lock 필드 이용)
• DMA 서술자에 명시된 채널은 DMA 오퍼레이션에 할당된 채널과 동일해야 한다.
• DMA 오퍼레이션에 사용되는 소스와 목적지 주소는 소스, 목적지 메모리 버퍼와 일치해야 한다
세부사항을 약간 더 보강해 aes_c 컴포넌트를 생성함으로써 AES 블록 상의 오퍼레이션을 모델화 한다. do_encrypt 동작에는 메모리 버퍼가 필요하며, 입력 데이터의 주소가 AES 블록의 버퍼 주소가 되도록 강제됐다는 점에 유의하자. membuf_s 입력 상의 제약사항은 쌍방향적이므로, 이 제약사항으로 인해 DMA는 do_mem2mem_dma 동작이 데이터를 do_encrypt 동작으로 보낼 경우 AES 장치를 목표로 할 수 밖에 없게 된다. 또 aes_c 컴포넌트의 자원 풀을 이용함으로써 주어진 시간 동안 AES 블록에서는 오직 단일 오퍼레이션만이 발생할 수 있다는 점을 명시해야 한다.
최종적으로 이 시스템은 가용 자원(DMA과 AES 블록)을 대표하는 컴포넌트로 명시하고 있다. 또한 병렬 DMA 전송을 수행할 최상위 수준 동작도 명시한다. 유의할 점은, 네 개의 병렬 DMA 오퍼레이션을 수행하고자 한다는 사실만 알게 됐다는 것이다. 이것은 부분적인 사양이며, 데이터가 어디에서 오는지 또는 어디로 가야 하는지는 명시하지 않는다. PSS 프로세싱 툴은 적절한 동작들을 추론해 연결함으로써 합법적인 시나리오가 생성되도록 한다. 구체적으로는 다음과 같다:
• 네 개의 병렬 전송 각각이 서로 다른 DMA 채널에 발생한다
• 한 번에 단 하나의 오퍼레이션만이 AES 블록을 대상으로 할 수 있다.
SoC 레벨의 통합
DMA 전송이 여전히 시퀀스에 의해 구동되는 서브시스템 레벨 환경에서는 블록 레벨 환경에서 했던 것과 동일한 스타일의 통합을 UVM 환경에서 재사용할 수 있다. SoC 레벨에서의 테스트는 C 언어로 작성된 유틸리티 기능을 이용해 DMA를 프로그래밍하게 된다. 많은 경우, 이런 유틸리티 기능들이 드라이버 루틴의 시작이 되며 나중에 운영체제(OS) 드라이버 내에서 사용된다. 통합 테스트에서 바로 이러한 유틸리티 루틴들을 호출하면 이 유틸리티 루틴에 대한 자신감을 더욱 높일 수 있을 뿐만 아니라 하드웨어 IP의 통합을 실행할 수도 있다.
블록 레벨 환경에서와 마찬가지로, 코어 PSS 서술내용을 환경 세부사항의 계층까지 확장할 수 있다. 이 경우 호출할 C API(wb_dma_drv_single_xfer)를 서술한다. 또 API를 호출해 DMA 서술자로부터 값을 넘겨주는 do_dma 동작을 위한 exec 블록의 정의를 제공한다.
포터블 스티뮬러스를 이용한 생산성 향상
포터블 스티뮬러스 툴은 테스트 서술 수준을 높이도록 도와주며, 통제된 무작위 테스트와 트랜잭션 레벨의 제한적 무작위 테스트를 통해서는 작성하기가 매우 어려운 시나리오를 모델화 할 수 있도록 해준다. 그 결과, 보다 독특한 테스트를 자동 생성할 수 있게 됐다.
아세렐라 PSS 입력 사양의 특징들을 통해 테스트 목적의 대상을 상이한 환경으로 다시 변경해도 서술 내용의 핵심은 환경에 대해 독립적으로 유지할 수 있다. 또 무작위 필드와 제약사항을 기존의 시스템베리로그 서술내용으로부터 손쉽게 가져올 수 있으며, 표준의 주요 구성요소들을 점진적으로 채택함으로써 손쉽게 시작할 수 있다.
따라서 다음 번에 통제된 무작위 테스트나 제한적 무작위 테스트의 역량을 넘어서는 검증 작업에 직면하게 된다면 포터블 스티뮬러스의 적용을 고려해보자.
글: 매튜 밸런스(Matthew Balance) 멘토 제품 매니저 및 포터블 스티뮬러스 기술 전문가
자료제공: 멘토 지멘스비즈니스
그래도 삭제하시겠습니까?