Introduction to MDIO:

Management Data Input/Output (MDIO), or Media Independent Interface Management (MIIM) is a serial bus protocol defined for the IEEE 802.3 standard Ethernet series of Media Independent Interface (MII). MII connects media access control (MAC) devices to Ethernet physical layer (PHY) circuits. The SMI/MDIO protocol is a simple two-wire serial interface that connects the management unit to the managed PHY to control the PHY and capture the status of the PHY. The Management Data Input/Output (MDIO) component can be used to read and write the PHY control register. Each PHY can be monitored before operation and the connection status can be monitored during operation. These registers provide status and control information such as link status, speed ability, and selection, power down for low power consumption, duplex mode (full or half), auto-negotiation, fault signaling, and loopback. The main purpose of using MDIO protocol is to configure the PHY layer transceiver parameters, for example, PHY devices can perform pre-emphasis or de-emphasis in the Physical Coding Sublayer (PCS), programming the control status registers in the PHY layer.

MDIO is a bidirectional shared bus structure that can provide a connection from the MAC (master) up to 32 PHY (slave) devices. All data is synchronously transmitted through the Management Data Clock (MDC), which is provided by the MAC and sent to all receiving devices. The data line is a tri-state shared bus that is MAC controlled for a write transaction or PHY controlled during a read transaction. The MDIO interface clock (MDC) supports frequencies up to 2.5MHz. The host processor, which is responsible for system configuration and monitoring, usually uses the MDIO host to perform individual access to various devices. MDIO was originally defined in Clause 22 of IEEE 802.3. To meet the growing needs of 10 Gigabit Ethernet devices, clause 45 of the 802.3ae specification is introduced.

MDIO System:

The MDIO bus has two signals: management data clock (MDC) and management data input/output (MDIO). MDIO has specific terms to define various devices on the bus. The device driving the MDIO bus is identified as a station management entity (STA). Target devices managed by MDC are called MDIO manageable devices (MMD). STA initiates all communications in MDIO and is responsible for controlling the clock on MDC. The specified frequency of MDC is up to 2.5 MHz. The following Figure captures the interface wiring diagram of a typical MDIO system.

Figure 1: Wiring diagram of a typical MDIO Application.

MDIO (SMI Protocol) Features:

• MDIO protocol has a configurable physical address.
• MDC (clock bus) is specified to have a frequency of up to 2.5 MHz.
• Capability added to address more registers–up to 65,536 registers in each device.
• Variable MDIO speeds and duty cycle.
• Power down for low power consumption.

MDIO Protocol Frame Format:

CLAUSE 22:

Figure 2: Clause 22 Frame format.

The MDIO data format for clause 22 is defined in the IEEE 802.3 Ethernet standard, as shown in the figure above.

Preamble (PRE): The first field in the MDIO protocol is indicated with Preamble. When the Preamble is sent, the MAC sends all bits as 1’s in the MDIO line. The 32 bits in the preamble are always 1’s.

Start (ST): The preamble is succeeded by the start bit which is 2 bits in size that remains 01 always in clause 22 for both read or write operations.

Opcode (OP): The next field is the opcode which gives information about whether a read or write operation is to be performed. Opcode with the value of ‘01’ in the frame specifies the write operation. Similarly, Opcode with the value of ‘10’ in the frame specifies read operation.

Physical Address (PHYAD): This field contains a 5-bit PHY address.

Register Address (REGAD): This field is 5 bits long indicating the register to be written or read from.

Turn Around (TA): The Turnaround field is 2 bits in size. When data is written to the PHY, the MAC will write “10” to the MDIO bus. When reading data, the MAC releases the MDIO bus.

Data: This field is 16-bit wide. During the read instruction, the PHY chip writes the data read from the REGAD register corresponding to the PHYAD in Data. During the write instruction, the MAC writes the value of the REGAD register corresponding to the PHYAD in Data.

Idle: At this state, MDIO is driven to a high impedance state, but it is generally pulled up with the help of a pull-up resistor.

CLAUSE 45:

Since there are not enough registers for future use, there was a need for Clause 45 to meet the growing need for 10-bit gigabit ethernet devices. There was little scope to cater multi the device’s PHY layer.

In addition, to read and write in Clause 22, additional commands are added in Clause 45. Clause 45 added support for low-voltage devices down to 1.2V and extended the frame format to provide access to many more devices and registers.

The MDIO data format for clause 45 is defined in the IEEE 802.3 Ethernet standard, as shown in the figure above.

The advantages of clause 45 over clause 22 are as follows:

• Accessibility of 65,536 registers in 32 different devices across 32 different ports.
• Additional OP and ST code for indirect access to register address for 10 Gigabit Ethernet.
• Terminal fault signaling.  Multiple repeaters.
• Low voltage specification

Figure 3: Clause 45 Frame Format

Preamble (PRE): The first field in the MDIO protocol is indicated with Preamble. When the Preamble is sent, the MAC sends all bits as 1’s in the MDIO line. The 32 bits in the preamble are always 1’s.

Start (ST): The preamble is succeeded by the start bit which is two bits in size that remain 00 always in clause 45 for all operations.

Opcode (OP): The next field is the opcode which gives information on whether a read or write operation is to be executed. Opcode with the value of ‘01’ in the frame specifies the write operation. The opcode with the value of 11 specifies the read operation. There exist additional two commands namely read increment and address. The read increment with opcode 10 does a read operation with the MMD device address incrementing after each access. The opcode with value 00 is to rewrite or reread DEV ADD’s address register.

Physical Address (PRTAD): This field consists of the 5-bit PHY address.

Device Address (REGAD): This field is 5 bits long indicating the registered address that must be written or read from.

Turn Around (TA): The Turnaround field is 2 bits in size. When data is written to the PHY, the MAC will write “10” to the MDIO line. When reading data, the MAC releases the MDIO bus to initiate driving read data if read operation.

Data: This field is 16-bit wide. During the read instruction, the PHY chip writes the data read from the REGAD register corresponding to the PHYAD in Data. During the write instruction, the MAC writes the value of the REGAD register corresponding to the PHYAD in Data.

Idle: At this state, the MDIO bus is driven to a high impedance state, but it is pulled up through a pull-up resistor of 1.5k ohm.

Theory of Operation:

The PHY devices require a preamble of 32 ones that must be sent by the MAC to PHY on the MDIO line. The register access consists of 16 control bits followed by 16 data bits. The control bits consist of 2 start bits, 2 bits for opcode or the type of operation (read or write), the PHY address (5 bits), the registered address (5 bits), and 2 turnaround bits. In a write instruction, the MAC provides the address and data. For a read instruction, the PHY receives from the MDIO stream during the turnaround, supplies the MAC with the requested register data, and then releases the MDIO stream.

When the MAC is driving the MDIO line, it must guarantee a steady value of 10 ns (setup time) before the rising edge of the MDC clock. In addition, the MDIO must remain stable for 10 ns (hold time) after the rising edge of the MDC. When the PHY drives the MDIO line, the PHY must provide an MDIO signal between 0 and 300 ns after the rising edge of the clock.

Therefore, with a minimum clock interval of 400 ns (max clock rate is 2.5 MHz), the MAC can safely sample the MDIO during the second half of the low clock cycle. The entire MDIO line is sampled on the rising edge of the clock except for the read operation. During the read operation, the MDIO line is sampled on the falling edge of the clock.

Figure 4: Theory of operation for clause 22.

Once the preamble is sent, the next two bits indicate the start operation. The start field is followed by a read or write operation. The corresponding PHY address is then sent on the MDIO line. The registered address of the PHY is then sent to the MDIO line. Both the addresses are 5 bits wide. During the turnaround, When the data is written to PHY, the MAC sends “10” indicating the line is free for the data to be written.

During the read operation, The MAC releases the MDIO line. The data is sampled during the read operation on the falling edge of the clock. If there is a mismatch with the PHY address, The value after the TA field will be continuously high. This means to say that MAC is trying to write to the register that does not exist.

Since there is a limit to using only 5-bit addresses for both PHYADDR and REGADDR, it limits the number of MMDs the STA can communicate with. Also, MDIO clause 22 only supports 5V tolerant devices and there is no low voltage option.

The main change in Clause 45 is how the registers are accessed. In Clause 22, both the address and read or write data are specified in one frame. Clause 45 changes this paradigm. First, an address frame indicating the MMD and the register is sent. Then a second read or write frame is sent.

An advantage of adding this two-cycle access is that clause 45 is backward compatible with clause 22, allowing the devices to communicate with each other. Second, by creating an address frame, the register address space is increased from 5 to 16 bits, which allows the STA to access 65,536 different registers. For this purpose, various changes have been made to the composition of the data frame. A new opcode (00) is defined to identify the data frames according to clause 45.

The OP codes have been extended to define an address frame, a write frame, a read frame, or an incremental read and post-read address frame. Since the registered address is no longer needed, this field is replaced with DEVADDR to indicate the type of target device. The extended device type allows the STA to access other devices in addition to the PHY.

SMI/MDIO Protocol Challenges in Debug:

The MDIO Protocol Analyzer (PGY-MDIO-EX-PD) is a device that captures the data from the host and is designed under test. PGY-MDIO-EX-PD is a leading tool that enables the design and test engineers to evaluate the respective MDIO designs for their specifications by configuring the PGY-MDIO-EX-PD as a primary/secondary device, generating MDIO traffic and decoding the MDIO protocol decode packets.

Figure 5: MDIO Protocol Analysis for clause 22 using PGY-MDIO-EX-PD

PGY-MDIO-EX-PD can generate traffic by adding a master or a slave device and then helps in decoding the packets with error injection capability. Users can easily select the clause with the help of a Graphical User Interface (GUI). PGY-MDIO-EX-PD provides an option to generate traffic through predefined scripts. The user can also configure the PHYADDR and REGADDR.

Users can capture protocol activity at specific events and decode the transition between the master and the slave. The decoded results can be viewed in the timing diagram and Protocol listing window with autocorrelation. This comprehensive view of information makes it the industry’s best, offering an easy-to-use solution to debug the MDIO protocol activity.

Figure 6: MDIO Protocol Analysis for clause 45 using PGY-MDIO-EX-PD

The timing view provides the plot of MDC and MDIO signals with a bus diagram. Overlaying of Protocol bits on the digital timing waveform will help easy debugging of Protocol decoded data. Cursor and Zoom features will make it convenient to analyze Protocol in the timing diagram for any timing errors. The protocol window provides the decoded packet information in each state and all packet details with error info in the packet. Selected frames in Protocol listing window will be auto-correlated in the timing view to view the timing information of the packet.

SMBus Protocol Introduction:

The System Management Bus (SMBus) is a two-wire interface through which various system component chips and devices can communicate with each other and with the rest of the system. It is based on the principles of operation of the I2C bus. SMBus provides a control bus for system and power management-related tasks.

SMBus is commonly used in personal computers for smart batteries, temperature control, and other low bandwidth system management communication. The original purpose of the SMBus was to define the communication link between an intelligent battery, a charger for the battery, and a microcontroller that communicates with the rest of the system. However, SMBus can also be used to connect a wide variety of devices including power-related devices, system sensors, inventory EEPROMs, communications devices, and more.

SMBus technology is used in Smart Battery Systems, or SBS, which is often implemented in portable devices such as laptop computers, mobile devices, and cameras for efficient battery management. Smart Battery Systems consist of a host, smart charger, and smart battery and use SMBus for these components to communicate with each other and the rest of the system. Smart Battery Systems are often beneficial to the battery life in portable devices. By using SBS, the battery can inform the charger about multiple aspects, including its capacity, ideal charging current, maximum charging time, and much more. Plus, because there is more precision with these variables, a Smart Battery doesn’t require recharging as frequently.

SMBus vs I2C:

• I2C defines input voltage levels as percentages of VCC, while SMBus operates with fixed input voltage levels. The I²C and SMBus specifications also specify the logic input threshold voltages, VIL and VIH, differently. The I²C specification requires that VIL be 30% of VDD and that VIH be 70% of VDD. The SMBus V3.0 specification has fixed thresholds. VIL is set to 0.8 V and VIH is set to 1.35 V.
• SMBus requires a minimum bus clock frequency of 10 kHz (Except when the bus is idle). I2C has no such requirement. The maximum frequency of SMBus is 100 kHz, which equals the maximum speed of I2C operating in standard mode.
• In I²C bus specification, the master may hold the clock line low forever and that would be a valid condition. In addition, the I²C specification permits a slave device to hold the clock line low for an unlimited amount of time. The SMBus specification places limits on the maximum amount of time a master may extend the clock low time within each byte of a message. There is also a limit on the total time a slave device may extend the clock low time within each message.
• The I²C specifications do not require that a device always acknowledge its address. This can confuse a system controller whether it is because the device is busy, has failed, or has been removed. To prevent this confusion, the SMBus specifications require that an SMBus device always acknowledge its address. If a device that did acknowledge its address fails to do so the system controller, then knows that the device has either failed or has been removed.
• For applications where power usage must be minimized, such as in battery-operated systems, the SMBus specification has a Low Power class. I²C does not have a similar specification.

SMBus Protocol Frame Format: 

Two unique bus situations define a message START and STOP condition.

1. A HIGH to LOW transition of the SMBDAT line, while SMBCLK is HIGH, indicates a message START condition. 
2. A LOW to HIGH transition of the SMBDAT line while SMBCLK is HIGH defines a message STOP condition. START and STOP conditions are always generated by the bus master. After a START condition, the bus is busy. The bus becomes idle again after a certain time following a STOP condition. 

After the START condition (“S”), the master places the 7-bit address of the slave device it wants to address on the bus. The address is 7 bits long followed by an eighth bit indicating the direction of the data transfer (R/W#); a ZERO indicates a transmission (WRITE) while a ONE indicates a request for data (READ). A data transfer is always terminated by a STOP (P) condition generated by the master.

Every byte consists of 8 bits. Each byte transferred on the bus must be followed by an acknowledge bit. Bytes are transferred with the most significant bit (MSB) first.

The acknowledge-related clock pulse is generated by the master. The transmitter, master, or slave releases the SMBDAT line (HIGH) during the acknowledged clock cycle. To acknowledge a byte, the receiver must pull the SMBDAT line LOW during the HIGH period of the clock pulse. A receiver that wishes to NACK a byte must let the SMBDAT line remain HIGH during the acknowledged clock pulse. An SMBus device must always acknowledge (ACK) its address. SMBus uses this signaling to detect the presence of detachable devices on the bus. An SMBus slave device may decide to NACK a byte other than the address byte in the following situations: 

• The slave device is busy performing a real-time task, or the data requested are not available. The master upon detection of the NACK condition must generate a STOP condition to abort the transfer. Note that as an alternative, the slave device can extend the clock LOW period within the limits of this specification to complete its tasks and continue the transfer. 
• The slave device detects an invalid command or invalid data. In this case, the slave device must NACK the received byte. The master upon detection of this condition must generate a STOP condition and retry the transaction. 
• If a master receiver is involved in the transaction it must signal the end of data to the slave transmitter by generating a NACK on the last byte that was clocked out by the slave. The slave transmitter must release the data line to allow the master to generate a STOP condition. 

SMBus Protocol Theory of Operation:

The SMBus specification refers to three types of devices: host, master, and slave.

• A host is a specialized master that provides the main interface to the system’s CPU.
• A master is a device that issues commands, generates the clocks, and terminates the transfer.
• A slave is a device that receives or responds to a command.

Each device that exists as a slave on the SMBus has one unique seven-bit address called the slave address. Each address is seven bits long with a read/write bit appended in bit position 0. When a device “sees” its address, it wakes up and responds to the rest of the command. Besides the General Call Address, SMBus systems can have 127 devices.

A typical SMBus device will have a set of commands by which data can be read and written. All commands are one byte long while their arguments and return values can vary in length. Accessing a command that does not exist or is not supported may cause an error condition. By the SMBus specification, the most significant bit (MSB) is transferred first. 

All the commands first put a start condition on the bus, then begin the transmission by transmitting the command/data, wait for an acknowledgment from the slave (receiving) device during command/data transmission, and then put a stop condition on the bus.

Following is a description of some basic SMBus command protocols:

Quick command—The R/W bit in the slave address denotes the commands. An example of using it is to turn it on/off or to enable/disable a device function. There is no data sent or received.

Send byte—The data byte sent contains the features to be accessed and actions for this feature to execute.

Receive byte—The Receive byte is like a Send byte; the only difference is the direction of data transfer. The Receive byte is used when the host accesses the device for some information.

Packet Error Checking 

The Packet Error Checking mechanism improves reliability and communication robustness. Packet Error Checking, whenever applicable, is implemented by appending a Packet Error Code (PEC) at the end of each message transfer. Each protocol (except for Quick Command and the host notify protocol) has two variants: one with the Packet Error Code (PEC) byte and one without. The PEC is a CRC-8 error-checking byte, calculated on all the message bytes (including addresses and read/write bits). The PEC is appended to the message by the device that supplied the last data byte.

Synchronization

A situation may occur in which more than one master is trying to place clock signals on the bus at the same time. The resulting bus signal will be the wired-AND of all the clock signals provided by the masters. A high-to-low transition on the SMBCLK line will cause all devices involved to start counting off their LOW period and start driving SMBCLK low if the device is a master. As soon as a device finishes counting its LOW period it will release the SMBCLK line. Nevertheless, the actual signal on the SMBCLK may not transition to the HIGH state if another master with a longer LOW period keeps the SMBCLK line LOW. In this situation, the master that released the SMBCLK line will enter the SMBCLK HIGH wait period. When all devices have counted off their LOW period, the SMBCLK line will be released and go HIGH. All devices concerned at this point will start counting their HIGH periods. The first device that completes its HIGH period count will pull the SMBCLK line LOW and the cycle will start again.

Arbitration

A master may start a transfer only if the bus is idle. One or more devices may generate a START condition within the minimum hold time resulting in a defined START condition on the bus. 

Since the devices that generated the START condition may not be aware that other masters are contending for the bus, arbitration takes place on the SMBDAT line while the SMBCLK is HIGH. A master that transmits a HIGH level, while another master (or masters) is transmitting a LOW level on the SMBDAT line loses control of the bus in the arbitration cycle.

This mechanism requires that SMBus master devices participating in an arbitration cycle monitor the actual state of the SMBDAT line during the arbitration.

ABOUT THE AUTHOR

Anuj is an FPGA Design Engineer at Prodigy Technovations. He graduated from NMAM Institute of Technology with a bachelor’s degree in Electronics and Communication Engineering. He has hands-on experience in debugging and fixing hardware issues reported during product development and has rich experience in resolving customer issues during product evaluation.

Prodigy’s SMBus Protocol Exerciser and Analyzer

SM Bus Serial bus interface has been widely used for voltage and temperature monitoring of the system. PGY-SMBus-EX-PD is the leading instrument that enables the design and test engineers to test the SM Bus designs for its specifications by configuring PGY-SM Bus -EX-PD as master/slave, generating SM Bus traffic with error injection capability and decoding SM bus Protocol decode packets.

What is CAN protocol?

The Controller Area Network (CAN) is a serial communications protocol that supports distributed real-time control with a very high level of security and efficiency. 

Where is CAN Protocol Used?

CAN is extensively used (but not restricted) in the automotive industry for automotive electronics precisely in the engine control units (ECUs), for various applications involving sensors, anti-skid systems, etc. The numerous ECU functions used in an automotive vehicle are managed by microcontrollers. To establish communication between the microcontrollers and devices with each other’s applications without needing a host computer, a bus architecture known as CAN is robustly designed. 

How does CAN communicate?

CAN is a message-based protocol and for each device, the data in a frame is transmitted sequentially. The message onto the bus is transmitted serially using a Non-Return-to-Zero (NRZ) format. 

CAN Protocol: Theory of Operations

Bit rate: The bit rate of a CAN bus in a given system is uniform and ranges up to a maximum of 1 Mbps (excluding CAN-FD). CAN-FD could have a variable bit rate in a given system and ranges up to a maximum of 5-8 Mbps.

Broadcast: CAN is a broadcasting type of communications protocol, in which the concept of ‘Master’ and ‘Slave’ is not present. Any device having an update over a specific activity from any application could transmit the corresponding frame and every other device on the bus could read this frame.

Arbitration: Since CAN is a broadcasting type of communication protocol, multiple devices tend to communicate at the same time. During such a condition, conflict on the bus is inevitable. To solve this type of problem, bitwise arbitration is adopted. Whichever device wins the arbitration, gets to communicate and others back off.

Error Detection: All CAN nodes are implemented with powerful measures for error detection, signaling, and self-checking, and these measures are:

• Monitoring (the bit levels of the data to be transmitted will be continuously compared by the transmitter with the bit levels detected on the bus).
• Cyclic Redundancy Check (CRC) – CRC is adopted to ensure that the data in the frame is received flawlessly.
• Bit stuffing – After every 5 consecutive homogeneous bits a bit with an opposite polarity is introduced. This is called bit stuffing.

Now let’s get into the CAN frame formats and the way they look.

CAN Frames Format :

The message transfer is done through four types of frames, and they are: 

Data frames: Carries the data between transmitter and receiver

Remote frames: A bus unit can request the transmission of a data frame with the same Identifier by sending this remote frame to the transmitter.

Error frames: When a bus error is detected, an error frame is transmitted.

Overload frames: An overload frame is transmitted to provide an extra delay between frames (a standard amount of delay is provided by Interframe space) during multiple frames transmission.

Each Data frame and Remote frame has two different types of frame formats, and they are, Standard frame and Extended frame.

Alright, pictures speak more than words! Let us show the frames

These fields are the same for both Data and Remote frames. The next fields are shown in the below figure.

After all these fields, it is the End-of-Frame field which consists of seven consecutive 1’s, indicating the end of transmission.

Seven consecutive 1’s? What about bit stuffing then?

Well, bit stuffing is done only till the CRC-Delimiter field. The remaining fields are fixed in a frame. Hence, no bit stuffing is done to the Acknowledgement field and End of frame field.

Okay, now what’s the difference between the Standard frame and the Extended frame? As well as between the Data frame and Remote frame?

One at a time; The only difference between Standard and Extended frames is that the identifier is of 29-bits in Extended frames whereas, 11-bits in Standard frame formats. The 29-bits are categorized into two ID fields, first, 11-bits are as same as in the Standard frame and next 18-bits in another field. The below figure shows the difference between the two frames.

The SRR field is Substitute Remote Request, and it is transmitted as recessive.

Well, now with the Data frame and Remote frame. A data frame is shown in the above figure. The remote frame is the same as the Data frame except that the Data field is not present. So, it comprises of SOF, Arbitration field, Control field, CRC field, ACK field, and EOF. 

Great! Next, what’s with that CAN-FD?

CAN-FD stands for CAN Flexible Data Rate. This was introduced to increase the bandwidth on the bus by increasing the bit rate. Meaning, the bit rate on a given system during the frame transmission could change to a higher speed.

Oh, that’s nice! What about the frame structure?

CAN-FD has a similar frame structure to that of normal CAN, and two different types of frame formats as that of normal CAN, standard and extended frames, but there are no Data frame and Remote frame concepts here. The below figure gives a clear idea about the same.

The only fields that are different from normal CAN are, EDL, BRS, and ESI

The CAN FD extended frame format consists of a 29-bit identifier and an SRR field which is recessive one bit. And the rest of the fields remain the same as that of the CAN FD standard frame format.

CAN Protocol Challenges in Debug

Well, the challenges during the debug are:

1. Identifying different types of errors on the CAN bus
2. Capture time for long data bytes and error checking for the same

Debugging CAN Protocol

To Debug CAN Protocol we need a very good protocol analyzer. Prodigy’s CAN Protocol Analyzer is capable of decoding every field in the frame and providing the user with the necessary information related to timing and data. The user can see this piece of information through the software UI.

The user can also set triggers for different conditions through the software GUI. The analyzer is then capable of triggering all the error conditions on the bus as well as at different fields in the CAN frame as set by the user. The analyzer constantly analyzes the bus for any errors and if found any, it reports, and this can be seen in the software UI.

The analyzer also checks for the CRC on the bus. Meaning, it receives the frame from the CAN Transmitter, decodes it, and calculates the CRC at its end. It displays the calculated CRC and the received CRC and throws an error if the comparison does not match. All this information can be viewed in the software UI.

The software is working in tandem with the hardware (Protocol Analyzer) and thus, the settings made through the GUI will be updated to the hardware and the analyzer then works accordingly.

Learn more about CAN Protocol Analyzer

About the Author :

Sumukha Bharadwaj is an FPGA Design Engineer at Prodigy Technovations. He graduated from the K S School of Engineering and Management in 2015 with a Bachelor’s degree in Electronics & Communication Engineering. He also completed his Master of Engineering, Information Technology from SRH Hochschule Heidelberg.

About Prodigy Technovations :

Prodigy has developed state of the art Protocol analyzer to debug various Protocols. The protocol analyzers range from CAN, I2C, SPI, QSPI, I3C, and UFS Plus many other protocols on the serial bus.