Alternatives to master <-> slave

[eine]

The purpose of this issue is to ask the community what alternative naming to master/slave can be used in this repo and in other libraries projects related to VHDL. There have been multiple proposals, and some other languages have already made the change. However, in VHDL it seems that many terms are usable in specific domains but not generic enough. At the same time, some other terms are too generic, and the meaning of the relation between modules/components/agents in the system might be lost.

I gathered multiple terms in the table below. I'd propose people (anyone) to pick a term from the first column (any), and a term from the second column (any). Then, search if masterterm <-> slaveterm has been written below in this issue/thread. If found, react to it. If not found, write a reply/comment which starts with masterterm <-> slaveterm.

To keep this tidy to some extent, anyone is welcome to reply with short and explicit arguments about why some combination is not adequate for some domain. Me or other maintainers will move those arguments to the comment where that combination was proposed. For this reason, authors of the comments (which are to be reacted to) will NOT be responsible for the content. At the same time, please keep the discussions in separate channels. Let's take this as a community effort to build some knowledge.

master	slave
Source	Sink
Client	Server
Leader	Follower
Captain	Lieutenant
Commodore	Lemming
Host	Device
	Guest
	Replica
Initator	Target
Requestor	Responder
Controller	Receiver
	Actuator
	Peripheral
	Mason
Main	Secondary
Primary	Agent
Planet	Satellite
Superhero	Sidekick
Supervisor (Super)	Minion
Supervillain
Gru
Driver	Consumer
Producer
Ruler
Parent	Child
Hive	Drone
Boss	Worker
Head	Helper
Chief	Mineur/Miner
Lord	Serf
Foreman
Kingpin
Taskmaster

See also: https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now

[eine]

Commodore <-> Lemming

---

Motivation: Lemmings is a videogame from 1991 launched for Commodore Amiga: https://www.youtube.com/watch?v=N6DfGKfVWPs

[GlenNicholls]

I found this https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now

I really like master/mason, master/agent, hive/drone, and hive/worker. My argument against some of the fun ones like Gru/minion is you need context to understand it if it's your first time reading it. By choosing something that everyone is familiar with, it is a seamless transition.

[JimLewis]

Supervisor <-> Minion

Motivation: Both are dictionary words (even before the movie) and if we are going to change, why not something fun.

On reflection, I like it, it is fun, but perhaps it is not natural enough.

[JimLewis]

initiator <-> target
Xilinx Documentation ug761 defines Master Interface as:
An interface of an IP or module that generates out-bound AXI transactions and thus is the initiator (source) of an AXI transfer.

Similarly for Slave Interface:
An interface of an IP or module that receives in-bound AXI transactions and becomes the target (destination) of an AXI transfer.

On reflection, I think this is close but not quite it - see my comments below.

[JimLewis]

Controller <-> Peripheral

If I put my "fun" hat aside, this is what I end up with. Controller because it covers either a Processor or DMA controller. Peripheral because that is the historical term for which CPUs and DMA controllers have talked to - and hence, when I see it I immediately relate to what it is. I took a look at my 1995 Intel 486 data book and it refers to the chips on the bus as peripheral components.

[LarsAsplund]

Leader <-> follower

I like this because because it ticks the following boxes

• Like master/slave it's clear about the authority
• Unlike master/slave it doesn't imply that one owns the other. Ownership is a relevant concept in programming but it's not relevant for describing the relation between the two communicating parts.
• One thing that separates it from several of the other proposals is that it doesn't imply a fixed arrangement. The part taking the lead can differ between transactions. The master/slave and some others analogies don't support that.
• Simple words for us less fluent in English
• Others have replaced master/slave with this.

When reading the other proposals I see that initiator/target also ticks these boxes. I actually like that more because it feels more like hardware. I wrote this just to be very clear about the properties I value.

[eine]

My main argument against controller or target is that those terms are already used in control applications. In fact, controllers might be peripherals of the CPU/bus. At the same time, target is frequently used as platform, device or plant.

Regarding leader - follower, source - sink, producer/driver - consumer/responder, etc. my concern is that the leader/source/producer is NOT always the master. There are many contexts where peripherals produce/generate content and masters read it through pooling.

Hence, I prefer head - helper, manager - taker, agent - node, etc. where there is no implicit direction. Commodore - Lemming is just a fun variant which fulfills Lars' items and mine.

[JimLewis]

Requestor <-> Responder

I have been working on AXI models for the last week. So everyday I have thought about the different words that could possibly replace and have some association with hardware. At this point, this is my number 2 choice (behind Super <-> Minion).

[Paebbels]

In my strong opinion, as long as a standard is not changed, the naming in an interface or view will not change.

With aliases or mappings as discussed in #10, this problem can be solved to everyone's personal feelings.

---

Are we going to call a multi-master bus a federalism?

[JimLewis]

@Paebbels Here in the US, at this point, change seems inevitable. OSVVM will change at least Slave. So if you want a say in what is next, I recommend you voice an opinion.

I have already changed AxiStream to Transmitter <-> Receiver as that was obvious and M/S never belonged there in the first place.

For Axi4 Full and Lite, I am leaning toward either Responder or Minion. I have seen Minion used in other places. It is ok if people need to look it up the first time - that way it is less likely to trigger someone. :)

[NJDFan]

Super/minion works. Source/target isn't bad. Requester/Responder has a whole lot of characters; fingers are going to get mighty tired by the end of a project. And that q is way off in a corner.

…

On Sun, Jul 12, 2020 at 3:02 PM JimLewis ***@***.***> wrote: @Paebbels <https://github.com/Paebbels> Here in the US, at this point, change seems inevitable. OSVVM will change at least Slave. So if you want a say in what is next, I recommend you voice an opinion. I have already changed AxiStream to Transmitter <-> Receiver as that was obvious and M/S never belonged there in the first place. For Axi4 Full and Lite, I am leaning toward either Responder or Minion. I have seen Minion used in other places. It is ok if people need to look it up the first time - that way it is less likely to trigger someone. :) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#27 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBCACGW775LC5WW6ZNMTI3R3IXFVANCNFSM4OUWUHKA> .

[GlenNicholls]

Requester/Responder has a whole lot of characters; fingers are going to get mighty tired by the end
of a project.

I think abbreviations of req/resp, or the standard abbreviation req/rspnd would suffice in-code. When I've done stuff with master/slave, I've adopted m_* and s_*. I don't think the length of the word matters as long as it is short already, or has an obvious abbreviation.

[JimLewis]

A challenge: Write in a sentence what a master does and what a slave does.

With respect to an Address Bus type interface, I get:
M: A party (model/device/IP block) that initiates transactions on an interface.
S: A party that responds (or provides a response) to transactions on an interface.
Hence if I were to change both, I would use:
Initiator <-> Responder

The OSVVM AXI models, currently use: Master <-> Responder

With respect to a streaming interface, I get:
M: A party (model/device/IP block) that transmits transactions on an interface.
S: A party that receives transactions on an interface.
Hence I would use instead:
Transmitter <-> Receiver

The OSVVM UART and AxiStream currently use: Transmitter <-> Receiver