Two fields controlling one bit

[mpriestleyidex]

It's a common design pattern to have two fields control a single bit. Writing 1 to one field sets the bit, and to the other clears it. Writing 0 to either has no effect. The actual state of the bit might be read through the "set" field or yet another "status" field.

What's the 'right' way (or ways) of expressing this in SystemRDL?

Bonus marks - can I have a multibit field of setters, and a corresponding multibit field of clearers?

[amykyta3]

Sounds what you're looking for is an alias register: (PeakRDL-regblock doesn't support aliases yet, but i hope to add it soon)

reg my_register {
    field {
        sw=rw;
    } f[31:0] = 0;
};

// Primary instance of the register
// This has normal read/write access
my_register my_reg_rw @ 0x00;

// Alias of "my_reg_rw", but it has access policy write-1-clear
alias my_reg_rw my_register alias_w1c @ 0x04;
alias_w1c.f->onwrite = woclr;

// Alias of "my_reg_rw", but it has access policy write-1-set
alias my_reg_rw my_register alias_w1s @ 0x08;
alias_w1s.f->onwrite = woset;

[amykyta3]

Yep what you have would totally work.
In my prior example, the spec doesn't actually define if hwset or hwclr takes precedence, so its left up to the tool to decide 😒 . Looks like I arbitrarily chose hwset to take precedence in my code generator: https://peakrdl-regblock.readthedocs.io/en/latest/props/field.html#hwclr-hwset.

Since you got me curious, I realized you could make your field example multi-bit by doing:

reg {
    field {
        sw=rw;
        woset;
    } thing[7:0] = 0;

    field {
        sw=w; hw=r;

        // emulate a multi-bit singlepulse
        next = 0;
        precedence = sw;
    } clear_thing[15:8] = 0;

    // bitwise clear 'thing' using per-bit enables
    thing->hwenable = clear_thing;
    thing->next = 0; // hwenable suppresses the per-bit update
};

... Although I'm pretty sure this would work, it starts to get ugly. Using alias is probably more 'correct' 😆.

Thanks for the interesting discussion! (not annoyed at all haha!)

[craigc40]

This is exactly the info I was looking for! I'd also like to implement a Set/Clear pair of bits in SystemRDL, but I'd like to implement the following tweaks:

1. Readable bit has a different name than set bit (but still represents same value).
2. Define the HDL port that gets driven by the set bit. I do not need a port (or even a local signal) for the clear bit.

Here's my (wrong) attempt at the SystemRDL implementation where bit 0 is the set bit (and status), and bit 1 is the clear bit:

reg {
    field {
        sw=w;
        woset = true;
    } EnablePs[0:0];

    field {
        sw=w;
        singlepulse;
    } DisablePs[1:1];

    field {
        sw=r;
    } PsEnabled[0:0];

    signal {} PsEnabledSignal;

    EnablePs->hwclr = DisablePs;
    EnablePs->???? = PsEnabled;            # trying to drive PsEnabled with value of EnablePs (or PsEnabledSignal?)
    EnablePs->???? = PsEnabledSignal;  # trying to associate port PsEnabledSignal with EnablePs
    DisablePs->???? = na;                       # trying to associate no signal with DisablePs
} PowerSupplyControl;

Any suggestions?

[amykyta3]

I think what you are looking for is the hw access property. If you set hw=r, then this infers an output signal that contains the value of that field. No need to declare a separate signal.

Try this. I reworked what you have slightly:

reg {
    field {
        sw=w;
        hw=r; // expose the EnablePs strobe to be visible to hardware. Infers an output
        singlepulse;
    } EnablePs[0:0];

    field {
        sw=w;
        hw=na; // No hardware access to this
        singlepulse;
    } DisablePs[1:1];

    field {
        sw=r;
        hw=r; // Assume you want to know the state of this too in hardware? or perhaps not?
    } PsEnabled[0:0];

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

[craigc40]

Thank you! I didn't really understand the hw property before. Is its net effect solely to describe what ports get created in generated HDL? Is the following table correct?

hwmode	function
hw=r	generate an HDL output of the same width and name as the bitfield (assuming no other properties modify this)
hw=w	generate an HDL input
hw=rw	generate an HDL inout? (or does it generate two signals, one input and one output? If the latter, what names does it use?
hw=na	do not generate a port for this field

Since I don't need HW to read either of the writable bits, I have created the StrobeBit field definition.

reg {
    field StrobeBit {sw=w; hw=na; singlepulse;}
    field StatusBit {sw=r; hw=r;}

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

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

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

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

The only change I'd still like to make is that I'd like the HDL port associated with PsEnabled to have a different name, such as EnablePowerSupply, since that will actually be a control signal that turns the power supply on or off. Obviously I can associate an actual with a new name where the register HDL is instantiated, but it would be nice to not have to do that. Is that possible to do, or does a port name always exactly match the bitfield name?

[amykyta3]

Yes output ports will always correlate with the field name.