Why source.ready := ingress.flit.ready && beat === 1.U ?

[JL102]

Hi @jerryz123, Re #1380:

I'm going through the RoCC-to-NoC example, since I need to do something similar, and I'm writing down my own notes for each line of code to make sure I understand it.

Looking at this section:

    for ((hartId, index) <- hartMappings.keys.zipWithIndex) {
      val beat = RegInit(0.U(1.W))
      val ingress = ingresses(index)
      val source = Queue(ron_io.from_source(index), 2)
      ingress.flit.valid          := source.valid
      ingress.flit.bits.payload   := source.bits.wdata >> (beat << 5)
      ingress.flit.bits.head      := beat === 0.U
      ingress.flit.bits.tail      := beat === 1.U
      ingress.flit.bits.egress_id := source.bits.sink_hartid
      source.ready                := ingress.flit.ready && beat === 1.U
      when (ingress.flit.fire()) { beat := Mux(beat === 1.U, 0.U, beat + 1.U) }
    }

Most of it makes sense to me, but I'm stuck on source.ready := ingress.flit.ready && beat === 1.U. I understand what it means -- "Mark that the module is ready to retrieve data from source, when the ingress is ready to retrieve data and the beat register === 1". But why 1 and not 0?

beat starts at 0, and I see that due to the last line, it only transitions from 0 to 1 when ingress.flit passes a valid message. But doesn't that mean a valid message has to be passed first, without source.ready being true? If source's internal logic for its valid signal depends on ready, wouldn't that cause a stalemate leading to no messages ever being passed?

EDIT: second question: Why is there a 2-long Queue for the ingress/source logic, but no Queue for the egress/sink logic?

[jerryz123]

Most of it makes sense to me, but I'm stuck on source.ready := ingress.flit.ready && beat === 1.U. I understand what it means -- "Mark that the module is ready to retrieve data from source, when the ingress is ready to retrieve data and the beat register === 1". But why 1 and not 0?

The example assumes packets have fixed size of 2 flits. So a packet can only be dequeued from the source queue when the seconf flit fires (ingress.flit.ready && beat === 1.U).

This bit of logic is converting each source message into a 2-flit packet, so each source.fire has to generate 2 ingress.flit.fire.

EDIT: second question: Why is there a 2-long Queue for the ingress/source logic, but no Queue for the egress/sink logic?

On the ingress side, the packet-to-flit conversion requires that the input is actually a Irrevocable decoupled interface, which means that once source.valid is asserted, source.bits cannot change. The 2 entry queue acts like a latch on the source bits. I think the minimal implementation would actually make it a 1-entry Queue with flow=true and pipe=true.

[JL102]

Thanks for the answer! It took me a while to go through the code and fully understand what you said. I see now that keeping source.ready = false is almost like a way to "trick" the source into holding the signal for longer, since it has to wait until ready is true before it can let go of the data. After playing around with Chiseltest, I see how both a 2-entry queue gets the desired behavior (and yeah, it looks like flow=true and pipe=true does also have the same desired behavior).