Discussion: Introduce `dyn_mem_d1` primitive?
Closed this issue · 2 comments
It seems like it could be useful to have a primitive dyn_mem_d1 that describes memories that are not guaranteed to finish in a single cycle. This would allow us to better represent external memories in Calyx and account for their dynamic behavior (say, fetching from DRAM or making an AXI request).
This would help progress #1733 with the dynamic AXI generation work. In particular this, along with #2085, would allow us to use axi_seq_mems in place of seq_mems (or more precisely, these new dyn_mems), which is not currently allowed because the content_en port of an axi_seq_mem does not have the @interval(1) attribute, so these ports are not considered equal when type checking.
As a happy aside, it seems like the implementation of this should be fairly straightforward. I think it would suffice to copy seq_mem implementations and remove the @interval(1) attribute? Maybe there's some more work to do if seq_mems get special treatment in the compiler that we'd want to port over to these new dyn_mems.cc @calebmkim if you might have thoughts on anything like this?
Sorry I'm behind the loop on this. Honestly you probably know use cases for dyn_mem better than me so I don't have much to add.
Regarding how it would go over in the compiler-- I can't think of any problems with adding a dyn_mem_d1, although (as you already say) you should definitely remove the @interval attribute.
Currently as a short-term solution we will be introducing dyn_mems with a verilog implementation equivalent to that of seq_mems, and a calyx interface that removes the static annotation @interval(1). In the long term, we hope to introduce virtual operators (see #1151) and allow the compiler to decide on concrete latencies for dyn_mems in general.