AXI4 transaction

Thank you Kolin for clearing my doubt.

BR,

Mayank

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.

Hi Colin, I need your help again
AXI4 has ID concept , how can we use ID in AXI4-lite for the same operation for which we use ID like AWID,RID etc in AXI4?

BR,

Mayank

Hi Mayank,

What is it that you wanted to achieve by having IDs in your AXI4-lite system ?

AXI4-lite doesn't need IDs because all transfers must be performed in order, effectively meaning that all transactions use the same ID value.

The protocol does state that you could add some ID ports to your AXI4-lite component so that it can be connected to a full AXI4 interface, but to do this the AXI4 interface would need to be aware of the limitations of this AXI4-lite component (bursts of length 1, full data bus width accesses, no complex memory types, no exclusive transfers).

So your AXI4-lite subordinate could have ID reflection ports to return the ARID value on RID, and AWID on BID, to allow it to function in an AXI4 system, but with very careful restrictions placed on the types of transactions attempted.

Thanks a lot for reply
Actually Colin, I want to make such AXI interface where I want to resolve " which Address for which data , i could easily catch, I think it can be easily done by IDs, because already out of order has been supported and verified by ARM.

thanks

The "which address for which data" issue can simply we determined by the order the addresses and data are received, so the ID wouldn't add anything. With no reordering on AXI4-lite the transactions are very simple, especially when it's one data for one address.

Sorry I could not understand Colin, what do you want to say.
in our environment, if we write data now then the next data on the read channel is not from the same write address continuously.

mayank

The AXI protocol has never had any relationship defined between read and write transactions (except for exclusive sequences), so if you want to guarantee that the data read back is the data you have just written, you must delay issuing the read until after you have received the write transfer BRESP response.

If you do not do this, as there is no protocol relationship between the read and write channels, a later issued read could complete before an earlier issued write. This isn't just down to the AXI subordinate looking after any "read-after-write" hazards as the write transfer could be delayed by the AXI interconnect structure before it reaches the subordinate, so the read could actually reach the subordinate before a stalled write.

So to ensure you read back the latest write data you must wait for the BRESP response indicating the write has been accepted by the subordinate before issuing the read transaction.

None of that is particular to AXI4-lite or the use of IDs, it is simply a requirement of the basic AXI protocol.