Why are there so many serial bus types? The answer involves cost, speed, EMC considerations, resiliency, reliability, the need for single/full duplex operation, and compatibility with other equipment. Technology and experience also affect bus design, influencing the level of complexity that is necessary and practical for a given application.
One advantage of serial communications is the minimal number of IC pins required. In general, separate hardware flow-control signals, such as initially defined for RS-232, are not part of modern buses. Instead, the medium access control (MAC) section within the OSI Data Link layer is used. For example, within the CAN bus, the MAC is responsible for message framing, arbitration, acknowledgement, error detection, and signaling.
To improve noise immunity, CAN automotive installations typically use twisted-pair wiring and a ground connection. As with other buses, special combinations of signal levels on the two wires are used to indicate start of frame (SOF) (both wires low) or as a delimiter (both high). Otherwise, the twisted pair is driven differentially. The meaning of the various strings of bits is defined by their positions relative to the SOF and the delimiters within the overall frame and by the type of frame.
CAN’s physical layer uses a carrier-sense, multiple access/collision detect scheme with arbitration based on message priority (CSMA/CD-AMP). Because the bus is a wired-AND structure with the high state (1) defined as recessive and the low state (0) as dominant, any node transmitting a 0 will control the bus. By monitoring the state of the bus, a node sending a recessive (1) level but sensing a 0 on the bus knows to stop transmitting.
In contrast, original Ethernet also used CSMA/CD but did not provide priority-based arbitration. Instead, all transmitting nodes stopped transmitting and waited a random amount of time before again attempting to access the bus. Modern Ethernet uses switches that partition the network, improving its resistance to faults caused by a broken wire. In addition, switches forward messages only to those nodes that can use the information.
The I2C bus also has a wired-AND configuration with two wires and a ground. For I2C, one wire is for data (SDA), and the other acts as a clock (SCL) although as with CAN, both signals high has special meaning—a start or stop condition in this case. Also similar to CAN, the wired-AND configuration of the SDA line provides arbitration among nodes simultaneously trying to transmit. For the SCL line, the wired-AND structure allows a receiver to stretch the SCL low state if the receiver is not ready to accept the next data bit.
Bus speed, reliability, complexity
High-speed CAN (ISO 11898) runs at speeds up to 1 Mb/s, but this has been increased to 8 Mb/s in CAN with flexible data rate (CAN FD). In addition to the higher speed, the maximum data length per frame has been extended from 8 bytes to 64 bytes. Sticking with a version of CAN makes sense in many cases for reasons beyond speed. Although often called synchronous, a CAN network doesn’t have exactly the same clock rate throughout. CAN is an event-driven protocol that synchronizes independent network clocks beginning with the start bit and repeating the process on each recessive-to-dominant transition in the frame.
The effective rate at each receiver is close enough to the nominal rate that transitions occur where they are expected. In particular, the 11-bit (CAN 2.0A) or 29-bit (CAN 2.0B) identifier field determines priority for arbitration. The same field lengths are used in CAN FD, which allows a much higher data transfer rate to be used after the arbitration process has been completed. This ensures that there is a greater noise margin during arbitration.
Higher speeds are available with FlexRay networks, a dual-redundant bus specifically aimed at safety-critical applications. FlexRay is a time-triggered architecture that’s important for real-time and deterministic applications such as drive by wire. These networks cannot operate in the same way as event-driven CAN. If an action is required but the receiver senses a frame error, the frame cannot simply be retransmitted as with CAN because to do so might overrun the timing required for the next action.
Clocking and EMC
Rather than specifying tight clock synchronization among nodes or providing a separate clock line, some protocols embed the clock with the data. Manchester encoding uses the direction of a transition at the center of the bit period to indicate a 1 or 0. Because there always is a transition at the center of each bit, it’s easy to recover the clock. However, the drawback is increased bandwidth.
MLT-3 is an alternative embedded clock scheme that is more complicated but has the advantage of requiring much less bandwidth. This scheme cycles among three levels: 0 V, +V, 0 V, -V, 0 V … or symbolically, 0, 1, 0, -1, 0. Rather than associating a specific level or change with an original NRZ data bit, MLT-3 only changes state when the NRZ data changes. So, if the NRZ data were 1, 0, 1, 1, 0, 1, 0, for example, and the MLT-3 output arbitrarily began at 0, the encoded values would be 0, 1, 0, 0, -1, 0, 1. To maintain a DC level close to zero, 4b-5b encoding also is used. That is, 5 bits are transmitted for every 4 NRZ bits, the fifth bit helping to correct the DC offset that may have accumulated.
ARINC 429 is an avionics bus that also uses a three-level scheme, but in this case there is a direct correspondence between the NRZ states and ARINC 429 states. A high NRZ 1 becomes a +V level, and a low NRZ zero becomes a -V level. Like Manchester encoding, there is a transition at the center of each bit period so the bus is self-clocking, but the data is represented by the level of the line during the first half of the bit period.
Test tools
As a quick look at a few buses shows, there is a lot of complexity associated with even fairly basic protocols. A specialized tool easily pays for itself in the time and errors it saves when you are working with serial buses. Compared with a protocol analyzer, a scope has the advantage of displaying both the analog waveforms as well as decoded digital values and their timing. Having the capabilities within one tool to decode serial bus activity as well as troubleshoot it has made scopes popular protocol analyzer alternatives.
Steve Barfield, general manager, Siglent Technologies America, explained, “All of the buses we support are triggered by hardware and decoded in software. The serial decode features are sold as options and can be ordered with the unit or later and are easily retrofitted to existing models.” Other than the time it takes to decode bus activity in software, it makes sense to handle complex protocol issues this way. Also, the approach makes it relatively straightforward to handle other buses in the future.
The company’s new SDS1000X family supports I2C, SPI, and UART applications while the SDS2000 family adds CAN and LIN buses (Fig. 1). As well as the usual analog trigger selections such as runt, pattern, and window, bus-specific trigger conditions also are provided. For I2C, the start and stop state, restart, missing acknowledge, 7 bits address and data, 10 bits address and data, and data length are all valid trigger conditions.
National Instruments recently has upgraded the multi-instrument VirtualBench product to include hardware-timed SPI/I2C mastering. This means you can program your VirtualBench instrument to exercise an SPI or I2C bus you need to test and, using the edge and pattern triggering, capture the packets of interest. Graham Green, senior project manager at the company, explained that users always have the ability to create their own custom software triggering and decoding functions that work with acquired data, hence the comment and ◆ symbol in Figure 1. However, currently there are no plans to support further hardware-timed extensions to the functionality.
The word “trigger” has gained added meaning in digital scopes beyond its original analog scope definition. In analog scopes, the trigger started the sweep—that’s all it did, as in Howard Vollum’s (Tektronix’s) first triggered-sweep scope in 1947. “Software triggering” implies pattern matching on data acquired using a scope’s hardware trigger capability. Acquisition criteria could be as broad as “trigger on any positive-going edge.” It’s then up to the software to sort out areas of interest. Of course, with software, there’s no limit to the protocol complexity that can be addressed once some data has been acquired.
Tektronix also provides serial bus triggering and analysis. For most buses, triggering is supported in hardware, leading to real-time capture. As Figure 1 shows, for a few buses, Tek uses software triggering—post-acquisition pattern matching. Hardware triggering is important because a high rate of frame capture improves your chance of finding an anomaly. Nevertheless, a software-based trigger is much more useful than not having a bus-specific trigger at all. And, as Tek’s Scott Davidson, product marketing manager, commented, software is very flexible and well-suited for data analysis.
Davidson said, “The analysis and automatic search capabilities are all done in software, providing flexible and powerful performance that can easily be updated at the customer site. For example, with the MSO/DPO5000B Series and other Tektronix performance oscilloscopes, the automated search can simultaneously scan the signal for up to eight different kinds of events and mark every instance of each event in the acquired waveforms. Such performance is not available in hardware-based solutions.”
Teledyne LeCroy offers an extensive range of options from trigger and decode support for individual buses through comprehensive generic high-speed 80-bit-deep NRZ trigger and decode. Generally, triggering is done in hardware and decoding in software with the provision that the bandwidth of the oscilloscope must equal the bit rate of the signal and the sampling rate must be four times the symbol rate. If those conditions are met, according to Bob Mart, product manager at the company, “All of Teledyne LeCroy’s serial trigger/decode packages run on all of our oscilloscopes.”
With Teledyne LeCroy’s generic High-Speed Serial Trigger and Decode option for NRZ rates up to 6.5 Gb/s or 14.1 Gb/s, hardware triggering can be extended to many bus types including DisplayPort, DVI, HDMI, FibreChannel, InfiniBand, and XAUI. Tektronix provides similar capabilities up to 6.25 Gb/s with the ST6G option for the company’s 70000 series scopes. Tek’s range of DSA scopes are special versions of the 70000 family bundled with options including ST6G, but this capability is an option on the 70000 MSO and DPO models.
Rohde & Schwarz recently announced the K50 option for R&S RTO and RTE Series scopes that provides a very flexible hardware trigger and decoding capability for Manchester- and NRZ-coded serial protocols up to a 5-Gb/s rate. In addition to protocols such as Profibus, Dali, and MVB, the option also can handle proprietary serial buses. The K52 option allows the R&S RTO oscilloscope to analyze 128-bit deep 8b-10b data at rates up to 6.25 Gb/s. This type of coding is found in USB 3.0 and PCIe interfaces as well as the MIPI M-PHY bus used in smartphones and display interfaces such as HDMI and DisplayPort.
Keysight Technologies, Yokogawa, and Rohde & Schwarz are in the minority by providing both hardware triggering and hardware decoding, although for supported protocols, this provides the fastest acquisition update rate and improves your chance of finding infrequently occurring faults.
GW Instek is the exception among the 10 scope companies included in this report because serial bus hardware triggering and software decoding are included as standard for the five supported protocols. Instek’s Roger Lee, application engineer, said, “… [we] equip the GDS-2000A/E scopes with standard triggering and decoding functions, including UART, I2C, SPI, CAN, and LIN bus that allow users to achieve serial bus triggering and decoding requirements without spending any extra costs on options.”
Although hardware gives the fastest performance, depending on how it has been implemented, extending the functionality to other protocols may not be easy. As an example, for Keysight’s 90000 Series scopes, additional capabilities are available in software. As stated on the company’s website for the N5414B InfiniiScan Event Identification Software, “… [this] software allows you to quickly and easily identify signal integrity issues in your electronic designs. This innovative software scans through thousands of acquired waveforms per second to help you isolate anomalous signal behaviors.”
NRZ patterns up to 80 bits long can be identified. In addition, a software trigger can be derived from acquired data via a measurement value, detection of a nonmonotonic edge, a runt condition, or interaction with up to four user-defined intersect/must-not-intersect zones.
As described by Trevor Smith, business development manager at Pico Technology, software decoding is used extensively for serial buses by the company’s PicoScope products. Rather than try to isolate specific trigger conditions in hardware to qualify the data prior to capture, Smith said, software search “… highlights those packets in long acquisitions that meet user-defined criteria.” Models in the 6000 Series have up to 2 GS of memory, so hundreds or even thousands of serial data packets can be acquired. Smith concluded, “The number of serial buses that can be decoded simultaneously is limited only by the number of channels on the specific PicoScope model. Decoding two or more channels is useful in many instances, for example, to view RS-232/UART full duplex data or to measure packet transit time across a LIN-to-CAN bridge.”
Software also figures in Rigol Technologies’ provision of serial bus decoding. Rigol’s Chris Armstrong, director of product marketing and software applications, said, “All of our bus decoding is done in firmware for the data captured on the display and in the record mode. Serial decode triggering includes digital pattern triggering across channels. Triggering on a decoded character or symbol in ASCII, binary, hex, or decimal allows engineers to investigate any data element.” Rigol has most recently bundled I2C, SPI, RS-232/UART, CAN, and FlexRay serial bus decoding for the MSO/DS4000 scopes as a special limited-time option.
In addition to those protocols shown in Figure 1, the Yokogawa DLM4000 MSO also provides a user-defined serial triggering function. You can specify the trigger state as up to 128 bits of NRZ data. However, the fastest bit rate of 50 Mb/s is only sufficient for protocols similar to those directly supported. Generally, the company’s test tools are well-suited to electromechanical applications, such as transportation, in which there could be a mix of power, sensors, control signals, and bus activity.
William Chen, product manager at Yokogawa Test and Measurement Division, described a moving vehicle test that needed to monitor at least four ECU signals along with sensor signals such as rotational speed, fuel-injector pulse times, crank angle, and CAN bus signals all in real time. He said, “The DL850EV Electric Vehicle ScopeCorder was a unique and complete solution to our client’s problems. Using flexible modular inputs with built-in signal conditioning, it combined the measurements of electrical signals, physical sensors (temperature, vibration/acceleration, strain), and CAN/LIN serial buses and is able to trigger on simple and advanced conditions in real time. An optional GPS input receiver on the DL850EV allowed the engineers to correlate and synchronize the vehicle action, ECU waveforms, and vehicle position data with high time precision.”
Further enhancement
Symbol decoding and the display of reconstituted analog waveforms are two software additions that significantly add to accuracy and insight. Rather than a listing indicating activity on address 7E, for example, if the user provides a suitable link file with corresponding signal names, the listing can display “brake pressure” or a similar application-specific variable name. As shown in Figure 2 and described by Pico Technology’s Smith, “Using a link file can help to speed analysis by cross referencing hexadecimal field values into human-readable form. The link file template with all field headings can be created directly from the serial table toolbar and edited manually as a spreadsheet to apply the cross reference values.” Several vendors offer this kind of feature.
Figure 3 shows a screenshot from a Yokogawa DL850EV ScopeCorder in which CAN bus data has been decoded and displayed as analog waveforms. Typically, a scope-like display showing a variable’s value vs. time is easier to understand than a list of data values.
Several manufacturers offer advanced applications that provide more detail about serial bus activity or that include the various test conditions specified by a compliance document. Tek’s Davidson said, “The MSO/DPO5000B and DPO7000C scopes support optional serial compliance testing and analysis for serial standards such as BroadR-Reach, Ethernet, MOST, USB 2.0, and USB HSIC. Because these sorts of analyses require parametric measurements on the underlying signals, they are very well suited for oscilloscopes.”
Finally, Teledyne LeCroy’s Mart commented about the company’s ProtoBus MAG serial debug toolkit. He said, “The ProtoBus MAG Toolset equips certain protocols … with decoders and a variety of data extraction, timing, and other measurement and graphing functionality. This toolset is the basic building block upon which many other Teledyne LeCroy serial trigger and decoder options can then be added, significantly extending the trigger and decode functionality … by providing tools for more complete and faster validation and debugging of embedded designs.”