-
Notifications
You must be signed in to change notification settings - Fork 299
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
Support sequential module; initial implement of lowering BufferOp #42
Conversation
@@ -143,10 +149,10 @@ static std::string getSubModuleName(Operation *oldOp) { | |||
/// circuit is pure combinational logic. If graph cycle exists, at least one | |||
/// buffer is required to be inserted for breaking the cycle, which will be | |||
/// supported in the next patch. | |||
static FModuleOp createTopModuleOp(handshake::FuncOp funcOp, | |||
static FModuleOp createTopModuleOp(handshake::FuncOp funcOp, bool hasClock, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why bother to make this optional? I think we can just always generate this. Alternatively, there should be a list of clocks to support multi-clock designs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. Let me try to support multiple clocks.
|
||
Value clock = portList[2][0]; | ||
Value reset = portList[3][0]; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like you're missing something here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the logic is not implemented in this patch. The buffer sub-module is an empty placeholder.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like I mentioned in the patch description, since the buffer here can be implemented separately as an IP, maybe that is a more convenient way.
Support sequential logic now! Sequential sub-modules will have clock and reset signals as arguments.
Currently the only supported sequential sub-module is buffer, which is lowered from handshake::BufferOp. In this patch, the logic of buffer is not implemented and the buffer sub-module is an empty placeholder.
BTW, since some components (e.g. buffers and some handshake elastic operations) can be implemented in FIRRTL / Verilog separately as parameterized template / IP, and imported through FIRParser, do you think this is a better way for the implementation of components like buffers?