Jump to content

    

Zynq, обмен по RGMII

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

Share this post


Link to post
Share on other sites
Официальный форум так и не смог дать ответа.

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

Интерфейс 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, то соединяйте их шнурком и далее решайте вопросы взаимодействия уже на протокольном уровне.

Share this post


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

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

Share this post


Link to post
Share on other sites
Если, у вас два Цинка на одной плате, то наверное есть более разумный способ наладить взаимосвязь между армами.

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

 

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

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

Share this post


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

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

Share this post


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

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

Share this post


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

...

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites
В общем случае, всё зависит от реализации 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

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

Share this post


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

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

 

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

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

Share this post


Link to post
Share on other sites
...

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

...

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

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

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

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

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

 

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

 

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

Share this post


Link to post
Share on other sites

Добавлю свои 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'а, можем вам продать их и вы сможете проверить свою схему полноценно.

Share this post


Link to post
Share on other sites
Соглашусь, приёмнику 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 осуществляется на уровне железа?

Share this post


Link to post
Share on other sites

И еще момент.

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

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

Share this post


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

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this