OVM/Basic OVM/Session3 - OVM "Hello World"
Здравствуйте, я – Джон Эйсли из компании Doulos. Это третье занятие в серии Основы OVM – OVM «Hello World». Сейчас мы перейдем от общей информации об OVM и обратимся к конкретному коду OVM. Оставшиеся занятия будут адресованы инженерам-практикам. Вероятно, вы уже пользовались VHDL или Verilog, может быть, вам уже что-то известно из SystemVerilog, и я помогу вам начать пользоваться именно OVM. Итак, идея с OVM «Hello World» – в том, чтобы дать вам реальный эквивалент в OVM программы C Hello World. Если вы помните, программа Hello World на языке C – это знаменитая однострочная программа, почти самая короткая из возможных программа на языке C, которая просто что-то печатает и делает нечто разумное. Теперь мы попытаемся сделать то же самое с OVM. Однако, чтобы сделать ее осмысленной, программа OVM Hello World фактически более сложна, чем программа на языке C, поскольку нам необходима работа нескольких ключевых элементов.
Поэтому первое, что нам необходимо – это тестируемая система, или DUT. Это будет модуль SystemVerilog, который может быть оберткой для компонента в другом языке. Возможно, ваш DUT написан на VHDL – отлично. Тогда у нас есть верификационная среда, и если вы изучали предыдущие модули, предыдущие занятия в этом модуле, вы увидите, что верификационная среда OVM разделяется на две части: фиксированную часть, называемую env, т.е. собственно верификационную среду, и переменную часть, которая представляет собой ovm_test. Верификационная среда в OVM основана на классах, так что и тесты, и среда строятся почти исключительно на основе классов SystemVerilog, по сравнению с тестируемой системой, которая была структурной и модульной. Чтобы создать мостик между основанной на классах верификационной среде и тестируемой системой, мы используем интерфейс SystemVerilog. Оказывается, что интерфейс SystemVerilog – самый практичный способ соединения в SystemVerilog основанного на классах и модульного кода. Итак, у нас структурный интерфейсный модуль и основанная на классах верификационная среда. Вся система целиком затем экземплифицируется из модуля SystemVerilog. Итак, нашим верхним уровнем будет модуль SystemVerilog – этот модуль SystemVerilog будет экземплифицироватьнашу тестируемую систему, интерфейс SystemVerilog и верификационную среду, которая состоит из env и test. Итак, это – общая структура примера, который я собираюсь показать вам.
Теперь нырнем поглубже и рассмотрим код подробно, начав с интерфейса. Логически интерфейс SystemVerilogдолжен быть первым для компиляции в SystemVerilog, поскольку он создает общий интерфейс как для верификационной среды, так и для тестируемого устройства. И фактически в нашей программе «Hello World» интерфейс пуст. Нам не нужно ничего в нем. Здесь представлен код, который вы бы фактически написали в интерфейсе, если бы это была реально тестируемая система. Вам нужно экземплифицировать штырьки в DUT. В данном случае оно может быть пусто.
Затем сама тестируемая система, которая в данном случае является пустым модулем. Тестируемая система учитывает интерфейс SystemVerilog в первой строке, чтобы определить входы и выходы тестируемой системы. Некоторые современные инструменты синтеза SystemVerilog фактически синтезируют модуль в этом формате. Если вы используете инструмент синтеза, когда вы не хотите синтезировать интерфейс SystemVerilog, все, что вам нужно сделать – написать тестируемую систему в Verilog или VHDL со списком отдельных штырьков, входящих в тестируемую систему или выходящих из нее, а затем просто положить это в обертку, которая содержит интерфейс SystemVerilog. Это может быть реальный DUT или обертка вокруг DUT.
Теперь мы дошли до верхнего уровня. Итак, верхним уровнем будет модуль Verilog – он экземплифицирует интерфейс,экземплифицирует тестируемую систему и передает интерфейс в строке экземплификации тестируемой системы. На этом мы закончим со структурными компонентами нашего простого примера Hello World.
Теперь обратимся к среде, основанной на классах. Здесь приведен первый пример класса SystemVerilog. Фактически весь код, который мы увидим в оставшихся занятиях, будет основан на классах. Мы немного займемся объектно-ориентированным программированием. Если вы уже знакомы с объектно-ориентированным программированием SystemVerilog или другим языком программирования типа C++ или Java, отлично. Если нет – без паники, я попытаюсь объяснить по ходу дела. Здесь мы создаем определяемую пользователем верификационную среду под названием my_env путем расширения ovm_env – класса, встроенного в библиотеку OVM, и мы создаем свою собственную верификационную среду, расширяя класс, встроенный в OVM; это – обычный вид объектно-ориентированного программирования, и мы увидим много похожего в будущем.
В строке 2 класса нам нужно зарегистрировать этот класс в библиотеке OVM как компонент OVM. Поэтому в каком-то смысле просто нужно помнить о том, что это нужно сделать. Рекомендуется сделать это во второй строке определения класса. Эта регистрация дает вам ту автоматизацию, которая не встроена в SystemVerilog. Так что нужно просто помнить, что это нужно делать всегда, когда вы пишете компонент в OVM, но это также имеет некоторую практическую пользу в автоматизации некоторых вещей, которые окажутся очень полезными позже.
Третье, что нам нужно сделать – это написать так называемый конструктор для класса. Если вам уже знакомо объектно-ориентированное программирование, вы знаете, что конструктор – особая функция или метод, который вы пишете внутри класса, который инициализирует объекты, когда они создаются. Итак, в SystemVerilog конструктор – это специальная функция под названием new. Если вам ничего не известно о System-Verilog или объектно-ориентированном программировании, единственное, о чем вам нужно знать здесь – это то, что каждый класс должен содержать функцию new, и вам настоятельно рекомендуется пользоваться именно этим стандартным кодом, когда вы пишете класс в OVM. Другими словами, нам нужна новая функция с именно двумя параметрами – именем и предком, который внутри содержит вызов super.new. super.new – еще один элемент объектно-ориентированного программирования. Мы здесь вызываем конструктор базового класса для данного класса. Другими словами, мы вызываем конструктор класса ovm_env.
Вам нужно знать о методе build следующее. Если вы новичок в области объектно-ориентированного программирования, вас может немного смутить жаргон, которым я пользуюсь. Метод – это термин, обозначающий функцию, определенную внутри класса. Итак, метод – это функция, которая принадлежит конкретному объекту объектно-ориентированного программирования. Если вам удобно, когда я говорю о методе build, можно понимать его как функцию. Работа метода build – это создание содержимого данной части верификационной среды. В нашей программе «Hello World» верификационная среда так проста, что метод build должен только вызывать метод build суперкласса, или базового класса. Поэтому очень важно, чтобы этот метод build вызывал super.build, и если бы это была реальная верификационная среда, которая бы не только умела говорить «Hello World», то метод build делал бы и другие вещи.
Последний элемент в этом классе – метод run класса, который в данном случае, как вы видите, представляет собой задачу Verilog. Метод run в определенном смысле является основным методом этого класса. Метод run содержит поведение, которое реализуется при моделировании. Это обычно получается в Verilog путем выписывания блока always или – в VHDL – путем выписывания оператора процесса. Фактически задача прогона среды OVM ведет себя как процесс в VHDL или Verilog. Так что методы new и build эффективно исполняются во время разработки для создания верификационной среды и экземплификации других компонентов, а метод run исполняется при моделировании одновременно с другими процессами в модели SystemVerilog. Возможно, вы заметили, что метод build – это функция, метод run – это задача, так что именно метод run фактически потребляет время, потраченное на моделирование.
В программе Hello World данный конкретный метод run просто запускает моделирование на 10 единиц времени, так что мы начинаем с контроля времени #10, который запускает моделирование на 10 единиц времени, а затем эта верификационная среда останавливает моделирование, вызывая запрос останова. Здесь мы видим метод top.stop_request. Думаю, понятие запроса на останов не требует подробных объяснений – название говорит само за себя, запрос останавливает моделирование. ovm_top – это имя объекта, и в частности, этот объект – высокоуровневый объект иерархии компонентов. Так, ovm_top – имя объекта, этот объект является экземпляром класса, и этот объект – верхний уровень нашей верификационной среды OVM. Это – верхний уровень верификационной среды, как противоположность модулю верхнего уровня. Так что ovm_top – это не модуль верхнего уровня в иерархии модулей SystemVerilog, а что-то совсем другое. ovm_top – объект верхнего уровня в основанной на классах верификационной среде. Так что ovm_top основан на классах. Это ПО, элемент программирования, в противоположность модулю верхнего уровня Verilog или SystemVerilog.
Итак, теперь мы видим среду OVM, верификационную среду, давайте рассмотрим test. Итак, test – еще один класс, определяемый пользователем. Здесь у нас есть класс под названием my_test и он написан путем расширения ovm_test. Итак, опять, ovm_test – это класс, встроенный в библиотеку OVM, и мы создаем определяемый пользователем тест путем расширения этого встроенного класса test. Опять же, не следует забывать в строке 2 зарегистрировать этот класс, определяемый пользователем с OVM с помощью макроса ovm_component_utils.
Тест тогда будет экземплифицировать среду, так что в терминах структуры нашего кода SystemVerilog у нас есть test вверху, и test сделает экземпляр среды в качестве компонента. Итак, здесь, внутри этого класса, у нас есть атрибут или свойство класса, которое можно считать переменной типа my_env и имя переменной – my_env_h, и мы сознательно используем суффикс _h при создании этой переменной. Это рекомендуется, поскольку эта переменная фактически используется как индекс. В SystemVerilog при создании переменной тип этой переменной – класс SystemVerilog, тогда эта переменная фактически содержит ссылку на объект, и эта переменная также называется индексом для этого объекта. Так что когда вы видите суффикс _h, это напоминает вам о том, что переменная не буквально сохраняет объект – она сохраняет индекс или ссылку на этот объект.
Затем у нас есть стандартные методы, которые мы рассматривали ранее. Итак, у нас есть конструктор, и вы можете заметить, что этот конструктор следует точно такому же стандартному коду, как в предыдущем классе, который мы рассматривали, и это делается сознательно. И метод build, снова метод build вызывает super.build – это очень важно, но это другое дело.
В этом случае метод build будет экземплифицировать верификационную среду, он будет экземплифицировать компонент my_env, который мы видели раньше. Эта экземплификация выполняется с помощью довольно длинной строки кода. На данном этапе я хочу вас попросить просто воспринимать эту строку кода как магическую формулу. Воспринимайте ее как есть. У нас есть my_env::type_id::create. Мы вызываем метод create, который связан с my_env::type, чтобы создать экземпляр данной верификационной среды my_env. Затем мы сохраняем логический номер, ссылку на только что созданный объект в переменной my_env. Я подробно объясню, что происходит здесь с этим идентификатором типа. Откровенно говоря, вам необязательно знать об этом. Все, что вам необходимо знать – это то, чтобы экземплифицировать компонент в основанной на классах верификационной среде: просто следуйте этой магической формуле – и все в порядке.
Нужно передать правильные аргументы в метод create. Первый аргумент – это строковое имя данного конкретного компонента в иерархии компонентов. Очень хорошая идея – сделать строковое имя тем же самым, что и имя переменной,которую мы собираемся использовать, чтобы сохранить индекс данного объекта.Например, в этом примере строковое имя – my_env_h, и имя индекса – тоже my_env_h. То, чтобы они были одинаковыми – не является техническим требованием: это нужно для вашего удобства. Второй аргумент для метода create – это this. this – это имя, встроенное в SystemVerilog. this хранит ссылку на текущий объект. В объектно-ориентированном программировании любой код, написанный внутри класса, исполняется в контексте конкретного объекта. this в SystemVerilog дает индекс этого конкретного объекта. Другими словами, что касается нашего примера Hello World, здесь вы находимся внутри тела test, и this указывает на сам объект test, который будет предком для остальной верификационной среды. Другими словами, второй аргумент – это создание предка компонента, который мы экземплифицируем.
Сейчас мы видим класс, представляющий нашу верификационную среду, класс, представляющий test, и оказывается, что лучшее место для размещения этих классов в коде SystemVerilog – пакет. Цель при этом – избежать введения слишком большого количества имен в исходный код SystemVerilog. Технически вы могли написать эти классы на верхнем уровне – при этом имена классов стали бы высокоуровневыми именами, глобальными именами, и они засоряют ваше пространство глобальных имен. Поэтому лучше определить все свои классы внутри пакета, а затем единственное имя, которое входит в глобальное пространство имен – это имя самого пакета, в данном случае – my_pkg. Чтобы фактически скомпилировать любой код OVM, а также написать классы и поместить их в пакет, нам необходимо воспользоваться директивой правого включения для включения заголовков. Поскольку мы пользовались макросом в коде OVM – если помните, мы пользовались компонентом макроса регистрации – то нам необходима директива включения Verilog ovm_macros.svh в верхней части файла; и нам также нужно импортировать символы из самого пакета OVM. Этот пакет встроен в библиотеку OVM, которая содержит все внутренние встроенные классы OVM. Они импортируются с помощью строки import ovm_pkg::*. Звездочка – это символ, который импортирует все содержимое пакета OVM.
Итак, мы рассмотрели основанную на классах верификационную среду и тест. Теперь мы закончим создание модуля верхнего уровня. Раньше мы видели высокоуровневый модуль, который экземплифицировал интерфейс, экземплифицировал тестируемую систему – теперь нам нужно экземплифицировать основанную на классах верификационную среду. Нам нужно несколько утверждений об импорте. Мы импортируем содержание ovm_pkg, импортируем содержание нашего собственного пакета my_pkg::*,
а затем из процедурного блока – первоначальное утверждение Verilog – мы делаем вызов run_test. Итак, run_test – это встроенный метод в OVM, который будет фактически выбирать и запускать тест. Имя теста, который мы запускаем, мы передаем как аргумент в метод run_test. Именно здесь вы выбираете конкретный тест, который вы хотите запустить. При выполнении run_test обнаружится класс, который был назван my_test – это делается с помощью информации, которая передавалась при регистрации класса. Он будет экземплифицировать тест, который в свою очередь экземплифицирует верификационную среду, и вся верификационная среда запускается – мы запускаем свою программу Hello World.
Итак, мы запускаем эту программу, затем выполняется моделирование, и мы можем увидеть несколько сообщений, написанных в окне транскрипта моделирования. Здесь можно увидеть сообщения, выходящие из Questasim. Если внимательно посмотреть, вы увидите, что мы запускаем версию 2.1 библиотеки OVM. Мы запускаем оригинальные коды OVM –вы видите здесь уведомления об авторских правах Mentor и Cadence.
Далее здесь информационное сообщение о том, что выполняется тест my_test. my_test – имя нашего конкретного теста, который запускается здесь. Затем переходим к остальной части транскрипта. У нас есть краткий отчет OVM – стандартная информация, одно информационное сообщение. Предупреждений и ошибок нет, все хорошо. Наша модель работает хорошо и без ошибок. И, наконец, у нас есть замечание, говорящее, что моделирование закончено успешно в момент 10. Другими словами, наш запрос на останов был исполнен по плану после того, как наша верификационная среда потратила 10 единиц времени. Это – как раз то, что мы хотели. Итак, это – эквивалент в OVM отображения написанного сообщения Hello World.
Итак, на этом занятии я привел очень простой, но полный пример кода OVM, так что при желании вы можете написать этот код и запустить его. Этот код работает в реальных условиях. Мы изучили различие между основанной на классах верификационной средой и модульным миром тестируемой системы, и фактически увидели, как выглядит код OVM, чтобы разделить переменную и фиксированную части верификационной среды, а затем экземплифицировать и начать тест. Мы рассмотрим это более подробно на следующем занятии.
