З волі долі я займаюся кілька років верифікацією конфігурацій ПЛІС. І з самого початку мене вражало нечисленність інформації з даного питання.
Якщо не все, то багато хто тут чув про ПЛІС. Можливо деякі навіть щільно з ними працювали, але, думаю, з верифікацією проектів на ПЛІС стикалося набагато менше людей. Сьогодні я розповім про процес верифікації.
Функціональна верифікація на ПЛІС - це процес пошуку і виправлення помилок у конфігурації ПЛІС (далі прошивка). Скажете навіщо потрібна верифікація адже на етапі налагодження ПЛІС в «залізі» все можна виправити. Можна, але надзвичайно складно.
По-перше в «залізі» пошук функціональних помилок досить трудомісткий і довгий процес. Це призводить до затримок завершення проекту. Для досить серйозного проекту налагодження може займати тижні і місяці. Верифікація ж дозволяє знайти і виправити більшість функціональних помилок ще на етапі моделі.
Скажете, що досвідчений розробник ПЛІС не робить помилок або робить їх вкрай мало? Робить! І досить багато.
Верифікація дозволяє виявляти не тільки поточні помилки, а й потенційні помилки, які можуть з'явитися в майбутніх проектах з використанням блоків.
Верифікацію можна умовно розділити на наступні етапи:
- Розробка ТЗ;
- Розробка плану верифікації;
- Розробка ТО;
- Тестування;
1. Розробка ТЗ на верифікацію
Як відомо - грамотний підхід до розробки ТЗ позбавляє від безлічі проблем протягом усього проекту. ТЗ на верифікацію має описувати повний і всеосяжний набір функцій і можливостей блоку, які необхідно перевірити. В ідеалі ТЗ на верифікацію повинен писати тимлід групи верифікації. Це вкрай важливо особливо при малому досвіді роботи верифікатора, який буде займатися тестуванням. До складу ТЗ має входити такі пункти:
- перерахування всіх блоків, які будуть входити до складу проекту і роботу яких необхідно перевірити;
- перерахування всіх режимів роботи, функцій, можливостей проекту, які вимагають перевірки;
- перерахування функцій і класів ТЕ, яке буде використовуватися повторно з інших проектів (наприклад набір функцій з розрахунку контрольних сум або по роботі з інтерфейсами передачі даних).
Природно, написання ТЗ має починатися після отримання всієї необхідної інформації по даному проекту.
2. Розробка плану верифікації
Процес планування можливий найважливіший і найбільш нехтований етап функціональної верифікації. Створення плану верифікації визначається розробкою стратегій і тактик роботи з проектом до його початку. План верифікації являє собою керівництво для команди по роботі з проектом. Без грамотного плану верифікації команди часто вибирають неправильний шлях пошуку помилок.
План верифікації включає набір всіх тестів з докладним описом.
План верифікації головний документ для команди верифікації ПЛІС. Вся подальша робота буде ґрунтуватися на цьому документі. Всі «забугорні монстри» систем на кристалі Synopsys і Cadence рекомендують починати з плану верифікації перед початком розробки ТО. По суті план верифікації представляє більш докладне ТЗ на верифікацію.
У докладному описі кожного тесту має бути вказано всі необхідні програмовані параметри, поточні режими роботи, вхідні, вихідні та еталонні дані.
3. Розробка ТО
Треба пам'ятати, що розробка конфігурації ПЛІС і розробка ТО повинні починатися і виконуватися паралельно. Даний порядок оптимальний з точки зору мінімального часу розробки проекту, тому як процеси верифікації займають більше 70% часу розробки всього проекту.
На підставі інформації всіх попередніх етапів можна приступати до створення тестового оточення (далі ТО). ТЕ прийнято писати мовами програмування створених спеціально для цілей верифікації, тому що вони мають весь необхідний інструментарій для цього. System Verilog одна з найбільш відповідних мов. Ця мова досить сильно схожа на С++ разом з інкапсуляцією, поліморфізмом, спадкуванням.
При розробці тестового оточення потрібно дуже рекомендуються не забувати про «реюзабельність». Якщо немає відповідних функцій, то написати їх з урахуванням можливого використання в майбутньому. Якщо ж є функцій, то використовувати. Потрібно організувати ТЕ так, щоб кожен тест міг модифікуватися без можливості пошкодити інші тести. Це позбавить від проблем у майбутньому, бо в процесі проведення тестів все одно доведеться вводити якісь зміни до коду ТО.
4. Тестування
На даному етапі верифікатору доводиться найбільш щільно працювати з розробником. Під час проведення тестів будуть виявлятися помилки, а вони будуть виявлятися. Якщо не будуть - значить ваше ТО працює неправильно. Після виявлення помилки потрібно повідомити розробнику про помилку. Потім після виправлення верифікатору потрібно запустити тест повторно і переконатися, що помилка усунена.
Ідеальним чином було б використання систем лід-трекінгу для здійснення зв'язку між верифікатором і розробником. Це дозволить пізніше відстежити які проблеми часто зустрічаються в тому чи іншому проекті, або у того чи іншого розробника. А заодно і буде доказом, що верифікатор не дарма їсть свій хліб.
Я вважаю слід додати, що не кожен розробник і не завжди визнає свої помилки. У даному випадку потрібно посилатися на ТЗ, в якому має однозначно описана робота проекту.
