я делал сетёвки на интеле 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 Мбит каждая, и всё будет сваливаться на сервер, то сервер (один) от такой нагрузки помрёт.

Сообщение отредактировал krux - Jun 20 2013, 18:41

..а про еером такой вопрос : вот у меня две платы есть с интел 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 опять-таки самому писать?

Сообщение отредактировал krux - Jun 22 2013, 12:38