- Some features (like the part solver) use some cloud services that you need to be on the internet to use. Most of the software runs on your local machine

- 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.

What would your top pick for a front end language be?

Thanks!

Our customers are electrical engineers -- electrical engineers on small teams that need to move faster with fewer errors, all the way up to senior EEs with a few decades of experience who want to automate design validation to ensure consistent quality.

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.

We can do both automated and programmatic layout. So you can add in hard placement constraints for location critical parts, then leave the rest to the optimization engine.

This is on the roadmap - we're big believers in automated design validation and we are certainly not stopping with schematic-level checks.

Hello - I'm one of the co-founders. Solid analysis! I'd say that we're better at building tools than websites so I'll add some extra information here.

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?

This is still true for all off the shelf autorouters.

Great to see this project go public! Seems pretty good if your requirements fit inside the spec.

$949 is a decent chunk of change, but it is half of what the very similar Geppetto service costs and Sparkfun seems willing to also sell you the native CAD files (for an extra $150).

Very curious to see how much real use this will get.

They just wrapped up Phase 1 of IDEA and POSH; programs that were explicitly trying to bring FOSS to hardware. There are now open-source end-to-end automated flows for RTL to GDS like OpenRoad.

JITX (YCS18) was funded under IDEA to automate circuit board design, and we're now celebrating our first users.

Great program.

I don't know that hardware is inherently more complex than software.

The issue I see in hardware is that all complexity is handled manually by humans. Historically there has been very little capacity in EDA tools for the software-like abstraction and reuse which would allow us to handle complexity more gracefully.

Good point and nice estimation! Measured bits/spike (e.g. in cricket sensory neurons) tops out at 3.2 bits/spike [1]. Most sensory neurons across all species top out at ~300 bits/second.

So if we assume a similar bit rate for spine neurons, we get 7.5 GBps, not 16.625 GBps.

[1] : https://www.nature.com/articles/nn1199_947

JITX | Algorithmics Software Engineer | Berkeley | Full-Time | www.jitx.com

The vision of JITX (YCS18) is to fully automate hardware design to advance science and the welfare of humanity. Our first step is to automate circuit board design. We are a profitable seed-stage startup, backed by Y Combinator and Sequoia.

We are looking for a brilliant algorithmics software engineer. You will be working together with a world-class team of electrical and software engineers to tackle real-world algorithmics problems. The ideal candidate is a creative problem-solver and excellent programmer, capable of breaking down a large complex problem into approachable sub-problems and writing high-quality code to solve each one.

Ideal qualifications:

- Experience designing algorithms to solve real-world problems

- Knowledge of advanced data structures, graph algorithms, solid geometry algorithms

- Experience with problem formulation using SAT/SMT/LP solvers, as numerical optimization (e.g. conjugate gradients, Lagrange multipliers), and as machine learning tasks

- Experience with programming language implementation (e.g. abstract syntax trees, intermediate representations)

- Writes clear, well-organized, maintainable, and efficient code

Here are some examples of algorithms that you'll be working on:

- Routing-aware placement algorithms

- Pattern recognition and automatic generation of human-readable schematics

- Massive design space exploration for cost, area, and power

- Cost-function approximation and learning heuristics for expensive objective functions

- Electrical and manufacturing verification and validation

We’re building the tool engineers have wanted for a long time. Come help us do it.

Apply here: workwithus@jitx.com

Curiosity is always good, and thanks for the compliments. Responses to your questions in order:

- We follow DFM/DFX very well. It's a strength of an automated system that you can make strong guarantees on the designs that come out of the tool. A board design that cannot be manufactured is useless, and our boards are guaranteed manufacturable.

- We rarely follow explicit layout guidelines, and instead determine electrical constraints and solve for a design that meets them. The switching regulator layout in the data sheet rarely fits well in any given floorplan. Better to make sure the physics are right than to encode rigid (and potentially arbitrary) constraints.

- See above. We don't copy/paste - we solve for the layout that fits, subject to electrical constraints.

- More of a lack of user constraints. Space makes good neighbours of electrical components, and makes testing/characterization easier. When size isn't critical, the optimal design is more spaced out.

- Layout is deterministic, and board revs are pretty smooth when all you have to do is edit the source code.

We're not looking for an acquisition. Luckily for you, we don't have to be acquired by Altium to write a plugin for their tool. Our competition are electrical engineers grinding out work that they don't want to be doing anyway.

Sorry, should have addressed that directly. We haven't run a job with memory routing through the tool.

Your point about DRAM is well taken, and we'll hopefully have a job justifying that bring-up soon.

This automates what you would normally do in KiCAD (and more). We export to KiCAD, because it's a convenient way to view and edit the design.

The autorouter we use is on par with what you find in Altium. The one part that makes it actually work where most autorouters breakdown is the guidance and handholding our software can do automatically.

Yes it allows placements for whatever you care about. Specify a placement if you care about it, don't specify it, and the system finds the best place for the part.

DDR4 is an example case that's just not well automated yet. We've got the road map sketched out but it hasn't been a priority.

We're optimizing our development for features that make us immediately more productive at designing boards. Thus far that has been things like solvers for power supplies and automated component selection. The special case stuff will come later, when it becomes a bottleneck.

I wonder how future engineers work will look like

Here's hoping it looks like software development. I want engineers to capture their expertise in code so that everyone will be able to benefit.

Thanks! Yeah, we've been designing fixtures like that and have built some specialized automation to do so.

The fixture design can also be co-generated when we design a PCB in our system.