OVM/Basic OVM/Session2 - Introduction to OVM

Здравствуйте, я – Джон Эйнсли из компании Doulos. Это второе занятие из серии «Основы OVM – введение в OVM». На предыдущем занятии я начал с базовой информации об ограниченно случайной верификации, чтобы показать мотивы, зачем развивать и улучшать свою методологию верификации:

возможно, прямо от традиционных тест-бенчей VHDL и Verilog к чему-то более сложному. Этот первый модуль на самом деле рассчитан на представление мотивации для использования OVM. Итак, в данном модуле, на этом занятии мы более подробно рассмотрим OVM, и я представлю общую картину OVM и расскажу о некоторых технических особенностях.

Итак, что такое OVM? OVM означает Open Verification Methodology (методология открытой верификации). OVM позволяет вам написать тест-бенчи для систем, которые выражаются в Verilog, SystemVerilog, VHDL или даже SystemC. OVM формально является библиотекой классов SystemVerilog. Итак, OVM состоит из тела кода SystemVerilog и соответствующей практической документации. OVM предлагается по общедоступной лицензии, конкретная лицензия, которая была выбрана – это лицензия Apache. Лицензия Apache – одна из наиболее свободных общедоступных лицензий: это означает, что OVM доступна вам бесплатно, в форме исходного кода, и с ней можно делать почти все, что вам хочется. OVM – результат совместной разработки Cadence и Mentor. Эта система обратно совместима с более ранними методологиями Cadence и Mentor. Вам не придется мучиться с ней, начиная все с нуля – она основана на проверенных методологиях, которые существуют не первый год.

Это также означает, что вы берете существующий код AVM и URM и запускаете его без модификаций в среде OVM. Хотя OVM формально является библиотекой классов SystemVerilog, всегда предполагалось, что она будет использоваться в многоязычной среде моделирования. Так что вполне возможно использование верификационной среды OVM с тестируемой системой VHDL или использовать стандартную модель SystemC или C++ в верификационной среде OVM.

Теперь обратимся к некоторым основным характеристикам OVM, и главное здесь – стандартизация и непротиворечивость, а не изобретение колеса заново. SystemVerilog – очень большой и очень сложный язык, и за последние несколько лет компании разработали свои собственные способы написания тест-бенчей SystemVerilog и последующего создания все более более сложных  верификационных сред. И опасность здесь состоит в том, что каждый делает свое дело, и все создают верификационные среды, несовместимые друг с другом. Таким образом, одно из основных направлений в рамках OVM – это создание стандартной и непротиворечивой верификационной среды, благодаря которой вы можете многократно использовать не только код, но и стандарты кода, свои навыки и утилиты от проекта к проекту. В частности, OVM поддерживает ограниченно случайную верификацию по охвату, как я объяснял на первом, вводном занятии. OVM также позволяет создавать настраиваемые и гибкие тест-бенчи. И главное здесь – создание тест-бенчей или верификационных сред, которые могут быть многократно использованы от проекта к проекту путем настройки, а не изменения исходного кода. Таким образом, во многом акцент здесь делается на многократном использовании верификации, на создании воспроизводимых компонентов верификации. При этом OVM в своей работе отделяет тесты от тест-бенчей. Когда я пользуюсь терминами «верификационная среда» и «тест-бенч», эти термины – практически синонимы. В OVM тесты изолированы от тест-бенчей, так что один тест-бенч может многократно использоваться для разных тестов. В верификационной среде OVM использует связь транзакционного уровня, и для этого используется стандарт TLM, созданный в мире SystemC. OVM также широко использует многоуровневые последовательные стимулы, также называемые последовательностями. Стимулы могут быть созданы OVM с помощью ряда последовательностей, которые могут моделировать протокол, связанный с вашим приложением. Наконец, OVM предлагает стандартную службу сообщений, так что ошибки, отчеты, предупреждения могут обрабатываться стандартным единообразным способом.

Возьмем одну из этих тем – тесты и тест-бенч. В тест-бенче OVM большая часть кода идет  в фиксированной верификационной среде многократного действия. И каждый тест приходит к этому коду, исправляет или настраивает его в целях управления тестом с тем, чтобы реализовать конкретные характеристики тестируемой системы. Итак, в итоге у вас получается единое фиксированное тело кода верификационной среды, и библиотека тестов, которые можно поочередно выбирать и запускать без необходимости в изменении или рекомпиляции основной верификационной среды.

Затем – многоуровневые последовательные стимулы, так что на самом нижнем уровне верификационная среда OVM будет содержать так называемый компонент драйвера, этот драйвер непосредственно контактирует с тестируемой системой, подавая и отслеживая значения отдельных частей канала (отклонения штырьков). Драйвер будет получать команды из остальной верификационной среды и преобразовывать их в отклонения штырьков. В верификационной среде эти команды представлены в виде так называемых транзакций. Таким образом, при моделировании на транзакционном уровне, которое представляет собой отдельный предмет для изучения, транзакция – это абстрагированное понятие контакта. Она может представлять собой пакет данных или цикл чтения или записи на шине. Драйвер получает транзакции из верификационной среды и преобразует их в отклонения штырьков. Сами транзакции объединяются в так называемые последовательности. Последовательность может состоять из серии операций, которые могут создаваться случайно или могут быть направленными,  чтобы реализовать тестируемую систему особым образом. Затем последовательности могут быть объединяться в большие последовательности в верификационной среде OVM, и эти последовательности могут быть связаны друг с другом целым рядом способов. Во-первых, последовательности могут быть просто вложены в другие последовательности, или же   последовательности могут быть уложены на разных уровнях так, чтобы они представляли или соответствовали различным уровням в протокольном пакете. Например, последовательность, представляющая нижний уровень в протокольном пакете, может получать информацию от последовательности верхнего уровня, а затем использовать ее в «сборке» транзакций нижнего уровня. Так, OVM делает акцент на последовательностях: они дают широкие возможности для создания многократно используемых компонентов верификации.

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

Я только подчеркнул некоторые основные характеристики и преимущества OVM. Теперь посмотрим на сообщество OVM. Это сообщество базируется на сайте OVMworld.org. Здесь вы можете загрузить реальный исходный код OVM – можно также загрузить разработки для сообщества OVM. Есть ряд полезных дополнений, все они доступны для загрузки по лицензии с открытым исходным кодом. Имеются утилиты и документация OVM.

В частности, я бы хотел обратить внимание на документацию HTML, которая является справочником по классам OVM. Эта документация доступна на сайте OVMworld.org (так что вы можете найти ее по поиску); она также включена в комплект OVM. Если вы откроете эту документацию из пакета OVM, вы фактически можете связать ее с исходным кодом библиотеки OVM, что делает ее отличным справочником. Этот документ – не учебник и, конечно, не конспект учебных занятий, однако как справочник для быстрого поиска информации он превосходно объяснит вам множество технических подробностей.

Я закончу это занятие описанием некоторых вещей, которые вам необходимо изучить, если вы думаете об использовании OVM. Первое, что вам точно надо знать – это SystemVerilog. Как я уже показывал, SystemVerilog – большой и сложный язык сам по себе. В компании Doulos мы проводим учебные занятия – обычно наши занятия по SystemVerilog (по изучению только самого языка) рассчитан на 5 дней. Это позволяет вам понять, как много можно изучить в SystemVerilog – при условии, что вы уже знаете VHDL или Verilog. Затем – сама библиотека OVM. OVM – это библиотека классов, так что вам необходимо изучить подробности библиотеки классов OVM, и мы коснемся этой темы в этом модуле Академии верификации. Мы шаг за шагом рассмотрим некоторые базовые классы в библиотеке OVM. Однако библиотека классов OVM использует методы объектно-ориентированного программирования (ООП) он использует моделирование транзакционного уровня (TLM), и для успешного использования OVM необходимо знать не только SystemVerilog и классы – вам также нужно знать методы объектно-ориентированного программирования и транзакционного моделирования, и все это требует времени для изучения и привыкания. Затем все это используется в контексте ограниченно случайной верификации, которую я упоминал во вступительных занятиях. Ограниченно случайная верификация и OVM также используют характеристики языка SystemVerilog – в частности, она использует утверждения, покрытие, ограничения и интерфейсы. В компании Doulos мы тратим три дня на обучение OVM в контексте ограниченно случайной верификации, в дополнение к пяти дням, которые мы тратим на изучение SystemVerilog. Я говорю об этом, чтобы вы поняли, что если вы собираетесь использовать в проектах OVM и SystemVerilog, то не следует недооценивать объем и глубину необходимого обучения. В этом конкретном модуле Академии верификации мы попытаемся дать простое и комфортное введение в некоторые основные характеристики OVM, что будет служить отличным трамплином для дальнейшего, более серьезного изучения OVM. Наконец, тонкий верхний слой – планирование верификации и управление ею. Планирование верификации и управление ею, возможно, является относительно небольшой темой по техническим деталям, одновременно это, может быть, самая важная тема, поскольку она связывает технические подробности ограниченно случайной верификации и OVM с целями бизнеса – управлением инвестициями и созданием реально работающих электронных систем. Так что вам нужно посвятить много времени пониманию планирования верификации и управления ею. На остальных занятиях модуля «Основы OVM» мы шаг за шагом рассмотрим некоторые ключевые классы в библиотеке OVM.