# astrimid - Regarding multiple components in one...

Channel: #support
Source: https://discord.com/channels/1233487248129921135/1526700084014878780
Started: 2026-07-14T21:21:05.242000+00:00
Last activity: 2026-07-23T09:56:46.052000+00:00

## astrimid — 2026-07-14T21:21:04.745000+00:00

Regarding multiple components in one body.

Another detail directly relevant to manufacturing (but probably not for schematic purposes) is an ability to split one physical component into `A` and `B` part. In this example, PQ203 is a dual MOSFET, meaning it's two independent `<mosfet>` in one PCB body. So pins have continuous numbering across the multiple components in a schematic. 

This is probably the hard one, as you'd need two different view for schematic and PCB trace:
for PCB you must have it as a single chip, while for schematic you'd want A part and B part:

```
    {/* Physical Dual MOSFET package placed on the PCB */}
    <chip name="PQ203" footprint="soic8" />

    {/* PART A: Positioned on the left side of the schematic sheet */}
    <mosfet
      name="PQ203A"
      schX={-15}
      schY={10}
      connections={{
        gate: "net.gate_ctrl_A",
        source: "net.gnd",
        drain: "PQ203.pin8" // Tied to physical pin 8 of the single chip
      }}
    />

    {/* PART B: Positioned far away on the right side of the schematic sheet */}
    <mosfet
      name="PQ203B"
      schX={25}
      schY={-5}
      connections={{
        gate: "net.gate_ctrl_B",
        source: "net.gnd",
        drain: "PQ203.pin5" // Tied to physical pin 5 of the single chip
      }}
    />

```

## astrimid — 2026-07-14T21:21:16.260000+00:00

Don't know if it's possible to hide the `chip` component for schematic, while hiding A and B components for the PCB and still representing these two components as in one physical body. I guess it can be thought of internal implementation of a chip flattened to a schematic.

Maybe something like this:

```
    <DualMosfet
      name="PQ203"
      // Position Part A near your power entry logic
      partA_schX={-20}
      partA_schY={15}
      // Position Part B far away near your switching/control logic
      partB_schX={35}
      partB_schY={-10}
      connections={{
        gateA: "net.gate_ctrl_A",
        sourceA: "net.gnd",
        drainA: "net.vcc_switched",

        gateB: "net.gate_ctrl_B",
        sourceB: "net.gnd",
        drainB: "net.led_driver",
      }}
    />
```

Or maybe this could be a group/subcircuit/chip with ports?

## Seve — 2026-07-14T22:17:19.061000+00:00

hmmm that's interesting and yes i think DualMosfet makes sense

## Seve — 2026-07-14T22:17:32.577000+00:00

the mosfets would be represented with a spice model that contains two mosfets right?

## Seve — 2026-07-14T22:17:37.655000+00:00

it's kind of like a mosfet array

## astrimid — 2026-07-14T23:00:08.812000+00:00

I've looked at DMN65D8LDW manufacturer's SPICE model, and contains only one MOSFET. Additional components in the model provide specification for timing, body diode, resistance, but not the second transistor. So semantically it's 2 MOSFETs in one body.

Does tscircuit already have an array of component packed into one physical chip/group, while specifying properties for each so that they could be split into different parts of the schematic?

## astrimid — 2026-07-14T23:01:25.284000+00:00

Oh, I forgot to attach a reference
Attachment: image.png — https://community.tscircuit.com/media/1526725335679369336

## astrimid — 2026-07-15T00:58:58.648000+00:00

schematic of AC_DISC path.
PQ203A and PQ203B are inside DMN65D8LDW 6 pin chip.

There's a separate use case where DMN65D8LDW has both mosfets acting as one, even though it's 6 pin package.

BTW, couldn't find the sot363 in the footprint list. Maybe footprint should be provided in the `<chip>` while the schematic level mosfets should not required `footprint`.
Attachment: image.png — https://community.tscircuit.com/media/1526754919196004423
Attachment: image.png — https://community.tscircuit.com/media/1526754919661699272

## Seve — 2026-07-15T01:36:21.099000+00:00

yea schematics should run without footprints specified for sure

## Seve — 2026-07-15T01:37:12.294000+00:00

CC <@809856037376491570>

## astrimid — 2026-07-15T03:51:31.199000+00:00

I've tried it, and it looks like this is already possible with custom components and chips:
```
    <DualMosfetSot363 
      name="Q203"
      mfg="Diodes Inc."
      mpn="DMN65D8LDW"
      footprint="sot363"
      chA={{
        channelType: "n",
        mosfetMode: "enhancement",
        symbolDrainSide: "top",
        symbolSourceSide: "bottom",
        symbolGateSide: "right",
        schSectionName: "ac_disc_path",
        schRotation: 0,
        schX: 2.3,
        schY: 13,
      }}
      chB={{
        channelType: "n",
        mosfetMode: "enhancement",
        symbolGateSide: "right",
        schSectionName: "ac_disc_path",
        schX: 6,
        schY: 11,
      }}
    />
```

The tricky part is how to specify that `<mosfet>` is inside the `<chip>` rather than connected to it exteranally, while also maintaining the ports mapping and separate A/B channel coordinates, and passing throught all those properties.

## astrimid — 2026-07-15T04:07:26.527000+00:00

Maybe there should be some kind of composition relationship between chip and implementation? Maybe I'm missing something basic. What I need is a physical chip in 6-pin package to look like two 3-pin mosfets in schematics, while being opaque 6-pad on PCB. And also supporting loading up spice models for simulation behaviour.

## astrimid — 2026-07-15T04:11:38.585000+00:00

maybe I should use `schematicDisabled` on a `<chip>` and some kind of `pcbDisabled` on the `<mosfet>`? while also supplying a custom spice model

## Seve — 2026-07-15T04:30:00.466000+00:00

yea i'm trying to think this through as well

## Seve — 2026-07-15T04:30:10.252000+00:00

it's a case where the PCB diverges from the schematic right

## Seve — 2026-07-15T04:34:21.270000+00:00

i think one way to do it is sort of as you suggested, the <chip /> and <mosfet /> are BOTH defined, but are somehow linked together e.g.

```
<chip name="U1" footprint="soic8" />
<mosfet chipRef="U1" name="Q1" />
<mosfet chipRef="U1" name="Q2" />
```

but i think that's a bit unclear


```
<chip name="U1" footprint="soic8" />
<mosfet footprintRef="U1" pinMapping? />
<mosfet footprintRef="U1" pinMapping={{ drain: "U1.pin5", ... }} />
```

## astrimid — 2026-07-15T11:35:48.099000+00:00

I think what nags me is whether the `<chip/>` is an opaque IC we don't know nothing about and just declare a part number as an opaque box to have a footprint on PCB and pin headers on schematic, or is it a shell for internal schematic components that expose ports through that shell.

## astrimid — 2026-07-15T11:37:55.342000+00:00

right now, as I understand `<chip/>` is an opaque box, so if we define boh chip and internal components, both would show up in pcb, schematic and simulation.

## astrimid — 2026-07-15T11:41:54.537000+00:00

Ideally, I think a new component, e.g. `<chipShell />` or some kind of `<footprint />`, should wrap the internal schematics. I saw somewhere an example of using `<port >`, but it looks like this is for logical subcircuits and groups, not for physical package having internal schematics.

## astrimid — 2026-07-15T11:48:45.070000+00:00

how about using child components? This is defining declaratively what the semantic meaning is without imposing any implementation:

```
    <chipShell 
      name="Q203" 
      footprint="sot363" 
      mpn="DMN65D8LDW"
      manufacturer="Diodes Inc."
    >
      {/* 
        2. Break out and position Subunit A
        You can place it exactly where it belongs in the 'ac_disc_path' section.
      */}
      <mosfet 
        unitId="A" // 👈 Unique subunit key (Translates visually to Q203A)
        channelType="n"
        schSectionName="ac_disc_path"
        symbolGateSide="right"
        schX={2.3} 
        schY={13} 
        schRotation={0}
        pinMapping={{ gate: "pin2", source: "pin1", drain: "pin6" }} 
      />
      
      {/* 
        3. Break out and position Subunit B 
        This part can be moved to an entirely separate area of the schematic canvas!
      */}
      <mosfet 
        unitId="B" // 👈 Unique subunit key (Translates visually to Q203B)
        channelType="n"
        schSectionName="power_regulation_path" // Can belong to a different visual section!
        symbolGateSide="left"
        schX={45} 
        schY={-8} 
        schRotation={180}
        pinMapping={{ gate: "pin5", source: "pin4", drain: "pin3" }} 
      />
    </chipShell>
```

## astrimid — 2026-07-15T11:51:56.198000+00:00

The question is whether you use `.Q203.B.pin1` or `.Q203B.pin1` or `.Q203.pin4` to define traces

## astrimid — 2026-07-15T12:00:35.955000+00:00

concatenating chipshell name and unitId feels simpler to implement and helps with schematic subunit naming, `Q203.pin4` feels honest about physical reality while creating a bit of confusion when it's rendered to two units, `Q203.B.pin1` is idiomatic, but I've not seen examples with two dots so far. Maybe unitId property should have a full name, e.g. `unitId="Q203B"` which creates a bit of duplication, but explicit without conventions and flexible if you want a different label. So tracing becomes .Q203B. But what about pin numbers? Do we use internal or external numbers/labels? Maybe we use internal logical names, e.g. `.Q203B.gate` but provide an outer shell pin numbers on a schematic/PCB?

## astrimid — 2026-07-15T12:17:53.500000+00:00

claude wrote this spec from this thread: https://claude.ai/public/artifacts/669c2734-c2c9-4afc-8e9b-3c4fee49858e
it made some decisions I wouldn't make but maybe it has a better mental what suits tscircuit or I need a better prompt.

## astrimid — 2026-07-15T12:59:26.429000+00:00

I probably don't need the PCB part, and I currently don't need complex simulations that require custom spice models, generic mosfet is fine for my use case. But having a peace of mind that I can make a mental map from the schematic to a physical device would be nice.

## astrimid — 2026-07-15T13:16:53.477000+00:00

Maybe I just need a type of `<subcircuit/>` with different semantic and pin/port mapping mechanics. Maybe some rules can be applied to child components via TS interfaces:

- It must be inside a <chipShell> to receive a unitId; a bare <mosfet unitId="A"> outside a shell is an error.
- It must specify pinMapping, mapping its own logical terminals (gate/source/drain, or anode/cathode, etc.) to package pin numbers of the shell.
- Children behaves as a completely normal standalone components and everyting that works inside subcircuit works inside `<chipshell>` with some parent guided tweaks.

So the POC is just API to define unit identification, parent/child relationship, and redefine pin numbering (if tscircuit supports displaying pin numbers on schematic). Whether it's implemented by using high-level subcircuit/chip/disableSchematic props or internal tscicuit API can be decided down the line.

Sorry for spamming the thread. I hope it will be useful.

## astrimid — 2026-07-15T13:22:39.558000+00:00

gemini-generated lightweight spec:

https://share.gemini.google/yCB2LRRyMXFN

## Seve — 2026-07-15T15:31:05.570000+00:00

yes that makes sense to me, <compoundchip> or something, or possibly we just make it so that <chip> supports it whenever there is children, we could also have e.g. <schematicrepresentation> within chip

I don't fully understand the unitId concept

## astrimid — 2026-07-15T19:43:20.512000+00:00

TL;DR, unitId is all about identification and mapping.

You need to identify both the chip and the schematic inside it. To allow schematic to be positioned in different logical places on a schematic you need to identify those schematic units.

The convention is A and B appended to the name of the chip name/id. We also need to map internal logical names to the outer shell pins sorta like subcircuit ports.

```
<chipShell name="Q203">
  <mosfet unitId="A" pinMapping={{ gate: "2", source: "1", drain: "6" }} />
  <mosfet unitId="B" pinMapping={{ gate: "5", source: "4", drain: "3" }} />
</chipShell>
```

`<chip/>` having children makes sense, my first thought was why do you need chip, subcircuit and group, as they seem to mean the same thing. Now I see there's a need to separate traces on the motherboard and logical "traces" (connections) inside the chip. 

Currently, tscircuit is about designing PCBs, as I understand, so breaking out chip internals might be pulling it in the wrong direction. Alternatively, it could keep the opaque <chip/>, but it would make them programmable, e.g. actual code that takes power line, input ports and converts them to output ports or simulation result. This would allow for more powerful firmware simulations, but it's a totally other can of worms.

## astrimid — 2026-07-15T19:48:46.250000+00:00

If `<chip>` children have  automatic naming like `${chipname}${alphabetical letter}`, this could work too, it's just a bit implicit which is harder for learning curve.

## Mustafa7 — 2026-07-16T07:15:55.540000+00:00

<@757706909351411845> How's this?:
```<chip name="Q203" footprint="sot363">
  <schematicunit
    unit="A"
    symbolName="mosfet_n_channel"
    pinMapping={{ gate: "pin2", source: "pin1", drain: "pin6" }}
  />
  <schematicunit
    unit="B"
    symbolName="mosfet_n_channel"
    pinMapping={{ gate: "pin5", source: "pin4", drain: "pin3" }}
  />
</chip>```
Let me know where it can be improved

## Mustafa7 — 2026-07-16T11:18:54.437000+00:00

https://github.com/tscircuit/circuit-json/pull/648
https://github.com/tscircuit/props/pull/736

## Seve — 2026-07-16T15:19:39.751000+00:00

we can't introduce any terms that aren't an industry standard- i haven't heart of a schematicunit before- likewise w/ unitId, unit isn't really a term we're allowed to build off

## Seve — 2026-07-16T15:20:21.713000+00:00

the <chip> can contain a <mosfet>, that is using standard industry terms, and makes sense

## Seve — 2026-07-16T15:20:55.418000+00:00

<chip>
  <chipschematic>
     <mosfet>

also uses standard industry terms

## Seve — 2026-07-16T15:21:38.794000+00:00

the api for tscircuit should be "guessable", you can use AI to suppose what the ai would be, but if you think about the implementation too much (which I think people are doing in this thread) then you become biased towards the implementation and not towards the ideal API

## Seve — 2026-07-16T15:21:43.856000+00:00

we start from the API not the implementation

## Seve — 2026-07-16T15:46:25.941000+00:00

Do this 10 times with AI, in different chats, do not give it context
Attachment: image.png — https://community.tscircuit.com/media/1527340641187659827
Attachment: image.png — https://community.tscircuit.com/media/1527340642550939678

## Seve — 2026-07-16T15:46:48.488000+00:00

see what ideas it comes up with. You don't need to use a high reasoning mode, we're looking for "what's obvious"

## Mustafa7 — 2026-07-16T16:06:31.057000+00:00

1: ```<chip name="U1" footprint="dfn8" pinLabels={pinLabels}>
  <internalcircuit>
    <mosfet
      name="Q_HIGH"
      channelType="n"
      connections={{
        gate: "net.HG",
        drain: "pin.VIN",
        source: "net.SW",
      }}
    />

    <mosfet
      name="Q_LOW"
      channelType="n"
      connections={{
        gate: "net.LG",
        drain: "net.SW",
        source: "pin.GND",
      }}
    />

    <diode
      name="D_BOOT"
      connections={{
        anode: "pin.BOOT",
        cathode: "net.HG",
      }}
    />
  </internalcircuit>
</chip>```

## Mustafa7 — 2026-07-16T16:06:44.360000+00:00

2: ```<chip
  name="Q1"
  manufacturerPartNumber="DUAL_NMOS"
  footprint="sot23_6"
  pinLabels={{
    pin1: "G1",
    pin2: "S1",
    pin3: "G2",
    pin4: "S2",
    pin5: "D2",
    pin6: "D1",
  }}
  schDisplay="expanded"
  internalCircuit={
    <>
      <mosfet
        name="A"
        channelType="n"
        mosfetMode="enhancement"
        connections={{
          gate: "package.G1",
          source: "package.S1",
          drain: "package.D1",
          body: "package.S1",
        }}
      />

      <mosfet
        name="B"
        channelType="n"
        mosfetMode="enhancement"
        connections={{
          gate: "package.G2",
          source: "package.S2",
          drain: "package.D2",
          body: "package.S2",
        }}
      />
    </>
  }
/>```

## Mustafa7 — 2026-07-16T16:07:04.260000+00:00

3: ```<chip
  name="U1"
  footprint="dfn8"
  pinLabels={{
    pin1: "VIN",
    pin2: "HG",
    pin3: "SW",
    pin4: "LG",
    pin5: "GND",
  }}
  schDisplay="internals"
  internals={
    <internalcircuit>
      <mosfet
        name="HIGH_SIDE"
        channelType="n"
        mosfetMode="enhancement"
        connections={{
          gate: "pin.HG",
          drain: "pin.VIN",
          source: "pin.SW",
        }}
      />

      <mosfet
        name="LOW_SIDE"
        channelType="n"
        mosfetMode="enhancement"
        connections={{
          gate: "pin.LG",
          drain: "pin.SW",
          source: "pin.GND",
        }}
      />
    </internalcircuit>
  }
/>```

## Mustafa7 — 2026-07-16T16:07:19.840000+00:00

4:```<chip
  name="U1"
  footprint="sot23_5"
  pinLabels={{
    pin1: "VIN",
    pin2: "GND",
    pin3: "EN",
    pin4: "NC",
    pin5: "VOUT",
  }}
  functionalModel={
    <internalcircuit>
      <mosfet
        name="PASS_FET"
        channelType="p"
        mosfetMode="enhancement"
      />

      <trace from="pin.VIN" to="PASS_FET.source" />
      <trace from="pin.VOUT" to="PASS_FET.drain" />
      <trace from="pin.EN" to="PASS_FET.gate" />
    </internalcircuit>
  }
/>```

## Mustafa7 — 2026-07-16T16:07:32.614000+00:00

5: ```<chip name="U1" footprint="qfn16" pinLabels={...}>
  <chipinternals>
    <mosfet
      name="Q1"
      channelType="n"
      connections={{
        gate: "pin.GATE",
        drain: "net.INTERNAL_DRAIN",
        source: "pin.SOURCE",
      }}
    />

    <diode
      name="D1"
      connections={{
        anode: "net.INTERNAL_DRAIN",
        cathode: "pin.CLAMP",
      }}
    />
  </chipinternals>
</chip>```

## Mustafa7 — 2026-07-16T16:07:46.559000+00:00

6: ```<chip
  name="Q1"
  footprint="soic8"
  pinLabels={{
    pin1: "G1",
    pin2: "S1",
    pin3: "S1",
    pin4: "G2",
    pin5: "D2",
    pin6: "D2",
    pin7: "D1",
    pin8: "D1",
  }}
  internalCircuit={
    <>
      <mosfet
        name="A"
        channelType="n"
        connections={{
          gate: "pin.G1",
          source: "pin.S1",
          drain: "pin.D1",
        }}
      />
      <mosfet
        name="B"
        channelType="n"
        connections={{
          gate: "pin.G2",
          source: "pin.S2",
          drain: "pin.D2",
        }}
      />
    </>
  }
/>```

## Mustafa7 — 2026-07-16T16:08:03.417000+00:00

7: ```<chip name="U1" footprint="soic8" pinLabels={pinLabels}>
  <internalcircuit schDisplay="hidden">
    <mosfet
      name="Q_HIGH"
      channelType="p"
      mosfetMode="enhancement"
      connections={{
        gate: "net.HIGH_GATE",
        source: "parent.VIN",
        drain: "net.SW",
      }}
    />

    <mosfet
      name="Q_LOW"
      channelType="n"
      mosfetMode="enhancement"
      connections={{
        gate: "net.LOW_GATE",
        drain: "net.SW",
        source: "parent.GND",
      }}
    />

    <trace from="net.SW" to="parent.OUT" />
  </internalcircuit>
</chip>```

## Mustafa7 — 2026-07-16T16:08:20.355000+00:00

8:```<chip
  name="U1"
  footprint="dfn8"
  pinLabels={{
    pin1: "IN",
    pin2: "EN",
    pin3: "GND",
    pin4: "OUT",
  }}
  internalCircuit={
    <>
      <mosfet name="PASS_FET" channelType="p" mosfetMode="enhancement" />
      <resistor name="GATE_PULLUP" resistance="1Meg" />

      <trace from=".PASS_FET > .source" to="port.IN" />
      <trace from=".PASS_FET > .drain" to="port.OUT" />
      <trace from=".PASS_FET > .gate" to=".GATE_PULLUP > .left" />
      <trace from=".GATE_PULLUP > .right" to="port.IN" />
    </>
  }
/>```

## Mustafa7 — 2026-07-16T16:09:22.638000+00:00

9: ```<chip
    {...props}
    footprint="soic8"
    pinLabels={{
      pin1: "S1",
      pin2: "G1",
      pin3: "S2",
      pin4: "G2",
      pin5: "D2",
      pin6: "D2",
      pin7: "D1",
      pin8: "D1",
    }}
  >
    <chipinternals>
      <mosfet
        name="Q1"
        channelType="n"
        mosfetMode="enhancement"
        connections={{
          source: "$pin.S1",
          gate: "$pin.G1",
          drain: "$pin.D1",
        }}
      />

      <mosfet
        name="Q2"
        channelType="n"
        mosfetMode="enhancement"
        connections={{
          source: "$pin.S2",
          gate: "$pin.G2",
          drain: "$pin.D2",
        }}
      />
    </chipinternals>
  </chip>```

## Mustafa7 — 2026-07-16T16:09:43.779000+00:00

10: ```<chip
  name="U1"
  footprint="qfn8"
  pinLabels={{
    pin1: "VIN",
    pin2: "GH",
    pin3: "SW",
    pin4: "GL",
    pin5: "GND",
  }}
>
  {/* Proposed API */}
  <internalcircuit schematicDisplay="collapsed">
    <mosfet
      name="Q_HIGH"
      channelType="n"
      mosfetMode="enhancement"
    />
    <mosfet
      name="Q_LOW"
      channelType="n"
      mosfetMode="enhancement"
    />

    <trace from="pin.VIN" to=".Q_HIGH > port.drain" />
    <trace from="pin.GH" to=".Q_HIGH > port.gate" />
    <trace from=".Q_HIGH > port.source" to="pin.SW" />

    <trace from="pin.SW" to=".Q_LOW > port.drain" />
    <trace from="pin.GL" to=".Q_LOW > port.gate" />
    <trace from=".Q_LOW > port.source" to="pin.GND" />
  </internalcircuit>
</chip>```

## Mustafa7 — 2026-07-16T16:10:53.422000+00:00

6th looks good ig? similar to cadModel. What do you think?

## Seve — 2026-07-16T16:17:54.104000+00:00

the "collapsed" concept is good

## Seve — 2026-07-16T16:18:00.846000+00:00

but we prefer booleans

## Seve — 2026-07-16T16:18:20.679000+00:00

i would say internal/external is usually confusing

## Seve — 2026-07-16T16:18:27.365000+00:00

"internal to what?"

## Seve — 2026-07-16T16:19:05.559000+00:00

but yea actually

## Seve — 2026-07-16T16:19:07.565000+00:00

maybe it's ok

## Seve — 2026-07-16T16:19:14.552000+00:00

<internalcircuit> makes sense to me

## Seve — 2026-07-16T16:19:20.772000+00:00

fwiw cadModel also has <cadmodel>

## Mustafa7 — 2026-07-16T16:27:55.522000+00:00

So 6th is good to go right? should we start imp?

## Seve — 2026-07-16T16:52:44.576000+00:00

i'm worried that <internalcircuit> might be unclear because it only contains a schematic representation.... but yea let's try it

## Seve — 2026-07-16T16:53:15.129000+00:00

CC <@778624824875941908> this is interesting for SPICE representation

## astrimid — 2026-07-17T01:15:33.467000+00:00

I think it's not about the specific example of dual mosfet in one package. I think it's about API to define the logical/physical split explicitly where it's needed. tscircuit has 3 models in one react element: one schematic symbol, one PCB footprint, on BOM. entry The issue arises when 1-to-1 relationship breaks.

## astrimid — 2026-07-17T01:22:08.608000+00:00

It's more of a problem of single model vs multiple views

## astrimid — 2026-07-17T01:28:00.021000+00:00

[attachment]
Attachment: image.png — https://community.tscircuit.com/media/1527486999198568510

## astrimid — 2026-07-17T01:47:03.771000+00:00

Whad do you mean by "industry starndard"?
ASMEY14.44 defines reference designators which has units and sub-assemblies

https://en.wikipedia.org/wiki/Reference_designator

## astrimid — 2026-07-17T01:53:35.104000+00:00

If you're open to abandoning one-to-one approach:
```
<View target="schematic">
  {/* schematic-only content */}
</View>

<View target={["pcb", "bom"]}>
  {/* physical + BOM content, no schematic presence */}
</View>
```
Still needs cross-referencing.

## astrimid — 2026-07-17T01:58:16.040000+00:00

tscircuit already defines connections/nets (logical/PCB labeling)  and traces (physical implementation). Some properties are prefixed with `sch`, some with `pcb`. So it's already split at the props level if not at element level.

## Seve — 2026-07-17T03:56:47.397000+00:00

Taking a look

## Seve — 2026-07-17T03:58:42.138000+00:00

We’re not strictly isomorphic- but we do think about modular representation and yes for sure we think about explicitly designated for things to render “only in schematic” or “only in pcb”

## Seve — 2026-07-17T04:00:23.431000+00:00

But we also think about the natural expression, and redundant representation- eg repeating <mosfet ref=“.U1 internalcircuit .Q1” />

## astrimid — 2026-07-17T12:51:11.380000+00:00

One approach that could provide this flexiblity is ability of user-defined custom elements to implement circuit JSON directly. This way users can specify fine grained circuitjson representation using user defined <PCBDevice> and <SchematicUnit> elements (names are just an example) that work in the editor playground. Maybe it could be implemented using some react hooks/context API.

## astrimid — 2026-07-17T13:37:35.875000+00:00

I think tscircuit needs an **escape hatch** for use cases where basic assumptions break, use case is pecurliar and API is not yet available. Currently, PCB and schematic are fighting each other: sometimes you want to assign sourcing and physical pins to schematic elements, sometimes you want to wrap schematic elements with PCB device.

The fundamental problem with **React** model is that it's a **tree**,  while circuits is multiple **graphs** (physical graph and logical graph) and bidirectional relationship between them. `<net>` and `<trace>` work for defining network graphs, but when the components themseves need **composition** relationship, the abstraction over circuitJSON database leaks.

When we design PCBs, we want **logic-first** approach: define how the system works semantically, then assign manufacturers and sourcing, tweak generated PCB, adjust sourcing to optimize cost. When we analyze PCBs, we want **physical-first** approach: define the physical traces and footprints, explode schematic of  chips and define simulations. And engineers often switch back and forth between **top-down synthesis** and **bottom-up analysis**.

Back to our example of dual mosfet:
- synthesis: logical function -> high side mosfet + low side mosfet -> implement as a chip + PCB
- analysis: PCB traces and chips -> extract logical function as schematic -> explode chips as schematic -> simulate with injecting voltage and monitor using scopes

So it seems exposing raw circuitjson database via tscircuit props package is the only way to provide user-driven model organization. But the problem is we still need the coordinate system be context driven as we don't want to hard code the coordinates while still preserving relational positioning and routing. So we need a mechanism to pass down low level positioning as props from high-level contexts.

## astrimid — 2026-07-17T13:58:13.455000+00:00

So for synthesis, the low level API needs to allow injecting pcb part into the circuitjson and defining the schematic representation controllable from the higher level component.

For analysis, we need to query circuitjson by id, so that we can construct a simulation bench component without modifying the model while still be able to override some parameters of the model for simulation purpose.

## astrimid — 2026-07-17T15:06:56.914000+00:00

Here's an updated Claude summary/rfc of this thread that incorporates the `<internalcircuit>` and `collapsed` visibility control API from this discussion while sugesting other API levels to expose more user control. It also introduces termonology aligned with ASME/IEEE standards (element < part < unit).
https://claude.ai/public/artifacts/c87b3c8a-e757-41b6-999b-5320a0155530

This pushes tscircuit into ability to define internals of passive IC while still leaving room for drill down into SoC, microcontrollers and CPU schematics. Maybe even silicon fabrication file and chip simulation/emulation in the future.

## astrimid — 2026-07-17T15:17:56.638000+00:00

So far, `<chip>` + child nesting of schematic with display control (expanded by default, collapsible and completely hidden) seems to be a straightforward addition. Maybe pcbOnly/schOnly as phase 2 for non-nestable elements.
Attachment: image.png — https://community.tscircuit.com/media/1527695861386182807

## astrimid — 2026-07-17T22:12:09.980000+00:00

I wonder what's the purpose of `<constainedlayout>` with `pcbOnly` and `schOnly` props: https://github.com/tscircuit/props/pull/42

This might be exactly what's needed here

## Seve — 2026-07-18T05:12:06.190000+00:00

Just read through this- im not satisfied with the examples for schOnly and pcbOnly- i dont understand how this solves a problem- i think a more full ecample would help clarify what this solves. Im not inherently opposed to the props but i dont see the concrete/literal example of where they are needed

## Seve — 2026-07-18T05:13:17.620000+00:00

Constrainedlayout effecitvely isnt used at the moment- the api may be deprecated (some apis/layout algorithms never saw enough usage)

## Seve — 2026-07-18T05:15:19.751000+00:00

Also astramid i dont mean to be dismissive at all, we are at a 3 day conference otherwise i would dig in and make my own suggestions- it is solely because of limited time that im not suggesting/collaboratingbetter- i really value your feedback/ideas i think you are on to something- i just dont understand enough to greenlight schOnly/pcbOnly because it seems to me the internal mosfets are represented now

## astrimid — 2026-07-18T06:24:22.888000+00:00

are you saying `<internalcircuit>` already green lighted? or are you saying you can aleady achieve separate representations for pcb and schematic? I've tried chip + mosfet and there seem to be no way to hide chip from schematic

## astrimid — 2026-07-18T06:26:06.496000+00:00

also, I'd like the ability to view physical chip part props on "logical" elements, like real pin numbers and the manufacturer part number, but that's something for later enhancement

## astrimid — 2026-07-18T06:28:10.874000+00:00

I'm in no rush. I can find more examples of multi-element parts if that what you're looking for. Good luck with a conference

## astrimid — 2026-07-18T06:41:16.495000+00:00

here's texas intstruments dual channel comparator in soic8 footprint, that has 2 element schematic
Attachment: image.png — https://community.tscircuit.com/media/1527928225240715294
Attachment: image.png — https://community.tscircuit.com/media/1527928225617936434

## astrimid — 2026-07-18T06:42:49.658000+00:00

notably, here pin 8 and pin 4 are shared between two comparator elements, while in dual mosfets example they are logically indepenent elements

## Mustafa7 — 2026-07-18T07:37:32.536000+00:00

```<chip
        name="Q1"
        footprint="soic8"
        pinLabels={{
          pin1: "G1",
          pin2: "S1",
          pin3: "G2",
          pin4: "S2",
          pin5: "D2",
          pin6: "D2",
          pin7: "D1",
          pin8: "D1",
        }}
        connections={{
          G1: "net.GA",
          S1: "net.SA",
          D1: "net.DA",
          G2: "net.GB",
          S2: "net.SB",
          D2: "net.DB",
        }}
        internalCircuit={
          <internalcircuit>
            <mosfet
              name="A"
              channelType="n"
              mosfetMode="enhancement"
              schX={-3}
              schY={0}
              connections={{
                gate: "pin.G1",
                source: "pin.S1",
                drain: "pin.D1",
              }}
            />
            <mosfet
              name="B"
              channelType="n"
              mosfetMode="enhancement"
              schX={3}
              schY={0}
              connections={{
                gate: "pin.G2",
                source: "pin.S2",
                drain: "pin.D2",
              }}
            />
          </internalcircuit>
        }
      />```
Isn't this syntax good enough, the internalcircuit will be shown in schematic as U1A, U1B. chip will be hidden from schematic and will be shown only in pcb

## astrimid — 2026-07-18T16:07:24.764000+00:00

Yeah, it's essentialy the same as `<chip children={<internalcircuit/>} />` without nesting syntax sugar. One consideration: sinse you're already using custom property name, why not just do `<chip internalcircuit={[<element1/>, <element2/>]}` without wrapper, as `<internalcircuit/>` then won't be useful on its own.

## Mustafa7 — 2026-07-18T17:14:10.486000+00:00

We are following the already used patterns as <internalcircuit/> is similar to <cadmodel/>

## astrimid — 2026-07-19T00:39:32.064000+00:00

I see. So same pattern should be applied to pinLabels and conections?

```
<chip
   pinLabels={<pinLabels pin1="G1" />}
   connections={<connections G1="net.GA" />}
```

Also footprint might be something more complex than just a string:

```
<chip footprint={<footprint name="soic8" width="150mil" height="50mil" />} />
```

## Seve — 2026-07-19T06:51:34.607000+00:00

Not all props can contain elements, but all props that accept elements can be specified as children. For stuff like pin labels or connections, these are already shorthands for port and trace concepts

## Seve — 2026-07-19T06:52:07.603000+00:00

It is a good thought tho- would love to elaborate more too because i love api design and making sure we’re correct- but i gotta sleep!!

## astrimid — 2026-07-23T09:56:46.052000+00:00

`<schematicbox` approach seems to work