Просмотр исходного текста страницы Open Source VHDL Verification Methodology/Верификация в VHDL

{{OS-VVM TOC}}
<slideshow title="" style="custis" scaled="true" font="Calibri, Segoe Print, cursive" footer="" headingmark="⌘⌘" />

== Изменения в верификации современных проектов ⌘⌘ ==
=== Соотношение стоимости поиска багов (ошибок) ⌘⌘ ===
=== Типичный процесс верификации ⌘⌘ ===

{|
!<graph>
digraph G{

ranksep=0.2

node [fontsize=11 fontname="Calibri" style=filled fillcolor=aliceblue]
edge [fontsize=6 fontcolor=blue fontname="Calibri" color=blue]
#rankdir=LR
rankdir=TB

FRS [label="Функции\n Требования\n Спецификация" shape="note"]
Design_Source [label="Исходники\nпроекта" shape="tab"]
Verification_Plan [label="План\nверификации" shape="box3d"]
Verification_Source [label="Verification\n Source" shape="note"]
Run_Simulations [label="Запуск\nмоделирования" fillcolor="lightgreen"]
results [label="Результаты тестов\n и\nДанные о покрытии" shape="folder"]
BUGS [shape="note" fillcolor=red]
VMan [label="Инженер\n верефикатор" fillcolor=yellow shape=circle]

FRS -> Verification_Plan
{Verification_Plan Verification_Source Design_Source } -> Run_Simulations -> {BUGS results VMan}
{BUGS results FRS Verification_Plan} -> VMan

} 
</graph>
|width=30%|
* Ручное сопостовление требований, плана верификации и результов покрытия для того, чтобы убедиться, что верификация полна и завершена.

* Это трудоёмкий, подверженный ошибкам и затратный по времени процесс.

* Leads to delays, missed functionality & low quality.
|}

===Верификация современных проектов ⌘⌘ ===

* Растущая сложность СнК проектов 
** около 1 миллиарда логических вентилей
** 100-ни IP блоков
** 1000-чи требований и функций
** 100 – 1000 ошибок
** 1000-чи регрессионных запусков с тысячами тестов
** множественное распределение команды разработчиков и верификаторов

* 70% усилий идёт на верификацию

* 89% проектов нарушает deadline в среднем на 44%{{Кр|*}}


<center><small>{{Кр|*}}SPIRIT/NXP study Dec 2007</small></center>

==== Пример проекта UHF RFID ИС ⌘⌘ ====

* 5 аналогвых блоков
* 2 блока памяти
* Спецификация на 50 страницах
** 15 команд
** 5 режимов
* 50 групп тестов
** моделирование 3 суток на 8 распределённых ядрах

=== Средства верификации ⌘⌘ ===

* Доступные технологии верификации
** Прямые тесты (Directed tests)
** Псевдослучайные тесты (Random tests)
** Управляемые псевдослучайные тесты (Constrained Random tests)
** Верификация управляемая покрытием (на основе покрытия) (Coverage driven verification)
*** Покрытие кода (Code coverage)
*** Функциональное покрытие (Functional coverage )
** Верификация на основе утверждений (Assertion based verification)
** Эмуляция (Emulation)
** Формальная верификация (Formal verification)
* But something is missing!

=== Управление (Management) процессом верификации ⌘⌘ ===

* Управление верификационной информацией
** Требования
*** Создание или импорт требований
** Планы
*** Определение верификационных метрик, которые должны проверить требования
*** Assign development of metrics to individuals
** Баги (Bugs)
*** Связь багов с верификационными метриками
** Регрессионные запуски
*** Связь результатов регриссионного тестирования с верификационными метриками
** Исходные файлы проекта и верификационной среды
*** Версионность, конфигурации и др.
* Мониторинг и анализ
* Поддержка САПР для верификации, методологий, процессов (маршрутов)

=== COVERAGE METRICS ⌘⌘ ===

Measuring progress is one of the most important tasks in verification and is the critical element that enables the designer to decide when to end the verification effort. Several methods are commonly used:

* Toggle testing: verifies over a series of tests that all nodes toggled at least once from 1 to 0 and back

* Code coverage: demonstrates over a series of tests that all the source lines were exercised; in many cases, there is also an indication as to whether branches in conditional code were executed; sometimes an indication of state-machine transitions is also available

* Tracking how many bugs are found each week: possibly the most common metric used to measure progress; after a period of a few weeks with very few or zero bugs found, the designer assumes that the verification process has reached a point of diminishing returns