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

[Torpeda]

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

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

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

[Shivers]

Предположу, что под " 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) сигналов, было не таким большим?