Hacker News Reader

Comment by cushychicken | Hacker News Reader

Smashing job. I use kibot in a similar fashion locally to generate my fab packages for my kicad designs.

I had it set up as a CI job for a while, but I ended up disabling it for a few reasons, the main one being that I just don't think it's a good idea to constantly create build artifacts for circuit board designs. It has created problems when people have circulated intermediate schematics generated by CI that don't match the hardware we built.

You really only need to archive fab packages (by which I mean schematic, gerbers, BOM, assembly drawing, fab notes, etc) at the points in time where you fab and assemble a board.

Creating more artifacts just creates the possibility for more noise. It's not like software CI as there's not really a way to automate hardware testing in a CI server. Very little incremental value in continuous artifact generation as a result.

View on HN

Yes, I was thinking of changing the pipeline to respond to only tags for outputs. Then i can just set a release tag when I am ready to send it to a fab.

How many people use the outputs of your pipeline, out of curiosity?

Just me. It's for my personal projects.

Ah OK. Way less chance of confusion that way. :)

I've used kicad professionally for about three years now. That brief phase of using CI was in my current employer and we had some confusing weeks where no one knew which sch version was the right one.

Being able to share out autogenerated schematics is one of those rare cases where CI hinders you rather than helps you.

I'm sort of tunneling in on this one facet though. This is great work and I'll be reading it more closely when I get off the plane. I'll probably grab some of your kibot configs for myself!

This is what I'm doing. Though it does break down for smaller projects where I had combined firmware and electronics design in the same repository (not a great idea in retrospect).

That rapidly becomes a rough ride - especially when you've got different groups writing hardware and firmware independent of one another, but pushing to the same repo.

You can have different rules for different folders, i.e. only do this if folder == schema && is-tag

I pointedly keep gerbers etc .ignored (directory naming convention where gerbers always export to GERBER_${TITLE}_${REVISION} ,and .gitignore includes GERBER_*/)

and only upload gerber zips as release artifacts

I do keep a bom.csv in the repo to link right in the readme. I consider the specific part selection part of the reference not entirely documented in the sch, and so it's source.

Same for .stl and other output meshes from openscad and freecad sources.

Which is kind of a pity because github has a neat stl diff viewr that's essentially useless if you don't want to check in stls.

I'm curious in what you meant by there's no way to automatically perform hardware testing in CI server?

Is it hardware testing at the simulation/emulation level as a "digital twin" or hardware as testing as in hardware-in-the-loop (HLL)?

> Is it hardware testing at the simulation/emulation level as a "digital twin"

This, very likely.

It's possible to set up simulations of certain sections of the hardware using some Spice software, but it's quite time consuming and I'm not sure if anyone's built a way to compare the output of the simulation to expected output.

Simulating any entire circuit as a whole is impossible, since lots of parts just cannot be simulated.

Piqued my curiosity: Example of a part that's hard to simulate?

Pretty much any kind of non-trivial digital logic. For instance emulating a typical ARM microcontroller accurately, while technically within the realm of possibility, would require a huge amount of effort; every bus and every peripheral's functionality would have to be replicated, including hard-to-gauge details like their power consumption. Even if you have access to the HDL that was used to build the chip (which you usually don't), such a simulation will never be 100% accurate.

spicyjpeg basically described the sort of thing I was thinking of, but even for more boring things like opamps or transistors, it's a big hassle to track down or design a simulation model.

There's a semi-standardized file format for simulation models, but there are still differences between simulators. And every manufacturer's website is a different kind of poorly-organized, so it's hard to even find the models.

The other thing is things where high frequencies exist, like switching regulators. It's possible to simulate them, but there's all sorts of parasitics (imperfections from the circuit being made out of real stuff rather than lines on paper) that impact the circuit. I've only used KiCad, so I don't know if the commercial software here can model these parasitics, but they can have a big on performance.

Things like pspice and microcap can simulate a lot. But if theres high speed digital and switchers on the board, simulating it all could take tens of hours, if not more.

Given enough computing power and resources --both human and hardware-- one could technically simulate anything. However, in the context of a reality with practical boundaries, that is simply impossible.

Imagine being tasked with simulating an entire Raspberri Pi board. You would probably need dozens of engineers and likely more than a year just to write and verify the simulation code. And, of course, a supercomputer to run it.

Hardware isn't about isolated components. It's an arrangement of components on a physical circuit board with interconnecting traces and physical characteristics that interact with the finished board. And, all of this, exists in the context of environmental requirements (temperature, humidity, vibration, RF susceptibility and emissions, thermal requirements, etc.).

A "simple" DDR memory design consists of memory chips, the transmission line (traces) connecting to the controller (FPGA, processor, etc.), the PCB stackup (at speed, this matters a lot), decoupling capacitors, the power distribution system feeding them, thermal management and more.

And that's just two chips talking to each other in a fairly structured way.

CI servers can't hold scope probes or land on test points.

For firmware development I’ve done automated testing with the hardware on a fixture connected to JTAG, uart, and DAQ. It worked pretty well but every once in a while I’d have to press a button or something that the fixture couldn’t.

Testing firmware is not the same as testing hardware.

Reply on news.ycombinator.com