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.

Source of noise when using PRGB output?

Other Parts Discussed in Thread: THS8200

Hello,

I have a custom PRGB to LVDS daughtercard on my DM355 EVM driving a 1280x768 LCD.  I supply a 74.25MHz clock from the daughtercard.  I've developed a similar daughtercard for the DM6446 and was able to get quite good quality video.  However, on the DM355 I'm seeing noise that has me stumped.

Please excuse the poor quality of the attached photo, but it gets the idea across.  In the photo, I am using the decode demo to display a test pattern that I captured using the encode demo.  The displayed image and the captured image are both at 720x480 resolution.  The video looks fine on the standard NTSC output, with and without the on screen display.

However, when I switch to PRGB output, using the driver code developed for my DM6446 project, the image is quite noisy.  In the photo, the worst of the noise is in the top half of the image.  The decode demo OSD is not displayed, but the OSD is active and squeezed into the top half of the image on purpose for debugging.  When the OSD is disabled completely, the noise is much less severe, as it is in the bottom half of the photo.

What am I seeing here?  Anyone have any experience with similar noise?

Thanks!

-Vim

 

  • Thank you for posting the image, it really helps to show what you mean :). I believe what you are looking at is memory bandwidth saturation causing the VPBE to be unable to meet real time deadlines in servicing the display. You can see where individual lines are missing and shifted when the deadline is broken, it ends up looking like random horizontal lines popping up randomly on the screen, also this explanation is congruent with your observation that the OSD when enabled makes things significantly worse, an OSD window being enabled means another mass of memory accesses in addition to the video itself making the effect more pronounced.The DM6446 that you had working with good quality before has 2x the DDR bandwidth available (32 bit vs 16 bit bus) making the probability of such effects actually appearing much lower.

    To make this better, the first area as you have suggested improves things already would be to lower the amount of bandwidth being used by the OSD, any other display windows you have open will be slowing things down and exaserbating this issue. The other step you may want to take is to try adjusting the PBBPR register discussed in section 4.7 of SPRUEH7d, this can help to alleviate these sorts of issues. I dont have all of my materials in front of me at the moment, so I may have some more suggestions for this issue tomorrow.

    As a general note, you will have a hard time supporting true 720p60 or higher output on the DM355 without the higher frequency 270MHz version (not the 216MHz on the EVM).

  • Thank you Bernie, that was very helpful.

    A couple of followup questions:  

    Does increasing the clock frequency (to 270MHz) also increase the DDR clock yielding increased memory bandwidth?  

    You say there aren't 270MHz EVMs.  Short of building my own main board, how can I evaluate a 270MHz version?

    Cheers,

    -Vim

  • Vim Venture said:
    Does increasing the clock frequency (to 270MHz) also increase the DDR clock yielding increased memory bandwidth?

    The 270MHz does not increase the clock speed but it does open up the device to do more than just service the display when working with HD resolutions, if all you plan on doing is displaying images, like a slideshow, than you can get away with less, but if you plan on having video on a 720p display the extra processor bandwidth ends up being necessary. If you really want a HD solution (with video) than you probably want to consider the newer DM365 that was recently released. With the EVM you have you should be able to get the 720p output stable with thePBBPR adjustment, the value ends up being system specific but you may want to try around 0x30 to start, from there it tends to be trial and error. Note that the less your system is doing outside of just the display the less likely you will see the artifacts on the display, if you have the ARM or the accelerators doing a lot of work in the background it can bring up these artifacts. 

    Vim Venture said:
    Short of building my own main board, how can I evaluate a 270MHz version?

    You would probably have to build your own board, in general the 270MHz devices can be hard to come by though, you may want to work with your local sales office on this topic as they may have other options.

  • Once again thank you for an informative post Bernie.  Most helpful.

    I have been planning on moving to the DM365 when it becomes available because it looks like I need to do just a little more than the DM355 was designed for, but as I learn more about the DDR constraints from the 16 bit data path, I'm beginning to have concerns.  It looks like the DM365 has the same memory architecture as the DM355, so I would run into the same problem I am having now.  Granted, I do have a 216MHz 355, so I may still be OK with the faster parts.  I'm seeing if I can track down a 270MHz version now.

    On my DM355, I get perfect output using internally generated color bars, no noise anywhere on my 1280x768 LCD.  But, I have not been able to reduce the noise present when playing back a video.  I've "fbset -fb /dev/fb/X -xres 0" for vid0,osd0,osd1 so I'm only using vid1.  I've tried setting the PBBPR register from 0x01 to 0x60 without much change in the output.  Low values (1-6) seem to compress the noise at the top 1/5th or so of the display for some reason, otherwise I didn't see much change.

    So, I'm running out of options.  Do you have any more ideas of areas that might be helpful to look into?

    Cheers,

    -Vim

  • First I would like to correct something said previously, it does look like the device speed grade has an effect on the maximum DDR  frequency that can be supported althought this is not obvious from the documentation (looking to change this). The 270Mhz devices are good up to 216MHz on the DDR whereas the 216MHz devices are good up to 171MHz on the DDR.

     

    Vim Venture said:
    It looks like the DM365 has the same memory architecture as the DM355, so I would run into the same problem I am having now.

    You make a good point here, though there must be some difference somewhere, as I have seen the DM365 decode and display 720p video with no artifacts on the display already, I think the DDR collateral for the DM365 is still being polished, I am not sure what the final speed capabilities will be off hand.

    Vim Venture said:
    Do you have any more ideas of areas that might be helpful to look into?

    I am working to get an internal document on this very subject published that may be of further help in explaining things and showing how best to configure the system for 720p display (I hope to see it published this week). The main other setting that you may want to try changing is the TC RDRATE register (EDMA3 Transfer Control Read Rate (TC RDRATE): 32 bit registers at 0x01C10140 and 0x01C10540) to a value of 0x2

  • Thanks Bernie!

    Setting those TC RDRATE registers to 0x04 did the trick for me.

    OSD still kills the display, but with it off I can get good video decode and display (no sound at this point though).

    Cheers,

    -Vim

  • I am glad to hear it :), hopefully the more thorough document on this issue and working around it will be out soon to help others but for now I am glad to hear that the basic settings described in this thread are working for you.

  • Hi Guys,

    I spoke with Bernie today on the phone about this same issue of getting 720p playback on the DM355-216 chip.  I have a couple of clarifiying questions that I was hoping you could answer.

    1.  Have you successfully gotten the DM355-216 to playback 720p video with stereo audio?

    2. If the playback w/ audio was successful, what else besides modifing the values for the "TC RDRATE" was necessary?

    Thanks,

  • I have posted in a different thread what i think is the cause for the noise - i do not think that the bandwidth settings are the issue here; try toggling the VCLKP (clock polarity bit) in the VIDCTL register. This will allow for proper data/clk timing so that the data 'eye' is in the middle of the clock transition.

  • JerryJohns said:
    I have posted in a different thread what i think is the cause for the noise - i do not think that the bandwidth settings are the issue here; try toggling the VCLKP (clock polarity bit) in the VIDCTL register. This will allow for proper data/clk timing so that the data 'eye' is in the middle of the clock transition.

    I think this part is specific to the general Davinci -> THS8200 issues regarding the 1.8v timing if I am not mistaken, more of a secondary problem though it may also apply to other digital video interfaces as well. I assume this means that you do have stable 720p@30fps decode and playback on a 720p60 display (though THS8200 in this case) on a 216MHz DM355?

    EDIT: Was a bit confused there for a minute since there are two people in the thread now :), Vim Venture was originally working with a directly connected LCD for 720p and not THS8200, though I am certainly interested if anyone can manage a 720p60 display with 720p30 MPEG4 decode on it with a 216MHz DM355, as I was under the impression from internal testing that it was not practical to perform video decode and 720p HD display with the 216MHz device due to DDR bandwidth.

  • Just a quick follow up on this, there is a new article on this sort of issue just published today at http://wiki.davincidsp.com/index.php?title=DM355_HD_Display

  • Excellent article summing up all this goodness.  Thanks Bernie.

  • A follow up question of my own:

    As I posted earlier, setting TC RDRATE to 0x04 eliminates this noise for me (DM355-216, PRGB output to 1280x768 LCD via custom daughter card), but I do not get the FPS performance I need.  One tick up to 0x03 gives me marginally OK FPS performance, but this EDMA transfer noise shows up again.  So I'm stuck.

    That Wiki article covers TCRDRATE and PBBPR registers, but I'm wondering if there are any other areas I can look at to tune? 

    Thanks!

  • Vim Venture said:
    That Wiki article covers TCRDRATE and PBBPR registers, but I'm wondering if there are any other areas I can look at to tune? 

    The wiki article covers most everything that TI was able to do to get stable high definition output on the DM355, so I do not believe there is anything else that you could do to tune the system other than lowering other accesses to the DDR (i.e. disable any background processes), or increasing the DDR frequency.

  • hi  Bernie,

    I'm using 216M DM355 to display 720P, and got the same problem as above, as your suggest to change TC RDRATE and PBBPR, but how can I change this specially the TC RDRATE register? I use writeb(val, addr)  write1(val, addr) and davinci_write1(val, addr) but all this make the kneral stop there; so any help?

    thanks

  • Eric,

    I would recommend first testing if adjusting PBBPR register fixes the issue you are seeing by issuing simple command at linux prompt as follows

       echo "20000020 30" >/sys/class/davinci_system/system/reg

    20000020 being the address of the register and 30 being the PBBPR .  If this does not fiex things, you may want to read http://wiki.davincidsp.com/index.php/TMS320DM355_High-Definition_%28HD%29_Display to understand the nature of the issue better.  Finally, if you need to adjust PBBPR register permanently, this register is set in u-boot, so you will need to make the code change there.

  • To set TC RDRATE, I used 

            davinci_writel(0x03,0x01C10140);

            davinci_writel(0x03,0x01C10540);

    in ti-davinci/drivers/media/video/davinci/davinci_platform.c

  • I have change the PBBPR to 0x10 and RDRATE to 0x2 but still have little noise, but you know I have disabled OSD0,1 and VID1, only use VID0, which I thank it's the smallest consume DMA, but still have little noise, I have no idea what to do, so, someone can help me?

  • Eric Hou said:
    I have change the PBBPR to 0x10 and RDRATE to 0x2 but still have little noise, but you know I have disabled OSD0,1 and VID1, only use VID0, which I thank it's the smallest consume DMA, but still have little noise, I have no idea what to do, so, someone can help me?

    As mentioned previously in this thread your best bet is to try the configurations given in this article though I suspect you have already seen it, unfortunately 720p on the DM355 may take some fine tuning. You mention you are using PBBPR of 0x10, have you tried some other values? The value that was found to work best here was around 0x30, though this was found with trial and error and can vary based on system conditions so you may have to try a few values to see if you can get any improvement.

  • Bernie,

        As mentioned above, I have tried some other values on PBBPR and it's best on 0x10, so, any other advance?

       By the way, I suspect if the the VPBE haven't got the external Clock which generate by CDCE on THS8200, so, how could I do to make sure it has worked? also, your datasheet has some confuse on the register  discribed like VPSS_CLK_CTRL and VPSSCLK, you know it can't mach values with I read from the register, and confuse their addr in the data-sheet, so, I just think you should know this. better advance please let me know.

                                                                                                             thanks

                                                                                                                                           Eric

  • Juan,

           I read the artical many times and I want to ask: if I use 216M DM355 and 171Mx8bank DDR, Can I got the 720P HD display, the means too much for me, because if it can't, I will change a new chip and if it could or someone has make it worked, I will work on it untill I success,

                                                                                                                                                                thanks

                                                                                                                                                                        Eric

  • Do you have anything else going on in your system (encode, decode, resize...)?  If so, then this is likely not possible.  I am looking into this, but to be honest, we normally recommend that customers wanting to do HD video applications consider DM365 instead.

  • In general you will want to have the 270MHz device with the faster DDR for 720p applications, the original author of this thread mentioned settings he was able to get 720p output going on with a 216MHz part, however in general we do not recommend the 216MHz device for 720p, as you will likely end up with the horizontal line noise you have been seeing. Since the DM365 is available you may want to consider migrating to it as Juan suggests.

  • I just got confirmation from one of our customers that they were able to see 720p @ 30fps video on 216 MHz DM355 part, but as soon as you turn on OSD overlay, then you see the noise discussed in the article.  I am afraid that if you do anything other than display which required DDR2 bandwidth, you may get into trouble with 216 MHz part.  As the wiki article suggest, it is better to use 270 MHz DM355 parts for HD display, but an even better option from a performance point of view is DM365

  • Juan,

            As you mentioned above, Can I just thought 270M DM355 can do this better without noise? we just need decode and display on VID0, you know, I have disabled VID1, OSD0, OSD1already and don't use resize, Have any one use 270M DM355 to do this success?  that means too much for me, because I have worked on this for months, and almost success but this problem,  also we can got 270M 355 easy, so, Please let me know if anything can help me to solve this problem or any advice

                                                                                                                                             thanks

                                                                                                                                                     Eric

  • 270 MHz versions of DM355 are very hard to come by; the customer I mentioned above seem to have 720p video display (no OSD) working on 216 MHz version of DM355, but not much else going on in their system.

  • Juan,

           We have someone to look for 270M 355 now, because we have done everything but this problem, if 270M 355 can work well, we will use 355,  and as your suggest, I'm working on DM365 now, but where can I got the packet like kernel and dvsdk?  you know we have an 365 BETA borad without enought update soft, any suggest may help me please let me know!

  • Juan,

             also, DM365 have 216M, 270M, 300M, and which one would be best for me just decode the net_stream and display on 720P? and how can I know which Frequency I'm using when I can't got it in Uboot booting message? thanks

  • Bernie,

               I'm working on DM365 BETA_borad and got some qusetion, when I use bootargs like:

    setenv bootargs mem=80M console=ttyS0,115200n8 root=/dev/mtdblock3 rw rootfstype=yaffs2 ip=off video=davincifb:vid0=1280x720x16,5529K:vid1=off:osd0=0,0K:osd1=0,0K davinci_enc_mngr.ch0_output=COMPONENT1 davinci_enc_mngr.ch0_mode=720P-60

    I got message:

     

    vpfe ccdc capture vpfe ccdc capture.1: vpif_register_decoder: decoder = TVP514X
    i2c_adapter i2c-0: THS8200 encoder initialized
    i2c_adapter i2c-0: i2c read error
    i2c_adapter i2c-0: Resetting THS8200 card
    i2c_adapter i2c-0: i2c write error = ffffff87
    i2c_adapter i2c-0: i2c write error = ffffff87
    i2c_adapter i2c-0: i2c write error = ffffff87
    i2c_adapter i2c-0: i2c write error = ffffff87
    i2c_adapter i2c-0: i2c write error = ffffff87
    i2c_adapter i2c-0: i2c write error = ffffff87
    i2c_adapter i2c-0: i2c write error = ffffff87
    i2c_adapter i2c-0: i2c write error = ffffff87
    i2c_adapter i2c-0: i2c write error = ffffff87
    i2c_adapter i2c-0: Failed to Program CDCE Clock Synthesiser

     

          As DM365 has intergrate THS8200 why I got this problem, you know I haven't got kernel source code yet, and also this kernel haven't an login name so it just go in system and run the demo and the system can't got CTRL+C so I can't go in system to control this, how could I do?

     

    MontaVista(R) Linux(R) Professional Edition 5.0.0 (0801921)

    (none) login: i2c_adapter i2c-0: tvp514x_setinput:lost lock]
    /opt/lsp_demos/audio_loopback: relocation error: /usr/lib/libasound.so.2: symbol , version GLIBC_
    2.4 not defined in file libc.so.6 with link time reference
    i2c_adapter i2c-0: tvp514x_setinput:lost lock]
    i2c_adapter i2c-0: tvp514x: no input connected
    vpfe ccdc capture vpfe ccdc capture.1: Unable to get standard from decoder
    vpfe ccdc capture vpfe ccdc capture.1: Error in initializing channel
    InitDevice:open::
    setting data format
    Detecting if driver supports COMPONENT
    Can't detect input  from the capture driver
    : Bad file descriptor
    Error in setting capture format
    Failed to intialize capture
    main : Leave

  • Eric Hou said:
    We have someone to look for 270M 355 now, because we have done everything but this problem, if 270M 355 can work well, we will use 355,  and as your suggest, I'm working on DM365 now, but where can I got the packet like kernel and dvsdk?  you know we have an 365 BETA borad without enought update soft, any suggest may help me please let me know!

    The latest DVSDK versions can be downloaded from http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/index.html, in the case of DM365 as of today you would need to use the DVSDK 2.10, and I would certainly recommend using this latest version, if you have a beta board than your software is likely out of date unless you have downloaded a newer version, and many issues have been fixed that were in the beta with the GA release available at the site above.

    Eric Hou said:
    also, DM365 have 216M, 270M, 300M, and which one would be best for me just decode the net_stream and display on 720P? and how can I know which Frequency I'm using when I can't got it in Uboot booting message?

    The 270MHz should work (assuming MPEG4, 720p H.264 requires 300MHz, see codec availability schedule for details) but 300MHz would give you more head room for other processing. The EVM comes with a 300MHz grade device, and I believe the current DM365 U-Boot will configure the PLLs for 300MHz operation.

    Eric Hou said:
    I'm working on DM365 BETA_borad and got some qusetion, when I use bootargs like:

    setenv bootargs mem=80M console=ttyS0,115200n8 root=/dev/mtdblock3 rw rootfstype=yaffs2 ip=off video=davincifb:vid0=1280x720x16,5529K:vid1=off:osd0=0,0K:osd1=0,0K davinci_enc_mngr.ch0_output=COMPONENT1 davinci_enc_mngr.ch0_mode=720P-60

    It looks like you are configuring the driver to try to use a THS8200 that does not exist, the encoder manager output only applies to other devices where a THS8200 was necessary. If you use the default bootargs as discussed in the alternate boot methods section of the DM365 GSG than you should have 720p output ready to go with the demo.

    As a side note, for continued discussion on the DM365 please make a new thread, this thread is specific to DM355 720p noise.

  • Bernie,

           sorry, one more question as we discuss in this thread, as the 365 demo fuction don't have an login name and password so it just run the demo without an pause and as the kernel don't accept an CTRL+C, so I  can't got an teminal to access and control system, how could I do? also, as the chip and Uboot message don't have any info about  DM365 frequency, how can I know it? because I should know 216, 270 or 300M frequency which I'm using unless make a big mistake again like DM355, thank you