Ситуация
Нужно сделать железку (плату), которая могла бы общаться с ПК по Ethernet в целях передачи:
- управляющей информации из ПК в железку (менее 1 Мб/с);
- информации о состоянии железки в ПК (менее 1 Мб/с);
- полезной информации из железки в ПК (~10 Мб/с);
- больших объемов информации (в планах несколько ГБ), накопленных на плате, не в режиме реального времени из железки в ПК, по его запросу.
Для указанных целей вполне подходит 100 Мб Ethernet.
Ethernet выбран как достаточно скоростной интерфейс, позволяющий подключить к компьютеру несколько таких плат.
На плате единственный управляющий элемент - это ПЛИС. Ориентировочно XC5VSX50T. Никаких микроконтроллеров и процессоров не планируется.

Мнение
Один из подходов в такой ситуации: использовать внешний (для ПЛИС) трансивер Ethernet физического уровня и встроенный в ПЛИС MAC-контроллер.
Я так понимаю, имея в руках только кадр MAC-уровня, многого не сделаешь - необходима реализация протоколов. К сожалению, пока не знаком с протоколами сетевого и транспортного уровней, поэтому не знаю всей сложности.
Хотелось бы услышать мнение тех, кто сталкивался с подобными вещами.

Вопрос
Реально ли вообще обойтись без каких бы то ни было микроконтроллеров/процессоров, имея только MAC-контроллер и программируемую логику, для организации обмена данными по сети?
Может быть существуют другие, более оптимальные варианты взаимодействия ПЛИС с ПК по сети Ethernet?

kst
Вопрос по ситуации: кроме FPGA вообще ничего нет? Всяких там FLASH, SDRAM и т.п.
Вопрос по мнению: а почему Вы не желаете использовать какой-нибудь MCU?
Дополнительный вопрос: все приборы будут работать в одной сегменте сети без выхода в другие сегменты?

Приветствую!

Если требуется поддержка стека TCP/IP то совсем без подобия MCU обойтись будет сложно.
Но при этом сам MCU может быть частью FPGA. Для основных функций в принципе даже на ядре типа PicoBlaze (правда програмить только на асме) можно соорудить что-то поддерживающие медленный командный канал (ARP, ICMP , UDP управления и статуса). Большой поток данных при этом можно формировать аппаратно автоматом формируя например UDP пакеты. В свое врем я делал похожее на Spartan3-400 обработка данных с радиолокатора. Правда потом от внутреннего контроллера отказался - так как снаружи поставил ADuC841 в основном из за встроенных ADC,DAC. Выходной поток данных был до 6 Мбайт/сек.

Хотя если не хочется связыватся с MCU -
посмотри сдесь синтезируемый . TCP/IP stack VHDL

Успехов! Rob.

Если на киты посмотреть. Можно lan91c111 задействовать.
На входе например имитируете isa шину.

Тоже интересуюсь данной темой. Есть корыстный вопрос: Нет ли у кого рабочего примера примера посылки UDP пакетов (формирования кадра, расчёта CRC и т.д.) с помощью ПЛИС и микросхемы phy-уровня? И если есть, то могли бы вы им поделиться. Для тестов планирую использовать отладочную плату на spartan3e500.

В данном случае, насколько я понимаю, потребуется достаточно развитое управление MAC уровнем в части приема/передачи/формирования пакетов, поэтому смотрите в сторону связки Microblaze (встраиваемое в ПЛИС процессорное ядро) + MAC + внешний PHY. При этом не потребуется никаких внешних управляющих микроконтроллеров и т.п.

Доброго здравия!

Из моего личного опыта применения для связи ПЛИС и ПЦ наиболее оптимальным оказалось использование внешнего Ethernet PHY к плис и EthernetLite для микроблейза. (готовых примеров в сети предостаточно хотя бы на том же xilinx.com ) Организовывать различные виды tcp/ip стэков тоже конечно можно хоть софтов хоть аппаратно было бы желание, из личного опыта для опознования устройства компьютером можно приделать софтовую обработку ICMP и ARP пакетов , и UDP для связи а остальное просто игнорировать. Обмен по UDP вполне позволит просто работать с пакетами на Winsocketе.

Но вот лично моё мнение: если не нужно организовывать передачи данных в интернет, связывать устройство с удалёным сервером, а нужно только построить простой обмен данными, то
а) обмен данными просто на Ethernet Frame со своей удобной структурой что позволит софтово на микроблейзе быстро и со вкусом паковать и распаковывать пакеты и обойтись без упаковки в пакет с трудоёмкой CRC и т.д.
б)на стороне компьютера ставим всеми любимый winpcap и работаем через его сокет. C ними работают Wireshark бывш. Ethereal, кстати xilinx ставит его для организации Co-Simulation со связью с target по Ethernet
в) При всём этом, если всё аккуратно написать в плис, то 5-7Мбайт в сек получить вполне возможно

Успехов!

Занимаюсь тем же самым. Единственное нО - ИС для phy-уровня содежит в себе и mac-уровень тоже. Пользуюсь WIZnet W5100 - http://www.ewiznet.com. Предыстория - меня попросили взять существущие тест-инструменты, и дать возможность управлять ими дистанционно, через TCP или UDP - им без разницы. Инструменты разработанны нами, и содержут ПЛИС который управляет разной фигней. Я беру схемы существующих плат с плис'ом, и добовляю W5100. Конкретно мне оказалось удобнее использовать TCP для этой задачи, и 10Mbs для меня достаточно. Пользоватся W5100 - совершенно примитивно, выставлять TCP/IP, UDP, keepalive, итд опции тоже легко. Рекоммендую, если у Вас нету жестких требованей насчет скорости.

ИМХО от времени и условий все у вас зависит.

отлаживать логику протоколов класса TCP-IP на проце намного легче чем на фпга.

Если время ограничено и нет человека который вариться в кухне EDK/SOPC то поставте внешний арм(например LPC2478 + бесплатный ничи стек).

Если запас есть то освоите EDK, пригодиться (да и чип у вас толстый). На форуме кстати темы про TCP/IP на микроблейзе были.

Можно конечно использовать опенсорсный проц класса AVR, MSP430, но думаю что по затратам времени это эквивалентно освоению микроблейза ( правда совесть будет более чистой %) )

TCP/IP stack VHDL кстати синтезируемый но проверен авторами на 10 мегабит эзернете.

ЗЫ. Сам использую частично переписанную корку от Igor Mohor.

Удачи!!!

У меня есть отсылка пакетов со скоростью 30 Мб/с TCP, используется спартан3+wiznet3150. Кстати, тоже данные от радара. Весь интеллект уместился в фсм на 24 состояния, полученный переложением на верилог фирменных Си-исходников. Могу намылить верилог, схему и описалово.

Не хочу показаться занудливым, но есть мнение, что 11 Мб/с через 100 Mbit ethernet может и не пролезть, особенно для протоколов верхнего уровня (могут начаться проблемы со стороны ПК). Я бы рассчитывал на 8-9 Мб/с как реальный максимум.

Огромное спасибо всем ответившим!

Платка должна быть промышленного исполнения.
На плату планируется ставить оперативку и FLASH.
Никакого интернета и никаких серверов пока не планируется. Конечная система - 4 платы, свитч и 1 компьютер. Все.
Можно даже какой-то самодельный протокол обмена данными придумать, главное - платы уметь различать.
Хотелось бы узнать какой минимум нужно реализовать в ПЛИС, чтобы обмениваться данными между платой и компьютером?

По поводу Microblaze раздумываю, правда сей зверь мне знаком только понаслышке. Хотелось бы узнать, сколько ресурсов может уйти на его реализацию?
И вообще, можно ли как-то спрогнозировать, сколько от ПЛИС откусит все управление Ethernetом в лучшем случае???

Отдельный микроконтроллер ставить - это еще одна отдельная задачка. Плюс на плате придется потесниться. Но тоже, в принципе, вариант.

А вообще есть вариант покупки готовой промышленной процессорной платы с Ethernetом и USB на борту. Тогда нужно будет отлаживать взаимодействие 2х плат - платы с ПЛИС и процессорной платы - по шине, скажем, PCI. Эта задача мне вообще не знакома. Но может быть так проще будет?

Добрый день !
Мы пользуемся следующим набором:

HW - Virtex4FX, внутри PowerPC и железный MAC, собран MPMC3 и LL_TEMAC в режиме DMA, память DDR, системная тактовая и тактовая MPMC 100МГц, тактовая проца - 300МГц.

Стек - доработанная LWIP в режиме SOCKET API.

Передача - 80Мбит по 100Мбит линку.

Получали и 94Мбита при работе MPMC на 200МГц

Может имеет смысл подумать над м\сх контроллера Ethernet совмещенного с процессором ? Например - Mcrel . Тогда Плис только поставщик информации и коммутатор шин, а управление и протоколы за процессором. Несколько смущает могучесть процессора (ARM9) для подобной задачи . но думаю можно найти и более подходящие варианты.

Так ведь это уже говорилось - можно micrel, realtek, я предложил wiznet... Варианты есть.

Есть пример... Совсем тупой и без всякой PHY-микросхемы. То есть RxD и TxD заведены прямо на ПЛИС.
UDP-пакеты принмает/посылает. Больше не умеет ничего. Я с ним пока ещё плотно не возился (хотел к нему ARP-хотя бы прикрутить, чтобы не руками его регистрировать в ARP-таблице компа), время на другое сейчас уходит. Как вода в песок.

Очень интересно было бы взглянуть...

Смотрите...

Предложенные варианты с применением ARM7 или MSP явно не пройдут по скорости, которую хочет получить автор топика. От Микроблейза ждать чудес тоже не стоит. Хорошо если он будет фурычить на 100МГц, но к нему еще я так понимаю прикрутят прерывания и внешнюю периферию, окромя МАС и тоже выйдем на 600-800 кбайт в секунду.
Если ставить внешний MCU уровня ARM9/XScale то пропускную способность получить можно, с програмным обеспечением проблем ни каких, но по своему это решение очень жирное и финансово расточительное.
Но я по своему опыту работы на экстримальные приложения, а-ля милитари, закладывался б именно на такое решение - дорого но дубово. Военные денег не считают. Подняв Linux можно получить любой сетевой уровень.

Посмотрел я протоклы IP, UDP, TCP... не буду я, пожалуй, связываться с отдельными микроконтроллерами/микропроцессорами...
Те возможности, что изначально закладываются в эти протоколы мне нафиг не нужны. А человеческих ресурсов и без того дефицит...

Скорости требуются, на самом деле, не большие. Под Мб я понимал Мбит. Извините, если ввел в заблуждение.

Почитал здесь темки и понял, что возможно работать вообще на низком уровне - с Ethernet-пакетами уровня MAC. Такой вариант вполне подходит.

Если потребуется реализация стека протоколов, задумаюсь о Microblaze. Для обмена служебной информацией быстродействия должно хватить, ибо это будет не в реальном времени. А вот поток данных ~10 Мбит/с возможно надо будет слать в raw-пакетах.

В моем случае , также пришел к похожей идеи. Не хочу никаких контроллеров и процессорв на кристалле. Только mac на логике и PHY на плате. Формируем пакет и отсылаем/ принимаем (собираюсь использовать только UDP ). Сначала хотел с нуля написать по статьям Iosifk mac контроллер , но время стала поджимать.
Из доступного , приведенный выше http://www.itee.uq.edu.au/~peters/xsvboard/stack/stack.htm и кое что на opencores на wishbone. Правда с последней шиной не работал , поэтому не хочется выбирать данный путь из-за недостатка времени.

Что есть еще ?? может что-то пропустил.

Было бы очень интересно. Если за два года оно не умерло

таки видимо, умерло) или уже стало бесценным)))

У меня вопрос по программной реализации.

Есть Actel SmartFusion (хардвареный CortexM3 на борту с Ethernet МАС) eval kit. Сделал UDP, ARP, ICMP протоколы.
Теперь нужно организовать прием/передачу с компУтером.

Я думаю со стороны ПК использовать UDP сокет сервер WinSock2. Хорошо... создаем его, открываем какой нить порт, посылаем байтики.

Теперь, какой должен быть алгоритм со стороны железяки?
Приняли пакет, посмотрели IP адрес и номер порта, если адрес и порт мой, то, соответственно, и байтики тоже)?

Или же у сокетов есть особый протокол? и без ОС или lwIP стека не обойтись?

да, все так

вполне можно обойтись

Возникла проблема:

При соединении точка-точка все работает нормально- пинг идет, UDP пакетики принимаются.
Стоит воткнутся в свич - все, ничего не работает и пинг в том числе.
В сети, у нас, DHCP сервак раздает IP и маску подсети.
ставлю статический IP 192,168,1,110 на компе (192,168,1,111 на железяке) маска 255,255,255,0 - тоже ничего.

Может быть из-за маски проблема? как ее можно учитывать внутри железяки?

ARP точно работает? IMHO без него через простой свич может не ходить

При точке-точке смотрел - ARP ответ приходит! Если бы не приходил пинг бы не работал. верно?

Проверьте на всякий случай - в командной строке (на хосте) наберите arp -a и посмотрите, есть ли в списке ваша плата с правильными MAC и IP
Нет, за ping отвечает ICMP

МАС какой-то осознаный у железяки? ни с кем больше не совпадает?
ещё учтите что если свич какой-нить умный, то после включения железяки или изменения её параметров (как правило МАС) некоторое время (обновление ARP таблиц от 2 до 10 минут) свитч может не пропускать нормально пакеты.

и да, регулярно при тестах проверяйте что на хосте в ARP таблице записано. команда как уже писали выше arp -a.
если её надо очистить принудительно то используйте arp -d * (но на свитч это естессно не повлияет никак)

Я имел в виду что если ARP ответа не будет, то компутер (если уже нет этого адреса в ARP таблице) не пошлет ICMP пакет!
Смотрю... ARP запросы не доходят до меня, какие то левые идут не с моим IP. ставлю брейк пойнт в ф-ции send_arp_reply. ничего...

Угу
Возможно MAC адрес вашей платы уже лежит в кэше ARP. Очистите его (arp -d *) и сделайте ping.

Один пинг прошел

Нажмите для просмотра прикрепленного файла
UPD:


смотрю ARP -a и вот

Нажмите для просмотра прикрепленного файла

Мдя, с ARP явный косяк. MAC адрес из всех нулей явно через свич не пройдет

если свитч сильно умный, то у него может быть своя таблица маршрутизации и пакеты с устройства МАС которого не в его базе разрешенных адресов, вообще никуда лететь не будут.
У меня МАС от Igor Mochor + самописный стек с UDP уровнем+самый простой свитч D-Link пол года полет нормальный.

При пинге компьютер не получает ARP ответа...
А железяка не получает ARP запроса

Хотя получает, но от других адресов. И в функцию он благополучно заходит! Но ответ не посылает т.к. IPшники da и ta не те вообще...

Собственно ф-ция обработки ARP запроса


UPD: у меня этот стоит!

А каким образом у вас кабели обжаты от ПК->Switch->Ваш девайс? Потому что не смотря на то что должны опознавать тип кабеля на практике не у всех свитчей это получаеться

Кабель рабочий!остальные девайсы работают нормально + на компьютере проверял.

gosu-art
MAC сделайте какой-то адекватный.. не нулевой.
лучше всего с железякой уйдите в какую-то свою подсеть. поставьте сниффер и смотрите что у вас там происходит на самом деле.

artix и? не понял суть поста.

вот с этим свичем http://www.dlink.ru/ru/products/2/26_b.html пару часов пропарился, когда мне врулили кабель обжатый Машина-Машина, а не Машина-Свитч : пинг как и все остальное не пролезало к остальным устройствам




не силен в С но я чего то не наблюдаю где вы тут указываете свой МАС в пакете который возвращаете в качестве ответа


там есть пример формирования ARP http://ru.wikipedia.org/wiki/ARP

2 bark

сниффером я и смотрю! ARP от компа идут, к компу ответы - нет=>нет ping'а.
МАС не нулевой стоит! А он увидел нуль по пингуемому адресу=> по этому аресу никого нет (физически).

Вопрос: А как перевести железяку на другую подсеть?

2 artix


Вот ф-ция ответа!

gosu-art
вот как у нас обычно в таких случаях работают:
1. В машине 2 сетевые карты. (одна для общей сети, а вторая специально для работы с отлаживаемыми устройствами).
2. Допустим если общая сеть 192.168.1.x , то для работы с железякой использует каждый какую-нить свою подсеть типа 192.168.21.x
эти два пункта позволяют с минимум настроек и фильтров наглядно мониторить в сниффере всё происходящее в сети. (например битые пакеты, если что-то где-то нарушено)

3. Сначала естессно всё проверяется и отлаживается точка-точка, потом комп - отдельный хаб/свитч - железяка, а потому уже общий свитч если вообще предполагается такой режим работы.

допустим свитч может быть не пропустит UDP пакет с плохой чексуммой или превышеным лайфтайм, но ARP пропускать как бы должен. если только не хранит у себя в таблице какое-то старое значение IP для какого-то MAC. не поленитесь подождать 10 минут после подключения через свитч. это стандартное время очистки записи в ARP-таблице.

и ещё конечно вопрос- правильно ли формирует ARP ответ железяка? может что-то не соблюдено и поэтому свитч не пропускает ответ.
заодно достоверно ли вы видете что железяка получила запрос? лампочкой например подмигнуть можно.

У вас в my_ip IP в правильном порядке байтов лежит?

Обратите внимание что младший бит старшего байта МАС не может быть 1 (тогда мультикаст получается). Я как-то 3 дня бился с МАС 01:02:03:04:05:06 - не работало, поменяли на 00:... - все сразу заработало.

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

Нажмите для просмотра прикрепленного файла

Поменял только IP на 192,168,1,110 (маска 255,255,240,0) все работает!
Почему вчера не получалось!? может потому, что пока машин в сети мало?

UPD: поработало и хватит! опять все заткнулось Че то видать в сети нехорошее включается...

Вы говорили что в сети у Вас ДХЦП есть может конфликт адресов возникает? Не может он выдать кому нить еще этот ИП? Нету ли у Вас возможности поцепить скажем еще одну сетевуху и через свитч соединить с Вашей платой?