We have indeed started with the schematic/requirements half of the problem. My experience in industry is there can be much more direct reuse/configuration in schematic as many boards might have similar features. Layout is typically quite bespoke as it will have mechanical constraints.
That said, we are absolutely looking to take on the layout section in the near future. We are starting with some augmentations of kicad, for example we just released a layout reuse feature, where component layouts can be captured and shared along with the ato code.
I think with few exceptions defining explicit layout choices in our language will be painful and not the right path (perhaps connector positions would be an exception). We have not put a huge amount of energy into this yet, but from some initial playing around, we believe capturing all the information that a person would use to judge a quality layout will be crucial. For example, current tools do not have concepts of current/voltage and definitely not transient behavior.
To get to actually good auto-layout that doesnt suck is going to be a slog for sure.
For sure, we found that to start with something useful from day 0 we needed to be able to completely represent any possible circuit. Starting by just providing a cleaner way to write out a netlist is just the beginning.
We are working to add an equations solver to our compiler over the next few weeks, which will allow you to do things like set the ratio of a divider and total resistance, then have the solver pick optimal values based on availability, cost etc.
I think that gets really exciting when you start to be able to link these together, its trivial from there to directly set the output voltage of a power supply in volts, which will internally configure the feedback resistor divider.
Also verified designs will be super important. Its a little crazy that the status quo is you will almost inevitably make a silly mistake on your first spin. I am imagining designers will go off, make a new circuit, build and test it then make a PR to merge it into main.
Get even a basic equation solver in there and I'll be a user! Have it handle units properly and I'll be a happy user. Have it be able to handle both worst-case and RSS tolerance stackups and I'll be in love.
Excited to hear it! Our language already captures tolerances and the solver we are building does proper tolerances stackups. You specify the desired output with a tolerance, eg my_regulator.power_out.voltage = 4.75V to 5.25V and we will solve the stack up to get you there.
If we can build the equation solver our hearts are set on, you should be able to account for as many factors as your design requires - albeit with some performance limitations at some point.
That is, assuming temperature can be factored into equations in the same manner as any other parameter or attribute
It's what underlies the geometric constraint solver which you don't need for what you're doing. It's probably worth a look under the hood. You might also read this post from Michael-F-Bryan implementing something similar in Rust:
I have found taking a 'functional programming' like approach, where you build up your circuit from small blocks with specific functions that are easy to hold in your mind and then building up by combining those. For example instead of sticking a bunch of resistors and caps in your top level file, you can abstract them into their functions like a filter, resistor divider etc. Very curious to get your thoughts on using the tool!
I am definitely curious for feedback from people after using it for a while. I felt the same in the beginning, but after writing a fair bit of it, I rarely find myself wanting it. I could imagine for more casual or new users it could be helpful at least for the transition.
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.
Exactly. A new level of modularity will be possible. Pretty incredible! Also parametric designs of modules (a function call with 3.3v vs 5v, or 8bit vs 12bit ADC) all the way down.
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.
That said, we are absolutely looking to take on the layout section in the near future. We are starting with some augmentations of kicad, for example we just released a layout reuse feature, where component layouts can be captured and shared along with the ato code.
I think with few exceptions defining explicit layout choices in our language will be painful and not the right path (perhaps connector positions would be an exception). We have not put a huge amount of energy into this yet, but from some initial playing around, we believe capturing all the information that a person would use to judge a quality layout will be crucial. For example, current tools do not have concepts of current/voltage and definitely not transient behavior.
To get to actually good auto-layout that doesnt suck is going to be a slog for sure.
Thanks!