# SAGE - A Tool for Optimal Deployments in Kubernetes Clusters ††thanks: This
work was supported by a grant of the Romanian National Authority for
Scientific Research and Innovation, CNCS/CCCDI - UEFISCDI, project number PN-
III-P1-1.1-TE-2021-0676, within PNCDI III.

Vlad-Ioan Luca1 and Mădălina Eraşcu2  Faculty of Mathematics and Informatics,
West University of Timisoara
4 blvd. V. Parvan, 300223, Timisoara, Romania
Email<EMAIL_ADDRESS><EMAIL_ADDRESS>
###### Abstract

Cloud computing has brought a fundamental transformation in how organizations
operate their applications, enabling them to achieve affordable high
availability of services. Kubernetes has emerged as the preferred choice for
container orchestration and service management across many Cloud computing
platforms. The scheduler in Kubernetes plays a crucial role in determining the
placement of newly deployed service containers. However, the default
scheduler, while fast, often lacks optimization, leading to inefficient
service placement or even deployment failures.

This paper introduces SAGE, a tool for optimal solutions in Kubernetes
clusters that can also assist the Kubernetes default scheduler and any other
custom scheduler in application deployment. SAGE computes an optimal
deployment plan based on the constraints of the application to be deployed and
the available Cloud resources. We show the potential benefits of using SAGE by
considering test cases with various characteristics. It turns out that SAGE
surpasses other schedulers by comprehensively analyzing the application demand
and cluster image. This ability allows it to better understand the needs of
the pods, resulting in consistently optimal solutions across all scenarios.
The accompanying material of this paper is publicly available at
https://github.com/SAGE-Project/SAGE-Predeployer.

###### Index Terms:

Cloud Services, deployment, scheduler, Kubernetes, OMT solver

##  I Introduction

The advent of cloud computing radically changed the software development. In
terms of architecture, it led to the transition from monolithic software
architectures to a more loosely coupled and cloud-enabled architecture such as
component-based applications111https://www.gartner.com/en/documents/3624017
and micro-services [3]. In terms of life cycle, for shorter timing between
idea and deployment, it facilitated the development of DevOps paradigm. At the
early stages of software development, _application modeling_ would benefit
from techniques for automatic and optimal deployment, which encompasses two
key aspects:  (1) the synthesis of deployment plans that are optimal by
design, and  (2) the integration of such deployment plans into the application
modeling process, enabling formal reasoning on a model of the deployed
application.

The process of _automated deployment_ typically involves:  (1) selecting
computing resources,  (2) distributing or assigning application components
across available resources, and  (3) dynamically modifying the deployment to
handle peaks in user requests.

In [7], we tackled the first two steps by developing a recommendation engine.
In this paper, we show the benefits of using such a recommendation engine in
the deployment of service containers managed by Kubernetes [4], abreviated as
K8s. More precisely, we developed SAGE, which at the initial stage of
deployment, can obtain significant cost savings for a K8s cluster while also
helping with the selection of the most optimal hardware from a cloud hosting
service in an automatic manner. Additionally, it obtains a deployment plan in
scenarios where the K8s scheduler fails. SAGE integrates the recommendation
engine from [7], here named SAGEOpt, and a new component named SAGE
Predeployer. We chose K8s as it has emerged, in the last years, as the
industry standard for container orchestration and service management
supporting DevOps CI/CD paradigm. K8s is an open-source project that acts as a
bridge between the cluster operator and the applications running on the
cluster. Applications are structured as sets of services, each developed,
deployed, and scaled independently.

SAGE takes as input an application description (components and their
hardware/software requirements and the constraints in between) and the list of
available Cloud Provides offers, and uses SAGEOpt to output, in an automatic
manner, an optimal deployment plan, i.e. assignment of components on offers
and the type of these offers, such that the application constraints are
fulfilled and the leasing costs are minimized. SAGE Predeployer translates the
SAGEOpt deployment plan into specific K8s constructs which are used for
creating manifest files to be deployed to the K8s cluster.

By using various test cases, we show that SAGE can be used in scenarios with
typical K8s deployment constraints: pod affinity, anti-affinity, anti-affinity
to itself, number of replicas and node affinity. Moreover, SAGE excels in
scenarios where an analysis of the entire deployment is needed to determine
the optimal solution. In such cases, it successfully determines optimal pod
placements when the default scheduler of K8s and of Boreas [10], a scheduler
improving the K8s one, fail. These findings highlight SAGE as a cost-effective
and reliable approach that reduces infrastructure expenses by optimizing the
pre-deployment phase and generating an optimal solution all by maintaining the
application requirements.

##  II Related Work

SAGE can be used for the selection of the computing resources and the
distribution/assignment of the application components over the available
computing resources but to be used during the deployment, as a resource
scheduler, it has to be further extended. At this stage, it can also be used
as a complementary tool for a K8s scheduler as a deployment orchestrator.

The most similar works related to our are [2, 6, 11]. Paper [2] introduces
Zephyrus2 which has a role similar to the SAGEOpt. Different from our
approach, in Zephyrus2, the list of offers is limited (only four types of VMs)
while in our case it is dynamically constructed based on the cloud providers
(CPs) offers. Zephyrus2 can handle a similar set of constraints in between
components as ours, and, additionally, binding preferences allowing the
connection of components with components located in the same availability zone
or region. Zephyrus2 characterizes CP offers only by memory and price
requirements but their approach can be easily extended to other types of
resources. Binding preferences can easily be implemented in SAGEOpt.

Paper [6] used Zephyrus2 to synthesize an initial static deployment (an
approach similar to SAGE), and subsequently, to synthesize dynamic deployment
actions. Dynamic deployment actions represent auto-healing (in case of faults)
and scaling in and out instances of the components. This was applied to one
complex case study The Fredhopper Cloud Services, now part of
https://www.attraqt.com/. However, there is no study on the benefit of an
initial deployment as compared to the case it is missing.

Zephyrus2 is also used in Boreas [11], a custom K8s scheduler that can be used
to deploy service containers optimally in terms of price such that the
constraints between containers is maintained. Different from our approach,
Boreas does not use an initial optimal placement of pods and uses the entire
cluster of nodes. Different from SAGE, it can be used also as a resource
scheduler. K8s [4] also has a default scheduler for service container
deployment but, it does not use an initial optimal placement of pods and,
differently to Boreas, does not optimally place them hence it might fail when
Boreas does not. Except for Boreas, there are also other approaches for
optimizing the K8s scheduler [13, 8, 9], however, they take into account
deployment information like the type of applications deployed, order, and
duration of tasks, just to name a few, and this is our aim for future work.

##  III Preliminaries

###  III-A K8s Terminology

Kubernetes [1], abreviated K8s, is an open-source container orchestration
platform that facilitates the deployment, scaling, and management of
containerized applications across a cluster of computers. A _cluster_ consists
of a set of interconnected machines, called _nodes_. These nodes can be
physical servers or virtual machines. Each node runs a K8s runtime
environment, which enables it to host and manage _containers_.

_Containers_ are lightweight, isolated environments that package applications
and their dependencies, providing consistency and portability across different
computing environments.

To effectively manage containerized applications, K8s uses _pods_. It
encapsulates one or more containers that are co-located and share the same
network and storage resources. Pods are scheduled onto nodes and are the
atomic unit of deployment in K8s. Multiple pods are grouped together within a
higher-level abstraction called a _deployment_. A _deployment_ manages the
lifecycle of pods, ensuring the desired number of replicas are running and
providing self-healing capabilities by replacing failed pods. Nodes, on the
other hand, provide the underlying infrastructure to host and execute the
pods. Understanding these fundamental concepts is crucial for comprehending
the interaction between the SAGE Predeployer, K8s, and the deployment process.

_Pod and node affinities and anti-affinities_ , in K8s, are mechanisms that
influence the scheduling of pods onto nodes based on specific criteria. These
features provide control over pod distribution within a cluster. _Pod
affinity_ allows to define rules for scheduling pods based on the presence of
other pods. It promotes co-location of related pods on the same node or their
spread across different nodes, improving locality and reducing network
latency. _Pod anti-affinity_ ensures that the specified pods do not run on the
same node, increasing fault tolerance and high availability. A deployment can
have _anti-affinity with itself_ to ensure resiliency. _Node affinity_
influences pod scheduling based on node properties such as labels or resource
capacities, optimizing workload placement. We will use these mechanisms to
assign pods to the required nodes as specified by the SAGEOpt.

###  III-B K8s Scheduler

K8s uses a scheduler to find a suitable place for a pod on a nod. To do this,
it follows these steps:  (1) _Pod Watching_ : The scheduler continuously
monitors the K8s API server for newly created pods without assigned nodes.
(2) _Filtering (Predicates)_ : The scheduler applies filter functions to some
nodes, checking if each node can accommodate the pod based on available
resources, node conditions, taints/tolerations, and policy constraints.  (3)
_Scoring (Priorities)_ : The scheduler assigns a score to each feasible node
using scoring functions.  (4) _Node Selection_ : The node with the highest
total score is selected to run the pod.  (5) _Pod Binding_ : The selected node
is communicated to the system and the pod is placed on it.

One of the main concerns of the K8s scheduler is the speed of execution and,
because of this, the scheduler implements a series of optimizations that make
it hard to find the optimal solution. For example, the node
threshold222https://kubernetes.io/docs/concepts/scheduling-eviction/scheduler-
perf-tuning/ forces the scheduler to look only at a percentage of nodes when
taking the decision where to place the pod. Another one is the fact that the
scheduler does not analyze the whole batch of manifest files received when
placing a pod. These might have negative implications, see Section VI.

##  IV SAGE - A Tool for Optimal Deployments in Kubernetes Clusters

In this section we present SAGE tool (see Figure 1), pipelining an
optimization engine (SAGEOpt) and a predeployer (SAGE Predeployer).

###  IV-A SAGE Optimization Engine

_SAGE Optimization Engine (SAGEOpt)_ was developed in [7]. It solves the
following problem: given a description of an application (components hardware
requirements and the constraints in between) and a list of offers from Cloud
Providers, find, in an automatic manner, an optimal deployment plan, that is,
the allocation of components on virtual machines (VMs) such that the cost is
minimal and the constraints are satisfied. SAGEOpt supports a large set of
constraints between components:  (1) _Conflict._ The set of conflictual
components can not be deployed on the same VM.  (2) _Co-location._ The set of
collocated components should not be deployed on the same VM.  (3) _Exclusive
deployment._ From the set of exclusive deployment components, only one should
be deployed.  (4) _Require-Provide._ Such a constraint determines the number
of instances corresponding to the interacting components as follows:  (i)
$C_{i}$requires (consumes) at least $n_{ij}$ instances of $C_{j}$ and  (ii)
$C_{j}$can serve (provides) at most $m_{ij}$ instances of $C_{i}$.  (5) _Full
deployment._ The component being in full deployment must be deployed on all
leased VMs (except on those which would induce conflicts on components).  (6)
_Deployment with bounded number of instances._ The number of instances
corresponding to deployed component should be equal, greater or less than some
values. Implicitly, the instances of the same component are assigned to
different VMs in order to ensure resiliency.

###  IV-B SAGE Predeployer

The SAGE Predeployer is the bridge between the output of SAGEOpt and the K8s
infrastructure. Its primary function is to translate the optimal solution
obtained from SAGEOpt into K8s manifest files and facilitate their deployment
to a K8s cluster (Digital Ocean333https://www.digitalocean.com for now). To
this end, it proceeds as follows:  (1) Receive input  (2) Translate solution
(3) Create manifest files  (4) Deploy to Cloud infrastructure.

SAGESAGE PredeployerSAGEOptTranslator Optimal
Solution App
Description Cloud
Offers SAGE
manifest
files Boreas
manifest
files K8s
manifest
files K8s Cluster

Figure 1: SAGE General Architecture

_Step 1: Receive Input_ SAGE Predeployer calls SAGEOpt and takes as input the
output produced by it. This file has two sections (see Listing 1). The first
includes the description of the application deployed (name, components and
their requirements and the restrictions in between). The second, introduced by
output, includes the optimal solution obtained by SAGEOpt: the minimal price
of the solution, the type of VMs to be acquired and their specification, the
allocation of components on VMs.

Listing 1: SAGE Predeployer Input file

⬇

{

"application": "SecureWebContainer",

"components": [

{

"id": 1,

"name": "Balancer",

"Compute": {

"CPU": 1000,

"Memory": 2048

}, ... },

"operatingSystem": "httpd"

}, ...

],

"restrictions": [

{

"type": "Conflicts",

"alphaCompId": 1,

"compsIdList": [2, 3, 4, 5]

}, ...

],

"output": {

"min_price": 3360,

"types_of_VMs": [7, 24, 10, 10, 10],

"VMs_specs": [

{

"s-2vcpu-4gb": {

"cpu": 1800,

"memory": 3150,

"storage": 69000,

"operatingSystem": "nginx",

"price": 240,

"id": 7

}

},...

],

"assign_matr": [[1, 0, 0, 0, 0],

[0, 0, 1, 0, 0],

[0, 0, 0, 1, 1],

[0, 1, 0, 0, 0],

[0, 0, 1, 1, 1]]

}

}

_Step 2: Translate Solution_ SAGE Predeployer translates the optimal solution
provided by the SAGEOpt into K8s manifest files. During this process, each
component listed in the input file as a component is converted into a K8s
deployment manifest. The relevant fields from the input file are translated as
follows:  (1) application: will be the name of the deployment.  (2) compute:
is the hardware and software requirements of each pod.  (3) restrictions: all
restrictions of type conflict, co-location, and full deployment will be
translated into pod anti-affinity, pod affinity, and pod anti-affinity to
itself, respectively. The last constraint places each component instance
(replica) on different nodes (resiliency).  (4) types_of_vmsand vms_specs
specify the type of the nodes used and their hardware/software specifications
to be used in the scheduling. In fact, these are the nodes that give the
optimal solution as computed by SAGEOpt.  (5) assign_matr: is a matrix with
entries in $\\{0,1\\}$ that determines how instances of components are placed
on VMs or nodes. Each column represents a VM from types_of_VMs and VMs_specs,
and each row represents a component.

_Step 3: Create Manifest Files_ : The SAGE Predeployer generates K8s manifest
files based on the translated solution. The manifest files used by SAGE use
all the information given by SAGEOpt used for deployment (see Listing 2). This
information includes pod affinity and anti-affinity, pod anti-affinity to
itself, pod number of replicas, node affinity (information found in
assign_matr) and node characteristics (information found in VMs_specs).

Listing 2: Manifest file generated for deployment using SAGE for pod Balancer

⬇

apiVersion: apps/v1

kind: Deployment

metadata:

labels:

app: balancer

id: ’1’

name: balancer

spec:

replicas: 1

...

template:

...

spec:

affinity:

nodeAffinity:

...

nodeSelectorTerms:

- matchExpressions:

- key: index@

operator: In@

values:

- ’0’

podAntiAffinity:

...

- labelSelector:

matchExpressions:

- key: app

operator: In

values:

- apache

topologyKey: kubernetes.io/hostname

# all the other podAntiAffinity, in this case with nginx, idsserver, idsagent

containers:

- image: k8s.gcr.io/pause:2.0

name: balancer-container

resources:

requests:

cpu: 1000m

ephemeral-storage: 0Gi

memory: 2048Mi

Manifest files used by K8s (see Listing 3) are obtained from SAGE ones except
the node affinity information as highlighted in Listing 2. Compared to
manifest files for K8s, Boreas ones need to substract the resources allocated
to the Boreas scheduler ($100mCPU/number\\_of\\_all\\_instances$) from the
hardware requirements of each pod and also specify that the custom scheduler
is used. Neither node affinities are given to the manifest files for K8s and
Boreas because we want to evaluate the capabilities of their schedulers, nor
pod anti-affinities with itself unless they are specified precisely in the
application description file. The information included is:  (1) node types to
be used in the deployment and  (2) pod affinity/anti-affinity and number of
replicas.

Listing 3: Manifest file generated for deployment using K8s for pod Balancer

⬇

apiVersion: apps/v1

kind: Deployment

metadata:

labels:

app: balancer

id: ’1’

name: balancer

spec:

replicas: 1

...

template:

...

spec:

affinity:

podAntiAffinity:

...

- labelSelector:

matchExpressions:

- key: app

operator: In

values:

- apache

topologyKey: kubernetes.io/hostname

# all the other podAntiAffinity, in this case with nginx, idsserver, idsagent

containers:

- image: k8s.gcr.io/pause:2.0

name: balancer-container

resources:

requests:

cpu: 1000m

ephemeral-storage: 0Gi

memory: 2048Mi

Listing 4: Manifest file generated for deployment using Boreas for pod
Balancer

⬇

...

name: balancer-container

resources:

requests:

cpu: 980m@

ephemeral-storage: 0Gi

memory: 2048Mi

schedulerName: boreas-scheduler@

_Step 4: Deploy to Digital Ocean_ : Once the manifest files are created, SAGE
Predeployer deploys the translated SAGE solution to the Digital Ocean
infrastructure. It interacts with the cloud provider’s CLI to create the
required resources, such as nodes and pods, according to the specified
configurations.

##  V Test Cases

In this section, we present test cases that will be used in Section VI to show
the potential benefits of SAGE  (i) of being used for the initial deployment
plan as well as  (ii) compared to Boreas and K8s schedulers in offering
optimal deployment plans.  These test cases are either taken from [7] (see
Sections V-A–V-C), or are proposed by us based on the conclusions drawn from
experimental analysis (see Sections V-E–V-F) or are those proposed by
developers of Boreas (see Section V-D) More tests and their analysis are
available here.

###  V-A Secure Billing Email Service

In the context of a web application ensuring a secure billing email service we
consider an architecture consisting of $5$ components:  (i) a coding service
($C_{1}$),  (ii) a software manager of the user rights and privileges
($C_{2}$),  (iii) a gateway component ($C_{3}$),  (iv) an SQL server ($C_{4}$)
and  (v) a load balancer ($C_{5}$).  Component $C_{1}$ should use exclusively
a virtual machine, thus it can be considered in _conflict_ with all the other
components. In such a case the original optimization problem can be decomposed
in two subproblems, one corresponding to component $C_{1}$ and the other one
corresponding to the other $4$ components. The first problem is trivial: find
the VM with the smallest price which satisfies the hardware requirements of
component $C_{1}$.

The load balancing component should not be placed on the same machine as the
gateway component and the SQL server (_Conflict_ constraint). On the other
hand, only one instance of components $C_{1}$ and $C_{5}$ should be deployed
while the other three components could have a larger number of instances
placed on different virtual machines (_Deployment with a bounded number of
instances_ constraint, in particular, _equal bound_).

###  V-B Secure Web Container

The _Secure Web Container_ [5] is a service that provides:  (i) _resilience_
to attacks and failures, by introducing redundancy and diversity techniques,
and  (ii) protection from unauthorized and potentially dangerous accesses, by
integrating proper _intrusion detection_ tools.  Resilience can be implemented
by a set of different Web Container components and a Balancer component, which
is responsible for dispatching web requests to the active web containers to
ensure load balancing. In the simplest scenario, there are two Web Containers
(e.g. Apache Tomcat444http://tomcat.apache.org and Nginx). Intrusion detection
is ensured by the generation of intrusion detection reports with a certain
frequency. It was implemented by deploying an IDSAgent, to be installed on the
resources to be protected, and an IDSServer, which collects data gathered by
the IDSAgents and performs the detection activities.

The constraints between application components are as follows. For Web
resilience:  (i) Any two of the Balancer, Apache, and Nginx components cannot
be deployed on the same machine (_Conflict_ constraint);  (ii) Exactly one
Balancer component has to be instantiated (_Deployment with bounded number of
instances_ constraint, in particular _equal bound_).  (iii) The total number
of instances for Apache and Nginx components must be at least $3$ (level of
redundancy) (_Deployment with a bounded number of instances_ constraint, in
particular, _lower bound_).  For Web intrusion detection:  (i) the IDSServer
component needs exclusive use of machines (_Conflict_ constraint).  (ii) There
must be an IDSServer component additional instance every 10 IDSAgent component
instances (_Require-Provide_ constraint).  (iii) One instance of IDSAgent must
be allocated on every acquired machine except where an IDSServer or a Balancer
is deployed (_Full Deployment_ constraint).

###  V-C Oryx2 application

The main goal of Oryx2 is to take incoming data and use them to create and
instantiate predictive models for various use cases, e.g. movie
recommendations. It is comprised of several technologies. Both the batch and
serving layer are based on Apache Spark which in turn uses both Apache
Yarn555http://hadoop.apache.org/ for scheduling and Apache HDFS as a
distributed file system. For a processing pipeline, Oryx2 uses Apache Kafka
with at least two topics; one for incoming data and one for model update.
Apache Zookeeper666https://zookeeper.apache.org/ is used by Kafka for broker
coordination. All of the aforementioned technologies have subservices with a
minimum system requirement and recommended deployment.The constraints
corresponding to the interactions between the components are described in the
following.  (i) Components HDFS.DataNode and Spark.Worker must the deployed on
the same VM (_Co-location_). In this scenario, we also collocated
Yarn.NodeManager because we used Yarn as a scheduler for Spark jobs.  (ii)
Components Kafka and Zookeeper, HDFS.NameNode and HDFS.SecondaryNameNode,
YARN.ResourceManagement and HDFS.NameNode, HDFS.SecondaryNameNode,
YARN.HistoryService are, respectively, in _conflict_ , that is, they must not
be placed on the same VM.  (iii) Components HDFS.DataNode, YARN.NodeManager
and Spark.Worker must be deployed on all VMs except those hosting conflicting
components (_Full Deployment_).  (iv) In our deployment, we consider that for
one instance of Kafka there must be deployed exactly 2 instances of Zookeeper
(_Require-Provide_ constraint). There can be situations, however, when more
Zookeeper instances are deployed for higher resilience.  (v) A single instance
of YARN.HistoryService, respectively Spark.HistoryService should be deployed
(_Deployment with bounded number of instances_ constraint, in particular
_equal bound_).

###  V-D Boreas Paper Tests

The Boreas Paper Tests is a collection of the four tests from [12, Chapter 4]
and were focused on evaluating the impact of the Boreas scheduler on
Kubernetes’ deployment performance, specifically examining the differences in
pod placement compared to the default scheduler. In this paper, we want to
check the behavior of SAGE on these benchmarks. For the lack of space, we
consider only _Test D: free node with deployment constraints_ (see Table I).

Pod | Replicas | Constraints
---|---|---
Asperitas | 3 | Anti-affinity to itself
Cirrus | 2 |
Cumulus | 3 | Anti-affinity to itself, affinity to Asperitas
Nimbus | 2 | Anti-affinity to itself and Asperitas
Stratus | 4 | Anti-affinity to itself
TABLE I: Specification of Test D: free node with deployment constraints

###  V-E Batch Analysis Test

The goal of this scenario, motivated by the analysis of Secure Web Container
(see Section VI-B), is to assess the ability of each scheduler to analyze
requirements of other components in the same batch (same K8s API request), in
particular, it evaluates if the scheduler can anticipate the resource needs of
upcoming components that are simultaneously submitted to the K8s API. We have
three components: two components with a CPU request of 500m each, and one
component with a CPU request of 1000m. The objective of this test is to reveal
that, if the first two pods are not placed on the same node, the third pod
cannot be deployed. To accomplish this, we ensure that the scenario runs on
two nodes, both with 2vCPU. Neither memory considerations nor constraints
between components are relevant in this specific scenario.

###  V-F Node Analysis Test

This test consists of three components and assesses the scheduler’s ability to
choose the optimal node for a pod, considering the requirements of other pods
in the same K8s API batch. The inspiration behind this test is also the result
from Section VI-B where the scheduler was not able to better match the pod’s
requirements with nodes specification. This scenario involves two pods of 500m
CPU and one of 2900m CPU. No constraints are present between the pods. By
allocating two nodes (of 2vCPU and 4vCPU), one capable of supporting the third
component and another that cannot, we evaluate the scheduler’s effectiveness
in node selection based on resource availability since a placement mistake of
any of the first two nodes will result in a failure for the third one.

##  VI Experimental Analysis

The main objective of this study is to analyze how pods are placed during the
initial deployment phase using three different approaches: SAGE, K8s, and
Boreas. To perform the analysis, we followed a specific _methodology_. We used
SageOpt to obtain the optimal deployment of the application. The precise
solution provided by SAGEOpt is used to create the manifest files for
deployment using SAGE: pod affinity, anti-affinity and anti-affinity with
itself, as well as node affinity. Notably, when dealing with K8s and Boreas
manifest files, we utilized the same information for both, with one exception:
the node affinity information, because the task at hand is to observe their
ability to locate suitable nodes.

To create a hardware context for the study, we deployed nodes that were
identified as the most optimal by SageOpt. This was done to evaluate the
performance of the schedulers in finding the best solution. We utilized the
Digital Ocean offers to provide a pool of available resources from which
SageOpt could choose. It is worth mentioning that the Kubernetes cluster
default processes use a part of the resources available on the pod.

The case studies considered allow us to examine how the schedulers perform
during the initial deployment phase by analyzing pod placements based on the
chosen hardware context.

In terms of _metrics_ , our focus was primarily on the placement of pods on
nodes. Specifically, we evaluated whether each scheduler is capable of
identifying the most optimal solution based on the recommended hardware
provided by SAGEOpt. Additionally, we will assess the resilience of the
solutions generated by each scheduler.

It is important to note that we will not consider scheduling time as a metric
in this study. Our main objective is to identify a scheduler that minimizes
deployment costs rather than prioritizing scheduling speed. Therefore, our
evaluation will primarily revolve around the effectiveness and cost efficiency
of the scheduler’s decision-making processes, rather than the time taken for
scheduling.

###  VI-A Analysis: Secure Billing Email Service

In this section, we look at the node placements obtained after running all
three solutions in the context described in Section V-A. In Tables II and III
we can observe that they are able to find a suitable solution, in particular
SAGE and Boreas came up with the same pods placement. This scenario can be
used as a validation that all three are set up correctly and are working
properly.

Pod Node | 8vcpu-16gb | s-8vcpu-16gb | s-8vcpu-16gb
---|---|---|---
Coding Service | 1 |  |
Security Manager |  | 1 |
Gateway |  |  | 1
SQLServer |  |  | 1
LoadBalancer |  | 1 |
TABLE II: K8s solution for Secure Billing Email Service Pod Node | 8vcpu-16gb | s-8vcpu-16gb | s-8vcpu-16gb
---|---|---|---
Coding Service | 1 |  |
Security Manager |  |  | 1
Gateway |  | 1 |
SQLServer |  | 1 |
LoadBalancer |  |  | 1
TABLE III: SAGE and Boreas solutions for Secure Billing Email Service

###  VI-B Analysis: Secure Web Container

This section considers the pod’s placements (see Tables IV and V) in the
context of Secure Web Container from Section V-B. One could observe that SAGE
and Boreas are able to obtain (the same) optimal solution, while K8s fails.
Specifically, the issue arises with the deployment of the IDSServer pod as K8s
fails to properly assign a feasible node for it, likely due to the Balancer
replica not being placed correctly. Since it requires only 1000m CPU, it could
be accommodated on a 2vCPU node, however, it is, instead, placed on a 4vCPU
node, leaving the IDSServer without a suitable node for deployment. This
behavior can be explained based on the features of K8s scheduler as described
in Section III-B. More precisely, this issue could arise because K8s only
analyzes the current pod it needs to deploy and does not consider the future
requirements of other pods. Additionally, this can be caused due to the fact
that it analyzes only up to 50% of the total number of nodes if a suitable
solution is found. This limited scope of analysis could lead to suboptimal pod
placement decisions and potentially result in an increase in resource costs.

Pod Node | 2vcpu-4gb | 4vcpu-32gb | 4vcpu-8gb | 4vcpu-8gb | 4vcpu-8gb
---|---|---|---|---|---
Balancer |  | 1 |  |  |
Apache |  |  | 1 |  | 1
Ngnix |  |  |  | 1 |
IDSServer |  |  |  |  |
IDSAgent |  |  | 1 | 1 | 1

TABLE IV: K8s solution for Secure Web Container

Pod Node | 2vcpu-4gb | 4vcpu-32gb | 4vcpu-8gb | 4vcpu-8gb | 4vcpu-8gb
---|---|---|---|---|---
Balancer | 1 |  |  |  |
Apache |  |  | 1 |  | 1
Ngnix |  |  |  | 1 |
IDSServer |  | 1 |  |  |
IDSAgent |  |  | 1 | 1 | 1

TABLE V: SAGE and Boreas solutions for Secure Web Container

###  VI-C Analysis: Oryx2

This section examines the specific scenario described in Section V-C. From
Table VI, one could observe that Boreas scheduler encounters difficulties when
deploying the third replica of the Yarn.NodeManager pod (denoted by X on
column s-8vcpu-16gb). This issue arises because both instances of the
Zookeeper component are placed on the same node, leaving insufficient
resources for the Yarn.NodeManager pod. This is because Boreas scheduler uses
as few as possible nodes when all other placement requirements are fulfilled
[12]. In contrast, K8s (see Table VII) and SAGE (see Table VIII) are able to
find solutions in this case due to their default constraint of resiliency,
which involves placing replicas of the same pod on different nodes whenever
possible. Boreas scheduler could address this problem by introducing pod anti-
affinity to itself for Zookeeper pod, preventing multiple instances from being
placed on the same node. Since it is not specified in the Boreas paper [10]
when one should or should not use the pod anti-affinity to itself, this paper
does not use it by default for benchmarking the Boreas scheduler.

Pod Node | s-8vcpu-16gb | s-8vcpu-16gb | s-8vcpu-16gb
---|---|---|---
Kafka |  |  | 1
Zookeeper | 2 |  |
HDFS.NameN |  |  | 1
HDFS.2NameN | 1 |  |
HDFS.DataN | 1 | 1 | 1
YARN.ResMng |  | 1 |
Yarn.HistServ | 1 |  | 1
Yarn.NodeMng | 1 | 1 | X
Spark.Worker | 1 | 1 | 1
Spark.HistServ |  |  | 1
TABLE VI: Boreas solution for Oryx2 Pod Node | s-8vcpu-16gb | s-8vcpu-16gb | s-8vcpu-16gb
---|---|---|---
Kafka |  | 1 |
Zookkeper | 1 |  | 1
HDFS.NameN |  |  | 1
HDFS.2NameN |  | 1 |
HDFS.DataN | 1 | 1 | 1
YARN.ResMng | 1 |  |
Yarn.HistServ |  |  | 1
Yarn.NodeMng | 1 | 1 | 1
Spark.Worker | 1 | 1 | 1
Spark.HistServ | 1 |  |
TABLE VII: K8s solution for Oryx2 Pod Node | s-8vcpu-16gb | s-8vcpu-16gb | s-8vcpu-16gb
---|---|---|---
Kafka |  |  | 1
Zookeeper | 1 |  | 1
HDFS.NameN |  |  | 1
HDFS.2NameN | 1 |  |
HDFS.DataN | 1 | 1 | 1
YARN.ResMng |  | 1 |
Yarn.HistServ |  |  | 1
Yarn.NodeMng | 1 | 1 | 1
Spark.Worker | 1 | 1 | 1
Spark.HistServ |  | 1 |
TABLE VIII: SAGE solution for Oryx2

###  VI-D Analysis: Boreas tests

For the test in Section V-D, all three schedulers find a deployment (see
Tables IX-X). Note that the test was not performed on the hardware specified
in [12], which uses their entire cluster of six nodes with the same
configuration, but on the hardware that SAGEOpt deems optimal for the
application from Digital Ocean infrastructure that we use in our experiments.

Pod Node | 2vcpu-4gb | 2vcpu-4gb | 2vcpu-4gb | 4vcpu-8gb | 4vcpu-8gb
---|---|---|---|---|---
asperitas | 1 |  |  | 1 | 1
cirrus |  |  |  | 1 | 1
cumulus | 1 |  |  | 1 | 1
nimbus |  | 1 | 1 |  |
stratus |  | 1 | 1 | 1 | 1
TABLE IX: K8s solution for Boreas Test D Pod Node | 2vcpu-4gb | 2vcpu-4gb | 2vcpu-4gb | 4vcpu-8gb | 4vcpu-8gb
---|---|---|---|---|---
asperitas |  |  | 1 | 1 | 1
cirrus | 1 |  |  | 1 |
cumulus |  |  | 1 | 1 | 1
nimbus | 1 | 1 |  |  |
stratus | 1 | 1 |  | 1 | 1
TABLE X: SAGE and Boreas solution for SAGE Test D

###  VI-E Analysis: Batch Test

This section presents the results of running the three schedulers in the
context described in Section V-E. The objective of this test is to evaluate
the ability of the schedulers to analyze all components within the same batch.
Specifically, we assess if the schedulers can identify that the third
component requires a dedicated node while the first two components should be
placed on the same node. The findings, shown in Table XI, reveal that the K8s
scheduler fails to deploy the third component as it mistakenly assigns the
first two components to different nodes, resulting in resource starvation for
the third component. This is likely due to the K8s scheduler’s limited batch
analysis, which prioritizes node scoring based on available resources during
the node scoring phase (see Section III-B). Boreas also fails to deploy the
third pod (see Table XI without a specific explanation identified especially
in the light that according to the documentation, Boreas seeks to minimize the
number of nodes if all constraints are satisfied, hence the first two pods
should have been placed on the same node. SAGE managed to deploy all pods (see
Table XI).

Pod Node | 2vcpu | 2vcpu
---|---|---
P1 | 1 |
P2 |  | 1
P3 |  |

Pod Node | 2vcpu | 2vcpu
---|---|---
P1 |  | 1
P2 |  | 1
P3 | 1 |

TABLE XI: K8s, Boreas (left) and SAGE (right) solution for Batch Test

###  VI-F Analysis: Node Test

This section focuses on the results obtained from conducting the test
described in Section V-F. The objective of the test is to determine if the
scheduler can effectively match pods with the most suitable node type.
Specifically, we aim to verify if the first two pods can be placed on the
2vcpu node and the third pod on the 4vcpu node, as any deviation would result
in resource starvation for the third pod. Reviewing Tables XII-, we observe
that SAGE successfully finds the optimal solution. However, both Boreas and
K8s fail to do so, placing the first and second pods on the 4vcpu node. The
K8s failure can be attributed to its default behavior of analyzing a maximum
of 50% of the available nodes for performance optimization purposes
777https://kubernetes.io/docs/concepts/scheduling-eviction/scheduler-perf-
tuning/. Regarding Boreas, the precise cause of the failure remains unclear,
but similar to the previous example, it appears to choose the node with the
most available resources for pod placement.

Pod Node | 2vcpu-2gb | 4vcpu-8gb
---|---|---
P1 |  | 1
P2 |  | 1
P3 |  |

Pod Node | 2vcpu-2gb | 4vcpu-8gb
---|---|---
P1 | 1 |
P2 |  | 1
P3 |  |

TABLE XII: K8s (left) and Boreas (right) solution for Node Test Pod Node | 2vcpu-2gb | 4vcpu-8gb
---|---|---
P1 | 1 |
P2 | 1 |
P3 |  | 1
TABLE XIII: SAGE solution for Node Test

##  VII Conclusion and Future Work

This study has established reliable benchmarks for infrastructure solutions
and demonstrated the effectiveness of the SAGE. Through its comprehensive
analysis, it consistently identifies optimal solutions, leading to improved
scheduling efficiency and resource allocation.

To further advance this field we will develop a custom Kubernetes scheduler
based on the SAGE approach which would handle the dynamic modification of the
deployment to support peaks in user requests. Moreover, we will tackle more
real-life cases. These efforts will provide practical validation of the SAGE
scheduler’s performance and contribute to ongoing enhancements of scheduling
algorithms for better cluster management.

## References

  * [1] Kubernetes Open-Source Platform.  https://kubernetes.io/.  Accessed: 2013-05-29.
  * [2] E. Ábrahám, F. Corzilius, E. B. Johnsen, G. Kremer, and J. Mauro.  Zephyrus2: On the Fly Deployment Optimization Using SMT and CP Technologies.  In Dependable Software Engineering: Theories, Tools, and Applications - Second International Symposium, SETTA 2016, Beijing, China, November 9-11, 2016, Proceedings, pages 229–245, 2016.
  * [3] A. Balalaie, A. Heydarnoori, and P. Jamshidi.  Microservices architecture enables devops: Migration to a cloud-native architecture.  Ieee Software, 33(3):42–52, 2016.
  * [4] B. Burns, J. Beda, and K. Hightower, editors.  Kubernetes: Up and Running Dive into the Future of Infrastructure.  O’Reilly, 2019.
  * [5] V. Casola, A. D. Benedictis, M. Erascu, J. Modic, and M. Rak.  Automatically Enforcing Security SLAs in the Cloud.  IEEE Trans. Services Computing, 10(5):741–755, 2017.
  * [6] S. de Gouw, J. Mauro, and G. Zavattaro.  On the Modeling of Optimal and Automatized Cloud Application Deployment.  Journal of Logical and Algebraic Methods in Programming, 107:108–135, 2019.
  * [7] M. Eraşcu, F. Micota, and D. Zaharie.  Scalable optimal deployment in the cloud of component-based applications using optimization modulo theory, mathematical programming and symmetry breaking.  Journal of Logical and Algebraic Methods in Programming, 121:100664, 2021.
  * [8] I. Gog, M. Schwarzkopf, A. Gleave, R. N. Watson, and S. Hand.  Firmament: Fast, centralized cluster scheduling at scale.  In 12th USENIX Symposium on Operating Systems Design and Implementation (OSDI 16), pages 99–115, 2016.
  * [9] Y. Han, S. Shen, X. Wang, S. Wang, and V. C. Leung.  Tailored Learning-based Scheduling for Kubernetes-oriented Edge-Cloud system.  In IEEE INFOCOM 2021-IEEE Conference on Computer Communications, pages 1–10. IEEE, 2021.
  * [10] T. Lebesbye, J. Mauro, G. Turin, and I. Yu.  Boreas – A Service Scheduler for Optimal Kubernetes Deployment, pages 221–237.  11 2021.
  * [11] T. Lebesbye, J. Mauro, G. Turin, and I. C. Yu.  Boreas–a service scheduler for optimal kubernetes deployment.  In Service-Oriented Computing: 19th International Conference, ICSOC 2021, Virtual Event, November 22–25, 2021, Proceedings 19, pages 221–237. Springer, 2021.
  * [12] T. L. Lebesbye.  Boreas – reducing resource usage through optimized kubernetes scheduling.  Master’s thesis, Department of Informatics, Faculty of Mathematics and Natural Sciences, University of Oslo, 2019.
  * [13] Y. Yang and L. Chen.  Design of Kubernetes Scheduling Strategy Based on LSTM and Grey Model.  In 2019 IEEE 14th International Conference on Intelligent Systems and Knowledge Engineering (ISKE), pages 701–707, 2019.


1Corresponding author: Murat Isik<EMAIL_ADDRESS>
# Advancing Neuromorphic Computing: Mixed-Signal Design Techniques Leveraging
Brain Code Units and Fundamental Code Units

Murat Isik1  Stanford University
Stanford, CA
Email<EMAIL_ADDRESS>
1Corresponding author Sols Miziev  ni2o, Inc
Providence, RI
<EMAIL_ADDRESS>Wiktoria Pawlak  Newton Howard  ni2o, Inc
Providence, RI
<EMAIL_ADDRESS>University of Oxford
Oxford, UK
<EMAIL_ADDRESS>
###### Abstract

This paper introduces a groundbreaking digital neuromorphic architecture that
innovatively integrates Brain Code Unit (BCU) and Fundamental Code Unit (FCU)
using mixed-signal design methodologies. Leveraging open-source datasets and
the latest advances in materials science, our research focuses on enhancing
the computational efficiency, accuracy, and adaptability of neuromorphic
systems. The core of our approach lies in harmonizing the precision and
scalability of digital systems with the robustness and energy efficiency of
analog processing. Through experimentation, we demonstrate the effectiveness
of our system across various metrics. The BCU achieved an accuracy of 88.0%
and a power efficiency of 20.0 GOP/s/W, while the FCU recorded an accuracy of
86.5% and a power efficiency of 18.5 GOP/s/W. Our mixed-signal design approach
significantly improved latency and throughput, achieving a latency as low as
0.75 ms and throughput up to 213 TOP/s. These results firmly establish the
potential of our architecture in neuromorphic computing, providing a solid
foundation for future developments in this domain. Our study underscores the
feasibility of mixed-signal neuromorphic systems and their promise in
advancing the field, particularly in applications requiring high efficiency
and adaptability.

###### Index Terms:

Neuromorphic Computing, Mixed-Signal Design, Brain Code Unit, Fundamental Code
Unit.

##  I Introduction

Neuromorphic computing, a paradigm inspired by the neural structures and
computational processes of the human brain, has seen considerable evolution
since its inception. Tracing its origins to Hebb’s concept of synaptic
plasticity as a mechanism for learning and memory, it forms the foundation of
modern neuromorphic computing [1]. The term ”neuromorphic computing” was
coined by Carver Mead in the late 1980s, marking a significant departure from
traditional von Neumann architecture and leading to the development of the
first neural-inspired chips like artificial retinas and cochleas using analog
VLSI circuits [2, 3].

In recent years, neuromorphic computing has expanded to include various
implementations in software and hardware, including digital, analog, and
mixed-signal circuits. This expansion is propelled by substantial research
initiatives, such as the DARPA SyNAPSE program, fostering advancements in
memristors, silicon neurons, and synapse models. Key developments in
neuromorphic architectures include IBM’s TrueNorth and Intel’s Loihi,
showcasing principles of plasticity and learning [4, 5, 6, 7, 8, 9].
Additionally, there is a growing exploration of optical ”memristors” as
potential key components for developing high-bandwidth and efficient
neuromorphic machine learning hardware, which represents a recent and
significant advancement in the field [10, 11, 12].

###  I-A Advantages of Neuromorphic Computing

Neuromorphic systems excel in parallel processing, event-driven computation,
and exhibit synaptic plasticity mechanisms like spike-timing-dependent
plasticity (STDP), enhancing pattern recognition and sensory data processing.
These systems are scalable and incorporate elements of stochasticity,
reflecting the probabilistic nature of biological neural networks [13, 14, 15,
16, 17, 18, 19, 9].

Brain Code Unit (BCU) and Fundamental Code Unit (FCU) are neuromorphic core of
our proposed neuromorphic computing implementation. BCU is designed to mimic
the brain’s ability to encode and process information, while FCU serve as the
fundamental building blocks for these operations. Together, they form the
basis of neuromorphic systems, enabling them to replicate complex neural
processes. Understanding these units is crucial for advancing neuromorphic
computing and utilizing its full potential [20].

Figure 1: Differential Encoding of Abstract Mathematical Rules in Human. This
figure illustrates the contrast between dynamic coding in the parahippocampal
cortex and static coding in the hippocampus. The top panel depicts the
sequence of abstract operations over time, linked to distinct neural
activities. On the bottom left, dynamic coding is visualized as shifting
activity patterns corresponding to different abstract rules. Conversely, the
bottom right heatmap demonstrates static coding with consistent activation
regions irrespective of changes in abstract rules. This indicates a division
of labor within the human medial temporal lobe in the processing of abstract
information, with implications for understanding the neural basis of high-
level cognition.

Mixed-signal design, which involves the integration of both analog and digital
circuitry, plays a crucial role in the advancement of neuromorphic systems.
This approach leverages the precision and flexibility of digital systems along
with the robustness and energy efficiency of analog systems. Mixed-signal
design holds the potential to significantly enhance the performance of
neuromorphic computing architectures, particularly in terms of scalability,
power efficiency, and the ability to handle a wide range of computational
tasks.

##  II Background

The landscape of neuromorphic computing is diverse, encompassing both digital
and analog architectures. Digital neuromorphic systems, known for their
precision and programmability, have been extensively explored and applied in
various computational tasks. They simulate neural processes using discrete
digital signals, offering a high degree of control and reproducibility. On the
other hand, analog neuromorphic architectures attempt to more closely mimic
the analog nature of biological neural networks. These systems are
characterized by their energy efficiency and real-time processing
capabilities, making them particularly suited for tasks that require natural,
continuous data processing [21, 22, 23, 24].

###  II-A Brain Code Unit (BCU) and Fundamental Code Unit (FCU)

The development of Brain Code Unit (BCU) and Fundamental Code Unit (FCU)
proposed by Newton Howard and Amir Hussain represents a significant
advancement in neuromorphic computing aiming to provide a better modeling of
the brain’s computational processes and enabling the design of more efficient
and effective neuromorphic systems. BCU focus on modeling complex decision-
making processes, while FCU aim to quantify intelligent thought processes at
various analytical levels from the linguistic and behavioral output to the
chemical and physical processes within the brain, contributing to a more
detailed understanding and simulation of brain functionality.

###  II-B Mixed-Signal Design in Neuromorphic Systems

Mixed-signal design, crucial in neuromorphic computing, integrates analog and
digital circuitry. It combines digital systems’ flexibility with the
robustness and energy efficiency of analog processing. BCU and FCU benefit
from this approach through reduced latency, increased computational speed, and
enhanced system robustness and adaptability [25, 26, 27, 28].

Figure 2: Overview of Brain-like Computing Paradigm.

Figure 2 illustrates the hierarchy of components in brain-like computing,
starting with foundational concepts at the neuron model level and peaking in
practical applications. It outlines the progression from neuron models and
spiking neural networks, through platforms designed to mimic brain functions,
to specific applications in various fields such as medical, space, and
military. The diagram also highlights the challenges faced in the development
of these technologies, including hardware limitations and the complexity of
brain learning mechanisms and algorithms. Prospects for future development are
indicated, suggesting areas for further research and potential breakthroughs.

##  III Proposed Design Methodology

Figure 3: Integration of Fundamental Code Unit (FCU) and Brain Code Unit (BCU)
in Neuromorphic Systems.

Figure 3 illustrates the intricate interplay between linguistic and
axiological structures, neurotransmitter chirality, and neuron network
structures. It details how these elements influence neuronal activity and are
represented in various modalities such as image, audio, and neuroscience
expressions. The diagram shows the incorporation of neuromorphic hardware and
inference mechanisms to process and analyze these representations. The FCU and
BCU are depicted as foundational elements, operating at different cognitive
levels and interfacing with read and write modalities. The neuroscientific
methodologies, including fMRI, TMS, and DBS, are mapped to specific aspects of
the FCU and BCU, highlighting their roles in understanding and addressing
neural disorders. The figure underscores the comprehensive approach of
neuromorphic systems in capturing, processing, and utilizing complex neural
information for advanced computing and medical applications.

###  III-A Integration Techniques for BCUs and FCUs

A key aspect of our methodology is the integration of BCUs and FCUs into the
digital architecture. This section will describe the techniques used to embed
these units into the neuromorphic system. It will detail how BCU and FCU
interact within the architecture, their role in data processing and neural
emulation, and the methods used to optimize their efficiency and
effectiveness. In our exploration of mixed-signal neuromorphic systems using
BCU and FCU, we have identified several relevant open-source datasets. For
BCU, we focus on datasets that provide insights into neural activity and brain
signaling processes. BrainMRI dataset offers valuable information on brain
activity patterns which are crucial for simulating brain-like information
processing. These datasets are integral to our methodology, allowing us to
rigorously evaluate the performance and efficiency of our proposed
neuromorphic architecture across various computational tasks.

###  III-B Brain Code Unit (BCU)

We delineate the construction of a BCU leveraging spiking neural network (SNN)
paradigms for the classification of Magnetic Resonance Imaging (MRI) scans of
the brain. The proposed BCU is architected to harness the computational
prowess of CUDA-enabled Graphical Processing Units (GPUs) to expedite parallel
processing, thereby augmenting efficiency.

###  III-C Data Handling

The BrainMRI dataset class is a signfy subclass of the dataset module within
PyTorch, tailored for the management of brain MRI datasets. It amasses file
paths and their associated binary labels, representing the presence or absence
of tumors, and facilitates index-based retrieval of individual data points.

###  III-D Preprocessing

We define a suite of transformations to standardize the images, employing the
transforms module in PyTorch. This preprocessing pipeline includes resizing
images to uniform dimensions, tensor conversion, and pixel value
normalization, crucial for optimizing the learning efficacy of the network.
The dataset is bifurcated into training and testing partitions, and data
loaders are instantiated to administer batch-wise data handling and shuffling
during the training phase. The neural composition of the BCU is encapsulated
within the SNN class, which comprises a convolutional layer succeeded by a
custom LIFNeuron layer. The LIFNeuron simulates the Leaky Integrate-and-Fire
neuron, a quintessential component of biological neural networks, to mimic the
temporal dynamics intrinsic to spiking neurons. The training regimen iterates
across designated epochs, within which the model parameters are refined via
the Adam optimization algorithm, paired with a cross-entropy loss function to
assess performance. Post each epoch, the model’s predictive accuracy on the
training and testing datasets is evaluated in a non-gradient update mode
(inference mode) to monitor and gauge learning progression. Upon the peak of
training, the model parameters are preserved to the storage medium,
facilitating subsequent retrieval for analysis or deployment in predictive
tasks. The model summarizes the core logic of the BCU, explaining the synergy
between computational models and neural dynamics.

##  IV Development of a Fundamental Code Unit for Arithmetic Logic Operations

This manuscript details the construction of FCU that is architected to perform
arithmetic logic operations within the framework of SNNs, leveraging the
computational efficiency of CUDA-enabled GPUs.

###  IV-A Data Acquisition and Preprocessing

The CIFAR-10 dataset, comprising a rich repository of labeled imagery, serves
as the training and testing ground for the FCU. The dataset undergoes a
normalization process, crucial for enhancing the convergence rate during the
learning process. The LIFNeuron module, integral to the FCU, encapsulates the
dynamics of a Leaky Integrate-and-Fire (LIF) neuron. It simulates the bio-
physiological processes of neuronal spike generation and membrane potential
resetting, which are pivotal for the temporal dynamics of spiking neurons. The
FCU is instantiated as an SNN, incorporating convolutional layers for feature
extraction from input images, followed by Leaky Integrate-and-Fire neurons to
introduce temporal dynamics. The output is subsequently flattened and
processed through a linear layer for classification. A training loop is
devised to fine-tune the FCU across several epochs, employing backpropagation
with the Adam optimizer and a cross-entropy loss criterion. The FCU’s
performance is periodically evaluated on both training and testing sets to
monitor the progression of learning accuracy. Upon the completion of the
training epochs, the FCU state is conserved onto the disk, enabling future
retrieval for inferential applications or further refinement. The model
encapsulates the quintessence of the FCU, showcasing the interplay between
neural dynamics and computational efficiency for the execution of arithmetic
logic operations.

###  IV-B Description of the Digital Neuromorphic Architecture

Our methodology begins with a detailed description of the proposed digital
neuromorphic architecture. This includes an outline of its structural design,
computational models, and the processes it emulates. The architecture’s core
components, data processing pathways, and neural network emulation techniques
are discussed to provide a comprehensive understanding of the system’s
functionality. We have successfully deployed the architectures of the FCU and
BCU on GPUs using the Python programming environment. A normalization process
was applied, focusing on accuracy metrics, to ensure the robustness of the
computational model. Subsequently, the research progressed towards the realm
of digital design. In this phase, we have harnessed the capabilities of
Verilog hardware description language to execute preliminary simulations of
the FCU and BCU designs on an XCZU7EV FPGA Chip, housed within the ZCU-104
evaluation board. These designs were verified on testbench within same
datasets. The scalability of our architecture was evaluated by varying the
size and complexity of the neural networks it emulated, thereby demonstrating
its adaptability to diverse computational tasks. Furthermore, we have
conducted a comparative analysis with extant neuromorphic architectures,
underscoring the distinctive features and benefits of our approach. Despite
encountering certain limitations and challenges, which we transparently
discuss, we have outlined strategies to explain these obstacles in future
iterations of our design.

###  IV-C Mixed-Signal Design Approach and Materials Used

The final part of the methodology focuses on the mixed-signal design approach.
This involves integrating analog and digital components to enhance the
system’s performance. The section will elaborate on the selection of materials
and components, the rationale behind their choice, and how they contribute to
the overall functionality of the neuromorphic system. Particular attention
will be given to the design choices that enable the system to efficiently
process complex neural computations. The intricacies of integrating analog and
digital domains are addressed through a mixed-signal design methodology. In
this approach, the pivotal connection between the analog and digital
components is facilitated via an analog-to-digital converter (ADC) and a
digital-to-analog converter (DAC). These converters interface with the
system’s logic through a Serial Peripheral Interface (SPI), a protocol
selected for its robustness and high-speed data transfer capabilities. The ADC
component is crucial in translating continuous analog signals, such as those
emanating from environmental sensors, into a discretized digital
representation. This digital form is flexible to processing by the subsequent
digital logic circuits coded in Verilog. Our design leverages the ADC’s
precision to ensure reliability in capturing the nuances of the analog input.

Conversely, the DAC serves as a bridge in the opposite direction. It takes
digital signals, which are the outcomes of VHDL logic computations, and
transforms them into analog signals. These analog outputs can then drive
actuators, enabling the system to interact with its physical surroundings. The
DAC’s accuracy is paramount in ensuring that the digital decisions are
accurately reflected in the real world.

To implement this mixed-signal approach, we selected high-quality components
that are compatible with the board’s specifications. The choice of materials
was informed by a series of criteria, including signal integrity, conversion
rate, resolution, and power consumption. The SPI interface pins on the board
were meticulously defined to align with the electrical characteristics and
timing requirements of the ADC and DAC. Additionally, the design incorporates
protective circuitry to guard against common pitfalls in mixed-signal
environments, such as noise coupling and signal interference. By adopting a
mixed-signal design, we integrate the analog richness of natural signals with
the computational power of digital systems, thus broadening the applicability
of our neuromorphic architecture to interact with a wide range of sensors and
actuators in a diverse array of environments.

###  IV-D Chip Layout with RTL to GDSII Flow

The process of transforming high-level architectural descriptions of the FCU
and BCU into a manufacturable chip layout has been meticulously executed via a
Register-Transfer Level (RTL) to Graphic Data System II (GDSII) flow.
Utilizing OpenLane, an automated RTL to GDSII flow suite that is designed to
produce high-quality layouts, we were able to translate our Verilog code into
a physical form factor compatible with silicon fabrication norms. OpenLane
arranges the intricate progression from Verilog code to a physical layout by
automating the various steps involved in the process. This synthesis, where
the Verilog code is converted into a gate-level netlist using logic gates and
other standard cells. Following this, floorplanning establishes the chip’s
initial spatial configuration, defining the location of logic blocks and
ensuring optimal area utilization and power distribution. The subsequent phase
of placement optimizes the positioning of the standard cells within the
floorplan’s constraints, aiming to minimize delays and signal integrity
issues. This is followed by routing, where electrical connections between the
components are made, taking into account the intricate web of design rules and
constraints. Throughout this progression, OpenLane employs rigorous design
rule checks (DRC) and layout versus schematic (LVS) checks to ensure that the
resulting layout is free from violations and accurately reflects the original
schematic. This verification is crucial, as it guarantees the
manufacturability of the design and its functionality post-fabrication.
Additionally, parasitic extraction is performed to model the unwanted
resistive, capacitive, and inductive effects that arise from the physical
layout. These are significantly influence the chip’s performance, and their
early consideration is vital for high-frequency applications typical of
neuromorphic computing architectures. Once the GDSII file is generated,
signifying the completion of the RTL to GDSII flow, it can be sent to a
foundry for fabrication. The GDSII file contains all the geometric shapes,
layer information, and design required to manufacture the physical integrated
circuit. This process is evidence of the synergy between computational logic
design and physical implementation, bridging the gap between neuromorphic
concepts and tangible, real-world applications. By leveraging OpenLane’s
capabilities, we have ensured that the FCU and BCU are not only theoretically
sound but are also poised for successful integration into hardware platforms.

Figure 4: Block Diagram of Implementation

Figure 4 presents a detailed depiction of a neuromorphic system’s
architecture, focusing on the integration of neural signal processing with
digital computing. Central to this illustration is an FPGA chip, signifying
its crucial role in neural data interpretation. The figure encompasses several
key components: the interface between the FPGA chip and neurons via an
electrode array, suggesting a direct connection for signal acquisition; sensor
systems for raw neural signal capture; and a sophisticated combination of ADC,
DSP, and TX modules for signal conversion, processing, and transmission. This
ensemble of components facilitates the recording and analysis of neural spike
waveforms, a fundamental aspect of neural communication. Additionally, the
preprocessor and design decoder elements indicate advanced stages of signal
conditioning and interpretation, translating neural activities into actionable
data. Collectively, the figure exemplifies the fusion of biological neural
signals with state-of-the-art digital processing, illustrating a holistic
approach to harnessing neural information for computational and
neuroscientific advancements.

##  V Evaluation

This section presents the findings from the experiments conducted using the
neuromorphic system. It includes a detailed analysis of the system’s
performance based on the open-source datasets. The results are quantified in
terms of accuracy, processing speed, power efficiency, and other relevant
metrics. The final part of the experimental setup defines the criteria used to
evaluate the performance of the neuromorphic system. This involves outlining
the benchmarks and metrics used to assess the system’s accuracy, efficiency,
and overall effectiveness. The criteria reflects the objectives of the
research, ensuring that the system’s performance is evaluated in a
comprehensive and objective manner.

TABLE I: Resource Utilization Summary for BCU and FCU Implementations Zynq
UltraScale+ XCZU7EV
---
Resource | BCU Utilization | % Utilization (BCU) | FCU Utilization | % Utilization (FCU) | Available
LUT | 151,200 | 30 | 140,000 | 27.78 | 504,000
Memory | 11.4MB | 30 | 10.5MB | 27.63 | 38MB
IO | 139 | 29.19 | 130 | 28.02 | 464
DSP | 518 | 29.94 | 480 | 27.78 | 1,728

Table I presents a comprehensive summary of resource utilization for both the
BCU and FCU implementations. This summary was compiled using the Zynq
UltraScale+ XCZU7EV platform as the benchmark. The table delineates the
specific resources utilized, including Look-Up Tables (LUTs), Memory,
Input/Output (IO) interfaces, and Digital Signal Processors (DSPs). For each
resource, we provide a dual comparison: one for the BCU and another for the
FCU.

The utilization figures are presented in absolute terms and as a percentage of
the total available resources on the platform. This dual presentation allows
for an immediate grasp of the scale and efficiency of the resource usage.
Specifically, the LUT utilization shows a consumption of 151,200 units for the
BCU and 140,000 units for the FCU, translating to 30% and 27.78% of the total
available LUTs, respectively. Similarly, memory usage is detailed with the BCU
utilizing 11.4MB and the FCU utilizing 10.5MB, equating to 30% and 27.63% of
the total available memory. The IO resource shows a utilization of 139 and 130
for the BCU and FCU, corresponding to 29.19% and 28.02% of the total IOs
available. Lastly, DSP resource usage is listed as 518 for the BCU and 480 for
the FCU, amounting to 29.94% and 27.78% of the total DSPs, respectively.

TABLE II: Comparative Analysis of FCU and BCU Based on Performance Metrics.

Performance Metrics | FCU | BCU
---|---|---
Accuracy (%) | 86.5 | 88.0
MAC (GOP) | 1.2 | 1.35
Latency [ms] | 15 | 12
Power Efficiency | 18.5 GOP/s/W | 20.0 GOP/s/W

  * •

*Accuracy is measured as a percentage of correct predictions.

  * •

*MAC (GOP) refers to the number of Multiply-Accumulate operations in Giga Operations.

  * •

*Latency is measured in milliseconds and indicates the response time of the system.

  * •

*Power Efficiency is assessed in terms of energy efficiency during operations.

Table II shows into a detailed comparative analysis between the FCU and BCU
based on several critical performance metrics. This comparison elucidates the
operational differences and relative strengths of each unit within our
framework. Firstly, we observe that the BCU demonstrates a slightly higher
accuracy (88.0%) compared to the FCU (86.5%). This margin, although narrow,
highlights the BCU’s enhanced capability in correctly interpreting and
processing the data it receives. The increased accuracy of the BCU can be
attributed to its more sophisticated algorithmic structure which is inspired
by the intricate workings of the human brain. Moving on to the MAC (Multiply-
Accumulate) operations, the BCU registers 1.35 Giga Operations, a slight
elevation over the FCU’s 1.2 GOP. This increment in MAC operations for the BCU
is indicative of its more complex computational framework, which, while
increasing its computational load, also enhances its processing capability.
The latency metric is especially telling in this comparison. The FCU exhibits
a latency of 15 milliseconds, which is higher than the BCU’s 12 milliseconds.
This difference underscores the BCU’s efficiency in processing data in a
timely manner, a crucial aspect for real-time applications. Finally, the power
efficiency of both units is compared. The BCU, with 20.0 GOP/s/W, shows a
higher efficiency compared to the FCU’s 18.5 GOP/s/W. This demonstrates the
BCU’s ability to perform more operations per watt, making it a more energy-
efficient choice, especially for applications where power consumption is a
critical factor. The comparative analysis between FCU and BCU in our framework
illustrates the differences in their design and operational efficiency. While
both units have their unique strengths, the BCU shows a slight edge in terms
of accuracy, MAC operations, latency, and power efficiency, making it a more
optimal choice for certain applications that demand higher performance and
efficiency.

###  V-A Effectiveness of Mixed-Signal Design

The integration of analog and digital components in mixed-signal design brings
together the best of both worlds: the precision and scalability of digital
systems with the nuanced and varied processing of analog systems. This
subsection delves into how mixed-signal design augments system performance,
with a focus on its impact on energy efficiency and processing speed. We
compare the chip area, latency, and energy efficiency (EE) of a traditional
digital CMOS design against our mixed-signal implementation that shows in
Table III.

TABLE III: Effectiveness of Digital CMOS vs. Mixed-Signal Design

Design Type | Chip area (mm2) | Latency (ms) | EE (TOPS/W)
---|---|---|---
Digital CMOS | 321 | 12 | 0.28
Mixed-Signal | 293 | 0.75 | 213

  * •

*The energy efficiency (EE) is represented in tera-operations per second per watt (TOPS/W), which is a standard metric for such evaluations.

(a) Latency comparison.

(b) Power Consumption comparison.

(c) Throughput comparison.

(d) Power Efficiency comparison.

Figure 5: Performance of our framework across three distinct hardware
platforms using various datasets.

Figure 5 illustrates provides a comprehensive comparison of key metrics such
as latency, power consumption, throughput, and power efficiency across
different computational platforms: GPU, FPGA, and Mixed-Signal. This
comparison is conducted for both the FCU and BCU applications. The latency
analysis reveals that the FPGA platform exhibits lower latency values for both
FCU and BCU, suggesting its efficiency in rapid data processing. In contrast,
the GPU shows relatively higher latency, while the Mixed-Signal design
achieves the lowest latency values, underscoring its potential in real-time
processing applications. The FPGA platform demonstrates a significantly lower
power requirement compared to the GPU, making it a more energy-efficient
choice. However, the Mixed-Signal design outperforms both FPGA and GPU in
terms of energy consumption, indicating its suitability for power-sensitive
applications. The Mixed-Signal design achieves the highest throughput for both
FCU and BCU, followed by the GPU and then FPGA. This highlights the Mixed-
Signal design’s superior processing capability. The power efficiency analysis
demonstrates that the Mixed-Signal platform provides the highest power
efficiency, followed by FPGA and GPU. This metric is crucial for understanding
the overall energy effectiveness of each platform in executing high-
performance tasks.

TABLE IV: Comparison of Edge-AI Processing Solutions Work / Metric |  Energy Efficiency (TOPS/W) |  Precision Support |  Technology Node |  Key Features
---|---|---|---|---
Our Work (BCU & FCU) |  213 |  Binary, INT2/4/8 |  16nm |  Mixed-signal design
DIANA [29] |  Up to 600 (AIMC part) |  7bit I, ternary W, 6bit O |  22nm |  Mixed-signal, mixed-precision
RRAM-based CIM [30] |  195.7 |  8b-input and 8b-weight |  Not specified |  Analog CIM with RRAM
BrainTTA [31] |  Binary: 29, Ternary: 15, 8-bit: 2 |  Binary, Ternary, 8-bit |  22nm |  Flexible datapath, TTA-based
TinyVers [32] |  0.8-17 |  INT2/4/8 |  22nm FDX |  eMRAM, low power management
Kraken [33] |  General: 1.8, SNE: 1.1 TSyOp/s/W |  Mixed-precision |  22nm |  SNN and ANN accelerators, RISC-V core
CUTIE [34] |  1036 |  Ternary |  Not specified |  Ternary Neural Network Accelerator

Table IV presents a comparison of various Edge-AI processing solutions,
including our work, alongside several other notable projects such as DIANA,
RRAM-based Computing-in-Memory (CIM), BrainTTA, TinyVers, Kraken, and CUTIE.
The comparison is made across four main metrics: energy efficiency measured in
TOPS/W, the types of precision support for operations, the technology node in
nanometers indicating the fabrication process’s scale, and key features unique
to each project. Each project has its unique strengths, from high energy
efficiency to support for various precisions and innovative features like
mixed-signal designs, analog and digital computing, and flexible
architectures. This comparison highlights the diverse approaches within the
Edge-AI processing domain, catering to different requirements and
applications.

##  VI Conclusions

This research marks a significant milestone in the development of neuromorphic
computing systems, as it encapsulates the successful integration and
implementation of BCUs and FCUs within a digital neuromorphic architecture.
The primary findings of this study highlight remarkable improvements in
computational efficiency and accuracy, primarily attributed to the innovative
mixed-signal design approach. Our experimental investigations, conducted using
diverse open-source datasets, have validated the superior performance
capabilities of our neuromorphic system. This encompasses processing speed,
energy efficiency, and adaptability, which are notably more advanced than
those observed in traditional neuromorphic systems. The data reveal that each
computational platform GPU, FPGA, and Mixed-Signal—exhibits unique strengths.
However, it is the Mixed-Signal design that stands out, offering an
exceptional balance of low latency, high throughput, and extraordinary power
efficiency. This makes it a compelling choice for a wide array of
applications, especially those demanding high efficiency and adaptability. The
importance of the mixed-signal neuromorphic systems, as demonstrated by our
research, lies in their capacity to effectively bridge the robustness of
analog processing with the precision and scalability of digital systems. This
study has evidenced that such systems are not just feasible but also excel in
certain computational tasks, particularly where high efficiency and
flexibility are paramount. The utilization of mixed-signal design has emerged
as a pivotal innovation in neuromorphic computing, paving the way for more
sophisticated, efficient, and versatile computing solutions.

##  VII Future Work

Future work will include taking the output of the chip shown in the GDSII flow
and creating a sensor fusion acceleration that includes multiple sensors along
with the models here, and running these sensors in IoT with a brain-inspired
chip. Our research has opened new avenues in the field of mixed-signal
neuromorphic computing, particularly highlighting its potential in advanced
computational models. Based on our findings, the following are proposed
directions for further research:

  * •

Advanced Integration Techniques: Exploring more sophisticated methods for
integrating BCU and FCU into mixed-signal neuromorphic architectures. This
could involve developing novel algorithms or hardware configurations that
further enhance the efficiency and scalability of these systems.

  * •

Diverse Application Scenarios: Extending the application of our mixed-signal
neuromorphic architecture to a broader range of fields, such as robotics,
autonomous systems, and complex data analysis. This would help in
understanding the versatility and adaptability of our architecture in
different scenarios.

  * •

Improving Energy Efficiency: Investigating new materials and circuit designs
that could further reduce the power consumption of neuromorphic systems. This
is crucial for developing sustainable and eco-friendly computing technologies.

  * •

Real-Time Data Processing: Focusing on real-time data processing capabilities
in dynamic environments. This includes enhancing the system’s ability to adapt
and learn from new data in real-time, which is vital for applications in areas
like autonomous driving and interactive systems.

  * •

Long-Term Reliability Studies: Conducting long-term reliability studies of
mixed-signal neuromorphic systems. This would involve assessing the durability
and maintenance needs of these systems over extended periods, which is
critical for their practical deployment.

  * •

Benchmarking Against Emerging Technologies: Benchmarking the performance of
mixed-signal neuromorphic systems against emerging technologies. This
comparison could provide valuable insights into the strengths and limitations
of each approach.

## References

  * [1] D. O. Hebb, “The organization of behavior,” p. 43–54, 1988.
  * [2] C. A. Mead and L. Conway, _Introduction to VLSI systems_ , 1978. [Online]. Available: http://portal.acm.org/citation.cfm?id=578480
  * [3] C. A. Mead and M. Ismail, _Analog VLSI implementation of neural systems_. The Kluwer international series in engineering and computer science, 1989.
  * [4] T. Hylton, “Systems of neuromorphic adaptive plastic scalable electronics,” _DARPA SYNAPSE Bidder’s Workshop and Teaming Meeting_ , 2008.
  * [5] S. Yin, “Algorithm and hardware design of discrete-time spiking neural networks based on back propagation with binary activations,” 2017. [Online]. Available: https://arxiv.org/abs/1709.06206
  * [6] H. Markram, “The human brain project,” _Scientific American_ , vol. 306, no. 6, p. 50–55, 2012.
  * [7] “Department of energy announces $2 million for neuromorphic computing research,” 2020. [Online]. Available: https://www.energy.gov/science/articles/department-energy-announces-2-million-neuromorphic-computing-research
  * [8] P. M. et al., “A million spiking-neuron integrated circuit with a scalable communication network and interface,” _Science_ , vol. 345, no. 6197, p. 668–673, 2014.
  * [9] M. D. et al., “Loihi: A neuromorphic manycore processor with on-chip learning,” _IEEE Micro_ , vol. 38, no. 1, p. 82–99, 2018.
  * [10] X. Duan, Z. Cao, K. Gao, W. Yan, S. Sun, G. Zhou, Z. Wu, F. Ren, and B. Sun, “Memristor-based neuromorphic chips,” _Advanced Materials_ , p. 2310704, 2024.
  * [11] M. Isik, M. Oldland, and L. Zhou, “An energy-efficient reconfigurable autoencoder implementation on fpga,” in _Intelligent Systems Conference_. Springer, 2023, pp. 212–222.
  * [12] M. Isik, H. Vishwamith, Y. Sur, K. Inadagbo, and I. C. Dikmen, “Neurosec: Fpga-based neuromorphic audio security,” in _International Symposium on Applied Reconfigurable Computing_. Springer, 2024, pp. 134–147.
  * [13] G. T. et al., “Seneca: building a fully digital neuromorphic processor, design trade-offs and challenges,” _Frontiers in Neuroscience_ , vol. 17, 2023.
  * [14] M. J. et al., “Sctn: Event-based object tracking with energy-efficient deep convolutional spiking neural networks,” _Frontiers in Neuroscience_ , vol. 17, 2023.
  * [15] K. A. et al., “Neuromorphic applications in medicine,” _Journal of Neural Engineering_ , vol. 20, no. 4, p. 041004, 2023.
  * [16] J. Bill and R. Legenstein, “A compound memristive synapse model for statistical learning through stdp in spiking neural networks,” _Frontiers in Neuroscience_ , vol. 8, 2014.
  * [17] J. B. et al., “Adversarial attacks on spiking convolutional neural networks for event-based vision,” _Frontiers in Neuroscience_ , vol. 16, 2022.
  * [18] Y. Z. et al., “Recent advances in emerging neuromorphic computing and perception devices,” _Journal of Physics D: Applied Physics_ , vol. 55, no. 5, p. 053002, 2021.
  * [19] S. F. et al., “The spinnaker project,” _Proceedings of the IEEE_ , vol. 102, no. 5, p. 652–665, 2014.
  * [20] N. Howard and A. Hussain, “The fundamental code unit of the brain: Towards a new model for cognitive geometry,” _Cognitive Computation_ , vol. 10, no. 3, p. 426–436, 2018.
  * [21] P. K. Huynh, M. L. Varshika, A. Paul, M. Isik, A. Balaji, and A. Das, “Implementing spiking neural networks on neuromorphic architectures: A review,” _arXiv preprint arXiv:2202.08897_ , 2022.
  * [22] M. Isik, A. Paul, M. L. Varshika, and A. Das, “A design methodology for fault-tolerant computing using astrocyte neural networks,” in _Proceedings of the 19th ACM International Conference on Computing Frontiers_ , 2022, pp. 169–172.
  * [23] M. Isik, “A survey of spiking neural network accelerator on fpga,” _arXiv preprint arXiv:2307.03910_ , 2023.
  * [24] M. Isik and K. Inadagbo, “Astrocyte-integrated dynamic function exchange in spiking neural networks,” in _International Conference on Engineering of Computer-Based Systems_. Springer, 2023, pp. 263–273.
  * [25] J. Q. et al., “55 nm cmos mixed-signal neuromorphic circuits for constructing energy-efficient reconfigurable snns,” _Electronics_ , vol. 12, no. 19, p. 4147, 2023.
  * [26] A. R. et al., “Neuromorphic analog circuits for robust on-chip always-on learning in spiking neural networks,” 2023.
  * [27] B. C. et al., “Surrogate gradients for analog neuromorphic computing,” _Proceedings of the National Academy of Sciences of the United States of America_ , vol. 119, no. 4, 2022.
  * [28] S. Miziev, W. A. Pawlak, and N. Howard, “Comparative analysis of energy transfer mechanisms for neural implants,” _Frontiers in Neuroscience_ , vol. 17, p. 1320441, 2024.
  * [29] K. U. et al., “DIANA: An End-to-End Energy-Efficient Digital and Analog Hybrid Neural Network SoC,” in _ISSCC_ , vol. 65, 2022.
  * [30] C.-X. X. et al., “16.1 a 22nm 4mb 8b-precision reram computing-in-memory macro with 11.91 to 195.7 tops/w for tiny ai edge devices,” in _ISSCC_ , vol. 64. IEEE, 2021.
  * [31] M. M. et al., “BrainTTA: A 35 fJ/op Compiler Programmable Mixed-Precision Transport-Triggered NN SoC,” _arXiv preprint arXiv:2211.11331_ , 2022.
  * [32] V. J. et al., “TinyVers: A 0.8-17 TOPS/W, 1.7 uW-20 mW, Tiny Versatile System-on-chip with State-Retentive eMRAM for Machine Learning Inference at the Extreme Edge,” in _VLSI Symposium_ , 2022.
  * [33] A. D. M. et al., “Kraken: A direct event/frame-based multi-sensor fusion soc for ultra-efficient visual processing in nano-uavs,” in _2022 IEEE Hot Chips 34 Symposium (HCS)_ , 2022, pp. 1–19.
  * [34] M. S. et al., “A 1036 TOp/s/W, 12.2 mW, 2.72 µJ/Inference All Digital TNN Accelerator in 22 nm FDX Technology for TinyML Applications,” in _COOL CHIPS_. IEEE, 2022.