Separate code generation for module with interface argument is not supported #454
Replies: 1 comment 1 reply
-
This was removed over 19 years ago, in an early version of BSC before the company Bluespec even existed. Instead of calling it an experimental feature, it might be more fair to say that it was a feature in BSC when BSC itself was experimental. If this feature ever worked, it was because the scheduling and synthesis was very different at the time and, as it matured (or was radically changed), the feature no longer made sense, and was therefore disabled. Synthesizing a module with interface arguments is possible, but you would need to define what it means (for scheduling and code generation), and what it looks like for the user. When you synthesize a design into separate modules, you are creating modules that each have their own scheduling logic, and which coordinate with each other through their ports. BSC's current code-generation creates Another thing to consider is that BSC can currently synthesize a module without knowing the whole design. And BSC generates a Verilog module that is not specific to the design, and can be used within any design that uses the module. But you could imagine changing BSC to read the entire design, and then to generate Verilog modules, knowing the context that they will be used in. This is also intertwined with the previous point: if BSC is able to read the entire design, then it could create a single global scheduler, and BSC could output a Verilog module for the scheduler, which has wires going out to all of the modules, telling those modules how to behave. (That is, a global scheduler, instead of a network of cooperating local schedulers). Another interwined issue is how much scheduling information is infered by BSC versus given by the user. The way that BSC's modularity works now is that modules have scheduling properties: the properties of primitive modules are provided and BSC infers the properties for user-written modules (based on the properties of the submodules that they use). For interface arguments, would you want BSC to infer their scheduling properties? This is intertwined with the earlier issues because, if BSC has access to the entire design, then it could see what module is being passed in and it could infer the properties of that module, for use in the scheduling of the module taking it as an argument. This requires being able to linearize the design into an order for synthesis, or else to resolve a set of recursive equations (if the design has modules that use each other's interfaces, possibly indirectly through other modules). A simple first step would be to require the user to provide the scheduling properties for the interface argunment, and then later check that the module passed in has those properties. (This is like type checking: the user provides a type signature for a function and then, wherever it's called, BSC checks that the provided argument has the right type.) However, even with this simplification, you have to decide what to do in situations where, for example, the same interface is passed as an argument to two separate submodule: BSC needs to guarantee that two submodules aren't trying to simultaneously call conflicting methods of the interface argument. (This is a situation where additional ports can help: submodule A can have an output wire that is asserted when it is calling a method, and this can be an input to submodule B, which won't call conflicting methods when that wire is asserted. For example.) Murali Vijayaraghavan et al at MIT did some work in this direction. I don't recall what is the best (or latest) reference for this, but I do see that there is a paper in the MEMOCODE 2013 conference, called "Modular compilation of guarded atomic actions". I believe that they use additional wires, in situations where more information needs to be communicated. I have also done some thinking on this. One area that I thought about was the inference question, and I came up with an idea called "liberties" (which hasn't been published anywhere, but I can probably dig up an old email writeup). When a synthesized module has a return interface with multiple methods, the scheduling properties that BSC infers are constraints on how the parent module is allowed to use those methods -- they are restrictions that say, for example, that method That also doesn't answer what to do about interfaces that are passed to two separately synthesized modules. A simple first step would be to only allow interfaces to be passed to one. Or, better, to say that the methods passed to submodule A must be conflict-free with any methods passed to submodule B (so that each can be free to use the methods without coordinating with the other module). I believe I'd done some thinking on this too, and could maybe find an old email. And that's just the simplest example of the kinds of situations that need to be handled. A module can take multiple interface arguments, which could come have conflicts (such as coming from a common source). An interface could be laundered through layers of separately synthesized modules, and scheduling still needs to guarantee that multiple users aren't making conflicting use the methods. Anyway, hopefully that gives you some idea of the issues. You might be able to find more work, at MIT or elsewhere, by searching for "bluespec" and "modularity", or "modular compilation", etc. |
Beta Was this translation helpful? Give feedback.
-
Hello,
My understanding is that generating verilog for a module that has an interface argument is currently not supported. Looking around in past commits, I found that at some point there was an experimental feature that allowed this:
Beta Was this translation helpful? Give feedback.
All reactions