[Summer Research] Robust Interpreter for Calyx

[rachitnigam]

TLDR: Build an interpreter for Calyx that can execute programs generated by the systolic array compiler and the Polybench benchmarks and generate the exact same results as the Verilator backend.

Onboarding

The first step is figuring out the current state and capabilities of the interpreter. We currently have some unmerged code on the interp and interp_yn branches. We should merge and/or remove them.

Next, we should write a suite of tests that we want to have work with the first version of the compiler. Some examples of tests are:

1. Interpreting group with group[done] = std_reg.done .
2. Interpreting group with group[done] = 1'd1. This will run into the issue Interpreter not updating when done signal of the group is directly assigned #509.
3. Interpreting seq, if, while.
4. Interpreting invoke.
5. Interpreting par.

Not all of the tests will work with the interpreter at the start. This is fine. We should make sure the tests work with Verilator and then start working on making them work with the interpreter.

Repository Rules

Follow a few rules when working with the Calyx repository.

1. Unless you're making an absolutely trivial change, do not commit to the main branch. Instead, create a branch. Make sure that you are not working on a fork of the repository.
2. Build a small feature using the branch, open a pull request, and request a review from @rachitnigam, @EclecticGriffin, and @sampsyo.
3. The pull request will either be approved, have small changes requested, or have larger changes requests (which might require a meeting).
4. Once a pull request is approved, click on the "Squash and Merge" option from the dropdown menu.

Roughly speaking, you should open a PR at the end of every week. Do not worry if your code is not pristine! We will help you figure out programming style and patterns to make it better during the pull request.

[ai-cu]

From the meeting on 6/2/2021:
Things to do:

• Check out the existing branches and merge (Griffin and Andrii)
• Develop the test suite (Alma and Alex)
• Interpretation of control statements
• Value representations within Rust
• Structure interpretation
• Primitives, i.e. making sure that primitives within Rust work the same as the Verilog counterparts.
• Figure out the state/environment model of the interpreter.
• I/O format
• Integration of the interpreter with Verilator
• Formal semantics

[EclecticGriffin]

See following for inventory of current state of tests: @almathaler and @yn224

(edit, forgot the link 🤦🏻 )
#519 (comment)

[EclecticGriffin]

I'll note that "correctness" here is dependent somewhat on what we think the interpreter should output

[EclecticGriffin]

https://docs.rs/bitvec/0.22.3/bitvec/vec/struct.BitVec.html May be suitable as a replacement for u64 though when writing the primitives this will require some attention to implementation

[rachitnigam]

Wow look at that we built an interpreter for Calyx :-)