About safe StreamMux and StreamDeMux.

[Readon]

trafficstars

According to the verification of Mux and DeMux, the output transaction would be interrupted by the changes of selection. It might be good to provide a safe version of those facilities. The question is whether a Stream based selection version or delayed switch version is prefered.

[Dolu1990]

Maybe it could be one function for each, i mean :

val myDemux = new StreamDemux(..)
val selector = myDemux.io.createStreamSelector()
//alternatively :
// val selector = myDemux.io.createLockedSelector()

?

[Readon]

Maybe it could be one function for each, i mean :

val myDemux = new StreamDemux(..)
val selector = myDemux.io.createStreamSelector()
//alternatively :
// val selector = myDemux.io.createLockedSelector()

?

Good idea, it can keep the compatibility and add function at the same time.

[Readon]

Maybe it could be one function for each, i mean :

val myDemux = new StreamDemux(..)
val selector = myDemux.io.createStreamSelector()
//alternatively :
// val selector = myDemux.io.createLockedSelector()

?

How about add an function createReg or driveReg of Stream, which can be used as

   val readyWhen: Bool = xxx // condition allow register be modified.
   val reg = streamA.driveReg(readyWhen)

So that the reg can be terminated by the Reg. It seems that there are cases that Stream is terminated by registers.

[Dolu1990]

How about add an function createReg or driveReg of Stream, which can be used as

In some ways it already exists as :

   val readyWhen: Bool = xxx // condition allow register be modified.
   val reg = streamA.continueWhen(readyWhen).toFlow.toReg

So, we could add a toReg toStream directly which would drive the ready High, to avoid the toFlow verbosity. But i think it is better to keep the arbitration (readWhen) outside of the register function, and use continueWhen / haltWhen instead.

In other words, avoiding to much aggregation of different functionalitty, and instead promote composition. I mean, i'm not sure where the right balance is.

[Readon]

How about add an function createReg or driveReg of Stream, which can be used as

In some ways it already exists as :

   val readyWhen: Bool = xxx // condition allow register be modified.
   val reg = streamA.continueWhen(readyWhen).toFlow.toReg

So, we could add a toReg toStream directly which would drive the ready High, to avoid the toFlow verbosity. But i think it is better to keep the arbitration (readWhen) outside of the register function, and use continueWhen / haltWhen instead.

In other words, avoiding to much aggregation of different functionalitty, and instead promote composition. I mean, i'm not sure where the right balance is.

That would be good enough to have a toReg. On the other hand, it seems that

   val readyWhen: Bool = xxx // condition allow register be modified.
   streamB <-< streamA.continueWhen(readyWhen)
   streamB.ready :=True   //use streamB.payload as an register.

These code works too.

[Dolu1990]

These code works too.

Ahhh it is weird it works, because internaly it does : val rData = RegNextWhen(self.payload, self.ready) So the reg which drive streamB payload will always sample the input i think.

Stream toReg added