You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We’ve been talking about so-called “method-based interfaces” for calyx for a while. The idea is to support components that can be called in multiple ways. For example, we can call the newly added synchronising register with either the write go/done ports or write go/done ports. Invoke currently only supports compiling with one set of go done ports.
I have a few proposals to make it work with multiple go/done interface. Unfortunately all of them rely on attributes which yet again adds semantic meaning to what are essentially comments:
Require invoke to specify distinguished go/done ports. Error if none are specified or default to the primitive specified go/done ports.
Add multiple go/done interfaces for the primitives and use numbers to group go/done symbols together. In the invoke, specify this number in the invoke.
The text was updated successfully, but these errors were encountered:
Just to fill out the design space, another option would be to extend the language to have multiple, named control programs for each component. We would then need a way to associate a go/done pair with a control program, which would presumably also use this name. Then the invoke statement would need to reference this name.
It's been roughly a year since we've thought of this problem. We've frankly not run into this much at all but worth asking @andrewb1999 if AMC might benefit from something like this?
We’ve been talking about so-called “method-based interfaces” for calyx for a while. The idea is to support components that can be called in multiple ways. For example, we can call the newly added synchronising register with either the write go/done ports or write go/done ports. Invoke currently only supports compiling with one set of go done ports.
I have a few proposals to make it work with multiple go/done interface. Unfortunately all of them rely on attributes which yet again adds semantic meaning to what are essentially comments:
The text was updated successfully, but these errors were encountered: