# The Championship Simulator: Architectural Simulation for Education and
Competition

Nathan Gober1, Gino Chacon1, Lei Wang1, Paul V. Gratz1,
Daniel A. Jiménez1, Elvira Teran2, Seth Pugsley3, Jinchun Kim1  1 Texas A&M
University
{ngober, ginochacon<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>2 Texas A&M International University
<EMAIL_ADDRESS>3 Intel
<EMAIL_ADDRESS>
###### Abstract

Recent years have seen a dramatic increase in the microarchitectural
complexity of processors. This increase in complexity presents a twofold
challenge for the field of computer architecture. First, no individual
architect can fully comprehend the complexity of the entire microarchitecture
of the core. This leads to increasingly specialized architects, who treat
parts of the core outside their particular expertise as black boxes. Second,
with increasing complexity, the field becomes decreasingly accessible to new
students of the field. When learning core microarchitecture, new students must
first learn the big picture of how the system works in order to understand how
the pieces all fit together. The tools used to study microarchitecture
experience a similar struggle. As with the microarchitectures they simulate,
an increase in complexity reduces accessibility to new users.

In this work, we present ChampSim. ChampSim uses a modular design and
configurable structure to achieve a low barrier to entry into the field of
microarchitecural simulation. ChampSim has shown itself to be useful in
multiple areas of research, competition, and education. In this way, we seek
to promote access and inclusion despite the increasing complexity of the field
of computer architecture.

##  I Introduction

Computer architecture has developed over the decades into a mature field with
strong specialization. Processors have grown in complexity, gaining more and
more features as transistor density continues to increase, and as each new
iterative innovation builds upon previous solutions. An increasingly lengthy
historical perspective is required to fully appreciate the state of the
leading edge of processors. Also, the trend of software tools used to assist
microarchitecture development has been towards large, complex, and monolithic
simulation environments.

Simultaneously, computer architecture education has become a core component of
undergraduate computer engineering and computer science curricula. A basic
understanding of computer architecture topics such as cache replacement and
branch prediction is no longer restricted to graduate level courses, but can
easily find a place in an undergraduate research project or classroom
assignment. While precise tools used by experts provide a high level of
correctness, students need tools appropriate for their level of knowledge,
experience, and ability. A large gap exists between the need for arcane tools
used by experts and the need for accessible tools that can be used by novices.
In this gap should stand a tool that strikes a balance between correctness and
accessibility.

Computer hardware development is impeded by the long production pipelines
required to realize a design. If a hardware design must traverse its entire
life cycle in order to be evaluated, it may take many years to produce a well-
tested design. It is furthermore infeasible to tape out many iterations of a
design in order to evaluate their comparative performance. In order to reduce
costs and mitigate long production pipeline times, hardware architects turn to
higher-level software simulation of their designs. Simulation bridges the gap
by enabling rapid comparisons between the designs, giving an approximation of
the system’s performance. Software simulation of designs is, by its nature,
far slower than the hardware designs being evaluated, but allows for a much
shorter design-to-evaluation time.

The advancement of the field of computer architecture depends on accurate and
rapid simulation. Simulator authors make tradeoffs between evaluation time and
simulation accuracy. The landscape of simulators today is wide, but few see
broad usage. Some simulators are less concerned with evaluation time, and are
more concerned with simulation accuracy. Others place greater emphasis on
model performance over a more detail-oriented approach. Such simulators find
their balance in a short evaluation time.

In this work, we present ChampSim, a simulator designed to promote innovative
research, inclusive education, and healthy competition in the field of
computer architecture. The ChampSim simulator is derived from the simulation
tools used in the Second Data Prefetching Competition, which was held in
conjunction with ISCA 2015. ChampSim simulates a heterogeneous multicore
system with an arbitrary memory hierarchy, where each out-of-order core can be
configured arbitrarily. It is intended to promote access in the rapidly-
growing field of computer architecture. To accomplish this, we keep three key
principles in mind: Low startup time, broad applicability, and design
configurability. These design principles have led to a simulator that favors
usability and rapid iteration.

This paper will discuss in detail the purpose, design, and effectiveness of
the ChampSim simulator, beginning with a discussion of the guiding principles
of the design in Section II, details on the key features of ChampSim’s modular
architecture in Section III, a history of ChampSim’s application in the field
and a vision of its continuing place in Section IV, and a list of future
development plans in Section VI.

##  II The ChampSim Architectural Simulator

The ChampSim simulator has its roots in the simulation environment used for
the Second Data Prefetching Competition [1]. In a competition environment, it
is valuable to have an easy-to-use environment to encourage wide participation
and a variety of novel submissions. These accessibility principles have
continued through the development of ChampSim and have emerged into three
guiding design principles: low startup time, broad applicability, and high
configurablilty.

###  II-A Low startup time

While failure is an important part of learning, wrangling with a highly
complex simulator before even beginning the implementation of a new idea can
frustrate the learning process of any student or beginning researcher. With
this insight in mind, we seek that a new user should be able to download and
compile ChampSim in a few minutes, create their first design in a few hours,
and perform new and meaningful computer architecture research within a few
weeks. In each of the applications for which ChampSim is intended, it is
valuable that a user is able to begin using the simulator quickly.
Furthermore, the runtime of the simulation should be short enough to provide
quick feedback for a novice user.

Many general-purpose processors have a lot in common. Designs are pipelined,
usually with a decoupled, in-order front end and an out-of-order back end.
Many researchers are not seeking to modify these basic design aspects, but
have a particular element of the design in mind that they intend to study or
improve. ChampSim presents a selection of areas that commonly see research
activity as configurable modules: branch predictors, cache replacement
policies, branch target buffers, and both instruction and data prefetchers.
These modules provide an intuitive interface into a larger system, allowing
designers to test new designs quickly and effectively, while affording them
the opportunity to not have to worry about the parts of the system they are
not studying.

Reference implementations of legacy modules, such as the GShare branch
predictor [2] or the next-line prefetcher, are included with the simulator.
These reference implementations can be used as starting points for new designs
or as placeholders if the user is not interested in modifying those particular
modules.

###  II-B Broad Applicability

A researcher seeking to perform hardware research should not be expected to be
broadly familiar with a variety of programming languages or to track their
changes over time. Therefore, for the sake of inclusion, we seek that a user
should only need an entry-level understanding of C++, the language in which
ChampSim is written, to perform research using ChampSim. The interface to an
simulator should be simple and present the user with a few meaningful choices
that map well onto their experience. Each module is fundamentally only the
implementation of a few functions.

ChampSim is trace-driven, meaning that simulation is performed in two stages.
First, the workload to be simulated is instrumented and run offline. The
tracing instrumentation produces a digest of the program’s activity, called a
trace. The tracing step can be performed offline from the simulation step and
the trace can be stored in a repository and made available to users. To test a
simulated design, the user selects a trace file as input. The trace is
streamed into the program as a stand-in for actual program execution. This
strategy sacrifices a modest amount of accuracy, particularly in how the
operating system interacts with the program, in favor of ease in reproducing
results and of speed of the model. It is simpler for ChampSim to read a
decoded trace file than to execute an external program, and given established,
compiled repositories of traces, it is a helpful abstraction to the user to
remove another step of environment setup.

Users are able to generate their own program traces with the included “tracer”
tracing tool, included in the ChampSim package. The included tracer is built
upon Intel PIN [3], a well-documented tool for instrumenting programs at
runtime, though other tool sets, such as DynamoRIO [4], can be used.
Alternately, instruction traces can be dumped from execution-driven simulators
such as gem5 or QFlex [5, 6, 7]. The tracer inspects every instruction the
program runs and encapsulates each instruction into a decoded format that
includes the instruction pointer, branching behavior, and which registers and
memory locations form the input and output operands for the instruction. The
concatenation of many instructions forms the entire trace. This trace format
permits ChampSim to run with low memory requirements, since the trace does not
need to be held in memory but can be streamed off the disk after inline
decompression.

###  II-C Design configurability

ChampSim is capable of modeling a large variety of commodity processors. A
configuration file specifies many aspects of the modeled CPU core, including
frequency, cache configuration, re-order buffer size, load and store queue
sizes, widths for instruction fetch, decode, execution and retire, and a
variety of latencies for different components. In addition, ChampSim includes
a DRAM system that models bank and bus contention. The trace format includes
only virtual memory addresses, so ChampSim simulates a page table and TLB
hierarchy with arbitrary mappings of virtual to physical pages.

Each cache must be configured with a prefetcher (to simulate no prefetcher,
there is an included “do-nothing” prefetcher) and a replacement policy. The
cache interfaces with a read queue, a write queue, and a prefetch queue.
Prefetches originating from the cache level are placed in its prefetch queue
and serviced with a lower priority than the read queue. When a prefetch misses
the cache, it is by default sent to the lower level’s prefetch queue, though
this is configurable. All TLB structures function identically to caches.

Each core model is configured with an instruction prefetcher (which may be a
do-nothing prefetcher), a branch predictor, and a branch target buffer. Each
core must be configured with an instruction TLB and cache, plus a data TLB and
cache.

The cache architecture is flexible. The sink of all TLB requests must be
configured to be a core’s hardware page table walker, whose lower level is, in
turn, the same core’s L1 data cache, and the ultimate sink of all instruction
or data memory requests must be configured to be the physical memory. Beyond
that, the cache hierarchy can be arbitrary. Caches can be shared between cores
and can be non-uniform levels of depth.

Figure 1: ChampSim defines four types of modules. Each module requires a
specific set of functions, or hooks, to be defined to allow the module to
interact with the underlying model.

Figure 2: ChampSim is capable of simulating multicore systems, an example of
which is given here. Each core has its own branch target predictor and branch
prediction module that may be configured uniquely from one another. Each core
has a private cache hierarchy and virtual memory hardware support. Every
core’s memory hierarchy shares a last level cache, which is subsequently
connected to the main memory model.

Figure 3: The virtual memory hardware support structures and private caches
are instantiated for each core model. Each TLB and cache hierarchy level has
interchangeable prefetcher and replacement policies. Each core sends requests
for virtual-to- physical address translations to its TLBs. Each core sends
instruction or data memory requests to its private caches. On a Second Level
TLB miss, the Page Table Walker navigates the page table through a series of
memory reads to find the translation. Page table entries are cached in the
private and shared caches, just like any other data.

##  III Modularity

Typically in computer architecture, the student or researcher approaches their
research with the goal of improving only a small part of a large processor. A
researcher rarely attempts to develop an entirely new processor from scratch.
Therefore, there is a need for a highly modular simulator, whose operative
elements are easily substituted for alternative elements. A modular design
permits convenient comparisons between competing component designs, as the
underlying simulation environment is otherwise identical. This ease of
comparison is important in both an academic and an industrial environment
because it simplifies communication with interested audiences. It is far
easier to communicate the benefit of a change when it is readily evident to
the audience that the performance gain is attributable to the design change,
and not a peculiarity of the underlying system.

A modular design also enables easier collaboration between researchers. A
design can be easily shared when the essence of the design is limited to a few
files of source code. ChampSim’s modular design minimizes the amount of
repetitive code between modules.

ChampSim defines four types of modules: branch predictors, branch target
predictors (BTPs), memory prefetchers, and cache replacement policies. Each
cache and TLB must define a prefetcher and a replacement policy. Prefetchers
and replacement policies can be heterogeneous across cache and TLB levels.
Each core defines a branch predictor and BTP that also can be heterogeneous
between cores. ChampSim detects all required modules at configuration time and
links a component’s source as needed.

Each module implements a set of predefined functions. These functions are
called when certain events occur in the underlying simulator model, and are
generally referred to as “hooks.” The hooks are implemented as member
functions of either the core or cache models to allow modules access to all
structures within their respective model. This structure permits designs that
may have unrealistic visibility into other parts of the model to allow for
extending a design’s capabilities or to collect statistics. A module’s
attempts to edit the internal state of the core or cache model is considered
undefined behavior and may adversely affect the simulator’s operation. More
information is provided to the modules than some may consider reasonably
constructible in a processor. Such information is not provided as an
implication that it should be possible, but to permit designs that make such a
case. We leave the evaluation of whether a design is constructible to the
discretion of the researcher and the committees responsible to review the
design. Figure 1 lists the required hooks for each module in ChampSim. All of
the listed hooks must be implemented, even if they are empty functions and
perform no action.

ChampSim is designed to be flexible and permit a wide variety of core and
cache parameters to be defined within a JSON configuration file, with
reasonable defaults as a fallback. Before compilation, a configuration step is
required in which the configuration script examines a user-specified
configuration file to determine how to build the simulator. The core, caches,
and other structures are sized individually with values extracted from the
configuration file. This allows ChampSim to simulate not only homogeneous
systems but heterogeneous multicore systems with each core having different
sized internal and memory structures. The modules are built with compiler
flags that instruct the preprocessor to substitute the simulator hook function
names with unique, procedurally generated names. The configuration script
generates discriminator code that ensures that only hooks corresponding to the
correct module are called at run time by each cache and core model. ChampSim
is capable of simulating multicore systems with individual private caches and
virtual memory structures such as the one shown in Figure 2. The virtual
memory and cache hierarchy is illustrated in Figure 3. This is only an example
of ChampSim’s default configuration and may be reconfigured based on a user’s
needs.

To simulate multi-programmed workloads, at run time, the user provides one
trace file for each core, statically assigned to that core for the duration of
the simulation. An upcoming version of ChampSim will allow more flexibility in
the trace assignments, as well as multi-threaded trace simulation (see Section
VI).

###  III-A Branch Predictors

A hardware branch predictor is commonly included in contemporary processors to
mitigate the performance impact of branches. If a given branch is predicted
incorrectly, the subsequent wrong path instructions must be flushed from the
pipeline. ChampSim’s traces do not include any wrong path instructions, so it
instead models this with a fixed-latency penalty following the resolution of
incorrectly predicted branches. In ChampSim, the branch predictor module hooks
are member functions of the core model. These hooks allow for designs to
create prediction structures that have access to recent branch information and
branch outcomes. The branch predictor’s hooks are as follows:

  * •

initialize_branch_predictor(): Each core calls this hook at the beginning of
the simulation after the core has been fully initialized. This hook can be
used to initialize structures in cases where the static initialization of C++
evaluation would occur too early. Furthermore, as a member function of the
core model, the initialization hook can observe the size of internal core
structures.

  * •

predict_branch(): This hook is called for each branch instruction in the
execution path of the program. It is responsible for predicting whether the
branch is taken or not, and returns a boolean value.

  * •

last_branch_result(): This hook presents the branch predictor’s opportunity to
train on the true outcome of each branch instruction. The same information is
provided to the branch predictor as predict_branch(), but updated with the
actual branch outcome.

###  III-B Branch Target Predictors

The branch target predictor (BTP) works in concert with the branch direction
predictor to attempt to fully predict the outcome and target of branch
instructions. The BTP provides the next instruction pointer after a taken
branch. Incorrect predictions of branch targets cause wrong path execution in
real processors. As with branch direction misprediction, ChampSim models these
mispredictions with fixed-size delays. All BTP modules are member functions of
the core model. Similar to the branch predictor module, these hooks allow for
the BTP to receive information about observed branches and their outcome.
These hooks are named based on branch target buffer (BTB) operations but can
be used to design other forms of BTPs.

  * •

initialize_btb(): Each core calls this hook at the beginning of the
simulation, after the core has been fully initialized. This hook can be used
to initialize structures within the BTP in cases where the static
initialization of C++ evaluation would occur too early. Furthermore, as a
member function of the core model, the initialization hook can observe the
size of internal core structures.

  * •

btb_prediction(): This hook is called for each branch instruction in the
execution path of the program. The BTP is given the instruction pointer of the
branch instruction and its branch type. It must attempt to predict the byte
address of the branch target and whether the branch is always taken, returning
these values as a tuple. The BTP may indicate that the branch is predicted not
taken by returning a target address of 0. If this disagrees with the branch
direction prediction, the module predicting not-taken receives priority.

  * •

update_btb(): This hook presents the BTP’s opportunity to train on the true
outcome of each branch instruction. This hook provides the branch instruction
pointer, the true branch target, whether the branch was taken, and the branch
type to train its internal structures to make better predictions.

###  III-C Data Prefetchers

Memory prefetchers are implemented in caches to reduce miss rates by
anticipating future demand accesses. Prefetchers require information regarding
cache accesses and the accesses that result in cache fills. This information
allows the prefetcher to observe cache behavior, generate predictions, and
receive feedback regarding predictions. In particular, memory prefetchers are
assumed to operate asynchronously with the operation of the underlying cache
model, precipitating a need for the prefetch_line() callback function. While
other modules supply their information as return values for function hooks, a
prefetcher may operate many cycles following the initiating event. All data
prefetcher hooks are member functions of the cache model, allowing for
prefetcher developers to extend the prefetcher’s visibility of the cache’s
behavior as they see fit.

  * •

prefetcher_initialize(): Each core calls this hook at the beginning of the
simulation after the cache has been fully initialized. This hook can be used
to initialize prefetcher structures if static initialization would occur too
early.

  * •

prefetcher_cache_operate(): The cache calls this hook when a demand request
occurs. By default, this hook is only called for loads and prefetches from
upper cache levels, though this is configurable. A prefetcher uses this hook
to examine the access patterns at its cache level on a per-address basis to
predict future cache accesses. As the primary function that communicates these
access patterns to the prefetcher, this function also provides the prefetcher
with the memory access’s address, the instruction address that caused the
memory access, whether the access resulted in a hit in the cache, and the type
of memory access. The prefetcher also receives metadata from the incoming
access that may be provided by a prefetcher in an upper cache level. Likewise,
the prefetcher may return metadata to the cache to embed within the memory
access’s packet to communicate with lower levels of the cache hierarchy.

  * •

prefetcher_cache_fill(): This hook is called each time a block is filled in
the cache. Its parameters include information about which blocks were evicted
and filled. Prefetchers can use this hook to evaluate their own accuracy,
estimate cache miss latency, or to make future prefetching decisions about
evicted blocks.

  * •

prefetcher_cycle_operate(): This hook is called once every cycle on the same
clock frequency as the underlying cache. This hook enables developers to
precisely simulate the pipelining of complex prefetchers, if desired. Memory
prefetch timing is often crucial to avoid misses, so complex prefetchers may
use this function to emulate the delay between a prefetch and its initiating
event.

  * •

prefetcher_final_stats(): Once all instructions are executed, this hook prints
user-defined statistics recorded throughout the simulation to the simulation’s
output.

  * •

prefetch_line(): This hook allows for the asynchronous operation of the
prefetcher. Unlike other hook functions, this function is never called by the
underlying simulator but must be called by the user to perform a prefetch. The
prefetcher might call this in response to a demand request, a fill, or on a
particular cycle, and can be called as many times as the user wants. The user
can choose whether to fill into either the prefetcher’s current cache level or
a lower cache level.

###  III-D Instruction Prefetchers

Unlike the data prefetcher modules, the instruction prefetcher module hooks
are members of the core model and are connected to the L1 instruction cache.
Most instruction prefetcher hooks are called by the cache when certain events
occur in the cache. Instruction prefetchers have the same hooks as the data
prefetchers, and are called on the same events. The only exception is the
prefetch_line() function, which is replaced by prefetch_code_line().
Furthermore, instruction prefetchers have one additional hook:

  * •

prefetcher_branch_operate(): This hook is called when a branch instruction is
read from the trace. This hook can give the instruction prefetcher information
about the boundaries of basic blocks.

###  III-E Replacement Policies

Cache replacement policies choose which cache line to evict from a cache set.
Many do this by using a heuristic to predict the future utility of cache
lines, and evict the line with the lowest expected utility. The information
provided to the replacement policy allows it to view the cache’s demand access
stream. All of the hooks of a replacement policy are member functions of the
cache model.

  * •

initialize_replacement(): Each core calls this hook at the beginning of the
simulation, after the cache has been fully initialized. This hook can be used
to initialize structures specific to the replacement policy where static
initialization would occur too early.

  * •

find_victim(): The cache calls this hook when a cache set requires a victim
cache block. The module returns the cache way within the set to be replaced.
Cache bypassing is also an option, and is indicated by returning a value equal
to the maximum number of ways.

  * •

update_replacement_state(): The cache calls this hook to update the
replacement policy on a change in the cache’s state due to a cache hit or
fill. The information provided to the replacement policy enables the
replacement structures to receive feedback on whether their victim selection
was harmful to the system’s performance.

  * •

replacement_final_stats(): This hook is called at the end of the simulation
after all instructions are executed. This hook is used to print user-defined
statistics recorded during the simulation.

##  IV Application

ChampSim has already found a place in the ecosystem of computer architecture
simulation as a lightweight tool to introduce ideas to the community. It has
promoted new and innovative research, fueled in part by industry-sponsored
competitions. Furthermore, it shows promise as a tool for classroom use,
striking a balance between being simple and accessible, and being a feature-
rich simulator.

###  IV-A Research

The rapid prototyping and evaluation of computer hardware designs is essential
to the continuing development of computer architecture. Established industry
heavyweights design and implement simulators for internal use. These
proprietary simulators are rarely disclosed, since doing so may reveal
valuable trade secrets that will hinder them competitively. Therefore, the
research community must itself develop and support open-source simulators to
conduct independent computer architecture research.

ChampSim has already been in use among the community for some time. Due to its
exposure through computer architecture competitions, several high-impact
publications have founded their results on ChampSim. It has been key in
demonstrating the excellence of many memory prefetchers, both of data [8, 9,
10, 11, 12, 13, 14, 15, 16, 17] and instructions [18]. It has found use in
evaluating cache replacement policies, particularly in the last level cache
[19, 20, 21, 22]. ChampSim’s view of a TLB as functionally identical to a
cache has led to research into prefetching in TLBs [23, 24]. The modularity of
ChampSim’s branch predictor has shown benefits in novel works [25]. The branch
target buffer has also been studied with ChampSim [26].

As a fast, lightweight simulator, ChampSim’s relatively small code footprint
has proven to be easy to understand and modify. While some have leveraged the
module system to develop novel works, others have additionally modified the
underlying model itself [27, 28, 29, 30]. Users can furthermore modify the
existing program tracer to generate traces of different formats to meet
particular needs.

In only a few years, ChampSim has shown to be a valuable tool for academic
research. As of this writing, research performed using ChampSim has already
received 352 citations. Development of ChampSim is still ongoing, and new
features are continually being added. ChampSim is likely to foster further
work in these areas as the simulator’s development continues.

###  IV-B Competition

There has been a rise in industry-sponsored contests to promote memory system
research. ChampSim has been featured in:

  * •

The Second Data Prefetching Championship (2015)[1]

  * •

The Second Cache Replacement Championship (2017)[31]

  * •

The Third Data Prefetching Championship (2019)[32]

  * •

The First Instruction Prefetching Championship (2020)[33]

  * •

The ML-Based Data Prefetching Competition (2021)[34]

Competition | Submissions
---|---
DPC-2 [1] | 13
CRC-2 [31] | 15
DPC-3 [32] | 14
IPC-1 [33] | 16
MLDPC [34] | 4
Total | 62
TABLE I: The number of submissions to a selection of competitions. Each of
these submissions is a unique proposal in the space of computer architecture.

In these competitions, a call for submissions solicits submissions of
innovative designs for a particular module. The submissions are compared and
ranked by metrics such as instructions per cycle or cache misses. These
contests encourage many designs to be compared and rewarded for their merits.
They have increased the rate of publication in the field of memory prefetching
and cache replacement. There have been many submissions to these competitions,
listed in Table I, which have produced many follow-up publications. ChampSim
has been the simulator of choice in these competitions due to its
availability, being open-source, ease of use, requiring minimal dependencies,
and speed, evaluating billions of instructions per hour.

ChampSim was designed from the beginning to make these kinds of comparative
contests simple to organize, evaluate, and participate in. Contestants
typically are given 2 months to ramp up with ChampSim and produce novel work.
The high rate of participation in each contest is evidence that ChampSim is
accessible and easy to use. The modular design creates a competition workflow
wherein contestants need only submit the source code for the module under
evaluation. The competition organizer can then easily compile, run, and
evaluate the competitors’ submissions. We invite any others who would like to
organize competitions in any field of CPU architecture to contact us.

###  IV-C Education

In a classroom setting, instructors are given approximately fourteen weeks to
teach students about tools needed to complete assignments while also teaching
them about the topics at hand. It is accordingly difficult to use a
heavyweight simulator in a classroom setting. Students may be asked asked to
configure and install systems they do not understand for the purpose of only a
few assignments. If this configuration and installation is difficult, it
impedes the students’ progress by increasing their frustration and decreasing
their engagement with the classroom topics. As before, the tools used in an
academic setting should, as much as possible, lower the barrier to entry for
these young entrants to the field. In such a scenario, a lightweight, easy to
understand simulator is preferred. ChampSim meets the needs of educators and
allows students to implement microarchitecture techniques they learn in class.

ChampSim has been designed such that the only dependencies are up-to-date C++
and Python environments. Further dependencies could increase the likelihood
that a student may encounter difficulties when initializing their simulation
environment. Its development target includes compilers available natively in
popular long-term supported operating systems that are commonly available to
students. At the time of writing, this includes GCC 7, Clang 4, Microsoft
Visual Studio 2017, and Python 3.6.

ChampSim has a small codebase, approximately 5000 lines of code, and so it is
possible to comprehend in its entirety. The design of ChampSim does not
necessarily attempt to precisely replicate all hardware functions, but to
emulate it in a readable way. These design decisions allow a student to
rapidly grasp its functionality, configure it, and implement or modify
techniques they’ve learned about in class, all within the span of one academic
semester. ChampSim has been successfully used in classroom settings at Texas
A&M University at both the undergraduate and graduate levels.

In the undergraduate level course, one the students’ first assignments was to
download ChampSim and to become familiar with each of its components. The
students’ final project was to optimize a last-level cache replacement policy,
and prove that their technique outperformed the base case (base cases were
different for each student). All students were able to successfully complete
the first assignment and never during the semester-long project faced
difficulties finding the computer resources to download and configure
ChampSim. As the semester progressed, students were able to identify which
module of the simulator modeled each of the components discussed in the course
and were able to visualize the topics by studying and modifying the simulator.
Students maintained a high level of interest during the lectures, were able to
run simulations and correctly interpret the results, and showed a high level
of mastery on the course exams.

ChampSim was also used in a graduate course at Texas A&M University. In
particular, the focus of this course is in out-of-order core and memory system
microarchitecture. As this is an introductory course in microarchitecture
research, the aim is to get the incoming students up and running on a
simulator as soon as possible, so that they can use most of the semester
developing a course project. To this end, ChampSim was used in two early
semester assignments, one exploring the impact of different branch predictors
on performance of cores with different OoO width, and another exploring the
impact of differing prefetch and replacement policies on the L2 cache. After
this introduction, nearly all the course students choose to use ChampSim for
their course projects, and those that did were more likely to achieve their
project goals by the end of the semester.

For an undergraduate computer architecture course at Texas A&M International
University, the students used ChampSim throughout the course for project work.
At the beginning of the semester, students were asked to download and set up
the simulator. All students were able to do in a matter of minutes, despite
none of these students having previous experience with any other simulator.
For their first assignment, students were asked to run simulations changing
the configuration of the simulator testing different cache sizes, different
replacement policies, and other configurable aspects, and were asked to reason
about results obtained. As the semester progressed and topics were covered
during lecture, being able to plainly read the source code of ChampSim helped
the students understand the concepts in the course and how the concepts could
be implemented in real systems.

In the lecture on memory hierarchy, students were asked to implement their own
replacement policy and, while it was not expected nor required for such policy
to show a performance improvement, it was required for the student to justify
their idea and implementation given what they learned in class. The same kind
of assignment was given over branch prediction and memory prefetching. These
types of assignment challenged the students to go beyond the concepts
presented to them on their textbook and to think outside the box about the
details in the implementation of such components. ChampSim was shown to be a
powerful supplementary teaching tool for this type of course.

We continue to advocate for its usefulness as a tool to invite new students
into the domain of computer architecture research. The authors are aware that
ChampSim has also been used at additional universities at both the
undergraduate and the graduate level, each with reports of success and
discovery on the part of the students. We hope that ChampSim continues to
serve as a low-impendance tool that permits discovery and research with a low
degree of frustration.

##  V Related Works

This section provides a brief overview of selected prior works in
architectural simulation and evaluation with regards to the key design
principles discussed in Section II. Simulation and emulation is the main tool
used by computer architects in academia to evaluate the performance impact of
new microarchitectural designs. As a result, simulation methodology and
simulator design is exceedingly broad area of study and development [35, 36].
As such, there have been an extremely large number of simulators proposed over
the years, here we discuss a subset of the most popular current simulators.

Scarab [37] is a recently developed simulator capable of performing cycle-
accurate execution-driven simulation by using Intel’s PIN to execute
application binaries passed by a user. For faster simulation times, Scarab
also supports trace-driven simulation. The simulator models an out-of-order
pipelined processor, a full cache hierarchy, and interfaces with Ramulator
[38] to provide an accurate and highly configurable main memory model. Scarab
is a promising simulation framework with a low start-up time, but users are
required to use Intel-based systems to use the Pintool based execution-driven
mode. Scarab is suitable for more advanced architects’ use and may not be
appropriate for a classroom setting with students of varying expertise.

Gem5 is a popular event-driven simulator with a wide variety of features to
enable the exploration of most areas of microarchitectural design. A
researcher that finds gem5 does not meet their needs will likely find another
work that extends gem5 for their purpose [39, 40, 41, 42]. Gem5’s full system
mode allows users to emulate a complete computing system with devices and for
an OS to be executed on the emulation. For designs that do not require OS-
support, gem5 provides system emulation mode in which a user may provide a
binary for the simulator to execute. The simulator supports most available
ISAs and is extremely modular, permitting researchers to plug-and-play system
components, interchange cache hierarchy organizations, experiment with various
network on chip topologies, and explore various core models. This high amount
of configurability allows gem5 to meet most architectural research needs.
Still, this robustness and configurability leads to very high complexity which
heavily increases the barrier of entry and startup time for new students and
researchers.

Zsim [43] is a multicore simulator that breaks the simulation down into
multiple phases, relying on Pin to perform instrumentation of an input binary
to relieve the burden of highly accurate timing models. Each core modeled in
the system is executed in a separate thread based on the instrumentation phase
to allow for highly scalable system simulation. The simulator is configurable
and extendable to allow researchers to represent a wide variety of memory
hierarchies and heterogeneous systems. Similar to Scarab, zsim limits the host
system to use an Intel processor subsequently limiting the system to the x86
ISA. Due to the simulation methodology used, the host system may require
specific configurations that a student may not have permission to modify.

Sniper [44] is a highly parallel multicore simulator that extends Graphite
[45] to add interval model implementation. This methodology allows for faster
simulation by abstracting the system model to events that affect timing
instead of tracking individual instructions as they traverse the pipeline. The
simulator supports heterogeneous core models and operating system execution.
The developers provide Python-based scripts to control and monitor the
simulation during runtime. Similar to Scarab and zsim, PIN dynamically
executes user-inputted binaries. Users are required to request access to the
latest version of Sniper’s source code. Overall, the simulator is configurable
and supports multiple system models, but is limited to x86 execution. The
complexity of interval modeling makes the system difficult for novice
architects and students to modify, resulting in a high barrier of entry.

Each of the simulators discussed here has been widely used for a variety of
research applications and resulted in a large number of publications. These
tools provide configurable features but require extensive knowledge and ramp-
up time to begin design exploration. ChampSim is not an attempt to replace
these tools, but rather to fill the gap in computer architecture tools for
architects. ChampSim is ideal for users that do not require heavyweight
simulation for their research and educators seeking to provide meaningful
curriculum for semester-long courses.

##  VI Future Work

ChampSim is a comparatively new tool and remains in very active development,
with new features and bug fixes being regularly added, within the constraints
of the design principles. Because of the growing adoption of ChampSim as a
tool for education and research, backwards compatibility is a high priority in
any changes that are made. For example, module hook signatures are unlikely to
change (without sufficient cause) to ensure that already published artifacts
remain compatible with newer versions of ChampSim.

Nevertheless, the trace format used imposes some restrictions on the
correctness of ChampSim’s simulation. The current trace format uses fixed-size
arrays to represent register and memory location usage information. This may
be inefficient, leaving some gaps of wasted memory if one instruction accesses
fewer memory locations or registers than other instructions, but it also
carries implicit assumptions about which instruction set architecture is being
traced. A planned future instruction trace format will use variable-sized
arrays to represent this information and should also use compression as part
of the trace specification.

As part of this new trace format effort, more information will be included.
ChampSim currently views instructions as being in one of the following
classes: branch, load, store or arithmetic. It handles all arithmetic
instructions identically, with the same arbitrary delay imposed on each. In
the future, more accurate simulation is possible with a more precise set of
delays.

The current implementation of ChampSim assumes a workload of multiple, single-
threaded programs. That is, each core is assumed not to interact with any
other core’s execution, except to create pressure on any shared caches. Lock
contention is a frequent source of execution delays in multi-threaded
workloads, and adding support for such contention will improve simulation
accuracy. In the future, ChampSim will support multi-threaded workload
simulation, adding support for synchronization constructs such as locks and
barriers. In a new trace format, the interaction between threads can be
encoded.

ChampSim currently makes no effort to maintain cache coherence and only models
non-inclusive cache hierarchies. A future step will be to implement other
forms of clusivity and allow for cache coherence modeling, since an ongoing
body of work, is the interaction of memory prefetching with various forms of
each. The modular design of ChampSim positions it well to examine the
interactions of combinations of such works, since the individual components
can be trivially substituted for one another.

Development has continued on the front end of ChampSim since the First
Instruction Prefetching Competition [33] to make the front end increasingly
fetch directed. The branch direction and target predictors may, as a part of
this effort, become asynchronous like the memory prefetchers, allowing for
prediction latencies longer than a single cycle.

##  VII Conclusion

In this work, we have discussed ChampSim, an architectural simulation tool
designed for ease of use and rapid simulation. We have presented it as a tool
for research, competition, and education, specifically that these may be more
accessible to an upcoming cohort of new architects. In this way, we hope to
promote a broad, diverse, and inclusive community of computer architecture.

The design of the simulator focuses on a low startup time, such that the user
is able to begin using ChampSim with minimal frustration; broad applicability,
so that any new researcher is able to comprehend their place in the broader
scope of the environment; and configurable design, where the user is able to
simulate their work in a variety of contexts with ease. ChampSim accomplishes
this with a modular design. Each element of the simulator is designed to be
replaceable with an equivalent element. This allows for prompt and proper
comparison between competing designs.

ChampSim has been used in a variety of research and teaching endeavors
throughout its lifetime. It has been shown to have a strong impact on the
community by promoting novel works in the field. The competitions that have
been centered around ChampSim have prompted many submissions and led to many
high-impact publications. ChampSim has also shown to be useful in a classroom,
as a tool where students can explore and develop their ideas. We believe that
this work has already found a niche in the landscape of architectural
simulation, and we hope that this work can continue to grow and to serve the
community well.

## References

  * [1] S. Pugsley, A. Alameldeen, H. Kim, and C. Wilkerson, “The second data prefetching championship,” 2015.
  * [2] S. McFarling, “Combining branch predictors,” Citeseer, Tech. Rep., 1993.
  * [3] C.-K. Luk, R. Cohn, R. Muth, H. Patil, A. Klauser, G. Lowney, S. Wallace, V. J. Reddi, and K. Hazelwood, “Pin: Building customized program analysis tools with dynamic instrumentation,” in _ACM SIGPLAN Conference on Programming Language Design and Implementation_. Chicago, IL, USA: Association for Computing Machinery, 2005, p. 190–200. [Online]. Available: https://doi.org/10.1145/1065010.1065034
  * [4] D. Bruening, E. Duesterwald, and S. Amarasinghe, “Design and implementation of a dynamic optimization framework for windows,” in _ACM Workshop on Feedback-Directed and Dynamic Optimization_ , 2000.
  * [5] N. Binkert, B. Beckmann, G. Black, S. K. Reinhardt, A. Saidi, A. Basu, J. Hestness, D. R. Hower, T. Krishna, S. Sardashti _et al._ , “The gem5 simulator,” _ACM SIGARCH computer architecture news_ , vol. 39, no. 2, pp. 1–7, 2011.
  * [6] J. Lowe-Power, A. M. Ahmad, A. Akram, M. Alian, R. Amslinger, M. Andreozzi, A. Armejach, N. Asmussen, S. Bharadwaj, G. Black _et al._ , “The gem5 simulator: Version 20.0+,” _CoRR_ , vol. abs/2007.03152, 2020. [Online]. Available: https://arxiv.org/abs/2007.03152
  * [7] B. Villalonga, S. Boixo, B. Nelson, C. Henze, E. Rieffel, R. Biswas, and S. Mandrà, “A flexible high-performance simulator for verifying and benchmarking quantum circuits implemented on real hardware,” _npj Quantum Information_ , vol. 5, no. 1, pp. 1–16, 2019.
  * [8] N. S. Kalani and B. Panda, “Instruction criticality based energy-efficient hardware data prefetching,” _IEEE Computer Architecture Letters_ , vol. 20, no. 2, pp. 146–149, 2021.
  * [9] C. Zhang, Y. Zeng, J. Shalf, and X. Guo, “RnR: A software-assisted record-and-replay hardware prefetcher,” in _IEEE/ACM International Symposium on Microarchitecture_. Virtual Event: Association for Computing Machinery, Oct. 2020, pp. 609–621.
  * [10] J. Kim, E. Teran, P. V. Gratz, D. A. Jiménez, S. H. Pugsley, and C. Wilkerson, “Kill the program counter: Reconstructing program behavior in the processor cache hierarchy,” _SIGPLAN Not._ , vol. 52, no. 4, p. 737–749, apr 2017. [Online]. Available: https://doi.org/10.1145/3093336.3037701
  * [11] J. Kim, S. H. Pugsley, P. V. Gratz, A. N. Reddy, C. Wilkerson, and Z. Chishti, “Path confidence based lookahead prefetching,” in _IEEE/ACM International Symposium on Microarchitecture_. Association for Computing Machinery, Oct. 2016, pp. 1–12.
  * [12] M. Bakhshalipour, M. Shakerinava, P. Lotfi-Kamran, and H. Sarbazi-Azad, “Bingo spatial data prefetcher,” in _IEEE International Symposium on High-Performance Computer Architecture_ , Feb. 2019, pp. 399–411.
  * [13] E. Bhatia, G. Chacon, S. Pugsley, E. Teran, P. V. Gratz, and D. A. Jiménez, “Perceptron-based prefetch filtering,” in _47th ACM/IEEE Annual International Symposium on Computer Architecture_. Phoenix, Arizona: IEEE, Jun. 2019, p. 1–13. [Online]. Available: https://doi.org/10.1145/3307650.3322207
  * [14] H. Wu, K. Nathella, M. Pabst, D. Sunwoo, A. Jain, and C. Lin, “Practical temporal prefetching with compressed on-chip metadata,” _IEEE Transactions on Computers_ , 2021.
  * [15] H. Wu, K. Nathella, J. Pusdesris, D. Sunwoo, A. Jain, and C. Lin, “Temporal prefetching without the off-chip metadata,” in _IEEE/ACM International Symposium on Microarchitecture_. Columbus, OH, USA: Association for Computing Machinery, Oct. 2019, p. 996–1008. [Online]. Available: https://doi.org/10.1145/3352460.3358300
  * [16] H. Wu, K. Nathella, D. Sunwoo, A. Jain, and C. Lin, “Efficient metadata management for irregular data prefetching,” in _47th ACM/IEEE Annual International Symposium on Computer Architecture_. Phoenix, Arizona: IEEE, Jun. 2019, p. 449–461. [Online]. Available: https://doi.org/10.1145/3307650.3322225
  * [17] S. Pakalapati and B. Panda, “Bouquet of instruction pointers: Instruction pointer classifier-based spatial hardware prefetching,” in _47th ACM/IEEE Annual International Symposium on Computer Architecture_. Virtual Event: IEEE, May 2020, pp. 118–131.
  * [18] A. Ros and A. Jimborean, “A cost-effective entangling prefetcher for instructions,” in _48th ACM/IEEE Annual International Symposium on Computer Architecture_. Valencia, Spain: IEEE, Jun. 2021, pp. 99–111.
  * [19] S. Sethumurugan, J. Yin, and J. Sartori, “Designing a cost-effective cache replacement policy using machine learning,” in _IEEE International Symposium on High-Performance Computer Architecture_ , Feb. 2021, pp. 291–303.
  * [20] P.-Y. Péneau, D. Novo, F. Bruguier, L. Torres, G. Sassatelli, and A. Gamatié, “Improving the performance of STT-MRAM LLC through enhanced cache replacement policy,” in _Architecture of Computing Systems_. Springer International Publishing, 2018, pp. 168–180.
  * [21] Y. Deng, J. Yue, Z. Lu, and Y. Zhu, “Efficient hardware-assisted out-place update for persistent memory,” in _Design, Automation, and Test in Europe Conference_ , Virtual Event, Feb. 2021, pp. 507–512.
  * [22] A. Jain and C. Lin, “Rethinking Belady’s algorithm to accommodate prefetching,” in _46th ACM/IEEE Annual International Symposium on Computer Architecture_. Los Angeles, California: IEEE, Jun. 2018, pp. 110–123.
  * [23] G. Vavouliotis, L. Alvarez, B. Grot, D. Jiménez, and M. Casas, “Morrigan: A composite instruction TLB prefetcher,” in _IEEE/ACM International Symposium on Microarchitecture_. Virtual Event: Association for Computing Machinery, Oct. 2021, p. 1138–1153. [Online]. Available: https://doi.org/10.1145/3466752.3480049
  * [24] G. Vavouliotis, L. Alvarez, V. Karakostas, K. Nikas, N. Koziris, D. A. Jiménez, and M. Casas, “Exploiting page table locality for agile TLB prefetching,” in _48th ACM/IEEE Annual International Symposium on Computer Architecture_. Valencia, Spain: IEEE, Jun. 2021, pp. 85–98.
  * [25] C. Lin and S. J. Tarsa, “Branch prediction is not a solved problem: Measurements, opportunities, and future directions,” _CoRR_ , vol. abs/1906.08170, 2019. [Online]. Available: http://arxiv.org/abs/1906.08170
  * [26] T. Asheim, B. Grot, and R. Kumar, “BTB-X: A storage-effective BTB organization,” _IEEE Computer Architecture Letters_ , vol. 20, no. 2, pp. 134–137, 2021.
  * [27] Y. Ishii, J. Lee, K. Nathella, and D. Sunwoo, “Re-establishing fetch-directed instruction prefetching: An industry perspective,” in _IEEE International Symposium on Performance Analysis of Systems and Software_ , Virtual Event, Mar. 2021, pp. 172–182.
  * [28] P. Kumar, C. S. Yashavant, and B. Panda, “DAMARU: A denial-of-service attack on randomized last-level caches,” _IEEE Computer Architecture Letters_ , vol. 20, no. 2, pp. 138–141, 2021.
  * [29] E. C. Barboza, S. Jacob, M. Ketkar, M. Kishinevsky, P. Gratz, and J. Hu, “Automatic microprocessor performance bug detection,” in _IEEE International Symposium on High-Performance Computer Architecture_ , Feb. 2021, pp. 545–556.
  * [30] Z. Shi, X. Huang, A. Jain, and C. Lin, “Applying deep learning to the cache replacement problem,” in _IEEE/ACM International Symposium on Microarchitecture_. Columbus, OH, USA: Association for Computing Machinery, Oct. 2019, p. 413–425. [Online]. Available: https://doi.org/10.1145/3352460.3358319
  * [31] P. V. Gratz, J. Kim, G. Chacon, A. Alameldeen, C. Wilkerson, S. Pugsley, A. Jaleel, B. Falsafi, M. Sutherland, and J. Picorel, “The second cache replacement championship,” 2017.
  * [32] S. Pugsley, A. Alameldeen, and M. Ferdman, “The third data prefetching championship,” 2017.
  * [33] S. Pugsley, A. Alameldeen, M. Al-otoom, and H. Zhou, “The first instruction prefetching championship,” 2020.
  * [34] A. Jain and Q. Duong, “Ml-based data prefetching competition,” 2021.
  * [35] A. Akram and L. Sawalha, “A survey of computer architecture simulation techniques and tools,” _IEEE Access_ , vol. 7, pp. 78 120–78 145, 2019\.
  * [36] H. Brais, R. Kalayappan, and P. R. Panda, “A survey of cache simulators,” _ACM Comput. Surv._ , vol. 53, no. 1, Feb. 2020. [Online]. Available: https://doi.org/10.1145/3372393
  * [37] Hpsresearchgroup, “hpsresearchgroup/scarab: Joint hps and eth repository to work towards open sourcing scarab and ramulator.” [Online]. Available: https://github.com/hpsresearchgroup/scarab
  * [38] Y. Kim, W. Yang, and O. Mutlu, “Ramulator: A fast and extensible dram simulator,” _IEEE Computer Architecture Letters_ , vol. 15, no. 1, 2016.
  * [39] A. A. Gubran and T. M. Aamodt, “Emerald: Graphics modeling for SoC systems,” in _47th ACM/IEEE Annual International Symposium on Computer Architecture_. Phoenix, Arizona: IEEE, Jun. 2019, p. 169–182. [Online]. Available: https://doi.org/10.1145/3307650.3322221
  * [40] Y. S. Shao, S. L. Xi, V. Srinivasan, G.-Y. Wei, and D. Brooks, “Co-designing accelerators and SoC interfaces using gem5-aladdin,” in _IEEE/ACM International Symposium on Microarchitecture_. Association for Computing Machinery, Oct. 2016.
  * [41] J. Power, J. Hestness, M. S. Orr, M. D. Hill, and D. A. Wood, “gem5-gpu: A heterogeneous CPU-GPU simulator,” _IEEE Computer Architecture Letters_ , vol. 14, no. 1, pp. 34–36, 2015.
  * [42] Y. M. Qureshi, W. A. Simon, M. Zapater, K. Olcoz, and D. Atienza, “Gem5-X, a many-core heterogeneous simulation platform for architectural exploration and optimization,” _ACM Transactions on Architecture and Code Optimization_ , vol. 18, no. 4, pp. 1–27, Dec. 2021. [Online]. Available: https://doi.org/10.1145/3461662
  * [43] D. Sanchez and C. Kozyrakis, “Zsim: Fast and accurate microarchitectural simulation of thousand-core systems,” in _40th ACM/IEEE Annual International Symposium on Computer Architecture_. Tel-Aviv, Israel: IEEE, Jun. 2013, p. 475–486. [Online]. Available: https://doi.org/10.1145/2485922.2485963
  * [44] T. E. Carlson, W. Heirman, and L. Eeckhout, “Sniper: Exploring the level of abstraction for scalable and accurate parallel multi-core simulation,” in _International Conference for High Performance Computing, Networking, Storage and Analysis_. Seattle, Washington: Association for Computing Machinery, 2011. [Online]. Available: https://doi.org/10.1145/2063384.2063454
  * [45] J. E. Miller, H. Kasture, G. Kurian, C. Gruenwald, N. Beckmann, C. Celio, J. Eastep, and A. Agarwal, “Graphite: A distributed parallel simulator for multicores,” in _IEEE International Symposium on High-Performance Computer Architecture_ , Jan. 2010, pp. 1–12.


# Modified gauge unfixing formalism and gauge symmetries in the non-
commutative chiral bosons theory

Cleber N. Costa<EMAIL_ADDRESS>Departamento de Física, Universidade
Federal de Juiz de Fora, Juiz de Fora - 36036-330, MG, Brazil  Gabriella V.
Ambrósio<EMAIL_ADDRESS>Departamento de Física, Universidade
Federal de Juiz de Fora, Juiz de Fora - 36036-330, MG, Brazil  Paulo R. F.
Alves<EMAIL_ADDRESS>Departamento de Física, Universidade Federal de
Juiz de Fora, Juiz de Fora - 36036-330, MG, Brazil  Jorge Ananias Neto
<EMAIL_ADDRESS>Departamento de Física, Universidade Federal de Juiz de
Fora, Juiz de Fora - 36036-330, MG, Brazil  Ronaldo Thibes<EMAIL_ADDRESS>Universidade Estadual do Sudoeste da Bahia, DCEN, Rodovia BR 415, Km 03,
Itapetinga – 45700-000, Brazil  Theoretical Physics Department, CERN, 1211
Geneva 23, Switzerland

###### Abstract

We use the gauge unfixing (GU) formalism framework in a two dimensional
noncommutative chiral bosons (NCCB) model to disclose new hidden symmetries.
That amounts to converting a second-class system to a first-class one without
adding any extra degrees of freedom in phase space. The NCCB model has two
second-class constraints – one of them turns out as a gauge symmetry generator
while the other one, considered as a gauge-fixing condition, is disregarded in
the converted gauge-invariant system. We show that it is possible to apply a
conversion technique based on the GU formalism direct to the second-class
variables present in the NCCB model, constructing deformed gauge-invariant GU
variables, a procedure which we name here as modified GU formalism. For the
canonical analysis in noncommutative phase space, we compute the deformed
Dirac brackets between all original phase space variables. We obtain two
different gauge invariant versions for the NCCB system and, in each case, a GU
Hamiltonian is derived satisfying a corresponding first-class algebra.
Finally, the phase space partition function is presented for each case
allowing for a consistent functional quantization for the obtained gauge-
invariant NCCB.

Gauge invariance, noncommutative chiral bosons, modified gauge unfixing
formalism

##  I Introduction

In the last decades, chiral bosons (CB) field theory has drawn a lot of
interest in the physics community Chizhov:2008tp ; Mezincescu:2022hnb ;
Ouyang:2020rpq ; Siegel:1983es ; Green:1987sp ; bar ; Shukla:2013baa ; bw ;
jsonne ; Giaccari:2008zx ; Bastianelli:1989cu ; Wang:2018dua ; Wen:1990se ;
Upadhyay:2011ph ; Srivastava:1999ym ; Srivastava:2002mw ; fj ; Amorim:1995tk ;
McCabe:1990ge ; Girotti:1988ua ; Rahaman:2016ofe . Additionaly to its own
relevance, CB have been useful for understanding strings, superstrings and
supersymmetry Siegel:1983es ; Green:1987sp ; bar ; Shukla:2013baa , gravity
and supergravity theories bw ; jsonne ; Giaccari:2008zx ; Bastianelli:1989cu ,
black holes Wang:2018dua , fractionary quantum Hall effect Wen:1990se , Hodge
theory Upadhyay:2011ph  and general aspects of field theories in the light
cone Srivastava:1999ym ; Srivastava:2002mw . After the pioneering work by
Siegel Siegel:1983es , in which the self-dual condition first appeared as a
quadratic constraint, Floreaninin and Jackiw introduced a local Lagrangian
density for chiral bosons in which a rich canonical structure was revealed fj
. Despite its initial straightforward simplicity, the description of CB
presents some subtleties Srivastava:2002mw ; fj ; Amorim:1995tk ;
McCabe:1990ge ; Girotti:1988ua ; Rahaman:2016ofe . Among several issues, we
may mention the presence of a single second-class primary constraint with a
non-trivial commutation relation with itself. Therefore CB field theory is not
naturally gauge invariant in its original inception. As it is well-known,
gauge invariant theories hold significant importance regarding its quantum
aspects Thibes:2020jfp , in particular the quantization of first-class systems
is much more easy when compared to second-class theories mes ; Henneaux:1992ig
. In the case of CB field theory, obtaining gauge invariance in a consistent
form is not a simple task and should be handled with extra care. Due to the
presence of an odd number of second-class constraints, in the Floreanini-
Jackiw (FJ) description, usual conversional methods such as standard Batalin-
Fradkin-Tyutin (BFT) or direct gauge-unfixing do not work. An alternative
successful route can be found in reference jplb  where, in order to restore CB
gauge invariance, a particular method employing both BFT and gauge unfixing
ideas was used. It is also worth mentioning the constraint Fourier modes
expansion approach used in Amorim:1994np  to allow for the introduction of BFT
modes.

Over and above that, in the beginning of the current century, there have been
various arguments regarding the possibility of noncommutative effects in high
energy physics Douglas:2001ba ; Konechny:2000dp ; Carmona:2003kh ;
Carmona:2002iv . Relating those two subjects, two extensions of CB field
theory including noncommutative features have been proposed in the literature
Miao:2003ab ; dgms . The first one allows for noncommutativity in space-time
coordinates Miao:2003ab  while the second one introduces noncomutativity
directly into the fields space itself dgms  and has been further investigated
in reference Abreu:2004xe . In the present work, we shall be concerned with
the latter idea, named here for short as Noncommutative Chiral Bosons (NCCB),
in which the quantum operators algebra is deformed in terms of a controlling
noncommutative parameter. The NCCB model, introduced in dgms , connects two FJ
chiral bosons through that noncommutativity parameter, giving rise to
nontrivial commutation relations among the fields in phase space and,
similarly to fj , is characterized as a constrained second-class system
lacking aparent gauge freedom. Due to the interaction between left and right
propagation modes, the original number of constraints doubles, turning more
feasible to look for gauge symmetries generated by constraint abelianization
methods. In fact, a couple of recent articles wkyp ; mvm  analyzed the
canonical structure of the NCCB in the framework of the BFT embedding method,
aiming to promote the NCCB constraints to first-class. The BFT formalism A_10
; A_11 ; A_12  converts second-class constraints into first-class ones by
enlarging the phase space with the introduction of auxiliary fields and has
found many important applications in the literature from which we mention a
short representative sample Amorim:1995sh ; bft1 ; bft2 ; Amorim:1999xr ; bft3
; DeAbreu:2000oil ; bft4 ; Mandal:2022xuw . In wkyp , it is shown that the
direct application of the BFT embedding formalism to the NCCB model may lead
to an infinite amount of auxiliary fields in phase space. With an alternative
choice for the BFT fields symplectic structure, Majid, Vahid and Mehran have
shown in mvm  that it is possible to abelianize the NCCB model in finite
order, reducing the number of auxiliary fields to only two. Nonetheless, we
claim that a consistent NCCB abelianization can be done without the need of
any auxiliary fields whatsoever. That is one of the main advantages of the
gauge-unfixing (GU) method mr ; vyt1 ; vyt2 ; vyt3 ; A_14 ; db ; epl1 ; epl2 ;
proto . Building on the original work of Mitra and Rajaraman mr , which first
conjectured the interpretation of second-class constraints in phase space as
resulting from gauge-fixing conditions within a larger gauge invariant theory,
Anishetty and Vytheeswaran constructed a Lie projection operator whose action
in the second-class functions was able to reveal hidden symmetries vyt1 ; vyt2
; vyt3 . Those ideas were further elaborated to produce the improved or
modified gauge-unfixing formalism A_14 ; db , centered on the construction of
the invariant GU variables, and have found recent appeal in quantum field
theory epl1 ; epl2 ; proto . In this way, the main goal of the present letter
is to develop a gauge invariant theory for the NCCB model, without auxiliary
fields, by directly applying the modified GU formalism A_14 ; db ; epl1 ; epl2
; proto  to the noncommutative fields space.

For the reader’s convenience, we have organized our presentation as follows:
In the next section, we discuss the NCCB model and analyse its constraints
canonical structure with the use of the Dirac-Bergmann formalism Dirac:1950pj
; Anderson:1951ta ; Dirac ; Sundermeyer:1982gv  computing the Dirac brackets
algebra in phase space. In Section 3, we take the opportunity to briefly
review the modified GU formalism preparing its application to the NCCB and
turning the article self-contained. In Section 4, the modified GU formalism is
applied to the NCCB model and we show that it is possible to obtain gauge
invariance without the introduction of auxiliary fields. We close in the last
section with our conclusions and final remarks.

##  II The Noncommutative Chiral Bosons Model

The noncommutative chiral bosons model (NCCB) in $(1+1)$ space-time dimensions
is defined by the first-order action dgms

$S[\phi_{a}]=\int
d^{2}x\left[-\frac{2}{1+\theta^{2}}\dot{\phi}_{a}\Delta_{ab}\phi_{b}^{\prime}-\phi_{a}^{\prime}\phi_{a}^{\prime}\right]\,,$
(1)

where $\theta$ denotes a noncommutative parameter and $\Delta_{ab}$ is an
invertible symmetric $2\times 2$ matrix given by

$\Delta_{ab}=\frac{1}{2}\begin{pmatrix}-1&\theta\\\ \theta&1\end{pmatrix}\,.$

The Latin indexes $a,b$ run through $1,2$ and the dynamics resulting from (1)
describes two chiral bosons $\phi_{1}$ and $\phi_{2}$ coupled by the
noncommutative parameter $\theta$. In fact, the field equations directly
derived from the minimum action principle applied to $S[\phi_{a}]$ read

$2\frac{\Delta_{ab}}{1+\theta^{2}}\dot{\phi}_{b}^{\prime}+\phi_{a}^{\prime\prime}=0\,,$
(2)

and, alternatively, can be cast into the form

$\dot{\phi}_{a}^{\prime}+2\Delta_{ab}\phi_{b}^{\prime\prime}=0\,.$ (3)

In the limit $\theta\rightarrow 0$, the left and right modes decouple and we
recover the usual commutative case consisting of two independent chiral bosons
fj ; Amorim:1995tk . It is interesting to notice that the non-commutative
parameter $\theta$ leads to an enhancement of the speed of light concerning
the two chiral bosons propagation. This can be seen from the fact that the
equations of motion (3) are equivalent to the pair

$\displaystyle\dot{\phi}_{1}^{\prime}$
$\displaystyle=~{}\phi_{1}^{\prime\prime}-\theta\phi_{2}^{\prime\prime}\,,$
(4) $\displaystyle\dot{\phi}_{2}^{\prime}$
$\displaystyle=-\phi_{2}^{\prime\prime}-\theta\phi_{1}^{\prime\prime}\,,$

which in turn, by space integration and time derivation, result in

$\Box_{\theta}\phi_{1}=\Box_{\theta}\phi_{2}=0\,,$ (5)

where $\Box_{\theta}$ denotes the $\theta$-dependent noncommutative
D’Alembertian operator defined as

$\Box_{\theta}\equiv\frac{1}{1+\theta^{2}}\partial_{t}^{2}-\partial_{x}^{2}\,.$
(6)

Thus, we see that Lorentz invariance is preserved in noncommutative space, as
long as we redefine the speed of light $c$ as

$c\rightarrow c_{\theta}\equiv c\sqrt{1+\theta^{2}}\,.$ (7)

Due to the presence of constraints, the canonical quantization of the NCCB
must be done carefuly. The action (1) actually corresponds to a singular
Dirac-Bergmann system Dirac:1950pj ; Anderson:1951ta ; Dirac ;
Sundermeyer:1982gv . To see this feature, note that the canonical momenta in
phase space can be written as

$\pi_{a}=-\frac{2}{1+\theta^{2}}\Delta_{ab}\phi_{b}^{\prime}\,.$ (8)

As we can see, Eq. (8) does not involve the fields time derivatives.
Consequently, we have a pair of primary constraints in phase space given by

$\Omega_{a}\equiv\pi_{a}+\frac{2}{1+\theta^{2}}\Delta_{ab}\phi_{b}^{\prime}\,,$
(9)

with corresponding Poisson bracket relations

$\left\\{\,\Omega_{a}(x)\,,\,\Omega_{b}(y)\,\right\\}=\frac{4}{1+\theta^{2}}\Delta_{ab}\delta^{\prime}(x-y)\,.$
(10)

Concerning the dynamical evolution, the Legendre transformation from
configuration to phase space leads to a well defined canonical Hamiltonian
within the primary constraints hypersurface given by

$H=\int dx\,\phi_{a}^{\prime}\phi_{a}^{\prime}$ (11)

and further steps of the Dirac-Bergmann algorithm show the consistent
stability of $\Omega_{a}$ without the need of new constraints. Hence, the
constraints set (9) is complete and the invertibility of Eq. (10) assures the
second-class nature of the system. To obtain the Dirac brackets among the
phase space variables, we note that the antisymmetric inverse of (10) can be
written as

$\left\\{\,\Omega_{a}(x)\,,\,\Omega_{b}(y)\,\right\\}^{-1}=\Delta_{ab}\epsilon(x-y)\,,$
(12)

with $\epsilon(x)$ denoting the antisymmetric unity step function satisfying

$\epsilon(x)=-\epsilon(-x)\,,$ (13)

and

$\epsilon^{\prime}(x)=\delta(x)\,.$ (14)

Eq. (12) represents the functional inverse of (10) in the sense of

$\int
dz\,\left\\{\,\Omega_{a}(x)\,,\,\Omega_{c}(z)\,\right\\}\left\\{\,\Omega_{c}(z)\,,\,\Omega_{b}(y)\,\right\\}^{-1}=\delta_{ab}\delta(x-y)\,,$
(15)

and

$\int
dz\,\left\\{\,\Omega_{a}(x)\,,\,\Omega_{c}(z)\,\right\\}^{-1}\left\\{\,\Omega_{c}(z)\,,\,\Omega_{b}(y)\,\right\\}=\delta_{ab}\delta(x-y)\,.$
(16)

Inserting (12) into the general DB definition

$\\{F,G\\}_{D}=\\{F,G\\}-\int
dzd\bar{z}\,\\{F,\Omega_{a}(z)\\}\\{\Omega_{a}(z),\Omega_{b}(\bar{z})\\}^{-1}\\{\Omega_{b}(\bar{z}),G\\}\,,$
(17)

the fundamental DBs among the phase space variables can be readily computed as

$\\{\phi_{a}(x),\phi_{b}(y)\\}_{D}=\Delta_{ab}\epsilon(x-y)\,,$ (18)
$\\{\phi_{a}(x),\pi_{b}(y)\\}_{D}=\frac{1}{2}\delta_{ab}\delta(x-y)\,,$ (19)

and

$\\{\pi_{a}(x),\pi_{b}(y)\\}_{D}=-\frac{1}{1+\theta^{2}}\Delta_{ab}\partial_{x}\delta(x-y)\,.$
(20)

At this point, the canonical quantization can be pursued by requiring the
associated operators to satisfy commutation relations dictated by the DB
algebra above. Our main goal in the present work, however, is to produce gauge
symmetry for the NCCB model, write down the corresponding quantum generating
functional, and proceed along the lines of the functional quantization
framework. This can be done by means of the modified GU formalism. Indeed, the
second-class property shown by the constraints in Eq. (9) allows us to
directly apply that improved version of the GU formalism considering one of
the constraints as generator of gauge transformations and calculating the GU
variables. In the next section, we give a brief general review of the modified
GU technique, paving the way for its application to the NCCB in the following
one.

##  III Brief Review of the modified GU formalism

The modified gauge unfixing formalism developed by Neto A_14 ; db ; mes ;
proto  is based on the idea of selecting one of the two second-class
constraints to be the gauge symmetry generator and the other one being
discarded in a broader gauge-invariant context. Consider for example a given
second-class phase-space function $T(A_{\mu},\pi_{\mu})$ with the index $\mu$
running through all phase space variables. Our strategy is to write a first-
class function $\tilde{T}({A}_{\mu},{\pi}_{\mu})$ obtained from the second-
class function $T$ as

$\tilde{T}({A}_{\mu},{\pi}_{\mu})\equiv{T}(\tilde{A}_{\mu},\tilde{\pi}_{\mu})\,,$
(21)

by redefining the original phase space variables

$A_{\mu}\longrightarrow\tilde{A}_{\mu}({A}_{\mu},{\pi}_{\mu})\,,$ (22)
$\pi_{\mu}\longrightarrow\tilde{\pi}_{\mu}({A}_{\mu},{\pi}_{\mu})\,,$ (23)

such that

$\displaystyle\delta\tilde{A}_{\mu}=\alpha\left\\{\tilde{A}_{\mu},\psi\right\\}=0\,,$
(24)

and

$\displaystyle\delta\tilde{\pi}_{\mu}=\alpha\left\\{\tilde{\pi}_{\mu},\psi\right\\}=0\,,$
(25)

where $\alpha$ is an infinitesimal parameter and $\psi$ is the second-class
constraint chosen to be the gauge symmetry generator. The deformed variables
$\tilde{A}_{\mu}$, $\tilde{\pi}_{\mu}$ are known as GU variables. It is clear
now that functions of the GU variables, in particular $\tilde{T}$, will be
gauge invariant since

$\displaystyle\left\\{\tilde{T},\psi\right\\}=\left\\{\tilde{A},\psi\right\\}\frac{\partial{T}}{\partial\tilde{A}}+\frac{\partial{T}}{\partial\tilde{\pi}}\left\\{\tilde{\pi},\psi\right\\}=0\,.$
(26)

Consequently, we can obtain a gauge invariant function from the replacement of

$\displaystyle T(A_{\mu},\pi_{\mu})\rightarrow
T(\tilde{A_{\mu}},\tilde{\pi_{\mu}})=\tilde{T}({A_{\mu}},{\pi_{\mu}})\,.$ (27)

Now suppose the system has only two second class constraints $Q_{1}$ and
$Q_{2}$. So, the GU gauge invariant phase space variables, collectively
denoted by $\tilde{\Lambda}\equiv(\tilde{A}_{\mu},\tilde{\pi}_{\mu})$, can be
constructed as a power the series in the discarded constraint $Q_{2}$

$\displaystyle\tilde{\Lambda}(x)=\Lambda(x)+\int dyb_{1}(x,y)Q_{2}(y)+\iint
dydzb_{2}(x,y,z)Q_{2}(y)Q_{2}(z)+...\,,$ (28)

satisfying, on the constraint surface $Q_{2}=0$, the boundary condition

$\displaystyle{\tilde{\Lambda}}_{\big{|}Q_{2}=0}=\Lambda\,.$ (29)

This assures that we recover the original second-class system when $Q_{2}=0$.
The coefficients $b_{n}$ in relation (28) are then determined by the GU
invariant requirement

$\delta\tilde{\Lambda}=\alpha\left\\{\tilde{\Lambda},Q_{1}\right\\}=0\,.$ (30)

The general equation for $b_{n}$ is

$\displaystyle\delta\tilde{\Lambda}(x)=\delta\Lambda(x)+\delta\int
dyb_{1}(x,y)Q_{2}(y)+\delta\iint dydzb_{2}(x,y,z)Q_{2}(y)Q_{2}(z)+...=0\,,$
(31)

in which we have

$\displaystyle\delta\Lambda(x)=\int
dy\,\alpha(y)\left\\{\Lambda(x),\psi(y)\right\\},$ (32) $\displaystyle\delta
b_{1}(x)=\int dy\,\alpha(y)\left\\{b_{1}(x),\psi(y)\right\\},$ (33)
$\displaystyle\delta Q_{2}(x)=\int
dy\,\alpha(y)\left\\{Q_{2}(x),\psi(y)\right\\}\,.$ (34)

So, for the first order correction term $(n=1)$ we have from Eq. (31)

$\displaystyle\delta\Lambda(x)+\int dyb_{1}(x,y)\delta Q_{2}(y)=0\,.$ (35)

From Eq. (35) we can determine the coefficient $b_{1}$. For the second order
correction term $(n=2)$ we have

$\displaystyle\int dy\delta b_{1}(x,y)Q_{2}(y)+2\iint dydzb_{2}(x,y,z)\delta
Q_{2}(y)Q_{2}(z)=0\,.$ (36)

Then, from Eq. (36) we can determine the coefficient $b_{2}$ and so on and so
forth. Therefore, from the GU variables power series defined in Eq. (28) we
can derive a corresponding gauge invariant theory.

##  IV Disclosing hidden symmetries

In this section, we apply the modified GU formalism to the NCCB. As we have
seen, the NCCB has two second-class constraints given by Eq. (9). Writting
them out explicitly in terms of the components of $\Delta_{ab}$, we have

$\displaystyle\Omega_{1}=\pi_{1}-\frac{\phi^{\prime}_{1}}{1+\theta^{2}}+\frac{\theta\,\phi^{\prime}_{2}}{1+\theta^{2}}\,,$
(37)
$\displaystyle\Omega_{2}=\pi_{2}+\frac{\theta\,\phi^{\prime}_{1}}{1+\theta^{2}}+\frac{\phi^{\prime}_{2}}{1+\theta^{2}}\,.$
(38)

Then, following the ideas of the modified GU formalism, one of the two second-
class constraints will be chosen to be the gauge symmetry generator and the
other one will be discarded. Thus, two possible choices for the gauge symmetry
generator for the NCCB are possible. We consider below each of these two
different cases separately.

###  IV.1 Case A

In this first case, we consider the constraint $\Omega_{1}$, Eq. (37), as the
gauge symmetry generator and discard the other second-class constraint
$\Omega_{2}$, Eq. (38). The $\varepsilon$-infinitesimal gauge transformations
generated by $\Omega_{1}$ are given by

$\displaystyle\delta\phi_{1}$ $\displaystyle=\int
dy\,\alpha(y)\,\\{\phi_{1},\Omega_{1}(y)\\}=\alpha\,,$ (39)
$\displaystyle\delta\phi_{2}$ $\displaystyle=\int
dy\,\alpha(y)\,\\{\phi_{2},\Omega_{1}(y)\\}=0\,,$ (40)
$\displaystyle\delta\pi_{1}$ $\displaystyle=\int
dy\,\alpha(y)\,\\{\pi_{1},\Omega_{1}(y)\\}=-\frac{1}{1+\theta^{2}}\,\alpha^{\prime}\,,$
(41) $\displaystyle\delta\pi_{2}$ $\displaystyle=\int
dy\,\alpha(y)\,\\{\pi_{2},\Omega_{1}(y)\\}=\frac{\theta}{1+\theta^{2}}\,\alpha^{\prime}\,,$
(42)

while the constraint $\Omega_{2}$ transforms under $\Omega_{1}$ as

$\displaystyle\delta\Omega_{2}$ $\displaystyle=\int
dy\,\alpha(y)\,\\{\Omega_{2},\Omega_{1}(y)\\}=\frac{2\theta}{1+\theta^{2}}\,\alpha^{\prime}\,.$
(43)

Since the fields $\phi_{1},\pi_{1}$ and $\pi_{2}$ are not naturally gauge
invariant under $\Omega_{1}$, following the improved GU approach, we need to
construct their GU invariant combinations in terms of a power series in
$\Omega_{2}$. For instance, the first gauge invariant GU variable
$\tilde{\phi}_{1}$ can be written as

$\displaystyle\tilde{\phi}_{1}(x)=\phi_{1}(x)+\int
dyb_{1}(x,y)\,\Omega_{2}(y)+\int
dydzb_{2}(x,y,z)\,\Omega_{2}(y)\Omega_{2}(z)+...\,,$ (44)

with the correction coefficient functions $b_{n}$ to be calculated from the
invariant condition $\delta\tilde{\phi}_{1}=0$. For the linear correction term
$(n=1)$, we have

$\displaystyle\delta\phi_{1}+\int dyb_{1}(x,y)\delta\Omega_{2}(y)=0\,,$ (45)

and, plugging Eqs. (39) and (43) into (45), we obtain

$\displaystyle b_{1}(x,y)=-\frac{1+\theta^{2}}{2\theta}\epsilon(x-y)\,.$ (46)

For the quadratic term we have $b_{2}=0$ and thus, for $n\geq 2$, all the
remaining correction coefficient functions $b_{n}$ are null. Taking this into
consideration and inserting Eq. (46) in (44), we obtain the final expression
for the first gauge-invariant GU variable $\tilde{\phi}_{1}$ as

$\tilde{\phi}_{1}(x)=\phi_{1}(x)-\frac{1+\theta^{2}}{2\theta}\int
dy\epsilon(x-y)\Omega_{2}(y)\,.$ (47)

Repeating this same iterative process, in a similar fashion, we can derive the
remaining gauge-invariant GU variables in phase space as

$\displaystyle\tilde{\phi}_{2}$ $\displaystyle=$ $\displaystyle\phi_{2}\,,$
(48) $\displaystyle\tilde{\pi}_{1}$ $\displaystyle=$
$\displaystyle\pi_{1}+\frac{1}{2\theta}\,\Omega_{2}\,,$ (49)
$\displaystyle\tilde{\pi}_{2}$ $\displaystyle=$
$\displaystyle\pi_{2}-\frac{1}{2}\,\Omega_{2}\,.$ (50)

Differentiating with respect to space, from Eqs. (47) and (48), we have the
further useful relations

$\displaystyle\tilde{\phi}^{\prime}_{1}$ $\displaystyle=$
$\displaystyle\phi^{\prime}_{1}-\frac{1+\theta^{2}}{2\theta}\Omega_{2}\,,$
(51) $\displaystyle\tilde{\phi}^{\prime}_{2}$ $\displaystyle=$
$\displaystyle\phi^{\prime}_{2}\,.$ (52)

By construction, as seen in the previous section, any function of the GU
variables is automatically gauge-invariant. In particular, the gauge-invariant
GU Hamiltonian can be directly obtained from Eq. (11) as

$\displaystyle\tilde{H}=\int
dx\left[\left(\phi^{\prime}_{1}-\frac{1+\theta^{2}}{2\theta}\,\Omega_{2}\right)^{2}+\phi^{\prime}_{2}\phi^{\prime}_{2}\right]\,,$
(53)

and satisfies the gauge-invariant condition $\\{\tilde{H},\Omega_{1}\\}=0$.
Due to its gauge invariance, the GU Hamiltonian can be used to obtain the
phase space partition function in the functional quantization approach fad  as

$Z=\int{\cal{D}}\phi_{1}{\cal{D}}\pi_{1}{\cal{D}}\phi_{2}{\cal{D}}\pi_{2}\,\delta(\Omega_{1})\delta(\Gamma_{1})\,det|\\{\Omega_{1},\Gamma_{1}\\}|e^{iS}\,,$
(54)

where $\Gamma_{1}$ denotes a suitable gauge-fixing condition and

$\displaystyle S=\int
d^{2}x\left(\pi_{1}\dot{\phi}_{1}+\pi_{2}\dot{\phi}_{2}-\tilde{H}\right)\,.$
(55)

Concerning gauge achievability, the gauge fixing function $\Gamma_{1}$ must be
chosen in such a way that the determinant in the integration measure in (54)
does not vanish. This concludes the functional quantization of the gauge-
invariant description of the NCCB, with gauge transformations generated by
$\Omega_{1}$.

###  IV.2 Case B

Next, we consider the other possible choice for the gauge symmetry generator.
Let now $\Omega_{2}$ generate the gauge symmetries, certainly different from
the ones in case A, while the constraint $\Omega_{1}$ is discarded. The
infinitesimal gauge transformations generated by $\Omega_{2}$ read

$\displaystyle\delta\phi_{1}$ $\displaystyle=0\,,$ (56)
$\displaystyle\delta\phi_{2}$ $\displaystyle=\int
dy\,\alpha(y)\,\\{\phi_{2},\Omega_{2}(y)\\}=\alpha\,,$ (57)
$\displaystyle\delta\pi_{1}$ $\displaystyle=\int
dy\,\alpha(y)\,\\{\pi_{1},\Omega_{2}(y)\\}=\frac{\theta}{1+\theta^{2}}\alpha^{\prime}\,,$
(58) $\displaystyle\delta\pi_{2}$ $\displaystyle=\int
dy\,\alpha(y)\,\\{\pi_{2},\Omega_{2}(y)\\}=\frac{1}{1+\theta^{2}}\alpha^{\prime}\,,$
(59) $\displaystyle\delta\Omega_{1}$ $\displaystyle=\int
dy\,\alpha(y)\,\\{\Omega_{1},\Omega_{2}(y)\\}=\frac{2\theta}{1+\theta^{2}}\,\alpha^{\prime}\,.$
(60)

Eq. (56) shows that $\phi_{1}$ is already gauge invariant under
transformations generated by $\Omega_{2}$, thus

$\tilde{\phi}_{1}=\phi_{1}\,.$

The gauge invariant field $\tilde{\phi_{2}}$ is constructed as

$\displaystyle\tilde{\phi}_{2}=\phi_{2}+\int dyc_{1}(x,y)\,\Omega_{1}(y)+\int
dydzc_{2}(x,y,z)\,\Omega_{1}(y)\Omega_{1}(z)+...\,.$ (61)

Now, imposing the gauge-invariant condition $\delta\tilde{\phi}_{2}=0$, the
correction terms $c_{n}$ can be obtained. For the linear correction term
$(n=1)$, we have

$\displaystyle\delta\phi_{2}(x)+\int dyc_{1}(x,y)\delta\Omega_{1}(y)=0\,.$
(62)

Using Eqs. (57) and (60) we find

$\displaystyle c_{1}(x,y)=-\frac{1+\theta^{2}}{2\theta}\epsilon(x-y)\,.$ (63)

It is easy to see that the variation of $c_{1}$ leads to $c_{2}=0$. Then, for
$n\geq 2$, all correction terms $c_{n}$ are null. Therefore, by putting Eq.
(63) into Eq. (61), the GU variable $\tilde{\phi}_{2}$ acquires the form

$\displaystyle\tilde{\phi}_{2}=\phi_{2}-\frac{1+\theta^{2}}{2\theta}\int
dy\epsilon(x-y)\Omega_{1}(y)\,.$

The remaining GU variables can be obtained by the same iterative process.
Proceeding this way and putting all GU variables together we have

$\displaystyle\tilde{\phi}_{1}$ $\displaystyle=\phi_{1}\,,$ (64)
$\displaystyle\tilde{\phi}_{2}$
$\displaystyle=\phi_{2}-\frac{1+\theta^{2}}{2\theta}\int
dy\epsilon(x-y)\Omega_{1}(y)\,,$ (65) $\displaystyle\tilde{\pi}_{1}$
$\displaystyle=\pi_{1}-\frac{1}{2}\,\Omega_{1}\,,$ (66)
$\displaystyle\tilde{\pi}_{2}$
$\displaystyle=\pi_{2}-\frac{1}{2\theta}\,\Omega_{1}\,.$ (67)

From Eqs. (64) and (65), it immediately follows

$\displaystyle\tilde{\phi}^{\prime}_{1}$ $\displaystyle=$
$\displaystyle\phi^{\prime}_{1}\,$ (68)
$\displaystyle\tilde{\phi}^{\prime}_{2}$ $\displaystyle=$
$\displaystyle\phi^{\prime}_{2}-\frac{1+\theta^{2}}{2\theta}\,\Omega_{1}\,.$
(69)

Now we are able to write the gauge invariant version of the Hamiltonian (11).
Substituting Eqs. (68) and (69) into (11) we have

$\displaystyle\tilde{H}=\int
dx\left[\left(\phi^{\prime}_{2}-\frac{1+\theta^{2}}{2\theta}\,\Omega_{1}\right)^{2}+\phi^{\prime}_{1}\phi^{\prime}_{1}\right]\,.$
(70)

By construction, the GU Hamiltonian, $\tilde{H}$, satisfies the condition
$\\{\tilde{H},\Omega_{2}\\}=0$.

As was done in case A, given the gauge invariant Hamiltonian, we can derive
the phase space partition function

$\displaystyle
Z=\int{\cal{D}}\phi_{1}{\cal{D}}\pi_{1}{\cal{D}}\phi_{2}{\cal{D}}\pi_{2}\,\delta(\Omega_{2})\delta(\Gamma_{2})\,det|\\{\Omega_{2},\Gamma_{2}\\}|e^{iS}\,,$
(71)

where

$\displaystyle S=\int
d^{2}x\left(\pi_{1}\dot{\phi}_{1}+\pi_{2}\dot{\phi}_{2}-\tilde{H}\right)\,,$
(72)

with the Hamiltonian density $\tilde{H}$ given by Eq. (70). The gauge fixing
condition $\Gamma_{2}$ is chosen so that the determinant appearing in the
functional measure is nonvanishing. In both cases A and B, we were able to
obtain a gauge-invariant version for the NCCB model.

##  V Conclusions

In this work, we have converted the NCCB model into a first-class constrained
system using a modified GU formalism, whose convenience lies on the freedom of
choice of the gauge symmetry generator and on the redefinition of the phase
space itself without using any extra variables. One of the constraints becomes
the generator of gauge symmetries and the other one is discarded. Such
ambiguity allowed us to obtain two gauge invariant systems consistent with the
original second-class one, which can be recovered back in a straightforward
manner by setting the discarded constraint equal to zero. In case A, the
constraint $\Omega_{1}$, Eq. (37), was chosen in order to be the gauge
symmetries generator, while in case B the constraint $\Omega_{2}$, Eq. (38),
was selected to be the generator of gauge symmetries. We can note that the
canonical structure acquired from the modified GU formalism, for both cases,
is similar to those obtained from other approaches. It is worth mentioning the
non-local form derived for the fields $\tilde{\phi}_{1}$, in case A, and
$\tilde{\phi}_{2}$, in case B, characterized by the presence of the
antisymmetric step function $\epsilon(x-y)$ in their expressions, since non-
locality can also be generated from noncommutative field theories. Here, we
can state that the GU variables are dictating the rules for obtaining a gauge
theory from a second-class constrained system. Thus, as has become clear
throughout our work, once GU variables are computed the corresponding gauge
theory is obtained consistently and in a very simple way.

##  VI Acknowledgments

The authors sincerely thank Nikoofard Vahid for useful comments. RT kindly
thanks the CERN Theoretical Physics Department (CERN-TH) for hospitality in a
insightful research environment. The CAPES (Coordenação de Aperfeiçoamento de
Pessoal de Nível Superior) and FAPEMIG (Fundação de Amparo à Pesquisa do
Estado de Minas Gerais) are ackknowledged for financial support. Jorge Ananias
Neto thanks CNPq (Conselho Nacional de Desenvolvimento Científico e
Tecnológico), Brazilian scientific support federal agency, for partial
financial support, CNPq-PQ, Grant number 307153/2020-7.

## References

  * (1) M. V. Chizhov, V. A. Bednyakov and J. A. Budagov, Phys. Atom. Nucl. 71, 2096 (2008).
  * (2) L. Mezincescu and P. K. Townsend, JHEP 07, 142 (2022).
  * (3) H. Ouyang and H. Shu, Eur. Phys. J. C 80, no.12, 1155 (2020).
  * (4) W. Siegel, Nucl. Phys. B 238, 307 (1984).
  * (5) M. B. Green, J. H. Schwarz and E. Witten, “Superstring Theory” (Cambridge U.P. Cambridge, 1987).
  * (6) J. Barcelos-Neto, P. P. Srivastava, Phys. Lett. B 259, 456 (1991).
  * (7) D. Shukla, T. Bhanja and R. P. Malik, Eur. Phys. J. C 74, 3025 (2014).
  * (8) N. R. F. Braga and C. Wotzasek, Mod. Phys. Lett. A 10, 173 (1995).
  * (9) J. Sonnenschein, Nucl. Phys. B 309, 752 (1988).
  * (10) S. Giaccari and P. Menotti, Phys. Rev. D 79, 065015 (2009).
  * (11) F. Bastianelli and P. van Nieuwenhuizen, Phys. Lett. B 217, 98 (1989).
  * (12) J. Wang, Phys. Lett. B 792, 56 (2019).
  * (13) X. G. Wen, Phys. Rev. B 41, 12838 (1990).
  * (14) S. Upadhyay and B. P. Mandal, Eur. Phys. J. C 71, 1759 (2011).
  * (15) P. P. Srivastava, SLAC-PUB-8252 [arXiv:hep-ph/9909412 [hep-ph]] (1999).
  * (16) P. P. Srivastava and S. J. Brodsky, Phys. Rev. D 66, 045019 (2002).
  * (17) R. Floreanini and R. Jackiw, Phys. Rev. Lett. 59, 1873 (1987).
  * (18) R. Amorim and J. Barcelos-Neto, Z. Phys. C 68, 513 (1995).
  * (19) J. McCabe, Phys. Lett. B 242, 198 (1990).
  * (20) H. O. Girotti, M. Gomes, V. Kurak, V. O. Rivelles and A. J. da Silva, Phys. Rev. Lett. 60, 1913 (1988).
  * (21) A. Rahaman and S. Yasmin, Annals Phys. 383, 497 (2017).
  * (22) R. Thibes, Eur. J. Phys. 41, no.5, 055203 (2020).
  * (23) M. Monemzadeh, A. S. Ebrahimi and S. Sramadi, Mod. Phys. Lett. A 29 (5), 1450028 (2014).
  * (24) M. Henneaux and C. Teitelboim, “Quantization of gauge systems,” Princeton, USA: Univ. Pr. (1992).
  * (25) J. Ananias Neto, Phys. Lett. B 571, 195 (2003).
  * (26) R. Amorim and J. Barcelos-Neto, Phys. Lett. B 333, 413 (1994).
  * (27) M. R. Douglas and N. A. Nekrasov, Rev. Mod. Phys. 73, 977 (2001).
  * (28) A. Konechny and A. S. Schwarz, Phys. Rept. 360, 353 (2002).
  * (29) J. M. Carmona, J. L. Cortes, J. Gamboa and F. Mendez, JHEP 03, 058 (2003).
  * (30) J. M. Carmona, J. L. Cortes, J. Gamboa and F. Mendez, Phys. Lett. B 565, 222 (2003).
  * (31) Y. G. Miao, H. J. W. Muller-Kirsten and D. K. Park, JHEP 08, 038 (2003).
  * (32) A. K. Das, J. Gamboa, F. Mendez and J. Lopez-Sarrion, JHEP 05, 022 (2004).
  * (33) E. M. C. Abreu, R. Menezes and C. Wotzasek, Phys. Rev. D 71, 065004 (2005).
  * (34) W. Kim, Y. J. Park, H. Shin and M. S. Yoon, Phys. Rev. D 75, 087702 (2007).
  * (35) M. Majid, N. Vahid and T. Mehhan, Commun. Theor. Phys. 54, 1067 (2010).
  * (36) L. D. Faddeev and S. L. Shatashvili, Physics Letters B, 167, 225 (1986).
  * (37) I. A. Batalin and E. S. Fradkin. Phys. Lett. B 180 (1986) 157.
  * (38) I. A. Batalin and I. V. Tyutin, Int. Jour. Mod. Phys. A 6, 3255 (1991).
  * (39) R. Amorim, L. E. S. Souza and R. Thibes, Z. Phys. C 65, 355 (1995).
  * (40) N. Banerjee and J. Barcelos-Neto, Nucl. Phys. B 499, 453 (1997).
  * (41) Wilson Oliveira and Jorge Ananias Neto, Nucl. Phys. B 533, 611 (1998).
  * (42) R. Amorim and R. Thibes, J. Math. Phys. 40, 5306 (1999).
  * (43) C. P. Natividade, H. Boschi-Filho and L. V. Belvedere, MPLA 19, 2957 (2004).
  * (44) E. M. C. Abreu, J. Ananias Neto, A. C. R. Mendes and G. Oliveira-Neto, Int. J. Mod. Phys. A 31, no.01, 1550225 (2016).
  * (45) V. K. Pandey and R. Thibes, MPLA 37, 2250086 (2022).
  * (46) B. P. Mandal, V. K. Pandey and R. Thibes, Nucl. Phys. B 982, 115905 (2022).
  * (47) P. Mitra and R. Rajaraman, Ann. Phys. 203, 157 (1990).
  * (48) R. Anishetty and A. S. Vytheeswaran, J. Phys A. 26 (1993) 5613.
  * (49) A. S. Vytheeswaran, J. Phys. G19 (1993) 957.
  * (50) A. S. Vytheeswaran, Int. Jour. Mod. Phys. A 17 (2002) 4095.
  * (51) J. Ananias Neto, Braz. J. Phys. 37 (2007) 1106.
  * (52) J. Ananias Neto, “The Gauge Unfixing Formalism and the Solutions of the Dirac Bracket Commutators”, arxiv: 0904.4711v2 (2009).
  * (53) P. R. F. Alves, C. N. Costa, E. M. C. Abreu, Jorge Ananias Neto and Albert C. R. Mendes, EPL (Europhysics Letters) 131, 31004 (2020).
  * (54) G. V. Ambrósio, C. N. Costa, P. R. F. Alves, E. M. C. Abreu, J. Ananias Neto and R. Thibes, EPL (Europhysics Letters) 142, 10002 (2023).
  * (55) J. Ananias Neto, W. D. Morais and R. Thibes, EPL (Europhysics Letters) 141, 22001 (2023).
  * (56) P. A. M. Dirac, Can. J. Math. 2, 129 (1950).
  * (57) J. L. Anderson and P. G. Bergmann, Phys. Rev. 83, 1018 (1951).
  * (58) P. A. M. Dirac, “Lectures on Quantum Mechanics”, Belfer Graduate School of Science Monographs No. 2, Yeshiva University, New York (1964).
  * (59) K. Sundermeyer, “Constrained Dynamics with Applications to Yang-mills Theory, General Relativity, Classical Spin, Dual String Model,” Lect. Notes Phys. 169, 1 (1982).
  * (60) L. D. Faddeev and V. N. Popov, Phys. Lett. B25, 29 (1967).