OVM/OVM методология/Основы верификации — различия между версиями

Версия 20:36, 20 февраля 2013

Функционально проверить устройство означает, сравнить цель разработчика с полученным поведением на их эквивалентность. Мы считаем устройство проверенным, когда, к всеобщему удовлетворению, оно работает в соответствии с целью разработчика. Этот основной принцип часто теряется при использовании testbenches, среды контроля, отладки, моделирования , и все другие средства, применяемые в современных технологических проверках. Чтобы узнать, работает ли верно устройство, вы должны сравнить его с некоторыми известными эталоном, который представляет цель разработчика. Каждый testbench имеет своего рода эталонную модель и средство для сравнения функциональность устройство с эталоном.

Когда мы говорим "устройство", мы имеем в виду проверяемое устройство, часто называемое тестируемое устройство или DUT. Чтобы проверить, DUT, как правило, представлен форме подходящей для производства, которое может быть перенесено на кремний с помощью автоматизированных и ручных средств. Мы различаем DUT от эскиза на обратной стороне салфетки или окончательного нанесенный на кристалл, ни один из которых не может быть проверен. Эталонная модель отражает цели разработчика, то есть то, что устройство должно делать.Эталон может принимать различные формы, такие как документ, описывающий работу DUT, golden модель, которая содержит уникальный алгоритм, или assertions, которые представляют протокол.

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

1.1.1Два вопроса

Проверка устройства включает в себя два вопроса: Работает ли это? и Сделали ли мы? Это основное, и некоторые сказали бы, очевидные вопросы. Тем не менее они мотивируют всю механику каждой проверочного потока. Первый вопрос Работает ли это? Этот вопрос исходит от основной идеей проверки. Он спрашивает, Соответствует ли устройство эталону? Второй вопрос: Сделали ли мы ? Он спрашивает, довольны ли мы сравнительным анализом устройства и эталона для определения работает ли устройство согласно цели разработки, если нет, то почему. Мы используем эти ценные вопросы создания основы для разработки эффективных testbenches.

1.1.2 Работает ли устройство?

Работает ли это? Это не единственный вопрос, а категория вопросов, которые представляют природу DUT. Каждый проект будет иметь свой собственный набор работает-ли-это вопросов, чья роль заключается в определении правильного функционирования устройства. Функциональные вопросы определяют, ведет ли себя устройство должным образом в конкретных ситуациях. Мы получаем эти вопросы непосредственно из цели разработки устройства, и мы используем их, чтобы отразить цель проекта в testbench.

Рассмотрим простой маршрутизатор пакет в качестве примера. Это устройство маршрутизации пакетов от входа к одному из четырех портов вывода. Пакеты содержат адрес и порт назначения и различной длины полезной нагрузки. Каждый пакет имеет заголовок, трейлер, и два байта для циклического избыточного кода (CRC). Работает-ли-это вопросы должны должны быть следующие:

• пакет, поступающий на вход порта адресованный на имя выходного порта 3 прибыл в порт 3?
• пакет длиной 16 пришел без изменений?
• CRC байты правильны, если полезная нагрузка [0f 73 a8 c2 3e 57 11 0a 88 FF 00 00 33 2b 4c 89]?

Это простой пример полного набора вопросов. Для устройства даже такого простого как этот гипотетическое маршрутизатор, набор работае-ли-это вопросов может быть длинным. Чтобы построить план проверки и testbench, который поддерживает план, вы должны сначала перечислить все вопросы или показать как их сгенерировать, а затем выберите те, которые являются интересными.

Продолжая пример маршрутизатора пакетов, чтобы перечислить все работает-ли-это вопросы, вы можете создать диаграмму вроде этой: