! Maybe in a future product this will be possible... Soren
this is very sad. please do not assess the following as negative, but constructive
firstly, these few people are not a couple, but I think many who bought 1121.
secondly, I do not understand the reason for persistent position regarding clocks of SILABS. the clocks are very weak, many have already talked and written about this more than once. I think that the clocks are a weak limiting link for great product.
thirdly, even just from a commercial point of view, this product will receive a second wind and additional sales if there is a possibility of variability and replacement of clocks.
The dam1121 makes changes to the MCLK in case it differs (?in phase?in frequency?) to the serial clock of the i2s signal?
Maybe one could test the use of a reclocker (edge triggered FF). This "should" bring the SCK in sync to the MCLK hence there should be less reason to alter the MCLK. Would one have to make sure the traces/cables of i2s and MCLK after this FF have the same length?
The differences between the incoming "speed" and the what you call MCLK (the DAM Si clock) is not on phase level but on frequency level. 1121 adopts to the incoming speed by changing its own clock frequency. Re-clocking wont fix this difference. So its a much bigger problem than cable lengths.
//
//
I dont get your vocabulary probably. You are obviously talking about an i2s interface? So SCK is also from an e.g. Amanero board?
Still, and again - the problem is not syncing between the different signals in a i2s interface (your SCK and MCLK comes from the same source/board right?) - its the difference in clock frequencies between the clocks on a e.g. Amanero board and the Si clock on the DAM. No re-clocking in the world will fix this. Which of the 2 different clocks do you suggest to use for your suggested re-clocking?
//
Still, and again - the problem is not syncing between the different signals in a i2s interface (your SCK and MCLK comes from the same source/board right?) - its the difference in clock frequencies between the clocks on a e.g. Amanero board and the Si clock on the DAM. No re-clocking in the world will fix this. Which of the 2 different clocks do you suggest to use for your suggested re-clocking?
//
Last edited:
I think this is not a correct statement. The relation between 2 clocks in one and the same interface has noting to do with clock domain syncronization.
(...SCK and MCLK being the same....) This is correct.
//
Last edited:
Well, of course. I did not mean that. The MCLK is a multiple of the SCK. but it is an exact multiple of it.
As I understood it, (I admit I don't have as much insights as some of you) the dam1121 in normal operation (i2s from an e.g. Amanero board) compares the incoming frequency of the i2s Serial Clock (SCK) signal with the MCLK (SI570). If these frequencies have not the exact multiplication, the frequency of the si570 is changed to match it. What else is there, the FPGA could compare the MCLK frequency to?
As I understood it, (I admit I don't have as much insights as some of you) the dam1121 in normal operation (i2s from an e.g. Amanero board) compares the incoming frequency of the i2s Serial Clock (SCK) signal with the MCLK (SI570). If these frequencies have not the exact multiplication, the frequency of the si570 is changed to match it. What else is there, the FPGA could compare the MCLK frequency to?
Last edited:
Yes that is how it works as I understand it.
How can a re-clocker (an incoming pulse train, a latch driven by a (more) stable clock, and an output of said pulse train with now the pace and timing of the stable clock, be implemented? NB - a re-clocker has no buffer so it can only fix phase/jitterfaults (jitter being say < 0,1 UI, UI being the bit clock time). Any larger deviation between the speed of the incoming data and the latching stable clock will result in either over- or under-run. This manifest itself often as "klicks & pops".
//
How can a re-clocker (an incoming pulse train, a latch driven by a (more) stable clock, and an output of said pulse train with now the pace and timing of the stable clock, be implemented? NB - a re-clocker has no buffer so it can only fix phase/jitterfaults (jitter being say < 0,1 UI, UI being the bit clock time). Any larger deviation between the speed of the incoming data and the latching stable clock will result in either over- or under-run. This manifest itself often as "klicks & pops".
//
Well, I gave it a thought and tried it with LTSpice. Three simple d-FF, all clock inputs with one pulse voltage source at 22.5792MHz.
Data input of FF No.1: a pulse voltage source with 2.8229MHz (resembling an BitClock signal at 44.1KHz sampling rate)
Data input of FF No.2: a pulse voltage source with 2.8229MHz + 100Hz.
Data input of FF No.3: a pulse voltage source with 2.8229MHz + 500Hz.
As a result all three outputs of the FF were 0.0030100001Hz away from the intended 2.8229MHz.
I tried the same thing with a doubled Master clock frequency of 45.1584MHz but the resultes were far away from the intended frequency.
(You don't have to say it) This is only a simulation not the real world. But maybe a reclocker isn't that a bad idea after all.
I attached the LTSpice circuit.
I don't know if I've done this simulation right, please point out mistakes or feedback.
Data input of FF No.1: a pulse voltage source with 2.8229MHz (resembling an BitClock signal at 44.1KHz sampling rate)
Data input of FF No.2: a pulse voltage source with 2.8229MHz + 100Hz.
Data input of FF No.3: a pulse voltage source with 2.8229MHz + 500Hz.
As a result all three outputs of the FF were 0.0030100001Hz away from the intended 2.8229MHz.
I tried the same thing with a doubled Master clock frequency of 45.1584MHz but the resultes were far away from the intended frequency.
(You don't have to say it) This is only a simulation not the real world. But maybe a reclocker isn't that a bad idea after all.
I attached the LTSpice circuit.
I don't know if I've done this simulation right, please point out mistakes or feedback.
It is a spice simulation. There is no real clock here.
The three FFs have a single voltage source in Pulse mode with a frequency of 22.5792MHz 50% Duty cycle at the clk input.
The reason for this imaginary experiment is to find a way that the FPGA does not change the frequency of the SI570.
The three FFs have a single voltage source in Pulse mode with a frequency of 22.5792MHz 50% Duty cycle at the clk input.
The reason for this imaginary experiment is to find a way that the FPGA does not change the frequency of the SI570.
Last edited:
How are you sure that you didn't have a slip?
The 1121 do indeed do re-clocking on the backside of the fpga. This means that the clocking of the data out of the fpga will be straighten up so that any jitter from the fpga is reduced to that of the Si (- some intrinsic jitter of the latch itself (re-clocker))
//
The 1121 do indeed do re-clocking on the backside of the fpga. This means that the clocking of the data out of the fpga will be straighten up so that any jitter from the fpga is reduced to that of the Si (- some intrinsic jitter of the latch itself (re-clocker))
//
Sorry TNT, I don't understand the question.
The first assumption is:The FPGA in normal operation, compares the incoming frequency of the i2s Serial Clock /Bit Clock (SCK) signal with the MCLK signal (SI570).
Second assumption:
If SCK frequency is not an exact multiplication, the MCLK signal (SI570), the SI570's frequency is changed to match the exact multiple of it.
Bogdan gave us this information, but I do not understand how a frequency adjustment helps in filling the fifo buffer.
Soeren confirmed assumption 2 for the dam1021 I'd say.Still, my idea is, to present the FPGA a SCK with a perfect devision of an external MCKL, with the purpose to give the FPGA no reason to adapt.
The first assumption is:The FPGA in normal operation, compares the incoming frequency of the i2s Serial Clock /Bit Clock (SCK) signal with the MCLK signal (SI570).
Second assumption:
If SCK frequency is not an exact multiplication, the MCLK signal (SI570), the SI570's frequency is changed to match the exact multiple of it.
Bogdan gave us this information, but I do not understand how a frequency adjustment helps in filling the fifo buffer.
Soeren confirmed assumption 2 for the dam1021 I'd say.Still, my idea is, to present the FPGA a SCK with a perfect devision of an external MCKL, with the purpose to give the FPGA no reason to adapt.
What jitter the FPGA sees is unimportant from a jitter perspective in 1121 as it is re-clocked on the output... this is what differs from the 1021 which has no re-clocking. And its a quite major one and I think one can hear this.
The thing we are trying to do is to be able to use a better clock on the DAM. The clock that you seem to want to use for re-clocking and, in fact, is already used for re-clocking in 1121.
If we had a stable very low jitter clock, the re-clocking on the backside/output of the FPGA (driving the ladders) would be more accurate vs jitter and *probably*, the SQ would up to stratospherical levels.
I feel somewhere there is a divide here in the understanding what the problem is and what a solution may be... if you didn't undertand my "slip" question I think you need to re-visit the hole aspect of this... maybe seek more info of "re-clocking" vs "jitter buffer" and what kind of problem they solve. But maybe I misinterpret you - probably so.
"..but I do not understand how a frequency adjustment helps in filling the fifo buffer." - in this game this is basics almost. I think you don't grasp this fully.
//
The thing we are trying to do is to be able to use a better clock on the DAM. The clock that you seem to want to use for re-clocking and, in fact, is already used for re-clocking in 1121.
If we had a stable very low jitter clock, the re-clocking on the backside/output of the FPGA (driving the ladders) would be more accurate vs jitter and *probably*, the SQ would up to stratospherical levels.
I feel somewhere there is a divide here in the understanding what the problem is and what a solution may be... if you didn't undertand my "slip" question I think you need to re-visit the hole aspect of this... maybe seek more info of "re-clocking" vs "jitter buffer" and what kind of problem they solve. But maybe I misinterpret you - probably so.
"..but I do not understand how a frequency adjustment helps in filling the fifo buffer." - in this game this is basics almost. I think you don't grasp this fully.
//
Last edited:
You really don't understand me :/ I'll give it a try and sum my findings up:
Of course I want to do the reclocking outside the dam module, and of course with an external master clock. not with the SI570. That was the hole point. I am however not talking about jitter. A reclocker is made of FlipFlops. My simulation showed, that FFs can change the output frequency in a small amount.
The question in hand is:
How can one feed an EXTERNAL Master clock to the dam1121.
The Problem is:
The dam1121 changes it's on board SI570 frequency in order to match an exact multiple of the incoming BitClock.
The Solution is:
Attach an EXTERNAL master clock, and present the dam1121 a Bitclock that is an exact division of this EXTERNAL Master Clock, with the help of an EXTERNAL reclocker (FlipFlop), so that the dam1121 which compares the Bitclock to the (now) EXTERNAL Master clock, has no need to change the clock speed (which it couldn't because it's an external clock that is not a programmable clock)
Of course I want to do the reclocking outside the dam module, and of course with an external master clock. not with the SI570. That was the hole point. I am however not talking about jitter. A reclocker is made of FlipFlops. My simulation showed, that FFs can change the output frequency in a small amount.
The question in hand is:
How can one feed an EXTERNAL Master clock to the dam1121.
The Problem is:
The dam1121 changes it's on board SI570 frequency in order to match an exact multiple of the incoming BitClock.
The Solution is:
Attach an EXTERNAL master clock, and present the dam1121 a Bitclock that is an exact division of this EXTERNAL Master Clock, with the help of an EXTERNAL reclocker (FlipFlop), so that the dam1121 which compares the Bitclock to the (now) EXTERNAL Master clock, has no need to change the clock speed (which it couldn't because it's an external clock that is not a programmable clock)
Well, I don't understand how that can work. But I'm probably wrong. Im sure some more people will chime in and comment on your proposal.
My biggest concern is how a re-clocking can fix clock domain differences. To my understanding, re-clocking only fixes jitter smaller than the bit clock pulse time (thats actually the definition of jitter (1/10 UI) - greater deviations is called wander). As a re-clocker has no memory but only one register, it can not digest any larger differences than this and if they do occur, your will simply lose or repeat (maybe 1 or 0 stuffing) a bit... with a certain intensity depending on the difference in clock speed.
//
My biggest concern is how a re-clocking can fix clock domain differences. To my understanding, re-clocking only fixes jitter smaller than the bit clock pulse time (thats actually the definition of jitter (1/10 UI) - greater deviations is called wander). As a re-clocker has no memory but only one register, it can not digest any larger differences than this and if they do occur, your will simply lose or repeat (maybe 1 or 0 stuffing) a bit... with a certain intensity depending on the difference in clock speed.
//