Понадобилось прогонять через систему 100Мб, видимо UDP пакетами.
От контроллера нужно лишь наличие мощи, чтоб переваривать 100Мб и отправлять в некий другой интерфейс.

Чем иp ARM минимально можно обойтись?
Работал тока с младшими stm32 и аналогичными LPC, они явно не тянут.

Что это по вашему не тянут? и 100Мб это скорость или объём? Скорость не та? Потеря пакетов? Младший это 107 как я понимаю. И какой Phy используете?

100Мб - это поток(вероятно UDP пакеты), реально будет меньше ~30-50Мбод, но запас это хорошо. Суть девайса парсить этот поток и выплевывать информацию в 16 последовательных интерфейсов ~3-5Мбод.

По ощущениям stm32 f107 не успеет. Может стоит смотреть в сторону Cortex M4?
Интересует ваш опыт работы с загруженным Ethernet 100.

Непонятно зачем конкретизировать физ. уровень, я пока выбираю контроллер.

Это где вы их наберете? Столько-то. Как то вам надо бы поближе к реальности.

Подобный поток (80+Мбит/с) вполне нормально перелопачивался даже на SAM7X. А вот 16 последовательных интерфейсов придется окучивать внешней логикой.

... отправлять в некий другой интерфейс. Это как? Как только какая мало-мальская обработка (5-8 команд) потока, то приплыли.
Не тот проц для этого выбрали. Cortex_ы любые, не причем. Сразу FPGA выбирайте.

Спасибо всем за ответы.
Варианты значит такие:
1. FPGA c загруженым ядром+ там же формирование внешних последовательных интерфейсов
2. CPU с Ethernet 100 + (маленькая FPGA)/CPLD

А какого уровня FPGA смотреть/пробовать? (уже не та ветка форума похоже)

На самом деле надо много считать.
1. Ethernet - как будет выполнен? Соединение точка-точка? Тогда реально можно получить суммарно 80-90Мбит.
Какого размера будут передаваемые блоки данных? Ethernet-фрейм в стандарте по минимуму содержит 26-28 байт
служебных. Если у вас блоки данных будут по 2 байта, то требуемые 50Мбит вы не получите. Вы упомянули UTP.
Там служебной информации еще больше. Если же не точка-точка, а в локалке еще есть кто-то живой, то скорость
передачи становится вообще не подлежащей расчету.
2. Следующее узкое место - передача данных из буферов Ethernet на последовательный интерфейс. Ладно бы один.
Тогда DMA и все в порядке. У вас 16. Значит что-то внешнее. Но во что-то внешнее, в ту же FPGA, тоже надо передать,
да еще и засинхронизировать. Как это сделать хз. Может быть использовать интерфейс внешней памяти? Тогда да,
контроллер с Ethernet и FPGA.

... 1. FPGA c загруженым ядром+ там же формирование внешних последовательных интерфейсов
3-й цыклон, 2 помедленнее, но может вас и устроит.

2. CPU с Ethernet 100 + (маленькая FPGA)/CPLD
... выбор зависит от протоколов ваших интерфейсов.

Не-не, Сашка! Тут можно хитро-вывернуться, если собрать четыре одинаковых независимых девайса и соединить их параллельно в Ethernet.
Каждый из девайсов имеет один ethernet-вход и четыре USART-выхода. Девайсы имеют один и тот же IP адрес и принимают UDP-поток на одинаковый номер порта (например 12345). Приняв UDP-пакет каждый девайс выделяет из него свою порцию данных для _своих_ четырех последовательных портов. Собственно, здесь эти четыре девайса и будут различаться.

И кто им раздаст один и тот же поток? Разве что налепить за одним PHY четыре процессора, но этот вариант явно хуже, чем одна FPGA или один процессор + CPLD/FPGA.

Да, можно и так. Особенно если FPGA для тебя (точнее для меня ) темный лес. Но блин
затратно наверное. Но исходить все равно надо из начальных условий, о которых я и
написал. Если в сети будет еще кто-то живой - забудь о 100 Мбитах, и даже о 50. Если у
тебя пакеты в которых данных по 2 байта - забудь тоже. Да и ТС не говорит, что за
последовательные каналы ему нужны. Может SPI. Столько тоже нет. Хотя может у каких-нибудь
чипов и есть 4 SPI, не в курсе, не пользовал.

Возможно мы говорим о разном. Я имею ввиду -- UDP-поток, ну или свой какой-нибудь "доморощенный" (не стандартный). Источнику достаточно "вещать" в сеть, а заботиться о том, принимается ли поток -- не обязательно. Так сказать симплекс-передача без обратной связи. Его задача -- выплюнуть в сеть информацию, а уж поймали ли ее, и сколько девайсов поймало -- не его дело.

"С моей стороны проблем нет. Пули из ствола ушли. Проблемы на вашей стороне." (с)исадмин на службе.

На месте приема цепляем параллельно четыре приемника, которые должны иметь одинаковые параметры. Приемники принимают _ВСЕ_ пакеты, которые приходят к ним на вход. Сортировкой пакетов типа наш-не наш и последующим их дропанием занимается проц.

Да, и самое главное, наверно тут не следует поднимать стандартные библиотеки для работы с сетевыми протоколами. Я бы написал свою реализацию. Собственно, я как-то давно так и делал, еще на ENC28J60 + MEGA8/16. Особо сложного тут ничего нет. Сложности только в маршрутизации этого нестандартного потока. Если потребуется маршрутизация, то можно же на одном из четырех девайсов поднять частично ICMP, ARP-протоколы. Пусть один за четырех отдувается. Не проблема.

Я не знаю. Я бы делал так, как описываю. Я не знаком с технологией FPGA, поэтому мне проще поставить четыре копеечных STM32 и не затягивать разработку. Мое рабочее время стоит на много дороже. Устройство вряд-ли будет производится серийно. Поэтому разница в 1000 рублей (четыре МК, вместо одного, округленно) -- никак не скажется на конечной стоимости изделия, цена которого вряд-ли будет ниже 10-20 труб.

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

Извините за оффтоп.


Ага. Все так.
Да уж... поколение молодых разработчиков. Привыкли, понимаешь, мыслить на уровне кубиков библиотечных функций и программировать мышкой. Надеются на то, что мощный проц всё вытащит. Глубоко не копают. Зачем? Лего-разработчики, мать их! (Это я не о ТС. Это я по старчески, по доброму. В воздух.)

а какой именно последовательный интерфейс, если только в одну сторону надо, то можно попробовать из 16-ти разрядного параллельного порта (как у блэкфинов, например) сделать 16 последовательных интерфейсов типа SPI.
ну или из внешней шины памяти,
а если без запаса, ~40мБит езернета устроит, то можно вообще сделать на ADSP-BF592 + KSZ8851SNL.

Только источнику придется вещать в broadcast или multicast режиме, иначе до всех не дойдет.