Навигация
Тестирование и верификация HDL-моделей компонентов SOC
11775
знаков
0
таблиц
9
изображений
ТЕСТИРОВАНИЕ И ВЕРИФИКАЦИЯ 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: 
Практически, если выполнены условия тестопригодности и правильно расставлены ассерции в критических точках программного кода для диагностирования всех компонентов, то ВЭП может однозначно идентифицировать адрес (место) и тип ошибки на основе построенной ранее таблицы неисправностей – механизма ассерций.
Похожие работы
ть алгоритмическое и программное обеспечение для тестирования пакета кристаллов ГАС, в соответствии со стандартом IEEE 1500. Объект исследования – пакет кристаллов ГАС. 1. Анализ технического задания 1.1 Состояние рынка технологий сервисного обслуживания SoC Проблема диагностирования и ремонта памяти связана с тенденцией на постоянное уменьшение площади кристалла, отводимой для ...
... диаграмм с сохранением результатов в стандартном формате VCD (Value Change Dump), воспринимаемом всеми системами работы с временными диаграммами. [1] 2.МЕТОД ПРОЕКТИРОВАНИЯ УСТРОЙСТВ ФИЛЬТРАЦИИ ПО РАБОЧИМ ПАРАМЕТРАМ Методика проектирования фильтров по рабочим параметрам основана на нахождении значений элементов, нармированных по частоте и сопротивлению нагрузки, путём аппроксимации или с ...
... программирование микроконтроллера, как инструмента накопления данных и управления ресурсами, с учётом необходимой и достаточной степени доступа к конечной аппаратуре. Модуль накопления для задач многомерной мессбауэровской спектрометрии спроектирован с учётом следующих условий: - Синхронизация накопителя с системой доплеровской модуляции осуществляется внешними тактовыми импульсами “старт” и ...
0 комментариев