Приветствую! На связи Антон Осетров, DFT-разработчик SoC в компании YADRO. В этой статье я хочу рассказать о вызовах в тестировании SoC, о том, как эти вызовы менялись со временем и как с этим связан переход от аппаратного интерфейса JTAG к IJTAG.

Введение

До начала 2000-х годов радиоэлектронные устройства проектировались из нескольких интегральных схем с разной специализацией. На печатной плате присутствовали микросхемы АЦП, DSP-процессор, RS-485-to-UART и другие компоненты. В такой ситуации тестирование с помощью стандарта JTAG (IEEE 1149.1) было исчерпывающим. О JTAG есть множество интересных статей, среди которых отмечу цикл «Разглядывая JTAG».

Интерфейс примечателен тем, что с помощью минимального набора из 4–5 портов мы можем эффективно проводить периферийное сканирование (Boundary Scan) и внутрисхемную отладку. Максимум информации о состоянии микросхемы при минимуме аппаратуры — по-прежнему важное свойство стандарта.

Выход на новые техпроцессы 90 и 65 нм позволил встраивать PHY, появилась аналоговая периферия для SoC. Параллельно стало возможным размещать десятки цифровых IP-ядер разной направленности — от процессорного до видеокодеков. Это позволяло делать более компактные и производительные устройства.

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

Так мы пришли к точке, когда в SoC уже появилось множество IP-ядер, сделанных разными разработчиками или поставленных разными поставщиками. А перед отделом испытаний появляется вопрос о тестировании внутренних IP-ядер, которые теперь стали менее контролируемы и наблюдаемы. К этому всему добавился «зоопарк» наименований портов и блоков, для которых приходилось вносить точечные изменения.

Получилось так, что проектировщики и топологи повторно использовали одни и те же IP-ядра, а тестировщикам приходилось генерировать разные тесты или менять дизайн для разных проектов. Это противоречие помог разрешить стандарт IEEE 1500 (Standard for Embedded Core Test).

IEEE 1500 и принцип «оболочки»

Давайте оценим, чем логически отличается печатная плата со множеством разных микросхем от SoC с IP-ядрами. С функциональной точки зрения мы так же подключаем tx и rx порты, шины адреса и данных, трассируем схему тактирования. С точки зрения тестирования видим, что к каждой микросхеме на печатной плате можно одинаково обращаться по стандарту JTAG и она, как функционально законченное изделие, имеет заранее известный набор паттернов, который можно переиспользовать из проекта в проект. Может быть, нам и использовать что-то похожее в SoC?

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

Рассмотрим основные компоненты оболочки:

• Интерфейсный порт (wrapper interface port) обеспечивает соединение между оболочкой и TAM (шиной доступа к тестированию) на уровне SoC. Этот интерфейс достаточно гибок, чтобы поддерживать разные требования к пропускной способности тестирования.

• Регистр команд (WIR, Wrapper Instruction Register) настраивает оболочку в тестовые режимы и инициирует все тестовые операции внутри обернутого ядра.

• Регистр границы (WBR, Wrapper Boundary Register) служит механизмом изоляции и содержит сканирующую цепочку для последовательного преобразования данных (сериализации и десериализации). Через WBR на выводы встроенного ядра можно подавать различные типы тестовых данных. Как и интерфейсный порт оболочки, WBR может быть спроектирован так, чтобы отвечать различным требованиям по пропускной способности тестирования.

• Регистр обхода (WBY, Wrapper BYpass register) обеспечивает короткий путь через обернутое ядро. WBY используют, когда данные, предназначенные для логики вне ядра, должны пройти через ядро за минимальное число тактов.

В целом регистры оболочки можно распределить на три категории:

• Регистр команд оболочки (WIR, Wrapper Instruction Register).

• Регистры данных оболочки (WDR, Wrapper Data Registers), которые включают WBR и WBY, а также любые другие пользовательские регистры уровня оболочки — обратите внимание, что WIR не относится к WDR.

• Регистры данных ядра (CDR, Core Data Registers), которые относятся к регистрам внутри ядра.

Рассмотрим структуру блоков на конкретном примере. Допустим, мы купили какое-то IP-ядро без оболочки (будем называть его CAT). Внутри него уже содержится сканирующие цепочки и MBIST. Каждый функциональный порт является либо регистрируемым, либо нерегистрируемым. Регистрируемый порт имеет функциональный регистр, непосредственно подключенный к выводу IP-ядра. Нерегистрируемый порт содержит комбинационную логику между регистрами и выводом. Эта информация может потребоваться при создании WBR.

Wrapper interface port

Начнем описание портов оболочки. Инстанцируем CAT в WRAPPER_CAT со следующими портами оболочки:

• WRCK (Wrapper Clock Terminal).

• WRSTN (Wrapper Reset Terminal).

• SelectWIR: при установке этого сигнала выбирается WIR, а при снятии — регистр данных.

• ShiftWR: установка этого сигнала задает основное условие для выполнения операции сдвига в регистрах оболочки.

• CaptureWR: управление операцией захвата (capture).

• UpdateWR: управление операцией обновления (update).

• WSI (Wrapper Serial Input).

• WSO (Wrapper Serial Output).

• Терминалы WPI (Wrapper Parallel Input) для входных тестовых данных с именем WPSI[3:0].

• Терминалы WPO (Wrapper Parallel Output) для выходных тестовых данных с именем WPSO[3:0].

• Терминалы WPO для MBIST с именами MBISTDONE, MBISTFAIL.

• Терминалы WPC (Wrapper Parallel Control) для сканирования и MBIST с именами WPSE, MBISTRUN, CLK, WRCK.

Wrapper Instruction Register

После определения портов необходимо определиться с командами для управления режимами во время тестирования. Необходимый минимум команд по стандарту представлен в таблице, команда для проверки MBIST является пользовательской. Две буквы перед названием команды означают, какие порты будут задействованы: последовательные (wrapper serial) или параллельные (wrapper parallel). 

Поскольку код для команд двухбитный, то сдвиговый регистр (Shift Register) в WIR также будет двухбитным. Он тактируется WRCK и управляется сигналом ShiftWR. Если ShiftWR=1, то данные из порта WSI последовательно задвигаются.

Далее полученная команда должна быть декодирована для установки значений необходимым регистрам управления — например, SCANMODE, MBISTMODE и SE. Также необходимо обеспечить контроль по смене значения данных сигналов. Для этого используется Update Register, управляемый UpdateWR.

В формировании схемы WIR участвуют также порты SelectWIR для включения логики WIR, WRSTN для асинхронного сброса и WPSE для формирования некоторых управляющих сигналов.

Wrapper Boundary Register

Для построения WBR нам нужны специальные ячейки, которые могут как перенаправлять данные как вокруг IP-ядра, так и быть, например, прозрачными в функциональном режиме. Ячейки очень похожи на Boundary Scan Cell — это схема из двух мультиплексоров и одного D-триггер. Управляя сигналами SE и Hold_enable, можно получить нужный режим работы.

Обратим внимание на регистрируемые и нерегистрируемые порты. Во время сдвига тестовых данных важно не занести данные в цепочку из комбинационной логики или обратно. Иначе говоря, и в Shift-режиме, и в IP-ядре для сдвига по цепи должны работать D-триггеры. 

Следовательно, создаются разные конструкции WBR Cell. Для нерегистрируемых портов (RESET или FUNCA на картинке) между мультиплексорами ставится триггер так, чтобы во время shift-режима данные с триггера к IP-ядру блокировал мультиплексор. Для регистрируемых портов триггер расположен после двух мультиплексоров.

Также мы должны учесть использование параллельных портов WPSI и WPSO, с помощью которых можно разрезать цепь на четыре фрагмента. Мультиплексор, переключающий между параллельным и последовательным портом (обозначен красным), управляется регистром wpp_enable из WIR. Чтобы разделить WPSI для WBR и SI и WPSO для WBR и SO, вводится дополнительный управляющий сигнал WIR, который на рисунке не представлен.

На порт CLK WBR Cell не ставится.

Wrapper Bypass register

Тут все легко и просто. Ставится D-триггер, который при выборе BYPASS-режима будет частью большой сдвиговой цепи на уровне чипа.

CTL

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

Предел стандартного JTAG внутри SoC

Казалось бы, бери и для каждого IP-ядра делай свою оболочку по IEEE 1500, подключай ее к общему JTAG-порту микросхемы, и все будет работать. Но здесь нас поджидают четыре серьезные проблемы, связанные с увеличением количества IP-ядер.

Длина сканирующей цепочки. Если соединить все WBR и внутренние сканирующие цепочки всех ядер последовательно в одну гигантскую цепь, время тестирования вырастает пропорционально суммарному количеству триггеров. Для современной SoC с миллиардами транзисторов это часы, а не секунды.

Разнородность интерфейсов. Одни ядра имеют параллельные порты для скоростного доступа (WPI/WPO), другие — только последовательные порты. JTAG изначально последовательный, и чтобы эффективно использовать параллельные TAM, ему нужна более гибкая арбитрация.

Независимость тестов. Часто нужно запустить тест только на одном конкретном ядре, не выключая и не перезагружая остальные. В классическом JTAG с одной цепочкой это невозможно — все ядра включены последовательно.

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

И вот тут на помощь приходит IJTAG — стандарт IEEE 1687.

IJTAG и маршрутизация

IJTAG не отменяет JTAG и не заменяет IEEE 1500. Он надстраивается над ними, предлагая новый подход к построению сканирующей инфраструктуры. Вместо того чтобы соединять все WBR и внутренние сканирующие цепи ядер в одну длинную последовательную цепочку, IJTAG организует их в сеть, состоящую из управляемых сегментов.

Ключевая идея стандарта в том, что активная сканирующая цепь не фиксирована. Она собирается динамически в зависимости от того, какой IP-блок мы хотим протестировать в данный момент. Управление этой сборкой осуществляется через специальные элементы — SIB (Segment Insertion Bits).

SIB-блоки

По сути, SIB — это однобитный программируемый переключатель, который может либо включить свой сегмент сканирующей цепи в общий путь, либо исключить его, замкнув путь через себя. Структура SIB включает:

• Сдвиговый триггер (Shift) — принимает данные из сканирующей цепи.

• Триггер обновления (Update) — фиксирует состояние SIB (активен/неактивен).

• Мультиплексор (ScanMux) — выбирает, какой путь активен: через сегмент или в обход.

Управление состоянием SIB осуществляется через стандартные сигналы TAP-контроллера:

• Бит загружается в сдвиговый триггер через последовательный интерфейс (аналогично загрузке команд).

• По сигналу Update состояние фиксируется в обновляемом триггере.

• Мультиплексор переключает путь в зависимости от зафиксированного значения.

Здесь раскрывается главная особенность: мы управляем не только TDR (Test Data Register, все регистры wrapper), но и другими SIB.

Иерархия SIB

Эта конструкция дает возможность создавать иерархические деревья, где один SIB верхнего уровня может выключить разом блоки нижнего уровня. То есть нам не нужно ходить по всем IP-ядрам, чтобы переключить их в режим BYPASS. Достаточно одним битом, поданным через TDI, настроить сеть, которая будет включена в тестирование.

На картинке мы видим, что каждый SIB управляет только своим сегментом или TDR. Следовательно, мы можем в любой момент убрать часть сети, и система этого не заметит. Или мы можем менять местами блоки, как нам удобно — это повлияет только на описания нахождения SIB, но не на саму логику тестирования.

ICL и PDL

Как и в случае с IEEE 1500, где CTL описывает оболочку и тестовые последовательности, в стандарте IJTAG существуют свои языки для описания сети и процедур доступа.

ICL (Instrument Connectivity Language) описывает топологию IJTAG-сети: какие SIB-элементы присутствуют, как они соединены между собой, какие инструменты (TDR) к каким SIB подключены. По сути, это карта всей тестовой инфраструктуры на кристалле.

PDL (Procedural Description Language) описывает процедуры работы с инструментами: какие биты нужно загрузить в SIB, чтобы открыть доступ к конкретному TDR, какие данные сдвинуть, как считать результат. PDL позволяет описывать тестовые операции на уровне интерфейса инструмента, не углубляясь в физическую маршрутизацию.

Вместе ICL и PDL обеспечивают автоматизацию работы с IJTAG: инструменты САПР могут по ICL построить сеть, а по PDL — сгенерировать последовательности для тестирования, что позволяет масштабировать процесс и переносить его между проектами.

Заключение

После большого количества IP-ядер в SoC для испытателей появилась новая проблема. Из-за физических ограничений закона Мура чипы стали собирать по принципу «системы в упаковке» (SiP), объединяя несколько кристаллов в один стек на общей подложке. Что, в свою очередь, породило ситуацию, подобную переходу к IEEE 1500. Появился новый стандарт P1838, который описывает порты и архитектуру оболочек для 2.5D- и 3D-сборок.

В этой статье я хотел в целом пробежаться по истории проблем тестирования чипов и их решений, осветить общие моменты стандартов. Далее планирую углубиться в одну из тем и поэтому буду рад увидеть ваши предложения в комментариях. Можно, например, рассмотреть, как использовать OpenOCD для тестирования микросхем на плате или как OpenLane реализует стандарты для DFT-вставки.

Если вам интересен Design for Testing в SoC, возможно, вас заинтересуют и наши вакансии:

• RTL-дизайнер (SoC)

• Старший инженер по системной верификации аппаратуры

• Руководитель направления системной верификации аппаратуры