In document on AXI3:
"The exclusive access monitor records the address and ARID value of any exclusive read
operation. Then it monitors that location until either a write occurs to that location or
until another exclusive read with the same ARID value resets the monitor to a different
address."
I have an example.
I have 2 Master and 2 bit ID per master. (out of order data & out standing address support)
M0 have master number is 0.
M1 have master number is 1.
When M0 is selected by the Arbiter, then M0 issue exclusive read to S0 with start address is 16h0000.
And then M1 is selected by the Arbiter, then M1 issue exclusive read to S0 with start address is 16h0000.
In two cases above, 2 exclusive read with same address is 16h0000 but different ARID.
What will happen with the monitor in my example???
After that, I assume that M1 issue exclusive write before M0.
What will S0 response to M0 and M1???
Best regards,
** Cao Phi
Hi yasuhikokoumoto,
your answer is however different from in another thread AXI 3/AXI 4 Exclusive Access (thread 2600: AXI 3/AXI 4 exclusive access).
The first-come-first-served principle what you explained is applied to the exclusive reads. According to the explanation by mharnisch in Thread 2600, this is applied to exclusive writes. And I am for mharnisch's opinion.
My understanding is for both exclusive reads, S0 should send back EXOKAY. If it sends OKAY to M1, M1 would consider S0 as a slave which does not support exclusive at all.
When M1 sends the exclusive write before M0, it should get EXOKAY and the address is not monitored anymore. Later M0 will be get OKAY as response.
I think "First-come-first-served" makes more sense for exclusive writes, because the basic idea of the mutual execution is to ensure that the address is not modified by others before the current master writes it. It does not matter which one first writes the address. What do you think?
But what confuses me in the specification, is the purpose of AWID in the exclusive write. It seems to be redundant, as the monitored address is unique enough for judging the written address is monitored or not.
Please let me know if I understand it wrongly. Can you share your opinion?
Thank you.
Best regards
Diandian
Hi diandianzhang,
My understanding is for both exclusive reads, S0 should send back EXOKAY.
This implementation is possible, but then a slave should monitor the newest address and ID.Under this implementation the following sequences would fall into a live lock or last the fail state infinitely.
LDREX Addr=A0 id=ID0 LDREX Addr=A0 id=ID1 STREX Addr=A0 id=ID0 STREX Addr=A0 id=ID1 LDREX Addr=A0 id=ID0 LDREX Addr=A0 id=ID1 STREX Addr=A0 id=ID0 STREX Addr=A0 id=ID1
Therefore my implementation is causing an error for the 2nd LDREX and preventing the STEEX corresponding to the 2nd LDREX.
I think "First-come-first-served" makes more sense for exclusive writes,
This would be wrong.The exclusive monitor of a slave should manage both addresses and IDs.
The exclusive monitor waits until a STREX of which address and ID would match comes.
Best regards,Yasuhiko Koumoto.
Hi Koumoto-san,
But if the slave generates an OKAY to an exclusive read, there is a risk that the master would think that the slave does not support exclusive access at all, and would never issue an exclusive access to that slave any more.
I understand the your explanation of the live lock. But this can be solved by monitoring multiple ID and address pairs.
In this case we would have two pair {ID0, A0} and {ID1, A0}, which are under monitoring. Any one that first sends the exclusive write gets the EXOKAY response and updates the address.
And the monitor uses address A0 to disable the monitoring of both pairs. Then the following exclusive write will get OKAY response.
Regarding your statement "The exclusive monitor waits until a STREX of which address and ID would match comes."
This is also what I do not understand, which I also asked in my previous post. In principle, with the address information in the exclusive write, the monitor can already decide which monitored addresses are updated and do not monitor them any more. Even if ARID and AWID would not match, this would not issue a problem, because the exclusive access to the address is guaranteed. The advantage of using AWID, what I think, is to simplify the hardware implementation of the monitor.
Is it a problem?Usually there are no means to distinguish whether the LDREX response was EXOKAY or OKAY, and the master may not care it other than error cases.If a master can recognize the return value of OKAY, the master only will not issue further exclusive accesses.
How many pairs will you have?I think it would not make sense.
Even if ARID and AWID would not match, this would not issue a problem, because the exclusive access to the address is guaranteed.
It would probably not be correct.I'm sorry but I cannot understand the meaning of "the exclusive access to the address is guaranteed".
The problem is "If a master can recognize the return value of OKAY, the master only will not issue further exclusive accesses", as you wrote.
Similar notes are also made in the AXI spec:
"If the master attempts an exclusive read from a slave that does not support exclusive accesses, the slave returns the OKAY response instead of the EXOKAY response. The master can treat this as an error condition indicating that the exclusive access is not supported."
In this case the hardware feature of supporting exclusive access by the slave is wasted. A workaround must be then found in the software to ensure the exclusive access to the slave.
In this case we would have two pair {ID0, A0} and {ID1, A0}, which are under monitoring. Any one that first sends the exclusive write gets the EXOKAY response and updates the address.How many pairs will you have?I think it would not make sense.
In section 6.2.3, it is stated as follow:
"A slave that supports exclusive access must have monitor hardware. It is recommended that such a slave has a monitor unit for each exclusive-capable master ID that can access it. "
If I understand this correctly, the number of the pairs should correspond to the number of exclusive-capable master IDs. Please correct me, if my understanding is wrong.
Even if ARID and AWID would not match, this would not issue a problem, because the exclusive access to the address is guaranteed. It would probably not be correct.I'm sorry but I cannot understand the meaning of "the exclusive access to the address is guaranteed".
Sorry for the unclarity. With "exclusive access to the address is guaranteed", I mean that during the monitoring period for the address, the address can only be updated once, no matter by which master.
Assuming that the monitor can only record one ID and address, and currently it is monitoring ID0 and address A0.
Now M1 sends LDREX to A0. Based on my understanding above, the slave should send back EXOKAY to M1.
Here we can have two cases in the monitor:
Case 1: Recorded ID and address are updated: i.e. ARID=1 and A0
Case 2: Recorded ID and address remain unchanged, i.e. ARID=0 and A0
Then the slave can receive STREX either from M0 or M1.
Case a: STREX from M0, AWID=0 and A0
Case b: STREX from M1, AWID=1 and A0
In total we have 4 combinations. If we only use the monitored address (independent of ID) to judge whether updating address and sending OKAY/EXOKAY, the correctness is always guaranteed:
- Case 1 + Case a: A0 is monitored => M0 gets EXOKAY and updates A0 => A0 is not monitored any more => M1 gets OKAY and does not update A0.
- Case 1 + Case b: A0 is monitored => M1 gets EXOKAY and updates A0 => A0 is not monitored any more => M0 gets OKAY and does not update A0.
- Case 2 + Case a: A0 is monitored => M0 gets EXOKAY and updates A0 => A0 is not monitored any more => M1 gets OKAY and does not update A0.
- Case 2 + Case b: A0 is monitored => M1 gets EXOKAY and updates A0 => A0 is not monitored any more => M0 gets OKAY and does not update A0.
So, basically it is "first-come-first-served" for exclusive writes.
I think you seem to have some misunderstanding.
It is not basically checked dynamically whether a slave support the exclusive.A programmer should know it in advance.Therefore, there would not be so big differences of returning OKAY of EXOKAY for an exclusive read.I can agree with that an exclusive read will always get EXOKAY.
Partly correct and partly incorrect.It is correct that the number of pairs of an address and id should be the sane as the number of exclusive-capable masters.It does not mean to have the pairs which is the same number of the masters for an address.The aim of the recommendation is to have an individual semaphore for each master at the same time.
Incorrect.M0 gets OKAY and does not update A0, andM1 gets EXOKAY and updates A0.The ordering of M0 and M1 does not change the results.
Yasuhiko Koumoto.
In this case the hardware feature of supporting exclusive access by the slave is wasted. A workaround must be then found in the software to ensure the exclusive access to the slave.It is not basically checked dynamically whether a slave support the exclusive.A programmer should know it in advance.Therefore, there would not be so big differences of returning OKAY of EXOKAY for an exclusive read.I can agree with that an exclusive read will always get EXOKAY.
What you explained makes more sense. The AXI spec is somehow misleading ...
If I understand this correctly, the number of the pairs should correspond to the number of exclusive-capable master IDs. Please correct me, if my understanding is wrong.Partly correct and partly incorrect.It is correct that the number of pairs of an address and id should be the sane as the number of exclusive-capable masters.It does not mean to have the pairs which is the same number of the masters for an address.The aim of the recommendation is to have an individual semaphore for each master at the same time.
I did not mean that there are the same number of pairs as the masters for an address. What I wanted to say is that it is possible to have different IDs pointing to the same address.
E.g. in a 3-master-system, there should be three pairs. They can be e.g. be:
- {ID0, A0}, {ID1, A1}, {ID2, A2} // all IDs have different monitored addresses
or
- {ID0, A0}, {ID1, A0}, {ID2, A2} // ID0 and ID1 have the same address, and ID2 has a different one
- {ID0, A0}, {ID1, A0}, {ID2, A0} // all IDs have the same monitored address
Do you think so?