Application-Specific Processing on a General-Purpose Core via Transparent Instruction Set Customization

Abstract

Application-specific instruction set extensions are an effective way of improving the performance of processors. Critical computation subgraphs can be accelerated by collapsing them into new instructions that are executed on specialized function units. Collapsing the subgraphs simultaneously reduces the length of computation as well as the number of intermediate results stored in the register file. The main problem with this approach is that a new processor must be generated for each application domain. While new instructions can be designed automatically, there is a substantial amount of engineering cost incurred to verify and to implement the final custom processor. In this work, we propose a strategy to transparent customization of the core computation capabilities of the processor without changing its instruction set. A configurable array of function units is added to the baseline processor that enables the acceleration of a wide range of dataflow subgraphs. To exploit the array, the microarchitecture performs subgraph identification at run-time, replacing them with new microcode instructions to configure and utilize the array. We compare the effectiveness of replacing subgraphs in the fill unit of a trace cache versus using a translation table during decode, and evaluate the tradeoffs between static and dynamic identification of subgraphs for instruction set customization.

Exploiting Narrow Accelerators with Data-Centric Subgraph Mapping

“…The new accelerator is also ideal for applications that do not operate on 32-bit inputs, such as video compression applications. CCA, as proposed in [8], is used as a baseline accelerator in this work. In essence, CCA is combinational acyclic accelerator consisting of a set of function units organized as a matrix.…”

“…In other words, this type of accelerator can be treated as an addition to the execution stage in the main pipeline, but with more computational power. Figures 1 and 2 show a CCA, proposed in [8], and how it is integrated into the pipeline from a high level. This extra FU can execute dataflow subgraphs of instructions in one cycle.…”

“…One problem with pipelining is that it would make latency for all subgraphs longer, significantly impacting performance gains from the CCA. Previous work showed that moving from the original CCA to 2-stage pipelined CCA eliminates around 30% of the performance improvement [8]. Another problem is that pipelining does not reduce the die area of CCA; it would actually make the problem worse due to pipeline registers.…”

“…This leaves much room for improvement when looking at the problem from the applications' perspective. Work by Clark et al [8] took a slightly different approach, designing an accelerator targeting important computation patterns, whether or not they were easily supported in hardware. This accelerator, termed a configurable compute accelerator (CCA), offers the promise of more efficiency if the hardware can be constructed.…”

Reconciling specialization and flexibility through compound circuits

“…By properly configuring these muxes, it is possible to make the compound circuit behave as any of the original individual circuits. However, this configurable logic and the additional links are kept to a minimum; as a result, there is no generic routing network such as in traditional FPGA, or in coarser grain configurable accelerator like in [11,27,5] where all possible connections between operators have to be implemented with an expensive network of switches or multiplexers. Previous research proposed to merge more than one hardware datapath to map several specialized instructions on the same hardware such as in [7,28,21] in the context of ASIP design but none of them leverage both data flow and control flow to allow full loop accelerator aggregation.…”