Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Подключение компьютера к LAN через FPGA
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > Fast Ethernet/Gigabit Ethernet/FibreChannel
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.

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


telix
Фото платы в студию, может у Вас LAN разведен так, что данные теряются, может FIFO теряет пакеты, нужно больше информации. Раз пакеты теряются, то либо на физическом уровне, либо на программном. Запустите тесты на просто передачу пакетов от FPGA к компьютеру на максимальной скорости и посмотрите, какая скорость. Чтобы FPGA сама генерила разные пакеты и пуляла их в комп. Затем повторите это со вторым каналом. Если скорость будет максимальная и потерь не будет, значит проблема в программе и FIFO.
А если пакеты будут теряться значит искать что именно портит пакеты.
iosifk
Цитата(EgorTol @ Jan 24 2013, 18:41) *
Задача: требуется подключить компьютер через FPGA с помощью Ethernet к локальной сети с интернетом и другими компьютерами.

А почему вместо FPGA не взять микросхемку 3 или 5-ти портового свитча? И гарантированно будет работать без всяких прошивок... Например у Микрела свитч с физикой сразу...
Alex11
Вообще-то странно. На 100 Мб должно работать абсолютно без сбоев. Циклон3 даже гига-ethernet тянет без сбоев. Попробуйте для начала выкинуть буфера и соединить две физики проводами в Циклоне. Если будет работать правильно, надо будет искать ошибки в проекте, а если нет - в разводке и электричестве.
EgorTol
Цитата(telix @ Jan 24 2013, 21:07) *
Фото платы в студию, может у Вас LAN разведен так, что данные теряются, может FIFO теряет пакеты, нужно больше информации. Раз пакеты теряются, то либо на физическом уровне, либо на программном. Запустите тесты на просто передачу пакетов от FPGA к компьютеру на максимальной скорости и посмотрите, какая скорость. Чтобы FPGA сама генерила разные пакеты и пуляла их в комп. Затем повторите это со вторым каналом. Если скорость будет максимальная и потерь не будет, значит проблема в программе и FIFO.
А если пакеты будут теряться значит искать что именно портит пакеты.


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

Цитата(iosifk @ Jan 24 2013, 21:59) *
А почему вместо FPGA не взять микросхемку 3 или 5-ти портового свитча? И гарантированно будет работать без всяких прошивок... Например у Микрела свитч с физикой сразу...


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

Цитата(Alex11 @ Jan 25 2013, 01:59) *
Вообще-то странно. На 100 Мб должно работать абсолютно без сбоев. Циклон3 даже гига-ethernet тянет без сбоев. Попробуйте для начала выкинуть буфера и соединить две физики проводами в Циклоне. Если будет работать правильно, надо будет искать ошибки в проекте, а если нет - в разводке и электричестве.


Попробовал. Потери большие, скорость настолько низкая, что нельзя определить какая она sm.gif
sorok-odin
Цитата(EgorTol @ Jan 24 2013, 18:41) *
1) Схема подключения:
Компьютер<--->плата с FPGA<--->роутер<--->сеть/интернет.

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

Цитата(EgorTol @ Jan 24 2013, 18:41) *
1) с помощью SignalTap определно, что буфер не переполняется и не опустошается (гарантированно), пакеты не обрываются (гарантированно), преамбула не повреждена (гарантированно), данные не повреждаются (маловероятно, что повреждаются в FPGA).

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

Цитата(EgorTol @ Jan 24 2013, 18:41) *
2) с помощью программы Wireshark было установленно, что компьютер или сервер посылает дублированные запросы на передачу данных, что говорит о том, что некая часть данных теряется, а теряется скорее всего из-за того что в каком-то месте пакет повреждается, а поврежденный пакет отбрасывается.

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

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

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

Цитата(EgorTol @ Jan 24 2013, 18:41) *
Попробовал. Потери большие, скорость настолько низкая, что нельзя определить какая она

Очень странно. Какие при этом пакеты доходят до вайршарка?
telix
Цитата(EgorTol @ Jan 25 2013, 12:03) *
Могу сказать сразу, что разведено всё "соплями".


Ну вот и ответ. Ваши "сопли на плате" искажают форму сигналов LAN и как результат часть данных теряется.
iosifk
Цитата(EgorTol @ Jan 25 2013, 12:03) *
В дальнейшем необходимо обрабатывать некоторые пакеты с помощью FPGA.

Ну так и надо делать все по человечески. Смело ставьте свитч, как минимум 3-х портовый, управляемый... И тогда через 2 порта у Вас будет вот это:
Компьютер<--->свитч<--->второй компьютер
а на третий будете зеркалить нужные Вам пакеты и прицепите его к ПЛИС. Или к быстрому процессору, что тоже неплохо.
При этом, поскольку в свитче есть буфер, то при сбоях в линии он сам перезапустит передачу пакета. И справится с автопереговорами. А если возьмете 5-ти портовый, а цена у микросхем примерно одинаковая, то в 4-й порт воткнете ноутбук и произведете отладку...
А уж в ПЛИС проект будет значительно проще...
Да, еще учтите, что "на соплях" порты работать не будут. Там 125 МГц аналоговые сигналы.
У меня на сайте найдите статью про 8842, там написано, как конструировать и отлаживать...
Удачи!
prig
Цитата(EgorTol @ Jan 25 2013, 12:03) *
Фото пока не могу предоставить, в понедельник может быть. Могу сказать сразу, что разведено всё "соплями". Где они там в FIFO могут потеряться? Считал количество принятых и переданных пакетов на входе и выходе FPGA, вроде всё совпадает. Сделать тест для генерации можно, хотя не слишком просто, надо поднимать сеть: компьютер<--->FPGA, для этого надо MAC-контроллер реализовывать? А еще как скорость в таком случае посмотреть? На данный момент я просто скачиваю большой файл из сети и смотрю скорость.



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



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


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

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

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


Цитата(iosifk @ Jan 25 2013, 23:21) *
Ну так и надо делать все по человечески. Смело ставьте свитч, как минимум 3-х портовый, управляемый... И тогда через 2 порта у Вас будет вот это:
Компьютер<--->свитч<--->второй компьютер

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


Вы думаете, что человек для развлечения FPGA ставит? Если нет, то зачем такие советы?
А некоторые категоричные утверждения крайне сомнительны. Там оно конечно аналог, но ещё тот. Убить его не так просто.
Старая разводка сетей под 10/100Мбит в большинстве офисов - сплошные "сопли", да ещё на хороших дистанциях, и ничего, работает.
polyakovav
Цитата(EgorTol @ Jan 24 2013, 18:41) *
Задача: требуется подключить компьютер через FPGA с помощью Ethernet к локальной сети с интернетом и другими компьютерами.

...

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

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

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


Попробуйте найти компьютер с двумя портами и закольцевать передачу. Обратите внимание на статистику задержек. Может быть при неравномерном потоке буфер маловат?
iosifk
Цитата(prig @ Jan 31 2013, 18:34) *
Вы думаете, что человек для развлечения FPGA ставит? Если нет, то зачем такие советы?
А некоторые категоричные утверждения крайне сомнительны. Там оно конечно аналог, но ещё тот. Убить его не так просто.
Старая разводка сетей под 10/100Мбит в большинстве офисов - сплошные "сопли", да ещё на хороших дистанциях, и ничего, работает.


Скорее всего человек просто не в курсе того, что есть микросхемы свитчей. Потому и пытается сделать "по Суворовски, через Альпы"... только на одних ПЛИС. Потому и советую...
И не забудьте про память для пакетов. Внутри ПЛИС пакет в 1,5Кб не поместится. Надо использовать внешнюю память. И перезапуск пакетов в линию при колиззиях, ну и т.д. А уж про уровни обслуживания я и совсем молчу. Это в ПЛИС сделать трудно. Хотя, если для развлечения, то почему бы не поставить дорогую ПЛИС с МАСами, вместо дешевого свитча...
А конструкция платы и сетевые провода - это совершенно разные вещи... И утверждения мои сделаны не на пустом месте, поверьте.
prig
Цитата(iosifk @ Jan 31 2013, 20:59) *
Скорее всего человек просто не в курсе того, что есть микросхемы свитчей.
...


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


Цитата(polyakovav @ Jan 31 2013, 19:18) *
Попробуйте найти компьютер с двумя портами и закольцевать передачу. Обратите внимание на статистику задержек. Может быть при неравномерном потоке буфер маловат?


Ещё лучше, найти(арендовать) сетевой тестер и сделать тест по кольцу с его помощью. С ним будет несколько удобней.
В принципе, при правильной загрузке каналов и отсутствии потери пакетов, задержка не должна сказываться на максимальной скорости.
iosifk
Цитата(prig @ Feb 1 2013, 13:03) *
Вообще-то, такое утверждение очень похоже на оскорбление.
Скорее всего, Вы просто не в курсе, что есть множество случаев, когда приходится делать обработку пакетов именно в FPGA. А речь шла именно об обработке.
А уж чего только не помещается в FPGA... Вы даже представить не можете, если судить по Вашим замечаниям.

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


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

Так что, если использование ПЛИС действительно оправдано, то всё остальное - оффтоп разной степени голимости.
Лучше уж нам прикрыть эту дискуссию, что бы не впадать во все тяжкие.
gosu-art
Цитата(iosifk @ Jan 31 2013, 20:59) *
Внутри ПЛИС пакет в 1,5Кб не поместится.

В EP3C16 56 кб ОЗУ! Даже если самый младший взять - 42к. Все влезет.
EgorTol
Цитата(gosu-art @ Feb 4 2013, 08:16) *
В 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% не загрузишь.

Еще одно замечание: на скорость сильно влияет размещение ячеек внутри ПЛИС, приходится вручную их размещать...
iosifk
Цитата(EgorTol @ Feb 5 2013, 17:29) *
Кстати да, не понимаю почему пакет то не поместится, пакет еще как помещается.

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

Посмотрите KSZ8842 от Микрел. 2 порта с PHY, а третий - параллельная шина 32/16/8 разрядов...
Про то, влезают или нет пакеты я Вам расписывать не буду. Сами потом упретесь. На приеме надо как минимум 2 раза по 1,5 КБ (байта), один такой же пакет на стороне передачи, один такой же буфер под разборку пакета. Ну и для полного дуплекса умножаем на 2. И при этом буфер на приеме будет только на 2 пакета, а остальные будут теряться. и надо будет следить, и как-то работать с приемной очередью. Или терять пакеты или делать противодавление. ... И для сравнения посмотрите, какой буфер есть в свитчах и как они работают с очередью пакетов. И что такое QoS...
Теперь посчитайте, сколько памяти потребуется под обработчик самих пакетов. Хотя-бы оценочно... А потом всю эту "накрутку" переведите в стоимость ПЛИС и сравните с 8842...
А при том, что свитчи или 8842 стоят примерно 10-15 долл. И учтите, что PHY у них встроенные...
Реализовывать свитч на ПЛИС - это для "упертых" ПЛИСоводов... А что в ПЛИС "влезает", так не спорю... На предыдущей работе в приборе была ПЛИС за 800 долл. Да, в нее много "влезает"... Но в том случае, заменить ее было нечем. А здесь - тривиальная и много раз пройденная задача. Жаль только, что Вы не хотите прислушаться к совету...
gosu-art
По поводу реализации езернета на плис:
http://electronix.ru/forum/index.php?showt...amp;hl=ethernet
http://electronix.ru/forum/index.php?showt...amp;hl=ethernet
еще можете поискать в разделе http://electronix.ru/forum/index.php?showforum=164 много тем было

Как вариант можно поставить 2 TSE с интерфейсом MII. Один ПК->ПЛИС, второй ПЛИС->свитч (в нем уже TX RX буфера есть -> на выходе готовые пакеты в вашем клоковом домене) а между ними ваш IP блок (нужно будет прикрутить его к Avalon-ST). Наверное также поставить небольшой Ниос, для настройки этих блоков. В TSE реализованы контроль всяких ошибок (переполнения, и.т.д), flow control. и еще всяких интересностей. в SOPCе (QSYS) система собирается на "раз". про TSE можно почитать тут http://electronix.ru/forum/index.php?showtopic=37680 Конечно, если вы не работали с Ниосом и ТСЕ будет сложновато.

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

А по частотам у вас там все сходится? в MII интерфейсе времянку выдерживайте?
EgorTol
Вы предлагаете мне МАК-контроллер сделать? Мне нужен простой прием и передача, типа конвеера что-ли.

Цитата(gosu-art @ Feb 6 2013, 00:08) *
А по частотам у вас там все сходится? в MII интерфейсе времянку выдерживайте?


По частотам все сходится, и времянка выдерживается, как я только с этой времянкой не игрался.
prig
Цитата(EgorTol @ Feb 5 2013, 17:29) *
...
Изначально был реализован интерфейс с достаточно сложным алгоритмом управления буфером.
...
После доработки алгоритма добился того, что тестер показывает 0 ошибок на скорсоти 100 Мбит/сек (12,5 МБайт/сек) с кучей сложных потоков и траффиков.
...
Еще одно замечание: на скорость сильно влияет размещение ячеек внутри ПЛИС, приходится вручную их размещать...


Таки, попробуйте отделить "мух от котлет".

- Тестером можно дать полную загрузку безотносительно к задержкам. 0 ошибок при полной загрузке говоит о том, что в случае допиленного алгоритма всё работало правильно. То, что при подключении к компу скорость упала, скорее всего, говорит о некорректности самого тестирования.

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

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

Цитата(EgorTol @ Feb 6 2013, 11:46) *
Вы предлагаете мне МАК-контроллер сделать? Мне нужен простой прием и передача, типа конвеера что-ли.
...
По частотам все сходится, и времянка выдерживается, как я только с этой времянкой не игрался.


Вообще-то, с фирменным МАКом надёжней. И проверять легче.
А что значит игрались?
EgorTol
Простите, не мог ответить. Продолжение следует...
Цитата(prig @ Feb 6 2013, 12:41) *
То, что при подключении к компу скорость упала, скорее всего, говорит о некорректности самого тестирования.

Тестирование простое: тестер посылает траффик через ПЛИС и этот же траффик принмает обратно, а потм сравнивает полученное и отправленное. В чем некорректность тестирования?

Цитата(prig @ Feb 6 2013, 12:41) *
Поведение упрощённого варианта явно указывает на ошибки внутри ПЛИС и чувствительности тестов к задержкам и ошибкам(потерям пакетов).

Конечно тесты чувствительны к задержкам и ошибкам, на то они и тесты.

Цитата(prig @ Feb 6 2013, 12:41) *
Реакция на ручное размещение ячеек наводит на мысль, что Вы что-то делаете неправильно, включая собственно размещение, и, вероятно, у Вас в проекте полный ахтунг с временными диаграммами, синхронизацией и т.п., и проверкой тайминга никто и не думал заниматься.

Упрощенный проект содержит в себе буквально два буфера, размером в 32 слова и несколько регистров, разрешающих запись или чтение. Буферы созданы с помощью MegaWizard. Всего задействовано 227 ячеек, из которых 206 забирают буферы. Ну так вот, если перемещать эти буферы целиком, вместе с регистрами по микросхеме, то получаются разные результаты.

Цитата(prig @ Feb 6 2013, 12:41) *
Описание Ваших телодвижений может говорить о том, что исходная задача потерялась.

Исходная задача была и остаётся такой, какой я её описал в первом посте. По-моему там все ясно написано. Других задач нет. Не надо ни разбирать пакет, ни собирать и т.д., просто передача данных с одного порта Ethernet на другой и обратно.

Цитата(prig @ Feb 6 2013, 12:41) *
А что значит игрались?

Смотрел документацию на микросхему RTL, на то какие требования к временным характеристикам там предъявляются и подстраивался под них, двигая сигналы в разные стороны, как-то так.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.