Наши делали так. Интеловский сетевой процессор. На нем раскручивается линух, который и реализует стандартные протоколы, в том числе и TCP/IP.

Для специалиста по ФПГА только слово "линукс" может показаться концом света, а не то, что "драйвер". При том, что контролировать передачу пакета и перепосылать, если не было подтверждения за определенное время, это достаточно просто в RTL-реализации. Что займет какое то время - это факт, но сильно сомнительно, что будет дольше, чем поднятия линукса на софт-проце.

В этом проекте без программиста все равно вряд ли обойдется дело. Даже делая простое подтверждение пакетов с перепосылкой надо написать некий софт на РС, чтобы это тестировать.

Это все так, но использование стандартной ОС очень соблазнительно, т.к. она позволит не только организовать TCP стек, но и предоставит базу для возможной последующей модернизации. ИМХО - новую программу написать легче, чем изготовить новое железо.

Но не легче, чем просто поправить RTL, внеся в него новую функциональность. Если, конечно, в ПЛИС влезет.


Ну PC-программист (он наверное и так есть, так как проект-то не новый, а модернизация) это одно, а программист, способный поднять что-то на софт-проце в фпга это совсем другое.

Тема очень интересная - мне кажется что быстродействие отнюдь не самая большая ценоость в решении на USB или Ethernet
Кроме того я видел и уже что для простых плат используют переходники с USB на Ethernet
Я согласен также что многие не понимают назначения TCP/IP стека и пытаются использовать болшую чем нужно функциональность для своих приложений
Если интересно давайте четко соберем требования и я как бывший технический редактор сформулирую и оформлю их - и уже тогда все будет ясно = можно даже статью будет написать




Тема очень интересная - мне кажется что быстродействие отнюдь не самая большая ценоость в решении на USB или Ethernet
Кроме того я видел и уже что для простых плат используют переходники с USB на Ethernet
Я согласен также что многие не понимают назначения TCP/IP стека и пытаются использовать болшую чем нужно функциональность для своих приложений
Если интересно давайте четко соберем требования и я как бывший технический редактор сформулирую и оформлю их - и уже тогда все будет ясно = можно даже статью будет написать



Вот мне кажется многие не знают что проще использовать 2 Ethernet порта и Ethernet коммутатор 4x 100 и 1x 1000 на выходе чем разбираться с Gigabit Ethernet
посмотрите что за потоки данных вы создаете и создавайте их на разных портах

Подведу очередные итоги обсуждения:


К сожалению, вынужден констатировать, что:
Вопрос 1 - остался без ответа (а сейчас для меня он архиважный),
Вопрос 2 - освещён только со стороны трудоёмкости разработки решения (сторона очень важная, я бы даже сказал ключевая), но необходимо всё-таки ответить на вопрос "А нужен ли вообще TCP/IP ??! И чего полезного он действительно может дать ?", т.к. если особой пользы от TCP/IP нет (а пока я склоняюсь к этой мысли), то при обсужденных трудозатратах на его освоение/поддержку тратиться жалко.
Вопрос 3 - можно считать более или менее хорошо обсужденным.

Пока думаю, что воспользуюсь Virtex5 Gigabit Ethernet MAC (по сравнению с Virtex4 у Virtex5 немного дешевле встроенная блочная память). Использовать PowerPC не хочу, может и ошибаюсь, конечно, но думаю, что проще набросать несколько несложных FSM. чем разбираться с EDK... В крайнем случае, если появиться ощущение, что я заблуждался, то воспользуюсь MicroBlase; конечно такое решение хуже встроенного PowerPC с прямым интерфейсом к Ethernet MAC.

Соединения пока планирую делать точка-точка (т.е. от моего комплекса в специально зарезервированную сетевуху).

Поэтому сейчас стоит проблема выбора конкретной микросхемы, сейчас в возможных вариантах стоят XC5VSX35T-1FF665C и XC5VLX20T-1FF323C (на случай использования PowerPC XC5VFX30T-1FF665C).
SX35T - привлекает неплохим количеством встроенной блочной памяти (заметно более дешёвой, чем у всех остальных представителей VIrtex5), цена в 20 килорублей (практически максимальная розничная цена) несколько омрачает прелести применения этого кристалла - но т.к. оная ПЛИС требуется только одна на весь комплекс, то терпимо.
LX20T - привлекает минимальной ценой среди Virtex4/5 с Ethernet MAC (такая ПЛИС стоит в 2 раза меньше, чем SX30, но и ОЗУ в ней в 3.2 раза меньше), а т.к. встроенной блочной памяти мало, то необходимо цеплять что-то внешнее.

Теперь новая пачка вопросов (в добавление к неотвеченному вопрос 1 из предыдущей пачки):
1. Применение SX35T позволит хранить данные на 25мс (при 15МБайтном потоке). Достаточно ли этого времени, чтобы гарантировать устойчивую передачу данных в Windows XP ?
2. Какой должен быть размер буфера (в мс), чтобы гарантировать устойчивую передачу данных в Windows XP (и где это можно прочесть) ?
3. Если использовать внешную память, то что лучше использовать ? (с динамической памятью пока не работал, да и что-то не тянет,.. а может зря ?)
4. Какие "неочень дорогие" микросхемы двухпортовой памяти (али даже готового FIFO) можете посоветовать. От двухпортовой памяти требуется иметь один порт для записи, второй - для чтения.

С прочтения стандартов - 802.3, а затем изучении того, что такое MAC и с чем его едят.

Верно, TCP/IP в первую очередь нужен для выхода в сети, построенные на этом протоколе. У Вас же своя собственная сеть, для которой TCP/IP не нужен, а нужен лишь какой то свой простой механизм контроля целостности и доставки с ретрансмитами.


Я бы поставил внешнюю SDRAM. Так, на всякий случай. 25 мс это маловато.

Прочесть - нигде. Это зависит исключительно от того, что крутится под этой ОС и на сколько корректно оно написано. Сколько... Я бы сделал 100 мс минимум. Так как большой буфер это просто и быстро, а вот отладка и поиск того, что вдруг тормозит, это сложно, долго и муторно.

DDR/DDRII с готовой коркой.

не надо это. Динамика ваши потоки через один порт 10 раз успеет.

PS.
Ethernet MAC можно и в почти любой спартан сунуть. Эт Вас обманул кто-то, что Eth MAC можно сделать только на какой-то части виртексов. Скорее всего речь про PHY, так PHY внешний значительно проще и дешевле, чем юзать монстроПЛИС.

Я начинал с учебника по TCP/IP для студентов. И там сразу обнаружил форматы фрэймов Ethernet , и всех специальных управляющих пакетов. Этого мне оказалось достаточным для самостоятельной работы с пакетами в FPGA. Стандарты осваивать не советую- утонете в малосущественных деталях. В стандарты лазить только по четко сформулированным вопросам, но не для начального ознакомления.
Мне представляется, TCP был разработан для связи на дальние растояния, когда пакеты путешествуют через маршрутизаторы и роутеры, могут теряться по дороге и перепутываться. Если же речь идет о локалке на обычных свитчах, TCP безусловно излишне сложен. Лучше подходит UDP или RAW пакеты. Самое простое и быстрое в реализации на FPGA- это RAW пакеты. Hо тут возникнут сложности со стороны OС ПК, например в виндах. UDP чуть сложнее за счет необходимости еще в протоколе ARP, но зато в каждой OC ПК вы найдете готовый компонент клиента или сервера. Я лично выбрал UDP вариант, как оптимальный по трудозатратам.
Для организации потока данных от периферии я использовал STR912FAW44- это ARM-9 c Ethernet-100 на борту. И добился потока UDP-пакетов в ПК производительностью 86 Мбит/сек. FPGA не потребовалось.
Это совершенно необязательно. UDP и RAW пакеты нормально ходят по сети через свитчи.
Зачем буфер? Как заполнили пакет в памяти данными, так и отправляйте. Он уйдет быстрее, чем сформируется новый пакет. Пропадание пакетов в XP зависит от скорости компа, от типа сетевухи, от типа шины этой сетевухи, от параллельно выполняемых задач. Hа скорости 50 Мбит/сек на моем стареньком и примитивном ПК ни один UDP пакет не пропал (проверялось снифером).
Вполне хватило встроенной SRAM на борту STR912. Внешняя память не потребовалась.

Да, а что Вас так ксилинксом приплющило? Ведь есть отличные более-менее бюджетные микросхемы, поддерживающие физику 1G Eth - LatticeECP2/M, Arria GX

Microblaze тоже делается через EDK и у него тоже есть прямой интерфейс к MAC. И разобраться с EDK в принципе не сложнее, чем делать простенькие FSM. А в вашем случае я не думаю, что FSM будут на самом деле простыми.

Дело в том, что настолько я успел проглядеть внутренние соединения Virtex5FX, у PowerPC есть аппаратная шина к Ethernet MAC (или я заблуждаюсь ?).

Начну делать - увижу что необходимо, тогда и решу. Пока вариант с MicroBlase я не отбрасывал.

Сейчас изучаю решение соседей... и в нем не используются RocketIO от Virtex4/5 (а я почему-то думал, что именно его то и прийдется использовать), если они действительно не нужны, тогда попробую уйти на заметно более дешёвый на Spartan3E/A. О полученном решении обязательно сообщу.


Как обычно с меня требуют решение быстро и с первого раза (совсем работодатель обарзел, привык, что все мои платы для него (9 шт. на каждой по паре ПЛИС - ну не работаем пока с BGA...) работали с первого варианта разводки). С Xilinx работаю около 8 лет, вроде достаточно хорошо работаю, поэтому и плющит, и колбасит (кроме как от их цен); а со средой Lattice пока ну нету времени разбираться, но ничего против этих ПЛИС не имею, и если появиться небольшой передых погляжу на них очень внимательно.

Странно вы решаете эту проблему.
Траблы у вас в PC, а решить их хотите со стороны внешнего железа.
Так как вы подошли к вопросу, так не решают.
Нужно знать точно кто потребитель данных.
Если это системный IDE диск, Win GUI то ловить тут нечего, ваш поток будет тормозить по любому.
И если у вас другого ничего нет (ну там RAID-ы), то выход может быть в балансировании нагрузки на уровне IP маршрутизаторов или VLAN свитчеров.
Т.е. вы применяете два и более компов для записи своего потока, а маршрутизатор по IP или по тэгу VLAN селектирует какой пакет на какой комп.
Посмотрите в ветке про процессоры PowerQUICC, в них что-то есть для данной проблемы.
Т.е. они заданный вами поток точно разрулят. Правда удовольствие не для любителей.

Дальше опять вопрос в том как же вы собираетесь дальше свои данные хранить и индексировать.
Если примените просто Ethernet пакеты то их не поймет никакой движок real-time баз данных.
Если не примените TCP, то можете оказаться зависимым от технологии свитчеров (блокирующие/неблокирующие, c Flow control или без), и это создаст большие сложности при развертывании вне вашей лаборатории.
Далее было бы умным поверх TCP еще использовать прикладной уровень поскольку потом данные придется когда нибудь агрегировать и делать это скорее всего специализированным софтом который для таких целей использует собственные форматы данных.

Вообщем проблемы железа тут только цветочки.

Если внимательно разуть глаза, то можно заметить, что "Проблемы" не просто в PC, а в отмирании PCI 32bit 5V (PCI v2.3) в этих самых персональных компьютерах (т.е. именно в железе)... Ну а в какай области проблема - в такой естественно и решается.


Читаем внимательно:

Нетрудно догадаться, что применение самопальной PCI платы и непрерывное гладкое графическое полноэкранное отображение врятли будут сдруживаться с какими-либо стандартными программами, а посему логично предположить, что используется какая-то своя специализированная программа. Для исчезновения дискуссий не связанных с темой обсуждения сразу скажу, что данные этой программой успешно накапливаются сотнями гигабайт в своей "базе данных" (если это так можно назвать). Да и не просто накапливаются, но и достаточно хорошо компрессируются, и с выборкой данных из этой груды тоже никаких проблем нет.


Выражу своё резкое несогласие:
1. Поток в 15МБайт/с для HiperTransport/PCI-E (основных коммуникационных артерий современного PC) - это просто смех.
2. Если правильно подбирать железо, то пишет на HDD хорошо (почую, что будет зашиваться один серверный винчестер - поставлю два... и в RAID их).
3. Программы тоже надо уметь писать, если пользовать DirectX и (или) OpenGL (а у нас есть варианты программы для обоих), то даже под Windows графика не тормозит, да и грамотно организованная многопоточность хорошо помогает на современных процессорах (2 и более ядерных). В ПЛИС страшно посчитать количество "так сказать" параллельных потоков, почему же тогда параллельное программирование для CPU считается чем-то из ряда вон выходящим ??!

Я не собираюсь хранить, а уже храню:

Ну да, с увеличением потока понадобится поставить не 500ГБ винчестер, а наверное пару то 1ТБ (и в RAID их), ну а если заказчик захочет ещё и надежности побольше (чего, к моему удивлению, за 10 лет работы с оным ну никак не отмечалось), то поставлю 4 HDD по 1-2ТБ.

Вот чтобы не было всех этих проблем:


Для того, чтобы не возникало ненужных вопросов - комплекс специализированный. На территории Российской Федерации их требуется всего около 100 шт, естественно конкуренты не дадут занять всю нишу. Железо, в т.ч. и для PC, работающего на объекте подбирается только производителем комплекса.

P.S. Ваши замечания могу считать справедливыми только если Вы по ошибке приняли 120Мбитный поток, за 120БМайтный поток. Но 120БМайтный поток данных через одиночную Gigabit Ethernet линию никак прокачать не удастся.

Вопрос ведь стоял не "в куда" залить данные, а какбы это так поудобнее их выпихнуть из железяки, чтобы уж очень сильно не напрягаться.

Вы хоть ПРИМЕРНО представляете себе, сколько времени уйдет у этого "готового TCP/IP Linux" на эту самую перепередачу? Ни о каком ровном многомегабитном потоке и речи идти не может, если встретится сбой. В реальности уровень ошибок на этих десятках метров и тем более при соединении точка точка будет ничтожен и соответственно или с этим мириться или делать заточенные под реальное время системы котроля, препередачи или избыточного кодирования. Использование штатных реализаций TCP/IP есть бред, если только за ними нет больших буферов на передачу на секунды и соответственно многократного запаса по пропускной способности канала.

Я Вам уже объяснял, что трансиверы нужны, если Вы не хотите внешний PHY. Если хотите внешний PHY - трансиверы не нужны.

Просмотрев Virtex-5 FPGA Embedded Tri-Mode Ethernet MAC User Guide я пришел к выводу, что если необходимо работать с медными проводами, то необходима внешняя PHY, а RocketIO (без HPY) может использоваться только для работы с оптическим приемопередатчиком (1000BASE-X). Надеюсь я всё правильно понял ?
Ну а коли в режиме GMII частоты более 125МГц не используются, то можно брать практически любую недорогую ПЛИС.

Если я в чём заблуждаюсь, то прошу меня поправлять (сейчас приходится много чего читать, а после детального прочтения задень более 150 страниц на нерусском, ум за разум заходит к вечеру...)

>Для того, чтобы не возникало ненужных вопросов - комплекс специализированный. На территории Российской Федерации их требуется всего около 100 шт, естественно конкуренты не дадут занять всю нишу. Железо, в т.ч. и для PC, работающего на объекте подбирается только производителем комплекса.

С таким "ценообразованием" можно взять любую ПЛИС средней жирности, подрисовать к ней два доставаемых гигабитных PHY, DDR SDRAM для синтезируемого контроллера. И дело сделано.

По поводу того, как завести этот "колхоз" - зависит от привычности среды разработки. Для Альтеры я подобрал всё типовое и готовое. Даже стыдно, ни строчки своего кода для ПЛИС. Скорость 114 МБ по UDP в одну сторону, не помню, с заголовками кадров IP/UDP или без.

В деле передачи данных из ПЛИС лимит пропускной способности на практике (вроде бы, не углублялся) задаётся межкадровым промежутком (IPG).
Вот куда поток пойдет далее - это вопрос. Приходилось увеличивать буфер стека TCP/IP.

Кстати, как дружат SFP модули с сетями, через них IP гонять можно? Не могу пока проникнуться этими SFP.

Все так, трансивер -> SFP -> волокно. Если медь, однозначно внешний PHY.


IP можно даже через RS-232 гонять, не то, что через любой транспорт, поддерживаемый SFP.

Не подскажете, а что типовое было на IP и UDP? Нашёл только у альтеры "Video Over IP Reference Design", там есть такие модули,
но где добыть, не вижу. Или ещё что-то есть?

По поводу USB переходников, не всё так просто.

боюсь, что в случае USB-IDE вашей плис придётся прикидываться дисковым устройством и в ней придётся реализовать хотя бы часть протокола ATA... т. е. как мин. его почитать.

по поводу CY68013 сейчас начаты поставки универсального мостика FT2232H в котором реализовано много разных интерфейсов, вплоть до эмуляции шины 8051 на частоте 30 Мгц.
у меня сейчас стоИт похожая задача и я почитал про эту микруху. всё вроде бы хорошо. имеется драйвер и дллька с описанным АПИ. но увы, мне решение не подошло. у меня жёсткие ограничения на стоимость и я могу поставить максимум это СПЛД Альтера 3128 или что то подобное. второе ограничение, это время реакции на переданную команду. отклик должен быть не позже нескольких микросекунд. реально USB решение даже на 480мб/сек похоже не позволяет этого сделать. во всяком случае, используя готовые мостики.

дело в том, что все передачи на шине начинаются по команде хоста. поскольку шина физически это одна витая пара, то двунаправленная передача не возможна. хост обязательно должен послать команду чтения девайса. всем занимается планировщик виндоус, а он работает от 1мс таймера. в АПИ есть параметр времени опроса и минимальноработающее значение состовляет 2мс.
кроме того, в баре мод на хай спид блоки имею размер 512 байт только. это означает что по приходе команды чтения ваш буфер должен быть заполнен не менее чем на 510байт (2байта служебных). если такого не случиться, то транзакция завершится с ош. а контроллер девайса (FT2232) сам отловит таймаут по умолчанию через 16мс (время тоже программируется, но с шагом 1мс)

резюмируя, протокол USB (пусть и Hi-Speed) заточен на на передачу потоков всегда по инициативе хоста. реакция на событие в конечном устройстве реально может последовать через 2мс (независимо от скорости). при изхронной передаче возможные скорости реально до 40-45мб/сек, но надо быть готовым к буфферизации данных на интервал до 2мс. кроме того в изохронном режиме протокол реализует только обнаружение ош. передачи. повтор передачи испорченных данных нужно делать самому. и он будет имет большой лаг (не менее 2мс)

вот такие есть ограничения...
если они вам не мешают, то посмотрите подробнее.

вообще, я тоже советую эзернет. мак левел можно реализовать в плис, а физический (PHY) сейчас реализуют даже в розетках. даже микруху подбирать не надо. я это совсем недавно видел в описании демоплат на атмеловские 32 бит. проц.

Представляю. Нисколько, если настроить все на работу по DMA.


Почти так. Еще RocketIO умеет 1000BASE-CX (но вам это вряд ли пригодится), а также, что несколько более интересно, SGMII. Что же касается недорогой ПЛИС - то все так, лишь бы еще вписалось по емкости.

NIOS2.
Протоколы IP и UDP реализованы программно в т.н. "наивной" манере, когда все уровни TCP/IP спрессованы в одну функцию. Эту наивность можно перенести в цифровой автомат, если нужно.

Контрольную сумму UDP можно занулить, но возместить это циклической суммой в данных UDP.

Кривое выравнивание протокола UDP (16 бит) возмещается двумя первыми пустыми байтами в данных UDP, после чего остальные данные сами выравниваются по 32 бита.

Высокая скорость передачи кадров достигается использованием контроллера DMA. В моем случае это был встроенный в сам MAC DMA-мастер.

Порядок байт шины можно поменять в нужную сторону, если он не подходит. Тогда пострадают регистры команд и состояний, что в 100-1000 раз менее затратно.

Если конкретно = NIOS2+Cyclone2+National Gig Phy + MAC IFI GMACII 1.7 + самый простой DDR контроллер Altera.
Лучше попробовать купить Realtek, а то National - "утюг" и по размерам, и по мощности.

Ясно, я то-ж к такому варианту скланялся, теперь больше уверенности - сначала сделать полностью программную реализацию,
а потом, после тестирования при необходимости в железо...
А код сами писали или какой готовый стек брали за снову?
Поковырял тут пару стеков, в принципе если IP-UDP в принципе не сложно, особенно если есть куда подсматривать

Стек сам писал. Это же "наивная реализация" ("НР"), в ней почти ничего нет. Пишется, глядя в логи Ethereal и в бумаги RFC. Рекомендую.

Готовые стеки для микроконтроллера либо велики (lwip), либо это те же "НР", только с многоэтажной оберткой (ucip и OpenTCP). Плюс еще проблемы с выравниванием по 16 бит и многократным копированием.

Все понятно, так и думал, что не представляете - это проблема TCP/IP протокола и возможного упирания в ширину канала, а отнюдь не затрат времени uC-MAC и мантра "DMA DMA.." тут ни причем.

Ага, народ даже не подозревает, что в большинстве случаев DMA работает медленнее программной пересылки.
И действительную пользу от DMA можно получить только в многозадачных решениях под управлением RTOS.
А если думать о масштабировании и разделении потоков, то однозначно надо использовать многозадачный многинтерфейсный стек с мощным процессором сделанным не на FPGA
В данной теме я уверен человек просто никуда не денется и ему придется заниматься масштабированием с расчеплением TCP потоков если надо сделать в сумме больше 100 MBit/s

Никакой самопал на UDP не спасет ситуацию. Сетевая карта перегруженного компа просто молча отбрасывает UDP пакеты.
UDP уровень в стеке TCP/IP нужен для протоколов которые обеспечивают целостность данных на более верхних уровнях, например SNMP или L2TP тоннели.
В данном случае переносить контроль целостности на еще более верхний уровень будет нетривиальной задачей хотя в некоторых случаях есть интересные решения, как тоннель с мultilink PPP поверх UDP делающий один логический канал на нескольких физических Ethernet линиях.
Эта фишка реализована в PowerQUICC на аппаратном уровне! Ваще кода писать не надо!

"Инвайт?" "Просто добавь воды?"

Применение Jumbo- пакетов сильно уменьшают вероятность отбрасывания UDP-пакетов в перегруженном компе.

В нормальных процессорах DMA таки ускоряет пересылку данных. Особенно в синхронных шинах.
Пересылка - последовательность операций ввода-вывода.

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

>И действительную пользу от DMA можно получить только в многозадачных решениях под управлением RTOS

Её успешно получают и в однозадачной среде без РТОС.


>UDP уровень в стеке TCP/IP нужен для протоколов которые обеспечивают целостность данных на более верхних уровнях, например SNMP или L2TP тоннели

Целостность данных в своем протоколе в ПЛИС реализовать можно оптимальным для себя образом, а не так, как в TCP.

Кто хочет, сделает перезапрос потерянных блоков, кто не хочет - блоки потеряет.
У ПЛИС буфер в DDR памяти на весь массив данных спокойно можно сделать.

И потом, что значит, что компьютер не может переварить жалкие 125 Мбайт в секунду из сети? Исправное железо и нормальная программа это исключают.

У автора всё оборудование в одной комнате. Глобально-сетевые навороты здесь не требуются.

Лучше расскажите где вы этот миф прочитали.


Эта логика не работает в коммуникационных процессорах. Надо знать и учитывать правила шинного арбитража.


Не представляю как. Но не будем здесь об этом, а то основная тема погибнет



У этой системы два конца и было сказано о затыках на стороне PC. Значит задача должна облегчаться для PC. Один из реальных стандартных вариантов - multilink


Здесь вы в фантазиях ограничены. Поскольку все диктуется механизмом сохранения данных в PC.
На таких скоростях и с цепочкой буферов на всех устройствах от сетевой карты до CPU и диска может не быть возможности переповторов на уровне приложения.


Такую скорость только iperf умеет показывать на обычном десктопе.


Неплохая комната в 40 м да еще с гальванической развязкой.
Тут суровое пром. применение проглядывает.

Может предложите конкретно, на чём можно сделать кроме FPGA пересылку потока 100 МБАЙТ по гигабиту с гарантией доставки (не голый UDP)?
А то что-то когда доходит до поиска, ничего не нахожу. Заманчиво поставить некий комуникационный проц и не иметь гемора с
реализацией всёго самому на FPGA, но что-то не находится проца, который может взять у моего устройства по локальной шине 100 МБАЙТ и передать по гигабиту с гарантией доставки (не голый UDP).
А то помнится все говорили что ARM за 15$ есть решение, только вот где тот ARM...
Да, и хотелось-бы не что-то абстрактное, а то что реально купить можно. Думаю будет не только мне интересно.

>Лучше расскажите где вы этот миф прочитали

В этот миф смотрю осциллографом и сетевым анализатором. Процессоры DSP и синтезируемый Nios2.
В мире DSP и ПЛИС то, что я говорю о пересылке DMA, никого не смутит.

>>Программная пересылка медленнее хотя бы потому, что разбавлена операциями увеличения указателей и поддержанием работы цикла
>Эта логика не работает в коммуникационных процессорах. Надо знать и учитывать правила шинного арбитража

У нас есть примерно два варианта - Nios/Microblaze или готовый процессор. Применительно к ним эта логика работает.


>У этой системы два конца и было сказано о затыках на стороне PC. Значит задача должна облегчаться для PC. Один из реальных стандартных вариантов - multilink

Сколько PC и сколько линков нужно, чтобы передать 125 Мбайт в секунду? 1 и 1. Сам передавал.
Блин, заболтали. 114 МБ пользовательских данных. 125, если голый сокет.

>Здесь вы в фантазиях ограничены. Поскольку все диктуется механизмом сохранения данных в PC.
На таких скоростях и с цепочкой буферов на всех устройствах от сетевой карты до CPU и диска может не быть возможности переповторов на уровне приложения.

Как может не быть, если приложение всегда способно перезапросить блок данных. Разве что дисковая система не справится, что зависит о потребностей автора. А тогда вопрос не в передаче.

Меня это вообще удивляет, пропускная способность нутра компьютера достигла десятка гигабайт в секунду, а поток опять не лезет.

На точкеNet, конечно, это может и не заработать.

>Такую скорость только iperf умеет показывать на обычном десктопе.

WinSocket + приемный поток + увеличенный буфер сокета (!) показывает такую скорость


> комната
пусть 40 м. Гигабитный Ethernet, пусть и в двух экземплярах, спасет отца русской демократии (с).



>Может предложите конкретно, на чём можно сделать кроме FPGA пересылку потока 100 МБАЙТ по гигабиту с гарантией доставки (не голый UDP)?

Да, и о гарантиях. Меня всегда интересовало, что будет гарантировать TCP, если вытащить сетевой провод из хаба.
Голый UDP с пользовательким протоколом гарантирует всё, что нужно.

>но что-то не находится проца, который может взять у моего устройства по локальной шине 100 МБАЙТ и передать по гигабиту с гарантией доставки (не голый UDP).

Проц такой есть. У AD это TigerSharc TS20x, у Техаса что-нибудь в духе C64xx. Главное, чтобы была внешняя шина 100-125 МГц в синхронном режиме. Наличие последовательных портов с LVDS у процессора тоже сособствует.

Арм за 15 долл здесь не катит.

И не найдете. Поскольку 100 МБАЙТ по гигабиту получали только в лабораторных условиях с голыми Jumbo-пакетами размером до 16К.
Про ARM за 15$ говорили в контексте скорости 86 МБИТ/СЕК на голых UDP пакетах.

Так хоть что близкое найти. Только PowerPC вот советовали, но там проц 400MHZ, явно не хватит.
Про максимум, вы тесили или как? Слышал что 2 компа выжимают под 100мбайт без напряга. Сам ещё не тестил, но проверю.


Да тут в соседней ветке AlexandrY советовал ARM с Гиг MAC-ом, но как-то напряг с такими.
Вот и хотел узнать, где такие берут.

Народ, вы все позабывали то, откуда берутся данные. Собрать их оттуда без ПЛИС решения вообще не видно.

Точно.

Сейчас прорабатываю варианты реализации - какую Eth PHY проще купить (и использовать), какое внешнее ОЗУ легче достать и т.п. Но архитектура уже более или менее определилась: две груды LVPECL линий заходят на Spartan-3AN (благо, хоть это и не документированно для этой ПЛИС, но при желании, можно собрать LVPECL выходы аналогичные "Virtex-E LVPECL"), благополучно преобразуются в 2 потока (данных и команд), далее запихиваются во внешнее ОЗУ. При освобождении Eth Gigabit MAC, данные из ОЗУ заталкиваются в MAC, и в служебном массивчике метятся как переданные (но пока еще без подтверждения о получении), после получения такого подтверждения для конкретного пакета, место, занимаемое в ОЗУ этим пакетом, считается свободным. Ну и в таком духе дальше принимать/передавать данные.

Еще раз напомню, т.к. не прозвучало достаточных (для меня) доводов: почему надо пухнуть с поддержкой UDP/IP, то предполагаю обойтись голым Ethernet'ом и соединение сделать по меди аппаратно точно-точка (без коммутаторов и прочей дряни).
Также не может не радовать и то, что выступившим удалось передать более 100МБайт/с по Gigabit Ethernet, мне же всего-то требуется только 15МБайт/с (или, если очень захочется заказчику увеличить количество датчиков - ну никак не более 30МБайт/с - только для меня остается загадной: нафига ставить еще больше датчиков - их и так в полноценной системе их дофига, а обычно заказывают с 50%-60% каналов сбора данных).

Один из плюсов UDP - стандартные возможности програмирования, например в винде стандартно можно работать только с TCP и UDP, если ниже, придётся использовать WinPCap: http://netgroup-serv.polito.it/winpcap/
Если WinPCap допустим, можно и без UDP попробовать.


И к чему склоняетесь?


Кстати, как-то пролистал стандарт на TCP, и меня терзают смутные мысли, что если начать делать такой протокол, получится почти тот-же TCP, только без уровня функций пользователя. Ни кто не пробовал, насколько это так?

Есть ещё древний RDP (rfc908+rfc1151):

На самом деле все не так сложно и ограничено в выборе. Стандартные возможности программирования позволяют без проблем написать свой любой протокол, который будет работать с NDIS-уровнем, и представляться в юзермоде хоть через те же обычные сокеты, что и TCP/IP, хоть как-то по своему. Тоже мне сверхзадача. И никакие пкапы не нужны.

Я в общем тоже считаю, что никакие UDP там не нужны. Голый Eth уровень, и своя удобная лично для себя система контроля доставки и ретрансмитов (на UDP ее кстати тоже реализовывать, так что UDP это просто лишняя возня в ПЛИС)

Хотелось бы продолжить данную тему.

Есть желание реализовать гарантированную доставку данных на базе fast Ethernet от внешнего устройства на базе FPGA на компьютер с максимально возможной скоростью.

В распоряжении имеется демо-плата (Spartan 3e starter kit). На ней соответственно имеется: FPGA Spartan 3e500, Ethernet phy LAN83C185, память DDR (32M x 16).

После ознакомления с данной темой возник ряд вопросов:

1) Реализовывать протокол UDP + IP, по-видимому смысла нет.
2) Соответственно стоит использовать пакеты Ethernet. На этом месте возникает первый вопрос: какой тип пакета использовать (Ethernet II, IEEE 802.3 или IEEE 802.2)? В голове сейчас некоторая каша, поэтому сильно не пинайте за, возможно, глупые вопросы.
3) На каком уровне обеспечивать гарантию доставки данных? Т.е. Например, я решил передавать голые кадры Ethernet II. Тогда, на сколько я понимаю, потребуется придумать некоторый свой заголовок, который будет, например, нести информацию о номере посланного пакета. На компьютере программа-сервер будет принимать пакеты и при обнаружении пропуска будет запрашивать внешнее устройство повторно передать потерянный пакет. Т.е. гарантия доставки выполняется приложением, принимающим данные? Либо есть какие-либо встроенные в операционную систему средства (продолжение вопроса в п.4)?
4) Как на компьютере принимать голые пакеты (под Windows и под Linux)? Использовать библиотеку pcap (winpcap/libpcap)? Или достаточно встроенных в операционную систему средств?
5) Стандарт IEEE 802.2 описывает LLC. После беглого пролистывания стандарта решил, что LLC type 3 как раз то, что я бы хотел реализовать: гарантированная доставка данных без установления соединения. Вопрос вот в чём: есть ли какая-то поддержка данного механизма в операционных системах (windows, Linux)? Т.е. есть ли встроенные в операционную систему средства, которые облегчили бы создание соединения, гарантирующего доставку данных?
6) На сколько я понимаю, реализация в лоб схемы ARQ (automatic repeat request: отправили пакет, дождались подтверждения, отправили следующий, либо если не дождались - повторно отправили текущий) приведет к получению мизерной скорости передачи данных. Как с этим бороться? Отправлять непрерывно пакеты, храня их буфере до получения подтверждения? Есть ли примеры реализации, доступные для просмотра в интернете? Есть ли другие алгоритмы?

Для начала имеет смысл озвучить количественный эквивалент выражения "максимально возможная скорость". :-)

Не менее 80 мбит/с

А... так речь всё-же о пропускной способности. А то первый пост был м... неоднозначным.
А чем так нравится ethtrnet? Или подразумевается большая (больше 3-х метров) удалённость девайса от компьютера? Я это к тому, что есть много микросхем USB интерфейса, где всё уже готово. Я сам достигал где-то 160-200 мбит/с с применением ez-usb от cypress-а.

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

Уточню исходный вопрос. На данный момент планирую использовать голые Ethernet фреймы (формат кадра - Ethernet II). Главная сложность продумать реализацию алгоритма гарантированной доставки данных.

Сам алгоритм описан в данном посте.



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

Может быть, где-то есть примеры реализации похожих механизмов передачи данных?

'Гарантированная доставка данных' - это TCP или нечто аналогичное по сложности. Можно взять соотвествующий RFC (по TCP) и выкинуть из него все ненужное.

Если используете BASE 100-TX "точка в точку", без свитчей, в пределах 100м, то заморачиваться на предмет гарантированной доставки данных не следует вообще. Что же касается RAW-пакетов, то возникнут приличные софтовые проблемы на стороне PC. В то время как для UDP существуют готовые и многократно проверенные компоненты в С-Builder и Delfi. Советую UDP пакеты, которые отличаются от RAW только размером хидера,- это для FPGA не проблема. Зато на стороне PC получите громадный выигрыш от стандартного решения.

В данной ветке проскакивало упоминание о "Video Over IP Reference Design". Не могли бы добрые люди скинуть в закрома данный проект. Кит для него куплен. По опыту - тут получить проект быстрее, чем от Альтеры.


--------------------------------------------
Проект найден. Вопрос снят.