Вот тут задумался, а каким средством можно через jtag протестировать чип, т.е. что все логические элементы в нем живы и прекрасно себя чувствуют...

А как Вы себе представляете алгоритм подобного тестирования?

На семинаре по xilinx мужик из европейского центра поддержки, сказал что дороже всего им обходится тестирование девайсов, еще на этапе изготовления подложки, думаю, если бы был реальный способ оттестировать плис в готовом виде, они бы так и делали.

makc>>А как Вы себе представляете алгоритм подобного тестирования?

Не знаю как все остальные, но Xilinx точно поддерживает Boundary Scan.
В этом режиме все pin-ы обьеденяються как сдвиговый регистр и можно на любой i-o выставить нужный сигнал либо считать значение i-o. Как реализовать динамику правда не знаю

Xilinx, например для этой цели предлагает продукт ChipScopePro. Тестируется правда не весь чип, а только то, что вошло в проект, причем отладка происходит на реальной скорости проекта. Сам еще с ним не работал, только документацию прочитал, но решил, что обязательно буду применять.

"Вот тут задумался, а каким средством можно через jtag протестировать чип, т.е. что все логические элементы в нем живы и прекрасно себя чувствуют..."

Если как этап входного контроля - то скорее всего никак. Но можно заказать молебен в церкви. Должно помочь.

Это немного не то, т.к. ChipScope - это возможность встраивания логического анализатора внутрь отлаживамого на ПЛИС проекта. Т.е. изначально предполагается, что кристалл ПЛИС исправен и необходима отладка разработанной пользователем прошивки ПЛИС.

Конечно, можно считать, что таким образом можно загрузить эталонный проект и далее с помощью ChipScope смотреть на его работу, но нужно помнить, что и сами блоки реализуются с помощью ЛЭ ПЛИС, т.е. это начинает больше походить на самотестирование в выдачей результата пользователю. К тому же лично мне кажется, что достоверность такой проверки практически равна нулю, т.к. число используемых в отдельном проекте способов связи элементов ПЛИС и вариантов их конфигурации ничтожно мало по сравнению с максимально возможным их числом.



Да, это мне известно. И на основе этого можно предложить создать проекты, которые бы пропускали сигналы от входных пинов по заданным трассам внутри кристалла и выдавали бы их наружу через выходные пины. Однако мне страшно представить тот объем работы, который нужно проделать чтобы получить такой набор тестовых проектов, реализующий полный тест кристалла. К тому же время тестирования одного кристалла может оказаться просто огромным, т.к. может потребоваться перезагрузка не одного десятка тестов.

Пока писал, в голову пришла мысль, что возможно отталкиваясь от статистики отказов построить некоторые качественные тесты, которые бы со значительной долей вероятности показывали исправен-ли кристалл или нет. Но вот беда - я не видел такой статистики. Уверен, что она есть у того же Xilinx'a, но они ее по понятным причинам не раскрывают.

Можно и отдельные вентили в FPGA тестировать при желании - объединять LUT в XOR-конусы и гонять псевдослучайные тесты, чтобы протестировать 99.9...% мультиплексоров. Конфигурационная память проверяется обычным обратным чтением прописанной прошивки. Блочная память тестируется стандартными маршевыми тестами.

Только вот смысл затеи не совсем понятен. Обнаружить физически неисправный элемент? Сильно сомневаюсь что удастся, так как производители чипов тратят на это огромные деньги и лучше чем у них протестировать чип точно не удастся. А если хотите проверить правильность работы своей прошивки, так это вам надо в сторону функциональной верификации смотреть - там свои методы и языки.