Вы находитесь на странице: 1из 5

50.Интерфейсные UVC, перечислить и привести характеристики.

Для реализации процесса генерирования тестовых данных в UVM определены следующие классы:
1. Sequence item. (Данные, представляющие транзакцию)
2. Sequence (Последовательность транзакций)
3. Sequencer (Управляет последовательностью или последовательностями, запускает генерирование
данных)
4. Driver (Получает данные от секвенсора и передает их в DUT)

51.Системные UVC, перечислить и дать характеристики.


System UVCs - могут использовать интерфейсные, модульные и другие системные UVCs. Могут не
иметь своих собственных агентов и использовать другие UVCs, формируя на их основе среду
верификации большего размера для целых систем, например cpu, мосты (bridge), мобильные
телефоны

52.Структура классов UVM

53.Фазы подготовки и выполнения модели.


1. build_phase(). Создает дочерние компоненты и их конфигурация. Должна начинаться с команды
super.build().
2. connect_phase(). Устанавливаются связи между компонентами, создаются TLM соединения.
3. end_of_elaboration_phase(). Завершающая настройка testbench, выполняется проверка связей между
компонентами и инициализация.
4. start_of_simulation_phase(). Подготовка DUT к моделированию
5. run_phase(). Фаза моделирования DUT.
6. extract_phase(). Извлечение данных из различных точек среды верификации (assert и coverage).
7. check_phase(). Проверка всех неожиданных условий в среде верификации, состояний регистров, Работа
scoreboard.
8. report_phase(). Вывод сообщений о результатах моделирования
9. final_phase() - Завершение моделирования

54. Механизмы конфигурации UVM


Механизмы конфигурации
● Factory
● Config db(Configuration)
Базовый класс для UVM классов данных и иерархии, и содержит основные методы автоматизации
работы с классами библиотеки UVM. Его наследники uvm_sequence_item описывает транзакцию, а
uvm_sequence - последовательнось транзакций. Это так называемая динамическая составляющая
среды верификации. Все составляющие среду верификации компоненты построены на основе класса
uvm_component, который умеет управлять фазами моделирования. Это статические элементы среды
верификации. Конфигурация среды верификации осуществляется с помощью классов
uvm_resource_db и uvm_config_db. Для моделирования состояния регистров и памяти в проекте
предназначены классы uvm_reg, uvm_reg_block, uvm_reg_file, uvm_reg_field и uvm_mem.

55.TLM-интерфейсы в UVM
Преимущества использования TLM-интерфейсов
1) Более высокий уровень абстракции
2) Повторно используемое plug&play соединение
3) Надежность в использовании
4) Меньше кода
5) Легкость реализации
6) Более быстрое моделирование
7) Связь с SystemC
8) Могут быть использованы для разработки эталонных моделей
В то время как как DUT функционирует на уровне сигналов, то для задач верификации удобнее более
удобный уровень транзакций. На этом уровне думает и инженер, когда анализирует и описывает
функционирование системы.
UVM предлагает интерфейсы и сокеты для соединения компонентов на уровне транзакций.
Использование таких соединений позволяет изолировать один компонент от другого, что дает
возможность простой замены одного компонента в системе на другой, если они поддерживают
одинаковый интерфейс.
TLM - моделирования уровня транзакций - это стиль моделирования для построения абстрактных
моделей компонентов и систем. TLM основан на транзакциях - объектах, которые содержат
различные относящиеся к протоколу данных для абстрактного представления процессов нижнего
уровня. TLM представляет семейство абстрактных уровней описания, начиная с циклического уровня
моделирования (cycle-accurate modeling). Наиболее известные уровни TLM: циклический(cycle-
accurate), с аппроксимированным временем(approximately-timed), loosely-timed, без времени и token-
level.
TLM-1 и TLM-2.0 - два TLM-моделирования систем, которые были разработаны как промышленные
стандарты для построения моделей уровня транзакций. Оба были разработаны для SystemC и
стандартизованы с TLM Working Group от Open SystemC Initiative (OSCI). TLM-1 доведен до
стандарта в 2005, а TLM-2.0 в 2009. OSCI объединился с Accellera в 2013 и текущим стандартом
SystemC является IEEE 1666-2011.
TLM-1 и TLM-2 имеют общую базу, и часть разработчиков TLM-1, продолжили потом работать и
над TLM-2, однако они совершенно разные. TLM-1 - система для передачи сообщений. Интерфейсы
или не используют время, или основываются на подсказках для выбора времени. Ни один из
интерфейсов не использует точного временного описаний. Хотя TLM-2.0 также может передавать
данные и синхронизацию между независимыми процессами, он главным образом создавался для
высокопроизводительного моделирования memory-mapped bus-based систем. Обя эти подмножества
были реализованы в SV и доступны через UVM.

56. Sequence, sequencer, driver


UVM Sequencer контролирует поток тестовых наборов (UVM Sequence Item),генерируемый
одним или несколькими последовательностями(UVM Sequence). Служит арбитром для
контроля за потоком транзакций от нескольких последовательностей.

Секвенсер - улучшенный генератор, управляет данными, передаваемыми на выполнение


драйверу. По умолчанию секвенсер действует как простой генератор стимулов и формирует
случайные данные для драйвера. При этом для управления распределением
псевдослучайных значений может быть использован механизм ограничений. В отличие от
обычного генератора, который может формировать массивы псевдослучайных значений или
одно значение за шаг, секвенсер имеет много важных встроенных функций :
 возможность реагировать на текущее значение DUT для формирования следующих
генерируемых данных;
 возможность фиксировать порядок между данными в определенной пользователем
sequence, что формирует более структурный и значимый шаблон данных;
 разрешение изменения времени в reusable-сценариях;
 поддержка применения декларативных и процедурных ограничений в одном
сценарии;
 системный уровень синхронизации и управления несколькими интерфейсами.
1.2.7 UVM Sequence
Последовательность в UVM - это объект, определяющий процесс генерирования тестовых
последовательностей и не является частью иерархии компонентов. Последовательность
может быть временной и постоянной; может создаваться для одной транзакции или
генерировать стимулы во время всего моделирования; может функционировать
иерархически, когда один компонент sequence (родительский) вызывает другой компонент
sequence (дочерний).
Для функционирования последовательности требуется sequencer, один sequencer может
управлять несколькими последовательностями.
1.2.9 UVM Driver
Драйвер эмулирует логику, управляющую DUT, он получает от секвенсора отдельные
транзакции (UVM Sequence Item) и передает их на интерфейс DUT. Таким образом драйвер
изменяет уровень абстракции, преобразуя транзакции(transaction-level) во входные сигналы
(pin-level). От включает TLM-порт, по которому тестовые наборы от секвенсора поступают в
драйвер, и подключается к интерфейсу DUT, для управления сигналами на его входах.
Драйвер и секвенсор формируют трафик на входах DUT, но они не применяются для оценки
функционального покрытия и выполнения формальной верификации (чекеров и ассерций),
эти задачи делегируются мониторам.

57. UVM Factory.

Для целей верификации бывает удобно создавать одну общую структуру среды
верификации, а потом “на лету” заменять одни компоненты и данные на другие. Для этого в
методологии верификации адаптировали механизм фабрик(factory), существовавший до
этого в программировании. В UVM фабрики можно использовать только с классами,
производными от uvm_object и uvm_component.
Существует три базовых шага для применения factory:
1) Регистрация
2) Создание
3) Переопределение
Регистрация
Тип класса регистрируется для factory в момент своего создания. Для этого используются
предопределенные скрипты (которые уже были рассмотрены ранее).
`uvm_component_utils(class_type_name)
`uvm_object_utils(class_type_name)
для параметризируемых классов:
`uvm_component_param_utils(class_type_name #(params))
`uvm_object_param_utils(class_type_name #(params))
Регистрация необходим для переопределения по имени, переопределение по типу может
быть выполнена без регистрации. Листинг 3.1 представляет примеры классов uvm_object и
uvm_component  с регистрацией.
Листинг 1. Пример использования макросов
class packet extends uvm_object;
  `uvm_object_utils(packet)
endclass
// параметризируемый класс
class packet #(type T=int, int mode=0) extends uvm_object;
`uvm_object_param_utils(packet #(T,mode))
endclass

class driver extends uvm_component;


`uvm_component_utils(driver)
endclass
class monitor #(type T=int, int mode=0) extends uvm_component;
`uvm_component_param_utils(driver#(T,mode))
endclass
Создание
Для создания объекта или компонента в UVM рекомендуется использовать статический
метод create() вместо new().
Синтаксис :
type_name::type_id::create(string name, uvm_component parent)
Функция create() возвращает объект класса type_name. Объект переопределяется фабрикой,
основываясь на контексте определяемым полным именем родителя. Аргумент context, если
он определен, заменяет контекст родителя. Новый объект будет иметь имя листа и родителя.
Классы, основанные на uvm_object, не требуют указывать второй аргумент.
Листинг 3.2 Примеры использования функции create()
// 1
class_type object_name;
...
object_name = clss_type::type_id::create("object_name",this);
// 2
task mycomponent::run_phase(uvm_phase phase);
mytype data; // данные должны быть типа mytype или производного от него.
data = mytype::type_id::create("data");
$display("type of object is: %0s", data.get_type_name());
...
endtask

Переопределение
Переопределять классы и объекты можно основывая на строки имени или типе класса.
Существует 4 метода для переопределения. Первые два меняют тип данных для
определенного объекта класса или группы объектов, если строка full_inst_path содержит
специальные символы. Различие между ними заключается в форме задания типа класса,
через ссылку (uvm_object_wrapper) или строку. Тип uvm_object_wrapper - абстрактный
интерфейс к созданным объектам. Вторая пара методов заменяет один типа класса на
другой.
1. Переопределение объекта по индексу типа:
function void set_inst_override_by_type (uvm_object_wrapper original_type,
uvm_object_wrapper override_type, string full_inst_path )
Заменяет для объекта full_inst_path типа "original_type" на "override_type", где
"override_type" является наследником от "original_type".
2. Переопределение объекта по имени типа:
function void set_inst_override_by_name (string original_type_name,
string override_type_name, string full_inst_path )
Аргументы original_type_name и override_type_name представляют строковое имя типов,
зарегистрированных в factory. Все объектов уровня full_inst_path с типом
"original_type_name" будут заменены типом "override_type_name".
3. Переопределение типа через индекс типа
function void set_type_override_by_type (uvm_object_wrapper original_type,
uvm_object_wrapper override_type, bit replace = 1 )
Объект original_type может быть переопределен типом override_type.

4. Переопределение типа по имени


function void set_type_override_by_name (string original_type_name,
string override_type_name, bit replace = 1)
Объект с именем типа original_type_name может быть заменнен override_type_name.
Когда выполняется множественное переопределение, можно использовать аргумент replace,
чтобы управлять выполнением предыдущего переопределения. Если replace = 1, то
переопределение будет выполнено, иначе будет сохранено предыдущее переопределение.
Вместо этих функций могут быть использованы статические методы set_type_override и
set_inst_override. Первая функция заменяет тип класса глобально, для всех объектов в среде
верификации; второй только для заданного строкой объекта.
<orig_type>::type_id::set_type_override(<override_type>::get_type(),bit replace = 1);
Пример:
ubus_master_driver::type_id::set_type_override(ubus_new_master_driver::get_type);
<orig_type>::type_id::set_inst_override(<override_type>::get_type(), string inst_path);
Пример:
ubus_slave_monitor::type_id::set_inst_override(ubus_new_slave_monitor:: get_type(),
“slaves[0].monitor”);

Оценить