\section{Introduction}
\label{sec:introduction}
\IEEEPARstart{T}{his} document is a template for \LaTeX. If, after reading these
instructions, you still have questions or require assistance, please contact
\underline {tns-editor@ieee.org}. If you are
reading a paper or PDF version of this document, please download the
electronic file, trans\_jour.tex, from the IEEE Web site at \underline
{http://www.ieee.org/authortools/trans\_jour.tex} so you can use it
to prepare your manuscript. You can also explore using the Overleaf editor at
\underline{https://www.overleaf.com/blog/278-how-to-use-overleaf-with-}\discretionary{}{}{}\underline
{ieee-collabratec-your-quick-guide-to-getting-started\#.}\discretionary{}{}{}\underline{xsVp6tpPkrKM9}
Your submitted paper should be
in this 2-column format with figures and tables embedded in the text.

The general IEEE policy requires that authors should only submit original
work that has neither appeared elsewhere for publication, nor is under
review for another refereed publication. The submitting author must disclose
to the editor if any part of the manuscript has been previously published or
submitted for publication elsewhere when submitting a manuscript. Do not
submit ``preliminary'' data or results.

The submitting author is responsible for obtaining agreement of all
coauthors and any consent required from employers or sponsors before
submitting an article. The submitting author is also responsible for
obtaining permission from the copyright holder to republish copyrighted
material. Transactions on Nuclear Science (TNS) strongly discourages
courtesy authorship. It is the obligation of the authors to cite relevant
prior work and only relevant prior work.

TNS does not publish conference records or proceedings, but can publish
articles related to conferences after they have undergone rigorous peer
review. Articles that have already appeared in an unreferred conference
proceeding (or other medium) and that include a substantial amount
($>50\%$) of new information may be acceptable.

All papers submitted to TNS undergo peer review and an automated plagiarism
check. Papers failing the plagiarism check will be rejected without further
review. Every published article receives a minimum of two independent
reviews.

Articles for peer-review can be submitted at any time, and are generally 8
pages in length, including figures, tables, equations, and references. TNS
also publishes tutorial expositions and critical reviews, however, we ask
that authors contact the editor in chief prior to submitting such a work.

Authors should consider the following points:

\begin{enumerate}
\item Technical papers submitted for publication must advance the state of knowledge and must cite relevant prior work. An obvious or minor extension of previously published work might not be appropriate for publication.
\item Authors must convince both peer reviewers and the editors of the scientific and technical merit of a paper; the standards of proof are higher when extraordinary or unexpected results are reported.
\item Because replication is required for scientific progress, papers submitted for publication must provide sufficient information to allow readers to perform similar experiments or calculations and use the reported results. Although not everything need be disclosed, a paper must contain new, useable, and fully described information. For example, a specimen's chemical composition need not be reported if the main purpose of a paper is to introduce a new measurement technique. However, if that composition is critical to the technique, then it should be disclosed. Authors should expect to be challenged by reviewers if the results are not supported by adequate data and critical details.
\item Papers that describe ongoing work or announce the latest technical achievement, which are suitable for presentation at a professional conference, generally are not appropriate for TNS.
\end{enumerate}

Additional information on the requirements for the technical content of
manuscripts of manuscripts submitted to TNS and on its review process,
including scope, content, and items for authors to address in their articles
are available at \underline
{https://}\discretionary{}{}{}\underline{ieee-npss.org/publications/transactions-on-nuclear-science/}.

\section{Structure of your paper}
Your paper will consist of at least four sections: an Introduction, a
description of the measurement, theory, computation, equipment, etc., a
discussion of the data and analysis, and a set of conclusions drawn from the
data and analysis. Feel free to add additional sections as necessary.

The Introduction motivates the work. Explain here why it is important, what
deficiencies in the state of the art you aim to overcome, how/why the work
extends the state of the art. Describe the problem you are trying to solve.
Include a review of relevant literature in this section.

In the Experimental section, you describe your equipment, technique,
materials, protocols, and whatever else is necessary so that another person
working in your field can understand what you did and reproduce the work.

Discuss the data you acquired and how you analyzed them. Include a
statistical analysis to demonstrate the limits of the data analysis.
Experimental data have uncertainties, although the error bars may be smaller
than the symbols used to represent them. Your discussion should include
something about the experimental uncertainties. Even simulations have (or
can have) uncertainties associated with them. TNS expects to see a
discussion of uncertainties in all papers.

A Conclusions (note the plural) section is required. Although this section
may review the main points of the paper, do not replicate the abstract here.
A Conclusions section draws inferences from the data and elaborates on the
importance of the work. You may suggest applications and extensions. You
should explain here how the data and analysis support the introduction to
your paper where you motivated and justified the work. Explain how the work
extends the state of the art. Answer the question ``So what?''

\subsection{Abbreviations and Acronyms}
Define abbreviations and acronyms the first time they are used in the text,
even after they have already been defined in the abstract. Common
abbreviations such as IEEE, SI, ac, and dc do not have to be defined.
Abbreviations that incorporate periods should not have spaces: write
``C.N.R.S.,'' not ``C. N. R. S.'' Do not use abbreviations in the title
unless they are unavoidable (for example, ``IEEE'' in the title of this
article).

\subsection{Inclusion of copyrighted material}
Sometimes it is expedient to include a figure, table, equation, or text from
a previously published work. If you find it useful to do this, it is your
responsibility to obtain permission from the copyright holder (usually the
publisher of the work. You must indicate the items in your paper that have
been reproduced from prior work and include a reference to the source of the
material in the references. Captions of reproduced figures and tables should
include ``Reproduced from [nnn], with permission.'' or whatever the
copyright holder requires. Reproduced text should be offset from the body of
your paper, enclosed in quotation marks, and include the permission
statement as for figures and tables.

\subsection{Other Recommendations}
Use one space after periods and colons. Hyphenate complex modifiers:
``zero-field-cooled magnetization.'' Avoid dangling participles, such as,
``Using (\ref{eq1}), the potential was calculated.'' [It is not clear who or what
used (\ref{eq1}).] Write instead, ``The potential was calculated by using (\ref{eq1}),'' or
``Using (\ref{eq1}), we calculated the potential.''

Use a zero before decimal points: ``0.25,'' not ``.25.'' Indicate sample
dimensions as ``$0.1~\text{cm} \times 0.2~\text{cm}$,'' not ``$0.1
\times 0.2~\text{cm}^{2}$.'' The abbreviation for ``seconds'' is ``s,'' not ``sec.'' Do not
mix abbreviations and full names of units. Write m/s, not meters/s. When
expressing a range of values, write ``7 to 9'' or ``7--9,'' and not
``$7\sim9$'' or ``$7\div 9$.'' Note that periods (.) and commas
(,) are punctuated within the quotation marks.

A parenthetical statement at the end of a sentence is punctuated outside of
the closing parenthesis (like this). (A parenthetical sentence is punctuated
within the parentheses.) In US English, periods and commas are within
quotation marks, like ``this period.'' Other punctuation is ``outside''!
Avoid contractions; for example, write ``do not'' instead of ``don't.'' The
serial comma is preferred: ``A, B, and C'' instead of ``A, B and C.''

If you wish, you may write in the first person singular or plural and use
the active voice (``I observed that \textellipsis'' or ``We observed that \textellipsis''
instead of ``It was observed that \textellipsis''). Remember to check spelling. If
your native language is not English, please ask a native English-speaking
colleague, a teacher of English as a second language, or a professional
translation service to proofread your paper carefully. Papers may be
rejected without review if the English usage is unsatisfactory. TNS prefers
US spelling (color rather than colour).

Try not to use too many typefaces in the same article. You're writing
scholarly papers, not ransom notes. Also please remember that MathJax
can't handle really weird typefaces.

\subsection{Equations}
Number equations consecutively with equation numbers in parentheses flush
with the right margin, as in (\ref{eq1}). First use the equation editor to create
the equation. Then select the ``Equation'' markup style. Press the tab key
and write the equation number in parentheses. To make your equations more
compact, you may use the solidus (~/~), the exp function, or appropriate
exponents. Use parentheses to avoid ambiguities in denominators. Punctuate
equations when they are part of a sentence, as in
\begin{equation}
\label{eq1}
x=\frac{111111111}{12345679}=9 .
\end{equation}
Note that $x$ is math mode because it is a variable. Be sure that the symbols
in your equation have been defined before the equation appears or
immediately following. Symbols must be in math mode, but not units: $T$ referring to
temperature, but T as the unit tesla. Refer to ``(\ref{eq1}),'' not ``Eq. (\ref{eq1})'' or
``equation (\ref{eq1}),'' except at the beginning of a sentence: ``Equation (\ref{eq1}) is
{\textellipsis}~.''

\subsection{\LaTeX-Specific Advice}

Please use ``soft'' (e.g., \verb|\eqref{Eq}|) cross references instead
of ``hard'' references (e.g., \verb|(1)|). That will make it possible
to combine sections, add equations, or change the order of figures or
citations without having to go through the file line by line.

Please don't use the \verb|{eqnarray}| equation environment. Use
\verb|{align}| or \verb|{IEEEeqnarray}| instead. The \verb|{eqnarray}|
environment leaves unsightly spaces around relation symbols.

Please note that the \verb|{subequations}| environment in {\LaTeX}
will increment the main equation counter even when there are no
equation numbers displayed. If you forget that, you might write an
article in which the equation numbers skip from (17) to (20), causing
the copy editors to wonder if you've discovered a new method of
counting.

{\BibTeX} does not work by magic. It doesn't get the bibliographic
data from thin air but from .bib files. If you use {\BibTeX} to produce a
bibliography you must send either the .bbl file or the .bib files.
If you use \texttt{biblatex}, please send the .bib file. The .bbl file
generated by \texttt{biblatex} is not designed to be edited.

{\LaTeX} can't read your mind. If you assign the same label to a
subsubsection and a table, you might find that Table I has been cross
referenced as Table IV-B3.

{\LaTeX} does not have precognitive abilities. If you put a
\verb|\label| command before the command that updates the counter it's
supposed to be using, the label will pick up the last counter to be
cross referenced instead. In particular, a \verb|\label| command
should not go before the caption of a figure or a table.

Do not use \verb|\nonumber| or \verb|\notag| inside the \verb|{array}| environment. It
will not stop equation numbers inside \verb|{array}| (there won't be
any anyway) and it might stop a wanted equation number in the
surrounding equation.

\section{Units}
Use either SI (MKS) or CGS as primary units. (SI units are strongly
encouraged.) English units may be used as secondary units (in
parentheses). This applies to papers discussing data storage, also.
For example, write ``15 Gb/cm$^{2}$ (100 Gb/in$^{2})$.'' An exception
is when English units are used as identifiers in trade, such as
``$3\nicefrac{1}{2}$-in disk drive.'' Avoid combining SI and CGS units,
such as density in kg/cm$^{3}$ because this can lead to confusion when
equations do not balance dimensionally. If you must use mixed units,
clearly state the units for each quantity in an equation.

The SI unit for magnetic field strength $H$ is A/m. However, if you wish to use
units of T, either refer to magnetic flux density $B$ or magnetic field
strength symbolized as $\mu _{0}H$. Use the center dot to separate
compound units, e.g., ``$\text{A}\cdot \text{m}^{2}$.''

\section{Guidelines for Graphics Preparation}
Tables, graphs, charts, and images should be embedded in the text of your
paper rather than collected in pages after the text. They should be
mentioned on the same page or before the appearance of the object itself, as
\figurename~\ref{fig1} is mentioned here. If there is insufficient
room in a column for a figure, rather than compress it, the figure is
allowed to move to the next page and white space is left immediately below.
Alternatively, you can move text from below the figure to this space, if it
makes sense to do so. It is good practice to tell the reader what is in the
figure in the caption and you can include a sentence or two about the
significance of the figure in the caption. However, lengthy explanations
should be placed in the body of the paper.

\begin{figure}[t]
\centerline{\includegraphics[width=3.5in]{imgs/example/tns1.png}}
\centerline{\includegraphics[width=3.5in]{imgs/example/tns2.png}}
\caption{Differential (a) and integral probability of interaction as a function of
angle of incidence.}
\label{fig1}
\end{figure}

\subsection{Multipart figures}
Figures comprising more than one sub-figure are presented side-by-side, or
stacked. Add an alphabetic label enclosed in parentheses inside each
sub-figure: (a), (b), (c), {\textellipsis}~. Choose a color for the text so
that it is visible over the image. The text box containing the label should
have no fill or border; only the letter in parentheses should be visible.

The figure caption will identify each sub-figure it is describing with these
labels. Write ``(a) Differential probability of interaction.
(b) Integral probability of interaction, both as a function of angle of
incidence,'' or ``Differential (a) and integral (b) probability of
interaction as a function of angle of incidence.'' Refer to the sub-figure as
\figurename~\ref{fig1}a in the body of the text.

If you choose to place figures (multipart or not) side-by-side in a single
column you might find it convenient to insert them in a single row of a
tabular. You can then place the captions in next row or insert them in the
same cell as the figure to keep the captions aligned with the figures.

\subsection{Using Labels Within Figures}
When preparing your graphics, if you prefer them to match the text of
the article, IEEE suggests that you use Times New Roman. The example
uses Cambria. (This guideline was originally written for \emph{Word}.)

Figure axis labels are often a source of confusion. Use words rather than
symbols. As an example, write the quantity ``Angle,'' and the units in
parentheses. Do not label axes only with units. Thus ``Angle of incidence
($^{\circ}$)'' and not just ``$^{\circ}$,''in Fig. 1, above. Do not
label axes as a ratio of quantities and units. For example, write
``Temperature (K),'' not ``Temperature/K.''

Multipliers can be especially confusing. Write ``Distance (m)'' or
``Distance (km).'' Do not write ``Distance (m) $\times$ 1000'' because the
reader would not know whether the tick mark labels have already been
multiplied by 1000 or whether the reader needs to multiply them by 1000.
Similarly, do not put a multiplier at the end of an axis. Figure labels must
be legible; use at least 8- to 10-point type.

\subsection{Tables}
Tables are inserted as {\LaTeX} tables, not as images, and should also be mentioned
in advance of their appearance. Table~\ref{tab1} shows an
acceptable layout of a table having both supplementary information below the
table and an internal footnote. The explanation of the footnote appears
after the supplementary information.

\begin{table}
\caption{Units for Magnetic Properties}
\label{table}
\setlength{\tabcolsep}{3pt}
\begin{tabular}{|p{25pt}|p{75pt}|p{115pt}|}
\hline
Symbol&
Quantity&
Conversion from Gaussian and \par CGS EMU to SI $^{\mathrm{a}}$ \\
\hline
$\Phi $&
magnetic flux&
1 Mx $\to 10^{-8}$ Wb $= 10^{-8}$ V$\cdot $s \\
$B$&
magnetic flux density, \par magnetic induction&
1 G $\to 10^{-4}$ T $= 10^{-4}$ Wb/m$^{2}$ \\
$H$&
magnetic field strength&
1 Oe $\to 10^{3}/(4\pi )$ A/m \\
$m$&
magnetic moment&
1 erg/G $=$ 1 emu \par $\to 10^{-3}$ A$\cdot $m$^{2} = 10^{-3}$ J/T \\
$M$&
magnetization&
1 erg/(G$\cdot $cm$^{3}) =$ 1 emu/cm$^{3}$ \par $\to 10^{3}$ A/m \\
4$\pi M$&
magnetization&
1 G $\to 10^{3}/(4\pi )$ A/m \\
$\sigma $&
specific magnetization&
1 erg/(G$\cdot $g) $=$ 1 emu/g $\to $ 1 A$\cdot $m$^{2}$/kg \\
$j$&
magnetic dipole \par moment&
1 erg/G $=$ 1 emu \par $\to 4\pi \times 10^{-10}$ Wb$\cdot $m \\
$J$&
magnetic polarization&
1 erg/(G$\cdot $cm$^{3}) =$ 1 emu/cm$^{3}$ \par $\to 4\pi \times 10^{-4}$ T \\
$\chi , \kappa $&
susceptibility&
1 $\to 4\pi $ \\
$\chi_{\rho }$&
mass susceptibility&
1 cm$^{3}$/g $\to 4\pi \times 10^{-3}$ m$^{3}$/kg \\
$\mu $&
permeability&
1 $\to 4\pi \times 10^{-7}$ H/m \par $= 4\pi \times 10^{-7}$ Wb/(A$\cdot $m) \\
$\mu_{r}$&
relative permeability&
$\mu \to \mu_{r}$ \\
$w, W$&
energy density&
1 erg/cm$^{3} \to 10^{-1}$ J/m$^{3}$ \\
$N, D$&
demagnetizing factor&
1 $\to 1/(4\pi )$ \\
\hline
\multicolumn{3}{p{251pt}}{Vertical lines are optional in tables. Statements that serve as captions for
the entire table do not need footnote letters. }\\
\multicolumn{3}{p{251pt}}{$^{\mathrm{a}}$Gaussian units are the same as cg emu for magnetostatics; Mx
$=$ maxwell, G $=$ gauss, Oe $=$ oersted; Wb $=$ weber, V $=$ volt, s $=$
second, T $=$ tesla, m $=$ meter, A $=$ ampere, J $=$ joule, kg $=$
kilogram, H $=$ henry.}
\end{tabular}
\label{tab1}
\end{table}

\subsection{Referring to a Figure or Table Within Your Paper}
\label{subsec:referring}
When referring to your figures and tables within your paper, use the
abbreviation ``Fig.'' even at the beginning of a sentence. Do not abbreviate
``Table.''

It is best if tables do not span pages and columns, but sometimes that
cannot be helped. When a table must span a page, please repeat the column
headings on each page.

\subsection{Sizing of Graphics}
Most charts, graphs, and tables are one column wide (3.5 inches~/ 88
millimeters~/ 21 picas) or page wide (7.16 inches~/ 181 millimeters~/ 43
picas). The maximum height a graphic can be is 8.5 inches (216 millimeters~/
54 picas). When choosing the height of a graphic, please allow space for a
caption. Figures can be sized between column and page widths if the author
chooses, however it is recommended that figures are not sized less than
column width unless necessary.

\subsection{File Formats For Graphics}\label{formats}
Format and save your graphics using a suitable graphics processing program
that will allow you to create the images as PostScript (PS), Encapsulated
PostScript (.EPS), Tagged Image File Format (.TIFF), Portable Document
Format (.PDF), Portable Network Graphics (.PNG), or Metapost (.MPS), sizes them, and adjusts
the resolution settings. When
submitting your final paper, your graphics should all be submitted
individually in one of these formats along with the manuscript.

\section{Some Common Misteaks}
Always check your spelling. The word ``data'' is plural, not singular; the
singular is ``datum.'' Use the word ``micrometer'' instead of ``micron,'' or
write ``$\mu $m.'' A graph within a graph is an ``inset,'' not an
``insert.'' The word ``alternatively'' is preferred to the word
``alternately'' (unless you really mean something that alternates). Use the
word ``whereas'' instead of ``while'' (unless you are referring to
simultaneous events). Do not use the word ``essentially'' to mean
``approximately'' or ``effectively.'' Do not use the word ``issue'' as a
euphemism for ``problem.'' When compositions are not specified, separate
chemical symbols by en-dashes; for example, ``NiMn'' indicates the intermetallic
compound Ni$_{0.5}$Mn$_{0.5}$ whereas \text{``Ni--Mn''} indicates an alloy of some
composition Ni$_{x}$Mn$_{1-x}$.

Be aware of the different meanings of the similar words ``affect'' (usually
a verb) and ``effect'' (usually a noun), ``complement'' and ``compliment,''
``discreet'' and ``discrete,'' ``principal'' (e.g., ``principal
investigator'') and ``principle'' (e.g., ``principle of measurement''). Do
not confuse ``imply'' and ``infer.'' Data imply something; people infer
something from the data.

Prefixes such as ``non,'' ``sub,'' ``micro,'' ``multi,'' and ``ultra'' are
not independent words when used as modifiers; they should be joined to the
words they modify, usually, but not exclusively, without a hyphen:
nonuniform, subminiature, micrometer, multimeter, ultrasound. However, if
your paper needs to mention a submarine, TNS prefers you write out the word
rather than use the word ``sub.'' There is no period after the ``et'' in the
Latin abbreviation ``\textit{et al.}'' (it is the italicized abbreviation for \textit{et alia,} meaning
``and others''). The abbreviation ``i.e.'' abbreviates \textit{id est}, meaning ``that
is,'' and ``e.g.'' abbreviates the Latin \textit{exempli gratia}, meaning ``for example.'' These
last two abbreviations are \textit{not} italicized).

Please do not use math mode for italicized text.

\section{Conclusion}
The manuscript submitted to TNS for consideration for publication should be
formatted according to this document. Doing so will allow an efficient
review process and minimize the effort required by authors in preparing
their final files, if the manuscript is accepted for publication.

Key factors to consider include the following:

\begin{itemize}
\item The document must be in this two-column format.
\item Font sizes for text, section headings, etc. must conform to those in this template.
\item Proper English usage is necessary. Manuscripts which are vague or unclear because of poor grammar or wording may be rejected without review.
\item The nominal maximum page length for the submitted manuscript is 8 pages, unless prior arrangements are made with the editor to accept a longer submission.
\end{itemize}

\appendices

\section*{Appendix}

Appendixes, if needed, appear before the acknowledgment. They do not have
Roman numeral section numbers. Use
the \verb|\appendices| command for multiple appendices and
\verb|
\section{Introduction}
\label{sec:introduction}


\IEEEPARstart{B}{reakthroughs} in the precision and speed of sensing instrumentation are impactful on advances in scientific methodologies and theories.
Thus, a common paradigm across many scientific disciplines in physics has been
to increase the resolution of the sensing equipment in order to increase either the robustness or the sensitivity of the experiment itself.
This demand for increasingly higher sensitivity in experiments, along with advances in the design of state-of-the-art sensing systems, has resulted in rapidly growing big data pipelines such that transmission of acquired data to the processing unit via conventional methods is no longer feasible. Data transmission is commonly much less efficient than data processing. Therefore, placing data compression and processing as close as possible to data creation while maintaining physics performance is a crucial task in modern physics experiments.  




At the CERN Large Hadron Collider (LHC) and its high luminosity upgrade (HL-LHC), extreme collision rates present extreme challenges for data processing and transmission at multiple stages in detector readout and trigger systems. As the initial stage in the data chain, the on-detector (front-end) electronics that read out detector sensors must operate with low latency and low power dissipation in a high radiation environment, necessitating the use of application-specific integrated circuits (ASICs).
In order to mitigate the initial bottleneck of moving data from front-end ASICs to off-detector (back-end) systems based on field-programmable gate arrays (FPGAs), front-end ASICs must provide edge computing resources to efficiently use limited bandwidth through real-time processing and identification of interesting data. Front-end data compression algorithms have historically relied on zero-suppression, threshold-based selection, sorting or summing of data.

Artificial intelligence (AI), and more specifically machine learning (ML), has recently been demonstrated to be a powerful tool for data compression, processing, and analysis in physics~\cite{Albertsson:2018maf,Radovic:2018dip,Bourilkov:2019yoi,Carleo:2019ptp} and many other domains.
While progress has been made towards generic real-time processing through inference including boosted decision trees and neural networks (NNs) using FPGAs in off-detector electronics~\cite{hls4ml,CMSP2L1T}, ML methods have not yet been used to address the significant bottleneck in the transport of data from front-end ASICs to back-end
FPGAs. 

The high-granularity endcap calorimeter (HGCAL)~\cite{CERN-LHCC-2017-023} currently under construction by the CMS experiment~\cite{Collaboration_2008} for eventual use at HL-LHC provides an excellent example of the big data challenges facing high energy physics.
As an \emph{imaging calorimeter}, the HGCAL includes 
over 6 million readout channels, providing an unprecedented level of segmentation for calorimetry at high-energy colliders. 
In order to provide input to the real-time event filtering (trigger) system of CMS, the HGCAL transmits a stream of trigger data at a frequency of 40\,MHz resulting in massive data rates.  At data creation, two ASICs are used to digitize and
encode trigger data before transmission to back-end
FPGAs for further processing.




In this paper, we explore the application of ML algorithms to the task of processing large amounts of data with low latency and low power in a high radiation environment in order to maximize efficient use of limited bandwidth.
We focus on an ASIC implementation of an autoencoder algorithm that uses a configurable NN to efficiently compress and encode
data automatically before transmission.  Subsequent stages of data processing can either decode the data or continue analyzing the encoded data.   
In our ASIC implementation, 
the NN architecture is fixed, but exceptional flexibility in application is preserved by making the NN \textit{weights} programmable.
We apply our methodology to the specific front-end data transmission challenge of the CMS HGCAL, showing that
the advantage of our approach lies in the flexibility and configurability of the algorithm, which allows us to generate unique data compression algorithms  depending on HGCAL sensor geometry, sensor location on the detector and the corresponding occupancy and signal patterns, changing accelerator conditions, or changing detector conditions

The remainder of this paper is organized as follows.
In Section~\ref{sec:our_method}, we introduce the HGCAL challenge in greater detail and outline our conceptual approach. Then, in Section~\ref{sec:AE}, we elaborate on the design and training of the autoencoder NN for the specific case of the CMS HGCAL detector. In Section~\ref{sec:cad_tools}, we present the digital implementation of the trained NN in the ASIC. Finally, we summarize our work and discuss future directions in Section~\ref{sec:conclusions}. 








\section{System Constraints and Concept}
\label{sec:our_method}


The HGCAL is a major upgrade of the CMS endcap calorimeter planned to for the HL-LHC and provides a fitting demonstrator for the ASIC ML accelerator technology. The HGCAL is described in detail in Ref.~\cite{CERN-LHCC-2017-023}; relevant implementation details that have changed since publication of Ref.~\cite{CERN-LHCC-2017-023} are updated in this article.

This ``imaging calorimeter,'' which includes over 600\,m$^2$ of active silicon and over 6 million readout channels, is composed of $50$ layers of active shower-sampling media interleaved with dense absorber. The active medium of the $28$-layer front electromagnetic compartment is silicon, while the $22$-layer rear hadronic compartment includes both silicon and plastic scintillator. Silicon layers are tiled with $8$'' hexagonal sensor modules, with each module including $48$ logical trigger cells (TC) arranged in three $4\times{}4$ matrices as shown in Fig.~\ref{fig:autoencoder_block}.  While the NN can be configured for both the silicon and scintillator geometries, the silicon geometry is used throughout this paper to illustrate the concepts.

To provide input to the CMS trigger system, data must be transmitted from the on-sensor analog-to-digital ASICs to the all-FPGA back-end detector electronics system at the nominal HL-LHC collision rate of 40\,MHz. Because bandwidth constraints prohibit transmission of data for all 48 TCs at 40\,MHz, a front-end concentrator ASIC (ECON-T) is being developed to compress a single sensor's information before transmission to the back-end trigger electronics. 
Each sensor module produces 7 bits of floating-point charge data for each of the 48 TCs at 40\,MHz. Thus, the lossy compression task of the ECON-T ASIC is to aggregate the 48 7-bit signals from a sensor and compress the data into a range spanning 48--144 bits while maximally preserving the energy pattern of the sensor. The range of the output bits depends on the location of the sensor module in the detector and the number of links available for a given ECON-T ASIC to transmit the data. The number of links allocated will roughly correspond to the average sensor occupancy, which varies by two orders of magnitude over all sensor locations. The exact task depends on handling of data framing and TC address information as well as on whether the ECON-T algorithm operates with fixed or variable latency.  The ECON-T design provides the user a choice among three expert algorithms for TC compression including TC threshold application, sorting and selection of highest energy TC, and aggregation of adjacent TCs.  Unused algorithms are clock-gated to conserve power.


\begin{figure}[!t]
    \centering
    \includegraphics[width=0.95\columnwidth]{imgs/fig1.pdf}
    \caption{Simplified version of the internal flow of the autoencoder compression task which takes the module energy deposits, normalizes them to the sum of the energy in the module, and then performs shape encoding}
    \label{fig:autoencoder_block}
\end{figure}

The ECON-T ASIC is being developed for the LPCMOS (Low Power CMOS) 65\,nm feature size technology and is under active development for CMS.  Because it is located on-detector in a high radiation environment, its design also requires tolerance to single event effects.  
The allocated footprint for the fabrication of this chip is approximately $5\times5$\,mm$^2$. 
It is expected that sufficient area will be available for potential inclusion of our NN compression logic with an approximate area of $4$\,mm$^2$.
The constraints for the compression algorithms are that they should accept new input data at 40\,MHz and complete processing in 50\,ns.
The power budget of the task is less than 100\,mW.

Our contribution is a NN to perform the ECON-T compression task.  
It is a central tenet of our design that the compression algorithm is \textit{reconfigurable}.
Because we are implementing a design for an ASIC, the architecture of the NN will be fixed, but the \textit{weights} of the NN need to be configurable such that the algorithm itself is adaptable.  
This has several advantages. Through reconfiguration, we will be able to: 
\begin{itemize}
    \item \textit{enable} more computationally complex compression algorithms, which could improve overall physics performance or allow more flexible algorithms;
    \item \textit{customize} the compression algorithm of each sensor based on their location within the detector;
    \item \textit{adapt} the compression algorithm for changing detector and collider conditions (for example, if the detector loses a channel or has a noisy channel it can be accounted for or if the collider has more pileup than expected, the algorithm can be adjusted to deal with new or unexpected conditions without catastrophic failure).
\end{itemize}

For our compression algorithm, we choose to utilize an autoencoder architecture. 
It provides a generic and flexible compression solution, consisting of two NNs: an encoder and a decoder.
The encoding network maps inputs to an intermediate \textit{latent} representation with lower dimensionality than the space of inputs, after which the decoding network aims to recover the original signal.
In the HGCAL application, the encoding NN would compress HGCAL data on the ASIC before transmission to the calorimeter trigger FPGAs for subsequent decoding.
Ultimately, in a final realistic system, we do not anticipate using a full autoencoder architecture because FPGA resources on the back-end FPGA system will not be sufficient to do a full decoding for every sensor.
However, in the absence of understanding how best to use the latent representation later in the processing chain, we optimize performance for an autoencoder because it is a reasonable proxy for the encoder NN encapsulating the salient sensor features such that the image can be decoded from the latent representation.  
Finally, in Fig.~\ref{fig:autoencoder_block}, the compression task is split into two parts: an overall normalization over the entire sensor to preserve the total energy in the sensor and the NN \textit{shape} encoder, which encodes the energy pattern across the sensor.

For the automated design tool flow, it is very important to have a rapid co-design loop between the NN algorithm training and the implementation in hardware in order to understand whether the algorithm is meeting system constraints for power, area, and performance simultaneously.  To achieve this, we use \texttt{hls4ml}~\cite{hls4ml} which translates NNs trained in common open-source ML software frameworks into RTL using high-level synthesis (HLS) tools~\cite{cong2011high}.  The efficacy of this approach will be described in greater detail in the following section.  






\section{Algorithm Design and Performance}
\label{sec:AE}

Our task is to design an algorithm that will reproduce the energy pattern in the sensor while simultaneously adhering to hardware constraints, i.e., fitting in the available area within the ECON-T ASIC chip while complying with system latency and power constraints.  Because we are training the algorithm based on a single sensor's energy pattern, we will not be able to optimize for multi-sensor physics performance, such as particle energy resolution.  Ultimately, the physics performance may determine the final system optimization, however, it is beyond the scope of this study.  Therefore, our target is to design an algorithm that reproduces the original sensor energy pattern as accurately as possible through the autoencoder compression-and-decompression bottleneck.  

There are a number of elements needed to design our compression algorithm: a sample of events for training and validation, a preprocessing and normalization block, an optimized NN architecture, and metrics for evaluating the NN performance, both for determining the training loss and the final network evaluation.
An essential aspect of the training procedure is quantization-aware training (QAT), i.e., we approximate bit-accurate reduced precision for all of the NN calculations during training.  QAT is known to be much more performant than post-training quantization (PTQ), where the training is done using 32-bit floating-point operations, which are then truncated post-training to fixed-point or integer representations. In a previous study of the  \texttt{QKeras}~\cite{qkeras} tool, QAT was performed for an LHC trigger task. It was found that with PTQ, the minimum bit width possible without loss of performance was 14 bits while with QAT, the same performance could be achieved with 6-bit weights.  Thus, PTQ would lead to more than 4-fold increase in the area of an ASIC design based on the bit operations hardware design metric~\cite{2020arXiv200408906K}.  Therefore, we use \texttt{QKeras} for training the NNs in this study.

\paragraph*{Training Sample}
Test energy patterns in the sensors are simulated using top-quark-pair events overlaid with 200 simultaneous collisions per bunch crossing in the CMS software framework~\cite{cmssw}.
These simulated events create a sample of typical energy patterns in the HGCAL sensors, which we use as a realistic proxy for the sensor data.  

\paragraph*{Preprocessing}
The compression task is factorized into normalization and shape extraction components, as illustrated in Fig.~\ref{fig:autoencoder_block}.  The first stage of ECON-T processing for all algorithms is to expand the 7-bit floating-point TC data to the inherent 22-bit fixed-point TC data.
The sum value of all 48 TC is identified and used to normalize the charge distribution across the full sensor (and the sum of TC charge is included in the final data payload to allow subsequent interpretation of normalized TC data).
The normalized NN inputs are truncated to 8 bits to allow a more compact NN implementation, while ensuring that any omitted cells constitute less than 1\% of the total energy recorded within a module.

\paragraph*{NN Architecture}
The encoding NN architecture consists of successive layers that sequentially process the input data.
Convolutional layers are used to extract spatial features from images through the application of filters: matrices of configurable parameters.
While convolutional layers use relatively few parameters, convolution requires many multiply-accumulate operations (MACs).
Conversely, a fully-connected layer multiplies a vector of input elements by a matrix of configurable weights, generally requiring more configurable parameters and fewer MACs than a convolution.
The impact of the choice of precision for all internal parameters (constrained by the available area on chip) is accounted for by training inherently quantized models with the \texttt{QKeras} package~\cite{qkeras}.
Because the HGCAL sensor data compression task takes as input an image data representation, we consider a convolutional NN layer as a natural approach.  Typical convolutions rely on the input being in a Cartesian representation, though other shapes can be explored in future work.  Here, we map the hexagonal sensor shape to a more typical Cartesian arrangement as illustrated in Fig.~\ref{fig:conv}, which simplifies the training and hardware implementation.

\begin{figure}[!htb]
\centering
\includegraphics[width=0.8\columnwidth]{imgs/econ-cnn.pdf}
\caption{Mapping the hexagonal sensor geometry to potential Cartesian representations for convolutional layer operations.} \label{fig:conv}
\end{figure}

\paragraph*{Training and Performance Metrics}
The performance of the autoencoder is based on how well the original image is reproduced after encoding and decoding.  
We quantify the difference between raw and decoded HGCAL data with the energy mover's distance (EMD)~\cite{emd}.
Given a particular normalized energy distribution, one may physically relocate some energy fraction $dE$ by a spatial distance $dx$, leading to a new distribution with an associated rearrangement cost $dEdx$.
This notion can be extended to define an ``optimal transport'' between two energy distributions $\mathcal{A}$ and $\mathcal{B}$, as a re-mapping that minimizes this total rearrangement cost, EMD($\mathcal{A},\mathcal{B}$).
While the performance of the autoencoder is assessed with EMD, taking into account the complete hexagonal sensor geometry, this metric is not used directly in the algorithm training, as it involves nondifferentiable and computationally intensive operations.
Models are instead trained with a modified $\chi^2$ loss function incorporating cell-to-cell distances, as a fast approximation of EMD.
Specifically, individual TCs are re-summed into all physical groups of approximately $2\times2$ and $3\times3$ ``super-cells'' based on the full hexagonal cells 
with corresponding $\chi^2$ values computed for the coarsened images.
The total loss sums each such $\chi^2$ together, resulting in a comparatively lenient penalty when mis-reconstruction occurs only on small spatial scales.
Including these additional $\chi^2$ terms in the training procedure is found to yield significant improvements to the autoencoder performance, as measured with EMD.
To ensure an unbiased NN optimization, the data are randomly partitioned into separate samples for training (80\%) and validation (20\%), with training termination set by the loss observed in the validation sample.

\begin{figure}[!t]
\centering
\includegraphics[width=0.9\columnwidth]{imgs/architecture.png}
\caption{The autoencoder neural network architecture and data flow for the baseline encoder model} \label{fig:data_flow}
\end{figure}

\subsection*{Baseline Encoder Model}

A simple encoding NN with a single convolutional and dense layer architecture is investigated.
Normalized inputs from hexagonal sensors are arranged into three arrays of $4\times4$ to form a regular geometry.
The convolution layer consists of eight $3\times3\times3$ kernel matrices, giving a $8\times4\times4$ output after convolution.
It was found that more than eight kernel matrices brought negligible performance improvement.  
These 128 values are flattened and fed through a dense layer to yield 16 9-bit output values.
ReLU activations~\cite{relu1,relu2} are applied before and after the dense layer.
This leads to a total of 2,288 weight parameters (dominated by the 2,064 parameters used to configure the dense layer), each of which are specified with 6-bit precision.
A single inference requires a total of 4,448 MACs, with similar requirements from the convolution (2,400) and dense layers (2,048).
The size and complexity of this baseline model are constrained by area, on-chip memory and interfaces, and power, which impose additional optimization considerations.
The encoder architecture with the reconfigurable weights is illustrated in Fig.~\ref{fig:data_flow}


\subsection*{Optimization Considerations and Comparisons}

While the presence of a single convolutional layer is critical for good physics performance of the algorithm (approximated by the EMD between input and decoded images), adding more filters or additional convolutional layers only weakly improves physics performance, at the expense of significantly increased area.
Changes in the number and size of the dense layers yield more dramatic differences.

\begin{figure}[!t]
\centering
\includegraphics[width=0.48\textwidth]{imgs/fig2.pdf}
\caption{Median EMD for decoded HGCAL images from the validation dataset, as function of sensor occupancy for six NN configurations.  Vertical lines (suppressed for the 160-bit configurations) denote 68\% EMD intervals. Occupancy is defined as the number of TCs with signals exceeding one minimum ionizing particle divided by cosh\,$\eta$ where $\eta$ is the pseudorapidity of the TC. (Results shown for version of NN with maximum of 10 bits for each of 16 outputs rather than 9 bits as described in the text.)}
\label{fig2}
\end{figure}

Figure~\ref{fig2} shows a sweep over the number of dense layer outputs, where remaining aspects of the design are fixed based on hardware constraints:
the precision of outputs and weights are coherently varied to ensure that both the total number of outputs and the weight bits are fixed.
Architectures featuring many outputs with lower relative precision consistently outperform their counterparts.
The autoencoder is robust across a variety of conditions and performs well in the high-occupancy regime, which poses the greatest challenge for trigger reconstruction.


\paragraph*{Reconfigurability}
Figure~\ref{fig2} also demonstrates how the same NN encoder can be re-optimized and configured for new data-taking conditions, by comparing sensors in detector regions requiring low- and high-throughput.
The maximum data throughput of 144 bits from 16 9-bit outputs can be reduced through fully configurable selective truncation.  Expected use cases include transmission of (48, 80, 112, 144) bits from 16 (3, 4, 7, 9) bit outputs, though the network can also be configured to transmit fewer than 16 outputs, or a mix of precisions.


\section{Implementation Methodology and Results}
\label{sec:cad_tools}

In this section, we detail the implementation of the trained NN described in Sec.~\ref{sec:AE} in the ECON-T ASIC. We discuss the design and verification flow, the architectural and design exploration, steps required for deployment in a radiation environment, design performance metrics, and finally the implementation results.



\begin{table}[t!]
    \begin{center}
    \caption{\label{tab:area_dse}Area breakdown for pipelined implementations. The results are from Catapult HLS estimations and areas are in $\mu m^2$.}
    \begin{tabular}{c|r|r|r}
       
        Initiation Interval & Total Area & Register Area & MUX Area  \\
        \toprule
         1 & 1,138,242	& 925 & 0 \\
         2 & 891,195 & 5,228 & 12,989 \\
         4 & 765,877 & 8,503 & 16,089 \\
         8 & 699,988 & 8,509 & 16,252 \\
        \bottomrule
    \end{tabular}
    \end{center}
\end{table}


\subsection*{Algorithm to Accelerator Development}
For our design flow, we adopted the \texttt{hls4ml} framework~\cite{hls4ml} to automate the mapping of ML models onto reconfigurable logic. For this work, we extended \texttt{hls4ml} to our ASIC flow.
Traditionally, hardware designers utilize hardware description languages (HDLs) and a level of abstraction known as the Register Transfer Level (RTL).
In recent years, HLS has become an alternative for generating hardware modules from code written in programming languages such as C/C++. HLS comes with significant benefits: it raises the level of abstraction and reduces the simulation time; it simplifies the verification phases; and finally, it makes the exploration and evaluation of design alternatives easier.
The original flow of \texttt{hls4ml} generates state-of-the-art synthesizable C++ code and HLS directives from the ML-model specifications. The generated code is then fed into the Vivado HLS tool to generate an accelerator in HDL RTL code for the deployment on Xilinx FPGAs~\cite{vivadohls2020}.
We extended \texttt{hls4ml} to support Mentor's Catapult HLS~\cite{catapulthls2020} tool and target our specific 65\,nm LP CMOS technology for ASIC fabrication.
We integrated the HLS-generated code with a SystemVerilog RTL IP of the programmable I\textsuperscript{2}C peripheral\footnote{The authors use \emph{controller/peripheral} in place of \emph{master/slave} when referring to such I\textsuperscript{2}C devices or processes~\cite{osha_resolution}.}.
We finally created a component database and layout to be incorporated into the ECON-T ASIC top-level assembly using a digital implementation flow. The standard flow was modified to accommodate automatic triple modular redundancy implementation for HLS-generated RTL integrated with other SystemVerilog modules.

We complemented our design flow with a robust validation and verification methodology across the various refinement steps.  We validated the C++ HLS code against the \texttt{QKeras} trained model to guarantee the model's functional correctness. Earlier in the design flow, we also performed dynamic and static verification of the synthesizable specifications: we checked design rules with static analysis of the C++ HLS code (Mentor CDesignChecker~\cite{hlsverific2020}), measured coverage metrics (Mentor CCov~\cite{hlsverific2020}), and finally, ran simulation-based equivalence checking. For the HLS-generated RTL code, we followed a more traditional simulation-based verification to ensure optimized power, area, and speed.  


\subsection*{Architectural Exploration}

\texttt{hls4ml} coupled with the industry standard Catapult HLS (ver. 10.6) tool allowed us to explore the cost and performance trade-offs of various micro-architectural hardware implementations for our ML model. We decided on a pipelined implementation for our accelerator to increase concurrent execution as an early design decision.
A pipelined design can process new inputs every $N$ clock cycles, where $N$ is the initiation interval (II) of the design. Table~\ref{tab:area_dse} shows the area breakdown for different II values (1, 2, 4, 8). It is noticeable that although the area is higher for II$=1$, the required resources are mostly functional logic to implement a highly-parallel datapath, i.e. there are no multiplexers.
A higher II value implies less design parallelism and more functional-resource reuse. This choice reduces the overall area, but the resource breakdown shows an increase in control logic (MUX) and registers. 
An II of 1 was ultimately selected so that new inputs may be processed in sync with a single clock operating at 40\,MHz LHC crossing frequency.

We used a fixed-point representation (\texttt{ac\_fixed}~\cite{hlslibs2020}) for the input, intermediate, and output parameters of our ML model designed with \texttt{hls4ml}. This choice provided us with a high degree of flexibility for exploring the area and accuracy trade-off of the ML-model hardware implementations obtained with HLS.  The RTL schematics for the encoder block are shown in Fig.~\ref{fig:rtl}.  The basic structure of the convolution and dense layers can be seen at the schematic level. The top right and bottom right diagrams are zoomed in portions of this schematic depicting the output and MACs.



\begin{figure}[!t]
\centering
\includegraphics[width=\columnwidth]{imgs/pdf/rtl_upd.pdf}
\caption{Encoder RTL Schematics, the basic structure of the convolution and dense layers can be seen at the schematic level on the left and zoomed in images are provided for the output and MAC portions on the right} \label{fig:rtl}
\end{figure}


\subsection*{Digital Implementation in a Radiation Environment}
The digital design consists of three major functional blocks: (i) A converter which is a classical module designed with HLS; (ii) An encoder, which uses \texttt{hls4ml}; (iii) and an I\textsuperscript{2}C peripheral which uses a SystemVerilog RTL code. The converter is used for normalizing the 48 (22\,b) inputs to 48 (8\,b). An encoder is used for data classification and further compression to 16 (9\,b) outputs. To have a flexible and reconfigurable algorithm, all the parameters (13,728\,b)  can  be  setup  via  the  I\textsuperscript{2}C  interface  on-chip. The programming of the I\textsuperscript{2}C peripheral takes less than 50\,$\mu$s corresponding to a total of 1,716 I\textsuperscript{2}C clock cycles, utilizing an 8\,b input bus. Once the weights are setup, the algorithm adds a total latency of 2 bunch crossing (BX) cycles to the trigger path---one cycle to convert and another cycle to encode resulting in total inference latency of 50\,ns and a new input accepted every 25\,ns.


\paragraph*{Integrated Converter, Encoder and I\textsuperscript{2}C peripheral}
 
 An integrated approach to the development is needed in order to avoid routing congestion of connecting the weights to the appropriate layers across the encoder. The floor-plan of the digital implementation occupying 2.4\,mm$\times$1.5\,mm is shown in Fig~\ref{fig:Autoencoder}. The converter logic is located near the data input at the top of the design, majority of the area is occupied by the encoder, interleaved with the distributed I\textsuperscript{2}C network.


\begin{figure}
    \centering
    \includegraphics[width=.4\textwidth]{imgs/Autoencoder.png}
    \caption{Design floor-plan with an integrated converter, encoder and I\textsuperscript{2}C peripheral occupying a total area of 3.6 mm\textsuperscript{2}. The converter is highlighted in grey, the I\textsuperscript{2}C peripheral in white and the rest of the area is occupied by the encoder.}
    \label{fig:Autoencoder}
\end{figure}

\paragraph*{Design Considerations for Total Ionizing Dose Performance}

Apart from all requirements considered above, our design must guarantee on-detector circuit reliability in the high radiation environment of HL-LHC~\cite{alia2017lhc,huhtinen1996radiation}. The circuitry should withstand total ionizing dose of approximately 200\,Mrad over the lifetime of the experiment along with high SEE rates~\cite{schrimpf2004radiation,petersen2011single,dodd2010current}. Since previous measurement results have indicated that the average time delay of all cells from the 65\,nm LP process library increases after 200\,Mrad irradiation~\cite{Casas:2275135}, minimum size cells are avoided. Normal Vt standard cell technology library is used. The implementation uses concurrent multi-mode multi-corner static timing analysis for ensuring performance. The foundry worst case libraries are a good stand-in for modelling radiation damage.
All weights are stored in registers and no SRAMs or DICE cells~\cite{8194929} are used.

\begin{figure}[!htb]
    \centering
    \includegraphics[width=.4\textwidth]{imgs/tmr_nothunder.png} \\
    \caption{Triple modular redundancy scheme used for the encoder and converter. Each register is triplicated and a majority voter determines the output.}
    \label{fig:tmr}
    \vspace{.3cm}
    \includegraphics[width=.4\textwidth]{imgs/full_tmr_nothunder.png}
    \caption{Full module triplication is used for the I\textsuperscript{2}C peripheral. All combinational logic within the module is triplicated, which is used by three majority voters to form the inputs to triplicated registers. Feedback from the output of the registers enables autocorrection and protects against accumulating errors due to single event upsets over time.}
    \label{fig:full_tmr}
\end{figure}

\FloatBarrier
\begin{table*}[ht]
    \centering
    \caption{\label{tab:metrics} Design (D) and verification (V) metrics from model generation to verified IP.}
        \begin{tabular}{p{.3\textwidth}|r|p{.1\textwidth}|p{.2\textwidth}}
        STEP                                 & TIME     & ITER.              & SIZE                                    \\
        \toprule
        Model generation (D)                 & 0.98s    & \multirow{2}{*}{50-100} & \multirow{2}{*}{1089 C++ LoC}           \\
        C Simulation (V)                     & 0.14s    &                         &                                         \\
        \hline
        High-level synthesis (D)             & 00:30:17 & \multirow{2}{*}{3-100}    & \multirow{2}{*}{39,716 Verilog LoC}     \\
        RTL Simulation (V)                   & 00:00:46 &                         &                                         \\
        \hline
        Logic synthesis (D)                  & 06:04:19 & \multirow{5}{*}{6}      & \multirow{2}{*}{769,481 gates}          \\
        Gate-level simulation (V)            & 00:25:19 &                         &                                         \\
        Place and route (D)                  & 39:33:11 &                         & \multirow{3}{*}{806,255 gates}        \\
        Post-layout simulation (V)           & 00:51:41 &                         &                                         \\
        Post-layout parasitic simulation (V) & 01:51:30 &                         &                                         \\
        SEE simulation (V)                  & 04:17:00 &
            &   \\
        \hline
        Layout (D)                           & $\sim{}$00:20:00 & \multirow{2}{*}{1}      &  \\
        LVS \& DRC (V)                       & $\sim{}$01:00:00 &                         &         \\ 
        \bottomrule
        \end{tabular}
\end{table*}
\FloatBarrier

\paragraph*{Single Event Effect Mitigation}


Mitigating single-event effects (SEEs) is a critical step in the ASIC implementation for effective performance in the HL-LHC environment. Several  %
techniques have been proposed and used over the years to tackle this specific problem~\cite{fulkerson2006single,kuboyama2009single,gong2008new}. 

Triple modular redundancy (TMR) is a well-known technique to protect digital circuits against the undesirable effects of SEEs~\cite{lyons1962use,habinc2002functional}. Depending on the functionality of the block auto-correction features might be required for registers which store data.  

We have used two different TMR implementations: simple TMR with triplicated registers and a majority voter for the data path shown in Fig.~\ref{fig:tmr} and fully triplicating the entire module as shown in Fig.~\ref{fig:full_tmr} for the I\textsuperscript{2}C peripheral for storing weights. 

Since new data arrives to the encoder block every $25$\,ns, no auto-correction techniques are required. On the other hand, the values of the weights set by the I\textsuperscript{2}C peripheral (parameters of the NN) are vital as they are central to the vector multiplications used in NNs. Once programmed these are not expected to change over lengthy periods of time, hence, auto correction techniques are used to ensure that register errors due to single event upsets do not accumulate over time. As shown in Figure~\ref{fig:full_tmr}, all combinational logic within the module is triplicated, which is used by three majority voters to  form  the  inputs  to  triplicated  registers.  Feedback  from  the  output  of the registers enables autocorrection. This method does require the I\textsuperscript{2}C peripheral to be clocked periodically. 








\subsection*{Performance Metrics and Implementation Results}



Table \ref{tab:metrics} lists metrics characterizing our design flow, such as the time spent for the design (D) and validation/verification (V) stages, the number of iterations, and the complexity of design representation at each stage. The table illustrates the main steps required to create a full and validated design.  A co-design approach requires being able to have a rapid transition between each step to inform the other steps. 

The HLS model description requires approximately 1,000 lines of code. This stage is fast ($\sim$1 second) but requires several hundred iterations to optimize the algorithm performance, driven by the physics goals. The HLS stage determines the level of parallelism in the design, choice of pipelining, resource reuse factor, and clock frequency. This directly impacts the total area, power consumption, and the latency of the design. One hot encoding of finite state machines for robust Single Event Upset (SEU) prevention also needs to be introduced at this stage. Clock gating is employed to save system level power. The digital implementation stage is time intensive, requiring $\sim$65 hours of design and verification to meet the speed and area constraints with fewer iterations.

The final implementation results are presented in Table~\ref{tab:comparison}.  While there are challenges due to technology choices in making a comparison with a our design in an FPGA, we consider a fully unrolled FPGA implementation on a typical Xilinx Kintex Ultrascale FPGA device. Considering algorithm block power only and depending on configuration choices, an equivalent FPGA implementation consumes roughly 2.5--5\,W with a latency of $\sim$300\,ns~\cite{hls4ml} compared to the ASIC implementation, which consumes 95\,mW.  The ASIC implementation is expected to provide more than an order of magnitude improvement in power with a reduction in latency.

\begin{table}[tbh!]
    \begin{center}
    \caption{\label{tab:comparison}Key simulation performance parameters of the design.}
    \begin{tabular}{c|c|c|c}
       
        Latency & Energy/inference & Power & Area  \\
        \toprule
        $50$\,ns & $2.38$\,nJ/inf. & $95$\,mW & $3.6\,\text{mm}^2$\\
        \bottomrule
    \end{tabular}
    \end{center}
\end{table}

\section{Summary and Outlook}
\label{sec:conclusions}

A design methodology spanning from machine learning model generation to ASIC IP block creation has been presented. 
A low power, low latency reconfigurable data compression algorithm based on a convolutional neural network has been processed through synthesis and physical layout flows based on a 65\,nm LP CMOS process, designed to withstand radiation environments of up to 200\,Mrad.  

For the ECON-T ASIC, our task is to perform efficient lossy compression of an HGCAL sensor energy pattern to transmit data to off-detector electronics.  Compression is accomplished using a neural network autoencoder consisting of convolution and dense neural network layers.  
Optimal design and training of the algorithm is performed using quantization-aware training techniques to achieve good physics performance while optimizing for low power and area.  

The encoder architecture set by the model requires approximately 225,000 multiply-accumulate operations to perform vector multiplications every 25\,ns. In order to optimize for low power operation while maintaining data throughput of 40\,MHz, a highly parallel architecture is chosen at the expense of larger area. The energy consumption per inference is 2.38\,nJ. The final design consists of 800k gates and occupies a total area of 3.6\,mm$^2$.

The design demonstrates how complex NN architectures can be implemented on the front-end ASICs with realistic area constraints, allowing for minimal loss of information in the trigger data stream. Furthermore, we show that in spite of a fixed ASIC implementation, ML algorithms can still be designed with sufficient flexibility to enable reconfiguration for new operational conditions. Apart from that, the I\textsuperscript{2}C block allows real-time reconfiguration of weights, thus, facilitating the first steps toward real-time embedded AI.  This is the first time that a radiation tolerant on-detector ASIC implementation of a neural network has been designed for particle physics applications.

We look forward to inclusion of the design IP in the ECON-T ASIC fabrication. This would allow us to test the design in a physical chip. Beyond the ECON-T ASIC, there is vast potential for future work using our design methodology including: other domain applications and adaptations for ultra low power, longer latency applications; other technology nodes and design considerations; and more types of neural network architectures, which could be scaled out to larger and more complex designs.  





\section*{Authors' Contributions}
The project was initiated and coordinated by FF, JH, and NT.  CH, MK, and DN led the development of the algorithm training and HLS translation. GDG and CH performed HLS to RTL synthesis and validation of the RTL design. FF and YL focused on the digital implementation, power analysis, and algorithm interfaces to the rest of the chip including I2C with CG. FF, MBV, and LM developed techniques for making the design radiation tolerant. JH, SOM, and NT provided supervision for the project. JD, PH, VL, JN, MP, and SS provided support for the \texttt{hls4ml} infrastructure and initial algorithm implementations in HLS.

\section*{Acknowledgment}
The authors would like to acknowledge CAD support from Sandeep Garg and Anoop Saha from Mentor Graphics for Catapult HLS and Bruce Cauble and Brent Carlson from Cadence for Innovus and Incisive. The authors would also like to thank the Fermilab ASIC group for incorporating the autoencoder block into the ECON-T ASIC; CMS HGCAL and Jean-Baptiste Sauvan for providing simulated module images for training; and Andre Davide for extensive input on network optimization.


We acknowledge the Fast Machine Learning collective as an open community of multi-domain experts and collaborators. This community was important for the development of this project.


{\footnotesize
\bibliographystyle{IEEEtran}
