# Intel Stratix 10 FPGA design for track reconstruction for the ATLAS
experiment at the HL-LHC

A. Camplani,11footnotetext: Corresponding authors. S. Dittmeier  A. Annovi,
K. Axiotis  R. Beccherle  N. Biesuz  R. Brenner  S. Débieux,  M. Ellert,  P.
Francavilla  P. Giannetti  K. Kordas,  M. Mårtensson,  P. Mastrandrea  C.
Noulas,  J. Oechsle  M. Piendibene  R. Poggi  A. Schöning,  A. Sfyrla  C. L.
Sotiropoulou,22footnotetext: now with Computer Aided Software Technologies
(CAST), Inc. J. Steentoft  T. Tsiakiris  S. Xella  and J. Zinßer.

###### Abstract

The fast reconstruction of charged particle tracks with high efficiency and
track quality is an essential part of the online data selection for the ATLAS
experiment at the High Luminosity LHC. Dedicated custom designed hardware
boards and software simulations have been developed to assess the feasibility
of a Hardware Tracking Trigger (HTT) system. The Pattern Recognition Mezzanine
(PRM), as part of the HTT system, has been designed to recognize track
candidates in silicon detectors with Associative Memory ASICs and to select
and reconstruct tracks using linearized algorithms implemented in an Intel
Stratix 10 MX FPGA. The highly parallelized FPGA design makes extensive use of
the integrated High-Bandwidth-Memory.

In this paper, the FPGA design for the PRM board is presented. Its
functionalities have been verified in both simulations and hardware tests on
an Intel Stratix 10 MX development kit.

##  1 HL-LHC and the ATLAS experiment

The High Luminosity Large Hadron Collider (HL-LHC) [1] is currently planned to
begin operation in 2029. Protons will collide at
$\sqrt{s}~{}=~{}$14\text{\,}\mathrm{T}\mathrm{e}\mathrm{V}$$, delivering an
instantaneous luminosity of up to
$\mathcal{L}~{}=~{}$7.5\text{\times}{10}^{34}\text{\,}\mathrm{c}\mathrm{m}^{-2}\mathrm{s}^{-1}$$.
This implies that the mean number of proton-proton collisions in the same
bunch crossing (pile-up) is expected to reach up to $<\\!\mu\\!>\,=\,200$, an
increase of more than a factor three compared to current conditions. In order
to achieve optimal physics performance under these harsh conditions, all LHC
experiments will undergo a series of upgrades.

For the HL-LHC era, the ATLAS experiment [2, 3] foresees, among others, two
major upgrades: the installation of a completely new tracking detector, the
Inner Tracker (ITk), composed exclusively of silicon pixels [4] and strips [5]
as depicted in Figure 1; and the redesign of the Trigger and Data Acquisition
(TDAQ) system [6].

Figure 1: A schematic view of the layout of the ATLAS ITk detector used for
this study, with a five-layer Pixel detector (red) surrounded by the Strip
detector (blue). Only the positions of the active sensors are shown. The final
ITk layout can be found in [7].

###  1.1 The TDAQ Phase-II Upgrade

The ATLAS detector currently produces more than
$60\text{\,}\mathrm{T}\mathrm{B}\mathrm{/}\mathrm{s}$ of data during
operation, but only a small fraction of these collision events contain
interesting characteristics that might lead to new physics discoveries. As a
consequence, a specialized multi-level system, the TDAQ system, selects the
events that are potentially interesting for physics analyses in real-time. The
TDAQ role is to reduce the data rates to manageable levels in order to be able
to transport the data to the storage system for offline analysis.

At the HL-LHC, the ATLAS TDAQ system will face various challenges, such as a
much more complicated event selection as a result of higher pile-up; readout
of a tracking detector with more than 5 billion channels (compared to the
$\sim$$100$ million channels of the current detector); and a full event size
of up to $\sim$$5.2\text{\,}\mathrm{M}\mathrm{B}$ (compared to the current
$\sim$$2\text{\,}\mathrm{M}\mathrm{B}$).

In addition, it is paramount for the trigger selection to remain inclusive
enough to allow for electroweak scale physics as well as a broad range of
physics searches. Therefore, the TDAQ system will undergo a major upgrade,
with several operating parameters updated with respect to the LHC era. Among
these the most relevant are:

  * •

the hardware trigger latency will be increased from
$2.5\text{\,}\mu\mathrm{s}$ to $10\text{\,}\mu\mathrm{s}$

  * •

the detector readout rate will be raised from
$100\text{\,}\mathrm{k}\mathrm{H}\mathrm{z}$ to
$1\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$

  * •

the rate of data sent to permanent storage will be increased from
$1\text{\,}\mathrm{k}\mathrm{H}\mathrm{z}$ to
$10\text{\,}\mathrm{k}\mathrm{H}\mathrm{z}$

Track reconstruction is a crucial element in the trigger selection, as it can
provide extremely precise measurements in both position and momentum. This is
of particular importance in order to distinguish hard-scattering processes
from the abundant low-momentum background particles from concurrent pile-up
events.

The trigger system is composed of two levels: the hardware based Level-0
Trigger system, which relies only on data from the calorimeters and muon
detectors and is operated with a fixed latency, and the software based Event
Filter system, potentially deploying accelerator hardware, that provides high-
level trigger functionality. Both trigger systems are connected to a complex
Data Acquisition system. A schematic view can be found in Figure 2.

Figure 2: TDAQ system structure for Phase II. The dashed lines represent the
Level-0 accept signal, while the solid lines represent the readout data.

The Event Filter design in the Technical Design Report (TDR) [6] includes a
CPU-based processing farm complemented by a hardware-based co-processor
system, called HTT (Hardware Tracking for the Trigger). The HTT system offers
several benefits over a CPU-only farm, e. g. a lower processing latency and a
more efficient use of resources. The latter allows for a reduction of the CPU
farm size required for online tracking by a factor of 10 [6], which in turn
leads to a lower power consumption of the overall system. This TDAQ
architecture is referred to as the baseline design for the TDAQ upgrade, as in
Figure 2.

Given the availability of a hardware based tracking system, the TDR includes a
scenario which evolves the trigger into a dual-level hardware trigger
architecture. This is done by introducing tracking at Level-1 using a
dedicated low-latency version of HTT. This can reduce the L0 rate to less than
$1\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$ for further processing in the Event
Filter. Implementing hardware tracking at Level-1 enables better control of
the trigger rates by adding more margins and more flexibility, not only in the
case of major changes of the experimental conditions or the trigger menu, but
also as a handle to maintain stability as the processing at high pile-up does
not scale linearly with luminosity. Furthermore, it creates opportunities to
lower thresholds and improve acceptance on many important physics signatures.

As the HL-LHC upgrade projects progressed, the final choice of the ATLAS
experiment was to design a heterogeneous system, based on commodity servers
and possibly accelerator boards, excluding the possibility of a system based
around custom associative memory ASICs [8]. Nevertheless, the decision process
required performance studies, both in simulation and on hardware
demonstrators, to assess the feasibility of such a system. In this paper we
present the development of the firmware design for one mezzanine board
dedicated to the track reconstruction and fitting, called the Pattern
Recognition Mezzanine.

###  1.2 The Hardware Tracking for the Trigger system

The HTT system is designed to reconstruct quickly and efficiently the tracks
of charged particles within the ITk. Depending on the Level-0 trigger
decision, the ITk detector data can be processed in two different ways in the
baseline HTT design: regional or full-scan track reconstruction, according to
trigger configuration.

| $p_{\rm{T}}$ |  | Detector
---
coverage
Level-0 rate
Regional tracking | >$2\text{\,}\mathrm{G}\mathrm{e}\mathrm{V}$ | < $10\text{\,}\%$ | $1\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$
Full-scan tracking | >$1\text{\,}\mathrm{G}\mathrm{e}\mathrm{V}$ | full coverage | $100\text{\,}\mathrm{k}\mathrm{H}\mathrm{z}$
Table 1: Regional and full-scan tracking requirements.

For the regional tracking, as shown in Table 1, tracks with transverse
momentum of $p_{\rm{T}}>$2\text{\,}\mathrm{GeV}$$ are reconstructed within the
so-called Regions Of Interest (ROI), which cover less than $10\text{\,}\%$ of
the detector volume. This allows for a quick initial background rejection for
single high-$p_{\rm{T}}$ lepton triggers, as well as for multi-object
triggers. Regional tracking can be done at the full Level-0 accept rate of
$1\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$.

For the full-scan reconstruction, all tracks with
$p_{\rm{T}}>$1\text{\,}\mathrm{GeV}$$ are reconstructed using the full
detector data. This is especially important for background rejection of
hadronic signatures, to enhance primary vertex identification, and to correct
and mitigate pile-up effects. As these requests demand more bandwidth and
processing power, they can be served at rates of up to
$100\text{\,}\mathrm{k}\mathrm{H}\mathrm{z}$.

For the scenario where the Level-1 Trigger is present, the low-latency version
of the HTT system has to provide tracks to the next processing step within a
few microseconds. In this case only the regional tracking is used. For the HTT
system placed in the Event Filter, both regional and global tracking are
available, as in the baseline design.

The requirements posed by the low-latency version are the main driver for the
architectural choice of the HTT system. The high throughput and the tight
latency budget can only be met using a dedicated hardware system. FPGAs that
can sustain the required throughput have been selected to implement the
clustering and track fitting algorithms. A custom-designed ASIC has been
developed, the Associative Memory (AM) ASIC (described in detail in [9]),
following the approach previously used by the CDF experiment [10] and intended
for the ATLAS FastTracKer (FTK) project [11]. The AM ASICs are able to deal
with the combinatorial complexity in an extremely parallel way, providing a
fast recognition of track candidates with high efficiency. In parallel to the
developments of the AM ASICs, hardware implementations of alternative pattern
recognition methods using Hough transform have also been studied [12]. Related
studies of non-AM based track triggers can be found in [13, 14].

The HTT design relies on a single ATCA [15] main board, the Tracking Processor
(TP), that can be equipped with two different types of mezzanines: the Pattern
Recognition Mezzanine (PRM) or the Track Fitting Mezzanine (TFM). The TP
mounts a Xilinx Virtex UltraScale+ VU19P FPGA. The PRM and the TFM both host
an Intel Stratix 10 MX FPGA. The AM ASICs are only mounted on the PRM. In the
baseline design, see Figure 3, 12 PRM boards and 2 TFM boards share one ATCA
crate and form one HTT unit. The detector volume is split into 48
$\eta\times\phi$ regions ($2.66\times\pi/8$), each being individually
processed by one HTT unit. The segmentation has been chosen to minimize data
sharing between HTT units required to account for regional overlaps.

Figure 3: HTT system architecture.

The HTT system receives the detector data via optical links from the network
through dedicated servers using the FELIX [16, 17] cards. In the Level-1 case,
dedicated low-latency streams are necessary to transfer the data directly from
the ITk to the regional tracking units.

The HTT system processes the ITk detector data in steps. The incoming ITk hits
are clustered on the TP and clusters are sent to the mezzanines. The PRM
reconstructs tracks from 8 ITk layers, while the TFM refines the fit adding
the hits from the remaining five layers.

##  2 The Pattern Recognition Mezzanine

A prototype of the Pattern Recognition Mezzanine (PRM) is shown in Figure 4.
The PRM PCB is meant to be mounted onto its ATCA motherboard (TP), and it
features a powerful FPGA, the Intel Stratix 10 MX333part number:
1SM21BHN3F53E3VG, together with 20 Associative Memory ASICs. To implement the
power-up sequence of the Stratix 10 as well as for control and monitoring of
the board, an Intel MAX 10 FPGA is also installed. The PRM connects to the TP
via eight Samtec Z-Ray connectors of type ZA8H-24-0.33-7, that provide power
and high speed serial data links, as well as SGMII [18], JTAG [19] and other
control interfaces.

Figure 4: Photograph of a Pattern Recognition Mezzanine board equipped with an
Intel Stratix 10 MX FPGA. No AM ASICs are soldered to the board.

###  2.1 Functional description

The PRM performs the first track reconstruction and selection step for the HTT
system. It processes data from 8 detector layers, of which a maximum of four
can be silicon pixels and the rest are silicon strip layers, depending on
which ITk detector region is being processed [4, 5]. As in the HTT simulation
studies, the configuration used for this study foresees 1 pixel and 7 strip
layers. The Intel Stratix 10 MX FPGA forms the core of the PRM, handling the
communication with the TP and the ASICs as well as implementing the algorithms
used for track reconstruction and selection. The PRM receives clustered ITk
detector data via high speed serial links from the TP using the FPGA’s
transceiver blocks. Up to 32 channels for the input and 16 for the output data
have been foreseen.

Figure 5: Simplified representation of super-strips identifiers granularity
vs. single clusters granularity: one super-strip can contain multiple
clusters.

Twenty AM ASICs on the PRM are arranged in four groups of five daisy-chained
ASICs, that can process different sets of clusters simultaneously. All 20
ASICs combined can store a total of 7.864 million patterns. A pattern is a
sequence of eight so-called Super-Strip IDentifiers (SSIDs), which collect
adjacent groups of silicon strip or pixel channels into a coarse position
identification. Figure 5 shows a simplified representation444HTT simulation
studies have used the following SSID sizes: 33x402 for the pixel and 40 for
the strips in the barrel, and 16x200 for the pixel and 10 for the strips in
the end-caps..

All the patterns are generated from Monte Carlo simulated muons555Efficient
tracking of long living particles, i. e. largely displaced tracks, requires
additional patterns and constants to be generated. Similarly, tracking
efficiency of lower energy electrons can be retained with additional patterns,
if no further processing, like a Gaussian Sum Filter, is available., which
originate from the interaction region in ATLAS with a flat $p_{\rm{T}}$
spectrum for $p_{\rm{T}}$ larger than
$12\text{\,}\mathrm{G}\mathrm{e}\mathrm{V}$ [20]. The super-strip width, in
both dimensions for the pixels, is a parameter tuned in the simulation to
optimize the number of patterns within the AM ASICs and to reduce the
bandwidth between the FPGA and ASICs. At the same time, it impacts on the
average number of fit combinations, as an increase in the super-strip width
would also increase the combinatorics.

Figure 6: PRM complete block diagram. Solid lines represent the data
transmission: in red the clusters, in orange the SSID, in green the roadID, in
blue the sectorID, in violet the constants and in black the tracks. Dashed
lines represent the firmware control and monitoring.

The complete block diagram of the Intel Stratix 10 MX FPGA design
functionalities is shown in Figure 6 and explained in the following
paragraphs. The data processing is event based, where one event corresponds to
the collision of two proton bunches. In the first processing step, the input
cluster data (red) coming from the TP is synchronized and converted into SSIDs
(orange), which are sent to the AM ASICs for pattern matching. The interface
between the FPGA and a group of ASICs consists of source-synchronous parallel
LVDS buses operated at $1\text{\,}\mathrm{G}\mathrm{b}\mathrm{p}\mathrm{s}$
per line, which yields an ASIC input data rate of
$32\text{\,}\mathrm{G}\mathrm{b}\mathrm{p}\mathrm{s}$ and an ASIC output data
rate of $8\text{\,}\mathrm{G}\mathrm{b}\mathrm{p}\mathrm{s}$.

Within the FPGA, all clusters are stored temporarily in an on-the-fly data
base called Data Organiser, grouped under their corresponding SSIDs. When an
event processing is being completed in the AM ASICs, the FPGA receives the
addresses of all matched patterns, which are referred to as road IDentifiers
(roadIDs, green). Using these roadIDs, the SSIDs of all matched patterns are
collected in the Data Organizer from the High-Bandwidth-Memory (HBM), where a
copy of the pattern bank is stored. The SSIDs and their associated clusters
are then processed in the Track Fitter block.

The Track Fitter block implements a Principal Component Analysis (PCA)
algorithm to determine the track parameters for a given set of clusters. A
specific PCA is only applicable within a small detector region, referred to as
a sector. The detector is therefore divided into many sectors which are
identified by their sectorIDs (blue), stored in the HBM. Within a sector the
track equation can then be linearized, according to equation 2.1.

$\displaystyle p_{i}$
$\displaystyle=\sum^{N_{\text{coo}}}_{j=1}\left(C_{ij}x_{j}+q_{i}\right)$
(2.1)

Here, $x_{j}$ are the coordinates of the clusters and $p_{i}$ are the 5
expected track parameters, namely pseudorapidity $\eta$, azimuthal angle
$\phi$, transverse momentum $p_{\rm{T}}$, and the impact parameters $d_{0}$
and $z_{0}$. $C_{ij}$ and $q_{i}$ form the set of constants extracted from the
software simulation training which are stored in the HBM (violet). The
minimization of the distance between the expected and real track parameters in
the PCA follows a $\chi^{2}$-distribution, allowing the use of the
$\chi^{2}$-variable to evaluate the track quality.

$\displaystyle\chi^{2}$
$\displaystyle=\sum^{N_{\text{dof}}}_{i=1}\left[\left(\sum^{N_{\text{coo}}}_{j=1}S_{ij}x_{j}\right)+h_{i}\right]^{2}$
(2.2)

Equation 2.2 contains the constants $h_{i}$ and $S_{ij}$, where $S_{ij}$ is
the inverted covariance matrix between the coordinates, also stored in the HBM
(violet). The number of coordinates is
$N_{\text{coo}}~{}=~{}2N_{\text{pixels}}~{}+~{}N_{\text{strips}}$, with pixels
contributing two coordinates and strips only one. $N_{\text{dof}}$ is the
number of degrees of freedom,
$N_{\text{dof}}~{}=~{}N_{\text{coo}}~{}-~{}N_{\text{par}}$, with the number of
track parameters $N_{\text{par}}~{}=~{}5$. It should be noted that the
algorithm also allows for tracks with up to two missing clusters, e. g. due to
detector inefficiencies. In these cases, the track parameters and $\chi^{2}$
can be recovered by a minimization with respect to the coordinates of the
missing clusters, or by generating additional sets of constants that could be
directly applied into equations 2.1 and 2.2.

The computations in the Track Fitter block rely solely on multiply-accumulate
(MAC) operations. Hence, they can be efficiently implemented with the FPGA’s
integrated DSPs. A cut on the $\chi^{2}$ value is implemented to reject most
of the wrong combinations of clusters before computing the track parameters,
such that only about $8\text{\,}\%$ of the tracks are selected, as shown in
Table 2. This concludes the data processing on the Intel Stratix 10 FPGA. For
each track (black), its track parameters, its $\chi^{2}$ value, and the
associated cluster information (represented by the black lines) are sent from
the PRM to the TP via high speed serial links.

###  2.2 Requirements

Table 2 summarizes the requirements for the Pattern Recognition Mezzanine in
the TDAQ baseline architecture with HTT as part of the Event Filter System.
These requirements are derived from simulations of the expected data flow
through the entire HTT system for pile up <$\mu$> = 200 [20]. The main
parameters that affect the processing speed are the average cluster rate, road
processing rate, fit constants access rate, and track fitting rate. In the
low-latency scenario, an additional constraint on the processing latency of
$\mathcal{O}($1\text{\,}\mathrm{\SIUnitSymbolMicro s}$)$ has to be fulfilled.
The HBM storage requirements for a full PRM are about
$73\text{\,}\mathrm{M}\mathrm{B}$ to hold the patterns, and about
$375\text{\,}\mathrm{M}\mathrm{B}$ for the constants, estimated from
simulation studies. Multiple copies of the patterns and constants can be
stored in the HBM to fulfil the rate requirements.

Table 2: Main parameters for the PRM and their requirements derived from the HTT system in the TDAQ Phase-II baseline design. The values are related to an expected maximum event request rate of $240\text{\,}\mathrm{k}\mathrm{H}\mathrm{z}$ and refer to one of four firmware units working in parallel within the PRM that are connected to separate groups of 5 AM ASICs. | Requirements
---|---
Parameter | per group of ASICs
Peak cluster rate per layer | $95\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$
Roads processing rate | $77\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$
Constants readout rate ($\chi^{2}$ calculation) | $41\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$
Fit rate ($\chi^{2}$ calculation) | $714\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$
Constants readout rate (parameter calculation) | $41\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$
Fit rate (parameter calculation) | $57\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$
Track output rate | $57\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$

##  3 Block description of firmware for standalone testing

The PRM firmware has been developed and tested in a "standalone" set-up, where
the transceivers and the ASIC functionalities have been emulated through a
Data Generator and an ASIC Emulator block. The corresponding firmware diagram
is shown in Figure 7. In the following, the individual blocks are described in
more detail in the order of the data flow.

Figure 7: PRM standalone block diagram. The dashed arrows are for paths
representing the storage of patterns or constants into memory. The solid line
arrows are for data paths.

###  3.1 Data Generator

The Data Generator block role is to provide different test modes, initialize
the PRM internal memories with the necessary constants, inject the data, and
check the results. The block diagram is shown in Figure 8.

Figure 8: Data Generator block diagram with activated SSID Encoder.

For the first functionality, the Control Signal block handles the different
testing modes. Two injection modes have been implemented: with and also
without the SSID Encoder block, responsible for the assignment of an SSID to
each cluster. The selection between the two modes is done at compilation time.
In both modes various parameters of the data injection can be controlled, such
as the injection frequency and the number of events. In addition, it is
possible to add randomly generated fake clusters and SSIDs into the data
stream, to emulate the real detector behavior in the high-pile-up environment.

The PRM internal memories are initialized when a memory initialization command
is issued. The fit constants are uploaded from the Constants RAM into the
High-Bandwidth Memory, presented in Section 3.4, through the Storing to HBM
block. The track patterns are also sent from the PRM Extended Input RAM to the
ASIC Emulator block, described in Section 3.2, and to the HBM via the Storing
to ASIC Emulator and HBM blocks.

Following the initialization of the memories, the injection is started. The
PRM Input RAM contains the clusters in the same format as expected to be
computed in the TP motherboard.

For the results check, the PRM Extended Input RAM contains the simulated true
track $\chi^{2}$ and the helix parameters for an easy comparison that happens
in the Comparator block.

###  3.2 ASIC Emulator

The ASIC Emulator implements the AM pattern matching by storing 16 patterns
per instance, each configurable at run-time. It uses the same data and road
bus input and output interfaces as the internal core of the AM ASIC [9]. To
fully mimic a single group of AM ASICs on the PRM, a daisy chain of five
emulator instances is implemented. Figure 9 shows a block diagram of a group
of five ASIC Emulators.

Figure 9: ASIC Emulator and Interface block diagram.

The input bus is designed to supply the ASIC Emulator with three types of
data: cluster data, control commands, and the idle character. The Input
Decoder distributes cluster data to the Core block and commands to the
Controls block. The Core block stores the patterns and implements the pattern
matching functionality. The Controls block decodes the commands and implements
the execution timing structure. Events are initialized before the first SSIDs
are to be sent to the core for comparison, and ended to gather the information
from all matches. All matched roadIDs are then read out in series. The roadIDs
from the Core block are combined in the Arbiter block with the output from the
Controls block. The output data streams of the five emulators are connected in
three daisy-chains of up to two emulators, mimicking the hardware
implementation on the demonstrator. The total output data is collected in the
ASIC Interface via another Arbiter block and sent to the Data Organiser.

###  3.3 Data Organiser

The Data Organiser is an on-the-fly database that allows fast access to the
cluster position and their SSID. This is critical to extract the cluster from
a matched pattern for the linearized track fit. A schematic view of the Data
Organiser block is shown in Figure 10.

Figure 10: Data Organiser block diagram.

The clusters and SSIDs coming from the Data Generator or from the SSID
Encoding and Sorting blocks, already organised per layer, are temporarily
stored in FIFOs in the Queueing block. This makes sure that the readout of the
previous event has been completed.

Later, a three-memory structure is used in order to better retrieve the
clusters. The Data Organiser has been designed under the assumption that all
clusters for a given SSID arrive in one uninterrupted sequence. The Cluster
List Memory sequentially stores each cluster received. The Cluster List
Pointer stores the Cluster List Memory address of the first cluster stored for
each SSID. The Cluster Counter Memory stores the number of clusters in each
SSID. These functions are performed in parallel for all eight layers.

The Interface block forwards the roadID from the ASIC Emulator blocks towards
the High Bandwidth Memory. The SSID list returned by the HBM for a matched
pattern is used to retrieve the correct clusters from the DO memories. The
found roads are then sent towards the Track Fitter block.

###  3.4 High-Bandwidth Memory Interfaces

The High-Bandwidth Memory block, shown in Figure 11, stores the patterns as
well as the constants needed for the computation of the quality of the track
fit ($\chi^{2}$) and the corresponding track parameters.

Figure 11: High-Bandwidth Memory user logic block diagram. CDC FIFO = Clock
Domain Crossing FIFO, ps-ch = pseudo-channel. The functionality of the
individual blocks is described in the text.

FIFO buffers are used at the interfaces between the core logic and the HBM AXI
user logic for crossing the clock domains, as each HBM channel has an
independent clock, and also for handling back pressure. Two distinct user
interfaces are implemented to best match the required data rates and
interfaces of the Data Organiser (HBM2DO) and the Track Fitter (HBM2TF).

As the individual data packets requested from the HBM are rather small
(ranging from 18 Bytes for each pattern for the Data Organiser, to a maximum
of 364 Bytes for each set of constants for the Track Fitter), all channels
used of the Intel HBM IP [21] are configured in burst length 4 mode, returning
32 Bytes per single read request. The HBM IP internal Read-Order-Buffers are
enabled to simplify the data flow. They can be bypassed to improve latency and
bandwidth. The remaining settings of the IP have been optimized in simulation
studies for lowest latency and highest throughput. Latency histograms have
been implemented within the AXI interfaces to be able to monitor the read data
turnaround time.

The Data Organiser requests the patterns from the HBM2DO interface by sending
the roadID paired with a requestID. The HBM2DO translates the roadID into a
valid memory address (Road2AXI). Two pseudo-channels are used within the
HBM2DO to match the maximum rate requirements. A scheduler checks which
pseudo-channel can serve a read request and evens the load on the two pseudo-
channels connected using round-robin arbitration. The requestID is stored
temporarily matching the AXI-ID used to send out the read request to the HBM
IP.

The data received from the HBM is matched to the requestID retrieved via the
AXI-ID. A scheduler merges the data streams of the two pseudo-channels towards
the output FIFO. The data is split into sectorID and SSIDs for the Data
Organiser to continue processing.

The Track Fitter requests constants from the HBM2TF for $\chi^{2}$ and/or
parameter computations specifying the sectorID. The request gets distributed
to one of 6 pseudo-channels connected using round-robin arbitration, taking
into account if a pseudo-channel is currently busy. Within a pseudo-channel
interface, a number of consecutive AXI memory read requests is issued to
retrieve a full set of constants (Sector2AXI). Upon return of the data, the
last chunk of a set of constants is flagged which allows the Track Fitter to
easily identify when a set of constants has been fully retrieved. This allows
operation of the HBM even without the Read-Order-Buffers being enabled.

In order to write the patterns and constants data into the HBM, an IPbus [22]
compatible interface has been implemented. For online monitoring and
configuring of the HBM, an IPbus to Advanced Peripheral Bus (APB) translator
interface has been developed.

###  3.5 Track Fitter

The Track Fitter block, shown in Figure 12, assesses the quality of the track
candidates by computing the $\chi^{2}$ value, and then extracts the track
parameters for those tracks that pass the $\chi^{2}$ test. Upon arrival of a
road data set, the Track Fitter retrieves the constants for the $\chi^{2}$
computation from the HBM. All constants are encoded as signed
$32\text{\,}\mathrm{b}\mathrm{i}\mathrm{t}$ floating point numbers. Hence, all
DSPs implemented are used in floating point mode.

Figure 12: Flow diagram of the Track-Fitter. Buffers and other minor entities
are not displayed.

In the Track Distributor, all possible combinations of clusters from the
matched patterns are generated as candidate tracks for the fit. To match the
required data rates, this is performed through four parallel sub-entities,
each associated with a Chi Square Unit block. For each track candidate, the
HBM interface retrieves the corresponding constants. All constants requests
are buffered while one set of constants is retrieved, and a supporting entity
aligns each set to the corresponding track data.

The Chi Square Unit receives a track candidate ($x_{j}$), and its IDs and
constants ($S_{i,j}$ and $h_{i}$) simultaneously. Here, the scalar products
per number of coordinates are executed in parallel for all degrees of freedom,
according to the inner sum of Equation 2.2, using a cascaded pipeline.
Likewise, the scalar product over all degrees of freedom is performed,
according to the outer sum of the Equation 2.2. This design can perform a
calculation at every clock cycle with a fixed latency, and originates from the
works of [23] and [24]. Finally, the track parameters for this track candidate
will be computed if the resulting $\chi^{2}$ is below a predefined threshold.

Since only $8\text{\,}\%$ of the track candidates are expected to pass the
selection in the studied configuration, see Table 2, only one Parameter
Calculator block is instantiated. Here, the HBM interface provides again the
constants, and a scalar product per parameter is executed according to
Equation 2.1. The resulting parameters, the $\chi^{2}$ of the track fit, and
the clusters are converted into $16\text{\,}\mathrm{b}\mathrm{i}\mathrm{t}$
fixed point numbers and transferred to the comparator block of the data
generator.

###  3.6 Monitoring

The Monitoring block handles the communication between the PRM FPGA and an
external PC, via Ethernet using IPbus protocol over UDP. The block diagram is
shown in Figure 13.

Figure 13: Monitoring block diagram.

The Physical (PHY) and the Medium Access Control (MAC) layer blocks are
Ethernet-dedicated IP cores provided by Intel. To allow the communication
between the MAC block (Avalon ST interface) and the IPbus block (AXI
Interface), a dedicated converter module has been designed. Information about
the functionality of the IPbus core can be found in [22]. Hardware checks
(e.g. voltages, temperatures), firmware configuration (e.g. data generator
setup), and data flow monitoring (e.g. FIFO full and empty, counters) can be
all executed via this block. The software part of the communication is
provided by the same group which developed the IPbus core [22].

##  4 Implementation and results

The firmware described above has been implemented and tested on an Intel
Stratix 10 MX development kit, which features a nearly-identical FPGA to the
one chosen for the PRM prototype666The FPGA on the development kit (part
number 1SM21BHU2F53E1VG) and the one on the PRM (part number 1SM21BHN3F53E3VG)
differ only in transceiver count, transceiver speed grade, and FPGA fabric
speed grade.. Simulation studies have been conducted using QuestaSim version
2019.4 [25]. The Intel Quartus Prime Pro software version 19.2 [26] has been
used for hardware synthesis and fitting. The results of the initial firmware
implementation are presented. It does not include further optimizations that
would allow to meet all the requirements of the HTT system; these are
presented as proposals in the final section of the paper.

###  4.1 Resource usage

The resource utilization after the final fitting step for each entity of the
standalone implementation is presented in Table 3. The block-by-block as well
as the total occupancy are presented in absolute numbers and in % fraction of
the full device resources. In addition to the individual components, the
resource usage of the top level (where all blocks are interconnected) is shown
with the addition of SignalTap [27] debug monitoring. All blocks that are
expected to consume significant logic resources are implemented and considered
in this measurement. More advanced features, in particular the extension to
include tracks with missing clusters, are not implemented.

ALMs k (%) Logic Registers k (%) Block Memory kb (%) DSPs # (%) HBM GB (%)
Data Generator 17.36 (2.47) 26.67 (0.95) 206.03 (0.15) 0 (0.00) 0 (0.00) ASIC
Emulator 7.06 (1.08) 16.42 (0.58) 45.28 (0.03) 0 (0.00) 0 (0.00) Data
Organiser 4.78 (0.68) 6.20 (0.22) 11,625.48 (8.29) 0 (0.00) 0 (0.00) High
Bandwidth Memory 14.15 (2.01) 39.85 (1.42) 188.91 (0.13) 0 (0.00) 2.00 (25.00)
Track Fitter 112.06 (15.95) 235.68 (8.38) 541.84 (0.39) 424 (10.7) 0 (0.00)
Monitoring 7.90 (1.12) 12.97 (0.46) 934.15 (0.67) 0 (0.00) 0 (0.00) Top level
+ Debug 8.19 (1.17) 17.14 (0.61) 321.06 (0.23) 0 (0.00) 0 (0.00) TOTAL 172.04
(24.48) 354.92 (12.63) 13,862.75 (9.89) 424 (10.71) 2.00 (25.0) TOTAL w/o Data
Generator and ASIC Emulator 154.69 (20.93) 328.25 (11.09) 13,611.44 (9.71) 424
(10.71) 2.00 (25.0)

Table 3: Resource usage of the PRM standalone firmware on the Intel Stratix 10
MX 2100. Absolute values are given (in multiples of 1000 = k), accompanied by
the corresponding percentage of the device in brackets. For considerations on
the final design the Data Generator and the ASIC Emulator blocks should not be
taken into account, as they are used only for standalone testing.
Abbreviations are explained in the text.

The Track Fitter, where the track-dedicated algorithms are implemented, is the
block using the most logic resources, i. e. Adaptive Logic Modules (ALMs),
registers, and Digital Signal Processing (DSP) blocks. The Data Organiser,
where the data are stored during the pattern recognition step, is the block
consuming the majority of the memory resources. The FPGA occupancy does not
exceed one quarter of the available resources. Considering that optimizations
could further reduce the resource utilization significantly, it would be
feasible to fulfill the PRM system requirement of implementing four
independent instances in parallel, including the missing extensions. For
operation on the PRM board, the ASIC emulator would be replaced by the actual
ASIC interface and the Data Generator by the input/output buffers,
synchronization modules777The Cluster to SSID Encoding block is already
included in the Data Generator., and the output formatter. Hence, the total
resource utilization excluding the contribution of these two entities should
be considered.

###  4.2 Clock and power studies

In order to satisfy the system requirements presented in Table 2, the PRM
firmware was planned with the goal of running the Track Fitter block at
$200\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$, and the rest of the logic at
$250\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$.

The hardware tests with the standalone firmware have been performed
constraining the design for a core clock speed of
$100\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$, aiming to verify the hardware
implementation rather than optimizing for highest processing speed. A single
clock domain has been used for the entire design, with the exception of the
HBM that is operated at a memory clock frequency of
$600\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$ and a core clock frequency of
$300\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$. Without violating internal setup
and hold time requirements, the maximum core clock frequency $f_{\rm{max}}$
reported by the Timing Analyzer (part of the Intel Quartus Prime Pro software)
is $f_{\rm{max}}=$105\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$$ in the worst
case (Slow $900\text{\,}\mathrm{m}\mathrm{V}$ Model @
$100\text{\,}{}^{\circ}\mathrm{C}$).

Under these conditions, the Quartus Power Analyzer tool estimated the total
thermal power dissipation to be about 11 W, where about 6 W are due to the
device static thermal power dissipation. Unfortunately, the Quartus tool does
not include a power model for the HBM component. Its power consumption can
hence not be properly estimated in this stage of the development.

In order to better understand the most critical blocks, dedicated
$100\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$ clock lines are used for each
block by splitting the core clock with a PLL. The results per block are
reported below in Table 4. It is important to note that in these studies clock
domain crossings have not been properly implemented. Although this should not
affect the performance and functionality of the individual blocks, treating
these crossings correctly is important for their interconnection, and could
potentially further improve the results. The following operating conditions
are used for this study. The $V_{cc}$ minimum supply voltage is fixed at
$900\text{\,}\mathrm{m}\mathrm{V}$, and the temperature is set to
$0\text{\,}{}^{\circ}\mathrm{C}$ and $100\text{\,}{}^{\circ}\mathrm{C}$, which
represent the two extreme corner cases for the $f_{\rm{max}}$ value.

| Slow 900 mV
---
Model
| Target Clock
---
Speed (MHz)
| Data Organiser
---
$f_{\rm{max}}$ (MHz)
| HBM
---
$f_{\rm{max}}$ (MHz)
| Track Fitter
---
$f_{\rm{max}}$ (MHz)
| Data Generator
---
$f_{\rm{max}}$ (MHz)
| ASIC Emulator
---
$f_{\rm{max}}$ (MHz)
100 ∘C | 100 | 141.60 | 301.39 | 114.94 | 141.26 | 136.69
0 ∘C | 154.63 | 322.37 | 125.20 | 152.39 | 148.08

Table 4: Per block $f_{\rm{max}}$ derived from static timing analysis for a
target clock of $100\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$
($300\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$ for the HBM). For considerations
of the final design only the Data Organiser, HBM and Track Fitter should be
taken into account.

A test has been made to evaluate the work needed to fulfill the HTT system
requirement to run at higher frequencies. With the current design constraints
and targeting an input clock speed of
$200\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$, an
$f_{\rm{max}}=$174\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$$ (Slow
$900\text{\,}\mathrm{m}\mathrm{V}$ Model @ $100\text{\,}{}^{\circ}\mathrm{C}$)
was achieved, not yet meeting our requirements. The Track Fitter block yields
the lowest $f_{\rm{max}}$ of all the individual blocks. An algorithm rework
would be required for a substantial speed optimization, as will be discussed
in the final section.

For this clock speed, the Quartus Power Analyzer tool estimated the total
thermal power dissipation to be about $15\text{\,}\mathrm{W}$, where about
$6\text{\,}\mathrm{W}$ are due to the device static thermal power dissipation,
excluding the HBM contribution.

###  4.3 Performance studies

The performance of the standalone firmware, with a focus on the processing
latency, has been evaluated in simulation using dedicated test vectors derived
from the software simulation of the HTT system [8]. A test vector is a
collection of information of cluster positions and track parameters, generated
by the simulation that reproduces the algorithms of the linearized track fit,
and converted into $32\text{\,}\mathrm{b}\mathrm{i}\mathrm{t}$ words readable
by the Data Generator interface. Simulated events with single muon tracks
crossing the ITk layers are used.

Larger event sizes have been studied by repeating the same track multiple
times as an intermediate step towards more realistic conditions. Each track
consists of one cluster per layer. This was done to study the constants
request rate and latency, as every track implies a request of constants
towards the HBM. Test vectors with few additional fake clusters, i. e.
clusters not belonging to any real track, have also been used during hardware
verification, but have not been part of the performance evaluation. Studies
trying to mimic realistic HL-LHC conditions by injecting events which fulfill
approximately the number of roads and fits per event, as specified in Table 2,
have been started but could not be concluded for this publication. For the
performance studies reported here, the SSID Encoding and Sorting block within
the Data Generator has not been included. However, both Data Generator modes,
with and without the SSID Encoding and Sorting block, have been verified in
hardware. Despite the limitations in clock speed seen in the hardware
implementation, the simulation has been run at a clock speed of
$250\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$, with the exception of the HBM
user logic running at $300\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$, as
explained in section 4.2.

(a) HBM pattern read latency, 1 track/event

(b) HBM pattern read latency, 16 tracks/event

(c) HBM constants read latency, 1 track/event

(d) HBM constants read latency, 16 tracks/event

(e) Track latency, 1 track/event

(f) Track latency, 16 tracks/event

Figure 14: Processing latencies of different parts of the PRM firmware for
events with a single track (left) and events with 16 tracks (right) in clock
cycles of $f_{core}=$250\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$$. (a) and (b)
show the latency of patterns being returned from the HBM when requested by the
Data Organiser. (c) and (d) show the latency of full sets of constants
returned from the HBM when requested by the Track Fitter. (e) and (f) show the
latency of a track through the processing pipeline, between its appearance as
a road at the output of the ASIC emulator and the final track at the output of
the Track Fitter. For all distributions, mean and standard deviations are
given.

For events with single and multiple tracks, the processing latency per block
has been measured as a function of the event rate. Single-track events are
filled at a rate of $886\text{\,}\mathrm{k}\mathrm{H}\mathrm{z}$. For events
with 16 tracks we chose an event rate of
$541\text{\,}\mathrm{k}\mathrm{H}\mathrm{z}$, leading to road, track, cluster,
constants readout and fit rates of
$8.65\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$. These event rates are chosen to
keep well separated single-event processing, since the handling of multiple
concurrent events is not implemented.

Figure 14 shows the histograms of the memory latency between the HBM and the
Data Organiser, between the HBM and the Track Fitter, and also the full
processing latency of each individual track from the output of the ASIC
emulator to the output of the Track Fitter. About 4000 events have been
processed to capture the effect of the HBM on the latency. The majority of the
read requests are served in a short time of about
$250300\text{\,}\mathrm{n}\mathrm{s}$; there are tails of up to about
$1\text{\,}\mathrm{\SIUnitSymbolMicro}\mathrm{s}$ due to the dynamic nature of
the HBM, being a DRAM, which requires refreshing of the stored data every few
microseconds. During the refresh, the HBM pseudo-channel cannot serve any read
requests. This behaviour is inherently different compared to internal/external
SRAM or the FPGA’s internal block RAM. Compared to single track events, no
significant increase on the average HBM latency per pattern or set of
constants is observed for events with 16 tracks, because the overall HBM
request rates are still well below the bandwidth limits.

The accumulated HBM latency accounts for the biggest part of the total latency
as there are three separate accesses per track: to retrieve the pattern, the
constants for the $\chi^{2}$ computation, and the constants for the track
parameter calculation. Considering the mean values of the latency
distributions, about $66\text{\,}\%$ ($60\text{\,}\%$) of the latency is due
to the HBM for events with single tracks (16 tracks). Moreover, we have an
increase of latency in the total processing pipeline. This can be linked to
the Data Organiser, which in its current state needs 3 clock cycles to
transfer a single road to the Track Fitter, and to the Track Fitter itself,
whose processing can be temporarily interrupted when the requested constants
are delayed. The average total processing latency is
$1.3\text{\,}\mathrm{\SIUnitSymbolMicro}\mathrm{s}$
($1.5\text{\,}\mathrm{\SIUnitSymbolMicro}\mathrm{s}$) for events with single
tracks (16 tracks), with increasing tails in the distribution for higher track
rates888In the presence of high energy jets and pileup 200 we would expect an
average of about 320 roads and 80 tracks per event per group of ASICS.. These
tails could be reduced by optimizing the design of the Track Fitter and the
output of the Data Organizer. No significant increase in latency due to the
HBM is expected at the required rates (Table 2). More details on design
optimizations are given in the following section.

###  4.4 Considerations for a final design

These studies show a possible implementation of the main functionalities of
the firmware for a linearized track fit with 8 detector layers, associated to
AM pattern matching. Not all requirements from the HTT system design, outlined
in Table 2, are achieved at this stage of our development. For example, the
$\chi^{2}$ fit rate requirement of
$714\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$ can be achieved with a clock
speed for the Track Fitter of $200\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$,
but hit a limit of $f_{\rm{max}}=$175\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$$
in our design. Because of this, and in order to lower its resource usage, the
Track Fitter block would be the very first candidate for optimizations. This
is despite the expectation that it will consume the largest fraction of
resources compared to all other blocks. For instance, the interface between
the Track Fitter and the HBM could be simplified such that there is one
dedicated Chi Square Unit per HBM pseudo-channel, instead of the current
implementation where all four Chi Square Units can retrieve their constants
from all of the six HBM pseudo-channels. This may have a positive impact on
the achievable $f_{\rm{max}}$ within the Track Fitter, and therefore increase
the overall throughput. The mean processing latency measured in simulations
exceeds the target of $1\text{\,}\mathrm{\SIUnitSymbolMicro}\mathrm{s}$ for
the low-latency scenario. Several options could be adopted to reduce latency:

  * •

From simulation studies we know that the Read-Order-Buffer within the HBM
Controller yields a large latency penalty, especially when considering higher
request rates. Removing this buffer, however, comes at the cost of increasing
complexity of the data processing at the Track Fitter and Data Organiser.

  * •

The constants for the $\chi^{2}$ and parameter calculations within the Track
Fitter could be requested in parallel, as opposed to the current
implementation where the second set of constants is only requested when the
track has passed the $\chi^{2}$ cut. This comes at the cost of increased HBM
bandwidth.

  * •

The constants for the Track Fitter could be requested as soon as the HBM has
retrieved the pattern for the Data Organiser in parallel to the processing
pipeline. This is instead of waiting for the data being transferred from the
Data Organiser to the Track Fitter, which then requests the constants.
Moreover, the sectorIDs could be stored in the FPGAs internal eSRAM, which has
a much shorter read latency than the HBM. That would allow for truly parallel
retrieval of the patterns and the fit constants from the HBM. From simulation
studies of the HBM model at the required roads processing rates and constants
readout rates specified in Table 2, it is expected that $99\text{\,}\%$ of
patterns and constants would be returned within
$650\text{\,}\mathrm{n}\mathrm{s}$ after their request.

  * •

The Track Fitter could be adapted to start calculations as soon as a single
chunk of constants has arrived, instead of waiting for the full set of
constants being returned from the HBM. This would however require a drastic
re-design of the Track Fitter block.

  * •

The overall number of constants could be reduced by adopting an algorithm as
it is reported in [14]. This makes use of hit position transformations to
address the non-linearities of the system in order to reduce the number of
sectors. This could allow the removal of the need for an HBM to retrieve the
constants at all. However, this would not only require a complete redesign of
the blocks following the Data Organiser within the PRM firmware, but also
major changes to the simulation software of the full HTT system.

  * •

Lastly, clock speed may be increased if a better speed grade version of the
FPGA is used. This change would also impact the HBM’s read latency, as the
core and memory frequency could be raised as well. This change would not
require any design changes on the hardware or firmware, but increase the
board’s production costs.

##  5 Conclusion

Within the HTT project, a custom-hardware tracking system has been designed.
It is relying on associative memories for pattern matching and FPGAs for data
organization, communication, and track fitting. Even if the project is
abandoned in ATLAS, many studies have been performed to assess its
feasibility, both on hardware demonstrators and with simulations. The Pattern
Recognition Mezzanine as part of the HTT system features the pattern matching
and track fitting capabilities. Key challenges to the design of the PRM
firmware are the high processing rates, e. g. the fit rate of
$$4$\times$714\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$$, and the low-latency
target of order $1\text{\,}\mathrm{\SIUnitSymbolMicro}\mathrm{s}$ requested
for a short-latency L1 trigger scenario.

This paper describes the implementation of the firmware for the PRM board, its
validation in simulation, and tests on an Intel Stratix 10 MX development kit.
The major processing blocks, i. e. Data Organiser, Track Fitter, and HBM
interfaces, have been implemented and tested using an AM ASIC Emulator and
Data Generator developed specifically for this task. Resource utilization of
these blocks is in agreement with the requirements for a full PRM board. Even
if the requirements imposed by the HTT system design are not met, its
feasibility with modern FPGAs with High-Bandwidth Memories is assessed.
Although High-Bandwidth Memories are optimized for highest throughput at a
cost of higher latencies compared to SRAM or internal block memory, they can
be utilized in low-latency
($\mathcal{O}($1\text{\,}\mathrm{\SIUnitSymbolMicro}\mathrm{s}$)$)
applications that require large data storage. Many improvements are possible
that could reduce the latency and resource utilization, leaving space for
optimizations for custom hardware systems in future experiments.

## Acknowledgments

We acknowledge support by the Federal Ministry of Research and Education
(BMBF), the Swiss National Science Foundation (SNSF), the University of
Geneva, Department of Nuclear and Particle Physics, the Italian Istituto
Nazionale di Fisica Nucleare and the Aristotle University of Thessaloniki,
School of Physics. We would like to thank Francesca Pastore, Naoki Kimura, and
Mel Shochet for valuable feedback that helped shape this article.

## References

  * [1] G. Apollinari, I. Béjar Alonso, O. Brüning, P. Fessia, M. Lamont, L. Rossi and L. Tavian, _High-Luminosity Large Hadron Collider (HL-LHC): Technical Design Report V. 0.1_ , CERN, Geneva (2017), https://cds.cern.ch/record/2284929.
  * [2] ATLAS Collaboration, _The ATLAS Experiment at the CERN Large Hadron Collider_ , JINST 3 (2008); https://doi.org/10.1088/1748-0221/3/08/s08003.
  * [3] ATLAS Collaboration, _ATLAS Phase-II Upgrade Scoping Document_ , CERN, Geneva (2015), https://cds.cern.ch/record/2055248.
  * [4] ATLAS Collaboration, _Technical Design Report for the ATLAS Inner Tracker Pixel Detector_ , CERN, Geneva (2017), https://cds.cern.ch/record/2285585
  * [5] ATLAS Collaboration, _Technical Design Report for the ATLAS Inner Tracker Strip Detector_ , CERN, Geneva, (2017) , https://cds.cern.ch/record/2257755.
  * [6] ATLAS Collaboration, _Technical Design Report for the Phase II Upgrade of the ATLAS TDAQ System_ , CERN, Geneva (2017), https://cds.cern.ch/record/2285584.
  * [7] ATLAS collaboration, _Expected tracking and related performance with the updated ATLAS Inner Tracker layout at the High-Luminosity LHC_ , CERN, Geneva (2021), http://cds.cern.ch/record/2776651
  * [8] ATLAS TDAQ Collaboration, _Technical Design Report for the Phase-II Upgrade of the ATLAS Trigger and Data Acquisition System - EF Tracking Amendment_ , CERN, Geneva (2022), https://cds.cern.ch/record/2802799
  * [9] A. Stabile et al., _Phase-II Associative Memory ASIC Specifications_ , CERN, Geneva (2018), CERN-OPEN-2018-003, https://cds.cern.ch/record/2320701
  * [10] B. Ashmanskas et al. [CDF], _The CDF silicon vertex trigger_ , Nucl. Instrum. Meth. A 518 (2004), 532-536, doi:10.1016/j.nima.2003.11.078, [arXiv:physics/0306169 [physics]].
  * [11] G. Aad et al. [ATLAS], _The ATLAS Fast TracKer system_ , JINST 16 (2021), P07006, doi:10.1088/1748-0221/16/07/P07006 [arXiv:2101.05078 [physics.ins-det]].
  * [12] M. Mårtensson on behalf of the ATLAS collaboration, _Fast pattern recognition of ATLAS L1 track trigger for HL-LHC_ , PoS Vertex2016 (2017) 069, doi:10.22323/1.287.0069
  * [13] R. Aggleton et al., _An FPGA based track finder for the L1 trigger of the CMS experiment at the High Luminosity LHC_ , JINST 12 (2017), P12019, doi:10.1088/1748-0221/12/12/P12019
  * [14] E. Clement et al., _A high-performance track fitter for use in ultra-fast electronics_ , Nucl. Instrum. Meth. A 935 (2019), 95-102, doi:10.1016/j.nima.2019.05.018, [arXiv:1809.01467 [physics.ins-det]]
  * [15] PICMG, PICMG 3.0 Revision 2.0, _AdvancedTCA Base Specification_ , http://www.picmg.org
  * [16] G. Aad et al., _Technical Design Report for the Phase-I Upgrade of the ATLAS TDAQ System_ , CERN (2013), https://cds.cern.ch/record/1602235
  * [17] Panduro Vazquez, Jose Guillermo and ATLAS TDAQ Collaboration, _FELIX: the new detector interface for ATLAS_ , CERN (2020), https://cds.cern.ch/record/2709188
  * [18] Cisco Systems, _Serial-GMII Specification_ , (2005) https://archive.org/details/sgmii
  * [19] _IEEE Standard Test Access Port and Boundary Scan Architecture_ , in IEEE Std 1149.1-2001, pp.1-212, 23 July 2001, doi: 10.1109/IEEESTD.2001.92950.
  * [20] S. Dittmeier on behalf of the ATLAS TDAQ Collaboration, _The ATLAS Hardware Track Trigger design towards first prototypes_ , PoS Vertex2019 (2020) 049, https://doi.org/10.22323/1.373.0049.
  * [21] Intel®, _High Bandwidth Memory (HBM2) Interface Intel® FPGA IP User Guide_ , https://www.intel.com/content/www/us/en/docs/programmable/683189/21-3-19-6-1/about-the-high-bandwidth-memory-hbm2.html
  * [22] C. Ghabrous Larrea, K. Harder, D. Newbold, D. Sankey, A. Rose, A. Thea and T. Williams, _IPbus: a flexible Ethernet-based control system for xTCA hardware_ , JINST 10 (2015) no.02, C02019. doi:10.1088/1748-0221/10/02/C02019
  * [23] M. Braagaard et al., _Implementation of a linearized $\chi^{2}$-Square [sic] method for the ATLAS Pattern Recognition Mezzanine_, Technical University of Denmark, Department of Applied Mathematics and Computer Science, Lyngby Denmark (2020)
  * [24] M. Jensen et al.,_Implementation of Particle Track Parameter Calculations for the ATLAS Pattern Recognition Mezzanine_ , Technical University of Denmark, Department of Applied Mathematics and Computer Science, Lyngby Denmark (2020)
  * [25] Siemens®, _Questa Advanced Simulator_ , https://eda.sw.siemens.com/en-US/ic/questa/simulation/advanced-simulator/
  * [26] Intel®, _Intel® Quartus® Prime - FPGA Design Software_ , https://www.intel.com/content/www/us/en/software/programmable/quartus-prime/overview.html
  * [27] Intel®, _About the SignalTap II Logic Analyzer_ , https://www.intel.com/content/www/us/en/programmable/quartushelp/13.0/mergedProjects/program/ela/ela_view_using.htm


# Reconfigurable Intelligent Surface-Assisted Backscatter Communication: A New
Frontier for
Enabling 6G IoT Networks

Sarah Basharat  Syed Ali Hassan  Aamir Mahmood  Zhiguo Ding  and Mikael
Gidlund  S. Basharat and S. A. Hassan are with the School of Electrical
Engineering and Computer Science (SEECS), National University of Sciences and
Technology (NUST), Islamabad 44000, Pakistan.A. Mahmood and M. Gidlund are
with Mid Sweden University, Sweden.Z. Ding is with the School of Electrical
and Electronic Engineering, The University of Manchester, Manchester M13 9PL,
U.K.

###### Abstract

Backscatter Communication (BackCom), which is based on passive reflection and
modulation of an incident radio-frequency (RF) wave, has emerged as a cutting-
edge technological paradigm for self-sustainable Internet-of-things (IoT).
Nevertheless, the contemporary BackCom systems are limited to short-range and
low data rate applications only, thus rendering them insufficient on their own
to support pervasive connectivity among the massive number of IoT devices.
Meanwhile, wireless networks are rapidly evolving towards the smart radio
paradigm. In this regard, reconfigurable intelligent surfaces (RISs) have come
to the forefront to transform the wireless propagation environment into a
fully controllable and customizable space in a cost-effective and energy-
efficient manner. Targeting the sixth-generation (6G) horizon, we anticipate
the integration of RISs into BackCom systems as a new frontier for enabling 6G
IoT networks. In this article, for the first time in the open literature, we
provide a tutorial overview of RIS-assisted BackCom (RIS-BackCom) systems.
Specifically, we introduce the four different variants of RIS-BackCom and
identify the potential improvements that can be achieved by incorporating RISs
into BackCom systems. In addition, owing to the unrivaled effectiveness of
non-orthogonal multiple access (NOMA), we present a case study on an RIS-
assisted NOMA-enhanced BackCom system. Finally, we outline the way forward for
translating this disruptive concept into real-world applications.

##  I Introduction

THE Internet-of-Things (IoT) is envisaged as one of the key technology trends
towards the development of intelligent Internet solutions for future sixth-
generation (6G) systems [1]. The IoT paradigm targets seamlessly connecting
massive power-limited sensor-like devices, with data sensing and transmission
capabilities, for realizing diverse applications, such as environmental
sensing, industrial automation, pervasive monitoring, intelligent
transportation, smart farming, and smart cities. According to the Cisco
report, “500 billion devices are expected to be connected to the Internet by
2030” [2]. Nonetheless, despite the rapid research and evolution over the
recent years, IoT is still at the germination stage, awaiting a large-scale
deployment and a wide-range commercialization. In many IoT applications,
powering the IoT devices is a major challenge, especially when battery
maintenance is not feasible due to cost, inconvenience, and the size of the
networks. In this context, energy harvesting is a promising solution for self-
sufficient and self-sustainable operations of IoT networks.

Backscatter communication (BackCom), one of the energy harvesting techniques,
has emerged as an energy-efficient solution for pervasive connectivity of
power-limited wireless devices in an IoT network [3]. BackCom enables the
passive backscatter devices (BDs) to not only transmit information, through
reflection and modulation of incident RF signals via intentional load
impedance mismatch at the antenna, but also to harvest energy from the
incident signals to sustain its operations. Thus, with this energy saving
feature, BackCom achieves a green communication paradigm for IoT networks.

The architecture of BackCom systems has evolved over time with three different
configurations, namely monostatic, bistatic, and ambient [5].

Monostatic BackCom Systems: In a monostatic BackCom system, such as RF
identification (RFID), the carrier emitter (CE) and backscatter receiver (BR),
are integrated as a single equipment, i.e., reader. The reader transmits the
RF signal to the BD, which then loads its own information onto the incident
signal and backscatters the modulated signal to the reader. Since the CE and
BR are co-located, the modulated signal suffers from round-trip path loss.
Consequently, a monostatic BackCom system is limited only to short-range
applications.

Bistatic BackCom Systems: Unlike monostatic BackCom system, the CE and BR are
spatially separated in the bistatic configuration, thus improving the
flexibility of the system by allowing the optimal placement of CE. In
addition, the bistatic BackCom system improves the performance in a cost-
effective manner due to a less complex design than the monostatic counterpart.
However, for long-range applications, the bistatic configuration requires the
dedicated RF source to be in close vicinity of BDs in an interference-limited
region.

Ambient BackCom Systems: Similar to bistatic configuration, the CE is also
separated from the BR in an ambient BackCom system. However, instead of a
dedicated RF source, it exploits the ambient RF sources, such as TV/cellular
towers, Bluetooth, or WiFi access points, which reduces the cost and power
consumption of a dedicated CE. Moreover, the ambient configuration improves
the spectrum resource utilization since it utilizes the existing RF signals.
However, in an ambient configuration, the reader suffers from direct-link
interference from the ambient signals, which adversely affects the detection
performance and consequently limits the transmission range.

Despite the extensive research, there exist a fundamental limitation in signal
coverage and data rate of BackCom systems, hindering the large-scale
deployment. Therefore, alternative methods needs to be developed, which can
support the ubiquitous connectivity among a massive number of devices, while
adapting to the dynamic nature of the wireless channels. This makes it
necessary to control and manipulate the electromagnetic waves to steer the
signals in the desired directions, thus paving a way towards the smart and
reconfigurable propagation environments. Hence, in this regard, reconfigurable
intelligent surfaces (RISs), also known as intelligent reflecting surfaces
(IRSs), have come to the forefront to improve the propagation conditions by
passive signal reflections [6, 7].

Specifically, an RIS is a planar array of numerous low-cost passive reflecting
elements, each capable of inducing a phase-shift in the impinging signal.
Through intelligent phase-shifts, the RIS reflected signal can be combined
with direct link signals, either constructively to boost the received signal
strength or destructively to attenuate the co-channel interference, hence
improving overall system performance. These properties make RIS an ideal
candidate to assist the BackCom systems to improve the network coverage,
lifetime, and capacity. Thus, as a change on the network infrastructure level,
the application of RISs into BackCom systems opens an entirely new realm for
IoT.

Inspired by the benefits that RIS can bring to BackCom systems, this article
is a first effort to give a forward-looking vision of the role that RISs can
play in enabling smart BackCom systems. The key contributions of this article
are summarized as follows.

  * •

To develop an understanding of RIS in BackCom, we provide a background of the
fundamental principle, hardware architecture, and major advantages of RIS
technology.

  * •

To realize the smart BackCom, we introduce four different variants of RIS-
assisted BackCom (RIS-BackCom), namely, RIS-assisted monostatic, bistatic,
ambient, and phase-shift BackCom systems.

  * •

We unleash the five potential improvements that can be achieved by integrating
RISs into BackCom systems.

  * •

Owing to the unrivaled effectiveness of non-orthogonal multiple access (NOMA),
a novel case study is presented which unveils RIS-assisted NOMA-enhanced
BackCom system as a potential candidate for 6G IoT networks.

  * •

We identify some critical challenges and research opportunities to provide the
way forward for realizing RIS-BackCom systems.

##  II RIS Technology: An Overview

In this section, to shed light on the basics of RIS, we provide an overview of
the RIS fundamental principle, hardware architecture, and major advantages.

###  II-A Fundamental Principle

RIS implementation is based on the concept of synthetically produced two-
dimensional form of electromagnetic metamaterials, known as the metasurface,
which is composed of a massive number of reflecting elements, called meta-
atoms [6]. The electromagnetic behavior of the metasurface is controlled by
the geometrical properties, i.e, size, orientation, arrangement, etc., of the
meta-atoms. However, owing to the stochastic nature of propagation channels,
the wireless communication applications demand real time response of meta-
atoms, which can be realized through electronic devices, functional materials,
or mechanical actuation.

###  II-B Hardware Architecture

The hardware architecture of RIS comprises of two parts: the multi-layer
planner surface and a smart controller [6]. In a typical three-layered
architecture, as shown in Fig. 1, the outer layer consists of a large number
of elements printed on a dielectric substrate to directly interact with the
incident signals. The middle layer is a copper panel, which avoids any signal
leakage. The inner layer is a control circuit board, responsible for adjusting
the reflection amplitudes and/or phase-shifts of each RIS element. The
reconfiguration of RIS elements is managed by the smart controller, such as a
field-programmable gate array (FPGA), which also acts as a gateway to
communicate with the base station (BS) and/or other network components.

The structure of an individual element, embedded with a positive-intrinsic-
negative (PIN) diode, is also shown in Fig. 1. By controlling the voltage via
biasing line, the PIN diode can be switched between on and off states to
realize the phase-shift of $\pi$ in radians. Moreover, the RIS elements can
also be equipped with low-cost dedicated sensors to enable sensing
capabilities beneficial for wireless channel estimation.

###  II-C Major Advantages

The RIS technology is not only conceptually appealing, but also offers several
advantages for practical implementation. The RIS elements passively reflect
the impinging signal, eliminating the requirement of RF chains and
sophisticated signal processing. Hence, RIS can be implemented at a much low
hardware cost and power consumption than active antenna counterparts.
Moreover, different from conventional relays, RIS operates in a full-duplex
mode (FD), free form self-interference and thermal noise. Architecturally, RIS
is lightweight with conformal geometry and can be easily mounted on the
ceilings, walls, and building facades. Additionally, the RIS-enhanced networks
are compatible with the emerging communication technologies, such as non-
orthogonal multiple access (NOMA), millimeter wave (mmWave) communication,
unmanned aerial vehicles (UAVs), and BackCom [7]. These advantages make RIS a
cutting-edge technology for realizing 6G wireless networks [4].

##  III Variants of RIS-BackCom

RIS can be incorporated in BackCom systems to realize the future green and
ubiquitous communication for IoT applications. To this end, in this section,
we discuss the four different variants of RIS-BackCom, as shown in Fig. 2.

###  III-A RIS-assisted Monostatic BackCom System

The communication in an RIS-assisted monostatic BackCom system can be split
into two phases, the excitation phase and the backscattering phase. In the
excitation phase, the reader sends the continuous-wave signal to the BD
directly and via smart reflection from RIS. In the backscattering phase, the
BD modulates the signal and then backscatters it towards the reader via both
the direct and RIS reflected links. The intelligent phase-shifts induced at
the RIS result in the improvement of the received signal-to-noise ratio (SNR),
which can be mapped to extend the transmission ranges of BDs.

Figure 1: Hardware architecture of RIS. Figure 2: Variants of RIS-BackCom
Figure 3: An illustration of RIS-assisted NOMA-enhanced bistatic BackCom
system.

###  III-B RIS-assisted Bistatic BackCom System

Similar to RIS-assisted monostatic BackCom system, in the bistatic
configuration, the ability of RIS to reconfigure the wireless medium can be
utilized to enhance the performance of both the forward (i.e., excitation) and
backward (i,e., backscattering) links. The direct and RIS reflected signals
are added coherently at both the BD and BR, resulting in favorable SNR
scaling, which can be translated to reduce the transmit power requirement,
extend the transmission ranges, and enhance the device lifetimes. Moreover,
the application of RIS to a bistatic BackCom system allows the flexible
placement and deployment of BDs, providing an additional degree of freedom.

###  III-C RIS-assisted Ambient BackCom System

In an RIS-assisted ambient BackCom system, the BD conveys information on the
top of an already modulated ambient signal, received directly from the ambient
source and via reflection from RIS. In the ambient configuration, the ability
of RIS to focus the signals in the desired direction can be utilized to
mitigate the direct-link interference from the ambient signals, which can
improve the detection performance at low complexity. Moreover, similar to RIS-
assisted monostatic and bistatic configurations, incorporating RIS in an
ambient BackCom system can enhance the coverage range, data rate, and energy
harvesting capability of BDs at reduced transmit power requirements.

###  III-D RIS-assisted Phase-shift BackCom System

In an RIS-assisted phase-shift BackCom system, the RIS substitutes the
conventional BDs to relay the primary message signal and convey the secondary
information, modulated over the CW signal, to the cooperative receiver [8]. In
this configuration, RIS introduces an additional phase-shift for the secondary
information while reflecting the primary message signal and unmodulated
carrier. The cooperative receiver, with a sharp band-pass filter, receives
both the secondary and primary signals and decodes them sequentially. Hence,
with effective power splitting among the primary message signal and
unmodulated carrier, the RIS-assisted phase-shift BackCom system can yield
better spectrum efficiency than a conventional BackCom system.

##  IV RIS-BackCom: Potential Improvements

In this section, we elaborate on the potential improvements that can be
achieved by integrating RIS in BackCom systems.

###  IV-A Reconfigured Channel Conditions

In conventional BackCom systems, both the continuous-wave, or ambient RF
signal, and the backscattered signal undergo various propagation phenomena,
such as reflection, diffraction, and scattering, which result in multiple
copies of the signals. These copies usually arrive out-of-phase at the BD, in
the excitation phase, and the BR, in the backscattering phase, which produce
significant distortions in the received signals, thus limiting the performance
of BackCom systems. However, the limitations of conventional BackCom systems
can be compensated via RIS. Through smart reflections, RIS can mitigate the
negative effects of electromagnetic radiations, thereby improving the system
performance.

RIS can establish virtual line-of-sight (LoS) links to improve the overall
channel gains. For instance, in a dense environment, such as an industrial IoT
network, RIS deployed at the optimal location can bypass the environmental
obstacles to establish communications. Such an application scenario is more
evident in high-frequency bands, i.e., millimeter waves (mmWaves) and
Terahertz (THz), which are vulnerable to signal blockage and attenuation. In
this regard, the authors in [9] analyzed the reliability performance of an
RIS-assisted monostatic BackCom system, where the direct link between the tag
and the reader is assumed to be blocked. The RIS-BackCom can achieve high
reliability than a relay-assisted BackCom at a moderate SNR with a massive
number of reflective elements.

###  IV-B Enhanced Transmission Range

Despite the research achievements, the conventional BackCom systems offer
inherently limited range, in the order of a few meters, which is a major
hurdle preventing their large-scale deployment. Specifically, monostatic
systems suffer from round trip path loss; bistatic systems require the CE to
be placed very close to BDs; and ambient systems experience direct-link
interference, thus restricting the BackCom to short-range low date rate
applications only. The conventional solutions to overcome the short coverage
impairments include relay-aided and multi-antenna backscattering. However,
such techniques incur high infrastructure cost, complexity, and power
consumption. Fortunately, RIS-BackCom system can boost the range and coverage
of BDs in an energy-efficient and cost-effective manner.

RIS can be installed at the edge of receiver’s coverage zone to enhance the
transmission range and cover the BDs located in the dead zones, i.e., regions
with no signal reception. As a result, BDs connectivity and coverage can be
enhanced with the aid of RIS. For the coverage enhancement of ambient BackCom
systems, the authors in [10] proposed a novel RIS-assisted ambient BackCom
technique over ambient orthogonal-frequency-division-multiplexing (OFDM)
subcarriers. The proposed technique benefits from multipath gains reflected
from the RIS elements in terms of enhanced received signal power and
consequently coverage.

###  IV-C Improved Energy Efficiency

The most attractive aspect of RIS technology, from an energy consumption
standpoint, is the ability to amplify and forward the impinging signal without
employing any power-hungry source, but rather by appropriately designing the
RIS phase-shifts to constructively combine the reflected signals. Hence, a
BackCom system can benefit from the power gains realized through RIS passive
reflections to achieve higher performance gains with less transmit power,
which can significantly improve the energy efficiency of RIS-BackCom systems.

As an exploratory work towards an energy-efficient design for future BackCom
systems, the authors in [11] proposed a novel setup for a bistatic BackCom
system, where an RIS is deployed close to the CE to assist the communication
between the BD and the reader. The joint optimization of RIS phase-shifts and
transmit beamforming vector at the CE can significantly reduce the transmit
power consumption, while guaranteeing a required BackCom performance. The
simulation results reveal the transmit power reduction of $3.5$ dB by
deploying an RIS with $49$ reflecting elements. Moreover, further reduction in
transmit power can be achieved by increasing the reflecting elements. In
addition, the authors extended the proposed design for transmit power
minimization to a multi-device scenario in [12], resulting in a similar
reduction in transmit power, which can be translated to improve the link
budget and transmission ranges. However, currently, there is a paucity of
research contributions to investigate the trade-offs between the transmit
power consumption and throughput of RIS-BackCom systems for maximizing the
energy efficiency, which is worth exploring in future.

###  IV-D Better Detection Performance

Amongst the three contemporary BackCom configurations, ambient BackCom is the
most energy-efficient and cost-effective solution for the pervasive networking
of massively deployed low-power IoT devices. Nonetheless, the robustness of
ambient BackCom systems is a prominent challenge that needs to be addressed.
Specifically, in ambient BackCom systems, the backscattered signal experiences
direct-link interference from the ambient signals, thus rendering poor
detection performance at the reader. Although the conventional methods, such
as channel estimation and modification of BDs, can improve the detection
performance, however, at the cost of high implementation complexity.

To tackle the aforementioned limitation, the ability of RIS to steer the
signals in different directions can be exploited to suppress the direct-link
interference, thus improving the detection performance at reduced complexity.
In this regard, the authors in [13] proposed deep reinforcement learning (DRL)
based approach, namely the deep deterministic policy gradient (DDPG)
algorithm, to optimize the performance of an RIS-assisted ambient BackCom
system in the absence of channel state information (CSI). The simulated
results demonstrate the better detection performance of the proposed design
over the conventional non-RIS based designs with full CSI knowledge.

###  IV-E High Energy Harvesting

Energy harvesting is an attractive technique towards the battery-free
operation of IoT networks. However, currently, the typical energy conversion
efficiency in BackCom is usually less than $20$%. Such a poor energy
harvesting performance can severely affect the self-sustainable operation of
future IoT networks. To address this challenge, RIS can be applied to BackCom
systems to improve the total received power by a coherent combination of
reflected signals. Thus, enabling the BDs to harvest energy from both the
direct and RIS reflected signals, consequently, improving the total harvested
energy to sustain the long-term operation of IoT networks.

Despite the exploratory works [9, 10, 11, 12, 13], the performance of RIS-
BackCom systems in the context of energy harvesting has not been analyzed yet.
Therefore, it is necessary to design efficient frame-based transmission
protocols for RIS-BackCom systems to avoid destructive wireless interference
among the energy harvesting and data transmission phases of the system.
Moreover, to fully reap the RIS passive beamforming gain for energy
harvesting, the transmit beamforming at the source needs to be jointly
designed with the RIS phase-shifts.

Figure 4: Success probability versus the SINR threshold for different values
of reflection coefficients, and CE transmit power of $35$ dBm.

##  V RIS-Assisted NOMA-Enhanced BackCom System: A Case Study

To support massive connectivity of an increasing number of IoT devices, non-
orthogonal multiple access (NOMA) is a promising multiple access candidate due
to its capability of exploiting available resources efficiently. In NOMA-
enhanced BackCom systems, multiple devices are multiplexed over the same
orthogonal resource (e.g., time, frequency, code) block but with different
backscattered power levels. With this, NOMA promotes high spectral efficiency,
massive connectivity, lower latency, and better user fairness over orthogonal
multiple access (OMA) techniques [3]. For the emerging 6G IoT networks, the
performance of NOMA-enhanced BackCom systems can be improved by incorporating
RIS. Therefore, in this section, we the integration of RIS into a NOMA-
enhanced bistatic BackCom system.

###  V-A System Model

As illustrated in Fig. 3, we consider an RIS-assisted NOMA enhanced bistatic
BackCom system, which consists of a CE, $K$ BDs, a reader, and an RIS, where
$N$ reflecting elements only adjusts the phases of the incident signals. The
RIS is deployed to enhance the channel gains over both the excitation and
backscattering phases of the bistatic BackCom system, where the CE transmits
the CW signal to the BDs, while each BD modulates its information over the
incident CW signal and backscatters it to the reader. We assume that each of
the CE, BR, and BDs are equipped with a single antenna.

Figure 5: Throughput for coherent and random phase-shift designs of RIS with
varying number of RIS elements, CE transmit, and SINR threshold of $15$ dB.

####  V-A1 BackCom Model

We assume that the CE transmits the CW signal almost all the time, while each
BD has two states: (i) sleep state, where the BDs harvest energy from the
incident CW signals and store the harvested energy in the battery to power the
circuitry and perform sensing operations; (ii) active state, where the BDs
backscatter the modulated signal to the BR by intelligently changing their
load impedance. To modulate the signal, we adopt the binary phase shift keying
(BPSK) modulation. Therefore, each impedance set can generate two reflection
coefficients with the same magnitude, denoted as $\Gamma_{i}$, but different
phase-shifts, i.e., $0\degree$ and $180\degree$. We consider $2$-BD NOMA
multiplexing, therefore, each BD is equipped with two impedance sets, with the
reflection coefficients $\Gamma_{1}$ and $\Gamma_{2}$, where $\Gamma_{1}$ $>$
$\Gamma_{2}$ [14].

####  V-A2 Frame-Based Transmission Protocol

As illustrated in Fig. 3, we propose a frame-based transmission protocol that
integrates $2$-BD NOMA multiplexing and time-division-multiple-access (TDMA)
with $K$ training slots, for the _training phase_ , and $M$ transmission
slots, for the _transmission phase_. In each training slot, only one BD
backscatters the CW signal with the same reflection coefficient, with all
other BDs in the sleep state, and the BR estimates the BD’s cascaded channel,
i.e., which is the sum of the direct and the RIS reflected channel. Then,
based on the BR’s received power levels, the BDs are sorted decreasingly and
categorized sequentially into two power groups, namely the higher-power BDs
and the lower-power BDs. Each higher-power BD is randomly grouped with a
lower-power BD to form a cluster. In each transmission slot, only one cluster
performs the NOMA transmission, with higher- and lower-power BDs switch to
reflection coefficient $\Gamma_{1}$ and $\Gamma_{2}$, respectively, while the
rest of the clusters remain in the sleep state.

###  V-B Performance Evaluation

In this subsection, we demonstrate the performance gains achieved by
integrating RIS in NOMA-enhanced bistatic BackCom system. We assume that the
RIS reflected channels, i.e., channels between the RIS and the CE, BDs and BR,
undergo Rician fading, with Rician factor $3$ dB and path loss exponent $2.4$;
while all other channels experience Rayleigh fading with path loss exponent
$3$. All wireless channels are assumed to be mutually independent and
perfectly estimated by the BR. As in [11], the CE, BR, and RIS are located at
$[0,0]$, $[100,0]$, and $[20,0]$ m, respectively, and the BDs are located
between $[5,0]$ and $[95,0]$ m. The noise power at the BR is considered to be
$-90$ dBm. The simulation results for a single cluster case are presented as
follows.

####  V-B1 Performance Improvement and the Effect of Reflection Coefficients

In Fig. 4, we evaluate the performance of the proposed RIS-assisted system,
i.e., RIS-NOMA-BackCom, against the success probability, defined as the
probability by which the received signal-to-interference plus noise ratio
(SINR) is greater than the specified threshold, $\tau$, required for
successful decoding of each BD’s signal. It can be observed that for any
combination of the reflection coefficients, the RIS-assisted system
outperforms the no-RIS counterpart, i.e., NOMA-BackCom. Moreover, better
performance can be achieved by reducing the value of $\Gamma_{2}$. This is
because the smaller value of $\Gamma_{2}$ reduces the interference from the
weaker signal, thus increasing the chances of the stronger signal to be
decoded successfully. However, the best performance can be achieved by setting
the optimal values for $\Gamma_{1}$ and $\Gamma_{2}$.

####  V-B2 Effect of the RIS Elements and Phase-shift Designs

The performance of RIS-assisted system highly depends on the RIS phase-shift
design and the number of RIS elements. In this regard, Fig. 5 compares the
cluster throughput for the coherent and random phase-shift designs. First, it
can be observed that for a given number of RIS elements and CE transmit power,
the coherent phase-shift design, for which the RIS phase-shifts are matched
with the phases of the fading channels [15], outperforms the random phase-
shift design. Second, the throughput scales up with the increase in the RIS
elements. For instance, for $30$ dBm CE power and coherent phase-shift design,
throughput is $11$ bps/Hz for $40$ RIS elements, while this value increases to
about $15$ bps/Hz for $60$ RIS elements. From here, we can conclude that RIS
passive reflection adds power gain, which can be either utilized to improve
the BackCom system throughput or reduce the CE power consumption.

####  V-B3 Energy Harvesting Performance

To evaluate the energy harvesting performance, Fig. 6 highlights the impact of
the increasing number of RIS elements on the harvested energy in the sleep
state. It can be observed that for given energy conversion efficiency, the
harvested energy increases with the increase in RIS elements. For instance,
for $20$% energy conversion efficiency, the harvested energy increases by
$0.15$ mJ when RIS elements increase from $50$ to $100$. Therefore, in
practical BackCom systems with low energy conversion efficiency, greater
energy can be harvested by deploying RIS with massive number of elements.

The aforementioned results clearly depict the significance of incorporating
RIS into NOMA-enhanced BackCom systems, thus unveiling it as a potential
candidate to support the demands for 6G IoT networks.

Figure 6: Harvested energy for varying number of RIS elements and energy
conversion efficiency with CE transmit power of $30$ dBm.

##  VI Challenges and Research Opportunities

Despite so many promising aspects, as a new-born thing, RIS-BackCom also
raises up some challenges and research opportunities which are discussed as
follows.

###  VI-A Channel Estimation for RIS-BackCom Systems

The enormous passive beamforming gains brought by RIS highly depend on the
availability of CSI, which is quite challenging to acquire since passive RIS
elements and backscatter devices lack signal processing capabilities. Thus,
only the composite channel, which is the product of the forward and backward
channels, can be estimated at the backscatter receiver. This makes the channel
estimation schemes available for conventional RIS-assisted systems
inapplicable. Therefore, novel schemes need to be developed for channel
estimation of RIS-BackCom systems, while accounting for the practical
constraints.

###  VI-B Optimal Configuration and Resource Allocation

The RIS configuration highly impact the overall performance of RIS-BackCom
systems. The optimal configuration of RIS phase-shifts for both the excitation
and backscattering phases renders high computational complexity and latency.
Therefore, efficient algorithms are required to control the phase-shifts in a
timely manner, according to the dynamics of the propagation environment. In
addition, low-complexity resource allocation algorithms need to be developed
for RIS-BackCom systems.

###  VI-C Machine Learning-empowered RIS-BackCom

Owing to the limited CSI and non-convex nature of optimization variables,
machine learning (ML) techniques are quite appealing for RIS-BackCom systems,
due to their learning capability and large search space. Compared to
conventional optimization and signal processing techniques, ML can achieve a
high degree in all respects of RIS-BackCom, including environmental sensing,
channel estimation, phase-shift design, and resource allocation. This, thus
calls for efficient ML-based algorithms to fully reap the potentials of RIS-
BackCom systems.

###  VI-D mmWave-based RIS-BackCom

With the capability to exploit the under-utilized immense bandwidth at high-
frequency spectrum, mmWave has been deemed as a serious candidate to host the
high data rate communications. Nevertheless, the vulnerability of mmWaves to
signal blockages renders it insufficient on its own to meet the growing
demands of wireless communication. Fortunately, RIS has the capability to
mitigate the limitations of mmWave systems by introducing effective additional
paths. In this context, mmWave-based RIS-BackCom is worth investing in for
realizing future IoT networks.

###  VI-E Integrating Multiple RISs into BackCom Systems

In future large-scale networks, multiple RISs are anticipated to be deployed
in the BackCom systems to provide ultra-high performance, since multiple RISs
open up a door for harvesting larger beamforming gains. However, the
deployment of multiple RISs incurs high design and implementation complexity.
Therefore, the cumulative impact of the operation of multiple RISs is worth
investigating, by considering their spatial distribution.

##  VII Conclusion

In this article, we explored the integration of RISs into BackCom systems for
enabling 6G IoT networks. Specifically, we first outlined the fundamentals of
RIS technology to develop an understanding of RIS in BackCom. We introduced
four different variants of RIS-BackCom and identified the potential
improvement that can be achieved by incorporating RISs into BackCom systems.
In addition, a case study for an RIS-assisted NOMA-enhanced BackCom system is
presented. Our numerical results clearly demonstrated the performance gains
brought by RIS in terms of success probability, throughput, transmit power
consumption, and harvested energy. Finally, to provide useful guidance for
future research, we indicated the crucial challenges and promising research
directions for realizing RIS-BackCom systems.

## References

  * [1] F. Tariq _et al._ , “A speculative study on 6G,” _IEEE Wireless Commun._ , vol. 27, no. 4, pp. 118–125, 2020.
  * [2] CISCO, “Internet of things at a glance.” [Online]. Available: https://www.cisco.com/c/dam/enlus/products/collateral/se/internet-of-things/at-a-glance-c45-731471.pdf.
  * [3] F. Jameel _et al._ , “NOMA-enabled backscatter communications: Toward battery-free IoT networks,” _IEEE Internet Things Mag._ , vol. 3, no. 4, pp. 95–101, 2020.
  * [4] S. Basharat _et al._ , “Reconfigurable intelligent surfaces: Potentials, applications, and challenges for 6G wireless networks,” _arXiv preprint arXiv:2107.05460_ , 2021.
  * [5] X. Lu _et al._ , “Ambient backscatter assisted wireless powered communications,” _IEEE Wireless Commun._ , vol. 25, no. 2, pp. 170–177, 2018\.
  * [6] Q. Wu _et al._ , “Towards smart and reconfigurable environment: Intelligent reflecting surface aided wireless network,” _IEEE Commun. Mag._ , vol. 58, no. 1, pp. 106–112, 2020.
  * [7] M. Di Renzo _et al._ , “Smart radio environments empowered by reconfigurable intelligent surfaces: How it works, state of research, and the road ahead,” _IEEE J. Sel. Areas Commun._ , vol. 38, no. 11, pp. 2450–2525, 2020.
  * [8] S. Y. Park _et al._ , “Intelligent reflecting surface-aided phase-shift backscatter communication,” in _International Conference on Ubiquitous Information Management and Communication (IMCOM)_ , 2020, pp. 1–5.
  * [9] W. Zhao _et al._ , “Performance analysis of large intelligent surface aided backscatter communication systems,” _IEEE Wireless Commun. Lett._ , vol. 9, no. 7, pp. 962–966, 2020.
  * [10] M. Nemati _et al._ , “Short-range ambient backscatter communication using reconfigurable intelligent surfaces,” in _IEEE WCNC_ , 2020, pp. 1–6.
  * [11] X. Jia _et al._ , “Intelligent reflecting surface-aided backscatter communications,” _arXiv preprint arXiv:2004.09059_ , 2020.
  * [12] ——, “Intelligent reflecting surface-assisted bistatic backscatter networks: Joint beamforming and reflection design,” _arXiv preprint arXiv:2010.08947_ , 2020.
  * [13] ——, “IRS-assisted ambient backscatter communications utilizing deep reinforcement learning,” _arXiv preprint arXiv:2103.07083_ , 2021.
  * [14] A. W. Nazar _et al._ , “BER analysis of a backscatter communication system with non-orthogonal multiple access,” _IEEE Trans. Green Commun. Netw._ , vol. 5, no. 2, pp. 574–586, 2021.
  * [15] Z. Ding _et al._ , “On the impact of phase shifting designs on IRS-NOMA,” _IEEE Wireless Commun. Lett._ , vol. 9, no. 10, pp. 1596–1600, 2020.

Sarah Basharat<EMAIL_ADDRESS>received her B.E. and M.S.
degrees in electrical engineering from National University of Sciences and
Technology (NUST), Pakistan, in 2019 and 2021, respectively. Her research
interests include B5G and 6G communication, non-orthogonal multiple access
(NOMA), backscatter communication (BackCom), and reconfigurable intelligent
surfaces (RISs).
---
Syed Ali Hassan [S’08, M’11, SM’17]<EMAIL_ADDRESS>received his
Ph.D. in electrical engineering from Georgia Tech, Atlanta, in 2011, his M.S.
in mathematics from Georgia Tech in 2011, and his M.S. in electrical
engineering from the University of Stuttgart, Germany, in 2007, and a B.E. in
electrical engineering (highest honors) from the National University of
Sciences and Technology (NUST), Pakistan, in 2004. Currently, he is working as
an associate professor at NUST, where he is heading the IPT research group,
which focuses on various aspects of theoretical communications.
---
Aamir Mahmood [M’18, SM’19]<EMAIL_ADDRESS>is an assistant professor
of communication engineering at Mid Sweden University, Sweden. He received the
M.Sc. and D.Sc. degrees in communications engineering from Aalto University
School of Electrical Engineering, Finland, in 2008 and 2014, respectively. He
was a research intern at Nokia Researcher Center, Finland and a visiting
researcher at Aalto University during 2014-2016. His research interests
include network time synchronization, resource allocation for URLLC, and RF
interference/coexistence management.
---
Zhiguo Ding [S’03, M’05, SM’17, F’20]<EMAIL_ADDRESS>is
currently a Professor at the University of Manchester. Dr Ding research
interests are 5G networks, signal processing and statistical signal
processing. He has been serving as an Editor for IEEE TCOM, IEEE TVT, and
served as an editor for IEEE WCL and IEEE CL. He received the EU Marie Curie
Fellowship 2012-2014, IEEE TVT Top Editor 2017, 2018 IEEE COMSOC Heinrich
Hertz Award, 2018 IEEE VTS Jack Neubauer Memorial Award, and 2018 IEEE SPS
Best Signal Processing Letter Award.
---
Mikael Gidlund [M’98, SM’16]<EMAIL_ADDRESS>is a professor of
computer engineering at Mid Sweden University, Sweden. He has worked as Senior
Principal Scientist and Global Research Area Coordinator of Wireless
Technologies, ABB Corporate Research, Sweden, Project Manager and Senior
Specialist with Nera Networks AS, Norway, and Research Engineer and Project
Manager with Acreo AB, Sweden. His current research interests include wireless
communication and networks, wireless sensor networks, access protocols, and
security.
---