JITX (YC S18) launches general availability and announces Series A from Sequoia | Hacker News Reader

JITX (YC S18) launches general availability and announces Series A from Sequoia

jitx.com

87 pointsDHaldane30 comments

We have some code examples, for anyone that wants to see what a software-driven design looks like!

https://docs.jitx.com/tutorials/quickstart-1.html

https://docs.jitx.com/getting-started/example-design.html

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?

Super interesting, thanks for posting this.

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.

Thanks, this is amazing work!

This is a really technologically interesting problem to solve, congrats!

The GitHub analogy is particularly captivating.

The potential for applying code re-use and other programming principles in hardware could create a 'Cambrian explosion' of activity there.

I'll be monitoring this with some excitement!

Hoping for the following:

- 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

- Interactive heirarcical schematic

Generally in agreement, but two minor questions:

> Use typescript, jsx to create the simplest way to implement components and sub circuits. (I know this isn't going to happen)

I can see why not many people would be willing the learn a new language from JITX (stanza?), but why typescript/jsx instead of python?

> Use a cloud package manager so people can share thier sub circuits and ICs

Why not just a github repository? Kind of like https://github.com/NixOS/nixpkgs

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.

JITX (and the general idea of schematics / PCB generators) is one of big challengers to the way hardware is designed.

I hope they succeed. They easier it is to make new hardware, the more competition is, the better products we get as consumers.

This looks really cool, and I would love to try it out on a hobby project before considering it for something more serious.

Are you planning to make some kind of "hobby" tier below the startup pricing at a later date?

We are - there will be a free offering for hobbyists soon.

I keep wanting to try this out, but man do they put up road blocks. Skidl + kicad cover the programatic schematic entry part kind of.

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.

Launch HN: JITX (YC S18) – Automating Circuit Board Design - https://news.ycombinator.com/item?id=17654865 - July 2018 (54 comments)

Looks super cool to bad no remote roles

You know an idea is great when it makes you say, “How didn’t I think of it!”

Godspeed JITX

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.

This looks super cool! Congrats on GA

Not sure why but I seem to be unable to share your website on facebook messenger. Maybe it mistakenly ended up on a blacklist?

Extending your Github analogy, do you see a future Copilot type of generative AI for circuit boards?

How does this differ from VHDL? Is it in principle something different?

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.

Nice work, congrats!

Like CDK for circuit boards, sounds pretty cool.

I will be monitoring this and hope they succeed.

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.

Reply on news.ycombinator.com