Тестирование и верификация 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:

Практически, если выполнены условия тестопригодности и правильно расставлены ассерции в критических точках программного кода для диагностирования всех компонентов, то ВЭП может однозначно идентифицировать адрес (место) и тип ошибки на основе построенной ранее таблицы неисправностей – механизма ассерций.



Информация о работе «Тестирование и верификация HDL-моделей компонентов SOC»
Раздел: Информатика, программирование
Количество знаков с пробелами: 11775
Количество таблиц: 0
Количество изображений: 9

Похожие работы

Скачать
56973
0
28

ть алгоритмическое и программное обеспечение для тестирования пакета кристаллов ГАС, в соответствии со стандартом IEEE 1500. Объект исследования – пакет кристаллов ГАС. 1. Анализ технического задания 1.1 Состояние рынка технологий сервисного обслуживания SoC Проблема диагностирования и ремонта памяти связана с тенденцией на постоянное уменьшение площади кристалла, отводимой для ...

Скачать
44493
3
33

... диаграмм с сохранением результатов в стандартном формате VCD (Value Change Dump), воспринимаемом всеми системами работы с временными диаграммами. [1] 2.МЕТОД ПРОЕКТИРОВАНИЯ УСТРОЙСТВ ФИЛЬТРАЦИИ ПО РАБОЧИМ ПАРАМЕТРАМ Методика проектирования фильтров по рабочим параметрам основана на нахождении значений элементов, нармированных по частоте и сопротивлению нагрузки, путём аппроксимации или с ...

Скачать
138361
13
23

... программирование микроконтроллера, как инструмента накопления данных и управления ресурсами, с учётом необходимой и достаточной степени доступа к конечной аппаратуре. Модуль накопления для задач многомерной мессбауэровской спектрометрии спроектирован с учётом следующих условий: -  Синхронизация накопителя с системой доплеровской модуляции осуществляется внешними тактовыми импульсами “старт” и ...

0 комментариев


Наверх