Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Atopile – Design circuit boards with code

news.ycombinator.com

Post reply on HN
Print view View original

201–210 of 300 posts

Re: Show HN: Atopile – Design circuit boards with code

#201

Post by mawildoer »

vrinsd wrote: post #197

At the risk of sounding pretty negative to someone who wants to make the world of EDA better, this really seems like a re-discovery of a text netlist with the idea of making it 'easier' to create schematics but I feel like it's DOA for anything non-trivial. Most PCB tools have the user create the schematics graphically, but the actual 'design' is usually a text netlist already or the tools let you export the netlist…

We're largely on board with the same problem's we're trying to tackle, and I most certainly understand why you're making these criticisms of these trivial examples and our current implementation. You're right to - these simple designs aren't where designing PCBAs with code will shine (we expect!).

Currently when you discuss configuring a regulator, it's beholden upon the designer to understand enough of the internals to configure it because, in our opinion, schematics aren't well suited to designing things that are configurable and plastic - either in topological terms, or in their parameters. Our hope isn't to abstract this complexity directly by using code, but rather because code allows the workflow itself to change, for a well tested and trusted configurable block to completely abstract the internals such that a designer can forget about it (like a tested piece of code). We want to bring configurability on this "trusted" scale in from the physical world of modules to the world of highly descriptive code. It's a tall order, I'll indeed admit!

It's also well worth nothing that while at the moment we're running lean on the visualisations, we do agree they're an extremely potent tool to convey the topology of a design at a glance. We expect we'll be adding a visualiser which should be used to gain familiarity with a circuit, diff it for review and understand it from a system level (by viewing topology by interface type etc...) - unlike current schematics that implicitly hold so much content via the positioning of components.

Thanks for the detailed comment!

Re: Show HN: Atopile – Design circuit boards with code

#202

Post by robomartin »

tubetime wrote: post #191
robomartin wrote: post #188

@Timot05 I wish you the best. Among other things, you are reinventing Verilog and other attempts. Yet, of course, evolution does not happen without people who are willing to devote their valuable time and effort to consider new ideas. My personal perspective, after having designed hundreds of PCB's, is that there's a reason for which symbol-based data entry has survived decades of computer-based circuit design evolut…

This is the most useful comment in the thread (so far)! This product would not work at all for any analog or power designs--EEs like to visualize current flow and a schematic is the best way to do that. Maybe if it could interoperate with small blocks of schematics, treating them as modules, it could be useful. If there was a way to parameterize part values, like those used to build analog filters, that could also be…

> The one thing it could be useful for is creating net connectivity for large numbers of pin to pin connections, like DDR memory or PCIe buses. Schematics for these end up looking like large data tables anyway, and can be tedious to create and prone to errors.

This is a good example. I'll expand it to include such things as breaking up the symbols for a large FPGA (say, over 1000 pins) into multiple schematic blocks and managing them as the schematic design progresses. Very often you have to move pins around within the same block or between blocks just to arrange them logically or align them with whatever they might connect to.

For example, take the output of an FPGA bank and connect it to the input of an HDMI transmitter chip. You would want to align the red, green, blue, clock and control pins so that you can connect them with a bus that looks right. If someone reading this isn't clear, imaging arranging the pins on each device in random order where, for example, the first chip has R0,B8,R1,G5 and the second chip is R0,R1,R2, etc.

This kind of thing is tedious and painful.

The way we solve the problem with Altium was to write code that allows us to fully define an FPGA (and other IC's) using data entry in Excel. One turn of the crank creates all symbols and PCB patterns and exports into the libraries. This took something that was a days-long torture to maybe 45 minutes of work. After that, if you need to move pins around, it takes minutes to update everything.

This is also an example of why a text file based approach would not be as useful. Entering data in Excel is very easy. Editing it is just as easy. In some cases you can even copy and paste from datasheets and easily edit or rearrange. I can also write formulas to generate sequences of pins, etc.

Having to manage this in a text file would not be as slick. Over the years, I have found that Excel, coupled with VBA code, is a very powerful tool for schematic entry and PCB design.

Re: Show HN: Atopile – Design circuit boards with code

#203

Post by mawildoer »

AnyTimeTraveler wrote: post #199

This reminds me of writing VHDL in the Sigasi IDE. You could write the description for a component, have it's syntax checked and get autocomplete while typing and once you were done, you could click a button and see an overview of your component and how its signals were connected to other components, kind of like a schematic. It helped me learn and find bugs quickly and I was really missing that when I got started wi…

Thank you!! That's just about the workflow as where we lie today - albeit without the full suite of potency we're working towards.

I haven't actually used Onshape, so I'm not intimately familiar with their constraints system. Thank you for the recommendation, I'll have to check it out for some hints.

Re: Show HN: Atopile – Design circuit boards with code

#204

Post by robomartin »

napowderly wrote: post #190
robomartin wrote: post #188

@Timot05 I wish you the best. Among other things, you are reinventing Verilog and other attempts. Yet, of course, evolution does not happen without people who are willing to devote their valuable time and effort to consider new ideas. My personal perspective, after having designed hundreds of PCB's, is that there's a reason for which symbol-based data entry has survived decades of computer-based circuit design evolut…

I am curious to hear that you dont see any value in bringing software workflow to hardware. I found in previous jobs we spent a huge fraction of our time dealing with things like release, version management and reviews. Thanks for your thoughts!

Here's something that has been true for decades: Storage is cheap and always getting cheaper.

When you are dealing with complex multidisciplinary designs (a full machine), the concept or a release takes-on a very different meaning.

Scenario: You update a single circuit board, or the code that runs on a single microprocessor.

The release descriptor for the product, the machine, must include every single element that goes into making that machine. If all you do is commit the software update to Git, you very well run a chance to create a very serious problem for manufacturing, qualification, testing and post-sales support.

It has been my experience that, because storage is cheap, a release due to any change is a full annotated copy of all design files for the entire design; electrical, firmware, software, mechanical, testing, manufacturing, etc. In some cases we've had to save entire virtual machines with working code because workstation and system software can mutate and things break. We recently had a case where a Windows 10 automatic update (don't get me started) broke code that used to work in a last month's Windows version.

If we accept that storage is cheap, then the concept of releases at the product level, are simple copies along with a set of relevant "readme" files describing release details. You can come back to this three years later and all is well.

In the era of little Arduino boards it is sometimes easier that, more often than not, electronics don't exist just for the sake of electronics but rather as part of a much larger, and often far more complex, multidisciplinary product. In that context, schematic entry is an insignificant burden. The same is true of hyperventilating about what code editor to use. Some of these things are truly rounding errors in the product life cycle.

Re: Show HN: Atopile – Design circuit boards with code

#206

Post by al2o3cr »

IMO it's hard to spot the "holes" for parameters in a module - for instance, in the logic-card project the instantiations of "LDOReg" end up setting values of objects in "Vdiv" two abstraction layers down.

https://github.com/Timot05/logic-card/blob/a63581636233dd1f9...

Re: Show HN: Atopile – Design circuit boards with code

#207

Post by mawildoer »

al2o3cr wrote: post #206

IMO it's hard to spot the "holes" for parameters in a module - for instance, in the logic-card project the instantiations of "LDOReg" end up setting values of objects in "Vdiv" two abstraction layers down. https://github.com/Timot05/logic-card/blob/a63581636233dd1f9...

You're right. It definitely is currently.

This is a hole we're planning to fill between linters and a language server. Picture a red-underline under an instance which is insufficiently configured, for example

Re: Show HN: Atopile – Design circuit boards with code

#210

Post by vrinsd »

mawildoer wrote: post #201
vrinsd wrote: post #197

At the risk of sounding pretty negative to someone who wants to make the world of EDA better, this really seems like a re-discovery of a text netlist with the idea of making it 'easier' to create schematics but I feel like it's DOA for anything non-trivial. Most PCB tools have the user create the schematics graphically, but the actual 'design' is usually a text netlist already or the tools let you export the netlist…

We're largely on board with the same problem's we're trying to tackle, and I most certainly understand why you're making these criticisms of these trivial examples and our current implementation. You're right to - these simple designs aren't where designing PCBAs with code will shine (we expect!). Currently when you discuss configuring a regulator, it's beholden upon the designer to understand enough of the internals…

Glad you're open to feedback.

I don't know if your regulator response was directed at me or someone else, but using that as an example, if you take something like an LM7805/LM317 I think the 'parameterization' you're talking about (i.e. "input_voltage=12V", "output_voltage=3.3V", "accuracy=5%" --> let "tool" solve for resistors, and populate schematics/BOM) sounds cool and would work.

But what if it's something like this (a multi-phase step-down converter):

https://www.analog.com/media/en/technical-documentation/data...

While it's "annoying" that a designer might have to go study a datasheet to know which resistors to tweak or change what's worse is having a tool or 'abstraction' do it for you, with the potential that it changes significantly underneath you and you don't even know what it did or why.

This is the bane of a lot of EDA tools and more specifically why people rightfully now loathe a lot of FPGA vendor's tools that have things like "abstract IP blocks" configured from the GUI but in each new release of the tool, the underlying "generated" RTL (which comes from some byzantine invokation of scripts and a soup of options) might be different and completely breaks people's designs.

What happens if it's not re-programmable like an FPGA but something physical with resistors, capacitors and traces on a circuit board?

Post reply on HN