ethernet, RGMII, потеря пакетов Опции

[bogaev_roman]

Уважаемые форумчане, требуется помощь.
Суть проблемы - теряются UDP пакеты в режиме RGMII. Была связка ПК->marvell 88e1111->борда с arriaII->marvell 88e1111->ПК и, соответственно, гонялись пакеты по обратной связи. Из миллиона отправленных пакетов принимались все без ошибок.
Сделали собственную плату с точно таким же контроллером - из миллиона пакетов стабильно теряются пару сотен, при этом MAC в fpga говорит о том, что все пакеты приняты и отправлены, т.е. потеря происходит где-то между выходом fpga->marvell->ПК. Все временные ограничения на fpga описаны в соответствии с документацией, более того - разводка на выходе фиксировалась и двигалась по фазе опорная частота с мелким шагом в пределах рабочего окна - в результате система либо не работала вообще, либо все те же доли процентов потери пакетов. Разработчик ПП проверил разброс длин сигнальных линий - все в пределах 20ps.
Куда двигаться дальше, ну помимо того, чтобы тыкаться осциллографом в сигналы RGMII?

[Ant_m]

Для начала сделать простой опыт: передать с ПК на ПК без всяких своих плат. Можете быть очень удивлены, если раньше такого не делали.

[bogaev_roman]

Для начала сделать простой опыт: передать с ПК на ПК без всяких своих плат. Можете быть очень удивлены, если раньше такого не делали.

Я в курсе, что UDP не гарантирует доставку всех пакетов без ошибок. При этом, со слов программиста, - в режиме точка-точка ошибок быть не должно. Ну и в случае борды от производителя потерь не было вообще ну или я их не дождался. Тут ведь вопрос в чем - во всей этой тестовой системе отличие одно - ПП другая стоит (ПК, кабеля и прочее одинаковое). Соответственно нужно найти место, чтобы определить у кого руки кривые.

[Ant_m]

Я в курсе, что UDP не гарантирует доставку всех пакетов без ошибок. При этом, со слов программиста, - в режиме точка-точка ошибок быть не должно.

Как много раз я слышал эту песню

Если найдете ответ, сообщите пожалуйста. Мне это крайне интересно, т.к есть такая же проблема.
Пока решение есть только одно - ставить самое быстрое железо для ПК какое есть сейчас.

Тут ведь вопрос в чем - во всей этой тестовой системе отличие одно - ПП другая стоит (ПК, кабеля и прочее одинаковое)

Ну так это элементарно. Замыкаете шины mac ядра в плисе, (loopback на уровне mac), в дырку эзернета подтыкаете BER тестер для медного эзернета и тестируете.

[bogaev_roman]

Ну так это элементарно. Замыкаете шины mac ядра в плисе, (loopback на уровне mac), в дырку эзернета подтыкаете BER тестер для медного эзернета и тестируете.

Там вообще можно пустить loopback через сам 88e1111, в обход fpga, только я пока не понял как. Что, кстати, на тестере можно увидеть?

[EgorTol]

Там вообще можно пустить loopback через сам 88e1111, в обход fpga, только я пока не понял как. Что, кстати, на тестере можно увидеть?

На тестере можно увидеть например количество битовых ошибок, определить правильно ли подсчитана контрольная сумма, возможно в преамбуле проблемы (это тоже может тестер показать), по крайней мере он может показать, что проблема точно не в FPGA или наоборот. ОС на ПК может не пропускать например пакеты с неправильной CRC (или даже сетевая карта на ПК может такое делать). Ну и тайминги на FPGA, должны обязательно выполняться) У меня была такая же схема ПК->ПЛИС->ПК, только не RGMII, а MII, тоже пакеты терялись, проблемы решить не удалось, забросил, с RGMII проще мне кажется.