AXI4 transaction

The earlier AW channel transfers are not lost, they are accepted by the subordinate, waiting for the corresponding W channel transfers to complete the transaction.

So 0x15 was accepted, and then 0x25. The AXI4 spec does not allow any write data interleaving, so all the W channel data for the 0x15 transaction must then be received by the subordinate before the 0x25 data can be accepted.

The AXI protocol allows you to have multiple outstanding (uncompleted) transactions queued up, so the 0x25 address transaction remains pending until the earlier accepted 0x15 transaction completes its data transfers.

Your diagram looks fine to me, and from T2 onwards you could have additional AW transfers send my the AXI manager, and these would remain pending until the AWID0 transaction has completed all its data transfers (completed at T5).

The earlier AW channel transfers are not lost, they are accepted by the subordinate, waiting for the corresponding W channel transfers to complete the transaction.

So 0x15 was accepted, and then 0x25. The AXI4 spec does not allow any write data interleaving, so all the W channel data for the 0x15 transaction must then be received by the subordinate before the 0x25 data can be accepted.

The AXI protocol allows you to have multiple outstanding (uncompleted) transactions queued up, so the 0x25 address transaction remains pending until the earlier accepted 0x15 transaction completes its data transfers.

Your diagram looks fine to me, and from T2 onwards you could have additional AW transfers send my the AXI manager, and these would remain pending until the AWID0 transaction has completed all its data transfers (completed at T5).

Thanks Colin
1-no problem with clk

2- how to calculate maximum axi clk frequency for our RTL which have sw access.

BR,
mayank

I'm not sure what you mean when you describe the 2ns and 4ns values, but if this is like the second question, asking about the clock frequencies the AXI protocol can run at, the same applies for any bus specification and it is not the protocol that limits the maximum frequency, but instead is a combination of the system design complexity, the silicon process being targeted, and also the tightness of the synthesis constraints being applied to the design.

The AXI protocol only uses rising edges of the ACLK signal for events, so all AXI paths have a full ACLK cycle for signal propagation, with outputs driven on one ACLK rising edge and inputs sampled on the next ACLK rising edge. So it is the complexity of that single cycle path that will decide how fast you can clock it, with larger designs usually meaning longer combinatorial paths between registers.

The silicon process and synthesis constraints applied are outwith the realms of the AXI spec, so I won't try and describe them here.

Thank you Kolin for clearing my doubt.

BR,

Mayank

Hi Colin,

I asked for 2ns and 4ns because
1- when I kept 10ns clk period means #5ns clk=~clk, for my RTL all three addresses were captured (0x15,0x25,0x35)and seen in Simulation for test scenario of initial post of this thread.
2- But when #1 ns clk=~clk or #2ns clk=~clk  , my middle address i.e 0x25  was not captured and not seen in simulation so what can be role of clk if any role?
this is last question .

Thanks & Regard.

Mayank

There isn't any AXI protocol reason for the failure you are seeing, so it sounds as if some RTL code in your design has delays built into it such that it can't operate with the faster clocks. Do any of your modules have # delays in them ?

Sir

My RTL have only flopped delay

now your reply seems that my RTL has limitation with clk because at 10ns it was working fine with above scenario but with 4ns middle address does not seem. so AXI clk frequency limitation exists .
Does it make sense?

BR,
Mayank

What is it that you are simulating ?

If this is a netlist, it will obviously have cell delays that will add up on combinatorial paths to limit the maximum frequency the design can be clocked at (nothing specific to AXI there).

If this is behavioural verilog it would run with simulation delta delays (unless there were # delays in the code), so there wouldn't be any limitation on the clock frequency.

Looking at this purely from an AXI protocol perspective there is no maximum ACLK frequency, so the only limitation are implementation specific limitations imposed by the design complexity and the cell library you are synthesising the design on.

You mention "flopped delay", so is this a synthesis cell library delay, or is it a behavioural simulation # delay ?

There isn't really anything anyone else can help with here, the delays limiting clock frequency are in your design RTL code.

Sir I am using functional simulation delay of one FF delay.I am not going to use cell, microcell, floorplanning, place and route etc.
thanks

Then it is this "functional simulation delay of one FF" that is somehow limiting the frequency you can run your system.

You will need to look at how long this delay actually is, and why that is stopping the design being able to sample inputs and generate outputs within the ACLK cycle timings.