The present invention relates to methods for improving the synchronization in digital display application, and more particularly to horizontal synchronization vibration and remapping of the last horizontal synchronization line in digital display application.
As flat panel gets more popular, the image-scaling controller becomes more cost down and has more versatility for handling different input graphic timing to digital display devices.
Most of the scaler chips use Line Buffer structure instead of Frame Buffer structure, since Line Buffer structure can save more memory cost and chip pinout interface. Then how to minimize Line Buffer Size and keep acceptable scaling quality are the most important issues. However, less line buffer means it takes the risk of FIFO (first-in first-out) under-run or over-run when the relative timing between input graphic and output graphic is not precisely handled.
In general, for a given input graphic, V_ip_Active time (Vertical Input Active Time) must be equal to V_op_Active time (Vertical Output Active Time) in order to match the Line Buffer input write speed with the output read speed. However, the calculated HS_op_Total_dots (Horizontal output total dots) would not be an integer most of the time, therefore rounding HS_op_Total_dots to integer causes input active time not equal to output active time. In prior art, either a bigger Line Buffer size is kept to increase FIFO under-run/over-run tolerance or let the FIFO time in some input modes to be failed to handle.
Also, the calculated V_op_Total_lines (Vertical output total lines) is not an interger number after fixing output clock period and Hsync (Horizontal synchronization) period. The last fraction line will cause some panel displaying noises on the top of next screen.
The primary objective of the present invention is to provide two methods for improving the synchronization in digital display application. In a digital display, the vertical timing is partitioned into four segments:
VSync_PulseTime (Vertical Synchronization Pulse Time),
VSync_BackPorch (Vertical Synchronization Back Porch),
V_Display_Active (Vertical Display Active), and
VSync_FrontPorch (Vertical Synchronization Front Porch),
In V_Display_Active period, a preset output clock (no relation to input clock) is used to calculate ideal HSync output total dots (mostly a non-integer number), then distribute its fraction dots to some other lines. This could make HSync period change a little, sometimes longer, sometimes shorter, but its average period equals to the ideal HSync period. This method makes the FIFO timing perfectly match and is called “horizontal synchronization vibration”.
The second method is called “remapping”. When the calculated “Vertical output total lines” is not an interger number, the “dots of last VSync fraction line” is distributed to all VSync_Front Porch (or to other non-V_Display_Active segments), so the Short/Long line issue can be easily removed.
A scaler for digital display device has to support different resolution graphic or video from many different sources, such as ADC and DVI input. We might have graphic in XGA, SXGA, UXGA or other format, each might have different VSync/HSync frequencies. For Video inputs (i.e. ITU-R656, ITU-R601, etc. . . . ), we might have different timing video inputs, such as NTSC, PAL, HDTV, . . . etc. Each of them has to be shrunk (scale down) or enlarged (scale up) to fit the fixed panel resolution.
A digital display device, such as LCD panel, based on its physical material, defines fixed active display region (resolution). It allows wide range VSync and HSync periods, and also accepts a little timing variation. However, if HSync timing changes a lot, e.g. more than 10% of previous period, the display device might generate unwanted image, such as a garbage white dots, shorter/delayed image line, or flicking, . . . etc. So, it is very important to keep HSync period as steady as possible.
For graphic scaling, it can save design cost if we keep output refresh rate (VSync frequency) equal to input refresh rate; this is also called “Frame-Lock”. The following 3-cases implement Scaler with buffers:
1. Scaler with Frame Buffer
Some Scalers are designed with Frame Buffers. They are embedded with DRAM or hooked to external DRAM to avoid this timing issue. However, the cost for such system and chip is very high.
2. Scaler with More Line Buffers
Some Scalers are designed with more Line Buffers, which has extra buffers to keep more FIFO guard band (distance between write pointers and read pointers), so that it can track Frame-Lock over few frames, i.e., it does not have to perform Frame-Lock in every frame, and accumulates the last fraction lines of each ideal frame to some other frames. Therefore, each output frame has integer HSync line (no short/long line). However, some frame may have 1 line more or 1 line less than other frames. This non-Frame-Lock design will cause the distance (time period) varies between the first write pointer and the first read pointer in each frame. Thus, it needs more Line Buffer guard band. This solution uses more on-chip SRAM blocks and usually has bigger chip size.
3. Scaler with Few Line Buffers
Some Scaler designs, based on chip cost consideration, may have very limited buffer guard band, so normally it has buffer under-run/over-run, short/long-line issues, or both.
As Line Buffer is very small, if it is unable to maintain speed of buffer write-in and read-out, it is easy to have under-run or over-run issue.
For an input image, if the line buffer maintains a correct speed, the output image will look like input image as shown in
In under-run, the scaled image will duplicate some lines, and be unable to show the last input line. The output image will somewhat look like the graphic as shown in
In over-run, the scaled image will lose some lines, and duplicate the last few input lines. The output image will somewhat look like the image as shown in
However, besides carefully calculate output HSync Period, if the HSync period is allowed to be adjustable during active lines, it is possible to match exactly the same buffer speed, and then save the chip cost.
For ideal case, if the valid image range is selected to be scaled, say, input active image, the equation below has to be kept:
V_ip_Active time=V_op_Active time;
or precisely, in other way to express:
V_ip_Active (Line#)×HS_ip_Period (time) (HS means Hsync)=V_op_Active (Line#)×HS_op_Period (time); and
HS_op_Period (time)=CLK_op_period (time/dot)×HS_op_Total (dots);
So, HS_op_Total (dots)=(V_ip_Active (line#)×HS_ip_Period (time)/V_op_Active (line#))/CLK_op_period (time/dot);
However, it is 99% that this calculated HS op Total (dots) is not an integer, so the fraction portion of HS_op_Total (dots) for each output line will be accumulated during whole output V_op_Active period and to be a large number dots. Maybe it will exceed one line buffer, and cause under-run or over-run.
Therfore, we let the fraction portion of HS_op_Total (dots) to be distributed to some other lines to form HSync Vibration.
The present invention, called “HSync Vibration in Vertical active region”, is implemented by the following procedures:
Let HS_op_Total (dots)_Base=Integer (HS_op_Total (dots));
and
HS_op_Total (dots)_Fraction=HS_op_Total (dots)_HSop_Total (dots)_Base;
For every time the next output line is displaying, calculate:
HS_op_Total (dots)_Vary:=Fraction (HS_op_Total (dots)_Vary)+HS_op_Total (dots)_Fraction;
If (HS_op_Total (dots)_Vary<1), then the current output line will have HS_op_Total (dots)=HS13 op_Total (dots)_Base;
If (HS_op_Total (dots) Vary>=1), then the current output line will have HS_op_Total (dots)=HS_op_Total (dots)_Base+1.
Thus, the variance can be self-adjust. This is shown in
For some high speed panel with dual channel output, the above equations can be slightly modified as below:
Let HS_op_Total (dots)_Base=Integer (HS_op_Total (dots)/2)×2;
and
HS_op_Total (dots)_Fraction=(HS_op_Total (dots)−HS_op_Total (dots)_Base)/2;
for every time the next output line is displaying, calculate:
HS_op_Total (dots) Vary:=Fraction (HS_op_Total (dots)_Vary)+HS_op_Total (dots)_Fraction;
If (HS_op_Total (dots)_Vary<1), then the current output line will have HS_op_Total (dots)=HS_op_Total (dots)_Base;
If (HS_op_Total (dots) Vary>=1), then the current output line will have HS_op_Total (dots)=HS_op_Total (dots)_Base+2.
For a frame lock scaling system,
input frame time=output frame time
input frame time=V_ip_Total (line#)×H_ip_Total (dots)×Clock_ip_Period (time/dot);
output frame time=V_op_Total (line#)×H_op_Total (dots)×Clock_op_Period (time/dot);
For given Clock op_Period (time/dot) and H_op_Total (dots) (or after adjusted), calculate the V_op_Total (line#)=(V_ip_Total (line#)×H_ip_Total (dots)×Clock_ip_Period (time/dot))/(H_op_Total (dots)×Clock_op_Period (time/dot)).
Unfortunately, the calculated V_op_Total (line#) is also 99% non-integer.
Some panels cannot accept that the last fraction line is less than 90% duration of the previous line. So, current solution is optional to remove last fraction line by disable last output HSync pulse; or try to adjust output clock or output HSync period.
The present invention is to remap the last fraction line to other non-active output lines, so that some output HSync lines may have more dots, but still in the HSync vary tolerance (normally, 10% variance range) of panels.
The drawing in
Therefore, the present invention provides a method to distribute the dots in the last fraction line to the previous several lines. The previous several lines are in the VSync_FrontPorch segment as shown in
Additional dots of each remapped lines=Roundup of [(Dots of last fraction line)/(number of the remapped output lines)] ∘Roundup means that fraction part will be omitted and let the integer part to be increased by “1”.
To well distribute those dots of last fraction line, it is better to have more remapped output lines. It can be whole output lines if there is no line buffer under-run/overrun issue, or it can be non-Active lines or just the vertical front porch lines.
The spirit and scope of the present invention depend only upon the following Claims, and are not limited by the above embodiments.
Number | Date | Country | |
---|---|---|---|
Parent | 11092938 | Mar 2005 | US |
Child | 12071547 | US |