Поток данных 16бит -> Ethernet, какой контроллер выбрать? Опции

[Serg_Sm]

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

[wolfman]

если еще актуально, то можно посмотреть в сторону 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

[_pv]

если еще актуально, то можно посмотреть в сторону SMSC, например LAN9215:

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

[wolfman]

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

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

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

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

выйдет даже дешевле.

[_pv]

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

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

[kolobok0]

...DM9000, кстати, еще IP/TCP/UDP контрольные суммы считать умеет...

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

(круглый)

[_pv]

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

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

[kolobok0]

...контрольная сумма вроде бы точно также считаться должна, только по фрагменту, не?

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

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

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

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

Сообщение отредактировал kolobok0 - May 12 2012, 10:26