Just back from ARITH 2026 in Fulda, Germany, where they introduced a new Tutorial Day! Together, Louis and I, gave the attendees first a brief introduction to MLIR and CIRCT, then got them working hands-on building, optimizing and verifying ASIC hardware designs.
If you want to have a go at home, all the tutorial materials can be found in our public repo. To play through the tutorial, you’ll need to use either a docker build or the VScode dev-containers extension. The goal was to give researchers and industrial engineers a short teaser of the various CIRCT capabilities, people seemed to find it interesting at least, and potentially even useful.
In this blog post I’ll give a short description of CIRCT and describe the features we presented (that way you can decide if you should care or not…).

What is CIRCT?

CIRCT (Circuit IR Compilers and Tools) is an open-source compiler infrastructure project for digital hardware design. It provides reusable compiler dialects, optimizations, and passes built on MLIR. CIRCT enables hardware designers and compiler developers to express, transform, and generate circuit representations for FPGAs, ASICs, and other digital systems.

Key Features:

• A hardware-centered IR and dialect ecosystem for digital circuit design.
• Reusable passes for lowering, verification, and code generation.
• Integration with MLIR and LLVM for compiler-based hardware flows.
• Support for multiple input formats and backends, including FIRRTL, HW, and system-level representations.

CIRCT Inspiration

• LLVM and MLIR: using compiler infrastructure patterns to make hardware transformation passes composable.
• Hardware description languages like Chisel.
• The desire to unify hardware and software compiler techniques in a shared framework.

CIRCT aims to make hardware compiler development more agile, enabling researchers and engineers to experiment with new optimizations and hardware dialects.

Tutorial Content

The tutorial introduces a range of different tools and optimization passes that can be used to synthesize and verify combinational circuit designs expressed in System Verilog. First you’ll compile a Verilog design with circt-verilog, producing a snippet of CIRCT IR, that will look a lot like LLVM/MLIR if you’ve ever worked in these software compiler frameworks.

hw.module @fma(in %a: i4, in %b: i4, in %c: i4, out d: i9){
  %c0_i5 = hw.constant 0 : i5
  %0 = comb.concat %c0_i5, %a : i5, i4
  %1 = comb.concat %c0_i5, %b : i5, i4
  %2 = comb.mul %0, %1 : i9
  %3 = comb.concat %c0_i5, %c : i5, i4
  %4 = comb.add %2, %3 : i9
  hw.output %4 : i9
}

Given some IR, we then move onto optimization which we automate with passes, that literally pass over the IR and make small incremental changes (usually until some fixed point is reached). CIRCT has loads of passes built in, and you apply them using circt-opt. For those wanting to extend CIRCT, a great starting point is trying to extend an existing pass with a new optimization.

Since most ASIC designers, are inherently sceptical (and rightly so), we then describe how one can verify the correctness of the transformation you just applied using circt-lec. The circt-lec tool takes two IR modules and checks that they are logically equivalent by formulating an SMT problem, which can be externally validated with your favourite SMT solver (Z3, Bitwuzla etc). Lastly, for those wanting to integrate into an existing EDA flow, we learn how to generate Verilog using firtool.

In the second part of the tutorial, we focused more on my work developing a datapath synthesis engine for CIRCT. In this part, we introduced circt-synth that leverages redundant number representations to produce realy efficient datapath netlists that can outperform the much more mature Yosys synthesis tool. To give a final flavour of what can be done when combining MLIR and CIRCT, Louis demoed his high-level synthesis flow from Python code to a full chip layout.

Whilst preparaing for the tutorial, I discovered markdown slides in Obsidian, which is why the README is a little terse!

ARITH 2026 Summary

In addition to the tutorials, ARITH is the main venue for research into computer arithmetic. Below is a list of my favourite papers from the conference (all papers are freely available from the ARITH program):

• A Conflict-Aware Learning Approach to SCA Verification for MAC Architectures
  • Hopeful that this might provide a way to verify the outputs of circt-synth much faster!
• Novel Aspects of IEEE SA P3109 Arithmetic Formats for Machine Learning
  • Describing all the details behind the upcoming IEEE standard for AI number formats
• Efficacy of Pipelining to Reduce Energy of Floating-Point Adders and Multipliers
  • An awesome way to visualize the switching and glitch frequency as a function of logical depth

Not available online but Erin Carson’s keynote was also great and raised lots of interesting questions!

Thanks

Huge thanks must go to Anastasia Volkova and Theo Drane who put a lot of effort into organizing both the tutorial day and a demo session during the conference. Martin Kumm and the Fulda team also organized a fantastic conference overall, good culture, good food and good beer the whole way through! Louis Ledoux was a great collaborator on the demo and provided a lot of insights into how far you can take HW design with CIRCT.

The opportunity came about through the 1851 Royal Commission, who support the London Wonder outreach initiative led by the Big Ideas charity. They let me take charge of a 2 hour class, containing 20 year 10 students (usually 14 or 15 years old). Along for the ride we had one Big Ideas co-ordinator, Hayley, and my colleague from UCL Ralph Sarkis.

To start with I shared a little background about how I got into computer chips and why they should care about them (5 mins). Before they got too bored we did a quick 3 question quiz that got them debating with each other.

1. Best selling phone ever? (iPhone 6 or Nokia 1100)
2. What did Nintendo originally make? (Playing cards or Welly Boots)
3. What has more computing power? (iPhone 15 or Apollo 11)

To settle back down, we then did a quick run through of how the CPU is like the computer’s brain that runs on some form of clock (5 mins). This led us nicely into the activity!

The Interactive Activity

How do you make CPUs fun? The advice from Big Ideas was it has got to be interactive but not cost a fortune…

My solution, students would form teams of 5, each working for one of the big chip design companies, and nominate one student to be a CPU. The remaining team members would then write out instructions on sticky notes at each clock cycle and hand them to their CPU to execute. Of course, CPUs can only execute specific instructions, so I devised a custom instruction set architecture (ISA). Specifically, the goal was to produce a bottle of salty squash from a starting bottle containing just water. Their goal was to get as close, in terms of squash colour and salanity, to the target bottle which we showed them right at the start then hid away, in as few cycles as possible.

So what instructions was the CPU allowed to execute:

1. Collect ?? ml/grams of squash/salt [2 cycles]
2. Remove/Replace bottle lid [1 cycle]
3. Add squash/salt [1 cycle]
4. Shake bottle [2 cycles]
5. Test colour/salinity [2 cycles]
6. Submit [1 cycle]

Once all teams had execute their submit instruction they were ranked from 1st to 4th in three categories.

• Number of cycles
• Squash accuracy (as judged by their teacher)
• Salt accuracy (measured using a refractometer)

This worked rather nicely. Some teams didn’t spend cycles testing their bottle, letting them submit their result much faster. Whilst other teams did spend cycles testing and refining the mixture in their bottles to get a more accurate result. This gave them a bit of a demonstration of the typical accuracy vs performance tradeoffs we experience all the time when designing code/chips.

The great thing about this setup is that we can make a natural progression, just as university students do when they are taught about these concepts. In round 2, teams elected two CPUs and had to produce two bottles of salty squash. This gave them a chance to appreciate parallelism, where they could write instructions for the second CPU whilst their first was busy. In round 3 (which we ran out of time for), we move to compilation, where students need to write out all their instructions ahead of time.

The Good

• Competition: making it competitive seemed to make the students very invested
• Getting their teacher involved: I asked their teacher to judge the squash rankings which proved a source of contention and lots of laughter, my apologies to setting the teacher involved to be like a football referee
• Chaos: the activity was chaotic but perhaps just the right level, the vast majority of students seemed very engaged

The Bad

• Keeping track of the clock: many teams weren’t quite in sync - a new mechanism rather than me calling out clock cycles is needed
• Dispensing: distributing the salt and the squash was time consuming - having set amounts pre-measured would have helped greatly

Conclusions

I was really worried this wouldn’t work, but was shocked when the students really engaged. My favourite student comment overheard by Hayley, “I thought this was going to be dead, but it was actually pretty lit”. Not every student engaged, but at least 15 out of the 20 got really into the activity and seemed to take away something from it. So it was far from perfect, but with some refinement I think the core concept is pretty ideal! Huge thanks to Ralph, Hayley and Sam from Big Ideas who helped make it happen.

You can find the slides here in case any teachers or engineers want to try out the activity in a classroom.

More often than not the goal of electronic design automation (EDA) tools is to optimize a given circuit design. One of the key mechanisms they use is rewriting, namely searching for a smaller circuit within our given design that matches some specific strucutre and replacing it with a more efficient implementation. A classic example is replacing x*2 by x << 1, as the shift circuit is much cheaper than a multiplication.

It is imperative that these rewrites, which are baked into the EDA tools source code, are correct. If the EDA tool contains an incorrect rewrite, it can silently introduce bugs into the circuit design it’s optimizing. Hardware bugs can be extremely costly so are best avoided otherwise you may have very unhappy tool users. What makes this problem tricky, is that EDA rewrites often manipulate bitvectors of parametric widths, meaning a rewrite can apply to 16-bit or 32-bit bitvectors as well as all the widths in-between.

Like all good researchers, the solution is a new solver called ParaBit, that automatically proves the correctness of the rewrites. ParaBit first encodes the problem in a custom language then turns to equality saturation to construct a proof. We’re not the first to tackle this problem. Zvika Berger and the CVC5 team made some great progress with the PBV project on these kind of rewrite verification problems, providing an admittedly more general purpose solution than us. Our work differs from theirs, in that they attach bitwidths to operators whereas we attach bitwidths to operands removing the need for excessive extension operations. This lets us solve a good chunk more problems as we’ll see later on.

In July 2026, Luigi will be presenting this work at CAV, but further details can be found in the version we submitted (official version will be linked when published and in this version we’ll have proofs for all the axioms).

An Example

Much of the motivation for this project came from my own frustrations in developing EDA tool rewrites for the Rover project. We’ll take a ROVER rewrite as an example.

This rewrite says that when our width parameters satisfy \(q\geq r\), we can safely replace the lhs by the rhs. Our goal is to prove that this is correct for all possible width parameters. We use the subscript notation to denote the width of a bitvector, namely \(a_p\) denotes a \(p\)-bit bitvector. Similarly, \((b_p + c_p)_q\) means we add up two \(p\)-bit bitvectors and store the result in a \(q\)-bit bitvector.

To construct a proof we’ll be composing axioms of modular arithmetic (which is what our notation is really a shorthand for). Crucial for this proof is the following, where we totally remove the inner width \(u\).

This essentially says that when I add up two bitvectors, if I store the result in a width smaller than one of the addends, then it doesn’t matter what the width of the inner addend is. It’ll just get truncated after the addition.

Under the given assumption \(q\geq r\), this axiom applies to both the lhs and rhs of the rewrite:

Having removed any dependencies on \(q\), the two resulting expressions can now be shown equivalent by associativity of integer addition. This constitutes a series of axiom applications (which we separately verify) that proves the correctness of the rewrite whenever it is applied.

Whilst this looks simple, when we get more complex rewrites and have more axioms to combine finding this proof becomes much more tricky. This is where we turn to e-graphs and equality saturation, a constructive rewriting procedure where the order in which axioms are applied is not important. We can see how the e-graph encodes the steps that were written out here.

The ParaBit Solver

ParaBit is implemented in roughly 2k lines of Rust and is built on-top of the egg equality saturation library. ParaBit contains 99 axioms, each of which is verified in the Isabelle theorem prover. ParaBit takes problems specified in our custom BWLang language and discovers a sequence of axioms that prove the correctness of the rewrite using equality saturation.

If ParaBit is able to construct a proof, then ParaBit generates an associated Isabelle certificate script that can be checked independently to verify that our ParaBit proof is valid. This gives users an extra level of confidence in ParaBit’s proofs, so hopefully some industry folks might be willing to try it out!

To test out whether ParaBit is any good we gathered a couple of benchmark sets. Two from the software compilers community (Alive and Hydra) and two from the hardware domain (Rover and Industry). We compared against the PBV work from the CVC5 team referenced earlier. We see that ParaBit isn’t able to handle quite as many problems as PBV, due to current language limitations, but on the supported subset ParaBit is much more capable across all benchmarks.

Out of the 144 problems solved by ParaBit, we were able to successfully verify 142 of the generated Isabelle certificates. For two problems the proof production step actually ran out of memory. When ParaBit fails to produce a proof it is usually because the equality saturation step either times out or hit a memory limit.

There is clearly further work to be done to ParaBit to handle a larger class of problems and to improve performance across the problem set. The submitted version of the paper (official version will be linked when published) contains far more details and Luigi, John and I will all be at CAV in Lisbon in July 2026, so do come along if you’ve got any questions! If any of this work sounds interesting and you’re looking to collaborate or for Masters projects then get in touch.

TLDR: Yes, you can, but it gets pretty ugly…

In this blog, we’re going to show how we answered this question for a specific example, namely discovering carry-save addition (a hardware optimisation) via loop fusion (a compiler optimisation).

Carry-Save Addition

Consider the problem of adding up three n-bit bitvectors (x+y+z). Assuming we know how to add two bitvectors, the simplest solution is to add x and y, then add z to the result. However, each time we add two bitvectors, we have to propagate the carries all the way from the least-significant to the most significant bit.

The time to perform this computation unfortunately scales at least logarithmically with the width of the bitvectors. In hardware we can go much faster and compute (x+y+z) in the same time as (x+y) plus a small constant overhead. To achieve this, we use a full-adder which takes three individual bits of equal weight (x[i], y[i], z[i]) and produces two bits s and c such that: 2*c + s = x[i] + y[i] + z[i]. In terms of gates:

c = MAJ(x[i], y[i], z[i])
  = (x[i] AND y[i]) XOR (x[i] AND z[i]) XOR (y[i] AND z[i])
s = x[i] XOR y[i] XOR z[i]

Using n of these full-adders operating in parallel on bits of equal weight, we can take our three addends and reduce them down to two. Consider this example:

  1010 = 10 (x)
  1011 = 11 (y)
 +0011 =  3 (z)
 ----------
  0010 =  2
+10110 = 22
 ----------
 11000 = 24

Here we first reduced three values to two which takes constant time as we only look locally, so it is much faster than the complete addition. We of course do have to pay the price for the slow addition of two bitvectors once, but that’s much better than doing it twice sequentially. This technique is known as carry-save addition (and it generalises to an arbitrary number of addends).

Loop Fusion

Now we’ll briefly describe a compiler concept, loop fusion, which we’ll later use to “rediscover” carry-save addition. Consider the following example containing two loops:

# Loop 1: Square each element
for i in range(n):
    a[i] = a[i] * a[i]

# Loop 2: Add 1 to each element
for i in range(n):
    a[i] = a[i] + 1

A classic compiler optimisation is to fuse these two loops together, so that you only iterate over a once:

for i in range(n):
    a[i] = a[i] * a[i] + 1

This is more efficient because we only execute the loop once in the program and have also been able to fuse operations together to eliminate some loads/stores. Nate’s question was, can we use loop fusion as a lens through which we can discover carry-save addition?

The Challenge

Consider the following program fragment, which takes in three arrays of booleans x, y, and z, and produces an array of booleans s (= x+y+z):

# Perform (x+y) - store result in w
a[0] = 0
for i in range(n):
    w[i],a[i+1] = FullAdd(x[i], y[i], a[i])
# Perform (w+z) - store result in s
b[0] = 0
for i in range(n):
    s[i],b[i+1] = FullAdd(w[i], z[i], b[i])

It should be easy to see that this program adds its three bitvector inputs together using two separate additions that are performed sequentially. We’ve implemented bitvector addition as a sequence of full-adders (FullAdd) each feeding their carry to the next full-adder. So the question is, what happens when we perform loop fusion?

a[0] = 0
b[0] = 0
for i in range(n):
    w[i],a[i+1] = FullAdd(x[i], y[i], a[i])
    s[i],b[i+1] = FullAdd(w[i], z[i], b[i])

This isn’t that different (although we might save some memory if we executed this sequentially), but now consider a fused version of the adders with the carry-save trick:

c[0] = 0
d[0] = 0
for i in range(n):
    w*[i],c[i+1] = FullAdd( x[i], y[i], z[i])
    s*[i],d[i+1] = FullAdd(w*[i], c[i], d[i])

The two programs above at least look very similar; do they produce the same final output (does s=s*)? We know (from global analysis of the carry-save trick) that they do, but is there a local argument? That is, can we show that these two programs are equivalent without appealing to the actual meaning of s and s* as bitvectors, just by manipulating values? The answer is yes; we’ll do the proof next.

The Proof

Let’s do some bit-level analysis. We’ll do all our analysis in $\mathbb{F}_2$ (so XOR will be addition, and AND will be multiplication). Note that MAJ(x, y, z) = xy + yz + xz (this is usually defined where + is OR, but XOR works just as well).

From the first program:

s[i] = w[i] + z[i] + b[i]
     = x[i] + y[i] + a[i] + z[i] + b[i]

From the second program:

s*[i] = w*[i] + c[i] + d[i]
      = x[i] + y[i] + z[i] + c[i] + d[i]

So we can see that these s and s* values are equivalent if a[i] + b[i] = c[i] + d[i]. We’re going to prove this by induction. The base case a[0] + b[0] = c[0] + d[0] is true since a[0] = b[0] = c[0] = d[0] = 0. For the inductive case we’ll assume a[i] + b[i] = c[i] + d[i].

Step 1: a[i+1] + b[i+1] = c[i+1] + MAJ(x[i] + y[i] + z[i], a[i], b[i])

  a[i+1] + b[i+1]
  = MAJ(x[i], y[i], a[i]) xor MAJ(w[i], z[i], b[i])
  = MAJ(x[i], y[i], a[i]) xor MAJ(x[i] + y[i] + a[i], z[i], b[i])

For simplicity, let’s drop the [i] subscripts.

= MAJ(x, y, a) + MAJ(x + y + a, z, b)
= xy + ya + xa + (x + y + a)z + zb + (x + y + a)b
= xy + ya + xa + xz + yz + az + zb + xb + yb + ab
= xy + xz + yz + (x + y + z)a + (x + y + z)b + ab
= MAJ(x, y, z) + MAJ(x + y + z, a, b)
= c[i+1]       + MAJ(x + y + z, a, b)

It remains to show that d[i+1]=MAJ(x[i] + y[i] + z[i], a[i], b[i]), which will be easy to show if we also prove by induction a[i]b[i] = c[i]d[i] (strengthening the inductive hypothesis).

Step 2: Assuming ab=cd show that d[i+1]=MAJ(x + y + z, a, b):

MAJ(x + y + z, a, b) = (x + y + z)a + ab + (x + y + z)b
                     = (x + y + z)(a + b) + ab
                     = (x + y + z)(c + d) + cd
                     = (x + y + z)c + (x + y + z)d + cd
                     = MAJ(x + y + z, c, d)
                     = MAJ(w*, c, d)
                     = d[i+1]

So lastly let’s prove a[i]b[i] = c[i]d[i] by induction as well. The base case again is trivial. The inductive case is where it gets annoying so strap in.

Step 3: Assuming ab=cd show that a[i+1]b[i+1]=c[i+1]d[i+1]

a[i+1]b[i+1] = MAJ(x, y, a)MAJ(w, z, b)
             = (xy + ya + xa)(wz + zb + wb)
             = xyzw + xyzb + xywb + 
               yzwa + yzab + ywab + 
               xzwa + xzab + xwab

Now we need to expand w everywhere, but that’ll be a lot of terms. To make it easier, note that in every term where w appears in the expression, it happens that exactly 2 of its components {x, y, a} appear as well, so you get something like xyzw = xyzx + xyzy + xyza. Two of these terms (where we used a component that already appears) are equivalent (since xx=x and yy=y) and cancel out. So basically the w just gets replaced by the one component that doesn’t already appear in the term:

= xyza + xyzb + xyab + xyza + yzab + xyab + xyza + xzab + xyab
= xyzb + yzab + xyab + xyza + xzab
= xyz(a + b) + ab(xy + yz + xz)
= xyz(c + d) + cd(xy + yz + xz)

This looks pretty simple, so let’s turn our attention to c[i+1]d[i+1]:

c[i+1]d[i+1] = MAJ(x, y, z)MAJ(x + y + z, c, d)
             = (xy + yz + xz)(xc + yc + zc + cd + xd + yd + zd)
             = (xyzc + xycd + xyzd) + 
               (xyzc + yzcd + xyzd) + 
               (xyzc + xzcd + xyzd) 

Note that in that step, we neglected to write some things that immediately cancel out within individual sub-expressions, but there’s still more to cancel out between them:

= xyzc + xyzd + xycd + yzcd + xzcd
= xyz(c + d) + cd(xy + yz + xz) = a[i+1]b[i+1]

This is pretty gnarly, but it means at least in principle what we wanted to show: a compiler which can fuse loops and then rewrite the loop body under this kind of inductive argument can automatically discover carry-save adders.

Conclusion

Obviously, we don’t need to rediscover the carry-save trick, since we already know it.

Rather, the hope is that other similar tricks can be discovered as well. In hardware, it’s easy to see how we can build a library of operator-level optimizations, and how we can build a library of bit-level optimizations for unrolled circuits, but compiler optimizations operate in a space in the middle, where the regularity inherent in the program must be taken advantage of to build global optimizations out of local transformations without unrolling. Hardware has regularity too, and we should perhaps be exploiting it so that we are not stuck with the other two choices of optimization.