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

RobFPGA

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

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

  • Посещение

Репутация

0 Обычный

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

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

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

9 384 просмотра профиля
  1. Приветствую! Конечно тут все зависит от конфигурации сети. Если точка - точка или через хороший коммутатор и сетевые карты - то для радикального уменьшения потерь надо настраивать сетевухи для работа в режиме lostless - это типа xon|xoff - когда сетевуха видит что место в приемном буфере заканчивается то тормозит удаленный передатчик и тот ждет разрешения . Пакеты не теряются но естественно и скорость падает. Соответственно и на стороне FPGA это надо поддерживать. Отлаживалась кстати это сначала как раз на Win7. Если же сеть на noname мыльницах - то тут увы ничего не поможет. Так я и не говорил что без настройки - естественно пошаманили и с настройками стека и c прерываниями. Но все крутилось на стандартном стеке linux без новомодных DPDK и тому подобного. Даже 6 потоков в 10g принимали с трех 2-портовых 10G сетевух. Делалось это уже лет 5 назад. С тех времен это все еще проще стало. Успехов! Rob.
  2. Приветствую! Да нормально справляется, 2x 4-ядерных Хeon принимают и синхронизирует потоки, пишут на SSD raid, да еще и кой-какую обработку и статистику по потоку считают - для нынешнего железа это не проблема. По UDP бегают jumbo с payload 4-8K. Но это уже старая система - медленная ;) Удачи! Rob.
  3. Приветствую! Нет не путаю - 4 штуки 10G по UDP льют из FPGA общий поток параллельно. На приемной стороне все собирается опять в один поток. Успехов! Rob.
  4. Приветствую! Хотелось бы конкретики - что значит маловато, какая пропускная MB/s получается, сколько % теоретической пропускной. Какой у вас цикл чтения/записи на шине? Как адресация формируется? Все это влияет на пропускную и без должной оценки гнать частоту памяти смысла нет. Удачи! Rob.
  5. Приветствую! Понятное дело для UDP вообще все просто тем более если для собственного использования. У меня несколько таких систем работает с потоком 4-8 GByte/s. В ручную статически сконфигурил и льешь в сеть дер.данные, положив на всех большой и толстый 10G ;). Но для удобства все же нужен полный ICMP и DHCP. Либо полностью в железе, либо замыкать соответствующие пакеты через bypass софт стек. Чтобы вовремя реагировать если заказчик вдруг поменяв конфигурацию сети не удивлялся что за хренов трафик идет север по старому IP :) Удачи! Rob.
  6. Приветствую! Ну я частично тоже автор этой корки и от красивого сертификата не отказалcя бы ;) Который хоть и ни чем но иногда очень даже помогает ;) А критерий правильной работы понятие расплывчатое. Современный зоопарк сетевых решений это тот еще геморрой. И когда стоит задача не просто что-то и как-то передать а и гарантировать работу в разном окружении то приходится с этим зоопарком считаться. А то на тестовом стенде все работает пучком - а как заказчику поставишь начинается - "... Ай Ай Ай - ваша железка шлет кучу ретрансмитов! Почему? Срррочно исправьте! ..." И начинаешь разгребать гигабайты pcap файлов чтобы понять что не так и где именно - у меня или у заказчика в sw стеке или конфигурации. И хорошо когда эти pcap доступны, а бывает что и их не дают из за security policy :(. Удачи! Rob.
  7. Приветствую! С этим чудом я понемногу разбираюсь. Но как мне кажется там тесты просто проверяют основной функционал в идеальном варианте событий. Это как раз не сложно. Пока основной вопрос именно в сценариях ситуаций в которых надо бы проверить поведение корки. Успехов! Rob.
  8. Приветствую! Зачем же покупать то что уже есть? Вот того чего нет я бы прикупил если не дорого :) Удачи! Rob.
  9. Приветствую! Было бы проще если бы вы привели требуемую диаграмму сигналов (с временами) для управления памятью. Тогда станет проще понять как это можно сделать с минимальными затратами. Успехов! Rob.
  10. Приветствую! Увы иногда просто некогда - да и о чем тут дискутировать? Смотрим в папочку $::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.
  11. Приветствую! А в чем проблема? И DDR, и PCIe и всякие интерфейсы с MGT - разницы в процессе симуляции по сравнению с сумматором на 3 бита почти никакой - за исключением длительности времени симуляции ;) Удачи! Rob.
  12. Приветствую! Скорее всего дело не в описании сумматора (тут вроде все правильно с точки зрения логики сумматора) - а в реализации этой схемы в FPGA. Может быть у вас неправильно назначен пин для кнопки/led, или неучтенный инвертор где-то затесался. Без всей картины получившейся схемы после синтеза и PR тяжело понять как выглядет этот "слон". Удачи! Rob.
  13. Приветствую! В FPGA ваше условие не выполнить - типичное время задержки на входных - выходных пинах ~3-5 ns, плюс задержки на роутинг и комутацию - так что задержки вряд ли будут < 8-10 ns. Удачи! Rob.
  14. Здравствуйте! не подскажете пожалуйста материал по акси интерфейсу с нормальными временными диаграммами? я вот пока ищу, но как оказалось это не так просто, у ксайлинкса их нет, я так понял надо у 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

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

  15. Приветствую! Пропускная будет зависеть от конфигурации объединения адресного пространства Так как например можно распределять адреса между MIG малыми блоками (interlive) начиная от размера burst на шине. Тогда при потоковой записи/чтении пропускная может быть ~2 раза больше чем отдельный MIG. Естественно для этого intercinnect core должен быть как минимум в 2 раза шире чем MIG, ну или работать на >=2x кратной частоте. Ну а также и того как вы настроите interconnect (размеры burst, буферизация, число запросов на чтение/запись в конвеере). FSM Вам в любом случае придется делать. Почитайте описание на AXI_DataMover, и AXI_DMA. Первый легко цепляется к FSM, ну а второй (кстати сделан как раз на базе AXI_DataMover и FSM) более заточен на управление CPU. Удачи! Rob.