[troiden 0]

Есть задача гонять данные между двумя стоящими рядом Цинками через Ethernet. Возможно ли напрямую соединить их процессорные части по RGMII или же надо в любом случае ставить еще и микросхемы физики? Официальный форум так и не смог дать ответа.

[Mad_kvmg 0]

Официальный форум так и не смог дать ответа.

Ну если официальная наука бессильна, то поможет нам википедия.

Интерфейс MII (Media Independent Interface — независящий от среды передачи интерфейс) представляет собой стандартизованный интерфейс для подключения MAC-блока сети FastEthernet к блоку PHY. Интерфейс MII может быть выведен на разъём для подключения внешнего приемопередатчика или может просто соединять две микросхемы на одной печатной плате.

Независимость от среды передачи означает, что существует возможность использования любых PHY-устройств без необходимости смены или переработки аппаратуры MAC-блока.

Эквивалентами интерфейса MII для других скоростей сети Ethernet являются AUI (для 10Мбит/с Ethernet), GMII (для 1Гбит/с Ethernet) и XAUI (для Ethernet 10Гбит/с).

Добавить можно, что RGMII это GMII, только reduced, вместо 8 физических линий четыре.

 

Если, у вас два Цинка на одной плате, то наверное есть более разумный способ наладить взаимосвязь между армами.

Если у вас две платы, возможно kits от xilinx, то соединяйте их шнурком и далее решайте вопросы взаимодействия уже на протокольном уровне.

[doom13 0]

Есть задача гонять данные между двумя стоящими рядом Цинками через Ethernet. Возможно ли напрямую соединить их процессорные части по RGMII или же надо в любом случае ставить еще и микросхемы физики? Официальный форум так и не смог дать ответа.

Если расстояние небольшое, то почему бы и нет.

[troiden 0]

Если, у вас два Цинка на одной плате, то наверное есть более разумный способ наладить взаимосвязь между армами.

Такое извращение нужно для унификации и возможности масштабирования системы. Плюс программисты сказали, что им так даже проще, типа сделали проброс трафика и всё.

 

Если расстояние небольшое, то почему бы и нет.

Вот и я не вижу причин для отказа, но например на форуме TI для AM3359 черным по белому пишут "Direct MAC-to-MAC connections are not a supported configuration.", а для DSP'шек уже таких ограничений нет. Не хотелось бы сделать плату и только потом узнать, что есть какие-то принципиальные невозможности.

[doom13 0]

Вот и я не вижу причин для отказа, но например на форуме TI для AM3359 черным по белому пишут "Direct MAC-to-MAC connections are not a supported configuration.", а для DSP'шек уже таких ограничений нет. Не хотелось бы сделать плату и только потом узнать, что есть какие-то принципиальные невозможности.

Что-то мне подсказывает, что ерунду пишут. Как работа RGMII может отличаться у разных устройств? Не может, всё стандартно! У PHY один из режимов проверки MAC Interface Loopback и проверяет работоспособность RGMII, он тоже тогда не должен работать?!

[troiden 0]

Что-то мне подсказывает, что ерунду пишут. Как работа RGMII может отличаться у разных устройств? Не может, всё стандартно! У PHY один из режимов проверки MAC Interface Loopback и проверяет работоспособность RGMII, он тоже тогда не должен работать?!

Черт его знает... Вот тут тема поднималась: http://e2e.ti.com/support/arm/sitara_arm/f/791/t/262120.aspx

[prig 0]

...Возможно ли напрямую соединить их процессорные части по RGMII или же надо в любом случае ставить еще и микросхемы физики?

...

В общем случае, всё зависит от реализации MAC. Не всегда удаётся отключить обработку событий от PHY. В таком случае приходится ставить микросхемы физики.

 

В остальном, каких-то серьёзных проблем с такими соединениями не наблюдается. Не считая некоторых мелких, но неприятных прихватов именно с RGMII. С этим вариантом могут быть проблемы с "времянкой" или нагрузочной способностью драйверов. Конкретный релиз надо очень аккуратно проверять. MII и GMII всегда подключались на раз-два, если хотя бы для одного контроллера было заявлено два режима: MAC и PHY. Софтовые контроллеры MII и GMII на Xilinx неоднократно подымали в обоих режимах. Главное в этом деле - с клоками не накосячить.

 

Для контроллера Zynq два режима (MAC и PHY) явным образом в документации не обозначены(UG585 (v1.7) February 11, 2014). Т.е., риски того, что они не залинкуются, вполне реальные. Можно ещё пошарить насчёт двух режимов в руководстве для программеров, но что-то я сомневаюсь...

 

Для вашего случая было бы оптимальным реализовать соединение в режиме 1000BASE-X. Если трансиверов MGT не жалко. В любом случае, это будет надёжней и удобней, нежели RGMII.

[doom13 0]

В общем случае, всё зависит от реализации MAC. Не всегда удаётся отключить обработку событий от PHY. В таком случае приходится ставить микросхемы физики.

Поясните пожалуйста, обработку каких событий от PHY необходимо отключить? Передаются данные (TXD, RXD), frame + наличие ошибки (TX_CTL, RX_CTL), что-то ещё?

Всё остальное общение с PHY только по MDIO.

 

Черт его знает... Вот тут тема поднималась: http://e2e.ti.com/support/arm/sitara_arm/f/791/t/262120.aspx

Посмотрел, но что-то окончательного ответа на вопрос не нашёл, просто нельзя и всё?

[troiden 0]

Для контроллера Zynq два режима (MAC и PHY) явным образом в документации не обозначены(UG585 (v1.7) February 11, 2014). Т.е., риски того, что они не залинкуются, вполне реальные. Можно ещё пошарить насчёт двух режимов в руководстве для программеров, но что-то я сомневаюсь...

Значит прямое соединение отметаем раз нет полной уверенности. 1000BASE-X это идея, не рассматривали раньше подобный вариант.

 

Посмотрел, но что-то окончательного ответа на вопрос не нашёл, просто нельзя и всё?

Ага, просто не поддерживается.

[prig 0]

...

Всё остальное общение с PHY только по MDIO.

...

Вот с этим MDIO как раз проблемы и возникают. Данные опроса состояния PHY могут влиять на состояние MAC напрямую.

В зависимости от релиза MAC, не всегда есть возможность отключить пуллинг на MDIO и взвести всё вручную.

Т.е., зафорсить линк и т.д. можно, да толку от этого никакого. Какие-то состояния логики контроллера определяются только данными пуллинга.

Отдельные девайсы всё равно будет считать, что у них есть PHY и чего-то ждать от несуществующей физики именно по MDIO.

Сталкивался с такими фичами на MII, GMII и SGMII и после первого приключения использую только девайсы с явно оговоренные режимы.

 

Имха, истоки этой проблемы находятся в Clause 22. MDIO там специфицировано недостаточно чётко, вот и появляется разнобой у производителей.

 

П.С. А вот у девайсов, поддерживающих Clause 45, мне такой мути не попадалось.

[insektazz 0]

Добавлю свои 5 копеек.

Сейчас делаем проект на Zynq, в нем все порты Ethernet подключены к PL части, в которой реализован коммутатор, и далее еще есть связь Ethernet PS-PL через EMIO (везде скорость 1000 Мбит/с). Т.е. коммутатор, реализованный в ПЛИС (PL), коммутирует данные между 4 портами - 3-мя внешними и 1 внутренним.

Так вот на этапе разработки, когда отлаживали части PL-PS, для проверки того, что CPU отправляет данные в ПЛИС и получает их обратно, мы сделали простую схему - CPU Eth - GMII - EMIO - PL - Loopback. Т.е. данные отправляемые с CPU просто завораживаются обратно в ПЛИС.

В итоге данная схема отлично заработала. tcpdump показывал отправляемые и получаемые пакеты, ошибок не было.

 

На мой взгляд (я не разработчик этого решения, больше занимаюсь руководством), это показывает, что связь между двумя Zynq без PHY будет работать без проблем.

 

P.S. У нас после прототипирования осталось 4 Zedboard'а, можем вам продать их и вы сможете проверить свою схему полноценно.

[doom13 0]

Соглашусь, приёмнику RGMII MAC-контроллера для приёма данных необходим передатчик RGMII, и не важно будет это передатчик со стороны PHY или MAC другого устройства.

 

 

Вот с этим MDIO как раз проблемы и возникают. Данные опроса состояния PHY могут влиять на состояние MAC напрямую.

В зависимости от релиза MAC, не всегда есть возможность отключить пуллинг на MDIO и взвести всё вручную.

Т.е., зафорсить линк и т.д. можно, да толку от этого никакого. Какие-то состояния логики контроллера определяются только данными пуллинга.

Отдельные девайсы всё равно будет считать, что у них есть PHY и чего-то ждать от несуществующей физики именно по MDIO.

Сталкивался с такими фичами на MII, GMII и SGMII и после первого приключения использую только девайсы с явно оговоренные режимы.

 

Имха, истоки этой проблемы находятся в Clause 22. MDIO там специфицировано недостаточно чётко, вот и появляется разнобой у производителей.

 

П.С. А вот у девайсов, поддерживающих Clause 45, мне такой мути не попадалось.

Насколько знаю, опрос PHY по MDIO со стороны MAC осуществляется программно, на уровне программного драйвера MAC-контроллера, т.е. если вы сами не захотите, то MAC по MDIO ничего мониторить не будет. Соответственно у PHY есть нога прирывая, которая срабатывает, если произошли какие-то изменения в работе PHY, и уже по наличию данного сигнала логично производить опрос состояния PHY по MDIO. Или Вы хотите сказать что мониторинг состояния PHY со стороны MAC осуществляется на уровне железа?

[insektazz 0]

И еще момент.

Драйвер Ethernet от Xilinx не умеет по умолчанию работать без PHY, хотя вроде как такие настройки упоминаются в Интернете.

Нам пришлось доработать его самим, чтобы он фиксировано работал на 1000FD. Так что если понадобится помощь - обращайтесь.

[DM1206 0]

Насколько знаю, опрос PHY по MDIO со стороны MAC осуществляется программно, на уровне программного драйвера MAC-контроллера, т.е. если вы сами не захотите, то MAC по MDIO ничего мониторить не будет. Соответственно у PHY есть нога прирывая, которая срабатывает, если произошли какие-то изменения в работе PHY, и уже по наличию данного сигнала логично производить опрос состояния PHY по MDIO.

 

По крайней мере, в случае железа и драйверов XILINX - именно так. И, как замечено выше, надо исключить из драйвера обмен с PHY. Это совершенно несложно.