Feature: Sum of product sop(), product of sum pos() about amaranth

[whitequark]

You can write a function sop yourself. This does not need to be an Amaranth built-in.

[jrmoserbaltimore]

True, but you can also write any() and all() yourself. mux() is another thing you can do yourself.

Sum of products/product of sums are common operations; I also considered sending a pull request for this but it was late and it's not immediately obvious to me the correct way to iterate over an array passed to a function to carry out the sop() or pos() functions. Maybe any([all(x) for x in inputarray]) or is that not how amaranth works? I think it should work, maybe? Probably.

Given how common the operation is, I actually went looking through the docs and codebase before making a feature request, since it wasn't obvious I wasn't just missing something.

[whitequark]

True, but you can also write any() and all() yourself. mux() is another thing you can do yourself.

any() and all() are standard Python functions. Mux() is the Amaranth equivalent of the standard Python x if y else z construct. sop() and pos() do not have a Python correspondence.

Sum of products/product of sums are common operations

That's not really the case in my experience. You're the first person who wanted a first-class sum-of-product operation that I'm aware of.

In any case, additions to the public API have to go through the RFC process.

[jrmoserbaltimore]

That makes sense

True, but you can also write any() and all() yourself. mux() is another thing you can do yourself.

any() and all() are standard Python functions. Mux() is the Amaranth equivalent of the standard Python x if y else z construct. sop() and pos() do not have a Python correspondence.

That makes sense.

Sum of products/product of sums are common operations

That's not really the case in my experience. You're the first person who wanted a first-class sum-of-product operation that I'm aware of.

I'm not sure those two things are equivalent, but fair enough. Large functions are impossible to k-map anyway since you need to do them in an n-dimensional hypercube for 2n inputs (k-mapping is an optimization technique used to minimize logic by finding the optimal sum-of-products/product-of-sums equation; the other method is Quine-McClusky, which is np-hard because you need to solve the set covering problem, and that outputs sop/pos too).

In any case, additions to the public API have to go through the RFC process.

Thanks, I'll look through that.

[whitequark]

Amaranth primarily targets FPGAs and ASICs and the open toolchain uses AIG-based synthesis for either, meaning neither K-maps nor Quine-McClusky are relevant at all for any of the main flows. CPLDs used to use those heavily but there is no CPLD toolchain explicitly supported at the moment (I think you could do some weird things with ISE but I'm not aware of anyone who has done that on a more than curiosity basis).

Even if K-maps were used, Amaranth is a high-level frontend that leaves all of the mapping work to the underlying toolchain, so even then I don't see the relevance of SOP/POS in the frontend.

[jfng]

Sum of products/product of sums are common operations

That's not really the case in my experience. You're the first person who wanted a first-class sum-of-product operation that I'm aware of.

Minimizing SOP/POS equations with Amaranth can be useful to implement complex instruction decoders. For example, Chisel provides one in its libraries, where minimization is done with QMC or by shelling out to Espresso.

This is probably too niche for Amaranth stdlib, but such functionality could make a good downstream library.

[jrmoserbaltimore]

Minimizing SOP/POS equations with Amaranth can be useful to implement complex instruction decoders. For example, Chisel provides one in its libraries, where minimization is done with QMC or by shelling out to Espresso.

This is probably too niche for Amaranth stdlib, but such functionality could make a good downstream library.

Fair point. I've used similar things when writing a RISC-V decoder or a Gameboy Color MMU emulator, with ugly things like (x & 'b0101 == 'b0101) | (x & 'b1011 == 'b1010)) (i.e. (b&d)|(a&c&~d)) and so forth in verilog long ago. Lots of overly complex case statements I'd rather replace with something more elegant. ...thinking about that code kind of makes me not feel so bad my SSD died without backups.

Wonder what else would go in such a library, but that's probably a conversation for somewhere other than here.

[whitequark]

I'm going to close this because there isn't enough interest in the feature that I've seen over the years to continue tracking it. It is still open for commenting, and of course anyone can submit an RFC for this feature or any other one.