• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 97 subscribers
  • Views 378 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.

TMS320C6748: PSC module states

user5238872
Prodigy 220 points
Part Number: TMS320C6748

Hi,

I am developing an application for the DSP 6748 and I would like to disable the modules that the application is not using for avoiding interferences and save power.

I have checked that the modules are disabled in PSC but I am not sured about the difference between the SwRstDisable and Disable modules states. Both states have the clock off, but I am not sure about the difference in the reset. I understand:

  • SwRstDisable: the module is reset and in case of going to Enable state the  module starts in an init (reset) state
  • Disable: the module is not reset and in case of going to Enable state the module starts in the previous state (before being disable)

Also I have some doubts in disabling SCR and BR.

  • If the app does not use the HPI could I disable the SCR F0? affect to the SCR1?
  • If the app does not use the HPI and EDMA, could I disable the SCR F5? affect to the SCR F6 and BRF3? I am using GPIOs and I do not want to disable the SCR F6

Thanks,

Lucía

  • 0
    TI__Guru* 83975 points

    Hi Lucia

    on your question on SwRstDisable vs Disable , i recommend making sure that you have read descriptions in Table 8-3 in the TRM 

    For all practical purposes you should never have to initiate the SwRstDisable state via software and rely on Disable state for any clock gating. 

    For your second set of queries, I would not recommend clock gating any SCRs, just disable the modules that you are not using. The switch fabric (SCR) are pretty lean in terms of area and clocking power, you get maximal power savings by just disabling a peripheral at the root via the module PSC, disabling SCRs will not give significant power saving over this and as you noted some times it get tricky as there are multiple peripherals hanging for an SCR and bridge.

    Hope this helps

    Regards

    Mukul 

  • 0 in reply to Mukul Bhatnagar
    Prodigy 220 points

    Hi Mukul,

    thanks for your answer.

    My questions about the SwRstDisable vs Disable are related to Table 8-3. My doubts came after reading that section and table so I decided to write to the forum. It is not clear enough for me the difference between both states. I know that the SwRstDisable is the default state in almost all the modules but I am trying to understand if Disable is the state I need,

    I am working in a safety application and a requirement is to disable all the interfaces that my application is not using for assure not interferences beetween modules. It is not only a power saving decisión, also safety and it is a requirement for my appication.

    Thank you.

    Lucía

  • 0 in reply to user5238872
    TI__Guru* 83975 points

    Hi Lucia

    Thanks for clarifying this - I have not seen customers use this device in safety application - so good to get that context. 

    • SwRstDisable: the module is reset and in case of going to Enable state the  module starts in an init (reset) state
    • Disable: the module is not reset and in case of going to Enable state the module starts in the previous state (before being disable)

    Your above description is correct. in SwRstDisable state the IP is not only clocked off, it is held in reset by the local psc (LPSC module), when it transitions to enable - it will be result in clocks being enabled as well as ip reset assertion. 

    In disable to enable, the ip is only transitioning from clock off to clock on (no reset assertion).

    SyncReset is just asserting reset (no clock on/off etc) 

    I would strongly still discourage to try to disable SCRs and bridges - if you do it - you will need to ensure all functional testing for all your application scenarios and rely primarily  only on the topology diagrams you find in the TRM (which are reasonably detailed). 

    The initial concept in  design to have granular clock gating for SCRs was just to ensure having finer clock control for power savings - but we did not find them  relevant and we would run into corner conditions where customer or test team will not understand all the data flow and topology dependencies etc. I had a choice of marking these LPSCs as "reserved" and leave them at default state vs exposing them in the TRM so that customers understand what these LPSCs are and don't make any unknown mistakes with rogue register read/writes to these and see unexpected behavior. 

    Hope this helps?

    Let me know if you have more questions. 

    Regards

    Mukul 

  • 0 in reply to Mukul Bhatnagar
    Prodigy 220 points

    Thank you Mukul for your answer and help. I will not disable SCRs and bridges and I set the SwRstDisable (Default mode) for the modules that the application is not using.. 

  • 0 in reply to user5238872
    TI__Guru* 83975 points

    Hi Lucia

    Let us know if you have any additional questions or concerns - we would be happy to help - I would love to see you successful in taking this device for a safety application and any lessons learnt/feedback will be valuable for us.

    Regards

    Mukul