Нужно передать 16 битный поток от устройства в систему по Ethernet.
Поток от 40МБит/с. Не непрерывный, но хорошая скорость нужна. Желательно предусмотреть возможность максимальной передачи потока до 200 МБит/с (задел на будущее).
Сроки как всегда сильно поджимают, поэтому системы на ПЛИС не рассматриваю - не успеем.
Если бы не USB, то идельно подошел Cypress FX3, но нужен Ethernet.
Делали проекты на Atmel ARM7/ARM9, но что-то с параллельной шиной там не очень и для достижения приличных скоростей по LAN нужно сильно постараться.
Из простого - посмотрел контроллер W5300. По минимуму укладывается, но может есть что получше? Гигабит не помешает))
И насколько прост W5300 в обращении? Дополнительно к параллельной шине хотелось бы SPI сделать.

Через W5300, с его 100BaseTX, "поток от 40МБайт/с", и уж тем более 200 МБайт/с, передать физически невозможно.

Вы мбиты и мбайты отличаете?

В наше время - это не показатель. Подобный проект поднимается из готовых примеров за неделю при отсутствии опыта(с учетом специфики работы в нашей стране ).
Больше всего времени уйдет на компиляцию проекта ПЛИС.
Если требуется гарантия доставки данных необходимо предусмотреть буфер на >0.5 секунды (экспериментально подобрано для windows)

Из W5300 DatasheetПоясните, пожалуйста, как поток 40 МБайт/с (320 Мбит/с) можно запихнуть в 100 Мбит/с Ethernet ?
Если Ваш поток всё-таки ложиться в 100Мбит/с, то в среднем он явно меньше 12МБайт/с - пожалуйста, поподробней опишите что же именно Вам надо.

Ну тут может оказаться мало и 2xGigabit Ethernet Link, если понадобится сделать гарантированную доставку данных.

Прошу прощения ошибся - от 40МБит/с. (Биты и байты различаю, но от очепятки никто не застрахован).



У нас один товарищ мучает TCP/IP на ПЛИС, но что-то не очень успешно пока ему удается. Скорость маленькая и поток данных со сбоями идет.
Хорошие примеры все идут за неплохие деньги, а из свободно доступного собрать стабильно работающий проект за неделю... Не верю. С отладкой задолбаешься возиться + ко всему со схемотехникой больше проблем будет.

Проверяйте также приемную часть задачи. Когда я наткнулся на "артефакты" проблема была именно в программе на ПК : ПО на C# не успевало переварить трафик(сделан прокси на c + winsock2), операционная система может "приостановить" обмен на неопределенный срок (решается буферизацией на передающей стороне). Передавать информацию необходимо блоками данных оптимального размера(как в udp).


Тут МК не поможет, т.к. в ПЛИС эту задачу торе решает МК(как правило)

делал похожее на adsp-bf532 + dm9000a (сейчас дешевле, наверное, будет взять BF512 + KSZ8851).
у блэкфинов удобный параллельный порт. данные сначала с PPI шли во внешний СДРАМ, а от туда по запросу выдавались в езернет.
по UDP реальная скорость передачи данных почти под 100МБит получалась.
есть и со встроенным MAC, но у BF516, например, он на тех же ногах что и PPI.

если без задела на будущее, то можно вообще взять adsp-bf592 без внешней шины памяти и KSZ8851SNL по spi около 40мбит и получится.
правда вот памяти под буфер для перепосылки в случае потери пакета маловато в нём.

Можно еще использовать DM9000 - он побыстрее, хотя весь стек придется прикручивать снаружи.

Если ориентироваться на 40 мбит, то LPC1768 + UDP + заточенный lwIP за глаза хватит. Если нужно 200 мбит, то можно попробовать Sitara от TI с гигабитным интерфейсом, либо на ПЛИС поднять.

а 16бит * 2.5МГц он чем принимать будет? просто чтением GPIO? он тогда только этим и будет занят.
можно конечно попробовать в последовательный вид преобразовать и через SSP, вроде на 50МГц может работать.

Да кто ж его знает. Чем-то принимает, скорее всего с АЦП ловит. Думаю, что LPC1768 вполне обеспечит 16 бит на 2,5 МГц сэмплов.

А нет, вру. LPC1768 даёт тока 12 бит на 200 КГц. Значит с SPI будет брать.

SSP правда в режиме мастера может 50мбит/с

у LPC еще SD контроллер есть!

А вообще 40 мбит по UDP практически любой АРМ потянет. Тут действительно важный вопрос откуда данные берутся и как будут в контроллер доставляться! Может быть по пути еще буферизировать нужно и много рама из-за этого.

_pv,
SSP в мастере 50 мбит не сможет, там частота ограничена ЕМНИП 30 Mhz, так что при чипе разогнаном до 100 mhz прескалер 2 нельзя использовать.

я просто даташит глянул, особо не разбирался, но почему бы spi не работать на половинной тактовой частоте?

неужели врут?

хотя при этом зачем-то приводят параметр
что вроде бы ограничивает частоту до 30МГц.
с другой стороны, какая ему разница за сколько наносекунд до фронта клоков slave данные выставил.

разница есть! и у первых LPC, правда еще 21xx, в которых появился SSP был баг которы не позволял даже на 30 mhz работать. Там не совсем простая схема т.к. имеется возможность менять конфигурацию фронт и т.п. IMHO с этим связано.
И недавно я про это ограничение забыл и ЕМНИП на LPC1754 влетел, что SSP не работал на 50 MHZ, пришлось на 25 ставить.

ну тогда тем более lpc в топку.
надо было как-то spi на ~40МГц две штуки да память внешнюю, присматривался к различным АРМам, далеко не во всех так можно было.
в результате поставил блэкфин, и видимо не зря.

если еще актуально, то можно посмотреть в сторону SMSC, например LAN9215:
Highly Efficient Single-Chip 10/100 Ethernet Controller
with HP Auto-MDIX.
Highlights
Optimized for medium performance applications
Efficient architecture with low CPU overhead
Easily interfaces to most 16-bit embedded CPU’s
Integrated PHY with HP Auto-MDIX
Supports audio & video streaming over Ethernet:
multiple standard-definition (SD) MPEG2 streams

чем он лучше уже упомянутых dm9000a и ksz8851, учитывая что он в 3-4 раза дороже их?

Ну для LPC17xx есть два способа.

1. Читать данные с параллельного порта через DMA по внешнему стробу (организовывается через таймер).
2. Использовать I2S. Он в Slave-mode работает до полста мегагерц. Хоть это и не описано в User Manual, но я имею ответ от техподдержки NXP по этому поводу.

dm9000a и ksz8851 их не знаю, т.к не использовал.

LAN9215 имеет, с одной стороны, классический интерфейс адрес/данные, ширина данных 16 бит, с другой стороны готовый Ethernet со встроенным phy. По цене всего лишь в два раза дороже, а учитывая, что выйдет даже дешевле.

я разницы по цене меньше чем в 3 раза не нашел.
по функциональности они все (dm9000, ksz8851 и lan9215) ничем не отличаются, та же асинхронная 8/16 разрядная шина с одной стороны, внутри МАС и phy с другой стороны.
IP стек всё равно прикручивать.
DM9000, кстати, еще IP/TCP/UDP контрольные суммы считать умеет, а не только езернетные - мелочь, а приятно.

Вам, как специалисту по DM9000:
значит ли это что он умеет собирать пакеты на IP уровне? Или считает только не дефрагментированные???

(круглый)

нет, ничего он собирать не умеет.
при посылке можно в него запихать пакет с чем попало вместо контрольной суммы, как для езернетного фрейма, так и для IP/UDP (у последних контрольная сумма от заголовка только считается насколько помню).
соответственно dm9000 сам посчитает контрольные суммы и заменит их на свои по соотвествующим смещениям.
ну и соответственно так же проверит при приёме.
про фрагментацию точно tcp не скажу - не знаю.
но у фрагментированных пакетов разве не такой же заголовок со своей контрольной суммой на каждый кусок? только оффсет еще указан.
контрольная сумма вроде бы точно также считаться должна, только по фрагменту, не?

опс. возможно вы и правы, и говоря о контрольной сумме TCP мы имеем ввиду IP сами пакеты. давно было дело. надо смотреть умные документы а лень матушка.

ок.
спасибо
(круглый)

переборол лень. не совсем в вумные залез. глянул. нет всё таки мне не изменяет память. у TCP своя у IP пакета своя CRC. Т.е. получая разрезанные IP данные Вы не сможете корректно считать TCP. так что... вопрос остался открытым. Либо, Вы перегнули палку и милкосхема не обрабатывает корректно TCP уровень.

удачи вам
(круглый)

сам проверял только работу IP и UDP
в даташите описания CRC нет,
есть только регистр с тремя битами для включения генерации CRC, для IP, для UDP, и для TCP. первые два работают нормально, TCP не трогал.