Zynq, обмен по RGMII Опции

[troiden]

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

[insektazz]

Добавлю свои 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]

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

[Дмитрий Мазунин]

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

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