DAC Update Spurs and Crosstalk

[pathfinder49]

I'm having a look at the DAC update spurs.

For a first look, I'm configuring Kasli & Fastino in the "no spurs" configuration from #56. (With CMCs on the DAC outputs and a ground strap to Fastino)

Single DACs are made to update at 2.55 MS/s by repeatedly writing a voltage via DMA.

Looking at channels 24-29 & 31 there is some variability in the DAC update spur intensity. I'll post proper data later. Of the top of my head, -70dBmV spur amplitude is typical for these spurs.

DAC update cross talk is much more significant. In paticular, channels 27 and 24 Have significant crosstalk onto other channels. The resulting spurs are in excess of -50dBmV.

I'll post more details at a later time.

[pathfinder49]

The list below contains the 2.55 MHz spur powers resulting from a single DAC updating with the configuration detailed above.

Noise floor at -85 dBmV

ch24 updating:

• ch24: na
• ch25: -76 dBmV
• ch26: -55 dBmV
• ch27: na
• ch28: -63 dBmV
• ch29: na
• ch31: na

ch25 updating:

• ch24: na
• ch25: -82 dBmV
• ch26: -53 dBmV
• ch27: na
• ch28: na
• ch29: na
• ch31: na

ch26 updating:

• only ch26: -77 dBmV

ch27 updating:

• ch24: na
• ch25: -71 dBmV
• ch26: na
• ch27: na
• ch29: -52 dBmV
• ch28: -71 dBmV
• ch31: na

ch28 updating

• ch24: na
• ch25: na
• ch26: -72 dBmV
• ch27: na
• ch28: na
• ch29: -53 dBmV
• ch31: -78 dBmV

ch29 updating:
no spurs seen

ch30 updating:

• ch24: na
• ch25: na
• ch26: -63 dBmV
• ch27: na
• ch28: na
• ch29: na
• ch31: -48 dBmV

ch31 updating:

• only ch31: -76 dBmV

[pathfinder49]

The data above has a general trend of DAC updates coupling to channels located behind the updating DAC. This may be in the same or adjacent row.

Here is the relevant board section.

[hartytp]

It's worth picking a few channels and measuring the cross-talk to all 31 other channels.

[hartytp]

Does na mean: lower than the instruments noise floor?

[hartytp]

@pathfinder49 can you have a go at installing altium please (I'm happy to help you if you get stuck). See if you can figure out the origin of the cross-talk. Also, can you post a spectrum? Is this noise just at the DAC clock frequency? What data are you writing, do you see pattern-dependent spurs? We don't need to do something completely exhaustive here, but just need to get an idea of the orders of magnitude and see if there are any channels that are particularly bad/good (which would point to a layout issue that might be fixable)

[pathfinder49]

Does na mean: lower than the instruments noise floor?

It does.

[hartytp]

i.e with data constantly being written to channel 24 you don't see any spurs on that channel? e.g. no clock spurs etc on that channel?

To check I've understood you:

• you've got the board configured such that one channel is updating with a fixed data word and a constant update rate of 2.55MHz
• on that channel, the clock, data, LDAC, NSS are toggling with a periodic pattern
• all other channels are static (NB IIRC the clocks etc are not shared between channels so we really can isolate just one channel)

[pathfinder49]

Also, can you post a spectrum? Is this noise just at the DAC clock frequency? What data are you writing, do you see pattern-dependent spurs?

This noise is at the DAC update frequency. So far I'm looking with a narrow bandwidth around 2.55 MHz to reduce the noise floor. I have not noticed any pattern dependent spurs. However, I do not expect to see them at 2.55 MHz. I have not noticed any pattern dependent spurs when measuring with wider bandwidth in the sub 10 MHz range.

The SPI clock updates at f_SPI = 47.6 MHz. As we have 16 bit words, I would expect the code dependent noise at f_SPI * n/16 +- 2.55 MHz with 0<n<17. Edit: I stand corrected.

i.e with data constantly being written to channel 24 you don't see any spurs on that channel? e.g. no clock spurs etc on that channel?

I don't see DAC update spurs at 2.55 MHz.

To check I've understood you:

• you've got the board configured such that one channel is updating with a fixed data word and a constant update rate of 2.55MHz

Correct

• on that channel, the clock, data, LDAC, NSS are toggling with a periodic pattern

SCLK is toggling at 47.6 MHz, LDAC is held low, CLR is held high. In this mode words are immediately transferred to the DAC when CS is brought high. CS toggles at 2.55 MHz.

• all other channels are static (NB IIRC the clocks etc are not shared between channels so we really can isolate just one channel)

That is correct.

[pathfinder49]

I attempted observing the DAC update glitches before the filter. Acccording to the datasheet these should look like this:

I measured with a 10:1 500 MHz scope probe and a voltage resolution of ~2 mV. I did not see any glitches before the filter when updating the DAC (both for individual updates and 2.55 MS/s updates).

[hartytp]

This is for major carry transitions. What data were you writing? Try triggering the scope off cs and turning on a bit of averaging...

[pathfinder49]

Then I missunderstood our earlier discussion. This shouldn't pertain to this issue. I was repeatedly writing the same code.

[pathfinder49]

Aside: I've removed R153 from channel 31 and connected the DAC output directly to the amplifier input with a wire (no PCB contact). This changes the cross-talk pickup of channel 31.

channel 31 spur from updating:

• ch24: na (unchanged)
• ch25: na (unchanged)
• ch26: na (unchanged)
• ch27: na (unchanged)
• ch28: -80 dBmV (similar)
• ch29: -72 dBmV (new)
• ch30: -48 dBmV (unchanged)
• ch31: -63 dBmV (increased)

This suggests that the large crosstalk spurs couple in after amplification.

[pathfinder49]

I'm now picking a few channels to check crosstalk to all channels for.

Updating channel 31 I observe crosstalk to:

• ch8@-82 dBmV (may be noise?)

Updating ch28 I observe crosstalk to:

• [email protected] dBmV
• [email protected] dBmV
• [email protected] dBmV
• ch16[email protected] dBmV
• [email protected] dBmV
• [email protected] dBmV

From above:

ch28 updating

• ch24: na
• ch25: na
• ch26: -72 dBmV
• ch27: na
• ch28: na
• ch29: -53 dBmV
• ch31: -78 dBmV

[pathfinder49]

Looking at altium, the CS trace runs like this:

It runs underneath (or close to) the analogue line of the channels listed above. Ch16 seems to be an odd one out here. I will double check that I didn't get it mixed up with channel 17 tomorrow.

Edit: The CS trace crosses the channel 26 (above ch23) analogue lines without causing as much crosstalk.

[pathfinder49]

Indeed, I got channel 16 and 17 confused. I've double checked the other channels. They are all correct.

[hartytp]

@pathfinder49 Thanks for the summaries. I think we have been talking past each other, but I now understand what you're up to.

This noise is at the DAC update frequency. So far I'm looking with a narrow bandwidth around
2.55 MHz to reduce the noise floor. ... I have not noticed any pattern dependent spurs when measuring with wider bandwidth in the sub 10 MHz range.

So, bascially, right now you're putting a fixed data work onto a single channel. So we expect to see:

• noise at ~50MHz due to the clock lines. Did you look for this and not see it or not look for it? (We're not particularly sensitive to this so it's not a big deal, just curious)
• Noise at 2.55MHz due to the CS line toggling
• Fixed voltages on the data lines mean we wouldn't expect to see any noise form them in this measurement

If you look at those two figures in the DAC data sheet and then read the section about what the measurements mean, I think you'll see that the glitches are highly pattern dependent, so we shouldn't expect to see them here.

The fact that you don't see any spurs on the channel you're updating suggests that with a fixed data word you don't get any glitches due to the DAC itself. In other words, all you're measuring is the cross-talk between the CS trace and the analog outputs (perhaps via the reference/supplies).

[hartytp]

Aside: I've removed R153 from channel 31 and connected the DAC output directly to the amplifier input with a wire (no PCB contact). This changes the cross-talk pickup of channel 31.

I don't follow what you mean here. Can you draw a line on the schematic to show what you did?

[hartytp]

I'm now picking a few channels to check crosstalk to all channels for.

Was this measurement with an unmodified board?

[hartytp]

It runs underneath (or close to) the analogue line of the channels listed above. Ch16 seems to be an odd one out here. I will double check that I didn't get it mixed up with channel 17 tomorrow.

You can use altium to highlight a net across all layers (see some of the images Greg posted). Can you post an image that clearly shows the active CSS trace, as well as the affected channels?

[hartytp]

At a high level, the real question here is whether there is anything easy we can do to reduce these spurs.

Assuming:

• we have decent evidence to support the claim that this is a direct coupling between traces and not via another channel like the reference/supply. This can be determined by correlating the spur heights with trace proximity (supplies/references would lead to different distributions of the spurs between channels).
• the stackup is correct (I have no reason to doubt it's not) so that the digital lines are all sandwiched between ground layers.

I'm not sure there is anything easy we can do to improve this. There are a few things we could potentially do, but I don't think the complexity would be warranted

• differentially drive the outputs
• add more layers (might not help). Potentially, we could have a separate layers for "analog" and "digital" grounds and be really careful about where the layers join together. Not sure how well this would work in practice.
• decrease the channel count/density

But, I'm not sure any of those would be warranted; the worst-case spurs are better than -40dBmV (10uV RMS). It would presumably be worse than that if all channels toggle, but not so bad for an out-of-band spur...

[hartytp]

@pathfinder49 one final question: do the spur heights you measure depend in any way on grounding etc?

[hartytp]

Once we have the data on this to show the coupling mechanics, it would be interesting to hear from @gkasprow if he can think of any ways the layout could be improved to make this effect smaller....

[pathfinder49]

So, bascially, right now you're putting a fixed data work onto a single channel. So we expect to see:

noise at ~50MHz due to the clock lines. Did you look for this and not see it or not look for it? (We're not particularly sensitive to this so it's not a big deal, just curious)

I did not look for this as it shouldn't be significant for our use case.

Noise at 2.55MHz due to the CS line toggling

Fixed voltages on the data lines mean we wouldn't expect to see any noise form them in this measurement

The data lines are changing. They repeat the same word every 1/47.6 us. I've described the expected data line frequencies above.

If you look at those two figures in the DAC data sheet and then read the section about what the measurements mean, I think you'll see that the glitches are highly pattern dependent, so we shouldn't expect to see them here.

As I understand it, the glitches are for pattern changes. Here an identical pattern is repeated.

The fact that you don't see any spurs on the channel you're updating suggests that with a fixed data word you don't get any glitches due to the DAC itself. In other words, all you're measuring is the cross-talk between the CS trace and the analog outputs (perhaps via the reference/supplies).

I do see a self-induced update spur in some channels. I expect that with some averaging I could resolve them in more channels. This is much less significant than the crosstalk caused in other channels. The self induced spurs may also be due to the CS line toggling.

Aside: I've removed R153 from channel 31 and connected the DAC output directly to the amplifier input with a wire (no PCB contact). This changes the cross-talk pickup of channel 31.

I don't follow what you mean here. Can you draw a line on the schematic to show what you did?

I'm now picking a few channels to check crosstalk to all channels for.

Was this measurement with an unmodified board?

The board was modified as described in the initial post. grounded IC3 shield, etc.
The modification of the ch31 output did not appear to have an effect of the ch31 updates coupling to other channels.

It runs underneath (or close to) the analogue line of the channels listed above. Ch16 seems to be an odd one out here. I will double check that I didn't get it mixed up with channel 17 tomorrow.

You can use altium to highlight a net across all layers (see some of the images Greg posted). Can you post an image that clearly shows the active CSS trace, as well as the affected channels?

This is already the case in the picture I posted. Unhelpfully this is highlighted in dark grey. I couldn't find a better way than control clicking the trace...

[pathfinder49]

@pathfinder49 one final question: do the spur heights you measure depend in any way on grounding etc?

I have not investigated this. It does not.

I'm not sure there is anything easy we can do to improve this. There are a few things we could potentially do, but I don't think the complexity would be warranted

* differentially drive the outputs

* add more layers (might not help). Potentially, we could have a separate layers for "analog" and "digital" grounds and be really careful about where the layers join together. Not sure how well this would work in practice.

* decrease the channel count/density

The crosstalk to a channel is very dependent on its position. To me, this suggests the crosstalk is avoidable by routing the digital (CS?) lanes differently.

From the highlighted trace above, it looks like the the crosstalk is significant when the CS line passes underneath(/close to) the CMC slot of a channel. The channel 28 trace runs in layer 5 so the main coupling mechanism may well be elsewere...

[hartytp]

The data lines are changing. They repeat the same word every 1/47.6 us. I've described the expected data line frequencies above.

You haven't said what the data word is yet. e.g. if it's 0xffff then the data lines are static. I assume this isn't the case but you really need to document everything required to reproduce the measurement.

The modification of the ch31 output did not appear to have an effect of the ch31 updates coupling to other channels.

From the diagram you posted, I can't understand what you were trying to achieve or why that modification would have any effect on anything. The noise source is not the DAC output (which is static) it's the CS line, which you haven't touched.

This is already the case in the picture I posted. Unhelpfully this is highlighted in dark grey. I couldn't find a better way than control clicking the trace...

Aah, ok, thanks. I didn't notice that the first time around.

[hartytp]

From the highlighted trace above, it looks like the the crosstalk is significant when the CS line passes underneath(/close to) the CMC slot of a channel

The interpretation I have for that is as follows:

• the signals from the CMC onwards are routed as a differential pair
• due to the low-impedance analyzer and liberal smattering of CMCs in the system we should have good common-mode suppression at 2.5MHz
• if a CS (or other noise source) runs under a differential pair then the cross-talk should be pretty common to both the signal and return line. Hence it is rejected by the CMCs
• so the only place you're sensitive to noise is where the return line connects to PCB ground. That's currently R67.

The channel 28 trace runs in layer 5 so the main coupling mechanism may well be elsewhere...

There are two hopefully quick things you can do to test this hypothesis

1. Remove R67. Add the shortest possible air wire between the output (not ground) side of R67 and the DAC ground. Probably the best place would be the ground side of C101 (which is the AC ground reference point for the reference). That basically gives a kelvin connection between the reference ground and the output return
2. Remove R67 and R66 and populate a CMC. In the current layout, the CMC ground is a little closer to the reference ground, which may help.

The channel 28 trace runs in layer 5 so the main coupling mechanism may well be elsewere...

Don't forget that with the current stackup the return currents for both digital and analog signals flow through the same planes, so there will be common-impedance couplings. If the Kelvin connection doesn't help we could consider additional ground layers in the next revision, which are only tied together at specific points. However, that would need some thought...

[hartytp]

From the highlighted trace above, it looks like the the crosstalk is significant when the CS line passes underneath(/close to) the CMC slot of a channel

How can you say whether it's the CMC or the output signal/return traces from a channel (or even the vais used for those traces)? They all come from the same area of the PCB and I don't see a strong enough spatial correlation to separate the causes.

[pathfinder49]

From the highlighted trace above, it looks like the the crosstalk is significant when the CS line passes underneath(/close to) the CMC slot of a channel

How can you say whether it's the CMC or the output signal/return traces from a channel (or even the vais used for those traces)? They all come from the same area of the PCB and I don't see a strong enough spatial correlation to separate the causes.

Agreed. This was only intended to identify the relevant board area.

[pathfinder49]

The crosstalk conincides with the CS trace crossing the line to C1 highlighted below.

Here is an image of the back of the PCB with the channel 28 CS line hilighted.

Crosstalk from ch28 to ch26 is about 20dBV less than to the other indicated channels.
Channel 29 does not fit well with the CS line routing hypothesis.

[pathfinder49]

You haven't said what the data word is yet.

The word for -9.5 V is: 0000 0110 0110 0110

[hartytp]

The crosstalk conincides with the CS trace crossing the line to C1 highlighted below.

I'm not sure I find that convincing...e.g. ch8 has only slightly lower cross-talk than those channels but the CS line is much further from that capacitor. See if the Kelvin connection works. Otherwise have at the cross-talk from a few more channels and see if a pattern emerges.

[pathfinder49]

There are two hopefully quick things you can do to test this hypothesis

1. Remove R67. Add the shortest possible air wire between the output (not ground) side of R67 and the DAC ground. Probably the best place would be the ground side of C101 (which is the AC ground reference point for the reference). That basically gives a kelvin connection between the reference ground and the output return

2. Remove R67 and R66 and populate a CMC. In the current layout, the CMC ground is a little closer to the reference ground, which may help.

I tried both of these modifications on channel 17 (channel 28 updating).

1. Makes no difference
2. Reduces the spur by ~3-4 dBV

I'll check if the spurs change significantly with no CMCs on the adapter board. Measuring without CMCs makes no difference.

Edit: populating the CMCs makes a large difference for some channel combinations.

[pathfinder49]

I've measured the crosstalk caused by channel 4 & channel 18 updates. Configuration is the same as as before with a noise floor around -85 dBmV.

Channel 4 updates give crosstalk to:

• ch1@ -39.5 dBmV
• ch3@ -62 dBmV
• ch5@ -74 dBmV
• ch6@ -80 dBmV
• ch7@ -69 dBmV
• ch10@-75 dBmV

Here the relevant trace routing for channel 4:

Front	Rear

Channel 18 updates give crosstalk to:

• ch5@ -35.8 dBmV
• ch7@ -57 dBmV
• ch8@ -77 dBmV
• ch10@ -66 dBmV
• ch13@ -53.8 dBmV
• ch16@ -38.8 dBmV
• ch19@ -80 dBmV
• ch20@ -54.4 dBmV
• ch22@ -72 dBmV

Trace routing for channel 18:

Front	Rear

[pathfinder49]

Some of the spurs are word dependent.

Updating ch28 with the word 0x0000 (-10 V), I observe reduced crosstalk to some channels:

• [email protected] dBmV -> -50 dBmV
• [email protected] dBmV -> -50 dBmV
• [email protected] dBmV -> -52 dBmV
• [email protected] dBmV -> -52 dBmV
• [email protected] dBmV -> -76 dBmV
• [email protected] dBmV -> gone
• ch26: -72 dBmV -> -73 dBmV
• ch29: -53 dBmV -> -66 dBmV
• ch31: -78 dBmV -> gone

The relevant traces are shown below.

Front	Rear

Channel 23 is paticularly interesting. The entire spur appears to couple in from the digital line underneath the CMC pads. On the rear side this trace runs underneath the double diode. The digital line crosses the analogue trace to the double diode and C1.

The coupling to channel 31 and 29 also reduces. There may be a different mechanism at work here.

Edit: The word dependence seems to correlate well with the digital line passing close to an analogue via. I'll look at a few more traces to check this.

[hartytp]

Look, for example, here at the spurs when updating channel 18. The two worst-affected channels are 18 and 5. But the CS line is routing with respect to those two channels is quite different. That suggests that there isn't just one noise-critical node in the circuit. That will make it harder to identify/fix the noise coupling.

[hartytp]

Edit: The word dependence seems to correlate well with the digital line passing close to an analogue via. I'll look at a few more traces to check this.

That's potentially interesting. Try to get as much data as you can and sort through it. Post here if you find strong correlations...

[pathfinder49]

I've remeasured channel 4 and 18 with the word 0x0000 (-10 V). This is compared to the previous crosstalk from writing -9.5 V.

My configuration is the same as as before with a noise floor around -85 dBmV.

Channel 4 updating:

• ch1@ -39.5 dBmV -> -40 dBmV
• ch3@ -62 dBmV -> -82 dBmV
• ch5@ -74 dBmV -> -76 dBmV
• ch6@ -80 dBmV -> gone
• ch7@ -69 dBmV -> -69 dBmV
• ch10@-75 dBmV -> gone

Trace routing for channel 4:

Front	Rear

Channel 18 updating:

• ch5@ -35.8 dBmV -> -45 dBmV
• ch7@ -57 dBmV -> -59 dBmV
• ch8@ -77 dBmV -> -82 dBmV
• ch10@ -66 dBmV -> -65 dBmV
• ch13@ -53.8 dBmV -> -53 dBmV
• ch16@ -38.8 dBmV -> 56 dBmV
• ch19@ -80 dBmV -> -82 dBmV
• ch20@ -54.4 dBmV -> -54 dBmV
• ch22@ -72 dBmV -> 80 dBmV

Trace routing for channel 18:

Front	Rear

[pathfinder49]

I've not noticed a unifying pattern for all crosstalk. However, there may be some patterns.

1. Digital lines passing close to analogue output vias. Word dependence of the relevant channels seems to also make sense with this.
   • Vias from CMC pad to differential pair of output
     • updating ch28: 17, 20, 23
     • updating ch4: 1, 3
   • Via from R66 to the double diode
     • updating ch28: 8, 11, 14
     • updating ch18: 16
     • updating ch4: 1
2. Digital lines passing close to op-amp vias.
   • Via connected to -ve terminal of filter op-amp
     • updating ch18: 5 (This also passes somewhat close to the DAC reference via)
   • Via connected to output terminal of filter op-amp
     • updating ch18: 7, 10
   • Via to pre-buffer side of C1
     • updating ch18: 13
3. Not near the digital traces.
   • No digital traces near the chanel analogue vias/ components. However, the dac channel is in proximity to the updating dac. The crosstalk tends to be to DACs further back on the board than the updating DAC.
     • updating ch28: 26, 29, 31
     • updating ch18: 19
     • updating ch4: 5, 6, 7, 10
   • Differential pair passing immediatly underneath the updating DAC.
     • updating ch18: 20
     • updating ch4: 5, (ch7 runs underneath termination)

With the exception of the crosstalk from ch18 to ch5, all spurs I've encountered with -50dBmV or above are in group 1.

All in all, this seems like a bit of a complicated model for the amount of data I have...

[pathfinder49]

To test the patterns, I predicted and then measured update spurs for channels 6 and 25.

I made the following predictions:

Behaviour	Channel 6 updating	Channel 25 updating
Word dependent spur (DIN near via)	ch3, (ch5 unsure due to intermidiate DIN-via seperation)	ch11, ch14, ch17, (ch8 unsure due to intermidiate DIN-via seperation)
Spur present for 0x0000 (-10 V)	ch3 (CS near via), ch5 (SCLK near via)	ch17 (SCLK near via), (ch8, ch 11 and ch14 are unsure due to intermidiate SCLK-via seperation)

Note: I did not predict coupling from channel 6 to channel 1 as I missed the SCLK trace passing close to the buffer output via. I would also expect a (word independent) spur from this.

Channel 17 has the CMC slot populated.

Spur hights are tabulated below (spurs over -70 dBmV in bold):

Word	Channel 6 updating	Channel 25 updating
-9.5 V	ch1@-54 dBmV, ch3@-47 dBmV, ch5@-78 dBmV, ch6@-80 dBmV	ch8@-58 dBmV, ch11@-45 dBmV, ch14@-60 dBmV, ch16@-80 dBmV, ch17@-56 (-66 see edit 3)dBmV, ch18@-78 dBmV, ch19@-79 dBmV, ch20@-79 dBmV, ch23@-80 dBmV, ch25@-80 dBmV, ch26@-53 dBmV
0x0000 (-10V)	ch1@-54 dBmV, ch3@-43 dBmV (reproducibly more powerful?!?!)	ch8@-73 dBmV, ch11@-80 dBmV, ch17@-68 (-66 see edit 3) dBmV, ch23@-81 dBmV, ch26@-66 dBmV

Predictions for channel 25 updates, correctly identified prominent spurs and their behaviour. The unpredicted coupling to channel 26 fits point 3 above.

Predictions for channel 6 updates were less successful. Channel 3 was correctly identified. Channel 1 makes sense (though not predicted). Coupling from the CS line seems to behave oddly. It's unclear why no spur is seen in ch5.

Edit: looking through the data and routings again, it may be that the posititive via of the differential pair is more succeptible than the negative via. I'll look for suitable channel combinations to test this hypothesis.

Edit 2: Modifying channel 26 by de-soldering R67 and connecting to C101 makes no diffference.

Edit 3: Removing the CMC from channel 17 makes a significant difference here. Without the CMC (R66 & R67 populated) the ch17 spur (channel 25 updating) becomes -66dBmV. This is for both the -10 V and -9.5 V words.

[pathfinder49]

I've studied some channels in more detail. This suggests:

1. Digital noise can come from SCLK, CS or DIN traces. LDAC is held static in my tests. I'd anticipate this behaving similarly to the CS trace.
2. Digital noise couples in from vias, not pads.
3. With R67 populated the negative output differential pair via is not sensitive to crosstalk. When removing R67 and using a CMC instead, this via is sensitive.
4. Most crosstalk to channels in the vicinity of the updating dac is caused by the digital trace termination.

[pathfinder49]

I've summarised my findings in #62