[FEATURE] Auto-Formatting Support for Register Array Path

[Zeeshan88c]

Problem
SystemRDL does not provide a standard mechanism for handling register array paths.
For arrays, paths have to be written or managed manually for each index, which becomes repetitive, error-prone, and difficult to scale.

Proposed solution
To handle this, I used a placeholder pattern (e.g., [%0d]) in the path definition of backdoor access in RDL.
A Python script then processes these paths and converts them into properly formatted $sformatf expressions. This is handled within the register array loop , so paths are directly accessible for every entry without manual duplication. This automatically generates correct paths for all array elements.

Suggestion
This approach could be standardized or integrated into the flow to provide a consistent and scalable way to handle register array paths.

[amykyta3]

Could you provide more detail on which component of PeakRDL you are referring to?

Is this a comment on the SystemRDL language itself, the compiler implementation and API, or perhaps one of the many sub-tools of PeakRDL?

[Zeeshan88c]

This stems from a limitation in SystemRDL rather than the compiler API itself.

When using hdl_path or hdl_path_slice, the value is treated as a static string. SystemRDL does not provide a mechanism to describe indexed HDL paths for register arrays or to bind an array index to the path expression.

Because of that, even if a placeholder like [%0d] is used in the RDL, it is not interpreted by the language or carried through as an index-aware construct.

In the generated UVM model from peakrdl, this shows up inside the register array loop as:

reg_array[i0].add_hdl_path_slice("BLOCK.reg_array[%0d]", -1, -1);

Even though this is emitted inside a for loop and the index (i0) is available, the path remains a literal string.

To make it functional, my post-process script makes it into:

reg_array[i0].add_hdl_path_slice($sformatf("BLOCK.reg_array[%0d]", i0), -1, -1);

This allows each iteration of the loop to generate the correct indexed backdoor path without manual expansion.

So the core limitation is that SystemRDL does not capture index-aware path information, and the generator does not currently leverage the available loop index to construct dynamic paths.

The suggestion is to standardize handling of this case in the UVM backdoor generation flow so that array indices can be incorporated automatically, avoiding the need for placeholder conventions and post-processing.

[amykyta3]

I see. I agree this is a limitation with the SystemRDL language. In general I have found that SystemRDL's specification of HDL paths to be quite lacking, and even broken in some cases.

Adding a format string would be one way to work around this issue, but it is still imperfect - in situations where a design has multi-dimensional arrays, or nested arrays, it is unclear which index this refers to. This can be problematic especially in cases where HDL paths do not map linearly to a single index (consider ASIC RAM-based register files that create 2d arrays of SRAM sub-elements). A more robust solution would require more advanced syntax.

Since this is something that would affect the SystemRDL standard itself, it is out of scope for me to change this behavior. Accellera is the governing organization for the SystemRDL language so I would recommend reaching out to them regarding feedback. I have had some luck with their public forums in the past: https://forums.accellera.org/forum/52-systemrdl-discussion/

[Zeeshan88c]

Thank you for the detailed response — I agree that a fully robust solution would require enhancements at the SystemRDL language level, particularly for SRAM-based implementations.

I wanted to clarify, however, that the placeholder-based approach can still handle multi-dimensional arrays in a deterministic and scalable way for structurally aligned RTL.

For example, using positional placeholders:

BLOCK.BOR[%0d][%1d]

Within the generated UVM model, and after running my post-processing script it fixes it and puts it inside the loop:

In this approach:

%0d, %1d, etc., map positionally to the loop indices (i0, i1, …)
The generator already has access to these indices
The mapping remains consistent for both 1D and multi-dimensional arrays

This keeps the mapping deterministic and avoids ambiguity in practical scenarios. The key point is that the index information already exists at generation time but is not currently utilized when emitting HDL paths. A potential improvement within PeakRDL’s UVM generation could be to detect such placeholders and automatically generate $sformatf(...) using the available loop indices, which would remove the need for post-processing while remaining backward-compatible.

[Zeeshan88c]

@amykyta3 , I couldn’t post this on the Accellera public forum facing some issues so asking here.
For supporting position-based formatting in hdl_path` (e.g., %0d, %1d-style indexing), would this first require SystemRDL level changes to formally define it?
If so, then the follow-up would be implementing the corresponding string formatting support in PeakRDL , just want to confirm if this is the correct flow for introducing this improvement.