This really consists of: (1) a "smart netlist" not dissimilar to Verilog, as an alternative of traditional graphics-based schematic capture (2) on top of it, automatic component selection (3) pre-defined bus types and topologies to simplify interconnection.
The value of #1 is debateable. For digital-heavy circuits, I do prefer text-based representation, but of course it depends on how terse it is. However when it comes to analog, the graphical representation is way more powerful, as it naturally reveals the topology of the circuit, while anything text-based obscures it by design. The schematic generated by the tool is nowhere close to human-readable, let alone modifyable (you aren't supposed to modify that anyway if the netlist is the source of truth), and AFAIK there has never been a drive to automate netlist-to-schematic, even with metadata annotation.
#2 sure is a bold proposal, and TBH I see it as the "core competency" of a schematic engineer --- something you cannot effectively automate out of. Even if you could, not sure real engineers would actually follow the, uh, "advice" from such tools. For smaller and commonly used things (passives, discrete semiconductors, building-block ICs) of course there is value, but arguably this is a feature, not a product. Then for bigger things that often dictate the rest of the design, just having a part handed to me is clearly not enough --- a good engineer needs to understand the multitude of trade-offs and provide justification on why a specific part / part group is chosen, more often than not based on part quantitative (maybe automate-able) and part qualitative (unlikely to be automated) measures.
#3 is where the money resides and synergizes with #1, although arguably tools like this (so-called pinout editor or configuration tool) had always been a first-party thing. Very useful for high pin count digital work. The database part of this needs to be hand-curated, but it only needs to scale as fast as the manufacturer can churn out new parts.
Also nit: It's almost always better to use an established general-purpose PL as the base, if programmability is the selling point. See Chisel, Bluespec, PCBDL, SKIDL, PyPCB, ... If you insist you can still build a symbolic representation like Tensorflow, but having to learn yet another esoteric PL is a really big barrier even for coding people.
1. Text based netlists are ok for digital heavy circuits like you said, and we agree the schematic is important (which is why we're generating one). It's hard, but quality of results is constantly improving. The schematic is modifiable by the way - we can keep human modifications to the aesthetics in lock step with the generator.
We do go a bit further than text based - the design code is parametric all the way through to low-level packages and symbols. It's not just typing out the same information that's in a schematic - it's about levels of hierarchical reuse that build on each other.
2. Right now we can do a good job automating the selection of parts that are fully defined by a set of parameters i.e. the jellybean parts like resistors, capacitors, inductors. Moderately useful by itself, but if this was the only part of JITX you used you may just be just saving yourself a few hours of digikey searching and spreadsheeting. The more interesting part is that it lets us write circuits that are more reusable. As designers, we key in the attributes that are important for the circuit and leave the rest of the constraints open for optimization.
We do more automated simulation and validation than I've seen in other tools, which helps with component selection (and other automated flows), and inspires a bit more confidence in the design than just saying 'here's your part, trust me'
I agree that guided design space exploration is the end game of automated component selection. We want people to have a conversation with the tool and rapidly evaluate 'what if' questions. It won't be fully automated and that's not our goal. We think tools can automate the low level work and leave the creative bits and the intangibles up to the humans.
On the programming language aspect - JITX is currently embedded in Stanza (the same language we wrote the compiler in). We use an Intermediate Representation for the language (like LLVM, or FIRRTL if you're familiar with Chisel), so other language front ends are possible. What would your top language pick be?
I didn't realize ".stanza" refers to http://lbstanza.org/index.html --- I had to google "stanza language -NLP" and even then it didn't show up on top!
Tons of respect to people writing practical programs in relatively esoteric PLs, but there's (of course) the usual negative aspect: PL people are unicorns (anecdote: exactly 1 PL guru among all my friends). In case you need to onboard more devs to scale up the effort, I'd imagine you actually need good luck and/or connections.
w.r.t. front-end language (for us mortals):
- Ruby, which makes way for a fluent syntactic feel without going all the way magic
- Python, for the absolute least friction
Considering the coding muscle of your even more enterprising fellow EEs (or lack thereof), I'd say KISS is your best bet.
Seriously though, routers should be something that has an open hardware option even if it doesn't hit gigabit speed.
Also see Tailscale.
Being able to use other libs, reuse language features and knowledge brings so much extra benefits.
I don’t know too many EEs that can code
And I don’t know that many software engineers either that know enough about electrical engineering to leverage this as part of their toolchain
It also seems like one way street? Like how do you go back and forth with PCB layouting?
For extremely large designs with a large number of pins on a bus, it's hard to validate all the pins line up correctly in a visual schematic. On a text file, it's really more like a data structure which can be easily validated.
See also skidl: https://pypi.org/project/skidl/
Or that like version control and whatnot. I have an EE degree equivalent (i.e. I am qualified for entry-level EE jobs) but have been a software dev my entire career -- if I wanted to branch into circuit / PCB design a tool like this would be the first one I'd look to, just like how I'd look toward OpenScad for mechanical design.
We haven't found programming skills to be a big blocker. You don't have to be an elite coder to use JITX. Most EEs have banged out a quick matlab or python script at some point, which is plenty of experience. We worked a lot on the semantics of the language to make it correspond to how EEs think about designs, which I beleive helps.
Not a one-way street -- you can flow designs back and forth between JITX and the CAD tools we support. It was hard for us to get working, but it is important. At least until we have all of PCB design fully automated.
Do we live in the same word? haha every EE I've worked with knows ho to program because it part of their training as an EE (which of course does not mean jquery or any other volatile webdev bs)
> And I don’t know that many software engineers
More often, since it's not a substantial chunk of their training
* Does it require a network connection to run?
* A quote from the demo video: "A different board is generated every time" - Is there a way to stabilize the output so the same input always generates the same exact design every time?
* The generated kicad PCB layout didn't match the output preview output in the demo video, and the FPGA was floating off the board. What happened there?
* Does this tool do auto-routing of traces?
- Running the same generator twice will produce the same design each time (but the design files will be generated afresh).
- Bug that is now fixed.
- We haven't released our autorouter yet because it is still in the early stages.