Поиск ошибок проектирования в HDL-моделях цифровых устройств

Размещено на http://www.allbest.ru/

Поиск ошибок проектирования в HDL-моделях цифровых устройств

Альмадхоун С.

Рассмотрены методы поиска ошибок проектирования в неструктурированном HDL-коде. Предложена модель НDL-кода для целей диагностирования в виде информационного и управляющего графов. Предложена модель ошибки проектирования и правила ее идентификации. Разработаны структурные методы поиска ошибок и метод обратного прослеживания.

Полный цикл диагностирования модели цифрового устройства (ЦУ), начиная от его описания на языках описания аппаратуры (HDL) и заканчивая поиском места возникновения ошибки проектирования, включает в себя этапы: описание модели на языках описания аппаратуры, компилирование внутренней модели, генерацию тестов, построение списка ошибок проектирования, получение эталонов, алгоритмы обработки диагностической информации и, собственно, методы поиска дефектов.

Модели на языках описания аппаратуры обладают свойством двойственности. С одной стороны, они формально выглядят и ведут себя как код на языках программирования (например, при использовании подпрограмм или переменных); с другой стороны, обладают рядом кардинальных отличий, присущих аппаратуре (сигналы, параллелизм, синтезируемость). Отсюда невозможно тестировать и диагностировать такие модели методами исключительно верификации ПО или методами диагностирования аппаратуры. С точки зрения уменьшения размерности задачи диагностирования необходимо подойти к HDL-коду, как к аппаратуре, и соответственно с этим строить тесты и проводить диагностические эксперименты с использованием процедур аппаратной тестовой диагностики. Исходя из двойственности HDL - модели, определим характер возможных ошибок, их влияние на конечную реализацию (устройство после синтеза) и методы поиска. Вместо термина «дефект» и «неисправность» в дальнейшем будет использоваться понятие «ошибка проектирования». Для HDL-моделей вводится модель ошибки проектирования, соответствующая ошибке в любом операторном выражении и не относящаяся к синтаксическим ошибкам.

В качестве модели объекта диагностирования можно эффективно использовать графовое представление описания устройства на HDL [1]. Описание на HDL представляется в виде двух графов. Информационный I-граф описывает поток данных и их преобразование (подобно операционному автомату в классической композиционной модели с микропрограммным управлением) без учета условных ветвей. I-граф содержит два типа вершин: операнды и функции. Типы операндов: целые числа и беззнаковые вектора. Типы функций ограничены синтезируемым подмножеством HDL (то есть теми конструкциями, которые имеют физические эквиваленты в системах синтеза и имплементации в САПР). Управляющий С-граф соответствует цепочке условий, при выполнении которых выполняется тот или иной оператор. С-граф содержит условные конструкции (например, case, if...then..., with … select) из исходного описания ЦУ.

С-граф - это граф с 2-мя типами вершин: условия и метки. Вершины условий содержат вычисляемые условия. Вершины меток - конечные, не имеющие входной дуги и содержащие имя метки. Результат моделирования С-графа - набор меток (метка), по которым осуществляются переходы в I-графе. В такой интерпретации С-граф соответствует управляющему автомату. цифровое устройство дефект графовый

Учитывая, что операторы HDL, выбранные в качестве функциональных примитивных элементов (ПЭ), не содержат внутри себя ошибок, очевидно, что подача на ПЭ тестов проверки исправности является нецелесообразной. Поэтому смысл тестирования примитива состоит не в проверке функционирования, а идентификации его типа. Таким образом, на примитив необходимо подать такие тестовые наборы, чтобы после анализа реакций на них можно идентифицировать тип (функцию) примитива и отличить его от других ПЭ. Такие различающие последовательности (РПС) позволяют найти ошибки связанные с подменой операторов в HDL - коде. Выбор сделан в пользу РПС, а не стандартных проверяющих тестов в основном потому, что в основе построения проверяющих тестов лежат понятия транспортирования и активизации пути, по которому неисправность транспортируется на внешний выход схемы. А это не всегда представляется возможным сделать, так как в
HDL-коде функциональные неисправности могут быть замаскированы дальнейшими вычислениями таким образом, что ошибка не будет наблюдаться на внешнем выходе.

Для декомпозиции исходного графа используются контрольные точки (аналогично контрольным точкам при генерации тестов, которые позволяли «разбить» путь активизации и определить границы подграфов). Данные контрольные точки (КТ) будут выходами каждого из подграфов. Таким образом, ошибка проектирования транспортируется на внешний выход каждого подграфа. Особенностью диагностирования HDL-модели является отсутствие эталонного HDL-кода, поэтому вычислить эталонные значения сигналов во всех КТ без привлечения внешних способов невозможно. Исходя из этого, определяются два типа контрольных точек, используемых при поиске места ошибки в HDL-коде в условиях отсутствия исчерпывающей (полной) спецификации. КТ первого рода - сигналы (переменные) модели, которые наблюдаемы, и эталонные значения которых известны из спецификации.

КТ второго рода - сигналы (переменные) модели, значения в которых наблюдаемы, но до начала диагностического эксперимента эти значения неизвестны.

Таким образом, общую методику диагностирования HDL-модели можно определить такой последовательностью шагов:

1. Составление модели на основе I-графа и С-графа , «разрыв» обратных связей в этой модели.

2. Определение класса ошибок проектирования, составление РПС для этих ошибок и тестирование модели на основе подачи РПС и сравнение с имеющимися эталонами.

3. Сужение области подозреваемых дефектов на основе структурного метода для многовыходовых моделей.

4. Применение структурного метода поиска для подграфов только с контрольными точками первого рода.

5. Применение структурно-функционального метода обратного прослеживания для «доискивания» в подграфах ограниченных контрольными точками первого рода.

Применение метода обратного прослеживания обусловлено тем, что КТ первого рода гораздо меньше, чем количество операторов HDL-кода. Поэтому необходимо выполнять поиск ошибочного оператора в условиях отсутствия эталонных сигналов и эталонного кода на участках программы, ограниченных КЕ первого рода [2].

Предложенный метод поиска дефектов/ошибок проектирования при верификации HDL-моделей позволяют не только говорить о наличии ошибки проектирования, но и точно определить место её возникновения (локализовать дефект).

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

В перспективе данные результаты могут быть включены в систему верификации HDL-кода (Testbench) в качестве режима отладки (debug-функция).

СПИСОК ЛИТЕРАТУРЫ

1. Шкиль, А. С. Методы поиска ошибок проектирования в HDL-коде [Текст] / А. С. Шкиль, Е. Е. Сыревич, Д. Е. Кучеренко, Г. П. Фастовец // Радиоэлектроника и информатика. - Харьков, 2008 - №. 3. - С. 47 - 53.

2. Шкиль, А. С. Метод обратного прослеживания для поиска ошибок проектирования в HDL-коде [Текст] / А. С. Шкиль, Е. Е. Сыревич, Д. Е. Кучеренко, Самер Альмадхоун // Радиоэлектроника. Інформатика. Управління. - Запоріжжя: ЗНТУ, 2009 - №. 2. - С. 86-90.

Размещено на Allbest.ru