This example realates to board-level on a multi-board circuit. The design uses a 48V DC link, which is fed to all boards. This is converted at point of load by means of a switching converter(s) placed close to the power consuming components. We have - as utility sub-circuits: POL_48V_5V.sch: (a 5V output buck converter) POL_48V_3V3.sch: (a 3.3V output buck converter) POL_48V_-5V.sch: (a 5V output charge-pump) The system consists of: backplane.sch: (This has data-buses, and some IO buffers. It uses a 5V POL converter to power the buffers). mains_psu_module.sch: (A 240V AC to 48V dc supply) data_logging_card.sch: (A data-aquisition interface. It uses 5V, -5V, and has two channels) data_channel.sch: (A single channel of data-logging). It uses its a 3.3V POL converter ethernet_interface.sch: (A data-interface via ethernet). It uses a 5V POL converter. The design hierarchy looks like this: backplane.sch (/) |--part_1 (/*) |-- ... |--POL_48V_5V.sym (/POL5V_1.sym | |--POL_48V_5V.sch (/POL5V_1/) | |--(parts) (/POL5V_1/*) | |--mains_psu_module.sym (/MAINS_PSU_1.sym) | |--mains_psu_module.sch | |--(parts) (/MAINS_PSU_1/*) | |--data_logging_card.sym (/DATA_CARD_1.sym) | |--data_logging_card.sch (/DATA_CARD_1) | |--(parts) (/DATA_CARD_1/*) | | | |--POL_48V_5V.sym (/DATA_CARD_1/POL5V_1.sym) | | |--POL_48V_5V.sch (/DATA_CARD_1/POL5V_1) | | | |--(parts) (/DATA_CARD/POL5V_1/*) | | | |--POL_48V_5V.sym (/DATA_CARD_1/POL5V_2.sym) | | |--POL_48V_-5V.sch (/DATA_CARD_1/POL-5V_2) | | | |--(parts) (/DATA_CARD_1/POL-5V_2/*) | | | |--data_channel.sym (/DATA_CARD_1/CHAN_1.sym) | | |--data_channel.sch (/DATA_CARD_1/CHAN_1) | | |--(parts) (/DATA_CARD_1/CHAN_1/*) | | |--POL_48V_3.3V.sym (/DATA_CARD_1/CHAN_1/POL3V3_1.sym) | | | |--POL_48V_3.3V.sch (/DATA_CARD_1/CHAN_1/POL3V3_1) | | |--(parts) (/DATA_CARD_1/CHAN_1/POL3V3_1/*) | |--data_channel.sym (/DATA_CARD_1/CHAN_2.sym) | | |--data_channel.sch (/DATA_CARD_1/CHAN_2) | | |--(parts) (/DATA_CARD_1/CHAN_2/*) | | |--POL_48V_3.3V.sym (/DATA_CARD_1/CHAN_2/POL3V3_1.sym) | | |--POL_48V_3.3V.sch (/DATA_CARD_1/CHAN_2/POL3V3_1/) | | |--(parts) (/DATA_CARD_1/CHAN_2/POL3V3_1/*) | |--ethernet_interface.sym (/ETH_CARD_1.sym) |--ethernet_interface.sch (/ETH_CARD_1) |--(parts) (/ETH_CARD_1/*) |--POL_48V_5V.sym (/ETH_CARD_1/POL5V_1) |--POL_48V_5V.sch (/ETH_CARD_1/POL5V_1) |---(parts) (/ETH_CARD_1/POL5V_1/*) > So, counting POL converters, we have > POL_48V_5V x 3 > POL_48V_-5V x 1 > POL_48V_3V3 x 2 > The client requires flattened refdes to be ordered by layout on the PCBs, with prefixes: > 1xx = backplane, > 2xx = mains psu, > 3xx = data logging card, > 4xx = ethernet interface. It's up to the packages or flattened numbering program to do this. Anyway, these attributes could be stored in / (backplane.sch), /MAINS_PSU_1.sym, /DATA_CARD_1.sym and /ETH_CARD_1.sym. > Note that we can't name the componets of the 3V3 POL converters at the "data_channel" level, > as one level higher, we have two of these "data_channel"s instantiatied, and would need to > re-name the parts. The lowest level (for this design) we could store a flattened refdes for > the 3V3 POL converters, is in data_logging_card.sch. Yes, we can name them. Each element in each .sch has its own hierarchical name. Each sheet symbol instantiation has its own instace specific data, and each sheet symbol has its own hierarchical name. Thus, all symbols are accessed using the whole hierarchical name. I can access: /DATA_CARD_1/CHAN_1/POL3V3_1/R10 (this is the whole hierarchical name), as well as /DATA_CARD_1/CHAN_2/POL3V3_1/R10, and the tool knows they are different because of the whole hierarchical name. However, when creating flattened refdes, the instance-specific data is stored in each sheet symbol .sym data: /DATA_CARD_1/CHAN_1/POL3V3_1.sym has some attributes to do the mapping inside its associated schematic: attribute(R10, "flattened_name") = "R105"; attribute(C10, "flattened_name") = "C205"; /DATA_CARD_1/CHAN_2/POL3V3_1.sym has also some attributes to do the mapping: attribute(R10, "flattened_name") = "R110"; attribute(C10, "flattened_name") = "C210"; Note that in both cases R10 and C10 names inside POL3V3_* are the same > This assumes data_logging_card.sch won't its-self get instnatiated in > some way which requires unique refdes between the isntances.