LVDS display bridges and automated measurements – part 1
Today’s vehicles use TFT LCD displays for presenting the vehicle’s status, entertainment system, and other information to the driver. The displays are driven by an SoC that contains memory, an control unit, and a bridge that delivers a serial LVDS (Low Voltage Differential Signaling) data stream. LVDS lets us achieve high speed data transfer with high signal integrity and low power consumption.
Characterizing LVDS devices requires us to make measurements under a range of power-supply voltage, temperature, and process variations. An automated test system makes and records the measurements and analyzes the results. I have used those experiments in a modified way with fully automated processes done using LabVIEW for the characterization of OpenLDI (Open LVDS Display Interface) used for controlling automotive displays. In this two-part article, I’ll first provide a background on LVDS. Part 2 will explain how we automate the measurements.
LVDS basics
The LVDS standard was created to address applications in data communications, telecommunications, servers, peripherals, and computers that need high-speed data transfer. Defined in the TIA/EIA-644 standard, LVDS is a low voltage, low power, differential technology used primarily for point-to-point and multi-drop cable driving applications. The standard was developed under the Data Transmission Interface committee TR30.2. It specifies a maximum data rate of 655 Mbps although some of today’s applications exceed this data rate.
LVDS has a typical voltage swing of 350 mV with a typical offset voltage of 1.25 V above ground. Its low swing differential constant-current source configuration supports fast switching speeds and low power consumption.
LVDS can use 5 V, 3.3 V, and 2.5 V power supply voltages. Low-voltage signals have many advantages including faster bit rates, lower power, and better noise performance than higher voltages. To increase noise immunity and noise margins, LVDS uses differential data transmission.
LVDS Display Bridge
The LVDS physical interface is part of an LDB (LVDS Display Bridge), which is a component of an SoC. Figure 1 shows The block diagram of the SoC. The DCU (display control unit) retrieves data from memory, processes it, and transfers it to the LDB. The LDB then serializes this data and transfers it to displays where it is again obtained in parallel format using converters. My main task is to characterize the data obtained at the LBD’s output.
Figure 1. An SoC containing an LVDS Display Bridge requires automation or characterize.
The LVDS Physical Layer
Figure 2 shows the equivalent structure of the LVDS physical layer. The driver’s current source limits the output to about 3 mA and minimizes current spikes. The switch box steers the current through the termination resistor. This differential driver produces a differential-mode signal, with equal and opposite currents flowing in the transmission lines. The current returns within the wire pair, so the current area is small and therefore generates the lowest amount of EMI.
The current source limits any spike currents that could occur during transitions. Because there are no spike currents, data rates as high as 1.5 Gbps are possible, but with a substantial increase in power dissipation. The constant current driver output can tolerate transmission lines shorted together or to ground without creating thermal problems. Hot plugging of LVDS drivers is possible because the constant current drive eliminates the potential for damage.
Figure 2. The LVDS physical layer uses a 3.5. mA constant-current source across at 100 O resistor (Rt) to produce 350 mV differential signals.
LVDS Display Bridge functions
The purpose of the LDB is to support flow of synchronous RGB data from the 2D-ACE to external display devices through its LVDS interface. This support covers all aspects of these activities:
- Connectivity
- Arranging data as required by external display receiver and by LVDS display standards.
- Synchronization and control capabilities.
An LDB must comply with the following standards.
- ANSI EIA-644-A. Electrical Characteristics of Low Voltage Differential Signaling (LVDS) Interface Circuits.
- SPWG Notebook Panel Specification (V3.8 from 03/2007)
- PSWG standards (Panel Standardization Working Group) – set of standards for panels using LVDS.
- DISM Standard JEIDA-59-1999
LDB data processing stages are as follows:
- Receive input data from 1 parallel input interface. 18/24 RGB data + up to four controls and map them to LVDS channel.
- Re-arrange the input data according to channel configuration.
- Serialize the 22/28 bit input bus on 3-4 output serial data lines (7:1).
Figure 3 shows the block diagram of an LVDS Display bridge. It receives parallel data from the DCU and then the LDB Controller serializes this data. Finally, the LVDS PHY subsystem converts the signals into LVDS form at the LVDS Data pair: LVDS(A:D)E_PN and LVDS(A:D)O_PN
Figure 3. An LVDS Display Bridge includes control logic and a PHY subsystem.
To understand the data driven at the output of the LVDS Display Bridge, we need to understand the complete functioning of the SoC’s Display Control Unit/2D-ACE (Two Dimensional Animation and Composite Engine.
DCU and 2D-ACE
The 2D-ACE is a system master that fetches graphics data stored in internal or external memory and displays them on a TFT LCD panel. A wide range of panel sizes is supported and the timing of the interface signals is highly configurable. Graphics are read directly from memory and then blended in real time, which allows for dynamic content creation with minimal CPU intervention. Graphics may be encoded in a variety of formats to optimize memory usage. The DCU drives the LVDS Display Bridge, which in turn gives input to the TFT Display. Figure 4 shows a block diagram of the DCU.
Figure 4. Block Diagram of a DCU that uses 2D-ACE architecture.
The 2D-ACE architecture consists of two distinct sections. The lower section shows the functional blocks that fetch the graphic and video content and drive the TFT LCD panel. The upper section describes the user interface through which the user configures the graphical content of the TFT LCD panel. The sections are analogous to the structure of communications modules, such as Flex CAN, where one part of the module is configured to connect with the communications bus through bit-timing, parity, baud rate, etc. while a different part is used to store the data content and message identifiers.
The configuration of the lower section is dependent on the specific TFT LCD panel that is attached to the outputs. In most cases, this is configured once for the hardware in use before the 2D-ACE section is enabled. When active, this section automatically performs the following functions.
- Calculates the relevant graphical content for each pixel.
- Fetches the source graphics from memory using its internal DMA channels (labeled CH1 to CH4) and stores the data in dedicated FIFO buffers.
- Converts the graphic value of each fetched pixel into full quality color format (if required).
- Calculates the required pixel value by blending the values of up to four separate graphics.
- Perform a gamma correction on the pixel value (if required).
- Send the pixel value to the TFT LCD display over its data bus.
- Set flags to indicate end of frame, FIFO buffer threshold, and other status changes.
The upper section describes the characteristics of the graphics to be displayed on the panel and how they are blended together. The 2D-ACE manages the graphical content of the panel through sets of registers called layers. There are 16 layers available in the 2D-ACE architecture. Each contains the following information:
- Horizontal and vertical size of graphic.
- Position of graphic on the panel.
- Address of graphic in memory,
- Color encoding format and color palettes (if required),
- Type and depth of blending.
- Range of colors identified for Chroma blending.
- Tile size.
- Foreground and background colors for transparency encoded graphics.
- Visible horizontal width,
- Size of RLE compressed image.
The values in these registers may be changed at any time, and the panel content will be updated either under software control or at an automatic point in the panel refresh cycle. The layers are set to a fixed priority, and this is used by the lower section to define which layers are blended, in which order, on the panel. The upper section also contains configuration registers for a cursor graphic, the default background color, interrupt enables, test graphic, and simple register protection settings.
The 2D-ACE has the following features:
- Full RGB888 output to TFT LCD panel.
- Output to system memory dependent on implementation.
- 16 graphics layers, a default background color layer and a cursor layer with integrated blinking option.
- Blending of each pixel using up to 4 source layers.
- Windowing to display a part of a layer width only out of the whole layer.
- Support for programmable panel size up to a maximum of 2032 x 2047 pixels. The actual resolution supported depends upon the pixel clock and bus bandwidth available.
- Gamma correction with 8-bit resolution on each color component.
- Safety mode for tagging pixels on highest priority layers.
- Dedicated memory blocks to store a cursor and Color Look Up Tables (CLUTs).
- Temporal Dithering.
Part 2 will describe the automated characterization process using LabVIEW and the challenges associated with characterization.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
