We’d wager that, if you’re reading Hackaday, you’ve looked at more than a few circuit diagrams in your day. Maybe you’ve even converted a few of them over to a PCB. It’s a workflow that, at this point, is well-understood. But as designs become more complex, the schematics are harder to create and maintain. That’s why Atopile wants to treat hardware design more like writing code.
We can see some real benefits to this but also some possible drawbacks. On the plus side, reusing chunks of PCB description should be easy. On the other hand, detecting certain errors on a schematic or PCB layout is easier than spotting them in code. Of course, there are probably types of errors that are easier to catch in code, too, so maybe that’s not a problem. Certainly, if you can spit out a schematic from your code, you could — potentially — have the best of both worlds.
Here’s an example circuit (from the documentation):
import Resistor from "generics/resistors.ato" module VoltageDivider: signal top signal out signal bottom r_top = new Resistor r_top.footprint = "R0402" r_top.value = 100kohm +/- 10% r_bottom = new Resistor r_bottom.footprint = "R0402" r_top.value = 200kohm +/- 10% top ~ r_top.p1; r_top.p2 ~ out out ~ r_bottom.p1; r_bottom.p2 ~ bottom
Then again, you can use Verilog-A or even Spice netlists to get the same effect (and those aren’t the only attempts at doing this). Will Atopile catch on? Maybe. Should it? Tell us what you think in the comments.
Software isn’t always readable, but it would be nice to see literate designs for hardware. This project reminded us a lot of SKIDL, but we haven’t seen any updates of that project for a bit.
It seems kinda counterproductive to go to a text based tools for something as traditionally visual as schematic capture. Images have always made more sense to me, than written text.
But then again, FPGAs do quite well with HDLs even though they’re describing gate arrangements.
An interesting tool nonetheless.
That seems akin to arguing against HTML because you prefer to read text and images laid out on a page. Ideally, code brings a standardized representation to something rather than everyone needing a bespoke solution. Browsers can exist because of web standards, and schematic tooling can improve if schematic representations can be standardized.
Having been a software developer and hardware engineer for 40 years, there is no way the same kind of creativity would be possible with text based PCB layout. When I’m trying to optimize a PCB, it’s a very visually oriented task. I can easily see possibilities for routing that would never be obvious using text. And trying to optimize trace routing using text sounds like an exhausting experience. I’m sure this solution will eventually find its problem to solve, but I don’t see myself doing much with it.
isn’t the text based only intended for schematics, not layout?
Counterproductive???
I’ve often thought about coding schematics while coding physical objects in OpenSCAD. Imagine parametric designs where the user can choose to include desired features or exclude others. Imagine a design that automatically adapts based on parts on hand.
I’m not 100% convinced this can be done well. Especially if one tries to go all the way with it, from code to PCB design. All those real world complications to consider, stray inductance and capacitance, coupling, etc…
But if it can be done it would be amazing! Imagine downloading a gadget as open-source code, filling out a parameters form, selecting features and maybe inputing inventory of parts on-hand too. Then pressing build and out comes a schematic, a PCB design and an STL for an enclosure. I can’t imagine a better, more productive future than that.
for some things like analog circutry schematic is probably more readable, but for things busses simply connecting digital interfaces the text based HDL could faster and more to the point
I wouldn’t really say that HDLs describe gate arrangements. They can but most of the time people write the logic, not gate arrangements.
It is common in HDLs to write what is basically a high level description of a state machine which the software then synthesises and implements into a configuration file for the FPGA.
Most people write in HDLs the behaviour they want and let the tools figure out how to do it in hardware and try and meet any timing constraints too.
Also in the majority of FPGAs there are not individual gates anyway, they are built up with Look Up Tables (LUTs) instead.
A language where you define a transfer function and it compiles a schematic would be interesting. A language where you hand code every component is like making a blueprint by editing a DXF in Notepad.
Indeed; this seems very much like solving the wrong problem.
It is a typical case of software guys trying to address a problem they don’t understand in order to sell you their SaaS solution.
That’s entirely unjustified, this is free software solving known problems in a slightly different way.
If you don’t like different that’s fine, but don’t lash out at people with unfounded accusations.
Amen
Pbthhh. What known problem is text based entry solving?
This seems analogous to using openscad or cadquery for modeling. It aligns well with the way some people think and work. It aligns poorly with the way that other people think and work.
It has strengths and weaknesses that are hard to articulate, but if you haven’t tried it you’re not qualified to dismiss it. If you have tried it, and it wasn’t for you, then you’re still not qualified to dismiss it on behalf of others.
Someone said the same think about CAD when it first appeared(nerds trying to take away our drafting table!). As someone who still does mostly analog I could say that the entire industry and hobby has been taken over by the software guys and their microcontrollers.
It’s one thing to complain about your workplace forcing a worse solution on you because one of C-Suites cousins is the publisher. But, acting like a passionate team of electronics enthusiasts volunteering to create a FOSS alternative to traditional layout are the evil out of touch suits is pretty rude IMO.
Never heard such a thing. Whom is this ‘someone’? Everybody around me, including engineers, technicians, and drafters all said (this was the 80s) that the new CAD systems were freaking cool. They all wanted a seat at the machine. By the mid/late 90s, there were a few tables remaining, mostly used as a platform to stack stuff.
I’ve yet to see the code monkeys “take over” anything with any measure of success without direction from hardware peoples.
I bet you’ll be surprised when you find out nobody’s selling you anything here. (It’s free!)
Regarding Free, many things are free but the devil is in the details while free, getting proper results quickly can be frustrating.
I have gone from drafted (or sketches) designs to ruby lith and 4x layout, drafting boards and light table, thru to final production items.
Using software like PCAD, EAGLE, or even MENTOR,
for schematics, net lists, spice modeling, PCB layout, and PCB / Panel test pin frame, we have come a long ways.
During the time I was selling CAD to / and training, never have I heard a request for a text method for schematics.
We have all run scripts in our various software platforms, even fiddled with cut and paste elements, most often just creating a mess. How many have ruined a gerber file by fiddling, resulting in a file that passed post testing and still cost money because of a missed “issue”.
I admit that I love creating software feature and function subroutines, which makes creating and or changing mainstream code by extensive use of those routines so very easy. That cut and paste method is great for HLL’s, however I can’t describe my circuit component by component with associated nets including various attributes, ON THE FLY. I can’t draft/design everything while entering it, I can block load sections from other designs, this is the better way to rapid design.
All in all I can’t fathom a way to Code up Schematics all or in part, after all CAD is ultimately VISUAL.
ChatGPT: here’s the transfer function, give me a schematic.
If you are satisfied with plausible looking but wrong you can probably get that today.
It could quite easily be compared to HDL. At the start the synthesis tools were basic or non existent, you had to program it all manually but then as synthesis tools got better they can do more and more like describing a state machine at a high level and it figures out how to implement it in the available hardware. Now for most things you can just describe what you want the system to do and it will deal with all the details of the actual hardware implementation which is much more useful and more productive than having to do it all manually.
Given that good HDL synthesis tools already exist it maybe wouldn’t be too difficult to take inspiration from them to create the sort of tool you suggest, where you tell it what the circuit needs to do and it figures out how to actually do it.
I do agree that manually programming each component isn’t very useful. Circuits are drawn like they are for a reason, so that they are easy to understand, it is much harder to understand if it is just some code. Code is good for some things, like normal programming where it is essentially a sequential list of instructions or for describing complex high level logic that would be difficult to draw out, like with HDLs, but schematics are the way they are because it is easiest to understand them that way, mostly because it is physical components being described in the schematic. PCB design is also a very visual task and I can’t see how writing code would make PCB design faster or better. It is also very individual to each circuit and it’s constraints, it is quite difficult to take a piece of a PCB from one design and just reuse it in another, not because of the tools but because of the nature of PCB design.
For this to really take off it needs to be a lot more advanced than it is now, with tools that can make the schematic from a description and then arrange the components on a PCB and auto route them properly as well.
Hopefully it can become the OpenSCAD/cadquery of schematic capture. Really, schematic capture has analog operations to CSG. The set operations occur over the symbolic (pre-numeric) reference designator space as well. Add an operation to break signal/pin connections. Also need loops/arrays to do multiple of common blocks.
“the set operations occur over the symbolic (pre-numeric) reference designator space”
I understand each of the individual words, but…
:-)
You get a spaceship out the other end.
Fair assessment. Reference designators are the little combinations of numbers and letters printed on a PCB to identify each component. Instead of hard numbers, the atopile code uses variables (symbols) , such as r_top, to identify these components before compiling a netlist. Set construction/manipulations operations would occur on the designators, signals etc at the pre-compilation phase.
The benefits of this approach is modularity — you end up designing things by gluing high-level functional components together, rather than fiddling with individual resistors; this makes it similar to the way FPGA logic is designed. That makes a lot of sense for a lot of applications, especially if the functional components are correctly annotated so that the input/output couplings are generated correctly. Like, being able to mix and match 5V and 3.3V components and have it automatically do level shifting would be great for some applications.
The biggest missing feature IMO is that it just exports netlists to kicad, where you have to route it manually. For me this is always the hardest part of any electronics project.
I’m OK with this because KiCad can potentially autoroute. I haven’t tried it in KiCad 7 yet but FreeRouting is a plugin again. Although it is getting to be quite a software stack if I need Python for Atopile, KiCad standalone, and Java for FreeRouting.
Very good point. I haven’t watched the video yet, so I didn’t realize this was only the circuit side. For me that’s the easy part. The routing is definitely the harder part and the part I thought this software was for. Clearly I was not paying attention. The modularity and mix and matching sounds great. Being able to slap bigger blocks together is definitely a boon. I may have to give it a try. I definitely prefer OpenSCAD to most GUI 3D CADs, so it might end up similarly here. Thanks for your thoughts.
The subject itself is interesting, translating code into schematic can be useful especially for hierarchical projects.
Anyway it seems to me that such a language still exists and it’s named SPICE, what is the advantage of this one, a more user friendly syntax?
So the “dropping a regulator circuit into the circuit” portion… cool, but it’s exactly the same as circuit snippets seen in Altium (and other similar packages with similar functionality), and that took a number of lines of code to accomplish the task. In short, this seems like a win for the visual aspect of schematics. Are there potential benefits to certain operations defined by text? I imagine there would be… but that wasn’t one of them.
One of the YT commenters thought it was neat to auto-insert the git code hash directly onto the silk. Yep, I can do that in Altium, too, with the hash of the PCB file check-in (or with the hash of the schematic check-in). I guess it seems unique if you didn’t know other packages already supported the functionality.
And before people start screaming “But Altium is a $10k package, yadda yadda yadda…”, I’m simply using it as an example. Other packages offer similar options, just in different ways. Can Atopile be useful? Possibly… but the video didn’t show a good example, and we kind of need one of those to give a thumbs up.
The embedded video is just a demo project, not a detailed application to be used in an industrial workflow. Also “Altium and other options have similar features” is no more a negative for Atopile than it is for Altium.
“The embedded video is just a demo project, not a detailed application to be used in an industrial workflow.”
I get that… but show us a demo project that shows Atopile achieving a task in a more efficient way. Dropping a regulator into a project by way of several lines of code isn’t one of those ways. In nearly any ED package (Altium, KiCAD, etc.) someone can create a schematic file with various regulator schematic snippets… open it up, select the desired snippet, copy/paste into your new design. Done.
I didn’t say it was (necessarily) a negative for Atopile, I simply pointed out that it’s not adding functionality in a more efficient manner. And if efficiency isn’t improved (or worse, reduced), there needs to be an obvious advantage in some other fashion… I’m unable to see any yet.
Since I don’t have $10k to spend on Altium, I guess that now gives me the same level of functionality that you have.
For me, that is an obvious upside to using it. And while there are “other packages” like you say, atopile sits on the same level as them. We can swap those out as we need in this example.
“And before people start screaming “But Altium is a $10k package, yadda yadda yadda…”, I’m simply using it as an example. Other packages offer similar options, just in different ways. ”
That’s just handwaving if you don’t list at least one alternative package.
It would be interesting if it used the code as input to actually render a schematic. Maybe with some metadata (schematic style, some hints about what should be grouped together, and what is the main flow).
Most comments here seem to be missing the point. So many mentioning other text formats with editors. and arguing the “GUI is better”. Take HTML as one example. Yes, layout graphically is so much easier….until you have a tedious task of click and drag repeatedly, in a form better done by a for loop. (Or an unrolled for loop with copy and paste of text). In the case of schematics, there is a lot of repetitive clicking and dragging that could be automated. There are some signals where visually seeing the data flow is beneficial. So why not allow a WYSIWYG schematic editor. So we have a text programming language and a gui render. (Or you could continue using just one).
So often people use the conjunction or when they should be using the conjuction and. code AND gui editor. Why limit yourself with OR?
Reading the example ‘circuit’ I would say there’s an error in it. Line 14 is redefining r_top.value. This will be hard to spot in a big coded ‘circuit’, but (I guess) beter to spot in a ‘real’ circuit.
Yup. Typical “copy and paste” error.
It should have been:
r_bottom.value = 200kohm +/- 10%
Well spotted! The toolchain should catch the fact that r_bottom.value was not initialized and is likely to complain when R_top.value is changed. I assume that Resistor.value is assumed constant.
As a counterexample, wires that touch but do not connect (when they should) can be troublesome in graphical in schematic capture tools. Again, there is some hope that the tool will complain.
Or connect when they should have crossed – I have had that one.
I liked the idea behind SKiDL and this looks like pretty much a clone of it. I did play with it for a few hours long ago, but for the sort of schematics I make it does not make much sense to use it. SKiDL (and atopile I guess) makes sense for only a limited range of projects. I can understand it being useful for FPGA stuff, especially if it can read pin names from the FPGA synthesis tools, so pins can be remapped to other locations flawlessly (for example for easier PCB layout) by just changing the pin assignment in the FPGA tools and recompiling the whole shebang. It is also useful for circuits with a lot of repetition, such as for example a LED array.
One thing I found lacking in SKiDL was the inability to combine a “classic” schematic with it. This would allow to combine the strengths of both the readability of the schematic, with the flexibility of the text based approach.
Often is is also “more fun” to make something new, according to your own ideas, then to cooperate and build upon and extend existing ideas. I have not looked into details of atopile, but I guess it’s so much alike SKiDL that I wonder why it’s a separate project (except for “just because I can”.)
Atopile also seems to use it’s own libraries and database system. KiCad has some respectable libraries (20.000 schematic symbols or thereabouts) KiCad also has an interface to integrate with database driven libraries. Having to duplicate the library parts just to work with atopile is a significant obstacle for getting started with atopile.
And also, why does it need python 3.11? My Linux box has Python 3.8.10 installed and I feel no incentive to fiddle with that just for atopile. I was interested in Python a whole lot of years ago, but that got pretty much flushed down the drain because of the humongous clusterfuck between python V2 and V3, and also it’s abuse of whitespace.
I also wonder what the difference to SKiDL was. IIRC SKiDL even has the ability to (somewhat) render the schematic to a traditional diagram…
Yes Python versioning is still whack, and I feel like it won’t get better in the future as developers depend on dependencies which get version-locked. I have 1 installed version as the default and several program-specific versions. I use PyEnv to manage which version I’m using.
This would be good for complex pinouts. As it is, it can be confusing to check up and down the list of pins and their names, and relate them to each other. It gets harder when there are conditional connections (eg. ssd1306).
It could help out a lot if datasheets came with a program table with conditional connections that you could just copy/paste into a schematic editor. That could be a good convention to start following
That’s a good idea, and it could be picked up by an open source group easily. Just make a database of volunteer contributed parts. Anything I coded out I would happily share with others to save them some time.
I believe some aspects of design is better done graphically while others probably benefit from the code (or at least textual) approach. What I would like to see is KiCad supporting text input for some repetitive parts like connecting busses that benefits little from a graphical view, while still using schematics for things where signal flow and familiar circuit elements needs to be shown.
KiCad has the [Ins] key with auto increment for labels and this speeds up adding all the labels for an address or data bus significantly. The [Ins] key also works for other repetitive tasks. For example draw a horizontal wire, and then repeat the [Ins] key to make a bunch of horizontal wires (then add labels with the same method). This works quite nice, and it is a function you also rarely see in tutorials. Copy & Paste also helps a lot. For example, it’s easy to copy (or duplicate with [Ctrl + D] a block of a bunch of wires together with labels and bus entries, and then mirror and/or rotate them before final placement. In general, you rarely have to enter a (block of) labels / bus entries more then once.
KiCad-Nightly (soon to become KiCad V8) also has “pin helpers” which can derive label names from pin names and this is also a productivity boost. https://forum.kicad.info/t/post-v7-new-features-and-development-news/40144/31
I’m so torn on this one. I love the idea but I don’t wanna use it. I wrote an entire freaking phone case generator in OpenSCAD, so I get it, modularity is useful. But I’m struggling with the end-to-end PCB design and manufacture (it’s just a USB gamepad) and I don’t want to complicate it more with Atopile. If I had more electronic skills then I would try because I certainly did think about modular PCB design – supporting different models of ATmega32U4, swapping ATmega with ATtiny+VUSB, adding a USB hub or not, etc. But I think the phone case generator was enough feature creep for one project
You have a point, and it’s based on one’s level of expertise/needs. A gamepad one off isn’t what this is for. It seems to me that it’s for people who make lots of things and want to reuse work while doing so programmatically.
Where do I go to learn about or get the code explained to me. Looking at the code example in this article makes absolutely no sense to me. Thank you in advance for any and all help.
I’m hesitant on replacing schematics with code.
I’m used to handing over a standardized schematic drawn with lines and labels to many people involved. Not just in the development phase, but also for testing, manufacturing, and years later for servicing and such. A non-editable pdf of the schematic is the reference everybody knows how to use.
Referencing some online service that might not even be there in 5 years any more? Nah
However, a standard format for exchanging of schematic blueprints? That would be nice! Go to an application note and copy a reference schematic with proper symbols and import this into my design software? That could save me a few minutes once a year…
Looks neat. I’ve tinkered with Verilog for FPGA development, and this does feel similar to that. I’d be interested to know how Atopile will position itself differently from other attempts of this concept.
In particular, what is the target audience? Most hobbyists or designers of small circuits are familiar with the GUI, and probably don’t care enough to switch. I’d expect that most large engineering firms are already set in their ways. I mostly see this appealing to people with a software background, like me.
Text-based interfaces do have some advantages over GUI (and vice-versa), but I’m skeptical about how much value I’d get out of those advantages for most of the PCB designs that I’ve done as a hobbyist. About the only part of a circuit that I’ve ever considered reusing on a different board is a switching regulator circuit, and even then the requirements are often different enough to mandate not only different components, but entirely different circuit schematics (i.e. a different kind of feedback network).
Modules would be helpful to have multiple instantiations of sub-sections of your circuit, like an array of relays. Maybe I’ll give Atopile a shot on my next project which has something along those lines.
Looking into this a bit more, the component search based on tolerances seems darn handy! Now, can you integrate that with the LCSC/DigiKey/Mouser parts library and limit to parts that are in stock? :-) I’ve spent hours doing that on larger designs, tweaking the design when parts aren’t in stock, and I would be very happy if I didn’t have to do it again.
I previously mentioned switching regulator designs, which is often where I have the tightest component specs with the most difficult parts search. Tools like TI WEBENCH do help here, but there’s likely a long road ahead for something like this project to get any kind of recognition from a TI tool or datasheet. But you might be able to take that concept and apply it to your own community.
If Atopile had an open source collection of easily searchable modules – things like what you find in TI WEBENCH – and these modules simplify schematic design and component selection that optimizes for in-stock parts, then that would really be something worth using.
I find the idea fascinating but the implementation counterproductive. It seems too verbose: Three lines to minimally implement a single passive component of the simplest fare?!
I bet if this was the standard way of making schematics, someone would have made a visual tool. This wouldn’t work for me because I’d likely still have to draw out the schematics. I write embedded C code, but I still plan out architecture, logic and flow visually.
The concept is good but it needs to be coupled with GUI-driven editing. What I mean is that modifying the text makes changes in the GUI and the changes in the GUI modifies the text.
Have this Atopile poeople ever see Altium!?
What about the speed of the design?
What about the price of the design?
For me this is wrong way.
The schematic design happen on another functional level, not on component description level.
Every hardware designer can tell this.
For what it’s worth, high-end chip design is sometimes done at multiple levels, one of which is is programming-language-like.
Gate-by-gate logic simulation for design testing is _expensive_. IBM, among others, solved this by having the first pass of the design done in a “cycle simulation” language that provides higher level descriptions of logic operations and data flow that could execute much more rapidly, testing those exhaustively, and then testing the actual circuit design by using a prover to confirm that the circuit-level designs were logically equivalent to the simulated solution. Timing and other dynamic simulations still had to be applied at the gate level, but this could still yield a huge improvement in development time. Much more so if the cycle-simulation model could be put through a circuit synthesizer and “compiled” to a hardware design, though when I was doing this that was rarely as efficient in gate-count as a hand-designed chip.
(In the 1980’s, IBM had a remarkably complete set of design tools. Unfortunately most of them needed adapters to talk to each other, and the user interfaces on some of them absolutely stank. BDL/CS had serious mixed metaphor problems to begin with; the insistence on then trying to edit this parallel-execution CS language as sequential programming flow charts rather than schematics made it worse. Great ideas, outdated and counterproductive implementations… They finally started trying to reinvent schematic capture to fix this (rather than starting with off the shelf tools), which was about when I moved back to the software side of the house )