BCK in my use is the incomong BCK (MvG DAC net bckin).
SRCK (Shift Register clock) is the double clock (MvG DAC net U28A out)
BCK / SRCK and RTZ_P and RTZ_N as data in the SRCK domains and RTZ_CM as the common mode.
A Tapped FIR will mitigate somewhat against the CM issue, as it has multiple taps, compared to a single Bit Switch,
BUT for 11 (BCK) which without RTZ would be 1111 (SRCK), the positive output would get (say) 0101 and the negative output 0000.
At the same time 00 (BCK) which without RTZ would be 0000 (SRCK), the positive output would get (say) 0000 and the negative output 0101.
If we ripple DSD (0x69h - 01101001) silence through the DAC it is more clear what is going on.
01101001 (BCK)
0011110011000011 (SRCK)
0001010001000001 (RTZ_P)
0100000100010100 (RTZ_N)
1010101010101010 (RTZ_CM) (strictly speaking 1 is actually 0.5 but it spoils clarity)
0011110011000011 (NRZ_P)
1100001100111100 (NRZ_N)
0000000000000000 (NRZ_CM) (NRZ has ideally no common mode)
01101001 (BCK)
0011110011000011 (SRCK)
0001010001000001 (RTZ_P)
0100000100010100 (RTZ_N)
0010100010000010 (RTZ_P2)
1000001000101000 (RTZ_N2)
0011110011000011 (RTZ_P+P2)
1100001100111100 (RTZ_N+N2)
0000000000000000 (RTZ+RTZ2_CM) (strictly speaking between each zero are glitches)
Clearer?
Thor
Yes.
Maybe this is more like Marcel's point of view:
If in #2,288 Marcel is taking the sum of P0 + P1 as the first summed output, then analyzing P0 in isolation shows that P0 by itself produces CM noise.
0011110011000011 (SRCK) DSD data clocked x2
0001010001000001 (RTZ_P0) if the hole is inserted before the 1 instead of after
_0001010001000001 (RTZ_P1) P0 delayed by BCK/2 (equivalent to DAC_2 offset in time?)
_0011110011000011 (RTZ_P0 + RTZ_P1)
Of course, this leaves N0 and N1 to work out.
So, anyway, the question then becomes what happens at the next SRCK clock cycle when the next shift takes place? Is there a large CM noise component in the net summation depending on the DSD bit pattern? Still mulling that part over, but, yeah, could be. Say maybe on P0/N0 and P3/N3, every other SRCK cycle. Something like that.
Last edited:
This risks having incorrect relationships between signals, clocks etc.
It is better to account for the whole system. Otherwise we get assumptions about how things work baked into the sim.
Thank you.
Observations.
Shift registers latch on the rising edge, timing between clock and data seems wonky?
Like this looks not quite right.
As said, when time allows I will input the whole DAC into TINA again and run everything again.
You have the actual DAC and I expect a 4-Trace 'scope? I only have the 'scope here.
Thor
There are a number of ways to achieve this.
Personally I'd use a separate delay chain. In a commercial product this was rolled into a FPGA, which also did other jobs.
DAC's were modern BB that in DSD mode work essentially like DSD1700.
Two DAC's were used "interleaved" running at ~25MHz to achieve ~50MHz effective DSD rate, a very different objective to what we talk about here.
Let's keep simple.
The "zero" part invariably forms a common mode only signal. Any differential mode is "error".
So we have a common mode (forced zero) element rippling through the FIR.
We also have a differential mode (data) element rippling through the FIR.
Again, main question is what we try to accomplish. That determines the method.
Thor
Sorry, there was a half cycle timing shift between clock and data.
Here is corrected simulation. Results are more or less the same. You can of course put everything in Tina but I doubt it will change the outcome.
Attachments
Mark,
This is what Marcel did in his Solid state DAC using FPGA’s, PCM in and 1 bit PWM out to a FirDac.
@marcel
Could you please give your comment on the proposal of simulating various models and also producing the most demanding DSD bit pattern of at least 16 bit.
It’s a lot of work to set up the models is a way that everything can be parametrized, but if you think its a waste of time then ……
Hans
This is what Marcel did in his Solid state DAC using FPGA’s, PCM in and 1 bit PWM out to a FirDac.
@marcel
Could you please give your comment on the proposal of simulating various models and also producing the most demanding DSD bit pattern of at least 16 bit.
It’s a lot of work to set up the models is a way that everything can be parametrized, but if you think its a waste of time then ……
Hans
Hans, regarding bit patterns for simulation, the only repetitive pattern I can measure is 10101010..., which should ideally result in constant DAC core outputs, and Thor likes to see 0110100101101001... I suggest to use those.
I'm don't know what the "various models" question refers to.
Last edited:
Mark, this is a modulator, not a DAC. The FIR DAC and DSD1700 are hardware, not software IP.
The FIR DAC Hardware they use does not appear to be available in in the public domain.
Thor
Looks interesting. I remember getting different results. Let me see. I find the display kills my eyes.
I ABSOLUTELY HATE LT-SPICE. EVERYTHING ABOUT IT.
Something I'm working on.
The Digital Generator in TINA is totally horrorshow. You can literally set up any clock and bit pattern across many outputs:
Here you see MCK (2 X BCK), BCK and DSD Data L/R.
Not "like". 0x69h is the official idle pattern for DSD. It's like that for a number of reasons.
Other bitpatterns to try are 0x77h, repeated for (say) 100uS alternating with 0x44h for 100uS (near full scale 10kHz square).
The dearth of useful DSD test files means you need to create them on binary level.
Thor
But that is not in that paper. I'm too busy/lazy to do deep digging in the dark web to see if it's somewhere.
Is there a patent for the FIR DAC Hardware?
Anyway, many ways to make such a DAC in hardware and to trade off performance related design features vs circuit complexity.
Thor
Marcel, I can imagine you get a bit grumpy about all the comments on your Firdac.
The "various models" to simulate was no question but were 1) the suggested “interleaved” dual Dac and 2) the cross coupled version as in the DSD1700 in comparison with your Firdac.
Hans
Reply to post #2317:
I don't know what paper you mean, but the picture in post #2310 is clearly about a digital hardware IP. If it were software, they wouldn't specify the equivalent number of gates. Not that it makes any fundamental difference, any hardware state machine can in principle be implemented in software as well (Alan Turing, "On computable numbers with an application to the Entscheidungsproblem", 1936-1937).
Anyway, the point is that with a sigma-delta with embedded pulse width modulator, you don't need an RTZ DAC, if you implement the modulator such that there is always one and only one gap between adjacent PWM pulses. That is, the modulator then already makes gaps between the pulses, so you don't need to add gaps around each bit.
I don't know what paper you mean, but the picture in post #2310 is clearly about a digital hardware IP. If it were software, they wouldn't specify the equivalent number of gates. Not that it makes any fundamental difference, any hardware state machine can in principle be implemented in software as well (Alan Turing, "On computable numbers with an application to the Entscheidungsproblem", 1936-1937).
Anyway, the point is that with a sigma-delta with embedded pulse width modulator, you don't need an RTZ DAC, if you implement the modulator such that there is always one and only one gap between adjacent PWM pulses. That is, the modulator then already makes gaps between the pulses, so you don't need to add gaps around each bit.
Last edited:
As you can see from post #2313, despite claims to the opposite, there is nothing wrong with Marcel's interleaving so simulations of other models would not necessarily reveal any improvements.
BTW do you know if there is a better way to generate pulse patterns in LTSpice than what I used in post #2313?