-
Notifications
You must be signed in to change notification settings - Fork 31
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
Add synchronous clear #42
base: pulp-v1
Are you sure you want to change the base?
Conversation
53cb97f
to
c836128
Compare
7935cf9
to
571c615
Compare
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.
Hi Yvan, thanks for the PR. I have just a couple of comments.
We have been planning for a while to change to the common cells register macros (https://github.com/pulp-platform/common_cells/blob/master/include/common_cells/registers.svh). That would give more flexibility when choosing FFs but I see that this would be out of the scope for this PR.
parameter SIM_INIT = "none", | ||
parameter SIM_INIT = "zeros", |
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.
Is this necessary?
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.
It is not strictly needed for this PR, no. I swapped this when working on lockstepped redundant execution. In that case if the caches or any memories propagate Xs to the checker that controls the buses, it might have unwanted behaviour (also during RTL simulation). Since memory macros never have undefined states (would be either initialized at random values or at 0), to reproduce a scenario that is more similar to what we would have on the silicon I changed the init parameter. We could do this also in other ways (preloading in testbenches) or anyway remove this from this PR.
core/cva6.sv
Outdated
rst_uarch_n <= rst_uarch_controller_n; | ||
rst_uarch_n <= rst_uarch_controller_n & ~clear_i; |
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.
rst_uarch_n
is asynchronous. There are some hazards when driving this with a synchronous signal (e.g. glitches). Are you sure you need to reset non-architected state?
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.
If so, we need to make sure that this is stable e.g. by latching the signal
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.
Did not figure out it to be asynchronous, I will tackle this differently.
core/issue_read_operands.sv
Outdated
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.
This will break fence.t
, which resets all non-architectural, microarchitectural state while preserving the architectural state (which you are clearing here). could you connect this directly to clear_i
from the top-level?
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.
Sure!
@niwis turning this to draft after related discussion. |
a1bf0bc
to
046b645
Compare
Hey @niwis, I mark this as ready for review even though some work still needs to be done. I have two questions, if you could provide a few hints that would be greatly appreciated.
Thank you! |
8dac0fd
to
03819d3
Compare
The CI still does not work, there is still the issue of automatically testing the integration into Cheshire. The branch where I tested it is this. The CI succeeds even though there is still the VCU issue (all the Cheshire branches break because of it, I think it is a problem of board availability). |
Hi @yvantor,
|
Thanks for the feedback, should be fine now! |
Synchronous clear is useful for applications where the core internal status must be flushed from the outside (for example, a redundant unit detects an error and needs to flush the core to bring its internals to a clear state), without compromising the regular asynchronous reset path.