However, pipelining handshaking is more complicated: simply adding a pipeline register to the valid, ready, and data lines will work, but now each transfer take two cycles to start, and two cycles to stop.
It will work, but the throughput will be cut in half if the destination normally can handle back-to-back write cycles.
timing diagram shows violation of the AXI spec as RDATA and RVALID should remain stable when RREADY is low.
I am not 100 percent convinced by this sentence above.
Could you elaborate more on this ?
AXI4 Spec said:Read address channel
The master can assert the ARVALID signal only when it drives valid address and control information. When
asserted, ARVALID must remain asserted until the rising clock edge after the slave asserts the ARREADY signal.
The default state of ARREADY can be either HIGH or LOW. This specification recommends a default state of
HIGH. If ARREADY is HIGH then the slave must be able to accept any valid address that is presented to it.
Note
This specification does not recommend a default ARREADY value of LOW, because it forces the transfer to take
at least two cycles, one to assert ARVALID and another to assert ARREADY.
Read data channel
The slave can assert the RVALID signal only when it drives valid read data. When asserted, RVALID must remain
asserted until the rising clock edge after the master asserts RREADY. Even if a slave has only one source of read
data, it must assert the RVALID signal only in response to a request for data.
The master interface uses the RREADY signal to indicate that it accepts the data. The default state of RREADY
can be HIGH, but only if the master is able to accept read data immediately, whenever it starts a read transaction.
The slave must assert the RLAST signal when it is driving the final read transfer in the burst.
RDATA and RVALID should remain stable when RREADY is low.
In Figure A3-2, the source presents the address, data or control information after T1 and asserts the VALID signal.
The destination asserts the READY signal after T2, and the source must keep its information stable until the transfer
occurs at T3, when this assertion is recognized.
the slave must wait for both ARVALID and ARREADY to be asserted before it asserts RVALID to indicate that valid data is available
Code Verilog - [expand] 1 else if(i_axi_arvalid && o_axi_arready) o_axi_rdata <= mem[i_axi_araddr];
Code Verilog - [expand] 1 else o_axi_rvalid <= i_axi_arvalid && o_axi_arready;
On each interface, a transaction is completed when valid and ready are high in the same clock cycle. In your diagram, this means that d2 is transferred 3 times to the slave, and d3 two times.
You mean o_axi_rvalid && o_axi_rready ?
If yes, then d2 is only transferred ONCE
@std_match
The problem is that this discussion seems to be taking place across 2 threads.
https://www.edaboard.com/showthread.php?388604-AXI-arvalid-signal-issue/page2
It might be worthwhile the admins merging these two threads.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?