Ограниченная случайная проверка

Ограниченная случайная проверка — это стратегия тестового стенда, основанная на генерации псевдослучайных транзакций для тестируемого устройства (DUT). Цель состоит в том, чтобы обеспечить функциональный охват ряда предопределенных событий за счет случайного взаимодействия с тестируемым устройством.

Open Source VHDL Verification Methodology (OSVVM) — это бесплатная библиотека VHDL, которая включает ряд удобных пакетов для создания ограниченных случайных тестовых стендов. Нас особенно интересуют RandomPkg и CoveragePck, которые мы будем использовать в этой статье. Я рекомендую посетить страницу OSVVM GitHub, чтобы узнать больше о функциях этой библиотеки.

Тестируемое устройство

Я собираюсь сразу же перейти к примеру, чтобы лучше объяснить, чем ограниченный случайный тестовый стенд отличается от классического тестового стенда, в котором используются направленные тесты. Мы создали кольцевой буфер FIFO в предыдущей статье этого блога, но мы не создали тестовый стенд с самопроверкой для проверки правильности модуля.

Мы собираемся создать правильный тестовый стенд для кольцевого буфера FIFO, который использует ограниченную случайную проверку.

Сущность модуля кольцевого буфера показана в приведенном выше коде. Мы будем рассматривать тестируемое устройство как черный ящик, а это означает, что мы не будем предполагать никаких знаний о том, как реализовано тестируемое устройство. В конце концов, эта статья о тестовом стенде, а не о кольцевом буфере FIFO.

Мы создадим экземпляр DUT в испытательном стенде, используя метод создания экземпляра объекта. Создание экземпляра тривиально, поэтому я пока опущу код, но его можно будет загрузить позже в этой статье.

Универсальные модели DUT будут сопоставлены со следующими значениями:

RAM_WIDTH:16
RAM_DEPTH:256

Стратегия тестирования

Давайте рассмотрим стратегию тестирования, прежде чем мы начнем что-либо внедрять. На изображении ниже показана основная концепция испытательного стенда, который мы собираемся создать.

Мы будем выполнять транзакции случайной записи на входной стороне тестируемого устройства. Входным данным будет присвоено случайное значение в каждом тактовом цикле, а длительность импульсов на входе разрешения записи будет произвольной.

Точно так же мы будем выполнять чтение случайным образом. Мы будем утверждать сигнал разрешения чтения в пакетах, которые длятся случайное число тактовых циклов.

Параллельно с ИУ будет поведенческая модель. Это FIFO, реализованный иначе, чем кольцевой буфер, используемый в тестируемом устройстве, но имеющий тот же интерфейс. В отличие от DUT, поведенческая модель не обязательно должна быть синтезируемой. Это дает нам возможность использовать расширенные функции программирования VHDL для его создания.

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

Наконец, мы будем собирать данные о функциональном покрытии, наблюдая за транзакциями, поступающими в DUT и исходящими из него. Функциональная точка покрытия может означать, например, одновременное чтение и запись или заполнение FIFO хотя бы один раз. Мы будем отслеживать эти события в нашем основном процессе секвенсора тестового стенда. Моделирование будет остановлено, когда произойдут все события функционального покрытия, которые мы отслеживаем.

Импорт библиотеки OSVVM

Библиотеку OSVVM можно использовать с любым симулятором, поддерживающим VHDL-2008. Возможно, он уже включен в библиотеки по умолчанию, поставляемые с вашим симулятором. Она включена в ModelSim PE Student Edition, которую можно бесплатно загрузить с сайта Mentor Graphics.

ModelSim поставляется с более старой версией OSVVM, но это нормально, в ней есть все, что нам нужно. Мы можем просто импортировать случайные пакеты и пакеты покрытия следующим образом:

Последнюю версию библиотеки OSVVM всегда можно загрузить со страницы GitHub. Сделайте это, если он не включен в ваш симулятор или если вы хотите использовать новейшие функции библиотеки.

Объявление переменных OSSVM

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

rv переменная типа RandomPType предназначен для генерации случайных значений. Нам нужен только один из них, потому что мы можем использовать один и тот же объект в каждом процессе, где нам нужно генерировать случайные значения. В последней строке кода объявляются шесть переменных типа CovPType. .

Мы объявили шесть переменных покрытия, потому что у нас будет шесть целей покрытия, мы будем называть эти объекты «бинами». Общие переменные должны быть инициализированы, прежде чем их можно будет использовать для сбора данных о покрытии. Мы делаем это, вызывая AddBins процедура для каждого из CovPType корзины.

Мы предоставляем строковое описание бина покрытия в качестве первого параметра для AddBins процедура. Эта строка снова появится в конце симуляции, когда мы распечатаем статистику для каждого из интервалов покрытия. Как вы можете видеть из текстовых описаний, мы собираемся использовать бины для проверки того, произошли ли какие-то очень специфические краеугольные случаи.

AddBins — это перегруженная процедура, которую можно использовать для создания нескольких табло в переменных bin. Однако у нас будет только одно табло, связанное с каждым бином. Поэтому мы будем использовать константу удобства ONE_BIN. в качестве параметра AddBins процедура. Это инициализирует CovPType переменные с одним бином каждая. Табло, представленные ячейками, считаются покрытыми, если события, которые они отслеживают, произошли хотя бы один раз.

Создание случайного ввода

Начнем с создания процесса, который генерирует входные данные для тестируемого устройства. Кольцевой буфер FIFO предназначен для игнорирования попыток перезаписи и пересчитывания. Следовательно, мы можем просто записывать случайные данные пачками случайной длительности. Нам не нужно думать о том, готово ли тестируемое устройство принять данные или нет.

Единственное соображение, которое принимает во внимание этот процесс, заключается в том, что тестируемое устройство не находится в состоянии сброса. Мы случайным образом включаем или отключаем сигнал разрешения записи в первой строке этого процесса, но он будет включен, только если rst равно '0' .

Последующий цикл for будет записывать случайные данные в тестируемое устройство в течение произвольного числа тактовых циклов, даже если сигнал разрешения не активен. Мы можем сделать это, потому что тестируемое устройство должно игнорировать wr_data. порт, если только wr_en сигнал '1' . После цикла for программа вернется к началу процесса, инициируя другую транзакцию случайной записи.

Выполнение случайного чтения

Процесс чтения данных из ИУ аналогичен процессу записи. Мы можем случайным образом активировать rd_en сигнал в любое время, потому что тестируемое устройство предназначено для игнорирования попыток чтения, когда оно пусто. Данные, которые отображаются на rd_data порт на самом деле не проверяется. Этот процесс управляет только сигналом разрешения чтения.

Проверка поведения

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

На изображении выше показана базовая схема такого тестового стенда. Поведенческая модель работает параллельно с ИУ. Мы используем его в качестве шаблона для проверки выходных данных тестируемого устройства.

Система FIFO

Мы будем использовать связанный список для реализации поведенческой модели. Связанные списки нельзя синтезировать, но они идеально подходят для тестовых стендов. Вы можете вспомнить Как создать связанный список в VHDL. статью, если вы постоянный читатель этого блога. Мы будем использовать код из него для реализации поведенческой модели для кольцевого буфера FIFO.

Объявление пакета для FIFO связанного списка показано в приведенном выше коде. Это защищенный тип, выполняющий три функции; Push, Pop и IsEmpty. Они используются для добавления и удаления элементов из FIFO, а также для проверки, не осталось ли в нем нулевых элементов.

Защищенные типы — это классоподобные конструкции в VHDL. Мы создадим объект связанного списка, объявив общую переменную в декларативной области тестового стенда, как показано в коде выше.

Модель поведения

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

В приведенном выше коде показано объявление двух выходных сигналов поведенческой модели. Нам не нужны какие-либо выделенные входные сигналы для поведенческой модели, потому что они такие же, как те, которые подключены к тестируемому устройству. Мы используем сигналы для эмуляции выходных данных тестируемого устройства, потому что это позволяет нам легко собирать данные о покрытии, как мы увидим позже в этой статье.

Процесс, реализующий поведенческую модель кольцевого буфера FIFO, показан в приведенном выше коде. Этот процесс будет запускаться при каждом переднем фронте тактового сигнала, если сигнал сброса не активен.

Поведенческая модель помещает новое значение в FIFO тестового стенда всякий раз, когда wr_en сигнал утверждается, пока full сигнал '0' . Точно так же логика чтения в процессе поведенческой модели работает путем прослушивания rd_en и empty сигналы. Последний управляется DUT, но мы проверим его работу в следующем процессе, который мы создадим.

Проверка результатов

Вся логика, отвечающая за проверку выходов ИУ, собрана в процессе с именем «PROC_VERIFY». Мы используем операторы утверждения для проверки того, что выходные данные тестируемого устройства совпадают с выходными данными поведенческой модели. Мы также проверяем, согласуются ли DUT и поведенческая модель, когда буфер FIFO пуст.

Код для процесса проверки показан ниже.

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

Второй блок кода проверяет, что empty сигнал, поступающий от тестируемого устройства, утверждается только тогда, когда FIFO испытательного стенда пуст. Тестируемое устройство и поведенческая модель должны согласиться с тем, что FIFO пуст или нет, чтобы этот тест прошел.

Затем следует сравнение считанных данных действительных сигналов. Тестируемое устройство и поведенческая модель должны выводить данные одновременно, иначе что-то не так.

Наконец, мы проверяем, соответствуют ли выходные данные тестируемого устройства следующему элементу, который мы извлекаем из FIFO испытательного стенда. Это, конечно, происходит только в том случае, если rd_valid сигнал установлен, что означает, что rd_data сигнал можно сэмплировать.

Сбор данных о покрытии

Чтобы управлять основным потоком тестового стенда, мы создадим процесс-секвенсор. Этот процесс инициализирует бины покрытия, запускает тесты и останавливает испытательный стенд, когда все цели покрытия будут достигнуты. В приведенном ниже коде показан полный процесс «PROC_SEQUENCER».

Во-первых, мы инициализируем объекты корзины покрытия, вызывая метод AddBins процедуры на них, как мы уже обсуждали ранее в этой статье. Затем, после сброса, мы приступаем к сбору данных о покрытии. При каждом переднем фронте тактового сигнала будет выполняться код внутри конструкции цикла.

Первый блок кода внутри цикла предназначен для сбора данных о покрытии. Мы можем вызвать ICover процедура в корзине для записи попадания в точку покрытия, которую она представляет. Если мы укажем целочисленный параметр 0 , вызов не будет иметь никакого эффекта. Если мы используем целочисленный параметр 1 , это будет считаться попаданием.

Внутри каждого из объектов корзины покрытия есть только одна «корзина», потому что мы инициализировали их с помощью ONE_BIN постоянный. Доступ к этой единственной ячейке можно получить, вызвав ICover(1). . Мы можем зарегистрировать попадание или промах в точке покрытия, преобразовав наши логические выражения в целые числа 1 или 0 используя to_integer функция

После записи данных о покрытии мы проверяем, все ли цели покрытия были достигнуты, позвонив по телефону IsCovered. работать на всех корзинах. Затем мы выходим из цикла, если все цели охвата достигнуты.

Мы удостоверимся, что тестируемое устройство пусто перед завершением теста. Для этого мы берем на себя управление процессами записи и чтения, заставляя wr_en сигнал на '0' и rd_en сигнал на '1' .

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

Запуск тестового стенда

Вы можете загрузить весь проект ModelSim со всеми файлами VHDL, используя форму ниже.

После того, как мы загрузили проект, выполнив do-файл, включенный в Zip, мы можем запустить тестовый стенд, просто набрав «runtb» в консоли ModelSim. Время выполнения тестового стенда будет случайным, поскольку цели охвата достигаются случайным образом. Однако результаты теста воспроизводимы, поскольку на самом деле используется псевдослучайная последовательность.

Мы не инициализировали начальное значение в нашем коде, а это означает, что начальное значение по умолчанию будет использоваться для генератора псевдослучайных чисел. Можно установить другое начальное число, вызвав InitSeed процедура на RandomPType объект, это создаст другую случайную последовательность.

Вывод в консоль

Вывод, напечатанный в консоли ModelSim после того, как мы дали команду «runtb», показан ниже. Во время моделирования будет происходить множество случайных перемещений в FIFO тестового стенда и извлечения из него.

Статистика для всех ячеек покрытия распечатывается, когда все цели покрытия достигнуты. В некоторые бункеры попали только один раз, а в один попали 106 раз. Но, в конце концов, каждый бин был поражен хотя бы один раз. Таким образом, мы можем знать, что все события, для которых мы определили интервалы покрытия, были протестированы и проверены.

Форма волны

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

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

Подробнее об ограниченной случайной проверке

Ограниченная случайная проверка является хорошей стратегией тестового стенда, когда тестовый вектор имеет слишком много перестановок для того, чтобы исчерпывающий тест был практичным. Случайные взаимодействия демонстрируют более естественное поведение, чем направленный угловой тест, без ущерба для точности.

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

В этой статье мы лишь немного коснулись того, что можно сделать с ограниченной случайной проверкой. Я рекомендую прочитать документы на странице OSVVM GitHub, чтобы углубиться в тему.

Я также рекомендую курс SynthWorks Advanced VHDL Testbenchs and Verification, с которым я не связан. Тем не менее, я посещал 5-дневную версию этого физического курса. Курс ведет Джим Льюис, председатель группы анализа и стандартизации VHDL (VASG). В целом, это отличная инвестиция для любой компании, которая хочет вывести свои испытательные стенды VHDL на новый уровень.

Курс FPGA — все, что вам нужно знать о курсе Dot Matrix VHDL Как создать кольцевой буфер FIFO в VHDL

VHDL