Case-Study Case-Study, Multi Channels, Design Flow, Detector
Almost every real experiment has more than one channel, and in almost every one of them the channels do the same thing. A 16-strip detector, a 32-channel SiPM array, an 8-fold coincidence system, a 64-anode PMT. The processing is identical; only the samples differ.
The naive way to build that is copy and paste. It works exactly once. The second time the algorithm changes, there are thirty-two copies to edit, and the interesting question becomes not whether you will miss one but which one — and a channel that quietly kept the old threshold is a bug that survives commissioning and shows up in the analysis.
Sci-Compiler’s answer is a sub-design whose ports know they belong to a multichannel block.
The one decision that matters: ARRAY or COMMON
A sub-design is an ordinary sheet holding the logic for a single channel. Draw it once, with whatever blocks the channel needs. What makes it a multichannel sheet is how its ports are declared.
When an input port is placed — right-click, MISC → Schematic Port — the dialog asks how that port should behave when the sheet is replicated:
ARRAY gives one instance of the port per channel. This is for anything that differs between channels: the signal itself, a per-channel threshold, a per-channel enable. On the sheet the symbol picks up a multi-square icon so that the choice is visible without opening the dialog.
COMMON gives one port shared by every channel. This is for configuration: a mode selection, a global enable, the polarity bit that applies to the whole detector.
That single choice is where the design is actually expressed. A threshold declared COMMON is the decision that all channels share a threshold; declared ARRAY it is the decision that they do not. Both are legitimate. What is not legitimate is discovering six months later which one you picked.
Output ports are always ARRAY, and the tool does not offer the choice. The reason is a hardware fact rather than a preference: N channels driving one net is a bus contention, so a COMMON output is not a design that could be built.
Replicating it
Compile the sub-design sheet, then in the top design place it: right-click, sub-design → Multi channels sub design, pick the sheet and say how many times to repeat it.
The block that appears is the whole story in one picture. N: 4. One SEL_POL pin, because it was declared COMMON. Four S_IN_ pins and four S_OUT_ pins, because those were ARRAY and outputs always are.
Change the algorithm once, on the one sheet, and all four channels change. Or all sixty-four.
The hierarchy rule that catches people
Sub-designs nest — root, branch, leaf — and a design of any size ends up as a tree.
There is one restriction, and it is not arbitrary. A child sheet can contain any logic except hardware I/O and memory-mapped peripherals. Only the top sheet has direct access to the physical I/O and to the communication interfaces; child sheets reach them through schematic ports.
This is the right constraint rather than a limitation. A leaf sheet replicated thirty-two times cannot each own the same physical pin, and a memory-mapped register replicated thirty-two times would need thirty-two addresses assigned by something that does not exist. Keeping both at the top is what makes replication well defined in the first place.
Living with a hierarchy
Most of the recent work in this area is not about the concept but about hierarchies surviving contact with real projects, which is where they usually fail:
- hierarchical export and import that carries nested sub-designs with it, rather than the top level only;
- cyclic dependency detection on save, export and import, so that A → B → A is refused rather than built — and the sub-design list hides, and paste rejects, anything that would close a cycle;
- endpoint labels and memory map regenerated correctly when a placed sub-design is pasted;
- Ctrl+click to descend into a sub-design instead of hunting for it in the project tree.
None of these are features anyone asks for in advance. All of them are what separates a hierarchy you can maintain from one you stop touching.
The other axis
Replication gives every channel its own hardware, which is the right answer when every channel must run at full rate at the same time and the device is large enough.
There is a second way to get N channels — pack them onto one bus and let a single block serve the lanes in turn — and it trades area against throughput on completely different terms. That is time multiplexing, and because it is easy to reason about wrongly it has its own case study, which also explains the trap that comes with it.
The two combine. A common shape for a large instrument is TM within a group and replication across groups: four time-multiplexed blocks of eight lanes each, rather than thirty-two separate chains or one thirty-two-lane block that cannot meet the sample rate. Sub-designs support TM ports, so a TM datapath sits inside a replicated sheet without difficulty.
What this is really buying
For a large instrument the win is not primarily area. It is that the design has one place where the channel algorithm lives.
Every subsequent change — a filter coefficient, a threshold policy, a bug found in the third month of commissioning — is made once and is correct in every channel by construction, rather than being made thirty-two times and correct in thirty-one.
This is a reference article. The port semantics, the replication flow and the hierarchy rules are as documented in the user guide, and the screenshots are the guide’s own.