IPIPE AND MPEG4 ENCODE CAN'T WORK AT THE SAME TIME

can you explain what you mean by the image is broken?  How many display buffers are you using; if you are decoding, you should use at least three (see http://e2e.ti.com/forums/p/6061/23307.aspx#23307 ).

To my knowledge, there is no reason why IPIPE and MPEG4 encode cannot work together; as a matter of fact they do in our demos (use resizer along with mpeg encode/decode).  Therefore, this may be a resource issue (e.g. working on same buffer at the same time), hence my question above.

thank you for the additional feedback; based on your latest description, it appears you are working with HD resolutions and require a high refresh rate.  We have found that in some situations, capturing or displaying HD resolutions while doing too many other tasks in you system can sometimes lead to artifacts that show up as white horizontal lines in your screen; I am wondering if you are running into this scenerio...  We have put together a wiki article that details our investigation using various HD video scenerios that you may find helpful. 

http://tiexpressdsp.com/index.php?title=TMS320DM355_High-Definition_%28HD%29_Display

william.zhou said:

If  the source is  YCC16 data format, I can't direct pass to ipipeif  from ccdc, so I must first save the yuv data to sdram, and then pass to ipipe to do resize。Is it right ?

from a hardware point of view, ipipe can receive data from CCDC or SDRAM; however, in software only the SDRAM path is implemented;  if you want to pass data directly from CCDC, you will need to modify the driver yourself.

Thanks Juan!

(1)I don't display HD resolutions。My scenerio is 1920x1080 source，culling it at ccdc to 960x1080, and then do resize in RZ0 and RZ1, the result of RZ0 is 720P for encodeing movie, the result of RZ1 is 480P(VGA) for display。

(2) As seeing in the picture above cutting from VPFE document。It seems only raw data input can direct passing to IPIPE module, it needn't first save to sdram。The YCbCr must first save to sdram, and then pass to ipipe。My idea is if it can direct pass it to IPIPE, it can use pixel_clk, so the process rate is quickly enough。

Any help is grateful!

Please note that many of the scenerios described in the wiki article I referred you to suggest memory bandwitdth limitations; you are more likely to run into these bandwidth limitation when using HD display, but it does not mean that HD display is the only reason you will experience this.   We need to take your whole system into account as HD capture also consumes large amounts of memory bandwidth; throw in resizer and then try to do some display you are likely to see the same limitations come up.

The wiki article suggest some things that may help, such as programming other values into PBBPR register.... this is why I thought it may help you understand the limitations and make use of some of the recommendations.  Having YCbCr data go directly from CCDC to IPIPE may help as well; unfortunately, the driver support is not there for this hence you will need to do some driver mods yourself.... If you are indeed running into bandwidth limitation, you may want to consider DM365 as an alternative...

william.zhou said:

I try to upgrade it to 270MHz below

    PLL1->PLLM = 179;                        // PLL1 24 * (179 + 1) / (7 + 1) = 540MHz
    PLL1->PLLDIV1 |= 0x8000;           // SYSCLK1 = 540MHz / 2 = 270MHz (ARM)
    PLL1->PLLDIV2 |= 0x8000;           // SYSCLK2 = 540MHz / 4 = 135MHz (Peripherals)
    PLL1->PLLDIV3 = 0x8000 | 19;    // SYSCLK3 = 540MHz / 20 = 27MHz (VENC)
    PLL1->PLLDIV4 = 0x8000 | 3;      // SYSCLK4 = 540MHz / 4 = 135MHz (VPSS)

I test it,but it works abnormal。Could you give me some advice for this。

The figures you have here are correct, they are the same values I have from a gel file that sets up a DM355 for 270MHz operation seen below. What do you mean when you say 'abnormal', will it just crash or does something in particular not work? You may also want to verify that you really have 270MHz silicon, the 270MHz devices are fairly rare and can be hard to come by, I have never seen one myself. Two other things to keep in mind, assuming this is a custom board, if you had a relatively weak power supply you may want to verify your voltage levels when operating at the higher frequency as there will be a slightly higher draw on the power supply, additionally you may want to ensure your DDR layout is well within tolerances as this could be operating at a higher speed as well, note our layout documentation was built around 171MHz DDR as opposed to the 216MHz DDR that is possible with a 270MHz grade DM355.

DM355 270MHz GEL File said:

/* ------------------------------------------------------------------------ *
 *                                                                          *
 *  Setup_PLL1( )                                                           *
 *  CLKIN   = 24MHz                                                         *
 *  PLL1 =    540MHz                                                        *
 *  SYSCLK1 = 270MHz (ARM)                                                  *
 *  SYSCLK2 = 135MHz (Peripherals)                                          *
 *  SYSCLK3 = 27MHz  (VENC)                                                 *
 *  SYSCLK4 = 135MHz (VPSS)                                                 *              
 *                                                                          *
 * ------------------------------------------------------------------------ */
Setup_PLL1_270()
{
    unsigned int* pll_ctl       = ( unsigned int* )( 0x01c40900 );
    unsigned int* pll_pllm      = ( unsigned int* )( 0x01c40910 );
    unsigned int* pll_cmd       = ( unsigned int* )( 0x01c40938 );
    unsigned int* pll_stat      = ( unsigned int* )( 0x01c4093c );
    unsigned int* pll_div1      = ( unsigned int* )( 0x01c40918 );
    unsigned int* pll_div2      = ( unsigned int* )( 0x01c4091c );
    unsigned int* pll_div3      = ( unsigned int* )( 0x01c40920 );
    unsigned int* pll_div4      = ( unsigned int* )( 0x01c40960 );
    unsigned int* sysctl_misc   = ( unsigned int* )( 0x01c40038 );

    GEL_TextOut( "Setup PLL1... " );

    *pll_ctl &= ~0x0100;             // Onchip Oscillator

    *pll_ctl &= ~0x0020;             // Clear PLLENSRC
    *pll_ctl &= ~0x0001;             // Set PLL in bypass
    _wait( 150 );

    *pll_ctl |= 0x0008;              // Put PLL in reset

    *pll_ctl |= 0x0010;              // Disable PLL
    *pll_ctl &= ~0x0002;             // Power up PLL
    *pll_ctl &= ~0x0010;             // Enable PLL
    _wait( 150 );                    // Wait for PLL to stabilize

//MODIFICATION 143->179
    *pll_pllm = 179;                 // PLL1 24 * (179 + 1) / (7 + 1) = 540MHz
//MODIFICATION
    *pll_div1 |= 0x8000;             // SYSCLK1 = 540MHz / 2 = 270MHz (ARM)
    *pll_div2 |= 0x8000;             // SYSCLK2 = 540MHz / 4 = 135MHz (Peripherals)
//MODIFICATION 15->19
    *pll_div3 = 0x8000 | 19;         // SYSCLK3 = 540MHz / 20 = 27MHz (VENC)
//MODIFICATION
    *pll_div4 = 0x8000 | 3;          // SYSCLK4 = 540MHz / 4 = 135MHz (VPSS)
    _wait (100 );
   
    *sysctl_misc &= 0xFFFFFFD;       // Enable high frequency operation
 
    *pll_cmd |= 0x0001;              // Set GOSET
    while( ( *pll_stat & 1 ) != 0 ); // Wait until complete

    _wait( 2000 );
    *pll_ctl &= ~0x0008;             // Take PLL out of reset

    _wait( 2000 );
    *pll_ctl = 0x0001;               // Enable PLL

    GEL_TextOut( "[Done]\n" );
}

I am curious if you are also configuring your DDR2 to operate at the higher speed (216MHz)? Below is an excerpt from the same GEL file for the DDR2 PLL configuration:

DM355 270MHz GEL File said:

/* ------------------------------------------------------------------------ *
 *                                                                          *
 *  Setup_PLL2( )                                                           *
 *                                                                          *
 *  CLKIN =   24MHz                                                         *
 *  SYSCLK1 = 216MHz (DDR PHY)                                              *
 *                                                                          *
 * ------------------------------------------------------------------------ */
Setup_PLL2_216()
{
    unsigned int* pll_ctl       = ( unsigned int* )( 0x01c40d00 );
    unsigned int* pll_pllm      = ( unsigned int* )( 0x01c40d10 );
    unsigned int* pll_cmd       = ( unsigned int* )( 0x01c40d38 );
    unsigned int* pll_stat      = ( unsigned int* )( 0x01c40d3c );
    unsigned int* pll_div1      = ( unsigned int* )( 0x01c40d18 );
    unsigned int* pll_div2      = ( unsigned int* )( 0x01c40d1c );
    unsigned int* pll_bpdiv     = ( unsigned int* )( 0x01c40d2c );

    GEL_TextOut( "Setup PLL2... " );

    *pll_ctl &= ~0x0100;             // Onchip Oscillator

    *pll_ctl &= ~0x0020;             // Clear PLLENSRC
    *pll_ctl &= ~0x0001;             // Set PLL in bypass
    _wait( 150 );

    *pll_ctl |= 0x0008;              // Put PLL in reset

    *pll_ctl |= 0x0010;              // Disable PLL
    *pll_ctl &= ~0x0002;             // Power up PLL
    *pll_ctl &= ~0x0010;             // Enable PLL
    _wait( 150 );                    // Wait for PLL to stabilize
//MODIFICATION 113->143
    *pll_pllm = 143;                 // PLL2 24 * (143 + 1) / (7+1) = 432MHz
//MODIFICATION
    *pll_div1 |= 0x8000;             // SYSCLK1 = 432MHz / 2 = 216MHz (DDR2)
 
    *pll_cmd |= 0x0001;              // Set GOSET
    while( ( *pll_stat & 1 ) != 0 ); // Wait until complete

    _wait( 2000 );
    *pll_ctl &= ~0x0008;             // Take PLL out of reset
   
    _wait( 2000 );
    *pll_ctl |= 0x0001;             // Enable PLL

    GEL_TextOut( "[Done]\n" );
}

 

I am sure I have a dm355 of 270MHz, because I can see it mark 270。

Yes, I am also configuring my DDR2 to 216MHz as the gel file you show.

After upgrading, the system can boot, but can not work normal。Before upgrading, I can capture yuv raw data, and resize it, encode it and display it。After upgrading, they all work abnormal, but none crash。

I imagine this is a custom board? The first two thoughts that come up on this would be either an issue with the power supply or the DDR layout, as the major difference with operating at higher speeds would be additional stress on the DDR timing and more power being drawn from the power supply, however with these I would expect intermittent crashes and not just abnormal operation. Could you provide some further details on what you mean by 'abnormal', do you mean there is now noise on the display, distortion, etc?