Rigel HLL

[jameshegarty]

Make a restriction: only support DAGs, only do typechecking forward. IE if we use a handshake module somewhere in the pipeline, require that the input to the pipeline is Handshake. This makes things a lot easier. This is the use case for almost all real pipelines anyway...

• concat/fanin should be merged
• index/selectStream should be merged
• fixed_new/systolic should be merged
• use a global variable to check for fanOut not being called.
• track .inputSize and .outputSize (image W/H) in the wrapper modules. If input/output size are not given by a module (i.e. as will be the case with map, reduce), then just leave it blank... if they get composed with something with a size, do a passthrough (as the default reasonable behavior). *** this won't work?... we need this to be part of the type system for real (ie to make inputs work correctly. They need to have an associated image size). Actually, if we overload rigel.input, this will be fine.
• split up harness. Instead, have a filereader & filewriter module. This should work fine in verilator/terra. For AXI, somehow extract the inputs/outputs with a compiler pass?

lambda(fn): fn should be a lua function that takes in a rigel value as input, and returns an output liftMath(fn): fn should be a lua function that takes in a fixed value as input, and returns an output

[jameshegarty]

Work on this is in progress with src/rigelhll.lua

[jameshegarty]

Rigel HLL will shove extra info in the IR to enable automatic generator value filling: "vectorized": is this value a vector? (can't tell this from the type... bc it could be an image etc) "imageSize": image size

The question is: is this sound? Is this well defined for all operators? How to deal with higher-order functions? (map etc). These will now need to operate on RigelHLL operators.

why is this different than a mid-level IR (#79)? That will still require explicit setting of parameters like image size. Rigel HLL will be built on top of mid-level IR.

[jameshegarty]

Why is "vectorized" necessary? There are ambiguous casting cases.

If we have A[2] going in to a line buffer, we don't know whether this is A vectorized to width 2, or a (x,y) coord pair (for example). Vectorized distinguishes these cases. This seems wrong. For one thing, 'vectorized' won't be propagated correctly through all operators without more annotations. Does this matter? Well, if the (x,y) coords are treated as a vector, stuff downstream won't end up with the correct types...