Skip to content
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

[racl] Follow-up fixes to TLUL adapter and reg_top #26056

Merged
merged 4 commits into from
Jan 30, 2025

Conversation

Razer6
Copy link
Member

@Razer6 Razer6 commented Jan 29, 2025

This PR is a follow up to the review in #26004 (review):

It adds:

  1. Proper qualification of the read and write request with the necessary TLUL signals for the reg and sram adapter
  2. Properly qualify the error log computation in the reg_top with the access control signal coming from the reg_adapter.

@Razer6 Razer6 requested a review from msfschaffner as a code owner January 29, 2025 12:20
@Razer6 Razer6 requested review from alees24 and removed request for msfschaffner January 29, 2025 12:20
@Razer6 Razer6 requested a review from a team as a code owner January 29, 2025 13:27
@Razer6 Razer6 requested review from matutem and removed request for a team January 29, 2025 13:27
util/reggen/reg_top.sv.tpl Outdated Show resolved Hide resolved
parameter bit RaclErrorRsp = 1'b1,
parameter bit RaclErrorRsp = EnableRacl,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm convinced that this is cleaner code, so it looks like the right thing to do. But does it actually change behaviour? I think the parameter is only used to qualify racl_error_o. This, in turn, is only true if we hit a register that doesn't have a matching racl permission and every register gets a permission if EnableRacl is false.

Is that correct? Probably worth explaining in the commit message why the change is needed (either cleaning stuff up or fixing some bug that Rupert didn't see!)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No there is no change in behaviour. Is proposed by Adrian, this is jus a safeguard to not send out a spurious racl error if RACL is disabled. Nothing else.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I included that in the commit message.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rswarbrick If the racl_error_o generation logic is correct, such that RACL errors cannot be raised spuriously, then it has no functional impact on non-RACL designs. It's belt'n'braces.

hw/dv/sv/mem_bkdr_util/mem_bkdr_util_row_adapter.sv Outdated Show resolved Hide resolved
@Razer6 Razer6 force-pushed the racl-fixes branch 3 times, most recently from cc3ec4a to 7f69d97 Compare January 29, 2025 17:41
Copy link
Contributor

@alees24 alees24 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for fixing up the rd_req/wr_req logic in the two adapters. Just the templated (+autogen) 'racl_error_o' logic that needs fixing now, I think.

util/reggen/reg_top.sv.tpl Show resolved Hide resolved
parameter bit RaclErrorRsp = 1'b1,
parameter bit RaclErrorRsp = EnableRacl,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rswarbrick If the racl_error_o generation logic is correct, such that RACL errors cannot be raised spuriously, then it has no functional impact on non-RACL designs. It's belt'n'braces.

@Razer6 Razer6 force-pushed the racl-fixes branch 2 times, most recently from 56fb6b5 to 9f5d722 Compare January 29, 2025 21:26
@Razer6 Razer6 requested a review from alees24 January 29, 2025 22:11
The RACL address hit needs to be qualified with the associated
read or write access signal. Otherwise, a denied RACL access might
not get logged as en error.

Signed-off-by: Robert Schilling <[email protected]>
This acts as a safe guard and ensures that there are no
spuriouos error logs if RACL is disabled. This does not have
any functional impact.

Signed-off-by: Robert Schilling <[email protected]>
Copy link
Contributor

@alees24 alees24 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, LGTM.

@alees24
Copy link
Contributor

alees24 commented Jan 30, 2025

CHANGE AUTHORIZED: hw/ip/i2c/rtl/i2c.sv
CHANGE AUTHORIZED: hw/ip/mbx/rtl/mbx.sv
CHANGE AUTHORIZED: hw/ip/pwm/rtl/pwm.sv
CHANGE AUTHORIZED: hw/ip/spi_host/rtl/spi_host.sv
CHANGE AUTHORIZED: hw/ip/tlul/rtl/tlul_adapter_reg_racl.sv
CHANGE AUTHORIZED: hw/ip/tlul/rtl/tlul_adapter_sram_racl.sv
CHANGE AUTHORIZED: hw/ip/uart/rtl/uart.sv
CHANGE AUTHORIZED: hw/ip_templates/ac_range_check/rtl/ac_range_check.sv.tpl
CHANGE AUTHORIZED: hw/ip_templates/alert_handler/rtl/alert_handler.sv.tpl
CHANGE AUTHORIZED: hw/ip_templates/rv_plic/rtl/rv_plic.sv.tpl

@alees24 alees24 requested a review from rswarbrick January 30, 2025 12:09
@alees24
Copy link
Contributor

alees24 commented Jan 30, 2025

CI failures unrelated.

@alees24 alees24 merged commit f6c8df4 into lowRISC:master Jan 30, 2025
34 of 38 checks passed
@Razer6 Razer6 deleted the racl-fixes branch January 30, 2025 13:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants