DAC Essentials: How accurate is your DAC?

Other Parts Discussed in Post: DAC8562, OPA188, DAC8560

We’ve covered a lot of material in the DAC Essentials series, starting with a simple ideal digital-to-analog converter (DAC) all the way to complex problems, like reducing glitch. In this final post in the series, we’ll talk about total unadjusted error (TUE).

Precision DACs deliver excellent DC, or very low frequency, performance. In many precision DAC applications, the AC error specifications related to code transitions, glitch and slew rate, are negligible when defining the accuracy of the DAC. This is because the output will spend a majority of its time settled and unchanging.

In my “DAC Essentials: Static specifications & linearity” post, I explained all of the DAC DC error parameters: offset error, zero code error, gain error, differential non-linearity (DNL) and integral non-linearity (INL). When trying to express how accurate a DAC is at DC, it’s challenging to keep all of those error sources in mind. That’s the beauty of TUE. It gives you a single number that succinctly explains how accurate the DC DAC output is as a result of the sum of all of these error sources. The only catch is you have to do a little statistics.

In statistics, a technique called RSS, or root sum squared, is used to sum uncorrelated error sources for error analysis. With string and ladder DAC architectures, offset, gain and INL error come from different components of the DAC architecture. This means they’re uncorrelated, and the RSS technique is safe to apply, as seen in Equation 1.

Equation 1: RSS equation

You may have noticed that I didn’t include zero code error and DNL. That’s because zero code error only applies to a very small portion of the DAC output. For a 16-bit DAC, this might be a few hundred codes out of 65,536 total codes. DNL, meanwhile, is actually included in the error calculation via INL.


Data Converters Learning Center

 Whether you're designing with ADCs or DACs, visit our Learning Center to find the resource you need.

Now let’s go through a short example that shows how to calculate TUE. In Table 1, you see the datasheet maximum and typical specifications for the 16-bit, two-channel DAC8562.

  

Table 1: Specifications for the DAC8562

Each of the specifications for the DAC8562 are provided in different units, which is typical across the industry. To calculate TUE, everything needs to be in the same unit, so we’ll use the Table 2 to convert the values.

Table 2: Converted values for TUE

Once we’ve converted units, we can plug the values back into the TUE equation and calculate the total unadjusted error for the DAC8562.

Using the maximum values for all of the specifications provides what I refer to as the “probable maximum TUE” of +/-111 LSBs, +/-8.5mV, or 0.17% FSR. I say this because the max values in the datasheet are three-sigma figures that should encompass 99.7% of all parts ever produced. On a typical Gaussian distribution, these edge cases are not likely to happen. You’re even less likely to find a part that actually displays the maximum errors for all parameters (an “absolute maximum error” so to speak - the figure you would see from simply summing all of the errors together). Even this probable maximum TUE is a somewhat unlikely unit to observe.

Using the typical figures provides the most realistic estimation of what you’ll see from most systems. The typical TUE for the DAC8562, as seen in Figure 1, is +/- 23 LSBs, 1.78mV, or 0.0356% FSR. Check out this TI Precision Design to see this method in practice, and proven reliable, with real data on a real system.

Figure 1: Schematic with the DAC8560 and OPA188

Remember that these parameters also have direction associated with them. For a DAC with positive offset error, negative gain error would actually help make the system more accurate. This isn’t taken into account when you use RSS to sum the maximum errors. So in many cases, RSS on typical error figures still provides a pretty modest estimate of TUE.

While this post marks the end of the DAC Essentials series, you’ll find me blogging on other topics on The Hub, our blog focused exclusively on precision analog tips, tricks and design techniques.

And be sure to check out my new Engineer It video if you want to get some advice on how to select the perfect DAC for your system.

As always, leave your comments below if you’d like to hear more about anything mentioned in this post, or if there is something you would like to see included in a future post here or on The Hub.

 

Anonymous
Parents
  • Jim,

    I completely agree with your comments.

    When I started writing this post I was a little apprehensive about the reception that it might receive - to some extent I think the RSS could be considered "controversial" given the qualifications that are required for it's use (normal distributions and uncorrelated sources, as you mentioned). I've seen a few arguments come up around the topic of exactly what error sources are correlated and uncorrelated, especially within the discussion of integrated circuits and other discrete components, but I've found that the RSS technique is still pretty accurate even if you have to "fudge" a few sources into the uncorrelated bucket.

    I was also a little worried about the use of typical figures in my calculations. You're certainly correct that, in your case, using a min/max spec is probably for the best so that you can guarantee performance boundaries. It is tricky to manage the balance between absolute performance boundaries, probable performance boundaries, and selling your products short (since some of those absolute min/max bounds are not very likely to happen).

    The TI Designs I linked to also apply the RSS technique to an entire system. When I started writing these reference designs I needed some way to overcome not having a DAC model and I bumped into RSS. I use a combination of RSS, SPICE models, and Monte-Carlo analysis to come up with the bounds for performance in the reference designs and it's worked out pretty well (although my sample size is usually limited to 10-20 designs, not a very large population).

    Thanks for reading, and for your excellent comments!

Comment
  • Jim,

    I completely agree with your comments.

    When I started writing this post I was a little apprehensive about the reception that it might receive - to some extent I think the RSS could be considered "controversial" given the qualifications that are required for it's use (normal distributions and uncorrelated sources, as you mentioned). I've seen a few arguments come up around the topic of exactly what error sources are correlated and uncorrelated, especially within the discussion of integrated circuits and other discrete components, but I've found that the RSS technique is still pretty accurate even if you have to "fudge" a few sources into the uncorrelated bucket.

    I was also a little worried about the use of typical figures in my calculations. You're certainly correct that, in your case, using a min/max spec is probably for the best so that you can guarantee performance boundaries. It is tricky to manage the balance between absolute performance boundaries, probable performance boundaries, and selling your products short (since some of those absolute min/max bounds are not very likely to happen).

    The TI Designs I linked to also apply the RSS technique to an entire system. When I started writing these reference designs I needed some way to overcome not having a DAC model and I bumped into RSS. I use a combination of RSS, SPICE models, and Monte-Carlo analysis to come up with the bounds for performance in the reference designs and it's worked out pretty well (although my sample size is usually limited to 10-20 designs, not a very large population).

    Thanks for reading, and for your excellent comments!

Children
No Data