• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Custom IC Design
  3. Glitch

Stats

  • Locked Locked
  • Replies 3
  • Subscribers 126
  • Views 6283
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Glitch

VIRAJ PANCHAL
VIRAJ PANCHAL over 1 year ago

I design 6 bit digital to analog converter & I successful plot dac output but in my output there are some glitches....! so how to reduce these glitches...? 

  • Cancel
  • Andrew Beckett
    Andrew Beckett over 1 year ago

    I'm assuming you're not just asking how to filter the glitches from the output waveform - those look like serious issues with your design that you probably need to address (and advising on that is going to be hard without any insight as to your DAC architecture). Do you have a bank of registers on your input bus? If not, that would isolate you from timing differences in changes on the bits on the DAC input - but even then you'd need to take care.  Beyond that, it's just guesswork, and probably reading some literature on DAC designs would be wise.

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • ShawnLogan
    ShawnLogan over 1 year ago in reply to Andrew Beckett

    Dear VIRAJ PANCHAL,

    VIRAJ PANCHAL said:
    so how to reduce these glitches...? 

    A quick look at your DAC transient response suggests that the "glicthes" you are observing are likely a result of the sequential decoder logic used to drive its switches and the topology of your DAC. Why do I suggest these?

    The largest glitches are present at the major code transitions in your binary DAC. Specifically, note they occur at times of 16 sec, 32 sec, and 48 sec. These are all times where the binary code undergoes a high-order bit transition:

    At 16 sec,

    Code 48: 0011 0000

    Code 47: 0010 1111

    ...32 sec...

    Code 32: 0010 0000

    Code 31: 0001 1111

    ...48 sec...

    Code 16: 0001 0000

    Code 15: 0000 1111

    Hence, in what appears to be a binary DAC of some type, at code 48, the time it takes for the significant bit 5 to turn off and the time it takes for the 4 lesser order bits to turn on are significantly different. Therefore, when you make the code transition, a combination of the more significant bit 5 AND the 4 lesser order bits are on for the same time leading to a much higher DAC output until the more significant bit 5 is totally off and its lesser 4 bits are totally on.

    To a lesser extent, this same phenomena is responsible for the DAC output responses at the other binary transitions.

    To eliminate the effect, the propagation time required for both any combinational/sequential logic driving your bit switches and the bit switch must be same for all code transitions. Hence, when you change from one input code to another input code, the time required for each analog switch to turn on or off is the same.

    On method to minimize the mismatch in timing for any combinational logic driving your analog switches is to use a parallel latch to align the outputs of your combinational logic with a clock edge after the combinational logic has settled. The outputs of the parallel latch will have minimum skew between them (assuming they all drive similar loads) and are used to drive the analog switches in lieu of the combinational logic itself.

    A second issue I see in your transfer curve is the linearity of your DAC. I note that at the major bit transitions I outlined above, the step size is significantly different than at other code transitions (see your annotated figure in Figure 1). This is a result of matching between your lower order bits and the upper order bits and common in a DAC with binary weighted segments.

    Hence, although a binary DAC is attractive from an area and implementation perspective, the topology is rarely used for DACs of any significant size. Often a DAC is designed using one or more thermometer coded sub DACs  to eliminate or minimize monotonicity and glitch isses. The use of a thermometer code eliminates the code dependent glicthes as only a single bit its turned on or off at any given code transition. You may need to include a binary to thermometer converter if the digital interface must be binary coded. Its logic must be synchronized to make sure the propagation delays for any code transition are very well matched.

    There are many, many references available to help you understand and consider design alternatives in light of your specific requirements. I cannot include the URL to non-Cadence references in my response as it will be classified as spam. However, a quick search suggest this reference might be helpful as only one example.

    You might also consider the technical resources available from well known ADC/DAC manufacturers such as Analog Devices or Texas Instruments.

    Shawn

    Figure 1

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • VIRAJ PANCHAL
    VIRAJ PANCHAL over 1 year ago in reply to ShawnLogan

    Thank you for reposed.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information