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
Other information
I would like to propose that the Rocket Chip codebase and related repositories move away from "master" and "slave" language to describe system components. As has already been discussed widely in other fora for technical standards and open-source projects, master-slave is an offensive and exclusionary metaphor that is both technically imprecise and historically inaccurate. In addition, many companies now have policies discouraging or prohibiting the use of these terms in code or documentation (sometimes enforced via automatic code checks), so their persistence in the current version of Rocket Chip may make it increasingly difficult to use this project in commercial toolflows. Other open-source codebases have already moved away from this language, and Rocket Chip and other Chips Alliance code and documentation should do the same.
There are many other valid relationship descriptors that the project could use depending on context, such as Manager/Client, Primary/Secondary, Active/Standby, Initiator/Target, Source/Sink, Leader/Follower, etc.
I imagine this will not necessarily be a straightforward task, so as a starting point, it would be helpful if the project maintainers could help enumerate the potential hurdles in accomplishing this. ARM has already migrated its AXI specifications to use "Manager/Subordinate" terminology, so AXI components can just be renamed to track the new spec. I imagine TileLink components may be more difficult to rename without a concomitant spec change. Are there other barriers to removing this language from Rocket Chip? I look forward to hearing from the community about the best way to move forward on this.
The text was updated successfully, but these errors were encountered:
TileLink has moved to a client/manager terminology, away from master/slave. However, not all of the code in this repo has been updated to reflect that. I don't think there's any other master/slave terminology left over in rocket-chip.
There's nothing barring us from changing over the naming completely, If this is causing a problem for users, I can try to allocate some time to change everything.
Type of issue: other enhancement
Impact: unknown
Development Phase: request
Other information
I would like to propose that the Rocket Chip codebase and related repositories move away from "master" and "slave" language to describe system components. As has already been discussed widely in other fora for technical standards and open-source projects, master-slave is an offensive and exclusionary metaphor that is both technically imprecise and historically inaccurate. In addition, many companies now have policies discouraging or prohibiting the use of these terms in code or documentation (sometimes enforced via automatic code checks), so their persistence in the current version of Rocket Chip may make it increasingly difficult to use this project in commercial toolflows. Other open-source codebases have already moved away from this language, and Rocket Chip and other Chips Alliance code and documentation should do the same.
There are many other valid relationship descriptors that the project could use depending on context, such as Manager/Client, Primary/Secondary, Active/Standby, Initiator/Target, Source/Sink, Leader/Follower, etc.
I imagine this will not necessarily be a straightforward task, so as a starting point, it would be helpful if the project maintainers could help enumerate the potential hurdles in accomplishing this. ARM has already migrated its AXI specifications to use "Manager/Subordinate" terminology, so AXI components can just be renamed to track the new spec. I imagine TileLink components may be more difficult to rename without a concomitant spec change. Are there other barriers to removing this language from Rocket Chip? I look forward to hearing from the community about the best way to move forward on this.
The text was updated successfully, but these errors were encountered: