RGMII port usage

[DemoniacMilk]

The xCore-200 Port map shows that most of tile 1's ports are being occupied when using the RGMII on XE(F) devices.

However, the 4 bit ports A..D are not listed as "unavailable", although the 8-bit ports on the same pins are occupied, so I wonder if I may still use them and what the restrictions will be. X1D35/38/39 are 1-Bit ports that are marked as "unavailable" but they not connected to anything.

I plan to simply drive an RGB LED with one of the ports, so no high frequency signals.

EDIT:
"When the RGMII block is enabled, the ports shown can only be used with the RGMII block,
and IO pins X1D26..X1D33/X1D40..X1D43 can only be used with the RGMII block.
Other IO pins and ports are unaffected." - X006991,XS2-UE16A-512-TQ128 Datasheet

So I guess the 1 bit ports may not be used. The pins on the 4 bit ports 4A..4D are used as 8-Bit TX and RX ports so i guess they cannot be used either?

[henk]

Hi,

You can use ports that are (a) not overlapped with the RGMII pins and (b) not used by the RGMII block.

Ports 1O/1P are used by the RGMII block (Figure 16, Section 11), so you won't be able to use them. 1L may be fine - not sure why that is listed. Ports 4A..D may be fine too.

The biggest problem will be to find the resources to drive them - RGMII gobbles up most of the tile, which is the reason that the use of these ports isn't explicitly supported.

Cheers,
Henk

[DemoniacMilk]

Performance should not be an issue here, i'd need the ports to read some switches at startup and to drive an RGB status LED (no PWM, just on/off) and it doesnt matter if the LEDs will be switched on or off with some ms delay. Using the GPIO library for this should be fine (although I am not sure about the chanend consumption with this approach).

I checked the eXplorerKit design files, and X1D0..X1D9, X1D14..X1D21 are not connected, so I guess using them is fine. Still confusing that the respective 8 Bit ports are marked as unavailable, so im not sure if these ports fulfill the first of your two conditions:

(a) not overlapped with the RGMII pins

especially as the ports are defined in the RGMII_PORTS_INITIALIZER:

Code: Select all

#define RGMII_PORTS_INITIALIZER { \
  XS1_PORT_1O, \
  XS1_PORT_1A, \
  XS1_PORT_8A, \  // rgmii_ports.p_rxd_1000
  XS1_PORT_4E, \
  XS1_PORT_4F, \
  XS1_PORT_1B, \
  XS1_PORT_1K, \
  XS1_PORT_1P, \
  XS1_PORT_1G, \
  XS1_PORT_1E, \
  XS1_PORT_1F, \
  XS1_PORT_8B, \ // rgmii_ports.p_txd,
  XS1_CLKBLK_1, \
  XS1_CLKBLK_2, \
  XS1_CLKBLK_3, \
  XS1_CLKBLK_4 \
}

It's also interesting that P8D0 and P8D1 are not marked as unavailable (the rest of the 8 bit port is) while being connected to PHY_INT and PYH_RST. Or do these count as free 1-bit ports that were "manually" assigned to these signals by the eXplorerKits hardware designers? (Same for X1D10 MDIO and X1D11 MDC).

[henk]

It's also interesting that P8D0 and P8D1 are not marked as unavailable (the rest of the 8 bit port is) while being connected to PHY_INT and PYH_RST. Or do these count as free 1-bit ports that were "manually" assigned to these signals by the eXplorerKits hardware designers? (Same for X1D10 MDIO and X1D11 MDC).

You are correct - there are some things that the hardware dictates, and some software conventions.

The pins along the top of the package are the physical connections to the RGMII PHY - so any ports that end up on those pins are no longer useful if an RGMII PHY is connected; that is the first "hard" condition.

The ports that the RGMII shim uses to serialise/deserialise the DDR signals are the ones shown in your initialiser, and in Figure 16 of the datasheet that I am looking at (figure numbers may vary a bit depending on the precise variant of the chip you use). These ports are hardwired to decode some signals, and hence are also out of bounds for anything else. This covers the 8-bit ports; they are not "available" because they are used to connect to the RGMII pins through the block described in the RGMII section.

What's left over is a stack of 4-bit ports, that are wired to pins (such as X1D04..X1D07) through a mux with the 8-bit port. You can probably use port 4B to drive/sample X1D04..07, but because of the lack of resources available this is not explicitly supported in the data sheet.

Cheers,
Henk

[DemoniacMilk]

Ou so internally, the 4 bit ports are completely independent from the 8 bit ports and they are just both routed to the same pins over a mux? I assumed these ports use the same ressources on the chip, not only the same pins.