0hmx - Why don’t agents have an easy way to rep...

this sounds cool

Why not make tscircuit/tscircuit have all our issues- im a bit skeptical of not getting totally spammed like we do on repos with bounties tho

If I understand correctly, you would still need someone to decide whether it's a confusion regarding API or a genuine missing feature/bug. From my short experience, the bottleneck is not crafting a reproduction example. It's finding documentation on how it's intended to work to judge whether it's a bug, missing feature, edge case. For that I believe we need a database of real device reference schematics, not toy examples. Is there anything like that, where you can point AI to reference example of PCB you're doing, be it a developement board or mass produced PCB?

Even a database/templates of common circuits, like LDO, charge controllers, buck-boost regulators would probably help LLM-driven design more productive. As I understand https://common.tscircuit.com/ is whee they're supposed to live. Currently, I only see raspberry pi with usb-c. Could benefit from more complex multipage schematics and annotated with code example.

If that common circuitl organization system exists, we could try using LLM to populate that. One way to categorize is by "passive" vs "programmable" components/circuits. Another way is by "physical" implementation vs "logical" function.

There is the “sparkfun boards” repo, the common repo we will mostly reserve for physically validated boards (something we know for sure works) until we are confident in ai https://github.com/tscircuit/sparkfun-boards

For ai generated circuits, i think anyone can push them to our registry via “tscircuit push”, we will also do this for designs that may not be physically validated

I'm thinking some repo for showcasing functional chips. For example reproducing texas instruments evaluation boards documentation: https://www.ti.com/lit/ug/slvu086/slvu086.pdf It has bill of materials, schematics and PCB layout, so seems to be perfect for creating tscircuit representations which could be backfed to train LLMs or creating skills.md Sparkfun appears to be a manufacturer? So does it mean a separate git repository per manufacturer?

For official repos yep

There is a tscircuit/ti repo as well

Ah, so it already exists and works. I was confused by editor syntax error: `Cannot find module '@tsci/tscircuit.ti' or its corresponding type declarations.` thinking I'd need to clone the repo locally and run the local copy. So there are official repos, maintained by tscircuit and community-implemented repos? And I could potentially create my own library LLM could feed on?

Yep!!! The official repos are pretty new so we’ll look into that issue cc <@809856037376491570>

Ok. Looking back at original thread, this seems to be a human-driven reporting without creating/navigating discord/github accounts/channels/repos, not fully automated feature/bug discovery. For this particular missing feature (impedance or diff pair gap), we have two facets: logical requirement (impedance) and PCB implementation (constraint on physical distance between traces, width, pcb layer thickness, etc). One could be represented as annotation on schemetics, another needs to be encoded as manually calculated and specified constraints for automatic routing. So one design intent needs multiple specifications: physical and logical/electrical constraints. Hence my previous note about canonical hierarchical listing of features independent of EDA implementation, so that AI could transplant and map knowledge.

Yea there are multiple domains that specifications map to, eg a usb port itself implies a differential pair. It also implies a cutout aperture for an enclosure, the need for power etc

So for automatic AI design it needs to: fetch the design intent from database, like electrical requirement for USB signals, solve the physycal constraint given electrical requirements and then try to implement it in tscircuit using `<keepout>`-like workaround with annotations while submitting a request for intent design syntax sugar (to compress it into fewer tokens/code).

yea the TSX is mostly a way to reduce the amount of context required- this is also true of any higher level language

As I understand, currently there's no high level "design intent" specification that encodes constraint domains (e.g. standard imposed characteristics). The closest thing is SPICE model, but the inverse of simulation is needed for constraints. So each standard/design intent requires multi-domain specification. As you noted, tscircuit tries to build a single cross-domain model, to minimize redundant specification, but there's no way to capture intent explicitly as there are many cross-domain views. For example, `<net>` is logical view of `<trace>`, footprint and pin/pads locations is physical implementation of `<chip>`. So logical intent and physical constraint are interdependent as there's no source of truth. To overcome that, one could think of design intent annotation: ``` <intent name="usb_diff_pair" type="differential_pair"> <intent:electrical impedance="90Ω" maxSkew="5ps" /> <intent:physical minGap="0.15mm" // Space between D+ and D- traceWidth="calculated" // Auto-calculated from stackup maxLength="100mm" // USB 2.0 max length recommendation /> <intent:targets> <target element="net.USB_D_P" /> <target element="net.USB_D_N" /> </intent:targets> </intent> ``` But this probably deserves a separate thread.

an intent element is too generic- <trace decouplingTo="net.GND" decouplingFor="U1.pin2" /> is an example of capturing an intent. And there's <differentialpair /> which is a manual way of specifying pairs, then there's <connector standard="usb" /> which is more automatic

your language proposal above is over-abstracting which reduces the effectiveness of types, and the compaction of intent

it's the right idea to think in terms of intent however

Yeah, I'm thinking of this `<intent` more like a structured annotation for `<net` and `<trace`. For purposes of AI bug/feature reporting it means a standardised way of capturing semantic intent and its mapping to different domain-specific propecrties/react components. This way you could define anything without thinking about how to implement it in specific tscircuit elements. I think it's natural progression: English -> Codified Intent -> tscricuit implementation -> circuitjson implementation. This could also help LLM to reason about version changes, as tscircuit evolves and defines more elements.

i guess, but it's actually less structured to have more generic names-

Is the package install not working for you?

Can't reproduce anymore, it was on https://tscircuit.com/editor