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

RobFPGA

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

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

  • Посещение

Репутация

0 Обычный

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

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

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

9 372 просмотра профиля
  1. Приветствую! Увы иногда просто некогда - да и о чем тут дискутировать? Смотрим в папочку $::env(QUARTUS_ROOTDIR)/../ip/altera/alt_mem_if/.. Выбираем папку ../alt_mem_if_controllers/alt_mem_if_*_controller нужного типа контроллера и смотрим в ней его открытые исходники. Аналогично смотрим модели памяти из ./alt_mem_if_mem_models и phy интерфейсы из ./alt_mem_if_phys/ Никто не мешает скомпилировать все это добро сразу vlib ./libs/ddr2 vmap ddr2 ./libs/ddr2 ... vlog -work ddr2 $::env(QUARTUS_ROOTDIR)/../ip/altera/alt_mem_if/alt_mem_if_controllers/alt_mem_if_ddr2_controller/*.v vlog -sv -work ddr2 $::env(QUARTUS_ROOTDIR)/../ip/altera/alt_mem_if/alt_mem_if_controllers/alt_mem_if_ddr2_controller/alt_mem_if_ddr2_controller_top.sv ... vsim -L ddr2 ... your_ddr2_tb Ну и естественно не забыв про свой тестбенчь попытаться взлететь в симе со всем этим добром :) Успехов! Rob.
  2. Приветствую! А в чем проблема? И DDR, и PCIe и всякие интерфейсы с MGT - разницы в процессе симуляции по сравнению с сумматором на 3 бита почти никакой - за исключением длительности времени симуляции ;) Удачи! Rob.
  3. Приветствую! Скорее всего дело не в описании сумматора (тут вроде все правильно с точки зрения логики сумматора) - а в реализации этой схемы в FPGA. Может быть у вас неправильно назначен пин для кнопки/led, или неучтенный инвертор где-то затесался. Без всей картины получившейся схемы после синтеза и PR тяжело понять как выглядет этот "слон". Удачи! Rob.
  4. Приветствую! В FPGA ваше условие не выполнить - типичное время задержки на входных - выходных пинах ~3-5 ns, плюс задержки на роутинг и комутацию - так что задержки вряд ли будут < 8-10 ns. Удачи! Rob.
  5. Здравствуйте! не подскажете пожалуйста материал по акси интерфейсу с нормальными временными диаграммами? я вот пока ищу, но как оказалось это не так просто, у ксайлинкса их нет, я так понял надо у arm искать, но все что я пока нашел - это не то что хотелось бы=/. Я просто решил попользовать прегенерируемый код вивадо(акси мастер) - он вроде работает, поменял ширину шины на 512 бит и выставил величину берстов до 128 и наблюдаю, что промежутки между берстами уж слишком большие - приводят к понижению пропускной способности в 2 раза(миг на входе 512 бит и соответственно мастер под него я делаю 512 бит, соединены через акси интерконнект), все что я вижу - это то что акси интерконнект сигнал bvalid выставляет поздно, после этого начинается новый берст, но чтоб разобраться, нужно все таки изучить акси стандарт

    Извините что пишу в личные сообщения, показалось, что так проще будет

    1. Показать предыдущие комментарии  Ещё #
    2. Lutovid

      Lutovid

      Спасибо! буду изучать референс. Для меня не понятным является тот факт, что когда я завершаю транзакцию(то есть берст в моем случае), та нога, которая является статусом выполнения транзакции, как вы написали, поднимается через большой промежуток времени. Не понятно что интерконнект все это время делает=/. Пропускная способность слэйва позволяет гнать хоть непрерывный поток... Для моей задачи это прям очень критично, поэтому надо будет докапываться до истины.

    3. RobFPGA

      RobFPGA

      Приветствую!

      axi4_b* сигнализирует тогда когда транзакция записи пробежала весь путь от вас к памяти и обратно. Понятное дело что будет большой latency. Для ускорения как я и писал можно делать конвеер - генерируете новые транзакции на axi4_aw* и axi4_w* (или на axi4_ar*) не дожидаясь прихода статуса на axi4_b* (или прихода данных на axi4_r*). В настройках интерконекта есть параметр (write|read)issule который задает сколько транзакций может быть в "полете" у данного интерконнекта. Ну и ваш FSM фактически должен состоять из 3 - один генирирует запросы на шину axi4_aw* и на второй FSM, который шлет данные на axi4_w* и в конце бурста плюсует счетчик третьему FSM, который проверяет на axi4_b* что запись прошла. 

      Удачи! Rob.

    4. Lutovid

      Lutovid

      ааа, спасибо! теперья понял вас! Так и сделаю)

  6. Приветствую! Пропускная будет зависеть от конфигурации объединения адресного пространства Так как например можно распределять адреса между MIG малыми блоками (interlive) начиная от размера burst на шине. Тогда при потоковой записи/чтении пропускная может быть ~2 раза больше чем отдельный MIG. Естественно для этого intercinnect core должен быть как минимум в 2 раза шире чем MIG, ну или работать на >=2x кратной частоте. Ну а также и того как вы настроите interconnect (размеры burst, буферизация, число запросов на чтение/запись в конвеере). FSM Вам в любом случае придется делать. Почитайте описание на AXI_DataMover, и AXI_DMA. Первый легко цепляется к FSM, ну а второй (кстати сделан как раз на базе AXI_DataMover и FSM) более заточен на управление CPU. Удачи! Rob.
  7. Приветствую! Задачу надо решать поэтапно. Для начала - DMA никоим образом не относится к объединению шин. Затем надо уточнить как вам надо объединять вглубь или вширь? Ну а потом выбираете как вам проще будет это сделать - 1 воткнуть 2 MIG в AXI4 interconnect - плюшки: универсальная шина, встроенный СDC для master/slave портов, Для реализации чтения/записи можно использовать готовые блоки (AXI_DataMover, AXI_DMA, ...) 2 Сделать свой CDC на fifo для каждого MIG, а потом уже объединять на своей fsm. плюшки: все свое, родное! Ни на что не похожее :) Имхо - первый вариант предпочтителен Удачи! Rob.
  8. Приветствую! Нее - так далеко от родного дома я еще на уехал :) Удачи! Rob.
  9. Приветствую! Собственно subj. Озадачили меня вот. :cranky: Есть некая реализация TCP/IP покрытая неким подобием функциональных тестов. И надо бы проверить на соответствие всяким RFC. Понятное дело можно учитаться спецификациями вусмерть (и кажется мне этого не избежать). Но может есть что для более легкого старта - типа набора скриптов/сценариев покрывающих основные требования. Или библиотеки какие для генерации пакетов по таким сценариям. Чтобы можно было их например прикрутить их через DPI к симулятору. В общем пытаюсь схалявить набрать крит. массу информации для осознания глубины проблемы. Удачи! Rob.
  10. FMC122P - PCI Express v3.0 x16

    Приветствую! Теперь понятно почему Biosы такие корявые ;) При энумерации шины сначала получают хотелки для всех BAR всех endpoint устройств. Распределяют эти хотелки в наличные адреса и только потом программируют BARы на распределенные диапазоны адресов. При сложной структуре шины со многими сегментами это все делается иерархически от дальних endpoind к root-complex. Удачи! Rob.
  11. FMC122P - PCI Express v3.0 x16

    Приветствую! Ну все зависит от типа процессора - теоритически у x86 можем имеем ~2^64 физ адресов ( 4GB * 4GB :wacko: ) Что то вы тут мудрите - при enumeration на PCIe сразу видно какой диапазон адресов хочет соответствующий BAR на устройстве - не надо ничего подбирать. К тому же ни кто не мешает выделить для BAR адреса > 4GB имея при этом системную памяти < 4GB. Это разные диапазоны адресов! Нет - их просто делают "как правильно" - не экономят :) Удачи! Rob.
  12. FMC122P - PCI Express v3.0 x16

    Приветствую! Это не память выделяется а только адресное пространство! Да и ведут себя так только "неправильные" биосы ;) - Был у меня знатный гемор с убитием материнок при попытке выделить 2..4 ГБ для BAR на PCIe устройстве. На "правильных" биосах в серверах все нормально выделяется. Удачи! Rob.
  13. Приветствую! Если по логике подходит то сделайте как функцию ... function logic simple_func (input logic var1); return ~var1; endtask ... VarC <= simple_func(VarA); ... Удачи! Rob.
  14. Приветствую! Да так и есть - все это TCL. Можно из скрипта генерировать динамически целые qsys модули в зависимости от параметров. Удобно еще то что можно собрать в библиотеку блоки кода для работы с часто используемыми шинами, блоками, ... и реюзать потом без лишней copy-paste. proc add_mm_ctrl_port {{name_bus "avmm_ctrl"} {name_port "avmm_ctrl"} {addr_wh 14} {name_clk ""} {name_rst ""}} { if {$name_clk==""} { set name_clk ${name_bus}_clk } if {$name_rst==""} { set name_rst ${name_bus}_rst } add_interface ${name_bus} avalon end set_interface_property ${name_bus} associatedClock ${name_clk} set_interface_property ${name_bus} associatedReset ${name_rst} ... add_interface_port ${name_bus} ${name_port}_waitrequest waitrequest Output 1 add_interface_port ${name_bus} ${name_port}_address address Input ${addr_wh} add_interface_port ${name_bus} ${name_port}_write write Input 1 add_interface_port ${name_bus} ${name_port}_writedata writedata Input 32 add_interface_port ${name_bus} ${name_port}_byteenable byteenable Input 4 add_interface_port ${name_bus} ${name_port}_read read Input 1 add_interface_port ${name_bus} ${name_port}_readdata readdata Output 32 add_interface_port ${name_bus} ${name_port}_readdatavalid readdatavalid Output 1 } ... add_mm_ctrl_port "dma_ctrl" "dma_ctrl" 14 "ctrl_clk" "ctrl_rst" ... Удачи! Rob.
  15. Приветствую! Эх молодежь ... "Линеально" не получится, ни как :( - это не известный науке закон управления ;) Если же вас устроит линейный закон то для начала надо вспомнить формулу частоты (что то типа F=1/T). А потом посмотреть куда попадает измеренное напряжение в эту формулу. И тогда стане ясно что делать чтобы получить требуемый закон. Хотя бесступенчато все равно не получится - увы мир изначально квантованный :) Успехов! Rob.