Посоветуйте современный быстрый Ethernet контроллер. До этого использовался LAN91c111 в связке с ПЛИС (cyclone3) с процессором NiOSII. Максимальная скорость обмена ПЛИС--компьютер, которой удалось достичь 15-20 Мбит/с (со стандартными драйверами под ниос). Хотелось бы приблизиться к скоростям 80-100 Мбит/с.
Какую микросхему выбрать, желательно, чтобы потом не возникло проблем с поиском или написанием драйверов, ну и цена чтобы не заоблачная была...

постановка вопроса не корректная. любая внешняя физика + МАС в ПЛИС позволяют забить хоть гигабит. А реальная скорость будет ограничена только способностями вашего процессора разгребать кадры.

Да, конечно, Вы правы. Но все-таки от размеров буфера микросхемы тоже кое-что зависит. Я привел пример каких скоростей можно добиться используя ниосовский иниш стек и микруху Lan91. Хотелось бы узнать какие сейчас микрухи используются.? И возможно ли добиться бОльших скоростей, используя существующий стек и сменив микруху.?

увеличение размеров буферов отрицательно сказывается на TCP/IP. Можете погуглить ключевое слово bufferbloat.


если нужен PHY к ПЛИС - то Marvell 88E1111. Получится wirespeed.


нет.

Вы должны понимать - какой вопрос такой и ответ.
Если вы манагер и вам нужен ответ прямо здесь и сейчас - то для вас правильным ответом будет сделать реализацию Ethernet на самом новом и самом мощном Intel Core, или ещё лучше если это будет Xeon.
Если вы инженегр и понимаете что Ethernet это не только TCP/IP, то решением может быть полностью аппаратный UDP, без каких бы то ни было процессоров вообще.

Сейчас используем микруху DM9000, это 10/100 mac. На сколько я знаю очень похож на ваш LAN.
Так вот просто на ниосе в циклоне 2 у меня работало все на скорости 40-45 мбит/с.
С аппаратным ускорителем UDP получается 90-93. Ну тут постановка вопроса такая, что ниос только отдает команды на контроллер, а данные идут аппаратно.

Вы использовали стандартный иниш стек или писали полностью свой, чтобы добиться таких скоростей.?

Как уже правильно говрили выше, вопрос поставлен неточно. При проворачивании какого стека коммуникационных протоколов вы хотите добиться data rate >= 80 Mbps @ FastEthernet? Варианты:

1) Eth PHY - Eth MAC - все, что выше - свое (свои network layer / transport layer - по мере надобности). +: можно добиться наивысшей скорости передачи. -: все проблемы реализации собственных уровней ;-)

2) Eth PHY - Eth MAC - IP - TCP/UDP. Надо применять наработанные реализации TCP/IP стеков, а они будут кушать процессорный и системный ресурс, и их проворачивание будет иметь на данной платформе вполне определенную latency, приводящую к некоему максимальному для платформы кол-ву обрабатываемых пакетов в секунду (сетевая производительность).

Рассмотрим вариант 2, как более реалистичный. Составляющие обработки (если грубо): обработка PHY/MAC (tMAC) + обработка TCP/IP (tTCP). В использовавшемся вами до сих пор варианте (LAN91С111 + NiosII + lite weight TCP (по-видимому)) обе составляющие выполнялись при плотном задействовании CPU, к тому же природа LAN91C111 ограничивает его предельную пропускную способность числами существенно ниже теоретически возможных 90-95 % от 100Mbps. Все вместе и дало наблюдаемый результат - 15-20 Mbps (для данной комбинации, кстати, весьма хороший).

Путь улучшения - разгрузка CPU от сетевых задач, насколько возможно => перенос функциональности на HW где только можно. Рассмотрим отдельно реализацию этого для PHY/MAC и TCP/IP.

PHY/MAC

В части MAC имеются хорошо наработанные решения, основанные на следующих идеях (еще со времен присной памяти NE2000 сетевых карт, как минимум):
1) МАС работает мастером и сам забирает-складывает содержимое пакетов, помещаемых в выделяемые буфера (в основной памяти данных);
2) драйвер (читай - CPU) в основном имеет дело с дескрипторами Rx и Tx буферов, которые он заполняет (для Tx) и проверяет (Rx); дескрипторы, как правило, объединеные в кольцевые списки;
3) MAC также работает с дескрипторами (узнает, откуда брать TxData, и куда класть RxData, и помечает отработанное).

Думаю, конкретный MAC-PHY чип, работающий по такому принципу, народ вам скоро насоветует. Ну, и сами теперь знаете, что искать надо. В качестве суб-варианта: {внешний PHY} + {MAC in FPGA} (у Altera же есть соответствующие ядра, да на OpenCores тоже).

TCP/IP

Теперь уже и в этой части есть аппаратные наработки. Например, WizNet - накрывает сразу все - PHY/MAC/TCP. Но вот насчет его производительности не могу ничего сказать - не имел дела непостредственно. Наверняка, есть и аппаратные ускорители для работы с TCP/IP стеком - только поискать надо. А вообще, вполне возможно, что и аппаратные улучшения на MAC уровне (см. выше) уже дадут вам желаемое (или сильно к нему приблизят).

Спасибо, за полезную информацию. Как раз хотел спросить про микросхемы с готовым Phy и Mac.
Может, кто имеет опыт работы с конкретными микрухами и может что-то посоветовать.?

Контроллеры ищите у Микрел.

WizNet не вариант.

Посмотрел описание микросхемы.
http://www.smsc.com/Downloads/SMSC/Downloa...eets/91c111.pdf

Она имеет две слорости 10 и 100 килобит в секунду. Судя по тому, что ваша скорость больше 10, у вас выбрано 100. Я полагаю, что скорость передачи данных ограничена другой частью системы. Скорее всего быстродействием драйвера. Попробуйте сделать loopback тест.
http://en.wikipedia.org/wiki/Loopback

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

Вы его щупали на предмет производительности? Что может дать, какого порядка?

Похоже, что его целевая аудитория другая (просто дать окно в TCP/IP мир для всего, что только можно), но все же интересно - для понимания расклада.

Приращивание заголовка ethernet, IP, UDP и выход этого дела на микруху, никакого стека сверху. Просто не было потребности в стеке.

WizNet щупали, разные версии, поначалу модули даже в серийные изделия ставили. но у всех были свои аппаратные проблемы - то буфера переполняются и зависает, то двойное тегирование VLAN не пропускает. В итоге создали свой модуль в том же конструктиве и везде заменили.
И да, предназначение WizNet - неспешное окошко в Ethernet , замена RS.

В TCP/IP очень даже вариант. 70 Мбит прокачивал...