По воле судьбы я занимаюсь несколько лет верификацией конфигураций ПЛИС. И с самого начала меня поражало малочисленность информации по данному вопросу.
Если не все, то многие здесь слышали про ПЛИС. Возможно некоторые даже плотно с ними работали, но, думаю, с верификацией проектов на ПЛИС сталкивалось намного меньше людей. Сегодня я расскажу о процессе верификации.
Функциональная верификация на ПЛИС — это процесс поиска и исправления ошибок в конфигурации ПЛИС (далее прошивка). Скажете зачем нужна верификация ведь на этапе отладки ПЛИС в «железе» все можно исправить. Можно, но чрезвычайно сложно.
Во-первых в «железе» поиск функциональных ошибок достаточно трудоемкий и долгий процесс. Это приводит в задержкам завершения проекта. Для достаточно серьезного проекта отладка может занимать недели и месяцы. Верификация же позволяет найти и исправить большинство функциональных ошибок еще на этапе модели.
Скажете, что опытный разработчик ПЛИС не делает ошибок или делает их крайне мало? Делает! И достаточно много.
Верификация позволяет обнаруживать не только текущие ошибки, но и потенциальные ошибки, которые могут появиться в будущих проектах с использованием блоков.
Верификацию можно условно разделить на следующие этапы:
- Разработка ТЗ;
- Разработка плана верификации;
- Разработка ТО;
- Тестирование;
1. Разработка ТЗ на верификацию
Как известно — грамотный подход к разработке ТЗ избавляет от множества проблем на протяжении всего проекта. ТЗ на верификацию должно описывать полный и всеобъемлющий набор функций и возможностей блока, которые необходимо проверить. В идеале ТЗ на верификацию должен писать тимлид группы верификации. Это крайне важно в особенности при малом опыте работы верификатора, который будет заниматься тестированием. В состав ТЗ должно входить следующие пункты:
• перечисление всех блоков, которые будут входить в состав проекта и работу которых необходимо проверить;
• перечисление всех режимов работы, функций, возможностей проекта, которые требуют проверки;
• перечисление функций и классов ТО, которое будет использоваться повторно из других проектов (к примеру набор функций по расчету контрольных сумм или по работе с интерфейсами передачи данных).
Естественно, написание ТЗ должно начинаться после получения всей необходимой информации по данному проекту.
2. Разработка плана верификации
Процесс планирования возможно самый важный и наиболее пренебрегаемый этап функциональной верификации. Создание плана верификации определяется разработкой стратегий и тактик работы с проектом до его начала. План верификации представляет собой руководство для команды по работе с проектом. Без грамотного плана верификации команды часто выбирают неправильный путь поиска ошибок.
План верификации включает набор всех тестов с подробным описанием.
План верификации главный документ для команды верификации ПЛИС. Вся последующая работа будет основываться на этом документе. Все «забугорные монстры» систем на кристалле Synopsys и Cadence рекомендуют начинать с плана верификации перед началом разработки ТО. По сути план верификации представляет более подробное ТЗ на верификацию.
В подробном описании каждого теста должно быть указаны все необходимые программируемые параметры, текущие режимы работы, входные, выходные и эталонные данные.
3. Разработка ТО
Надо помнить, что разработка конфигурации ПЛИС и разработка ТО должны начинаться и выполняться параллельно. Данный порядок оптимален с точки зрения минимального времени разработки проекта, потому как процессы верификации занимают более 70% времени разработки всего проекта.
На основании информации всех предыдущих этапов можно приступать к созданию тестового окружения (далее ТО). ТО принято писать на языках программирования созданных специально для целей верификации, потому как они имеют весь необходимый инструментарий для этого. System Verilog один из наиболее подходящих языков. Данный язык довольно сильно похож на С++ вместе с инкапсуляцией, полиморфизмом, наследованием.
При разработке тестового окружения требуется очень рекомендуются не забывать о «реюзабельности». Если нет подходящих функций, то написать их с учетом возможного использования в будущем. Если же есть функций, то использовать. Требуется организовать ТО так, чтобы каждый тест мог модифицироваться без возможности повредить другие тесты. Это избавит от проблем в будущем, потому как в процессе проведения тестов все равно придется вводить какие-то изменения в код ТО.
4. Тестирование
На данном этапе верификатору приходится наиболее плотно работать с разработчиком. Во время проведения тестов будут обнаруживаться ошибки, а они будут обнаруживаться. Если не будут – значит ваше ТО работает неправильно. После обнаружения ошибки требуется сообщить разработчику об ошибке. Затем после исправления верификатору требуется запустить тест повторно и убедиться, что ошибка устранена.
Идеальным образом было бы использование систем баг-трекинга для осуществления связи между верификатором и разработчиком. Это позволит позже отследить какие проблемы часто встречаются в том или ином проекте, или у того или иного разработчика. А заодно и будет доказательством, что верификатор не зря ест свой хлеб.
Я полагаю следует добавить, что не каждый разработчик и не всегда признает свои ошибки. В данном случае требуется ссылаться на ТЗ, в котором должно однозначно описана работа проекта.
Автор: x0n
