Initialising the Datapath Dialect for Lowering Arithmetic Operators to Gates #8634
Conversation
… builder and assemblyFormat
…explicit reduction factor
…ingle compressor tree and removing zeros
|
Drive-by comments:
|
|
Thanks for the comments @teqdruid - will split up as per suggestion. Regarding the second question, the dialect is certainly not a replacement for the pipeline dialect. Potentially datapath and dataflow get used in many different ways. I've typically seen datapath synthesis refer to the challenge of converting arithmetic into efficient circuits. Synopsys also refers to this as a datapath problem. Particularly in an ASIC setting we can do a lot of arithmetic within a pipeline stage - opening up a lot of optimisation opportunities (like the opportunity to remove a carry-propagate adder from the critical path in the example). Happy to take other naming suggestions but the intent is to really optimise arithmetic circuits particularly leveraging efficient ASIC circuits. |
|
Will break up into separate PRs and resubmit tomorrow |
|
Great! The naming is a minor thing. If "datapath" is the standard name, I'm ok-ish with it. |
The datapath dialect will be used as part of the growing synthesis capabilities, where arithmetic operators such as comb.mul and multi-input comb.add can be lowered to gates via the datapath dialect. The datapath dialect allows us to directly express efficient circuits such as compressor trees, in the IR itself, allowing us to manipulate and combine arithmetic operations.
The key idea is to view datapath operators as generators of circuits that satisfy some contract, for example in the case of the
datapath.compresssumming it's results is equivalent to summing it's inputs. This allows us to defer implementing these critical circuits until later in the synthesis flow.In a simple example, we can fold a*b+c using the datapath dialect to remove a carry-propagate adder:
Which is equivalent to:
This is the first in a series of PRs to add datapath synthesis capabilities that will include the following (implemented but not merged):