Если не все, то многие здесь слышали про ПЛИС. Возможно некоторые даже плотно с ними работали, но, думаю, с верификацией проектов на ПЛИС сталкивалось намного меньше людей. Сегодня я расскажу о процессе верификации.
Функциональная верификация на ПЛИС — это процесс поиска и исправления ошибок в конфигурации ПЛИС (далее прошивка). Скажете зачем нужна верификация ведь на этапе отладки ПЛИС в «железе» все можно исправить. Можно, но чрезвычайно сложно.
Во-первых в «железе» поиск функциональных ошибок достаточно трудоемкий и долгий процесс. Это приводит в задержкам завершения проекта. Для достаточно серьезного проекта отладка может занимать недели и месяцы. Верификация же позволяет найти и исправить большинство функциональных ошибок еще на этапе модели.
Скажете, что опытный разработчик ПЛИС не делает ошибок или делает их крайне мало? Делает! И достаточно много.
Верификация позволяет обнаруживать не только текущие ошибки, но и потенциальные ошибки, которые могут появиться в будущих проектах с использованием блоков.
Верификацию можно условно разделить на следующие этапы:
- Разработка ТЗ;
- Разработка плана верификации;
- Разработка ТО;
- Тестирование;
1. Разработка ТЗ на верификацию
Как известно — грамотный подход к разработке ТЗ избавляет от множества проблем на протяжении всего проекта. ТЗ на верификацию должно описывать полный и всеобъемлющий набор функций и возможностей блока, которые необходимо проверить. В идеале ТЗ на верификацию должен писать тимлид группы верификации. Это крайне важно в особенности при малом опыте работы верификатора, который будет заниматься тестированием. В состав ТЗ должно входить следующие пункты:
• перечисление всех блоков, которые будут входить в состав проекта и работу которых необходимо проверить;
• перечисление всех режимов работы, функций, возможностей проекта, которые требуют проверки;
• перечисление функций и классов ТО, которое будет использоваться повторно из других проектов (к примеру набор функций по расчету контрольных сумм или по работе с интерфейсами передачи данных).
Естественно, написание ТЗ должно начинаться после получения всей необходимой информации по данному проекту.
2. Разработка плана верификации
Процесс планирования возможно самый важный и наиболее пренебрегаемый этап функциональной верификации. Создание плана верификации определяется разработкой стратегий и тактик работы с проектом до его начала. План верификации представляет собой руководство для команды по работе с проектом. Без грамотного плана верификации команды часто выбирают неправильный путь поиска ошибок.
План верификации включает набор всех тестов с подробным описанием.
План верификации главный документ для команды верификации ПЛИС. Вся последующая работа будет основываться на этом документе. Все «забугорные монстры» систем на кристалле Synopsys и Cadence рекомендуют начинать с плана верификации перед началом разработки ТО. По сути план верификации представляет более подробное ТЗ на верификацию.
В подробном описании каждого теста должно быть указаны все необходимые программируемые параметры, текущие режимы работы, входные, выходные и эталонные данные.
3. Разработка ТО
Надо помнить, что разработка конфигурации ПЛИС и разработка ТО должны начинаться и выполняться параллельно. Данный порядок оптимален с точки зрения минимального времени разработки проекта, потому как процессы верификации занимают более 70% времени разработки всего проекта.
На основании информации всех предыдущих этапов можно приступать к созданию тестового окружения (далее ТО). ТО принято писать на языках программирования созданных специально для целей верификации, потому как они имеют весь необходимый инструментарий для этого. System Verilog один из наиболее подходящих языков. Данный язык довольно сильно похож на С++ вместе с инкапсуляцией, полиморфизмом, наследованием.
При разработке тестового окружения требуется очень рекомендуются не забывать о «реюзабельности». Если нет подходящих функций, то написать их с учетом возможного использования в будущем. Если же есть функций, то использовать. Требуется организовать ТО так, чтобы каждый тест мог модифицироваться без возможности повредить другие тесты. Это избавит от проблем в будущем, потому как в процессе проведения тестов все равно придется вводить какие-то изменения в код ТО.
4. Тестирование
На данном этапе верификатору приходится наиболее плотно работать с разработчиком. Во время проведения тестов будут обнаруживаться ошибки, а они будут обнаруживаться. Если не будут – значит ваше ТО работает неправильно. После обнаружения ошибки требуется сообщить разработчику об ошибке. Затем после исправления верификатору требуется запустить тест повторно и убедиться, что ошибка устранена.
Идеальным образом было бы использование систем баг-трекинга для осуществления связи между верификатором и разработчиком. Это позволит позже отследить какие проблемы часто встречаются в том или ином проекте, или у того или иного разработчика. А заодно и будет доказательством, что верификатор не зря ест свой хлеб.
Я полагаю следует добавить, что не каждый разработчик и не всегда признает свои ошибки. В данном случае требуется ссылаться на ТЗ, в котором должно однозначно описана работа проекта.
Комментарии (15)
ishevchuk
15.07.2015 22:28+1И с самого начала меня поражало малочисленность информации по данному вопросу.
Не соглашусь.
Прошивка FPGA является программным обеспечением (хотя тут можно поспорить, но в данном контексте сравнение уместно), следовательно её верификация сходна с верификацией любого другого ПО. По тестированию ПО есть достаточное количество статей, книг, методологий и пр.
Однако прошивка является «необычной» программой, и у нее есть нюансы, как её тестировать. И здесь нам помогают книги типа «SystemVerilog for Verification» и «Writing testbenches using systemverilog», а так же сайты типа testbench.in, ну и такие методологии верификации как UVM, которые заточены под RTL.
Так что, на мой взгляд, информация есть в сети есть :)
Мне кажется, полезнее для сообщества будет показать свой тестбенч (или его часть), рассказав, что, как и почему вы делаете, т.к. реальная жизнь в большом серьезном проекте очень часто расходится с советами из книжек и статей в интернете)
x0n
15.07.2015 22:45+1Тут моя промашка. В уме писалось «русскоязычной информации», а было написано просто «информации». Безусловно на английском хватает литературы, однако в сравнении с литературой для тестирования «обычного» ПО, информации крайне мало.
Изначально я планировал серию статей. Так что в будущих статьях я обязательно коснусь каких-либо практических решений.
slovak
15.07.2015 22:48Сперва Вы приводите определение:
Функциональная верификация на ПЛИС — это процесс поиска и исправления ошибок
А потом:
потому как процессы верификации и поиска ошибок
Ни то, ни другое не является верным.
Верификация — это не поиск и устранение ошибок, а доказательство соответствия функционирования продукта согласно ТЗ.
Верификация — это подтверждение соответствия конечного продукта предопределённым эталонным требованиям. Простыми словами — мы создали продукт правильно, согласно требованиям.
Рассматривается качество продукта.
Валидация — это процесс приведения доказательств того, что требования конкретного внешнего потребителя или пользователя продукта, услуги или системы удовлетворены.
Простыми словами — мы создали правильный продукт, используя правильные требования. Рассматривается качество всего процесса создания продукта.x0n
15.07.2015 23:01потому как процессы верификации и поиска ошибок
Это я поправил.
Функциональная верификация на ПЛИС — это процесс поиска и исправления ошибок
Здесь мне хотелось описать данное определение более понятными словами, передать суть.
Верификация — это не поиск и устранение ошибок, а доказательство соответствия функционирования продукта согласно ТЗ.
Тут слово «доказательство» неуместно, на мой взгляд. То есть мне, как верификатору, дали продукт и я должен доказать, что продукт правильно работает? Так не годится. Верификатор должен проверить соответствие продукта ТЗ, а если продукт не соответствует, то сообщить тому, кто это исправит.
fpgaFAE
16.07.2015 11:00Статья похожа на перевод рекламного буклета. А литература по этой, несомненно, важной теме имеется. Нпример, вот эта книжечка
x0n
16.07.2015 14:58По поводу наличия информации я уже в комментариях поправился на отсутствие русскоязычной литературы.
А по поводу рекламного буклета. Сожалею, что вам так показалось. Надеюсь следующие статьи не будут создавать такое впечатление.fpgaFAE
16.07.2015 17:57Так же можно посетовать на отсутствие русскоязычного ПО (((
Данная профессия подразумевает знание английского хотя бы на уровне технической терминологии в области дизайна FPGA.x0n
16.07.2015 19:00Есть огромная разница в усвоении информации для русскоязычного специалиста на английском и на русском. Даже для того, кто неплохо знает технический английский. Надеюсь с этим вы согласитесь?
ПО на русском совсем уж неуместно, потому как большинство терминов все-таки англоязычны.
Так что тут бессмысленно сравнивать ПО и литературу.
Можно ведь посетовать еще на англоязычные операторы «while», «for» итп. Вряд ли это кого-то будет напрягать.
valeriyk
16.07.2015 16:03+1Как-то «верификация» в заголовке плавно перетекла в «функциональную верификацию» в тексте. Про другие виды верификации вы нам не расскажете?
x0n
16.07.2015 16:22Не могу не согласится с данной критикой. Изначально стоило в заголовке указать функциональную верификацию.
О формальной верификации можно было упомянуть, однако, к сожалению, ей уделяется намного меньше времени. Незаслуженно.
А если и уделяется, то данный термин не фигурирует.
nckma
15.07.2015 21:01+2Честно говоря показалось, что какая-то поверхностная статья. Хотя бы пример какого нибудь тестбенча… Хоть вот такой www.marsohod.org/index.php/11-blog/113-icarus
x0n Автор
15.07.2015 22:48Нельзя не согласится, но хотелось бы для начала сделать этакое «введение» в предметную область.
В следующих статьях обязательно подробнее коснусь разработки тестбенчей.
Fen1xL
15.07.2015 21:18Правильно ли я понял, что верификация — это набор testbenchей, который формально описан в виде документа. Верификация выполняется только на этапе симуляции?
x0n Автор
15.07.2015 22:40Верификация — это весь процесс в целом. Начиная от создания ТЗ до успешного окончания всех тестов.
ishevchuk
15.07.2015 22:28+1И с самого начала меня поражало малочисленность информации по данному вопросу.
Не соглашусь.
Прошивка FPGA является программным обеспечением (хотя тут можно поспорить, но в данном контексте сравнение уместно), следовательно её верификация сходна с верификацией любого другого ПО. По тестированию ПО есть достаточное количество статей, книг, методологий и пр.
Однако прошивка является «необычной» программой, и у нее есть нюансы, как её тестировать. И здесь нам помогают книги типа «SystemVerilog for Verification» и «Writing testbenches using systemverilog», а так же сайты типа testbench.in, ну и такие методологии верификации как UVM, которые заточены под RTL.
Так что, на мой взгляд, информация есть в сети есть :)
Мне кажется, полезнее для сообщества будет показать свой тестбенч (или его часть), рассказав, что, как и почему вы делаете, т.к. реальная жизнь в большом серьезном проекте очень часто расходится с советами из книжек и статей в интернете)x0n Автор
15.07.2015 22:45+1Тут моя промашка. В уме писалось «русскоязычной информации», а было написано просто «информации». Безусловно на английском хватает литературы, однако в сравнении с литературой для тестирования «обычного» ПО, информации крайне мало.
Изначально я планировал серию статей. Так что в будущих статьях я обязательно коснусь каких-либо практических решений.
slovak
15.07.2015 22:48Сперва Вы приводите определение:
Функциональная верификация на ПЛИС — это процесс поиска и исправления ошибок
А потом:
потому как процессы верификации и поиска ошибок
Ни то, ни другое не является верным.
Верификация — это не поиск и устранение ошибок, а доказательство соответствия функционирования продукта согласно ТЗ.
Верификация — это подтверждение соответствия конечного продукта предопределённым эталонным требованиям. Простыми словами — мы создали продукт правильно, согласно требованиям.
Рассматривается качество продукта.
Валидация — это процесс приведения доказательств того, что требования конкретного внешнего потребителя или пользователя продукта, услуги или системы удовлетворены.
Простыми словами — мы создали правильный продукт, используя правильные требования. Рассматривается качество всего процесса создания продукта.x0n Автор
15.07.2015 23:01потому как процессы верификации и поиска ошибок
Это я поправил.
Функциональная верификация на ПЛИС — это процесс поиска и исправления ошибок
Здесь мне хотелось описать данное определение более понятными словами, передать суть.
Верификация — это не поиск и устранение ошибок, а доказательство соответствия функционирования продукта согласно ТЗ.
Тут слово «доказательство» неуместно, на мой взгляд. То есть мне, как верификатору, дали продукт и я должен доказать, что продукт правильно работает? Так не годится. Верификатор должен проверить соответствие продукта ТЗ, а если продукт не соответствует, то сообщить тому, кто это исправит.
fpgaFAE
16.07.2015 11:00Статья похожа на перевод рекламного буклета. А литература по этой, несомненно, важной теме имеется. Нпример, вот эта книжечка
x0n Автор
16.07.2015 14:58По поводу наличия информации я уже в комментариях поправился на отсутствие русскоязычной литературы.
А по поводу рекламного буклета. Сожалею, что вам так показалось. Надеюсь следующие статьи не будут создавать такое впечатление.fpgaFAE
16.07.2015 17:57Так же можно посетовать на отсутствие русскоязычного ПО (((
Данная профессия подразумевает знание английского хотя бы на уровне технической терминологии в области дизайна FPGA.x0n Автор
16.07.2015 19:00Есть огромная разница в усвоении информации для русскоязычного специалиста на английском и на русском. Даже для того, кто неплохо знает технический английский. Надеюсь с этим вы согласитесь?
ПО на русском совсем уж неуместно, потому как большинство терминов все-таки англоязычны.
Так что тут бессмысленно сравнивать ПО и литературу.
Можно ведь посетовать еще на англоязычные операторы «while», «for» итп. Вряд ли это кого-то будет напрягать.fpgaFAE
17.07.2015 13:16Те, «кто неплохо знает технический английский» как правило предпочитают оригинал на английском. Ибо русскоязычная литература в своем подавляющем большинстве — перевод тех же английских источников, причем довольно часто — перевод некачественный.
valeriyk
16.07.2015 16:03+1Как-то «верификация» в заголовке плавно перетекла в «функциональную верификацию» в тексте. Про другие виды верификации вы нам не расскажете?
x0n Автор
16.07.2015 16:22Не могу не согласится с данной критикой. Изначально стоило в заголовке указать функциональную верификацию.
О формальной верификации можно было упомянуть, однако, к сожалению, ей уделяется намного меньше времени. Незаслуженно.
А если и уделяется, то данный термин не фигурирует.
nckma
Честно говоря показалось, что какая-то поверхностная статья. Хотя бы пример какого нибудь тестбенча… Хоть вот такой www.marsohod.org/index.php/11-blog/113-icarus
x0n
Нельзя не согласится, но хотелось бы для начала сделать этакое «введение» в предметную область.
В следующих статьях обязательно подробнее коснусь разработки тестбенчей.