• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 102 subscribers
  • Views 1212 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C6748 LCDC clarifications

Dean Hofstetter
Expert 2585 points

1.  For the C6748, the max PCLK out of the LCDC is 37.5MHz.  Is this correct?

Yes.  Verified by Mukul.

 

2.  This Wiki:  http://processors.wiki.ti.com/index.php/OMAP-L1x/C674x/AM1x_LCD_Controller_(LCDC)_Throughput_and_Optimization_Techniques has an entry in one of the tables that has PCLK set to 50MHz.  I've looked at all the devices this Wiki references, and I don't think ANY of the devices can support a PCLK of 50MHz.  I realize there is a note on the Wiki to verify the max PCLK for your device, but having the 50MHz in the table is mis-leading.  Is 50MHz a typo?

Max PCLK is indeed 37.5MHz.  Verified by Mukul.  I don't believe there is any device in the OMAP-L1x/C674x/AM1x family that supports a 50MHz PCLK, and thus it should be removed from the Wiki above to avoid confusion.

 

3.  What are the ramifications of running PCLK beyond 37.5MHz?  I realize at this point we are overclocking this peripheral, however is the 37.5MHz overly cautious?  Most of the 10.1" LCD panels we have looked at, require a PCLK in the 45MHz range.

As expected, overclock at your own risk.  TI guarantees nothing if you over stress the device.  Confirmed by Mukul.

 

4.  In the C6748 Tech Manual, when setting CLKDIV in the LCD_CTRL register, it states that using an odd CLKDIV value distorts the duty cycle.  Is this a recommendation to NOT use an odd value?  How bad is the distortion?

Never got a straight answer to this, other than "the duty cycle gets worse with odd dividers".  Would have been nice to know if it is something like 55% high / 45% low  ..or..  70% high / 30% low.  At this point, I'm going to play it safe and stick with even dividers.

 

5.  What is the size of the LCD FIFO?  I believe it is 512 dwords or 2048 bytes.

Mukul confirmed the FIFO has a maximum of 512 "elements".  Scroll down if you care to see how the "elements" are stored.  I believe Mukul's math is wrong, and the LCD FIFO is 2k bytes.  Not that it matters much.

 

6.  Once the LCD raster starts drawing down data out of the FIFO, what is the logic for the LCD DMA to keep it filled?  I understand that TH_FIFO_READY in the LCDDMA_CTRL register controls how many dwords must be in the FIFO before the raster engine can start consuming them, but what happens after the raster engine starts?  Basically I want to understand how often the LCD DMA will grab bytes out of DDR2 and place them in the FIFO.

This question was never really answered, other to say that the DMA will keep the FIFO full.  How it actually does that:  wait until FIFO half empty??, wait until FIFO has room for BURST_SIZE bytes??, is it a function of TH_FIFO_READY??, etc.  I'm concerned with FIFO underflow, as we have a ton of code / data in DDR2, plus our LCD panel is 1024 x 600, with 16bit color.  Lots of bytes to move and keep the FIFO happy.

 

7.  When the LCD DMA grabs bytes out of DDR2, it uses the BURST_SIZE setting in the LCDDMA_CTRL register.  A BURST_SIZE of 16 will equal 64 bytes.  Is this correct?

Yes.  Confirmed by Mukul.

 

8.  Once the raster engine outputs the last pixel, in the last line, it is done with that frame and done grabbing data out of the FIFO.  During the VFP + VSW + VBP time, is the LCD DMA filling the FIFO for the next frame?  If so, does it need to satisfy TH_FIFO_READY again before the next frame can start?

Yes, TH_FIFO_READY needs to be satisfied for each frame.  Confirmed by Sunil.  I assume this means that if you are getting FIFO underflow errors, you may need to increase VFP + VSW + VBP so the FIFO has a chance to fill for the next frame.

9.  Observation made by Sunil.  Make sure the size of the frame buffer is divisible by the BURST_SIZE.  If you don't do this, the words that are left over are transferred one at a time until complete, which increases the chance of a FIFO underflow.

  • 0
    Guru 31670 points

    Dean,

    What is the maximum resolution you would like to support? Since C6748 LCDC supports max of 1024x1024, the calculation for 30fps' frequency == 37.5MHz seems to be correct. If you want to use a smaller resolution than this, then this will not be an issue for you, I guess.

  • 0 in reply to Renjith Thomas
    Expert 2585 points

    Our LCD panel is 1024 x 600, 16bit color.  The datasheet for the panel has a minimum PCLK of 39.57MHz, and the maximum at 46.16MHz.  I'm not worried about frames per second at this time, just my questions in the original post.

    Thanks, Dean

  • 0 in reply to Dean Hofstetter
    Guru 31670 points

    Dean,

    I guess, 39.57MHz is required if you need 60fps refresh rate. I believe it should work easily in 37.5 MHz.

  • 0 in reply to Renjith Thomas
    Expert 2585 points

    I appreciate you trying to help, but so far we are getting no where.  I need the four questions in my original post answered.  Based on those answers, we will determine what is the best course of action to drive our LCD panel.  If you can answer any of the questions above, please reply.  Otherwise, please find someone within TI who can answer them.

    Thanks, Dean

  • 0
    TI__Guru* 83975 points

    Hi Dean

    For 1, Yes 37.5 MHz is the max PCLK supported

    For 2, We had done throughput analysis with higher than 50 MHz, in the hope that we could close timings at higher than 37.5 MHz, however based on design and char data we were not able to change this limit and it stays at 37.5 MHz. So the wiki warning to refer to datasheet is still valid and limits you to stick to datasheet specified range.

    For 3, Like any other timing parameters and max clock rates specified, running it beyond the specified limit , TI will not be able to guarantee that it will work across all conditions. We do not recommend you violate the datasheet estabilished max. Looking at additional discussion between you and Renjith, i would recommend exploring the option of running the PCLK at datasheet limit (lower than 45 MHz) to get lower fps (which seems acceptable), assuming your LCD panel allows this.

    For 4, we will need to get back to you on this.

    Hope this helps.

    Regards

    Mukul

  • 0 in reply to Mukul Bhatnagar
    Expert 2585 points

    While I continue to wait for an answer to #4, I have a few more questions.

    5.  What is the size of the LCD FIFO?  I believe it is 512 dwords or 2048 bytes.

    6.  Once the LCD raster starts drawing down data out of the FIFO, what is the logic for the LCD DMA to keep it filled?  I understand that TH_FIFO_READY in the LCDDMA_CTRL register controls how many dwords must be in the FIFO before the raster engine can start consuming them, but what happens after the raster engine starts?  Basically I want to understand how often the LCD DMA will grab bytes out of DDR2 and place them in the FIFO.

    7.  When the LCD DMA grabs bytes out of DDR2, it uses the BURST_SIZE setting in the LCDDMA_CTRL register.  A BURST_SIZE of 16 will equal 64 bytes.  Is this correct?

    8.  Once the raster engine outputs the last pixel, in the last line, it is done with that frame and done grabbing data out of the FIFO.  During the VFP + VSW + VBP time, is the LCD DMA filling the FIFO for the next frame?  If so, does it need to satisfy TH_FIFO_READY again before the next frame can start?

    Thanks, Dean

  • 0 in reply to Dean Hofstetter
    TI__Guru**** 177486 points

    Dean

    For question #4, I do see the duty cycle of MCLK gets a little bit worse with the odd clock divider than the even clock divider. So if it is possible, I would recommend to use even clock divider. If you have to use odd clock divider, what is the clock duty cycle requirement of the LCD display?

    Thanks

    David 

  • 0 in reply to David (ASIC) Liu
    Expert 2585 points

    The LCD panel datasheet doesn't spell out the duty cycle required.  Since you are unable to specify how bad the duty cycle gets, and I would have to work through many broken English emails to find out the required duty cycle for the LCD panel, we will just live with a even clock divider.  It reduces our max frame rate, but we should still be OK with an even divider.

    Please continue to work on the other questions (5 through 8).  Once I have everything, I'll summarize everything and mark the question as answered.

    Thanks, Dean

  • 0 in reply to Dean Hofstetter
    TI__Guru* 83975 points

    Dean

    Will try to knock a couple more outstanding questions...and we will provide clarification on the rest soon

    Dean Hofstetter said:
    What is the size of the LCD FIFO?  I believe it is 512 dwords or 2048 bytes.

    The FIFO is 512 elements  512x34 FIFO, each entry of which contains two 17-bit words (16 bits of graphics data and a 1-bit Frame Synchronizer flag). So for all practical purposes it is 1K byte

    Dean Hofstetter said:
    7.  When the LCD DMA grabs bytes out of DDR2, it uses the BURST_SIZE setting in the LCDDMA_CTRL register.  A BURST_SIZE of 16 will equal 64 bytes.  Is this correct?

    Yes.

  • 0 in reply to Dean Hofstetter
    TI__Expert 7470 points

    Dean,

    Dean Hofstetter said:
    6.  Once the LCD raster starts drawing down data out of the FIFO, what is the logic for the LCD DMA to keep it filled?  I understand that TH_FIFO_READY in the LCDDMA_CTRL register controls how many dwords must be in the FIFO before the raster engine can start consuming them, but what happens after the raster engine starts?  Basically I want to understand how often the LCD DMA will grab bytes out of DDR2 and place them in the FIFO.

    The DMA's function is to keep the FIFO full. So, as the raster engine consumes data, the DMA is initiated to fetch data from the frame buffer into the FIFO.

    Dean Hofstetter said:
    8.  Once the raster engine outputs the last pixel, in the last line, it is done with that frame and done grabbing data out of the FIFO.  During the VFP + VSW + VBP time, is the LCD DMA filling the FIFO for the next frame?  If so, does it need to satisfy TH_FIFO_READY again before the next frame can start?

    Yes, the DMA fills in data for the next frame and TH_FIFO_READY condition needs to be satisfied.

    Please also note the following comment from the TRM which is sometimes overlooked by users:

    "If the data left in the frame buffer is smaller than the DMA burst size, the DMA by default transfers 1 word (4 bytes) at a time until the entire frame buffer is transferred. This sometimes causes an input FIFO underflow, which can only be recovered through a Power and Sleep Controller (PSC) reset. Thus, it is recommended that the size of the frame buffer be divisible by the chosen burst size."

    Regards,

    Sunil Kamath

  • 0 in reply to Sunil Kamath
    Expert 2585 points

    Mukul / Sunil, thanks for your help answering these questions.  I've updated the original post so everything is in one place.  There are still a few un-answered points, but I think I have enough information to stabilize the LCDC in our system.

    Thanks, Dean