a question about XMOS port Topic is solved

Technical discussions around xCORE processors (e.g. xcore-200 & xcore.ai).
Post Reply
BruceX
Junior Member
Posts: 4
Joined: Sat Aug 20, 2016 9:18 am

a question about XMOS port

Post by BruceX »

I'm a newbie of XMOS and began to study XMOS development recently.
For the XE216-512-TQ128 chip, the usb phy and RGMII both use Port_8A Port_8B Port_1E Port_1F and so on, does it mean usb and ethernet function can't work simultaneously?
The same like that, if USB function is enabled, then the Port_8A, Port_8B are used, is it right that we can't use Port_4A, Port_4B, Port_4C, Port_4D which share the same pins with Port_8A, Port8B ?

Anyone can give an explaination ? Thanks a lot.


View Solution
DemoniacMilk
XCore Addict
Posts: 191
Joined: Tue Jul 05, 2016 2:19 pm

Post by DemoniacMilk »

USB and ETHERNET run on different tiles. Each tile has its own set of ports, so you can use both at the same time.
Some pins are mapped to multiple ports, so ye, some big ports use the same pins as smaller ports. You cant use these simultaneously.
henk
Respected Member
Posts: 347
Joined: Wed Jan 27, 2016 5:21 pm

Post by henk »

To add to that: RGMII must run on tile 1; USB can run on either tile 1 or tile 0; depending on the application.

An example application that would run USB on tile 1 is a board that has both an RGMII and a USB interface, but it only uses one of them decided at boot time (for example, a mixing desk that is either a USB device or an AVB device).

An example application that runs USB on tile 0 is a board that interfaces RGMII and USB.

Cheers,
Henk
BruceX
Junior Member
Posts: 4
Joined: Sat Aug 20, 2016 9:18 am

Post by BruceX »

Thanks for the help and the infomation, it's clear for the usb and RGMII.

But Still a little puzzled about the different width ports sharing the same pins.
I'm using the board XK-AUDIO-216-MC-AB, and the LED array on this board uses Port_4C and Port_4D on tile[1]. In the usb-audio example, the app enables usb on tile[1] and uses Port_8A to communicate with USB phy.

In my understanding, I can't operate LED array when usb function is working because Port_8A and Port_4C/Port_4D share the same pins (X1D14 ~ X1D19). However, when I add some code to enable LED array flash, the USB function seems to work well. I can't understand why the usb function is not affected by the pin's state(X1D14 ~ X1D19).
henk
Respected Member
Posts: 347
Joined: Wed Jan 27, 2016 5:21 pm

Post by henk »

Hi BruceX,

Port 8A and Ports 4C/D are overlapped on the IO pins; but are otherwise independent.

The USB-PHY uses port 8B.
Pins X1D14..X1D21 can still be used with ports 4C and 4D.

This is only the case with XCore 200 devices, not with the older XS1 chips.

Cheers,
Henk
BruceX
Junior Member
Posts: 4
Joined: Sat Aug 20, 2016 9:18 am

Post by BruceX »

Hi Henk

Thanks for the reply.

So it means we use the XMOS ports independent of its associated IO pins, and the ports don't always reflect the state of the IO pins, is it right?
henk wrote:Hi BruceX,

Port 8A and Ports 4C/D are overlapped on the IO pins; but are otherwise independent.

The USB-PHY uses port 8B.
Pins X1D14..X1D21 can still be used with ports 4C and 4D.

This is only the case with XCore 200 devices, not with the older XS1 chips.

Cheers,
Henk
henk
Respected Member
Posts: 347
Joined: Wed Jan 27, 2016 5:21 pm

Post by henk »

Correct, with a caveat.

There is still port precedence.

For pins driving output it looks like this, where each MUX is set to the top if that port is active. This example is for pin X0D14:

Code: Select all

            +
           /|<---- Port 4C bit 0
          + |      +
X0D14 <---| |     /|<--- Port 8B bit 0   
          + |    + |      +
           \|<---| |     /|<--- Port 16A bit 8
            +    + |    + |         
                  \|<---| |
                   +    + |             
                         \|<--- Port 32A bit 28
                          +

So, if port 8B is active, it will take precedence over ports 16A and 32A as far as pin X0D14 is concerned; but port 4C might still beat it to it. Narrower ports always take precedence, and links take precedence over any port (any link that is enabled will take over the pins associated with the link). Note also that when, for example, port 8B is enabled to talk to the USB PHY, it will stop port 16A reaching the pin.

For the general case, section 4 of the data sheet shows which bits of which ports are mapped to each pin.

On the input side, a pin will drive all ports in parallel, with the exception that the USB PHY is muxed into, for example, port 8B.
BruceX
Junior Member
Posts: 4
Joined: Sat Aug 20, 2016 9:18 am

Post by BruceX »

It's clear now, Thanks very much!!!
henk wrote:Correct, with a caveat.

There is still port precedence.

For pins driving output it looks like this, where each MUX is set to the top if that port is active. This example is for pin X0D14:

Code: Select all

            +
           /|<---- Port 4C bit 0
          + |      +
X0D14 <---| |     /|<--- Port 8B bit 0   
          + |    + |      +
           \|<---| |     /|<--- Port 16A bit 8
            +    + |    + |         
                  \|<---| |
                   +    + |             
                         \|<--- Port 32A bit 28
                          +

So, if port 8B is active, it will take precedence over ports 16A and 32A as far as pin X0D14 is concerned; but port 4C might still beat it to it. Narrower ports always take precedence, and links take precedence over any port (any link that is enabled will take over the pins associated with the link). Note also that when, for example, port 8B is enabled to talk to the USB PHY, it will stop port 16A reaching the pin.

For the general case, section 4 of the data sheet shows which bits of which ports are mapped to each pin.

On the input side, a pin will drive all ports in parallel, with the exception that the USB PHY is muxed into, for example, port 8B.
Post Reply