SLES032E June 2002 – September 2014 THS8200
PRODUCTION DATA.
INPUT INTERFACE | TIMING CONTROL | SYNCHRONIZATION | |||||||
---|---|---|---|---|---|---|---|---|---|
30 BIT | 20 BIT | 10 BIT (1) | 16 BIT | 15 BIT | EMBEDDED TIMING | DEDICATED TIMING | MASTER | SLAVE | |
[PRESET] HDTV-SMPTE296M progressive (720P) |
X (4:4:4) | X (4:2:2) | X | X | X | ||||
[PRESET] HDTV-SMPTE274M progressive (1080P) |
X (4:4:4) | X (4:2:2) | X | X | X | ||||
[PRESET] HDTV-SMPTE274M progressive (1080I) |
X (4:4:4) | X (4:2:2) | X | X | |||||
[GENERIC] HDTV | X (4:4:4) | X (4:2:2) | X | X | X | ||||
[PRESET] SDTV-ITU.1358 (525P) |
X (4:4:4) | X (4:2:2) | X (2) | X | X (5) | X | |||
[PRESET] SDTV-ITU-R.BT470 (525I) |
X (4:4:4) | X (4:2:2) | X (3) | X | X (5) | X | |||
[PRESET] SDTV-ITU-R.BT470 (625i) |
X (4:4:4) | X (4:2:2) | X (3) | X | X (5) | X | |||
[GENERIC] SDTV | X (4:4:4) | X (4:2:2) | X | X | X | ||||
[PRESET] VESA | X (4) | X (4) | X (4) | X | X | X |
Table 6-1 summarizes all supported video mode configurations.
Each video mode is characterized by three attributes:
NOTE
Device operation with combinations of settings for the dman_cntl, dtg2_embedded_timing and chip_ms registers that result in operating modes not marked in Table 6-1 is not assured. See detailed register map description for actual register settings.
Furthermore, Table 6-1 shows for which modes presets are defined. When in a preset video mode, the line-type/breakpoint-pairs that define the frame format (see Section 6.7) are preprogrammed. Therefore the user does not need to define the table with line type/breakpoint settings, nor does the field and frame size need to be programmed. However, when in preset mode, the horizontal parameters (all dtg1_spec_x registers for the line types used by the preset setting, and dtg1_total_pixels registers) still need to be programmed. Presets are available for most popular DTV video formats. Alternatively, generic modes for SDTV, HDTV or VESA can be selected, which allow full programmability of the field/frame sizes and DTG parameters.
Note from the table that:
The following figures define the input video format for each input mode, as selected by the data_dman_cntl register setting. Video data is always clocked in at the rising edge of CLKIN.
NOTE
For 8-bit operation with 10-bit input buses, connect only the 8 MSBs of each input bus used, and tie the 2 LSBs to ground.
CLKIN is equal to the 1x pixel clock. The pixel clock equals the rate of the Y input and is 2x the rate of the 2 other channels in this input format where Cb and Cr are multiplexed onto the same input bus.
When dedicated timing is used in this mode, there is a fixed relationship between the first active period of HS_IN (that is, the first CLKIN rising edge seeing HS_IN active) and a Cb color component assumed present during that clock period on the bus receiving CbCr samples. When embedded timing is used in this mode, the SAV/EAV structure also unambiguously defines the CbCr sequence, according to SMPTE274M/296M for HDTV.
NOTE
The figure shows the case when only 8 bits of each 10-bit input bus are used.
CLKIN is equal to 2x the pixel clock since all components are multiplexed on a single 10-bit bus with a 4-multiple sequence: CbYCrY. Therefore the pixel clock (that is, the Y input rate) is 1/2 of CLKIN and the Cb and Cr rate are 1/4 of CLKIN.
When dedicated timing is used in this mode, there is a fixed relationship between the first active period of HS_IN (that is, the first CLKIN rising edge seeing HS active) and a Cb color component assumed present during that clock period on the input bus. When embedded timing is used in this mode, the SAV/EAV structure also unambiguously defines the CbCr sequence, according to ITU-R.BT656 (for 625I and 525I) and SMPTE293M (for 525P).
CLKIN is equal to 1x the pixel clock. This format is only supported in VESA mode and can be used for PC graphics applications that do not require full 8-bit resolution on each color component.
CLKIN is equal to 1x the pixel clock. This format is only supported in VESA mode and can be used for PC graphics applications that do not require full 8-bit resolution on each color component.
The clock generator/clock driver blocks generate all on-chip clocks for 4:2:2 to 4:4:4 and 2x video oversampling. The DMAN setting controls whether the input data is 4:2:2 or 4:4:4 sampled, and whether a 30-, 20- or 10-bit interface is used. This selection affects the clock input frequency assumed to be present on CLKIN.
The internal DLL (delay-locked loop) generates the higher clock frequencies. The user should program the input frequency range selection register, dll_freq_sel, according to the frequency present on CLK_IN when using either or both interpolation/oversampling stages.
The 4:2:2 to 4:4:4 stage is switched in or bypassed, depending on the setting of data_ifir12_bypass register (interpolation only on chroma channels). This feature should only be used with YCbCr 4:2:2 input. The THS8200 can perform color space conversion to RGB depending on the CSC setting. The dtg2_rgbmode_on register should be set corresponding to the color space representation of the DAC output.
The 2x oversampling stage is switched in or bypassed, depending on the setting of data_ifir35_bypass register.
The user should not enable the 2x oversampling stage when the CLK_IN frequency exceeds 80 MHz, as is the case for the higher PC graphics formats and 1080P HDTV. In this case the DLL should be bypassed using the vesa_clk register to disable the 2x frequency generation. As explained in the detailed register map description for this register, it is still possible to support 20-bit 4:2:2 input in this mode (for example, for 1080P).
A second bypass mode operation exists for the DLL, enabled by the dll_bypass register. When this bypass mode is active, the CLKIN input is assumed to be 2x pixel frequency.
THS8200 contains a fully-programmable 3×3 multiply/add and 3×1 adder block that can be switched in for all video formats up to a pixel clock frequency of 150 MHz. Color space conversion is thus available for all DTV modes, including 1080P and VESA modes up to SXGA at 75 Hz (135 MSPS). The operation is done after optional 4:2:2 to 4:4:4 conversion, and thus on the 1x pixel clock video data prior to optional 2x video oversampling. The CSC block can be switched in or bypassed depending on the setting of register csc_bypass.
Each of the nine floating point multiplier coefficients of the 3×3 multiply/add is represented as the combination of a 6-bit signed binary integer part, and a 10-bit fractional part. The integer part is a signed magnitude representation with the MSB as the sign bit. The fractional part is a magnitude representation; see the following example.
The register nomenclature is: csc_<r,g,b> <i,f>c<1,2,3> where:
For the offset values, a value of 1/4 of the desired digital offset needs to be programmed in the individual offset register, so a typical offset of 512 (offset over 1/2 of the video range) requires programming a value of 128 decimal into the offset<1,2,3> registers, where again <1,2,3> defines the output channel affected, with similar convention as shown previously.
Saturation logic can be switched in to avoid overflow and underflow on the result after color space conversion using the csc_uof_cntl register.
An example of how to program the CSC follows. This also explains the numeric data formats.
CSC configuration example: HDTV RGB to HDTV YCbCr
The formulas for RGB to YCbCr conversion are:
To program the red coefficient of channel 1 (Y) with the value of 0.2126 the following must be done:
Using the above method all the registers for the CSC blocks can be programmed with the correct value for RGB to YCbCr conversion. Below is a complete list of register values for the above conversion.
0.2126 → csc_ric1 = 00 0000 | csc_rfc1 = 00 1101 1010 |
0.7152 → csc_gic1 = 00 0000 | csc_gfc1 = 10 1101 1100 |
0.0722 → csc_bic1 = 00 0000 | csc_bfc1 = 00 0100 1010 |
−0.1172 → csc_ric2 = 10 0000 | csc_rfc2 = 00 0111 1000 |
−0.3942 → csc_gic2 = 10 0000 | csc_gfc2 = 01 1001 0100 |
0.5114 → csc_bic2 = 00 0000 | csc_bfc2 = 10 0000 1100 |
0.5114 → csc_ric3 = 00 0000 | csc_rfc3 = 10 0000 1100 |
−0.4646 → csc_gic3 = 10 0000 | csc_gfc3 = 01 1101 1100 |
−0.0468 → csc_bic3 = 10 0000 | csc_bfc3 = 00 0011 0000 |
For the offsets necessary in the second and third equation, the csc_offset<n> registers need to be programmed. Add 512 to the Cb and Cr channels. The value to be programmed is 1/4 of this offset in a signed magnitude representation, thus 128 or csc_offset2 = csc_offset3 = 00 1000 0000.
Packing these individual registers into the I2C register map, the programmed values are:
SUBADDRESS | REGISTER NAME | VALUE |
---|---|---|
0x04 | csc_r11 | 0000 0000 |
0x05 | csc_r12 | 1101 1010 |
0x06 | csc_r21 | 1000 0000 |
0x07 | csc_r22 | 0111 1000 |
0x08 | csc_r31 | 0000 0010 |
0x09 | csc_r32 | 0000 1100 |
0x0A | csc_g11 | 0000 0010 |
0x0B | csc_g12 | 1101 1100 |
0x0C | csc_g21 | 1000 0001 |
0x0D | csc_g22 | 1001 0100 |
0x0E | csc_g31 | 1000 0001 |
0x0F | csc_g32 | 1101 1100 |
0x10 | csc_b11 | 0000 0000 |
0x11 | csc_b12 | 0100 1010 |
0x12 | csc_b21 | 0000 0010 |
0x13 | csc_b22 | 0000 1100 |
0x14 | csc_b31 | 1000 0000 |
0x15 | csc_b32 | 0011 0000 |
0x16 | csc_offs1 | 0000 0000 |
0x17 | csc_offs12 | 0000 1000 |
0x18 | csc_offs23 | 0000 0010 |
0x19 | csc_offs3 | 0000 0000 |
CSC configuration example: HDTV YCbCr to HDTV RGB
In a similar manner, it can be calculated that the programming array is in this case:
SUBADDRESS | REGISTER NAME | VALUE |
---|---|---|
0x04 | csc_r11 | 1000 0001 |
0x05 | csc_r12 | 1101 0101 |
0x06 | csc_r21 | 0000 0000 |
0x07 | csc_r22 | 0000 0000 |
0x08 | csc_r31 | 0000 0110 |
0x09 | csc_r32 | 0010 1001 |
0x0A | csc_g11 | 0000 0100 |
0x0B | csc_g12 | 0000 0000 |
0x0C | csc_g21 | 0000 0100 |
0x0D | csc_g22 | 1000 0000 |
0x0E | csc_g31 | 0000 0100 |
0x0F | csc_g32 | 0000 0000 |
0x10 | csc_b11 | 1000 0000 |
0x11 | csc_b12 | 1011 1011 |
0x12 | csc_b21 | 0000 0111 |
0x13 | csc_b22 | 0100 0010 |
0x14 | csc_b31 | 0000 0000 |
0x15 | csc_b32 | 0000 0000 |
0x16 | csc_offs1 | 0001 0100 |
0x17 | csc_offs12 | 1010 1110 |
0x18 | csc_offs23 | 1000 1011 |
0x19 | csc_offs3 | 0001 0100 |
There are limits on the code range of the video data if sampled according to ITU or SMPTE standards. In other words, the full 10-bit range [0:1023] is not used to represent video pixels. For example, typically 64 decimal is the lowest code allowed to represent a video signal and corresponds to the blanking level. Similarly for Y, typically the maximum code is 940 decimal. Excursions outside this range can be the result of digital video processing.
THS8200 can handle such instantaneous excursions in either of two ways: by limiting the input codes to programmable max/min values, or by allowing such excursions to occur.
Depending on which approach is chosen, the user can scale up the video data in the CSM to make sure the full-scale dynamic range of the DAC is used for optimal performance when using limiting. Alternatively, the instantaneous excursions outside the code range can be output by the DAC in the analog output signal (allowing super-white/black in analog output) when this clipping is disabled.
The CSM block allows the user to specify the behavior of THS8200 with such reduced-swing input video codes. It consists of the following:
Clipping (limiting) of the video input data can be turned on or off on a per-channel basis, and selectively at the high and/or low end, by programming the csm_<gy,rcr,bcb>_<high,low>_clip_on registers. The high/low clipping values can be programmed on a per-channel basis using registers csm_clip_<gy,rcr,bcb>_<high,low>.
Figure 6-5 shows a typical situation to clip ITU-R.BT601 sampled video signals.
Next the video data can be shifted over a programmable amount downward. The number of codes over which to shift the input video data is set per channel by programming csm_shift_<gy,rcr,bcb>. Shifting of the input video data can be done downwards over 0..255 codes inside the CSM.
Figure 6-5 and Figure 6-6 also show the analog output from the DAC if the full-scale video range over the [64..940] input would correspond to the normal 700-mV range for component video. This full-scale range is set by the selected FSADJ full-scale setting (register data_fsadj).
When the 10-bit range is not fully used for video, scale the input video data to use the full 10-bit dynamic range of the DACs. Care should be taken not to overflow/underflow the available range after scaling.
This multiplying control serves two purposes:
Figure 6-7 illustrates a shifted analog ramping output. The multiplication factor could be calculated to scale this output range to the full 10-bit range of the DAC. Note that this scaling can be programmed individually per channel using registers csm_mult_<gy,rcr,bcb>. The range of the multiplication is 0..1.999, coded as a binary weighted 11-bit value, thus: csm_mult_<gy,rcr,bcb> = (Desired scale ( 0 to 1.999) / 1.999) × 2047.
Note that this approach allows to scale input code ranges that are different on each channel to an identical full-scale DAC output compliance, as is required for ITU-R.BT601 sampled signals where Y video data is represented in the range [64..940] and both Cb,Cr color difference channels are coded within the range [64..960]. All three channels need to generate a 700-mV nominal analog output compliance. Using a combination of FSADJ—adjusting the full-scale current of all DAC channels simultaneously in the analog domain—and digital CSM control, different trade-offs can be made for DAC output amplitude control, including channel matching.
As discussed in Section 6.7, the user also controls the DAC output levels during blanking, negative and positive sync, pre- and post-equalization, and serration pulses. Using a combination of CSM and DTG programming, it is therefore possible to accommodate many video standards, including those that require a video blank-to-black level setup, as well as differing video/sync ratios (for example, 10:4 or 7:3).
Finally, using the selectable full-scale adjustment from the FSADJ1 or FSADJ2 terminals, it is possible to switch between two analog output compliance settings with no hardware changes.
Physically, the CSM output is represented internally as an 11-bit value to improve the DAC linearity at the 10-bit level after scaling. Each DAC internally is of 11-bit resolution.
For relaxing the requirements of the reconstruction filter behind the DAC in the analog domain, and to take advantage of the high-speed capability of the DACs in THS8200, a 2x digital up-sampling and interpolation filter module is integrated.
Figure 6-8 through Figure 6-11 show the YRGB and CbCr filtering requirements for HDTV (SMPTE274M/296M standards) and SDTV (ITU-R.BT601 standard), respectively.
Figure 6-12 through Figure 6-14 illustrate the frequency and phase responses of the interpolating filters. The actual response using the finite-word length coefficients present in THS8200 is shown. The same filter characteristic is used for SDTV/HDTV modes and for both 4:2:2 to 4:4:4 interpolation (2 filters, one on each of Cb and Cr channels, switched in when a 4:2:2 input mode is selected on DMAN to interpolate chrominance from 1/2 to 1x pixel clock rate) as well as for 2x video oversampling (3 filters, one on each DAC channel, switched in when 2x interpolation is activated).
Each of the two interpolation stages can be switched in or bypassed:
THS8200 can generate dedicated Hsync/Vsync/FieldID video synchronization outputs, as well as a composite sync inserted on either the G/Y or all analog output channels. Both types of output synchronization can be available simultaneously and programmed independently. Synchronization patterns are fully programmable to accommodate all standard VESA (PC graphics) and ATSC (DTV) formats as well as nonstandard formats.
For the purpose of output video timing generation, the device is configured in HDTV, SDTV or VESA mode (dtg1_mode register). Depending on the selected DTG mode, a number of line types are available to generate the full video frame format. The timing and position of horizontal and vertical syncs, the position of horizontal and vertical blanking intervals, and the structure, position and width of equalization pulses, pre- and post-serration pulses within the vertical blanking interval are user-programmable.
The DTG determines:
The user should program the DTG with the correct parameters for the current video format. The DTG contains a line and a pixel counter, and a state machine to determine which user−defined line waveform to output for each line on the analog outputs. The pixel counter counts horizontally up to the total number of pixels per line, programmed in 'dtg1_total_pixels'. The line counter counts up to 'dtg1_field_size' lines in the first field, and continues its count up to 'dtg1_frame_size' lines in the total frame (field1+field2).
The current field is derived from the even/odd field ID signal, which is sampled at the start of the Vsync period. The source for the internal FID signal can be either the signal to the FID terminal, or can be internally derived from relative Hsync/Vsync alignment on the corresponding terminals, as selected by 'dtg2_fid_de_cntl' and the current DTG mode (VESA vs. SDTV/HDTV). See register map description of 'dtg2_fid_de_cntl' for more details. Derivation of FID from Hsync/Vsync input alignment is done according to the EIA−861 specification. There is a tolerance implemented on Hsync/Vsync transition misalignment. When the active edge of the Vsync transition occurs within ±63 clock cycles from the active edge of Hsync, both signals are interpreted as aligned, which signals field 1. Because of this timing window, the internal FieldID signal is generated later than the start of Vsync period. Since the signal is internally sampled at the start of the Vsync period to determine the current field, the field interpretation is opposite. Use the 'field_flip' register to correct this through field reversal.
If the video format is progressive, only field1 exists and no FID signal is needed. However the DTG will only startup when a field 1 condition is detected i.e when FID is detected low at the start of the Vsync period. Thus in the case of a progressive video format, and when using the device with external FID input, the user must make sure to keep the FID terminal low.
It is also needed for proper DTG synchronization that the programmed Hsync and Vsync input polarities are correct. Since Hsync, Vsync polarities change for different VESA PC formats, the device has built−in support to detect the incoming sync polarities. This is done by comparing the width of Hsync high ('misc_ppl') to the total line length ('dtg2_pixel_cnt') to derive the Hsync duty cycle and thus its polarity. Upon this detection, the user can program the detected incoming polarity for DTG input synchronization ('dtg2_hs_pol') – it is not set automatically by the device. The procedure is similar for Vsync polarity detection, using registers 'misc_lpf', 'dtg2_line_cnt' and 'dtg2_vs_pol'.
The DTG synchronization can be separated into three functions:
The DTG is based on a state machine that can generate a set of line types which can override the values on the DAC inputs. The DTG output is multiplexed into the data path by the DIGMUX. The selected video format preset setting, or the programmed (line type, breakpoint) table in case a generic mode is selected in dtg1_mode, determines which line type is generated for a particular line, and where this DTG output is used to override the normal DAC inputs. Internally, a fixed preconfigured number of line types exists from which the user can select.
Also, for each set of line types (there are two different sets of line types possible) the user can program the horizontal duration of each predefined excursion (negative sync, positive sync, back porch, front porch, broad pulse, interlaced sync, etc.) and also the amplitude (for example, negative sync amplitude, positive sync amplitude, blank amplitude).
The setting of dtg1_mode determines:
While the DTG has the flexibility to generate a wide array of video output formats and their synchronization signals, the most common video formats have predefined settings for the field and frame sizes and for (line type, breakpoint) settings.
When selecting a video format preset, the horizontal timings of the line types still need to be programmed. The preset only fixes the (line type, breakpoint) table.
The pixel and line counters of the DTG are reset by internal signals. In slave mode (THS8200 slaves to external video input source) these signals are derived from either the embedded SAV/EAV codes or the dedicated Hsync/Vsync/FID inputs. In master mode, these counters are in free-run and the HS_IN/VS_IN signals are generated by the THS8200 based on the programmed field/frame parameters. Master mode is only available for progressive-scan VESA modes. FID is not generated in master mode.
The user can delay, in both horizontal and vertical directions, the 0-reference of the DTG by programming the input delay registers. Physically, the horizontal and vertical DTG startup values are altered. The effect is that, when a vertical or horizontal sync is received, either from dedicated inputs or from embedded SAV/EAV codes, the output frame starts at position (x,y). This ensures that, for example, the output video frame can be centered on the display.
Based on the 0-reference of the DTG, the line types are generated and the DIGMUX will select between the video input and the DTG output for each line type. All horizontal timings of the different line types are programmable, including the portion of the video line seen as active video. A complete overview of all available line types in either SDTV or HDTV mode is presented in Section 6.7.3.
Additionally, Hsync/Vsync outputs can be generated, synchronized to the THS8200 DAC outputs. These outputs are programmable in width, position and polarity, based on the horizontal/vertical pixel counters, and thus independently of the DTG reference. This ensures that independent synchronization is possible between the composite sync output inserted into the DAC output(s) and the dedicated Hsync/Vsync outputs. Because of their programmability, these output signals could be used for other purposes as well; for example, Vsync could be programmed as a signal active during the VBI.
Figure 6-15 shows how the internal pixel and line counters are synchronized to internal HS and VS signals in slave mode. HS and VS are internal signals derived from either HS_IN, VS_IN, or from embedded SAV/EAV codes in the input video data. Since the 0-reference of the DTG is determined by these counters, the dtg2_vs_in_dly and dtg2_hs_in_dly register settings influence both HS_OUT, VS_OUT and composite sync output timing. The dtg2_vdly<1,2> and dtg2_hdly settings, on the other hand, only affect HS_OUT and VS_OUT, because they are downstream of the pixel counter. Likewise, dtg2_hlength and dtg2_vlength<1,2> only affect these dedicated sync output signals.
Note that both independent sets of delay registers allow accommodation of different input timing references in slave mode. When the device is configured in master mode, the delay registers can compensate for different external (frame memory) synchronization requirements.
The composite sync is generated from a programmed sequence of (line type, breakpoint) combinations, either user-programmed (in generic mode) or preset (in preset mode). The line type determines the waveform shape at the output of the DAC(s) with programmable amplitudes and timings.
On each line, at the horizontal reference point of the DTG, the DTG decides where to start/stop the DTG-generated data and where to pass input video data. For example, during an active video line, ancillary data can be embedded in the digital stream outside the active video portion of the line, that it might be necessary to convert to analog. Alternatively, during a nonactive video line, where normally the predefined line type would be inserted, ancillary data might need to be passed during the active video portion of the line.
The amplitudes of positive, negative sync excursions and of the negative serration, pre- and post-equalization and broad pulses are independently programmable between G/Y and BPb, RPr channels. Therefore sync insertion can be programmed on only the G/Y output or on all DAC outputs.
To limit the number of selection bits to select the line type, and because of the fact that a set of line types can be defined that is mutually exclusive for SDTV and HDTV video modes, there are two DTG video modes: SDTV and HDTV. There is a third DTG mode (VESA) which does not use the line type/breakpoint state machine and only generates Hsync/Vsync outputs.
These are the HS_OUT and VS_OUT signals, of which the width, position and polarity are programmable in all DTG modes.
When an HDTV mode is selected in dtg1_mode (preset or generic), a tri-level sync is inserted on the analog output at the start of every video line. The amplitudes during negative and positive excursions are programmable, as well as the horizontal timing parameters (width, position) of both excursions.
The transition time for negative-to-blank and blank-to-positive excursions during VBI is fixed to 2T, generating a tri-level sync negative-to-positive excursion of 4T. The line type is programmed in registers dtg2_linetype<n> and is output by the DTG from the vertical field/frame position corresponding to the line number programmed in register dtg2_breakpoint<n>, until the line number listed in the next breakpoint register is reached. An example for 1080I is shown in Figure 6-25.
The DTG overrides the input video data except where specified below for the specific line types.
The horizontal timings shown in Figure 6-16 and Figure 6-17 correspond to the dtg1_spec_<x> registers. Note that the f spec is fixed.
Device input data is passed during state #5 if dtg1_pass_through is on.
Example: 1080I/P
THS8200 is put into 1080I mode by programming dtg1_mode = 0001. Figure 6-25 shows the required output format of both fields for 1080I and 1080P.
When in 1080I preset mode, the (line type, breakpoint) table and frame and field size registers are filled out as follows internally:
Breakpoints | Line Type | |
6 | BTSP_BTSP | |
7 | NTSP_NTSP | |
21 | FULL_NTSP | |
561 | ACTIVE_VIDEO | |
563 | FULL_NTSP | |
564 | NTSP_BTSP | |
568 | BTSP_BTSP | |
569 | BTSP_NTSP | |
584 | FULL_NTSP | |
1124 | ACTIVE_VIDEO | |
1126 | FULL_NTSP | |
frame_size = 10001100101; 1125d | ||
field_size = 01000110011; 563d |
From line 1 to 5, line type BTSP_BTSP is generated. When the line counter reaches line 6, the DTG switches to line type NTSP_NTSP, etc. Note that the dtg1_spec_<x> registers need to be filled out with the correct values to set the horizontal line timings.
In SDTV mode, the start of a video line is signaled by the leading edge of a negative-going bi-level sync.
Device input data is passed during states number 4 and number 5 if dtg1_pass_through is on.
Video data is always passed during state number 5.
Video data is always passed during state number 5.
Video data is always passed during state number 5.
Example:525I
When the 525I preset is selected, the following line type sequence is active:
Breakpoints | Line Type | |
4 | NEQ_NEQ | |
7 | BSP_BSP | |
10 | NEQ_NEQ | |
20 | FULL_NSP | |
263 | ACTIVE_VIDEO | |
264 | ACTIVE_NEQ | |
266 | NEQ_NEQ | |
267 | NEQ_BSP | |
269 | BSP_BSP | |
270 | BSP_NEQ | |
272 | NEQ_NEQ | |
273 | FULL_NEQ | |
282 | FULL_NSP | |
283 | NSP_ACTIVE | |
526 | ACTIVE_VIDEO | |
frame_size = 1000001101; 525d | ||
field_size = 00100000111; 263d |
It can be seen this corresponds to the frame format shown, with 263 lines in digital field1 and 262 lines in digital field2.
THS8200 contains three DACs with an internal resolution of 11 bits, and maximum speed of 205 MSPS. This allows operation with all (H)DTV formats including 1080P, and PC graphics formats up to UXGA at 75 Hz.
The DAC output compliance can be selected between two full-scale ranges using the data_fsadj register. DIGMUX selects DTG output data during nonvideo line types, except when dtg1_passthrough is active: in this case video input data still is passed during the active video portion of certain line types, as identified in Section 6.7.3 on the DTG line types.
THS8200 supports output in either RGB or YPbPr color spaces. When using RGB output, the dtg2_rgb_mode_on register needs to be set. In this case an offset is added to all DAC output channels to provide headroom for the negative sync. Nominally the blanking level is at 350 mV, and the 700 mV swing extends upwards. Therefore peak white corresponds to 1.05 V. When YPbPr mode is selected on this register, the offset is only added to the Y channel output; Pb and Pr outputs now have a video range from 0 to 700 mV with 0 V corresponding to internal DAC input code 0 (note that due to the CSM block this could correspond to another device input code). The Cb and Cr chroma difference channels are thus assumed to be offset binary encoded, not 2s complement.
Finally, the DTG mode determines whether the DIGMUX switches in output data from the DTG. For example, in VESA mode the DACs are always driven by the video input bus. When the DTG overrides the video input bus in SDTV or HDTV modes, the actual amplitude levels output by the DACs during this time are user-programmable using the dtg1_<y,cbcr>_blank , dtg1_<y, cbcr>_sync_low, and dtg1_<y, cbcr>_high registers.
The following sections described some of the analog component video output formats that can be generated from THS8200.
In this mode, no sync signal is inserted on any of the analog outputs. HS_OUT and VS_OUT signals are generated for output video synchronization. This mode is commonly used in computer graphics video output.
Two levels of full-scale output can be selected by software. For video applications, the nominal voltage levels are 0.7 V and 1.305 V.
For component video applications, the nominal voltage level is 0.7 V; 1.305 V is used in NTSC/PAL composite video display. For composite video applications, the digital video stream must be encoded in an external digital NTSC/PAL encoder. The THS8200 only converts the digital composite signal to analog composite video. Figure 6-39 illustrates analog outputs without sync insertion.
When the THS8200 is programmed in this mode, it can also be used as a general-purpose DAC due to the linear response to the DAC input codes. Optionally, the CSM block can be bypassed to avoid any processing on the device input codes.
Figure 6-40 shows the linear DAC I/O relationship for either of the two nominal full-scale settings.
In this mode, a tri-level (HDTV modes)/bi-level (SDTV modes) sync signal is inserted into the G channel. The nominal analog output voltage range, which is from the sync tip to the peak of active video, is from 0.0 V to 1.050 V. During the active video period, the peak-to-peak ac value (dynamic range) is 700 mV (from 350 mV to 1050 mV). The blank levels on all three channels correspond to the bottom code 64 and are at 350 mV. Figure 6-41 and Figure 6-42illustrate the analog video output signals, both the output from the G channel with a tri-level or a bi-level sync pulse inserted, as well as the outputs from R and B channels. No sync signal is inserted during the sync period on R and B channels.
Alternatively, sync can be inserted on all three channels on THS8200 by appropriately programming the sync amplitude levels. On those channels where no sync is inserted, the blank levels are maintained at a 350-mV dc level.
The range of active video codes on the R, G, and B channels is from 64 to 940. By definition, code 64 corresponds to blank-level output, and code 940 corresponds to peak analog output. Input codes outside this region can either be clipped by THS8200 or can be passed, depending on the CSM setting. When passed, the user should make sure not to overdrive the DAC outputs outside the DAC output compliance range if instantaneously high output codes would occur.
This is another SMPTE-compatible RGB output. This mode is very similar to the mode described in Section 6.8.2, except the sync signals are inserted on all three channels. Now all three channels have the same analog output format, during both the active video period and the sync period.
In this mode, the output color space is YCrCb. The sync signal is inserted on the Y channel only.
The input code range of the Y channel is from 64 to 940, but the range of input codes of Cr and Cb is from 64 to 960.
The blanking level of all channels is at 350 mV. Note that for the Pb and Pr output channels, there is no dc offset added, so DAC input code 0 now corresponds to 0 V dc output. Whether or not offset is added to the DAC outputs is determined from the setting of the dtg2_rgb_mode_on register.
In this mode, sync signals are inserted on all three channels Y, Cr, and Cb. The Y channel output is identical to that of Section 6.8.4. The Pb and Pr channel outputs are shown below. The range of input codes to the Y channel is from 64 to 940. The range of input codes to the CrCb channels is from 64 to 960.
The ac dynamic range during the active video period is the same on all channels, 700 mV. This means that two different code ranges are mapped to the same analog output range. Because three DACs in the THS8200 share a common full-scale adjust resistor, therefore, different input codes to the DAC result in different analog outputs. To map two code ranges into a same analog output, the input code range must be scaled in the CSM block.
RGB WITHOUT SYNC | RGB SYNC ON G | RGB SYNC ON ALL |
YPbPr SYNC ON Y | YPbPr SYNC ON ALL | |
---|---|---|---|---|---|
Range of input codes | 0 to 1023 | 64 to 940 | 64 to 940 | 64 to 940 on Y; 64 to 960 on Cr and Cb |
64 to 940 on Y; 64 to 960 on Cr and Cb |
Peak level | 700 mV or 1305 mV | 1050 mV | 1050 mV | 1050 mV | 1050 mV |
Blank level | 0 V | 350 mV | 350 mV | 350 mV | 350 mV |
DC level shift during active video period | 0 | 350 mV | 350 mV | 350 mV | 350 mV |
The user can activate a 75% SMPTE color bar test pattern when the device is configured in VESA mode using the vesa_colorbars register setting. The width of each color bar can be programmed using the dtg1_vesa_cbar_size register.
The digital logic in front of the DACs can be completely bypassed and the DACs can be driven directly with levels programmed from the I2C interface by activating the dac_i2c_cntl register. In this case the dac<n>_cntl registers set the DAC input codes. A fast or slow ramp signal can be internally generated and sent to the DACs using tst_fastramp and tst_slowramp registers. This could be useful for a static DAC linearity test.
Alternatively, the input bus can directly drive the DACs when the tst_digbypass register is activated for tests at full speed.
The delay of the Y channel can be changed in YCbCr modes with respect to Cb and Cr channels by programming the tst_ydelay register.
Finally, there is a digital output port with data encoded according to ITU-R.BT656. This is a loop-through of the original input bus, prior to any THS8200 internal processing, and thus only provides standard data when input to the THS8200 is provided in a 10-bit ITU-R BT.656 format. This output bus could be used to connect to a separate NTSC/PAL video encoder. The data_clk656_on register activates the clock output on this bus and the data_tristate656 register disables the output bus. It is recommended to disable this output when not in use.
THS8200 implements two power-down modes: dac_pwdn powers down the DAC channels but keeps all digital logic active; chip_pwdn powers down the digital logic except the I2C interface. Activating both registers enforces a complete analog/digital power down except for the I2C interface.
The THS8200 can embed data within the vertical blanking interval, encoded according to the EIA-805 data insertion standard. CGMS is an implementation of the EIA-805 standard that defines data insertion in component video interface (CVI) video signals.
The THS8200 supports CGMS data insertion on line 41 of every frame in the 525P format. The data is inserted on the Y channel only; Pb and Pr channels remain at the blanking level. CGMS data insertion is enabled by activating the cgms_en register and programming the cgms_header and cgms_payload registers appropriately. The user needs to program header and payload data in the correct format, as no additional data encoding is done prior to insertion into the analog DAC output. The THS8200 only performs a play-out function for the programmed data. The CGMS encoding block assumes that a full 10-bit video range is used to determine the 70% of peak-white amplitude of a logic 1 bit, as prescribed by EIA-805. The CSM does not affect the amplitude of the CGMS data insertion.
CGMS is inserted on line 41 as prescribed by EIA 770 standards for progressive format display of SDTV. Fourteen bits can be inserted on this line, consisting of 6 bits header and 8 bits payload. The user can directly program these bits into the corresponding THS8200 registers. Care should be taken to format this data according to CGMS semantics; the user is referred to the original standards to determine header/payload data programming. To avoid the transmission of invalid data, the data transmitted is updated only when the CGMS register with the highest subaddress is programmed with cgms_en active.
CGMS insertion is possible in either 1x or 2x interpolated video modes of the THS8200. While EIA-805 allows the inserted data to change on every frame, and also allows data packets that would span multiple lines (and therefore also multiple frames, since only 1 line/frame is used for insertion), the THS8200 does not support multiline data insertion because it is not required for CGMS.
The THS8200 contains a slave-only I2C interface on which both write and read are supported. The register map shows which registers support read/write (R/W) and which are read-only (R). The device supports normal and fast I2C modes (SCL up to 400 kHz). The I2C interface is also operational when no input clock is received on CLKIN.
To discriminate between write and read operations, the device is addressed at separate device addresses. There is an automatic internal sub-address increment counter to efficiently write/read multiple bytes in the register map during one write/read operation. Furthermore, bit1 of the I2C device address is dependent upon the setting of the I2CA pin, as follows:
The I2C interface supports fast I2C, that is, SCL up to 400 kHz.
WRITE FORMAT
S | Slave address(w) | A | Sub-address | A | Data0 | A | ...... | DataN-1 | A | P |
S | Start condition |
Slave address(w) | 0100 0000 (0x40) if I2CA = 0, or 0100 0010 (0x42) if I2CA = 1 |
A | Acknowledge, generated by the THS8200 |
Sub-address | Sub-address of the first register to write, length: 1 byte |
Data0 | First byte of the data |
DataN-1 | Nth byte of the data |
P | Stop condition |
READ FORMAT
First write the sub-address, where the data must be read out to the THS8200 in the format as follows:
S | Slave address(w) | A | Sub-address | A | P |
S | Slave address(r) | A | DataN | AM | Data(N+1) | AM | ...... | NAM | P |
S | Start condition |
Slave address(r) | 0100 0001 (0x41) if I2CA = 0, or 0100 0011 (0x43) if I2CA = 1 |
A | Acknowledge, generated by the THS8200; if the transmission is successful, then A = 0, else A = 1 |
AM | Acknowledge, generated by a master |
NAM | Not acknowledge, generated by a master |
Sub-address | Sub-address of the first register to read, length: 1 byte |
Data0 | First byte of the data read |
DataN+1 | Nth byte of the data read |
P | Stop condition |
In both write and read operations, the sub-address is incremented automatically when multiple bytes are written/read. Therefore, only the first sub-address needs to be supplied to the THS8200.