SVD multiple enumeratedValues occurrences meaning

[StripedMonkey]

I'm currently in the midst of examining the svd format, and trying to understand the usecase or rationale between a field having 0..2 enumeratedValues fields in a field. The documentation mentions that

A field may define an enumeratedValue in order to make the display more intuitive to read.

but the current definition allows for two. How is a second enumeratedValues field supposed to be interpreted? An alternate/alias? Which is to be preferred?

The next closest guess I could come up with was for asymmetric read/write enumerations, but this grouping seems to be already covered by the individual enumeratedValue values, in which case the actual enumeratedValues would simply be a union of the two.

[jkrech]

@StripedMonkey, the <usage> determines whether an enumerated value is used in case of:
a) read
b) write
c) read + write
The expectation is that either a + b or c are described.
A debugger can either offer the same symbols for read (display) and write (edit value) or dedicated symbols for read and write operations. For read-only and write-only bit-fields the usage becomes obvious.
The default, when not specified is c) and should do in most cases.
I hope this clarifies.

[StripedMonkey]

Thanks, that does clarify it.

Call it dyslexia or whatever, but I somehow read the <usage> being on the enumeratedValue instead of on the enumeratedValues, and as a result was discounting that interpretation despite it being the only logical conclusion I could come up with. This is probably compounded by the fact that the field description conflates the singular and plural naming a bit.