[RACL] Enable initial RACL support for sram_ctrl #26047
Conversation
davidschrammel
requested review from
Razer6,
rswarbrick and
vogelpi
and removed request for
msfschaffner
davidschrammel
force-pushed
the
racl-support-sram_ctrl
branch
from
9f0626b to
c14d791
Compare
| // Enable asynchronous transitions on alerts. | ||
| parameter logic [NumAlerts-1:0] AlertAsyncOn = {NumAlerts{1'b1}}, | ||
| parameter logic [NumAlerts-1:0] AlertAsyncOn = {NumAlerts{1'b1}}, |
There was a problem hiding this comment.
I realise that this indentation change is probably the right thing to do (either that or shortening some of the indents, to wrap "per block").
But can we split it out of the commit that enables RACL? Or drop the change from this PR?
There's no reason the changes need to be atomic.
| .clk_i, | ||
| .rst_ni, | ||
| .tl_i (regs_tl_i), | ||
| .tl_o (regs_tl_o), | ||
| .tl_i ( regs_tl_i ), |
There was a problem hiding this comment.
A similar note here to the one about the spacing earlier. I'd suggest trying to match the format in the existing code.
(I've just looked and it's really rather inconsistent in this file! Very happy for a follow-up that makes it consistent, but it should be a separate commit)
…face) Signed-off-by: David Schrammel <[email protected]>
Signed-off-by: David Schrammel <[email protected]>
davidschrammel
force-pushed
the
racl-support-sram_ctrl
branch
from
c14d791 to
d47fc48
Compare
@rswarbrick I have separated out the formatting changes. Are there any other changes that you wanted to be separate? Unfortunately, a lot of the code changes are auto-generated and I don't think it makes sense to put those in a separate commit as well. Apart from that, similarly to #26044 I would also rebase this PR on top of #26056 after it has been merged. |
This commit enables RACL for
sram_ctrl. However, we only enable it for itsregstlul interface for now. Enabling RACL for itssramtlul interface will follow in a separate commit or PR since it requires more intrusive changes.The issues raised in #26004 also affect generated files here.
They are fixed in #26056 and I will rebase this PR on top assuming #26056 will be merged to master before this PR.