Lossy valid to stream #189
Conversation
niwis
left a comment
There was a problem hiding this comment.
Looks good to me in general, thanks a lot!
I have one question: The documentation mentions the case that ...we want the latest value. If I understand correctly, the module needs to be read twice to obtain the newest value (the first value read will be the oldest uncommited value, since the signals are kept stable). Is that correct?
One more comment inline.
| if (valid_i && valid_o && ready_i) begin | ||
| pending_tx_counter_d = pending_tx_counter_q; |
There was a problem hiding this comment.
Indeed it is. That was a voluntarily decision to make the three cases (push, pop and simultaneous push and pop) a bit more clear in the code.
|
Yes that is correct. Since we are not allowed to revoke an already started transaction that is the only option we have if I am not mistaken. |
niwis
left a comment
There was a problem hiding this comment.
Okay, clear! Thanks a lot
This module helps to deal with sources that use a valid-only interface, that
is they do not support backpressure i.e. cannot handle the case where the
sink is not ready to accept a value. The module is implemented as FIFO with 2
elements. In contrast to a regular FIFO that stops accepting new transactions
once the FIFO is full, this IP overwrites the last element entered into the
FIFO. This means the input is always ready to accept new transactions,
however, intermediate transactions might be overwritten by the latest one. On
the output side, the module behaves like a regular ready-valid source i.e.
once valid is asserted, data_o remains stable until the sink consumes them
(by asserting ready_i).
The
lossy_valid_to_streammodule is helpful to connect configuration registers withIPs that could cause back pressure. In this case we might not care how long
it takes for the config value to be sent to the IP but if we change the
config value we want the latest value to be used regardless whether the
previous value has already been forwarded or not.