ADV7280
Not Recommended for New Designs
The ADV7280 / ADV7280-M are versatile one-chip, multiformat video decoders. The ADV7280 / ADV7280-M automatically detect standard analog baseband video...
Datasheet
ADV7280 on Analog.com
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:
Is that accurate?
Or do I potentially have something configured incorrectly in the ADV7280?
The ADV7280 pattern appears to be:
While I was expecting something without the flipping SAV/EAV parameters for vertical blanking lines, e.g.:
SAV+vertical blanking = 0xAE from ADV7280, but isn’t spec 0xAB?
EAV+vertical blanking = 0xB3 from ADV7280, but isn’t spec 0xB6?
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:
Does this only work correctly in one of the other operating modes?
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
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