Datasheet
19.3.2.2 Last Access Master
After the end of the current access, if no other request is pending, the slave remains connected to the last master that
performed an access request.
This allows the MA
TRIX to remove the one latency cycle for the last master that accessed the slave. Other non
privileged masters still get one latency clock cycle if they want to access the same slave. This technique is useful for
masters that mainly perform single accesses or short bursts with some Idle cycles in between.
This configuration provides no benefit on access latency or bandwidth when reaching maximum slave bus throughput
whatever is the number of requesting masters.
19.3.2.3 Fixed Default Master
At the end of the current access, if no other request is pending, the slave connects to its fixed default master. Unlike
the last access master
, the fixed default master does not change unless the user modifies it by software
(FIXED_DEFMSTR field of the related MATRIX_SCFG).
This allows the MATRIX arbiters to remove the one latency clock cycle for the fixed default master of the slave. All
requests attempted by the fixed default master do not cause any arbitration latency, whereas other non-privileged
masters will get one latency cycle. This technique is useful for a master that mainly performs single accesses or short
bursts with Idle cycles in between.
This configuration provides no benefit on access latency or bandwidth when reaching maximum slave bus
throughput, regardless of the number of requesting masters.
19.3.3 Arbitration
The MATRIX provides an arbitration technique that reduces latency when conflicting cases occur; for example. when
two or more masters try to access the same slave at the same time. One arbiter per AHB slave is provided, so that
each slave is arbitrated dif
ferently.
The MATRIX provides the user with two arbitration types for each slave:
1. Round-robin Arbitration (default)
2. Fixed Priority Arbitration
Each algorithm may be complemented by selecting a default master configuration for each slave.
When re-arbitration is required, specific conditions apply. Refer to the "Arbitration Rules" section.
19.3.3.1 Arbitration Rules
Each arbiter has the ability to arbitrate between requests from two or more masters. To avoid burst breaking and to
provide maximum throughput for slave interfaces, arbitration should take place during the following cycles:
•
Idle cycles: When a slave is not connected to any master or is connected to a master which is not currently
accessing it
• Single cycles: When a slave is performing a single access
• End of Burst cycles: When the current cycle is the last cycle of a burst transfer. For a defined length burst,
predicted end of burst matches the size of the transfer but is managed differently for undefined length burst.
Refer to the "Undefined Length Burst Arbitration" section.
• Slot cycle limit: When the slot cycle counter has reached the limit value indicating that the current master access
is too long and must be broken. Refer to the "Slot Cycle Limit Arbitration" section.
19.3.3.1.1 Undefined Length Burst Arbitration
In order to prevent slave handling during undefined length bursts, the user can trigger the re-arbitration before the
end of the incremental bursts. The re-arbitration period can be selected from the following Undefined Length Burst
T
ype (ULBT) possibilities:
1. Unlimited: no predetermined end of burst is generated. This value enables 1-Kbyte burst lengths.
2. 1-beat bursts: predetermined end of burst is generated at each single transfer during the INCR transfer.
3. 4-beat bursts: predetermined end of burst is generated at the end of each 4-beat boundary during INCR
transfer.
4. 8-beat bursts: predetermined end of burst is generated at the end of each 8-beat boundary during INCR
transfer.
SAM E70/S70/V70/V71 Family
Bus Matrix (MA
TRIX)
© 2019 Microchip T
echnology Inc.
Datasheet
DS60001527D-page 94










