Lowest possible power consumption on C6748

Reinier,

Does your hardware design support voltage reduction while sleeping?  If it does, then adding that may reduce the consumption significantly.

I see from your post that your hardware doesn’t support DEEPSLEEP.  But have you tried using PWRM_sleepDSP(), with the lighter PWRM_SLEEP mode instead?  By default, PWRM_SLEEP will put the DDR into self-refresh, bypass the PLLs, and scale voltage to a lower voltage (high enough for sleep) before putting the CPU subsystem to sleep.  And upon wakeup, reverse the process to bring the system active again.  [The steps to scale voltage can be optionally excluded, likely resulting in what you’ve already implemented with bypassing PLLs and putting the DDR into self-refresh.]

The sources for doing these sleep transitions are included in the product release, with the intent that they can be modified as necessary for your custom hardware design.  The routines that PWRM calls to do the low-level transitions are in the “PMI” layer, and the sources are in the DSP/BIOS installation here: packages\ti\pmi\src\pmi.  The file pmi_slp.c has the relevant code for implementing the sleep transitions.

There are a couple of PWRM examples that are included in the product for the C6748: sleep6x and vfscale6x (in the packages\ti\bios\examples directory) .  The product release notes (Bios_5_42_01_09_release_notes.html) include additional PWRM implementation details, and some notes on building these examples.

Hope this helps…

Scott

Hi Scott,

Thank you for all the information.

I would just to confirm the details from my hardware colleague, but I am sure we have voltage reduction capability in hardware.

I just have a few questions:

- How do you change the CPU voltage at a register level? Is this even possible, or is this completely controlled by an outside controller or circuitry? 

- By looking at the PMI examples,  in particular PMI_sleepCPU() in pmi_slp.c, if I understand you correctly the PWRM_sleepDSP() calls PMI_sleepCPU()?

- I am already performing most of the steps in PMI_sleepCPU() on a lower level via the CSL libs. From a bit of experimenting, I found that putting the mDDR in self-refresh mode and bypassing and shutting down the PLLs, by far have the most significant effect. Freezing the cache and gating the clocks to the mDDR seem to have very little effect. Is this to be expected?

- Even-though I did place the mDDR in self-refresh mode, it still appears as though the power consumption of the  mDDR is quite higher than expected when compared to the expected values in its data sheet. Is there something else I can try?

- Do the DSP/BIOS functions PWRM_setDependency() and PWRM_releaseDependency() in effect perform the LPSC transitions, which can also be achieved by programming the PSC module, i.e. do they do the same thing?

Hi Reinier,

1) Yes, PWRM_sleepDSP() calls PMI_sleepCPU() to perform the actual transition in/out of sleep.  Some pseudo code for the flow:

- TSK_disable()
- notify clients registered for pre-sleep notification
- SWI_disable()
- HWI_disable()
- call PMI_sleepCPU() to transition in/out of sleep
- HWI_restore()
- SWI_restore()
- notify clients registered for post-sleep notification
- TSK_restore()

2) Yes, I expect bypassing the PLLs and putting the mDDR into self-refresh to have a biggest impact versus freezing the cache and clock gating.

3) I don’t know what else to recommend for the mDDR consumption, other than maybe contacting that manufacturer to resolve how to get the numbers shown in the datasheet.

4)  Yes, PWRM_setDependency() and PWRM_releaseDependency() will trigger LPSC transitions to activate and deactivate the individual modules.  These functions make calls to two PMI-layer functions to perform the actual transitions: PMI_setModuleState() and PMI_getModuleState().  Some pseudo code for PWRM_setDependency():

- validate the resource ID
- SWI_disable()
- read the reference count for the resource
- if resource is already activated, simply increment its reference count
- else {
    - call PMI_setModuleState() to initiate the LPSC transition to the active state
    - call PMI_getModuleState() until the module has transitioned to the active state
    - set resource’s reference count to ‘1’
}
- SWI_enable()

PWRM_releaseDependency() has a slightly different flow, but makes similar calls to PMI_setModuleState() and PMI_getModuleState() to transition the LPSC to the inactive state.

Regards,
Scott

Scott,

Thank you for the detailed feedback.

I just have a further question. Since we do not have the hardware capability to enable or disable sleep mode externally, we would like to activate and deactivate this functionality over UART0, i.e. UART0 always remains active, with the baud rate dividers being adapted for the change in PLL0 SYSCLK2 frequency changes to maintain the same baud rate.

In my simple test program, I could easily achieve this by just putting the entire application as well as the relevant UART0 driver buffers in internal RAM, i.e. bios.MEM.TEXTSEG = prog.get("IRAM") in the TCF script, so that it is not affected when the mDDR is put into self-refresh mode.

However, with our actual application there is no way that the .text section will all fit into internal RAM. Therefore, I need to selectively place just the relevant pieces of code and data into internal RAM to have the same effect. The problem with this is that I can maybe find all the relevant variables and functions in my own code that need to go into internal RAM, but how on earth do I known exactly which pieces of DSP/BIOS should go into internal RAM??

Would this be possible?