jojo

было так, что тайминги сходятся - а прошивка работает только с Minimize Output Jitter. на Balanced прошивка уходит в запрещённое состояние. Было это не помню уже где на Virtex-6 или Kintex-7.

Я сильно не думал над этим, взял модель микросхемы памяти на Verilog от Micron и конвертировал оттуда тест на язык Си. То, что было на Verilog регистрами, вывел из FPGA через GPIO. Чисто софтовое решение, bitbang. Когда несколько bin зашиты в ПЗУ, по адресу любой прошивки можно сделать горячую перезагрузку. Что нужно шить я сейчас не помню, нужно уточнить. По идее это BIN или его производные в формате Hex.

Кстати, мы у кого надо покупали, но привезли нам партию из той же, видимо, неведомой тайваньской свалки. Интересовавшие нас параметры были сильно хуже у всей партии. Таков бизнес, деньги не пахнут.

Я не стал получать этот документ из-за организационной корявости нашей фирмы. Но получить документ можно через белого дилера Xilinx на вашей территории, с которым вы работаете. Заполняется регистрационная форма.

ПЛИСы с этим ядром весьма древние, какой тут вариант?

Можно временной анализ после par отключить (Generate Post-Place & Route Static Timing), это несколько минут может дать. Думаю, поможет 1. устранение узких мест в проекте, 2. размещение модулей квадратиками (floorplanning), 3. иерархическое супер-flow, которое всё равно не обойдётся без первых двух шагов, 4. свежий разогнанный компьютер с игроманской памятью. Мне кажется, время сборки больше часа-двух берётся от требований к проекту, которые не соответствуют глубине его проработки или выбранной микросхеме. Если есть пути критические - их ничто не уберёт, может быть, вывезет какая-нибудь шальная оптимизация САПРом и то до поры.

Время сборки стратегии примерно равно времени сборки одиночного проекта (кнопка просто по кнопке Run). Я даже не знаю, куда грести, тут всё уже перечислили. Возможно, что-то можно получить используя иерархические маршруты проектирования. Упоминание параллельной сборки на нескольких компьютерах навело на мысль собирать отдельно RPM-ы и сводить их под крышей одного проекта финальным запуском. Но это какой надо иметь проект... У меня средний кинтекс-7 занятый в слайсах на >90% и частотой > 500 МГц собирается за 1.5 часа от синтеза до бит-файла. За 1.5 часа! На попсовом 2500К На одном ядре Под Windows С синтезом в XST Что-то я делаю не так.

Это чтобы стратегию сборки искать, на которой сойдутся тайминги. Можно N стратегий параллельно собирать. Помогает убрать 100-200 пикосекунд задержек не тратя лишнего времени.

СмартЭксплорер иногда спасает вундер-проекты, в которых неустойчивая собираемость. С той переменной лучше собираются тесные проекты.

Необременительный и иногда действенный шаг - перебрать в SmartXplorer стратегии и (или) Cost Tables. Перебирать нужно у проекта в нежелательном состоянии (когда PAR долго-долго). Если использование ПЛИС "под крышку", попробуйте системную переменную XIL_PAR_ENABLE_LEGALIZER установить в 1 и пересобрать проект (опять же из нежелательного состояния).

Сейчас так инжненеры что-ли выражатся? Специалисты.. по говну... подтянулись. Да, там были какие-то проблемы с оными чипсетами. Где те чипсеты сейчас.

Вот он: Full speed USB 1.1 interface enabling download speeds of up to 150 KB/Sec (ADZS-USB-ICE) Посмотрите http://www.analog.com/en/design-center/lan...-and-tools.html Есть ещё Debug Agent, не знаю уже, какие DSP оне поддерживает.

Вот самый нормальный: http://www.insys.ru/device/emu-ad.htm По поводу должен показать - должны совпасть звёзды - правильно установить нужную версию VisualDSP 3.5 и вписать EMU-AD (клон эмулятора) в реестр. Ну и целостность сигналов, TCK хороший. Тогда покажет, да. Иначе окошко с Error 0xXXXXXXXX и никакого коннекта вплоть до устранения. Посмотрите ещё разъём JTAG на плате и у EMU-AD, не нужен ли переходник. Родных эмуляторов для этого DSP два, один 4000 USD, а второй - медленный и глючный.

Эмулятор это раньше было дорого, самый реальный был EMU-AD (остальное или дорого или хлам). Тут - или искать родные тулзы от платы, - или сделать свои собственные, тем более что схемы и FPGA/PAL открыты и достаточно просты, - или заглушить всё, кроме процессора, и, благо схема есть, прошить свою автономную от компа программу в ПЗУ платы. Если вы знаете этот процессор и есть хорошее оснащение лаборатории, все эти варианты примерно одинаковы по сложности. Самый простой - конечно - купить JTAG, раньше 700 USD стоил. Вы по Sharc Handbook почитайте, все вопросы сами отпадут. Реально у вас всё есть для запуска этой платы уже сейчас. Нужно ввести DSP в соотв. режим загрузки и сформировать временные диаграммы на его выводах. Здесь поможет проект PAL, который есть в UG платы.

Про эту штуку скоро Google забудет, однако задача всё равно стоит! Попробуйте следующие варианты, какой лучше - по ситуации: Ещё живы те компы, в которых можно завести штатные инструменты (нужены древний комп, ОС, дистрибутив тулзов, Visual DSP). Вероятно, можно подключиться через JTAG из Visual DSP (нужены JTAG, Visual DSP). Можно отбросить весь имеющийся инструментарий и прошить свою standalone программу в ПЗУ (нужен программатор или эмулятор ПЗУ, VisualDSP). Наконец, работу фильтра можно показать в симуляторе, привязав файлы с данными к адресам ввода-вывода (нужен только VisualDSP).

А сколько вы используете памяти и какой порядок обращения? Хотелось бы воспроизвести ваш эксперимент. Глюков с BRAM я не видел, но грязное питяние ПЛИС хорошего не сулит. Системный монитор таких пульсаций не видит. Нужно смотреть осциллографом. Я делал ради эксперимента заниженное напряжение на Kintex 325, 1С или 2C, кажется. Прошивка работала неправильно.

Не знаю, зачем ограничивать область применения именно радио. Видел вот такие железки - их точно (и дорого) покупают те, кто не может сделать свою такую же: dinigroup.com www.hitechglobal.com Постоянно нужны такие изделия местной разработки.

Да, и про печальку с имплепентацией. Если 1. укоротить пути распространения сигнала до 1-2 LUT, 2. не пережимать констрейны размещения и частот, 3. управлять входами clock enable с выхода триггера, 4. закладывать избыточные регистры в путях с выхода BRAM, и т.п. то под крышку занятая ПЛИС собирается на автомате за ~час с частотами вплоть до максимально возможных по даташиту. Причём без констрейнов на размещение. Если в проекте есть хоть какая-то дыра, она вылезет из-за высокой плотности размещения или частоты. И перебор стратегий сборки в сложных случаях не поможет вплоть до 1. устранения причин, 2. смирения с происходящим.

Товарищи, это же статический мультиплексор в LUT. У него нет других целей. Что касается появления внезапных LUT-ов в путях - это вполне возможно. Этим грешит как синтезатор, который из экономии делает, например, много LUT3 где можно сделать мало LUT6, или "Улучшитель потребления" (Coolgate ) который, гад, тоже много себе позволяет - из чистокровного регистра, например BRAM enable делает lut-ы.

Сложный вопрос, только опытным путём. Мы нормально покупаем, может, что дадут. А если нет - возьмём PLDA. Конкуренция!

Пока нет, только узнал сам. Наверное, обратимся к нашему дилеру. http://www.xilinx.com/products/intellectua...y/pcie-dma.html The Xilinx DMA for PCIe is provided at no additional cost. Approval is required. Please register for access Регистрационная форма не открывается

Лицензия с фичей xdma спасает отца русской демократии. Каким-то древним тулзом для генерации лицензий с ftp её сделал по образцу из директории Vivado 2015.3, синтез и симуляция работают. Что с этим делать - пока не знаю, но информация хорошая. Места занимает мало.

Спасибо! Макрос укрощён. Ларчик просто открывался, достаточно было задать положение любого элемента макроса через свойство LOC в XDC. Всё остальное у меня не заработало.

opt_design надо попробовать отключить, вдруг получится. Я так понял, адский САПР теряет rloc при обработке иерархии проекта. Путем многих экспериментов я затащил свое ядро в vivado и сделал из него xdc macro через create macro. Теперь как-то надо инстанциировать несколько копий ядра и подействовать на них этим макро, но как?

Товарищи, нужно перетащить в Vivado IP ядро. Оно сделано в ISE 14 и сохранено с размещением в NGC через EDIF+UCF. Размещение задано с помощью RLOC в сетке GRID. В общем, в ISE оно всё работает. В Vivado это IP я затащил через добавление NGC как исходника. Но в Vivado что-то произошло с сеткой координат, и, главное, (* RLOC= *) не перемещает IP по кристаллу. Короче, IP ядро стало в 2 раза шире и не перемещается. Если кто-то работал с RLOC, прошу ответить. Пересобирать ядро не вариант, в Vivado оно хуже получатся, что критично.