OVM/Advanced OVM/Session5 - Writing and Managing Tests
- Understanding TLM
- Understanding the Factory
- The Care and Feeding of Sequences
- Layering Sequences
- Writing and Managing Tests
Рад снова приветствовать Вас на курсе по методологиям верификации OVM и UVM. Меня зовут Том Фицпатрик. На сегодняшнем уроке мы разберём тему «Составление и дальнейшая разработка тестов».
И первый же вопрос, требующий ответа - Что представляет собой тест? Согласно методологии OVM, существует так называемая среда – то, что обычно мы называем тест-панель. Она определяет, какие компоненты нужны для верификации дизайна, какие агенты, секвенсоры, программы-мониторы, программы-агенты, устройства сбора потребуются. Среда задает настройки «по умолчанию», охват «по умолчанию», последовательности «по умолчанию». Затем задача теста заключается в настройке-отладке тест-панели. Чтобы её сконфигурировать, сбросить заводские настройки, может быть, еще добавить последовательности для выполнения. Может, добавить обратные вызовы к щособым компонентам среды. Суть в том, что в методологии OVM если программный код среды написан, его не нужно менять, тест же может затронуть многие аспекты среды посредством различных механизмов и изменить поведение среды, это переход от одной модели поведения к другой, что отличает один тест от другого. будь то последовательность, которую Вы проходите, либо необходимый Вам охват, критерии завершения какие угодно, по Вашему усмотрению. В этом и заключается смысл теста – внести довольно небольшие изменения в поведение среды, чтобы Вы смогли проработать различные аспекты плана верификации.
Для установки настроек «по умолчанию» обычно мы используем нашу среду. Первое, что должна делать среда - получать информацию о конфигурации для особенных элементов среды. В таком случае можно выяснить, сколько ведомых устройств должно работать. Вызовем get_config, если же get_config даёт ноль, тогда это значит, что этот конкретный параметр в этом случае – количество ведомых устройств, которые мы включаем, никем не было задано вначале из теста. В этом случае мы будем использовать значение «по умолчанию», в этом случае – 2, хотя м.б. любое значение, конкретно для данной среды. Продолжим и создадим любые доступные нам ведомые устройства, используя метод создания из набора. То, что мы сделали, сводится не только к тому, что мы создали отдельный объект из набора, мы определили тип «по умолчанию» для наших ведомых устройств. Когда мы создали особую последовательность для последующего выполнения, которая также является типом «по умолчанию» для данной последовательности, Затем среда может начать выполнять последовательность «по умолчанию». Такое поведение «по умолчанию», которое демонстрирует среда, и когда нам известно, что делает среда тест же может полагаться на тои факт, что среда выполнит это, затем тест либо изменит некоторые из этих параметров, либо добавит дополнительные модели поведения, которые запускают последовательности или другие элементы.
Ещё одна важная деталь, когда получаете данные через config заключается в том, если config был кем-то задан, а на заданные значения наложены ограничения, проверьте их и убедитесь, что значения, которые устанавливаются сейчас, являются действительно точными. В таком случае можно утверждать, что значение, которое мы получили от ведомых устройств через config, находится в диапазоне между 2 и 8; в противном случае нужно сообщить об ошибке. Эту ошибку можно сделать фатальной, либо какой угодно, по Вашему усмотрению. Когда получите информацию о конфигурации, первое, что нужно сделать с этими сведениями проверить их актуальность, есть ли какие-то ограничения относительно того, каким д.б. это значение.
Другой способ установки значений «по умолчанию» в OVM реализуется посредством базового теста, который сейчас и составим. Это основной тест, на котором будут основываться другие наши тесты. То, что мы можем в основном тесте в режиме конструктора - на самом деле выбрать среду «по умолчанию». Таким образом, среда сама по себе является компонентом. Её можно создать прямо из набора. Так что мы выберем среду «по умолчанию», а затем, если захотим, можем просто заменить эту среду другой средой в следующем тесте.
Затем мы можем расширить основной тест, чтобы составить т.н. действительный тест. Это то, что совершит нечто значительное вдобавок к «умолчаниям». Первое, что мы делаем в режиме конструктора с нашим тестом - вызываем super.build, которая вызовет основной тест и позволит ему делать всё, что нужно для задания настроек «по умолчанию». Итак, заданы все настройки «по умолчанию», которые были зарегистрированы, после чего можно будет изменить некоторые из них. Можно вызвать set_config и задать количество ведомых устройств, сейчас - 4. Также можно игнорировать любые типы компонентов либо, в данном случае, особую разновидность типа ведомого объекта; пусть будет error_slave. Также можно игнорировать тип последовательности, которая будет сгенерирована в основной среде. Стало быть, вместо test_sequence назовём её test1_sequence. Итак, вот этот тест, my_test1, используется та же среда, при этом у неё немного другая конфигурация, и она выполняет иную последовательность. Сам по себе код среды не меняется, все, что делаем - изменяем здесь её конфигурацию. Итак, на лицо особый сценарий, который можно выполнить, чтобы проверить правильность особого элемента в нашем плане верификации.
После того, как составлен тест, его можно активировать из модуля верхнего уровня. В нашем же модуле верхнего уровня есть интерфейс, который мы будем использовать для подключения к дизайну. Мы также создадим упаковщик вокруг данного интерфейса, чтобы затем сконфигурировать нашу среду и каждый ее компонент, использующий интерфейс, для подключения к дизайну через тот интерфейс. Затем вызовем run_test. Вызовем run_test пока без аргументов, чтобы использовать тестовое имя +arg в командной строке, чтобы задать, какой тест будет запущен. Берем имя теста, который хотим создать из набора, И мы рекомендуем не задавать имя в run_test, поскольку в таком случае действительно придется задать имя теста согласно методологии OVM в командной строке. Если Вы забыли это сделать, либо не задали имя и не вызвали run_test, обязательно будет ошибка. Иначе же придется запускать тест «по умолчанию», который Вы превратили в run_test, что могло быть вовсе не тем, что было нужно. Поэтому лучше всегда вызывать run_test без аргументов и задавать имя теста в командной строке.
Одна из задач, которую мы бы хотели суметь выполнить - упростить составление тестов по методологии OVM. Частично можно решить эту задачу, если поместить в среду большое число описаний. Когда все описания будут находиться в среде наряду с другими значениями «по умолчанию», тест становится достаточно понятен, поскольку теперь осталось только изменить определенные настройки в среде. Так что наша среда будет задавать нам программы-агенты. прочие компоненты, как-то: табло, устройства сбора, может, виртуальный секвенсор, выполняющий какую-то последовательность. Эта виртуальная последовательность обычно обладает большим функционалом того, что должно считаться тест-кейсом. Задача же виртуальной последовательности будет заключаться в том, чтобы координировать работу последовательностей, на других компонентах среды. Как только это будет готово, тест просто ссылается на среду и выбирает особые описания, как, напр., виртуальную последовательность для запуска. Также после можно задать, какие устройства сбора будут задействованы, какой тип табло будет использоваться, степень охвата на табло могут во многом зависеть от того, конкретно какую виртуальную последовательность Вы запускаете. Вам хочется убедиться в том, что все взаимосвязанное в среде верно. Следовательно, тест довольно понятен; он же просто задает несколько параметров среды, среда же затем отпочковывается и отлично работает сама по себе с любыми настройками, заданными этим тестом, и прочими «умолчаниями», которые Вы задали.
Итак, если взглянуть на довольно простой здесь тест, вот этот тест, назовём его sequence_test_by_name. Выберем такое имя из командной строки в аргументе тестового имени OVM Это тест, являющийся компонентом, зарегистрированным в наборе и то, что будет сделано, сведётся к созданию виртуальной последовательности и её пуску. Итак, создаём среду, используя набор, затем используем команду $value$plusargs из языка SystemVerilog, чтобы пользователь мог задать, какую виртуальную последовательность запустить в командной строке. Можно просто сказать +seqname или plusarg – не важно, как будет называться,задать имя класса последовательности, которую хотим сгенерировать. В данном случае мы собираемся задать my_virtual_sequence. Зададим значение «по умолчанию», так что если нет признака plusarg для этого значения, здесь же создадим его вида virt_seq. Если же оно использовано, то, что мы сделаем - создадим из набора объект с таким именем. Это основанный на названии интерфейс к набору, и задан он строками. Это не тот тип базового объекта, который мы видели раньше, созданный с пом. type_id::create. Мы используем create_object и передаем его в имени последовательности, которую создали. Дело в том, что мы не советуем делать всегда так, использование основанного на строках интерфейса к набору представляет трудность из-за классов с определенными параметрами. В этом же случае виртуальные последовательности обычно не имеют параметров так что это разрешается делать. В общем же не рекомендуется использовать основанный на именах интерфейс набора. Впрочем, для таких целей, как эта, сгодится, поэтому у нас есть полная свобода действий для создания здесь простого теста который позволяет работать из командной строки, и задавать, какую виртуальную последовательность нужно выполнить. Потом нам только остаётся начать, независимо от выбранной последовательности, будь то «умолчание» или последовательность, заданную в командной строке на виртуальном секвенсоре в среде. Это позволяет нам иметь среду, в которой, как мы знаем, имеется виртуальная последовательность, и из командной строки мы задаем, какую виртуальную последовательность хотим запустить на данном секвенсоре.
Сейчас же можно изменить тест, добавив к нему кое-какие подробности поинтереснее. Мы создадим одну такую последовательность и назовём её cov_test. Снова вызываем super.build, чтобы создать виртуальную последовательность, которая снова возьмёт себе имя последовательности из командной строки, если мы так решим. Еще одна вещь, которая точно произойдёт, - будет проигнорирован охват, в данном случае, охват в агенте 1 в среде и вместо основного типа охвата мы будем использовать control cov. Если же данный конкретный тест направлен на интерфейс устройства управления и набор команд управления или ещё что-то, можно получить одно устройство сбора, которое специально следит за элементом из нашего плана верификации. Его можно поместить сюда с помощью cov_test, задать последовательность, которую хотим использовать, а также поместить на табло, которое будет соотноситься с любой последовательностью, которая будет выбрана. Поэтому важно убедиться в том, что табло подходит к заданной нами последовательности независимо от того, какая последовательность будет сгенерирована. Табло же надо отыскать ту же последовательность. Тест же сейчас задает, какой мы ищем особый охват, какое особое поведение должно быть у табло, основываясь на последовательности, которую мы собираемся генерировать. Мы не хотим ссылаться на контрольную группу cov cover, если последовательность, которую мы выберем, завершиться, при этом будет задействован канал передачи данных. Необходимо убедиться в том, что эти вещи соотносятся друг с другом. Здесь же на лицо гибкость, сейчас эта cov tes, обычно это две строки кода, которые позволяют решить, какое устройство сбора будет использоваться, какое использовать табло также можно выбрать последовательность из командной строки. За счет этого достигается высокая гибкость без необходимости много работать с тестом, поскольку мы построили большую часть инфраструктуры, используя базовые классы и среду «по умолчанию». Все, что нужно, - задать в командной строке какую последовательность мы хотим выполнить, которая соотносится с устройством сбора на табло, которое мы использовали и все что мы бы хотели от него, можно нацелиться на любую часть нашего плана по верификации которая необходима для конкретного теста.
Когда мы начинаем тест, надо уметь управлять тем, как этот тест будет завершён. Мы не хотим, чтобы симуляции работали постоянно. В методологии OVM предусмотрено два механизма для завершения теста. Первый механизм я называю прямым методом, он использует механизм «Возражение». Есть встроенное возражение - ovm_test_done. которое и надо использовать. Компоненты и последовательности могут поднимать или опускать возражения в конец симуляции. Когда кто-то начинает исполнять команду, он поднимает возражение, означающее, что остановить тест нельзя, пока я не соглашусь понизить возражение. Потом, когда все возражения будут понижены, тест может завершиться.
Существует также непрямой метод, использующий строку global_stop_request. Если тест достигнул точки, в которой сработал стимул, он вызывает global_stop_request, который запустится и потребует, чтобы все компоненты системы прекратили работу. Любой компонент системы, чувствительный к этому, задаёт enable_stop_interrupt, затем для каждого компонента у которого задана enable_stop_interupt, запускается метод stop gets позволяющий компоненту откладывать завершение теста, пока он не закончится, что бы ни потребовалось для очистки, а затем отпускает его. Когда же тест запрашивает остановку, компонент говорит: «Нет, не сейчас Я пока не готов». А когда он завершает свою работу, тогда и заканчивается тест.
Эти два механизма на самом деле работают сообща до определенного момента, когда же все поднятые возражения понижаются, система безоговорочно вызывает global_stop_request. Не нужно переживать из-за этого, поскольку просто надо понять, когда понижены все возражения, global_stop_request будет вызвана Вам в помощь, Это значит, что все компоненты, которые включили stop_interrupt, задействуют свои задачи по остановке, и все это возникло параллельно, так что когда они вернутся, тогда тест может закончиться. Если вызовите global_stop_request, случится следующее: система станет ожидать, когда все текущие возражения будут понижены, чтобы заработать и вызвать задачи на остановку. Можно использовать только возражения, можно использовать только global_stop_request, либо использовать комбинацию того и другого.
Реализация этого в тесте выглядит так: после начала выполнения последовательности, просто вызываем global_stop_request. Затем, когда вернётся последовательность, вызываем global_stop_request. Это значит, если пойти этим путём, этой последовательности действительно придётся вернуться в некоторую точку. Иначе global_stop_request никогда не вызовут.
Если же запрос на полную остановку вызовет некий метод остановки для этих компонентов, надо понять, что делать дальше с методом остановки. В случае метода пуска, в данном случае, это программа-монитор, это может быть любой компонент системы, мы устанавливаем enable_stop_interrupt на значении "1" это мог быть конфигурируемый параметр, если Вам, конечно, надо. Можно вызвать get_config, чтобы понять, стоит или не стоит задействовать это. Итак, тест запустит последовательность, затем это произойдёт в методе пуска, метод пуска программы-монитора также работает. Пока есть показания к тому, чтобы продолжать в том же духе, мы вызовем то, что призвано признать операцию будет признано начало операции, и ждать завершения операции, а затем записать эту операцию в порт для анализа, потом вернуться наверх и приняться за следующий. Мы в этой петле в нашей программе-мониторе, и нам нужно как-то остановить то, что случится. Когда же начинается тест, он вызывает global_stop_request, мы вызовем метод остановки данного компонента. Обычно происходит следующее с методом остановки - метод остановки может быть вызван для любой основанной на задании фазы. «По умолчанию» в OVM «пуск» – единственная основанная на задании фаза, пользователи же могут добавлять свою основанную на задании фазу в список фаз. В данном конкретном случае нужно убедиться, что задействован метод пуска. С этой целью делаем повторную проверку. При вызове остановки она безоговорочно передаётся аргументу, который является фазой, выполняющейся в данный момент. Смотрим, что мы в режиме «пуск», затем здесь же можно задать поведение, которое скажет нашей махине и методу остановки, что пора остановиться. А затем можно подождать сигнала, который мы уже завершили во время последней операции. Метод пуска задаёт поведение на включение, который позволит методу остановки вернуться, что, в свою очередь, позволит закончить тест. Вот довольно простой и и наглядный пример. Можно поместить в систему что угодно, и остановить ожидает ли она операцию, чтобы завершить её, или ожидает сигнала от чего-то ещё, о том, что наступило некое событие. Окончательное решение принимаете Вы. Когда получена команда на остановку, задача на остановку, нужно убедиться, что метод пуска достигнет точки, в которой его можно остановить. Не надо останавливаться посередине процесса обработки операции. В этом и заключается задача метода остановки.
Вопрос же в том, встретятся ли они, или метод остановки ожидает, что наступит другое событие, что случится, если остановка не вернётся. Есть два сторожевых таймера в методологии OVM, которые защищают от этого. Первый таймер - global_timeout. Каждая основанная на задаче фаза д. б. завершена за некоторый промежуток времени, можно задать эту global_timeout самому прямо из теста, если хотите. Также имеется счетчик set_global_stop_timeout. Когда остановка вызвана, метод остановки должен вернуться за тот самый промежуток времени Нельзя установить их на ноле, так как они не должны быть нулевыми. Если же установить их на ноле, будем использовать значение «по умолчанию», которое весьма близко максимальному значению времени для симуляции. Если Вы ждете, что симуляция быстро остановится, если что-то пойдёт не так, а метод остановки не вернётся, я советую не использовать нулевое значение. Выберите довольно большое значение, но не берите ноль.
А теперь давайте рассмотрим возражения. Возражения имеют строгую иерархию. Если же наша последовательность, выполняющаяся в секвенсоре который, в свою очередь, работает внутри программы-агента, последовательность может решить поднять возражение. Когда же она поднимет возражение, есть счётчик возражений, который ведёт их учёт, а у последовательности же уже есть одно поднятое возражение, когда послед-ть поднимает своё возражение, что приводит к тому, что также вызывается её родной метод возражений. И вот секвенсор поднимает возражение, затем вызывает его предка, в данном случае, агента, заставляет поднять возражение. Монитор тоже может поднимать возражения. Когда же её спрашивают, её родитель, в данном случае, агент, поднимает возражение. И вот у программы-агента есть два возражения. На самом деле, когда Вы поднимаете возражение, его можно передать в виде числа, если хотите поднять более одного возражения за единицу времени. Так что возражения поднимаются в соответствии с иерархией. И вот у нас есть последовательность, секвенсор и программа-монитор, у которых по одному возражению, и программа-агент с двумя возражениями, согласно принципу, который исповедует данная иерархия.
Возражения отбрасываются также на основе иерархии. Если понизить возражение в последовательности 1, когда её счетчик доходит до нулевого значения, это вызывает отказ от возражения у родителя. Сейчас мы отказались от возражений программы-агента. А теперь мы дошли до одного текущего возражения у программы-агента, таким образом, отказ от возражений не ссылается на элемент с более высокой иерархией. Когда монитор отказывается от своего возражения, на самом же деле когда счётчик возражений любого компонента достигает ноля, срабатывает обратный отсчёт, который ждёт, пока пройдёт какое-то время, чтобы поднять отказ от возражения наверх. Это позволит, если опять поднять возражение до того, как выйдет время, отказ от возражения не перейдёт наверх по иерархии.
В целях применения возражения ovm_test_done можно разобрать пример, в данном случае, с программой-монитором. Программа-монитор непременно признает начало операции, здесь важно то, что как только программа-монитор признает начало операции, тест не нужно заканчивать посередине процесса обработки той операции. Вы можете, как только Вы признали начало операции, поднять возражение в программе-мониторе. Потом мы продолжим собирать информацию об операции с записью этой информации в порт для анализа либо совершая любые операции, которые должны быть завершены до того, как закончится тест. После того, как мы подошли к этому моменту, можно отказаться от возражения. Единственная сложность здесь в том, если программа-монитор – единственный компонент в системе, использующий возражение, тест закончится, когда произойдет отказ от всех возражений. Это значит, как только программа-монитор откажется от возражения, даже если это единственная обрабатываемая операция, тест обязательно закончится. Нужно прикинуть, как обойти это.
Одно из решений - использовать время, отпущенное на срабатывание. Вы просто вызываете метод set_drain_time, возражения test_done, и он будет ждать столько времени, сколько установлено до передачи отказа от возражения. В нашем случае с монитором, если следующая операция происходит в теч. 10 временных ед., после отказа от возражений, мы снова поднимаем возражение, и всё будет в порядке. Как я уже говорил, это не то, на что нужно действительно полагаться, поскольку, прежде всего, это добавочно если подниматься по иерархии, и когда окажетесь в комплексной системе, времени для срабатывания м.б. намного больше, чем Вы думали. К тому же не всегда можно предугадать, сколько времени нужно подождать, в итоге, Вы столкнётесь с такой ситуацией, с которой лучше не сталкиваться.
Итак, я советую поднимать возражение в тесте, чтобы компонент, имеющийся в системе, больше не был единственным возражающим. Когда же Вы поднимаете возражение в тесте, после чего другие компоненты поднимают и понижают возражения, когда все остальные возражения были занижены, они до сих пор являются возражением из выполняемого теста, поэтому тест пока не закончится. Вы начинаете выполнять последовательность из теста, и когда она будет пройдена, Вы снимаете возражение. Если же прочие возражения пока не сняты, когда Вы снимаете своё возражение, тест будет продолжен, пока прочие возражения также не будут сняты. Как и в предыдущем нашем примере с global_stop_request, всё же требуется, чтобы виртуальная послед-ть вернулась в некоторую точку. И это, наверняка, произойдёт. Нужно убедиться, что это точно произойдёт. Это позволяет сейчас нам использовать механизм возражений со всеми нашими компонентами, чтобы убедиться, что все компоненты ведут себя так, как нам бы хотелось. Мы не должны переживать из-за создания механизма остановки, который сможет работать вместе с работающей махиной, чтобы быть уверенным в том что всё «тормозит», как надо, пока не пришло время заканчивать тест. Мы советуем Вам поднимать возражение в тесте, делайте то, что хотите, в конце понизьте возражение, после чего прочие имеющиеся возражения будут обрабатываться и дальше.
Название данного модуля - Методологии OVM и UVM для опытных пользователей. Для большинства задач UVM сродни UVM. Для Accelera мы использовали OVM 2.1.1, поменяли букву «O» на букву «U» и получили UVM. Часть общего замысла заключается в том, чтобы добавить несколько расширений к методологии OVM, что частично вылилось в небольшие изменения в программном интерфейсе приложения. Это тот случай, когда между двумя методологиями OVM и UVM – имеются незначительные различия. В случае же с поднятием возражений и снятием возражений у всех аргументов есть «умолчания», в методологии UVM же есть второй аргумент, который называется описание. Итак, когда Вы поднимаете или снимаете возражение, можно перейти в значение строки, которое объясняет, зачем надо поднимать или снимать данное возражение. Это полезно для выявления и устранения ошибок. Существует ряд других методов, которые наз-ся «поднятые», «снятые» и «полностью снятые» Это методы обратного вызова, когда бы компонент ни поднял возражение, вызывается метод «поднятые», который может делать всё, что угодно. Снова есть строка описания. Аналогично «снятым» и «полностью снятым», когда счетчик отказа «падает» до ноля, это может быть вызвано также по любому компоненту. Мы советуем, когда Вы вызываете функцию поднятия или снятия возражения, Вы всегда переходите сюда как объект, что позволяет одновременно OVM и UVM вести себя одинакового, с данной точки зрения. «Поднятые», «снятые» и «полностью снятые» обратные вызовы на самом деле не потребуются. Они уже там, если захотите ими воспользоваться, на самом же деле, можно сделать гораздо больше и без них.
Поэтому сейчас не будем останавливаться на них. Итак, следующее, что умеет тест - изменять поведение некоторых компонентов при помощи обратных вызовов. Это опция предусмотрена в обеих методологиях OVM и UVM, и она позволяет техпису основательно расширять поведение некоторых компонентов. Она требует, чтобы разработчик компонентов встраивал в компонент инфраструктуру для поддержки обратных вызовов. Основной смысл об обратных вызовах в том, чтобы их использовать неоднократно, компонент, который будет иметь обратный вызов, может использоваться в любом контексте, в который его могут поместить. Обратные вызовы же не должны зависеть от порядка. Если же есть обратный вызов, который обязательно должен быть запущен первым, на самом деле он не является многоразовым. И мы тоже не советуем так делать. Итак, обратные вызовы должны быть независимы от порядка, следующий же вопрос, который мы должны задать самим себе, - как же нам настраивать эти обратные вызовы?
Как я уже говорил, решение принимает разработчик компонентов, помещать ли его здесь в объёмной инфраструктуре. Первое, что надо сделать - создать класс обратных вызовов. В этом случае это будет называться bus_driver_callback. Это расширение из методологии OVM основного класса обратных вызовов. В данном объекте обратного вызова мы заявляем специальные методы, в которые будет внедрён функционал обратных вызовов. Мы создаём функцию, в данном случае она называется trans_receive, также можем создать задачу trans_exec. Эти объекты могут стать чем угодно, в качестве аргумента они принимают тот объект, от которого исходит обратный вызов, особая операция, которую должен обработать обратный вызов. Мы также даём имя нашему обратному вызову в целях выявления и устранения ошибок. есть метод, который называется get_type_name, использующий инфраструктуру дебаггинга, чтобы вернуть имя обратного вызова. Нужно объявить их как часть объекта обратного вызова. При использовании UVM единственное отличие в том что в UVM расширяется класс обратных вызовов в отличие от обратных вызовов в методологии OVM.
В добавок к разработке объект обратного вызова разработчик компонента также должен предусмотреть выходы на пользователя, которые бы позволили эти методы обратного вызова вызывать. В данном случае у нас есть драйвер, когда же он получит операцию, тогда можно обращаться к методу, в данном случае к trans_receive, Сразу после того, как операция получена от секвенсора, подходит для обращения к обратному вызову, если Вы склоняетесь к нему. В данном случае этот обратный вызов вернёт значение, если же это значение будет нулевым, мы узнаем, что у нас проблема. В противном случае мы выполним шинный цикл. Когда же шинный цикл завершится, ещё подходит для обращения к обратному вызову, В данном случае мы вызовем trans_exec. Имейте в виду, что trans_receive – функция. Она возвращает значение. trans_exec – задача, поэтому она будет выполнена. Это позволит техпису дать определение trans_receive и trans_exec должен делать для данного применения, потом это у теста будет возможность контролировать специфические модели поведения, чтобы нацелиться на другую сферу плана верификации. В зависимости от применения места, в которых Вы собираетесь предусмотреть выходы на пользователя во многом определяете Вы сами. В общем, сразу после того, как Вы получаете операцию, сразу после того, как Вы выполните операцию, и перед тем, как передать операцию куда-то, где самое время вставлять обратные вызовы. Зарегистрированные методы обратного вызова и через минуту мы увидим, как мы на самом деле регистрируем обратные вызовы, они вызываются из макроса.
Впрочем, мы не хотим применять макросы непосредственно. Поэтому мы создадим один виртуальный метод в компоненте, который будет называться макросом обратного вызова. Основной макрос называется ovm_do_callbacks, и это пройдёт через все обратные вызовы, которые зарегистрированы на конкретное имя и будут вызываться по порядку. Первое – тип, который связан с конкретным обратным вызовом, компонент, для которого Вы зарегистрировали обратный вызов в данном случае - bus_driver. И потом у нас есть тип объекта обратного вызова, с которым мы имеем дело это bus_driver_callback. trans_exec – метод вызова, запомните сейчас, это макрос. Это программный код, который в действительности будет вызван, trans_exec - это являющийся объектом, в котором мы находимся. а tr – это операция. Это и есть вызов метода. Аналогично по функции, мы также можем вызвать макрос. Этот конкретный макрос - ovm_do_callbacks_exit_on - пройдётся по всем функциям, которые были зарегистрированы, со особым именем с теми же аргументами, что мы использовали ранее. Драйвер, обратный вызов и вызов действенного метода. Есть другой аргумент для макроса exit_on, который используется со специальным значением, чтобы выйти из данного круга с помощью объектов обратного вызова. Как только один из обратных вызовов возвращает значение, в данном случае это нулевое значение, тогда этот метод вернётся и вернёт то нулевое значение, как возвращённое значение функции.
Сейчас же пользователь обратного вызова, в данном случае это может быть техпис, расширит объект обратного вызова, чтобы создать то, что мы назовём my_bus_driver_callback, пользователь же вносит более подробное описание данных объектов обратного вызова. Следовательно, функция trans_exec сделает что-то, что может пойти на пользу. А метод trans_receive сделает нечто такое, и вернёт значение в результате проверки или модификации содержимого или обработки содержимого операции, и вернёт значение. Когда мы определили, что это такое, опять же, всё сильно зависит от применения, во многом определяете Вы сами, что Вы хотите сделать. Не забудьте задать имя для метода get_type таким образом, чтобы мы понимали, какой объект обратного вызова используется для дебаггинга. Как только Вы закончите с этим, надо связать данный объект обратного вызова со специфическим компонентом в системе, чтобы обеспечить всю функциональность.
Мы также можем создать ещё один обратный вызов, который снова вытекает из основного класса bus_driver_callback. Убедитесь в том, что Вы изменили здесь get_type_name. Нам не нужны ошибки по вине «вырезки» и «вставки». Потом мы задаём здесь же дополнительный функционал, для данного случая – обратный вызов trans_exec. Не нужно задавать все методы обратных вызовов для каждого объекта обратного вызова, в данном случае у нас есть один, мы ничего не сделали с trans_receive. Безотносительно того, какую функциональность хотелось бы добавить, Вы можете это сделать.
Техпису же нужно добавить эти объекты обратного вызова либо связать их со специфическими компонентами системы. Получилась my_callback_test. Создаём typedef объекта ovm_callbacks. Обратите внимание, что обратные вызовы стоят во мн.ч. Это определяется типом компонента, с которым мы будем связывать его, и типом обратного вызова, который мы собираемся задействовать, Назовём его cbs_t. Отчасти это облегчает нам задачу по набору на клавиатуре, и позволяет нам получить доступ к статическим методам объекта ovm_callbacks. В режиме конструктора мы создадим объекты обратного вызова, которые мы зарегистрируем. Обратите внимание, что мы просто используем здесь конструктор. Цель объекта обратного вызова - изменить поведение какого-либо объекта в системе. На самом деле здесь не обязательно использовать набор для создания объектов обратного вызова, поскольку тест на самом деле не должен изменять тип объекта обратного вызова, который вернулся из набора. Он может просто сослаться на другой объект обратного вызова. Мы вполне можем использовать простой конструктор для объектов обратного вызова. Мы ссылаемся также на среду, и, как обычно, мы делаем это из набора. Мы применяем метод end_of_elaboration для регистрации обратных вызовов, поскольку мы должны убедиться в том, что эти компоненты существуют, до того, как мы зарегистрируем на них обратные вызовы. Мы вызываем метод get_global_cbs заданного параметрами объекта ovm_callbacks и это убеждает нас в безопасности типа мы убеждаемся, что мы всего лишь регистрируем соответствующий тип объекта обратного вызова с соответствующим компонентом. Мы вызвали метод добавления данного объекта cbs_callbacks, и можем зарегистрировать более одного обратного вызова. Мы задаем объект обратного вызова, который мы регистрируем и компонент, который мы регистрируем с ним.
В UVM мы поменяли букву «O» на букву «U», и сейчас у нас есть объект uvm_callbacks, который также задан параметрами компонентом и типом обратного вызова. Изменение, которое мы внесли, вместо того, чтобы вызвать get_global_cbs, у нас есть статический метод, называющийся надстройкой данного типа cbs_t. Мы просто вызываем надстройку и передаем её компоненту и объекту обратного вызова, с которым мы собираемся иметь дело. Мы не будем вызывать get_global_cbs, чтобы понять суть объектов обратного вызова, лучше воспользуемся стат. методами согласно UVM. За исключением того, что функциональность та же.
Подводя итоги, хочу сказать, что среда служит нам тест-панелью, она определяет компоненты, которые нужны для верификации конкретного дизайна, она задает «умолчания» для последовательностей, или устройств сбора, которые, возможно, Вы захотите использовать, либо какие-то другие объекты в системе. Задача теста затем состоит в настройке тест-панели, не важно, используется при этом set_config для изменения границ охвата, либо количества ведомых устройств на шине. Может испол-ся набор, чтобы игнорировать тип последо-ти, которая генерируется «по умолчанию» либо от используемого типа охвата. Можно создавать доп. послед-ти для запуска, либо взамен, либо параллельно последовательности «по умолчанию». Можно задавать обратные вызовы, чтобы изменять поведение определённых компонентов. Сами компоненты могут использовать возражения, чтобы убедиться, что они завершают любое поведение, которое требуется до того, как будет закончен тест. Так, тест становится координатором того, что происходит внутри среды, задавая же тест «по умолчанию», который потом можно расширить и изменить с помощью весьма незначительных изменений программного кода, не важно, меняем ли мы заводские настройки, или добавляем новую конфигурацию, можно создавать библиотеку тестов, которые используются со специальными элементами в Вашем плане верификации.
Когда же мы представим себе всю архитектуру методологии OVM, мы получим среду, которая располагает рядом компонентов. Программы-агенты с секвенсорами, драйверами и мониторами, устройствами сбора данных. Мы представляем виртуальную последовательность, которая включает последовательность, координирующую поведение других последовательностей в системе. Это позволяет задать «по умолчанию» специально для Вашего набора приложений некие инструменты, которые будут использоваться с большим числом элементов Вашего плана верификации. Тест, который можно направить на специальный элемент в Вашем плане верификации. для использования среды и незначительной её модификации задавая другую виртуальную последовательность для запуска либо какой тип информ-ого табло использовать, либо устройства сбора потребуются. Сейчас в методологии OVM из-за того, что все эти компоненты используют TLM интерфейсы можно воспользоваться преимуществом гибкости, используя набор для замены одного компонента другим компонентом того же типа. Интерфейсы те же. Главный код не нужно изменять, чтобы задействовать этот новый компонент из-за того, что все соединения точно такие, какими они были. Так что любой элемент в OVM, будь то компонент низкого уровня как драйвер или программа-монитор либо агент, или секвенсор, либо устройство сбора, либо даже среда настроена так, чтобы так быть сконфигурированной, используя набор для отсылки к компонентам-предкам, позволяет тесту изменить тип компонента, на который происходит ссылка без необходимости изменения программного кода среды или компонента. Сконфигурировав каждый компонент, перед тем, как сделать ещё что-то, либо во время запуска в соответствующее время позволяет тесту настроить соответствующее поведение, снова, Вам не надо изменять подлежащий компонент, поскольку он настроен на конфигурацию соответствующим образом. Сочетая всё это вместе, Вы имеете ситуацию, когда можно создать библиотеки компонентов и сред, затем тест определяет небольшой набор элементов из такой библиотеки, и изменяет его немного. Сами же тесты на самом деле имеют лишь несколько строк кода, для изменения этих моделей поведения по умолчанию и параметров конфигурации, затем можно направить их на специфические элементы Вашего плана верификации. Итак, после того, как мы собрали всё вместе, элементы, о которых мы вели разговор, на этих пяти уроках, нацеленных на опытных пользователей методологии OVM, Я надеюсь, что теперь Вы понимаете, как пользоваться методологией OVM, чтобы создавать модульную систему, которая позволила бы с любого подходящего уровня будь то уровень блоков, переходить к среде больших масштабов от более мелких компонентов, используя последо-ти, о которых была речь можно создать многоуровневый стек протоколов для верификации. Можно сконцентрироваться на различных уровнях абстракции в различных областях тест-панели на различных отрезках Вашего процесса верификации, Общий же смысл в том, чтобы использовать OVM для создания среды, которая нацелена на специфический элемент в Вашем плане верификации. Вы можете убедиться, что у Вас есть тест, который затрагивает каждый элемент Вашего плана, после того, как Вы пройдёте все тесты, Вы получаете результаты. Можно проверить что Вы действительно прошлись по каждому элементу Вашего плана. Так что если Вы хотите добиться успеха в работе, Вы его точно добьётесь. Если же Вы не сможете составить план верификации тогда Вы планируете неудачу. Методология OVM даёт Вам возможность сосредоточиться на целях верификации Вашего плана верификации. Когда же Вы закончите, то будете знать, что верификация пройдена. Благодарю за внимание! Надеюсь, Вам понравился этот урок. Надеюсь увидеть Вас снова на следующих модулях от Verification Academy.
