[question] Clarification on Guarantees for High/Mid/Low FIRRTL

I had an odd realization in that FIRRTL levels below High do not respect last connect semantics. The ExpandWhens transform is expected to clean this up for you.

A result of this is that transforms that add new statements (that are not “in place” modifications of existing statements) should either take place at the High FIRRTL level or emit High FIRRTL so that the circuit will be cleaned up for you.

Are there any existing clarifications of what guarantees are expected for specific transforms at specific FIRRTL levels?

• Technically these guarantees can be gleaned by reading the LoweringCompilers code…

What I’ve discovered:

• circuits <= Mid FIRRTL do not obey last connect semantics (cleand up by ExpandWhens)
• circuits == Mid FIRRTL provide no guarantees that signal names will not alias to each other (cleaned up by Uniquify), e.g., adding the signal wire r_x: UInt<5> to a module with existing signal wire r : {x: UInt<5>} will result in a hidden name conflict

These may be bugs or they may be a violation of the [High, Mid, Low] FIRRTL contract.

Alternatively, this may motivate a new CheckMidForm pass (to save me from myself…).

Edit: After digging a bit more, this is some documentation of this in the code: Compilers.scala. I think that the restrictions are stricter, nonetheless.

[jackkoenig]

Oh cool, thanks @edwardcwang, I didn’t realize we were publishing the ScalaDoc

[seldridge]

The guarantees for this are explained in the comments. The Dependency API refactor will make it explicit what is required and what is invalidated. See: #948.