Timot05

agree with all of this. Though i'd say: since the language is mostly read by humans rather than written, in my opinion, it makes even more sense to have a language syntax that actually matches intent. In the case of Machine Learning, it's mostly connecting functions together and acting on them, which matches functional syntax. LLMs are also already very effective at writing ML-inspired syntax (like ocaml or f#) as they have plenty of data to train on, making llms effective from day one if a similar syntax was chosen.

I’m relatively new to programming but I wish they had used a functional language syntax rather than an object oriented one as the basis for mojo.

From my experience, AI revolves a lot around building up function pipelines, computing their derivatives, and passing tons of data through them; which composability and higher order functions from functional programming make it a breeze to describe.

I also feel that other fields than AI are moving towards building up large functional pipelines to produce outputs, which would make mojo suitable for those fields as well. I’m building in the space of CAD for example and I’d love to use a “functional mojo” language.

Nice kickstand!

Skip to 6:22 for the action. Feedback is welcome. Thanks!

Honored to be there!

Thanks! And glad you are making your way towards electronics.

Yes, we hope for the packages.atopile.io to become a place where you can share your designs and explore what other people have built.

Pain might not have been the right word indeed. The aspect we wanted to point to was rather the fact that we had to do it over and over again. And so from that perspective it became a “pain”.

Ultimately we do love electronics. This is one of our attempts to contribute back to the field.

Thanks for sharing! We will have a look

Thanks for your detailed answer! Tons of information in there.

To your point about how the work gets divided, I don't think that work will necessarily be distributed amongst many people for a given design but code gives you a couple of benefits:

- you can branch and merge the changes you make, which means that you can design a given feature and have your team review only this change instead of reviewing a batch of changes.

- If someone actually does want to pickup your design and wants to contribute to it, code makes it easier for them because more information is captured in the code, so they get a better sense of what the design requirements are.

To your last point, we don't really see the code becoming the documentation of the implementation of the module. Actually the goal is to do something similar to the IC space or the software space, where the code becomes the implementation of something but the documentation lives somewhere else, perhaps in a datasheet-like document. Currently the schematic forces you to have both the documentation and the implementation baked into the same document, which forces you to find a middle ground between adding information relevant to those two objectives.

Fully agree! We'd much rather be in a situation where criticism is consistently thrown at the project so we can further improve it rather than having positive feedback and the discussion just stopping there.

Thanks for sharing the docs! Our language is mostly declarative at the moment. There are some features we discussed that would be imperative and we might introduce them in future versions of the compiler.

Well designed schematics are great. Especially if you are sharing them with your team as documentation.

The point we would like to move towards is one where atopile enables you to generate high quality documentation about your design in a similar fashion to a datasheet but not entangling the documentation with the source design, which is what a schematic forces you to do. There are some features we'd want to build that could enable that like a visualizer for important parts of a schematic, a fan out view of the consumed interfaces around a chip, the results of a spice simulation...

Autorouting would for sure be a valuable tool to add to EEs toolchains. The reason we focused on the language first is because it is critical to provide high quality information to autorouter for them to do a good job. And achieving that with a schematic is tough, as it only captures part of the information required to doing a good job laying out the circuit. A bunch of information is currently implicit.

Thanks for sharing this blog post! Super cool to see how things were done early in the industry!

Counterintuitively, I do agree with your points. We didn't end up designing the ato language because we actively wanted to end up there but rather because we tried everything else before and none of the solutions we tried worked out.

The problem we wanted to solve was: "how does git look like in hardware?". Another way to phrase it is: "How can groups of people coordinate and share their work in hardware?".

The first solution was simply to put KiCAD on GitLab. That solves the version control part of the problem but doesn't solve consistency of design outputs, coordination and reuse problems. The we tried to add automation on top (namely with KiBOT) to generate manufacturing outputs automatically. That was pretty cool for consistency of manufacturing outputs but it didn't solve the coordination and sharing aspect of the problem. And so at that point we kind of had ran out of ideas of things to try. And that's when we started developing the ato language.

Schematics are definitely a great medium to share a design with your peers. But we've found that for those other aspects I mentioned, code is more suited.

Thanks!

I do think that is fair. The reason that we don't have a visualizer is not that we don't want one, but rather that the value to effort ratio is quite low (and really because the effort is high, not because of low value). I'm sure we'll get there at some point. But at the moment there are more pressing issues for the people who are ok dealing with no visualization (like typing, language server, equations etc...).

Yeah, I think we only allow import x from y for the minute. And because we don't have a language server yet, it wasn't obvious that it was an issue. That'll change soon when the server is up though!

From a security perspective, it does help that ato is not executable!

Great point. We'll change that soon! Especially true for interfaces too since modules might have tons of accessible interfaces and the language server could list them out for you.

Did you see the ESP32 in the package registry? https://packages.atopile.io

Aspects of the python lexer and parser implementation were borrowed from python, which is partly why we ended up here. I do agree though.

Hey everyone, if you want to see a complete project, please check out the Spin Servo Drive that Narayan designed: https://github.com/atopile/spin-servo-drive

It can be a good example of how to setup an ato project.

NetlistSVG is great yeah. We had a play with it. We had a visualizer in the compiler early on in the compiler implemented with JointJS. But it was a pain to maintain and difficult to get value out of.

I'm sure we will have some flavor of a visualizer in the compiler one day. But outputting a "normal" schematic doesn't seem like it's the right approach. We might actually end up with a bunch of different ways to "visualize" your circuit, each one optimized for a specific thing you are trying to achieve.

Hadn't thought about the BOM line one but that definitely makes sense. The implementation I linked is definitely math heavy but might actually not be the best idea. As you say, the cost functions has steps. For less than a given amount of components, random search might be suited. Past that point, we might use maths to constrain the problem and then search within that range.

We have equations at the top of our todo list and hope to get there soon :) Matt setup a roadmap here with things we want to work on: https://atopile.io/roadmap/

There are actually two steps to the design process:

- First, requirements. In ato, you define how your circuit is connected and the requirements for the components that sit within it. From there, we generate a netlist and a BOM.

- Second, the netlist is turned into an actual object during the layout operation. We use KiCAD's layout tool in our case. There are infinitely more dimensions in the real world than there are instructions in a computer. So we do need that second step to point the requirement to one implementation in the real world. But technically there could be a quasi infinite implementations that fit the requirements written in ato.

The manufacturing files are a combination of the ato output files, like the BOM and the KiCAD output files, like the gerbers.

Yeah the side by side thing makes sense. Especially for very low level or analog designs. But in some cases it wouldn't be desirable to show the whole circuit. Say you are dealing with a module that has been characterized and that you know works. In this case, using a language server or a linter that shows you available interfaces might be easier to use.

For the spice graphs, having a jupyter notebook-like interface would be great to document why your design looks the way it does.

If you have specific ideas or drawings of how this might look like, please send them over in our discord server :)

Had a play here for equations: https://github.com/atopile/atopile/blob/tim/equations/sandbo...

We do agree. We built an early version of a viewer in the project but later moved away from it because it wasn't good enough to interact with. We might come back to it with something that is more targeted at inspecting only sections of the circuit or provide a block diagram level representation. But we don't think that just outputting a schematic the way they look today is the right solution.

Oh yeah we did think about that. Would be cool to have an ato package for a keyboard! Or maybe a script that generates both the CAD (with OpenSCAD or similar) and the ato code would ne nice.

Thanks!

I do agree. Though it is interesting to try figure out why openscad (and similar projects) haven't become more prominent in the industry. It feels like some aspects about code to hardware have to be tweaked for it to become the standard way to design.