Программные продукты и системы, 2010, № 4

Программные продукты и системы
№ 4, 2010 г.

3

УДК 004.416.2

РАЗВИТИЕ СПЕЦИФИКАЦИЙ JTAG 

ДЛЯ ОТЛАДКИ АППАРАТНОГО И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

В.А. Галатенко, д.ф.-м.н.; К.А. Костюхин, к.ф.-м.н.; Н.В. Шмырев, к.ф.-м.н. 

(НИИ системных исследований РАН (НИИСИ РАН), г. Москва, 

galat@niisi.msk.ru, kost@niisi.msk.ru, shmyrev@niisi.msk.ru)

В работе дается краткий обзор базовых спецификаций JTAG,  новых спецификаций cJTAG и некоторых корпо
ративных расширений, помогающих использовать JTAG в качестве отладочного интерфейса.

Ключевые слова: JTAG, cJTAG, EJTAG, отладка.

Отладка отдельных аппаратных компонентов, 

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

Необходимым условием решения перечислен
ных проблем является стандартизация средств 
тестирования, в частности, тестовых интерфейсов.

В 1985 году для разработки стандартов тести
рования интегральных схем и печатных плат была 
образована Объединенная группа тестового доступа (Joint Test Access Group (JTAG)). Спустя почти 15 лет предложения этой группы оформились в 
виде стандарта IEEE STD. 1149.1–2001 (IEEE Standard Test Access Port and Boundary Scan Architecture [1]). Параллельно ряд других групп и корпораций, например MIPS, развивали свои стандарты 
и спецификации, такие как Enhanced JTAG (EJTAG
[2]). Развитие спецификаций JTAG продолжалось 
и в рамках IEEE: в феврале 2010 года была опубликована новая, значительно расширенная версия 
стандарта IEEE Std. 1149–7.2009 (IEEE Standard 
for Reduced-Pin and Enhanced-Functionality Test 
Access Port and Boundary-Scan Architecture [3]).

Основная цель настоящей статьи – анализ того 

нового, что появилось в стандарте [3]. Также рассматриваются корпоративные расширения стандарта [1], представляющие, на взгляд авторов, 
наибольший интерес.

Стандарт IEEE 1149.1 – базовые 

спецификации JTAG

Стандарт IEEE 1149.1 создан для поддержки 

тестирования функциональности аппаратных компонентов, их взаимосвязей и взаимодействий в составных аппаратных продуктах. Объектом стандартизации является тестирующее устройство.

Тестирующее устройство, соответствующее 

стандарту IEEE 1149.1, содержит один регистр 
инструкций, несколько регистров тестовых данных, а также контроллер порта тестового доступа 
(Test Access Port (TAP)), управляющий всеми операциями по тестированию.

Стандарт предусматривает метод граничного 

сканирования, в котором используются сканирующие ячейки, подсоединенные к входу и выходу тестируемых элементов и образующие в совокупности последовательный сдвиговый регистр. 
Тестовые шаблоны продвигаются управляющим 
устройством шины TAP через контроллер TAP в 
компоненты и подводят известные значения к 
сканирующим ячейкам. Предыдущее содержимое 
сканирующих ячеек выдвигается из компонентов 
и может быть подхвачено управляющим устройством шины TAP.

Согласно стандарту IEEE 1149.1 регистр ин
струкций должен содержать не менее двух бит; он 
используется для управления тестовой функциональностью.

Регистры данных специфичны для конкрет
ных устройств, однако стандарт предусматривает 
наличие по крайней мере двух подобных регистров – однобитного регистра обхода и регистра 
граничного тестирования.

Стандартом предусмотрены следующие ин
терфейсные сигналы на шине TAP (направление 
указывается с точки зрения управляющего устройства шины TAP):

1) тестовый тактирующий сигнал (Test Clock

(TCK), последовательные тактирующие сигналы, 
выходной);

2) выбор тестового режима (Test Mode Select

(TMS), переходы в конечном автомате JTAG, выходной);

3) исходные тестовые данные (Test Data Input

(TDI), доставляются к тестируемым компонентам, 
выходной);

4) выходные тестовые данные (Test Data 

Output (TDO), извлекаются из тестируемых компонентов, входной);

5) перезагрузка тестов (Test Reset (nTRST), не
обязательный сигнал для асинхронной инициализации тестов, выходной).

Программные продукты и системы
№ 4, 2010 г.

4

Сигнал TCK позволяет загружать тестовые 

данные в набор компонентов независимо от системной тактовой частоты последних.

Функционирование JTAG
определяется ко
нечным автоматом, реализованным в контроллере 
TAP. Сигнал TMS служит для выбора маршрута в 
конечном автомате JTAG [1].

От устройств, удовлетворяющих стандарту 

IEEE 1149.1, требуется поддержка ряда тестовых 
инструкций. Перечислим наиболее употребительные из них.

 BYPASS. При выборе для устройства данной 

инструкции однобитный регистр обхода подключается в качестве регистра тестовых данных. Это 
позволяет укоротить цепочку сканирования, состоящую из нескольких последовательных устройств, тем самым ускоряя тестовый доступ. Устройство в режиме обхода не должно выполнять 
никаких тестовых операций. Кодом операции для 
инструкции обхода могут служить все единицы 
(для 4-битного регистра инструкций – 0xF), но и 
другие коды могут отображаться на эту инструкцию.

 EXTEST. Обязательная инструкция EXTEST

выбирает регистр граничного сканирования в качестве текущего регистра тестовых данных.

 IDCODE. 
Дополнительная 
инструкция 

IDCODE выбирает регистр идентификации устройства в качестве текущего регистра тестовых 
данных.

В связи с развитием технологий проектирова
ния, разработки и производства микросхем возникла ситуация, требующая дополнения и расширения стандарта IEEE 1149.1. Кроме того, появился ряд корпоративных расширений, позволяющих 
использовать механизм JTAG не только для тестирования, но и для отладки аппаратных компонентов. Рассмотрим эти расширения более подробно.

Новое в стандарте IEEE 1149.7

Стандарт IEEE 1149.7, называемый также 

cJTAG (compact JTAG), не является революционным обновлением стандарта IEEE 1149.1. Он полностью совместим со своим предшественником и 
представляет новые расширения JTAG, призванные улучшить характеристики JTAG и расширить 
область его применения.

Основные отличия cJTAG от JTAG следую
щие: звездная топология, расширенные возможности управления
электропитанием, уменьшение 

числа обязательных контактов до двух.

Стандарт 1149.7 охватывает две группы ха
рактеристик, каждая из которых подразделяется 
на классы. Первая группа характеристик представляет собой расширение стандарта 1149.1, то 
есть определяет ряд усовершенствованных методов тестирования, реализация которых в рамках 
традиционного стандарта JTAG даже не предпола
галась. Вторая группа характеристик определяет 
двухконтактный протокол функционирования таких усовершенствованных JTAG-структур. Стандарт 1149.7 подразделяется на шесть операционных классов, каждый из которых строится на базе 
функций, задаваемых предыдущим классом. Классы Т0–Т3 относятся к первой группе характеристик, а классы Т4 и Т5 – ко второй.

Класс Т0 определяет совместимость инте
гральных схем (ИС), поддерживающих стандарт 
1149.1 (ИС.1), и ИС, поддерживающих стандарт 
1149.7 (ИС.7), в рамках одной и той же схемы.

Характеристики класса Т1 определяют так на
зываемые уровни управления (УУ) ИС.7, которых 
нет для ИС.1. Эти уровни управления являются 
основой построения всех функций, определяемых 
классами Т1–Т5, и базируются на диаграмме состояний контроллера ТАР, описанной в стандарте 
1149.1. 

Введение УУ ИС.7 является ключевым нов
шеством стандарта 1149.7, которое заключается в 
использовании последовательностей состояний 
диаграммы ТАР в сочетании с подсчетом количества обходов состояния Shift-DR, то есть числа невхождений в это состояние диаграммы ТАР. УУ
ИС.7 приведены в таблице.

УУ ИС.7 Функция перегрузки
DR-сканирование

0–1
Нет
Системное

2
Команды управления
Бит обхода на уровне 
чипа

3
Нет (резерв)
Резерв

4–5
Добавочные пути сканирования

Определяется пользователем

6–7
Используется системой 
отладки

Определяется пользователем

Иерархия управления структурой 1149.7 обра
зует основу, на которой базируется двухконтактный протокол, определяемый классами Т4 и Т5. 
Поскольку команды управления представляют собой некоторую функцию последовательности переходов между состояниями диаграммы ТАР, для 
управления протоколом требуются лишь два контакта – TCK и TMS. 

Кроме определения УУ, класс Т1 определяет 

несколько режимов выключения питания ИС.7, 
что может быть критичным при тестировании самих ИС и ПП, а также при отладке тестов.

Класс Т2 определяет механизм обхода ИС.7 на 

уровне чипа, который предназначен для укорачивания цепочек сканирования при разработке тестов сложных схем. Этот же класс обусловливает 
механизм так называемого горячего включения 
ИС.7. Для реализации этих новых возможностей 
класс Т2 определяет три формата JTAG-сканирования.

1. JSCAN0 – операции, совместимые с тради
ционным JTAG-стандартом 1149.1. 

Программные продукты и системы
№ 4, 2010 г.

5

2. JSCAN1 – обеспечивает защиту при горячем 

включении и отключении ИС.7, обусловливая обход всех подключенных ИС.7 при включении питания по умолчанию. Этот формат предназначен 
для защиты отдельных портов ТАР от непреднамеренных подключений и предотвращения повреждения функциональных ядер при горячем 
включении. 

3. JSCAN2 – обеспечивает обход ИС.7 на 

уровне чипа для последовательных цепочек ИС. 
Этот механизм работает как дополнительный 
фильтр, разрешающий доступ к порту ИС.7 только 
после выполнения заданной последовательности 
операций, содержащих, кроме прочего, проверку 
стабильности электрических соединений.

Характеристики класса Т3 определяют воз
можность соединения ИС.7 звездой, что является 
определенным 
упущением 
стандарта 
1149.1, 

предполагающего соединение ИС только в цепочку. Соединение звездой обеспечивает новый формат JSCAN3, для определения которого в классе 
Т3 используется специальный регистр «Только 
для записи». Стандарт 1149.7 предусматривает 
также возможность адресации каждой из ИС.7 при 
соединении их звездой. 

Класс Т4 вводит ряд дополнительных форма
тов сканирования для поддержки протокола передачи тестовых данных при помощи только двух 
контактов порта ТАР вместо четырех. Контакты 
передачи данных TDI и TDO не используются, а 
тестовые данные передаются по теперь уже двунаправленной цепи TMSC. Кроме того, класс Т4
определяет ряд оптимизированных режимов ввода 
тестовых данных, позволяющих вводить только 
необходимые данные, без повторов и избыточности.

Функции класса Т5 ориентированы в основ
ном на разработчиков ПО, использующих протокол JTAG в целях отладки. Основное преимущество этих функций заключается в сокращении числа 
контактов, предназначенных только для отладки, а 
также в использовании контактов TMSС и ТСКС
для реализации разнообразных пользовательских 
протоколов. 

Следует отметить, что наряду с полной со
вместимостью с традиционным стандартом 1149.1 
новый стандарт 1149.7 обеспечивает сокращение 
числа контактов сложных ИС типа System-on-Chip
(SoC), выключение питания ИС в схемах с пониженным потреблением, упрощает производство и 
тестирование многоядерных модулей и ИС с многоэтажными чипами, а также существенно повышает эффективность процедур отладки. 

Корпоративные расширения 

спецификаций JTAG

Значительную роль в распространении стан
дарта JTAG сыграло применение этого интерфейса 

для отладки приложений на микропроцессорах 
встраиваемых систем, в частности, спецификации 
EJTAG для семейства процессоров MIPS и спецификации для семейства процессоров ARM.

Расширения MIPS: 

спецификации EJTAG

EJTAG – спецификация программно-аппарат
ной подсистемы для семейства процессоров с ядрами MIPS. В качестве интерфейса доступа к данным и командам EJTAG использует инфраструктуру IEEE 1149.1 JTAG и расширяет семейство 
инструкций ядра MIPS, а также набор компонент 
ядра. Таким образом создается унифицированная 
архитектура для отладки встраиваемых систем. 
Спецификации EJTAG постоянно обновляются. На 
данный момент последней является спецификация 
EJTAG версии 5.00 [2], вышедшая в июне 2009 г.

Первоначально в основу отладочной архитек
туры MIPS легла RISC-философия, ориентирующаяся на минимизацию аппаратной составляющей. Первые ядра MIPS определяли небольшой 
набор примитивов отладки – инструкцию прерывания, порождающую исключение, инструкции 
проверки значений регистров, пару необязательных регистров слежения за памятью, а также специальный режим устройства управления памятью, 
позволяющий реализовать защиту от изменения. 
Все эти механизмы требовали поддержки программного обеспечения, выполняющегося на процессоре, – операционной системы или некоторого 
монитора, позволяющего вставлять точки прерывания и передавать данные пользователю. Кроме 
того, внешние анализаторы логики и эмуляторы 
контуров могли управлять выполнением приложений. 

Эта модель была достаточно эффективной, но 

при появлении сложных многоядерных конфигураций с несколькими ядрами на одном чипе использование внешних интерфейсов процессора 
значительно усложнилось. Одним из препятствий 
стала отладка приложений, выполняющихся из 
неизменяемой памяти, другим – необходимость 
наличия специального отладочного порта, что 
значительно затрудняет разработку встраиваемых 
систем, увеличивая их стоимость. Важно обеспечить отладку приложения в полевых условиях. 
Отладка с использованием интерфейса EJTAG позволила решить эти проблемы. Небольшая часть 
чипа, необходимая для этого интерфейса, была 
потрачена не зря.

Процессор с поддержкой EJTAG может быть 

встроен в цепь устройств и отлажен с помощью
внешнего оборудования. EJTAG использует стандартный интерфейс для доступа к TAP. Для 
управления процессором применяются перечисленные далее регистры контроллера TAP, дополняющие набор стандартных:

Программные продукты и системы
№ 4, 2010 г.

6

IMPCODE – для доступа к содержащейся в 

нем информации о процессоре и реализованных 
функциях EJTAG;

ADDRESS – для доступа к шине адреса;
DATA – для доступа к шине данных;
CONTROL – для управления процессором;
ALL – для одновременного доступа к шинам 

адреса, данных и управления;

EJTAGBOOT – для установки режима отладки 

после перезагрузки;

NORMALBOOT – для обычной перезагрузки;
FASTDATA – для ускоренного доступа к дан
ным;

TCBCONTROL[A–E] – для доступа к блоку 

трассировки;

TCBDATA – для доступа к данным трассиров
ки;

PCSAMPLE – для профилирования;
FDC – для доступа к каналу быстрой отладки.
Спецификация EJTAG описывает возможно
сти процессора.

Отладочное исключение и отладочный ре
жим. Для предоставления доступа к состоянию 
процессора в любой момент выполнения приложения в спецификации EJTAG описывается отладочное исключение, после которого процессор переходит в специальный отладочный режим. В 
этом режиме возможен свободный доступ к сопроцессору, памяти и другим устройствам. Исключения по доступу к адресу и прерывания маскируются. Обработчик отладочного исключения 
предоставляется отладочной системой или приложением по решению разработчика. В случае необходимости разработчик может при наступлении 
отладочного исключения послать сигнал о нем 
внешним аппаратным модулям, заставляя их приостановить работу на время отладки.

Внешняя память EJTAG. EJTAG позволяет 

процессору MIPS в отладочном режиме выполнять 
инструкции, поступающие из TAP-интерфейса. 
Для этого память EJTAG в сегменте KSEG3 преобразуется в операции над интерфейсом TAP. И 
данные, и инструкции становятся доступными на 
инструментальной платформе, что позволяет отлаживать программы в постоянной памяти. Коммуникация с агентом отладки осуществляется посредством регистра CONTROL, бит которого говорит об ожидании процессора. После этого адрес 
транзакции выставляется в регистре ADDRESS, а 
данные – в регистре DATA. Бит в регистре управления обновляется, чтобы сигнализировать о совершении транзакции. 

Эта последовательность требует примерно 200 

периодов TCK при работе с 32-битными регистрами адреса и данных. С частотой 40 МГц это занимает порядка 5 мкс, а скорость передачи данных 
составляет 800 кБ/с. Оптимизация передачи может 
осуществляться с помощью программных методов, таких как предсказание следующего адреса, 

или регистра FASTDATA.

Инструкции 
останова.
Спецификации 

EJTAG определяют новую инструкцию SDBBP, 
отличающуюся 
от 
инструкции 
BREAK
ядер 

MIPS32 и MIPS64 тем, что ее исключение переводит процессор в отладочный режим и позволяет 
выполнить обработчик из внешней памяти EJTAG.

EJTAG определяет различные типы аппарат
ных точек останова. Исключение порождается до 
того, как действие приводит к изменению состояния процессора или памяти, например, прерывание по выполнению по адресу происходит после 
извлечения команды, но до того, как она будет 
выполнена. Прерывание по записи в память выполняется до того, как запись будет произведена. 
Аппаратные точки останова срабатывают без изменения памяти и поэтому обладают преимуществом перед программными.

EJTAG определяет два типа простых точек ос
танова:

 останов по выполнению инструкции по за
данному виртуальному адресу;

 останов по доступу к данным, причем сра
батывающий при некотором значении записываемых/считываемых данных.

Возможна реализация до 15 точек останова 

различных типов. 

Начиная с версии 4.00, спецификации EJTAG

определяют сложные точки останова различных 
типов, например, инструкции со счетчиками срабатывания, инструкции с условием останова по 
адресу выполнения и данным одновременно, точки останова для заданных процессов, точки останова, зависящие от других точек останова, точки 
останова по таймеру. Точки останова могут сигнализировать о начале трассировки, работа которой 
определяется спецификацией MIPS PDTrace.

В спецификации EJTAG предусмотрен режим 

пошагового выполнения, при этом приложение 
необязательно должно находиться в памяти процессора.

Режимы трассировки и профилирования.

Спецификации EJTAG содержат разделы, посвященные аппаратной трассировке PDTrace и аппаратному профилированию. Аппаратная трассировка позволяет передавать данные о выполнении 
приложения по специальному внешнему каналу на 
инструментальную машину. Аппаратная трассировка настраивается с помощью регистров TAP.

Поддержка аппаратного профилирования за
ключается в периодическом занесении текущей 
информации о выполнении приложения, такой как 
адреса инструкций, промахи в кэш-память или записываемые данные в регистр TAP PCSAMPLE, 
посредством которого она становится доступной
на инструментальной платформе.

Аппаратные компоненты. Аппаратная ин
фраструктура EJTAG состоит из нескольких компонент: расширений ядра MIPS, порта TAP, реги

Программные продукты и системы
№ 4, 2010 г.

7

стра управления отладкой, модуля точек останова. 
Не все компоненты являются обязательными, среди них следующие: пошаговое выполнение, порт 
TAP, прерывание по сигналу от TAP, модуль точек 
останова, модуль сложных точек останова, регистр управления отладкой, регистр профилирования, канал быстрой передачи данных.

Расширения для многоядерной отладки.

Спецификации MIPS MT ASE определяют процессоры, состоящие из нескольких виртуальных модулей VPE (виртуальный процессорный элемент). 
С точки зрения аппаратуры и приложений такой 
процессор не отличается от набора нескольких 
процессоров. EJTAG может поддерживать все VPE
по отдельности или модуль целиком. В первом 
случае каждое ядро должно иметь свой контроллер TAP и все они должны быть связаны в единую 
цепь, как определяет спецификация JTAG 1147.1. 
При этом значительная часть аппаратной составляющей не разделяется между модулями, каждый 
имеет свой отладочный регистр, регистр точек останова и т.д. Во втором случае ядра могут иметь 
один регистр отладки, поддерживать одновременное пошаговое выполнение и другие совместные 
отладочные 
действия. 
Версии 
спецификаций 

EJTAG определяют необходимые в этом случае 
изменения значений регистров.

Расширения семейства 

процессоров ARM

Спецификации семейства процессоров ARM

включают в себя архитектуру CoreSight, предназначенную для отладки и трассировки многоядерных процессоров. Данная архитектура не указывает на четкий набор аппаратной логики, а определяет то, как ядра могут взаимодействовать между 
собой, используя стандартный набор компонент и 
позволяя автоматически обнаруживать их, а также 
механизмы безопасности, обеспечивающие контроль доступа инструментальных средств к отладочной инфраструктуре.

Архитектура CoreSight не определяет жестко 

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

CoreSight определяет набор шин для много
ядерных архитектур, таких как AMBA AXI (Advanced eXtensible Interface) / AHB (Advanced Highperformance Bus), управляющая шина APB и шина 
для сбора трассы ATB, единый порт доступа DAP, 
который реализует TAP-контроллер для доступа с 
инструментальной машины. Порт доступа мультиплексирует управляющие команды, позволяя 
отдельно работать с каждым ядром. Кроме интерфейса TAP, контроллер отладки может поддержи
вать и более высокоскоростной последовательный
интерфейс SWD.

Каждое ядро, поддерживающее JTAG, управ
ляется посредством регистров TAP. Ядра могут 
поддерживать и более современную высокоскоростную шину APB. Высокоскоростная шина AHB
может использоваться для прямого доступа к памяти и другим устройствам в обход процессора.

Как уже отмечалось, каждый ARM-процессор 

имеет свои особенности реализации отладочных 
функций через TAP-интерфейс. В качестве примера опишем отладку ядер ARM11 и ARM1136.

Обычно ядро ARM11 интегрировано с различ
ными устройствами на одном чипе. Каждое из них 
может содержать свой контроллер TAP. Например, 
процессор OMAP2420 включает в себя TAP для 
граничного сканирования, ядро ARM1136 с отладочным контроллером TAP, буфер трассировки 
ETB11, DSP-модуль C55x и TAP для отладки графического чипа на основе ядра ARM7TDMI, при 
этом TAP граничного сканирования может быть 
исключен из JTAG-цепи [4]. Такая конфигурация 
позволяет отлаживать устройства в режиме малого 
потребления 
энергии, 
так 
как 
процессор 

OMAP2420
предназначен для мобильных уст
ройств.

Регистры, поддерживаемые TAP, включают в 

себя:

 SCAN_N – инструкции для того, чтобы вы
брать цепь для сканирования с помощью стандартных механизмов INTEST/EXTEST. Определены несколько цепей: 

− 40-битный регистр-идентификатор;
− 32-битный регистр управления отладкой 

(DSCR);

− регистр для записи инструкций в режиме 

отладки (ITR), 33 бита (32 бита инструкции + 1 
бит состояния);

− регистр для передачи данных (DCC), 34 би
та (одно слово + 2 бита состояния); этот регистр 
может использоваться как во время отладки, так и 
при обычном выполнении;

− регистр управления трассой (ETM), 40 бит 

(7 бит адреса, 32 бита данных и один бит чтениязаписи);

− отладочный модуль для доступа к точкам 

останова (7 бит адреса, 32 бита данных и один бит 
чтения-записи). Эта цепь может записываться даже в режиме выполнения процессором приложения;

 HALT, RESTART – инструкции для останова 

и перезапуска процессора;

 ITRSEL – инструкция, специфичная для 

ARM11 и предназначенная для ускорения работы с 
цепью ITR.

В отличие от ядра MIPS регистры управления 

здесь не являются регистрами TAP, а читаются и 
записываются с помощью INTEST/EXTEST. В других ядрах ARM используется похожая модель 

Программные продукты и системы
№ 4, 2010 г.

8

управления, но другой аппаратный интерфейс. В 
более 
старых 
ядрах 
использовался 
модуль 

EmbeddedICE. В более новых, таких как Cortex-A8, 
предпочтение отдается высокоскоростному методу доступа к DAP с помощью последовательной 
шины SWD.

Процесс отладки приложений ARM достаточ
но стандартен. Контроллер TAP может прервать 
выполнение ядра, переведя его в отладочный режим с помощью HALT, затем считать регистры и 
данные, используя команды ITR и DCC. После выполнения отладочных действий инструментальное 
ПО восстанавливает регистры и продолжает выполнение с помощью инструкции RESTART.

Процессор может войти в отладочный режим 

по точке прерывания или по выполнению инструкции BKPT из программы. Когда цепь трассировки ETM не используется для трассировки инструкций, она тоже может вывести процессор в 
отладочный режим по наступлению определенного состояния, так как поддерживает триггеры, настраиваемые на заданные значения шины адреса и 
шины данных. Для определения момента останова 
процессора используется опрос регистра DSCR. 
Для пошагового режима необходимо прервать выполнение, установить точку прерывания и запустить процессор, затем удалить точку прерывания.

Мониторинг. В ядрах ARM поддерживается и 

сбор информации, не вносящий значительные изменения в приложение. Процессоры ARM поддерживают специальный режим мониторинга, в нем 

точки останова передают управление специальному обработчику, код которого включается в приложение. Этот обработчик может передать данные 
с использованием регистра DCC или инициировать пошаговую отладку одного из процессов, в то 
время как остальные процессы будут продолжать 
свою работу.

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

Литература

1. IEEE STD. 1149.1-2001. URL: http://standards.ieee.org/re
ading/ieee/std_public/description/testtech/1149.1-1990_desc.html
(дата обращения: 7.06.2010).

2. MIPS EJTAG 5.00. 2009. URL: http://www.mips.com (да
та обращения: 7.06.2010).

3. IEEE 
Standard 
for 
Reduced-Pin 
and 
Enhanced
Functionality Test Access Port and Boundary-Scan Architecture. 
2009.
URL: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnum
ber=5412866 (дата обращения: 7.06.2010).

4. Городецкий А. Новый JTAG-стандарт IEEE 1149.7.

Компоненты и технологии. № 4. 2010.

5. DBJTAG User Guide. Texas Instruments. URL: http://wi
ki.davincidsp.com/images/9/90/Dbjtag_users_guide.pdf (дата обращения: 15.06.2010).

УДК 004.021

ПАРАЛЛЕЛЬНАЯ ГЕНЕРАЦИЯ ПРОСТРАНСТВА 

СОСТОЯНИЙ ДИСКРЕТНЫХ ДЕТЕРМИНИРОВАННЫХ МОДЕЛЕЙ

И.А. Коротков (НИИСИ РАН, г. Москва, twee@tweedle-dee.org)

Основной проблемой проверки конечных моделей является комбинаторный взрыв числа состояний, которые с 

ростом размера модели становится трудно хранить в ОЗУ одной машины. Рассматривается подход к проверке моделей на основе параллельной генерации состояний и их распределенного хранения. Предлагается схема распределенного хранения состояний, позволяющая уменьшить число удаленных вызовов между узлами в процессе генерации. 
Приводятся результаты экспериментов, полученные при помощи разработанного программного средства.

Ключевые слова: формальная верификация, проверка моделей, генерация состояний, параллельные вычисления, 

язык Promela.

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

Для этого осуществляется проверка модели 

(model checking) – автоматический формальный 

подход, при котором на основе дискретной детерминированной модели программы или комплекса 
программ строится полное пространство состояний и на нем проверяется набор интересующих 
утверждений – спецификация [1].

Проверку моделей можно использовать для 

поиска взаимоблокировок в параллельных алгоритмах и ошибок в спецификациях сетевых протоколов. В качестве примера можно привести протокол маршрутизации RIP: проверка модели сети из 
четырех маршрутизаторов, соединенных четырьмя 

Программные продукты и системы
№ 4, 2010 г.

9

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

Формальное описание проверки моделей.

Пространство состояний моделируемой программы или программного комплекса можно формализовать как модель Крипке (структуру Крипке). 
Моделью Крипке M над множеством атомарных 
высказываний AP называют четверку M=(S, S0, R, 
L), где S – конечное множество состояний; S0S –
множество начальных состояний; RSS – отношение переходов, обязанное быть тотальным, то 
есть для каждого состояния sS должно существовать такое состояние sS, при котором имеет 
место R(s, s); L:S2AP – функция, помечающая 
каждое состояние множеством атомарных высказываний, истинных в этом состоянии.

Пусть в модели M состояние s – бесконечная 

последовательность состояний =s0s1..., где s0=s и 
для всех i0 выполняется R(si, si+1).

Моделируемый программный комплекс в каж
дом своем состоянии описывается набором значений переменных V={s0, s1, …} на конечном множестве D (домене интерпретации), описывающих 
отдельные компоненты и взаимодействие между 
ними. Множество AP состоит из утверждений вида vi=di, где diD. Таким образом, каждое состояние s в M представляет собой отображение VD.

Отношение R определяется следующим обра
зом. Пусть существуют два состояния – s1 и s2. Если в s1 имеется компонент, который может выполнить атомарный переход (изменение значений 
своих переменных), в результате чего система будет находиться в состоянии s2, значит, состояния 
s1 и s2 связаны отношением перехода (s1, s2)R. 
Если нет такого состояния s2, для которого выполнялось бы R(s1, s2), получается R(s1, s1), то есть
тупиковое состояние s1, связанное отношением
перехода самого в себя.

Для формализации проверяемых на модели M

утверждений обычно используются временные 
логики: LTL (linear time logic) – логика линейного 
времени, CTL (computation tree logic) – логика ветвящегося времени, CTL* – объединение LTL и 
CTL. Формулы в CTL* составляются из атомарных 
утверждений относительно значений переменных 
vi и кванторов: A (all) – для всех путей, выходящих из данного состояния; E (exists) – существует 
путь, выходящий из данного состояния; F (finally) – рано или поздно в пути встретится состояние, в котором выполняется...; G (globally) – во 
всех состояниях пути выполняется...; X (next) – в 
следующем состоянии на данном пути выполняется...; U (until) – пока в пути не появится состояние, 
в котором выполняется y, во всех состояниях 
должно выполняться x.

Например, AFGx означает, что во всех путях, 

идущих из начального состояния, с некоторого состояния на протяжении всего пути выполняется x, 
а AGEF – во всех путях, идущих из начального 
состояния, из каждого состояния есть хотя бы 
один путь, в котором рано или поздно встретится 
состояние, в котором выполняется x.

Средство проверки модели SPIN. Это наи
более распространенное средство, использующее 
для описания исходной модели язык Promela
(PROtocol Meta Language). 

Модель на языке Promela описывается в виде 

набора процессов, состоящих из последовательности команд. Каждый процесс имеет свой набор 
локальных переменных (в том числе счетчик команд). Для взаимодействия между процессами могут использоваться глобальные переменные и каналы (очереди сообщений). Каждая команда имеет 
свое условие выполнимости, и процесс считается 
заблокированным, если условие выполнимости 
его текущей команды не выполнено.

Приведем пример описания модели семафора 

Дейкстры и трех захватывающих его процессов в 
нотации Promela.

mtype { p, v };
chan sema = [0] of { mtype };
active proctype Dijkstra()
{      byte count = 1;

do
:: (count == 1) ->

sema!p; count-
:: (count == 0) ->

sema?v; count++

od

}
active [3] proctype user()
{       do

:: enter: sema?p; /* enter critical section */

crit: skip;    /* critical section */

sema!v; /* leave critical section */

od

}
В ходе верификации SPIN выполняет исчер
пывающий поиск в глубину по графу состояний 
(модели Крипке) и при обнаружении пути, на котором нарушается проверяемое утверждение, сохраняет его в качестве контрпримера. Если контрпример обнаружить не удается, верификация успешна. Функциональная схема процесса проверки 
модели изображена на рисунке 1.

Генерация 

пространства 

состояний A1

Проверка 

утверждений

A2

Множество

Генератор

состояний

Набор 

или успешность проверки

Множество 
автоматов 

Мили

Модель Крипке

Набор 

утверждений

Генератор состояний
Средство проверки 

утверждений

Контрпример, 

или 

успешность 

проверки

Рис. 1

Программные продукты и системы
№ 4, 2010 г.

10

Проблемы традиционного подхода. При рос
те числа и сложности компонент моделируемого 
программного комплекса происходит комбинаторный рост числа возможных состояний, поэтому
проверка модели требует значительных вычислительных ресурсов. Приведенная в примере модель 
сети из четырех RIP-маршрутизаторов имеет более 109 состояний. Поскольку граф состояний в 
общем случае цикличен, необходимо хранить 
множество посещенных состояний, которое не 
помещается в ОЗУ одной машины, а использование внешней памяти приводит к увеличению времени проверки на 3–4 порядка. 

Для сокращения числа состояний, а также тре
буемого для их хранения объема ОЗУ применяется ряд оптимизаций: сокращение частных порядков (уменьшается размер графа состояний), битовое хэширование (уменьшается объем требуемой 
памяти за счет того, что сами состояния не хранятся и коллизии в хэш-таблице не отслеживаются) [2], сжатие состояний (уменьшается объем 
требуемой памяти, но незначительно и за счет существенного увеличения времени проверки). Однако все эти оптимизации либо дают небольшой, 
плохо масштабируемый прирост, либо приводят к 
потенциальным потерям состояний при обходе. 
Альтернативным подходом является параллельная 
генерация состояний с распределенным хранением по различным узлам вычислительной сети.

Параллельная генерация состояний.
Воз
можны два подхода к параллельной генерации состояний.

1. Распределенное хранилище состояний. Со
стояния генерирует только один узел, а для хранения используются все узлы. Каждое состояние 
имеет свой  однозначно вычисляемый номер узла, 
и для проверки принадлежности следующего состояния множеству посещенных делается синхронный удаленный вызов хранящего это состояние узла.

2. Распределенная генерация состояний. Каж
дый узел одновременно является и хранилищем, и 
генератором. Если новое состояние принадлежит 
другому узлу, оно высылается ему асинхронным 
удаленным вызовом. На рисунке 2 показан пример 
обхода графа при данном подходе. Цифры на нем
обозначают локальный порядок генерации (в пределах данного узла).

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

В данной статье рассматривается лишь гене
рация состояний, проблема нахождения таких 
циклов при распределенной генерации выходит за 

ее рамки и подробно рассмотрена в [3].

Распределение состояний между узлами. 

Функция распределения определяет для каждого
состояния соответствующий индекс узла, отвечающего за хранение данного состояния. 

Эта функция должна обладать следующими 

свойствами:

 зависеть только от самого состояния (его 

битового представления), поскольку одно и то же 
состояние может генерироваться различными узлами в результате различных переходов;

 распределять состояния между узлами дос
таточно равномерно, в противном случае часть 
памяти у некоторых узлов будет простаивать;

 обладать локальностью относительно пере
ходов между состояниями (по возможности новые 
состояния должны принадлежать тому же узлу, 
что и исходное).

Последнее условие имеет смысл лишь при

распределенной генерации состояний и позволяет 
уменьшить число асинхронных удаленных вызовов между узлами.

Наиболее простым подходом является исполь
зование хэш-функции от битового представления
состояния s в качестве индекса хранящего его узла. Это обеспечит первые два условия: если выбрана подходящая хэш-функция, распределение 
будет достаточно равномерным. Однако третье 
условие при этом не соблюдается, поскольку все 
новые состояния имеют равные шансы принадлежать любому узлу независимо от того, на каком из 
них они были сгенерированы.

Пусть число узлов – N, состояний – S, перехо
дов между ними – T. При равномерном распределении состояний между узлами вероятность того, 

Рис. 2. Пример работы распределенной 

генерации состояний

Программные продукты и системы
№ 4, 2010 г.

11

что следующее состояние будет принадлежать те
кущему узлу, равняется 1

N . Следовательно, веро
ятность того, что потребуется удаленный вызов, 

равна 
1
1
N

, а среднее число удаленных вызовов в 

течение всей генерации составит 
1
1
T
N









, что 

при больших значениях N стремится к T. 

Такое большое число удаленных вызовов не
гативно отражается на производительности, поэтому необходимо найти более удачную функцию 
распределения состояний, которая удовлетворяла 
бы условию локальности. Одна из возможных 
идей предложена в [4] – использовать хэш-код не 
от всего состояния s, а от некоторой его части s. 

Битовое представление состояния в общем 

случае – это набор значений переменных, описывающих состояние отдельных компонент моделируемой системы, и значения общих переменных, 
описывающих взаимодействие между ними.

Пусть P – число таких компонент (процессов в 

нотации Promela) в модели; k – среднее число 
компонент, чье состояние затрагивается переходом (состояние которых меняется при переходе). 
Для языка Promela 1k<2, поскольку взаимодействие между более чем двумя процессами (далее 
под процессом будет подразумеваться процесс в 
понимании Promela, то есть компонент моделируемой системы) нереализуемо, но для двух процессов есть возможность синхронной передачи 
сообщения, при которой оба меняют свое состояние. Последняя возможность используется редко, 
поэтому для большинства моделей k достаточно 
близко к 1.

Таким образом, битовое представление со
стояния естественным образом разделяется на 
(P+1) область (учитывая область глобальных переменных), P из которых меняются почти независимо друг от друга (при условии k1), и в качестве хэшируемого подсостояния s можно выбрать 
первые (или произвольные)  областей, хранящих 
локальные состояния (значения переменных) первых  процессов.

Если предположить, что каждый процесс pi

участвует примерно в равном количестве переходов, то для произвольного, ранее заданного процесса вероятность участия в данном переходе со
ставит k

P , а для  процессов при k1 либо не
большом  – kρ

P . При условии, что множество 

возможных локальных состояний процесса отображается на множество узлов равномерно, вероятность удаленного вызова при изменении локального состояния процесса (то есть при его участии в переходе) по аналогии с предыдущими рас
суждениями составит
1
1
N

. Таким образом, ко
личество удаленных вызовов во всей модели рав
няется 
1
1
kρ T
P
N









и с ростом N стремится к 

kρ T
P
. При количестве процессов P=10, k=1,1 и 

=2 число удаленных вызовов уменьшается примерно в 4 раза по сравнению с наивным подходом.

Выбор меньших значений  приводит к мень
шему числу удаленных вызовов, однако увеличивает неравномерность распределения, поэтому его 
значение следует выбирать из баланса между требуемой равномерностью распределения состояний 
и выигрышем во времени за счет уменьшения 
числа вызовов.

Пусть i-й процесс  имеет wi возможных зна
чений локального состояния (то есть число допустимых комбинаций значений его переменных составляет wi). Объединение локальных состояний 

процессов тогда имеет не более 

1

ρ

ρ
i

i=

W =
w

воз
можных значений (не все комбинации могут быть 
допустимыми). Значение  должно обеспечивать 
условие W>>N, иначе, особенно при WN, распределение будет неравномерным даже при удачном выборе хэш-функции, а при W<N
память 

некоторых узлов не будет использоваться вообще, 
так как число возможных значений хэш-функции 
будет меньше числа узлов.

Экспериментальная проверка. Создан про
тотип ПО для параллельной проверки состояний с 
распределенной 
генерацией, 
поддерживающий 

подмножество языка Promela для описания модели. Для задания проверяемых утверждений поддерживается подмножество LTL, допускающее 
формулы AGx и AFx, где x может содержать локальные переменные процессов (включая счетчик 
команд) и глобальные переменные. На практике 
данное подмножество LTL реализовано при помощи встроенной в Promela функции assert и поиска тупиковых состояний.

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

Исходными данными служат две модели: ал
горитм выбора лидера и обедающие философы с 
числом компонент P=6. Для проведения экспериментов использовался кластер из 20 узлов, имеющих 4 Гб ОЗУ и 4 ЦПУ Intel Xeon 5120 1.86 ГГц 
каждый.

Результаты 
экспериментов 
по 
сравнению 

предлагаемого распределения с =1 и =2 с наивным (Н) представлены в таблице. Приведены следующие величины:

Программные продукты и системы
№ 4, 2010 г.

12

 доля вызовов среди переходов – отношение 

числа удаленных вызовов (суммарно на всех узлах) к числу переходов T;

 неравномерность распределения – отноше
ние среднеквадратичного отклонения к среднему 
для последовательности m1, m2, …, mN, где mi –
число состояний, хранимых узлом i;

 время простоя при ожидании сообщений от 

других узлов (сетевые задержки);

 общее время работы.

Сравнение распределений



Доля вызовов среди 

переходов, %

Неравномерность распре
деления, %

Время 
простоя, 

сек.

Общее 

время работы, сек.

Алгоритм выбора лидера

1
16
66,3
29
43

2
35
12,8
65
84

Н
87
0,1
127
164

Обедающие философы

1
17
89,4
3
14

2
35
29,6
7
21

Н
88
0,1
50
74

Проблемные значения выделены жирным 

шрифтом. 

Из результатов можно сделать следующие вы
воды.

1. Выбор распределения между узлами важен, 

поскольку время простоя за счет удаленных вызовов составляет существенную часть от времени 
выполнения.

2. При наивном подходе к распределению со
стояний число удаленных вызовов близко к числу 
всех переходов, как и следует из расчетов.

3. Предлагаемый способ распределения со
стояний по первым  процессам позволяет в несколько раз по сравнению с наивным подходом 
уменьшить число удаленных вызовов и время выполнения.

4. Необходим подбор параметра  в соответ
ствии со свойствами проверямой модели (P, wi) 
для обеспечения требуемого уровня равномерности распределения состояний; в частности, значения =1 в приведенных экспериментах оказалось 
недостаточно, поскольку неравномерность до 
90 % означает, что большая часть памяти некоторых узлов не используется вообще.

В заключение отметим, что использование па
раллельной генерации состояний дискретных детерминированных моделей в ходе проверки их соответствия спецификациям делает возможной верификацию моделей размера, на несколько порядков большего, чем позволяют традиционные подходы с последовательной генерацией. Одним из 
наиболее важных факторов является функция распределения хранимых состояний между узлами, 
правильный выбор которой, как подтверждают 
эксперименты, позволяет в несколько раз ускорить верификацию.

Литература

1. Кларк Э.М., Грамберг О., Пелед Д. Верификация мо
делей программ. МЦНМО, 2002.

2. Gerard J. Holzman. An Analysis of Bitstate Hashing. In 

proc. 15th Int. Conf. on Protocol Specification, Testing, and 
Verification. Kluwer, 1998, pp. 301–314.

3. Jiri Barnat, Lubos Brim. Parallel Breadth-First Search 

LTL Model-Checking. 18th IEEE International Conf. on Automated Software Engineering (ASE'03). Springer, Berlin, 2003, 
pp. 106–115.

4. Flavio Lerda, Riccardo Sisto, Distributed-Memory Model 

Checking with SPIN, Lecture Notes In Computer Science // 
Springer, Berlin, 1999. Vol. 1680, pp. 22–39.

УДК 004.05

ИССЛЕДОВАНИЕ АРХИТЕКТУРНОЙ ЧУВСТВИТЕЛЬНОСТИ 

К СБОЯМ С ИСПОЛЬЗОВАНИЕМ 

МЕТОДА СТАТИСТИЧЕСКОГО ВНЕСЕНИЯ СБОЕВ

П.Н. Осипенко, к.т.н.; А.А. Антонов; С.А. Левадский

(НИИСИ РАН, Москва, osipenko@niisi.msk.ru, antonov@niisi.msk.ru, levadsky@niisi.msk.ru)

В статье описываются методика определения коэффициента архитектурной чувствительности к сбоям цифровых 

блоков и результаты ее применения на примере исследования блока автомата состояний контроллера мультиплексного канала информационного обмена, выполненного в соответствии с ГОСТ Р 52070-2003.

Ключевые слова: коэффициент архитектурной чувствительности к сбоям, эталонная трасса, микроархитек
турное состояние, «серый» результат.

С уменьшением проектных норм обостряется

проблема одиночных сбоев в современных интегральных схемах вследствие воздействия на них 
одиночных частиц (ТЗЧ, протонов, нейтронов) [1].

Чтобы разрабатывать эффективные методы защиты, необходимо понимать особенности поведения 
интегральных схем в присутствии одиночных сбоев. Одной из них является то, что одиночные сбои