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?

Parents
  • 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

Reply
  • 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

Children
No Data