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

    

RobFPGA

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

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Профессионал

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

9 542 просмотра профиля
  1. Приветствую! Тут проблема в том что все такие "примеры" привязаны к конкретным палатам с FPGA. Поэтому "универсальных" решений для неизвестных плат на куче разных чипов нет. (ну разве за исключением варианта 2.5) ;) Если передо мной стояла бы задача придумать такое решение - то я бы смотрел на вариант внешнего модуля с flash и MCU на котором работал бы сетевой стек и программа для обновления flash/загрузки FPGA. Для пущей универсальности можно было бы и JTAG сервер поднять на нем сделав этакий сетевой JTAG. Удачи! Rob.
  2. Приветствую! У вас файл добавился в Source/Hierarchy? Если он парсится с ошибками то откройте его и увидите что Vivado в нем не нравится . Удачи! Rob.
  3. Приветствую! Вы путает мягкое с теплым - В общем случае при переходе из clk200 в clk100 синтезатор не знает на каком фронте clk200 (из 2 для периода clk100) данные валидны поэтому берет худший вариант. Если вы точно знаете - то укажите это для конкретных цепей через multi_cycle или max_delay. Удачи! Rob.
  4. Приветствую! Когда клоки связаны (например генерируется из одной PLL) и целочисленно кратны то фронта этих клоков выровнены (если конечно не добавлены настройки фазы для каждого клока в PLL). Анализатор автоматом вычисляет времена для переходов которые при этом будет равны периоду большей частоты (минус джиттер и неравномерность пути клоков). Удачи! Rob.
  5. Приветствую! Методов ровно 2.5 1: Либо контролер обновления прошивки сидит внутри дизайна FPGA - полностью в виде FSM либо частично программно на встроенном CPU ядре. 2: Либо внешний (по отношению к FPGA) контроллер (CPU, MCU, CPLD) который может обновлять flash/загружать FPGA из внешнего источника. 2.5: Разновидность внешнего контролера с подключением к сети - мальчик с ноутбуком и JTAG ;) по утру ходит по стойкам, тыкает JTAG палит все статикой обновляет прошивки. 8-() Удачи! Rob.
  6. Приветствую! Вы для начала определитесь на сколько шустрая память вам нужна и какого размера а потом уж искать беритесь. Когда будет конкретика требований к пропускной полосе, тип и режимы работы по портам, тогда и можно судить подойдет ли виртуальная много-портовость или потребуется "железная" DP-RAM. Удачи! Rob.
  7. Приветствую! Это справедливо только для синхронного режима работы памяти - при асинхронном (при разных тактовых на портах) одновременные запись и чтение по одному и тому же адресу приведет к неопределенным данным чтения. Для всех этих задач достаточно "виртуальной" дву/много-портовости - достаточно разнести во времени циклы чтения/записи на обычной памяти и ни каких конфликтов не будет. Удачи! Rob.
  8. По отдельности использовать без проблем - а вот со скоростью 1G не не знаю. Для маленького футпринта посмотрите еще на модули FireFly. Они ставятся прямо на плату и не обязательно на торец. Удачи! Rob.
  9. Приветствую! А вам оптика нужна или медь для 12 x 10G ? Для оптики я вроде видел CXP модули для multi-fiber кабеля (вроде CXP - MTP) соответственно ему можно и fanout сделать на отдельные жилы. Для меди не помню такого. Удачи! Rob.
  10. Приветствую! Когда у вас связанные клоки - (чаще всего когда генерируются из одного источника) то анализатор по умолчанию вычисляет худший вариант соотношений времянки межу ними для проверки ограничений. И не важно сколько при этом регистров между ними (это служит для других целей - для устранение метастабильности). Проблема анализатора всегда между выходом регистра в одной тактовой и входом регистра в другой тактовой. Поэтому либо кладем болт глобально (если конечно по дизайну это допустимо!) - объявляя клоки асинхронными. Либо посылаем локально - указывая set_false_path для конкретных цепей. Тут вам надо определится - если это просто отдельный сигнал то достаточно перехода через 2-4 регистра без всякого handshake. Тоже и для группы сигналов которые не связанны между собой. Если же это шина данных (сигналы зависимы) то тут либо синхронизатор как описал des00 для медленных сигналов - либо fifo для быстрых. В Vivado есть библиотека XPM в ней есть готовые модули CDC как для одиночных/группы сигналов так и для шины. Посмотрите в визарде. P.S. Ну и можно не только использовать модули из XPM, а подсмотреть как задавать constrain для таких случаев : ..../data/ip/xpm/xpm_cdc/tcl/xpm_cdc_single.tcl # Scoped constraints for xpm_cdc_single set src_clk [get_clocks -quiet -of [get_ports src_clk]] set dest_clk [get_clocks -quiet -of [get_ports dest_clk]] if {($src_clk != $dest_clk) || ($src_clk == "" && $dest_clk == "")} { set_false_path -to [get_cells syncstages_ff_reg[0]] } elseif {$src_clk != "" && $dest_clk != ""} { common::send_msg_id "XPM_CDC_SINGLE: TCL-1000" "WARNING" "The source and destination clocks are the same. .... } Удачи! Rob.
  11. Приветствую! Может и в здравом уме такое сделать - например если тактовая назначения высокая (например 400 MHz) а чип плотненько так упакован. Основная засада в такой ситуации в том что тяжело отслеживается в работе. Так что лучше double-перебдеть :) Тем более сейчас в Vivado можно "привязать" к модулю СDС файл constrain.tcl и в нем автоматом рассчитывать требуемые задержки в зависимости от частоты тактовых на пинах модуля. Успехов! Rob.
  12. Приветствую! Не совсем так - если клоковые домены объявлены асинхронными то при P&R время распространение сигнала между ними не проверяется никак, а значит и не гарнируется! Поэтому теоретически ничего не мешает трассировщику забубенить соединение с суммарной задержкой и 10 и 20 и все 50 нс (да еще и разные для разных бит) :( А сигнал валидности обычно задержан всего на 2-4 такта тактовой назначение Поэтому чтобы быть уверенным что задержка распространения меньше чем задержка valid и нужно задавать max_delay для таких сигналов (равно как для cdc перехода valid). Удачи! Rob.
  13. Приветствую! Ругань на не объявленный сигнал при компиляции в verilog можно включить прямо в исходник `default_nettype none module blablabla #( ... ... endmodule `default_nettype wire Удачи! Rob.
  14. Приветствую! Вопрос слишком общий - в старой системе 2x Xeon, 64GByte, cсервер, 2x 2x10G Ethernet, 2x raid контроллера- 36x 256GB SSD диска. Сейчас можно было все на PCIe SSD сделать было бы проще. Это если делать все на "коммерческом" железе. Сколько это стоит можно прикинуть по прайсам в инете. Удачи! Rob.
  15. Приветствую! Да это немного заметно :) Успехов! Rob.