[UVM] UVM 검증방법론의 개념과 구조

안녕하세요. 현업에서 가장 많이 사용되는 반도체 Chip의 (Dynamic)검증 방법론인 UVM에 대해서 글을 작성하도록 하겠습니다. 저는 국내 대기업 S사에서 반도체 검증에 대해서 짧게나마 배운 이력이 있습니다. 당시 이 사이트https://www.chipverify.com/tutorials/uvm를 많이 참고했으며, 앞으로 글을 작성할 때도 많이 참고할 예정입니다.

UVM이란 무엇인가?

UVM(Universal Verification Methodology)은 반도체 칩 설계 검증을 위해 사용되는 표준화된 검증 방법론입니다. UVM은 시스템 설계 및 검증 언어인 SystemVerilog를 기반으로 하며, 복잡한 반도체 설계를 효과적으로 검증하기 위해 검증 환경을 구축하고 관리하는 데 사용됩니다.    -GPT-

 

GPT가 알려준 기본적인 개념이며, 이게 맞습니다. 현재 UVM은 반도체 산업에서 설계 검증을 위한 사실상의 표준이 되었으며, 칩 설계자와 검증 엔지니어들이 설계의 정확성과 기능을 검증하는 데 널리 사용되고 있습니다.

---

그렇다면 왜 UVM이라는 방법론을 사용할까요?

우리가 처음 Verilog에 대해 배우며 내가 짠 코드가 잘 작동하는지 '검증'하기 위해 Input값에 하나하나 값을 입력해주는 testbench를 작성하게 됩니다. 하지만 실제로 칩에 들어가는 Input으로는 많은 경우의 수가 존재합니다.

예를 들어, a+b=c인 8비트 adder의 Input 값 조합으로는, 216의 경우의 수가 존재합니다. 우리는 이것을 하나하나 타이핑할 수 없습니다. 그리고 constraint한 범위 내에서 random한 a와 b로 검증하기 어렵습니다. 일반적인 Verilog로 구현된 testbench의 단점은 아래와 같습니다.

• 많은 양의 코드 line 기술
• Randomize를 위한 복잡한 메카니즘 필요
• 사람마다 다른 코드 구성 (테스트벤치 재활용성에 있어서 매우 안좋습니다.)
• 베릴로그 자체가 static한 언어기 때문에 Test Case의 reuse가 안좋습니다.

이렇듯, 베릴로그로 구현한 testbench는 칩이 복잡해짐에 따라 단점이 많습니다.

하지만 UVM이라는 방법론을 사용하면 이러한 문제점을 해결할 수 있습니다.

• UVM은 일반적인 Verilog가 아니라 SystemVerilog로 구현합니다. Class 기반의 객체지향언어(OOP)인 SystemVerilog의 강력한 문법스킬(randomize, interface 등)과 동적인 객체의 생성으로 효율적인 검증환경 구성이 가능합니다.
• 표준화된 구성 요소(Driver, Monitor 등)를 사용하여 유지보수와 재활용성이 좋습니다. 또한 모든 개발자들이 사용하는 표준 방법론이 생겼다는 것은, 협업할 때도 큰 장점입니다.
• Coverage check, 경고 문구 출력 등 강력한 검증 도구가 있습니다.

기회가 된다면 SystemVerilog에 대해서도 글을 작성해보겠습니다.

---

UVM의 구조는 어떻게 이루어져 있을까요?

허접하지만 UVM구조를 그려보았는데요. 실제 검증을 한다고 생각하고 AMBA BUS개념을 포함해서 그려보았습니다. 각 구성 요소가 어떤 의미이고 어떤 역할을 하는지 용어 설명을 통해 알려드리겠습니다.

 

UVM의 구성 요소

• hdl: Hardware Description Language
• hvl: Hardware Verification Language
• DUT(Design Under Test): 검증하고자 하는 코드
• Sequence(stimulus generator): DUT의 기능을 test하기 위한 Transaction들을 병합하고 정의하는 곳.
• Transaction(item): 주고받는 데이터의 단위(=Driver 의 전송 Packet 단위). 이를 기반으로 DUT에 제공하는 입력들을 stimulus라고도 합니다. Variable, constraint, method를 포함하고 있어 이들 자체를 실행시킬 수 있습니다.
• Sequencer: Sequence로부터 trasaction을 받아서 driver로 건네주는 곳. (Sequence와 Driver간의 중개업자)
• Driver: Sequencer에서 transaction을 가져와서 DUT의 input으로 보내주는 곳.
• Interface: 말 그대로 DUT와 Driver간의 interface를 선언해주는 곳. SystemVerilog의 interface문법을 사용합니다.
• Monitor: DUT와 driver 간의 통신 내용을 확인하고 input, output값들을 낚아채는 곳.
  여기서 통신 내용이란 DUT로 들어가는 input값과 DUT를 빠져나온 output값을 말합니다. 이 값들을 모니터링하는 component입니다.
• Agent: Sequencer, driver, monitor을 create하고 연결합니다. 반드시 1개가 아니여도 됩니다.
• Scoreboard: Monitor로부터 온 값들을 기반으로 예측 값과 실제 결과를 비교, 검증하는 곳
• Env: DUT의 검증에 필요한 모든 Verification Component들을 모아 놓은 hierarchical component. 하위 구성 요소들을 create하고 연결합니다.
• Test: UVM testbench의 가장 상위의 UVM component. 하위 block들을 컨트롤.
• Top: DUT, TB, Virtual interface를 인스턴스화 하고 이들을 연결해주는 역할을 수행.
• SVA: SystemVerilog Assertion으로 실제 검증 환경에서 protocol값들이 타이밍맞게 잘 전달되는지.. 등을 check하기 위해 사용됩니다. UVM의 구성 요소는 아니지만 검증 환경에서 같이 사용되기 때문에 적어봤습니다. (개념 추후 추가 예정)

동작 원리를 간단하게 이야기 하자면, 검증할 때 필요한 Sequence를 Sequencer를 통해 Driver로 전달되며 Driver는 interface를 통해 DUT에 값을 전달해줍니다. Monitor는 driver가 제공하는 input값과 DUT로 부터 나온 output을 모두 모니터링하며 모니터링한 값을 가지고 Scoreboard에 값을 전달하며 Scoreboard에서 옳고 그름을 판단하게 됩니다.

 

오늘은 UVM의 기본 개념과 구성요소를 정말 간단하게만 알아보았습니다. UVM의 특성에 대한 자세한 내용과 각각의 구성요소들의 구체적인 작동 원리, 예제 코드는 다음에 작성해보도록 하겠습니다.

지적 감사히 받겠습니다. 댓글 부탁드립니다~~

 

https://velog.io/@onething818/UVM-UVM%EC%9D%98-%EA%B8%B0%EB%B3%B8-%EA%B0%9C%EB%85%90-%EA%B5%AC%EC%A1%B0

[UVM] UVM 검증방법론의 개념과 구조

제가 운영하는 벨로그입니다. 많은 관심 부탁드립니다.