Beby

С таким извращением, как «clipped sine wave» пока ещё не сталкивался. К сожалению без осциллограммы выходного сигнала и сведений о его нагрузочной способности ничего не могу порекомендовать определённого. Однако, могу предложить «на подумать» рассмотреть варианты втаскивать данный сигнал в ПЛИС, как SSTL или LVDS/VLPECL при подаче на второй вход среднего уровня сигнала. В своё время подобное решение нам предлагал ленинградский Морион (производитель тактовых генераторов) для ввода синусоидального сигнала с выхода их термостатированных генераторов: «Хотите меньше фазовых шумов ? Да без проблем, переходите с КМОП на Sin и тащите его в ПЛИС, как SSTL/HSTL/LVDS/LVPECL – как вам больше нравится !».

«Реальные задачи» - это, конечно, хорошо. Но вроде тут больше обсуждалась специфика «реального отечественного железа». Потому буду более конкретен: вот есть такая микросхема (К)1986ВЕ1* от Миландра считающаяся отечественной. У неё есть встроенное ПЗУ, которое достаточно тормозное («порядка 40нс», при частоте работы микроконтроллера до 144 МГц), чтобы Миландру пришлось реализовывать механизм «упреждающего чтения». Как только появляется необходимость читать что-то не подряд, то конвейерная работа этого механизма ломается, и мы получаем полноценную задержку чтения (5-7 тактов системной частоты, вместо 1-го). Вот эта штука «упреждающего чтения» вполне себе подходит под определение, которое дала Xenia: Соответственно, спотыкание в работе оного «упреждающего чтения» вполне себе Cache Miss. К сожалению, в программах, с большим количеством условных переходов это случается с завидной регулярностью.

Весьма вероятно, что так и будет, поэтому можно вспомнить про 2 вида мухлежей около медленной Flash-ROM: 1. Flash-ROM снабжается статической памятью, в которую (при инициализации микросхемы) переносится содержимое Flash-ROM. Так сделанно в Xilinx CPLD: CoorRunner и CoolRunner II. 2. Рядом с Flash-ROM ставиться статическая или даже динамическая память, в которую переваливается содержимое Flash-ROM. Так было сделано в обычных PC ёще до появление кешей, называлось: Shadow RAM. Угу, но только если не учитывать Cache Miss. После которого всё становится очень тоскливо. При прочих равных условиях так пока и есть. Работают заметно медленнее, жрут заметно больше.

Добавлю свои 5 копеек: 1. Работаю преимущественно с Xilinx и лет 5 назад различные опыты проводил над ISE 14.7 под Win7. 2. Ключевыми моментами оказались частота одного ядра и частота памяти (большинство операций при MAP и P&R проводятся в 1 поток – только расчёт временных ошибок выполнялся в 2-4 потока). 3. Выяснилось, что отключив на Intel Core i7-4770 Hyper-Threading, получаем небольшой прирост быстродействия (около 5%) – толи от того, что cache сдвоенного ядра стал монопольно доставаться одному полуядру, толи отключенное полуядро стало меньше греть оставшееся – не знаю. 4. На i7-8700K тот же фокус с отключением Hyper-Threading тоже показывает положительные результаты... и не только с Xilinx. 5. Процессоры с огромным избытком ядер, как правило, работают хуже, чем процессоры с 4-6 ядрами – вероятно проблемы кроются в RAM->Cache L4/L3->Cache L2 тракте. Частично это нивелируется более грамотным распределением вычислительной нагрузки по ядрам в UNIX/Linux системах (по сравнению с Windows). 6. Внешняя видеокарта, тоже разгружает тракт RAM->Cache L4/L3, поэтому может давать от 5% до 10% прироста быстродействия – зависит от видеорежимов, количества мониторов и загрузки видео-ядра (оно, если встроенное в CPU, тоже его хорошо греет, уменьшая тепловой бюджет процессорных ядер, да и Cache L4/L3 забивает своей информацией). Ну и уже была тут аналогичная тема в 2016 году: Может кому чем поможет.

Возможные состояния ПЛИС можно грубо разделить на 4 зоны: 1. ПЛИС не в адеквате (не все необходимые для старта питания поданы) – Х.З. что. 2. ПЛИС до загрузки – обычно есть спец. нога, которой: либо все I/O ножки переводятся в Pull-up, либо в ‘Z’. 3. после загрузки первого конфигурационного пакета – в соответствии с настройками сгенерированного bitstream’а (для «during configuration») и возможностями ПЛИС. 4. после загрузки bitstream и старта ПЛИС – в соответствии с настройками сгенерированного bitstream. (для «after configuration»). P.S. Конкретно с Cyclone-V пока ещё не работал, читать документацию пока лень. Но суть процессов от этого не меняется - разве что именно у Cyclone-V какие-либо из указанных настроек (возсожностей) могут и отсутствовать...

Теоретически - да. Но я бы рекомендовал заглянуть в 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 – но они к этой теме никак не относятся.