Post Go back to editing

ADV7280 frame timing on the digital output video bus

It appears the ADV7280 has the following frame timing on the digital output video bus when using one of the one of the interlaced CVBS to progressive configuration scripts (“I2P_NTSC_In_Ain1_YPrPb_Out_480p_EAV_SAV.py”).

Horizontal Active Video

720 (1440)

Pixels (data clock cycles)

Horizontal blanking

138 (276)

Pixels (data clock cycles), & includes 8 clocks for SAV and EAV codes per line

Vertical Active Video

507

Rows**

Vertical Blanking Video

18

Rows**

Data bus clock frequency

~54

MHz

**Because of the way EAV and SAV BT.656 codes are swapped around for vertical blanking, its hard to tell if this is correct or if it should be interpreted instead as 508 active lines and 17 blanking lines.

Can you confirm what the correct active video and blanking intervals are for the digital output video frame?

Additionally:

  1. The output clock period seems to jitter a fair amount. Is there a min/max clock period expected for this bus clock?
  2. It appears that the BT.656 codes for the vertical blanking interval may have swapped EAV and SAV ordering.

Is that accurate?

Or do I potentially have something configured incorrectly in the ADV7280?

The ADV7280 pattern appears to be:

  1. For line 1-506 active video: SAV (0x80) à 720 active pixels à EAV (0x9D) à 134 pixels à repeating until finish line 506
  2. Line 507 active video: SAV (0x80) à 720 active pixels à followed by:
  3. Line 1-18 vertical blanking: “SAV+vertical blanking w/wrong ECC?” (0xAE) à 134 pixels à “EAV+vertical blanking w/wrong ECC?” (0xB3) à 720 pixels à repeating until finish 18th blanking line then…
  4. Line 1 active video lead-in of:  EAV (0x9D) à 134 pixels à hop to line 1 active video start

While I was expecting something without the flipping SAV/EAV parameters for vertical blanking lines, e.g.:

  1. Lines 1-507 active video: SAV (0x80) à 720 active pixels à EAV (0x9D) à 134 pixels à repeating until finish line 507
  2. Line 1-18 vertical blanking: “SAV+vertical blanking” (0xAB) à 720 vertical blanking pixels à “EAV+vertical blanking” (0xB6) à 134 pixels à return to line 1 active video.
  3. Vertical blanking codes seem to have the wrong ECC bits in the lower nibble from what I was expecting.

SAV+vertical blanking = 0xAE from ADV7280, but isn’t spec 0xAB?

EAV+vertical blanking = 0xB3 from ADV7280, but isn’t spec 0xB6?

  1. The “Boundary Box” test pattern output doesn’t appear to be working correctly in this operating mode.

It is specified as follows:

But in the operating mode we’re using, it does not draw a box of that description on the BT.656 digital video bus.

FYI, I enabled the test mode by changing these bits in the devkit GUI:

For the digital video output’s 720x507 frame, I see:

  • A solid white vertical line in columns 1 and 2
  • A solid ‘gray’ vertical line column 3
  • A solid ‘gray’ vertical line column 720 and somewhere mid-frame this transitions to from a brighter to a darker gray in the code values
  • A solid white horizontal line in row 1
  • A solid ‘gray’ horizontal line in row 2
  • And no apparent bottom horizontal line

Does this only work correctly in one of the other operating modes?

  • Hi,

    Your question has been forwarded to the part specialist.

    Best Regards,

    Jeyasudha.M

  • Dear Sir/Madam,

    0) Could you try using an interlaced script first. You are currently using a progressive script. The interlaced-to-progressive converter in the ADV7280 works by interpolating between line to generate the missing lines (e.g. interpolating between lines 1 and 3 to generate line 2).

    1) The ADV7280 was evaluated and found to be fully compliant with the ITU-R BT.656-3 and ITU-R BT.656-4 specifications. These specifications can be found here: http://www.itu.int/rec/R-REC-BT.656/en

    2) By default the ADV7280 outputs according to the ITU-R BT.656-3 specification. There are 10 extra blanking lines in the vertical blanking period for NTSC signals in ITU-R BT.656-3 mode compared to ITU-R BT.656-4 mode.

    3) You can switch between the ITU-R BT.656-3 mode and  ITU-R BT.656-4 output mode by toggling the User Map register 0x04 bit [7].

         0: (default) BT656-3 mode

         1: BT656-4 mode

    4) The line lock clock output (LLC) from the ADV7280 has a nominal frequency of 27 MHz. However this clock is locked to the length of the horizontal line length of the incomming analog video signal. If horizontal line length is too long/short the LLC frequency will speed up/down to compensate. The LLC clock can vary by +/- 5%. See table 5 of ADV7280 datasheet (Rev.A).

    5)  Post on how to modify the boundary box test pattern is here:

    boundary box test pattern can't  be complete display

    In interlaced mode the boundary box test pattern top line appears on odd fields and bottom line appears on even fields.

    In interlaced mode the first/last pixel on every second line in the odd and even fields are white to generate the white vertical lines.

    In progressive mode the line interpolation algorithm doubles the size of the odd and even fields. Therefore the first frame could be doubled odd field that will only have the white line at its top. The next frame could be doubled even field that will only have the white line at its bottom.

  • Customer came back with the following follow questions:

    We’ve a few unanswered issues
    regarding the replies.  For example, one suggestion was to alter registers
    0x8B and 0x8c.  These cannot be located in the ADV7280 GUI.

    Ultimately we need to determine:

    1A)   how many pixel clocks per line

    1B)   how many lines per 480P frame? 

    2)     Of those two values, how many are video and how many are blanking?

  • FormerMember

    Hi ,

    Please see the follow up questions above and answer as soon as possible.

    Thank you,

    Lisa

  • Dear Sir/Madam,

    Apologies I have been out of office for the last few weeks.

    To answer your questions.

    • There are 720 pixels per horizontal line of video.
      • Each horizontal pixel has a single LLC clock pulse. DDR mode is not supported on the ADV7280.
    • When an NTSC source is connected to the ADV7280 and it is programmed into progressive mode then it will output 525 horizontal lines of video in each video frame.

    How many of these 525 lines are blanking data is unfortunately very hard to answer. Unlike PAL, the NTSC standard does not have fixed vertical blanking specifications. Therefore each NTSC video source will output slightly different vertical blanking. The ADV7280 will output whatever blanking the NTSC source has.

    There are somethings to take into account:

    • In progressive mode the ADV7280 interpolates between lines e.g. In an odd field it will interpolate between lines 1 and 3 to generate line 2.  Therefore any horizontal blanking lines will be doubled by the ADV7280 in progressive mode.
    • For most NTSC standards (but not all), odd fields have one extra half line of video at the top of a field. Even fields do not have have this extra half line of video at the top of a field.
    • The amount of vertical blanking lines output from the ADV7280 is different in BT656-3 or BT656-4 mode. The BT656 output mode is controlled by User Map register 0x04 bit [7].

    As an experiment an Eiden 3116A-001 Video Generator was programmed to output NTSC-M and was fed into an ADV7280-M evaluation board. The output was captured using a Keysight U4421A MIPI protocol analyser.  The ADV7280 and ADV7280-M have the same vertical blanking output.

    The following vertical blanking was recorded. Note these timing can be slightly different for different NTSC sources.

    When ADV7280-M was in BT656-3 mode

         Lines 1- 22 : Blanking

         Lines 23 - 507 : Active Video

         Lines 508 - 525 : Blanking

    When ADV7280-M was in BT656-4 mode

         Lines 1- 2 : Blanking

         Lines 3 - 507 : Active Video

         Lines 508 - 525 : Blanking

    Regards,

    Robert Hinchy

    Senior Applications Engineer,

    Analog Devices Inc.

  • FYI you can use the following steps to access User Map registers 0x8B and 0x8C

    1) In the "DVP Eval Latest Source Program" ensure that register 0x0E is set to the value 0x00.

    2) press Tools -> Register Control Tool

    3)     A "Load/Read Register" box will appear.

    In the Device Address box enter 42 (this is the I2C device address of the ADV7182 when the ALSB pin is pulled high).

    In the Register box enter 8B or 8C to access user map register 0x8B and 0x8C respectively.

    Enter the value you want to write to this register in the write box and then press the write button on the bottom left.

    Press Read to read the value stored in the register.

    Leave Address size and register size at their default values.

    regards,

    Robert Hinchy

  • Hi Rob,

        This thread provided helpful info for a vertical shift issue that we'd been seeing in an application with the ADV7280 using the BT.656 interface with embedded timing.  We'd already discovered the helpfulness of the 656 mode change.  However there is also a horizontal right-shift issue that is causing the last pixel or two of a line to wrap to the left edge.  This likely involves mismatched timing that could potentially be solved in the processor, but may not be practical to do, given the use of standard blocks provided with the FPGA.  So, in the ADV7280 is there another single control bit that might resolve the horizontal timing issue?  

        For reasons not clear, there seem to be neither V nor H shifts when using the pattern generator.  The "boundary box" pattern outputs its top line to the top of the screen (after FPGA processing) regardless of the 656 mode of -3 or -4, and horizontally it appears to be centered, not shifted right.  There is no wrapping of the right color bar to the left edge.  But, regardless, we're wondering if the V-blank and H-blank periods have data stuffed in them that might make it hard to notice if the image was shifted(?).

    ~Brian

  • This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.

    Thank you,
    EZ Admin