Inconsistent labelling of ports in combinational components

[edstott]

Describe the bug Some combinational components in the catalogue don't have consistent port labelling:

• Some components have a Q input, which clashes with the Q output of sequential components
• The N bits OR component has no port labels, unlike the other N bits ... components
• The adder has ports labelled Cin and COUT, which have inconsistent capitalisation
• The N bits NOT component has an input IN, which isn't consistent with other N bits ... components

Expected behaviour There are many possible naming conventions. My preference would be to loosely follow IEEE standards where they are intuitive, since we are using IEEE gate symbols and they may align better with literature. I also think concise, symbolic labels throughout would be better than the current mix of IEEE symbolic labels (e.g. D, Q), abbreviated labels (e.g. Cin, COUT) and natural language labels (e.g. IN, OUT, SUM). But a minimal fix could be:

• Change Cin to CIN
• Change P and Q inputs to A and B
• Add port labels to N bits OR

[tomcl]

I agree in principle. The cosmetic & typo changes will be folded in right away.

Changing P,Q to A,B results in a naming clash in Spring where Ra,Rb outputs feed an ALU with adders that have A,B inputs. In addition I think (but maybe not) P,Q are used in Autumn Term notes - and they are certainly used in Spring notes - so it will need some rewriting?

One of the problems here is that IEEE notation is fine with unlabelled outputs, but for net differentiation in simulation all ports must have unique per symbol names. Hence IN,OUT.