OVM/OVM методология/Механика OVM/4.8
Содержание |
Тестирование и тестовые окружения
Благодаря правильному использованию конфигураций, для производство, и поэтапного процесса разработки, можно создать тестбенч для верификации, что позволяет подавать случайные воздействия больше, чем просто сгенерированный stimuls. Например, если тестбенч написан, чтобы количество драйверов на шине можно настраивать, то же тестбенч может быть повторно использован на нескольких тестах, каждый из которых может указать другой (возможно, случайно) число драйверов. Как вы можете видеть, гибкость OVM позволяет запускать каждую из этих различных тестов без изменения тестбенча. OVM также обеспечивает явные ovm_test классы в качестве контейнера для испытаний. Как правило, на top-level модуль будет экземпляром ovm_test, который в свою очередь настраивает и создает тестбенч. Дополнительные тесты могут быть написаны как расширения базовым тестам, которые включают новую конфигурацию и директивы factory, в результате чего сами тесты относительно короткий, четкий и простой в обслуживании. В действительности, ovm_test это просто другое расширение ovm_component. Поскольку тесты и testbenches просто компонентами, они тоже могут быть созданы и переопределены через factory.
Диаграмма UML выше иллюстрирует отношения между тестом и окружением. И тесты и окружение (ENV) компоненты. Тест содержит окружение. Среда содержит top-level компонет тестбенча и их соединений. Для определенния окружения, вы может хотите иметь несколько тестов. Кроме того, для конкретного теста, вы, возможно, пожелаете осуществлять его на твои окружения. factory позволяет менять тесты, окружения, или то и то.
4.9.5 Изменение потока управления (Altering the Flow of Control)
Большую часть времени, когда вы выдаете отчет, отчет отображается или отправить файл, а затем контроль возобновляется в последующих состояниях. Есть случаи, когда вы хотите изменить поток управления, основанный на сообщениях, которое выдается. Наиболее очевидный случай остановка тестбенча. EXIT событие заканчивает тестбенч сразу после отправки сообщения до того как тест выполниться до конца. Действие COUNT увеличивает на единицу quit_count, и тестбенч заканчивается, когда quit_count достигает max_quit_count. Как правило, вы будете использовать эти действия чтобы, прервать цикл выполнения программы, в котором может произойти ошибка в неопределенное время, или предотвратить каскадные сообщения об ошибках из запутанного (неопределенного) источника ошибки.
4.9 Reporting
OVM предоставляет богатый набор классов и функций для генерации и фильтрации сообщений. Объекты OVM типа сообщения содержит три вида функций:
- Отображение сообщений в едином порядке по различным направлениям
- Фильтрация сообщений
- Изменение потока управления в результате сообщения в печати
4.9.1 Базовые сообщения (Basic Messaging)
function void ovm_report_info( string id, string message, int verbosity = OVM_MEDIUM, string filename = "", int line = 0); function void ovm_report_warning( string id, string message, int verbosity = OVM_MEDIUM, string filename = "", int line = 0); function void ovm_report_error( string id, string message, int verbosity = LOW, string filename = "", int line = 0); function void ovm_report_fatal( string id, string message, int verbosity = OVM_NONE, string filename = "", int line = 0);
Каждая из этих четырех функций выдает сообщение, которое имеет несколько компонентов: статус, уровень детализации, идентификатор, сообщение, имя файла и номер строки.
Статус. Статус сообщение может принимать значения OVM_INFO, OVM_WARNING, OVM_ERROR, или OVM_FATAL. Выбор тяжести меняет окончательный текст, который напечатан тексте в котором указана серьезность. Это также влияет на то, как сообщение обрабатывается. Например, вызов ovm_report_fatal заканчивает выполнения тестбенча. Другие способы, в которых статус влияет на обработку сообщений, обсуждаются в разделе 4.9.2.
Идентификатор сообщения содержит произвольную строку, которая используется для идентификации строк. Идентификатор печатается как часть текста сообщения, и это также влияет на сообщения обрабатываются.
Сообщение. Сообщение тело текстового сообщения.
Уровень детализации. Уровень детализации сообщения является произвольным числом, которое по отношению к текущей настройки детализации является порогом, после которого сообщения с уровень детализации на уровне или ниже порога будут напечатаны, а те что выше, будут игнорироваться. Это способ фильтрации сообщений. Вы можете задать свой порог для тестбенча. Функция для изменения уровня порога set_report_verbosity_level (INT уровень).
Имя файла и номер строки. Это необязательные аргументы, роль которого заключается в обеспечении файла и номер строки содержащем информацию о произошедшем событии.
4.9.2 Сообщения о событиях (Message Actions)
Message Actions ставит соответствие каждому сообщению действие, которые определяют, как именно она обрабатывается. Действие представлено битовым вектором, в котором каждый бит представляет одно из возможных действий. Вы можете задать несколько действий, включив один или более битов в векторе. Таким образом, вы не должны помнить, какой бит за что отвечает, OVM умеет выполнять действия перечисления, которое можно использовать, чтобы указать действие. В следующей таблице описываются возможные действия:
| Action | Definition |
|---|---|
| NO_ACTION | Do not execute an action. |
| OVM_DISPLAY | Display the message on the standard output device. |
| OVM_LOG | Send the message to a file. |
| OVM_COUNT | Increment quit_count. When quit_count reaches a predetermined threshold, terminate the testbench. |
| OVM_EXIT | Terminate the testbench immediately. |
| OVM_CALL_HOOK | Call the appropriate hook function. |
| OVM_STOP Call | $stop after the message has been processed. |
quit_count и max_quit_count хранятся в глобальной месте. Вы можете изменить max_quit_count со следующей функцией:
set_max_quit_count(int q);
Сочетание статуса сообщения и идентификатор определяют выполняемое действие. Обработчик сообщений держит набор таблиц, которые определяют действия и файл направления сообщений по идентификатору и серьезности. (Мы вскоре увидим, как эти таблицы созданы.) Во-первых, обработчик сообщения смотрит, если есть действие, указанное для комбинации идентификатора и тяжесть в сообщении. Если его нет, то обработчик сообщения смотрит, если есть действие, указанное только для идентификатора. Если он не находит, то он ищет действий по степени тяжести. OVM объекты сообщений гарантируют, что всегда есть действие для каждой степени тяжести. Действия по умолчанию показаны в следующей таблице.
| Severity | Default Action |
|---|---|
| OVM_INFO | OVM_DISPLAY |
| OVM_WARNING | OVM_DISPLAY |
| OVM_ERROR | OVM_DISPLAY или OVM_COUNT |
| OVM_FATAL | OVM_DISPLAY или OVM_EXIT |
Только действия по умолчанию, определяются тяжестью, как показано в таблице выше. Вы должны установить любые другие действия по идентификатору или комбинацию идентификатора и тяжесть с помощью функций (собственных, сами разрабатываем нужные функции), предназначенными именно для этой цели.
4.9.3 Message Files
Для отправки сообщений в файл, необходимо сначала открыть файл и изменить соответствующие меры сообщение для OVM_LOG.Удобное место, чтобы сделать это в методе компонента build(), например:
class component extends ovm_component; FILE f; function void build(); f = $fopen("logfile", "w"); set_report_default_file(f); set_report_severity_action(OVM_INFO, OVM_LOG); set_report_severity_action(OVM_WARNING, OVM_LOG); set_report_severity_action(OVM_ERROR, OVM_LOG); set_report_severity_action(OVM_FATAL, OVM_LOG | OVM_EXIT); endfunction
function void report(); $fclose(f); endfunction
4.9.4 Обработчик сообщений (Message Handlers)
Каждое сообщение объекта имеет обработчик сообщений (ovm_report_handler), связанный с ним. В докладе обработчик напрямую не доступны пользователю, хотя и содержит локальные данные, что состояние объекта отчета. В объект сообщения не содержит в себе данных отчета, только интерфейс который посылает отчет, то есть функции, работа с которыми передана в обработчику. Чтобы проиллюстрировать эту концепцию, давайте посмотрим на примере иерархические связи, которые мы обсуждали в разделе 4.2.1. Они, как и все иерархии компонентов, имеют обработчик сообщений, связанный с каждым компонентом.
Чтобы изменить характеристики отчетов по отдельным компонентам, необходимо изменить только отбработчик сообщений. Например, инициирующий данный вызов в компоненте sink2:
set_report_id_action(“fsm”, OVM_LOG);
вызывает все сообщения с идентификатором "fsm" должны войти в файл. Поскольку этот вызов был сделан в sink2, это относится только к сообщениям которые выдают sink2. Сообщения которые выдаются от любой другой компонент в этом тестбенче не влияют, даже если они также имеют "fsm" идентификатор. Чтобы сделать аналогичные изменения на по всей суб-иерархии, вы можете оформить тот же вызов на каждый компонент, или вы можете позвонить в иерархическом эквивалент set_report_id_action () метод. В этом случае, вы могли бы назвать:
set_report_id_action_hier(“fsm”, LOG);
Если вы сделаете этот призыв в sinker, вы будете влиять на sinker и все компоненты в иерархии под ним. На рисунке ниже, закрашены отработавшие обработчики сообщений.
В следующей таблице приведены все методы для изменения обработчика сообщений и файлов и их иерархические эквиваленты.
| Local Method | Hierarchical Method |
|---|---|
| set_report_verbosity_level | set_report_verbosity_level_hier |
| set_report_default_file | set_report_default_file_hier |
| set_report_severity_action | set_report_severity_action_hier |
| set_report_id_action | set_report_id_action_hier |
| set_report_severity_id_action | set_report_severity_id_action_hier |
| set_report_severity_file | set_report_severity_file_hier |
| set_report_id_file | set_report_id_file_hier |
| set_report_severity_id_file | set_report_severity_id_file_hier |
4.9.5 Переключение потока управления (Altering the Flow of Control)
Most of the time when you issue a report, the report is displayed or sent to a file, and then control resumes at the next sequential statement. There are occasions when you’ll want to alter the flow of control based on a message that is issued. The most obvious case is terminating the testbench. The EXIT action terminates the testbench immediately after the message is sent to its final destination. The action COUNT increments quit_count, and the testbench terminates when quit_count reaches max_quit_count. Typically, you will use these actions to do things like prevent an errant program from looping indefinitely in an error state, or prevent cascading error messages from obfuscating the source of an error.
В большинстве случаев, когда вы выдаете сообщение, сообщение отображается или отправляется в файл, а затем управление возобновляется в последующих состояниях. Есть случаи, когда вы хотите изменить поток управления основываясь на выдаваемых сообщениях. Наиболее очевидный случай это прекращение выполнения тестбенча. EXIT действие заканчивается испытательный стенд сразу после отправки сообщения до конечного пункта назначения. Действие COUNT шагом quit_count, и испытательный стенд заканчивается, когда quit_count достигает max_quit_count. Как правило, вы будете использовать эти действия делать вещи, как предотвратить странствующий программу из цикла неопределенное время в состоянии ошибки, или предотвратить каскадные сообщения об ошибках из запутывания источник ошибки.
