Beby

В имеющихся у меня 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

Цитата(DS @ Jul 22 2017, 15:14) И второе, что не описано - если используется PLL с обратной связью через BUFG (phase aligned), похоже, для расчета setup прибавляется целый период, а при расчете hold - не прибавляется. (Я и от входного клока пробовал тактировать, и от PLLльного).Вот я как раз и хотел посоветовать работать от PLL'ного Clock'а, с компенсацией кривизны BUFG, за счёт обратной сзязи. Но без конкретных цифр, это было бы неправильно. Цитата(DS @ Jul 22 2017, 15:14) Проблема в способе отсчета фронта для hold по умолчанию - это описано в документации. Когда набегает задержка, сравнимая с периодом, это приводит к ошибке, если явно не задавать. Это, кажется, Vivado-специфичная вещь.К сожалению, с Vivado-специфичными бякостями я пока помочь не смогу - мне ещё не приходилось работать с Vivado. Так случилось, что сейчас меня используют на схемотехку вокруг ПЛИС (в т.ч. US/US+), а вот до внутренностей у меня руки пока ещё не дошли: есть другие люди, которые могут работать внутри ПЛИС и совсем не могут проектировать внешнюю обвязку. Цитата(DS @ Jul 22 2017, 15:14) Тактовая 300 Мгц, внутри местами 600 Мгц.И по такой входной частоте проконсультироваться не у кого из знакомых: либо передаём совсем медленные сигналы (до 50 MT/s), либо уже используем более высокоскоростные интерфейсы (DDR3/4) с тренировкой (подбором входной задержки). В обоих случаях на constraint’ы для I/O ног забивается. Ещё, конечно, очень активно используются MGT – но они к этой теме никак не относятся.

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

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

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

Цитата(Lmx2315 @ Jan 13 2017, 17:23) А ещё помню - подтягивающие резисторы может быть неправильных номиналов , вместо Ком , Момы. Сталкивался с подобным лично, но более 10 лет назад: резисторы 0805 имели маркировку как 5.1кОм,.. а по результатам измерения 51кОм. Отдел закупки потом кровожадные разборки клеил с поставщиками.

Цитата(Олег Гаврильченко @ Jan 13 2017, 17:40) Блокировочный конденсатор - это конденсатор фильтрующий питание микросхемы буфера? Да. На Вашей схеме это будут C1 и C2.

Цитата(Олег Гаврильченко @ Jan 13 2017, 15:25) Но ПЛИС все равно не определяется оп прежнему. Однако, если поставить щуп осциллографа на линию TCK JTAG, то ПЛИС нормально определяется. Сигналы JTAG проходят через КМОП-буферы SN74LVC2G34DCK. Судя по осциллограммам проходят нормально.В SN74LVC2G34 - 2 канала,.. причём не самых быстрых... а в JTAG интерфейсе: 3 линии идёт к ПЛИС - может быть разбежка между буферами - они же не обязаны быть идентичными. Посмотрите, правильные ли Вы получаете диаграммы TDI/TMS/TCK под ПЛИС ? Исследование схем Xilinx привело нас к использованию SN74AVC / SN74ALVC буферов для JTAG - они вносят меньшую задержку, чем SN74LVC. Естественно, для одного направления передачи данных (TDI, TMS, TCK) мы стараемся использовать общий буфер (SN74AVC8T245). Был у нас интересный случай: после подачи питания на плату iMPACT правильно определял всю цепочку Xilinx ПЛИС (8 шт. Virtex-6 или Virtex-7 не помню), а потом ничего не мог сделать. Оказалось, что TMS (вход буфера) залип на землю, а по включению питания в выходные каскады JTAG интерфейса записывается IDCODE ПЛИС - поэтому идентификация проходила росно 1 раз. Также был другой неприятный случай: развалился блокировочный конденсатор под буфером, да так, что выглядел целым, пока не стали его отпаивать - становишься осциллографом под ПЛИС на TMS и TCK - всё работает, убираешь щупы - глючит. Кстати, а какой JTAG Вы испольуете ?