Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Note about Zaamo on microcontrollers should not imply that caches are required to naturally support Zalrsc #15

Open
chrisnc opened this issue Sep 9, 2024 · 0 comments

Comments

@chrisnc
Copy link

chrisnc commented Sep 9, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant