OVM/Basic OVM/Session5 - Connecting Components — различия между версиями

Текущая версия на 13:14, 25 ноября 2013

Здравствуйте, я Джон Эйнли из компании Дулос. Это пятое занятие по основам OVM. Его тема - соединение компонентов. Мы познакомимся с тем, как создавать несколько компонентов OVM в окружении верификации и как собирать их воедино. Также мы подробнее рассмотрим архитектуру отдельного компонента.

На предыдущем занятии я говорил, что типичный компонент OVM состоит из контроллера, драйвера и монитора. Идея в том, чтобы использовать компонент как стандартный строительный блок в окружении верификации OVM. Такая конфигурация компонентов называется агентом. Эта структура не является единственно возможной. Вы не обязаны строить окружение верификации исключительно из агентов с такой структурой, однако это неплохая отправная точка, позволяющая обеспечить стандартизацию и согласованность между компонентами верификации из различных источников. Поэтому при обсуждении создания и соединения компонентов будет разумно использовать описанную структуру агентов в качестве примера, отправной точки. И именно так мы сейчас и поступим.

Я уже неоднократно упоминал компоненты OVM, и теперь самое время взглянуть на формальную иерархию классов OVM. Здесь мы вступаем на территорию объектно-ориентированного программирования. На слайде представлена диаграмма иерархии классов в обозначениях, немного напоминающих язык UML. Классы, изображенные ниже, расширяют, или наследуют тем, что изображены выше. Внутри широкой рамки в нижней части диаграммы показаны все виды компонентов OVM. Они применяются для описания структуры. В OVM имеется много классов, причем все они наследуют единственному базовому классу ovm_component, который в свою очередь является производным от класса ovm_report_object, а тот - от класса ovm_object, с которым мы встречались на предыдущем занятии. В нижней части диаграммы мы видим различные компоненты OVM, в частности ovm_env для уже знакомого нам ovm_test, а также такие компоненты, как ovm_agent и ovm_driver. Позже мы узнаем, что некоторые из компонентов полностью взаимозаменяемы и отличаются только названиями. Но есть также компоненты с уникальными свойствами, присущими только им. Во многих случаях у вас есть выбор. Например, можно воспользоваться как ovm_env, так и ovm component. А это означает, что выбор того или иного компонента OVM - вопрос стиля кодирования и единообразия, а не технической необходимости. Тем не менее, на данном занятии я буду выбирать подходящий тип компонента исходя из той роли, которую он играет.

Стало быть, в данном случае мы возьмем компонент ovm_agent. Итак, создадим определенный пользователем компонент верификации, расширив базовый класс ovm_agent. Однако подчеркну еще раз: я мог бы расширить ovm_component, или даже ovm_monitor или ovm_env, и в данном случае получился бы точно такой же результат.

Итак, в строке 2 мы регистрируем my_agent как ovm_component. Это стандартный код, который следует включать обязательно. Впоследствии агент будет создавать экземпляры контроллера и драйвера, поэтому мы объявляем в классе два описателя: my_sequencer_h и my_driver_h.

Далее следует метод new, конструктор класса, и стандартные методы, build и connect. С методом build мы уже встречались ранее, а метод connect для нас внове. Он служит для соединения дочерних компонентов, и чуть позже я подробнее объясню, как он работает.

Однако начнем с расширения метода build. Сначала метод build, как обычно, вызывает метод базового класса super.build,а затем создает экземпляры контроллера и драйвера, с помощью волшебного заклинания type_id::create. Передаваемые методу create аргументы очень важны. Первый аргумент, как и раньше, это имя экземпляра,которое должно совпадать с именем переменной. Второй аргумент – родитель, мы всегда будем использовать в этом качестве "this", встроенную в SystemVerilog переменную, которая обозначает текущий объект, с которым мы работаем. В объектно-ориентированной терминологии метод create называется фабричным. Фабричные методы - это один из так называемых паттернов объектно-ориентированного программирования, то есть заведомо хороших способов решить определенную задачу.Конкретно, фабричный метод позволяет создать объект и в то же время переопределить тип объекта, создаваемого где-то в другом месте. На первый взгляд кажется, что здесь мы создаем объекты типа my_sequencer и my_driver, и по умолчанию так оно и есть. Однако имеется возможность переопределить типы компонентов, создаваемых этими фабричными методами. Так, в каком-то конкретном тесте, не изменяя исходный код данного конкретного агента ни на йоту, мы могли бы переопределить поведение фабричных методов, заставив их создавать иные компоненты, последовательности или драйверы. С помощью этого механизма мы можем настраивать поведение того или иного компонента верификации в конкретном тесте: А. не изменяя ни единой строки кода и Б. не заставляя автора компонента верификации предвидеть все возможные модификации. Ему достаточно просто воспользоваться фабричным методом. Так что это весьма полезный механизм.

Мы рассмотрели метод build, применяемый для конструирования компонентов в окружении верификации. Далее идет метод connect, который служит для соединения компонентов более низкого уровня между собой. В данном случае соединяются драйвер и контроллер. Как видите, метод connect агента вызывает метод connect драйвера, чтобы соединить оба компонента нижнего уровня. Сам код соединения – это обычный исполняемый код. Технически его можно было бы включить в метод build, и все работало бы точно так же. Однако стилистически правильнее и настоятельно рекомендуется размещать код соединения компонентов нижнего уровня в теле метода connect, хотя бы из соображений единообразия.

Взглянув на код метода connect более пристально, вы увидите ссылки на два выделенных жирным шрифтом компонента:

sequence_item_port и sequence_item_export.

Понятия порта и экспортера - выходцы из мира моделирования на уровне транзакций. Они заимствованы из стандарта System C TLM. В данном контексте можно считать, что порты и экспортеры – это просто описатели дочерних компонентов, необходимые для того, чтобы их можно было связать. Итак, чтобы связать драйвер с контроллером, мы берем описатель драйвера, sequence_item_port, описатель контроллера, sequence_item_export, и соединяем их, устанавливая соединение между контролем и драйвером. Можете считать, что эти порты уровня транзакций - своеобразные вариации на тему портов в системах Verilog или VHDL. На самом деле, они не полностью эквивалентны портам VHDL или Verilog, но, если смотреть с высоты птичьего полета, то выполняют они ту же функцию соединения между собой деталей внутреннего устройства отдельных компонентов.

Итак, я познакомил вас с методами build и connect, которые в OVM называются фазовыми методами. А теперь я опишу сами фазы OVM более формально. Идея в том, что каждый компонент в иерархии верификации должен сконструировать свои дочерние компоненты и должен обладать неким основным поведением, выполняемым в ходе моделирования. Кроме того, он может выполнять какие-то служебные функции: открывать файлы, выводить результаты и так далее. Поэтому действия всех компонентов верификации в процессе моделирования необходимо координировать. Именно для этого и предназначены стандартные фазы OVM. Каждый компонент выполняет стандартный набор фаз. Этот механизм позволяет координировать поведение всех компонентов, входящих в иерархию верификации. Давайте рассмотрим пример. Мы создадим пользовательский класс my_component, расширяющий базовый класс ovm_component. Как вы, наверное, помните, класс ovm_component является базовым для целого семейства различных классов компонентов. Обычно выбирается какой-то конкретный класс, скажем ovm_agent, ovm_driver или ovm_monitor, который отражает ваше намерение. Но технически вполне допустимо создавать пользовательский класс, расширяя ovm_component.

В данном примере мы так и поступим. Кое-что из показанного в этом примере мы уже видели раньше. Начинаем с метода new. Метод new, строго говоря, не является фазой, это просто конструктор, часть языка SystemVerilog. Но для удобства можете считать, что это фаза 0. Как правило, в OVM метод new не должен делать ничего, кроме вызова метода new базового класса.

Далее идет метод build, который мы начали писать ранее. Он создает дочерние компоненты. Как я уже отмечал, методы new и build должны вызывать соответственно методы new и build базового класса. Таким образом, оба метода new и build вызываются в порядке строго сверху вниз, то есть начиная с уровня окружения верификации вглубь. Пока вы еще не освоились с OVM более основательно, очень важно помнить, что компоненты в окружении верификации строятся сверху вниз. Напротив, все остальные фазовые методы вызываются снизу вверх.

Следующей стандартной фазой (необязательной) является фаза соединения, на которой соединяются порты и экспортеры дочерних компонентов, а точнее их виртуальные интерфейсы. Методы connect вызываются снизу вверх, начиная с компонентов верификации самого нижнего уровня.

Затем идет стандартная фаза start_of_simulation, которая, как следует из названия, вызывается в начале моделирования. Название этой фазы заимствовано из системы System C. В System C имеется аналогичный обратный вызов, выполняемый в начале моделирования, и называется он точно так же: start_of_simulation. Обычно на этой фазе производятся такие служебные операции, как открытие файлов для чтения или записи в процессе моделирования.

Затем начинается само моделирование, оно выполняется на фазе run, и, как мы видели раньше, run - это единственная задача. В Verilog задача, конечно, может быть продолжительной, выполнять обработчики событий, расходуя на это модельное время. За фазой run следуют еще две фазы, предназначенные для выполнения служебных операций в самом конце моделирования.

На слайде показана фаза report, на которой можно вывести отчет о результатах после того как собственно моделирование завершилось. Таким образом, фазовые методы позволяют координировать и синхронизировать действия разнообразных компонентов, находящихся на разных уровнях иерархии верификации.

Резюмируем все, что мы узнали об анатомии компонента OVM. Компания Mentor настоятельно рекомендует при написании компонента OVM располагать его элементы в порядке, показанном на данном слайде. Так, во второй строке мы всегда регистрируем компонент в библиотеке классов OVM. Затем объявляются все внешние интерфейсы, включая как виртуальные интерфейсы, так и порты и экспортеры, если их необходимо объявить явно. Далее идут объявления описателей внутренних компонентов, в данном случае контроллера и драйвера. И потом все стандартные фазовые методы в надлежащем порядке: сначала конструктор, за ним собственно фазы, build, connect и так далее.

Итак, на этом занятии я объяснил, как создавать экземпляры нескольких компонентов в иерархии верификации. Мы видели, что использование фабричных методов позволяет создавать компоненты так, чтобы в отдельных тестах один компонент можно было подменить другим. Мы видели, что стандартные фазы используются для координации действий нескольких компонентов. А также что OVM предписывает способ структурирования компонентов верификации с тем, чтобы повысить степень их повторного использования, а также поддержать единый стиль кодирования. Мы познакомились с типичной структурой: имеется так называемый агент, который состоит из контроллера, драйвера и монитора, а окружение верификации обычно содержит несколько агентов. Как правило, один агент представляет один коммуникационный канал, шину или порт в тестируемом устройстве. Например, если в тестируемом устройстве имеется шина Amber, то в качестве ее формирователя мог бы выступать агент Amber. Если имеется USB-соединение, то для USB-порта заводится отдельный агент. И так далее. Окружение верификации, как правило, содержит несколько агентов, по одному для каждого из основных интерфейсов тестируемого устройства. А, помимо них, существуют другие компоненты верификации, задача которых - координировать и суммировать действия всех агентов.