`sw_access` in JSON output doesn't seem to match HDL

[jamesmunns]

For post_code_monitor, the fields are marked read only to software:

quartz/hdl/ip/vhd/espi/sys_regs/espi_regs.rdl

Lines 131 to 135 in 6f68cc7

	field {
	default sw = r;
	default hw = w;
	desc = "0x1de90001 - PHBLhello. Sticky: set when post code is seen, cleared by hardware on new boot.";
	} phbl_hello[7:7] = 0;

But in the generated JSON, the sw_access is marked as "rw":

{
    "type": "field",
    "inst_name": "phbl_hello",
    "lsb": 7,
    "msb": 7,
    "reset": 0,
    "sw_access": "rw",
    "se_onread": null,
    "se_onwrite": null,
    "desc": "0x1de90001 - PHBLhello. Sticky: set when post code is seen, cleared by hardware on new boot."
}

This leads to the codegen emitting setters for these fields, which is perhaps not what we want!

[Aaron-Hartwig]

Hmm, when I print the output from the rdlc (the systemrdl compiler) I see it set as rw as well:

  field: phbl_hello [7:7]
    sw: AccessType.rw
    hw: AccessType.r
    desc: 0x1de90001 - PHBLhello. Sticky: set when post code is seen, cleared by hardware on new boot.
    reset: 0

There's likely some issue this property being overwritten somehow when the compiler is chewing on our RDL.

[Aaron-Hartwig]

Okay, it seems like setting the sw/hw properties on the field node are getting overwritten with the addrmap defaults. If I move those definitions up to the reg level, they work. I'll go look at the spec again and see if we're doing something wrong here.

[Aaron-Hartwig]

Turns out the compiler eats any usage of default within a field and the property is left unset, which explains why the addrmap defaults were getting picked up and why when I made the default definition at the reg level things worked.