Add IrrevocableIO alternative to DecoupledIO

[hcook]

… that promises not to change the contents of .bits on a cycle after .valid is high and .ready is low. This is useful for detecting whether queues have been correctly inserted in front of modules that require these additional semantics.

[aswaterman]

There's also the constraint that valid will stay high once it's asserted, right? Should probably be pedantic about the description in the comment.

[sdtwigg]

The subclassing seems improper since the subclassing contract fails, for example, when this is used for 'enqueue' sides of Modules. The underling issue is that IrrevocableIO is indicating (via subclassing) that it can be used any time you expect a DecoupledIO.
This is fine for a producer dequeue side: A Module that can consume a DecoupledIO can easily consume an IrrevocableIO.
This is not fine for a consumer enqueue side. You may have a function (or class, etc.) that takes as input a consumer port and connects a producer to it. Since IrrevocableIO <: DecoupledIO, you are allowed to give it an IrrevocableIO. However, the function thinks it has a DecoupledIO and will not be bound to the same contract.

class SensitiveSink extends Module {
  val io = IO(new Bundle {
    val enq = Flipped(IrrevocableIO(UInt(16)))
  })
  // do something
}

def driveFromUnreliableSource(enq: DecoupledIO[UInt]) = {
  val parity = Reg(init = false.asBool)
  val bits = Reg(init = 1.asUInt(16))
  enq.valid := parity
  enq.bits := Mux(parity, bits, 0.asUInt)
  when(enq.valid && enq.ready) { bits := bits +% 1.asUInt }
}

class Test extends BasicTester {
  val sink = Module(new SensitiveSink)
  driveFromUnreliableSource(sink.io.enq) // will compile and elaborate fine
}

[aswaterman]

Is your proposal to not make it descend from DecoupledIO but instead be a separate part of the type hierarchy?

[sdtwigg]

Yes

On Tue, Sep 6, 2016 at 10:10 PM, Andrew Waterman notifications@github.com
wrote:

Is your proposal to not make it descend from DecoupledIO but instead be a
separate part of the type hierarchy?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#274 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA9_-CUdGEEPI-qhjLqiRBohf9RaQxirks5qnkdagaJpZM4J2dc7
.

[hcook]

I totally see your point. I was scared of making backwards-incompatible changes to QueueIO. Working on a solution that uses a common base class and some factory method cleverness. Too bad that flipped things are the same type :P

[aswaterman]

can you add scaladoc for the two apply methods? the new one should explain the use case and the invariant

[aswaterman]

I think this is ok now

[terpstra]

While we're at it, could we have 'flow' added as another defaulted argument on the Queue.methods?