Универсальная методология верификации ( UVM ) — это стандартизированная методология верификации проектов интегральных схем . UVM в основном происходит от OVM ( Open Verification Methodology ), которая в значительной степени основывалась на eRM ( e Reuse Methodology ) для языка верификации электронных схем , разработанного Verisity Design в 2001 году. Библиотека классов UVM привносит структуру и автоматизацию в язык SystemVerilog, такие как последовательности и функции автоматизации данных (упаковка, копирование, сравнение) и т. д., и в отличие от предыдущих методологий, разработанных независимо поставщиками EDA ( Electronic Design Automation ), является стандартом Accellera с поддержкой нескольких поставщиков: Aldec, Cadence, Mentor Graphics (Siemens), Synopsys, Xilinx Simulator (XSIM).
В декабре 2009 года технический подкомитет Accellera — организации по стандартизации в сфере автоматизации электронного проектирования (EDA) — проголосовал за создание UVM и решил основать этот новый стандарт на Открытой методологии верификации (OVM-2.1.1) [1] — методологии верификации, разработанной совместно в 2007 году компаниями Cadence Design Systems и Mentor Graphics .
21 февраля 2011 года Accellera одобрила версию UVM 1.0. [2] UVM 1.0 включает в себя справочное руководство, справочную реализацию в форме библиотеки базовых классов SystemVerilog и руководство пользователя. [2]
Фабрика — это часто используемая концепция в объектно-ориентированном программировании. Это объект , который используется для создания экземпляров других объектов. Существует два способа регистрации объекта в фабрике UVM. В объявлении класса A можно вызвать макросы регистрации `uvm_object_utils(A) или `uvm_component_utils(A). В противном случае можно использовать макросы `uvm_object_registry(A,B) или `uvm_component_registry(A,B) для сопоставления строки B с типом класса A. [3] Фабрика UVM предоставляет множество методов создания, которые позволяют пользователю создавать экземпляр объекта с определенным именем экземпляра и зарегистрированного типа. [4]
Секвенсор отвечает за три основные функции:
На этом этапе DUT (Device Under Test) и среда испытательного стенда должны быть установлены в желаемые начальные условия. Обычно это включает:
Табло может быть реализовано различными способами. В общем, табло принимает входные данные и выходные данные от DUT, определяет, какими должны быть отношения входных и выходных данных, и судит, соответствует ли DUT спецификации. Эти отношения входных и выходных данных часто определяются моделью, называемой предиктором. [3] Предиктор может быть реализован на языке программирования более высокого уровня, например SystemC.
Классы UVM scoreboard реализованы как подклассы класса uvm_scoreboard, который сам является подклассом uvm_component. uvm_scoreboard — это чистый лист для реализации scoreboard. Он содержит только один метод класса, а именно метод конструктора «new». Остальная часть реализации определяется пользователем. [5]
В современных VLSI DUT может иметь несколько интерфейсов. Каждый из этих интерфейсов может иметь различные объекты UVM, связанные с ними. Например, если DUT является полноценным чипом, могут быть отдельные интерфейсы для PCI, Ethernet и других стандартов связи. Табло и монитор для интерфейса PCI будут отличаться от таковых для интерфейса Ethernet. Различные объекты UVM могут быть организованы как члены класса-оболочки, известного как агент. Пассивные агенты будут анализировать только значения портов интерфейса и должны содержать члена-монитора. Активные агенты будут управлять портами и должны содержать члена-драйвера, возможно, в дополнение к члену-монитору. [6]
Классы агентов UVM реализованы как подклассы класса uvm_agent, который сам является подклассом uvm_component. Подобно uvm_scoreboard, uvm_agent является легковесным с точки зрения методов класса. Его единственными методами класса являются конструктор "new" и метод "get_is_active". Если агент используется для управления портами, get_is_active возвращает UVM_ACTIVE. В противном случае get_is_active возвращает UVM_PASSIVE.
Элементы последовательности для теста описываются абстрактно. Например, если DUT является файлом регистра, он может иметь порты для адреса чтения и адреса записи. Объект элемента последовательности может иметь переменные-члены для адреса чтения и адреса записи. Однако эти значения должны в конечном итоге стать битами на входных контактах DUT. [7] Может даже использоваться экзотическое кодирование при предоставлении стимула DUT, которое должно быть абстрагировано от остальной части агента. Ответственность драйвера заключается в том, чтобы взять эти элементы последовательности и предоставить надлежащий стимул портам DUT. [3]
Классы драйверов UVM реализованы как подклассы класса uvm_driver, который сам по себе является подклассом uvm_component. [5]
UVM позволяет использовать макросы