Am I understanding correctly, this is kind of like code generation (which is roughly a compiler that takes some sugared language and produces unsugared code that's usually incredibly ugly / indecipherable), but the input is some sugared language and the output is board designs?
Do the board designs you output look alien / weird to people who have been laying out boards by hand / with conventional EDA tools? If so, is it causing any resistance to JITX adoption?
A common creature comfort requirement for anything that transpiles / codegens, is source maps so that while debugging you can see the lines of code that you(r team) typed, rather than harder-to-read generated code. Have you thought of trying to bring that concept to JITX?
Code generation is a good analogy - nice high-level code in, CAD design out. The 'sugaring' is implemented in a macro system that generates an Intermediate representation we designed for electrical systems (kinda like LLVM for hardware).
JITX only produces weird-looking designs when they are provably correct and of high-performance. You can't throw an indecipherable mess to an EE and ask them to spend time understanding it. That's just not a productive way to design. There's a lot of work we do to make a design legible, including generating a schematic for the user to read.
Yes! Our 'source-maps' connect the generated design checks, board, and schematic back to the originating line of code. So the user sees the output they are familiar with (e.g. schematic), and can trace it back to the line of code it came from. Collaboration in a team happens more at the source-code level, and we make sure that the same CAD design gets generated when that code is run.
- Fully automated place and routing up to 3d PCB level, with constraints including locked item positions, orientations and board stackup. Most likely ML based and fairly quick and trained on a simulator that takes into account various design rules, realistic physics, etc . Zero input from a GUI.
- Datasheet semantics implemented directly into code / logic and rules checking and analog simulation
- Use typescript, jsx to create the simplest way to implement components and sub circuits. (I know this isn't going to happen)
- Use a cloud package manager so people can share thier sub circuits and ICs
Personal preference but I would say typescript because, performance is not overly a concern when doing something like infrastructure as code, great static type checking / development integration already provided when using something like vscode and lastly because it has jsx / tsx....And so why jsx, I know that designing a circuit is more akin to a graph data structure and jsx is really more suited to a tree data structure but if you can get over that by defining your nets separately up above the components in the jsx structure then I feel like you can really harness a lot of the benefits that jsx brings to regular UI design. Again this is personal and I've mucked about with this very thing a bit myself.
Im not familiar with pulling a github repo to get at a package, if it allows anybody to make their circuits publicly available, forkable, etc then all good..
BTW definitely wouldnt recommend jsx it for something like a digital design
/ verilog replacement. Hard for me to reason even to myself why I would treat that differently to discrete component domain...
I’m not an EE, but I’ve heard plenty of horror stories over the last 2 years where a component is unavailable and an entire new design needs to be configured with new available components only for the redux to take too long and components are unavailable again…
Can someone smarter than me tell me if jitx solves that problem?
Don't know that I'm at all smarter, but I have some domain knowledge. Yes, JITX makes it easier to source/design in replacement components and the circuits around them.
It's a major use cases these days with all the churn coming from supply chain volatility.
Founder here! JITX today is pretty tightly positioned at a group of professional folks that find it very valuable. We'll be opening up more fully later this year, and we'll relaunch then with some pretty jaw dropping stuff.
Is schematic entry where most of the effort and complexity is when doing board design? Will JITX address the layout part of the design pipeline as well down the line?
Well if you consider the entire design process, accelerating or automating just a portion of it would not be that useful, right? So that's about all we can say right now.
It's similar to VHDL in that Synposys came out with Design Compiler in the 80s, and people switched from drawing schematics to writing code to design electronics.
From a language perspective it's quite different. VHDL has super-limited semantics to make it easier to synthesize. JITX is embedded in a general purpose programming language, which makes it more productive to write, and capable of describing all the weird little details that need to be handled for board design.
Looks awesome and for sure will be the future. Most ECAD software has a circuit 'library' function you can design something once and use it many times so it's not completely fair to claim that's something really novel.
You are correct that most EDA platforms have a notion of a library but in the domain of PCB design, those libraries are usually limited to components (symbols/footprints). And there is very little verification that is done upon reuse. That's where we differ: design verification upon reuse with the judicious use of component properties written in the same code as the component itself. And reuse is now just copying text, and not having to worry about tool version compatibility for instance.
https://docs.jitx.com/tutorials/quickstart-1.html
https://docs.jitx.com/getting-started/example-design.html