Задача: требуется подключить компьютер через FPGA с помощью Ethernet к локальной сети с интернетом и другими компьютерами.

Исходные данные:
1) Компьютер (обычный)
2) Плата с FPGA (Cyclone III), двумя микросхемами PHY (RTL8201bl) и двумя трансформаторами для сети Ethernet.
3) Роутер D-LINK (DI-804 HV)
4) Кабели категории 5Е с разъёмами RJ-45.

Решение:
1) Схема подключения:
Компьютер<--->плата с FPGA<--->роутер<--->сеть/интернет.

2) Берем кабели и подключаем все компоненты согласно схеме подключения.

3) Пишем код в FPGA и программируем её.

4) Работаем.

Описание работы и взаимодействия FPGA и PHY:
Плата с FPGA, микросхемами и разъемами выглядит так:
Трансформатор<--->PHY<--->FPGA<--->PHY<--->Трансформатор
PHY и FPGA связаны интерфейсом MII.

Описание кода для FPGA:
В FPGA реализован асинхронный буфер, который с одной стороны принмает данные от PHY по интерфейсу MII и потом передает эти же данные в другой PHY также по интерфейсу MII и наоборот (т.е. в обратную сторону).

Описание проблемы: Если компьютер подключить просто к сети, без FPGA, то максимальная скорость передачи данных равна 11,5 МБайт/сек, если подключить через FPGA, то скорость падает до 10,9 МБайт/сек.

Диагностика:
1) с помощью SignalTap определно, что буфер не переполняется и не опустошается (гарантированно), пакеты не обрываются (гарантированно), преамбула не повреждена (гарантированно), данные не повреждаются (маловероятно, что повреждаются в FPGA).
2) с помощью программы Wireshark было установленно, что компьютер или сервер посылает дублированные запросы на передачу данных, что говорит о том, что некая часть данных теряется, а теряется скорее всего из-за того что в каком-то месте пакет повреждается, а поврежденный пакет отбрасывается.

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

P.S. буфер реализован с помощью MegaWizard. Управление буфером тоже очень простое, могу выложить код на Verilog.
P.S.2 не знаю в какую тему форума писать, так как задача объединяет и язык Verilog, и интерфейсы, и FPGA.

Спасибо за внимание.

Фото платы в студию, может у Вас LAN разведен так, что данные теряются, может FIFO теряет пакеты, нужно больше информации. Раз пакеты теряются, то либо на физическом уровне, либо на программном. Запустите тесты на просто передачу пакетов от FPGA к компьютеру на максимальной скорости и посмотрите, какая скорость. Чтобы FPGA сама генерила разные пакеты и пуляла их в комп. Затем повторите это со вторым каналом. Если скорость будет максимальная и потерь не будет, значит проблема в программе и FIFO.
А если пакеты будут теряться значит искать что именно портит пакеты.

Сообщение отредактировал telix - Jan 24 2013, 17:09

А почему вместо FPGA не взять микросхемку 3 или 5-ти портового свитча? И гарантированно будет работать без всяких прошивок... Например у Микрела свитч с физикой сразу...

Вообще-то странно. На 100 Мб должно работать абсолютно без сбоев. Циклон3 даже гига-ethernet тянет без сбоев. Попробуйте для начала выкинуть буфера и соединить две физики проводами в Циклоне. Если будет работать правильно, надо будет искать ошибки в проекте, а если нет - в разводке и электричестве.

Фото пока не могу предоставить, в понедельник может быть. Могу сказать сразу, что разведено всё "соплями". Где они там в FIFO могут потеряться? Считал количество принятых и переданных пакетов на входе и выходе FPGA, вроде всё совпадает. Сделать тест для генерации можно, хотя не слишком просто, надо поднимать сеть: компьютер<--->FPGA, для этого надо MAC-контроллер реализовывать? А еще как скорость в таком случае посмотреть? На данный момент я просто скачиваю большой файл из сети и смотрю скорость.



В дальнейшем необходимо обрабатывать некоторые пакеты с помощью FPGA.



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

Отсекаем все лишнее, попробуйте Компьютер<--->плата с FPGA<--->второй компьютер.


TX_ER и RX_ER на MII ни разу не возникают?


Приложите лог-файл вайршарка, лучше снятого и у передатчика, и у приемника (естественно, одной и той же передачи). Сильно большой файл не надо, вдруг там что-то такое, что сразу бросится в глаза.

Я так понимаю, вы скачиваете какой-то файл из расшаренной папки, или фтп, или чего-то подобного высокоуровнего. Отсекайте и их. Найдите в интернете любой простейший генератор траффика (сырых Ethernet пакетов, IP или UDP, но не TCP) и пошлите мильён пакетов (на разных скоростях), у приемника вайршарком посчитаете, посмотрите, есть ли пакеты со сбойной CRC. Так вы гарантированно установите, повреждает ли ПЛИС данные.

Вдруг ваша ПЛИС вносит некую маленькую, но достаточно ощутимую задержку для пакетов, и передатчик, не дождавшись квитанции о доставке пакета, посылает его еще раз. Конечно, это очень маловероятно, но если вы все равно в тупике, стоит посмотреть время между входом пакета в ПЛИС и выходом его оттуда (например, по сигналам RX_DV и TX_EN).


Очень странно. Какие при этом пакеты доходят до вайршарка?

Ну вот и ответ. Ваши "сопли на плате" искажают форму сигналов LAN и как результат часть данных теряется.

Сообщение отредактировал telix - Jan 25 2013, 18:40

Ну так и надо делать все по человечески. Смело ставьте свитч, как минимум 3-х портовый, управляемый... И тогда через 2 порта у Вас будет вот это:
Компьютер<--->свитч<--->второй компьютер
а на третий будете зеркалить нужные Вам пакеты и прицепите его к ПЛИС. Или к быстрому процессору, что тоже неплохо.
При этом, поскольку в свитче есть буфер, то при сбоях в линии он сам перезапустит передачу пакета. И справится с автопереговорами. А если возьмете 5-ти портовый, а цена у микросхем примерно одинаковая, то в 4-й порт воткнете ноутбук и произведете отладку...
А уж в ПЛИС проект будет значительно проще...
Да, еще учтите, что "на соплях" порты работать не будут. Там 125 МГц аналоговые сигналы.
У меня на сайте найдите статью про 8842, там написано, как конструировать и отлаживать...
Удачи!

Не всё, что сопля, есть плохо. Если сигнал RXER с PHY в порядке, то это в ПЛИСе. Честно говоря, это ещё какие сопли должны быть, что бы убить сигнал 100Мбит.
Ну, разве что некорректно сделано подключение PHY или "левая" комплектация.

С MAC-контроллерами на фирменном ядре и "тестером" у Вас появится возможность нормально посчитать все пакеты, включая битые, сравнить их количество с количеством посланных из тестера и проверить потерю пакетов в ПЛИСе по разбежке счётчиков. Это стандартный путь. Остальное - от лукавого.

Если получится, что RXER в порядке, а пакеты по входу битые, то м.б. это проблема с тактированием по MII. Но для MII это маловероятно, разве что клок перевёрнут.
Ну, и т.д., от точки к точке, пока не локализуется место потери пакетов.




Вы думаете, что человек для развлечения FPGA ставит? Если нет, то зачем такие советы?
А некоторые категоричные утверждения крайне сомнительны. Там оно конечно аналог, но ещё тот. Убить его не так просто.
Старая разводка сетей под 10/100Мбит в большинстве офисов - сплошные "сопли", да ещё на хороших дистанциях, и ничего, работает.

Сообщение отредактировал prig - Jan 31 2013, 16:37

Попробуйте найти компьютер с двумя портами и закольцевать передачу. Обратите внимание на статистику задержек. Может быть при неравномерном потоке буфер маловат?

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

Вообще-то, такое утверждение очень похоже на оскорбление.
Скорее всего, Вы просто не в курсе, что есть множество случаев, когда приходится делать обработку пакетов именно в FPGA. А речь шла именно об обработке.
А уж чего только не помещается в FPGA... Вы даже представить не можете, если судить по Вашим замечаниям.




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

Сообщение отредактировал prig - Feb 1 2013, 09:09

Вижу, что читать Вы умеете, но суть не всегда понимаете. Я же написал - управляемый свитч. Нужные пакеты перебрасываются на 3-й порт т отправляются в ПЛИС на обработку. Не нужные - идут транзитом с 1-го порта на 2-й.
А для справки сообщаю, что с ПЛИС я имел дело всего-то лет 12, а может и более. Те, кто был на моем сайте, это знают и знают, какие проекты я делал. А Вы не знаете, ну потому и спорить с Вами не вижу необходимости..


И даже более добавлю для ТС. За последние 7 лет, когда я занимался еще и техподдержкой Микрела, то от клиентов чего только не приходилось выслушивать. И чем более неординарная постановка задачи дается клиентом, тем больше вероятность того, что сама задача исходно поставлена неправильно.
Вот и в данном случае. Что делаем? приемное ФИФО на глубину кадра и передающее ФИФО так же на глубину кадра? Значит ставим к ПЛИС внешнюю память и организуем к ней несколько каналов ДМА. Но это будет работать только при дуплексе, без колиззий на той стороне, которая уходит в сеть... А значит, там надо обязательно ставить свитч, чтобы убрать колиззии и сделать дуплекс.
А если полудуплекс, то кто будет очищать ФИФО на стороне "линии". Делаем автомат? А если ФИФО не на всю глубину кадра? То и кто сообщит компьютеру, что надо перезапустить пакет? Еще автомат?
И чем обработка в ПЛИС лучше, чем на микроконтроллере? UDP будем разбирать аппаратно? Или сделаем внутри микроконтроллер и будем мучиться с отладкой? Для чего? Ведь разборка пакетов - обычно идет как библиотека. Да и дешевле в микроконтроллере получится в несколько раз... Например Блэкфин с тактовой 800 МГц чем будет хуже, чем ПЛИС?

iosifk, дело не в том, что лучше или хуже. М.б. 101 причина, что бы делать обработку именно на ПЛИСе. А у военных иногда всего 1 причина, но непрошибаемая.
Думаю, что из этого и надо исходить, давая советы ТС. Ну, поинтересоваться в необходимости именно ПЛИС, как максимум.
Тем более, предлагаемая Вами схема давно известна и не является откровением для большинства разработчиков, решающих задачи обработки пакетов.

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

В EP3C16 56 кб ОЗУ! Даже если самый младший взять - 42к. Все влезет.