Modify ReadyValidIO noenq to set the data payload to DontCare.

[stevenmburns]

Related issue: None

Type of change: other enhancement

Impact: no functional change (probably)

Development Phase: implementation

Release Notes
Modified ReadyValidIO (also used in DecoupledIO) to set the data payload (.bits) to don't care when a no enqueue action (noenq) is called. This will clean up the frequently used idiom:

c.noenq
when( cond) {
  c.enq( data)
}

This currently needs to be written as:

c.noenq
c.bits := DontCare
when( cond) {
  c.enq( data)
}

It is possible that noenq was used like this in some existing code:

c.bits := 47.U
c.noenq
when( cond) {
  c.valid := true.B
}

If this was the case, then the PR will change the behavior of the circuit.
The comment for noenq is:

    /** Indicate no enqueue occurs. Valid is set to false, and bits are
      * connected to an uninitialized wire
      */

so it wasn't supposed to be used this way.

[edwardcwang]

Seems fine to me - @ucbjrl @jackkoenig any thoughts?

[aswaterman]

This was the intent of 72e6c88 in Dec 2016. Looks like it was erroneously removed in c313e13 in Oct 2017, and no one noticed it, probably for the reason you mentioned.

[ucbjrl]

This is the classic trade-off of "intent" vs. "ease of use".

Without the explicit DontCare connection, FIRRTL will issue a warning if bits isn't connected. There could be complicated logic with nested whens where one of the conditions leaves bits unassigned and this will be correctly flagged as an error by FIRRTL.

With the DontCare connection, this error (a missing connection to bits) will no longer be diagnosed by FIRRTL.

[albert-magyar]

I think that connecting a DontCare for a noenq actually does more explicitly align with programmer intent.

Also, the problem with not flagging missing connections is universal for all "default assignment" patterns; a default enq at the top would cause the same problem