WP_Term Object
(
    [term_id] => 13
    [name] => Arm
    [slug] => arm
    [term_group] => 0
    [term_taxonomy_id] => 13
    [taxonomy] => category
    [description] => 
    [parent] => 178
    [count] => 392
    [filter] => raw
    [cat_ID] => 13
    [category_count] => 392
    [category_description] => 
    [cat_name] => Arm
    [category_nicename] => arm
    [category_parent] => 178
)
Mobile Unleashed Banner SemiWiki 
WP_Term Object
(
    [term_id] => 13
    [name] => Arm
    [slug] => arm
    [term_group] => 0
    [term_taxonomy_id] => 13
    [taxonomy] => category
    [description] => 
    [parent] => 178
    [count] => 392
    [filter] => raw
    [cat_ID] => 13
    [category_count] => 392
    [category_description] => 
    [cat_name] => Arm
    [category_nicename] => arm
    [category_parent] => 178
)
Arm
Posted on by guruvadhiraj

Hardware Intelligence for Low Power

Hardware Intelligence for Low Power
by guruvadhiraj on 09-05-2012 at 9:42 am
Categories: Arm, IP
1 Comment

Low power is the hottest topic these days. The designers of hardware and software are trying to find instances where they can save power . This article tries to identify the role that can be played by the hardware which traditionally it is always software who drives it.

During the course of my career, I found that low power is an important topic and loved by the industry. Second important point that I observed is that, low power is driven by software in most of the cases. This is similar to setting a bit in a particular register to make the peripheral or all the peripherals in particular bus to go to power down( there can be multiple peripheral buses in a SOC like APB peripheral 1 bus, APB peripheral Bus 2 etc) and in some applications idle task executes low power mode. But I always felt that hardware can share some responsibility for low power requirements. To make it simpler it should have some intelligence. The reason for this requirement is related to complexity of software. As the firmware /application becomes large and complex , it becomes difficult for the firmware developers to monitor the devices which are not active and further they have little control on happenings at bus level in the SOC. Let us consider a soc design below . There are two processors with p1 being high priority and p2 being lower priority

If p1 and p2 are trying to access the X in APB1 then p1 would be granted permission by the arbiter. As p2 has lost arbitration, it has three options that it can perform,

[LIST=1]

  • Perform some activity on APB2
  • Do some other task which is internal like reconfiguring the interrupts etc
  • Wait till it gets the Bus

    If p2 performs 3[SUP]rd[/SUP] task then it would be executing NOP instruction. Though it is NOP it would still be executing the NOP at higher frequency clock and if Arbiter has asserted lock signal or if p1 is making a large transfer then p2 has to execute large number of NOP instruction. This can be avoided if ARM2 can execute WFI instruction on its own( No software) which will enable it to go to low power mode.
    The Second method of communication to ARM2 is by making use of interrupt scheme. when ARM1 has gained the bus, arm1 can inform ARM2 , “ I have gained the Bus and will inform you when I release the Bus”. This requires inter-processor communication

    From the diagram we can see that parallel port pins is connected between two processors. P1 can send a long signal to P2 which generates interrupt in p2. This makes p2 to go sleep and when ARM1 re-asserts this pin ARM2 can come out of sleep. The same process can be implemented in the reverse direction also.

    Question that would arise is why can’t p2 execute an idle task or low power instruction instead of waiting for handshaking for power down?
    Idle task is executed only when there is no task to perform or when there is requirement for processor to be in low power(software decides it). This is from software perspective and software does not know when the processor has lost arbitration. Therefore it is best for hardware to go to low power on its own. The problem can occur for priority based algorithms but for round robin this problem may not occur Till now processor going to low was mentioned but what about peripherals?

    In most of the cases (as I remember), peripherals keeps running even after it is used as software do not disable the clock for the peripherals after they are used. Let us take a example of I2C (case where I2C IP can be configured only as Master)which communicates with slaves which can be EEPROM or any other slave device. Once the communication is over, it still continues to be in ON state. It is essential that some slave devices go to off or low power (depends on the slave)on its own or it needs to be driven to perform this action.

    Next question is how does the I2C block know when to switch off and who turns it on?
    One method could be to use stop bit as the reference for disabling the clock . Hardware on generating the STOP bit can disable the clock. When the processor needs to use, it can enable it and program the registers. It may look like a overhead of enabling the block whenever it is used, but we must consider the fact that not all the blocks would be used all the time.
    For the above SOC diagram consider block y is i2c block. if p1 completes the transfer and p2 uses the same block this would result in I2C block being stopped and enabled at short duration of time.

    Does it affect the performance?
    Time may be consumed for the clock to become stable after it is enabled. This may result in data transfer being delayed, but slave peripherals always operate at lower speed compared and the impact on overall system performance should be minimal .

    Conclusion:
    There are many instances where hardware devices is running without doing any task. It becomes too wide a topic to discuss it here. From the above we can see that there are opportunities for hardware to go to low power on its own(depends on final application).

    Comments and feedback:
    This is a suggestion. All the designs always come’s with advantages and disadvantages. Comments and feedback are welcome. I can be reached at [email]guruvadhiraj@gmail.com/gurushesha@gmail.com[/email] or LINKEDIN : in.linkedin.com/pub/guruprasad-pv/9/947/9b1

    Share this post via:

    • Comments

    One Reply to “Hardware Intelligence for Low Power”

    You must register or log in to view/post comments.