Содержание к диссертации
Введение
ГЛАВА 1. Выбор методики тестового диагностирования процессоров 14
1.1 Основные определения 14
1.2 Тестовое диагностирование процессоров в системах на кристалле 16
1.3 Архитектура и тестовое диагностирование реконфигурируемых систем 20
1.4 Методы тестового диагностирования процессоров 22
1.5 Оценка существующих методик программного тестового диагностирования 24
ГЛАВА 2. Методика функционального тестового диагностирования процессоров 29
2.1 Архитектура системы команд процессоров 29
2.2 Методика функционального тестового диагностирования механизмов передачи и обработки данных 33
2.2.1 Функциональная декомпозиция процессора 33
2.2.2 Механизм хранения и передачи данных 33
2.2.3 Механизмы обработки данных 38
2.3 Методика функционального тестового диагностирования механизмов управления 39
2.3.1 Функциональная декомпозиция механизмов управления 39
2.3.2 Механизм управления передачей данных 42
2.3.3 Механизм управления обработкой данных 44
2.3.4 Механизм управления выполнением команд 47
ГЛАВА З. Разработка функциональных тестов микропроцессоров 49
3.1 Особенности архитектур диагностируемых процессоров 49
3.2 Разработка тестов механизмов хранения и передачи данных 50
3.3 Разработка тестов механизмов обработки данных 57
3.4 Разработка тестов механизмов управления 60
ГЛАВА 4. Оценка эффективности функциональньіх тестов средствами имитационного моделирования 63
4.1 Эффективность функциональных тестов 63
4.2 Принципы работы программного испытательного стенда . 65
4.3 Разработка испытательного стенда с использованием совместной работы двух программ-имитаторов 69
4.3.1 Постановка задачи 69
4.3.2 Обоснование схемы совместной работы программ-имитаторов 71
4.3.3 Оценка качества теста моделированием константных неисправностей 74
4.3.4 Схема испытательного стенда 77
4.4 Оценка эффективности функциональных диагностических тестов на моделях процессоров 78
ГЛАВА 5. Функциональное тестовое диагностирование механизмов хранения и передачи данных конвейеризованных risc процессоров 83
5.1 Функциональная декомпозиция архитектуры 83
5.2 Принцип тестового диагностирования механизмов процессора с параллелизмом уровня системы команд 85
5.3 Особенности конвейерной архитектуры, существенные для разработки тестов 88
5.4 Общая функциональная модель механизма и модель неисправности 89
5.5 Тестовое диагностирование механизма, управляемого полями команд 90
5.6 Тестовое диагностирование механизма управляемого зависимостями по данным 93
5.7 Оценка эффективности функциональных тестов на модели 98
Заключение 100
Список литературы
- Архитектура и тестовое диагностирование реконфигурируемых систем
- Методика функционального тестового диагностирования механизмов передачи и обработки данных
- Разработка тестов механизмов хранения и передачи данных
- Разработка испытательного стенда с использованием совместной работы двух программ-имитаторов
Введение к работе
Актуальность темы. Публикация первых работ, [16, 20] и др., в которых представлен функциональный, основанный на выполнении тестовых программ подход к тестовому диагностированию процессоров, относится к началу 80-х годов 20-го века. В 90-е годы развитие этого подхода привело к разработке методик, [4, 32] и др., основанных на функциональных моделях и использующих особенности архитектуры процессоров, а так же к появлению автоматизированных методик разработки тестов [22, 37], в которых наряду с использованием функциональных моделей применяется рандомизация. В последние годы разработаны автоматизированные методики [27, 28, 38, 39], характеризующиеся отказом от функциональных моделей и использующие точные регистровые и вентильные модели.
Разнообразие прикладных вычислительных задач, растущий спрос на электронные вычислительные средства и прогресс в технологии производства полупроводников вызвали потребность в массовом производстве и гибком конфигурировании этих средств. Универсальные и специализированные процессоры являются неотъемлемой частью современной электронной аппаратуры. Сегодня процессорные модули обычно интегрированы в состав систем на кристалле, которые могут включать один или несколько модулей универсальных и специализированных процессоров. Как правило, архитектуры современных универсальных процессоров наследуют архитектуру RISC и конвейеризованы. Более того, развитие других архитектур часто идет по пути использования принципов RISC на уровне микроархитектуры. Проектирование современных процессоров и систем на кристалле требует значительных затрат времени и других ресурсов, поэтому в проектируемых системах часто используются готовые функциональные модули, разработанные ранее для других систем.
Новые задачи стоят сегодня перед разработчиками систем тестового диагностирования цифровой аппаратуры и тестов. Невозможность диагностирования модуля отдельно от системы и ограниченное количество внешних тестовых контактов в системе вызвали потребность в использовании встроенной тестовой аппаратуры и принципов самодиагностики. Широкое применение процессоров и специфика их разработки, производства и применения позволили выделить их в отдельный подкласс цифровых объектов диагностирования. Для их тестового диагностирования признано целесообразным использование специальных тестовых программ. Потребность в сокращении временных затрат на проектирование, реконфигурировании аппаратуры и использовании в новых системах готовых модулей вызвала необходимость начала разработки теста и тестового оборудования, когда точная логическая вентильная схема процессора еще неизвестна.
В связи с этим, для тестового диагностирования современных процессоров возрастает актуальность функциональных методов. Функциональные тесты можно эффективно применить для самодиагностики процессорных модулей в составе систем на кристалле. Выполнение тестовых программ проводится на рабочей частоте, поэтому занимает мало времени. Для разработки тестовой программы может быть необязательным знание точной логической схемы всего процессора, поэтому тест может разрабатываться параллельно с самим процессором. Функциональные тесты, полученные на основе архитектуры процессора, наряду с формальными методами могут применяться для верификации его проекта.
Актуальность настоящего исследования вызвана потребностью в разработке и внедрении методик функционального тестового диагностирования конвейеризованных RISC процессоров, использующих архитектуру системы команд как исходные данные. Исследование развивает методики разработки тестов последовательных процессоров, основанные на- функциональных моделях и использующие особенности их архитектуры, применяя их для тестового диагностирования конвейеризованных RISC процессоров.
Объект исследования диссертационной работы — универсальный процессор, принципы его разработки и методы его технической диагностики с использованием методов моделирования цифровых систем.
Цель работы. Целью диссертационной работы является разработка методики тестового диагностирования конвейеризованных универсальных RISC процессоров, основанной на функциональном подходе к разработке тестов. Требованиями к методике являются: возможность ее реализации как автоматизированного процесса разработки тестовых программ; использование архитектуры системы команд как основных исходных данных для разработки тестов.
Основные задачи работы:
- анализ существующих методик функционального диагностирования;
- разработка математических моделей и процедур функционального диагностирования конвейеризованных RISC процессоров;
- разработка процесса генерирования диагностических тестов;
- оценка качества разработанных тестов как покрытия одиночных константных неисправностей вентильных моделей процессоров средствами имитационного моделирования;
Методы исследований. Для решения поставленных задач в работе использованы методы теорий множеств, графов, булевых функций и конечных автоматов.
Научная новизна заключается в следующих результатах работы:
- Предложена методика функциональной декомпозиции процессоров с параллелизмом уровня системы команд для их тестового диагностирования;
- Предложены функциональные модели и процедуры генерирования тестов механизмов хранения и передачи данных конвейеризованных RISC процессоров;
- Предложен принцип взаимодействия функционально дополняющих друг друга программ-имитаторов. По этому принципу разработан прототип испытательного стенда, на котором оценено качество тестов. Практическая ценность работы заключается в разработке моделей, алгоритмов и процедур, являющихся основой процесса генерирования функциональных диагностических тестов конвейеризованных RISC процессоров и разработке программного испытательного стенда для оценки качества этих тестов:
- Предложены функциональные модели и разработаны процедуры тестового диагностирования механизмов хранения и передачи данных конвейеризованных RISC процессоров;
- Предложена и экспериментально подтверждена методика разработки тестов механизма обработки данных;
- Разработана схема программного испытательного стенда, позволяющего оценивать качество функциональных тестов с использованием дополняющих друг друга функционально программ-имитаторов. Результаты работы внедрены в ГОУ ВПО «Дальневосточный государственный технический университет».
Основные положения, выносимые на защиту:
- Методика функциональной декомпозиции процессоров с параллелизмом уровня системы команд для их тестового диагностирования;
- Функциональные модели и процедуры тестового диагностирования механизмов хранения и передачи данных конвейеризованных RISC процессоров;
- Принцип взаимодействия дополняющих друг друга функционально программ-имитаторов; схема испытательного стенда для определения качества функциональных диагностических тестов;
- Результаты оценки качества разработанных в соответствии с методикой функциональных тестов;
Достоверность научных положений подтверждена теоретическим обоснованием разработанных моделей и методов и данными экспериментов.
Апробация результатов работы. Основные положения и результаты работы представлялись и обсуждались на научной конференции ДВГТУ (г. Владивосток, 2004 г.), на III всероссийской научно-практической конференции студентов МСИТ (г. Томск, 2005 г.), на четырех международных семинарах под патронажем ШЕЕ - EWDTW, DDECS (г. Алушта, 2004 г., г. Одесса, 2005 г., г. Прага, 2006 г., г. Сочи, 2006 г.), на международном симпозиуме под патронажем IEEE — EWDTS (г. Ереван, 2007 г.).
По результатам работы реализован экспериментальный прототип программного испытательного стенда и оценена эффективность разработанного подхода к тестовому диагностированию конвейеризованных RISC процессоров.
Публикации по теме диссертации. Основные результаты и положения диссертации изложены в 2 статьях в научных изданиях, в том числе в 1 статье в рецензируемом журнале из списка, рекомендованного ВАК, в 6 сборниках трудов конференций, в 1 тезисах конференции. Всего опубликовано 9 печатных работ [12, 13, 21, 23, 24, 25, 35, 36].
Работа организована следующим образом:
- В первой главе по материалам журнала «Автоматика и телемеханика» и трудам конференций по технической диагностике (ITC, DAC, VTS и др.) проведена оценка требований к разрабатываемой методике тестового диагностирования процессоров и существующих методик диагностирования.
- Во второй главе представлен подход к тестовому диагностированию процессоров RISC архитектуры с использованием функциональных моделей.
- В третьей главе рассматривается процесс разработки функциональных тестов процессоров с использованием методики, представленной во второй главе, проводится анализ этой методики.
- В четвертой главе представлена экспериментальная оценка эффективности разработанных тестов на моделях процессоров, представлена и обоснована схема программного испытательного стенда. Эффективность рассматривается как совокупность двух показателей — длины тестовой программы (число ее команд) и качества теста.
- В пятой главе представлена методика тестового диагностирования механизма хранения и передачи данных конвейеризованных RISC процессоров. Методика разработана в соответствии с предложенным подходом к диагностированию механизмов процессора с параллелизмом уровня системы команд (конвейеризованный или суперскалярный процессор).
Основное содержание диссертации изложено на 105 страницах и включает 25 рисунков и 9 таблиц. 11 приложений на 24 страницах включают 3 рисунка и 13 таблиц. Список литературы включает 44 наименования.
Архитектура и тестовое диагностирование реконфигурируемых систем
Как показано выше, универсальные процессоры широко применяются в автоматизированных системах, Такие системы реализуются аппаратурой с высокой степенью интеграции, их элементы представляют собой СНК. Перспективные системы обладают свойством динамической реконфигурации при изменении внешних условий. Современные процессоры и системы, их использующие, представляют собой сложные объекты диагностирования. Сложность процессора относится как к его организации (конвейеризация, неупорядоченное выполнение команд и т.д.), так и к исполнению. Разработка современных систем и их тестов требует значительных затрат времени и других ресурсов. Поэтому используемые при проектировании систем тестового диагностирования и тестов сложных цифровых устройств методы должны предусматривать автоматизацию.
Под процессором понимается цифровая система, управляемая программой. Процессор может быть аппаратно реализован на кристалле кремния как одна интегральная микросхема или, что характерно для перспективных систем, как модуль в составе микросхемы. Такую аппаратную реализацию называют микропроцессором. Процессорный модуль в составе микросхемы СНК называют так же процессорным ядром. По своему назначению процессор может быть универсальным (общего назначения) или специализированным. Типичный специализированный процессор, - цифровой сигнальный процессор, предназначен для обработки измеренных и оцифрованных физических величин. В представленной работе анализируются проблемы, касающиеся тестирования универсальных процессоров. С учетом рассматриваемой области исследования термины процессор, микропроцессор и процессорное ядро используются как синонимы.
При тестировании процессоров учитываются два факта. Первый состоит в том, что процессор - цифровая система. Второй - что он предназначен для выполнения программы и управляется программой. Использование первого факта привело к разработке методов тестирования процессоров, основанных на граничном сканировании [6, с.358] и использовании стандарта IEEE 1149.1 (JTAG) [6, с.395]. Эти методы используют вентильный и регистровый уровни представления системы. Использование второго факта привело к разработке методик, основанных на выполнении процессором специальных тестовых программ (программное тестирование). Методики программного тестирования используют уровни представления системы регистровый и системы команд, может использоваться и логический, вентильный.
Для решения задачи тестирования процессора, встроенного в систему, важно решить задачу минимизации объема тестового оборудования, встраиваемого в систему. А если система предусматривает динамическую реконфигурацию, и тестирование будет проводиться в работающей системе, то критическим становится еще и время тестирования. Очевидно, что к работающей системе подключение внешнего тестера может быть затруднено или невозможно. Одной из задач работы является разработка методики тестирования процессоров, позволяющей применить ее в перспективных системах, в том числе и во встроенной тестовой аппаратуре.
Методики самотестирования процессоров, основанные на граничном сканировании, универсальны, хорошо автоматизируемы и позволили достичь высокого качества теста, но оказались достаточно затратными, что касается
ресурсов системы и низкой скорости тестирования [31]. А необходимость сокращения временных затрат на разработку и возможность реконфигурации означают, что точная логическая вентильная схема процессора, на известности которой основана методика граничного сканирования, на момент разработки теста и тестового оборудования может быть неизвестна.
В то же время в работах [22, 26 — 28, 37] показано, как программное тестирование можно эффективно применить для тестирования и самотестирования процессорных ядер в составе СНК. Тестирование, основанное на выполнении программ, проводится на рабочей частоте, поэтому занимает мало времени. Для разработки тестовой программы может быть необязательным знание точной логической схемы всего процессора, что существенно для реконфигурируемой аппаратуры. Экспериментальные данные, полученные Максвеллом и Айткеном [18], показали, что уровень обнаружения физических неисправностей в микропроцессоре для программного теста с 75% покрытием константных неисправностей при моделировании такой же, как у теста, основанного на граничном сканировании, с более высоким покрытием. Перечисленные факторы определили преимущества программных методов тестирования.
Проанализируем существующие методики программного тестирования.
В работах по программному тестированию можно выделить два основных подхода к разработке тестов. Первый основан на использовании функциональных моделей. Второй основан на соответствии системы команд и ее реализации. В последние годы разработано множество методик, комбинирующих различные подходы к диагностированию, в том числе использующие точные регистровые и вентильные модели процессора, его структурных модулей и модель одиночной константной неисправности. Рассмотрим подробно каждый из подходов.
При каноническом подходе [20, 16], давшем еще одно название этой методологии тестирования в целом - функциональное тестирование, процессор рассматривается с точки зрения своей общей функциональности (передача, хранение, обработка данных и управление) и ее связи с архитектурой системы команд. Он представляется как система взаимодействующих функций. Тесты разрабатываются для каждой функции отдельно. Тест процессора включает тесты всех его функций. При разработке тестов функций руководствуются моделями исправной работы и неисправности функций в приложении к системе команд. Качество теста определяют эти функциональные модели. Этот подход хорош тем, что позволяет разработать достаточно компактные тесты и не требует знания вентильной схемы. К недостаткам следует отнести значительные затраты усилий человека на разработку тестов при усложнении процессора, а так же, что метод не универсален. При неизвестном алгоритме работы какой-то функции, хороший тест для нее разработать нельзя. Это касается, прежде всего, функций обработки данных.
Методика функционального тестового диагностирования механизмов передачи и обработки данных
В соответствии с выбранным функциональным подходом к тестированию [14] процессор рассматривается как система взаимодействующих функций, для выполнения каждой из которых предусмотрен свой механизм. Под механизмом понимается часть аппаратуры, выполняющая определенную функцию (структура самого механизма может быть неизвестна). Общий набор механизмов любого процессора один и тот же: хранение и передача данных, управление передачей; обработка данных, управление обработкой; управление выполнением команд. Функции механизмов в конкретном процессоре определяет его архитектура.
Тестирование микропроцессора подразумевает тестирование всех его механизмов. При разработке теста конкретного механизма, неисправности других механизмов во внимание не берутся, эти механизмы полагаются исправными. Так же предполагается, что тест механизма обнаружит максимальный процент неисправностей аппаратуры микропроцессора, относящейся именно к этому механизму. Концепция механизмов и их независимого тестирования позволяет для каждого механизма найти свои, максимально точно отражающие его работу, модели, модели неисправностей и методы синтеза теста.
Рассмотрим функциональные модели и процедуры генерирования тестов для каждого из механизмов процессора.
Механизм хранения и передачи данных представляет функцию хранения и обмена данными между регистрами микропроцессора. Модель механизма хранения и передачи данных включает все регистры, определенные на некотором уровне абстракции процессора, и передачи данных между ними под
управлением программы. Для рассматриваемой методики это - уровень архитектуры системы команд. Используется графическое представление модели этого механизма — граф регистровых передач (ГРП).
Для разработки теста механизма используется подход, представленный в [4, с. 121]. Представлю кратко этот подход. По исходному описанию строится граф-модель (ГМ) процессора на данном уровне абстракции, (см. рис. 2.3). ГМ - направленный граф. Он включает три типа узлов: множество R = {RO, R1, ... R-m-i} регистров; множество F — {FO, F1, ... Fn_i} функциональных узлов; две вершины - IN, OUT, соответствующие внешним портам (памяти и внешним устройствам). Множество направленных дугЕ = {ЕО, Е1, ... Еы} эквивалентно множеству передач данных между узлами, управляемых множеством команд / = {10, II, ... 1ц}. Каждая дуга включает несколько проводников, соответственно разрядности передаваемых по ней данных. Узлы ГМ обладают следующими свойствами:
1. любая команда \\ ЕІ передает данные по дугам между парой регистров (Rj, Rk) eR; узлы ieF передают данные без задержки;
2. каждый регистр всегда включает 1 вход и 1 выход, число входов и выходов узла соответствует числу входящих и выходящих дуг. Дуги ГМ нагружены списками команд 1[ЄІ, управляющих передачей данных по ним. ГМ для конкретной архитектуры определяется следующей процедурой: Процедура 2.1. Построение графа-модели Вход: множества R, F, Е, I. Выход: ГМ.
1. Если существует хотя бы одна команда из /, при которой данные передаются из регистра Rj-є или выхода функционального узла Y\&F в регистр Rk EJ? или на вход узла FJGF, то в ГМ строится дуга, направленная от Rj или F; к Rk или входу Fi. Эта дуга помечается списком команд из /, активирующих эту передачу.
2. Если существует хотя бы одна команда из I, при которой данные передаются из внешнего порта в регистр R eR или на вход узла FjeF, то в ГМ строится дуга, направленная от вершины IN к Rk или входу \. Дуга помечается аналогично.
3. Если существует хотя бы одна команда из 7, при которой данные передаются из регистра Rjei? или выхода функционального узла FJGF на внешний порт, то в ГМ строится дуга, направленная от Rj или Ft к вершине OUT. Дуга помечается аналогично.
Модель механизма не включает функциональные узлы, поэтому они исключаются из графа-модели. Исключение функциональных узлов - операция замены множества дуг и узла на множество дуг. Полагаем, что в каждом узле, если он исправен, данные могут передаваться без искажения с любого входа на любой выход.
Порядок исключения узлов. Рассмотрим произвольный узел w со входами Xi, х2 ... хп и выходами Заменим узел w совокупностью р дуг, где р = max(m, п), следующим образом: 1. Если n т, то выберем вход xv такой, что существует путь от вершины IN к xv, который не превосходит по длине любой путь от IN к любому m 36 другому входу узла.
Разработка тестов механизмов хранения и передачи данных
Рассмотрим процесс разработки тестов механизмов хранения и передачи данных. При рассмотрении предполагается, что процесс должен быть автоматизированным. Тесты механизмов процессоров DP32 и DLX создавались с использованием этого процесса, в то же время процедуры уточнялись в ходе создания этих тестов. В основе процесса лежит методика построения тестов механизма, представленная в разделе 2.2.2. На рис. 3.1 представлена общая схема разработки тестов механизма хранения и передачи данных в соответствии с этой методикой.
Моделью механизма является граф регистровых передач, в котором каждая команда в ходе своего выполнения активизирует определенный путь. Механизм неисправен, если в результате активизации последовательностями команд (с тестовыми операндами и адресами) подмножества путей ГРП, покрывающего все его дуги, хотя бы один операнд или адрес будет изменен. Тестовые операнды и адреса — наборы «теста переноса», обнаруживающего произвольные сочетания констант 0 и 1 на разрядных линиях шин и на перемычках между этими линиями [14, 4, с. 124].
Как следует из методики построения теста (см. раздел 2.2.2 и рис. 3.1), а так же видно из формулировки модели механизма и его неисправности, одним из ключевых понятий, определяющих процесс разработки теста, является понятие команды процессора. В [4, с. 121] дано общее понятие команды, отмечается, что можно использовать любое удобное обозначение команд.
Понятие команды включает информацию о прохождении данных по дугам через те или иные функциональные узлы в направлении от вершины IN к вершине OUT. В [4, с. 122] рассматриваются отдельные команды и множества команд. Отдельной команде, активизирующей путь в ГРП, в каждом такте работы процессора соответствует единственная дуга. Множеству команд в некоторые такты работы соответствует множество дуг. В ГМ командам в некоторые такты их выполнения соответствуют последовательности дуг, соединенные с функциональным узлом. Для разработки теста механизма определим команду как управляющее слово процессора, за каждый такт выполнения активизирующее пересылку данных по единственной дуге ГРП без их изменения.
Первая процедура в ходе разработки теста — процедура построения ГМ по спецификации архитектуры (см. рис. 3.1). Описание процедуры построения ГМ (см. раздел 2.2.2) достаточно определенное и полное, поэтому может быть легко формализовано.
Вторая процедура в ходе разработки теста — процедура исключения функциональных узлов из ГМ. Порядок исключения функциональных узлов определяют правила, представленные в разделе 2.2.2 (см. рис. 2.4). Последовательность исключения узлов этими правилами не определена, кроме того, правила не учитывают обработку данных в узлах. Доопределим правила, внеся в них соответствующие дополнения.
Первое дополнение касается учета обработки данных в узлах. При прохождении узлов обработки данных, тестовые данные не должны меняться. Поэтому для команд, активизирующих пересылки через узлы обработки, операции обработки и другие операнды должны быть соответственно выбраны. Так команда, активизирующая путь через арифметическое устройство, должна включать код операции и операнды, не меняющие тестовых данных, например, сложение с нулем. Процедура исключения функциональных узлов определяет списки команд, убирая операции с неподходящей обработкой и налагая ограничения на операнды.
Второе дополнение касается последовательности исключения узлов. Результирующий ГРП зависит от этой последовательности, поэтому исключать узлы в произвольном порядке нельзя. В некоторых случаях ГРП, полученный в результате произвольного исключения узлов, может оказаться бессмысленным, что означает невыполнимость задачи его полного обхода (см. рис. 3.2). Тестирование передачи данных через регистр R3 в этом ГРП невозможно.
Устранить это противоречие возможно двумя способами. Первый способ основан на введении порядка исключения узлов. Дополним правила исключения функциональных узлов (см. раздел 2.2.2) следующими правилами:
1. Все выходы на контуры с исключаемых узлов соединяются со входами путей от вершины IN.
2. Все входы в исключаемые узлы с контуров соединяются с произвольными выходами, кроме выходов на контуры.
3. Функциональные узлы исключаются из ГМ в порядке, определяемом расстоянием от вершины IN.
При использовании дополненных правил исключения функциональных узлов все регистры (не исключаемые узлы) ГРП, полученного в результате операции исключения узлов, останутся соединенными путями с вершинами IN и OUT.
Формальная модель зависимости ГРП от порядка устранения узлов в ГМ, а так же соответствующая теорема и ее доказательство представлены в приложении 1. Условием применения правил исключения узлов являются данные о входах и выходах исключаемых узлов на контуры. Контуры в ГМ, выходы на них с исключаемых узлов и входы с них в исключаемые узлы определяются процедурой обнаружения контуров в ГМ (см. приложение 2). Исходными данными для процедуры является формальная модель ГМ. Процедура основана на построении кратчайшего остова ГМ и последующего построения на его основе подграфа ГМ, сохраняющего частичную упорядоченность к вершинам IN и OUT.
Второй способ основан на использовании свойств RISC архитектуры. Множество регистров архитектуры таких процессоров ограничено большим числом однотипных регистров, управляемых и наблюдаемых с использованием команд класса LS. Контуры в графе-модели архитектуры обусловлены обработкой данных в этих регистрах с использованием команд класса ТМ. Поэтому в ходе генерирования ГРП все регистры соединяются с вершинами IN и OUT с учетом выполнения соответствующих команд класса LS.
Первый способ предполагает выполнение более сложной процедуры генерирования теста и подходит для любых процессоров. Второй способ приводит к незначительно более длинному тесту. В целом второй способ менее затратный и лучше подходит именно для RISC процессоров.
Разработка испытательного стенда с использованием совместной работы двух программ-имитаторов
Цель проведения экспериментов — оценка эффективности представленной методики разработки тестов. Необходимость оценки эффективности следует из необходимости решения практических задач. Приведем два примера: разработаны два теста для одного процессора, но с использованием разных методик или моделей; разработан тест для одной архитектуры, которая реализована в процессорах с использованием разных технологий или в разном базисе логических элементов. Как решить, пригоден ли тест к использованию, и какой именно тест использовать?
При решении практических задач руководствуются двумя основными показателями - качеством теста и его объемом. Всегда в первую очередь рассматривается возможность применения теста с лучшим качеством, но при жестких ограничениях на объем, например во встроенной тестовой аппаратуре, возможно использование менее качественного, но короткого теста. В работе эффективность рассматривается как совокупность двух показателей - длины тестовой программы и качества теста. Длина тестовой программы - число составляющих ее команд. Качество теста определяется в контексте некоторой модели неисправности как отношение числа неисправностей, обнаруженных тестом к общему числу таких неисправностей, возможных в системе (покрытие неисправностей). В качестве такой модели неисправности используется модель одиночной константной неисправности (далее — константная неисправность). Покрытие константных неисправностей рассчитывается для вентильной модели процессора. Это позволяет сравнивать качество тестов, полученных с использованием разных функциональных моделей на более высоких уровнях абстракции, а так же и с использованием вентильной модели процессора и модели константной неисправности. Как дополнительные показатели качества функционального теста, используются данные о покрытии метрик, характеризующих модель процессора как программу на ЯОА. Это подсчет покрытия ветвей, процедур, операторов, логических условий ветвлений и циклов, логических выражений [42]. Таким образом, в проводимом исследовании подход к оценке функциональных тестов определяется следующими факторами: - для разработки функциональных тестов используются разные логические модели - графы, алгебра высказываний, конечные автоматы и др.; — для разработки тестов используются логические модели высоких уровней абстракции системы, а для оценки качества этих тестов используется модель вентильного уровня абстракции — логическая сеть и одиночные константные неисправности, отображение в которую модели высокого уровня неоднозначно.
Задача исследования - по результатам экспериментальной оценки эффективности методики разработки тестов сделать вывод о возможности применения функциональных тестов для определения технического состояния процессоров, в том числе при условии реализации тестового оборудования как встроенных средств самотестирования.
По данным, приводимым в исследовательских работах [26, 27, 28, 37], объем встроенного теста для самотестирования несложных процессоров находится в пределах от 1 до 10 тыс. команд. Что касается качества, то по данным исследований [18, 26-28, 37] оно считается приемлемым, когда функциональный тест покрывает более 90% одиночных константных неисправностей вентильной модели процессора. Несущественные неисправности исключаются. У процессоров, разработанных по технологии с повторным использованием разработанных ранее узлов, этот показатель может быть ниже (80-90%) [38, 39]. Лучшие показатели качества (см. раздел 1.6) составляют 94 - 95% покрытия константных неисправностей для моделей простых процессоров и 90 - 91% — для более сложных.
Качество теста рассчитывается в ходе имитационного моделирования. Моделирование — основа проектирования современных цифровых систем. В этом контексте уровни абстракции цифровой системы, представленные в таблице 1.1 относятся именно к представлению системы в виде моделей для имитационного моделирования.
Любая цифровая система может быть представлена своей поведенческой, функциональной и структурной моделью [6, с.9-37]. Каждая модель -поведенческая, функциональная или структурная отражает какое либо свойство системы или схемы. Функциональная модель отражает свойство системы отображать свои входы на выходы. В зависимости от уровня абстракции - это отображение логических значений, слов данных и т.д. Моделью системы здесь является ее логическая функция. Поведенческая модель представляет функционирование системы во времени. Она добавляет к функциональной модели временные зависимости. Структурная модель представляет систему как набор взаимосвязанных «черных ящиков», называемых структурными компонентами или структурными элементами. Структурная модель является иерархической, поскольку структурные элементы более низкого уровня так же представляются их структурными моделями. Элементы нижнего уровня, представленные функциональными или поведенческими моделями, называют базисными.
