r_valid and burst request duration issue

[mslijepc]

Hi Eyck,

in AXI4 protocol, if there is e.g. a burst read transaction of size 2, how many cycles should it last? From the moment it puts first r_valid to true until it asserts r_last ?

From this waveform, I can see it lasting 3 cycles, but shouldn't it last 2 cycles?

We can see that axi4_target is asserting r_valid for 1 cycle, w\o considering whether there is a new data, is that 1 cycle meant to always occur and therefore the burst of size 2 should last minimum 3 cycles? https://github.com/Minres/SystemC-Components/blob/e2dea44610e04bc4f7189ce9aacc424f4d15e011/src/bus_interfaces/axi/pin/axi4_target.h#L296

[eyck]

The target aserts r_valid signaling that this is the first beat (incl. data) of the 2-beat burst. This is immedaitely acknoledged by the intitiator since r_ready is asserted. So the first beat enda after 1 clock cycle. Then the target inserts 1 clock delay and asserts in the 3rd cycle r_valid and r_last thus signalling that this is the second and final beat. This is also immediately acknowledged by the initiator since ready is asserted. So at 27300ns the response is finished after 2 1-cycle beats and 1 cycle intra-beat delay (RBV aka Read data handshake to next beat valid, check ARM IHI 0082A spec section 3.1.1). I can only speculate: assuming your are using one of the AT targets (e.g. axi::pe::simple_target or axi::pe::ordered_target): it seems your target is configured to insert 1 cycle delay between END_PARTIAL_RESP and BEGIN_RESP.

[mslijepc]

I am using axi::pe::simple_target.

it seems your target is configured to insert 1 cycle delay between END_PARTIAL_RESP and BEGIN_RESP.

Can we "configure" / affect on this, shouldn't they arrive w/o delay?

Even if END_PARTIAL_RESP and BEGIN_RESP would arrive in 2 consecutive cycles, since in rresp_t we always wait for 1 cycle, 1 cycle intra-beat delay will always happen?

[eyck]

Yes, this can be configured at the pe of the simple_target. There is a sc_attribute called rd_data_beat_delay. If you look at the axi pin example there are no cycles between the read responses.

[eyck]

Can this be closed?

[mslijepc]

I was just checking, rd_data_beat_delay is 0. I will debug it tomorrow to see the root cause

[eyck]

You might also have a look at https://git.minres.com/SystemC/SystemC-Components-Test/src/branch/develop/tests/axi4_pin_level which shows:

[eyck]

Hi Mladen, what about this issue? Did you solve it? Can it be closed?