Всем привет! Есть вопрос.
Изучая различные стандарты DFT, пришел к мнению, что IEEE 1500 (Wrapping core + scan logic) не замещает, а лишь дополняет давно известные IEEE 1149.1+1149.6 (JTAG Tap + boundary scan). Причем, получается что надо делать и то и другое, поскольку с одной стороны JTAG - стандарт де факто, и при отладке печатных плат просто необходим, а с другой стороны Internal Scan так же необходим при отбраковке чипов на заводе. Но если делать и то, и другое, получается что вокруг Core создается двойной Wrapper из управляющей логики, что не есть хорошо при вытягивании perfomance, т.к. на путь сигналов In2Reg и Reg2Out накладываются дополнительные задержки.
Отсюда возникает вопрос - можно ли как то совместить тестовую логику вокруг портов IO для обоих стандартов (1500 и 1149.6)? Т.е. я хочу один wrapper сразу и для internal scan и для boundary scan.

Вручную - уверен что можно, достаточно, к прмеру, модифицировать цепочку BSR управляющими сигналами Scan. Вопрос именно в стандартном маршруте Cadence/Synopsys, т.е. чтобы на выходе обязательно была автоматизированная проверка соответствия стандартам.

возможно не понял вопрос, но для ускорения тестирования внутренней логики используется много цепочек, а не одна TDI->...->TDO.
TAP машинка JTAG-а настолько микроскопическая, что совмещать ее с чем-то еще смысла не имеет
то есть мы делаем (ну и не только мы) - одна нога, которая переключает SCAN/WORK в режиме SCAN все IO включаются в цепочки, в режиме WORK IO пользовательские и JTAG в том числе. пользователь про режим SCAN ничего не знает - эта нога для него NC (если есть подтягивающий резистор в ячейке) ну или connect to GND/VCC

Спасибо за ответ!

А когда вы Scan встявляете, то используете shadow wrapper? Другими словами, Scan покрытие у вас охватывает вариации переключения IO, или вы при генерации тестов на порты Х ставите?

И второй вопрос. Я так понял, вы JTAG делаете отдельно, и scan к ТАР контроллеру не цепляете (поскольку вы сказали о отдельных портах scan). Тогда, как у вас построен маршрут - сначала вставка Scan, а затем jtag, или наоборот? Или же вы все вместе констрейните и вставляете одновременно?

Предположу, что под " Scan покрытием" имеются ввиду внутренние сканцепочки цифры. Давайте назовём тесты сгенерённые для этих внутренних цепочек ATPG

1) Тестировать ну очень медленные входы-выходы во время прогона ATPG не очень хорошая мысль.
В таком случае скорость ATPG будет определятся скоростью падов микросхемы.
2) Х на портах плохо - тест кавередж ATPG будет низким. Во время ATPG должна быть возможность тулзе самой задавать нужные значения.

Да, все верно - речь о ATPG.
Собственно, к этому я разговор и вел - что если позволить тулу генерить тест с учетом переключения входов, покрытие получается больше. Но чтобы реально появилась возможность дергать входы, нужно вставлять shadow wrapper (ieee 1500), который суть - boundary scan по границе блока. При этом, один boundary scan у нас уже и так есть - житаговский. Получается, на каждом порте висит две цепочки boundary scan - одна jtag, вторая atpg. Если порты критичны к задержкам, может нехватить частоты. Из всего это и возникает вопрос, который я (вероятно, криво) задавал в первом посте, перефразирую:
Можно ли как то как обьединить boundary scan JTAG с boundary scan ATPG, чтобы общее latency всей этой логики, накладываемой на путь входных (io) сигналов, было не таким большим?

Как вариант, заведите выходы на входы в ATPG режиме и всё продёргается само

Не понял .. для генерации тестов наверно так и можно сделать. Но что потом делать с полученными векторами, когда в руках спеченный кристалл и его надо проверить на тестере? Там дергать ногами может только цепочка граничного сканирования (shadow wrapper), если она есть.

А совместить тест ATPG с переключением значений портов через JTAG будет слишком сложной задачей, имхо. Я думал, может есть какое то схематехническое решение, желательно в рамках стандартных маршрутов проектирования.

В режиме ATPG, ваша схема должна иметь подключенные выходы на входы.
В режиме нормальной функции, входы\выходы идут к падам микросхемы.
Мультиплексор соединяющий входы\выходы - это часть дизайна а не обманка для ATPG генератора (У вас кстати TetraMAX or EncounterTest?)

Я использую Tetramax.
Очень интересная информация, спасибо! А не подскажете, где об этом почитать можно? Я в документации на САПР этот мультиплексор либо пропустил, либо это все какая то эдвансед методика, которую очень бы хотелось изучить в деталях

Это жизненный опыт
trick - как говорят буржуи....

мы не используем тулзы ATPG (Tetramax и т.п.) из-за соображений легальности - то есть экономим на лицензии (и может я снова не понимаю проблемы)
только вставляем сканцепочки и т.п. - чтобы была точнее оценка после синтеза, скан-енаблед триггера чуть медленне, чуть больше и т.п.
а собственно вектора (и "трассировку цепочек") и всяческие дополнительные хитрости - например, IO мультиплексор получается более чем двухвходовый, так как есть специфические, не скан тесты, типа тесты PLL - делает субподрядчик/backend

так как JTAG у нас кроме BS нагружен USER цепочками (отладка процессоров, ну типа J-LINK, всяческие специфические USER задачи), то мы не берем готовое JTAG ядро а используем синтезируемый код - я предполагаю, что JTAG IP имеют возможность подключения USER цепочек и все-такое, но нам нужно сохранять программную совместимость, то есть проще иметь свой
ну и он соответственно рассматривается DFT как обычная логика (то есть через него проходят/ит скан цепочки/а)

также, это уже ноу-хау бэкенда (некое их секретное IP), используются некие "BIST" машинки, также мы вычленяем узлы, на которых можем прогнать дополнительно тесты типа тестов покрытия в симуляторе - смысл этого в том, что scan equipment, работает на частоте ограниченной IO (например 20МГц), а внутренняя логика может работать на частоте 600МГц (то есть можно прогнать 30х проверок за то же время) - то есть для экономии времени этого скан-эквипмента IO полностью отвязаны от внутренней логики
еще есть одно свойство - что если прогонять сканцепочки на частоте 30МГц, то могут быть пропущены ошибки (дефекты кремния), проявляющиеся на 600 - для этого вычленяется два импульса боевой частоты и защелкивание в скан цепочку выполняется по ним (то есть даже для обычного прогона скан патернов используются некие расширения)

ну то есть такой длинный рассказ к тому, что DFT это не только скан цепочки, а еще дополнительно всякой, завязанной на технологию, фигни - ATPG это только один из инструментов тестирования

ATPG бывают таких видов : Stack-At, IDDQ, At-Speed (то что вы упомянули), Low Voltage
Все используют встроенные скан цепочки и другие вещи (OPCG итп). Таким образом только DFT (по сути вставление скан цепочки) во время бекэнда недостаточно для реализации даже самих ATPG.
Соответственно генерятся по-разному тем-же EncounterTest.
Эти типы тестов способны выявлять разные типы дефектов.

А с тем что DFT это не только скан цепочки, а еще дополнительно всякой, завязанной на технологию, фигни (типа BIST) - 100% согласен.
Создание качественных тестовых структур - ой какая хитро-навороченная задача.... JTAG - это даже не верхушка айсберга, а так... навершие...

Спасибо, интересно.
Из буржуйских ядер лучшее что ковырял, это ARM, и у них кстати тоже был свой TAP контроллер. Часто еще делают вручную clock_gate, чтобы не отдавать все на откуп синтезатору. Но я сейчас пытаюсь разобраться с автоматическими work-flow. К примеру, работа scan-цепочек на частоте процессора (то, о чем написал yes, полагаю) называется в документации On-Chip Clocking (OCC) и контроллер для этой штуки может вставляться автоматически, хотя я это делать еще не пробовал.

А такой вопрос (всем участвующим в обсуждении), MBISTы вы тоже собственного написания используете, или генерите каким то САПРом?
Я читал документацию только на тул Mentora, но там какой то мрак, чуть ли не рандомные паттерны генерятся во время работы MBIST. Мне кажется, такой контроллер будет занимать в три раза больше места чем память, которую он тестирует.

Про "работа scan-цепочек на частоте процессора"
скан цепочки работают на частоте, на которую их дизайнил бекенд дизайнер

yes имел ввиду скорее АtSpeed & More than AtSpeed ATPG test.

ну про Memory BIST могу только сказать, что память - это аналоговая схема и далеко не у всех она одинакова... так-что врятли тут что-то можно сделать автоматом.
мы вот сами написали, под конкретную память, зная её схемотехнику....