How to interface the startKIT with the audio slice

All technical discussions and projects around startKIT
User avatar
infiniteimprobability
XCore Legend
Posts: 1124
Joined: Thu May 27, 2010 10:08 am

Re: How to interface the startKIT with the audio slice

Postby infiniteimprobability » Wed Jan 22, 2014 9:40 am

Thanks for the feedback - Glad you have it working and the example was useful.

With xSCOPE on startKIT, the key thing is to:

- Add the xscope_user_init constructor
- Add -fxscope switch to your make file
- Enable it in the run configuration tab in the GUI

That should be it - the xscope link is already connected inside the kit, and the entry is already in the XN file.

Presumably it builds OK but just doesn't output?
connerlacy
Junior Member
Posts: 6
Joined: Wed Jan 01, 2014 8:31 pm

Postby connerlacy » Wed Jan 22, 2014 10:53 pm

Ok, I'm running into some trouble.

Now for some reason when I try to run the audio_dalek app I get:

Code: Select all

ERROR: socket bind. (0)
in the Console.

I'm not sure what this error means.

However, I can flash it and it seems to work fine.

I think I may uninstall xTimeComposer and reinstall, as this wasn't happening before...
stdefeber
Active Member
Posts: 35
Joined: Wed Dec 18, 2013 9:20 pm

Postby stdefeber » Mon Jan 27, 2014 8:34 pm

I recently bought my audio slice with the purpose to do "multi"-channel audio processing.

My plan is to have a single stereo channel input and have 2 processed stereo channel outputs.
The DSP + amplifier system will drive an open-baffle speaker.
One channel will have a low pass filter and additional shelving filter to compensate for the acoustic short.
The other channel is to be used as high-pass filter.

It is not clear to me how the clocking is done.
The core is clocked @ 24 or 25 MHz and the IO's of the device @ 100MHz.
The audio codecs are clocked at a certain audio frequency with its related MCLK.
MCLK is fed to the core.
It seems to me that a clock domain crossing needs to take place some where !
But how ?

grtz


Simon
mhelin
Active Member
Posts: 52
Joined: Fri Dec 24, 2010 10:54 am

Postby mhelin » Mon Jan 27, 2014 11:41 pm

I recently bought my audio slice with the purpose to do "multi"-channel audio processing.
I have similar plans (though just closed box speakers). Don't know if it's worth implementing the shelfing baffle step or dipole compensation EQ in digital domain as you will loose some bits in the critical midrange. You might want to consider building analog shelfing filter instead (post DAC) and take it into account in filter coefficient calculations.

If you want to get rid of the 100 MHz noise and get better phase relation between the clock signals then let your ADC or DAC run in master mode. Alternatively you could resample the word and bit clocks using the MCLK generated by your oscillator (well you might need to resample also the data just in case).
User avatar
infiniteimprobability
XCore Legend
Posts: 1124
Joined: Thu May 27, 2010 10:08 am

Postby infiniteimprobability » Wed Jan 29, 2014 4:16 pm

It is not clear to me how the clocking is done.
The core is clocked @ 24 or 25 MHz and the IO's of the device @ 100MHz.
The audio codecs are clocked at a certain audio frequency with its related MCLK.
MCLK is fed to the core.
It seems to me that a clock domain crossing needs to take place some where !
But how ?
The 24/25MHz is the PLL input. This then gets scaled up to 500MHz for the system (CPU tile runs at this speed) and is then prescaled down to 100MHz for the reference clock.

Clock domain crossing is all handled inside the xcore device. For typical audio systems, the I2S ports on the xcore are all clocked via an external MCLK (which is the master that drives XMOS ports and the DAC/ADC).
This is then resynchronised at the system clock speed (usually 500MHz) where is crosses the domain into xmos. There is a little jitter introduced ( a nanosecond or so) which you will see on BCLK, LRCLK and DATA output lines, but they all comfortably meet the setup and hold times of the DAC and vice versa for the ADC, and the MCLK (which is the important one for quality) is externally supplied direct from the XTAL to the ADC/DAC, so rock solid.

In this case, the 100MHz internal ref clock is irrelevant, because the audio port clocking is done from an external clock.

In certain cases (eg. SPDIF out) we do chose to synchronise to the MCLK using an external flop to eliminate the resynch jitter, but frankly even that is optional (it would meet spec..) and only done to ensure lowest possible jitter out.

The ability to clock the ports externally is a very cool and powerful feature of the chip. It makes the job of interfacing to interfaces with external clocks (source synchronous stuff) a lot easier..
stdefeber
Active Member
Posts: 35
Joined: Wed Dec 18, 2013 9:20 pm

Postby stdefeber » Thu Jan 30, 2014 11:42 am

Thanks for your answer.

In the meantime I have done some reading on this material.

Concluding this means that every pin can have 1 of the 5 available clock sources and have a x-bit deep fifo which are synchronized to the core domain ?
Fancy and impressive !

grtz

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

Postby infiniteimprobability » Thu Jan 30, 2014 12:12 pm

Yep - there are 5 clock blocks per tile, and each of these can either be clocked off a prescaled version of reference clock, or by an external one-bit port. The latter mode is used for external clocking of ports.

The ports have some nice hardware attached to them to help with all sorts of low level tasks, such as serialisation/deserialistaion, buffering, inputs waiting for a condition, outputs waiting for a count/time, strobing and ready/valid gating. This is all hooked into the processor's event system so you can just do a simple in/out in the software and the CPU will block until the condition has occurred. It's very powerful is the key to making I/O and time driven software state machines that are fast and predictable enough to emulate hardware.

Here's a piccy (simplified for marketing purposes) of what they can do..
You do not have the required permissions to view the files attached to this post.
User avatar
segher
XCore Expert
Posts: 843
Joined: Sun Jul 11, 2010 1:31 am

Postby segher » Thu Jan 30, 2014 6:28 pm

infiniteimprobability wrote:Yep - there are 5 clock blocks per tile, and each of these can either be clocked off a prescaled version of reference clock, or by an external one-bit port. The latter mode is used for external clocking of ports.
Six, even -- although usually you let one of them output the
reference clock, the hardware doesn't care :-)
mhelin
Active Member
Posts: 52
Joined: Fri Dec 24, 2010 10:54 am

Postby mhelin » Thu Feb 27, 2014 9:30 pm

In case someone is wondering what f the Dalek means:
http://www.youtube.com/watch?v=YQLbwOGT8eM

Context: https://www.xmos.com/en/published/app_a ... lek-readme

So when testing the dalek FX please shout "Exterminate!" to the microphone, otherwise it doesn't work.
User avatar
infiniteimprobability
XCore Legend
Posts: 1124
Joined: Thu May 27, 2010 10:08 am

Postby infiniteimprobability » Fri Feb 28, 2014 8:53 am

So when testing the dalek FX please shout "Exterminate!" to the microphone, otherwise it doesn't work.
This is a critical part of the verification for this code. If you don't get the desire to purge the Universe of all non-Dalek life, then the code is not working properly.

Who is online

Users browsing this forum: No registered users and 0 guests