This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

AXI ID BITS , help to understand

Hello ,

i can see that AXI have some bits : AWID ARID BID ARID RID , those bits role is trasaction ordering , well i want to know how axi form those bits , i heard (i dont know if it is true) that a master can use those bits to find his path to the slave (though multiple interconnects) , (i heard many people talk for those bits as thread bits ), i would like too know how can i test those bits with vivado  ? (any ideas ) , how does those bits affect ordering restrictions  on AXI?

tnx you

Parents
  • hi rentoumis,

    The AXI bits are used to link together the parts of a write transaction occuring on the AW, W and B channels, or the AR and R channels for a read transaction. That is their primary function.

    It would be up to the AXI master design what it might use particular AXI encodings for, so the ID could indicate which sub-block within the master is generating the transaction request, or as you suggested, they could indicate a processing "thread" if the master supports multiple threads (operations that can occur in parallel).

    The AXI protocol has various ordering requirements for transactions using different IDs, but the best place to read about those requirements would be in the AXI protocol.

    The AXI interconnect logic between the AXI master and AXI slave might add extra bits to the AWID, ARID and WID signals generated by the AXI master so that it can route any responses from the final slave on the R or B channels back to the correct AXI master, but those additional ID bits would not be seen by the AXI master, only the AXI slave. So these "routing" bits are generated by the AXI interconnect, not the AXI master, and what you have heard about a master using those ID bits to find his path through to the slave isn't correct.

    Regarding how to use Vivado, as that looks to be a Xilinx software suite you would be better to send that question to Xilinx.

    JD

Reply
  • hi rentoumis,

    The AXI bits are used to link together the parts of a write transaction occuring on the AW, W and B channels, or the AR and R channels for a read transaction. That is their primary function.

    It would be up to the AXI master design what it might use particular AXI encodings for, so the ID could indicate which sub-block within the master is generating the transaction request, or as you suggested, they could indicate a processing "thread" if the master supports multiple threads (operations that can occur in parallel).

    The AXI protocol has various ordering requirements for transactions using different IDs, but the best place to read about those requirements would be in the AXI protocol.

    The AXI interconnect logic between the AXI master and AXI slave might add extra bits to the AWID, ARID and WID signals generated by the AXI master so that it can route any responses from the final slave on the R or B channels back to the correct AXI master, but those additional ID bits would not be seen by the AXI master, only the AXI slave. So these "routing" bits are generated by the AXI interconnect, not the AXI master, and what you have heard about a master using those ID bits to find his path through to the slave isn't correct.

    Regarding how to use Vivado, as that looks to be a Xilinx software suite you would be better to send that question to Xilinx.

    JD

Children
  • hi JD , you where really helpful ,

    well can you help me understand how the R5 arm unit when connected with axi interface is generating ID theards ? i mean when you say "add extra bits to the AWID, ARID and WID" how can i know exactly which bits added and what will the final resolt of the ID will be ?

    thanks you again .

    giannis rentoumis

  • Hi giannis,

    Where I talked about "add extra bits to the AWID, ARID and WID" outputs, I was referring to what the interconnect logic between the AXI master and slave might add, not what the AXI master does. What those additional interconnect added ID bits might be will depend on the interconnect design, and the complexity of the system being connected together. You would hopefully see this described in the interconnect logic documentation.

    For the "R5 arm unit", it will have specific ID encodings that it uses for specific operations, and you will usually find these described in the technical reference manual, but you shouldn't design any slave logic to perform specific operations based only on the IDs because firstly they could change between revisions of the AXI master design, and secondly the slave won't see those exact ID encodings because they will almost certainly be changed in some way by the interconnect logic.

    So rather than worry about how to decode or interpret the ID values received by the AXI slave, just treat the ID as a tag field to link together the transfers on the AW, W and B channels, or the AR and R channels, and then just perform the transfer being requested on the other AXI address channel signals.

    JD