Підтвердження підтвердження поза межами покриття

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

Що ще має значення під час підписання?

Все, що передує внутрішньо розробленим функціональним специфікаціям/вимогам, має значення. Неможливо повністю замкнути цикл між вимогами клієнта та впровадженням/перевіркою, якщо вони не включені в аналіз. Тепер ланцюжки створення вартості стиснуті, а системи на чіпі (SoC) стають більш специфічними для застосування. Клієнти очікують, що проекти точно відповідають їхнім потребам, тому те, що вони визначили як вимоги, має відповідати під час реалізації/перевірки. Це не буде сприйнято добре, якщо клієнт виявить, що від нього очікується виправлення невідповідностей.

Проблема тут полягає в тому, що визначення може бути досить змішаним пакетом вхідних даних: Word, PDF, документи на основі DITA, електронні таблиці, Simulink, SysML або прототипи віртуальних моделей, а також програмне забезпечення, яке має працювати на кінцевому обладнанні (можливо, з урахуванням деяких зміни). Також можуть бути задокументовані вимоги в DOORS, Jama Connect або подібному форматі. Як команда верифікації, команда дизайнерів або архітектор підтверджують, що впровадження та перевірка відповідають вимогам? Звичайно, вони зроблять усе можливе, але де детальний процес, який підлягає перевірці, щоб гарантувати, що кожна вимога відповідає реалізації впровадження та що перевірка впровадження належним чином покривається?

Щоб зробити це більш конкретним, припустімо, що є функція, яку хоче один важливий клієнт, але ніхто інший не вимагає. Можливо, через недогляд або непорозуміння ця функція не входить до функціональної специфікації/вимоги. Це трапляється занадто часто. Навіть ідеальне 100% охоплення не допоможе вирішити цю проблему, оскільки охоплення настільки добре, наскільки гарне план верифікації. Існує велика проблема, якщо план верифікації не точно відображає вимоги.

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

Відстеження вимог доповнює покриття для підтвердження підтвердження

Запуск перевірки еквівалентності між документами Word, віртуальними моделями та рівнем передачі реєстру (RTL) навряд чи буде можливим за нашого життя, але це й не обов’язково. Розробники систем і команди програмного забезпечення вже активно використовують відстеження вимог як дуже надійний метод відстеження відповідності між вимогами верхнього рівня та рівня реалізації, аж до реалізації, перевірки та тестування. Ця відстежуваність підтримується відстеженням вимог за допомогою формату обміну вимогами (ReqIF) із такими платформами, як DOORS та інструменти Jama Connect.

Хоча ці інструменти створені для легкого впровадження у світі програмного забезпечення, вони не розуміють апаратної семантики. Вони дійсно підтримують зв’язки «чужих об’єктів» для підключення до даних проектування та перевірки, але тягар правильного встановлення цих зв’язків лягає на інженерів з проектування та перевірки. Це було б не так вже й погано, якби було лише кілька сотень об’єктів для відстеження. Але подумайте про карту пам’яті, карту переривань, карту мультиплексування вводу-виводу; вони можуть працювати з десятками тисяч об’єктів або більше. Оновлення вручну всіх цих об’єктів через зміни дизайну та перерозподілу стає надзвичайно складним, якщо не неможливим.

Кращий підхід полягає в управлінні відстеженням, яке може підключатися до таких інструментів, як ReqIF на стороні клієнта, і безпосередньо до артефактів, які відстежуються командами проектування та верифікації. Розуміння семантики дизайну дає можливість зробити висновок про зв’язки між вимогами та впровадженням і правильно відслідковувати їх у міру розвитку проекту. Цей метод забезпечує перевірку зв’язків від специфікацій замовника до вимог проектування та, зрештою, до реалізації SoC.

Це відстежуваність, яка може завершити мету перевірки підписання з незначним впливом на команди проектувальників SoC. Тип підтримки відстеження, який ви знайдете Arteris Harmony Trace.