GPIO Ports used by Ethernet on explorerKIT Topic is solved

If you have a simple question and just want an answer.
Post Reply
kevpatt
Member++
Posts: 30
Joined: Thu Feb 09, 2017 4:53 pm

GPIO Ports used by Ethernet on explorerKIT

Post by kevpatt »

Hi,

I have a question about the GPIO ports used by Ethernet on xCore-200 explorerKIT. The hardware manual makes it clear that Tile X1 ports 1C, 1D, 1M, 1N, 8C (4E+4F) and the upper 4 bits of 8D are dedicated to the Ethernet interface (MII/RGMII). (That is, none of these pins are brought out to GPIO headers, so they are unavailable whether or not the Ethernet feature is enabled.)

Now, the lib_ethernet user manual has a diagram on page 5 (Figure 1: RGMII Port Structure). If I understand it correctly, the manual indicates that *additional* ports (also on Tile X1) are used internally when the Ethernet interface is operated in Gigabit/RGMII mode. These are 1A, 1B, 1O, 1P, 8A, and 8B. This leaves only a single accessible GPIO pin (a single 1-bit port) available: 1L. I suppose this is OK if you pretty much plan to dedicate Tile X1 to GbE.

My question is this: On the xCore-200 explorerKIT specifically, is it possible to operate the on-board PHY in 10/100mbit "MII" mode, leaving ports 1A, 1B, 1O, 1P, 8A, and 8B available for regular GPIO? I don't see a clear answer to this in the documentation. If I don't need Gigabit speeds, I could use the extra I/O. Also, the 10/100 MAC server uses only 2 cores (4 for realtime mode), which means other work could be done on that tile too.

Thanks!


View Solution
peter
XCore Addict
Posts: 230
Joined: Wed Mar 10, 2010 12:46 pm

Post by peter »

Unfortunately, it is not possible to use less pins when using an RGMII PHY, even if you are just running 10/100. You would have to use a 10/100 ethernet PHY externally and then the number of ports required would be reduced.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

If you are looking for ethernet connectivity with XMOS with limited I/O pins and not concerned about realtime access for the ethernet then consider to use a solution from wiznet. The Wiznet solution could interface with XMOS via SPI port pins and the TCP/IP stack is hardened inside their external device. For now, avoid the use of the W7500P as there is some internal bug that limits the operation to 10Mbps but they are working on a resolution which may require a silicon respin.

From Wiznet (USA):

Code: Select all

There has been a report that particular routers would not work with W7500P.

What our R&D has discovered so far is that,

-          A separate IC footprint of W7500 & IP101A will work perfectly.

-          And to answer your question, yes it would work in fixed 10 Mbps connection.
So if you take this approach then source this tool and use mbed (C language coding) to stitch the XMOS and Wiznet together:

https://developer.mbed.org/platforms/WIZwiki-W7500/

You can then remove the Ethernet support code inside the XMOS IP and focus on how to communicate with this external CPU via SPI.

It could be the best of both worlds.
kevpatt
Member++
Posts: 30
Joined: Thu Feb 09, 2017 4:53 pm

Post by kevpatt »

peter wrote:Unfortunately, it is not possible to use less pins when using an RGMII PHY, even if you are just running 10/100. You would have to use a 10/100 ethernet PHY externally and then the number of ports required would be reduced.
Thanks, Peter for the confirmation. It's not a big deal on the explorerKIT. I'm designing another board around xCore-200, and knowing this, I'll just use a MII (10/100) PHY if I become GPIO constrained.

I do wish it was a little clearer in the documentation. The port lists shows the RGMII hardware pins, but does not indicate the additional ports that are used internally in GbE mode. The section on RGMII shows which additional ports are used internally, but does not list all the standard RGMII pins. You have to combine the two lists to get a complete picture. For the additional (internal) ports, it would be nice if XMOS always used ports that are not actually bonded out. That way, GbE becomes a pure "bonus" feature, instead of a feature that sacrifices more GPIO.

SPECIAL REQUEST TO XMOS: In future designs, please allocate additional ports on the core (that are not bonded out) for dedicated hardware like Ethernet and USB. Another even BETTER option would be to have some dedicated logic that presents the ethernet port (PHY access) directly on the internal xCONNECT switch (with it's own node identifier, etc.), so it isn't tied to GPIO ports at all and can be accessed from any tile using standard "channel" communications. Same could be done for USB. It would save ports, cores, code, and RAM. :)
Last edited by kevpatt on Wed Mar 08, 2017 7:10 pm, edited 8 times in total.
kevpatt
Member++
Posts: 30
Joined: Thu Feb 09, 2017 4:53 pm

Post by kevpatt »

mon2 wrote:If you are looking for ethernet connectivity with XMOS with limited I/O pins and not concerned about realtime access for the ethernet then consider to use a solution from wiznet.
I'm familiar with the Wiznet devices as one of their chips forms the basis of the Arduino Ethernet shield. I have encountered a few bugs/issues, but they seem to get the basic job done. However, there are a few reasons I can think of that would make this a less-than-ideal solution:

1. Additional cost of another chip in your design, and associated support components. (maybe that's comparable to the PHY that XMOS requires anyway?)
2. Ethernet over SPI is surely going to be lower bandwidth than even 100 MbE, let alone GbE. So, lower bandwidth applications only.
3. Lack of low-level access (Layer 2)?
Post Reply