FPGA и ПЛИС в JTAG-тестировании

Конфигурирование FPGA и ПЛИС меняет не только физическую структуру КВВ отдельных банков. В файлах BSDL [1] подобных компонент помечено, что такие файлы должны быть существенно изменены, чтобы соответствовать новой структуре JTAG-ячеек всех КВВ конфигурированной ИС, и как именно их следует изменить. Следует обратить внимание на значение параметра USERCODE в декларации USERCODE_REGISTER и модифицировать его при необходимости. Все создаваемые кодом внутренние регистры FPGA должны быть соответственно описаны в атрибуте REGISTER_ ACCESS. Для предотвращения потери кода конфигурации при JTAGтестировании необходимо во всех тестовых векторах удерживать «лог. 1» в цепи, подключенной к контакту PROG_B.

Требуемые изменения в файлах BSDL должны охватывать также описание регистра РГС [2], объявляя логические значения в ячейках управления JTAG (параметр disval), переводящих связанные с ними выходные контакты в состояние с высоким импедансом, в соответствии с кодом конфигурации. Необходимо также обозначить как Z состояние с высоким импедансом тех выходных ячеек, которые действительно будут переведены в это состояние в результате конфигурирования ИС (значение по умолчанию — Х). Дополнительное требование, содержащееся в файле BSDL и связанное с вмешательством в текст этого файла, но не относящееся к конфигурированию ИС, заключается в схемном подключении контакта HSWAP_EN к уровню «лог. 1». Если же, исходя из схемотехнических соображений, этот контакт подключен к уровню «лог. 0», то все значения PULL0 (параметр disrslt), задаваемые по умолчанию, следует заменить на PULL1. И, наконец, чтобы избежать несоответствия имен файлов BSDL, в тексте видоизмененного файла следует переименовать заголовок entity. Очевидно, что переделка файлов BSDL выполняется преимущественно вручную (хотя и не всегда) и может сопровождаться множеством ошибок.

Разработка JTAG-тестов межэлементных связей для схем, содержащих конфигурированные FPGA и ПЛИС, в значительной степени определяет саму стратегию тестирования ПП. Дело в том, что фирмы-производители группируют КВВ большинства таких ИС в специализированные банки, так что уровни сигналов на КВВ отдельных банков и поддерживаемая ими полупроводниковая технология могут заметно отличаться как для одного и того же банка до и после конфигурирования ИС, так и между различными банками. На рисунке, к примеру, приведена структура конфигурированной ИС FPGA, содержащей четыре банка, два из которых (банки 2 и 4) предназначены для работы на уровне сигналов 3,3 В в технологии LVCMOS, банк 1 — также на уровне сигналов 3,3 В, но в технологии LVTTL, а банк 3 — на уровне сигналов 1,5 В в технологии LVCMOS.

До конфигурирования, то есть непосредственно после монтажа ИС на поверхность ПП, КВВ такой ИС поддерживают уровни сигналов, определяемые по умолчанию как 3,3 В в технологии LVTTL или определяемые выходным опорным напряжением VCCO каждого банка. Разработчик схемы ПП подключает к тем или иным КВВ цепи, предназначенные для работы ИС после ее конфигурирования, например работающие в технологии HSTL (High-Speed Transceiver Logic) на уровне сигналов 1,5 В, как показано на рисунке для банков 2 и 3. При JTAG-тестировании межэлементных связей КВВ банка 3 не возникает никаких проблем ни до, ни после конфигурирования этой ИС FPGA, а вот для КВВ банка 2 есть существенное отличие в этих двух режимах. Понятно, что КВВ банка 2 до конфигурирования FPGA в тесте межэлементных связей будут работать на уровне сигналов, определяемом напряжением VCCO, то есть 3,3 В в нашем примере, что может повредить их нагрузку, спроектированную для уровня сигналов 1,5 В.

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

Интересной особенностью некоторых семейств современных FPGA является возможность конфигурирования их КВВ как контактов дифференциальных пар, подключаемых к цепям LVDS (Low-Voltage Differential Signaling). Тестирование таких цепей в цифровом протоколе JTAG создает определенные сложности, однако принципиально возможно, если дифференциальные цепи не содержат емкостных развязок, представляющих собой обрывы для низкочастотных тестовых JTAG-сигналов [3]. При разработке JTAG-теста связей FPGA, подключенной к таким цепям, следует решить, тестировать ли их до конфигурирования FPGA как обычные цепи или после конфигурирования как дифференциальные, что, разумеется, определяется их схемными связями. Для обеспечения JTAG-тестирования подключенных к FPGA цепей SerDes, содержащих гальванические развязки, широко применяемые в современной схемотехнике для блокирования связей по постоянному току между контактами, выполненными в различных технологиях, и для согласования сигналов между передатчиками и приемниками, некоторые семейства FPGA (например Virtex 5) снабжаются поддержкой JTAG-стандарта IEEE-1149.6. Поддерживает ли планируемая к применению в схеме ИС этот стандарт, можно определить по наличию в файле BSDL этой ИС фрагмента use STD_1149_6_2003.all. Применение в схеме FPGA, имеющей такую встроенную JTAGподдержку, позволяет выполнять JTAG-тесты цепей SerDes с гальваническими развязками без предварительного конфигурирования.

Другой пример исходного файла BSDL можно найти для ИС семейства Stratix III фирмы Altera. В исходном, не конфигурированном состоянии все КВВ этих ИС являются тристабильными, каждый из них снабжен тремя JTAG-ячейками (входная, выходная, управляющая), так что уровень тестопригодности этих КВВ весьма высок. В файлах BSDL этих ИС отмечено, однако, что после конфигурации все КВВ, конфигурируемые как контакты дифференциальных пар (LVDSp, LVDSn, LVDSCLKp, LVDSCLKn), становятся целиком нетестируемыми, то есть их описание в файле BSDL должно быть изменено на «внутренний» (internal). Тестопригодность всех этих КВВ, таким образом, падает до нуля, что диктует необходимость их тестирования до конфигурации. Можно привести примеры FPGA и ПЛИС, КВВ которых, тристабильные до конфигурации, становятся только входными после нее, что также может быть критичным для достижения желаемого уровня покрытия неисправностей при тестировании.

В заключение, в качестве ответа на задаваемые читателями вопросы, несколько слов о применении технологии JTAG для тестирования кабелей. Иногда приходится слышать, что, мол, мы высокими технологиями не занимаемся, у нас даже не электроника, а электротехника, зачем нам JTAG? Тем не менее, применение этой технологии при производстве и тестировании даже сравнительно простых электротехнических изделий оказывается удобным, выгодным, а зачастую и просто незаменимым. Что может быть проще, скажем, кабеля или жгута проводов? Но если эти кабели предназначены для ответственных применений, они многожильные и достаточно длинные, таких кабелей много и они подключаются к кросс-плате, то автоматизированное тестирование качества монтажа кабелей может оказаться совсем непростым делом. Задача усложняется еще больше, если разъемы этих кабелей уникальные, дорогостоящие или очень миниатюрные, так что количество их подключений при тестировании должно быть минимальным, а лучше — только одноразовым. Простой прозвонкой здесь не обойдешься…

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

Между тем решение может находиться в области средств тестирования JTAG, совсем не связанных с функциональными тестами. Сердцевиной такого стенда обычно является несложная ПП, разрабатываемая самостоятельно или приобретаемая у тестовых фирм (например, модуль наружного тестирования JEMIO [5]), которая содержит одну или несколько ИС JTAG, назначение которых — выдача JTAG-тестов на отдельные цепи кабелей и фиксация результатов тестирования в протоколе JTAG. КBB такой платы подключаются к разъемам, находящимся с обеих сторон тестируемого кабеля. Если кабели не слишком длинные (1–3 м), так что внутреннее сопротивление их проводов пренебрежимо мало, то никаких проблем в организации для них JTAG-теста не возникает. Время выполнения такого JTAG-теста составляет считанные секунды, а достигаемая полнота покрытия дефектов типа обрывов и коротких замыканий в цепях кабеля [6] может быть 100%-ной. Правильно построенный JTAG-тест выдает имя неисправной цепи и имя контакта, что предельно упрощает и значительно удешевляет процесс диагностики неисправностей в кабелях.

При большом числе цепей в тестируемых кабелях приходится принимать во внимание дополнительный фактор, известный как ground bounce, то есть резкие колебания потребления тока при одновременных переключениях логического уровня сигналов на большом количестве КВВ управляющих ИС JTAG. Если это критично для ПП, управляющих тестом, то следует выбирать такие системы генерации JTAG-тестов (например, onTAP [7]), которые поддерживают управление этим фактором при генерации тестов межэлементных связей в функции числа одновременно переключаемых цепей. Стенды тестирования кабелей в технологии JTAG просто и естественно встраиваются во все популярные системы функционального тестирования на базе программных пакетов LabVIEW, LabWindows/CVI, TestStand, HP-VEE или же совмещаются с пользовательскими стендами функциональных тестов, программируемыми на языках С++, С#, Visual Basic и им подобных.