Jump to content

    

Beby

Свой
  • Content Count

    608
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Beby

  • Rank
    Злополезный
  • Birthday 12/03/1979

Контакты

  • AIM
    -
  • MSN
    -
  • Сайт
    http://
  • ICQ
    0
  • Yahoo
    -

Информация

  • Город
    Russia Taganrog

Recent Profile Visitors

2587 profile views
  1. Дело в том, что там, где нужны действительно большие скорости и огромная пропускная способность, часто применяется не LVDS, а SSTL/HSTL: в таком случае количество I/O на один IO-Bank возрастает практически в 2 раза (по сравнению с LVDS) - и в этом случае очень легко поиметь проблемы с SSO. Сейчас, конечно, в современных ПЛИС хорошо развились SerDes'ы (MGT) - и частенько для высокоскоростных обменов они подходят лучше, а вот лет 5-7 назад с MGT была тоска полная. Да и в современных DDR’ах пока ещё используют SSTL, а не MGT (Про Hybrid Memory Cube знаю... даже как-то обсуждал с представителями Micron его сильные и слабые стороны по сравнению с DDR, естественно, применительно к ПЛИС).
  2. Я бы посоветовал воспользоваться чем-нибудь типа HyperLynx (PCB Analysis and verification tool от Mentor Graphics). Для начала IBIS моделей (передатчика и приёмника) вполне должно хватить.
  3. Хоть это нигде и не прозвучало, но, наверное, Вы используете что-то вроде 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 программировалась "естественным" образом.
  4. Если у iMPACT'а необходимо подавить проверку SPI Flash ID, то можно добавить переменную окружения XIL_IMPACT_SKIPIDCODECHECK=1 Детальнее обсуждалось тут: Spartan 6 indirect SPI Flash programming ID Check Failed
  5. Цитата(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 – но они к этой теме никак не относятся.
  6. К сожалению, в обсуждении этой темы я не заметил конкретных цифр: периода тактовой, величин задержек в 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 остаёмся в текущем. У Вас, случаем, не подобная ситуация ? И, пожалуста, если не сложно, укажите конкретные цифры.
  7. Цитата(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 в зависимости от стандарта и различных условий.
  8. Укажите, пожалуйста, тип ПЛИС - от этого много зависит. У ряда ПЛИС есть параметр Drive - можно его поставить на максимум, для Вашего стандарта ввода-вывода. Кстати, стандарты тоже укажите: какой у Вас сейчас выбран, и тот который требуется - может кто чего хитрого и насоветует...
  9. Цитата(Lmx2315 @ Jan 13 2017, 17:23) А ещё помню - подтягивающие резисторы может быть неправильных номиналов , вместо Ком , Момы. Сталкивался с подобным лично, но более 10 лет назад: резисторы 0805 имели маркировку как 5.1кОм,.. а по результатам измерения 51кОм. Отдел закупки потом кровожадные разборки клеил с поставщиками.
  10. Цитата(Олег Гаврильченко @ Jan 13 2017, 17:40) Блокировочный конденсатор - это конденсатор фильтрующий питание микросхемы буфера? Да. На Вашей схеме это будут C1 и C2.
  11. Цитата(Олег Гаврильченко @ 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 Вы испольуете ?
  12. Цитата(Олег Гаврильченко @ Jan 13 2017, 14:52) У меня в меню Debug такого пункта нет. Он появляется, только если устройство уже правильно определилось Так сами добавьте руками нужную ПЛИС, и весь необходимый функционал появится: Menu -> Edit -> Add Device -> Add Xilinx Device (Ctrl+D) После добавления можно делать всё, что угодно. Добавлять можно не только bit-файл, но и подходящий BSDL-файл, например: Xilinx/14.7/ISE_DS/ISE/kintex7/data/xc7k70t_fbg676.bsd (если я угадал - схему то Вы так и не представили...).
  13. Цитата(Олег Гаврильченко @ Jan 11 2017, 11:50) На питании нашел сильные пульсации: на VCCINT 150 мВ, на VCCAUX пилообразное напряжение 200 мВ, частота пилы много меньше частоты преобразователя DC/DC. Я понимаю, что на такой вопрос невозможно дать четкий ответ.Не совсем понятно, что такое "пульсации: на 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 Поэтому лучше приложить фото/картинки осциллограмм/схемы, чтобы было легче догадаться, что же у Вас там за проблема. Кстати, следующее утверждение неверное: Цитата(Lmx2315 @ Jan 11 2017, 12:13) ..там VccINT 1V +-5 %, а у вас явно хуже.из 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 и пр. ... Но тут лучше уже схему узреть целиком.
  14. Если выдержать последовательность включения питания, то для Virtex-5/6/7/US/US+: во время подачи питания, в ожидании конфигурации и при конфигурации - токи очень маленькие (до нескольких ампер по VCCint, а иногда и меньше 1 А - зависит от размера кристалла) и более или менее совпадаю с приведённым в Datasheet'ах. Работающие ПЛИС мы нагружали на десятки ампер. Поэтому на фоне десятков ампер, то, что творится по включению питания, для нас является незначительно малым потреблением. Если нарушить последовательность подачи питания, то - да: можно нарваться на неприятности; но если я правильно помню, то жор будет преимущественно по VCCo (при отсутствии VCCint). Собственно для Virtex-5 сказано:Цитата(DS202 v5.3 Virtex-5 FPGA Data Sheet: DC and Switching Characteristics @ May 5 2010)The power supplies can be turned on in any sequence, though the specifications shown in Table 5 are for the recommended power-on sequence of VCCINT, VCCAUX, and VCCO. The I/O will remain 3-stated through power-on if the recommended power-on sequence is followed. Xilinx does not specify the current or I/O behavior for other power-on sequences. Kintex-7/Virtex-7 можно вообще спалить, если на VCCo "долго" будет на 2.64 В больше, чем на VCCaux. А вот есть и неприятный нюанс, о котором обычно не задумываются: выключение ПЛИС: далеко не все источники питания нормально выдерживают переход от 85% - 90% нагрузки (в десятки ампер) к 0% нагрузки. Поэтому, перед выключением питания в нагруженных системах, для предотвращения выхода из строя ПЛИС и источников питания необходимо снижать нагрузку на источник постепенно. Естественно, во избежание неприятностей, последовательность выключения питания тоже настоятельно рекомендуется выдерживать.
  15. Цитата(Koluchiy @ Nov 25 2016, 19:14) Надо чтоб было 400МГц на большом Кинтексе с большим заполнением. Если изделие единичное или мелкосерийное, то оказаться проще и дешевле взять Kintex-7 с самым быстрым speed grade ('-3'), чем месяцами оптимизировать и втрамбовывать туда проект. А, вообще, оптимизация очень сильно зависит от проекта (DSP/BRAM или CLB-логику оптимизировать надо),... о котором Вы не сказали ни слова, равно как и о конкретном размере ПЛИС. Может быть Ваш "большой Кинтекс" для кого-то - не такой уж и большой... Да и ПЛИС надо бы поконкретней указывать, а то я как-то и не заметил какой из 3 Kintex'ов Вы имели ввиду: 7, US, US+. И предположил, что самый древний, т.е. Kintex-7.