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 Silicon errata 2.0.1

I'm devoloping code assuming Rev 2.0 silicon for the C6748.  Looking at the first Advisory for the C6748, it says that problems can occur if the CPU and DMA priorities are the same.  The workaround is to make sure that the CPU has a different priority from the SDMA / IDMA (SDMA can equal IDMA).

1.  It appears the defaults for CPUARBU, MSTPRI1, and MSTPRI2 are all different.  Therefore, no problem if we leave the everything at the default priorities?

2.  Why isn't MSTPRI0 included in the advisory discussion?  Shouldn't we verify the priorities in MSTPRI0 don't equal the CPU priority as well?

3.  Our project uses the LCDC.  One of the notes says if you use the LCDC, you probably don't want to use the default priority, and should raise it up.  Is there any downside to setting it to priority zero?  The CPU would be priority 1.

4.  Finally, there is some confusion about the MDMAARBE register.  In the C64x+ class we were instructed to raise the default priority in the MDMAARBE register.  In fact page 146 of the C674x DSP Megamodule guide says to raise the default priority.  However on page 146 of the C6748 DSP System Guide, it says the priorities for the DSP MDMA and DSP CFG are controlled by MSTPRI0, and NOT by MDMAARBE.  So, do we have to adjust the MDMAARBE priority for the C6748?

Thanks, Dean

 

  • Hi Dean

    Dean Hofstetter said:

    1.  It appears the defaults for CPUARBU, MSTPRI1, and MSTPRI2 are all different.  Therefore, no problem if we leave the everything at the default priorities?

    This is correct, for this family of devices, none of the master priorities defaults to 1 and CPUARBU is default 1, so the default values are ok. Note that MSTPRIx values for various masters can be and should be tweaked to meet system performance requirements and in that case you can make sure this advisory is still being followed.

    Dean Hofstetter said:

    2.  Why isn't MSTPRI0 included in the advisory discussion?  Shouldn't we verify the priorities in MSTPRI0 don't equal the CPU priority as well?

    Yes MSTRPRI0 is also in the mix (all masters are) and  should've been shown in the pseudo code too . FYI, the defaults for masters configured by MSTPRI0 also don't have a value of 1.

    Dean Hofstetter said:
    Our project uses the LCDC.  One of the notes says if you use the LCDC, you probably don't want to use the default priority, and should raise it up.  Is there any downside to setting it to priority zero?  The CPU would be priority 1.

    No downside, it is typically recommended to keep LCDC and Audio (EDMA TC servicing McASP/McBSP requests) at highest priority in your system. So keeping it 0 should meet that recommendation as well as be fine from a advisory perspective (this also assumes that LCD is actually using DSP memory like L2 for its buffers, if it was using DDR2 , then LCDC vs CPUARBU priority is a don't care)

    Dean Hofstetter said:

    4.  Finally, there is some confusion about the MDMAARBE register.  In the C64x+ class we were instructed to raise the default priority in the MDMAARBE register.  In fact page 146 of the C674x DSP Megamodule guide says to raise the default priority.  However on page 146 of the C6748 DSP System Guide, it says the priorities for the DSP MDMA and DSP CFG are controlled by MSTPRI0, and NOT by MDMAARBE.  So, do we have to adjust the MDMAARBE priority for the C6748?

    Compared to previous gen c64x+ devices, in this device the "control" for managing the MDMA priority is been taken away from the C674x MDMAARBE registers and is instead done via MSTPRIx registers. This change was done specifically to try to centralize all "master prioritization" with one set of registers /module (instead of configuring CPU priority via C674x CPU registers and other priorities via system configuration module register). The recommendations to raise the MDMAARBE priority still hold, and you can accomplish this via writing to MSTPRI0.MDMAARBE register bits.

    You might find the following set of wikis http://processors.wiki.ti.com/index.php/OMAP-L1x/C674x/AM1x_SOC_Architecture_and_Throughput_Overview

    helpful to better understand concepts of master priority etc.

    Regards

    Mukul