В среднем половина времени разработки для ПЛИС тратится на верификацию. Мы знаем, что разработка архитектуры важна и для качества проекта, и для времени разработки. Таким образом очевидно, что то же применимо и к тестбенчу. Кроме того интересен факт того, что половина времени верификации тратится на отладку. Это значит, что потенциально можно улучшить верификацию в общем и отладку в частности, и уменьшить временные затраты. Методология UVVM (the open source Universal VHDL Verification Methodology) была разработана чтобы решить эту проблему и значительно уменьшить время верификации, тем самым улучшая качество продукта. UVVM предоставляет очень простую и мощную архитектуру, которая позволяет разработчкам строить их собственные тестбенчи и тестовые сценарии намного быстрее. Полезные ссылки:

• https://uvvm.org/ - сайт разработчиков UVVM
• https://github.com/UVVM/UVVM - репозиторий с исходным кодом UVVM

Далее рассмотрим на сколько просто понять и начать исползовать предложенную методологию. Также рассмотрим как UVVM поможет нам сделать лучше тестбенчи и в то же время уменьшить рабочую нагрузку.

Основные поставщики САПР говорят о пробеле в верификации и предоставляют решения чтобы решить эту проблему. К сожалению, они предпочитают решение, которое является сложной методологией, называемой UVM (Universal Verification Meyhofology). Эта методолгоия требует изучения дополнительного языка SystemVerilog и покупкт очень дорогих инструментов. Подовляющее большенство FPGA разработчиков в Европе используют VHDL для разработки и верификации (60% и 50% соответвенно во всём мире) и нет причин менять это.

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

Люди часто говорят об эффективном написании кода, но это не правильный фокус. Написание кода - это маленький фрагмент сложного модуля, либо FPGA разработки, отличие одного подхода от другого имеет относительно небольшой эффект на общую эффективность разработки. Что на самом деле важно:

• Обзорность, читаемость: простое понимание тест harness и того, как работает тестбенч.
• Модифицируемость, поддерживаемость и расширяемость: простота модификации или расширения функциональности.
• Отлаживаемость: хорошая поддержка для поиска корневой причины проблемы.
• Переиспользуемость: эффективное переиспользование между различными модулями тестбенчей, из block level тестбенчей в top level тестбенче, из одного проекта в другом, и между различными модулями верификации (Verification Components).

Если мы углубимся в деталли шаг за шагом, то мы увидим что некоторая функциональность всегда требуется для любого хорошего тестбенча:

• Обработка предупреждений: чтобы гарантировать, что любая потенциальная проблема помечается и выдаётся соответствующее предупреждение. Эти проблемы также должны быть посчитаны, суммированы и обработаны раличными спосабами.
• Логирование:чтобы позволить выдавать простые сообщения о конкретных действиях, а также и детализированные сообщения о прогрессе. Может уменьшить время отладки в разы, когда перед предупреждением выдаётся детальная информация о транзакции в структурированном виде.
• Проверка значений сигналов: наиболее общая часть во всех тестбенчах – проверка реакций проаеряемой системы.
• Проверка сигналов во времени: важно, например, для обеспечения того, чтобы не было неожиданных импульсов, либо чтобы сигнал был стабильным в течение некоторого периода времени.
• Ожидание значений, либо изменений: необходимо, например, чтобы ожидать прерывания, либо определенного значения. Необходимо иметь таймаут, чтобы избежать вечного ожидания (зависания).

Это всё и многое другое поддерживается в библиотеке "UVVM Utility", которая входит в UVVM и это является базисом для более продвинутых возможностей.

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

-- In test sequencer as a noraml progress msg log("Checking Registers in UART");

BV:   160ns   uart_tb   Checking Registers in UART

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

-- In test sequencer as a section header log(ID_LOG_HDR, "Checking Registers in UART");

BV:   60ns   uart_tb   Check defaults for all registers
BV:----------------------------------------------------

Предоставляются многочисленные варианты комманды check_value() для различных типов сигналов, с возвращаемым значением, либо без него, и некоторые более продвинутые опции.

-- E.g. inside the test sequencer check_value(dout, x"00", ERROR, "dout must be default inactive");

BV:   60ns   irqc_tb  check_value(slv x00)=> OK.
                      dout must be default incative

Сообщение об ошибке:

BV:====================================================
BV: ERROR:
BV:     192 ns.  irqc_tb
BV:              value was: 'xFF'. expected 'x00'.
BV:              dout must be default inactive
BV:====================================================

Библиотека UVVM Utility предоставляет также множество других полезных комманд, которые можно найти в PDF документе "Quick Reference" (util_quick_ref.pdf), который постовляется вместе с UVVM. В этом документе можно найти обзор всех доступных комманд и типов, а также каждую команду с подробным описанием для всех возможными перегрузок, примерами и комментариями.

Пример использования комманды await_value():

await_value(irq, '1', 0 ns, 2* C_CLK_PERIOD, ERROR, "Interrupt expected immediately");

Пример описания из документа "Quick Reference" для комманды await_value():

target(sl),   exp(sl),  [match_strictness],  min_time, max_time, [alert_level], msg, [scope, (etc.)]
target(slv),  exp(slv), [match_strictness],  min_time, max_time, [alert_level], msg, [scope, (etc.)]
target(bool), exp(bool), min_time, max_time, [alert_level], msg, [scope, (etc.)]]
target(u),    exp(u),    min_time, max_time, [alert_level], msg, [scope, (etc.)]
target(s),    exp(s),    min_time, max_time, [alert_level], msg, [scope, (etc.)]
target(int),  exp(int),  min_time, max_time, [alert_level], msg, [scope, (etc.)]
target(real), exp(real), min_time, max_time, [alert_level], msg, [scope, (etc.)]

await_value(bol, true, 10 ns, 20 ns, “Waiting for bol to become true”);
await_value(slv8, “10101010”, MATCH_STD, 3 ns, 7 ns, WARNING, “Waiting for slv8 value”);

В левой колонке (Parameters and examples) показаны параметры процедуры, каждая строка соответсует одной перегрузке. И затем слудует два примера использования. В крайней правой колонке даны комментарии и объяснения.

Важно то, что тесбенч будет всегда сообщать как минимум о падении или успешном прохождении, но также предпочтительно выводить итоговый отчёт обо всех предупреждениях:

============================================================
BV:  ***  SUMMARY OF ALL ALERTS  ***
BV:  =======================================================
BV:                    REGARDED  EXPECTED  IGNORED  Comment?
BV:    NOTE        :       0        0         0     ok
BV:    TB_NOTE     :       0        0         0     ok
BV:    WARNING     :       0        0         0     ok
BV:    TB_WARNING  :       0        0         0     ok
BV:    MANUAL_CHECK:       0        0         0     ok
BV:    ERROR       :       0        0         0     ok
BV:    TB_ERROR    :       0        0         0     ok
BV:    FAILURE     :       0        0         0     ok
BV:    TB_FAILURE  :       0        0         0     ok
BV:  =======================================================
BV:  No mismatch between counted and expected serious alerts
BV:  =======================================================  

Библиотеку UVVM с различными примерами, документацией и дополнительной информацией можно скачать из репозитория github https://github.com/UVVM/UVVM . Ниже приведём список шагов, которые необходимо выполнить чтобы начать работу с UVVM Utility library:

1. Скачать репозиторий https://github.com/UVVM/UVVM
2. Скомпилировать UVVM Utility library
   a) В консоли вашего симулятора перейти в 'uvvm_util/script';
   b) Выполнить: 'do ../script/compile_src.do'
3. Добавить библиотеку в ваш тестбенч, добавив следующие строки до декларации entity тестбенча
   library uvvm_util;
   context uvvm_util.uvvm_util_context;
4. Теперь вы можете включить любую команду из данной библиотеки в ваш тестбенч (процесс, либо подпрограмму); например:
   log("Hello world");

Замечание:
Библиотеки UVVM были проверены на Modelsim, Rivera-PRO и GHDL, также должны работать на Questa и Active-HDL и на любых других симуляторах совместимых с VHDL-2008. Упомянутые скрипты были проверены на Modelsim. GHDL предоставляет свои скрипты для UVVM.

Стоит отметить, что САПР Xilinx ISE не поддерживает VHDL-2008. VHDL-2008 поддерживается более новой САПР Xilinx Vivado.

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

• обзорность, читаемость;
• модифицируемость, поддерживаемость и расширяемость;
• отлаживаемость;
• переиспользуемость.

По этим причинам проекты разбиваются на более-менее автономные модули в независимой функциональность, такие как, например, UART, SPI, DMA контроллер, ADC и т.д.

Эти модули (или VHDL enities/components) получают комманды от программы (software) и затем выполняют требуемые задачи, пока программа продолжает выполнение и делает что-то параллельно и совершенно независимо. Если что-то идёт не так, либо модуль нуждается во внимании, то он говорит об этом (обычно с помощью прерывания (interrupt)). В этом подходе хорошо то, что верхний уровень FPGA проекта в таком случае легко понять. Мы видим модули и знаем, что они делают, интерфейсы модуля стандартизированы (например AXI4-lite или Avalon) и запущенная программа контролирует это всё с помощью команд высокого уровня.

Очевидно, что структура проекта рассмотренная ранее является чрезвычайно эффективной и способствует хорошему качеству проекта. Однако для VHDL тестбенчей не было такой системы, либо методологии. Это основная причина того, что большинство тесбенчей довольно неструктурированы, и основная причина разработки UVVM.

UVVM отражает структуру дизайна ЦС. В результате мы имеем архитектуру тестбенча, которую легко понять, при этом сохраняются преимущества хорошей можульной стркутуры:

• Верификационные модули с хорошо понимаемой функциональностью интерфейсом;
• Стандартизированная система шин от секвенсера к верификационному модулю;
• Стандартизированный интерфейс шин на для всех верификационных модулей.

Верификационные модули в UVVM называются VVC (VHDL Verification Components). На рисунке ниже 'SBI_VVC' – Simple Bus Interface, но также это мог бы быть интерфейс 'AXI4-lite' или 'Avalon'.

Архитектура UVVM очень похожа на архитектуру FPGA дизайна с внешним программным секвенсером упомянутом ранее. Тестовый секвсенсер раздаёт команды различным VVC, так же, как и программа раздаёт команды FPGA модулям. Затем VVC делают то, что им говорят – так же, как и модули в FPGA. Обычно это означает обработку доступа к их физическому интерфейсу. Например, FPGA модуль может передавать некоторые данные, и на самом деле VVC может делать то же самое. Для нашего примера UART тестбенча, сиквенсер может послать команду на UART TX чтобы передать байт на вход UART RX.

В UVVM существует два пути для доступа к интерфейсу DUT (Device Under Test). Наиболее простой это использование базовых процедур BFM (Bus Functional Model - функциональная модель шины), как показано в строке кода ниже, где последний параметр служит как комментарий к строке кода, и при необходимости записывается в лог.

-- UART transmission command — as a BFM uart_transmit(x"4C", "Apply byte on UART RX");

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

Более продвинутый вариант называется CDM (Command Distribution Method – метод распределённых комманд). В этом случае, когда секвенсер вызывает данную процедуру, команда немедленно отправляется в VVC, который задан целевым адресом (помечен красным цветом), который определяется именем и номером экземпляра VVC, который должен выполнить эту команду.

-- UART transmission command — using VVCs
uart_transmit(UART_TX_VVCT,1,x"4C", "Apply byte on UART RX");

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

Код ниже показывает как можно написать очень маленький тест чтобы проверить одновременный доступ по всем интерфейсам. Этот пример из немного другого тестбенча, здесь VVC для UART TX и RX объединены в общий VVC для более удобного использования. Для этого случая было решено использовать дополнительный параметр для обозначения канала (RX или TX).

sbi_write(SBI_VVCT,1, C_ADDR_TX_DATA, x"A0", "Send byte UART TX"); uart_expect(UART_VVCT,1,RX, x"A0", "Check byte from UART TX"); uart_transmit(UART_VVCT,1,TX, x"A1", "Apply byte on UART RX"); wait for C_FRAME_PERIOD; sbi_check(SBI_VVCT,1, C_ADDR_RX_DATA, x"A1", "Check UART RX byte");

Во любом FPGA проекте важно иметь хорошую архитектуру верхнего уровня, однако этого недостаточно. Не менее важно иметь хорошую микроархитектуру на всех уровнях. Это применимо и для тестбенчей, и это значит, что архитектура VVC должна быть так же проста для понимания, модификации и переиспользования. И опять же – стандартизация была бы замечательна. Базовый компонент VVC состоит из блоков в желтом прямоугольнике, и это применимо абсолютно ко всем VVC.

VVC будет смотреть на CDM выше и принимать только команды, которые являются целевыми для конкретно этого VVC. Затем он поместит команду uart_transmit() в очередь и отпустит тестовый секвенсер. Executor будет выбирать команды из очереди, увидит что это команда uart_transmit(), и затем выполнит эту команду с помощью BFM используя переданные параметры.

Очень структурированная архитектура VVC даёт дополнительное преимущество. Это преимущество в том, что легко добавлять более структурированную функциональность: неважно, либо для более сложных интерфейсов, либо чтобы просто включить более удобную функциональность (как, например, различные проверки). Протокол с раздельными транзакциями, такой как Avalon MM, часто приводит к хаотичным тестбенчам, поскольку там может быть несколько запросов на чтение до получения первого ответа на чтение. Используя же VVC архитектуру рассмотренную ранее и это можно сделать достаточно просто и очень структурировано. Базовый 'executor' выбирает команды из очереди и знает, что это доступ с разделёнными транзакциями. Таким образом он вызывает процедуру запроса BFM, и в то же время передаёт команду чтения в следующую очередь. Ответный 'executor' заберёт эту команду и затем просто вызовет BFM проедуру для получения ответа на чтение и будет ждать ответа. Таким образом, может быть любое число запросов на чтение между любыми ответами на чтение, и пр иэтом всё достаточно просто и наглядно.

UVVM предоставляет скрипт для того чтобы сгенерировать VVC для новых интерфейсов. Сгенерированный код – это шаблон, в котором ясно отмечено, где пользователю необходимо добавить его собственные BFM и различные адаптации. Учитывая процедуры BFM, которые в любом случае пользователь должен описать для любого тестбенча, создание VVC с нуля должно занять около 30 минут. Если верить Doulis, то немного дольше в первый раз, но возможно 30 минут хватит в следующий раз.

Подводя итог, наиболее важные части тестбенча следующие:

• основная инфраструктура тестбенча – с логированием, предупреждениями, проверками, ожиданиями и т.д., и возможно BFM для обработки доступа по интерфейсам;
• тестовый harness верхнего уровня – для того, чтобы получить полный обзор;
• верификационные модули (где необходимо) – понимание и создание;
• тесты – написание актуальных тестов и понимание полной последовательности событий.

Первый пункт лежит на библиотеке UVVM Utility. Довольно структурированная архитектура (на верхнем уровне и внутри VVC) заботится о следующих двух пунктах. В то время, как последний и вероятно самый важный пункт (поскольку здесь надо будет потратить большую часть времени) выполняется, позволяя высокоуровневым и легко понимаемым командам контролировать весь тестбенч, включая одновременную активность на многих интерфейсах.

Для FPGA дизайна, сандартизация в течение нескольких десятилетий, используя хорошую концепцию архитектуры с регистрами управления и состояния, системой шин, автономными модулями и высокоуровневыми программными командами, привела к эффективной методолгии проектирования устройст на FPGA, а также к эффективной разработке программного обеспечения, поскольку программистам не нужно разбираться в деталях модулей, которыми они управляют. Это может казаться очевидным, что для тестбенчей проектов на FPGA мы имеем похожий сценарий, где секвенсер контроллирует множество интерфейсов. Однако VHDL тестбенчи не были стандартизированы до UVVM. Нже список того, что предоставляет UVVM , и даже стандартизирует наиболее важные аспекты:

• стандарт инфраструктуры тестбенча;
• стандарт установки и использования BFM;
• стандартный модуль управления (VVC) и интерфейс состояния;
• стандартный протокол от секвенсера к VVC;
• стандартные команды для секвенсера (для общих задач);
• стандарт внутренней архитектуры VVC;
• стандартная система очередей команд;
• стандартная обработка многопоточных интерфейсов (например с разделёнными транзакциями);
• стандартные методы синхронизации между VVC (или люыми другими процессами);
• стандартное ожидание и таймауты;
• стандарт сообщений (логирвания) и обработки предупреждений;
• стандарт многоадресных и широковещательных команд;
• стандартная поддержка отдладки;
• повторное использование стандартизированного тестбенча.

Ранее мы рассмотрели как начать работу с UVVM Utility library, рассмотрели общую концепцию работы с VVC и общую структуру тестбенча. В UVVM входит следующий набор библиотек.

Для работы с VVC нам понадобится UVVM VVC Framework, который является частью UVVM. Установка и компиляция VVC Framework

1. Скачать репозиторий https://github.com/UVVM/UVVM
2. Если UVVM был скачен как ZIP файл, то следует распаковать его в директорию по вашему выбору, но при этом следует убедиться, что все части UVVM находятся на своих местах, как показано в таблице выше.
3. Скомпилировать все библиотеки UVVM
   В консоли вашего симулятора выполнить: 'do <install_dir>/script/compile_all.do <install_dir>/script <compile_dir>' , где <install_dir> - выбранная в предыдущем пункте директория, где находятся файлы UVVM, <compile_dir> - директория, куда следуюет поместить файлы компиляции, может быть директорией проекта, можно и не указывать <compile_dir>, тогда по умолчанию файлы компиляции будут расположены рядом с исходными файлами.

Если вы хотите запустить пример тестбенча, который идёт в комплекте с UVVM, то вам следует выполнить несколько дополнительных действий

1. Скомпилировать DUT и тестбенч для UART
2. Запустить пример тестбенча для UART

Международные игроки с сильным интересом в VHDL и верификации сейчас принимают UVVM. Два основных симулятора VHDL, Aldec и Mentor Graphics, оба показывают большой интерес, Aldec уже провёл несколько вебинаров по UVVM (https://www.aldec.com/en/downloads/private/920 и https://www.aldec.com/en/downloads/private/1158). И Mentor включил презентации UVVM в их "FPGA verification day" (https://trias-mikro.de/en/dates/fpga-verification-day/). Doulos, лучший международный постовщик тренингов для FPGA и ASIC методологий, рекомендует UVVM для FPGA тестбенчей. Последним свидетельством того, что UVVM на самом деле набирает обороты, является то, что ESA (European Space Agency – Европейское космическое агенство) теперь UVVM спомощью контракта на более чем 250 000 евро на расширение UVVM, и может рекомендовать своим постовщикам использовать UVVM для верификации FPGA проектов (https://indico.esa.int/event/232/contributions/2159/). То, что UVVM набирает обороты – это сильное преуменьшение. Со второго квартала 2016 по второй квартал 2018 года (между двумя исследованиями Wilson Research Group https://www.mentor.com/products/fv/events/the-2018-wilson-research-group-asic-and-fpga-functional-verification-study) количество пользователей UVVM во всём мире резко вырасло – с долей процента в 2016 году до 10% от всех FPGA разработчиков во втором квартале 2018 года и продолжает расти.

UVVM поддерживается любыми совместимыми с VHDL-2008 симуляторами. Для опенсорс сообщество будет хорошей новостью то, что GHDL был обновлён для работы с UVVM (https://github.com/ghdl/ghdl).

Дополнительно был создан новый репозиторий для внешнего вклада в UVVM(https://github.com/UVVM/UVVM_Community_VIPs) и обмена верификационными компонентами.

Проект европейского космического агенства предоставит несколько новых и важных функций для UVVM. Некоторые уже были предоставлены, например, легко используемый, гибкий и конфигурируемый Scoreboard, и некоторые всё ещё разрабатываются, такие как watchdogs, механизм инжекции ошибок, улучшенный контроль рандомизации и функционального покрытия, и более удобная система подключения DUT моделей к harness тестбенча.

Наиболее важная функциональность, которая скоро появится – иерархические верификационные компоненты. Это позволит решить проблему использования scoreboards для проверки данных, которые проходят через DUT, когда слой коммуникации различный с двух сторон, например, когда ввод с одной стороны ориентирован на слова или байты, как в AXI4-lite или Avalon, а выход с другой стороны ориентирован на пакеты, как например Ethernet. Ирерархические верификационные компоненты позволят легко обрабатывать такие сценарии.

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

Структурированная верификация является очень важной для эффективности, качества и повторного использования. UVVM – открытый проект, который предоставляет очень струкртурированную методологию и библиотеку. UVVM даже предоставляет открытые VVC и BFM для UART, I2C, SPI, SBI, AXI4-Lite, AXI4-steam, GPIO и Avalon MM. Это даёт возможность для отличного старта любого проекта, который использует эти (либо аналогичные) периферийные устройства.