Cloud native EDA tools & pre-optimized hardware platforms
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
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).
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.
A system like a distributed monitoring application consists of a multi-drop network ¨C 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.
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 |
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
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.
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.
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:
Figure 4: Typical I/O connection for a multi-lane SPI Flash
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:
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
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.
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.
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:
Key advantages of a SMBus are:
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
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.
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:
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.
Figure 8: SDA Recovery with 9 SCL clocks
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.
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:
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.