Here is a sim of the glue logic board I designed for the LTC2642 DAC (16bit, Vout, Binary Offset input).
The logic board, built like the sim, did not work as intended but I managed to fix it.
As is, the sine produced by the DAC with this logic board looked something liked this:
The fix was to add 1 extra bit of delay to the data, easily done as the neighbouring shift register output was unused on the board.
I presume the shift was causing the 2nd data bit to be written to the MSB of the DAC and a zero padding bit became the new LSB, resulting in something like the above waveform
e.g 1 1 1 1 0 0 0 0 0
All good but I want to understand why the data needed to be delayed by an additional clock cycle.
My arrangement for the shift registers is like so:
A single shift register delays the data by half BCLK cycle, then the inverted BCLK clocks the data into and through the preceding shift registers after another half cycle...
This was to avoid the problem with traditional DAC glue logic circuits where data is shifted through the delay registers and clocked into the DAC on the same clock edge, and relies on propagation delay to work at all.
When I sim trad glue logic, where the data is clocked into and through the shift registers with normal BCLK, I see what I would expect:
The LSB is a half cycle ahead of the latch signal but presumably with enough delay in the real world that it gets clocked into the DAC on rising edge of BCLK at its tail end, before the latch:
The sim for my logic board, things are aligned more appropiately and in time for the latch:
I cant understand how my board needed the data delayed by an extra clock cycle
Hopefully I gave a clear enough explanation of the setup and the issue that someone might be able to shed some light on this.
The logic board, built like the sim, did not work as intended but I managed to fix it.
As is, the sine produced by the DAC with this logic board looked something liked this:
The fix was to add 1 extra bit of delay to the data, easily done as the neighbouring shift register output was unused on the board.
I presume the shift was causing the 2nd data bit to be written to the MSB of the DAC and a zero padding bit became the new LSB, resulting in something like the above waveform
e.g 1 1 1 1 0 0 0 0 0
All good but I want to understand why the data needed to be delayed by an additional clock cycle.
My arrangement for the shift registers is like so:
A single shift register delays the data by half BCLK cycle, then the inverted BCLK clocks the data into and through the preceding shift registers after another half cycle...
This was to avoid the problem with traditional DAC glue logic circuits where data is shifted through the delay registers and clocked into the DAC on the same clock edge, and relies on propagation delay to work at all.
When I sim trad glue logic, where the data is clocked into and through the shift registers with normal BCLK, I see what I would expect:
The LSB is a half cycle ahead of the latch signal but presumably with enough delay in the real world that it gets clocked into the DAC on rising edge of BCLK at its tail end, before the latch:
The sim for my logic board, things are aligned more appropiately and in time for the latch:
I cant understand how my board needed the data delayed by an extra clock cycle
Hopefully I gave a clear enough explanation of the setup and the issue that someone might be able to shed some light on this.
Last edited:
I still have no idea how the logic is working like this,
The only significant source of propagation delay would be HC164 shift registers. While it does not spec delay at 3.3V, at 2V it becomes significantly higher from clock edge to output, enough to cause corruption at higher sample rates...
But extra delay was the solution to the problem, not the cause, and the DAC plays fine up to 352.8kHz.
It could then be that the latch is delayed, but that would be an even bigger question of "how"
Speaking of the latch, there is some adjustments that could be made to the logic.
The LTC's Idd spikes as digital inputs change, these currents are significant compared to the quiescent current and Vref current.
Stopped clock operation seemed like a good idea here and was easy to implement.
The LRCLK holds the DAC's BCLK high for the first half of the frame via an OR gate,
holding it high to avoid it transitioning low at the most crucial time - as the dac is latched:
Problem?
Holding high requires BCLK is delayed compared to LRCLK or there will be a short low pulse... doubling the issue.
This could be addressed with small RC filter on the LRCLK input of the OR gate.
But that only addresses BCLK, the data signals are also transitioning as the DAC latches...
It would be better to latch the DAC a bit later, after the clock is stopped and when the data is zero, and this is easily achieved.
The chain of flip flops in the circuit outputs LRCLK with a 2 bit delay, so this can now be used as the new latch signal.
It should also extend the stopped clock operation for 2 extra cycles after the clock renables in the glue logic since the clock is disabled while the CS pin is held high.
Updated sim
The only significant source of propagation delay would be HC164 shift registers. While it does not spec delay at 3.3V, at 2V it becomes significantly higher from clock edge to output, enough to cause corruption at higher sample rates...
But extra delay was the solution to the problem, not the cause, and the DAC plays fine up to 352.8kHz.
It could then be that the latch is delayed, but that would be an even bigger question of "how"
Speaking of the latch, there is some adjustments that could be made to the logic.
The LTC's Idd spikes as digital inputs change, these currents are significant compared to the quiescent current and Vref current.
Stopped clock operation seemed like a good idea here and was easy to implement.
The LRCLK holds the DAC's BCLK high for the first half of the frame via an OR gate,
holding it high to avoid it transitioning low at the most crucial time - as the dac is latched:
Problem?
Holding high requires BCLK is delayed compared to LRCLK or there will be a short low pulse... doubling the issue.
This could be addressed with small RC filter on the LRCLK input of the OR gate.
But that only addresses BCLK, the data signals are also transitioning as the DAC latches...
It would be better to latch the DAC a bit later, after the clock is stopped and when the data is zero, and this is easily achieved.
The chain of flip flops in the circuit outputs LRCLK with a 2 bit delay, so this can now be used as the new latch signal.
It should also extend the stopped clock operation for 2 extra cycles after the clock renables in the glue logic since the clock is disabled while the CS pin is held high.
Updated sim
You have two logic outputs fighting each other.
The Q-bar output of each DQ flipflop is shorted to the BCLK or an inverter driven from BCLK.
This will lead to unreliable / faulty behaviour.
Also why so many DQ flipflops, you can delay 1 whole clock cycle with each (or 1/2 cycle if inverted)...
The Q-bar output of each DQ flipflop is shorted to the BCLK or an inverter driven from BCLK.
This will lead to unreliable / faulty behaviour.
Also why so many DQ flipflops, you can delay 1 whole clock cycle with each (or 1/2 cycle if inverted)...
It looks like short but it's just overlapping wire, no junction... not the best layout
Good catch on FFs, it functions the same without #3.
This needs to be verified but I think this would explain the source of the main issue:
What the sim doesnt include is that the latch signal is reclocked with MCLK on the DAC board.
If LRCLK is slightly delayed relative to BCLK, causing the stop clock gate to generate a rising edge on the clock line as shown, the LSB is being loaded in twice by this edge as the latch is delayed slightly by the reclocker.
Because the data shift registers are clocked by BCLK, which is slightly ahead of LRCLK, that final clock edge just barely catches the LSB after the extra bit of delay was added.
Good catch on FFs, it functions the same without #3.
This needs to be verified but I think this would explain the source of the main issue:
What the sim doesnt include is that the latch signal is reclocked with MCLK on the DAC board.
If LRCLK is slightly delayed relative to BCLK, causing the stop clock gate to generate a rising edge on the clock line as shown, the LSB is being loaded in twice by this edge as the latch is delayed slightly by the reclocker.
Because the data shift registers are clocked by BCLK, which is slightly ahead of LRCLK, that final clock edge just barely catches the LSB after the extra bit of delay was added.
this is exactly why i stopped using individual parts, I prefer fpga´s or silego greenpak. FPGA´s have saved many times a board respin when a sudden problem was encountered during final testing. So the cost of the fpga is easily offset by the board respin cost and project delay costs.
This was a lot easier than using an FPGA and learning to code 🙂
But what about cost of the FPGA versus individual parts for such simple logic (once the kinks are worked out)?
Noise and power consumption compared to FPGA?
Repairability?
But what about cost of the FPGA versus individual parts for such simple logic (once the kinks are worked out)?
Noise and power consumption compared to FPGA?
Repairability?
I personally hate coding, I prefer schematic input, greenpaks are childplay, looks like visio drag and drop. That´s the trouble with analog people. With the greenpaks the delay may be less predictable, and your design should be robust for that. I used it up to 10Mhz clocks. Above that fpga´s.
ah very cool, would be handy for prototyping the glue logic.
Next up will be 14 bit AD9744 with 2s parallel input, but this is even simpler logic again.
Next up will be 14 bit AD9744 with 2s parallel input, but this is even simpler logic again.
the dual rail greenpaks are ideal for levelshifting. the kits are dirt cheap. their slogan was : integrate 25 parts in 25 minutes for 25 cents. its OTP, but the I2S devices can always be loaded with an external file. Done tons of fancy stuff with them.
Here are some rough measurements of the DAC collected during testing, made with Cosmos ADC:
0dB 1khz @ 352.8k into 60k load
0dB 1khz @ 352.8k into low impedance load
-60db 1khz @ 352.8k
THD doesnt seem to decrease much with level but HF noise does, prob due to lower glitch.
Maybe a sign magnitude config could help?
The DAC vref is connected direct to Vdd, provided by Li-ion cell, the datasheet measurements are done with 2.5V vref and 5V Vdd, I cant test what a reduced vref voltage does but based on -60dB it probably wont influence low level performance.
I assume the 2.5V vref is only to reflect a typical use case where a highly stable, low noise reference is generated from the Vdd supply, like datasheet example.
No need to worry about gain accuracy for this application however
Tweaking supply decoupling or swapping Li-ion for LiFePo4 cell had virtually no influence on the measurements .
0db 1khz @ 352.8k with buffered output, -6db ADC input
vs NOS
More noise with NOS but is the DAC the source?
test signals are from REW, 16bit with dither.
CCIF with 60k and low Z load, offset for clarity
For reference:
TDA1387
0dB 176kHz
Topping DX1, -6dB ADC input
0dB @ 352.8k
small noise skirts compared to LTC , the "Discrete LNRD" is not so effective for 1/f noise?
-60dB, HD vanishes but same rising out of band noise
0dB @ 44.1kHz, typical usage
Poorer image rejection with built in filters?
-60dB @ 44.1kHz
0dB 1khz @ 352.8k into 60k load
0dB 1khz @ 352.8k into low impedance load
-60db 1khz @ 352.8k
THD doesnt seem to decrease much with level but HF noise does, prob due to lower glitch.
Maybe a sign magnitude config could help?
The DAC vref is connected direct to Vdd, provided by Li-ion cell, the datasheet measurements are done with 2.5V vref and 5V Vdd, I cant test what a reduced vref voltage does but based on -60dB it probably wont influence low level performance.
I assume the 2.5V vref is only to reflect a typical use case where a highly stable, low noise reference is generated from the Vdd supply, like datasheet example.
No need to worry about gain accuracy for this application however
Tweaking supply decoupling or swapping Li-ion for LiFePo4 cell had virtually no influence on the measurements .
0db 1khz @ 352.8k with buffered output, -6db ADC input
vs NOS
More noise with NOS but is the DAC the source?
test signals are from REW, 16bit with dither.
CCIF with 60k and low Z load, offset for clarity
For reference:
TDA1387
0dB 176kHz
Topping DX1, -6dB ADC input
0dB @ 352.8k
small noise skirts compared to LTC , the "Discrete LNRD" is not so effective for 1/f noise?
-60dB, HD vanishes but same rising out of band noise
0dB @ 44.1kHz, typical usage
Poorer image rejection with built in filters?
-60dB @ 44.1kHz
Attachments
Last edited:
Yes, I thought it could be LJ output from interface but confirmed it works with another I2S DAC.
Im using cheapest amanero clone from Aliexpress, I tried messing with OEMtool to see if it would work to get the interface to output at 32fs... it seemed to detect and upload to the interface but had no effect, tool had an option for LJ so it was possible the settings got messed up, fortunately no... lucky to not have bricked the whole interface doing that.#
An official amanero board set to 32fs would eliminate a bunch of shift registers and stop the clock fully in this logic.
Frustratingly this interface also only has 32bit output in windows, either need to use HQPlayer or PGGB-RT to be able set the correct DAC bits for upsampling and dither.
Im using cheapest amanero clone from Aliexpress, I tried messing with OEMtool to see if it would work to get the interface to output at 32fs... it seemed to detect and upload to the interface but had no effect, tool had an option for LJ so it was possible the settings got messed up, fortunately no... lucky to not have bricked the whole interface doing that.#
An official amanero board set to 32fs would eliminate a bunch of shift registers and stop the clock fully in this logic.
Frustratingly this interface also only has 32bit output in windows, either need to use HQPlayer or PGGB-RT to be able set the correct DAC bits for upsampling and dither.
Last edited: