Creating Ethernet Interface from MAC and PCS/PMA

[araneidae]

I am attempting to assemble a simple Gigabit Ethernet interface from a Tri-Mode Ethernet MAC (PC051) and a 1G/2.5G PCS/PMA or SGMII (PG047), and I am struggling to see how to correctly wire these components together and generate the appropriate resets.

The figure below shows what I have created using the IP Integrator:

I have simulated the assembly above with the following test conditions:

• gtrefclk_in driven at 125 MHz
• clk_200MZ driven at 200 MHz
• glbl_rstn driven low for 100 ns, driven high afterwards
• configuration vectors set to 0
• sfp_io looped back (tx drives rx)

and after around 3.25 ms both links appear to spring into life, so I presume it's not completely wrong (I started writing this on the assumption that the system was dead, before letting the simulation run for long enough...)

So I guess I have the following questions:

1. Have I wired this correctly?  The documentation is pretty weak and very confusing when it comes to clocking and resets.
2. What on earth am I supposed to do about the AXI resets?  Given that the relevant AXI clocks are being generated by the MAC, isn't it actually the responsibility of the clock source to generate the appropriate resets?
3. Is there any definitive documentation on connecting a MAC and PCS/PMA in this way?

For reference, here is how the components are configured (and I've attached the relevant block design tcl file):

MAC

• Data Rate: 1 Gbps
• Physical Interface: Internal, 1000 Mbps, rx user clk2
• Management Type: Configuration Vector
• All features disabled

PCS/PMA

• Data Rate: 1 G
• Standard: 1000BASEX
• Core Functionality: Device Specific Transceiver, RXOUTCLK, no options
• Shared Logic: in Core

[araneidae]

Forgot to say: this is targeting a Virtex-7 using Vivado 2019.2

[nanz]

Hi @araneidae ,

I recommend you to use 1G/2.5G AXI Ethernet IP and generate it in 1000BASE-X mode. If you do not use processor in your system, you can just simple disable processor mode. This IP wires TEMAC and PCS/PMA IP underneath automatically for you. This will save you work to manually connect them together. 

[araneidae]

Ok, it is clearly not working.

Next step is to push data into the TX AXIS interface (PG051, Normal Frame Transmission).  I see tx_axis_mac_tready go high for two ticks as expected and then low ... and it never goes high again.  I am of course holding tvalid high, tlast low, and I've waited 800 µs with no change, and there appears to be no traffic on the GMII interface.

Any suggestions, please?

[araneidae]

Hmm.

I'd prefer to get the wiring of TEMAC and PCS/PMA done correctly.  After all, if the AXI component does this then it should be pretty easy to document how it should be done.

Also, the interface to the AXI Ethernet component is more complex than I want.

[nanz]

Hi @araneidae ,

How are you sending the traffic on the user interface? Do you have the packet generator or checker?

Once you generate the 1G AXI Ethernet core, you can right click on the IP and click on "Open IP example design" and check the example design in simulation. 

Here is a snapshot in Vivado:

If you are really looking for a manual connection, you can check this one on KU device:

https://www.xilinx.com/support/answers/71662.html

[araneidae]

I forgot to configure {rx,tx}_configuration_vector ... oops .

Regarding traffic generation, I'm literally just sending a byte stream, which is now completing the loop and working properly as far as I can tell, so as far as I can tell everything is good.  I just wish there was more room for confidence.

My problem is that the documentation of the resets is, frankly, terrible.  Let's look at rx_axi_rstn.  The documentation says this:

Active-Low RX domain reset

That's it.  Ok, let's look at the "Resets" section of PG051, Chapter 3.  This says "the reset structure is not simple ... [with] many separate reset regions", but fails to say anything helpful (except, interestingly, a warning not to use {rx,tx}_reset outputs for reset generation), though figure 3-10 does look useful.

The AMBA AXI documentation (I'm looking at ARM IHI 0022D, guess my document is a little old now!) specifies that "reset ... deassertion must be synchronous with a rising edge of ACLK", but figure 3-10 of PG051 does appear to suggest that this is synchronised inside the TEMAC core, for which I'm grateful.

In the end, the references @nanz has given me appear to show all four resets (TEMAC glbl_rstn, rx_axi_rstn, tx_axi_rstn, and PCS/PMA reset) all tied to a common input, which is the same reset structure I'm using, so maybe I'm good.

Really I just wish I didn't have to guess so much.  Finally, what on earth are rx_reset and tx_reset supposed to be good for?  I see that tx_reset is asserted for around 600ns after startup, but rx_reset isn't asserted until the PCS/PMA finally starts to wake up, 3.04ms after startup.  Again, the documentation says little of value.

A final grumble: is it documented anywhere that the system needs to be simulated for more than 3.2ms before it is operational?  Knowing that would have saved me a lot of anxiety (and I probably wouldn't have posted this in the first place!)  I just wish there wasn't so much guesswork in making this system go .

[nanz]

Hi @araneidae ,

For AXI Ethernet IP, there is SIMULATION_MODE that can be set to reduce the simulation time.(PG138)

set_property CONFIG.SIMULATION_MODE {1} [get_ips <component_name>]

For standalone PCS/PMA, you can set EXAMPLE_SIMULATION to reduce the simulation time. (PG047)

For reset, there is Reset Sync logic inside of the core which does the synchronization. If you have better suggestions to modify the doc, please feel free to send through. We welcome any feedback from our customers for improvements. Thank you!

<component_name>

]