Всем привет. Наконец то запустил LwIP на микроблайзе в спартане 6. Микроблайз работает на 100 МГц, мак контроллер МАК - лите, физика гигабитная, но зарезана на 100 МБит.

У меня получилось передача по ТСР со скоростью 15 Мбит. Это если слать с компьютера большой файл пакетами по 5000 байт. Если пакеты длинные (10-50Кбайт), то скорость падает до 7 МБит, а если коротенькими пакетиками то скорость падает до каких то очень мизирных значений. Шлю из C# через TcpClient. В Спартане реализован эхо сервер, шлю пакет потом принимаю его обратно, считаю время между отправкой и приемом. Также время смотрел в wireshark, там отмечается время когда прошел пакет в плис, и когда пошел обратно АКК. Скорость 15 МБит - реальность

Я так понимаю что основной затык в ядре микроблайз, LwIP работает из DDR, потому что после того как я его подключил проект вырос до каких то неприличных 120 КБайт, и во внутреннюю память не влез. DDR не двух портовый, а данные и программа лежат в одной памяти, кеши все включил, но lwIP активно создает буфера в куче.

Собственно вопрос что надо сделать чтобы получить те данные что заявлены в описании LwIP для мак лите, а именно 50 Мбит прием, 38 Мбит передача?

Разобраться где потери.

Спасибо капитан очевидность.

Вопрос к тем кто уже разбирался)... где же потери то?

Может пакет сильно фрагментированным приходит.

1514 байт по данным ваершарка.

на самом деле я думаю все затыки где то рядом с ядром, то есть не МАК контроллер, а уже именно LwIP, и то что все из DDR работает. Так ли это? Будет ли быстрее если в рам перепихать, как перепихать в рам. Можно что-то сделать с ЛвИП чтобы он перестал создавать и уничтожать буферы и так далее...

Там помнится у ЛвИП настроек дофига. Если DDR имеется, то может ему буфера поувеличивать?

Потому я и спрашиваю кто это делал.

Я уже крутил настройки исходя из смысла этих настроек по описанию, но 15 мегобит край! Вот хочу знать был ли кто кто получил обещанные 50, и что он для этого сделал... может он стек порезал, чтобы он в рам влез...

Может тогда микроблейзу настройки крутить. Я lwIP на AVR32 крутил. Помню что приличную скорость я на UDP получил.

Я делал Начните с xapp1026, цифры, что там заявлены, вполне соответствуют реальности. Вот прям возьмите последний (в предыдущем была ошибка в обработке таймеров lwip) xapp1026 и запустите на своей плате, а потом iperf. Это будет максимальный идеал, к чему стремиться.

Какое ядро для ethernet используете? на axi или plb? с FIFO или DMA? Без DMA большой скорости не ждите.
Про урезание lwip и запихивание в BRAM - это тупиковый путь, я как раз намучался с этим (не заложил на плату внешнюю память). Ethernet DMA может работать только с внешней памятью, а без DMA максимум мне удалось выжать 50 МБит на передачу при отправке заранее сформированного пакета (как в iperf) и 35 с подготовкой пакета между передачей.

я начал с MACLite без дма, без фифо, на акси лайте
получил 15 МБит, а в мануале обещали 50,
Я подумал может проблемка в том что все крутиться из ДДР. Но если путь тупиковый то ходить по нему и не буду...

Теперь я хотел сделать МАК ембендет АПИ, и фифо.

В ДМА меня беспокоит такой момент, у меня память в кешируемом пространстве, и я вообще не понимаю как если ДМА будет в нее писать, да еще под управлением ЛвИП, как получать актуальные данные? Отключать кэш данных? Или ДМА умеет через кэш писать? Вряд ли кэш внутри проца, а ДМА внешний модуль...

И я еще не очень понимаю как оно все в целом в ДДР быстро работает? ведь считай в одну память все лезет, и программа, и стэк ЛвИП, и ДМА?...




Перечитал Хапп, блин у меня и близко нет таких характеристик как у них... 37 Мб, 52 Мб, ну хорошо они это делают с зеро-копи пбуфом, и что не использование этого уронит скорость в 2 раза, а то и 3? В чем то еще подвох...

в общем случае, Xil_DCacheInvalidateRange (data, length). Но, если не ошибаюсь, в lwip это и так делается.



Посмотрите настройки lwip из xapp - количество и размер pbuf, размер send_buf, размер окна прежде всего.
А копирование очень сильно режет скорость. Может и не в 2 раза, но в полтора точно.

И ещё настройки микроблейза тоже стоит проверить, размер кэша очень сильно влияет на скорость передачи. И размер фифо у самого TEMAС.

Спасибо погляжу.

Про инвалидате кэша это понятно, но будет ли тогда он него хоть какой то бонус? Надо проверить делает ли LwIP его, хорошо если делает, не получу бонус в езернете, так в другом останется...

Вот поднял гигабитный езернет, с расчетом контрольных сумм внутри модуля, с ДМА, и че?
24 мегабита на пакета от 2000 до 5000 байт.
пакеты 50 000 байт дают 9 мегабит
а 1500 и меньше дают вообще какие то копейки.

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

с 100 м бит перешел на гигабит и вместо 15 получил 24... что-то явно не так...

правильно я понимаю что если уже все работает, хоть как-то, то констрайны плисовые уже не причем?

Вот что меня еще беспокоит.
По протоколу ТСР каждый переданный пакет длинной от 46 до 1500 байт должен сопровождаться Акнолиджем что типа принял. И получается что я могу раздувать буферы внутри сколько хочу, вместе с ДМА и прочим, но больше чем 1500 байт не обработается... Со всеми вытекающими, проч то микроблайз на 100 мегагерцах пыхтит всего лишь...

В армах, в кайловском стеке, есть фишка отучить ждать подтверждение, а ЛвИП в плисине можно такое научить? Как бы режим отложенного подтверждения? А будет ли это удовлетворять протоколу? Не будет ли проблем в сети?

Да, правильно.


Отдельной настройки нет. Это разруливается на уровне LWIP, ЕМНИП, при скоростях выше 30 Мбит пакеты начинают отсылаться через [PSH, ACK]

Ещё раз настоятельно советую не искать проблему наощупь. Слишком много факторов, влиящих на скорость - как настройки железа, так и настройки lwip и код работы с ним (в частности, обработка таймеров). Скачайте проект xapp1026 c максимальным кэшем, подправьте ucf и настройки памяти под свою плату, а потом запустите iperf. И если цифры совпадут с заявленными, то будет понятно, что с платой и окружением всё ок. А дальше можно ковыряться в настройках своего проекта, используя этот в качестве образца.

То есть LWiP сам переходит на отложенное подтверждение? прикольно...

Обнаружил что если во время приема-передачи выдернуть сетевой шнур и вставить обратно, схема входит в безответный режим. Время от вермени пытается ретрансмитнуть старый пакет, но новый АРП запросы, пинги и прочее уже не принимает... Даже когда закончила ретрансмитить старый пакет, все равно пингов и прочего не появилось...

Как с этим бороться по уму? Проверять активность канала и рессетить его если что?

Вообще есть какие то общие меры обеспечения жизни канала? или в ТСР они встроенные и все настроив все будет хорошо?

Из опыта: DDR тут практически не влияет если кеш работает. Я у себя в системе добавлял block ram для данных с критическим временем доступа - никакой заметной разницы (если нет других мастеров на шине, конечно).
В lwIP можно попробовать использовать memory pool - в одним из проектов очень помогло.
100MHz microblaze - очень не мало. Например 100Мбит трафик, пакеты по 1500 байт - всего около 8000 пакетов в секунду, совсем ничего. Надо искать где задержка (а для TCP именно она как правило ограничивает скорость). Проверенный метод - дергать GPIO и измерять время на осциллографе.

Угу. Идея замечательная. И никакой фрагментации памяти.

Если в ддр только данные, то да он быстрее проца. Но тут программа и данные, сразу и инструкции в большее число тактов, шины то 2 данных и инструкций, а ддр то одна(может правда на разные банки развести...). Данные и инструкции в разных местах, тут только кэш и спасает. Но теперь еще и езернет по дма+лвип в тот же ддр ломиться. В этом есть проблема.

Мемори пул это как? Если для буферов тср, то на хилых они уже пулом.


Поборюсь за живучесть стека, а потом создам прожку записи- чтения памяти, а там поглядим....
К 8000 пакетов добавьте контрольные суммы, парсинг, раскладку в памяти и уже не мало....

А может чтобы исключить задержки подтверждения и остальную TCP лабуду просто погонять UDP и померить скорость?
Если устроит - копать именно в TCP приблудах, а если нет - то "дело даже не в бобине"...

Мне кажется вы недооцениваете DDR, 333MHz/DDR/8b -> 5Gbps, для такой задачи вполне достаточно. Что касается DMA, то самописный AXI мастер (думаю далеко не лучший) справлялся в 5мкс для 1500-байтного пакета при частоте шины 50МГц.



у lwIP все выделения памяти идут через свой аллокатор из собственной "песочницы". Аллокатор может быть malloc-like либо pool-based. Второй несколько быстрее ценой менее эффективного использования памяти.
Кстати если включить внутреннюю проверку целостности памяти - очень замедляет работу lwIP.

Вот кручу кэши,

Кэш данные на 2 Бандка ДДР(адреса), 64 кбайта, 8 словная строка, все включить кроме тагов в дистрибутед рам, виктим 8, 32 битная шина данных

Кэш инструкций на 2 банка ДДР (адреса), 64 кбайта, 8 словная строка, все включить кроме тагов в дистрибутед рам, виктим 8, 32 битные данные.

В такой конфигурации включение кеша данных проходит.
А включение кеша инструкций вызывает повисание программы... И что я сделал не так не понятно... Перед включением кеши пробовал инвалидайтить, не помогает... что не так не пойму...

тестовый пример от тренца
32 кбайта кеши и на 1 банк ДДР, это принципиально?



это про ЛвИП в целом или именно про тот что отбиблиотечен ксалинксом? Потому что таких настроек я что-то не нахожу....

У меня кеши по 8кб, line size 4, что такое банк ДДР - честно не знаю.


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

А что за плисины, какие частоты и сколько они в итоге выдают? Какая скорость езернета?

Не знаю поможет ли вам, т.к. проект специфический - обработка пакетов идет в самописном блоке подключенном прямо к МАС, но при этом каждый пакет записывается в ДДР и через некоторое время читается обратно. Также каждый пакет вызывает прерывание, но microblaze не анализирует содержимое пакетов. lwIP передаются только "приблудные" пакеты (ARP, ICMP...).
S6, speedgrade -2, частота шины 50МГц, до около 800Мбит проблем не было.

Что еще можно посмотреть: т.к. lwIP активно использует таймеры и потоки, то разрешение системного таймера и алгоритм планировщика могут сильно влиять. У наблюдалось изменение времени пинга на порядок.

я без операционки...

А почему частота системной шины 50?

На самом деле там две шины - AXI - память, и AXI lite - регистры периферии. Изначально было 100 и 50. Но т.к. в своем блоке не хотелось связываться с разными клоками - было принято решение выбрать один клок для всей системы. Выбор 100 привел бы ненужному усложнению AXI Lite - а он большой (много периферии) и ничего не делает. И поскольку 50 хватает для данной задачи - выбрали 50.

Мне как раз интересно зачем делают шину АХИ лайт 50, почему не 100? Есть где то какие то описания? Есть какие то ограничения?

Просто у меня проект с 64 Кбайт кэша так и не запустился, падает после подключения кеша инструкций. С 32 Кбайтами кэша работает. Вот думаю может работает на переделе, и чуть увеличу нагрузку начнет сбоить... Не понимаю ни как проверить, ни как обеспечить запас...

Потому, что не нужно . Через AXI lite в типичных системах доступны регистры периферии операции с которыми сравнительно редкие. Также стоит учесть что, как правило, единственный мастер на шине - микроблейз, транзакции генерируются программно - например *(uint32_t* GPIO_REG_ADDR) = val; - и процессор просто не состоянии ее загрузить.
Можно и 100 - но тогда больше вероятность (зависит от чипа и от размера проекта), что не сойдутся тайминги и придется добавлять промежуточные регистры (FULLY_REGISTERED или LIGHT_WEIGT вместо BYPASS) - а оно надо? Да и потребляет больше на 100.
Кстати о таймингах - в процессе синтеза они анализируются для наихудшего случая (температура 85 и минимальное напряжения питания). Так что описанные симптомы указывают что таки не сошлись, а вы не заметили, либо внешние условия совсем плохи (напряжение питания, целостность сигналов).

P.S. Если нужно только мигать LED раз в секунду - можно частоту шины установить 5Гц (насколько я помню одна транзакция столько около 5 тактов занимает) - и тогда в программе вообще не придется задержек делать - процессор 99.999999% времени будет в состоянии ожидания.

P.P.S. Мне показалось у AXI-based систем довольно крутой "порог вхождения", приходилось и документацию от ARM читать (AXI = AMBA) и с ChipScope ночами сиживать... Зато потом - sky is the limit

Я планировал через акси лайт набивать фифо модуля, который потом будет данные наружу синхронно пихать по нескольким каналам. Но в целом и 50МГц мне подойдет...

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

Тайминги я не то чтобы не заметил Я просто даже не уверен что знаю где смотреть. Я в микроблайзе ваще по нулям и плисинами давно не занимался, а еще все так поменялось пока я армами занимался... Был уверен что если частота задана, клок визард все клоки создал, то процессор просто не соберется если что-то не так с таймингами... Где посмотреть? Подскажите пожалуйста.

У меня питальник всего 800 мА на 12 вольт. Вроде бы в стандартном варианте плисинка жрет по 12 вольтам (ну понятно что до плисины куча регуляторов и преобразователей) около 300 мА, и я думал что это с запасиком... Но регистры я добавил на шину что на память идет, это мне позволило стабильно запускать проект с 32 КБайтами кеша, хотя среда говорила что никаких бонусов не будет, и предлагала Light Wight вместо Full registered, но я не пошел на поводу... а вот 64 КБайта так и не пустились.....

последние про порог вхождения если честно я ваще не понял... типа трудно разобраться, но потом быстро поедем? Меня не покидает чувство какого-то наколеночного продукта если честно. Проц - это проц, он сделан, описан, оттестирован, а тут шуршал шуршал, что-то собрал, оно как-то завелось, а вот как хрен знает... Все время сижу и думаю вот оно сейчас работает, а завтра? А если дождь пойдет?

Если предположить, что транзакция записи на AXI Lite занимает 4 такта (не помню точно протокола), процессор работает на 100МГц, а шина на 50 - то после каждой операции записи процессор будет ждать 8 своих тактов (4 такта шины) в идеальном случае.
Учитывайте при разработке архитектуры.

нет

Повиснете в любом случае:



Да

Да, но вы собираете SoC - проц в которой один из элементов, прочем далеко не самый сложный. Тот же tri-mode ethernet сложнее.
И то, что проц работает никак не значит что вся система будет работать.

А где времянку глянуть, это чей отчет? в суммари должно быть?


если виснет при обмене, не буду пока шину снижать по частоте...


хороший проц готовый имеет и периферию так же оттестированную


В этом отношении мне все больше начинает нравиться цинк по своей идее...

Периферия годная и оттестированная. А вот как вы все вместе будете собирать на неизвестном железе - не знает никто, следовательно никто и не может гарантировать что будет работать вот так сразу.
Что качается Zynq - чип хороший, нет слов. Если подходит под задачу и бюджет. Там всю интеграцию сделали за вас. А вот если не подходит - увы, кушайте что дают.

с цинком не было готового модуля, а с разводкой ДДР3 не хотели возиться. Потому мучаю спартан.

Посмотрел суммари нашел что дебуг модуль имеет максимальный делай 9.96 , это на грани 100 МГц. А вот может ли мне как помешать этот дебуг модуль? Еще у меня полные не понятки с констрайнами, можно ли через system.ucf нарулить так чтобы кэш работал или нет? То есть может у меня не хватать какого то констрайна, который бы гарантировал сборку проца с лучшими характеристиками? Или на спартане 6-45 надо смириться, и считать что кэш 64 не для него.

Мне не нужен кэш 64, я просто хочу понять все ли я сделал для того, чтобы потом не вылезли проблемы? Ведь если с 64 кэшем не запускается, значит что-то еще не так.. или это уже ограничение спартана?

Zynq и microblaze по вычислительной мощности как BMW и велосипед. Если вам все равно что использовать - трудно комментировать. Ну, купите может zedboard - всяко дешевле чем самому разводить
Со свой стороны могу на выходных в нашем проекте на S6-45 сделать кеш 64к и посмотреть что получится. Но глубокого анализа не обещаю, на уровне работает/не работает.

Буду благодарен если попробуете, кэш данных и инструкци по 64 КБайта, 8 словный кэш, виктим кэеш тоже на полную, стрим кэш. Вообщем все галочки включить, все ползунки на максимум...


в нашем проекте конечная стоимость продукта весьма высока, а серия не велика, так что нет смысла в экономии на железе... А вычислительные мощности решаются стационарным компьютером. От плисины требуется удобство и гибкость. Спартан в целом подходит, но уже без запаса. Цинк с сильным запасом, можно позволить себе иногда халатное программирование без мыслей об оптимизации и так далее... Но это должен быть продукт, а не стартер кит. Старкиты нельзя ставить в прибор, они меняются, перестают делаться и так далее, заимеешся с поддержкой потом, все же серия малая, но серия...

Так что поедем пока на велике, но будем думать о БМВ...

Синтезировал согласно вашим пожеланиям - все работает. Трудно сказать быстрее или нет (нет объективных тестов), но стабильно.

Спасибо большое!

у меня отличие что виктим и врайт бак еще в кеше данных, и ДДР у меня 2 микрушки. То есть адресное пространство пошире.
А какие частоты на шинах и у ядра? и какаой спартанчик? А какие шины зарегистерены?

Странно почему же мой спартан не работает? Хотя я замечал что без регистров 1 банк ДДР работает, а 2 перестает. Наверное все уже на грани, чуть добавил еще один модуль управления ДДР и усе перегрелось...

6S45-3, AXI (та, на которой DDR) - 100MHz, AXI Lite - 50MHz, Microblaze - 100MHz, DDR - 300MHz, на AXI все FULLY_REGISTERED, на AXI Lite - LIGHT_WEIGHT.
А перегрелось - вряд ли, у них рабочая температура до 85. Скорее из-за нагрева тайминги поплыли - ну, на одно выходит.

А какие то особенные констрайны были?

Вручную ничего не дописывал.

то есть system.ucf вообще пуст? или он каким то визардом создан?

Если без пинов, то все что осталось

угум спасибо. Это успокаивает, я все думал может там чего не дописал. С примером шел могучий констраин, но я так понимаю он больше для симулятора, и я все переживал может чего не дописал.

Вообще говоря могучий констрейн на ddr нужен, и совсем не только для симуляции. Как его правильно прописать есть в доке на ddr. Он реально большой и могучий

Да и на Ethernet тоже - но их визарды прописывают в отдельных файлах.

про ДДР понятно, иначе оно и работать не будет. Там к блокам визард сделал констрайны, он их даже менять не разрешает, так что их не обсуждаем. Вопрос именно в юзер констрайне.

У меня там были всякие сопряжения частоты и шин, типа такого


# TNM_NET clk_gtx is */GTX_CLK
# TIMESPECs for AXI Streaming clock crossing to/from */GTX_CLK
TIMESPEC "TS_axistreamclks_2_GTX_CLK" = FROM axistream_clk TO clk_gtx 8000 ps DATAPATHONLY; #assumes clk_gtx <= 125 MHz
TIMESPEC "TS_GTX_CLK_2_axistreamclks" = FROM clk_gtx TO axistream_clk 10000 ps DATAPATHONLY; #assumes axistream_clk <= 100 MHz
# TIMESPECs for AXI-Lite clock crossing to/from */GTX_CLK
TIMESPEC "TS_axi4lite_clk_2_GTX_CLK" = FROM axi4lite_clk TO clk_gtx 8000 ps DATAPATHONLY; #assumes clk_gtx <= 125 MHz
TIMESPEC "TS_GTX_CLK_2_axi4lite_clk" = FROM clk_gtx TO axi4lite_clk 10000 ps DATAPATHONLY; #assumes axi4lite_clk <= 100 MHz

на многое среда в итоге ругнулась и не захотела применять... и уж не знаю что с этим делать...

Насколько я помню архитектуру стандартной системы - GTX_CLK - для tri-mode ethernet.

это маленький кусок.
Там акси и акси лайт
акси лайт и езернет
акси и езернет,

все шины друг к другу с такими описаниями сопрягались. А вот для чего они я не бум бум...