[BLOG] Technology Mapping with Egraphs #532

neel-patel-1 · 2025-05-13T08:26:09Z

closes #511

… for any user of egg

sampsyo

Hi, everybody—thanks for the detailed writeup; this made the adjusted goal and the concrete approach clear. It's too bad that the original plan to use SmoothE did not work out. But it was definitely interesting to see how well ILP-based extraction worked for this workload.

One big question I had was: while I understand how an ILP-based extractor could be an interesting intermediate step, what was your motivation for adding support for good_lp? Were there specific limitations in egg's existing ILP solver support that you needed to work around? It might be nice to add some additional motivation for this in the body of the post.

sampsyo · 2025-05-13T19:51:09Z

content/blog/2025-5-13-superopt/index.md

+
+## Introduction
+### E-graphs and Equality Saturation
+Equality-graphs, or more simply, e-graphs, efficiently represent equivalence classes of expressions. This makes them useful for superoptimization, where, given an input program, we seek to find the sequence of optimizations that emits the *best* program, minimizing some user-provided cost function. E-graphs are directed graphs with edges from expressions (*e-nodes* in an e-graph), to a group of e-nodes (an *e-class* in an e-graph, where all the e-nodes contained are equivalent expressions). To efficiently maintain and merge these equivalence classes, e-graphs rely on a union-find data structure. The example below shows an arithmetic expression `a * 2 / 2` represented as an e-graph.


Maybe it would be nice to link to the Wikipedia page, or some other definition? https://en.wikipedia.org/wiki/E-graph

sampsyo · 2025-05-13T19:54:05Z

content/blog/2025-5-13-superopt/index.md

+
+<img src="canonical-example-before.svg" alt="" width="33%">
+
+In *equality saturation*, we apply pattern-based *rewrites* to repeatedly produce equivalent expressions. Each rewrite grows the e-graph, without losing the previous versions of the expression. So if two expressions always evaluate to the same result, they belong in the same e-class. Upon saturation, an e-graph will have undergone enough rewrites to reach a fixed point where it encodes all possible programs simultaneously.


Equality saturation probably also deserves a hyperlink.

sampsyo · 2025-05-13T19:55:03Z

content/blog/2025-5-13-superopt/index.md

+
+<img src="canonical-example-before.svg" alt="" width="33%">
+
+In *equality saturation*, we apply pattern-based *rewrites* to repeatedly produce equivalent expressions. Each rewrite grows the e-graph, without losing the previous versions of the expression. So if two expressions always evaluate to the same result, they belong in the same e-class. Upon saturation, an e-graph will have undergone enough rewrites to reach a fixed point where it encodes all possible programs simultaneously.


"all possible programs" perhaps could use a little more precision here… maybe you mean all the possible results of applying all the rewrite rules?

Clarified that "all possible programs resulting from all rewrite rules are encoded in the e-graph"

sampsyo · 2025-05-13T19:55:25Z

content/blog/2025-5-13-superopt/index.md

+### E-graphs and Equality Saturation
+Equality-graphs, or more simply, e-graphs, efficiently represent equivalence classes of expressions. This makes them useful for superoptimization, where, given an input program, we seek to find the sequence of optimizations that emits the *best* program, minimizing some user-provided cost function. E-graphs are directed graphs with edges from expressions (*e-nodes* in an e-graph), to a group of e-nodes (an *e-class* in an e-graph, where all the e-nodes contained are equivalent expressions). To efficiently maintain and merge these equivalence classes, e-graphs rely on a union-find data structure. The example below shows an arithmetic expression `a * 2 / 2` represented as an e-graph.
+
+<img src="canonical-example-before.svg" alt="" width="33%">


It seems like a nice idea to use alt text, if you can think of anything…

Descriptions added for each img

sampsyo · 2025-05-13T19:58:31Z

content/blog/2025-5-13-superopt/index.md

+The second is an [exact extractor](https://github.com/egraphs-good/egg/blob/v0.10.0/src/lp_extract.rs) which formulates extraction as a mixed integer linear programming problem and solves it using the [COIN-OR](https://github.com/coin-or/Cbc) Branch-and-cut solver.
+
+### E-graphs for Technology Mapping
+The task of technology mapping in logic synthesis is to express a given Boolean function as a network of gates from a standard cell library (for ASICs) or programmable LUTs (for FPGAs) so that an objective function, such as total area, is optimized.


"Technology mapping" is another good place to use a hyperlink to some kind of place where people can learn more.

sampsyo · 2025-05-14T13:00:02Z

content/blog/2025-5-13-superopt/index.md

+
+## Results
+
+We compare the number of LUTs in the designs extracted using greedy and ILP extraction on the [ISCAS85](https://github.com/matth2k/synth-benchmarks/tree/main/verilog/iscas85) design benchmarks. Since finding an exact solution quickly becomes prohibitive in terms of extraction time, (the size of the e-graph and corresponding linear programming problem gets too large), we incrementally increase the number of "rewrite iterations" until reaching 10 . This limits the size of the e-graph by restricting the number of times rewrites are applied. Some benchmarks/solvers were not able to complete even a single iteration within the 30 minute timeout threshold.


time, (the size of the e-graph and corresponding linear programming problem gets too large), we

Use commas or parentheses here, but not both.

sampsyo · 2025-05-14T13:01:53Z

content/blog/2025-5-13-superopt/index.md

+| c7552     | 335                        | 325              | DNF                                      | 315 (7)                                | DNF                                   |
+| c880      | DNF                        | DNF              | DNF                                      | DNF                                    | DNF                                   |
+
+The times to solution are reported in the table below


What units?

number of LUTs in the synthesized design (specified in column headers)

sampsyo · 2025-05-14T13:02:27Z

content/blog/2025-5-13-superopt/index.md

+
+| Benchmark | Greedy Time       | Microlp Time      | HiGHS Time        | CBC Time           |
+|-----------|-------------------|-------------------|-------------------|--------------------|
+| c1355     | 0.046134086       | DNF               | 640.92384104      | 230.738058229      |


Please reduce the number of significant figures. For example, it's enough to say that this benchmark using greedy extraction takes 0.05 units (seconds?); we do not need all these decimal digits.

sampsyo · 2025-05-14T13:04:21Z

content/blog/2025-5-13-superopt/index.md

+| c6288     | 0.136245309       | DNF               | 608.710588015     | DNF                |
+| c7552     | 0.045072024       | DNF               | 600.26766583      | DNF                |
+| c880      | DNF               | DNF               | DNF               | DNF                |
+


For all these results, is there some kind of context you can give to convey whether this is "good" or "bad"? The ideal thing to have done here would be to compare against ABC or similar (on both QoR and running time). But given that it's probably too late to do that, is there any way you could just give some kind of very vague context for how well this system is doing? Are the LUT count reductions anywhere close to the results of traditional tools? How about the running times—is 600 units of time (seconds?) in the ballpark of a traditional tool?

I agree. There is still time to rerun with ABC to provide an optimized baseline

I will report when this is complete

Since we are using yosys synth_xilinx to synthesize a design targetting an FPGA in all configurations, an ABC tech mapping is always performed. This means that any further LUT decreases in the greedy and exact configurations are in addition to the improvements from ABC. This has been clarified in the text and configuration names.

sampsyo · 2025-05-14T13:05:19Z

content/blog/2025-5-13-superopt/index.md

+
+We also compare the area (µm²) of the designs extracted using greedy and exact extraction (this time only using the top-performing - HiGHs - solver) on the ISCAS85 verilog design benchmarks using a standard cell library. Synthesizing an ASIC design using exact extraction becomes prohibitive faster than synthesis targetting an FPGA due to the larger design search space. There is no "No Optimization" column in this chart. To convert to a standard cell library, a set of rewrite rules must be applied required to convert digital logic to standard cells. We also compare against the Synopsys commercial design compiler to show the design quality a tuned EDA tool can achieve.
+
+| Bench   | Greedy Area   | Exact Area (Node Limit) (msynth) | Synopsys               |


What does "msynth" mean here?

this is actually another tool. similar to lvv, but uses rewrite rules that convert to a standard cell library to target ASICs. clarified in the text: "We use another e-graph-based logic synthesis tool, called msynth, which operates similarly to lvv, but can synthesize ASIC designs using a standard cell library."

neel-patel-1 · 2025-05-17T05:59:41Z

One big question I had was: while I understand how an ILP-based extractor could be an interesting intermediate step, what was your motivation for adding support for good_lp? Were there specific limitations in egg's existing ILP solver support that you needed to work around? It might be nice to add some additional motivation for this in the body of the post.

This is a reasonable question which deserved further explanation. We added more information to motivate our implementation decision in Design Extraction in the post.

Briefly, the Coin-OR Branch-and-Cut solver used by egg emits errors for some of the large problems constructed for ASIC synthesis. We hypothesized that the issue had to do with the solver itself, since previous users have also triggered unexpected behavior with their problem formulations. We figured we would encounter similar issues with other solvers as well, so being able to quickly switch between them to see if any of them could produce a result would be helpful. In addition, many solvers actually implement different algorithms, so some might be faster than others depending on the problem. This motivated the integration of a good_lp based extractor, which would allow us to quickly switch between solvers at runtime. Also, good_lp provides a clean API for expressing problem variables, constraints and objective function, making it easy to understand the code. Our implementation has drawbacks (performance) as shown in the Results section, though.

sampsyo · 2025-05-17T17:11:19Z

Got it; that absolutely makes sense!

Thanks for all the changes overall. Can you let me know when I should take another look (and publish) by requesting a review with the widget on the right-hand side of the GitHub PR page?

neel-patel-1 · 2025-05-17T20:13:55Z

I have finished reviewing. Thanks for the feedback on this!

sampsyo · 2025-05-18T13:48:07Z

Looks great; nice work on this! The expanded detail in the evaluation is especially helpful to see how things worked out.

neel-patel-1 and others added 30 commits May 2, 2025 13:08

superopt

6c45040

title

6b24105

example

f671f86

outline

45040d2

remove example

1cf822f

greedy results

73fb28e

exact results for those that we have

9fa537e

exact time results

ac56a92

only area exact msynth that completed within 10 min

f8831d1

insert canonical example

6fff256

lut synth figs

2eb2491

area comparison

64ae789

results

39f49e6

add to introduction

cd9a006

exact msynth results

db6f7a7

mention max nodes

2408cbc

Merge branch '2025sp' into solver_comparison

fc9f819

update results and design extraction

62a19c6

link

2512b51

more details on design

4e73b6c

challenges

1d65b15

challenges

bcab7aa

update tech mapping section

809d02a

links and fixups

ae28d6f

specify problem

564b6ce

move good_lp sentence

706d4ce

remove bullets

0ebf08d

fix name

f0e322e

specifying an rtl design lutlang grammar

4d0777b

Merge branch '2025sp' of github.com:neel-patel-1/cs6120 into 2025sp

e231208

Your Name added 3 commits May 13, 2025 15:23

->Synopsys

6b8e468

new link to benchmarks and specify that good_lp extractor can be used…

d91d87a

… for any user of egg

change back to program

f55ddf2

sampsyo requested changes May 14, 2025

View reviewed changes

Your Name added 9 commits May 15, 2025 11:25

reduce sig figs

241abf1

clarify meaninf of saturation

c9ce3a0

link and clarify

06bac3f

verilog -> Verilog

cdad1c6

of

4795ed6

specify that yosys does an initial ABC tech mapping

0924e68

yosys and greedy lut counts

4474798

report original egg cbc solver times

bb43255

poor scalability quality tradeoff and comparison against egg's CBC

f457f7e

sampsyo added the 2025sp label May 16, 2025

Your Name added 6 commits May 17, 2025 00:28

motivate the need for a good_lp-like extractor with multiple backends

606f04a

include infeasible for cbc

f14d3b8

single rewrite iteration results

08d401c

track all the errors

542d37c

populate area table

8599ec8

explain the errors

fa2fe49

Your Name added 3 commits May 17, 2025 11:42

48000 nodes

42faeef

run with larger e-graphs to get greedy results

1f7dc49

reinsert synopsys results

ff055c7

conclusion

22c3a4d

neel-patel-1 requested a review from sampsyo May 17, 2025 20:12

sampsyo merged commit 02295d9 into sampsyo:2025sp May 18, 2025
2 checks passed


		<img src="canonical-example-before.svg" alt="" width="33%">

		In equality saturation, we apply pattern-based rewrites to repeatedly produce equivalent expressions. Each rewrite grows the e-graph, without losing the previous versions of the expression. So if two expressions always evaluate to the same result, they belong in the same e-class. Upon saturation, an e-graph will have undergone enough rewrites to reach a fixed point where it encodes all possible programs simultaneously.


		## Results

		We compare the number of LUTs in the designs extracted using greedy and ILP extraction on the [ISCAS85](https://github.com/matth2k/synth-benchmarks/tree/main/verilog/iscas85) design benchmarks. Since finding an exact solution quickly becomes prohibitive in terms of extraction time, (the size of the e-graph and corresponding linear programming problem gets too large), we incrementally increase the number of "rewrite iterations" until reaching 10 . This limits the size of the e-graph by restricting the number of times rewrites are applied. Some benchmarks/solvers were not able to complete even a single iteration within the 30 minute timeout threshold.


		We also compare the area (µm²) of the designs extracted using greedy and exact extraction (this time only using the top-performing - HiGHs - solver) on the ISCAS85 verilog design benchmarks using a standard cell library. Synthesizing an ASIC design using exact extraction becomes prohibitive faster than synthesis targetting an FPGA due to the larger design search space. There is no "No Optimization" column in this chart. To convert to a standard cell library, a set of rewrite rules must be applied required to convert digital logic to standard cells. We also compare against the Synopsys commercial design compiler to show the design quality a tuned EDA tool can achieve.

		\| Bench \| Greedy Area \| Exact Area (Node Limit) (msynth) \| Synopsys \|

[BLOG] Technology Mapping with Egraphs #532

[BLOG] Technology Mapping with Egraphs #532

Uh oh!

Conversation

neel-patel-1 commented May 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sampsyo left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

neel-patel-1 May 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

neel-patel-1 commented May 17, 2025

Uh oh!

sampsyo commented May 17, 2025

Uh oh!

neel-patel-1 commented May 17, 2025

Uh oh!

sampsyo commented May 18, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

neel-patel-1 commented May 13, 2025 •

edited

Loading

neel-patel-1 May 15, 2025 •

edited

Loading