conflicting reset values for registers that share a type behave unexpectedly

[nathanaelhuffman]

given rdl:

reg io {
        field {
            desc = "bits for current port";
        } bits[7:0] =  0;
    };

 io ip0 @ 0x00;
 ip0->name = "Ip0"; 
 ip0->desc = "I/O port input state after polarity inversion (if enabled)";
 ip0.bits->sw = r;

 io ioc0 @ 0x18;
 ioc0->name = "ioc0"; 
 ioc0->desc = "Config registers. 0: output, 1: input";
 ioc0.bits->reset = 0xff;

We expected the rec_reset function to return 0's for ip0 and 1's for ioc0, but, instead, there's only one type, and only
one rec_reset and it returns 0's due to the base function.

There are a couple of challenges here:

1. We told the RDL generator that these are the same type.
2. rec_reset is an overloaded VHDL function, so it only disambiguates by type, so it can't disambiguate between these two types because they're the same (VHDL2019 allows functions to understand subtypes, so that may be a solve in the long-run but we need to generically
   continue supporting VHDL2008 also)
3. We get no error messages in this case, so we don't know anything is wrong, stuff just behaves incorrectly.

Possible next steps:

1. Emit a warning or error message when we have the same type with conflicting reset values. We should probably do this no matter what else we do.
2. I think we only have a few possible options here:

• Force the user to make these two different types. If they're closely related, this means that they'll have to manually create the overloads to do bitwise operations on them: not super ideal
• Make the reset optional, and make the user implement two different kinds of rec_reset functions.
• Somehow figure out the various reset options and make different function names that return the same type but different values. This is sort of a hybrid of the first two options.

[Aaron-Hartwig]

I agree we should emit an error --not a warning-- when this is observed. Someone not knowing (or remembering) this behavior is a rake I'd rather not leave in the yard.

My thought on what we should do about it: The io type was defined with a certain behavior.

Force the user to make these two different types. If they're closely related, this means that they'll have to manually create the overloads to do bitwise operations on them: not super ideal

If we need a different behavior in certain cases then that seems like a different type is warranted. To me, if the user wants to leverage rec_resets generated by our tools then they should make different types when they want different behavior. I don't see this option as being problematic at all really.

Make the reset optional, and make the user implement two different kinds of rec_reset functions.

Is the reset not optional today? There's nothing stopping someone from ignoring the generated rec_reset functions in favor of a custom reset value if they'd prefer something different than the one supplied by the type. Regardless of path we choose a user will always have this available to them. Until we start completely generating register access code, that is 😉

Somehow figure out the various reset options and make different function names that return the same type but different values. This is sort of a hybrid of the first two options.

I think this is fine too.