Добрый вечер уважаемые!

Такая проблема есть:

..есть поток 60 Мбайт/секунду общим объёмом 1 Гигабайт , его нужно по 1G Ethernet-у отправить за 50 метров серверу.
Я разрабатываю схемотехнику - не знаю что заложить, можно заложить какой-нить PHY и ПЛИС , а дальше сказать копайтесь сами.
Но что-то мне подсказывает что делать придёться самому. А контроллер в ПЛИС я не вытяну.
Есть вариант - поставить какой-нить ARM + PHY , поднять на нём какую-нить операционку где всё есть и гнать поток через него, но справится ли ? и кто именно может справится? И сложно ли поднять операционку? Подозреваю что проблема давно решённая и что на демобордах есть и ARM, и подробные инструкции как всё поднять. Но я вообще не в теме.

Короче подскажите - где и что читать что бы решить проблему, куда смотреть ?

з.ы.

поток порождает связка АЦП+DSP на плис .

В проекте марсоход, просто на ethernet ПЛИС посылала сигнал с темп датчика. Без всяких там TCP\IP и прочего. Конечно 1G это не 10Mbitный Ethernet, но наверное как то можно заставить ПЛИС генерировать Ethernet кадры

подобные примеры я знаю - вот например 10 Мбит на fpga .

http://www.fpga4fun.com/10BASE-T.html

но мне надо нечто посложнее,

можно тоже самое и даже проще и на гигабите сделать, ну только через phy конечно, например ksz9021/9031.
данные можно просто пихать в голые езернет фреймы, добавив МАС адрес сервера в начале и контрольную сумму в конце. То что потеряется, принимающий сервер может попросить потом послать еще раз.
на компе принимать езернет фреймы через libpcap.

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

Идем на OpenCore и берем GE MAC. Работает нормально. Но прийдется делать UDP обмен и другие функци исходя из требований к проекту. Скорей всего надо будет определиться с форматом посылок и др детали.
Могу сфарганить -недорого.

UDP не гарантирует сохранность пакетов, или что они не напутуются. Будет много отправителей и один сервак, можно много пакетов потерять - каша получиться.

ИМХО, можно взять практически любой одноядерный микропроцессор со встроенным Gigabit Ethernet MAC с частотой от 800МГц, и по TCP вполне реально отдать 60Мбайт/сек. Но не на Линуксе, скорее всего. У меня был проект на MPC8347@533MHz, получалось забирать с PСI 32@66MHz 250Мбайт/сек и медленно и печально отдавать примерно 50Мбайт/сек по TCP через гигабитный эзернет (ну там еще резервы оставались, с Джумбо-пакетами на wire-speed вышло бы), но это все с самописным софтом. Сейчас контроллеры попродвинутей есть - и частота больше, и MACи умеют TCP-offload делать, думаю можно что-то подобрать, может даже издержки Линукса вытянуть.

UDP это будет нижний уровнь соединения. Над ним добовляется простой свой протоkол обменна, и retransmission и другие требования.

..сервер не я делаю, за свой протокол обмена меня попрут.

Есть люди работают над TCP/IP в ФПГА - ето не дешево.
Tогда дешевле найти процессор с достаточной пропускной способностью.

Сделать MAC в FPGA - не штука. Я тут слепил и отладил за пару недель. Но если нужен протокол с ретрансмитом и без потерь данных - то лучше ставить процессор с приличной памятью - на TCP/IP таймауты очень длинные и буфера требуются большие. Опять же, заниматься сборкой/разборкой пакетов и подстверждений чисто на FPGA неоправданно сложно. Может быть, поставить быстрый DSP. Там уже решены проблемы с подключением памяти и, не некоторых, есть уже MAC.

..мне тоже так кажется, вот и хочется доброго совета - на что обратить внимание?
Так чтобы была хорошая отладочная, чтобы можно было по примерам быстро своё решение поднять. Чтобы была , ОСЬ , сеть и возможность оперативно пренять и выдать заданный поток.

А зачем Вам, вообще, ось? Чтобы потерять время? Если Вы хотите, чтобы Вам рассказали комплексное решение Вашей комплексной задачи, то рисуйте здесь подробное описание, строк на двести, а то все телепаты повывелись. Ось имеет смысл, когда у Вас требуется многозадачность или многопоточность. Здесь Вы рисуете одну задачу - взять поток и отправить в линию.

Мне прям специально Ось не нужна, просто я подозреваю что уже опубликованные и отлаженные решения написаны под какую-то Ось.
Врят ли кто-то делал в демоборде специально для меня Сеть и модуль обмена с сетью моим потоком.

В первом сообщении я достаточно данных дал чтобы понять глубину проблем.
Есть и тербуемая скорость и объём передаваемого трафика, прочие пожелания.

Я просто попросил, если кто вспомнит что-нить готовое из демобордов на 1G.

DL-ZedBoard Zynq-7000
Плис (Xilinx) + ARM(Cortex A9) + 1G
Стандарт для подключения мезонинов FMC Vita-57
Стоимость малая

спасибо.

Такой вопрос (возможно что смешной и глупый) , а чего мне никто в теме не предложил интеловские контроллеры 1G ?
Там и MAC встроен и PHY , наружу PCI выходит .
Документацию на них скачал с сайта интела.
В чём подвох? Их не продают смертным? Они не поддаются программированию? Или они не то что я себе на представлял?
просто не понятно - зачем покупать процессор с 1G и осваивать его или в ПЛИС совать MAC и осваивать его (оно там место нужное ещё занимает) , если можно поставить например - 82547GI от интела?

У интела контроллеров 1G - вагон, у микреля - несколько PHY и всё. У интела даже 10G есть.

Может я чего не понимаю в английском?
.. - читаю описание : контроллер 1G , передаёт и получает IP,TCP и UDP.
..управление по шине PCI .

з.ы.

Уважаемые - развейте иллюзии, чтобы я и дальше спокойно продолжил копировать отладочную плату ксалинкса себе в проект , с марвелом на борту.

Так изначально задача стояла принять поток данных и передать в Ethernet на 60 МБит/с. А тут ещё какой-то PCI, которым кто-то тоже должен рулить. Это же чип для сетевой карты, ему кто данные будет формировать?
Ну и возможность купить пару штучек с улицы - большой вопрос.

..ну т.е. если PCI или PCI-express не проблема, то смело можно эти камешки от интела ставить?

Забавно, как вы это 1G на 50 метров собираетесь прокинуть, наверное кабельком 7 категории, соблюдая стандарт?
При низкой скорости потока данных, как у вас, проще двумя сотками бросить. Меньше мороки. Да и дешевле, надежнее.

Думать-то за него кто будет? Сам по себе TCP не сделается, это просто MAC с некоторыми ускорителями.


У ТС 60МБайт/с, так что двумя точно не обойтись.

А что не так?

Вот, у Intel'а сетевые карты 1G на 100 метров по пятой категории работают: Intel-Ethernet-Server-Adapter-I350-T2.

Неужели, Intel стандарт не соблюдает?

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


..вы мне дураку объясните, эти интеловские контроллеры "аналоги" wiznet W5100 но только для 1G или нет?
Думать оно конечно - да, чего-то придётся поднимать .
Просто я так понял решение с интеловскими контроллерами по крайней мере лучше чем связка плис-марвеловская аляска, хотя бы за счёт экономии места в ПЛИС.

Вот у меня в VisualDSP для blackfin-а 533 есть LwIP TCP/IP - смогу я завязать узлом это с интеловским контроллером через ПЛИС ?
Ведь ничего больше не надо , кроме реализации ещё PCI.



да верно, я уже дошёл до мысли - купить что-то вроде мелкого компа с единственной целью по любому интерфейсу принимать поток и по его покупному интерфейсу 1G отсылать товарищам. Что-то вроде : PC/104 http://www.rtsoft.ru/upload/pdfcat/MSM-LP_Manual_V102.pdf

Для полноты картины: LAN8820.

Нет.

спс.

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

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

Вот это правильное направление полёта. Помнится, у "сигнальщиков" были подходящие решения. Что бы с линуксом не связываться и рашпилем сильно не орудовать.
Только не надо Интела. У того же тексаса есть сигнальники со встроенным 1G маком. Достатчно добавить PHY, и канал готов. А PCI к FPGA.
Что там сейчас у ADI не скажу. На blackfin вроде только 10/100 были.

я делал сетёвки на интеле 82571, 82599.
сделать схему и развести плату - никаких подвохов нет. Базовый EEPROM тоже можно сделать.
Покупается нормально, если знаешь полный part number.

Подвохи начинаются потом: а как это всё тестировать?
на "закрытой стороне" дают утилиту (winxp/linux 2.6.22+), которая может тестить внутренние блоки, ставить лупбэки, тестить linerate, писать EEPROM in-situ и тому подобные плюшки.
Но туда всех подряд не пускают. Для получения NDA нужно очень серьезно заинтересовать Intel. Доступ дадутт если сможете с ходу сделать им обороты от $100к в год. Если ничего не обещать - будут смотреть на историю фирмы, захотят общаться, в том числе лично, вобщем будут прощупывать.

А почему не поставить связку ADC+FPGA на PCIe карточку в этот сервер?
Или если нельзя тащить сервер к месту АЦП то можно распилить слона пополам: АЦП+FPGA+трансивер+SFP через оптику до сервера, а там плата с SFP+трансивер+FPGA+PCIe. По опте наваять протокол попроще.

И ещё, если у вас каждая ваша плата будет генерить поток в 60 Мбит каждая, и всё будет сваливаться на сервер, то сервер (один) от такой нагрузки помрёт.

..а про еером такой вопрос : вот у меня две платы есть с интел 82599, на одной еепромка сломалась, гарантии нет - надо чинить самому.
могу я снять хорошую еепромку и скачать содержимое, потом прошить в новую и установить заместо сломаной с первой платы, работать будет?
Или там подводные камни?



да, сервер в одном месте а ацп-fpga в другом. Начальство мечтает как было бы здорово освоить 1G и всё замутить на максимально серийно-доступном оборудовании, а своё ноухау делать поменьше - а то от своих ноухау одни проблемы. Люди увольяются ...или мрут.



это не мои проблемы, мне бы этот поток выдать правильно.

И т.д., и т.п. В том-то и дело.

Я потому и обратил внимание на решения у "сигнальщиков". Они в большей степени ориентированы на реальное время.

В принципе, можно поставить что-нибудь типа MPC8313. Если ориентироваться на SFP, то даже PHY не нужен.
Проц не слишком быстрый, но железо у него очень хорошо сделано. Вроде бы, должен справиться.
Но вот насколько придётся обрабатывать напильником тот же Линукс, заранее сказать сложно.
У меня "квики" уже на нескольких проектах использовались, но реалтайм никому не был нужен, и никто его не проверял.

В общем-то, имеется возможность проверить тестером максимальную пропускную способность канала на том железе и софте, что есть и работает.
Мне даже самому стало интересно. Если с тестами что получится, дам знать.

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

городить свое решение на FPGA + PHY я бы не стал по причине того, что данные для ретрансмита по TCP надо будет хранить в DDR-памяти (т.к. её надо много). Nios/Microblaze с TCP-потоком в 60 МБайт/с не справятся, а писать собственный TCP-стек и собственный MMU для разгребания проблем с памятью - полжизни уйдёт.

Лучше действительно под такую задачу брать FPGA + DSP + PHY.
QorIQ или C647x например.

Или 5CSEBA5U19I7N, например.

..спасибо за совет.
Пока склоняемся к мысли - сунуть внутрь COM-Express и тем поубивать всех зайцев.
Благо - деньги роли особо не играют.

а TCP Checksum Offload опять-таки самому писать?