You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Zaamo extension enables microcontroller class implementations to utilize atomic primitives from the AMO subset of the A extension. Typically such implementations do not have caches and thus may not be able to naturally support the LR/SC instructions provided by the A extension.
Uniprocessor microcontrollers can implement Zalrsc with a single global monitor that is invalidated when specific events occur in the hart (e.g., exception entry and return, any store, etc.), without the presence of or support from caches. I noticed that the reasoning in this note is similar to what is described in the SiFive FE310-G002 manual. The FE310 is a RV32IMAC core, so it nominally supports Zalrsc, except for this note in Section 3.5:
The load-reserved and store-conditional instructions are only supported on cached regions, hence generate an access exception on DTIM and other uncached memory regions.
Because the DTIM is the only data memory in the processor, this implementation of Zalrsc means that only Zaamo can actually be used. My concern is that carrying this reasoning into the official spec of these extensions will lead other implementations to similarly forgo a usable and lightweight implementation of Zalrsc, unnecessarily limiting its applicability and reducing portability across different RISC-V embedded devices. Even on devices with caches, this statement may lead other implementations to not support Zalrsc on tightly-coupled memories, as in the case of FE310.
As a point of comparison, esp32c6 describes its A extension support in section 1.15, where a list of several hart-level events will clear the reservation.
The text was updated successfully, but these errors were encountered:
Uniprocessor microcontrollers can implement Zalrsc with a single global monitor that is invalidated when specific events occur in the hart (e.g., exception entry and return, any store, etc.), without the presence of or support from caches. I noticed that the reasoning in this note is similar to what is described in the SiFive FE310-G002 manual. The FE310 is a RV32IMAC core, so it nominally supports Zalrsc, except for this note in Section 3.5:
Because the DTIM is the only data memory in the processor, this implementation of Zalrsc means that only Zaamo can actually be used. My concern is that carrying this reasoning into the official spec of these extensions will lead other implementations to similarly forgo a usable and lightweight implementation of Zalrsc, unnecessarily limiting its applicability and reducing portability across different RISC-V embedded devices. Even on devices with caches, this statement may lead other implementations to not support Zalrsc on tightly-coupled memories, as in the case of FE310.
As a point of comparison, esp32c6 describes its A extension support in section 1.15, where a list of several hart-level events will clear the reservation.
The text was updated successfully, but these errors were encountered: