How to handle reserved/undefined fields/registers.

[jeras]

When generating a HDL implementation from SystemRDL, how should unused/reserved fields/registers be handled.
Is there SytemRDL syntax for reserving fields by default without explicitly defining reserved fields?
Is there a syntax for having partial register address decoders by default?
Searching the standard for keywords partial and reserved I could not find anything useful.

Fields

As common practice, reserved fields are sometimes defined explicitly, and sometimes they are just left undefined.
When explicitly reserved, the recommendation is usually to always write 0 into a reserved field and that reading would return a 0.

One common case would be single bit fields representing something like an enable, interrupt, ...
In this case the purpose of reserving unused fields is to be able to add new fields in the feature without breaking backward compatibility.

Another common case would be storing a number in a field which is less than regwidth wide.
In this case there is an advantage, if the CPU can load/store the value and interpret it as a number without extra masking.
For unsigned numbers the reserved/unused bit fields should be 0, for signed numbers they should be the same as the number's sign field.

In the given cases it makes sense to have defined reserved fields, usually 0.

As an alternative undefined fields could be left for the synthesis tool to optimize as a partial decoder.
But this option is not a good fit for software, where it is common to assume unused fields are 0.

Registers

Reserved/undefined registers would be padding the undefined holes between defined registers.
This registers are only read written to in case of a burst/pre-fetch scheme, or as a bug in the SW.

It is common to let the synthesis tool optimize them into a partial address decoder.
This can be done by setting them to X in the default of the case statement for a read address decoder.

[amykyta3]

In SystemRDL, there is no need to explicitly define reserved fields or register addresses. Reserved space is simply implied by gaps in bit-ranges or addresses in the model's description.

In general, the RDL spec does not make any attempt to recommend how a register file will be implemented in RTL. This is a pretty pervasive philosophy in the spec - it describes the register description language itself, and not necessarily how it will be used to generate code. If you want your RDL to control this aspect of the RTL implementation, you can always use a user-defined property to apply such a concept to your model.

Regarding implementations - it is up to you to decide.
Sure, there is some possible optimization the synthesizer can perform if you assign readbacks of undefined addresses/bits to be don't-care X's, but I have found that the savings is usually negligible. In my opinion, having "clean" reserved space return 0's on readback is more preferable and causes less confusion.

[jeras]

Thanks for the reply amykyta3.

I agree the synthesis optimization due to don't care X values is mostly negligible and confusing, and therefore not really worth a long discussion.

What I am still looking for is a way to sign extend integer and fixed point values so that SW does not have to perform a custom sign extension before being able to interpret the value as a signed integer.

I will prepare an example of a user defined property for solving this (sign extension, fixed point). My aim here is not to create a standard extension to SystemRDL, I just want to discuss my approach so it makes sense before (if) I implement it. Hopefully the idea will be useful to others.

[jeras]

I wanted to see how PeakRDL-cheader handles reserved locations, so I wrote a test case:

addrmap test {
    default regwidth = 32;
    reg {
        field {} val [32];
    } conf0;
    reg {
        field {} val [32];
    } conf1;
    reg {
        field {} val [32];
    } conf3 @0xC;
};

Part of the generated code is the structure:

// Addrmap - test
typedef struct __attribute__ ((__packed__)) {
    uint32_t conf0;
    uint32_t conf1;
    uint8_t RESERVED_8_b[0x4];
    uint32_t conf3;
} test_t;

When I initially started this discussion, I was also looking for some kind of help from the compiler when generating reserved registers, so I don't have to check if there is unused space between defined registers.
This help could be in the form of an option similar to unwrap, which would create nodes for reserved spaces.

Just a comment, I expected a RESERVED to be of type uint32_t, the type could be sized like the regwidth default, but as far as I know, the compiler does not expose default values directly to the user.