OVM/Basic OVM/Session4 - Connecting Env to DUT
Здравствуйте, я Джон Эйнсли из компании Дулос. Это второе занятие по основам OVM.На нем я объясню, как связать окружение верификации с тестируемым устройством. На предыдущем занятии мы написали свою первую программу в OVM. Тогда же мы познакомились с понятиями окружения верификации и тестируемого устройства. Но в тот раз мы немного схитрили,поскольку между окружением и устройством не передавалось никакой информации. Если мы хотим, чтобы информация передавалась, то необходимо предоставить соответствующий механизм,
а, значит, нам понадобится ввести ряд новых концепций. Напомню, что у нас имеется тестируемое устройство, оно же модуль, интерфейс на SystemVerilog, представляющий собой некий структурированный код, и окружение верификации, то есть некоторый класс. А хотим мы, чтобы класс, представляющий окружение верификации, имел доступ к содержимому интерфейса,написанному на языке SystemVerilog. Оказывается, что существует простой и практически удобный способ решить эту задачу, заключающийся в использовании так называемого виртуального интерфейса SystemVerilog. Далее я покажу, как получить доступ к выходам интерфейса SystemVerilog из виртуального интерфейса в окружении верификации. Для этого нам потребуется познакомиться с виртуальными интерфейсами, а также научиться записывать значение в виртуальный интерфейс и настраивать виртуальный интерфейс так, чтобы он указывал на реальный интерфейс SystemVerilog. Попутно нам придется ввести также понятие конфигурационной таблицы, о которой я упоминал ранее.
Итак, приступим. Интерфейс SystemVerilog Наша цель – организовать взаимодействие между тестируемым устройством и окружением верификации. Интерфейс SystemVerilog несет в себе некое содержимое, он представляет все выходы (контакты) тестируемого устройства. Без ограничения общности можно предположить, что это тактовый сигнал, сброс и какие-то данные. На самом деле контактов могут быть сотни, и для их разумной организации можно было бы воспользоваться mod-портами. Но надо же с чего-то начать, а это вполне репрезентативный пример контактов тестируемого устройства.
Далее имеется определение тестируемого устройства. В первой строке модуля dut мы передаем интерфейс. Устройство может синхронизироваться по фронту тактового сигнала, как показано на слайде. Определение может содержать тысячи, даже сотни тысяч строк кода на SystemVerilog,помимо показанной на слайде оболочки.
Теперь перейдем к самому интересному. Как вы, наверное, помните, в окружении верификации необходимо реализовать метод, точнее задачу, run, которая будет тестировать устройство, подавая и считывая сигналы с контактов. На слайде показано определенное пользователем окружение верификации, класс my_env, расширяющий ovm_env. Этот класс содержит содержит метод run, который по существу ничем не отличается от процесса в VHDL или Verilog. Этот процесс потребляет время. На слайде с помощью нотации #10 представлены временные задержки. В определенные моменты времени процесс изменяет состояние контактов интерфейса SystemVerilog, конкретно подает сигналы на вход данных. Это можно сделать с помощью виртуального интерфейса SystemVerilog. Эпитет «виртуальный», пожалуй, выбран неудачно, потому что это слово активно употребляется в объектно-ориентированных языках программирования, а также в SystemVerilog. Я думаю, будет понятнее считать, что речь идет просто о переменной, ссылающейся на интерфейс. Итак, виртуальный интерфейс в SystemVerilog – это всего лишь переменная, в которой хранится ссылка на интерфейс SystemVerilog. И язык SystemVerilog позволяет это делать. Таким образом, в классе, представляющем окружение верификации, мы завели переменную, которая может ссылаться на сам интерфейс SystemVerilog. И эта возможность – структурная особенность языка SystemVerilog. Теперь мы можем получить доступ к содержимому этого интерфейса SystemVerilog, например к контакту данных, через виртуальный интерфейс, написав dut_vi.data. Этот механизм позволяет как подавать, так и считывать сигналы с любого контакта интерфейса SystemVerilog из класса, представляющего окружение верификации. Основной принцип вам, видимо, понятен. Осталось только придумать удобный способ задавать значение виртуального интерфейса из модуля верхнего уровня, там, где создается экземпляр интерфейса SystemVerilog. Обратите также внимание на суффикс _vi. Рекомендуется использовать его, чтобы показать, что речь идет именно о виртуальном интерфейсе. Строго говоря, рекомендует это не столько OVM, сколько компания Mentor Graphics, но тем не менее к совету стоит прислушаться.
Теперь посмотрим, как задается значение виртуального интерфейса. Для этого мы применим механизм конфигурирования. На верхнем уровне нашего модуля SystemVerilog мы создаем экземпляры тестируемого устройства и интерфейса SystemVerilog. Поскольку интерфейс SystemVerilog существует именно на этом уровне, то именно здесь мы и должны инициализировать виртуальный интерфейс. Поэтому мы создаем виртуальный интерфейс на верхнем уровне и присваиваем ему ссылку на интерфейс SystemVerilog. Далее необходимо исхитриться и сделать этот виртуальный интерфейс доступным внутри окружения верификации. Для этого мы воспользуемся конфигурационной таблицей. Мы хотели бы поместить наш виртуальный интерфейс в конфигурационную таблицу, но тут возникает небольшое техническое препятствие, потому что OVM не разрешает хранить виртуальные интерфейсы непосредственно в конфигурационной таблице. Поэтому нам придется обернуть виртуальный интерфейс, замаскировав его под что-то другое, и это что-то сохранить в конфигурационной таблице. Ну что ж, создадим обертку вокруг виртуального интерфейса, а затем поместим замаскированный таким образом виртуальный интерфейс в конфигурационную таблицу. После этого окружение верификации, равно как и любые находящиеся в нем компоненты, которым нужен доступ к интерфейсу SystemVerilog, смогут получить виртуальный интерфейс из конфигурационной таблицы. Далее я продемонстрирую вам все технические детали кода. Мы увидим, как инициализировать виртуальные интерфейсы
и как работать с механизмом конфигурирования. Что ж, начнем. Первым делом нам необходимо создать обертку вокруг виртуального интерфейса. Выглядит она следующим образом. Обертка – это тоже определяемый пользователем класс, но расширяет он класс ovm_object. То есть наша обертка – это объект типа ovm_object. Подробнее мы будем говорить об объектах OVM на следующих занятиях, но уже сейчас отметим, что ovm_object – базовый класс для большинства классов из библиотеки OVM, с которыми нам предстоит встретиться. В остальном наша обертка чрезвычайно проста. Она содержит обертываемый виртуальный интерфейс и конструктор. Конструктор принимает виртуальный интерфейс в качестве аргумента и с его помощью инициализирует свойство класса, в котором хранится виртуальный интерфейс. Если вы не очень хорошо знакомы с объектно-ориентированным программированием, подскажу, что роль конструктора заключается в том, чтобы инициализировать члены класса. Наш класс содержит переменную dut_vi, поэтому конструктор должен ее инициализировать. Чтобы разобраться в этом, не нужно быть экспертом по ООП.
Итак, класс-обертку мы написали, теперь воспользуемся им, чтобы создать указатель на виртуальный интерфейс. На этом слайде в последней строке блока initial мы создаем экземпляр обертки, вызывая конструктор класса, которому передаем интерфейс SystemVerilog, а конструктор возвращает надлежащим образом инициализированную обертку if_wrapper, с которой дальше можно работать.
Затем мы сохраняем эту обертку в конфигурационной таблице, обращаясь к методу set_config_object Этот метод заносит объект в конфигурационную таблицу OVM. Я задержусь на описании его аргументов, поскольку очень важно понимать, для чего они предназначены. Первый аргумент – это путь к компоненту, для которого мы сохраняем информацию. Это может быть полный путь в иерархии, что позволяет избирательно задавать конфигурационную информацию для конкретного объекта в иерархии верификации. Таким образом, в принципе мы можем очень точно настроить иерархию верификации, задавая параметры для объектов каждого класса. В данном же случае мы хотим сделать виртуальный интерфейс SystemVerilog доступным на любом уровне иерархии верификации. Поэтому вместо конкретного пути указываем звездочку. Звездочка означает, что данная конфигурационная информация доступна всей иерархии верификации. Вторым аргументом метода set config_object является имя устанавливаемого конфигурационного параметра. Третий аргумент – значение этого параметра, а четвертый – флаг, о котором следует рассказать подробнее. Что мы хотим сделать? Занести объект в конфигурационную таблицу. Но, как вы знаете, в переменной SystemVerilog хранится не сам объект, а ссылка на него. Так что мы передаем методу set_config_object ссылку на объект. А дальше есть два варианта: клонировать объект и поместить в конфигурационную таблицу ссылку на клон, то есть копию. Либо сохранить в конфигурационной таблице ссылку, или, если угодно, указатель на исходный объект. Строго говоря, в языке SystemVerilog нет указателей, но есть ссылки, которые по существу ведут себя точно так же. В данном случае четвертый аргумент равен нулю. Это означает «не клонировать», так что в конфигурационной таблице будет храниться ссылка на исходный виртуальный интерфейс, нас это вполне устраивает.
Для полноты картины приведем оставшуюся часть кода. Мы вызываем встроенный метод run_test, который запускает тест и конструирует окружение верификации. Мы видели, как на верхнем уровне информация заносится в конфигурационную таблицу.
Теперь посмотрим, как эту информацию можно извлечь, находясь в окружении верификации. Наше окружение верификации представлено пользовательским классом my_env и, как вы помните, он содержит стандартный метод build. А этот метод вызывается на фазе предвыполнения, чтобы построить иерархию верификации. Первое, что должен сделать метод build, - это вызвать super.build. Ни в коем случае не забывайте об этом. Если опустить вызов super.build, то ничего не будет работать. Затем мы объявляем переменные obj и if_wrapper, поскольку собираемся их использовать, и вызываем метод get_config_object. Get_config_object вернет объект с указанным именем из конфигурационной таблицы. Мы запрашиваем конфигурационный параметр с именем dut_if_wrapper, и получаем его значение в переменной obj. Переменная obj имеет тип ovm_object. Поскольку SystemVerilog - строго типизированный объектно-ориентированный язык, то сейчас нам предстоит проделать несколько трюков. Технически метод get_config_object возвращает переменную типа ovm_object. Но нам необходим объект типа dut_if_wrapper, только тогда мы сможем сделать что-то полезное.
Поэтому надо выполнить приведение типа. В языке SystemVerilog для приведения служит метод доллар cast. Мы передаем ему значение, полученное от get_config_ object, то есть obj, и переменную, в которую следует поместить объект, приведенный к нужному типу, - if_wrapper. Предложение assert просто проверяет, что приведение выполнено успешно. Теперь значение нужного параметра находится в переменной правильного типа, if_wrapper, и мы можем извлечь из этой обертки виртуальный интерфейс, а затем присвоить полученное значение виртуальному интерфейсу внутри окружения верификации.
Еще раз повторим, что именно мы сделали в терминах конфигурационной таблицы. Я привел пример использования методов set_config_object и get_config_object. В принципе все элементарно. Set_config_object помещает значение конфигурационного параметра в глобальную конфигурационную таблицу, а get_config_object извлекает значение конфигурационного параметра из этой таблицы. Помещая объект в таблицу, мы можем указать конкретный путь в иерархии верификации, к которому этот параметр будет применяться. А get_config_object просто вернет то значение параметра, которое действует для текущего экземпляра компонента. Вместо пути и имени поля в обоих методах set и get_config_object можно задавать звездочку. И это бывает очень полезно.
Однако это еще не все. Чтобы разобраться в работе механизма конфигурирования, следует понимать, что методы set_config и get_config могут вызываться на любом уровне иерархии верификации. Удобно считать, что конфигурационная информация распространяется сверху вниз - из вашего теста через окружение верификации к отдельным компонентам верификации, находящимся в этом окружении. Как правило, set_config вызывается на верхних уровнях, чтобы задать значения конфигурационных параметров, а get_config - на нижних уровнях, чтобы эти значения получить. Может возникнуть ситуация, когда один и тот параметр установлен на нескольких разных уровнях иерархии. На данном слайде показан параметр data, который установлен дважды: один раз внутри теста, а другой - в окружении ovm_env. Первый раз ему присвоено значение a, второй - значение b. В таком случае значение, заданное на более высоком уровне, отменяет значение, заданное на нижнем уровне. Идея в том, чтобы можно было настроить компоненты OVM, задав значения параметров в окружении верификации, затем, быть может, создать экземпляр этого окружения в более широком объемлющем окружении и, наконец, переопределить параметры на уровне теста. Тогда параметр, заданный в тесте, будет иметь приоритет. Стало быть, именно тест получает шанс установить окончательные значения конфигурационных параметров, которые будут действовать для конкретных компонентов верификации.
Итак, я познакомил вас с базовым механизмом, применяемым для организации взаимодействия между окружением верификации и тестируемым устройством. Попутно я рассказал о конфигурационной таблице, которая лежит в основе техники параметризации как существующих компонентов верификации, так и существующих окружений верификации с целью адаптации их к работе в конкретном контексте.
