Роль пользовательского контроля при автоматическом создании тестов периферийного сканирования

Что такое тестовый вектор? Как мы помним, суть метода JTAG-тестирования заключается в последовательном сдвиге последовательностей цифровых данных (нулей и единиц) в регистры периферийного сканирования микросхем платы, поддерживающих стандарт IEEE 1149.1. Эти последовательности и называются тестовыми векторами (или паттернами), и вдвигаются и выдвигаются они по всем известному интерфейсу JTAG. При автоматической генерации векторов, комбинации нулей и единиц в каждом из них различаются для точной диагностики и определяются анализом межсоединений платы и ожидаемым спектром дефектов. Так как регистр периферийного сканирования среднестатистической ИС, поддерживающей стандарт IEEE 1149.1, имеет как драйверы, так и сенсоры, то в пределах каждого вектора данные как выставляются на внешние цепи, так и считываются с них во время JTAG-команды EXTEST. Затем вектор, дополненный считанными значениями, выдвигается по контакту TDO в контроллер периферийного сканирования и поступает в анализирующее ПО. Полноценное тестовое приложение поочередно вдвигает определенное количество тестовых векторов, выполняет требуемые JTAG-команды, и выдвигает их. А тестовые приложения, в свою очередь, различаются задачами: каждое из них выполняет различные задачи по тестированию межкомпонентных связей, ОЗУ, ПЗУ и т. д.
Что такое вектор, теперь понятно. Вопрос только в том, как эти векторы создаются: автоматически или вручную. С ручным созданием все довольно ясно: примером может послужить JTAG ActiveTest, утилита, которая по умолчанию включается в любую комплектацию пакета JTAG ProVision. Процесс создания тестовых векторов заключается в выборе выводов или цепей, имеющих связь с компонентами, поддерживающими периферийное сканирование и ручном вводе значений на этих цепях. Введенные значения, собственно, и образуют тестовые векторы. Окно для создания векторов показано на рисунке 1.
После конвертации нетлиста платы в проект JTAG ProVision, все компоненты и цепи представлены в виде объектов (на правой части рисунка). В левой части — окно создания векторов, куда мышью можно перетаскивать как целые цепи, так и отдельные выводы компонентов. Затем цепи объединяются в группы (на рисунке названия групп: «LEDs», «SWITCHES» и «Different»). В данном примере мы создали 10 векторов для трех групп цепей. При этом группа «LEDs» использует драйверы, то есть выставляет вписанные нами данные на цепи, состоящие в группе. Какой компонент с поддержкой периферийного сканирования выбрать для стимуляции (если на цепи их несколько) система выбирает автоматически, так как мы не используем конкретные пины, как в группе «Different». Группы «SWITCHES» и «Different» имеют атрибут «R» (Read) и используются для захвата значений с цепей. Таким образом, данные, которые мы видим в тестовых векторах под метками «SWITCHES» и «Different» — это считанные значения с платы. Вот так выглядит на сегодняшний день ручное создание тестовых векторов. Но как определить комбинации, для диагностирования всех возможных дефектов, которые могут возникнуть в каждой из цепей, а также всех перекрестных ошибок? Для этого нужна специальная математика.

Рис. 1. Окно для создания тестовых векторов вручную

При автоматической генерации у нас есть все тот же нетлист, который мы сконвертировали в общий проект. Но здесь мы уже не создаем никаких групп и не выбираем цепи. Система сама выбирает цепи, которые можно протестировать и генерирует какое-то количество тестовых векторов с различными комбинациями данных (естественно с определенными изменяемыми опциями, о которых — чуть позже). Увидеть сами векторы можно после выполнения тестового приложения: в результирующей таблице. На рисунке 2 показана такая таблица, в которой можно увидеть драйверы, сенсоры и их состояние во время теста. Красным цветом подсвечены данные, которые противоречат ожиданиям системы тестирования, то есть сигнализируют о дефекте. На основе этих данных автоматически создается диагностическое сообщение, которое в данном примере сигнализирует нам о том, что у D200 обрыв на 22-м выводе.

Рис. 2. Таблица, показывающая тестовые векторы после выполнения приложения

Тут сразу же возникает справедливый вопрос: неужели мы никак не можем повлиять на этот процесс? Конечно же, можем! Хотя, если мы хотим сами придумывать комбинации тестовых данных в векторах, то лучше использовать ActiveTest, а если нужно разом протестировать все межкомпонентные связи платы — лучше воспользоваться автоматической генерацией, которая хоть и ограничивает степень свободы, но все же предоставляет обширные возможности пользовательского контроля.
Начнем с того, что при создании теста межкомпонентных связей в JTAG ProVision мы видим окно с опциями теста, показанное на рисунке 3. В зависимости от этих опций будет различаться количество тестовых векторов, их длина и содержание. В левой части окна мы видим область Patterns (векторы) — здесь можно устанавливать степень покрытия потенциальных дефектов платы. Как нетрудно догадаться, чем более широкий спектр покрываемых дефектов будет установлен, тем больше получится тестовых векторов после генерации, так как придется перебрать гораздо больше комбинаций. Например, если не установить опцию «Stuck-at-zero detection», то в полученном наборе векторов будут отсутствовать те из них, которые при помощи определенных сочетаний тестовых данных детектируют замыкания выводов на землю. Количество векторов будет меньше, а спектр автоматически определяемых дефектов – ниже.

Рис. 3. Опции генерации тестовых векторов в JTAG ProVision

Теперь представим себе ситуацию, когда на одной из тестируемых цепей присутствуют выводы сразу нескольких компонентов, поддерживающих периферийное сканирование, как показано на рисунке 4. D1, D2 и D3 поддерживают стандарт периферийного сканирования 1149.1 и, следовательно, у них у всех есть тестовый доступ к цепи Net1. На рисунке показаны фрагменты регистров периферийного сканирования этих ИС с драйверами, сенсорами и контрольными ячейками. Мы хотим проверить целостность соединения всех трех микросхем. Самый простой вариант, который используют простейшие генераторы тестовых векторов — это установить уровень на цепи Net1 с драйвера микросхемы D1 и принять этот уровень на D2 и D3 при помощи сенсоров. Казалось бы, этого достаточно. Но в таком случае, у микросхемы D1 мы проверяем только драйвер, а у D2 и D3 — только сенсоры. Если есть сомнения в целостности внутренней структуры (а не только внешних паяных соединений) микросхем и возникает желание проверить все драйверы и сенсоры на данной цепи, можно использовать опции генерации «Bus drivers used:» «distributed», «all». В таком случае в разных тестовых векторах, которых теперь стало больше, будут использоваться все имеющиеся у цепи драйверы. Кроме того, расширенное (distributed) использование драйверов позволяет повысить вероятность обнаружения дефектов в случае слабых драйверов одной из микросхем — участниц теста.

Рис. 4. Несколько компонентов с поддержкой периферийного сканирования на одной шине

Еще один вопрос, который возникает к автоматической генерации, — какие цепи система выбирает для тестирования? Объясним этот момент на примере одной из самых интересных опций генерации в JTAG ProVision: «Allow possible driver conflicts» (см. рис. 3). По умолчанию, она всегда выключена. Как известно, JTAG ProVision оперирует не только цепями, полученными из нетлиста платы, но и моделями компонентов, которые, кроме функциональности, рассказывают системе также о том, является ли компонент активным или пассивным, и как можно его отключить, чтобы сделать неактивным (сигналы EN, CS и т.д.). Уточним, что речь идет о компонентах без поддержки стандарта периферийного сканирования IEEE 1149.1 (память, логика, резисторы и т.д.). Таким образом, если определить модели для 100% компонентов на плате, то система сама будет решать, какие компоненты опасны сточки зрения конфликтов драйверов, какие из них пассивны (например, резисторы, светодиоды, конденсаторы) и генерировать тестовые векторы, которые будут манипулировать максимальным количеством цепей, используя максимум драйверов компонентов с поддержкой периферийного сканирования. При этом если какому-то компоненту из нетлиста не установлена в соответствие модель (даже самая простая, говорящая о том, что компонент пассивен), то ProVision будет считать, что это потенциально опасный компонент и будет держать драйверы ИС с периферийным сканированием, связанные с данным «опасным» компонентом, в третьем состоянии, чтобы ничего не повредить. Однако часто при создании и отладке тестов возникает потребность сгенерировать тестовые паттерны еще до определения моделей. Тогда по умолчанию тест, скорее всего, сгенерируется только для неподключенных выводов JTAG-компонента, так как остальные выводы подключены к «черным ящикам» — компонентам с неопределенными моделями. Так можно получить вектор длиной не более 10 бит, ничего, практически, не тестирующий. Поэтому, если мы уверены, что вокруг JTAG-микросхем отсутствуют потенциально опасные активные компоненты, то можно применить «галочку» «Allow possible driver conflicts». Тогда тест будет сгенерирован для всех окружающих цепей JTAG-компонента.
Цепи, для которых тест по тем или иным причинам не сгенерировался, отображаются в окне Netlist Explorer, который можно открыть после генерации (см. рис. 5). В этом окне можно разрешить тест для отдельных цепей, а не для всего приложения. Это решение альтернативно опции «Allow possible driver conflicts», только более избирательно. То же самое можно сделать с отдельным компонентом, объявив его пассивным. И тогда для всех цепей, имеющих с ним связь, генерация будет считаться безопасной. На рисунке 5 не сгенерированы тестовые воздействия для цепей DATA[0…7] из-за того, что не определена модель микросхемы D301 и система считает ее потенциально опасной. Как видно, мы вручную устанавливаем для одной из цепей атрибут «Allow Test» (позволить тест). Однако делать это рекомендуется, только при полной уверенности безопасности теста (например, мы уверены, что компонент D301 отключен, возможно, каким-то внешним воздействием). Такой же эффект может быть достигнут если поставить на D301 атрибут «Passive». Если же определить для него модель, то ProVision найдет сигнал отключения этого устройства (в случае его наличия, как, например, у ОЗУ или ПЗУ).

Рис. 5. Контроль цепей и компонентов после генерации

Такого рода контроль очень важен. Без него получить удовлетворительное тестовое покрытие очень трудно. При обучении новых пользователей систем JTAG Technologies я всегда обращаю внимание инженеров на то, что после генерации необходимо открыть Netlist Explorer (рис. 5) и проверить, много ли цепей имеют атрибут «Don’t Test». Тестовый инженер должен осознавать получаемое тестовое покрытие. Возможно, окажется, что он забыл определить модель для обыкновенных резисторов, тогда огромное количество цепей и выводов выпадут из тестирования. Случается, что инженер довольствуется тестами, сгенерированными автоматически, и не обращает внимание на то, сколько цепей не тестируется и на причины, по которым они пропускаются. Также программные среды для создания приложений периферийного сканирования обычно имеют средства расчета тестового покрытия: теоретически достижимого для данного изделия, и, полученного в результате уже созданных приложений. Этим инструментом также всегда нужно пользоваться, так как существует он не для информационных целей, как это иногда кажется, а для отладки тестовых приложений.
На рисунке 5 видны и другие возможности контроля, которые можно реализовать вручную. Например, любую цепь с доступом периферийного сканирования можно поставить в состояние с фиксированным значением («Drive 1» и «Drive 0»). Это означает, что во всех тестовых векторах (будь их 10 или 1000) на данной цепи установится только одно значение (0 или 1), тогда как на остальных, данные обычно меняются от вектора к вектору. Для чего это нужно? Предположим, у нас используется компонент с поддержкой периферийного сканирования, но для включения режима тестирования внешних цепей требуется подать на порт JTAG_EN этого компонента высокий уровень. Если эта информация указана в BSDL-файле на данную микросхему (COMPLIANCE PATTERNS), то JTAG ProVision, прочитав это, будет автоматически держать данный вывод в состоянии «1» с помощью какой-либо другой микросхемы с поддержкой сканирования (см. рис. 6). Однако в BSDL-файле строка COMPLIANCE PATTERNS может отсутствовать, а нам все равно нужно держать JTAG_EN в единице, поэтому можно открыть Netlist Explorer и установить на этой цепи атрибут «Drive 1». Данный пример показывает, что при помощи контроля цепей мы не просто регулируем тестовое покрытие платы, а, вообще, делаем возможным периферийное сканирование для части платы.

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

Также во время тестирования может потребоваться отключить какой-либо сложный функциональный узел, который мешает проводить периферийное сканирование. Для этого тоже можно использовать вышеуказанную возможность. Предположим, что на тестируемой плате помимо компонентов с поддержкой IEEE 1149.1 содержится также СБИС, не имеющая данной замечательной возможности. Как было показано в [1], если обеспечить «пассивность» данного компонента, то при помощи окружающих ИС с поддержкой сканирования, имеющих с ним связь, можно протестировать его выводы на короткие замыкания между собой, с землей и питанием. Предположим, что для того, чтобы перевести выводы СБИС в третье состояние, необходимо подать на ее специальные порты некоторые статические сигналы, которые можно установить с ячеек периферийного сканирования других компонентов. Если это, к примеру, СБИС собственной разработки, то вряд ли ее модель окажется в библиотеке ProVision (хотя ее можно и создать самому). Если мы не хотим создавать модель, то в данном случае легче всего использовать функции «Drive1» и «Drive0». После этого можно указать, что данный компонент пассивен, и система добавит цепи нашей СБИС в тестовые векторы. Таким образом, простой манипуляцией с одиночной цепью можно управлять тестовым покрытием платы.
Приведенный на рисунке 6 пример относится к случаю, когда необходимый для ручного контроля сигнал может управляться при помощи периферийного сканирования. То есть он выведен на другой JTAG-компонент, или на другой вывод того же самого компонента. Однако встречается ситуация, когда сигнал включения режима периферийного сканирования выведен только на внешний разъем, или, возможно, сигнал отключения какого-нибудь мешающего контроллера не имеет связи с ячейками сканирования JTAG-компонентов платы. Именно поэтому современный контроллер периферийного сканирования помимо стандартных TAP-сигналов (TDI, TDO, TCK, TMS и TRST) имеет на интерфейсном разъеме много других сигналов: User0, User1, Ready, AW и т.д. (см. рис. 6). Часть этих сигналов призвана контролировать нужные цепи извне, когда к этим цепям нет доступа периферийного сканирования.

Рис. 7. Дополнительные выводы на JTAG-контроллере помимо стандартных TAP-сигналов

В заключение, пользователям средств JTAG-тестирования хотелось бы посоветовать уделять особое внимание тестовому покрытию: не просто доверяться автоматической генерации тестовых векторов (хотя средства для этого на сегодняшний день довольно интеллектуальны), а контролировать цепи, которые по тем или иным причинам не тестируются. Для этого есть множество средств и методов, описанных выше. Их нужно активно использовать и экспериментировать. В случаях, когда тест вообще не работает, можно использовать для поиска причин опции «бегущий 0» и «бегущая 1», а также такие утилиты, как ActiveTest и программу JTAG Live Buzz, позволяющие не оперировать сразу большими массивами данных, а проверить единичные цепи и выводы компонентов.