Incorrect error about meaningless access property combination

[craigc40]

Importing the SystemRDL snippet below returns this error:

.\mytestmap.rdl:6:21: error: Field 'EnablePs' access property combination is meaningless: sw=w; hw=na;
StrobeBit_t EnablePs[0:0];

addrmap TopAddrMap {
    reg {
        field StrobeBit_t {sw=w; hw=na; singlepulse; reset=1'b0;};
        field StatusBit_t {sw=r; hw=r;};

        StrobeBit_t EnablePs[0:0];
        EnablePs->desc = "Write a 1 to this bit to enable the power supply";

        StrobeBit_t DisablePs[1:1];
        DisablePs->desc = "Write a 1 to this bit to disable the power supply";

        StatusBit_t PsEnabled[0:0];
        PsEnabled->desc = "This bit returns a 1 if the power supply is enabled";

        // Control the state of the PsEnabled bit
        PsEnabled->hwset = EnablePs;
        PsEnabled->hwclr = DisablePs;
    } PowerSupplyControl;

};

The EnablePs and DisablePs fields work together to set or clear the PsEnabled bit (which is read by HW). They are write-only by SW and do not need to be read by HW, so I think the property combination should be considered valid (at least for the case where the field in question controls another field that is read by either SW or HW).

[amykyta3]

Aha interesting. I think I added that validation rule based directly off of Table 12 in section 9.4.1 of the RDL spec. It must not properly take the hwset/hwclr properties into account.

Looks like during elaboration, I need to keep track of whether the field value was ever referenced in addition to the hw property. Pretty subtle.

Will fix!

[craigc40]

Looks like you were following the spec correctly, and the spec itself is wrong. Perhaps there's a better way to implement a set/clear pair of bits, but the example above sure seems valid and a clean way to approach the problem.

I noticed that the table entry for field f { sw = r; hw = r; }; is probably wrong as well, since a field that is affected by hwset/hwclr is not constant. I sent an email to systemrdl@lists.accellera.org to report this and hopefully get clarification on both spec issues.

For what it's worth, it may not be a bug if it is invalid to drive hwset and hwclr with a field instead of a signal. I do think that the spec is wrong in the second case regardless.

As an experiment, I changed the hw property of EnablePs to 'r' to get past the error and used the PeakRDL-regblock command to generate System Verilog. I didn't try to simulate, but on inspection it appears that the code produced matches what I had described in the SystemRDL.

[amykyta3]

I wouldn't say the spec is wrong, but rather that Table 12 only shows a very limited window into the field access policy combinations. I still agree with the spec that on its own, sw=w; hw=na is meaningless. However once you introduce the hwset/hwclr properties, they imply that the field contains a storage element which changes the interpretation.

The SystemRDL spec is merely a guide and does not attempt to describe every permutation of properties, so we are left to interpret it the best we can.

[amykyta3]

Fixed in 1.25.4