Feedback

[Febbe]

Many of your modules are just combinatorial. Those won't place and route without timing issues, when your input sizes are large and the frequency is high (eg. frq >= 300 Mhz). Alsoy why should I use modules, when I can just write my combinatorial logic in-place. E.g. my_reg <= a * b + c;

You should add pipelined versions of your comb modules.
For example, module multiply_piped #(.AW(32), .BW(32), .DELAY(5)) , and module multiply_data_piped #(.AW(32), .BW(32), .DATAW(64) .DELAY(5)).
The latter is also delaying data, to ensure they all make the same progress.

[MrAbhi19]

Thanks for pointing out the timing issue with modules like Multiplier, MAC, and ALU. I see how pipelined versions would make them more practical for high‑frequency designs. Your suggestion of adding configurable pipeline stages (e.g., DELAY parameter) is a great idea, since it would allow users to balance latency and timing closure based on their target frequency.

I also appreciate the example of multiply_data_piped — delaying associated data alongside the computation is an important detail to keep everything aligned across stages. That’s something I’ll keep in mind when designing pipelined variants.

I’ll start by experimenting with pipelined versions of the arithmetic modules, and then extend the approach to others where timing can become critical. I’ll work on updating these modules as fast as possible so the library becomes more useful for high‑frequency designs. Thanks again for sharing this insight — it’s very helpful for shaping the next improvements to the library.