cucapra/dahlia

Idea to support for Records in the Calyx Backend

Opened this issue · 4 comments

Idea 1: Records are lowered to separate variables

Currently the Lower unroll and bank pass lowers arrays

let x: ubit<32>[64 bank 4];

after lowering

let x0: ubit<32>[16];
let x1: ubit<32>[16];
let x2: ubit<32>[16];
let x3: ubit<32>[16];

Similarly a record can be lowered

record ivector_t {
  x: bit<32>;
  y: bit<32>;
  z: bit<32>
}

let arr : ivector_t[128];

to something like this

let arr_ivector_t_x : bit<32>[128];
let arr_ivector_t_y : bit<32>[128];
let arr_ivector_t_z : bit<32>[128];

Cons:

  1. This would also affect the Vivado/Vitis HLS backend (maybe a good thing?)

Idea 2: Calyx specific

  1. Given a record the bit-width can be determined as the sum of individual elems. This can be used to create a std_reg or seq_mem of given width

Let me know your thoughts @rachitnigam

Yeah, this sounds like a fun idea! Basically, we'd be implementing a array-of-struct to struct-of-array transformation.

From the language semantics perspective, it enables parallel access to different fields at different indices (which is more powerful than what the type system allows for).

A possible alternative is concating the various fields together and extracting them through bit slicing if that makes sense. The upside with this is that we only allocate one memory.

I'm not particularly leaning towards either one; just wanted to highlight the space of options. Regarding Vivado backend: if you implement this as a lower pass, we can just disable it for Vivado like we do with unrolling.

I also thought about the slicing idea, though I'm not sure how that will scale/work out with the number of fields in the record (during synthesis, I suspect synthesis tools messing with generated Verilog). The AoS to SoA transform seems quite elegant and simple. I'm going to try a Proof of Concept

Btw, https://capra.cs.cornell.edu/fuse/docs/overview/ is out of date

Can you publish the updated docs.

Hm, the website publishing flow is currently broken. Could you open an issue about it? I think we'll need to host it using Github pages. We might as well use mdbook which is more lightweight than docusaurus.