Understanding Advanced Interconnect IP Peripherals for IoT and Automotive SoCs

Introduction

Interface standards are evolving and design requirements for low-power, high-performance applications in growing markets such as the IoT and automotive are driving the need for more advanced interconnect IP peripherals. Today, robust and proven peripherals including I2C, synchronous serial interface (SSI) and UART are seeing resurgence in design use. This article describes the DesignWare IP® for ARM® AMBA® APB™ Advanced Peripherals and highlights the key updates to three of its commonly-used peripheral components: UART for the AMBA 2 APB bus (DW_apb_uart), synchronous serial interface (DW_apb_ssi) and I2C device with APB target interface (DW_apb_i2c).

UART for the AMBA 2 APB bus (DW_apb_uart)

The DW_apb_uart is modeled after the 16550 UART standard. However, the register address space is relocated to 32-bit data boundaries for advanced peripheral bus (APB) implementation. The DW_apb_uart can be configured, synthesized and verified using the Synopsys coreConsultant GUI and is used for serial communication with peripherals, modems and data sets.

9-bit and RS485 Support

A system like a distributed monitoring application consists of a multi-drop network – a PC acting as a Host to communicate, and micro-controllers acting as Targets. The physical layer for this particular network often uses the RS485 standard, while the application/logical layer consists of user-defined protocols. The RS485 standard specifies the physical layer and not the speed and communication protocol of the data transmission. While only specifying electrical characteristics of the transmitter and receiver, the RS485 standard is also used as the physical layer for many communication protocols including the most common versions of ModBus or process field bus (ProfiBus). For integration into systems for which an RS485 interface is required, the DW_apb_uart can be configured for a software-programmable RS485 mode.

In a ModBus or ProfiBus communication, the device receives, searches and identifies an address byte which is part of the serial data. Every Target device is interrupted constantly, wasting valuable CPU time. To overcome this issue, the 9-bit serial data transfer protocol is used. In the 9-bit protocol, in addition to the 8-bit data, there is a 9th bit that detects the address on the bus. If a character with a 9th bit set in the data stream is presented to all the Targets, then all the Targets devices are interrupted to decode the address byte and check whether it is intended for its use. From then on, the Host transfers zero characters with 9th bit set. Therefore, only the devices that are selected will start to accept the data bytes, and all other devices will be in idle mode and ignore the characters until a new address is presented, saving CPU time. Typical use cases for this are shown in Figures 1 and 2.

The DW_apb_uart supports data transfers for both RS485 and 9-bit modes, enablingRS485 compliance with and without 9-bit modes. The user also has the flexibility to carry out the operations in RS485 for full-duplex and half-duplex traffic. In the 9-bit mode, users have the flexibility to auto-match the address or let the application to model the same. This is summarized in the following table:

Fractional Baud Rate Support

A UART is an asynchronous mode of transmission between two serial communication devices. UART baud rates are of standard values such as: 9600, 19200, 38400, 57600, 115200 and 1843200 baud.

With the ever increasing need for the lower clock frequencies and with more reliable communication lines like RS422 and RS485 compared to RS232, the standard UART baud rates is no longer used exclusively. Applications now demand baud rates beyond the standards. The use of these baud rates still needs to ensure that the percentage error (drift) is well within the acceptable limits.

With an integer baud rate clock divider, the achievable percentage error might become unacceptable over the period of time. This is where the need for the fractional baud rate features is used. The fractional baud rate clock divider gives the flexibility of using the fractional part of the baud to achieve lower clock frequencies with minimal percentage error.

DW_apb_uart supports the fractional baud rate generation with a minute level of granularity for the fractional part. The provision has been provided for the user to skip the fractional generation if needed. The waveforms below show the fractional baud generation with a fractional division over 16 clock periods.

Synchronous Serial Interface (DW_apb_ssi)

The DW_apb_ssi is a programmable Synchronous Serial Interface (SSI) peripheral that is an AMBA 2.0-compliant Advanced Peripheral Bus (APB) Subordinate device. The DW_apb_ssi can be connected, configured, synthesized and verified within a DesignWare subsystem using coreAssembler.

SPI Dual-Quad Operation

One common use of the DW_apb_ssi IP is as a simple serial peripheral interface (SPI) which is used to carry data exchanges in a serial fashion. SPI is typically used in Flash memories, including NAND or NOR. Users of SPI can carry out higher data-rate transfers for high-performance automotive and IoT applications, especially when implemented in a multi-lane configuration. Many automotive and mobile applications need to read the Flash memory in less time, while exchanging maximum information. By carrying out the transfers on a multi-lane SPI, designers can increase the number of data transactions to meet today’s high performance requirements.

Compared to a typical single-lane SPI, the variants of a multi-lane SPI are:

• Dual SPI – Improving throughput by 2X
• Quad SPI – Improving throughput by 4X

The DW_apb_ssi IP supports a multi-lane SPI in the Controller mode and provides the flexibility to set up the transfers over dual-/quad-lanes while still providing the option to revert back to single-lane mode for basic status fetch operations.

The DW_apb_ssi dual/quad supports:

• Exchange of data on single/dual/quad lanes during data transfers
• Multi-lane modes:
  • Intelligence to transfer instruction/address over single/dual/quad lanes
  • Intelligence to SKIP the instruction/address

DW_apb_ssi dual/quad support is designed to interface with industry-standard NOR Flash multi-lane memories. Figure 5 shows a typical I/O connection.

I2C Device with APB Target Interface (DW_apb_i2c)

The DW_apb_i2c is a configurable, synthesizable and programmable control bus that provides support for the communications link between integrated circuits in a system. It is a simple two-wire bus with a software-defined protocol for system control, which is used in temperature sensors and voltage level translators to EEPROMs, general-purpose I/O, A/D and D/A converters, CODECs and many types of microprocessors.

Support for SMBus and PMBus Protocols

The I2C bus is the communications protocol for several system architectures consisting of command sets and application-specific extensions along with the base I2C specification. These architectures are basically targeted to the system management bus (SMBus) and power management bus (PMBus) related tasks.

System Management Bus (SMBus)

The SMBus is a two-wire interface through which various system component chips can communicate with each other as well as with the rest of the system. It is based on the I2C standard. SMBus provides a control bus for the system to pass messages to and from devices instead of using individual control lines, reducing pin count and system wires. The acceptance of messages instead of control lines ensures future expandability. SMBus enables an inexpensive, yet powerful method for controlling and receiving information from devices attached to a network.

Key features of a SMBus are:

• Low cost
• More robust than I2C
• SMBALERT# Line for Interrupts
• Packet error checking
• Defined bus protocols
• Host notify protocol

Key advantages of a SMBus are:

• Noise sensitivity:
  • False START and STOP detection through timeouts which forces the reset of the bus
  • Corrupt data through supporting the Packet Error Checking (PEC) for the transfers
• SMBus defines the address resolution protocol through which resolves the Target address conflicts by dynamically assigning a new unique address to each Target device
• The ‘Timeout Force Device Reset’ mechanism prevents the I2C device to stop responding
• The I2C’s requirement for retrieving device information through polling is eliminated by the dedicated ‘SMBALERT’ line which acts as an interrupt
• SMBus protocol defines command-based Write/Read transfers to differentiate the type of control transfer initiated by the Controller; command arguments and return values of each transfer vary in length based on the command

Power Management Bus (PMBus)

With the emergence of the Internet-of-Things (IoT) applications, connecting billions of embedded devices and sensors, saving energy is essential. Measuring energy consumed by each device in a system helps manage overall power consumption. Energy-management applications such as the smart meter and similar energy-measurement subsystems inevitably serve as critical elements, providing information on energy usage to help users optimize their energy consumption.

The PMBus, a superset of the SMBus, is a standard protocol to communicate with power converters over a digital communication bus. The PMBus uses the SMBus protocols to transfer the power commands.

The PMBus provides on-chip energy metering functionality, which is when the host processor does not have to poll the power monitor continuously to read power samples. Individual power samples are accumulated on-chip and read intermittently from the power monitor via the PMBus, which frees up the I2C bus for other transactions.

Designers can integrate a single IP into their SoC that supports both the SMBus and PMBus protocol specifications.

Bus-Clear Feature

The bus clear feature is an automatic recovery of clock (SCL) and data (SDA) lines during the unlikely event that either clock or data line is stuck at zero.

SDA Line Stuck at Zero

The Controller, which is usually a microcontroller/processor, will be interrupted (example external reset) in the middle of its communication (Read transfer) with an I2C Target and, upon return, finds a stuck bus on the SDA line. The cause of this problem is due to the following two scenarios:

• The Target is still waiting to send the remaining data requested by the Controller before it is interrupted. At this point, the Target will have put the next bit out on the SDA line (because the SCL line may have dropped to a low on reset) and wait for the next clock on the SCL. However, the Controller or microcontroller/processor does not send the data, causing the Target to keep waiting.
• The Controller has forgotten where it was when it was interrupted or reset.

As a result the bus becomes nonoperational due to the Controller’s or processor’s/microcontroller’s inability to finish the message it started. To solve this problem, the Target must be allowed to finish sending the last byte of data and the Target must be reset externally. Allowing the Target to finish sending the last byte of data does not require hardware and is a key feature of the I2C specification version 3.0.

The following steps can be taken to recover the SDA Line stuck at zero:

1. The Controller recovers the SDA line if it detects the SDA line is stuck at zero.

2. The Controller sends 9 or 18 clock pulses to let the Target finish the remainder of its data byte.

• 9-clock pulses - The number of clock pulses will vary with the number of bits that remain to be sent by the target. The maximum would be 9. This number is derived from the worst-case scenario, the case where the processor/microcontroller was reset just after sending an ACK to the Target. Now the target is ready to send 8 data bits and receive 1 ACK (or NAK in the case of a SDA bus recovery).
• 18-clock pulses – In the case of a Multi-Controller scenario:
  • If both Controllers receive the start to send on the bus and if one Controller ‘tBuf’ time is lesser than the other controller.
  • The first Controller which has less ‘tBuf’ time will drive the low on the SDA to generate start and second controller will see the SDA low once it’s ‘tBuf’ timer expires and perceives the SDA is stuck at low
  • The second Controller will generate 9 SCL clocks to recover the SDA thinking SDA is stuck low, whereas the first Controller drives the normal transfer to the target. The second Controller backs off from the recovery procedure once the SDA line is high during the transfer of first Controller.
  • The real issue is if the first Controller transfers the general call address (all 8 bits are zero) and any one of the Target acknowledges it. The second Controller thinks that SDA is not recovered after recovery and forces the user to falsely execute a hard reset. To avoid this issue, the recovery clocks can be up to 18 clocks (2 bytes) to recover the SDA line.

There may be some concerns about the effect of the additional clocking on other Targets. There is no adverse effect; other Targets are not engaged due to the fact that they have not been addressed. Only the Target that had the interrupted message will respond to the clocks.

Ultra-Fast Speed Mode

The Ultra-Fast Speed mode is another variant of I2C bus speed mode that operates from DC (0) to 5 MHz, transmitting data in one direction. It is useful for speeds greater than 1 MHz to drive LED controllers and other gaming systems.

Synopsys offers the features described above in the DW_apb_i2c IP:

• SMBus/PMBus interface
• Bus clear feature
• Ultra-fast mode (UFm)

Synthesizable DesignWare IP for AMBA 2.0

The Synopsys DesignWare IP is fully compatible with the ARM AMBA 2.0, AMBA 3 AXI™, and AMBA 4 AXI protocols including ACE-Lite™, allowing flexible system architectures to fully support designers' requirements. The configurable architecture of the IP, coupled with the automated assembly tool, reduces the complexity of designing next-generation AMBA-based subsystems and significantly improves overall productivity for faster time-to-results.

Additional Resources

DesignWare IP Solutions for AMBA Interconnect

DesignWare IP Solutions for AMBA – APB Advanced Peripherals