Though oscilloscopes are most known for viewing and diagnosing analog signals, there are some cases where critical characteristics of digital signals can only be viewed on an oscilloscope. When designing products, validating prototypes efficiently and accurately is a key step in making product deadlines. The various signals present on the device may lack critical properties, affecting the target specifications of the design.
Five Features of Digital Logic Signals That Can Be Viewed on an Oscilloscope
Here are a couple of characteristics of these digital signals that a scope is useful in diagnosing:
Logic Thresholds are Met
If your digital signal can’t reach a threshold, a voltage level at which a signal is read as a “1” or a “0”, of the logic standard you are using, then not only will connected devices not see the signal transitions, but a logic analyzer using the same logic standard will also not be able to catch those transitions. Consider the case that a pullup resistor network is incorrectly designed and pulls a signal that is supposed to read as a “1” below the input high threshold. A logic analyzer will see a “0” here, while an oscilloscope can tell you the voltage that it does manage to reach, valuable information for understanding why the functionality didn’t match your expectations.
Signal Doesn’t Under/Overshoot
When a digital signal transitions, the voltage level can temporarily exceed the stable high voltage, or go below the stable low voltage. In some scenarios, if this overshoot/undershoot is extreme enough, you could potentially damage your devices. As a critical spec, the electrical specifications for a digital device typically include information on the maximum voltage they can safely operate at. Part of the inspiration behind our devices) having a multitude of instruments in the time and frequency domain and designed for mixed signals is the experience we have designing our FPGA development boards.
As an example, below we can see a capture from one of our validation tests, for a clock signal being passed to an Ethernet PHY. Here, the signal thresholds are explicitly being measured to ensure that they correspond to the specifications of the devices, and that the thresholds are never passed while the signal is in the high or low part of the cycle (another possible byproduct of over/undershoot).
Rise and Fall Times
Similarly, the digital devices in your circuit expect the signals they take as input to rise and fall in specific periods of time. If a signal rises too slowly, some devices might have unexpected output, not knowing how to interpret a voltage somewhere in the middle. If the signal is fast, or the rise/fall time of the signal is egregiously slow, you can even lose the ability to detect transitions at all, if a “sawtooth” waveform is created by the charge/discharge cycle. For example, an unexpected source of capacitance can cause your signals to slow down. The best way to find out if this kind of thing is happening is to check for it on an oscilloscope.
As another example, another validation test looks at the input hold time of a SPI signal – how long the data signal waits to transition after the positive edge of the clock used to sample it. In this case, a slight reflection effect can be seen in the data signal’s rising edge (blue line), which is having an effect on the measured time (but is not bringing the signal out of spec).
Reflections Due to Unadapted Termination
When you run a signal down a long cable, the signal can reflect off the other end, and in returning, interfere with further signals coming down the same line. This interference can easily lead to several of the issues mentioned above – interference that causes the signal to temporarily stay lower than an input high threshold increases the rise time, for example. This doesn’t just apply to “long” cables, and also comes up when you have a short cable (or even a trace on a printed circuit board) and a fast signal. While this can be corrected with a load at the end of the cable or trace (adding a termination impedance), issues will still arise if the impedance was incorrectly selected. They can be detected with a scope. (informative video – Reflected Waves on a Cable)
Noise in a signal can just cause problems and viewing it and measuring it in both the time and frequency domains is an important step in diagnosing the source. A classic example of noise is button bounce: when pressing a button causes the voltage to repeatedly rise and fall for a short period before settling at its final state. While this can often be caught by a logic analyzer, the scope gives more detail on the situation – what appears as a series of toggles on a logic analyzer may be hiding more complex behavior that can be seen with a scope, slow ramp up over time, short glitch pulses, or other transient waveforms. You can even mitigate button bounce with analog circuitry. This is just one of the many sources of noise.
Finally, for visual reference, an example of a noisy button bounce:
Part of the inspiration behind our devices having a multitude of instruments in the time and frequency domain and being designed for mixed signals is the experience we have designing our FPGA development boards. Fundamentally, even if the thresholds and logic standards differ, a logic analyzer accepts signals the same way that any other digital device does, and can’t diagnose that arise from the analog properties. Logic analyzers are of course a wonderful tool for looking at your already nice-and-clean digital signals to ensure that they are sending the right data, but an oscilloscope is also invaluable. Having a mixed signaled oscilloscope (like the ADP3450) will give you both.
2 Comments on “When Digital Becomes Analog: A Story of Mixed Signals”
Darn! Here I thought you were referring to Apple’s Logic music software program!
Hi Arthur, an excellent post indeed. As clock rates increase, we have to contend with RF type effects on boards. Here’s where sampling rate specifications and rise time matters.