[Aleksey25 0]

Здравствуйте!

Подскажите, пожалуйста, хорошие примеры или литературу по реализации UDP/IP.

Хочу реализовать передачу данных по Ethernet на FPGA GOWIN. MAC хочу использовать библиотечный Triple Speed Ethernet MAC.

А вот разработка UDP вызывает трудности.

 

Заранее спасибо!

[Raven 9]

2 hours ago, Aleksey25 said:

Хочу реализовать передачу данных по Ethernet на FPGA GOWIN. MAC хочу использовать библиотечный Triple Speed Ethernet MAC.

Давайте уточним: вы хотите реализовать поддержку UDP/IP именно в виде чистого HW, т.е., в виде конечных автоматов? Программируемая составляющая (SW) не входит в ваши планы?

[Aleksey25 0]

1 час назад, Raven сказал:

Давайте уточним: вы хотите реализовать поддержку UDP/IP именно в виде чистого HW, т.е., в виде конечных автоматов? Программируемая составляющая (SW) не входит в ваши планы?

Да, хочу попробовать именно HW.

[Arlleex 154]

А разве реализовывать стек протоколов на FPGA - это норма? Максимум что я бы оставил за FPGA-частью, это то, чего не доделал GOWIN в MAC (если такое есть, а оно обязательно найдется). А помимо UDP для сети надо поднимать еще несколько промежуточных протоколов. Изучать можно где угодно - хоть по википедии.

[BSACPLD 14]

2 hours ago, Aleksey25 said:

Да, хочу попробовать именно HW.

Чисто HW это лишнее усложнение и трата ресурсов.

Вам как минимум нужно: ARP, ICMP, UDP.

Я когда свою видеокамеру делал, реализовал комбинированный вариант - фильтр MAC HW, маршрутизация UDP HW, всё что прошло фильтр, но не прошло в UDP HW обрабатывалось на встроенном софт-процессоре RISC-V (PicoRV32).

И то даже в таком комбинированном виде это занимало довольно прилично как Slice, так и BRAM.

Чисто HW это монстр будет с точки зрения потребления ресурсов.

Не говоря уже про сложности с отладкой.

[Ivanii 2]

На сколько я знаю даже в коммутаторах/маршрутизаторах управляемых и сложнее L2 пакет не попавший под текущие правила в матрице попадает в проц и в матрицу пишутся правила для него процом, сразу аппаратно не делают из за большой вариативности.

С другой стороны прием/передача ARP и IP-UDP не сложны и их можно реализовать в железе, с IP-TCP-DHCP будет сложнее.

[_4afc_ 25]

10 minutes ago, BSACPLD said:

Вам как минимум нужно: ARP, ICMP, UDP.

Делал на си автомат который разбирал ethernet на ARP/UDP/TCP ничего сложного чтоб написать на верилоге. Структура простая, нужно лишь контрольные суммы считать. 

[RobFPGA 28]

18 hours ago, BSACPLD said:

Чисто HW это лишнее усложнение и трата ресурсов.

А с другой стороны  городить целый soft-CPU  вместо пары-тройки простых автоматов. 
UDP с сопутствующими сервисами (ARP, ICMP) поднимается в HW несложно. Причём сложность и ресурсы зависит в основном от на сколько правильно и полно вы хотите все это делать. 

Для примера реализации можно посмотреть на стек у  Аlex Forencich,  где все сделано по классике, с чётким разделением по уровням стека.  

[Aleksey25 0]

13 часов назад, Arlleex сказал:

А разве реализовывать стек протоколов на FPGA - это норма? Максимум что я бы оставил за FPGA-частью, это то, чего не доделал GOWIN в MAC (если такое есть, а оно обязательно найдется). А помимо UDP для сети надо поднимать еще несколько промежуточных протоколов. Изучать можно где угодно - хоть по википедии.

Если взять за основу статью "Построение Ethernet-контроллера на ПЛИС" Алексея Пашинова, и на сколько я разобрался в Triple Speed Ethernet MAC, то GOWIN сделал: само MAC ядро, MAC Transmit, MAC Receive. В статье указывается, что UDP/IP был взят с opencores, но я пока не нашел именно тот, который указывает автор статьи.

11 часов назад, Ivanii сказал:

На сколько я знаю даже в коммутаторах/маршрутизаторах управляемых и сложнее L2 пакет не попавший под текущие правила в матрице попадает в проц и в матрицу пишутся правила для него процом, сразу аппаратно не делают из за большой вариативности.

С другой стороны прием/передача ARP и IP-UDP не сложны и их можно реализовать в железе, с IP-TCP-DHCP будет сложнее.

На данном этапе,  хочу сделать только прием/передачу ARP и UDP/IP

9 часов назад, RobFPGA сказал:

А с другой стороны  городить целый soft-CPU  вместо пары-тройки простых автоматов. 
UDP с сопутствующими сервисами (ARP, ICMP) поднимается в HW несложно. Причем сложность и ресурсы зависит в основном от на сколько правильно и полно вы хотите все это делать. 

Для примера релизации можно посмотреть на стек у  Аlex Forencich,  где все сделанно по классике, с четким разделением по уровням стека.  

У Аlex Forencich хорошая библиотека для Гигабитных сетей, в моем распоряжении PHY только на 100MBit. Но рассмотреть Аlex Forencich как пример стоит, согласен.

[Arlleex 154]

https://ru.wikipedia.org/wiki/ARP

https://ru.wikipedia.org/wiki/UDP

ICMP не обязательно.

[Aleksey25 0]

4 минуты назад, Arlleex сказал:

https://ru.wikipedia.org/wiki/ARP

https://ru.wikipedia.org/wiki/UDP

ICMP не обязательно.

Спасибо!

[fguy 5]

13 часов назад, BSACPLD сказал:

Вам как минимум нужно: ARP, ICMP, UDP.

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

[Arlleex 154]

28 минут назад, fguy сказал:

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

MAC назначения знать нужно, поэтому ARP как минимум обязателен. Если хочется схалтурить и слать не юникастом, то можно слать бродкастом, тогда ARP тоже можно выкинуть.

[fguy 5]

7 минут назад, Arlleex сказал:

MAC назначения знать нужно, поэтому ARP как минимум обязателен.

В том и фокус что для мультикаста мас назначения знать не нужно, а из "плюсов" мультикаст можно смотреть на нескольких пк одновременно, ну и из "минусов" он не проходит через радиоканал - его банят вай-фай роутеры и прочие мосты - в таком случае спасает уникаст. Для уникаста арп то же не обязателен - вы заранее узнаете мас назначения и пишите его в ядро. Для реализации обоих вариантов нужно иметь возможность задавать ядру формирующему пакеты MAC, IP адрес и порт для src и dst.

[Ivanii 2]

Свой МАК всегда вносить вручную.

Если отказываться от DHCP то не делать IP-TCP, DHCP и вносить "вручную" IP, маску и шлюз.

Если отказываться от ARP то не делать сам ARP и дополнительно вносить "вручную" МАКи всем устройствам связанным с ПЛИС(в т.ч. роутеру) и ПЛИС.

Если отказаться от маршрутизации то можно использовать голый эзернет, ARP, IP и UDP тоже не нужны. 

С мультикастом/броадкастом нужно заморачиваться сетевой инфраструктурой(предполагаются 100+ Мб/с потоки данных).

 

Тут https://habr.com/ru/articles/308636/ есть наглядно поля пакетов.