Gigabit Ethernet IP Опции

[robix]

Всем привет!
Есть задача реализовать Гигабитный ethernet на Cyclone III или IV.
Есть желание все это сделать на NIOS II. Вопросы:
1. кто нибудь пробовал на стандартных IP-корах езернета достигать 500 мбит в передаче?
2. каким образом езернет можно сопрягать с NIOS, не будет ли больших задержек!?

[vadimuzzz]

1. кто нибудь пробовал на стандартных IP-корах езернета достигать 500 мбит в передаче?

да, с использованием аппаратного ускорения UDP это вполне реально. у меня было порядка 600 в системе с ниосом практически без оптимизаций.

2. каким образом езернет можно сопрягать с NIOS, не будет ли больших задержек!?

в примерах посмотрите, можно на alterawiki.com. корка интегрируется в SOPC. у нее 1 интерфейс Avalon-MM для доступа к регистрам и 2 Avalon-ST (на прием и передачу). Avalon-ST подключаются к SGDMA. Большие задержки это сколько? В любом случае, это определяется главным образом контроллером прерываний, можно поставить внешний VIC.

[robix]

А можно точнее, что значит почти без оптимизаций? И где этот ускоритель UDP - в настройках тристате я его не нашел!?
То есть куда мне смотреть, что бы выжать это 600?

[vadimuzzz]

А можно точнее, что значит почти без оптимизаций?

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

И где этот ускоритель UDP - в настройках тристате я его не нашел!?

я брал отсюда
http://www.alterawiki.com/wiki/Nios_II_UDP_Offload_Example

[bark]

я достиг 982Mbit/s при выдаче UDP потока с девборды на комп.
проверка целостности данных по счетчки внутри пакетов.

без ниоса. всё руками.

[vadimuzzz]

без ниоса. всё руками.

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

[bark]

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

да.. поэтому есть желание сесть разобраться в ниосе. )

[robix]

Уважаемые коллеги, можно ли такое устройство " 982Mbit/s при выдаче UDP"
использовать с NIOS? Как его вообще можно использовать без NIOS если необходимо принимать команды с компьютера и обрабатывать их в плис, если нужно коммутировать потоки на гигабитный эзернет с разных входных блоков...
Неужели это все можно запрограммировать на verilog в разумные сроки? Я имею ввиду прикладной контроллер управления. Небось нужно убить кучу времени на отладку!? К тому же, одно дело автоматом генерить пакеты и другое дело загружать данные из другого блока, не упадет ли скорость передачи в этом случае!?

[bark]

Уважаемые коллеги, можно ли такое устройство " 982Mbit/s при выдаче UDP"
использовать с NIOS? Как его вообще можно использовать без NIOS если необходимо принимать команды с компьютера и обрабатывать их в плис, если нужно коммутировать потоки на гигабитный эзернет с разных входных блоков...
Неужели это все можно запрограммировать на verilog в разумные сроки? Я имею ввиду прикладной контроллер управления. Небось нужно убить кучу времени на отладку!? К тому же, одно дело автоматом генерить пакеты и другое дело загружать данные из другого блока, не упадет ли скорость передачи в этом случае!?

я начал работу с сетью во второй половине января. Тогда корки MACa ещё в глаза не видел, а о сетевый протоколах имел общее представление.
Avalon-ST и Avalon-MM в глаза не видел.
И вообще с девбордой впервые работал, так что нового было много.
в середине февраля у меня железяка уже работала с ARP и ICMP. Ещё через неделю заработал запрос/ответ по UDP.
сейчас уже есть система команд, управление внутренними регистрами, несколько портов для запросов и блок обработки приема/передачи данных с пакетами JUMBO до 7K. с расчетом чексумм.
удалённо доступны все параметры MAC/PHY. можно менять физический адрес, IP, задавать порты прослушки и выдачи.

UDP весьма прост. поэтому принимать и обрабатывать его проблем нет.
Вот с TCP уже сложнее. поэтому с ним лучше сразу браться за ниос.

по поводу можно ли всё это с НИОС... раз говорят что UDP можно аппаратно формировать - то вероятно можно.

Сообщение отредактировал bark - Mar 15 2011, 08:14

[Serhiy_UA]

NiosII не справится с UDP для сотен Mbit/s, это однозначно. Он своим софтом и три-четыре десятка Mbit/s тянет с трудом при внешнем аппаратном акселераторе для контрольных сумм.
Оптимальное решение для сотен Mbit/s здесь уже озвучено: слабые потоки TCP обрабатывать софтом на NiosII, а мощные потоки выдавать аппаратным UDP.
Только надо организовать мультиплексор для доступа к Ethernet между аппаратным UDP и NiosII, с приоритетом у NiosII (или нескольких NiosII).

[vadimuzzz]

NiosII не справится с UDP для сотен Mbit/s, это однозначно.

ниос тут ни при чем, его работа - сконфигурировать DMA и рулить прерываниями. готовые компоненты для SOPC есть, можно систему готовую за день поднять. ниос, раздающий 600 Мбит на пакетах 1024 байт - пройденный этап. если бы мне надо было больше, я бы пооптимизировал, там все прозрачно

[Serhiy_UA]

ниос тут ни при чем, его работа - сконфигурировать DMA и рулить прерываниями. готовые компоненты для SOPC есть, можно систему готовую за день поднять. ниос, раздающий 600 Мбит на пакетах 1024 байт - пройденный этап. если бы мне надо было больше, я бы пооптимизировал, там все прозрачно

У меня NiosII был сконфигурирован без DMA. Согласен, с DMA будет гораздо быстрее.
Но здесь еще пара аспектов по структуре:
1.Если используется готовый контроллер то DMA подходит, а если PHY то лучше синтезировать автомат UDP. Так ли?
2.При работе с DMA нужно работать с несколькими блоками памяти. Из одних выдавать по DMA, а в других тем временем подготавливать данные в соответствии со структурой текущего пакета. В автомате UDP для PHY это все можно делать конвейером, как бы на проходе. Какие были решения?

[vadimuzzz]

1.Если используется готовый контроллер то DMA подходит, а если PHY то лучше синтезировать автомат UDP. Так ли?

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

2.При работе с DMA нужно работать с несколькими блоками памяти. Из одних выдавать по DMA, а в других тем временем подготавливать данные в соответствии со структурой текущего пакета. В автомате UDP для PHY это все можно делать конвейером, как бы на проходе. Какие были решения?

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

[Serhiy_UA]

Спасибо, vadimuzzz, за соображения, они интересны...

другой источник лагов - убогий "родной" контроллер прерываний, лечится внешним. авалон - штука гибкая и масштабируемая, плата за это - оверхед по ресурсам.

"Родной" контроллер прерываний NiosII уже здесь обсуждали (осуждали), а о внешнем, ни разу не слышал. Если не обращать внимание на ресурсы, то, что это за вещь, какой получен выигрыш, есть ли цифры?

[vadimuzzz]

Если не обращать внимание на ресурсы, то, что это за вещь, какой получен выигрыш, есть ли цифры?

латентность по сравнению со штатным (у того может до сотни тактов доходить) сильно меньше - единицы тактов.
http://www.altera.com/literature/hb/nios2/..._controller.pdf