Подключение компьютера к LAN через FPGA Опции

[EgorTol]

Задача: требуется подключить компьютер через 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.

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

[EgorTol]

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

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

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

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

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

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

[prig]

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



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



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

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

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

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

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

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

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

[iosifk]

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

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

[gosu-art]

Внутри ПЛИС пакет в 1,5Кб не поместится.

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

[EgorTol]

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

Кстати да, не понимаю почему пакет то не поместится, пакет еще как помещается.

ПЛИС нужна, чтобы определять пакеты UDP, менять в них некоторые поля, персчитывать контрольную сумму и отправлять дальше по назначению (Это локальная задача. Ну а в целом задачей для ПЛИС конечно же не является реализация свитча на ней). Если ставить трехпортовый свитч, то там ведь тоже интерфейс MII? А если он неправильно реализован в ПЛИС, то всеравно ведь потери будут?

По поводу сигнала RX_ERR. Сигнал замечен не был.

Согласен, что "сопли" врядли влияют на сигнал. Но пока не исключил их из источника опасности.

Небольшая предыстория:
Изначально был реализован интерфейс с достаточно сложным алгоритмом управления буфером. А еще у меня был тестер битовых ошибок вот такой: http://metrotek.ru/catalog/270/1994/ (ну и сейчас тоже есть). С помощью этого тестера тестировался интерфейс. После доработки алгоритма добился того, что тестер показывает 0 ошибок на скорсоти 100 Мбит/сек (12,5 МБайт/сек) с кучей сложных потоков и траффиков. Я обрадовался, конечно, но не тут то было! При подключении к компьютеру скорость упала до 1 МБайт/сек., что меня, конечно, огорчило. Затем я значительно упростил алгоритм, очень упростил, по сути одни буферы остались. В результате чего скорость на компьютере достигла 10,9 МБайт/сек., а вот тестер показывает море ошибок, коэффициент BER ну где то 10 в минус третьей степени. И вот я теперь как-то озадачен.
Счетчик пакетов был, результаты не помню. Вроде всё совпадает.

По поводу генератора траффика. Пробовал раньше, как раз коласофтом. Но так и не удалось с помощью этой программы загрузить сеть на 100% (в режиме burst, без паузы межу передачей пакетов). Видимо, в паузу входит время формирования пакета, буферизация, очереди в ОС и т.д., а с такой паузой сеть на 100% не загрузишь.

Еще одно замечание: на скорость сильно влияет размещение ячеек внутри ПЛИС, приходится вручную их размещать...

Сообщение отредактировал EgorTol - Feb 5 2013, 13:30