cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Participant
Participant
10,976 Views
Registered: ‎09-10-2012

Direct RGMII connectrion between two Zynq's.

Is it possible to connect two Zynq's with PS RGMII interface without PHY?

0 Kudos
33 Replies
Highlighted
Xilinx Employee
Xilinx Employee
10,913 Views
Registered: ‎08-01-2008

The Gigabit Ethernet Controller in Zynq-7000 AP SoC supports the following PHY modes:

RGMII v2.0 through the MIO interface
GMII through the EMIO interface

Other PHY interfaces can be implemented by using appropriate shim logic in the PL. Currently available shim cores are as follows:

MII to RMII; see the Reduced Media Independent Interface (RMII) page for more information.
GMII to RGMII; see the GMII to RGMII (http://www.xilinx.com/products/intellectual-property/gmii-to-rgmii.htm) page for more information.
GMII to SGMII/SGMII over LVDS/1000 Base-X; see the Ethernet 1000 Base-X PCS/PMA or SGMII (http://www.xilinx.com/products/intellectual-property/DO-DI-GMIITO1GBSXPCS.htm) page for more information.
Thanks and Regards
Balkrishan
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
10,911 Views
Registered: ‎08-01-2008

http://www.xilinx.com/support/answers/51616.html
Thanks and Regards
Balkrishan
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.
0 Kudos
Highlighted
Participant
Participant
10,908 Views
Registered: ‎09-10-2012

Thanks for reply, but my question is about different aspect.
We are thinking about connecting two separate Zynq's ARM cores via ethernet.
There are two variants:
1. Zynq -> RGMII -> PHY -> UTP Cable -> PHY -> RGMII -> Zynq
2. Zynq -> RGMII -> Zynq.
Second variant will be the best, but we must know that it is able to work.

Similar question is discussed in this thread:
http://forums.xilinx.com/t5/Zynq-All-Programmable-SoC/Direct-MAC-MAC-connection-to-Ethernet-switch-without-a-PHY/m-p/433342#M1707

0 Kudos
Highlighted
Scholar
Scholar
10,848 Views
Registered: ‎02-03-2010

Hi ,

 

 I do not think xilinx test high-speed point-to-point communication path on a board between two devices for Ethernet.

It was always with Marvel chip.

 

You may connect this as below. The right side of one device and left on another device.

RXD    <-TXD

TXD   -> RXD

TXCTL -> RXCTL

RXCTL <- TXCTL

RXC <- rx clock

TXC -> tx clock

 

But RGMII specification enforces some rules for clock speeds for changing transmissin and reception speed.

You need to maintan these device to device.

I believe it can be trated as normal parallel interface running at DDR operation.

You need to evaluate the timing to be met for DDR interface with given 4ns data window.

 

Also user need to take care of the in band signalling (as per protocol to exchange register level details of Link sptatus i.e., speed and duplex).

 

 

 

Regards,

Koti Reddy

--------------------------------------------------​--------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------
0 Kudos
Highlighted
Scholar
Scholar
10,830 Views
Registered: ‎02-03-2010

Hi,

 

If your query is answered, please close the thread by marking the answer.

 

Regards,

KR

--------------------------------------------------​--------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
8,887 Views
Registered: ‎07-21-2014

Hi,

 

is such a "cross connection" working?

Asking for positive, real experience.

 

I am about doing such a connection from ZYNQ PS (Ether0) to another CPU/Controller using RGMII on the same PCB; basically I just want to use fixed 100Mbit speed. 

I want to save money by avoiding PHY.

 

Frank

 

0 Kudos
Highlighted
Participant
Participant
8,882 Views
Registered: ‎02-11-2009

This should work. But not only hardware links shoul be set correctly (e.g. to be compatible with RGMII spec). You have to do some updates in Linux driver as it expect some phyter for configuration -- eg. link negotioation for link speed (10/100/1000) etc. Of course if you are using Linux.

--
Research Assistant at Brno University of Technology | CEO at RehiveTech spin-off company
0 Kudos
Highlighted
Visitor
Visitor
8,880 Views
Registered: ‎07-21-2014

Thanks for reply ....

 

I will use fixed 100Mbit UDP point-2-point, propretary handshake protocol for simple data transfer between ZYNQ ARM core0 (core1 not used) and other controller on the PCB.

Just running bare metal SW (one main loop) on ARM core0, no OS. It shall collect data over the ethernet and feed it into the PL via FIFOs

 

It SHOULD work, yes; but I dug the whole web for confirmation, without finding any .

 

Frank

0 Kudos
Highlighted
Newbie
Newbie
7,859 Views
Registered: ‎01-27-2016

Hi Frank,

 

Could you update on your work, did the direct connection worked?

 

Thanks,

Yossi

0 Kudos
Highlighted
Visitor
Visitor
6,089 Views
Registered: ‎07-21-2014

Still no Progress ...

 

In a first step I am trying to to use a Switch (88E6352/port-5) with CPU compliant RGMII port (no PHY) without MDIO slave.

There seems to be an issue with the lwip which is relying on MDIO.

 

Topic here, no answer/solution: https://forums.xilinx.com/t5/Zynq-All-Programmable-SoC/Direct-MAC-MAC-connection-to-Ethernet-switch-without-a-PHY/m-p/742289#M14232

 

Frank

0 Kudos
Highlighted
Moderator
Moderator
6,069 Views
Registered: ‎09-12-2007

I created a wiki article for the fixed link support in the macb driver ( linux). I used the gem via EMIO just to test on a Zynq ultrascale. But the same steps apply on Zynq.
0 Kudos
Highlighted
Moderator
Moderator
6,068 Views
Registered: ‎09-12-2007

0 Kudos
Highlighted
Visitor
Visitor
6,038 Views
Registered: ‎07-21-2014

Thanks.

 

Did you face any issue with the MDIO Interface of the MAC?

(I can not see this in your Demo)

 

I just run the peripheral test (one of the Default applications in the SDK) and it fails, obviously due to the missing PHY.

 

Is there any hardwired logic from MDIO and so called "Control Registers" into the MAC-RX/MAC-TX?

Some automatism which relies on some valuable data from MDIO which is out of the control of the ARM CPU (here APB-Slave)?

 

ZYNQ_ETH-MAC.jpg

 

 

0 Kudos
Highlighted
Scholar
Scholar
5,828 Views
Registered: ‎04-04-2014

I see this has not been marked as solved yet. I am trying to do something very similar, only between a Zynq PS MIO and another processor.

 

Basically, can the Zynq be configured as the PHY and leave my other processor (which doesn't support MAC-to-MAC links for RGMII) as the MAC?

 

Are the hardware connections simply to connect the RX to TX equivalent pins etc..? (with added skew on the clocks).

 

Has anyone got this working?

 

Thanks

0 Kudos
Highlighted
Participant
Participant
5,398 Views
Registered: ‎03-09-2016

Hi,

 

We also try to connect zynq 7045 gem0 RGMII MAC to marvell 88e6352 eth. switch port 5 which is RGMII MAC.

It is appreciated if anyone has solved and could give information about this issue?

 

thanks,

 

 

0 Kudos
Highlighted
Scholar
Scholar
5,391 Views
Registered: ‎04-04-2014


@idogan wrote:

Hi,

 

We also try to connect zynq 7045 gem0 RGMII MAC to marvell 88e6352 eth. switch port 5 which is RGMII MAC.

It is appreciated if anyone has solved and could give information about this issue?

 

thanks,

 

 


Hi idogan,

 

We are going to try something similar to you by connecting a Zynq to a Marvell 88E6321, which is a 7 port ethernet switch. I have asked the rep who recommended the device and he is confident that it will work. the 88E6321 does not say if it is a RGMII MAC or PHY, so the understanding is that it can work as both. It does say it can connect to a CPU master. The datasheet does say it is able to operate as either an RMII/MII MAC or PHY.

 

We will know when our PCB is completed and ready for test, probably around October.

0 Kudos
Highlighted
Participant
Participant
5,383 Views
Registered: ‎03-09-2016

Hi ,

 

thanks a lot for the reply, 

we have been working on this switch to use it with our zynq7045 board, for long time but still could not. I have some unclear points, and I appreacited if you could give some information about them if you knows;

 

1) Considering our case similar to your case, that is RGMII MAC-to-MAC connection, what is the correct connections of the pins between zynq and marvell switch, cross (zynq TXpins->marvell RXpins, zynq RXpins<-marvell TXpins) pr straight (zynq TXpins<->marvell TXpins, zynq RXpins<->marvell RXpins)???

 

2) Marvell 88e6352 switch has address pins, called ADDR[4:1]. According to the pins state, single-chip addressing mode (that is address = 0) or multi-chip addressing mode (that is address different than 0) can be selected. Which mode should be used to be able to work with zynq/petalinux??

Why I am asking that, when multichip addressing mode is selected, on u-boot prompt we could not access the registers of the chip using mii tool (mii info, mii read .... these are u-boot commands). But, in single-chip addresing mode, we can access the registers of the ethernet chip.

 

thanks, again.

 

0 Kudos
Highlighted
Scholar
Scholar
5,380 Views
Registered: ‎04-04-2014


 

 

1) Considering our case similar to your case, that is RGMII MAC-to-MAC connection, what is the correct connections of the pins between zynq and marvell switch, cross (zynq TXpins->marvell RXpins, zynq RXpins<-marvell TXpins) pr straight (zynq TXpins<->marvell TXpins, zynq RXpins<->marvell RXpins)???

  


I would just make sure input pins connect to output pins and vice versa. So, our wiring has Marvell Rx Pins (e.g. P5_INCLK) connected to Zynq TxPins (e.g. MII1_TCLK). Use Table 16-11 of the Zynq TRM UG585 to check the direction of the Zynq pins and then the Marvell Datasheet for those pins.

 

The other thing to make sure of is adding delay to the TxClk and RxClk lines. The RGMII spec has the clock edges aligned to data edges. In order for the data to be clocked in correctly a 1.5ns (approx) delay needs to be added to the clock signal to centre the clock edge in the data eye. Often devices have the ability to compensate for this delay on-chip rather than having to resort to PCB components to create the delay. The Zynq does not have this ability but the Marvell device does. I believe this is sufficient but the delay compensation does beed to be enabled via the MDIO interface.

 


 

2) Marvell 88e6352 switch has address pins, called ADDR[4:1]. According to the pins state, single-chip addressing mode (that is address = 0) or multi-chip addressing mode (that is address different than 0) can be selected. Which mode should be used to be able to work with zynq/petalinux??

Why I am asking that, when multichip addressing mode is selected, on u-boot prompt we could not access the registers of the chip using mii tool (mii info, mii read .... these are u-boot commands). But, in single-chip addresing mode, we can access the registers of the ethernet chip.

 


Multichip mode is there if you wish to access the slave PHY device memory maps via the Marvell chip. You conect each PHY MDIO interface to the MDIO_PHY interface on the Marvell chip. You give each device an address on that bus (hardware resistors). Then you should be able to access their memory map via the MDIO_CPU interface that is connected to the Zynq.

 

We have no downstream PHY devices so are only interested in single chip mode. I don't know for sure why it changes your behaviour, possible the address map is different in multichip mode to account for the different devices.

 

 

As you are unable to get the Zynq-Marvell connection to work it would be interesting to know what your connections are.

 

Thanks

0 Kudos
Highlighted
Participant
Participant
5,367 Views
Registered: ‎03-09-2016

Hi,

 

thanks for the reply with details. I see that we think similar things about our question;

 

1) we have also connected to pins such that output pins come into input pins on both side, that is cross connections like your comment. I have also utilised the information of the TRM Table 16-11.

 

In device tree, gem mode is rgmii-id, id means internal delay.. That is, we can think that zynq may obey the spec for RGMII timing consideration. If not, I do not know how to enable delay compensation for the zynq, maybe vivado ???

 

The default value of the delay compensation for the marvell switch is "default" means add delay not activated. We read the Physical Control Register from the u-boot, and gives 0 to those bits. I will try to set those bits and test again.

 

2) Actually, single-chip addresing mode is also enough for us since only this switch is connected to mdio bus. Just want to know if you have experienced also or not.

 

3) Our conneciton is cross explained above #1, PCs connected to other PHY ports of the switch for example port0, port2, can ping with each other. However, ping from and to the zynq is unsuccesful.

Actually, when I observe the pins with oscilloscope while pinging PC to zynq and pinging Zynq-to-PC; switch port5 RGMII TX pins are acitvated, that is it takes ping request from the port0 connected to a PC and send to Zynq. However, there is no any activity on zynq RGMII TX pins when pinging zynq to PC. Only TX clock which is 125mhz seen always from the TX pins side of the zynq RGMII pins.

 

Maybe our device tree is not proper one, I am still trying to different device tree configurations. Do you have any proper device tree configuration, for marvell switch? In addiditon to that, kernel has DSA driver feature, do you enable it or just use macb driver?

 

0 Kudos
Highlighted
Participant
Participant
5,147 Views
Registered: ‎03-09-2016

Hi,

 

I do not enable dsa within the kernel. I try to follow follwing patch from the xilinx side defined below for petalinux 2017.1;

https://www.origin.xilinx.com/support/answers/69132.html

It describes the patch for proper using of the macb driver.

 

thanks,

 

 

0 Kudos
Highlighted
Scholar
Scholar
5,146 Views
Registered: ‎04-04-2014

Hi,

 

We are still in the PCB design phase, we don't have a board we can test software with yet so I cannot help with everything just now.

 

I was under the impression that the Zynq did not have internal delay compensation. However, I cannot find reference to this in the TRM right now so I don't know what I thought that. I am going to investigate. Im the meantime, I would turn on the internal delay at the Marvell switch. If the Marvell switch is not aligning the data and clock then the Zynq will not receive any valid data and therefore not respond, like you have seen.

 

The other thing to check is that you are running at 1.8V or 2.5V on the Zynq bus. The Zynq RGMII interface is not capable of running at 3.3V.

 

0 Kudos
Highlighted
Participant
Participant
5,145 Views
Registered: ‎03-09-2016

Hi,

 

We have tested all the peripherals with related parts on our PCB such as USB, SPI, I2C, DDR, QSPI Flash ,eMMC, usb-to-jtag, Uarts, power circuitry, reset circuitry etc... but only ethernet switch. I hope you will work on your PCB without any problems especially with ethernet switch.

 

You are right but when ping from PC-to-zynq, switch get ping request from port0 which is connected to PC, and also send ping data to zynq over port5 rgmii pins since it can be seen on switch port5 RGMII TX pins using oscilloscope. now, forgot about the whether zynq can receive ping request as valid or not.

Since main problem is different;

 

stops the ping command PC-to-zynq and then

run ping command on petalinux console (ping 192.168.2.30) that is now zynq start to ping to PC, I could not see any activity on Zynq RGMII TX pins. This is the problem, eth0 operation state is shown as always down using this command;

 

root@plnx_arm:~# cat /sys/class/net/eth0/operstate
down
root@plnx_arm:~#

 

by the way, zynq RGMII interface is powered by 1.8V.

 

thanks,

0 Kudos
Highlighted
Scholar
Scholar
5,133 Views
Registered: ‎04-04-2014

I hope you get it working. My main concern with the Marvell chip was it's ability to connect to the Zynq RGMII MAC. The Marvell rep assured me that this would work just fine so I am going a little bit on faith here.

 

Thanks

0 Kudos
Highlighted
Participant
Participant
5,121 Views
Registered: ‎03-09-2016

thanks, we are continue to work on further for a couple days. On the other hand, we have also started to make new PCB design which now include a PHY between zynq and ethernet switch. By this way, zynq deals with only one PHY connected to it,  and this PHY will be connected to one of the P0-P4 ports of the switch, P5 and P6 disable, so that ethernet switch behaves as normal switch. I suggest to you to consider two alternative design for your board, one for direct connect zynq to switch, other for zynq->PHY->switch conection.

 

thanks,

0 Kudos
Highlighted
Scholar
Scholar
5,105 Views
Registered: ‎04-04-2014


@idogan wrote:

thanks, we are continue to work on further for a couple days. On the other hand, we have also started to make new PCB design which now include a PHY between zynq and ethernet switch. By this way, zynq deals with only one PHY connected to it,  and this PHY will be connected to one of the P0-P4 ports of the switch, P5 and P6 disable, so that ethernet switch behaves as normal switch. I suggest to you to consider two alternative design for your board, one for direct connect zynq to switch, other for zynq->PHY->switch conection.

 

thanks,


 

Thanks,I'm sure that approach will work. Is this purely a back-to-back PHY chip? Which one are you going to use?

Thanks



 

 

0 Kudos
Highlighted
Participant
Participant
5,086 Views
Registered: ‎03-09-2016

We will use the PHY used on ZC706 board. I am not sure it is a back-to-back PHY, but we do not use back-to-back PHY connection. We will route the zynq-PHY connection as ZC706, and the PHY's 10/100/1000 interface not going to outside, instead we will route it to the one of the P0-P4 10/100/1000 interface of the switch. P5 and P6 R/G/MII digital interface of the switch are disabled.

 

thanks,

0 Kudos
Highlighted
Scholar
Scholar
5,015 Views
Registered: ‎04-04-2014


@idogan wrote:

We will use the PHY used on ZC706 board. I am not sure it is a back-to-back PHY, but we do not use back-to-back PHY connection. We will route the zynq-PHY connection as ZC706, and the PHY's 10/100/1000 interface not going to outside, instead we will route it to the one of the P0-P4 10/100/1000 interface of the switch. P5 and P6 R/G/MII digital interface of the switch are disabled.

 

thanks,


Ok, I can see that will probably work. 

 

Out of interest, have you tried enabling the delay on the Marvell device to see if that fixes it?

0 Kudos
Highlighted
Participant
Participant
5,002 Views
Registered: ‎03-09-2016

Hi ,

 

Yes, I enabled the delay bits of the marvell switch at uboot using "mii write", then run to kernel but still problem. Actually, we see the lan0 to lan3 (port4 is not used so no lan4) and eth0 using "ifconfig -a". However, when we try to up eth0, "ifconfig eth0 up", see the below;

macb e000b000.ethernet eth0: no PHY found
ifconfig: SIOCSIFFLAGS: Resource temporarily unavailable

 

No phy found is reasonable since zynq connected to switch at port5 with rgmii interface, that is no phy mac-to-mac.

 

and, also when we try to up lan0, "ifconfig lan0 up", see the below;

ifconfig: SIOCSIFFLAGS: Network is down

 

you can find the ifconfig -a below;

 

root@plnx_arm:~# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:0A:35:00:1E:53  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:145 Base address:0xb000

lan0      Link encap:Ethernet  HWaddr 00:0A:35:00:1E:53  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lan1      Link encap:Ethernet  HWaddr 00:0A:35:00:1E:53  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lan2      Link encap:Ethernet  HWaddr 00:0A:35:00:1E:53  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lan3      Link encap:Ethernet  HWaddr 00:0A:35:00:1E:53  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1%1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

sit0      Link encap:IPv6-in-IPv4  
          NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

 

thanks,

0 Kudos
Highlighted
Scholar
Scholar
4,982 Views
Registered: ‎04-04-2014

Hi Idogan,

 

It would seem you just can't get this interface working. As we are working on slightly different devices (88E6321 vs 88E6532) I decided to compare the datasheets. They are very similar, both 7 port gigabit ethernet switch, the main difference between the exact combination of port types. But I did notice a significant difference, which may just be the datasheet wording. 

 

If you look at the RGMII connection diagram (Fig 14, Page 46 for 88E6352, Fig 11 Page 43 88E6321) the wording is different. The 88E6352 says "Port 5 or 6 acting as a MAC" whereas the 88E6321 just says "Port 2, Port 5 or Port 6". This would indicate why you cannot get the switch working as a PHY. 

 

I have asked my sales rep about this for confirmation but I suspect my device is the same.

 

You said you were looking at the 88E6111R MAC/PHY chip that is used on the ZC706 board. I did wonder about using this but was unsure whether the PHY interface would work because it usually interfaces to the transformer magnetics you would find in PHY connector rather than into another digital interface. You may want to also consider the MAX24287, which is an RGMII to SGMII converter. We used this on another design which had no ethernet switch.

 

Good luck

0 Kudos