Multi-clock digital domains.

[paulca]

I'm working through some multi clock puzzles in my audio project.  I keep ending up at dead ends and wondering if I should consider actually designing a set of clocking circuitry or even make use of existing ICs designed for the purposes.

Firstly I strived for a single master clock for the audio domain.  That's not going to work however, not without stepping up a grade in the audio ICs I'm planning on using from consumer to professional grade.  The reason being that most "basic" USB-I2S bridges that are available outside of Atmel DSPs have their own internal clocks, driven by ceramic oscillators.  ... and no.. no they don't use any practical frequencies or even n/fs multiples.  I think the PCM2706's clock speed is 12.000Mhz with a fs/clk ratio of like 100:1.  Who does that?

Everything else so far is happy enough with the 24.576Mhz clock I borrowed from an ADC module containing an actual xtak clock generator circuit.

So, the only options I have available to me are: 

A) accept I will have to realign and resync audio streams.  Man up and stop trying to avoid it because it makes my nice neat buffering a mess.

B)  employ some form of circuitry such that I can synchronise, if not the master/sys clocks of the I2S peripherals, but at least the I2S bit clocks across domains.

Even without dealing with the PCM* USB bridges internal clocks there is always the issue with the USB sourced clock when using an MCU as the USB-I2S bridge.  That spreads out into multiple options, most involve either low level USB hacking to firstly FIX the HAL libraries and secondly extend them to implement iosynchronous sync properly.  Or... it's back to realigning buffers again.

So to my question.  Are there best practices here for having multiple clock domains, but providing syncrhonisation...   or is it a better option to explore a master clock and multiply/dividers?  (in the case of the later, if an IC expects a resonator and you inject a clock pulse, can you drive it's internal clock that way? or do you need to couple to the oscilator somehow)

A rather "janky" option I considered briefly was just using an MCU, SPI and DMA to generate whatever clocks I want.  Briefly because I believe that way lies many dragons.

[tggzzz]

I'm working through some multi clock puzzles in my audio project.  I keep ending up at dead ends and wondering if I should consider actually designing a set of clocking circuitry or even make use of existing ICs designed for the purposes.

Firstly I strived for a single master clock for the audio domain.  That's not going to work however, not without stepping up a grade in the audio ICs I'm planning on using from consumer to professional grade.  The reason being that most "basic" USB-I2S bridges that are available outside of Atmel DSPs have their own internal clocks, driven by ceramic oscillators.  ... and no.. no they don't use any practical frequencies or even n/fs multiples.  I think the PCM2706's clock speed is 12.000Mhz with a fs/clk ratio of like 100:1.  Who does that?

Everything else so far is happy enough with the 24.576Mhz clock I borrowed from an ADC module containing an actual xtak clock generator circuit.

So, the only options I have available to me are: 

A) accept I will have to realign and resync audio streams.  Man up and stop trying to avoid it because it makes my nice neat buffering a mess.

B)  employ some form of circuitry such that I can synchronise, if not the master/sys clocks of the I2S peripherals, but at least the I2S bit clocks across domains.

Even without dealing with the PCM* USB bridges internal clocks there is always the issue with the USB sourced clock when using an MCU as the USB-I2S bridge.  That spreads out into multiple options, most involve either low level USB hacking to firstly FIX the HAL libraries and secondly extend them to implement iosynchronous sync properly.  Or... it's back to realigning buffers again.

So to my question.  Are there best practices here for having multiple clock domains, but providing syncrhonisation...   or is it a better option to explore a master clock and multiply/dividers?  (in the case of the later, if an IC expects a resonator and you inject a clock pulse, can you drive it's internal clock that way? or do you need to couple to the oscilator somehow)

A rather "janky" option I considered briefly was just using an MCU, SPI and DMA to generate whatever clocks I want.  Briefly because I believe that way lies many dragons.

In general if you have information coming from two sources, you will have to synchronise somewhere. That's true even if the two sources have nominally identical clock frequencies controlled within limits - plesiochronous systems https://en.wikipedia.org/wiki/Plesiochronous_system

You might be able to get away with less if the sampling rate is much lower than the clock rate. Even then there would be a 1 clock period jitter.

If all your sources are completely under your control, you could use PLL-based clock generation ICs to generate multiple clocks at different frequencies. (Inside FPGAs they are typically called "clock tiles" or something similar).

Don't forget the inevitable metastability problems and ameliorations, of course.

[paulca]

Sounds like sync'ing or sharing clocks might be more work and still not infallible.

I logged the buffer pointers for the I2S's streams which actually share the same master clock.... and... well... they drift too.   They don't migrate in any prevalent direction, but they do drift, maybe as much as a byte a minute though my measuring technique is subject to a 1 second timer's view.  Without intervention it might be rare that they drift enough to roll off the end of a buffer window, but WHEN it does happen it will also take a long time to clear.

Luckily I found, what I'm hoping is, a technique to easily alter the timing of the buffers to address these.  Multi-buffering DMA (rather than Circular).  It also provides the basis for a "StreamMute()" function in error conditions by switching buffers to a prepared area of silence.  I believe I2S literature refers to it as "alt-source".

I mean, I can log a "quality" factor out to show how many interventions are happening.  I expect in most cases it will be fine and if there are any outliers I'll handle them when I find them.

[tggzzz]

Synchronisation across clock domains cannot be reliable, for deep theoretical reasons. That began to be recognised in the early 70s, and was orthodox by the late 70s.

Keyword: metastability.

Key question: what happens if a flipflop's setup and hold times are not observed?

[dmills]

True but you can chain a few flops and get reliable enough (for any value of enough)....

If I was doing this I would look hard at the ASRC chips from Crystal or TI, they are effectively digital audio any to any sample rate converters and do not need the input and output side clocks to have any particular relationship, so you can bring in I2S from your USB dodad, and reclock it to your master clock at 24576/48 or whatever you are using.

Very easy to use, just a few mode setting resistors and some bypass caps, and job done.
Not the cheapest parts, but you only need a few.

Regards, Dan.

[paulca]

If I was doing this I would look hard at the ASRC chips from Crystal or TI, they are effectively digital audio any to any sample rate converters and do not need the input and output side clocks to have any particular relationship, so you can bring in I2S from your USB dodad, and reclock it to your master clock at 24576/48 or whatever you are using.

Very easy to use, just a few mode setting resistors and some bypass caps, and job done.
Not the cheapest parts, but you only need a few.

Thank you.  I'll take a look.  It's this kind of info I was hoping to find by posting.  Too often you fiddle around for weeks trying to address a complex issue and THEN... someone says, "You know TI/Analog make an IC for that?"

[tggzzz]

True but you can chain a few flops and get reliable enough (for any value of enough)....

Just so, of course.

The point is to get the OP to push their thinking to the logical limit, thus enabling understanding of the irreducable issues and how to ameliorate them.

I found that very useful in a vacation job, where I forced myself to understand what couldn't be expressed in the language I was using. That lead me to understand the need for semaphores and how to implement them. That turned out to be highly relevant in my final year university project

I see too many people not pushing their thinking, and hence not understanding things like the Byzantine Generals Problem, the Dining Philosopher's Problem, the Split Brain Problem, and Lamport's seminal works. Not understanding those let salesmen blind them along the lines of "our product just works and solves your problem", when clearly it can only do that in most cases - but not all cases.

Ever been the victim of a rare "computer error"? If not, then just wait!

[RoGeorge]

Are there best practices here for having multiple clock domains, but providing syncrhonisation...   or is it a better option to explore a master clock and multiply/dividers?  (in the case of the later, if an IC expects a resonator and you inject a clock pulse, can you drive it's internal clock that way? or do you need to couple to the oscilator somehow)

A rather "janky" option I considered briefly was just using an MCU, SPI and DMA to generate whatever clocks I want.  Briefly because I believe that way lies many dragons.

Crossing clock domains methods (search those terms for more info) are well established in hardware design.  No need to improvise.  Very brief main ideas, see if it makes sense (look at the diagrams and the text, ignore the "code lines" unless you are familiar with HDL already - that's a schematic described with text, it is not a "program"):
https://www.fpga4fun.com/CrossClockDomain.html

From the rest of the text in your OP, dedicated I2S chips, USB, MCU and so on, should have no problem interconnecting together.  Somebody else already solved the clock crossing when those chips were designed. 

For sure you will need some buffering to handle the audio streams in software, but the DSP MCU is fast enough to keep all in sync, so you won't care about hardware clock crossing domains.  This can be very different, depending on the design and its destination.  In that link clock crossing seems trivial, but there is more to it.  A generic talk about the subject won't help much.

To get more meaningful answers, you'll have to add at least a block diagram with the clocks, and the chips, and the data streams you want to move.

[paulca]

I mean I figured that "crossing clock domains" would be difficult.  Mostly I was looking for ways to avoid doing so entirely.  The elephants in the room are the ICs who are "helpfully" generating their own bizarre clock rates.

But... even with that out of the way I've established I just can't control every bodies clock.  USB I think "can" be asked to work synchronuosly with the device providing clocking information, but as the packet duration is 1ms, I'm not quite sure if I want to know how they expect to synchronise that clock.

My (software) Engineering sense tells me to plan for the worst and expect all manor of annoying clock issues, so write the code to expect them or even use them to your advantage instead of trying to avoid them.  Achieve that and you won't care about them.

Translating that to a mixed hardware/software domain is an interesting challenge of conception.  However, the suggestion about I2S reclocking ICs  sounds like a decorator pattern to me.  Don't like the output of one thing, wrap it in a decorator to make it so you do like it.  It's more BOM, but I should be able to limit my cross clock domains to discrete points and only have the reclockers there.  Rather than in software we would create one does-all and inherit from it in all use cases   Cause, you know, Ghz and Tbs.

I might find something else to look at this evening.  I had one of those days in work where nobody speaks to you for weeks and you idle around doing nothing and then suddenly there is a panic and they want a production release on Saturday morning.  I even sinned a greatest sin and commited a "delete: src/test/" with an appology comment.  "Corners cut?  I didn't see any corners."  Now everyone has gone quiet, but I've done my bit and it's 17 minutes to "Beer O'Clock."  I see an immanent "technical fault" with my Internet....

[RoGeorge]

If you connect existing chips together, do it as shown in the datasheet and/or in the application notes of the ICs you want to use.  For software, use boilerplate and demo code from devboards of the specific MCU or DSP you are using (from the chip manufacturers, the manufacturers always have some code examples, too, aside from software libs).

Unless you design a new integrated circuit, or a new hardware inside an FPGA, there are no clock crossing you need to worry.  Connect the ICs as shown in their datasheet, and it will work.

Preferably would be to use a development board, or some kit with existing demo software.  If you start from scratch, it might take many days of datasheets reading, if not months before finding how to configure all properly.  That is why usually there are configuration tools (from the manufacturer) to help configuring various registers in the CODECs, or filters in the DSPs, and so on.

[paulca]

We are way beyond that stage now George

I can't just interconnect ICs.  I have to intervene in software in several places.  STM32F4/H7 stuff.  The trouble with THAT platform is the current software examples and libraries are dubious to say the least.

Everytime I regen the HAL layer code I have to go and fix TWO bugs in the libraries.  The most vunerable buffer to over-running isn't mine apparently, it's STMs library code.  As an aside... I am slowly working my way behind the emperor's curtain there and looking for key points to intervene and take control of the USB packet reception myself.

Their examples are not worth using.  Why?  Because, a) they limit the scope of their examples to stupidly narrow use cases.  b) the limit the scope of their examples to their own development boards.  c) Everything useful is abstracted into BSP macros.  (Board support package).  So to get anywhere you have to down load that package for a board you.... nevermind, I got angry and I'm not going back there.  I'm resolved to taking what I can get working with HAL and learning to intervene in the lower layers when I need.

In contrast the ICs don't really seem to care what you do with them.  I have tried... not necessarily intentionally...
* unpowering and repowering them. 
* shorting them out.
* dragging both GND the 3.3V pins from a uart over the top of their module.
* disconnecting and reconnecting their clock lines.

The just don't care.  Obviously they stop when out of parameters, but they just start back up again like nothing happened. 

The STM32 ... it's just such a "Diva".  You look at it funny and it quits.  Actually this I believe comes down to their USB implementation.  They use an interrupt loop to fetch data.

The call PrepareReceive.  In the callback for that successfully being received they call another PrepareReceive.  Now you see the reason it just stops dead if you look at it funny.

You maybe understand the urge to move as much of the insanity into ICs.  So  your point is very valid

[paulca]

As to "circuit design" aspects.  We are far from that.  However the development evironment is being set up in such a way as, if I have clock signal issues, I will find them.  Aka.  I'm building it on an expanding set of breadboards with lots of multi MHz antennas looping over everything.  From there it will got to modules on PCB+Proto boards.  Which in terms of noise will be like the project just got into the taxi after coming out of the night club!