Intro and Question on Hardware IP Domain Specific Terms

[Tom Wurtz]

Hi Inclusive Naming Initiative people!

My name is Tom Wurtz and I am the Senior Director of the Customer Knowledge Applications (Technical Support and Documentation) team at Xilinx Inc. Xilinx is committed to evolving toward more inclusive names in our products going forward. I'm excited to see this community devoted to trying to work together on making the change. I have looked through the resources available and in most cases we see clear mapping to inclusive terms. The replacements for master/slave however is proving to be a bit of a challenge. We rely heavily on Arm's AMBA specification for a lot of the IP we offer to our customers. We have been in close contact with Arm recently and have reviewed the proposed next revision of their spec. They’ve put forth a small number of replacement terms for the different contexts in which the M/S terms are currently applied to. When we went to map those replacement terms into the suggestions in the Inclusive Naming Initiative word replacement list, they didn't appear and frankly none of the terms in the word replacement list seem to be appropriate for most of the contexts in the hardware IP domain. Has this been raised previously and should there be a dedicated workstream for this topic?

Thanks,

Tom Wurtz

[Larry Kunz]

Hi, Tom. Thanks very much for engaging with us. I applaud Xilinx for wanting to move toward inclusive terminology. 

Even though we try to formulate our terminology recommendations to be as broad as possible, there are so many different domains that they might not apply in every context. The key in those cases is to be aware of why a given term is offensive or divisive, and to use your domain-specific knowledge to select alternatives that fit your context.

That said, can you please elaborate on why the recommended master/slave alternatives don't work in your situation? I also hope you'll participate in INI so that your voice can be heard. All this will help us broaden our knowledge as we move forward as a community. 

Thanks,

Larry Kunz

[Tom Wurtz]

Thanks, Larry.

One big area where HW IP has a challenge is that we have a lot of pins and attributes that use M and S as initials. This is the reason Arm went with Manager and Subordinate in most cases. Even they recognized that didn't work in all cases and picked Transmitter and Receiver in at least one case. A couple other use cases would be ingress/egress or host/destination. Unfortunately we've been very sloppy in employing master/slave through the years.

I think my approach at this point will be to see if I can get a critical mass of people from this domain to have a conversation and then come back with a clearer idea of where we want to go.

Thanks, again.

Tom

[Damian Yerrick]

For "master" and "slave", both Nintendo and SEGA have used "main" and "sub".

- A Vs. Dualsystem arcade system board takes input from two control panels and outputs to two screens. The Vs. System manual and the analytics screens in the service console of the game Vs. Ice Climber refer to these as "main" and "sub" sides.

- Color blending functions in the Super Famicom (Japan) or Super NES (North America, Europe) route pixels from background and object layers into "main" and "sub" layer groups, whose colors can be added, averaged, or subtracted to form the final pixel.

- Developer documentation for the Mega CD (Japan, Europe) or Sega CD (North America) accessory mentions a "main" CPU in the Mega Drive or Genesis console and a "sub" CPU in the accessory.

- Developer documentation for the Nintendo DS handheld video game system describes a "main" GPU, with 2D and 3D cores and more VRAM, and a "sub" GPU, with only 2D and less VRAM.