Dynamic register file resizing and frequency scaling to improve embedded processor performance and energy-delay efficiency

Abstract

With CMOS scaling leading to ever increasing levels of transistor integration on a chip, designers of high-performance embedded processors have ample area available to increase processor resources in order to improve performance. However, increasing resource sizes can increase power dissipation and also reduce access time, which can limit maximum achievable operating frequency. In this paper, we explore optimizations for the processor register file (RF), to improve performance and reduce the energy-delay product. We show that while increasing the size of the RF can potentially increase the IPC, overall it results in an increase in program execution time. In response we propose L2MRFS -a dynamic register file resizing scheme in tandem with frequency scaling, which exploits L2 cache misses to noticeably improve processor performance (11% on average) and also significantly reduce the energy-delay product (7%).

Sensible Energy Accounting with Abstract Metering for Multicore Systems

“…Adaptive processors (or reconfigurable processors) have already been studied to reduce power consumption [Albonesi et al 2003;Dhodapkar and Smith 2002;Huang et al 2003b]. In each component, such as the branch predictors and the buffers [Huang et al 2003a]; register files [Abella and Gonzalez 2003;Homayoun et al 2008]; issue queues [Cazorla et al 2004;Folegnani and González 2001;Petoumenos et al 2010];caches [Albonesi et al 2003;Qureshi and Patt 2006;Suh et al 2002]; functional units; and fetch, decode, and issue bandwidth [Albonesi et al 2003;Dhodapkar and Smith 2002;Huang et al 2003b], power gating techniques have also been proposed with minimal area and energy overheads to power down different sections, with negligible impact on the delay.…”

Exploiting STT-NV technology for reconfigurable, high performance, low power, and low temperature functional unit design

“…The functional unit conflicts occur when the processor pipeline has ready instructions, but there are no available functional units to execute them. As studied in several works, increasing the number of functional units in general purpose processors not only increases the power consumption of the processor but will also significantly affect the complexity of several pipeline stages including instruction queue, write-back buffers, bypass stage, register file design and could severely affect the processor performance, as the number of write-back ports increases significantly [16,17]. As studied in several works, increasing the number of functional units in general purpose processors not only increases the power consumption of the processor but will also significantly affect the complexity of several pipeline stages including instruction queue, write-back buffers, bypass stage, register file design and could severely affect the processor performance, as the number of write-back ports increases significantly [16,17].…”

“…Note that in spite of high functional unit conflicts, it is not design efficient to increase the number of functional units in the processor pipeline, as the complexity of additional functional units will be significant [16,17,19]. Only increasing the total number of functional units (which are equivalent to the maximum issue width) from 4 to 6, increase the critical path delay and the total power of the processor by 21% [16,17]. Only increasing the total number of functional units (which are equivalent to the maximum issue width) from 4 to 6, increase the critical path delay and the total power of the processor by 21% [16,17].…”

Run-Time Reconfiguration of Expandable Cache for Embedded Systems

“…As for timing issue, our approach will increase the critical path delay for at most one XOR gate delay. However, in modern pipeline processors, the performance bottleneck is often found in the stage of register file access due to the increasing number of registers and the requirement of multi-port access [23], [24]. Our proposed expansion hardware is added to L1 data cache in the stage of memory access.…”