UART Protocol: INTRODUCTION

UART stands for Universal Asynchronous Receiver Transmitter. A UART’s main purpose is to transmit and receive serial data. UART was developed by Gordon Bell at Digital Equipment Corporation in the 1960s. UARTs are used in automobiles, smart cards, and SIMs in which they are commonly integrated in microcontroller chips.

In UART communication, the Transmitting UART converts parallel data to serial form and transmits it serially to the receiving UART, which then converts the serial data back into parallel data. Only two wires are needed to transmit data between the two UARTs. UART data bits are sent one by one, from the LSB to the MSB, framed by start and stop bits to precisely handle timing in the communication channel.

UART transmits bits asynchronously, which means that there is no clock signal to synchronize the output of bits from the transmitting UART to the sampling of bits by the receiving UART. Instead of a clock signal, the transmitting UART adds a start and stop bit to the data packet being transferred. Baud rate is a measure of the speed of data transfer, expressed in bits per second. Both UARTs must operate at the same baud rate. The standard baud rate is 9600bps which is sufficient for low-speed operations and it can reach speeds of up to 115200bps.

Figure 1. Transmitting and Receiving UART

UART Protocol: THEORY OF OPERATION 

The Transmitter UART is the one that receives the data on a data bus from a CPU or microcontroller. After the transmitting UART gets the parallel data from the data bus, it adds a start bit, a parity bit, and a stop bit which makes a data packet. Next, the data packet is sent to the output serially, bit by bit. The receiving UART reads the data packet bit by bit and then converts the data back into parallel form removing the start bit, parity bit, and stop bits. After which, the receiving UART transfers the data packet in parallel to the data bus at the receiving end.

Figure 2. UART data packet

START BIT 

To start the transfer of data, the transmitting UART pulls the transmission line from high to low for one clock cycle. When the receiving UART detects the high-to-low voltage transition, it begins reading the bits in the data frame at the frequency of the baud rate.

DATA FRAME

The data frame contains the actual data being transferred. It can be 5 bits if a parity bit is not used or up to 8 bits long if a parity bit is used. If no parity bit is used, the data frame can be 9 bits long. In most cases, the data is sent with the least significant bit (LSB) first.

PARITY

Parity is used for error checking in UART and it describes the evenness or oddness of a number. The parity bit is a way for the receiving UART to tell if any data has changed during transmission or not. Bits can be changed by mismatched baud rates or long-distance data transfers.

After the receiving UART reads the data frame, it counts the number of bits with a value of 1 and checks if the total is an even or odd number. If the parity bit is a 0 (even parity), the 1 bits in the data frame should total to an even number. If the parity bit is a 1 (odd parity), the 1 bits in the data frame should total to an odd number. When the parity bit matches the data, the UART knows that the transmission was free of errors. But if the parity bit is a 0, and the total is odd; or the parity bit is a 1, and the total is even, the UART knows that bits in the data frame have changed.

Figure 3. Odd and even parity UART

STOP BIT 

To signal the end of the data packet, the sending UART drives the data transmission line from a low voltage to a high voltage for at least two-bit durations.

UART Protocol Analysis and Debug :

UART is a simple protocol however the analysis continues to remain a challenge. Prodigy Technovations has multiple solutions for the UART protocol analysis and Debug.

1. UART Protocol Analyzer and Exerciser.

UART Protocol Analyzer and Exerciser

2. UART Protocol Analysis software.

 UART Protocol Analysis software.

3. Logic Analyzer with inbuilt UART protocol decode capability

Logic Analyzer with inbuilt UART protocol decode capability

RFFE Protocol: Introduction

Mobile radio communication involves multi-radio systems composed of several parallel transceivers making a leap in complexity for the RF front-end design. RF front-end devices include power amplifiers, low-noise amplifiers, filters, switches, power management modules, antenna tuners, and sensors. The devices may be located either in a separate unit or they may be integrated into a single module depending on the applications. RF Front-End Control Interface (RFFE) offers a common method for controlling RF front-end devices. RFFE provides a low-complexity solution to meet the cost and performance of RF front-end devices. RFFE is designed to support existing 3GPP standards such as LTE, LTE-A, EGPRS, UMTS, HSPA, etc, and also other non-3GPP air interfaces.

RFFE Protocol: Theory of operation

RFFE Protocol is a two-wire serial interface intended to be used to connect one or more radio frequency ICs (RFICs) in a mobile terminal to their related front-end modules (FEMs) to control and monitor them. RFFE has two primary signal lines- A serial bidirectional data signal (SDATA) and a clock signal (SCLK). RFFE interface enables systems to efficiently control various FEMs in next-generation mobile terminals with the increased complexity of performance supporting multi-mode, multi-band, and multiple antennas, using RFFE bus or by using multiple buses.

There are two configurations of RFFE namely, Basic configuration and Complex configuration.

The basic configuration and its bus structure are shown in Figure 1 which is a single master configuration. RFFE requires two primary signaling lines- One serial bidirectional data signal (SDATA) and one clock signal (SCLK), which is controlled by the bus owner master. Additional signals may be present on an RFFE device as a means for providing additional proprietary functionality.

RFFE v2 is a more complex bus structure. This is a multi-master configuration and the high-level view of such a structure is shown in Figure 2. SCLK and SDATA signal lines and connections remain the same, but the number of master devices on a particular bus instance may be up to four.

Figure 1. RFFE v1 Interface and Bus Structure

Figure 2. RFFE v2 interface and bus structure

RFFE Pin Descriptions:

VIO

VIO is the RFFE interface voltage reference or supply. The primary function of the VIO signal is to provide a shared voltage reference for the SCLK and SDATA pins for all devices on an RFFE bus instance.

SCLK

The SCLK signal provides the clocking and synchronization for all devices on an RFFE bus. It is always sourced by the Bus Owner Master (BOM) device.

In the case of a bus that has multiple master devices, the responsibility for the sourcing of SCLK is transferred to the new BOM any time that a master switchover occurs. There will be a dedicated SCLK signal for each RFFE bus instantiation.

SDATA

The SDATA signal on an RFFE bus provides the mechanism for command and data transfers, on the RFFE bus.

For write only slaves the SDATA pin is input-only. For slaves supporting read and write operations, the SDATA is bi-directional.

FREQUENCIES OF OPERATION: RFFE BUS SPEED RATES

RFFE provides a continuous range of frequencies for operation thus providing flexibility in clock sourcing. The active RFFE master device BOM is responsible for sourcing the non-continuous bus clock (SCLK) by specified requirements such as edge transition times.

The master device may select a desired operating frequency for SCLK at any time. The available range of SCLK frequencies and their parameters are given in the table below:

Figure 3. RFFE Frequencies of operation

RFFE Protocol: Data Transfer Structure

SEQUENCE START CONDITION (SSC)

The Sequence Start Condition (SSC) shall be a unique condition on the bus which is identified by a rising edge of SDATA, followed later by a falling edge on SDATA, all while SCLK remains at a logic ‘0’ level. The SSC is used by the master to identify the beginning of a new command sequence. Slaves shall synchronize themselves to expect a new command sequence following the detection of an SSC. The master shall generate the SSC by driving SDATA to logic level ‘1’ for one SCLK period, then to logic level ‘0’ for one SCLK period, all while holding SCLK at logic level ‘0’.

Figure 4. Sequence start condition

FRAMES

There are three types of frames and all three frame types consist of address plus command, or of data, or address bits, plus a parity bit.

COMMAND FRAME

A command frame shall consist of a 4-bit slave address field, an 8-bit command payload field, and a single parity bit, for a total of 13 bits. The first four bits of the address field are the slave address (SA) bits, followed by the eight command bits, and finally followed by the parity bit for the frame. The parity bit is calculated over the 12 bits of the CF. The command frame structure is shown

Figure 5. Command Frame

DATA OR ADDRESS FRAME

A data frame or an address frame shall consist of right data bits or eight address bits respectively and a single parity bit. The frame is called an address frame when the payload bits carry address information and a data frame when the payload bits carry data information. Otherwise, the frame structure is identical. The type of payload data being carried is defined by the position of the frame within the command sequence.

Figure 6. Data or Address Frame

NO RESPONSE FRAME

All bits including the parity bit of a no response frame (NRF) shall be ‘0’. This frame may be generated by driving SDATA to logic level ‘0’ or by passively allowing the master to pull SDATA to a logic ‘0’ for the duration of the frame. A no-response frame is nine bits long since it is a data frame. A no-response frame may be transmitted passively or actively. A passive no-response frame may be the result of a write-only slave during a read command sequence, while an active or passive NRF may be the response from a read-capable slave in the event of a read operation to an unused register location in that device.

Figure 7. No Response Frame (Passive)

PARITY BIT

All frames shall end with a single parity bit. The parity bit shall be driven such that the total number of bits in the frame that are driven to logic level '1', including the parity bit, is odd, thus
achieving odd parity.

RFFE Protocol Debug:

Debugging RFFE Protocol continues to remain a challenge. Decoding the packets will help to better understand Protocol related issues and help speed up the engineering debug and development time. Prodigy has developed a Protocol Analyzer for debugging the RFFE protocol.

RFFE Protocol Analyzer and Exerciser

About Prodigy:

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

ONFI INTRODUCTION

The Open NAND Flash Interface (ONFI) is an industry Workgroup made up of more than 100 companies that build, design-in, or enable NAND Flash memory dedicated to simplifying NAND Flash integration into consumer electronic products, computing platforms, and any other application that requires solid state mass storage. ONFI defines standardized component-level interface specifications as well as connector and module form factor specifications for NAND Flash.

Using an open interface standard strengthens the compatibility and interoperability of NAND devices from different vendors. Thus increasing the supply base for standard devices, reducing design time, and speeding time to market.

WHY ONFI?

The importance of NAND Flash memory is growing every day as it is used from mobile phones to industrial systems. Until 2006 there was no standard, and thus no simple ways to introduce new NAND Flash components into existing designs. The lack of a standard caused serious design problems: host systems had to accommodate differences between vendors’ devices and adapt to generational changes in parts from a single vendor. All of this made incorporating new or updated NAND Flash components extremely costly, often requiring extensive hardware, firmware, and/or software changes, and additional testing, which slowed time to market. Thus, the development of ONFI solved all these issues by standardizing the NAND Flash interface reducing vendor and generational incompatibilities, and accelerating the adoption of new NAND products.

ADVANTAGES OF ONFI

• Faster and Easier Design- ONFI’s parameter page provides the controller with all of the device's relevant capabilities for quicker design, qualification, and testing.
• Higher Speeds- At Speeds of up to 1200 MT/s, ONFI is the fastest NAND interface standard on the planet. These high speeds are made possible by the bidirectional source-synchronous DQS and scalable I/O interface.
• No Requalification- Standardized compatibility enables pin and function drop-in compatibility and integration. ONFI-standardized devices can use the same firmware and software to avoid expensive driver testing.
• Flexible Packaging- ONFI’s industry-standard BGA package accommodates both asynchronous and source-synchronous interfaces, reduces noise, and offers excellent signal integrity.

FEATURES OF ONFI

• EZ-NAND interface removes the burden of the host controller having to keep pace with the fast-changing ECC requirements of NAND technology, improving throughput and minimizing write errors on NAND.
• Parameter page solves inconsistencies among devices by describing revision info, features, organization timing, and other vendor-specific data.
• Asynchronous and source-synchronous support with Backward compatibility simplifying qualification for new NAND devices.
• Low-power DDR I/O and Scalability for high-density applications.
• Broad support from more than 80 top-level companies, including Micron, Intel, SK Hynix, Western Digital, Phison, and Sony.

Conclusion:

Prodigy Technovations supports ONFI interface protocol decode and analysis.

ONFI Electrical Timing Analysis Software

eSPI Protocol INTRODUCTION

eSPI stands for the enhanced serial peripheral interface. It was developed by Intel. eSPI is an all-in-one bus that was designed to replace the LPC bus as well as the SPI bus, SMBus, and sideband signals. For designers of computing applications, migrating from the LPC bus to the eSPI bus offered benefits such as cost savings, lower voltage, simplified board layout and design, and low power consumption. The eSPI bus can either be shared with SPI devices to save pins or be separate from the SPI bus.

Figure 1. An EC/BMC/SIO connection over the eSPI bus

Sideband pin communications between the chipset and these devices are converted to in-band messages through the eSPI interface as part of the effort to reduce the component pin count and provide a migration path toward the elimination of high-voltage 3.3V I/O pins.

eSPI: BENEFITS

eSPI is defined to meet the following requirements.

● Medium Bandwidth: The bus bandwidth needs to be higher than that of the Low PinCount (LPC) bus.
● LPC Replacement: Supports all the capabilities needed to replace the parallel LPC interface. However, 8237 DMA and Firmware Hub (FWH) are not supported over this interface.
● Sideband Pins as In-Band Messaging: Facilitates the removal of sideband pins for communication between chipset and slave devices by converting this communication into in-band messages sent over the eSPI bus.
● Real-Time Flash Sharing: Supports flash sharing based on partition-able memory mapping. Allows real-time operational access by chipset and slave devices.
● Chipset and Slave Devices SMBus Replacement: Supports tunneling of all SMBus communication between chipset and slave devices over the new interface as in-band messages.
● Scalable bandwidth: Allows the bandwidth to be scaled based on application needs to optimize power versus performance. This could be done through frequency scaling or
varying the number of active data pins.
● Low Voltage I/O Buffer: eSPI uses the same I/O buffer as Serial Peripheral Interface (SPI). The I/O buffer will support only a 1.8V mode of operation for the eSPI bus.

eSPI Protocol: PIN DESCRIPTIONS

RESET

Reset is typically driven from eSPI master to eSPI slaves. In other configurations, the eSPI Reset could be generated by the eSPI master and thus, it is driven from the eSPI master to the eSPI slave.

CHIP SELECT

eSPI master and eSPI slaves must tri-state the interface pins when their respective eSPI Reset is asserted. The Chip Select and I/O[n:0] pins require weak pull-ups to be enabled on these pins.

SERIAL CLOCK

The direction of the serial clock is from master to slave. A serial clock provides the reference timing for all the serial input and output operations.

ALERT

The direction of Alert is from slave to master and it is asynchronous. Alert is used by eSPI slaves to request service from the eSPI master. The alert pin is optional for single master-single slave configuration.

I/O[n:0]

These are bi-directional input/output pins used to transfer data between masters and slaves. The value of ‘n’ may be 1 or 3 depending on the I/O mode.

In Single I/O mode (n=1), I/O[0] is the eSPI master output/eSPI slave input (MOSI) whereas I/O[1] is the eSPI master input/eSPI slave output (MISO).

Figure 2. Single Master-Single Slave with eSPI Reset# from Slave to Master

eSPI Protocol: BUS TRANSACTIONS

The Serial Clock must be low at the assertion edge of the Chip Select while eSPI Reset has been de-asserted. The first data is launched from the master while the serial clock is still low and sampled on the first rising edge of the clock by the slave. Subsequent data is launched on the falling edge of the clock from the master and sampled on the rising edge of the clock by the slave. The data is launched from the slave on the falling edge of the clock. The master could implement a more flexible sampling scheme since it controls the clock. All transactions on eSPI must be in multiples of 8 bits.

Figure 3. Basic eSPI Protocol

The eSPI transaction consists of a Command phase driven by the master, a Turn-Around (TAR) phase, and a Response phase driven by the slave. The Command phase consists of a CMD, an optional header (HDR), optional DATA, and a CRC. The Response phase consists of an RSP, an optional header (HDR), optional data, a Status, and a CRC. CRC generation is mandatory for all eSPI transactions where the CRC byte is always transmitted on the bus. However, CRC checking is default disabled after reset and it is enabled by SET CONFIGURATION. When CRC checking is disabled, the CRC byte is ignored by the receiver. A transaction could be initiated by the master through the assertion of Chip Select, Start the clock, and drive the command onto the data bus. The clock remains toggling until the complete response phase has been received from the slaves.

Figure 4. Slave Triggered Transaction (Single Slave)

A transaction could be initiated by the slave by first signaling an Alert event to the master. The Alert event could be signaled in two ways. In the Single MasterSingle Slave configuration, the I/O[1] pin could be used by the slave to indicate an Alert event. In the Single Master-Multiple Slaves configuration, a dedicated Alert pin is required. The Alert event can only be signaled by the slave when the slave’s Chip Select is high.

Figure 5. Slave Triggered Transaction (Multiple Slaves)

Debug of eSPI Protocol:

Debugging eSPI remains a challenge in engineering development. Prodigy Technovations provides state of an art tool for eSPI Protocol Debug and analysis.

eSPI Electrical Validation and Protocol Decode Software

About Prodigy:

Prodigy Technovations continues to lead in the protocol analysis space. Prodigy Technnovation offers protocol analysis for basic serial protocol like I2C to complex high speed protocols like PCIe. The protocol analyzers range from CAN, I2C, SPI, QSPI, I3C, PCIe, and UFS Plus many other protocols on the serial bus.