Xilinx конечно же следит за своей продукцией. И некондицию наверно сдает в утилизацию. А дальше - уже от вашего дистрибьютера зависит.
Где покупает.
Надежные контрагенты - это забота вашего отдела закупки.
Работоспособность узла - забота разработчика этого узла. Ведь при его сдаче по ТУ там наверно токи потребления прописаны.
Вот и спросите у разработчика, почему такой разброс и несоответствия по ТУ.
А если хотите собой разработчика подменить, поставьте пакет разработки, и возьмите у разработчика его проект, и вот реакцию пакета на этот проект
изучайте. А тыкаться по плате, имея в наличии только файл прожига, не прочитав даже файла по пинам на это семейство от фирмы производителя - дело неблагодарное.

sazh Я очень извиняюсь за свою неосведомленность и то, что ранее не обратила внимания на Ваше "рапорт пакета по подключению каждого пина кристалла"...Но почему-то я не сталкивалась с такими рекомендациями. В datasheet есть общее описание, и, насколько я понимаю, у меня есть несколько видов выводов: питания, GND, глобальные(которые также могут использоваться как либо входы, либо выходы, но в моем проекте не используются) и непосредственно пины ввода-вывода(которые конфигурируются программно и то чем они будут входом или выходом тоже задается программно).
И еще я искренне за Вас рада, что Вы занимаетесь только узко своим занятием, выполняете свою работу и не вмешиваетесь в дела комплектации и других служб. У нас инженер на производстве должен быть осведомлен по большинству вопросов и я к этому стремлюсь. Пока что это не очень получатеся, потому что Xilinx инфой не особо делится-прям многоступенчатый доступ к секретам, но при этом ты должен свои секреты выдавать....

Давно я тут не была...Приветствую всех!
Для общего развития шуршала по инету-наткнулась на такую вещь:
JEDEC Files for Blank XC9500 Devices
------------------------------------

The XC9500 5v CPLD family does not support a self-blank-check
operation. However, a "verify" using a "blank" JEDEC file
may be performed to accomplish the same function as a
blank-check.

The files included in this archive are "blank" JEDEC files
that can be used to verify that a given XC9500 device is blank.

For the XC9500 5v CPLD family, a verify operation is significantly
quicker than an erase operation. Verifying that a device is blank
will allow you to skip erase for parts that are already blank. (All
parts are shipped blank from the factory.) This optimization can
provide huge improvements in overall in-system programming time
in production environments especially on automated test equipment.

SVF files that contain the blank-check (verify) vectors for the
XC9500 devices in single device scan chains are also included in
this archive. For multi-device scan chains, you will have to
generate custom SVF files that correspond to your scan chain
using JTAG Programmer with the "blank" JEDEC files.

Так похоже на мою мечту о создании пустого файла, после программирования которым ПЛИС не будет потреблять. Так ли это, господа разработчики? Я даже уже пыталась помучить свою ПЛИС и попытаться прошить этим файлом, но на этапе загрузки файла в буфер программатора IMPACT выдал, что данные несогласованные, что файл косой и нажала на отмену. Может IMPACT у меня старый для этого файла - 8.1 версия?

Когда рассказывают о таких чудесах, то даже хочется их увидеть самому вживую. Вот только XC95288 у меня нет, есть XC9572. В принципе могу провести измерения потребления кристалла после стирания и после загрузки какого-нибудь проекта. Аппроксимировать результаты эксперимента в применении к вашей ситуации сами сможете? Или мне не стоит этим заморачиваться?

а чего чудесного - иногда перепродавци перестраховываются и прошивают микросхемы на пробу. в этом случае на выводы попадают лог уровни и впаянная микросхема коротит выход на внешнюю схему. При таких экспериментах с макс 3000 а попадали даже в такую ситуацию, что невозможно запрограммировать. пока дорожки не отрежешь.

Чудесами я считаю тот факт, что даже принудительно стертые кристаллы (после стирания, но еще до прошивки) имеют разное потребление.