Реферат: Тестирование и верификация HDL-моделей компонентов SOC
1. Анализ тестопригодности графа управления
Учитывая, что автоматная модель программного продукта представлена взаимодействием операционного и управляющего автомат, рис. 1, то наряду с моделированием транзакционного графа, необходимо иметь возможность анализировать тестопригодность граф-схемы алгоритма управления (ГСА).
Рис. 1. Автоматная модель HDL-программы
Предлагается ГСА представить в виде содержательного графа управления (СГУ), который является подобным транзакционному графу. Здесь вершины есть операции программного кода, а дуги представляют условия перехода из одной вершины в другую для выполнения команды, обозначенной вершиной-стоком.
Следовательно, для СГУ можно использовать процедуры, ранее разработанные для подсчета критериев тестопригодности транзакционного графа в части управляемости и наблюдаемости. Примером содержательного графа может служить рис. 2, имеющий 6 вершин и 9 дуг.
Рис. 2. Содержательный граф HDL-программы
Подсчет управляемостей графа, представленного на рис. 2, имеет следующий вид:
Подсчет наблюдаемостей графа, представленного на рис. 2, содержит следующие выражения:
Рис. 3. Графики тестопригодности для графа управления
Для использования тестопригодности выполняется построение управляемости и наблюдаемости всех компонентов HDL-модели (рис. 3). Затем вычисляется обобщенная характеристика – тестопригодность каждого компонента как произведение управляемости и наблюдаемости:
. (1)
Далее интерес представляет создание таблицы тестопригодности, управляемости и наблюдаемости, а также соответствующий им график для визуального контроля «плохих» компонентов. Фиксация определенной планки тестопригодности, ниже которой значения будут считаться неприемлемыми, позволит разработчику создавать ассерции и другие дополнительные средства повышения тестопригодности для проблемных функциональных блоков. Кроме того, средства повышения тестопригодности должны обеспечивать глубину диагностирования до функционального компонента и привязанных к нему операций в целях быстрого восстановления работоспособности программной HDL-модели. В целях построения алгоритмов поиска ошибок в программном коде можно использовать таблицу неисправностей, по аналогии с технологией тестирования hardware. Любопытное решение в процессе проверки функциональных блоков связано с сигнатурным анализом, где обобщенная сигнатура отождествляется с исправным поведением всего кода, а также с каждым компонентом. Любое несовпадение эталонной сигнатуры с фактической приводит к выполнению процедуры диагностирования и восстановления работоспособности HDL-модели путем исправления семантики кода.
Предложенная модель верификации HDL-проекта использует testbench, функциональное покрытие, механизм ассерций, описанную выше метрику оценки тестопригодности, таблицу неисправностей и вектор экспериментальной проверки (ВЭП), формируемый по заданным контрольным точкам путем сравнения сигнатур. Функциональное ограничение testbench связано с неразличимостью компонентов программного кода, в которых могут быть ошибки. Его основное назначение – проверка исправности HDL-модели. Поэтому в качестве дополнения к процедуре проверки придается механизм ассерций, основная цель которого с заданной глубиной – до программного компонента – определить место и вид ошибки на стадии выполнения диагностирования, после того, как testbench зафиксировал неправильное функционирование программного проекта. Две стадии верификации: тестирование и диагностирование – представлены ниже в виде следующих двух векторно-матричных операций:
Для первой стадии используется двоичный вектор экспериментальной проверки 
, формируемый на основе процедуры тестирования. На второй стадии используется уже матрица 
экспериментальной проверки, которая с наперед заданной глубиной определяет диагноз проекта на основе сравнения технических состояний HDL-модели и механизма ассерций:
В процессе выполнения процедуры верификации выполняется сравнение фактического и эталонного (специфицированного) технического состояния компонента путем применения операции Xor: 
Практически, если выполнены условия тестопригодности и правильно расставлены ассерции в критических точках программного кода для диагностирования всех компонентов, то ВЭП может однозначно идентифицировать адрес (место) и тип ошибки на основе построенной ранее таблицы неисправностей – механизма ассерций.
2. Верификация DCT IP-core, Xilinx
Представленные модели верификации программного HDL-кода проверены на реальном проекте Xilinx IP-core в целях определения наличия в нем ошибок. При этом удалось получить положительный результат относительно неверной семантики работы программы для последующего исправления кода. Фрагмент модуля дискретного косинусного преобразования представлен листингом 1 [Xilinx.com]. Вся HDL-модель насчитывает 900 строк кода System Verilog.
Листинг. 1.
--> ЧИТАТЬ ПОЛНОСТЬЮ <--