SoC 설계 주기서 설계 자원 70%가 검증에 소비
검증 엔지니어 다수, 커버리지 클로저 달성에 고심
커버리지 클로저 100%, 스티뮬러스 최적화 관건


5G, AI, IoT 등의 발전으로 에지 디바이스가 다양한 역할을 하게 되면서 자연스레 탑재되는 SoC에 대한 요구사항이 늘어나고 있다.

통상적인 SoC 설계 주기에서 설계 자원의 70%가 기능 검증에 소비되는데, 설계가 점점 복잡해짐에 따라 SoC 검증 역시 날이 갈수록 까다로워지고 있다. 만일 검증 과정에서 오류가 발생한다면 앞선 설계 흐름을 다시 반복해야 하므로 설계 시간과 비용이 증가할 수밖에 없다.

효율적인 검증 방법론과 기술들이 필요한 이유다.

윌슨 리서치와 멘토, 지멘스 비즈니스의 2016년 조사에 따르면, 검증 과정에 있어서 많은 검증 엔지니어가 커버리지 클로저(Coverage closure)를 달성하기 위해 충분하고 적절한 테스트 케이스를 만드는 것이 가장 어렵다고 밝혔다.

기존에는 SoC 검증 시 디렉티드 테스트(Directed tests) 방식이 활용되었으나 낮은 생산성을 이유로 컨스트레인트 랜덤 테스트(Constrained-random test) 방식이 도입됐다. 하지만 이 방식은 랜덤 변수, 즉 스티뮬러스(Stimulus)를 무작위로 생성하기 때문에 다양한 환경에 맞는 테스트가 쉽지 않다는 문제가 있다.

이를 보완하기 위해 등장한 것이 PSS(Portable Test and Stimulus)다.

PSS를 통한 테스트 시나리오 모델링은 엔지니어에게 테스트할 대상에 대한 검증 요구사항에 집중할 수 있도록 지원하며, 자동화를 통해 유효한 특정 테스트를 만들 수 있게끔 한다. 그뿐만 아니라 이러한 테스트를 다양한 검증 환경에서 사용할 수 있게 한다.

그렇다면 PSS를 어떤 식으로 활용해야 기존 시스템베릴로그(SystemVerilog)/UVM 검증 환경을 ‘어떻게 검증해야 하나?’에서 ‘무엇을 검증해야 하나?’로 바꿔 구성할 수 있을까? 포터블 스티뮬러스 테스트벤치 자동화 솔루션 ‘퀘스타 인팩트(Questa® inFact)’를 제작한 멘토, 지멘스 비즈니스에서 FAE로 근무하고 있는 박성진 대리에게 이 방안을 물었다.


Q. 칩의 크기가 커지고 복잡도가 증가하면서 검증의 중요성 또한 커지고 있습니다. 많은 엔지니어가 검증에 긴 시간을 투자하고 있고, 특히 커버리지 클로저를 달성하기 위해 노력한다고 알고 있는데요. 커버리지 클로저에 대해 설명해주십시오.
A. 여기서 말하는 커버리지란 검증 커버리지를 의미합니다.

검증 커버리지는 보통 코드 커버리지와 기능 커버리지로 구분합니다. 기능 커버리지는 디자인 스펙에 맞추어 설계물이 기능적인 측면에서 수행해야 하는 모든 동작을 얼마나 수행하였는지에 대해 수치로 나타내는 방법입니다. 커버리지를 통해 검증 엔지니어는 테스트가 어느 정도 진행되었는지 그리고 테스트가 충분히 이뤄졌는지를 판단할 수 있습니다.

따라서 커버리지 클로저는 검증 계획으로 세워진 타깃 커버리지 수치에 도달할 때까지 검증을 진행하는 과정으로서, 커버리지 클로저를 달성했을 때 설계 디자인은 검증이 완료된 것으로 간주합니다. 보통 100%를 목표로 커버리지 클로저를 진행합니다.


Q. 그렇다면 커버리지 클로저를 달성하지 못하거나 커버리지가 낮을 때 발생하는 문제점으로 어떤 것들이 있습니까?
A. 커버리지가 낮다는 것은 검증이 완전히 진행되지 않았다는 뜻입니다. 완성한 설계를 반도체로 만들었을 때 디자인 스펙에 맞게 동작하지 않을 수도 있다는 의미입니다.

따라서 검증 엔지니어가 정의한 커버리지를 완벽히 달성할 수 있어야지만 반도체가 만들어진 후에 발견된 불량에 관한 디자인을 수정하고, 다시 반도체를 만드는 등의 반복작업을 줄일 수 있습니다.

커버리지 100% 달성은 많은 시간과 노력이 필요한 과정이라서 계획된 개발 기간 내에 100% 검증하지 못하고 반도체를 만들고 있는 것이 현실입니다.


Q. 커버리지 클로저 달성 과정이 특별히 어려운 이유가 있다면 무엇입니까?
A. 기능 커버리지는 컨스트레인트 랜덤 테스트로 진행되는데, 이는 코드상에 제약사항을 정의하고 그 범위 안에서 스티뮬러스를 무작위로 생성하여 테스트하는 방식입니다.

랜덤 테스트 특성상 테스트가 진행될수록 커버리지가 올라가지 않는 현상이 발생하고, 이런 경우 엔지니어가 어쩔 수 없이 개입하여 커버하지 못한 타깃 케이스를 고려하여 컨스트레인트를 반복적으로 수정하게 됩니다. 이 경우에도 남은 커버리지를 조금 더 올릴 수 있지만 100% 커버리지를 달성할 수 없습니다. 따라서 남은 타깃의 경우 직접 스티뮬러스를 주입하여 커버리지 클로저를 달성하게 됩니다.

엔지니어들은 이러한 과정을 통해 커버리지를 올리려 하지만, 시간적 혹은 기술적 문제로 100% 커버리지를 달성하지 못하는 경우가 발생합니다. 이 과정에서 만들어지는 많은 스티뮬러스가 중복해서 같은 테스트를 하기도 하여 검증 시간을 불필요하게 늘리기도 합니다.


Q. 커버리지 클로저 달성을 위해 퀘스타 인팩트가 지원하는 것은 어떤 것들이 있습니까?
A. 퀘스타 인팩트에서 제공하는 것은 크게 3가지가 있습니다.

첫 번째로 커버리지 클로저를 빠르게 달성할 수 있도록 스티뮬러스를 최적화하며, 두 번째로는 엔지니어가 작성한 컨스트레인트 랜덤 테스트의 제약사항에 대해 테스트 전에 미리 검증할 수 있는 환경을 제공합니다. 마지막으로 기술된 제약사항을 기반으로 사용자가 목적에 맞게 커버그룹을 자동으로 생성해주는 환경을 제공합니다. 따라서 중복된 테스트를 하지 않고 커버리지 모델을 미리 검증함으로써 전반적으로 커버리지 클로저를 앞당길 수 있는 환경을 제공합니다.


Q. 스티뮬러스란 무엇이고 스티뮬러스를 최적화해야 하는 이유는 무엇입니까?
A. 여기서 말하는 스티뮬러스란 디자인을 테스트하기 위한 벡터값입니다. 컨스트레인트 랜덤 테스트의 경우 랜덤 변수들의 값이 스티뮬러스라고 생각하시면 됩니다. 테스트를 진행하다 보면 시뮬레이터가 가지고 있는 컨스트레인트 랜덤 솔버를 통해 정의된 제약사항을 해석하여 랜덤값을 생성하게 되는데 이때 커버리지 타겟을 벗어난 스티뮬러스를 생성하기도 하고, 중복된 스티뮬러스를 생성하게 됩니다.

퀘스타 인팩트의 경우 생성한 스티뮬러스는 최적화가 되고, 중복되지 않은 스티뮬러스와 커버리지 타깃에 맞는 스티뮬러스를 먼저 제공합니다.


Q. 새롭게 대두되는 PSS(Portable Test and Stimulus)란 무엇입니까?
A. PSS는 아셀레라(Accellera)에서 내놓은 표준으로서, 다양한 검증 플랫폼의 테스트 목적을 기술할 수 있는 표준화된 입력 언어입니다. 블록 레벨에서부터 SoC 레벨까지, 그리고 시뮬레이션 플랫폼에서부터 에뮬레이션까지 이 모든 플랫폼과 디자인 사이즈를 하나의 테스트 의도를 가지고 테스트를 할 수 있는 환경입니다.

여기서 퀘스타 인팩트는 PSS 모델링 된 테스트 의도를 기존 환경에 쉽고 빠르게 적용하여 사용할 수 있도록 지원하고 있습니다.


Q. 타 솔루션 대비 퀘스타 인팩트의 강점은 어떤 것들이 있습니까?
A. 퀘스타 인팩트는 기존 UVM 환경, 그리고 시스템 베릴로그 테스트 환경을 재활용할 수 있습니다. 이미 기술된 제약사항과 커버그룹을 그대로 가져와서 PSS 모델링이나 추가로 인팩트 룰을 추가로 작성하지 않고 바로 적용하여 사용할 수 있습니다.

그뿐만 아니라 앞서 말씀드린 것과 같이 제약사항을 시뮬레이션 전에 미리 분석하고, 커버그룹을 자동으로 생성해주는 기능 또한 큰 차이점이라고 말씀드리고 싶습니다.


Q. 어떤 엔지니어에게 퀘스타 인팩트가 필요하다고 생각하십니까?
A. 대부분의 검증 엔지니어들이 커버리지 클로저를 달성하기 위해 많은 고통과 어려움을 느끼고 있다고 들었습니다. 가장 큰 이유는 컨스트레인트를 지속적으로 수정해야 하고 반복적인 테스트를 진행함에 따라 시간과 노력이 많이 소요되기 때문입니다.

커버리지 클로저를 조금 더 빨리 달성하고 싶은 분들이나 컨스트레인트를 조절하는 데 어려움을 겪으시는 분들, 컨스트레인트를 시뮬레이션 전에 미리 검증하고 싶으신 분들에게 퀘스타 인펙트가 큰 도움이 될 것입니다.