Calyx primitives within CIRCT

[mikeurbach]

I would like to be able to provide my own primitives to Calyx within a CIRCT-based compilation pipeline. The motivation is from the scheduling work: we are able to schedule affine-level program and lower the schedule to a Calyx control program, provided a suitable library of primitive operators.

Right now, the pass I wrote in CIRCT just assumes the primitives that exist in the native Calyx compiler. What I'd really like, is to come up with target specific primitives (i.e. DSPs on a specific Xilinx part, for example), which can be used by the scheduling infrastructure as well as the Calyx lowering.

The native Calyx compiler already has this ability through the primitive keyword, so I think this is really about adding that kind of representation to the CIRCT Calyx dialect. Rather than codifying a known library of primitives in the CIRCT dialect, we would need some sort of "primitive declaration" op, like hw.module.extern, that captures the primitive's name, ports, etc.

Then, we would need a way for whatever is generating these primitives to "link" the primitives to the Calyx design at an appropriate intercept point in the compilation pipeline. I think this would probably happen around the time Calyx gets lowered to CIRCT's core dialects, if the generator is also emitting CIRCT's core dialects.

I think this could open up some really interesting workflows where the compiler takes care of scheduling with CIRCT and Calyx, and the user is responsible for bringing a library of primitives to the table that are specific to their domain.

[rachitnigam]

The upshot from this discussion is that we need to add a primitive op to the circt calyx dialect and support emitting it on the compiler side