Cyclone + 2 GBEthernet, Создать рабочий проект Опции

[NIOSnew]

Доброго времени суток всем! Необходимо на DE2-115 c Cyclone и 2 88E1111 реализовать работу 2-х Gb Ethernet (TCP/IP). Есть сомнения, что указанное быстродействие может быть достигнуто. Кроме того, необходим ли только один процессор, или надо 2 (если это всё-таки реально)? Может ли кто-нибудь посоветовать, с чего начать? Проекты на основе примеров Alterы работают, но приспособить их для решения задачи не кажется реальным. Заранее спасибо!

[vadimuzzz]

Есть сомнения, что указанное быстродействие может быть достигнуто

может, в этом никаких сомнений

Кроме того, необходим ли только один процессор, или надо 2 (если это всё-таки реально)?

можно и 0, об этом ниже

но приспособить их для решения задачи не кажется реальным

реально, только надо разобраться,

а начать надо с самой задачи: что конкретно надо от системы?
1. процессор нужен только, если требуется TCP/IP. Для UDP это уже может оказаться излишеством. Количество CPU тут мало влияет, т.к. используется SGDMA,ядро только прерывания обрабатывает.
2. процессор удобен как средство настройки, но не необходим. можно сделать свой автомат, который будет рулить MAC.

[NIOSnew]

может, в этом никаких сомнений

а начать надо с самой задачи: что конкретно надо от системы?
1. процессор нужен только, если требуется TCP/IP. Для UDP это уже может оказаться излишеством. Количество CPU тут мало влияет, т.к. используется SGDMA,ядро только прерывания обрабатывает.
2. процессор удобен как средство настройки, но не необходим. можно сделать свой автомат, который будет рулить MAC.

Да, но кроме 2 Ethernet, буду использовать и другую периферию платы. 1 ядро сможет всё обработать?
Хватит ли только МАС при этих условиях?
Большое Вам спасибо за внимание и вселённый оптимизм!

[vadimuzzz]

1 ядро сможет всё обработать?

все зависит от того, что вы понимаете под "обработать". в правильно спроектированной системе ядро не занимается тупой работой, которую можно вынести в соотв. модуль (типа контроллера SGDMA). например, подсчет crc-32 для фрейма: можно на ядре, а можно на самом MAC. думаю, не надо пояснять, что быстрее. фактически, ядро должно заниматься обработкой прерываний и тем, что невыгодно выносить в железо (либо не требуется высокая скорость). выше я приводил пример с TCP/IP. в качестве примера: можно на одном ядре сделать что-нибудь типа IP-камеры. управление будет через TCP/IP, а трафик пойдет по UDP. вполне реально иметь порядка 800-900 мбит/с трафика, при этом само ядро работает, скажем, от 50 МГц.

[NIOSnew]

в правильно спроектированной системе ядро не занимается тупой работой, которую можно вынести в соотв. модуль (типа контроллера SGDMA). .. можно на ядре, а можно на самом MAC. думаю, не надо пояснять, что быстрее. фактически, ядро должно заниматься обработкой прерываний и тем, что невыгодно выносить в железо (либо не требуется высокая скорость). выше я приводил пример с TCP/IP. в качестве примера: можно на одном ядре сделать что-нибудь типа IP-камеры. управление будет через TCP/IP, а трафик пойдет по UDP. вполне реально иметь порядка 800-900 мбит/с трафика, при этом само ядро работает, скажем, от 50 МГц.

Извините, "Ich бин дубин", но тема совершенно незнакомая, "учить матчасть"ещё долго. TCP/IP занимается процессор NIOS. Кто выполняет действия МАС? Программа для него вроде - на verilogе, если не процессор NIOS, то кто?

[vadimuzzz]

Кто выполняет действия МАС? Программа для него вроде - на verilogе, если не процессор NIOS, то кто?

MAC - это отдельная от NIOS IP-корка. типа TSE или с opencores.org. и не программа, а описание, он физически синтезируется на триггерах, логике и памяти. собственно, вполне может работать и без CPU, было бы кому пакеты принимать/отдавать

[NIOSnew]

В каких случаях надо использовать Nichestack (предполагается, что необходимо работать с TCP/IP)? Намного ли это замедлит работу?

[vadimuzzz]

TCP/IP в принципе не гарантирует скорость, только доставку данных. представьте себе ssh на 50-МГц контроллере - речи о скорости не идет. нужна скорость - UDP или raw-сокеты, естественно, никаких гарантий, ошибки обрабатываете сами. Nichestack, ЕМНИП, требует лицензирования. лучше смотреть в сторону LWIP, порт для ниоса есть.

[WitFed]

NIOSnew, ты б приоткрыл еще предметную область и желаемые параметры.
Ибо Гиг-поток в 100М/с действительно Ниосу не потянуть, тем более с TCP/IP-шизой, которая разрабатывалась под убогие каналы связи лет 30 назад. Только ОС Альтерную включаешь и стек какой-нибудь, сразу 300 К коду нарастает, и там реализовано хорошо если десятую часть от "большого и свежего" стандарта TCP/IP.
У нас, допустим, хоть и Гиг-режим передачи, но там данных от силы 10М/с, просто Eth используется как среда передачи даже полудуплексная и на приличное расстояние. UDP вполне достаточно, если просто гнать какое-то видео, а никакая Линда сверху не стоит и не занимается своими многозадачными и мультипротокольными извратами по тому же каналу. Даже можно в UDP-реализации без Ниос заложить посылку запроса на повторную передачу пакета, если вдруг какой-то потерялся из-за случайного нейтрино и битой им CRC. Или можно не запрашивать, а брать прошлое содержимое того места памяти, куда не пришел пакет. На экране сильно это не отразится
Хотя в рамках локальной сети предприятия сколько не пингуй, допустим, -- пакеты никогда не теряются при обычной жизни без дёрганья проводов, так что надо смотреть на dest-условия по помехам или дребезгу контактов, чтоб просто восстанавливалось всё как-то автоматом хоть через полсекунды после окончания возмущения.

По поводу начального поста -- рекомендую сварганить на Nichestack проект для имеющейся платы с 2 нитями, первая из которых будет гнать любую пургу по TCP/IP в один из двух каналов, другая -- читать из альтернативного, считать и принтфовать М/с раз в секунду, а выходы каналов закоротить. Выше этой цифры не подняться никогда, а только можно попробовать то же самое с UDP
Чем "круче" реализация TCP/IP, тем она медленнее будет работать. Простейшая может даже не сильно отличаться от UDP, если только источник кусками большими шлёт в свой сокет, память накристалльная со всех сторон, пакеты длинные собираются приёмником, смотрящим только заголовки, тоже в большой буфер, помех никаких нет...