[RoadRunner 0]

Развязывающие конденсаторы не помогли.. 

 

Интересно, что phy по SGMII выдает значения конфигурационного регистра 0x9801 при воткнутом ethernet-кабеле и 

0x0801 при выдернутом ethernet-кабеле. Если им верить, то при воткнутом ethernet-кабеле имеет место Link_Failure. Но судя по индикации светодиодов на ПК и

на phy, линк вроде есть. И непонятно, как это интерпретировать..

[sorok-odin 5]

7 часов назад, RoadRunner сказал:

0x9801

Если им верить, то:

бит 15=1 -- link up

бит 14=0 -- отсутствует Acknowledge

бит 12=1 -- full duplex

биты 11:10=10 -- 1000BASE-T, 1000BASE-X

бит 7=0 -- 10/100/1000BASE-T

бит 0=1 -- always 1

Все хорошо, в даташите на PHY в регистре SGMII PHY Status я вообще не вижу никаких Link_Failure. По отсутствию Acknowledge похоже, что PHY ждет от вас чего-то по SGMII. Чего именно - не знаю, у меня в virtex5 автосогласованием при старте занимается сам встроенный аппаратный блок MAC, я никаких данных в это время ему не даю. Может в вашем MAC тоже можно включить SGMII автосогласование?

[RoadRunner 0]

12 hours ago, sorok-odin said:

Все хорошо, в даташите на PHY в регистре SGMII PHY Status я вообще не вижу никаких Link_Failure. 

Хм.. А я ориентируюсь на стандарт IEEE Std 802.3 clause 37 - глава про 1000BASE-X auto-negotiation. В доке на phy вроде написано, что в соответствии с ним сделано.

 

Может, тут собака зарыта.. Как-то путано в доке на phy написано: с одной  стороны пишут, что кодировка автопереговоров 1000BASE-T такая же как в 1000BASE-X, а с другой - что автопереговоры 1000BASE-T основаны на clause 28 и 40, а это вообще автопереговоры для 100Мбитного ethernet..

 

Тот регистр, который Вы привели, это из еще какого-то вида автопереговоров -  SGMII Auto-Negotiation. Короче, у меня пока в голове каша.. Буду разбираться. Если кто может разложить, что тут где и для чего, буду очень благодарен.

Изменено 19 августа, 2021 пользователем RoadRunner

[vadimp61 0]

Насколько я знаю автопереговоров на SGMII нет, там все строго подключается TX на RX и не перепутать полярность P и N (так у марвела описано в доках на 88E6131 и 88E6095)

Изменено 19 августа, 2021 пользователем vadimp61

[RoadRunner 0]

С автопереговорами я, кажется, разобрался: они такие же как на 1000BASE-X, только сам регистр конфигурации phy другой - биты другие. Это объясняет, почему по моему мнению там шла белиберда - я биты интерпретировал не по той доке, надо было так, как sorok-odin написал постом выше. Но Acknowledge бит там на том же месте, поэтому, учитывая что я его посылаю по стандарту, автопереговоры проходят и так. 

 

Но самое интересное в другом. Как только проходят автопереговоры, я на автомате начинаю непрерывно передавать пакеты, т.е. на максимальной скорости. Это прокатывало у меня, когда я работал с SFP-модулем: если все было исправно, сразу после прохождения автопереговоров свич начинал непрерывно моргать. А с этим phy, как писал выше, ничего не моргает - не проходит передача и прием при этом тоже не проходит. 

 

Так вот, я ради эксперимента отрубил непрерывную передачу после конфигурации, и приемные пакеты начали проходить! Короче, выглядит так, как будто я phy засыпаю передающими пакетами, и он отказывается как их передавать, так и принимать входящие. Сейчас буду прореживать передачу, посмотрим, в этом дело или нет..

[RoadRunner 0]

Все оказалось весьма загадочно: затыкание phy наблюдается только при почти непрерывной отправке пакета длиной 81 байт (без контрольной суммы). При этом каждая такая посылка приводит к сбросу конфигурации, возобновлению автопереговоров phy. Байтом больше, байтом меньше и все уже начинает работать - ничего не сбрасывается, phy начинает передавать эти пакеты и принимать приемные. Если уменьшить периодичность посылки пакета, скажем до секунды, то и этот "несчастливый" пакет длиной 81 байт начинает проходить.

 

Что это - аномалия, или все-таки проблемы с цепями питания/тактовой частоты, вызывающие нестабильность и затыки в работе микросхемы phy, мне сказать трудно. Хотелось бы конечно, чтобы такой магический в плохом смысле пакет был единственным. Но что-то мне подсказывает, что я не просто по чистой случайности наткнулся на этот единственный пакет: скорее всего, тут дело в сочетании периодичности отправки и длины отправляемого пакета, и тогда таких ситуаций может быть много.

 

В любом случае, всем большое спасибо за советы! Буду благодарен, если поделитесь соображениями по поводу того, что у меня получилось: может быть, кто-то встречался с таким, наблюдал подобное поведение на этом или других phy.

[RoadRunner 0]

Всем доброго времени суток! 

 

Новую тему решил не создавать, т.к. вопрос в продолжение старой проблемы. Вопрос следующий: нужно ли после отправленного в трансивер ПЛИС кадра данных менять код IDLE2 на IDLE1 в зависимости от значения disparity в конце кадра?

 

По идее, disparity считается в кодировщике 8b/10b, т.е. на уровне PCS. Но он уже в ПЛИС находится, а IDLE2 или IDLE1 вставлять после пакета, нужно решить еще до этого. Читал, что в некоторых трансиверах поэтому замена IDLE2 на IDLE1 выполняется внутри кодировщика 8b/10b, чтобы отправителю, т.е. MAC-уровню, этим повторно не заниматься. Но имеется ли такая функция в трансиверах Cyclone 10 GX, я не нашел.

 

Подскажите, кто знает. Благодарю.

Изменено 2 марта, 2022 пользователем RoadRunner