Hey,
Are there any plans on developing an SoC with a USB PHY that supports USB 3.x so that the data bandwidth can increase? I know that for most audio purposes, higher speeds than 480Mbps may be more than enough, but was wondering if any USB 3.x support is planned.
I'm thinking of using XMOS for bidirectional audio data throughput, but along with it I also wanted to send metadata. The metadata will be bottle necked by the 480Mbps and I'm looking which way to go in terms of the implementation solution.
Thank you!
USB 3.x support forecast
-
- Member++
- Posts: 24
- Joined: Wed May 07, 2025 11:13 pm
-
Verified
- XCore Legend
- Posts: 1243
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
USB 3.0 is not on the immediate roadmap. We don't actually have any designs maxing out USB2.0 at the moment to be honest.
Technical Director @ XMOS. Opinions expressed are my own
-
- Member++
- Posts: 24
- Joined: Wed May 07, 2025 11:13 pm
Ok, thanks for the prompt response Ross!
Yup, I know the reference designs don't max out, but because of the metadata, I'll be above the threshold. I'll see if I can find a way to compress the data without losing any bit.
Yup, I know the reference designs don't max out, but because of the metadata, I'll be above the threshold. I'll see if I can find a way to compress the data without losing any bit.
-
Verified
- XCore Legend
- Posts: 1243
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
What kind of meta data is it and how big? Out of interest..
Technical Director @ XMOS. Opinions expressed are my own
-
- Member++
- Posts: 24
- Joined: Wed May 07, 2025 11:13 pm
The type of metadata that I send varies. It may be related to the data frame or not.
If it is, and my most common use-case is, it is essentially a timestamp (32bits) of the data sampled, sample counter (32bits as well) and then providing another 32bits overhead per channel for every data frame (whether it is usb-in or usb-out). I'm trying to have minimum 4 chananels up to ideally 16.
In the metadata non related to the data frame, I can't claim I've started implementation because at the moment there isn't bandwidth anyway, unless I compress it somehow (that said I'm also not yet 100% finalised on how the data structure will look like).
If it is, and my most common use-case is, it is essentially a timestamp (32bits) of the data sampled, sample counter (32bits as well) and then providing another 32bits overhead per channel for every data frame (whether it is usb-in or usb-out). I'm trying to have minimum 4 chananels up to ideally 16.
In the metadata non related to the data frame, I can't claim I've started implementation because at the moment there isn't bandwidth anyway, unless I compress it somehow (that said I'm also not yet 100% finalised on how the data structure will look like).
-
Verified
- XCore Legend
- Posts: 1243
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
We're upping the available bandwidth by implementing high-bandwidth endpoints at the moment. Our implementation will only give a maximum of two 1024 byte packets in a micro frame though. Sounds like you need more.
Technical Director @ XMOS. Opinions expressed are my own
-
- Member++
- Posts: 24
- Joined: Wed May 07, 2025 11:13 pm
Oh I thought the USB Endpoints from XMOS already supported the 480Mbps. What is the limit at the moment?
Even with the higher bandwidth new implementation, it would mean that the data throughput would be maxed at 125Mbps? Are there plans to go actually implement up to 480Mbps?
Even with the higher bandwidth new implementation, it would mean that the data throughput would be maxed at 125Mbps? Are there plans to go actually implement up to 480Mbps?
-
Verified
- XCore Legend
- Posts: 1243
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
480 Mbps is the raw signalling rate of USB 2.0 High-Speed, but actual throughput is always lower due to USB protocol overhead (packet headers, inter-packet gaps, handshaking etc)
For bulk endpoints, the theoretical maximum data rate is ~53 MB/s (≈ 424 Mbps), but bulk is best effort, real-world performance is often lower and can vary based on host behaviour, bus usage etc.
Bulk ep's guarantees delivery, but not bandwidth or timing. Good for hard-drives etc. If you take a look at AN00136 it will run a bench mark (not, depending on OS the host API might be a bottleneck!)
For isochronous endpoints, which reserve bandwidth, USB 2.0 allows up to 3 × 1024-byte packets per 125 μs microframe, giving:
1024 bytes × 3 × 8000 microframes/sec = 24 MB/s ≈ 192 Mbps
Bandwidth and timing is guaranteed but delivery is not. This is typically good for video/audio.
The upcoming xmos implementation limits packet count to 2 per micro-frame.
For bulk endpoints, the theoretical maximum data rate is ~53 MB/s (≈ 424 Mbps), but bulk is best effort, real-world performance is often lower and can vary based on host behaviour, bus usage etc.
Bulk ep's guarantees delivery, but not bandwidth or timing. Good for hard-drives etc. If you take a look at AN00136 it will run a bench mark (not, depending on OS the host API might be a bottleneck!)
For isochronous endpoints, which reserve bandwidth, USB 2.0 allows up to 3 × 1024-byte packets per 125 μs microframe, giving:
1024 bytes × 3 × 8000 microframes/sec = 24 MB/s ≈ 192 Mbps
Bandwidth and timing is guaranteed but delivery is not. This is typically good for video/audio.
The upcoming xmos implementation limits packet count to 2 per micro-frame.
Technical Director @ XMOS. Opinions expressed are my own
-
- Member++
- Posts: 24
- Joined: Wed May 07, 2025 11:13 pm
Extremely helpful information. WIll have a look at AN00136 in more detail to see the maximum it's possible to achieve.
Thank you very much Ross!
Thank you very much Ross!