Inconsistent labelling of ports in combinational components
Describe the bug Some combinational components in the catalogue don't have consistent port labelling:
- Some components have a
Qinput, which clashes with theQoutput of sequential components - The
N bits ORcomponent has no port labels, unlike the otherN bits ...components - The adder has ports labelled
CinandCOUT, which have inconsistent capitalisation - The
N bits NOTcomponent has an inputIN, which isn't consistent with otherN 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
CintoCIN - Change
PandQinputs toAandB - Add port labels to
N bits OR
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.