VIP Central

 

Video Frame Transmission in MIPI-DSI

DSI is a high speed serial interface targeted to reduce the cost of display sub-systems in a mobile device by transferring the data to the display module in real time without storing the data in the device. However this means that the data has to be sent with proper timing information. The most important aspect in verifying the MIPI-DSI is the timing parameters associated with the video frame transmission. I went through this whole exercises with a couple of VIP users and felt that this would be useful to share as it would benefit others in understanding the complexities involved in video frame transmission.

You can learn more about Synopsys’ MIPI DSI VIP here.

In this blog let’s see the timing details associated in transmitting the video frame by taking an example of RGB888 video frame in 640×480 resolution.

Figure1: RGB888 video format in 640×480 display

In RGB888 data format, each pixel has 3 bytes (24bits) of information, 1byte (8bits) for each component (R and G and B).  In 640×480 resolution frame, each line has 640 pixels and frame has 480 lines. Let’s see the timing information which needs to be sent along with this RGB data.

Every video frame should have below information (in the order of sequence):

  1. VSYNC (Sync information)
  2. VBP (Vertical back porch timing information)
  3. VACT (Active video data along with horizontal back porch and front porch timing)
  4. VFP (Vertical front porch timing information)

VSYNC (Sync information)

VSYNC has the information of synchronization pulses. Each pulse information is conveyed by sending Vertical Sync Start or Horizontal Sync Start packet (first pulse alone has VSS and remaining has HSS) followed by Horizontal Sync Active (which is nothing but a blanking packet), Horizontal Sync End and BLLP (which is again a blanking packet, if time permits low power state can be introduced), see figure2. This information is sent for each VSA (Vertical Sync Active) line.  In a simplified mode (non-burst/burst with sync event) host can only send the start event of synchronization pulse (only VSS or HSS), peripheral may regenerate the sync pulse from sync event received, whenever required. Each VSA line should be in the range of tL (line time), timing parameter as defined by the peripheral.

Timing parameters involved during this state is tL (Line Time), tHSA (Horizontal sync active time) and BLLP, constraints for these timing parameters are shown in the VACT section as these also depends on other parameters(HBP, HACT, HFP)  in VACT.

VBP (Vertical back porch timing information)

VBP has the information of vertical back porch timing. VBP line information is conveyed by sending Vertical Sync End or Horizontal Sync Start (first line alone has VSE and remaining has HSS) packet followed by Horizontal Sync Active (which is nothing but a blanking packet), Horizontal Sync End and BLLP (which is again a blanking packet, if time permits low power state can be introduced), see figure2. This information is sent for each VBP line. Each VBP line should be in the range of tL (line time).

Figure2: Non-Burst with sync pulse timing information (source: DSI 1.1 specification)

Timing parameters involved during this state is same as in VSA and will be covered in VACT as these also depends on other parameters (HBP, HACT, HFP) in VACT.

VACT (Active video data along with horizontal back porch and front porch timing)

VACT has the information of active video data along with horizontal back porch and horizontal front porch. Each VACT line has below information in it

  • HSYNC (Horizontal Sync information):

This is same as Hsync information we have seen in VSA or VBP. This is conveyed by HSS followed by HAS and HSE. Sync information should be in the range of tHSA timing parameter defined by peripheral.

  • HBP (Horizontal Back Porch timing information):

This is nothing but a blanking packet with the horizontal back porch timing information. This information should be in the range of tHBP timing parameter defined by peripheral.

  • Active line data (RGB888 data in our example)

This is the active video pixel data having the 24bit pixel information.  Each line is sent as one long packet or can be divided into multiple long packets. But multiple lines cannot be merged as a one long packet in which case we may not be able to convey the HBP and HFP of the second line. This information should be in the range of tHACT timing parameter defined by peripheral.

  • HFP (Horizontal Front Porch timing information)

This is nothing but a blanking packet with the horizontal front porch timing information. This information should be in the range of tHFP timing parameter defined by peripheral.

Each line should be in the range of tL (line time) timing parameter. Timing parameters involved during this state is tL, tHSA, tHBP, tHACT, tHFP. HSA should be in the range of tHSA minimum and maximum range. Similarly Line, HBP, HACT, HFP should be in the range of corresponding minimum and maximum timing parameters. It is difficult to constraint on real time and so we recommend converting the time into word count and constraint on word count. For example if minimum tL is tL_MIN and maximum tL is tL_MAX then calculate the word count by dividing it by bitrate and then by 8 (to get no of bytes = word count). Similarly calculate word counts for other parameters from their minimum and maximum range.

bit[15:0] min_line_wc = ((tL_MIN ) / bitrate) / 8;
bit[15:0] max_line_wc = ((tL_MAX ) / bitrate) / 8;
// Note: tL_MIN and tL_MAX are in micro seconds and so make sure the units of bitrate is also in micro seconds

constraint constraint_hsa {
    hsa_wc inside {[min_hsa_wc:max_hsa_wc]};
}

constraint constraint_hbp {
    hbp_wc inside {[min_hbp_wc:max_hbp_wc]};
}

constraint constraint_hfp {
    hfp_wc inside {[min_hfp_wc:max_hfp_wc]};
}

constraint constraint_hact {
    hact_wc inside {[min_hact_wc:max_hact_wc]};
    // Below constraint is required to make sure HACT has one byte of data for RGB in each pixel
    (hact_wc % 3) == 0;
}

constraint constraint_line {
    line_wc inside {[min_line_wc:max_line_wc]};
    // LINE = HSS (4bytes short packet) + HSA + HSE (4bytes short packet) + HBP + HACT + HFP
    line_wc == 4 + hsa_wc + 4 + hbp_wc + hact_wc + hfp_wc;
}

constraint constraint_bllp {
    //BLLP = LINE – HSS (4bytes short packet) – HSA – HSE (4bytes short packet)
    bllp_wc == line_wc – 4 – has_wc – 4;
}

Line timing is constraint to be sum of hsa_wc, hbp_wc, hact_wc, hfp_wc, HSS and HSE. HSS and HSE are 2 short packets and so 4 bytes each. Word count for BLLP (used in VSA, VBP, and VFP) should be line word count subtracted by has word count and 2 short packets, each for HSS and HSE.

VFP (Vertical front porch timing information)

VFP has the information of vertical front porch timing. VFP line information is conveyed by sending Horizontal Sync Start packet followed by Horizontal Sync Active (which is nothing but a blanking packet), Horizontal Sync End and BLLP (which is again a blanking packet, if time permits low power state can be introduced). This information is sent for VFP times. Each VFP line should be in the range of tL (line time) timing parameter as defined by the peripheral.

The range (min and max) for timing parameters mentioned in the DSI1.1 specification (Table 22, section 8.11.5) has been left to the discrete of peripheral suppliers. There are different modes of sending the video frame information other than the non-burst with sync pulse which is explained in this blog, with minute changes like, in non-burst with sync event, one need not send HSA and HSE rather can just contain with HSS. Similarly DSI also has burst mode where pixel data is transferred in a shorter time using time compressed burst format, thus giving more time for LP state. Let’s look at these other modes in follow up blogs. Hope this blogs helps those who are verifying the video frame transmission in DSI.

Authored by Hari Balisetty, Broadcom

You can learn more about Synopsys’ MIPI DSI VIP here.

 

Comments are closed.