[patch] Define Storable types

[mmaloney-sf]

Storable Types

This PR defines a new term "Storable Type" which captures the class of FIRRTL types which are admissible inside of registers and memories.

Isn't this just like Passive?

Yes.

The definition has a large overlap with the term Passive Type. And that is not a coincidence.

The term Passive Type has been used to designate 'types without flips'. However, with the introduction of Probe Types and also Property types, more nuance is required to handle types. Arguments have been made both for and against the above types being allowed be passive.

In order to help resolve this tension, the new term Storable Type is intended to separate out one particular usage of Passive Types.

What is different between Passive and Storable?

Some notable differences between Passive and Storable:

1. Clocks and Resets are Passive but not Storable
2. Analogs are Passive but not Storable.
3. Properties are not Storable
4. Probes are not Storable
5. Any structural part of a type being const disqualifies it from being Storable.

No. 1 acknowledges the special nature of Clocks and Resets.

I would insist on No. 2 on the grounds that Analog isn't very well-specified. We can always add it in later once we have a better foundation for it.

No. 3 and No. 4 are the primary motivation. Properties are easy to exclude, as we have stipulated they are not to affect the RTL, but rather serve as metadata to it. For probes, we use a similar appeal to the non-"hardware-y-ness" of probes, combined with the fact that storing a probe in a register requires a nontrivial encoding (and ultimately is likely to wind up meaningless).

No. 5 is a lesson from @darthscsi (feel free to forward attribution if needed) who pointed out to me that you can use const registers to create a mutating const value. This PR removes the non-const restriction from registers, as it is subsumed into this definition. (The spec seems to have forgotten to include a const restriction on memories).

Why doesn't this PR remove the term Passive?

The term Passive still exists after this PR goes through. It still requires a bit of investigation to work out what role passivity plays in FIRRTL. There are only a handful of places in the spec Passive Types are referenced:

• Inside the definition itself (11 times out of 18)
• Rule 3 of the Connection Rules
  • Either the flow of the right-hand side expression is source or duplex, or the right-hand side expression has a passive type.
• One incidental time in an example about probes (can probably be removed safely)
• Talking about non-passive force targets (2 times)
• Talking about multiplexers
• Once talking about the types of probes
• Once in the definition of enumeration types

This gives us only a handful of places where we need to apply scrutiny. But none of these cases is so clear cut I feel I could change or remove them without changing the interpretation of the spec.

[mwachs5]

Can you please add to the version notes and also note what you think this is for the spec. Is this patch or minor? I think patch since the intention is not to actually change any allowed behavior ?

[azidar]

This distinction makes sense to me, thanks! I agree with @mwachs5 that this should probably be included in the release notes.

[mmaloney-sf]

Updated the release notes.

Marked this as [patch].