Pin re-assignment for XMOS USB interface?

[jerryXCORE]

I am developing USB interface with XS1-L16. According to the datasheet, pins should be assigned:
* D12, D13, D22, D23: ULPI_STP, ULPI_NXT, ULPI_DIR, ULPI_CLK
* D14---D21: ULPI_DATA[0...7]
* D2----D9: reserved ( as PORT_USB_TXD)
(D26----D33, D37--D43 also reserved)

Can I change pin assignment (easy PCB routing for me), so that I can still use XMOS USB library?
*D14---D21: reserved ( as PORT_USB_TXD)
* D2----D9: ULPI_DATA[0...7]
[/highlight]
Thanks!

[Guest]

Unfortunately, ULPI pin configuration cannot be changed.

[jerryXCORE]

I understand what you mean.

But are you XMOS insider? Can you read carefully about my new pin assignment, and double confirm your answer?
(I just change the pin assignments for ULPI_DATA[0..7], does it really matter?)


Thanks!

[Bianco]

ULPI is hardware assisted on XS1-L, so you cannot diverge from the assignments as stated in the datasheet.

[jerryXCORE]

I understand that it is "hardware assisted", but let's see the XUD library("xud.h"):
#define PORT_USB_TXD on USB_TILE: XS1_PORT_8A
#define PORT_USB_RXD on USB_TILE: XS1_PORT_8B

So, with my new pin-assignments, I just exchange the assignments:
#define PORT_USB_TXD on USB_TILE: XS1_PORT_8B
#define PORT_USB_RXD on USB_TILE: XS1_PORT_8A

So how does my assignment affect the XUD library function?
should not it still work?

[kubao]

ULPI is hardware assisted on XS1-L, so you cannot diverge from the assignments as stated in the datasheet.

What does it mean that XS1-L has "hardware assisted" USB? There is no documentation whatsoever for any USB-specific hardware assistance module in the L devices. Do you have any official sources for such?

After spending a couple of hours looking at the XUD source code, I was under an impression that the ports were used merely as an implementation detail - to leverage the port hardware in a rather unorthodox way. In such case, the ports should be freely reassignable. Basically, XUD seems to use 6 extra ports on top of the 5 ports used for ULPI (1 for data, 4 for control signals).

XUD has other nice undocumented tidbits, such as granular port delay settings...

[mon2]

Taking a logical stab at this that the specified pins for the USB PHY are proven to be operational with the supplied code. Respectively, the developers are hinting at some potential coding grief which you may face down the road if the USB PHY ports are tasked to other locations. Otherwise, cannot see a reason why the pins could not be re-assigned to suit your project since in the end, the USB PHY is "just" another digital interface. As noted, the specified pins for the project have some proven history with the locked in software support.

Curious to know if you have reviewed the use of the XS1-U16A-128-FB217 which features an internal USB PHY. Granted not the same number of IO as the XS1-L16A but then again, you no longer have to stitch an external USB PHY. Would that not be a cleaner solution also for your PCB layout ?

How many PCB layers are you planning to use for this project ? We would recommend as a minimum, 4 layers (FR4). Do apply a good quality USB 2.0 compliant ESD TVS protection device onto the USB connector / interface.

Do you have access to USB bus analyzer tools ?

Updating my own post :)

The XS1-L16A appears to be automotive grade (ie. support for higher temps @ -40C..105 C - nice !!)
The XS1-U16A is available in commercial temp (0..70 C) and also industrial (-40C..85 C) temp (but not automotive grade / temp)

interesting to learn this. Is the operating temp a factor to your component decision ?

[kubao]

Taking a logical stab at this that the specified pins for the USB PHY are proven to be operational with the supplied code. Respectively, the developers are hinting at some potential coding grief which you may face down the road if the USB PHY ports are tasked to other locations. Otherwise, cannot see a reason why the pins could not be re-assigned to suit your project since in the end, the USB PHY is "just" another digital interface. As noted, the specified pins for the project have some proven history with the locked in software support.

It appears that there is a hidden hardware assist module, called UIFM, that lives even in L series devices. libxud appears to use this hidden hardware - upon some further examination, it seems that it doesn't speak ULPI directly. If it did speak ULPI, it really wouldn't need the extra ports for anything. I was initially under the impression that the ports were used for their events only, but that's not the case and I was wrong about that.

The existence of UIFM is not such a surprise, since XMOS took the approach of not providing comprehensive product documentation. When you use OMAP from TI, you get a nice 3,500 page document that tells you everything there's to be known about what's on the chip. XMOS thinks that their users don't need any of this. Frankly said, the only reason that we use XS-1 is that there's no other fixed-function silicon that does what we need. The documentation itself would be grounds to disqualify it, but other providers of similar silicon seem to be even worse. As it is, XS-1 gives us the competitive advantage we need, so reluctantly, we can't but use it. I'm doing quite a bit of reverse-engineering to figure things out, though.

Curious to know if you have reviewed the use of the XS1-U16A-128-FB217 which features an internal USB PHY. Granted not the same number of IO as the XS1-L16A but then again, you no longer have to stitch an external USB PHY. Would that not be a cleaner solution also for your PCB layout ?

We have multiple ethernet PHYs already, and two L16A's connected over two links, so the USB PHY is not a big deal. Currently we run a USB2 FS master, but a HS master is not out of the question as the timings all work out. With some head-scratching a "native" ULPI HS device might work, but that requires some serious pushing of the architecture, and the use of two overlapping ports.

How many PCB layers are you planning to use for this project ? We would recommend as a minimum, 4 layers (FR4).

We use six, with two full coverage power planes that the return currents get a good ride on.

Do apply a good quality USB 2.0 compliant ESD TVS protection device onto the USB connector / interface. Do you have access to USB bus analyzer tools ?

The PHY supplies sufficient ESD protection. We have a bus analyzer too.

Is the operating temp a factor to your component decision ?

Very much so.

[Ross]

Have you considered using xCORE-200? You would get some I/O back.

[mon2]

Be sure to review this thread on topic of datasheet errors related to the XS1-L device:

http://www.xcore.com/questions/2833/xs1 ... cu-problem

The issues were due to the PCU pin connections on this component. The current datasheet appears to have been revised and corrected so best to review the posted checklist inside that document.

Summarized here:

• The PCU_VDD pin is connected to the VDD supply and PCU_VDDIO is
  connected to the VDDIO supply (Section 10).

• The PCU_CLK pin is supplied with a clock, for example it is tied to the
  main CLK (Section 9.1).

• The PCU_VDD supply must be connected to the VDD supply.

• The PCU_VDDIO supply must be connected to the VDDIO supply.

• The PCU_WAKE and PCU_GATE pins should be left unconnected (Section
  9.1).