Generic intent component. This is extracted from the AI assisted bug reporting thread. It serves several goals. Currently, topological, electrical, mechanical, schematic, physical, etc domains are not explicitly tagged. So you don't know the difference between <net connectsTo and
Generic intent component.
This is extracted from the AI-assisted bug reporting thread. It serves several goals.
Currently, topological, electrical, mechanical, schematic, physical, etc domains are not explicitly tagged. So you don't know the difference between `<net connectsTo` and `<trace from to`, as both define a conceptual connectivity constraint.
There's no way to specify a generic model if you don't know a comprehensive list of all tscircuit features and component/props API. So when AI hallucinates, it tries to use something like `<nonexisting_element nonexisting_prop="desired_value">`. We need an escape hatch for AI to define things it doesn't know how to map becuase specification doesn't have it.
Another point is that tscircuit doesn't have a high-level intent components. You could define both schematic and pcb implementations of a concept, but there's no way to validate that schematic and pcb are both valid, even if you use LLM.
Example:
```
// TODO: This trace needs to be 90Ω impedance for USB 2.0
<trace from="J1.D+" to="U1.DP" />
```
Currently, `<differentialpair` exists, but pretend it didn't (previous versions). AI would hallucinate some nonexisting element and user would be confused while AI would gaslight them.
What I propose is some way to capture that TODO comment using general purpose `<intent> primitive. It could define topology (what connects to what), electrical connectivity (what the impedance or max resistance should be), mechanical/physical constraints (e.g. cutouts, footprint, 3D). It feels like circuitjson, but higher-level.
It is similar to subscircuit or group as it's a collection of domain properties, and interfaces, but it's more freeform.
The key difference it never fails. If there's no tscircuit element that defines the intent, it just works
Seve
i just want to re-iterate that we WILL/DO have high level intent, we just do not make it generic
Seve
if there is intent in code that is not used by the compiler, then that is typically stored as a comment, not an element
Seve
if we adopted this approach, AI would start to use <intent /> even as we introduced new elements
A
astrimid
How about making it a comment annotation?
```
/** @intent type="differential_pair" impedance="90Ω" targets={["J1.D+", "U1.DP"]} */
```
Seve
that's fine but it's outside of our framework scope- that could be a framework on top of tscircuit for example
Seve
because our philosophy is to define (strictly/well-typed) the intent specification and it's translation into circuit json
A
astrimid
The problem this solves is that currently, when AI generates some hallucinated code or reading existing implementation, we don't actually know what was the design intent. We see a couple of resistors and capacitrors, but we don't know whether it is voltage divider or a filter or both
Seve
comments are great for that but also we support things like <resistor pullupTo pullupFor /> etc. We would continue to add specific ways to indicate intent
Seve
also in general components names like <BoostConverter /> provide strong hints
Seve
it is also possible to enforce constraints via explicit <drccheck /> and <analog.simulationcheck /> elements (work here is ongoing)
Seve
so if you have characteristics that must be maintained, that is also specified and checked when the circuit is built
A
astrimid
The problem I constantly hit, is there's no escape hatch for stuff that is not supported. So if tscircuit doesn't support something, there's no workaround using low level stuff. I can describe in English what I want to do, but no way to draw schematic nets or PCB traces or add components to BOM or implement the circuit inside the chip.
This makes tscircuit unsuitable for general purpose CAD use case. So you can't conceptualy built upon tscricuit because it doesn't always provide low level primitives, even if circuitjson supports them.
Seve
i agree with what you're saying that that is a wall for users- and that is our fault if we don't have something supported in TSX, but we have to extend our specification rather than create generics because AI will prefer to use generics due to the way it is trained
A
astrimid
In my experience, AI prefers the most efficient representation. So if generic is most efficient way to describe intent why would a concrete specification even exist? If I could generate an SVG that would represent PCB or schematic using less number of tokens, why would I use tscircuit?
A
astrimid
if I could represent a PNG using less data, why would SVG exist?
Seve
generic is always less efficient, the higher level and more specific the representation, the less tokens needed to represent it
Seve
<connector standard="usb" /> carries with it effectively hundreds of lines of other elements
Want to add to the conversation?
Reply in Discord so your notes stay connected to the source.
