alexadmin

Прописать set_clock_groups или set_false_path в констрейны для соответствующих клоков или сигналов.

Можно написать собственный загрузчик, который будет принимать данные через JTAG иль еще как и программировать флэшку. Проблема системного загрузчика в том, что она работает на низкой частоте (порядка 1 МГц), из-за чего все и тормозит... Хотя 10 минут для артикса все равно многовато как-то. Компрессия используется в bit-файле?

Вопрос традиционно для тех, кто полностью скурил стандарт. Есть, к примеру, порт : CTRL : inout STD_LOGIC_VECTOR(31 downto 0); Далее я могу написать alias MY_CTRL : std_logic_vector(2 downto 1) is CTRL(23 downto 22); А хочется написать что-то типа alias MY_CTRL : std_logic_vector(2 downto 1) is (CTRL(23), CTRL(19)); Но аггрегация здесь, похоже, не поддерживается (да наверное и не должна, если подумать о том, что такое массив). Но тем не менее хочется. Понятное дело, можно разбить MY_CTRL на отдельные скалярные элементы MY_CTRL_1 и MY_CTRL_2, но некрасиво. Можно MY_CTRL сделать сигналом. Но тогда про двунаправленность придется забыть и при назначении всякий раз думать вход это или выход. Еще идеи?

Зависит от speed grade, корпуса, используемого типа банка и питания. Смотрите DS182, раздел Performance Characteristics.

Хм. У Xilinx есть готовое ядро JESD, можно пользоваться им если готовы приобрести лицензию. Если нет - есть бесплатное ядро JESD Phy, которое берет на себя все вопросы настройки трансиверов, остается только прикрутить несложную логику.Еще у самого AD есть открытое ядро JESD на верилоге, можно на него посмотреть. PS The Xilinx JESD204 core is a fully tested Physical and Data Link Layer block designed to JEDEC JESD204B specifications

Даже не знаю, есть ли смысл тут спрашивать, вопрос у меня больше софтовый, но тем не менее... Хочется сделать плату PCIe в которой была бы возможность контролировать работу через служебный интерфейс, автоматически управлять серверными вентиляторами в зависимости от температуры и т.д. С нижним уровнем SMBUS/I2C все понятно, а вот дальше как-то мутно. Есть спецификация PMBUS, которая содержит в протоколе ряд команд для передачи данных о напряжении/температуре/вентиляторах и т.д. И оставляет довольно много для manufacturer-specific. В то же время, если смотреть исходники linux, там есть некая поддержка pmbus, но пилят драйвера под конкретные чипы. Собственно вопросы: 1. Будет ли поддерживаться биосом (системным контроллером серверным) и ОС (Windows/linux) мое абстрактное устройство, если я реализую поддержку PMBUS по спецификации или потребуется пользовательская программа? 2. Если поставить стандартное устройство (или мимикрировать под него), например из списка https://github.com/torvalds/linux/tree/mast...ers/hwmon/pmbus , то повышаются ли шансы на автоматическую поддержку всяким ПО для мониторинга? Пытался читать описание материнских плат серверных, там слово pmbus вообще отсутствует, про smbus один раз упоминается.

Покурив доки обнаружил что область User area в eeprom, можно читать/писать функциями d2xx драйвера. Похоже так вивада и делает. Ну либо можно работать с бинарным дампом, полностью копируя образ eeprom без участия ft_prog.

Да. Читает (FT_Prog). Собственнно оттуда я и выяснил, что VID/PID оригинальные, а отличаются. Manuf.Desc. Но ответа на второй вопрос это не дает. У Digilent хотя бы используется универсальный модуль (SMT2) и там все неизменно. Но вот с платами Xilinx... Правда есть предположение, что первые цифры серийного номера могут определять аппаратную конфигурацию. Было бы интересно считать EEPROM у VCU1525, ZCU104. Ни у кого в столе не валяются? :) Очень интересно. Нашел еще https://forums.xilinx.com/t5/Configuration/...ado/td-p/817466 В FT_Prog в самом интерфейсе ничего кроме серийного номера не вижу, но в дампе, который так же любезно предоставляется просматривается еще текст...

Современные киты от Xilinx и Digilent имеют встроенный USB JTAG на базе микросхемы FTDI FT*32H. Хочется в своей плате сделать такое же решение. Идея понятна, повторить схему, скопировать настройки FTDI. Больше вроде ничего не надо. Но есть ряд непонятных моментов: 1) FTDI чипы в этих платах имеют стандартный VID/PID. Как Vivado опознает, что это именно программатор, по полю Manufacturer Description?2) На схемах трех китов, что я смотрел, подключение сигналов JTAG (TCK, TDI, TDO, TMS + доп. управление) к шине данных FTDI везде разное. Как драйвер или кто там разбирает где что?3) Я вообще плохо понимаю, как они эмулируют работу JTAG в режиме FT245 FIFO (выбран в настройках FTDI), но это уже вопрос теоретический. Может быть кто-то уже делал подобное?

Я бы еще смотрел на широко-используемые платы FPGA, как сделано в них. Ибо они стараются соответствовать стандарту, но иногда не полно. Сталкивался с ситуацией, что то, что можно подключить к какой-то там плате со стратиксом, нельзя, например, к KCU705 (подробностй не помню уже).

Вот та картинка, что приведена выше, это скриншот из модели, без всякого фотошопа? Тогда объясняю: источник сигнала надо ставить в схеме верхнего уровня, всю синтезируемую систему оформлять подкомпонентом с портами. И источник сигнала цеплять к этим портам. Потом где-то в настройках hdl coder задается какой именно блок модели следует синтезировать.

Надо отделять блоки, которые поддерживаются для синтеза (они представлены в списке выше) и блоки симулинка в целом. Для подачи на модель вам нужен блок, который так и называется - Step. Но он ставится снаружи по отношению к синтезируемой части модели и не попадает в синтезируемый код.

Если речь про модуль верхнего уровня,то лучше использовать `ifdef - чтобы эти порты совсем не виделись средством синтеза. переменную SIM определяете в настройках симулятора.

В данном случае можно просто закомментировать generate, endgenerate, а k объявить просто переменной целого типа. И получится обычный цикл for.

Когда я знакомился с этим года два-три назад, TI сам не верил, что у них такое получилось ;) Вроде как у них был один пример, который вроде как работал с определенным АЦП и на определенной частоте, без особой документации. Возможно, что с тех пор они продвинулись в практическом освоении...

Вообще говоря, если не требуется детерминированность задержки в тракте, то JESD - элементарный протокол, особенно с учетом что ядро JESD Phy бесплатное (у Xilinx). Если нужна детерминированность, то есть нюансы, но все равно ничего кардинально сложного. А так, в соседней теме кто-то ядра расшифровывает, вдруг поможет ;)

Снижать скорость JTAG. Смотреть качество сигналов, в частности клока (TCK). Еще Done по каким-либо причинам может быть притянут к земле, тогда эффект будет тот же (но это не точно, не помню наизусть какова там процедура старта у спартана)

В качестве догадки наобум: rc - это часто переменная кода возврата из функции, которая потом, бывает, не используется. Может она была выкинута из объектного файла в процессе оптимизации, но кто-то ее пытается найти? Соответственно или как-то задействовать ее в коде или совсем убрать.

Просто к слову. Kintex UltraScale, DS892 T INBUF_DELAY_PAD_I: LVCMOS33 0.96 ns LVDS_25 0.45 ns

Принимать по одному байту, складывать в буфер, выходить из прерывания, ждать следующего прерывания.

Проблема-то в том, что софт очень своевольно обращается с файлами проекта - положить HDL из отдельного каталога под котроль версий проблемы никакой. Но когда начинаешь создавать ip-компоненты, блок-схемы уже ой. Файл проекта даже при отсутствии изменений тоже сам по себе обновляется (это все в виваде, в квартусе несколько построже, но тоже есть нюансы).

В DSP Builder можно рисовать тот же RTL, только с автоматическим контролем разрядности и удобным тестовым окружением. Не вижу, как "по старинке" может получиться эффективнее при прочих равных.

Data master процессора к памяти подключен? Сбросы еще посмотреть.

Есть два прикола: Если в XDC в конце строки стоит символ комментария (#), то вся такая строка считается закомментированной. Не скажу за последние версии, но на предыдущих версиях было. Если какие-нибудь пины назначены внутри IP-блоков и они конфликтуют с вашими назначениями, то приоритет у IP, а ваши окажутся неназначенными.

В свете обсуждения: меня особо умиляет ограничение на импорт устройств с шифрованием, под которое в данный момент попали новые системы на кристалле от Xilinx. Которые при их цене по карману в основном только комитетчикам. В итоге выходит вор у вора дубинку украл гэбэшник гэбэшник на голову нагадил.