<!DOCTYPE html>
<html lang="en" data-content_root="../../">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Qualcomm Cloud AI 100 (AIC100) — The Linux Kernel documentation</title>
<link rel="stylesheet" type="text/css" href="../../_static/pygments.css?v=fa44fd50" />
<link rel="stylesheet" type="text/css" href="../../_static/alabaster.css?v=3918102e" />
<script src="../../_static/documentation_options.js?v=5929fcd5"></script>
<script src="../../_static/doctools.js?v=9bcbadda"></script>
<script src="../../_static/sphinx_highlight.js?v=dc90522c"></script>
<link rel="index" title="Index" href="../../genindex.html" />
<link rel="search" title="Search" href="../../search.html" />
<link rel="next" title="accel/rocket Rockchip NPU driver" href="../rocket/index.html" />
<link rel="prev" title="Qualcomm Cloud AI 80 (AIC080)" href="aic080.html" />
<link rel="stylesheet" href="../../_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="../../index.html">
<img class="logo" src="../../_static/logo.svg" alt="Logo of The Linux Kernel"/>
</a></p>
<h1 class="logo"><a href="../../index.html">The Linux Kernel</a></h1>
<p class="blurb">6.18.50</p>
<search id="searchbox" style="display: none" role="search">
<h3 id="searchlabel">Quick search</h3>
<div class="searchformwrapper">
<form class="search" action="../../search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script>
<p>
<h3 class="kernel-toc-contents">Contents</h3>
<input type="checkbox" class="kernel-toc-toggle" id = "kernel-toc-toggle" checked>
<label class="kernel-toc-title" for="kernel-toc-toggle"></label>
<div class="kerneltoc" id="kerneltoc">
<ul>
<li class="toctree-l1"><a class="reference internal" href="../../process/development-process.html">Development process</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../process/submitting-patches.html">Submitting patches</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../process/code-of-conduct.html">Code of conduct</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../maintainer/index.html">Maintainer handbook</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../process/index.html">All development-process docs</a></li>
</ul>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="../../core-api/index.html">Core API</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../driver-api/index.html">Driver APIs</a></li>
<li class="toctree-l1 current"><a class="reference internal" href="../../subsystem-apis.html">Subsystems</a><ul class="current">
<li class="toctree-l2"><a class="reference internal" href="../../subsystem-apis.html#core-subsystems">Core subsystems</a></li>
<li class="toctree-l2"><a class="reference internal" href="../../subsystem-apis.html#human-interfaces">Human interfaces</a></li>
<li class="toctree-l2"><a class="reference internal" href="../../subsystem-apis.html#networking-interfaces">Networking interfaces</a></li>
<li class="toctree-l2"><a class="reference internal" href="../../subsystem-apis.html#storage-interfaces">Storage interfaces</a></li>
<li class="toctree-l2 current"><a class="reference internal" href="../../subsystem-apis.html#other-subsystems">Other subsystems</a><ul class="current">
<li class="toctree-l3"><a class="reference internal" href="../../accounting/index.html">Accounting</a></li>
<li class="toctree-l3"><a class="reference internal" href="../../cpu-freq/index.html">CPUFreq - CPU frequency and voltage scaling code in the Linux(TM) kernel</a></li>
<li class="toctree-l3"><a class="reference internal" href="../../edac/index.html">EDAC Subsystem</a></li>
<li class="toctree-l3"><a class="reference internal" href="../../fpga/index.html">FPGA</a></li>
<li class="toctree-l3"><a class="reference internal" href="../../i2c/index.html">I2C/SMBus Subsystem</a></li>
<li class="toctree-l3"><a class="reference internal" href="../../iio/index.html">Industrial I/O</a></li>
<li class="toctree-l3"><a class="reference internal" href="../../pcmcia/index.html">PCMCIA</a></li>
<li class="toctree-l3"><a class="reference internal" href="../../spi/index.html">Serial Peripheral Interface (SPI)</a></li>
<li class="toctree-l3"><a class="reference internal" href="../../w1/index.html">1-Wire Subsystem</a></li>
<li class="toctree-l3"><a class="reference internal" href="../../watchdog/index.html">Watchdog Support</a></li>
<li class="toctree-l3"><a class="reference internal" href="../../virt/index.html">Virtualization Support</a></li>
<li class="toctree-l3"><a class="reference internal" href="../../hwmon/index.html">Hardware Monitoring</a></li>
<li class="toctree-l3 current"><a class="reference internal" href="../index.html">Compute Accelerators</a></li>
<li class="toctree-l3"><a class="reference internal" href="../../security/index.html">Security Documentation</a></li>
<li class="toctree-l3"><a class="reference internal" href="../../crypto/index.html">Crypto API</a></li>
<li class="toctree-l3"><a class="reference internal" href="../../bpf/index.html">BPF Documentation</a></li>
<li class="toctree-l3"><a class="reference internal" href="../../usb/index.html">USB support</a></li>
<li class="toctree-l3"><a class="reference internal" href="../../PCI/index.html">PCI Bus Subsystem</a></li>
<li class="toctree-l3"><a class="reference internal" href="../../misc-devices/index.html">Assorted Miscellaneous Devices Documentation</a></li>
<li class="toctree-l3"><a class="reference internal" href="../../peci/index.html">PECI Subsystem</a></li>
<li class="toctree-l3"><a class="reference internal" href="../../wmi/index.html">WMI Subsystem</a></li>
<li class="toctree-l3"><a class="reference internal" href="../../tee/index.html">TEE Subsystem</a></li>
</ul>
</li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="../../locking/index.html">Locking</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../../process/license-rules.html">Licensing rules</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../doc-guide/index.html">Writing documentation</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../dev-tools/index.html">Development tools</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../dev-tools/testing-overview.html">Testing guide</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../kernel-hacking/index.html">Hacking guide</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../trace/index.html">Tracing</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../fault-injection/index.html">Fault injection</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../livepatch/index.html">Livepatching</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../rust/index.html">Rust</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../../admin-guide/index.html">Administration</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../kbuild/index.html">Build system</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../admin-guide/reporting-issues.html">Reporting issues</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../tools/index.html">Userspace tools</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../userspace-api/index.html">Userspace API</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../../firmware-guide/index.html">Firmware</a></li>
<li class="toctree-l1"><a class="reference internal" href="../../devicetree/index.html">Firmware and Devicetree</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../../arch/index.html">CPU architectures</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../../staging/index.html">Unsorted documentation</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../../translations/index.html">Translations</a></li>
</ul>
</div>
<script type="text/javascript"> <!--
var sbar = document.getElementsByClassName("sphinxsidebar")[0];
let currents = document.getElementsByClassName("current")
if (currents.length) {
sbar.scrollTop = currents[currents.length - 1].offsetTop;
}
--> </script>
<div role="note" aria-label="source link">
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../../_sources/accel/qaic/aic100.rst.txt"
rel="nofollow">Show Source</a></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="qualcomm-cloud-ai-100-aic100">
<h1>Qualcomm Cloud AI 100 (AIC100)<a class="headerlink" href="#qualcomm-cloud-ai-100-aic100" title="Link to this heading">¶</a></h1>
<section id="overview">
<h2>Overview<a class="headerlink" href="#overview" title="Link to this heading">¶</a></h2>
<p>The Qualcomm Cloud AI 100/AIC100 family of products (including SA9000P - part of
Snapdragon Ride) are PCIe adapter cards which contain a dedicated SoC ASIC for
the purpose of efficiently running Artificial Intelligence (AI) Deep Learning
inference workloads. They are AI accelerators.</p>
<p>The PCIe interface of AIC100 is capable of PCIe Gen4 speeds over eight lanes
(x8). An individual SoC on a card can have up to 16 NSPs for running workloads.
Each SoC has an A53 management CPU. On card, there can be up to 32 GB of DDR.</p>
<p>Multiple AIC100 cards can be hosted in a single system to scale overall
performance. AIC100 cards are multi-user capable and able to execute workloads
from multiple users in a concurrent manner.</p>
</section>
<section id="hardware-description">
<h2>Hardware Description<a class="headerlink" href="#hardware-description" title="Link to this heading">¶</a></h2>
<p>An AIC100 card consists of an AIC100 SoC, on-card DDR, and a set of misc
peripherals (PMICs, etc).</p>
<p>An AIC100 card can either be a PCIe HHHL form factor (a traditional PCIe card),
or a Dual M.2 card. Both use PCIe to connect to the host system.</p>
<p>As a PCIe endpoint/adapter, AIC100 uses the standard VendorID(VID)/
DeviceID(DID) combination to uniquely identify itself to the host. AIC100
uses the standard Qualcomm VID (0x17cb). All AIC100 SKUs use the same
AIC100 DID (0xa100).</p>
<p>AIC100 does not implement FLR (function level reset).</p>
<p>AIC100 implements MSI but does not implement MSI-X. AIC100 prefers 17 MSIs to
operate (1 for MHI, 16 for the DMA Bridge). Falling back to 1 MSI is possible in
scenarios where reserving 32 MSIs isn’t feasible.</p>
<p>As a PCIe device, AIC100 utilizes BARs to provide host interfaces to the device
hardware. AIC100 provides 3, 64-bit BARs.</p>
<ul class="simple">
<li><p>The first BAR is 4K in size, and exposes the MHI interface to the host.</p></li>
<li><p>The second BAR is 2M in size, and exposes the DMA Bridge interface to the
host.</p></li>
<li><p>The third BAR is variable in size based on an individual AIC100’s
configuration, but defaults to 64K. This BAR currently has no purpose.</p></li>
</ul>
<p>From the host perspective, AIC100 has several key hardware components -</p>
<ul class="simple">
<li><p>MHI (Modem Host Interface)</p></li>
<li><p>QSM (QAIC Service Manager)</p></li>
<li><p>NSPs (Neural Signal Processor)</p></li>
<li><p>DMA Bridge</p></li>
<li><p>DDR</p></li>
</ul>
<section id="mhi">
<h3>MHI<a class="headerlink" href="#mhi" title="Link to this heading">¶</a></h3>
<p>AIC100 has one MHI interface over PCIe. MHI itself is documented at
<a class="reference internal" href="../../mhi/index.html"><span class="doc">MHI</span></a> MHI is the mechanism the host uses to communicate
with the QSM. Except for workload data via the DMA Bridge, all interaction with
the device occurs via MHI.</p>
</section>
<section id="qsm">
<h3>QSM<a class="headerlink" href="#qsm" title="Link to this heading">¶</a></h3>
<p>QAIC Service Manager. This is an ARM A53 CPU that runs the primary
firmware of the card and performs on-card management tasks. It also
communicates with the host via MHI. Each AIC100 has one of
these.</p>
</section>
<section id="nsp">
<h3>NSP<a class="headerlink" href="#nsp" title="Link to this heading">¶</a></h3>
<p>Neural Signal Processor. Each AIC100 has up to 16 of these. These are
the processors that run the workloads on AIC100. Each NSP is a Qualcomm Hexagon
(Q6) DSP with HVX and HMX. Each NSP can only run one workload at a time, but
multiple NSPs may be assigned to a single workload. Since each NSP can only run
one workload, AIC100 is limited to 16 concurrent workloads. Workload
“scheduling” is under the purview of the host. AIC100 does not automatically
timeslice.</p>
</section>
<section id="dma-bridge">
<h3>DMA Bridge<a class="headerlink" href="#dma-bridge" title="Link to this heading">¶</a></h3>
<p>The DMA Bridge is custom DMA engine that manages the flow of data
in and out of workloads. AIC100 has one of these. The DMA Bridge has 16
channels, each consisting of a set of request/response FIFOs. Each active
workload is assigned a single DMA Bridge channel. The DMA Bridge exposes
hardware registers to manage the FIFOs (head/tail pointers), but requires host
memory to store the FIFOs.</p>
</section>
<section id="ddr">
<h3>DDR<a class="headerlink" href="#ddr" title="Link to this heading">¶</a></h3>
<p>AIC100 has on-card DDR. In total, an AIC100 can have up to 32 GB of DDR.
This DDR is used to store workloads, data for the workloads, and is used by the
QSM for managing the device. NSPs are granted access to sections of the DDR by
the QSM. The host does not have direct access to the DDR, and must make
requests to the QSM to transfer data to the DDR.</p>
</section>
</section>
<section id="high-level-use-flow">
<h2>High-level Use Flow<a class="headerlink" href="#high-level-use-flow" title="Link to this heading">¶</a></h2>
<p>AIC100 is a multi-user, programmable accelerator typically used for running
neural networks in inferencing mode to efficiently perform AI operations.
AIC100 is not intended for training neural networks. AIC100 can be utilized
for generic compute workloads.</p>
<p>Assuming a user wants to utilize AIC100, they would follow these steps:</p>
<ol class="arabic simple">
<li><p>Compile the workload into an ELF targeting the NSP(s)</p></li>
<li><p>Make requests to the QSM to load the workload and related artifacts into the
device DDR</p></li>
<li><p>Make a request to the QSM to activate the workload onto a set of idle NSPs</p></li>
<li><p>Make requests to the DMA Bridge to send input data to the workload to be
processed, and other requests to receive processed output data from the
workload.</p></li>
<li><p>Once the workload is no longer required, make a request to the QSM to
deactivate the workload, thus putting the NSPs back into an idle state.</p></li>
<li><p>Once the workload and related artifacts are no longer needed for future
sessions, make requests to the QSM to unload the data from DDR. This frees
the DDR to be used by other users.</p></li>
</ol>
</section>
<section id="boot-flow">
<h2>Boot Flow<a class="headerlink" href="#boot-flow" title="Link to this heading">¶</a></h2>
<p>AIC100 uses a flashless boot flow, derived from Qualcomm MSMs.</p>
<p>When AIC100 is first powered on, it begins executing PBL (Primary Bootloader)
from ROM. PBL enumerates the PCIe link, and initializes the BHI (Boot Host
Interface) component of MHI.</p>
<p>Using BHI, the host points PBL to the location of the SBL (Secondary Bootloader)
image. The PBL pulls the image from the host, validates it, and begins
execution of SBL.</p>
<p>SBL initializes MHI, and uses MHI to notify the host that the device has entered
the SBL stage. SBL performs a number of operations:</p>
<ul class="simple">
<li><p>SBL initializes the majority of hardware (anything PBL left uninitialized),
including DDR.</p></li>
<li><p>SBL offloads the bootlog to the host.</p></li>
<li><p>SBL synchronizes timestamps with the host for future logging.</p></li>
<li><p>SBL uses the Sahara protocol to obtain the runtime firmware images from the
host.</p></li>
</ul>
<p>Once SBL has obtained and validated the runtime firmware, it brings the NSPs out
of reset, and jumps into the QSM.</p>
<p>The QSM uses MHI to notify the host that the device has entered the QSM stage
(AMSS in MHI terms). At this point, the AIC100 device is fully functional, and
ready to process workloads.</p>
</section>
<section id="userspace-components">
<h2>Userspace components<a class="headerlink" href="#userspace-components" title="Link to this heading">¶</a></h2>
<section id="compiler">
<h3>Compiler<a class="headerlink" href="#compiler" title="Link to this heading">¶</a></h3>
<p>An open compiler for AIC100 based on upstream LLVM can be found at:
<a class="reference external" href="https://github.com/quic/software-kit-for-qualcomm-cloud-ai-100-cc">https://github.com/quic/software-kit-for-qualcomm-cloud-ai-100-cc</a></p>
</section>
<section id="usermode-driver-umd">
<h3>Usermode Driver (UMD)<a class="headerlink" href="#usermode-driver-umd" title="Link to this heading">¶</a></h3>
<p>An open UMD that interfaces with the qaic kernel driver can be found at:
<a class="reference external" href="https://github.com/quic/software-kit-for-qualcomm-cloud-ai-100">https://github.com/quic/software-kit-for-qualcomm-cloud-ai-100</a></p>
</section>
<section id="sahara-loader">
<h3>Sahara loader<a class="headerlink" href="#sahara-loader" title="Link to this heading">¶</a></h3>
<p>An open implementation of the Sahara protocol called kickstart can be found at:
<a class="reference external" href="https://github.com/andersson/qdl">https://github.com/andersson/qdl</a></p>
</section>
</section>
<section id="mhi-channels">
<h2>MHI Channels<a class="headerlink" href="#mhi-channels" title="Link to this heading">¶</a></h2>
<p>AIC100 defines a number of MHI channels for different purposes. This is a list
of the defined channels, and their uses.</p>
<table class="docutils align-default">
<thead>
<tr class="row-odd"><th class="head"><p>Channel name</p></th>
<th class="head"><p>IDs</p></th>
<th class="head"><p>EEs</p></th>
<th class="head"><p>Purpose</p></th>
</tr>
</thead>
<tbody>
<tr class="row-even"><td><p>QAIC_LOOPBACK</p></td>
<td><p>0 & 1</p></td>
<td><p>AMSS</p></td>
<td><p>Any data sent to the device on this
channel is sent back to the host.</p></td>
</tr>
<tr class="row-odd"><td><p>QAIC_SAHARA</p></td>
<td><p>2 & 3</p></td>
<td><p>SBL</p></td>
<td><p>Used by SBL to obtain the runtime
firmware from the host.</p></td>
</tr>
<tr class="row-even"><td><p>QAIC_DIAG</p></td>
<td><p>4 & 5</p></td>
<td><p>AMSS</p></td>
<td><p>Used to communicate with QSM via the
DIAG protocol.</p></td>
</tr>
<tr class="row-odd"><td><p>QAIC_SSR</p></td>
<td><p>6 & 7</p></td>
<td><p>AMSS</p></td>
<td><p>Used to notify the host of subsystem
restart events, and to offload SSR
crashdumps.</p></td>
</tr>
<tr class="row-even"><td><p>QAIC_QDSS</p></td>
<td><p>8 & 9</p></td>
<td><p>AMSS</p></td>
<td><p>Used for the Qualcomm Debug Subsystem.</p></td>
</tr>
<tr class="row-odd"><td><p>QAIC_CONTROL</p></td>
<td><p>10 & 11</p></td>
<td><p>AMSS</p></td>
<td><p>Used for the Neural Network Control
(NNC) protocol. This is the primary
channel between host and QSM for
managing workloads.</p></td>
</tr>
<tr class="row-even"><td><p>QAIC_LOGGING</p></td>
<td><p>12 & 13</p></td>
<td><p>SBL</p></td>
<td><p>Used by the SBL to send the bootlog to
the host.</p></td>
</tr>
<tr class="row-odd"><td><p>QAIC_STATUS</p></td>
<td><p>14 & 15</p></td>
<td><p>AMSS</p></td>
<td><p>Used to notify the host of Reliability,
Accessibility, Serviceability (RAS)
events.</p></td>
</tr>
<tr class="row-even"><td><p>QAIC_TELEMETRY</p></td>
<td><p>16 & 17</p></td>
<td><p>AMSS</p></td>
<td><p>Used to get/set power/thermal/etc
attributes.</p></td>
</tr>
<tr class="row-odd"><td><p>QAIC_DEBUG</p></td>
<td><p>18 & 19</p></td>
<td><p>AMSS</p></td>
<td><p>Not used.</p></td>
</tr>
<tr class="row-even"><td><p>QAIC_TIMESYNC</p></td>
<td><p>20 & 21</p></td>
<td><p>SBL</p></td>
<td><p>Used to synchronize timestamps in the
device side logs with the host time
source.</p></td>
</tr>
<tr class="row-odd"><td><p>QAIC_TIMESYNC
_PERIODIC</p></td>
<td><p>22 & 23</p></td>
<td><p>AMSS</p></td>
<td><p>Used to periodically synchronize
timestamps in the device side logs with
the host time source.</p></td>
</tr>
<tr class="row-even"><td><p>IPCR</p></td>
<td><p>24 & 25</p></td>
<td><p>AMSS</p></td>
<td><p>AF_QIPCRTR clients and servers.</p></td>
</tr>
</tbody>
</table>
</section>
<section id="id1">
<h2>DMA Bridge<a class="headerlink" href="#id1" title="Link to this heading">¶</a></h2>
<section id="id2">
<h3>Overview<a class="headerlink" href="#id2" title="Link to this heading">¶</a></h3>
<p>The DMA Bridge is one of the main interfaces to the host from the device
(the other being MHI). As part of activating a workload to run on NSPs, the QSM
assigns that network a DMA Bridge channel. A workload’s DMA Bridge channel
(DBC for short) is solely for the use of that workload and is not shared with
other workloads.</p>
<p>Each DBC is a pair of FIFOs that manage data in and out of the workload. One
FIFO is the request FIFO. The other FIFO is the response FIFO.</p>
<p>Each DBC contains 4 registers in hardware:</p>
<ul class="simple">
<li><p>Request FIFO head pointer (offset 0x0). Read only by the host. Indicates the
latest item in the FIFO the device has consumed.</p></li>
<li><p>Request FIFO tail pointer (offset 0x4). Read/write by the host. Host
increments this register to add new items to the FIFO.</p></li>
<li><p>Response FIFO head pointer (offset 0x8). Read/write by the host. Indicates
the latest item in the FIFO the host has consumed.</p></li>
<li><p>Response FIFO tail pointer (offset 0xc). Read only by the host. Device
increments this register to add new items to the FIFO.</p></li>
</ul>
<p>The values in each register are indexes in the FIFO. To get the location of the
FIFO element pointed to by the register: FIFO base address + register * element
size.</p>
<p>DBC registers are exposed to the host via the second BAR. Each DBC consumes
4KB of space in the BAR.</p>
<p>The actual FIFOs are backed by host memory. When sending a request to the QSM
to activate a network, the host must donate memory to be used for the FIFOs.
Due to internal mapping limitations of the device, a single contiguous chunk of
memory must be provided per DBC, which hosts both FIFOs. The request FIFO will
consume the beginning of the memory chunk, and the response FIFO will consume
the end of the memory chunk.</p>
</section>
<section id="request-fifo">
<h3>Request FIFO<a class="headerlink" href="#request-fifo" title="Link to this heading">¶</a></h3>
<p>A request FIFO element has the following structure:</p>
<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="k">struct</span><span class="w"> </span><span class="nc">request_elem</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="n">u16</span><span class="w"> </span><span class="n">req_id</span><span class="p">;</span>
<span class="w"> </span><span class="n">u8</span><span class="w"> </span><span class="n">seq_id</span><span class="p">;</span>
<span class="w"> </span><span class="n">u8</span><span class="w"> </span><span class="n">pcie_dma_cmd</span><span class="p">;</span>
<span class="w"> </span><span class="n">u32</span><span class="w"> </span><span class="n">reserved</span><span class="p">;</span>
<span class="w"> </span><span class="n">u64</span><span class="w"> </span><span class="n">pcie_dma_source_addr</span><span class="p">;</span>
<span class="w"> </span><span class="n">u64</span><span class="w"> </span><span class="n">pcie_dma_dest_addr</span><span class="p">;</span>
<span class="w"> </span><span class="n">u32</span><span class="w"> </span><span class="n">pcie_dma_len</span><span class="p">;</span>
<span class="w"> </span><span class="n">u32</span><span class="w"> </span><span class="n">reserved</span><span class="p">;</span>
<span class="w"> </span><span class="n">u64</span><span class="w"> </span><span class="n">doorbell_addr</span><span class="p">;</span>
<span class="w"> </span><span class="n">u8</span><span class="w"> </span><span class="n">doorbell_attr</span><span class="p">;</span>
<span class="w"> </span><span class="n">u8</span><span class="w"> </span><span class="n">reserved</span><span class="p">;</span>
<span class="w"> </span><span class="n">u16</span><span class="w"> </span><span class="n">reserved</span><span class="p">;</span>
<span class="w"> </span><span class="n">u32</span><span class="w"> </span><span class="n">doorbell_data</span><span class="p">;</span>
<span class="w"> </span><span class="n">u32</span><span class="w"> </span><span class="n">sem_cmd0</span><span class="p">;</span>
<span class="w"> </span><span class="n">u32</span><span class="w"> </span><span class="n">sem_cmd1</span><span class="p">;</span>
<span class="w"> </span><span class="n">u32</span><span class="w"> </span><span class="n">sem_cmd2</span><span class="p">;</span>
<span class="w"> </span><span class="n">u32</span><span class="w"> </span><span class="n">sem_cmd3</span><span class="p">;</span>
<span class="p">};</span>
</pre></div>
</div>
<p>Request field descriptions:</p>
<dl class="simple">
<dt>req_id</dt><dd><p>request ID. A request FIFO element and a response FIFO element with
the same request ID refer to the same command.</p>
</dd>
<dt>seq_id</dt><dd><p>sequence ID within a request. Ignored by the DMA Bridge.</p>
</dd>
<dt>pcie_dma_cmd</dt><dd><p>describes the DMA element of this request.</p>
<ul class="simple">
<li><p>Bit(7) is the force msi flag, which overrides the DMA Bridge MSI logic
and generates a MSI when this request is complete, and QSM
configures the DMA Bridge to look at this bit.</p></li>
<li><p>Bits(6:5) are reserved.</p></li>
<li><p>Bit(4) is the completion code flag, and indicates that the DMA Bridge
shall generate a response FIFO element when this request is
complete.</p></li>
<li><p>Bit(3) indicates if this request is a linked list transfer(0) or a bulk
transfer(1).</p></li>
<li><p>Bit(2) is reserved.</p></li>
<li><p>Bits(1:0) indicate the type of transfer. No transfer(0), to device(1),
from device(2). Value 3 is illegal.</p></li>
</ul>
</dd>
<dt>pcie_dma_source_addr</dt><dd><p>source address for a bulk transfer, or the address of the linked list.</p>
</dd>
<dt>pcie_dma_dest_addr</dt><dd><p>destination address for a bulk transfer.</p>
</dd>
<dt>pcie_dma_len</dt><dd><p>length of the bulk transfer. Note that the size of this field
limits transfers to 4G in size.</p>
</dd>
<dt>doorbell_addr</dt><dd><p>address of the doorbell to ring when this request is complete.</p>
</dd>
<dt>doorbell_attr</dt><dd><p>doorbell attributes.</p>
<ul class="simple">
<li><p>Bit(7) indicates if a write to a doorbell is to occur.</p></li>
<li><p>Bits(6:2) are reserved.</p></li>
<li><p>Bits(1:0) contain the encoding of the doorbell length. 0 is 32-bit,
1 is 16-bit, 2 is 8-bit, 3 is reserved. The doorbell address
must be naturally aligned to the specified length.</p></li>
</ul>
</dd>
<dt>doorbell_data</dt><dd><p>data to write to the doorbell. Only the bits corresponding to
the doorbell length are valid.</p>
</dd>
<dt>sem_cmdN</dt><dd><p>semaphore command.</p>
<ul class="simple">
<li><p>Bit(31) indicates this semaphore command is enabled.</p></li>
<li><p>Bit(30) is the to-device DMA fence. Block this request until all
to-device DMA transfers are complete.</p></li>
<li><p>Bit(29) is the from-device DMA fence. Block this request until all
from-device DMA transfers are complete.</p></li>
<li><p>Bits(28:27) are reserved.</p></li>
<li><p>Bits(26:24) are the semaphore command. 0 is NOP. 1 is init with the
specified value. 2 is increment. 3 is decrement. 4 is wait
until the semaphore is equal to the specified value. 5 is wait
until the semaphore is greater or equal to the specified value.
6 is “P”, wait until semaphore is greater than 0, then
decrement by 1. 7 is reserved.</p></li>
<li><p>Bit(23) is reserved.</p></li>
<li><p>Bit(22) is the semaphore sync. 0 is post sync, which means that the
semaphore operation is done after the DMA transfer. 1 is
presync, which gates the DMA transfer. Only one presync is
allowed per request.</p></li>
<li><p>Bit(21) is reserved.</p></li>
<li><p>Bits(20:16) is the index of the semaphore to operate on.</p></li>
<li><p>Bits(15:12) are reserved.</p></li>
<li><p>Bits(11:0) are the semaphore value to use in operations.</p></li>
</ul>
</dd>
</dl>
<p>Overall, a request is processed in 4 steps:</p>
<ol class="arabic simple">
<li><p>If specified, the presync semaphore condition must be true</p></li>
<li><p>If enabled, the DMA transfer occurs</p></li>
<li><p>If specified, the postsync semaphore conditions must be true</p></li>
<li><p>If enabled, the doorbell is written</p></li>
</ol>
<p>By using the semaphores in conjunction with the workload running on the NSPs,
the data pipeline can be synchronized such that the host can queue multiple
requests of data for the workload to process, but the DMA Bridge will only copy
the data into the memory of the workload when the workload is ready to process
the next input.</p>
</section>
<section id="response-fifo">
<h3>Response FIFO<a class="headerlink" href="#response-fifo" title="Link to this heading">¶</a></h3>
<p>Once a request is fully processed, a response FIFO element is generated if
specified in pcie_dma_cmd. The structure of a response FIFO element:</p>
<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="k">struct</span><span class="w"> </span><span class="nc">response_elem</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="n">u16</span><span class="w"> </span><span class="n">req_id</span><span class="p">;</span>
<span class="w"> </span><span class="n">u16</span><span class="w"> </span><span class="n">completion_code</span><span class="p">;</span>
<span class="p">};</span>
</pre></div>
</div>
<dl class="simple">
<dt>req_id</dt><dd><p>matches the req_id of the request that generated this element.</p>
</dd>
<dt>completion_code</dt><dd><p>status of this request. 0 is success. Non-zero is an error.</p>
</dd>
</dl>
<p>The DMA Bridge will generate a MSI to the host as a reaction to activity in the
response FIFO of a DBC. The DMA Bridge hardware has an IRQ storm mitigation
algorithm, where it will only generate a MSI when the response FIFO transitions
from empty to non-empty (unless force MSI is enabled and triggered). In
response to this MSI, the host is expected to drain the response FIFO, and must
take care to handle any race conditions between draining the FIFO, and the
device inserting elements into the FIFO.</p>
</section>
</section>
<section id="neural-network-control-nnc-protocol">
<h2>Neural Network Control (NNC) Protocol<a class="headerlink" href="#neural-network-control-nnc-protocol" title="Link to this heading">¶</a></h2>
<p>The NNC protocol is how the host makes requests to the QSM to manage workloads.
It uses the QAIC_CONTROL MHI channel.</p>
<p>Each NNC request is packaged into a message. Each message is a series of
transactions. A passthrough type transaction can contain elements known as
commands.</p>
<p>QSM requires NNC messages be little endian encoded and the fields be naturally
aligned. Since there are 64-bit elements in some NNC messages, 64-bit alignment
must be maintained.</p>
<p>A message contains a header and then a series of transactions. A message may be
at most 4K in size from QSM to the host. From the host to the QSM, a message
can be at most 64K (maximum size of a single MHI packet), but there is a
continuation feature where message N+1 can be marked as a continuation of
message N. This is used for exceedingly large DMA xfer transactions.</p>
<section id="transaction-descriptions">
<h3>Transaction descriptions<a class="headerlink" href="#transaction-descriptions" title="Link to this heading">¶</a></h3>
<dl class="simple">
<dt>passthrough</dt><dd><p>Allows userspace to send an opaque payload directly to the QSM.
This is used for NNC commands. Userspace is responsible for managing
the QSM message requirements in the payload.</p>
</dd>
<dt>dma_xfer</dt><dd><p>DMA transfer. Describes an object that the QSM should DMA into the
device via address and size tuples.</p>
</dd>
<dt>activate</dt><dd><p>Activate a workload onto NSPs. The host must provide memory to be
used by the DBC.</p>
</dd>
<dt>deactivate</dt><dd><p>Deactivate an active workload and return the NSPs to idle.</p>
</dd>
<dt>status</dt><dd><p>Query the QSM about it’s NNC implementation. Returns the NNC version,
and if CRC is used.</p>
</dd>
<dt>terminate</dt><dd><p>Release a user’s resources.</p>
</dd>
<dt>dma_xfer_cont</dt><dd><p>Continuation of a previous DMA transfer. If a DMA transfer
cannot be specified in a single message (highly fragmented), this
transaction can be used to specify more ranges.</p>
</dd>
<dt>validate_partition</dt><dd><p>Query to QSM to determine if a partition identifier is valid.</p>
</dd>
</dl>
<p>Each message is tagged with a user id, and a partition id. The user id allows
QSM to track resources, and release them when the user goes away (eg the process
crashes). A partition id identifies the resource partition that QSM manages,
which this message applies to.</p>
<p>Messages may have CRCs. Messages should have CRCs applied until the QSM
reports via the status transaction that CRCs are not needed. The QSM on the
SA9000P requires CRCs for black channel safing.</p>
</section>
</section>
<section id="subsystem-restart-ssr">
<h2>Subsystem Restart (SSR)<a class="headerlink" href="#subsystem-restart-ssr" title="Link to this heading">¶</a></h2>
<p>SSR is the concept of limiting the impact of an error. An AIC100 device may
have multiple users, each with their own workload running. If the workload of
one user crashes, the fallout of that should be limited to that workload and not
impact other workloads. SSR accomplishes this.</p>
<p>If a particular workload crashes, QSM notifies the host via the QAIC_SSR MHI
channel. This notification identifies the workload by it’s assigned DBC. A
multi-stage recovery process is then used to cleanup both sides, and get the
DBC/NSPs into a working state.</p>
<p>When SSR occurs, any state in the workload is lost. Any inputs that were in
process, or queued by not yet serviced, are lost. The loaded artifacts will
remain in on-card DDR, but the host will need to re-activate the workload if
it desires to recover the workload.</p>
</section>
<section id="reliability-accessibility-serviceability-ras">
<h2>Reliability, Accessibility, Serviceability (RAS)<a class="headerlink" href="#reliability-accessibility-serviceability-ras" title="Link to this heading">¶</a></h2>
<p>AIC100 is expected to be deployed in server systems where RAS ideology is
applied. Simply put, RAS is the concept of detecting, classifying, and
reporting errors. While PCIe has AER (Advanced Error Reporting) which factors
into RAS, AER does not allow for a device to report details about internal
errors. Therefore, AIC100 implements a custom RAS mechanism. When a RAS event
occurs, QSM will report the event with appropriate details via the QAIC_STATUS
MHI channel. A sysadmin may determine that a particular device needs
additional service based on RAS reports.</p>
</section>
<section id="telemetry">
<h2>Telemetry<a class="headerlink" href="#telemetry" title="Link to this heading">¶</a></h2>
<p>QSM has the ability to report various physical attributes of the device, and in
some cases, to allow the host to control them. Examples include thermal limits,
thermal readings, and power readings. These items are communicated via the
QAIC_TELEMETRY MHI channel.</p>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="footer">
©The kernel development community.
|
Powered by <a href="https://www.sphinx-doc.org/">Sphinx 8.1.3</a>
& <a href="https://alabaster.readthedocs.io">Alabaster 0.7.16</a>
|
<a href="../../_sources/accel/qaic/aic100.rst.txt"
rel="nofollow">Page source</a>
</div>
</body>
</html>