Need help to know if my project can fit into a XMOS processo

XCore Project reviews, ideas, videos and proposals.
Post Reply
mx12
Member++
Posts: 20
Joined: Thu Aug 18, 2016 3:22 pm

Need help to know if my project can fit into a XMOS processo

Post by mx12 »

Hi,
I usually work with ADI DSPs, such as Blackfin and Sharc. My project is a dual mic amplifier with USB audio. As the mic inputs can be digital (AES42), I have to sync audio to local domain clock using asynchronous sample rate converters.
As I never developed a XMOS application, I wonder if the following can fit into one XU2016 chip (we don't want BGA in that design, and power for a 24 or 32 cores is too high):
- 2x digital spdif receiver
- 2x stereo ASRC
- 2 channels USB audio in/out
- user interface for a small OLED display
- audio processing such as limiters, gain, ...

I already tried to integrate two spdif receivers and dedicated ASRC using the xCORE-200 MC AUDIO eval board, it works, but really doubt that I have enough available cores to add USB and all other things listed. Also, I've no idea of the core CPU usage, available memory, ...

Really need help for that design, as the solution of one single chip is really advantageous, but don't want to go with an impossible design.

All the best,
Vincent


User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

Sounds like a nice project! Definitely sensible to discuss requirements early on.

First thing I would say is that SPDIF Rx is only supported up to 96KHz. Also ASRC currently needs to be <=96KHz on one side to fit in the MIPS available. So as long as that's acceptable you are good.

It would help to understand sample rates. This has a big effect on MIPS needed for ASRC. I'll assume up to 96KHz for now...
Also, I've no idea of the core CPU usage, available memory, ...
OK - here are some budgetary estimates..
2x digital spdif receiver
2 cores @ 61.25MHz
- 2x stereo ASRC
6 cores @ 61.25MHz (assuming 16 sample blocks)
- 2 channels USB audio in/out
5 cores (one at 80MHz, the rest at 50MHz), which includes I2S. You may be able to delete one if I2S is not needed, but it will need extra work. However, it's useful to have an audio task to act as a hub to receive the samples from the SRC and pass them back to USB audio.
- user interface for a small OLED display
1 core (not many MHz). This may be combined with other stuff although if I2C or something similar then it may be quite a slow update, so a dedicated task may make sense.
- audio processing such as limiters, gain, ...
Difficult to say without details, but a 62.5MHz core gets you around 2M biquads/second or 2.7M biquads a second if 4 are cascaded. Or it can do about 15M/FIR taps per second. I would be surprised if two 61.25MHz cores weren't more than enough..

So it sounds like enough, but to be honest its pretty full. It's going to be something like one tile for digital Rx + SRC and the other tile for USB, control and DSP. There will not be a huge amount of space left (I expect it to use all cores actually) but it sounds like it should fit and the nice thing about logical cores is that filling one doesn't stop another from running.

It's quite a chunky project though in terms of effort (several months), but I don't see any technical barriers and all of the things you want to do have been done before, so lots of references available.

Memory-wise, you'll be using way less than half of a XU216-256-TQ128 and none of the other resources (I/O, timers, channels etc.) will be under any pressure either.

Do share target sample rates. For example, if 48KHz max then you can delete 2x SRC cores straight away making things much less tight. Room is always good!
mx12
Member++
Posts: 20
Joined: Thu Aug 18, 2016 3:22 pm

Post by mx12 »

Thanks!
First thing I would say is that SPDIF Rx is only supported up to 96KHz. Also ASRC currently needs to be <=96KHz on one side to fit in the MIPS available. So as long as that's acceptable you are good.
Yes, I've seen that. 192k operation would be great, but we can accept 96k limitation.

Thanks for the core budgetary estimation. As this project would be my first XMOS application, and as I'm alone as software engineer, this is quite risky for me. I've a parallel design with an ADI processor, and don't know for now which one I'll choose.

After some discussion, I've been able to modify the design, by deleting a digital input. So that's mean that there is only one spdif receiver/ASRC (6 -> 3 cores).

There are still some open points:
  • The product is battery powered. Does XMOS has some charge/battery management application note? Or an application note on how to enter sleep mode, wake up? What is the sleep current?
  • I've seen that USB includes a firmware upgrade, using Thesicon driver. Is there a solution to upgrade firmware using Android/iOS?
  • Does XMOS provides some support for such an application (I'm in a very small company working in the pro audio market)? What about costs?
Thanks,
Vincent
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

I've been able to modify the design, by deleting a digital input. So that's mean that there is only one spdif receiver/ASRC (6 -> 3 cores).
OK - that leaves plenty of space so the risk goes from medium/low to very low in terms of resource usage.
There are still some open points:
The product is battery powered. Does XMOS has some charge/battery management application note? Or an application note on how to enter sleep mode, wake up? What is the sleep current?
xcore 200 chips don't have a deep sleep mode, but you can do a shallow sleep (with instructions still executing) mode by clocking everything down to a few MHz. You can get down to about 50mW-60mW lowest by doing this (which is mostly the static power). However...you can't do this in USB mode because we have to run at full speed to listen to the bus (the USB PHY talks at 60MHz). This means consumption on USB is in the region of 250mW for suspend mode, as opposed to double that (very roughly) for USB streaming with some DSP.

To get lower than this, it's necessary to add some external logic to remove the power (a latch or keeper circuit can easily do this) and then re-enable power on wake condition. We have played with that and it works.
I've seen that USB includes a firmware upgrade, using Thesicon driver. Is there a solution to upgrade firmware using Android/iOS?
Yes, this is USB DFU class compliant solution, so any host that can support this (such as Windows with Thesycon) will work. We also provide example DFU app source example running on OSX to support DFU too, which may give a useful starting point. Note also that the flash API is open so you can DFU yourself in app from any data source.
I seem to recall on iOS that stand-alone DFU apps are not allowed; it must be part of some other functionality. I'm not sure about Android. XMOS does not specialise in mobile Apps so this probably isn't the right place to get more info on this, but as mentioned, it's standard USB/DFU so nothing specific to XMOS.
Does XMOS provides some support for such an application (I'm in a very small company working in the pro audio market)? What about costs?
We have to be realistic here - XMOS engineering time is as valuable as your engineering time so we have to consider the ROI before spending lots of resource on a particular customer project. However, we do offer best effort open support on this forum and for genuine reproducible bugs (which likely affect more than one user), we will track and fix them.

Also remember that it is not just XMOS staff providing responses here. The community on this forum includes some very knowledgable and helpful people too.
Post Reply