Accelerator Centric Computing


Below is a set of notes that describe the main design choices for the ACC architecture, as discussed so far. There are more parameters and options which are not addressed here, and those which are, are not necessarily the result of consensus. Please contribute to this document by correcting/adding/removing at will, but maintain the structure. Don't worry about losing changes, the wiki maintains a history of this document.

--++ Conventions

ACC: Accelerator GPC: General purpose core MMA: Matrix Multiply Accelerator

--++ Accelerator tile


  1. Multiple accelerators of the same type - thus, they maintain uniform memory requirements and access patterns.
  2. Scratchpad memory - multi-banked and multi-ported, so that it can effectively support double buffering and the bandwidth requirements for full accelerator utilization.
  3. Communication interface. Could the resistive-memory substrate be used as the communication medium for putting together accelerator into pipelines?

Scratchpad Memory

  1. In close proximity (physically) to the accelerators.
  2. Shared among the accelerators of a tile - not unique for every accelerator.
  3. Allocated by the system before the accelerator can execute. Every accelerator has a (base, bound) pair, used for safe address resolution. A process can use one or more accelerators, according to availability.
  4. The only memory addressable by accelerators is scratchpad memory.
  5. Limited in size, but enough to support at least the equivalent of two input-widths for every accelerator (double buffering). For example, the MMA for an operation of A[8x8] * B[8x8] = C[8x8] of doubles, needs 1.5kb before it can even execute, and 3kb to enable double-buffering.
  6. Populated through DMA requests from the resistive memory substrate.

--++ Work queues

It helps to think of the work queues as something similar to the queue employed to hold floating point operations in the UltraSparc T1 (Niagara) FPU (shared among 8 GPCs).

  1. There exists one accelerator work queue for every type of accelerator.
  2. The contents of the work queue lie in main memory. This allows it to expand without size limitations. A concurrent queue, or some simpler locking mechanism, would have to be implemented before any
  3. A process does not have to trap to the operating system to insert work into a queue.

--++ Memory management

  1. There exists a unified address space across scratchpad memories and main system memory.

--++ Programmability

The library writer who wants to use an accelerator, would have to do something like this in their C code:

scratchpad<double> A[1024];

to the system programmer, it will appear as if the lowest parts of their address space are

Scratchpad memory appears to be mapped at a range of addresses of the physical main memory. The idea is similar to the address mapping between

Edit | Attach | Watch | Print version | History: r9 | r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r4 - 2010-03-02 - KonstantinosMenychtas
  • Edit
  • Attach
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding URCS? Send feedback