The array component's ports as names and widths - what every sheet signature is - and what is wrong with the sheet if anything.

How many bits the select input of an array multiplexer has: enough to index the copies, and never zero, since a width of zero is not a width. ceil(log2 copies), counted by shifting an int rather than through ParameterTypes.clog2, which takes a bigint. A copy count is small by construction - ArrayElaborate.Constants.maxArrayCopies bounds it, as a bus width is bounded - so converting one to a bigint to count its bits would be work for nothing. The same answer as clog2 for every value this is asked about.

The name of the sheet port an unmatched JoinIn becomes. The direction is in the name as well as in the port list so that the two ends of one channel read apart, and so that the generated names sit further from anything a user would write.

The name of the sheet port an unmatched JoinOut becomes.

Which JoinOut in which copy drives which JoinIn in which copy, and which ends are left over. The one place join semantics live. parseDiagramSignature asks it what ports the sheet has, and the expansion asks it what wires to draw between the copies, so the two cannot disagree about which end of a chain is loose. A JoinOut end and a JoinIn end MATCH when they carry the same label and the same channel number; a match is a wire from one copy to another. Everything left over becomes a port on the sheet's outline - an unmatched JoinOut an output, an unmatched JoinIn an input - which is what makes the ends of a chain the array's own connections without anything having to say which copies they are.

The unmatched ends of one join component, grouped by the channel they are on and in channel order, so that a sheet with several loose ends lists them predictably. One PORT per channel, and EVERY end on that channel with it. A port is named after the channel, so a channel several copies are loose on can only be one port - but it is a port of all of them, and each has to be wired to it. A number that does not vary with the loop variable is the extreme case (every copy on one channel); `i/2` is the ordinary one, giving the array one input per pair of copies. Keeping one end per channel and dropping the rest wired the first copy and left the others' body ports dangling, which came out as an unconnected port on a sheet the user cannot open.

The name of the select input a MuxOut adds to the sheet, beside the output of its own name.

The ports an array design sheet has, and what is wrong with the sheet if anything. DERIVED from the sheet's contents and its copy count, rather than being its Input1 and Output components - which is the whole of what makes an array sheet different from every other sheet as far as anything outside this module is concerned. The copy count is a plain integer on the sheet, so this is a fact about the SHEET, exactly as an ordinary sheet's ports are. Ports come in the (Y, X) order of the components that generate them - the order getOrderedCompLabels already uses. A MuxOut contributes BOTH an input and an output, so the two lists are over the same components in the same order and a mux select lands in the middle of the inputs, which is exactly where the outline puts it. The canvas passed in must already be resolved at whatever bindings are wanted, as signatureOfInstance resolves it: the widths here are read off the components.