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. In this text, we simplify to the following operation: A[8x8] * B[8x8] = C[8x8] , where A, B, C are arrays of doubles.
  • TQ : Task Queue
  • TQC: Task Queue Controller

--++ Accelerator tile


  1. Multiple accelerators of the same type - thus, they maintain uniform memory requirements and access patterns.
  2. Scratchpad memory - highly parallel, so that it can effectively support double buffering and the bandwidth requirements for full accelerator utilization.
  3. Communication interface.
  4. Multiple memory controllers, maintaining direct connection to the resistive memory substrate, so as to accommodate the high-bandwidth requirements of the accelerators.

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 task queue controller before the accelerator can execute.
  4. The only memory addressable by accelerators. Every accelerator has a (physical base address, bound) pair, used for safe and fast address resolution - addresses outside the [base, base+bound) region are not accessible by the accelerator.
  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 needs 1.5kb before it can even execute, and 3kb to enable double-buffering. A multiple of this must appear on scratchpad to sustain the accelerator bandwidth requirements.
  6. Populated through DMA requests from the resistive memory substrate.

--++ Task queues

  1. There exists one accelerator task queue for every type of accelerator. Every task queue is unique and can be identified by its id.
  2. The contents of the task queue lie in main memory, in the kernel address space. This allows it to expand without limitations and be protected from arbitrary user writes.
  3. The task queue can only be read or written by the task queue controller. The only way it is visible to the system, is by expand/shrink requests in (hopefully) rare occasions.
  4. The task queue contains task descriptors. The task descriptors are described through a software/hardware contract.
  5. Example: for the MMA, a task descriptor could be { &A, &B, &C, n, m, flag }, where
    • &A, &B are the virtual addresses, in user space, of the matrices to be multiplied, and &C is the address of the matrix where results will be saved
    • Matrices are of sizes A[n x m] * B[m x n] = C[n x n]
    • The flag can have four states: NotExecuting, Executing, Executed, GaveUp.
  6. A task descriptor is automatically associated with a unique (to the task queue) task id.

--++ Task queue controller

  1. The task queue controller is a flexible, programmable, dedicated, general purpose core.
  2. It is loaded with the task queue management policy at boot time, or through some on-the-fly policy selection mechanism.
  3. Whether the task-queue appears as a blocking LIFO queue, or some other data structure, is a matter of policy implementation.
  4. The controller

  1. Upon decoding an accelerator instruction, a GPC sends the task queue controller a request to read from the process' address space the respective task descriptor.

A concurrent queue, or some simpler locking mechanism, would have to be implemented before any

  1. A process does not have to trap to the operating system to insert work into a queue.

    • Since the accelerator suggests a certain blocking size (8x8), it is the responsibility of the system to figure out the best possible blocking for

--++ Memory management

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

--++ Programmability

  1. There exists a

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

When used by the same process, the multiple accelerators of the same type in a tile can appear as a single, very wide accelerator.

Could the resistive-memory substrate be used as the communication medium for putting together accelerator into pipelines?

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

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