Audio USB in light of S1-L Hardware Design Checklist

[bearcat]

Wow! The USB ULPI contraints with the L1, that's HUGE and a major issue. I now understand the strange choice of pins used by the USB Audio design. The other errata can be dealt with.

When using USB, the only resources you can use are a few 1 bit ports, and the 32 bit port in the 128 pin package. No 4's, 8's, or XLINKS.

I wish they would have included this tidbit in the original USB audio documentation (or any published spec), so the rest of us could have known the serious limitations. I haven't seen any forum posts about this till earlier this week when woody made a passing reference to pins and USB, which I hadn't heard about anywhere yet and got me wondering about the strange pinouts on the reference design.

I am sorry I have to be critical again, as I do not want to be nor had planned but..
I hope someone can set me straight here, and maybe I am incorrect, but the just released document yesterday seems pretty clear.

[lilltroll]

The pinout is like this in the existing design.

USB_Audio_2pinout.png

And for the L1-128, the totalt pinout is like this:

L1_128.png

I know the issues with the existing design - but why cannot it be improved with the L1??
I do not understand the ULPI-thing. It uses 4 1-ports and 1 8-port.

[bearcat]

The reference design uses every one of the I/O available (1, 4, or 8 bit) on the L1, when using the USB capabilities.

The problem is lack of transperancy here. How do you design with an XMOS product without all the crucial design details? This crucial information should have been documented when they released the reference design.

[lilltroll]

I do agree about the Windows Audio 2.0 driver stuff, since it seems to only support the thing that is used on the Audio card - and does not support all other function that can be supported under USB 2.0 so far.
But you can add a new thread att full load at 192 kHz without problems on the XMOS side, and if you disable S/PDIF you get 2 threads, meaning at least 80 MIPS. Since several threads is used to buffer USB data, I guess those threads are in sleep mode most of the time waiting for next event - reducing the actuall "MIPS" load - making somthing between 80-200 MIPS available.

Can you explain for me why I cannot use 2bit X0LA for an example pin(X0D4 - X0D7)
and why cannot I use P4E and P4F pin(X0D26 - X0D33) and P1N , P1O, P1P (X0D37-X0D39) ?

All the above pins are not connected as I understand it. Is it impossible to adress them in the software when using ULPI ?

[bearcat]

I am going by the following diagram:

XS1-L Hardware Design Checklist_05.jpg

Those ports can't be used. I ASSUME that also means the ports can't be used for XLINKS either.
Can anyone tell me that the XLA can be used on the (64 pin device) while using ULPI?

But, I think you saved the day lilltrol!!!!!!! Thank you, thank you!

I have been using the 64 pin device in my design and my train of thought was on that device. But the 128 pin device has two additional XLINKS pinned out of the 32 bit port.

I assume those can work. Anyone verify that XLC and XLD do work when using ULPI?

That still leaves the issue of why this wasn't put in a spec till this week. The ULPI is a black box, it is difficult to know what it is. The hardware support is still unknown.

Again thanks for the help lilltrol.

[lilltroll]

Ohh, I missed this (new) document,
http://www.xmos.com/system/files/xs1-l-des-check.pdf

That makes me understand the "strange" design choice as well.
So if we skip the 32-bit port on the L1-128, we might be able to run a high-speed XLINK to another chip!? or go for an L2.

[lilltroll]

What about :idea:

I have 2 XK-1 cards, and many XTAG2's.

What about:
Desolder the L1-64 on a XTAG2 and connect it to port B on the XK-1 (Port A would be of no use). Reroute from the ULPI chip to the ICD header on the XTAG2 (with help of the free pads from the L1-64).
Finally connect the second KX-1 to the first via 2-wire Xlink port D.
That would give 10 1-ports + 16 pins of 4/8/16 port on the second KX-1 + USB2.0 on the first !?

(A USB2.0 module would be nice for the XK-1 cards)

Or we could start to pray for the Amino-cards raining from the sky :mrgreen:

The alternative is to add a small wire to pin-13 for Xlink port C, and skip the LED's.
Port D is even harder to fetch.
That way you could maybe add an extra XK-1 to the Audio 2.0 card!?

Audio.png

[Woody]

Anyone verify that XLC and XLD do work when using ULPI?

When ULPI is used, you can not use X0LB, but you can still use all of the other links: X0LA (64 pin L1); X0LA, X0LC and X0LD (128 pin L1). Note that because you can not use the ports corresponding to X0LA when ULPI is used, it is a good use of device pins to use X0LA if you can.

[lilltroll]

Ahaa, so it's possible to build a dual L1-64 card with ULPI!?, where the first L1 is connected to ULPI, and used as USB buffer, and the second L1 is used as DSP and CODEC communicator :?:

[Woody]

Note that because you can not use the ports corresponding to X0LA when ULPI is used, it is a good use of device pins to use X0LA if you can.

It's also worth noting though that in 5 wire mode, 2 of the pins of X0LA will overlap with the standard SPI boot pins. Of course you can change the SPI boot pins, but you need to program the OTP with the boot code to do this.