For sure, its amazing how many places you need to write down basically the same information today. EDA tool, SPICE, requirements pages, documentation. SPICE is definitely an exciting one, particularly as the model can be versioned along with the package with parametrized tests that will automatically run in CI.
I was a designer at a big company in my last job. Many of my colleagues shared the sentiment that the tools were trash, I think people just need an exciting future to rally around. I think being able to link across disciplines is super exciting also, firmware and hardware can be versioned along side eachother, no more checking schematics for pinouts and meetings about which pin which signal should be on, just put up a PR, have both hardware and FW teams review.
Worth adding, we have found much higher returns building tools to solve the problems that a visualizer would normally help you with in other ways. For example ERC checking and modular abstraction of circuits. Working at a 'block diagram' level is much more intuitive than at the net level in my experience.
We also think that there might be better and more interesting ways to view your data, for example maybe you want to just see all the power paths through your circuit, or investigate how a signal travels from your input to your adc through filters, protection etc. Often on big designs these things might be strewn across multiple sheets and a bit hard to follow.
Pretty similar in concept, a few important nuances that come with building boards in the real world. For example dealing with tolerances. The language is definitely an important part of this, but we think alot of the surrounding infrastructure like package managers, CI pipelines and SPICE integration will be critical also.
We have been working on an optimizer for solving components that we will put a post out about soon. But the gist is figuring out which constraints are expensive, for example a precision inductor might be quite expensive, but a precision resistor is comparatively cheap. We can look at where to shift precision in your components to get the desired output for the lowest total cost. We already do a few things like prioritize in stock parts with high availability. I am excited to add more constraints, like board area, multi-sourcing etc.
For sure the goal! Our current component tool will find components that are available on JLC, in stock and to your spec, no more looking for resistor part numbers. The layout side is going to be exciting, we are just scratching the surface there.
We have some basic component parameters that we can define, like value, dielectric and voltage rating for capacitors. I think these become much more powerful once we add in equations to help relate these values and link them together. For example if I configure my powersupply for a 12V input, the tool should know that the capacitors need 12V * some safety factor of rating.
I think I see the entry point for auto routing to be taking advantage of the fact that layers have become pretty cheap (atleast for prototyping) and engineering time is the expensive bit. If the tool can help me layout a board in half the time, particularly for test hardware or the likes, that would be huge. Eventually I think we will get to a place where computers will do a better job of layout than most people, but thats a ways off.
I bet you do ;) We are fully opensource today, but we will eventually have some features we sell to enterprise. We have a small community of mostly friends at the moment, we are hoping to grow that very soon now that we have something we believe is worth sharing!
For sure, its a big benefit of using language, it is comparatively very fast and easy to define custom relationships of component values, trace widths etc that would quickly become untenable in a point and click tool. We think the path forward is to be able to encode the governing equations that you would get in say a buck controllers data sheet directly into our source code. That way from a user perspective you can define your circuit simply by importing modules, defining them (for example input voltage, output voltage and current) we can then solve the component values and pick them from our component database for you. One of our early users wrote a plugin to do LED arrays in an afternoon. Our compiler is all open so its pretty easy to add on custom scripts for whatever you might be wanting to do.
Specifically on the layout section, I have been thinking along the lines of start with sensible 'seed' layouts that users will contribute, then mutate the layouts with a physics driven solver. Imagine links between components as a spring and repulsion forces to model creepage/clearance distances, you could imagine the layout warping into a suitable shape for your board. I am pretty excited to get to this bit.
We are taking the open-source route (eventually moving to open-core). We think a big part of moving the industry in this direction is building a community around it, much like the way Github started out.
Indeed, the ability to branch and merge is a pretty exciting concept for me as a hardware designer. Another simple one is building artifacts in CI and doing quality checks, I have make some silly manual errors that have been very expensive during export.
Indeed, Altium has similar features also. I think what has been missing is an effective way to collaborate on hardware projects as a community and be able to share them like you would packages on pypi or npm.
I have noticed a huge improvement in ChatGPTs coding abilities having an interpreter to check its work. I expect we will be able to bring a similar feedback loop to hardware once we can integrate things like simulation and equations. Also having modules that are tricky to configure incorrectly.
For sure, we are starting with the schematic/requirements side of things and will push in the layout direction soon. We have started with some simple layout snippet reuse that is available today. My experience with autorouters is they do not have a good understanding of the problem, we hope to improve that by being able to capture more information about the circuit, for example physical values like voltage and current are captured today.
Our goal generally is to automate tasks that are boring/repetitive like multi-day reviews of big schematics to see if anything accidentally changed. Definitely building a lever for EEs, not a replacement.
For sure, we definitely subscribe to works out of the box / path most taken. We have been working on adding equations to our language so we can solve component values based on requirements like output current and ripple for a regulator to get cap values for example. I hope in the future our component models will capture a good fraction of the info you have to go to the datasheet for today.
We do have interfaces! They are super useful, I am very stoked that I dont have to remember which way around MISO/MOSI go any more.
Interfaces are just a collection of signals eg
interface I2C:
signal sda
signal scl
signal gnd
you can connect two together like so:
micro.i2c ~ sensor.i2c
Importing schematics would be possible, but IMO not super valuable as all we could import would be the raw connectivity, a big benefit of our language is being able to add a layer of abstraction on that.