Conversation
53cb97f to
c836128
Compare
7935cf9 to
571c615
Compare
niwis
left a comment
There was a problem hiding this comment.
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 USER_EN = 0, | ||
| parameter NUM_WORDS = 1024, | ||
| parameter SIM_INIT = "none", | ||
| parameter SIM_INIT = "zeros", |
There was a problem hiding this comment.
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.
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.
If so, we need to make sure that this is stable e.g. by latching the signal
There was a problem hiding this comment.
Did not figure out it to be asynchronous, I will tackle this differently.
There was a problem hiding this comment.
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?
|
@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.