Beby

Я бы посоветовал воспользоваться чем-нибудь типа 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.

В 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 Вы испольуете ?

Так сами добавьте руками нужную ПЛИС, и весь необходимый функционал появится: Menu -> Edit -> Add Device -> Add Xilinx Device (Ctrl+D) После добавления можно делать всё, что угодно. Добавлять можно не только bit-файл, но и подходящий BSDL-файл, например: Xilinx/14.7/ISE_DS/ISE/kintex7/data/xc7k70t_fbg676.bsd (если я угадал - схему то Вы так и не представили...).

Не совсем понятно, что такое "пульсации: на VCCINT 150 мВ", если это амплитуда пульсаций, то тогда получается, что на VCCINT более 1.1 В, что, в принципе, смертельно для ПЛИС: Kintex-7 FPGAs Data Sheet (DS182 (v2.15) November 24, 2015): Table 1: Absolute Maximum Ratings VCCINT (Internal supply voltage) min –0.5 V max 1.1 V Поэтому лучше приложить фото/картинки осциллограмм/схемы, чтобы было легче догадаться, что же у Вас там за проблема. Кстати, следующее утверждение неверное: из Table 2: "Recommended Operating Conditions" документа "Kintex-7 FPGAs Data Sheet (DS182 (v2.15) November 24, 2015)" видно, что допустимый предел по VCCINT: ±3% (при номинальном питании 1.00 В, пределы установлены от 0.97 и до 1.03 В, что явно не выполняется). Да и 3А по VCCint как-то маловато,... но это уже определяется прошивкой ПЛИС: на одной из задач у нас XC7K160T-1FFG676C по VCCint жрала 21А,.. сожрала бы и больше, да нам было стрёмно: мы превысили порог в 16A (1А на ногу питания). Можно попробовать посмотреть на ногу Init - если в ПЛИС идут Power-on-reset, то, теоретически, Init должен переходить в '0', но гарантировать это я не могу - мы так жестко не насиловали Kintex-7. Также интересно, что подано на CFGBVS, VCCBATT и пр. ... Но тут лучше уже схему узреть целиком.

Если выдержать последовательность включения питания, то для Virtex-5/6/7/US/US+: во время подачи питания, в ожидании конфигурации и при конфигурации - токи очень маленькие (до нескольких ампер по VCCint, а иногда и меньше 1 А - зависит от размера кристалла) и более или менее совпадаю с приведённым в Datasheet'ах. Работающие ПЛИС мы нагружали на десятки ампер. Поэтому на фоне десятков ампер, то, что творится по включению питания, для нас является незначительно малым потреблением. Если нарушить последовательность подачи питания, то - да: можно нарваться на неприятности; но если я правильно помню, то жор будет преимущественно по VCCo (при отсутствии VCCint). Собственно для Virtex-5 сказано: Kintex-7/Virtex-7 можно вообще спалить, если на VCCo "долго" будет на 2.64 В больше, чем на VCCaux. А вот есть и неприятный нюанс, о котором обычно не задумываются: выключение ПЛИС: далеко не все источники питания нормально выдерживают переход от 85% - 90% нагрузки (в десятки ампер) к 0% нагрузки. Поэтому, перед выключением питания в нагруженных системах, для предотвращения выхода из строя ПЛИС и источников питания необходимо снижать нагрузку на источник постепенно. Естественно, во избежание неприятностей, последовательность выключения питания тоже настоятельно рекомендуется выдерживать.

Если изделие единичное или мелкосерийное, то оказаться проще и дешевле взять Kintex-7 с самым быстрым speed grade ('-3'), чем месяцами оптимизировать и втрамбовывать туда проект. А, вообще, оптимизация очень сильно зависит от проекта (DSP/BRAM или CLB-логику оптимизировать надо),... о котором Вы не сказали ни слова, равно как и о конкретном размере ПЛИС. Может быть Ваш "большой Кинтекс" для кого-то - не такой уж и большой... Да и ПЛИС надо бы поконкретней указывать, а то я как-то и не заметил какой из 3 Kintex'ов Вы имели ввиду: 7, US, US+. И предположил, что самый древний, т.е. Kintex-7.

Тут (Xilinx Video Keyword Search) больше посмотреть и послушать, но если скачать ppt'шку, то можно и почитать. Посмотрите видюшки по timing closure - может быть на какие-нибудь полезные мысли наведут. Рекомендую посмотреть все видюшки по Вашему семейству ПЛИС (и семействам-близнецам: Virtex6/Virtex7), а также по Вашей среде разработки. Я смог найти в этих видюшкиах полезную информацию, которой в документах - нет (около 5% от объёма видюшек). Эта информация встречается на конференциях и в официальных обучающих курсах,.. а вот в документах на ПЛИС и среды разработок - её нет. Совсем нет. Также, в видющках можно увидеть как задумывалось использовать те или иные инструменты и для чего они вообще рождались. Что тоже помогает более качественному проектированию. В тоже время, если Вы уже много знаете и умеете, необходимо запастись огромным терпением, ибо в этом случае полезный выход от видео будет на уровне 5%-10%, преимущественно в виде нюансов, интонаций и небольших замечаний, не относящихся к основному материалу видюшек, но проходящих на его фоне. В этом случае Вы как бы ничего нового не узнаете, а результат работы может заметно улучшиться.

INPUT_JITTER, задаётся для входного тактового сигнала и определяется неидеальностью этого сигнала. Constraint SYSTEM_JITTER может задаваться в тех случаях, когда значение по умолчанию Default System Jitter Вас почему-либо не устраивает. System Jitter обусловлен не идеальностью ПЛИС и порчей тактовых сигналов из-за проседания питания внутри ПЛИС во время массовых переключения синхронных элементов. Оба этих параметра пересчитываются в суммарный jitter для конкретных тактовых цепей, полученные значения можно увидеть в отчёте Timing Analyzer’а. Как расчитать конкретное значение System Jitter, отличное от Default System Jitter - я не знаю, и на сайте Xilinx как-то этот момент опущен. Наверное, для этого надо бы напрячь официальную тех. поддержку.

Для таких больших ПЛИС (Xilinx xc6vlx240tff1156-1) - это нормально, т.к. Xilinx перестрахиу ещё те, и это значение будет достигнуто, если всё звёзды галактике повернутся к Вам и Вашему устройству задом. В остальных случаях реальный Slack будет заметно больше. Собственно, условием успешного окончания разводки и является одновременное выполнением следующих условий: 1. все связи разведены, 2. все Slack >= 0 (может быть > 0). Поэтому, если Вы зададите большую частоту (не 100 МГц, а 110 МГц например) то, возможно, проект тоже благополучно разведётся, но за большее время.

Так я архивы снимал.

Это было года 2 назад, SSD'ка (Kingston 80Gb или 120Gb - уже не помню, но моделька была из бюджетненьких - "временная", до приобретения чего-нибудь хорошего) жила весьма хорошо месяца 2-3, а потом был включён SWAP, который её и кончил, часа за 2-2.5. Админ утверждал, что TRIM под Win7 был включён (точно знаю, все Intel драйвера стояли, в т.ч. AHCI, Suerfetch был отключён - всё это проверял лично). Естественно, Win7 ставился на NTFS (журналируемый),.. на него же умельцы и включили SWAP - "сколько надобно системе", ибо 16Gb ОЗУ было маловато. ОЗУ для того проекта реально не хватало, и SWAP пользовался на полную. Никого не хочу запугивать, но такой печальный случай имел место быть. С другой стороны, необходимо отметить, что, не смотря на повреждения SDD, все интересующие меня пользовательские данные (около 10Gb) я смог благополучно снять с той повреждённой SSD'ки (без каких-либо спец. утилит - просто копированием).

А про него не читать надо, а пробовать его надо, и затем прикидывать - удобно или нет. Раньше, под Win7, я пользовал ASUS ROG RAMDisk, а теперь перешёл на ImDisk (именно ImDisk, только старый, и лежит в основе ASUS ROG RAMDisk). Но на работе мы RAMDisk'и практически не используем - смысла нет: если все операции с файлами занимают где-то минут 5 на одну компиляцию, а проект компилируется часов 5-20, то никакого смысла использовании RAMDisk'а не видно. Но у нас - монстровидные кристаллы Virtex-7/UltraScale, а у Вас может быть совсем другой расклад. Есть такое приятное дело, особенно если хорошенько посношаться с файловыми системами - но это - на любителя. Но и тут не всё гладко: в продукции Western Digital наметилась нездоровая тенденция включать таймер автопарковки головок диска на 300с... причём, операционная система об этом гадстве совсем не в курсе и отключить не в состоянии. Оно, конечно, замечательно экономит энергию и ресурс... но уж больно долго головки вылезают. В тоже время, сам пользуюсь исключительно WD'шками,.. предварительно отучив их от такого гадства. Возможно, те, кто много работают с SeaGate'ами, тоже смогут рассказать что-нибудь не менее гадостливое - оно и там тоже есть, но другого плана - поэтому мы на фирме практически отказалось от продукции SeaGate. Когда добрые люди на notebook'е включили swap (видите ли им ОЗУ не хватало !), то за пару часов знатно испоганили системную SSD'ку. В результате машина стала хаотично зависать (Win7 глухо виснет при ошибке записи/чтения на/с SDD/HDD, если операции были инициированы самой системой) или вообще не хотела загружаться. С подлой порчей исключительно пользовательских файлов - не сталкивались.

Когда у меня была похожая нужда, я позвонил в БМГ+ и попросил подобрать для меня генератор, который удовлетворял бы моим потребностям: без цифрового PLL, ±50ppm за время эксплуатации (7 лет), при -40 ÷ 70 C, выход LVCMOS_2.5V, 25 МГц. В итоге нам посоветовали ГК251-П2 (DIL8) с какими-то (им более удобными для производства) буковками - нам было всё равно, как ppm'ы распределится между точностью настройки и стабильностью. После телефонного звонка, уточнение технических деталей производилось по электронной почте, но сам звонок помог быстро решить принципиальные вопросы и значительно сократил время утряски мелких деталей. Подозреваю, что DIL8 – это явно не «малогабаритный» корпус, но Вы можете попробовать повторить наш путь, возможно БМГ+ сможет сделать что-нибудь подходящее и для Вас. P.S. Для Marvell 88E1111 нам обязательно требовался кварцевый генератор без встроенного цифрового PLL, поэтому мы и остановились на несколько громоздком варианте, но с точно известным поведением и параметрами.

Использовать RAM Disk надо уметь, а, к моему глубокому сожалению, подавляющее большинство людей не хотят понимать, как его можно удобно использовать. Поэтому, в большинстве случаев, проще сказать использование RAM Disk’ка - это "знатное извращение", чем долго и нудно доказывать, его преимущества - кому надо, и так всё услышит и призадумается... Однако отмечу, что мне весьма отрадно слышать, что есть ещё люди, активно пользующие такие «технологии».

Можно хранить рабочие проекты и на SSD, и на HDD, естественно файлы будут быстрее читаться с SSD. Вопрос надёжности любого носителя необходимо решать регулярным резервным копированием, желательно ещё и частым - чтобы в случае проблем можно было недалеко откатиться. Проблемы могут быть обусловлены, как надёжностью носителя, так и какими-либо ошибками разработчика, а также и кривизной сред разработки. Конечно, можно хранить большие рабочие проекты и на HDD, но в случае использования NTFS, для достижения хорошего уровня быстродействия, потребуется, как следует посношаться с различного рода оптимизационными процедурами. Что, в свою очередь, не избавляет от необходимости проводить регулярное резервное копирование. Поэтому проще сразу использовать хороший SDD для хранения как операционной системы со средами разработки, так и для рабочих файлов проектов. Если на машине «много» ОЗУ, можно заняться знатным извращением: начать использовать RAM Disk, но одно неловкое телодвижение или зависание системы - и данные с RAM Disk’а безвозвратно пропадают. В своё время ASUS предлагал Gamer’ам использовать ASUS ROG RAMDisk для увеличения ресурса жизни SSD: образ игры, находящийся на SDD, при старте системы быстро загружается в ОЗУ машины, и далее работа идёт только с ОЗУ, при остановке операционной системы изменения записываются на SDD. Необходимо отметить, что записываются только изменённые фрагменты образа, что значительно экономит время и количество циклов записи на SSD.

Нет, не могу сказать, т.к. это очень сильно зависит от реализованной на CLB схеме. Для нашей типовой тестовой задачи количество потребляемых ампер можно грубо оценить как индекс Virtex-5/6/7 делённый на 10. Например, для XC7VX485T это будет 48.5 А. Очень тяжело оно живёт без радиаторов, только разработчикам можно выполнять базовые короткие и маложрущие тесты (памяти и связей) и при очень сильном воздушном потоке. Обычно такой режим используется при ремонте платы после замены одной из ПЛИС. Естественно, это было фото платы со снятым радиатором, ибо с радиатором ничего не было бы видно: Обычно у MMCM Jitter и Wander значительно больше, чем у внешних специализированных PLL. Степень чреватости, в свою очередь, определяется конкретными значениями Jitter, Wander и параметрами потока передаваемых данных.

Точные параметры назвать не могу, но основное потребление в XC7VX485T происходит в CLB (LUT+FF), более 90% коих работает на частоте более 300 МГц. Ну вот напримет на этой плате: :rolleyes: "Покупайте наших слонов." :rolleyes: