[BUG] RASDepth=1 creates invalid slices in ras.sv #3587

Code of Conduct

• I have searched the existing bug issues.
• I am a human engaging in an interpersonal interaction. During this interaction, my words are my own and are not generated. If relevant, I provide links to my sources.

CVA6 commit affected

6cb2001

Bug Description

Bug Description

RASDepth is a public configuration parameter, and config_pkg::check_cfg accepts every value greater than zero. However, setting RASDepth=1 makes the production RAS shift logic form the invalid ranges [0:1] and [-1:0], preventing RTL generation. I think this is a CVA6 parameter/RTL consistency issue rather than a RISC-V ISA violation. RISC-V defines call/return hints that an implementation may use for return-address prediction, but it does not require a particular RAS depth.

Steps to reproduce

I have provided the reproduction scripts in test.zip.

• test/cva6_ras_depth_tb.sv instantiates the production RAS, calls config_pkg::check_cfg, and checks a push/pop operation for the control configuration.
• test/run.sh runs the depth-two control and verifies the depth-one compile-time failure against the production source.

To reproduce the issue, execute the following steps:

1. Use the affected CVA6 checkout.
2. Place the attached test directory next to this issue draft.
3. Run bash test/run.sh.

The test instantiates the production core/frontend/ras.sv with a minimal configuration derived through cva6_cfg_t. It first compiles and simulates DEPTH=2, including a push/pop check, and then compiles the otherwise identical DEPTH=1 trigger.

The relevant output is:

RAS_DEPTH_2_OK
%Warning-SELRANGE: core/frontend/ras.sv:50:14: [0:1] Slice range has ascending bit ordering
%Warning-SELRANGE: core/frontend/ras.sv:50:35: [-1:0] Slice range has ascending bit ordering
%Warning-SELRANGE: core/frontend/ras.sv:54:14: Selection index out of range
BUG_CONFIRMED: check_cfg accepts RASDepth=1 but production ras.sv contains invalid one-entry slices

Expected behavior

A one-entry RAS accepted by check_cfg should compile and support one push/pop entry. If the implementation intentionally requires at least two entries, check_cfg and the parameter documentation should reject one with a clear RAS-specific diagnostic.

Observed behavior

The two-entry control compiles, runs, and passes the push/pop check. With one entry, Verilator reports invalid and out-of-range selections in ras.sv and cannot produce the executable model. The error occurs before an instruction-level test can run.

Root cause analysis

The push path always executes stack_d[DEPTH-1:1] = stack_q[DEPTH-2:0], while the pop path always executes stack_d[DEPTH-2:0] = stack_q[DEPTH-1:1]. These are valid for depths of at least two but become [0:1] and [-1:0] when DEPTH=1. There is no one-entry special case, while check_cfg only asserts Cfg.RASDepth > 0.

The relevant source is core/frontend/ras.sv around lines 45–57 and core/include/config_pkg.sv around lines 464–469. The design manual also describes the RAS as a LIFO composed of RASDepth entries without documenting a minimum of two.

Reproduction test case

• test/cva6_ras_depth_tb.sv instantiates the production RAS, calls config_pkg::check_cfg, and checks a push/pop operation for the control configuration.
• test/run.sh runs the depth-two control and verifies the depth-one compile-time failure against the production source.

Possible fixes

The preferable fix is to special-case DEPTH==1 so push writes entry zero and pop invalidates entry zero without evaluating empty shift slices. The smaller alternative is to change the configuration check to require RASDepth > 1 and document that restriction. A regression should cover the minimum accepted nonzero depth.

Environment and source

• CVA6 commit: 6cb200105fb9441d170e45786125a737fab98e91.
• Host: Linux x86_64.
• Verilator: 5.020.
• Relevant RTL: core/frontend/ras.sv.
• Configuration check: core/include/config_pkg.sv.