верифікація fpga

Верифікація FPGA. Що це? +6

15.07.15 12:53 •
x0n •
# 262693 •
Хабрахабр •
15 •
4448

- такий же як Forbes, тільки краще.

З волі долі я займаюся кілька років верифікацією конфігурацій ПЛІС. І з самого початку мене вражало нечисленність інформації з даного питання.

Якщо не всі, то багато тут чули про ПЛІС. Можливо деякі навіть щільно з ними працювали, але, думаю, з верифікацією проектів на ПЛІС стикалося набагато менше людей. Сьогодні я розповім про процес верифікації.

Функціональна верифікація на ПЛІС - це процес пошуку і виправлення помилок в конфігурації ПЛІС (далі прошивка). Скажете навіщо потрібна верифікація адже на етапі налагодження ПЛІС в «залізі» все можна виправити. Можна, але надзвичайно складно.

По-перше в «залізі» пошук функціональних помилок досить трудомісткий і тривалий процес. Це призводить до затримок завершення проекту. Для досить серйозного проекту налагодження може займати тижні і місяці. Верифікація ж дозволяє знайти і виправити більшість функціональних помилок ще на етапі моделі.

Скажете, що досвідчений розробник ПЛІС робить помилок або робить їх вкрай мало? Робить! І досить багато.

Верифікація дозволяє виявляти не тільки поточні помилки, але і потенційні помилки, які можуть з'явитися в майбутніх проектах з використанням блоків.

Верифікацію можна умовно розділити на наступні етапи:

Розробка ТЗ;
Розробка плану верифікації;
Розробка ТО;
тестування;

1. Розробка ТЗ на верифікацію

Як відомо - грамотний підхід до розробки ТЗ рятує від безлічі проблем на протязі всього проекту. ТЗ на верифікацію повинно описувати повний і всеосяжний набір функцій і можливостей блоку, які необхідно перевірити. В ідеалі ТЗ на верифікацію повинен писати тімліда групи верифікації. Це вкрай важливо особливо при малому досвіді роботи верифікатори, який буде займатися тестуванням. До складу ТЗ повинно входити такі пункти:
• перерахування всіх блоків, які будуть входити до складу проекту і роботу яких необхідно перевірити;
• перерахування всіх режимів роботи, функцій, можливостей проекту, які вимагають перевірки;
• перерахування функцій і класів ТО, яке буде використовуватися повторно з інших проектів (наприклад набір функцій з розрахунку контрольних сум або по роботі з інтерфейсами передачі даних).

Природно, написання ТЗ повинно починатися після отримання всієї необхідної інформації по даному проекту.

2. Розробка плану верифікації

Процес планування можливо найважливіший і найбільш нехтуємо етап функціональної верифікації. Створення плану верифікації визначається розробкою стратегій і тактик роботи з проектом до його початку. План верифікації є керівництво для команди по роботі з проектом. Без грамотного плану верифікації команди часто вибирають неправильний шлях пошуку помилок.

План верифікації включає набір всіх тестів з докладним описом.

План верифікації головний документ для команди верифікації ПЛІС. Вся подальша робота буде грунтуватися на цьому документі. Всі «зарубіжні монстри» систем на кристалі Synopsys і Cadence рекомендують починати з плану верифікації перед початком розробки ТО. По суті план верифікації представляє більш докладний ТЗ на верифікацію.

У детальному описі кожного тесту повинно бути вказані всі необхідні програмовані параметри, поточні режими роботи, вхідні, вихідні та еталонні дані.

3. Розробка ТО

Треба пам'ятати, що розробка конфігурації ПЛІС і розробка ТО повинні починатися і виконуватися паралельно. Даний порядок є оптимальним з точки зору мінімального часу розробки проекту, тому що процеси верифікації займають більше 70% часу розробки всього проекту.

На підставі інформації всіх попередніх етапів можна приступати до створення тестового оточення (далі ТО). ТО прийнято писати на мовах програмування створених спеціально для цілей верифікації, тому як вони мають весь необхідний інструментарій для цього. System Verilog один з найбільш підходящих мов. Дана мова досить сильно схожий на С ++ разом з инкапсуляцией, поліморфізмом, спадкуванням.

При розробці тестового оточення потрібно дуже рекомендуються не забувати про «реюзабельності». Якщо немає відповідних функцій, то написати їх з урахуванням можливого використання в майбутньому. Якщо ж є функцій, то використовувати. Потрібно організувати ТО так, щоб кожен тест міг модифікуватися без можливості пошкодити інші тести. Це позбавить від проблем в майбутньому, тому як в процесі проведення тестів все одно доведеться вводити якісь зміни в код ТО.

4. Тестування

На даному етапі верифікатори доводиться найбільш щільно працювати з розробником. Під час проведення тестів будуть виявлятися помилки, а вони будуть виявлятися. Якщо не будуть - значить ваше ТО працює неправильно. Після виявлення помилки потрібно повідомити розробнику про помилку. Потім після виправлення верифікатори потрібно запустити тест повторно і переконатися, що помилка усунена.

Ідеальним чином було б використання систем баг-трекінгу для здійснення зв'язку між верифікатором і розробником. Це дозволить пізніше відстежити які проблеми часто зустрічаються в тому чи іншому проекті, або у того чи іншого розробника. А заодно і буде доказом, що верифікатор не дарма їсть свій хліб.

Я вважаю слід додати, що не кожен розробник і не завжди визнає свої помилки. В даному випадку потрібно посилатися на ТЗ, в якому повинно однозначно описана робота проекту.

Ви можете допомогти і перевести трохи коштів на розвиток сайту

І з самого початку мене вражало нечисленність інформації з даного питання.
Не погоджуся.

Прошивка FPGA є програмним забезпеченням (хоча тут можна посперечатися, але в даному контексті порівняння доречно), отже її верифікація подібна до верифікацією будь-якого іншого ПО. За тестування ПО є достатня кількість статей, книг, методологій та ін.

Однак прошивка є «незвичайної» програмою, і у неї є нюанси, як її тестувати. І тут нам допомагають книги типу «SystemVerilog for Verification» і «Writing testbenches using systemverilog», а так само сайти типу testbench.in, ну і такі методології верифікації як UVM, які заточені під RTL.

Так що, на мій погляд, інформація є в мережі є :)

Мені здається, корисніше для спільноти буде показати свій тестбенч (або його частина), розповівши, що, як і чому ви робите, тому що реальне життя у великому серйозному проекті дуже часто розходиться з порадами з книжок і статей в інтернеті)

Тут моя промашка. У розумі писалося «російськомовної інформації», а було написано просто «інформації». Безумовно англійською вистачає літератури, проте в порівнянні з літературою для тестування «звичайного» ПО, інформації вкрай мало.

Спершу Ви приводите визначення:
Функціональна верифікація на ПЛІС - це процес пошуку і виправлення помилок
А потім:
тому що процеси верифікації та пошуку помилок
Ні те, ні інше не є вірним.
Верифікація - це не пошук і усунення помилок, а доказ відповідності функціонування продукту согласно ТЗ.

Верифікація - це підтвердження відповідності кінцевого продукту визначеним еталонним вимогам. Простими словами - ми створили продукт правильно, відповідно до вимог.
Розглядається якість продукту.

Валідація - це процес приведення доказів того, що вимоги конкретного зовнішнього споживача або користувача продукту, послуги або системи задоволені.
Простими словами - ми створили правильний продукт, використовуючи правильні вимоги. Розглядається якість всього процесу створення продукту.

тому що процеси верифікації та пошуку помилок
Це я поправив.
Функціональна верифікація на ПЛІС - це процес пошуку і виправлення помилок
Тут мені хотілося описати дане визначення більш зрозумілими словами, передати суть.

Верифікація - це не пошук і усунення помилок, а доказ відповідності функціонування продукту согласно ТЗ.
Тут слово «доказ» недоречно, на мій погляд. Тобто мені, як верифікатори, дали продукт і я повинен довести, що продукт правильно працює? Так не годиться. Верификатор повинен перевірити відповідність продукту ТЗ, а якщо продукт не відповідає, то повідомити того, хто це виправить.

І з самого початку мене вражало нечисленність інформації з даного питання.
Не погоджуся.

Так що, на мій погляд, інформація є в мережі є :)