LVDS LCD with DM8148 through Serialisier

Hi Padmanabhan,

Please refer to the below links:

http://processors.wiki.ti.com/index.php/LCD_connectivity#Connection_to_LVDS_LCDs

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/288204.aspx

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/137043.aspx

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/124583.aspx

http://e2e.ti.com/support/arm/sitara_arm/f/791/t/256840.aspx

Regards,
Pavel

Regarding whether you can see any impact in image quality, it really depends on what images you are displaying. You inherently have 1/4 the dynamic range.Sharp computer generated images typically don't show any artifacts but computer generated shaded regions or things like soft sky/sea  images in video will show banding.

Using 6 bits per color channel typically shows 'banding' on shaded color regions. This is an inherent limitation of 6 bits per color channel though.

The only thing you can do to mitigate this display artifact is to dither the output. Dithering sacrifices spatial dynamic range for color dynamic range, meaning it basically smears the image a little so that there are not sharp contour boundaries hence banding is less visible. This dithering would need to be done in software by manipulating the frame buffer. Check Google for more information on dithering.

BR,

Steve

Steve,

Thanks for your reply.

We would be hooking up our LCD subsystem to the DM8148 eval board and testing it out. Shall post the updates later .

Regards,

Padmanabhan

Hi Guys

We are running into some issues with benchtop wiring and testing. Below are the queries. It would be helpful if you guys can help with your inputs/comments

1. Is the serialiser (DS90C363B) selection dependent on LCD resolution. The 363B datasheet specifies that it supports VGA, SVGA, XGA and Dual Pixel SXGA. Is this list exhaustive? If not, does it mean resolutions in-between these standard resolutions are also supported? Our application uses WVGA (800x480) resolution.

2. We are noticing jittering (vertically) while using the recommended LCD pixel CLK Frequency (33.5MHz). But on doubling the pixel clock frequency to 67MHz, the jittering disappears and the image is perfectly ok. What is it that we are missing here? On checking with the LCD supplier, their recommendation is to use a max pixel clock frequency of 40MHz.

Regards,

Padmanabhan

This serializer should be good for all resolutions up to the max pixel rate of 65MP/s. The format is not important, only the pixel rate.

Make sure that all power supplies are good and clean.

Using an oscilloscope make sure that the setup and hold timing for the input to the serializer is valid.

Using an oscilloscope make sure that the timings of H, V & DE feeding in to the serializer are valid as per the LCD datasheet.

BR,

Steve

Hi Steve

Thanks for your suggestions.
While probing the DE line , the display actually stopped jittering. So adding a 100pf on the DE line 'fixed' the issue or did it?.......

... Curiously, we noticed that the the data on TxIN lines are actually switching states on the falling edge of  TxCLK IN. This is completely opposite to the setup/hold timing diagram as captured in Fig 7 of DS90C363B datasheet. We setup the serialiser with Pin14 - (i) Open [Falling Edge Strobe] (ii) Pulled up to VCC through 10K [Rising Edge Strobe]. The timing waveform were exactly the same for both cases and remain the same as explained above and so does the jittering (100 pf Cap removed btw). Does that mean there is a violation in the setup/hold timing? 

Also, is there a way to control to the Pixel CLK?

Hypothetically, if we were to invert the CLK, all timing spec would be met. I shall try to test out the same using an inverter externally and whether that does help to remove the jittering(without the 100pf Cap on the DE line).

Steve,

You are referring to tie to R_FB pin to high isn't it?  I have already done that and there is no change in the waveform. Data seems to switch only at the falling edge of the TxCLK IN - irrespective of the R_FB pin being high or NC.

Any other way to do it ? 

Thanks for support!

Pin 14 on the DS90C363B will not change now the signals look between the DM processor and the DS90C363B. It changes the way that the DS90C363B looks at the signals.

Output data from the DM cannot be changed, this is why you need to tell the DS90C363B to look at the opposite clock edge which is done by changing the state of pin 14.

BR,

Steve

Steve, 

I should have added that changing R_FB pin didn't solve the problem. 

So the only way the current mock up test up works ok when

a. 68pf or 100pf cap is added to the DE line (Setup timing doesn't meet spec though as mentioned earlier ) 

b. 68pf or 100pf AND Inverter on CLK line ( Setup Timing does meet spec in this case) 

For b,  DE line without cap doesn't work. So is the Cap on the DE line is really onto something isn't it? May be in an actual pcb,  the behaviour might be different? 

Fundamentally you have a timing violation which you need to fix.

I suggest first capturing eye diagrams at the DS serializer for DE and all the data signals to check that which signals are violating timing.

Also check the integrity of the clock signal at the serializer. If the clock is distorted and/or does not have good sharp edges then this will also reduce your effective timing margins.

BR,

Steve

Ok., noted. Shall look into it.

Thanks, as always.

Regards,

Padmanabhan