Вопрос по DFT Опции

[Shivers]

Всем привет! Есть вопрос.
Изучая различные стандарты 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, т.е. чтобы на выходе обязательно была автоматизированная проверка соответствия стандартам.

[yes]

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

[Shivers]

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

возможно не понял вопрос, но для ускорения тестирования внутренней логики используется много цепочек, а не одна 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, или наоборот? Или же вы все вместе констрейните и вставляете одновременно?

[yes]

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

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

мы не используем тулзы 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 это только один из инструментов тестирования