Rio in Summer 2025 (WIP writeup)

[polybeandip]

Timeline for working on the compiler

Week Of	Milestone
May 26 June 2	Make a complete PIFO block design in Verilog (not just a flow scheduler)
June 9	Wrap the PIFO block in a Calyx primitive and write tests - Should be similar to the 20,000 command tests that uses queue_call - Try to use static Calyx to make the test do pipelining
June 16	Implement Round-Robin and Strict with the new Sivaraman style PIFO in Calyx - These new RR and Strict queues should pass our existing tests - Benchmark them against against our existing RR and Strict designs (maybe these scripts will do the trick?)
June 23	Build a compiler from Rio to Calyx using exclusively Sivaraman style PIFOs - Should be similar to Cassandra's PR but without specialized queues - Take advantage that a PIFO block, holding multiple logical PIFOs, can represent an entire level of the PIFO tree
June 30	Extended the subset of Rio we have well-defined semantics for - Currently, we have semantics nailed down only for trees with RR, Strict, and FIFO - This includes the extending the policies the simulator supports (i.e. make Policy.of_program crash on fewer programs)
July 7	Extend the subset of Rio that can be compiled down to hardware
July 14	Try adding optimizations to the compiler - Rather than always using the Sivaraman PIFO, perhaps there are cases where we use the specialized queues?
July 21	Write a report that describes the work down over the summer

[anshumanmohan]

This is exciting, and, IMO, largely within reach. It would be fun to use Calyx's static features as your describe. I believe the item you have for the week or July 14 will be particularly fun and rewarding.

What gives me pause is the very first item. I see you have given yourself a fortnight, but it's a tricky task and we lack expertise in that task. You'll need a combination of luck, self-taught Verilog skills, and help from Capra. I don't have anything very insightful to add to that agenda item, but I did want to point this out.

[sampsyo]

Thanks for thinking through this in detail, @polybeandip!

This is something I briefly mentioned to @anshumanmohan today, but I happened to catch a presentation about BBQ last week. Nirav made a compelling case that BBQ is (a) a good design for a general-purpose PIFO and (b) a pretty optimized open-source Verilog artifact. So if we're looking for an existing PIFO to wrap, it might be a good candidate! At least it might be worth revisiting the paper in detail to decide whether it is suitably general for our purposes?

In general, however, this trajectory seems like a great goal for the summer: an end-to-end Rio compiler workflow that uses off-the-shelf PIFOs and our scheduling-transaction logic, and possibly additional optimizations beyond.

This is probably a bad idea, but I think it would be "fun" to have occasional conversations along the way about the probably-too-ambitious idea of automatically generating these scheduling-transaction implementations.