A real numerics library for Calyx

[rachitnigam]

The current state of the numerics operators in Calyx is not great. The goal of this PR is to build a realistic, well-designed, and well-tested numerics library for Calyx that has robust supported for signed and unsigned computations for bitnum and fixedpoint numbers.

Current State

Most of the numeric operators live under primitives/{bitnum,fixed}/{signed,unsigned}.sv. There are broadly three problems:

1. No Standardized Guidelines: For example the sqrt implementation used blocking assignments at the time of submission which are widely discouraged when writing synthesizable RTL code. Similarly, the code does minor annoying things like not capitalizing parameter names.
2. Unspecified Interfaces: The fixedpoint implementations only work with number of the same width and don't really have guarantees on how things overflow.
3. Unnecessary Code Duplication: The bitnum implementations should "just work" for FP since the FP format is just powers of two. It shouldn't be necessary to have two separate implementations. Plus, all primitives in the library should be synthesizable; currently they are not (std_div, std_fp_div)

Brave New World

The new numerics library should be carefully redesigned to provide support for all computations that Dahlia supports and support operators like sqrt and exp. We should define a standard way to build new primitives and clear guidelines on when things need to be written in Calyx and when they can be written in Verilog.

[sampsyo]

Seems like a good vision! One question on a very low-level detail: what should the general policy be for operations that combine bit widths---for example, adding an 8-bit integer to a 16-bit integer? I can think of two policies:

• Permissive: The operations try to support flexible combinations of formats whenever they can, so this "16+8" example could be done with a single adder.
• Orthogonal: Operations work on strictly matching formats, and there also "width adjusting" primitives that can be applied to get widths to match. So if you want to do the "16+8" thing, you presumably first sign-extend the 8-bit number and then do the operation.

I feel like the orthogonal option would be my first instinct because it makes the actual semantics of operations a little clearer (which is more important for fixed-point and, eventually, floating point than it is for integers!). But there are possibly practical reasons why the exact-match restrictions would complicate the operations themselves.

[rachitnigam]

Yeah, the Orthogonal approach is also what the CIRCT people seem to have adopted for now so seems reasonable. TLDR, the more magic we have in the primitives, the more complicated handling logic we need to write for passes.

[rachitnigam]

This is done thanks to @cgyurgyik hard work!