Idea to support for Records in the Calyx Backend
Mark1626 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:
- This would also affect the Vivado/Vitis HLS backend (maybe a good thing?)
Idea 2: Calyx specific
- Given a record the bit-width can be determined as the sum of individual elems. This can be used to create a
std_reg
orseq_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.