9.1 Введение
Процесс верификации в нашей повседневной жизни происходит везде.Одно главное определение верификации данное в [ANSI/ASQC 1978] это – процесс просмотра, инспектирования, тестирования, проверки, аудита или по-другому создания и документирования ли или нет предметов, процессов, сервисов или документов согласно конкретным требованиям.“the act of reviewing, inspecting, testing, checking, auditing, or otherwise establishing and documenting whether or not items, processes, services or documents conform to specified requirements.” В рамках автоматизации проектирования IC устройства, показанного на рисунке 9.1 ,функциональная верификация это шаг гарантирующий, что технические требования и/или внедрение проекта на различных абстрактных уровнях выполняются в соответствии с целью разработки.
Рисунок 9.1
Обзор типичного процесса разработки.
В типичном процессе разработки, представления проекта на разных абстрактных уровнях часто содержит тысячи или больше строк кода языка описания аппаратных средств (HDL). Эти представления ошибочны, из-за высокой сложности дизайна. Верификация играет важную роль в идентификации различных проблем ,которые могут появиться на разных уровнях разработки. Для большинства средне и крупномасштабных процессоров, специализированных под приложения интегральных схем или систем на микросхеме, функциональная верификация может потреблять больше чем 70% от общих трудовых усилий процесса разработки[Piziali 2006]. Трудности, свойственные функциональной верификации – результат следующих трёх проблем:
1. Двусмысленные технические задания: требования заказчика часто вписаны в техническое задание разговорно.Ambiguous specifications: Customer requirements are often written colloquially into the specification.Может быть сложно точно определить требования на обычном языке , таком как английский. Более того, техническое задание часто описано на системном уровне. Когда проверяется элемент или блок внутри системы, отчётливое техническое задание для элемента или блока как правило, не доступно.
2. Вспышка сложности: в общем сложность булевой схемы может расти в геометрической прогрессии с точки зрения как числа входных данных, так и числа внутренних состояний. Исчерпывающее моделирование (всех комбинаций входных значений и/или комбинаций состояний) просто невыгодно для любого нетривиального дизайна.
3. Заботы о качестве: гарантирование высоко-качественной верификации с ограниченным строительными ресурсами и временем вызов каждой задаче верификации Для эффективного использования ресурсов и времени, нужны метрики покрытий чтобы вести расходы работ по верификации. Также существуют различные покрытия для измерения охвата верификации, но ни один из них не указан, как золотой показатель, который может надежно и точно отразить качество верификации. Как результат списание проекта относящемуся к функциональной верификации может стать управленческим решением, которое сильно зависит от опыта и часто влияет давление времени выхода на рынок As a result, signing off a design with respect to functional verification can become a managerial decision that heavily depends on one’s experience and is often influenced by time-to-market pressure as well.
9.2 Иерархия верификации
Современные проекты интегральных схем обычно следуют потоку внедрения сверху-вниз, в которой система иерархически разделена на компоненты. Каждая граница разделов определяет уровень компонентов схемы. Each partitioning boundary defines the level of the design components.В пределах иерархии, задачи верификации должны выполнятся до того, как отдельные компоненты собраны. V Диаграмма на рисунке 9.2 показывает поток проектирования, верификации и интегрирования начинающийся с уровня системы/управления, через уровень чипа и ядра / элементов, до уровня модели.The V diagram in Figure 9.2 illustrates the design, verification, and integration
Рисунок 9.2