포터블 스티뮬러스의 적용 초점 선택
상태바
포터블 스티뮬러스의 적용 초점 선택
  • 이건한 기자
  • 승인 2019.11.29 09:00
  • 댓글 0
이 기사를 공유합니다

Selecting a Portable Stimulus Application Focal Point

설계, 그 중에도 특히 시스템온칩(System on Chip, SoC)의 설계가 더욱 복잡해짐에 따라, 검증 스펙트럼 전반에 걸쳐 양호한 스티뮬러스를 자동생성 해야 할 필요성이 커지고 있다. 오늘날, 검증 환경의 재활용성과 자동화된 스티뮬러스의 필요성은 블록에서의 서브 시스템, 그리고 SoC 레벨 검증에 이르기까지 명백하게 드러나고 있다. 

악셀라(Acccellera)의 포터블 테스트 앤 시뮬러스 스탠더드(Portable Test and Stimulus Standard, PSS) 언어는 [그림1]에서처럼, 테스트 시나리오를 검증 단계(블록, 서브 시스템, SoC) 전반과 실행 환경(시뮬레이션, 에뮬레이션, 프로토타입) 전반에 걸쳐 재사용 가능한 방식으로 캡처할 수 있도록 지원한다. 

사진=게티이미지뱅크
사진=게티이미지뱅크

물론 이처럼 넓은 범위를 포함하는 언어라면 매우 다양한 응용 분야와 사용 모델을 지원해야 한다. 다만, 특정한 경우 PSS가 어떻게 적용되는지 분류하기 복잡해지는 경우도 발생한다. 그리고 애플리케이션의 중심이 되는 재사용 유형에 따라 포터블 스티뮬러스의 적용 분류를 결정하는 것은 상당히 유용하다. 개인적으로 이런 유형의 재사용을 ‘재사용의 축’이라고 부르고 있다. 

수직적 재사용: 블록 레벨에서 서브 시스템 레벨과 SoC 레벨의 검증까지 테스트 계획을 재사용하는 것

수평적 재사용: 동일한 설계의 파생 디자인 또는 상당한 유사성을 지닌 설계 전반에 걸쳐 테스트 계획을 재사용하는 것

기술적 재사용: 자동화된 양질의 스티뮬러스가 없는 상태에서 포터블 스티뮬러스가 제공하는 자동화 스티뮬러스 기법을 재사용하는 것

상기 축에 따른 재사용은 재사용 축을 가능케 하기 위해 수행돼야 하는 선행 작업과, 이를 통해 달성되는 이득이라는 측면에서 상이한 특성을 갖는다. 이제 이 글의 나머지 부분 전반에 걸쳐 각각의 재사용 축에 대해 보다 상세히 설명할 것인데, 이는 PS를 처음으로 시범 운용해보는 독자와 독자가 속한 조직이 선택하기에 적합한 재사용 축을 한결 정확하게 찾을 수 있도록 돕고, 나아가 PSS의 사용 확대를 권장하기 위함이다.

[그림1]
[그림1]

수직적 재사용

수직적 재사용은 사람들이 포터블 스티뮬러스에 대해 생각할 때 종종 떠올리는 것으로, 테스트 계획을 블록에서 시스템에 이르기까지 재사용하는 것이다. [그림2]의 로직은 아마도 예상한 대로일 것이다. IP 블록 검증 과정에서 개발된 테스트 계획은 해당 IP가 사용되는 서브 시스템을 검증할 때 재사용된 뒤, 독자적으로 재사용되거나 또는 SoC 레벨에서 서브 시스템 레벨의 테스트와 함께 재사용된다.

[그림2]
[그림2]

포터블 스티뮬러스는 선언적 스펙(Declarative specification)으로서, 주로 제약사항이 기반임을 의미한다. 제약사항 기반 기술은 규칙의 구현보다는 기술 내용이 작동할 때 따르게 되는 규칙을 캡처한다. 포터블 스티뮬러스는 원본 소스 코드를 수정하지 않고도 기술된 내용이 작동할 때 따르는 규칙을 쉽게 맞춤화할 수 있도록 도우며, 테스트 동작을 사용자가 손쉽게 정의할 수 있도록 지원한다.

 

IP 블록 레벨

DMA IP의 경우를 예로 들어보자. 블록 레벨에서는 [그림3]과 같은 UVM 테스트벤치 환경을 이용해 작동 여부를 검증한다.

[그림3]
[그림3]

UVM은 트랜잭션 중심의 검증을 수행할 수 있도록 도와준다. 따라서, 예컨대 단일 DMA 채널에서 DMA 전송을 기술하는 UVM 시퀀스 항목과 일련의 DMA 전송 트랜잭션으로 DMA 엔진을 작동시키는 UVM 시퀀스를 생성할 수 있다는 말이다. PSS는 검증 테스트 의도를 시나리오 레벨까지 이동할 수 있도록 도와준다. 또 PSS를 이용해 블록이 수행할 수 있는 주요 작업과 이런 작업을 수행해야 하는 방법에 대한 규칙을 특성화한다.

이 글에서 다루는 DMA 엔진의 경우, DMA가 실행할 수 있는 주요 작업 3가지를 기술할 수 있을 것이다. [그림 4]에서 보듯, 메모리 대 메모리 전송, 메모리 대 주변 장치 전송, 주변 장치 대 메모리 전송이 바로 그것이다. PSS에서는 각각의 작업을 기술하기 위한 새로운 PSS 액션을 생성한다. 이런 각각의 액션에, 해당 작업에 필요한 데이터(있을 경우)와 해당 액션이 생성하는 데이터(있을 경우)를 특성화한다.

[그림4]
[그림4]

메모리 대 메모리 전송 액션을 위해서는 소스 데이터의 위치를 알아야 한다. 이것은 액션에 대한 입력(dat_i)으로서 모델링 된다. 메모리 대 메모리 전송 액션은 데이터를 목적한 위치로 전송한다. 이것은 출력(dat_o)으로 모델링해 다른 액션이 이 정보를 입력할 수 있도록 한다. PSS는 액션 입력과 액션의 실행 방식, 그리고 이를 정상적인 하나의 시나리오로 결합하는 방법을 모델링할 수 있도록 돕는 것 외에도 많은 기능을 제공한다.

PSS가 제공하는 시나리오 레벨의 모델링은 특히 블록 레벨에서 유용하다. 예를 들어, 각각의 DMA 액션은 전용 DMA 채널을 액세스해야 하는데, 각 채널에서는 한 번에 하나의 데이터 전송만 실행될 수 있기 때문이다.

[코드1]
[코드1]

고유의 DMA 채널에 의해 무작위로 선택된 네 개의 채널에서 네 개의 병렬 전송을 실행하는 시나리오를 작성하는 일은 [코드1]의 코드에서 볼 수 있듯이 간단하다. 메모리 대 메모리 전송 액션에 대한 배열을 선언하고, 각 액션이 사용하는 채널이 고유한 것이 되도록 제약사항을 추가한 뒤, ‘병렬’ 블록 내의 4가지 액션을 모두 실행함으로써 모든 전송이 동시에 실행되도록 한다.

이처럼 보다 높은 추상화 수준에서 테스트 의도를 모델링 할 수 있는 기능을 통해 사용자는 보다 생산적이 되며, 블록 레벨에서도 좀 더 복잡한 테스트를 작성할 수 있다. 액션과 시나리오 규칙을 이용한 테스트 인텐트(Intent) 모델링이 갖는 재사용의 이점은 서브 시스템 수준에서 한층 더 명백해진다.

 

서브 시스템 레벨

PSS IP를 SoC 레벨에서 재사용하는 예를 알아보기 위해 이번에는 서브 시스템 레벨을 살펴보자. [그림5]의 서브 시스템에는 이전 섹션에서 살펴본 DMA 엔진뿐만 아니라 UART도 포함돼 있다. 여기서 목표는 IP의 테스트 인텐트를 SoC에 재사용하는 것이므로, UART에 대해 수행할 수 있는 구성과 송수신 작업을 기술하기 위한 PSS 액션을 작성해야 한다.

[그림5]
[그림5]

블록 레벨에서 생성된 테스트 인텐트를 재사용함으로써 서브 시스템 레벨 테스트 시나리오를 생성해 IP가 서브 시스템에 올바르게 통합되도록 할 수 있다. 물론, 각 IP를 위한 PSS 테스트 인텐트는 특정 서브 시스템을 염두에 두고 생성되지는 않았다. 따라서 이를 서브 시스템 레벨에서 재사용하려면 약간의 커스터마이징이 필요하다. 다행히도, PSS를 통해 기존의 액션, 구성요소, 데이터 구조를 확장하면 원래의 코드를 실제로 수정하지 않고도 새로운 제약사항을 추가할 수 있다.

[코드2]
[코드2]

[코드2]는 DMA 액션의 작동을 커스터마이즈함으로써 이 서브 시스템에 사용될 수 있도록 하는 방법을 보여준다. 메모리 대 메모리 전송 액션에는 특정한 커스터마이징이 필요 없다. 메모리 주소만 올바르게 구성하면 어떤 시스템에서도 작동하기 때문이다.

하지만 장치 대 메모리 전송과 메모리 대 장치 전송 액션의 경우는 다르다. 해당 액션은 DMA 상의 핸드셰이크 인터페이스 중 하나에 연결된 특정 IP와 함께 작동해야 한다. 블록 레벨 테스트벤치를 통해 어떠한 DMA 채널이라도 핸드셰이크-전송 모드를 사용할 수 있지만, 서브 시스템은 핸드셰이크 인터페이스 중 두 개만 사용하며, 이들을 UART IP에 연결시킨다.

[코드2]는 mem2dev와 dev2mem 액션을 커스터마이즈해 이들이 UART에서만 작동하도록 만든다. UART의 수신-핸드셰이크 신호는 DMA의 채널 0에 연결되므로, dev2mem 액션이 채널 0에서만 작동하고 항상 UART의 주소를 전송에 사용하도록 확장한다. 마찬가지로, mem2dev 액션이 채널 1과 UART 주소만을 전송에 사용하도록 커스터마이징한다.

이처럼 약간의 커스터마이징을 통해 서브 시스템의 각 IP에 대해 개발된 PSS 액션을 이용하면 서브 시스템 내에서 상호작용을 실행할 수 있는 시나리오를 신속하게 작성할 수 있다.

[그림6]의 그래프는 서브 시스템 내부 IP에 대한 PSS 액션을 이용해 생성할 수 있는 간단한 시나리오를 보여준다. 목표는 시스템 내에서 정상적인 동작을 하도록 만드는 것이므로, 우리의 시나리오는 UART에서의 전송 작업, UART에서의 수신 작업 또는 DMA 전송 작업 중 하나를 실행하는 것이다. 여기서 분명한 점은, 사용 가능한 액션들로부터 시나리오를 몇 가지 더 구축할 수 있다는 것이며, 이 경우의 이점은 시나리오 기술이 간결해지고 IP 팀이 이미 수행한 모델링 작업을 충분히 이용하게 된다는 것이다.

[그림6]
[그림6]

SoC 레벨

SoC 레벨에 도달하면, [그림7]과 같이 검증한 서브 시스템이 프로세서 서브 시스템과 결합된다. 검증 관점에서의 커다란 변화 중 하나는 이 테스트가 이제는 디자인 내장 프로세서에 대한 C 테스트로 실행된다는 것이다.

[그림7]
[그림7]

이런 큰 변화 외에도, 전체 시스템에 대한 메모리 맵과 같이 보다 작은 다른 변화들도 이뤄진다. 블록 레벨과 서브 시스템 레벨에서 본 것과 같은 유연성, 그리고 구성 가능성이라는 PSS의 이점 덕분에 PSS 콘텐츠를 SoC 환경에서 사용할 수 있도록 손쉽게 커스터마이징 할 수 있다.

[코드3]
[코드3]

먼저, 지금까지 만든 액션을 적절한 테스트 실현(구현) 코드에 연결하는 문제부터 다뤄 보자. [코드3]은 UART 액션 두 개와 이 액션들에 의해 기술되는 동작을 구현하는 C 코드 API 간의 매핑을 정의한다.

DMA 액션을 추가적인 제약사항으로 확장해 서브 시스템에서 사용할 수 있도록 커스터마이즈 한 것처럼, UART 액션을 확장하는 방식으로 SystemVerilog 코드를 대신할 동작을 구현하려면 C API를 사용해야 한다고 정의할 수 있다. 이런 C 유틸리티 기능과 PSS 테스트-실현 매핑은 IP 팀이 제공하는 것 중 일부이므로, 우리는 단지 적합한 파일을 선택해 컴파일 하기만 하면 된다.

많은 경우, 서브 시스템 레벨에서 개발한 시나리오는 아주 최소한의 변경으로도 재사용할 수 있으며, SoC 레벨에서 검증 값을 제공할 것이다. 이는 서브 시스템 레벨에서와 마찬가지로 SoC 레벨에서의 핵심 검증 과제 중 하나는 통합된 IP들 간의 상호작용을 수행하는 것이기 때문이다.

 

PSS의 수직적 재사용에 따른 이점과 비용

IP에서 SoC까지의 이런 PSS 재사용 과정 전반에 걸쳐 몇 가지 이점을 볼 수 있었다. 블록 레벨에서는 PSS로 인해 시나리오 작성에 보다 상위 수준의 모델링을 사용할 수 있는 이점을 누렸다. 서브 시스템과 SoC에서는 각각 IP 팀과 서브 시스템 팀이 작성한 PSS 콘텐츠를 재사용해 시나리오를 보다 신속하게 작성할 수 있었다. SoC 레벨에서는 특히 SoC 브링업 테스트를 신속하게 생성할 수 있는데, 이 테스트는 UVM 중심의 검증 환경에서 이미 검증된 시나리오를 이용한다.

하지만 장점만 있는 것은 아니고 비용과 단점도 있다. 재사용 가능한 검증이라는 비전을 실현하는 데 있어서의 주요한 장애물은 전체 IP 공급자들로부터 재사용 할 수 있는 PSS 테스트 인텐트를 만들어내도록 하는 일이다. 설령 같은 회사의 IP 팀이라 해도 서브 시스템과 SoC 팀에서 주로 사용할 PSS를 개발해달라고 설득하기란 쉬운 일이 아니다.

외부의 IP 공급업체가 PSS 테스트 인텐트를 제공하도록 설득하고, 경우에 따라서는 되돌아가서 이미 있는 IP를 위한 PSS를 개발하도록 설득하기는 한층 더 어렵다. 요컨대, PSS의 수직적 재사용은 확실히 이점도 많지만 비용도 높은 재사용 축이다.

 

▲ 수평적 재사용

오늘날의 수많은 설계와 검증 프로젝트는 사실상 기존 설계의 파생 설계다. SoC 파생 설계의 경우, 하드웨어를 추가해 시간이 많이 소요되는 일부 프로세싱을 가속할 수 있다. 또는 그 대신 전용 하드웨어 가속기 일부를 제거하는 방법으로 기능이 축소된 저가형 버전을 만들 수도 있다. 요컨대, [그림8]에서 보듯이 설계의 대부분은 그대로 유지된 것이다.

[그림8]
[그림8]

물론 파생된 SoC 디자인 전체를 검증해야 하며, 이전 버전과 다른 점만 검증해서는 안 된다. SoC 통합을 설계 내의 임베디드 프로세서에서 실행되는 일련의 directed C 테스트로 검증할 경우에는 이들이 새로운 기능을 제대로 수행하는지 확인하기 위해 다수의 테스트를 수작업으로 검증하고 업데이트 해야 한다.

기능이 제거된 경우에는 더 이상 존재하지 않는 기능이 작동되지 않도록 테스트를 변경해야 한다. 또 기능이 추가되면 새로운 기능을 이용해야 하는 시나리오에 대한 테스트를 업데이트해야 한다. 이 모든 작업에는 상당한 시간이 소요되며, 각 SoC에 대한 테스트 항목들은 이전 버전의 테스트 항목에서 파생됐음에도 불구하고 저마다의 테스트 항목을 갖게 되는 것이다.

반면 이와 대조적으로, PSS 모델을 커스터마이즈해 테스트 기능을 추가하거나 제거하는 일은 간단하다. 선언적인 규격으로서 새로운 규칙들(제약사항 형태의)은 단순히 PSS 모델에 계층화해 테스트중인 기능을 맞춤화할 수 있기 때문이다.

[그림9]
[그림9]

[그림9]에서 블록 다이어그램에 표시된 디자인을 살펴보자. 이 디자인에는 두 개의 DMA 엔진이 있다. 하나는 주변 서브 시스템에 있고, 다른 하나는 SoC 레벨에 있다. 주변 서브 시스템 DMA는 그대로 두고 시스템 레벨 DMA는 제거하는 파생 디자인을 작성한다면 어떻게 될까? 검증 테스트 항목이 수작업으로 작성한 directed 테스트일 경우에는 시스템 레벨의 DMA 엔진으로 어떠한 동작도 시도하지 않도록 각 테스트(또는 상당량의 세트)를 점검해야 한다.

[코드4]
[코드4]

PSS를 사용하면 테스트 항목의 세트를 훨씬 더 간단하게 커스터마이즈 할 수 있다. [코드4]는 원래의 SoC에서 DMA 엔진이 서브 시스템과 시스템 DMA 엔진 모두에서 작동하도록 하기 위해 사용됐다. [코드5]는 PSS 모델이 주변기기 서브 시스템 DMA에서만 작동하도록 제한하기 위해 커스터마이징 된 제약사항이다.

[코드5]
[코드5]

PSS 모델이 새로운 디자인에 적합하게 맞춤화되고 나면, 단지 새로운 디자인에 적합한 테스트 항목을 생성하기만 하면 된다. 이를 통해 테스트 항목의 검사와 수정에 소요되는 시간은 물론, Fail이 발생한 테스트 디버깅에 드는 시간도 크게 절감할 수 있다.

 

수평적 재사용에 따른 이점과 비용

수평적 재사용은 수직적 재사용에 비해 포터블 스티뮬러스를 보다 선별적으로 적용한다. 검증 대상 디자인의 핵심 요소들을 실행해 보기 위해서는 PSS 모델을 작성해야 하지만, 업체에서 SoC를 개발하기 위해 사용하는 모든 IP에 대해 PSS 기술 내용을 갖출 필요는 없다. 

물론 PSS 모델은 설계 IP를 어떻게 동작 시키는지 명시할 필요가 있으므로, IP 동작을 위해 PSS 모델을 개발하는 것은 여전히 상당한 비용이 들 수 있다. 요구 사항에 대한 범위가 (프로젝트 그룹에 구속된) 수직적 재사용보다 훨씬 작기 때문에, 수평적 재사용의 구현을 위한 실행 계획은 수직적 재사용의 구현을 위한 것보다 상당히 단순하다.

수평적 재사용이 제공하는 전반적인 이점은 수직적 재사용의 경우보다 적지만, 프로젝트 변경 전반에 걸친 시간 절약이라는 이점은 상당히 크다. 시작 비용도 수직적 재사용의 경우보다 현저히 낮은 편이다.

 

▲기술적 재사용

오늘날 거의 모든 테스트 환경은 고품질의 자동화된 스티뮬러스를 필요로 한다. High Level Synthesis를 위한 C++ 디자인, Verilog 또는 VHDL 블록을 또는 SoC검증이든 상관없이 코너 케이스(Corner case)를 찾아내고 테스트 자동화를 이용해 이에 대한 검증을 수행하는 과정은 극히 중요하다.

중요한 도전 과제는 대부분의 테스트 환경이 기본적으로 자동화된 스티뮬러스 생성 기능을 제공하지 않는다는 것이다. SystemVerilog는 Constraint Random 생성 기능과 Functional 커버리지를 언어의 일부로서 제공한다. 결과적으로, SystemVerilog와 UVM을 사용하는 검증 엔지니어는 자동화된 스티뮬러스 생성 기능을 손쉽게 이용할 수 있다. 

C++나 임베디드 C에서 작업하는 사용자는 사용할 수 있는 Constraint Solver가 없으므로, 테스트 생성의 자동화는 Directed 테스트나 환경에 특정된 솔루션으로 제한된다. PSS는 여러 언어와 환경에 걸쳐 작동하는 테스트를 자동 생성할 수 있는 모델을 기술하는 방법을 제공한다. 이를 통해 사용자는 PSS 언어에 대한 지식을 활용하고, 다양한 커스텀 솔루션을 이용해 작업하는 대신 PSS를 처리하는 툴을 이용할 수 있다.

[그림10]
[그림10]

기술적 재사용에 따른 비용과 이점

기술적 재사용은 이 글의 기술된 기법 중 시작 비용이 가장 적다. 일차적인 비용은 PSS 모델이 설계를 동작시키기 위해 기존의 유틸리티 코드에 어떻게 연결될 것인지를 결정하는 것이다. 따라서 기존 코드 중 일부를 PSS에서 좀더 쉽게 호출할 수 있도록 재구성해야 한다. 이 작업은 사실상 코드를 좀 더 모듈화 하기 위해 재구성하는 것으로서, 단지 괜찮은 소프트웨어 엔지니어링일 뿐이다.

기술적 재사용은 시작 비용이 가장 적게 드는 대신 전반적인 이점도 가장 적지만, 그 이점은 상당히 중요할 수 있다. 가령 기술적 재사용을 수평적 재사용과 결합하지 않을 경우, 생성되는 테스트는 특정 프로젝트에만 고정되고 만다. 물론 이런 테스트를 상이한 실행 플랫폼 전반에 걸쳐 재사용할 수는 있다.

 

결론, 재사용 축의 선택

PSS를 운용할 생각이라면, 재사용 축을 포터블 스티뮬러스 애플리케이션의 초점을 파악하기 위한 방법으로 사용할 것을 권장한다. 많은 애플리케이션이 2개 이상의 재사용 축의 측면을 포함하고 있겠지만, 대부분의 애플리케이션은 하나의 재사용 축에 일차적으로 초점을 맞출 것이다. 초점의 선택은 필요한 자원을 파악하고 필요로 하는 것과 조직 내에 이미 있는 것 간의 간극을 파악하는 데 도움이 된다. 

마지막으로, 포터블 스티뮬러스 적용을 위한 초기 초점을 선택하는 것은 향후의 포터블 스티뮬러스 적용 확대를 배제하는 것은 아니다. 오히려 PSS의 초기 이용이 가장 성공적으로 수행되도록 함으로써 PSS의 적용 확대 가능성을 더욱 높여준다. 
 

글 | 매튜 밸런스(Matthew Ballance) / 멘토, 지멘스 비즈니스

- 이 글은 테크월드가 발행하는 월간 <EMBEDDED> 2019년 11월호에 게재된 기사입니다.