LPIF question on pipeline behavior
johna-eximiusdesign opened this issue · comments
If we leave the active state, do we need to flush the flit data pipeline or is it assumed the flits are either already flushed before we enter the inactive state or those flits are intended to be preserved across the inactive state.
Related, we see the attached screenshot behavior in the VIP. We think it is a bug in the VIP because the VIP is not obeying the trdy and is truncating the last beat of data early. (around 2670ns). A similar state exists around 2664ns (stallreq high, no stallack) and the VIP obeyed the flow control. So it looks like the bug is the last beat of data before the stallack is not obeying flow control. But the spec was a little confusing on the relationship of trdy, stallreq, stall ack. Do you concur it looks like a VIP bug from these waves?
This is a second case that occurs on the "last" transaction from the VIP (as indicated by the irdy going low), but without the stallreq/stallack to muddle the conversation. And similar to before, a few clocks earlier, there is a flit that is split in two by the pl_trdy, and the VIP obeys that flow control (and other identical scenarios earlier). It is only the last one.
I can't tell from these screen caps where the signals are being sampled at. Ideally the waves would more closely match Figure 26 in the LPIF 1.1 Specification with probes of the relevant signals taken at both sides of the pipelining block.
The Link Layers (VIP in this case) have no knowledge of pipeline delay between its interface and the LogPHY interface (CXL LPIF to AIB Adaptor in our case). Our RTL needs to fully account for the total roundtrip latency when changing the values of pl_stallreq/pl_trdy and sampling lp_valid/lp_stallack.
Looking at the waves above and assuming all signals are probed at the LogPHY boundary, this doesn't look like a VIP error to me. It looks like pl_trdy is de-asserted early and lp_valid and lp_stallack are toggled at the correct clock edges when accounting for pipelining. There is no way for the VIP to know exactly when pl_trdy is de-asserted as it does not know the pipeline depth and assumes a direct connection to the LogPHY.
Agreed that we need to make sure all flits are "flushed" through the pipeline before we transition state. This mirrors the general flow that as far as the link layer is concerned, the boundary conditions are definitive and any pipelining / delays should be hidden from the boundary interfaces. In this case, the flits were accepted by the PHY (via TRDY=1) and the state transition will occur only after they really accepted by the internal logic of the PHY after the pipeline.
Michael concurred that the VIP dropping the last beat of data looked incorrect. Still waiting for Synopsys's response.