[Shivers 0]

Всем привет! Есть вопрос.

Изучая различные стандарты 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 5]

возможно не понял вопрос, но для ускорения тестирования внутренней логики используется много цепочек, а не одна TDI->...->TDO.

TAP машинка JTAG-а настолько микроскопическая, что совмещать ее с чем-то еще смысла не имеет

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

[Shivers 0]

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

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

[topor_topor 0]

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

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

 

1) Тестировать ну очень медленные входы-выходы во время прогона ATPG не очень хорошая мысль.

В таком случае скорость ATPG будет определятся скоростью падов микросхемы.

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

 

 

[Shivers 0]

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

[topor_topor 0]

Да, все верно - речь о ATPG.

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

Можно ли как то как обьединить boundary scan JTAG с boundary scan ATPG, чтобы общее latency всей этой логики, накладываемой на путь входных (io) сигналов, было не таким большим?

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

 

[Shivers 0]

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

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

 

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

[topor_topor 0]

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

 

В режиме ATPG, ваша схема должна иметь подключенные выходы на входы.

В режиме нормальной функции, входы\выходы идут к падам микросхемы.

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

 

module top;

output out1, out2;
input in1, in2;

wire ATPG_test; // ATPG_test=1 - генерация и выполнение ATPG
wire  w_in1, w_in2; 

always @ (*)
begin
   if ( ATPG_test)
   begin
      w_in1 =out1;
      w_in2 =out2;
   end
   else
   begin
      w_in1 = in1;
      w_in2 = in2;
   end
end

digital_top u_dig_top
(
   .in1(w_in1),  
   .in2(w_in2),

   .out1(out1),
   .out2(out2)
);

[Shivers 0]

Я использую Tetramax.

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

[topor_topor 0]

Я использую Tetramax.

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

Это жизненный опыт :)

trick - как говорят буржуи....

 

 

[yes 5]

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

 

[topor_topor 0]

.... проявляющиеся на 600 - для этого вычленяется два импульса боевой частоты и защелкивание в скан цепочку выполняется по ним (то есть даже для обычного прогона скан патернов используются некие расширения)

 

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

 

ATPG бывают таких видов : Stack-At, IDDQ, At-Speed (то что вы упомянули), Low Voltage

Все используют встроенные скан цепочки и другие вещи (OPCG итп). Таким образом только DFT (по сути вставление скан цепочки) во время бекэнда недостаточно для реализации даже самих ATPG.

Соответственно генерятся по-разному тем-же EncounterTest.

Эти типы тестов способны выявлять разные типы дефектов.

 

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

Создание качественных тестовых структур - ой какая хитро-навороченная задача.... JTAG - это даже не верхушка айсберга, а так... навершие...

[Shivers 0]

Спасибо, интересно.

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

 

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

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

[topor_topor 0]

Спасибо, интересно.

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

мы вот сами написали, под конкретную память, зная её схемотехнику....