Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Верификация цифровых устройств. Курс лекций. Учебное пособие
.pdf
ное тестовое окружение в общем случае должно выполнять следующие шаги:
1. Генерация входных воздействий.
2. Передача воздействий на тестируемый блок (DUT).
3. Захват с DUT ответной реакции.
4. Анализ полученного ответа.
5. Корректировка тестовых воздействий на основе анализа.
Разумеется, отдельные шаги могут пропускаться в зависимости
от целей и задач разрабатываемого теста. Например, корректировка
тестовых воздействий может выполняться вручную для уточнения
каких-либо моментов в работе устройства, а подача воздействий в
DUT может быть совмещена с их генерацией.
В процессе верификации возможны два подхода к генерации
входных воздействий. Первый, традиционный, подход – применение направленных тестов. При данном подходе инженерверификатор анализирует спецификацию оборудования и пишет
план проверки со списком тестов, каждый из которых концентрируется на наборе связанных функций. Далее, следуя намеченному
плану, онтесты, формирующие необходимые для осуществления
проверяемых функций вектора тестовых воздействия на DUT. Затем выполняется моделирование DUT с помощью векторов и вручную просматриваются полученные на выходе файлы журналов и
временные диаграммы, чтобы убедиться, что проект соответствует
ожиданиям. Как только тест работает правильно, он помечается в
плане проверки как прошедший и инженер переходит к следующему.
Такой подход обеспечивает стабильный прогресс в тестировании, так как функции устройства покрываются тестами последовательно. Более того, написание каждого отдельного вектора тестовых воздействий не требует наличия какой-либо тестовой инфраструктуры. Для многих проектов такого подхода вполне достаточно, чтобы при наличии времени и ресурсов полностью покрыть тестовый план.
Из графика на рис. 1.1 видно, что покрытие теста линейно увеличивается с увеличением тестов. Каждый тест направлен на тестирование конкретной функции устройства. При наличии достаточного количества времени и ресурсов постепенно направленное
тестирование покрывает весь функционал устройства.
– 11 –
Рис. 1.1. Зависимость покрытия от времени
при направленном тестировании
Но что делать, если на выполнение направленных тестов нет достаточно времени или ресурсов? Из рис. 1.1 видно, что на всем
протяжении тестирования время и покрытия связаны линейно: если
проект увеличивается в два раза, то и требуемое для его тестирования время удваивается.
Одновременно с этим покрытие направленных тестов ограничено тестовым планом. Это означает, что проверяются только те случаи и ситуации, которые верификатор сумел предусмотреть в поведении устройства. На рис. 1.2 приводятся весь возможный функционал устройства, проверяемые тестами функции и обнаруженные
ошибки. Как видно из рисунка, тесты покрывают далеко не весь
функционал устройства, и при этом каждый тест направлен на проверку лишь небольшого количества функций устройства.
Рис. 1.2. Покрытие устройства направленными тестами
– 12 –
Второй подход, применяемый при построении тестов, – случайное тестирование. Методология этого подхода строится на
следующих взаимосвязанных принципах:
1. Генерация случайных воздействий.
2. Функциональное покрытие.
3. Многоуровневая модель тестового окружения.
4. Общее тестовое окружение для всех тестов.
5. Разделение тестов и тестового окружения.
Направленные тесты позволяют находить ошибки, которые инженер ожидает найти в системе. При использовании же случайных
тестовых воздействий возможно обнаружить ошибки, существование которых даже не предполагалось в проекте. Использование
случайных воздействия приводит к необходимости сбора функционального покрытия – механизма, позволяющего оценить, какой
функционал устройства уже покрыт, а какой еще нет. Кроме того,
требуется механизм автоматического прогнозирования и анализа
результатов, в качестве которого обычно выступает эталонная модель устройства. Построение такого тестового окружения – не простая задача, и одним из способов ее упростить и избежать ошибок
является применение многоуровневой модели тестового окружения, что позволяет разбивать задачу на части.
Поскольку создание тестового окружения требует много времени, то логично создавать общее окружение для нескольких тестов.
Такое окружение должно иметь механизмы управления, с помощью которых каждый тест сможет выполнить необходимые ему
последовательности воздействий на DUT. Сами тесты при этом отделены от тестового окружения.
Создание такого тестового окружения занимает больше времени, чем при традиционном подходе. В результате может возникнуть значительная задержка, прежде чем можно будет запустить
первый тест. На рис. 1.3 приведена зависимость покрытия от времени.
Как видно, начальные временные затраты на создание тестового
окружения существенны, но вскоре это окупается. Причина в том,
что все тесты используют общее, разделяемое тестовое окружение.
Таким образом, создание нового теста сводится к формированию
необходимых ограничений на генерируемые тестовым окружением
воздействия, что зачастую может поместиться в несколько строк.
– 13 –
Рис. 1.3. Зависимость покрытия от времени при случайном тестировании
Помимо общего ускорения работы по проекту, применение случайного тестирования позволяет также увеличить область покрытия тестов, поскольку входные воздействия не ограничены заданным набором, как при направленных тестах.
Несмотря на то, что тестирование называется случайным, на
входы устройства подаются не совсем случайные значения. Однако, если для направленного теста инженер ограничивает входные
значения строго заданными значениями, то при случайном тестировании ограничивается множество разрешенных значений и
из этого множества выбираются случайные.
Например, для направленного теста при проверке работы памяти тест будет записывать данные Д по заданному адресу А. При
случайном тестировании инженер ограничивает область допустимых адресов и данных, после чего тест записывает случайные данные по случайному адресу в рамках заданных ограничений. На
рис. 1.4 приведено тестовое покрытие при случайном тестировании.
Из рис. 1.4 видно, что случайный тест часто охватывает более
широкое пространство, чем направленный. Это дополнительное
покрытие может перекрывать другие тесты или исследовать новые
области, исследование которых не планировалось. И в этих новых
областях могут быть найдены новые ошибки, которые были бы
пропущены направленными тестами. Если новая область недопустима, нужно написать более строгие ограничения, чтобы предотвратить недопустимые входные воздействия на DUT. Тем не менее,
– 14 –
возможно, все еще придется написать несколько направленных тестов, чтобы найти случаи, не охваченные случайными тестами.
Рис. 1.4. Тестовое покрытие при случайном тестировании
Говоря про генерацию случайных тестовых воздействий, в
первую очередь думаешь о случайных данных и адресе. Однако это
не приведет к значительному увеличению покрытия теста. Случайным образом следует задавать и следующие вещи:
1. Конфигурация устройства.
2. Конфигурация окружения.
3. Входные данные.
4. Нарушения протокола и ошибки.
5. Временные параметры.
Конфигурация устройства и конфигурация окружения являются
важными параметрами – если тест проверяет работу устройства
только после сброса, когда все регистры приведены в заданное
начальное состояние, то существует высокий шанс пропустить
ошибку, которая появляется после длительной работы устройства.
Если проверять устройство на работу только с одной конфигурацией окружения, тогда как спецификация допускает различные, то это
также приведет к пропуску ошибок.
– 15 –
Про необходимость случайного задания входных данных упоминалось ранее.
Важно также проверять работу устройства в условиях нарушения протокола: как поведет себя система, если пришли некорректные данные или команда, возникла ошибка в транзакции на шине и
т.п. Кроме того, тестовое окружение должно контролировать соблюдение протоколов самим устройством, например, выдавая предупреждения при нарушении.
Даже при функциональном моделировании следует учитывать
временные параметры. Если какой-либо протокол предполагает
передачу данных с переменной задержкой, надо задавать эту задержку случайным образом. Работа на разных частотах позволит
выявить некорректные переходы между частотными доменами или
ошибки, когда одна часть схемы не справляется с потоком данных,
поступающих на более высокой частоте.
В заключение следует отметить такой параметр как «семя». Если запускаем случайное тестирование, генерируем случайные последовательности данных, то должны иметь возможность этот тест
повторить. С другой стороны, запуская несколько тестов одновременно, нужно быть уверенными, что они не будут дублировать
друг друга и выполнять тест с одинаковыми входными параметрами. Для этого все случайные значения в тесте должны зависеть от
передаваемого в тест параметра – «семя». Запуск тестов с разным
значением семени позволит получить запуски с разными данными.
А при необходимости повторного запуска какого-либо набора,
например, для подтверждения/уточнения ошибки, знание значения
семени позволит сделать это без каких-либо сложностей.
– 16 –
Лекция 2. SystemVerilog – основы языка
Введение
Вторая лекция курса посвящается изучению общей структуры
тестового окружения и уровней абстракции, которые приводят к
такому его разделению. Рассматриваются базовые типы данных
языка SystemVerilog, в том числе и все виды массивов.
2.1. Структура тестового окружения
При выполнении моделирования тестовое окружение «оборачивается» вокруг тестируемого устройства, как это было бы при подключении тестового анализатора к реальной системе. Отличие заключается в уровнях абстракции, на которых работает тестовое
окружение: оно должно переводить транзакции с высоких уровней
абстракции в битовые последовательности и обратно.
Что должно входить в тестовое окружение? Оно состоит из нескольких функциональных моделей шин (BFM), которые можно
рассматривать как компоненты тестового окружения: для DUT они
выглядят как реальные компоненты, но являются частью теста, а не
дизайна RTL. Если реальное устройство подключается к шинам
AMBA, USB, PCI и SPI, то необходимо встроить эквивалентные
компоненты в тестовое окружение, чтобы они могли генерировать
воздействия в соответствии с протоколами шин и анализировать
реакции DUT. Это не детализированные, синтезируемые модели, а
высокоуровневые транзакции, которые подчиняются протоколу и
выполняются быстрее. Хотя возможно и использование синтезируемых моделей для размещения, например, на ПЛИС.
Ключевой концепцией любой современной методологии верификации является многослойное тестовое окружение. Хотя разработка такого окружения может показаться более сложной, но в общем это упрощает задачу, разделив код на более мелкие части, которые можно разрабатывать отдельно. Не надо пытаться написать
одну подпрограмму, которая может случайным образом генериро-
– 17 –
вать все типы стимулов, как допустимых, так и не допустимых. Такая система очень сложна в управлении и контроле и будет иметь
много внутренних ошибок.
Многослойное тестовое окружение может включать в себя следующие уровни:
1. Уровень сигналов.
2. Уровень команд.
3. Функциональный уровень.
4. Уровень сценариев.
5. Уровень теста.
Применение уровней абстракции позволяет разделить функционал тестового окружения и упростить его создание и отладку, а
также дает возможность повторного использования отдельных
компонент. На рис. 2.1 приведена структура тестового окружения с
учетом применения различных уровней.
Уровень сценария
Функциональный
уровень
Уровень команд
Уровень сигналов
Рис. 2.1. Структура уровней тестового окружения
Генератор
Агент Табло Проверка
Утверждения МониторДрайвер
DUT
Окружение
Самый нижний – уровень сигналов. К данному уровню относится подключение тестируемого устройства и взаимодействие с
ним на уровне отдельных сигналов.
– 18 –
Следующий, более высокий уровень – командный. Входы DUT
управляются драйвером, который выполняет отдельные команды,
такие как чтение или запись, и формирует необходимые сигналы.
Выход DUT анализируется монитором, который принимает сигналы и преобразует их в команды в составе тестового окружения.
Утверждения (assertions) также находятся на уровне команд, поскольку они смотрят на отдельные сигналы, но ищут ошибки по
всей команде.
Таким образом, командный уровень – это граница между моделированием сигналов, которое привязано к модельному времени, и
транзакциями, которые к модельному времени не привязаны.
Функциональный уровень располагается после командного. В
его состав входит блок агента, который получает транзакции более
высокого уровня, такие как чтение или запись DMA, и разбивает их
на отдельные команды. Эти команды также отправляются на табло,
которое прогнозирует результаты транзакции. Средство проверки
сравнивает команды с монитора с теми, которые находятся на
табло.
Функциональный уровень управляется генератором на уровне
сценария. Что такое сценарий? Работа в качестве инженераверификатора заключается в том, чтобы убедиться, что это устройство выполняет поставленную задачу. Примером устройства может
является MP3-плеер, который может одновременно воспроизводить
музыку из своего хранилища, загружать новую музыку с хоста и
реагировать на ввод от пользователя, такой как регулировка громкости и управление треками. Каждая из этих операций является
сценарием. Загрузка музыкального файла выполняется в несколько
этапов: чтение и запись управляющего регистра для настройки
операции, несколько операций записи в DMA для передачи песни,
а затем другая группа операций чтения и записи. Сценарий тестового окружения координирует все эти шаги со случайными ограниченными значениями для таких параметров, как размер дорожки и
место в памяти.
Все перечисленные выше компоненты составляют тестовое
окружение DUT, оно обозначено пунктиром на рис. 2.1. Это тестовое окружение может дорабатываться при добавлении тестов,
например, внесением новых сценариев, но оно остается общим для
всех тестов. Оно имеет механизмы для управления, которые позво-
– 19 –
лят тестам настраивать это окружение под себя, формируя необходимые воздействия на DUT.
Самый верхний – уровень тестов. Его структура приведена на
рис. 2.2.
Рис. 2.2. Уровень теста
Тест управляет параметрами и ограничениями тестового окружения, заставляя его генерировать необходимые тестовые воздействия. Также к уровню теста относится сбор функционального покрытия – эта часть меняется в зависимости от тестируемой части
проекта, поэтому она находится за пределами тестового окружения.
Далее не всегда требуется реализовывать все слои теста – все
зависит от сложности тестируемого устройства: для простых
устройств может быть достаточно и одного агента, тогда как для
сложных DUT, сочетающих в себе несколько протоколов, может
потребоваться создание отдельных слоев для каждого протокола.
Например, для протоколов TCP, IP и Ethernet может потребоваться
создание отдельного слоя для каждого из них.
– 20 –
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]