Confusion about pins available for USB PHY for XU316-1024-QF60B-xcore_ai

[sonaben]

Hi folks,

I'm programming the XU316-1024-QF60B as a USB audio interface, and implementing the USB PHY I'm not too sure about the documentation. From the datasheet:
(https://www.xmos.com/download/XU316-102 ... eet(6).pdf)

USB PHY.PNG

Mapping the ports to pins available on the chip:
8A => X0D04, X0D05, X0D06, X0D07
1K => X1D34
1H => Not available
8B => X1D16, X1D17, X1D18, X1D19
1E => Not available
1F => X1D13

Can you please confirm that I should not use any of the pins listed above?

The confusion comes from lib_xud which mentions other pins too e.g X0D02 and X0D03:

lib_xud.JPG

Which documentation should I follow?

Thank you!

[fabriceo]

Hello

for the XU316 QF60, the recommended tile for the USB phy is tile 0, this is the best configuration to optimize pin outs as the usb pins are not provided on the qfn package.

on tile 0, X0D04, X0D05, X0D06, X0D07 are used for the quad SPI flash device and it is not recommended to use them for other purpose unless you have proper chip selection.

you can get some insight with the mapping file available here:
https://www.xcore.com/viewtopic.php?t=8379
and you can certainly leverage the schematic from the pawpaw v3.0 which is in this post:
https://www.xcore.com/viewtopic.php?p=40690#p40690

[michaelf]

Hello

for the XU316 QF60, the recommended tile for the USB phy is tile 0, this is the best configuration to optimize pin outs as the usb pins are not provided on the qfn package.

on tile 0, X0D04, X0D05, X0D06, X0D07 are used for the quad SPI flash device and it is not recommended to use them for other purpose unless you have proper chip selection.

you can get some insight with the mapping file available here:
https://www.xcore.com/viewtopic.php?t=8379
and you can certainly leverage the schematic from the pawpaw v3.0 which is in this post:
https://www.xcore.com/viewtopic.php?p=40690#p40690

I recently contacted support with a very similar question to this topic. I, too, am using the QF60B as a USB audio interface, along with a requirement to access QSPI flash during runtime (i.e. not just at boot). I note that the USB PHY and QSPI flash pins overlap on tile 1. The multichannel audio evaluation board gets away with using QSPI flash and using the USB PHY on tile 0 because it only uses the flash to load the boot rom i.e. never uses flash and USB simultaneously.

I was told that to use the QSPI flash and USB PHY simultaneously, then one needs to place the USB code (lib_xud and any endpoints) on tile 1. This leaves you with single-bit ports 1A, B, C, D and G available to use on tile 1. I've attached of a partial screenshot of the broken out pins on tile 1, marking which ones are used by the USB PHY for reference.

I'm not sure I fully understand when you say that "usb pins are not provided on the qfn package".

[fabriceo]

Hi Michaelf,

The USB DM and USB DP pins are obviously on the Q60 package on pin 28 and 29.
But all the other pins required on the xu316 silicium to connect the PHY layer and the TILE0 are not on the Q60 package:

Code: Select all

FLAG0 P1E X0D12
FLAG1 P1F X0D13
TXDRDYIN P1H X0D23
RXRDY P1I X0D24
USBCLK P1J X0D25
TXDRDYOUT P1K X0D34

they exist and are internally connected but somehow they are hidden and this is why it is better to use USB on tile 0.

Now, flash device is usually on TILE0 too, on different ports (P1B, P4B, P1C) so here I don't see any overlap as such.

could you clarify why it would not be possible to use the flash on tile0 while using lib_xud ???
if you use a specific task to talk to the libquadflash, if you check that the clock block used by libquadflash is not already allocated and finally if you ensure that none of the buffer/decouple/endpoint task is blocked by a flash command by having async RPC or messaging or fifo, then I don't understand why it would not be possible ?
The DFU upgrade process is a good example that it is feasible. But there is a quite complex mechanism implemented with a combinable task "DFUhandler"

Thanks in advance for clarifying, as I can imagine this would be an incredible limitation of course

[michaelf]

Hi Michaelf,

The USB DM and USB DP pins are obviously on the Q60 package on pin 28 and 29.

Agreed about DM and DP - when I'm talking about ports for USB, I'm specifically referring to the USB PHY itself as per section 11 of the datasheet.

But all the other pins required on the xu316 silicium to connect the PHY layer and the TILE0 are not on the Q60 package:

Code: Select all

FLAG0 P1E X0D12
FLAG1 P1F X0D13
TXDRDYIN P1H X0D23
RXRDY P1I X0D24
USBCLK P1J X0D25
TXDRDYOUT P1K X0D34

they exist and are internally connected but somehow they are hidden and this is why it is better to use USB on tile 0.

All of the pins exist internally, as you say, different packages (60 pin 128 pin, 265 pin) just provide external access to more or less of them. It doesn't matter that not all of the pins aren't broken out on the Q60 package, because the USB PHY is just using them internally. There's no difference in allocating the USB PHY to tile 0 or tile 1.

Now, flash device is usually on TILE0 too, on different ports (P1B, P4B, P1C) so here I don't see any overlap as such.

Apart from burning a QSPI flash progam onto OTP configured with different pins (penultimate paragrph of section 9.1), QSPI flash is always on tile 0. It's the pins that are hardcoded for usage with QSPI flash, so, as you say, it is ports 1B, 4B and 1C, but specifically those ports on tile 0.

The overlap I referred to previously comes from TXD in the USB PHY, which uses port 8A. Looking at the datasheet, we can see that port 8A is partially available on tile 0 (bits 2, 3, 4 and 5) on pins X0D04 to X0D07. Hence, port 4B and 8A overlap. Look at the datasheet for the FB265 package to see all the ports and how they overlap. The ports are mapped to the same pins - the FB265 pinout is a superset of the 128 package, which is a superset of the 60 pin package.

could you clarify why it would not be possible to use the flash on tile0 while using lib_xud ???

Because port 8A (the TXD pins for the USB PHY) overlaps with port 4B (the data pins for the QSPI flash). You can't use both at the same time; only one port per pin can be used.

if you use a specific task to talk to the libquadflash, if you check that the clock block used by libquadflash is not already allocated and finally if you ensure that none of the buffer/decouple/endpoint task is blocked by a flash command by having async RPC or messaging or fifo, then I don't understand why it would not be possible ?
The DFU upgrade process is a good example that it is feasible. But there is a quite complex mechanism implemented with a combinable task "DFUhandler"

Thanks in advance for clarifying, as I can imagine this would be an incredible limitation of course

I haven't looked fully at the DFU code because I don't need it in my project, but the bits I have seen, all audio is stopped (i.e. USB usage is stopped) when in DFU mode. Thus, the USB won't be in use whilst the DFU code is communicating with the QSPI flash.

[fabriceo]

Hi Michaelf
I better understand your concern about Port 8A and port 4B, but there is a mechanism of port precedence/priority which solves the problem. the phy is connected to 8A, right, but when you use P4B then it connects to the X0D3/4/5/6 with full priority and this doesn't impact P8A or PHY. This is well documented somewhere but cannot produce a link easily.

Regarding DFU, you are right that there is STOP_AUDIO sequence sent from Decouple to Audio task, in order to stop generation of I2S patterns , BUT there is a specific "dummy deliver" task which is launched in order to continue exchanging data with Decouple and the USB (xud,buffer, decouple, endpoint0) is not stoped and just continue to handle the USB communication, which is mandatory to get the DFU packets to be writen in flash.

I suggest you reiterate with a support ticket to XMOS, the answer you got is confusing and not good :)
hope this helps, good luck for your project

[michaelf]

Hi Michaelf
I better understand your concern about Port 8A and port 4B, but there is a mechanism of port precedence/priority which solves the problem. the phy is connected to 8A, right, but when you use P4B then it connects to the X0D3/4/5/6 with full priority and this doesn't impact P8A or PHY. This is well documented somewhere but cannot produce a link easily.

Regarding DFU, you are right that there is STOP_AUDIO sequence sent from Decouple to Audio task, in order to stop generation of I2S patterns , BUT there is a specific "dummy deliver" task which is launched in order to continue exchanging data with Decouple and the USB (xud,buffer, decouple, endpoint0) is not stoped and just continue to handle the USB communication, which is mandatory to get the DFU packets to be writen in flash.

I suggest you reiterate with a support ticket to XMOS, the answer you got is confusing and not good :)
hope this helps, good luck for your project

My understanding was that narrower ports take priority, but that seems to be separate to what you're saying where the USB PHY is not impacted at all. I'll send another ticket and see if we can get a definitive answer! Thanks for your input.

[Joe]

The USB "PHY" is somewhat of a special case as it is internal to the device and connected to port 8A before it makes it to the pins. In this way it never interacts with port 4B which can be used as normal.

For more info on port precedence in general, see my replies in the following thread:
https://www.xcore.com/viewtopic.php?p=40696#p40696

[michaelf]

The USB "PHY" is somewhat of a special case as it is internal to the device and connected to port 8A before it makes it to the pins. In this way it never interacts with port 4B which can be used as normal.

For more info on port precedence in general, see my replies in the following thread:
https://www.xcore.com/viewtopic.php?p=40696#p40696

Thanks for your clarification, it finally just clicked for me (the combination of Thomas Ng's answers on my support tickets, your comment in this thread, and your comment in the thread you just linked to).