Trouble connecting clock block to oscillator port

Technical discussions around xCORE processors (e.g. xcore-200 & xcore.ai).
Post Reply
niektb
Member++
Posts: 28
Joined: Tue Mar 26, 2019 8:38 am

Trouble connecting clock block to oscillator port

Post by niektb »

Hi all,

I'm trying to port AN00231_ASRC_SPDIF_TO_DAC to my own XUF208 board and I have a question. My board has one oscillator (24574kHz) that is connected to the CLK pin. As the onboard DAC has a built-in PLL i figured i didn't need anything else. But this app note configures the mclk clock block to run of an incoming port. Is there a way to reconfigure this to the CLK pin? Or do I need to figure out the divisor to divide ~100MHz to 24.574MHz? Thanks in advance!


niektb
Member++
Posts: 28
Joined: Tue Mar 26, 2019 8:38 am

Post by niektb »

i've found the function configure_clock_rate(), could I use that to get the desired frequency? Which values should I enter? I've tried configure_clock_rate(clk_mclk, 24576, 1000); but that throws an exception
User avatar
Caleb
Experienced Member
Posts: 82
Joined: Thu Apr 04, 2013 10:14 pm
Contact:

Post by Caleb »

I think you probably need to give more info about your circuit, what you're attempting to do. Perhaps a schematic?

I believe the goal of the app. note is to demonstrate the ASRC algorithm. It presumes that you have an IIS interface to a DAC that is synchronous to an mclk. The xmos clock resources could also be the source for a master clock that operates the IIS interface but the the XMOS pll is not capable of generating an arbitrary frequency such as 24.576MHz. You could probably very easily configure a clock block at 25MHz and use that as a substitute for an mclk from an input port. From there, the IIS interface would run at 48.828kHz sample rate. Since you're demonstrating the ASRC functions, it won't matter then if the IIS is operating at an uncommon sample rate.
niektb
Member++
Posts: 28
Joined: Tue Mar 26, 2019 8:38 am

Post by niektb »

Ah yes, let me explain a bit further. I'm connecting the XMOS with a PCM5102A. The latter has a built-in PLL and doesn't require a master clock. it also operates in hardware control mode, so no I2C needed. Very convenient chip to use :)
You'll find the schematics attached. The oscillator used provides a master clock of 24.576MHz. (i'm aware that I can't use USB with that, was a design mistake :))

What I'm trying to achieve is to convert SPDIF with an arbitrary sample rate (in the range of 44.1kHz to 96kHz) to a fixed arbitrary I2S sample rate (f.e. 96kHz).

Published my code here: https://github.com/niektb/SPDIF-ASRC-I2S-BRIDGE (based on the AN, but with I2C config and led driver removed)
Attachments
DAC.png
(79.07 KiB) Not downloaded yet
DAC.png
(79.07 KiB) Not downloaded yet
SPDIF-I2S-Bridge.png
(190.54 KiB) Not downloaded yet
SPDIF-I2S-Bridge.png
(190.54 KiB) Not downloaded yet
User avatar
Caleb
Experienced Member
Posts: 82
Joined: Thu Apr 04, 2013 10:14 pm
Contact:

Post by Caleb »

I took a minute to look at your schematics. The signals DAC_BCK,DAC_DIN and DAC_LRCK are from a 6-pin connector that I assume connectes somehow to 1-bit xmos i/o pins. And you provide no mclk to the XMOS that can be used as a synchronizing reference for a clock block.
So I see, you're attempting to use a clock configuration function to configure a clock block to run at a specif frequency that is derived from the system clock XS1_CLKBLK_REF. configure_clock_rate probably can't provide the granularity that you may want. You can read up on the limits of the configuration capabilities of the xmos PLL. And you can use some other clock config functions besides configure_clock_rate that give you more direct control of divide ratios. I think that the tools doc. will give you accurate info on what parameters you can use for such functions and what parameters will raise exceptions.
Have you indicated to the tools that you have a 24.576MHz oscillator in the .xn file? I think that the tools usually default to / assume that the system execution clocks and timers are running at 500 and 100 MHz respectively but you probably aren't getting those exact frequencies with that oscillator frequency. It may be helpful to just configure your bclk pin as a clock output and experiment to determine what frequencies can be generated. It's possible to manipulate the 500MHz execution clock (and the divided counters, timers, etc), raise or lower a bit if you want to manipulate the resulting bclk frequency.

Am I correct to assume that it's not critical what the exact frequnce sample rate you send to the DAC? And since the SRC will convert to whatever sample rate that the IIS runs, you have flexibility. But given that you have a 24.576MHz oscillator, I think it should be possible to find combinations of pll config parameters to result in a 3.072MHz bclk.

So I'm suggesting that you experiment with the various clock config functions to determine what frequency you are able to achieve. For example, you could try configure_clock_rate_at_most instead of configure_clock_rate.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Also review your #RESET RC circuit which does not look to be correct.

By XMOS design notes, the #RESET line should be released after both the +1v0 and +3v3 rails are deemed to be stable through a reset supervisor circuit.

However, if you plan to use the RC circuit, then it should be wired up as follows:

http://www.ladyada.net/library/rccalc.html
niektb
Member++
Posts: 28
Joined: Tue Mar 26, 2019 8:38 am

Post by niektb »

Thank you for your answers!
@Caleb: indeed, for the sake of prototyping i routed all free xmos ports to pin headers (including several 1-bit ports) so i can just connect some wires inbetween.
I've specified the oscillator frequency, indeed it also mentions that the reference clocks aren't exactly 500 and 100 MHz:
..\.\XUF208-256-TQ64-C10.xn:16 Warning: XN11137 500000000Hz system frequency for node "0" could not be achived. Using 499998720Hz.
..\.\XUF208-256-TQ64-C10.xn:16 Warning: XN11136 Default 100Mhz reference frequency for node "0" could not be achived. Using 99999744Hz.

The exact i2s frequency indeed doesn't matter much, the DAC does any standaard audio format in the range between 44.1 and 384kHz. (and the bck can be either 32 or 64 times the sample rate)
I'll try to fiddle around with the PLL settings! you're advice is to adjust the system clocks such that i can specify an integer to divide the system clock to 24.576MHz), did I understand that correctly?

@mon2: i deliberately omitted a reset supervisor (which is the proper option indeed). I haven't encountered any issues with that whatsoever (i can run blink programs etc. just fine :))
User avatar
Caleb
Experienced Member
Posts: 82
Joined: Thu Apr 04, 2013 10:14 pm
Contact:

Post by Caleb »

niektb wrote: Mon Aug 26, 2019 8:56 am Thank you for your answers!
@Caleb: indeed, for the sake of prototyping i routed all free xmos ports to pin headers (including several 1-bit ports) so i can just connect some wires inbetween.
I've specified the oscillator frequency, indeed it also mentions that the reference clocks aren't exactly 500 and 100 MHz:
..\.\XUF208-256-TQ64-C10.xn:16 Warning: XN11137 500000000Hz system frequency for node "0" could not be achived. Using 499998720Hz.
..\.\XUF208-256-TQ64-C10.xn:16 Warning: XN11136 Default 100Mhz reference frequency for node "0" could not be achived. Using 99999744Hz.

The exact i2s frequency indeed doesn't matter much, the DAC does any standaard audio format in the range between 44.1 and 384kHz. (and the bck can be either 32 or 64 times the sample rate)
I'll try to fiddle around with the PLL settings! you're advice is to adjust the system clocks such that i can specify an integer to divide the system clock to 24.576MHz), did I understand that correctly?
Yes, that was one of the options I was thinking you might pursue (integer divide of system clk to achieve 24.576MHz). But I think you've also understood that I don't think it really matters whether you achieve that exact frequency. For example, wht that 99999744Hz reference divided by 4, you achieve 24999936Hz. You would then have a 48.828kHz FS (2x, 4x, etc). The output of the ASRC, and the DAC should both should work correctly at basically any arbitraty frequency within the limits you cite.
But I'd be surprised if you can't find the correct PLL parameters so that you will have an internally divided mclk that is the same frequency as your external osciallator.

You could of course just put a wire from you external oscillator to one of those available port pin headers and then run the IIS software the way that the XMOS developers intended. Bu I think it should be possible for it to work either way.

More advanced and maybe interesting optimization: you could replace your 24.576MHz oscillator with 24MHz so that your USB interface can work. But without the correct 24.576 and 22.5792 MHz oscillators, you'd have to hack the ASRC between the USB decouple thread and the IIS thread. And then you'd also have to make some changes to the feedback endpoint so that it reports nominal FB data (rather than measured). Or make it an adaptive audio endpoint rather than asynchronous. Then you would also have to create a mechanism to manage the rate of moving samples from decouple (FIFO) and the input to the ASRC (basically rewrite the FIFO). Fun idea? Maybe. It can be difficult to debug stuff like that.
niektb
Member++
Posts: 28
Joined: Tue Mar 26, 2019 8:38 am

Post by niektb »

What I ended up doing is configuring the xn file differently, no need to find out the exact pll settings :)
<Node Id="0" InPackageId="0" Type="XS2-L8A-256" SystemFrequency="491520kHz" ReferenceFrequency="98304kHz" OscillatorSrc="1">
This generates the proper clocks. (according to simulation)

Still have some issues though, the output i2s rate is wrong (output below) and after 3/4 times it stops reporting (and seems to freeze? i need to pull the power plug before I can run a new application)
"[508732992] spdif rate ave=48777, valid=1, i2s rate=86686, valid=1, i2s_buff=18, fs_ratio=0x8FEC748, nom_fs=0x8B51D9A"
User avatar
Caleb
Experienced Member
Posts: 82
Joined: Thu Apr 04, 2013 10:14 pm
Contact:

Post by Caleb »

niektb wrote: Tue Aug 27, 2019 10:12 am Still have some issues though, the output i2s rate is wrong (output below) and after 3/4 times it stops reporting (and seems to freeze? i need to pull the power plug before I can run a new application)
"[508732992] spdif rate ave=48777, valid=1, i2s rate=86686, valid=1, i2s_buff=18, fs_ratio=0x8FEC748, nom_fs=0x8B51D9A"
Since you're not operating the USB interface, then I suspect there could be problems if your IIS thread is still making channel interactions with the decouple.xc thread. It's awkward the way the iis loop has to return to the calling function ( audio() ) for sampling frequency changes (or PCM <> DSD format changes). Assuming that you want to run your IIS at a constant FS, it might be worth going through and pruning out every piece of code in the IIS loop that is extraneous to your application. At least for now you could just comment-out the DoSampleTransfer(). But then I'm not familiar with how the ASRC connects with the IIS thread in that app. not example.
Post Reply