Перейти к содержанию

alexadmin

Свой
  • Публикаций

    573
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о alexadmin

  • Звание
    Знающий

Контакты

  • Сайт
    http://
  • ICQ
    310601465

Информация

  • Город
    СПб, Россия

Посетители профиля

3 534 просмотра профиля
  1. Зависит от speed grade, корпуса, используемого типа банка и питания. Смотрите DS182, раздел Performance Characteristics.
  2. Хм. У 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
  3. Даже не знаю, есть ли смысл тут спрашивать, вопрос у меня больше софтовый, но тем не менее... Хочется сделать плату 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 один раз упоминается.
  4. Покурив доки обнаружил что область User area в eeprom, можно читать/писать функциями d2xx драйвера. Похоже так вивада и делает. Ну либо можно работать с бинарным дампом, полностью копируя образ eeprom без участия ft_prog.
  5. Да. Читает (FT_Prog). Собственнно оттуда я и выяснил, что VID/PID оригинальные, а отличаются. Manuf.Desc. Но ответа на второй вопрос это не дает. У Digilent хотя бы используется универсальный модуль (SMT2) и там все неизменно. Но вот с платами Xilinx... Правда есть предположение, что первые цифры серийного номера могут определять аппаратную конфигурацию. Было бы интересно считать EEPROM у VCU1525, ZCU104. Ни у кого в столе не валяются? :) Очень интересно. Нашел еще https://forums.xilinx.com/t5/Configuration/...ado/td-p/817466 В FT_Prog в самом интерфейсе ничего кроме серийного номера не вижу, но в дампе, который так же любезно предоставляется просматривается еще текст...
  6. Современные киты от 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), но это уже вопрос теоретический. Может быть кто-то уже делал подобное?
  7. Я бы еще смотрел на широко-используемые платы FPGA, как сделано в них. Ибо они стараются соответствовать стандарту, но иногда не полно. Сталкивался с ситуацией, что то, что можно подключить к какой-то там плате со стратиксом, нельзя, например, к KCU705 (подробностй не помню уже).
  8. Вот та картинка, что приведена выше, это скриншот из модели, без всякого фотошопа? Тогда объясняю: источник сигнала надо ставить в схеме верхнего уровня, всю синтезируемую систему оформлять подкомпонентом с портами. И источник сигнала цеплять к этим портам. Потом где-то в настройках hdl coder задается какой именно блок модели следует синтезировать.
  9. Надо отделять блоки, которые поддерживаются для синтеза (они представлены в списке выше) и блоки симулинка в целом. Для подачи на модель вам нужен блок, который так и называется - Step. Но он ставится снаружи по отношению к синтезируемой части модели и не попадает в синтезируемый код.
  10. Если речь про модуль верхнего уровня,то лучше использовать `ifdef - чтобы эти порты совсем не виделись средством синтеза. переменную SIM определяете в настройках симулятора.
  11. В данном случае можно просто закомментировать generate, endgenerate, а k объявить просто переменной целого типа. И получится обычный цикл for.
  12. Когда я знакомился с этим года два-три назад, TI сам не верил, что у них такое получилось ;) Вроде как у них был один пример, который вроде как работал с определенным АЦП и на определенной частоте, без особой документации. Возможно, что с тех пор они продвинулись в практическом освоении...
  13. Вообще говоря, если не требуется детерминированность задержки в тракте, то JESD - элементарный протокол, особенно с учетом что ядро JESD Phy бесплатное (у Xilinx). Если нужна детерминированность, то есть нюансы, но все равно ничего кардинально сложного. А так, в соседней теме кто-то ядра расшифровывает, вдруг поможет ;)
  14. Снижать скорость JTAG. Смотреть качество сигналов, в частности клока (TCK). Еще Done по каким-либо причинам может быть притянут к земле, тогда эффект будет тот же (но это не точно, не помню наизусть какова там процедура старта у спартана)
  15. В качестве догадки наобум: rc - это часто переменная кода возврата из функции, которая потом, бывает, не используется. Может она была выкинута из объектного файла в процессе оптимизации, но кто-то ее пытается найти? Соответственно или как-то задействовать ее в коде или совсем убрать.