@mortbopet There is some question in my mind as to whether or not dc.buffer should support initial values at all. It's only used by HLS, correct? If so, we should probably remove it from DC and do something about it in the HandshakeToDC conversion. Just to keep things abstract, we should maybe introduce some sort of dc.init_values op which just spits out a series of tokens.

@teqdruid as of right now, yes, it is only used for HLS... but that's because HLS is the only thing that uses it! Based on our offline discussions about buffers, yes, i could see how there may be an argument against buffers. But, DC is intended to be able to represent arbitrary control-flow graphs - HLS is just one user of that. My biggest worry about removing dc.buffer is that it's (again, from DHLS' point of view) required to be able to break control-flow loops. But, whether that is constraint that enters at the Handshake level (a generic dataflow constraint), or at the (Handshake | DC) -> HW level is a good question.

I'd be interest in hearing @luisacicolini's thoughts on this. AFAIK, you made an attempt at modelling DC semantics, correct? did you have any interesting conclusions wrt. dc.buffer? (did you find it a requirement for the dialect to be able to express the things you needed to express? was it "awkward" to fit it into the abstraction level you were modelling? ...).

Hi @mortbopet @teqdruid :)
So in our semantics we are currently ignoring dc.buffer, under the assumption that the behavior of the overall circuit is in fact independent of the buffers and their placement - also looking at some literature in the area. However, this is still very much WIP, and reasoning about the role of buffers is definitely one of the things that we are stuggling with, too. CC: @ymherklotz @alexkeizer

I'm not arguing against dc.buffer. I'm arguing to remove the initialValues option from it. Then if HandshakeToDC needs to add some initial values, it is responsible for adding some widget to populate the initial values at every reset.