DesignWare Technical Bulletin

Understanding Advanced Interconnect IP Peripherals for IoT and Automotive SoCs

By John A. Swanson, Product Line Manager, Synopsys; Sriram Balasubramanian, Sr Manager, R&D, Synopsys; Sreenath Panganamala, Sr ASIC Digital Design Engineer, Synopsys; Pratap Neelasetty, Sr ASIC Digital Design Engineer, Synopsys; Srinivasa Yelavatti, Sr ASIC Digital Design Engineer, Synopsys; Nishith Sharma, ASIC Digital Design Engineer, Synopsys

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 slave 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 Slaves. 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 Slave 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 Slaves, then all the Slaves 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.

Figure 1: A typical RS485 use case (half duplex)

Figure 2: A typical RS485 use case (full duplex)

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:

Feature Support Scope
RS485 standard Full duplex
Half duplex hardware controlled
Half duplex software controlled
9-Bit protocol Receive auto-address match
Receive software address match
Transmit software based 9-bit data
Transmit with user control on the data

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.

Figure 3: Fractional division in UART

Fractional Baud Rate Calculation

The baud rate defines the number of symbols transfer rate per second and it is derived as

Where the sample rate of UART is 16 (commonly used).

For example, if the input clock (peripheral clock) = 133Mhz, baud rate = 499200 and sample rate = 16, then from Equation 1: 

Which gives Divisor value = 16.65 ~= 17

The baud rate derived with the obtained divisor value is: - See more at:

The baud rate obtained through the Eq3 is 488970.5. 

The percentage of error is 2.049, which is outside of the acceptable range.

With a fractional baud rate and fractional resolution of 4, the baud rate achieved is 5,000,000 which has the percentage error of 0.160, which is in the acceptable range.

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) Slave 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

Figure 4: Typical I/O connection for a multi-lane SPI Flash

The DW_apb_ssi IP supports a multi-lane SPI in the Master 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.

Figure 5: Typical connection of SSI with Flash memory

I2C Device with APB Slave 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.

Figure 6: Typical topology of a SMBus system

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 Slave address conflicts by dynamically assigning a new unique address to each Slave device
  • The ‘Timeout Force Device Reset’ mechanism prevents the I2C Slave device to hang
  • 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 Master; 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.

Figure 7: Typical topology of a PMBus system

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 Master, which is usually a microcontroller/processor, will be interrupted (example external reset) in the middle of its communication (Read transfer) with an I2C Slave and, upon return, finds a stuck bus on the SDA line. The cause of this problem is due to the following two scenarios:

  • The Slave is still waiting to send the remaining data requested by the Master before it is interrupted. At this point, the Slave 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 Master or microcontroller/processor does not send the data, causing the Slave to keep waiting.
  • The Master has forgotten where it was when it was interrupted or reset.

As a result the bus becomes nonoperational due to the Master’s or processor’s/microcontroller’s inability to finish the message it started. To solve this problem, the Slave must be allowed to finish sending the last byte of data and the Slave must be reset externally. Allowing the Slave 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 Master recovers the SDA line if it detects the SDA line is stuck at zero.

2. The Master sends 9 or 18 clock pulses to let the Slave 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 slave. 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 Slave. Now the slave 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-Master scenario:
    • If both Masters receive the start to send on the bus and if one Master ‘tBuf’ time is lesser than the other master.
    • The first Master which has less ‘tBuf’ time will drive the low on the SDA to generate start and second master will see the SDA low once it’s ‘tBuf’ timer expires and perceives the SDA is stuck at low
    • The second Master will generate 9 SCL clocks to recover the SDA thinking SDA is stuck low, whereas the first Master drives the normal transfer to the slave. The second Master backs off from the recovery procedure once the SDA line is high during the transfer of first Master.
    • The real issue is if the first Master transfers the general call address (all 8 bits are zero) and any one of the Slave acknowledges it. The second Master 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.

Figure 8: SDA Recovery with 9 SCL clocks

There may be some concerns about the effect of the additional clocking on other Slaves. There is no adverse effect; other Slaves are not engaged due to the fact that they have not been addressed. Only the Slave 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.