Fix/noc backpressure#300
Conversation
| elif s.drain_when_inactive: | ||
| # An inactive route acts as a sink for stale traffic. The tile keeps | ||
| # this disabled after the current control has completed so tokens for | ||
| # the next control step are not dropped. | ||
| for i in range(num_inports): | ||
| s.recv_data[i].rdy @= 1 |
There was a problem hiding this comment.
I don't get this... Can we have a concrete example about why we need this?
There was a problem hiding this comment.
I removed the Crossbar change. The Crossbar prologue behavior is now isolated in #303 with its own focused test and concrete inline example.
#300 now only changes LinkOrRTL.py: it gates FU/xbar messages by their own val bits before OR-ing payload/predicate, so stale invalid data cannot pollute the active valid input.
guosran
force-pushed
the
fix/noc-backpressure
branch
from
d5198fb to
53b83d3
Compare
guosran
force-pushed
the
fix/noc-backpressure
branch
from
53b83d3 to
c0ff8db
Compare
guosran
force-pushed
the
fix/noc-backpressure
branch
from
c0ff8db to
85a3a32
Compare
guosran
force-pushed
the
fix/noc-backpressure
branch
from
85a3a32 to
32a563f
Compare
|
Concrete example: Before: After: |
Sorry it's still not concrete enough. You can paste the waveform here to explain how an 'uncomitted' FU output win the traffic before you correction. |
| # Interface | ||
| s.recv_fu = RecvIfcRTL(DataType) | ||
| s.recv_xbar = RecvIfcRTL(DataType) | ||
| s.fu_xbar_rdy = InPort(b1) |
There was a problem hiding this comment.
s.recv_fu already contains a rdy signal, why would we still need s.fu_xbar_rdy?
| # which is guaranteed by the compiler/software. | ||
| s.send.msg.predicate @= s.recv_fu.msg.predicate | s.recv_xbar.msg.predicate | ||
| s.send.msg.payload @= s.recv_xbar.msg.payload | s.recv_fu.msg.payload | ||
| fu_active = s.recv_fu.val & s.fu_xbar_rdy |
There was a problem hiding this comment.
Is that a handshake check?
| # Only let FU traffic win once the FU crossbar has actually committed | ||
| # the multicast/send for this cycle; otherwise the link can expose | ||
| # transient FU output and create cross-tile bubbles. | ||
| s.send.val @= fu_active | xbar_active | ||
| s.recv_fu.rdy @= s.send.rdy & s.fu_xbar_rdy |
There was a problem hiding this comment.
I have similar feeling with @yyan7223, this part is a bit confusing. It sounds the root cause might not be here. Or we need a concrete example to show case why we need to change this file. The file originally should only target simple or functionality...
3 participants
Summary
Addresses #292 with a minimized LinkOr input-validity fix. This PR only updates
LinkOrRTL.pyand its focused test.Changes
valbits before OR-ing payload/predicate fields.No Crossbar, Tile, new port, or new interface changes are included.