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

ПЛИС нужна, чтобы определять пакеты 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

Посмотрите KSZ8842 от Микрел. 2 порта с PHY, а третий - параллельная шина 32/16/8 разрядов...
Про то, влезают или нет пакеты я Вам расписывать не буду. Сами потом упретесь. На приеме надо как минимум 2 раза по 1,5 КБ (байта), один такой же пакет на стороне передачи, один такой же буфер под разборку пакета. Ну и для полного дуплекса умножаем на 2. И при этом буфер на приеме будет только на 2 пакета, а остальные будут теряться. и надо будет следить, и как-то работать с приемной очередью. Или терять пакеты или делать противодавление. ... И для сравнения посмотрите, какой буфер есть в свитчах и как они работают с очередью пакетов. И что такое QoS...
Теперь посчитайте, сколько памяти потребуется под обработчик самих пакетов. Хотя-бы оценочно... А потом всю эту "накрутку" переведите в стоимость ПЛИС и сравните с 8842...
А при том, что свитчи или 8842 стоят примерно 10-15 долл. И учтите, что PHY у них встроенные...
Реализовывать свитч на ПЛИС - это для "упертых" ПЛИСоводов... А что в ПЛИС "влезает", так не спорю... На предыдущей работе в приборе была ПЛИС за 800 долл. Да, в нее много "влезает"... Но в том случае, заменить ее было нечем. А здесь - тривиальная и много раз пройденная задача. Жаль только, что Вы не хотите прислушаться к совету...

По поводу реализации езернета на плис:
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 интерфейсе времянку выдерживайте?

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



По частотам все сходится, и времянка выдерживается, как я только с этой времянкой не игрался.

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

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

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

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



Вообще-то, с фирменным МАКом надёжней. И проверять легче.
А что значит игрались?

Простите, не мог ответить. Продолжение следует...

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


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


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


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


Смотрел документацию на микросхему RTL, на то какие требования к временным характеристикам там предъявляются и подстраивался под них, двигая сигналы в разные стороны, как-то так.