Beby

Теоретически - да. Но я бы рекомендовал заглянуть в IBIS модель (если её предоставляет производитель ПЛИС) и поглядеть цифирьки для крайних случаев (Min/Max) для интересующего режима работы буферов. Можно ещё в HyperLynx промоделировать (погонять ту же IBIS модельку) - поглядеть какие токи/напряжения при каких условиях будут возникать. Иногда, производители ПЛИС делятся и SPICE моделями - тогда моделирование может быть более точным. Но, думаю, что запредельные случаи (приводящие к необратимым повреждениям ПЛИС) промоделировать, скорее всего, не получится, т.к. пока ещё я не встречал систем моделирования учитывающие локальные перегревы транзисторов и их разрушение.

В имеющихся у меня Errata (текущих и древних) ничего подобного не описано. Микросхема у Вас относительно свежая – Revision D (Errata проходит как Revision Code – 4), поэтому с этой стороны проблем не ожидаю. С проблемами, похожими на Ваше описание, я сталкивался на Virtex-6/7. Было 3 основных причины: 1. Ошибка компонента – в одном случае был неправильно создан PCB Pattern, в другом – попутаны ножки между парами. 2. Ошибка подключения внешних элементов в схеме. 3. Непропай шара. Естественно, в Вашем случае, 3-й вариант весьма маловероятен, но мы сталкивались и с таким – из-за особенностей изготовления PCB и неотлаженной технологией пайки сложной платы с большой вероятностью не припаивались именно конкретные шары. 2-й вариант тоже выглядит крайне маловероятным... до тех пор, пока мы не предположим, что внешние элементы отожгли 1 ногу в паре. P.S. Ну и конечно желательно использовать ISE 14.7.

Укажите, пожалуйста, полное наименование микросхемы. Она у Вас не ES случаем ?

Сильно в этом сомневаюсь, что так оно будет устойчиво работать, т.к. было указано, что: А согласно ds181_Artix_7_Data_Sheet.pdf (v1.25, 18 June 2018) Table 11 "LVDS_25 DC Specifications": VIDIFF min: 100 mV. Посему я и запросил уточняющую информацию о параметрах входного сигнала.

Из предоставленных Вами данных совсем непонятно с каким сигналом необходимо работать. Уточните, параметры выходного сигнала: Униполярные уровни относительно GND и дифференциальные уровни.

Дело в том, что там, где нужны действительно большие скорости и огромная пропускная способность, часто применяется не LVDS, а SSTL/HSTL: в таком случае количество I/O на один IO-Bank возрастает практически в 2 раза (по сравнению с LVDS) - и в этом случае очень легко поиметь проблемы с SSO. Сейчас, конечно, в современных ПЛИС хорошо развились SerDes'ы (MGT) - и частенько для высокоскоростных обменов они подходят лучше, а вот лет 5-7 назад с MGT была тоска полная. Да и в современных DDR’ах пока ещё используют SSTL, а не MGT (Про Hybrid Memory Cube знаю... даже как-то обсуждал с представителями Micron его сильные и слабые стороны по сравнению с DDR, естественно, применительно к ПЛИС).

Я бы посоветовал воспользоваться чем-нибудь типа HyperLynx (PCB Analysis and verification tool от Mentor Graphics). Для начала IBIS моделей (передатчика и приёмника) вполне должно хватить.

Хоть это нигде и не прозвучало, но, наверное, Вы используете что-то вроде ISE 14.7. В таком случае в меню iMAPACT необходимо вызвать Help->Help Topics. В появившемся Help'е, в разделе "Configuration and Programming а Device" (3-й снизу) необходимо выбрать подраздел "SPI, BPI, and NAND PROM Support". В таблицах этого раздела можно увидеть, что для Spartan-6 из SPI Flash ROM Micron (Numonix) поддерживаются только N25Q 3.3V: 32Mb – 128Mb. Для Kintex-7, Virtex-7, Artix-7 поддерживаются 32Mb – 256Mb, но там другое IPS-ядро погружается в ПЛИС. Поэтому с одной стороны: iMAPACT "знает" идентификатор N25Q256A, однако с другой стороны: Xilinx не обещал его программировать для Spartan-6. Предполагаю, что запрограммировать всю N25Q256A в ISP режиме у Вас не получится, поэтому что N25Q128A - это самая большая SPI Flash ROM’а которой ещё хватает 3-х байтовой адресации. Для SPI Flash ROM большего объёма уже требуется 4-х байтовая адресация, а у меня есть серьёзные сомнения в том, что соответствующие команды были реализованы в ISP для Spartan-6 и Virtex-6. Может быть у Вас получится запрограммировать нижнюю половину N25Q256A если: 1. задать переменную окружения XIL_IMPACT_SKIPIDCODECHECK=1, 2. в iMAPACT указать, что к ПЛИС подключена N25Q128A. P.S. Подобным образом мне удавалось запрограммировать нижнюю половину N25Q512, подключенную к Virtex-7, однако в этом случае ситуация существенно отличалась от Вашей: N25Q512 - это сборка двух независимых N25Q256 в одном корпусе, поэтому нижняя N25Q256 программировалась "естественным" образом.

Если у iMPACT'а необходимо подавить проверку SPI Flash ID, то можно добавить переменную окружения XIL_IMPACT_SKIPIDCODECHECK=1 Детальнее обсуждалось тут: Spartan 6 indirect SPI Flash programming ID Check Failed

Вот я как раз и хотел посоветовать работать от PLL'ного Clock'а, с компенсацией кривизны BUFG, за счёт обратной сзязи. Но без конкретных цифр, это было бы неправильно. К сожалению, с Vivado-специфичными бякостями я пока помочь не смогу - мне ещё не приходилось работать с Vivado. Так случилось, что сейчас меня используют на схемотехку вокруг ПЛИС (в т.ч. US/US+), а вот до внутренностей у меня руки пока ещё не дошли: есть другие люди, которые могут работать внутри ПЛИС и совсем не могут проектировать внешнюю обвязку. И по такой входной частоте проконсультироваться не у кого из знакомых: либо передаём совсем медленные сигналы (до 50 MT/s), либо уже используем более высокоскоростные интерфейсы (DDR3/4) с тренировкой (подбором входной задержки). В обоих случаях на constraint’ы для I/O ног забивается. Ещё, конечно, очень активно используются MGT – но они к этой теме никак не относятся.

К сожалению, в обсуждении этой темы я не заметил конкретных цифр: периода тактовой, величин задержек в BUFG (для обоих крайних случаев), да и про данные, которые необходимо принимать - тоже мало что сказано. А частичное описание проблемы, типа: очень похоже на проблему, с которой я сталкивался в ISE при работе с Virtex-6 LX240T/SX315T: огромная неопределённость прохождения сигнала по BUFG. Для расчёта Setup бралась величина от 3 до 5 нс (от ПЛИС зависело), а для расчёта Hold - около 0.5 нс. Естественно, при временном анализе проекта для передачи данных где-то на 200 MT/s получалась херня: по Setup улетаем на следующий период, а по Hold остаёмся в текущем. У Вас, случаем, не подобная ситуация ? И, пожалуста, если не сложно, укажите конкретные цифры.

Хорошая ПЛИС, очень много разных стандартов ввода-вывода поддерживает. Если Вы используете LVCMOS выходы, то можно попробовать установить максимальное значение атрибута Drive (у OBUF). Оно для разных LVCMOS - разное. В ug331 (Spartan-3 Generation FPGA User Guide) в Table 10-10: Available Single-Ended I/O Standards указаны максимальные значения Drive в зависимости от стандарта и различных условий.

Укажите, пожалуйста, тип ПЛИС - от этого много зависит. У ряда ПЛИС есть параметр Drive - можно его поставить на максимум, для Вашего стандарта ввода-вывода. Кстати, стандарты тоже укажите: какой у Вас сейчас выбран, и тот который требуется - может кто чего хитрого и насоветует...

Сталкивался с подобным лично, но более 10 лет назад: резисторы 0805 имели маркировку как 5.1кОм,.. а по результатам измерения 51кОм. Отдел закупки потом кровожадные разборки клеил с поставщиками.

Да. На Вашей схеме это будут C1 и C2.