CC BY
126
УДК 004.942
ФУНКЦИОНАЛЬНАЯ ВЕРИФИКАЦИЯ СИСТЕМ НА КРИСТАЛЛЕ
ПО МЕТОДОЛОГИИ UVM
Е. В. Чупров Научный руководитель - В. Х. Ханов
Сибирский государственный аэрокосмический университет имени академика М. Ф. Решетнева Российская Федерация, 660037, г. Красноярск, просп. им. газ. «Красноярский рабочий», 31
E-mail: snair8@bk.ru
Рассматривается функциональная верификация систем на кристалле с использованием методологии UVM, где описываются основные составляющие тестового окружения. Методология UVM применялась при функциональной верификации СФ-блока контроллера протокола RMAP сети SpaceWire.
Ключевые слова: функциональная верификация, Методология UVM.
FUNCTIONAL VERIFICATION OF SYSTEMS-ON-A-CHIP USING UVM
METHODOLOGY
E. V. Chyprov Scientific Supervisor - V. Kh. Khanov
Reshetnev Siberian State Aerospace University 31, Krasnoyarsky Rabochy Av., Krasnoyarsk, 660037, Russian Federation
E-mail: snair8@bk.ru
This paper discusses the functional verification of systems-on-chip using the methodology UVM, which describes the components main of the test environment. This methodology was usedfor functional verification of the IP - block controller for the SpaceWire network RMAP Protocol.
Keywords: functional verification, UVM Methodology.
С перманентным увеличением сложности проектируемых систем на кристалле все больше времени уходит на проверку функциональности. Одной из главных проблем является процесс функциональной отладки, так как из всего цикла разработки и проектирования этой системы, на нее тратиться около 60-70 % времени [1].
Компания Mentor Graphics была одной из первых в полной мере осознавшей решающее значение функциональной верификации в современных маршрутах проектирования, разработав методологию функциональной верификации UVM (Universal Verification Methodology).
На основе предложенной методики генерируются тестовые последовательности, проверяется функциональность блоков, собирается информация о достигнутом уровне тестового покрытия и представляется возможность повторного использования тестов. Функциональная верификация при проектировании систем на кристалле является доказательством функционирования системы, согласно предъявляемому техническому заданию.
Методология UVM применялась при функциональной верификации СФ-блока контроллера протокола RMAP сети SpaceWire.
В общем виде SoC можно представить как систему, состоящую из множества разнообразных по назначению и функциям блоков.
Традиционный подход к проектированию и верификации SoC начинается с разработки спецификации на систему в целом, с последующим разбиением системы на крупные, а затем на более меньшие функциональные блоки. Каждый блок проектируется и верифицируется отдельно с последующим объединением в более крупные и затем верифицируется уже в составе системы
Секция «Автоматика и электроника»
в целом. На данном этапе проектирования SoC проверяется, соответствует ли функционирование каждого блока его спецификации.
Принимая во внимания всю сложность и многообразие применяемых блоков и функций, реализуемых на SoC, решающее значение принимает не столько верификация отдельных блоков SoC, а сколько верификация взаимодействия между собой самих блоков.
Наиболее распространенным способом верификации является тестирование с использованием тестового окружения (UVM), разработанный американской компанией Mentor Graphics.
Суть метода заключается, в том что, при построении тестового окружения используется моделирование на уровне транзакции TLM (Transaction-Level Modeling). Симуляция упрощенных моделей и скоростные, но не точные алгоритмы, применяемые в этом методе, позволяет существенно сократить временные и ресурсные издержки при малом расхождении результатов с реальными прототипами.
Компоненты тестового окружения представлены на (рис. 1), где:
1. DUT (Device Under Test) - устройство, находящееся под тестированием.
2. Пакеты данных (sequence items) - структуры данных, подаваемых на вход тестируемого устройства.
3. Драйвер (driver) - компонент, непосредственно подающий сигналы в тестируемое устройство. Драйвер получает пакеты данных и обрабатывает их. После этого он выполняет одну или несколько процедур пересылки данных в устройство. Драйвер имеет доступ к тестируемому устройству.
4. Описатель последовательности (seqence) - в зависимости от устройства и тестов он может генерировать произвольные или настраиваемые пакеты.
5. Монитор (monitor) - компонент, который собирает результаты работы устройства. Монитор имеет доступ к тестируемому устройству.
6. Генератор последовательностей (sequenser) - компонент контролирующий выполнение последовательностей и передающий пакеты данных в драйвер.
7. Компаратор (scoreboard) - компонент, анализирующий полученные результаты работы устройства, проводит оценку правильности функционирования.
8. Агент (agent) - компонент, содержащий генератор последовательностей, драйвер и монитор. Агент представляет собой универсальный компонент и используется для уменьшения времени разработки новых окружений, так как разработчику не требуется разбираться в его составляющих и подключать их к проекту поодиночке.
9. Окружение (environment) - компонент самого высокого уровня. Состоит из набора агентов и других более низкоуровневых компонентов.
Рис. 1. Основные компоненты тестового окружения
Тесгшьк' I сценарии
нсрмфикицш'ччог ик1'у.щ\'чш"
Ос-рифм катар Модель
собьтий сравнения
Конфигурация Mi)iiuio|)co6uTiili !
Д|шПи.'р тестовых последовательностей V Драйвер дощщии кпюВствей
4 z
ал-нт вчяодимх
Мовнгар событии 2
Конфигурация
Сверши к 3 тестового покрытия
Рис. 2. Блок преобразователя адресов (БПА)
В качестве примера конфигурации тестового окружения на основе методологии UVM наглядно рассмотрим верификацию Блока преобразователя адресов (рис. 2).
Тестовое окружение состоит из двух окружений агентов входных и выходных воздействий соответственно, а также верификационного окружения. Так как выходной интерфейс БПА является однонаправленным, то агент выходных воздействий находится в пассивном режиме, осуществляя лишь мониторинг выходных реакций на внешнее воздействие. Агент входных воздействий находится в активном режиме и через драйвер входных воздействий преобразует тестовые последовательности в дискретные цифровые воздействия на интерфейс БПА. Активный и пассивный режим агента, его функциональный состав и прочие настраиваемые параметры задаются в файле конфигураций тестового окружения. Предназначение драйвера тестовых последовательностей состоит в генерации пользовательских структур данных на основе ограничений, заложенных в тестовых сценариях. Связь тестового окружения с интерфейсом БПА осуществляется через карту сигналов, ставящую в соответствие именные названия портов тестового окружения и тестируемого блока. Верификатор событий через мониторы событий осуществляет контроль ошибочных реакций тестируемого блока на внешнее воздействие, для чего необходима модель сравнения. При возникновении расхождений фиксируется ошибка. Модель сравнения должна отображать эталонные реакции блока в рамках тестовых сценариев, но не обязательно должна полностью повторять его функционал. Представленная структура тестового окружения не является единственной возможной, однако концепция является достаточно универсальной и подходит для множества поведенческих моделей.
Практическое применение методологии UVM отражено в работе [2-5], где разработана функциональная верификация СФ-блока контроллера RMAP в сети SpaceWire с созданием верификационной модели и тестового окружения по средствам САПР американской компании Mentor Graphics и последующим апробированием данного блока.
Библиографические ссылки
1. Лохов А. Функциональная верификация СБИС в свете решений Mentor Graphics // Электроника: Наука, технология, Бизнес. 2004. № 1.
2. Methodologies of Functional Verification, Mentor Graphics [Электронный ресурс]. URL: http://www.mentor.com/products/fv/methodologies/ (дата обращения: 20.02.2017).
3. Арашев С. И., Рогактин Б. Ю., Барских М. Е. Современные методы функциональной верификации RTL моделей блоков СБИС микропроцессора // МЭС-2014. М., 2014.
4. Ровнягин М. М. Использование UVM для автономной верификации цифровой аппаратуры // МЭС-2012. М., 2012.
5. Ханов В. Х., Шахматов В. А., Чекмарёв С. А. Система верификации СФ-блока контроллера протокола RMAP сети SpaceWire // АПЭП-2014.
© Чупров Е. В., 2017
