Будет напрягать его BGA и многослойка.

С этим вообще справляется и трехсотмегагерцовый BF531..3,...

Ну поскольку вещь не крупносерийная, то универсальную железку LPC2378+FPGA тоже натянется

Меня не напрягает.. Мне нравится и BGA и многослойки..

Но BF537 минус FPGA может оказаться дешевле..

По быстродействию, естественно. На объемы кода в подавляющем большинстве случаеев наплевать. Да и по обьему не обещанные 30% а около 15.

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

Некоторое время назад я разрабатывал прошивку для этого процесора в которой была добавлена функциональность обмена данными по сети и USB. В качестве операционной системы использована FreeRTOS, TCP/IP стека - uIP. Сейчас потребовалось повысить скорость обработки событий устройством и оказалось, что по сети обмен данными идёт медленно. Так как я разбирался со всеми нюансами процесора и внутренностями сети самостоятельно, то мог пропустить какие-то важные моменты. Может кто увидит какие-то недостатки приведённого ниже алгоритма и подскажет как увеличить скорость работы устройства.
Итак, в устройство периодически по сети передаются данные блоком размером приблизительно в 16-20 кБ. Эти данные записываются в масив памяти и по таймеру процесора обрабатываются.
Когда я програмировал работу с сетью то передачу данных сделал блоками по 1500 Байт. Может я что-то не учёл, а может тогда вылезали другие ошибки, но при передачи блока большей длины у меня подвисал процесор (приёмный буфер установлен приблизительно на 2кБ), поэтому сделать так как в USB, когда я пишу в порт всё одним куском, на уровне USB контролера масив разбивается на части, а в процесоре я уже собираю данные (гарантированно доставленные), мне не удалось. Сейчас я смотрю, что похоже можно в обработчике прерываний от сети поставить свой код анализа входных данных и сделать похоже как в USB но не уверен - не буду ли я получать повреждённые даные, которые долго нужно будет перефрагментировать, проверять и т.д.
Сейчас у меня скорость передачи данных приблизительно 2Мб/с по 100 мегабитной сети. Выглядит это приблизительно так (результат теперешнего анализа с помощью Ethereal): отсылается пакет размером в 1500 байт в процесор, приблизительно через 4мс (время работы стека и моего копирования порции в нужное место памяти) процесор отсылает однобайтный пакет-подтверждения о приёме данных (чтобы внешняя программа не начала посылать данные пока я не обработал предыдущую порцию - правильно ли?), приблизительно через (дома забыл логи поэтому тут цыфру не помню) толи 1, толи 0,1мс, отсылается следующая порция данных. В результате 16кБ передаётся приблизительно за 50мс. Долго, было бы хорошо хотя бы в 2 раза быстрее. Можно ли улучшить скорость? Я смотрел, что при обработке стек копирует данные из буфера контролера в память, а потом я копирую куда мне нужно. Может можно сразу копировать без промежуточного буфера, но не будут ли проблемы с проверкой ошибок при передаче?
Может в стеке uIP можно убрать лишнюю обработку?

Пока что я в процессе анализа кода, может ещё что и сам найду, но за любые советы и предложения буду искренне благодарен.

Возьмите процы от Freescale, в них IP-core Ethernet-а такой, что дескрипторы буферов приема могут быть настроены под любую длину фрагментов входных пакетов.
Соответственно хидеры можете в одно место принимать, а данные сразу в точку назначения.
Причем можно вызвать прерывание сразу по окончании хидера и таким образом фильтровать пакеты так чтобы целевой трафик не попадал в RTOS.
RTOS-ы .. OS-ы на таких скоростях только мешают.

RTOS-ы .. OS-ы на таких скоростях только мешают.

А если вдувать в Ethernet пакеты со всей дури это не есть единственное предназначение устройства?

Возьмите процы от Freescale, в них IP-core Ethernet-а такой, что дескрипторы буферов приема могут быть настроены под любую длину фрагментов входных пакетов.Соответственно хидеры можете в одно место принимать, а данные сразу в точку назначения.Причем можно вызвать прерывание сразу по окончании хидера и таким образом фильтровать пакеты так чтобы целевой трафик не попадал в RTOS.

Это классно конечно, но почему-то забывают про то, что заголовки не имеют фиксированной длинны - так что может оказаться, что граница заголовки/данные окажутся совсем не там, где настроенно для приема...

Есть такой тэг VLAN, в MAC хидере. Используя его можно много чего придумать.

Не совсем понятно, что же можно придумать с этим тегом на приемном конце? Тег-то приходит из сети, и есть он или нет - еще неизвестно (обычно, в конечном устройстве его надо просто стрипнуть). А я о том, что и в IP-заголовке, и в TCP-заголовке возможны дополнительные опции - например, при открытии сессии очень все любят сунуть опцию MTU. Хотя, с другой стороны, при передаче собственно данных обычно дополнительные заголовки не встречаются (нефиг оверхед гонять, и это правильно), но закладываться на это - себе дороже.

Хотя, конечно, это мои размышлизмы, может в мотороловской реализации мака уже и подумали за нас. Дайте, чтоли, ссылочку на даташит, почитаем, проникнемся