[CombToAIG] Add a pattern for mul

[uenoku]

This commit adds a pattern to lower mul. Mul is lowered into chains of comb.add + comb.mux. There must be more efficient implementation but for now this naive pattern should work fine. LEC is verified.

{a_{n}, a_{n-1}, ..., a_0} * b
= sum_{i=0}^{n} a_i * 2^i * b
= sum_{i=0}^{n} (a_i ? b : 0) << i

[Max-astro]

It's great to see the progress made with the circt-synth tool.

I have a question about the current CombToAIG lowering flow. In a commercial logic synthesizer, the operator lowering process considers the timing/area trade-off, especially for operators on the critical path. For example, a multiply operator will be mapped into a Wallace Tree multiplier if it's on the critical path. Other non-critical multiply operators might be mapped to serial multipliers to save chip area.

So, Suppose multiple implementation architectures are available for each operator in the future. How do you plan to approach the operator in selecting the most suitable architecture during the lowering process? To achieve that, the synthesis flow might need to incorporate a timing and area analyzer.

[uenoku]

the operator lowering process considers the timing/area trade-off, especially for operators on the critical path

That's great point!

One thing we can possibly do is to lazily lower heavy operations
such as mul or div. We can keep them first, and analyze the timing
and critical path in the partically lowered AIG IR. We'll definitely implement
timing and area analyzer (in fact they are implemented in my local branch)
so we should be able to use that in the future.

That said I agree it would be really nice if the compiler/synthesizer
can automatically optimize the critical path or area but
I think it's also important for users to specify the lowering choice.
Users shouldn't use builtin operators for heavy operations like mul
or div in the first place for the modules that are performance critical.

[Max-astro]

We'll implement timing and area analyzer (in fact they are implemented in my local branch)
so we should be able to use that in the future.

Cool! It's good to know that.
I have experience developing an STA tool and am willing to contribute to this area.

[uenoku]

Awesome, thanks! That would be really really helpful. Can we set a meeting? (or we can use CIRCT open meeting if time works for you). Do you mind if you could send me email to hideto.ueno@sifive.com?

[Max-astro]

Yeah sure! I sent you an email before (about a month ago) when I first saw your commit about the circt-synth , but maybe your mailbox blocked that mail. I'll resend that letter, and my email is max_astro@qq.com