Купить готовое: PCI/PCIe Expansion System
PicoDev: Область применения..

Мне кажется, что именно второй вариант вам подойдет - вы в один Virtex-4 все затолкаете вместе со сбором данных. Причем делать Microblaze не придется, так как в тех Virtex-4, где есть MAC - есть и PPC405. Можно также посмотреть на Virtex-5 (ведь с анонсом Virtex-6 четвертое семейство становится уже позапрошлым) - там есть MAC без процессора, а где есть процессор - он уже PPC440.

IMHO тогда так:

внешний PHY, например RTL8211.
ПЛИСина - навроде Cyclone-II или III, только ксилинкс, сорри, не знаю, кто там аналогичен.
МАК-корка - навроде CAST Gigabit Lite , в альтере займет ~2К лутов, значит в ксиле примерно 1.5К слайсов.

Ну и остальное - как zltigo советовал, передача голыми ethernet пакетами, контроль целостности и повторы передачи прикрутить самому.

Никаких ембеддед-процессоров, ни хард, ни софт, ну и соотв. никакого ембеддед-софта.

К сожалению удобных мостов 1G Eth -> локальная шина я не знаю. Но если такой есть - то разумеется найти и применить

Я вот только думаю, что нормальная реализация контроля целостности и повтора передачи займет столько усилий, что отсутствие ембеддед-процессоров будет очень быстро проклято. А в EDK все готовое: проц, MAC, Linux. Остается написать драйвер устройства сбора данных для Linux - и все.

Внешний PHY 10/100/1000
Древний, зато купить легко

http://www.national.com/mpf/DP/DP83865.html

к нему ядро вроде IFI GMAC 1.7 или ещё какое есть под выбранное семество ПЛИС.

Наши делали так. Интеловский сетевой процессор. На нем раскручивается линух, который и реализует стандартные протоколы, в том числе и 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