Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idea to support for Records in the Calyx Backend #424

Open
Mark1626 opened this issue Mar 9, 2024 · 4 comments
Open

Idea to support for Records in the Calyx Backend #424

Mark1626 opened this issue Mar 9, 2024 · 4 comments

Comments

@Mark1626
Copy link
Collaborator

Mark1626 commented Mar 9, 2024

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

@rachitnigam
Copy link
Member

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.

@Mark1626
Copy link
Collaborator Author

Mark1626 commented Mar 9, 2024

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

@Mark1626
Copy link
Collaborator Author

Mark1626 commented Mar 9, 2024

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

Can you publish the updated docs.

@rachitnigam
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants