[blackfin 22]

Может еще какие предложения есть ?

Купить готовое: PCI/PCIe Expansion System

PicoDev: Область применения..

[DmitryR 0]

1. FPGA + ARM9 (как я понял, поддержку TCP/IP в ARM9 прийдётся делать самому, али есть готовое и доступное решение ?).

2. V4 Ethernet MAC (+ MicroBlase with LwIP - для поддержки TCP/IP).

Может еще какие предложения есть ?

 

Пока, второе предложение кажется более близким т.к. работаю с ISE давно и очень плотно (есть надежда, что и с EDK очень долго разбираться не прийдется), а вот про ARM только приходилось иногда слышать...

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

[SM 0]

IMHO тогда так:

 

внешний PHY, например RTL8211.

ПЛИСина - навроде Cyclone-II или III, только ксилинкс, сорри, не знаю, кто там аналогичен.

МАК-корка - навроде CAST Gigabit Lite , в альтере займет ~2К лутов, значит в ксиле примерно 1.5К слайсов.

 

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

 

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

 

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

[DmitryR 0]

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

 

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

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

[jojo 0]

Внешний PHY 10/100/1000

Древний, зато купить легко

 

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

 

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

[kuzis 0]

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

[SM 0]

Остается написать драйвер устройства сбора данных для Linux - и все.

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

[DmitryR 0]

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

[kuzis 0]

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

 

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

[SM 0]

ИМХО - новую программу написать легче, чем изготовить новое железо.

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

 

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

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

[islavv 0]

Эквивалентно - скажите, как сделать так, что-бы ничего не делать? Дайте мне мои любимые протезы :(. Ну не нужны они. В данном случае для Ethеrnet, который Вы судя по Вашей реакции не отличаете от TCP/IP :( на самом деле даже UDP/TCP/IP не нужны - голые фреймы, максимум с чем-нибудь типа IEEE 802.3 в заголовке. Со стороны PC RAW Socket и вперед.

 

1. USB в даном случае нужно пихать не в FPGA а куда подальше...

2. Реализация MAC Ethernet вполне обыденное дело, да и из внешние навешивать никто не мешает, не говоря уже о том, что просто берется любой 32битник по вкусу с MAC на борту.

3. И никаих проблем с совершенно ненужными USB наворотами, "сертификациями", "драйверами" и их конфликтами.

 

Вы хоть сами-то поняли что сказали? Если под "проблемой" понимается принципиальная возможность доступа из локальной сети, то ставите отдельный Ethernet контроллер в PC и получаете точка-точка.

 

Тема очень интересная - мне кажется что быстродействие отнюдь не самая большая ценоость в решении на USB или Ethernet

Кроме того я видел и уже что для простых плат используют переходники с USB на Ethernet

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

Если интересно давайте четко соберем требования и я как бывший технический редактор сформулирую и оформлю их - и уже тогда все будет ясно = можно даже статью будет написать

 

 

Эквивалентно - скажите, как сделать так, что-бы ничего не делать? Дайте мне мои любимые протезы :(. Ну не нужны они. В данном случае для Ethеrnet, который Вы судя по Вашей реакции не отличаете от TCP/IP :( на самом деле даже UDP/TCP/IP не нужны - голые фреймы, максимум с чем-нибудь типа IEEE 802.3 в заголовке. Со стороны PC RAW Socket и вперед.

 

1. USB в даном случае нужно пихать не в FPGA а куда подальше...

2. Реализация MAC Ethernet вполне обыденное дело, да и из внешние навешивать никто не мешает, не говоря уже о том, что просто берется любой 32битник по вкусу с MAC на борту.

3. И никаих проблем с совершенно ненужными USB наворотами, "сертификациями", "драйверами" и их конфликтами.

 

Вы хоть сами-то поняли что сказали? Если под "проблемой" понимается принципиальная возможность доступа из локальной сети, то ставите отдельный Ethernet контроллер в PC и получаете точка-точка.

 

Тема очень интересная - мне кажется что быстродействие отнюдь не самая большая ценоость в решении на USB или Ethernet

Кроме того я видел и уже что для простых плат используют переходники с USB на Ethernet

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

Если интересно давайте четко соберем требования и я как бывший технический редактор сформулирую и оформлю их - и уже тогда все будет ясно = можно даже статью будет написать

 

 

Естественно с таким потоком Ethernet-100 не справиться, соответственно прийдется использовать Gigabit Ethernet.

2. Необходимо иметь возможность в будущем увеличить поток в 2 (или 2.5) раза, т.е. до 240Mbit/s (или 300Mbit/s - это крайняя цифра, выше неё прыгать не собираемся).

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

посмотрите что за потоки данных вы создаете и создавайте их на разных портах

[Beby 4]

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

 

Теперь вопросы:

1. С чего лучше начать знакомство с Ethernet ?

2. Что лучше использовать чистый Ethernet или еще реализовывать и TCP/IP (в чем достоинства/недостатки обоих решений) ?

3. Исходя из 2, какие микросхемы/сборки лучше использовать ?

К сожалению, вынужден констатировать, что:

Вопрос 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) можете посоветовать. От двухпортовой памяти требуется иметь один порт для записи, второй - для чтения.

[SM 0]

Вопрос 1 - остался без ответа (а сейчас для меня он архиважный),

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

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

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

 

1. Применение SX35T позволит хранить данные на 25мс (при 15МБайтном потоке). Достаточно ли этого времени, чтобы гарантировать устойчивую передачу данных в Windows XP ?

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

2. Какой должен быть размер буфера (в мс), чтобы гарантировать устойчивую передачу данных в Windows XP (и где это можно прочесть) ?

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

3. Если использовать внешную память, то что лучше использовать ? (с динамической памятью пока не работал, да и что-то не тянет,.. а может зря ?)

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

4. Какие "неочень дорогие" микросхемы двухпортовой памяти (али даже готового FIFO) можете посоветовать. От двухпортовой памяти требуется иметь один порт для записи, второй - для чтения.

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

 

PS.

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

[aprox 0]

Вопрос 1 - остался без ответа (а сейчас для меня он архиважный),

Я начинал с учебника по TCP/IP для студентов. И там сразу обнаружил форматы фрэймов Ethernet , и всех специальных управляющих пакетов. Этого мне оказалось достаточным для самостоятельной работы с пакетами в FPGA. Стандарты осваивать не советую- утонете в малосущественных деталях. В стандарты лазить только по четко сформулированным вопросам, но не для начального ознакомления.

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

Мне представляется, TCP был разработан для связи на дальние растояния, когда пакеты путешествуют через маршрутизаторы и роутеры, могут теряться по дороге и перепутываться. Если же речь идет о локалке на обычных свитчах, TCP безусловно излишне сложен. Лучше подходит UDP или RAW пакеты. Самое простое и быстрое в реализации на FPGA- это RAW пакеты. Hо тут возникнут сложности со стороны OС ПК, например в виндах. UDP чуть сложнее за счет необходимости еще в протоколе ARP, но зато в каждой OC ПК вы найдете готовый компонент клиента или сервера. Я лично выбрал UDP вариант, как оптимальный по трудозатратам.

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

Для организации потока данных от периферии я использовал STR912FAW44- это ARM-9 c Ethernet-100 на борту. И добился потока UDP-пакетов в ПК производительностью 86 Мбит/сек. FPGA не потребовалось.

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

Это совершенно необязательно. UDP и RAW пакеты нормально ходят по сети через свитчи.

2. Какой должен быть размер буфера (в мс), чтобы гарантировать устойчивую передачу данных в Windows XP (и где это можно прочесть) ?

Зачем буфер? Как заполнили пакет в памяти данными, так и отправляйте. Он уйдет быстрее, чем сформируется новый пакет. Пропадание пакетов в XP зависит от скорости компа, от типа сетевухи, от типа шины этой сетевухи, от параллельно выполняемых задач. Hа скорости 50 Мбит/сек на моем стареньком и примитивном ПК ни один UDP пакет не пропал (проверялось снифером).

3. Если использовать внешную память, то что лучше использовать ? (с динамической памятью пока не работал, да и что-то не тянет,.. а может зря ?)

Вполне хватило встроенной SRAM на борту STR912. Внешняя память не потребовалась.

[SM 0]

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