SIRRTL Workplan

[dz333]

This issue has been made to track progress on improving the SIRRTL compiler performance, modularity and scope.

The next steps for the SIRRTL compiler follow below (in order of importance):

1. Start refactoring the v0.2 SIRRTL compiler to operate on CHIRRTL. This involves incorporating some of the label checking designs from the v0.1 compiler, without introducing circuit re-writing. In particular, we need to correctly interpret the "last connect semantics" so that when conditions include the negation of subsequent conditions. We should not incorporate the limitations of v0.1 (such as wires can't be used as labels). Those original decisions were made to simplify the compiler since the contemporary use cases didn't really need it. This improvement is primarily tracked in Refactor to Typecheck Chirrtl Correctly #10 .

2. Improve the modularity of SIRRTL typechecking by allowing Hoare-style pre and post conditions on modules. Ideally we can also implement condition generation such that these constraints are somewhat inferrable. This improvement is tracked in Better Support for Modular Typechecking #8.

3. Improve SIRRTL usability. We need to improve the configurability of label formats/interpretations as well as improve error reporting. Currently, a user of SIRRTL needs to have a good understanding of SIRRTL and IFC Lattices to do either of these. Tracked in Support Better IFC Label Configuration #7 and Improve Workflow and Error Messages #13 . Lastly, we should also improve the documentation and example infrastructure by adding a tutorial & demo of insecure information flows in simple circuits; tracked in Add Easy Demo Libraries and Tutorial #12 .

Orthogonally, we should update the base SIRRTL compiler to the newest version of the FIRRTL compiler in order to 1) support new FIRRTL features, such as multiple clocks and 2) incorporate improvements to the compiler itself. This is tracked in #11 .