Just finished Cory Doctorow's latest novel, "Picks and Shovels" - what a thriller! Cory had me hanging on every word, blending retro-computing, romance, and rebellion into a masterfully spun tale.

Five stars, would recommend.

@azonenberg COP? choco on polymer? :blobcatthinking:

I can't help but think mmmmMOSFET when I see these... that choco gate surrounded by creamy channel with mousse source and drain contacts... the ganache seal layer... tasty transistors!

@timonsku I had not - mainly because for the "main rig" I wanted to pick lower cost, more accessible parts. However, this might be an interesting option for some fun-time exploration just for my curiosity.

My talk on IRIS is up!

https://media.ccc.de/v/38c3-iris-non-destructive-inspection-of-silicon

Great to see everyone at 38c3.

@kris zomg I have fortunately not had to encounter problems with initial states ordering, but I could definitely imagine situations where that can make a huge difference...especially if you leave the realm of static CMOS and start talking about dynamic logic, self-timed circuits, combinational loops, or heck even just plain old bus arbiters...

@yrlf if I were to have to guess it's because everyone has a different definition of what a reset should be. For example, is the reset synchronous, or is it edge-sensitive? That's a basic question, and most F/OSS FPGA code I've seen is synchronous reset; but most ASIC code is asynchronous reset.

If you're doing async reset - then questions like rise/fall time of the reset, minimum pulse width come in to play. You still have to meet timing on a reset signal, it's no magic bullet. And then you have questions about reset relative to clock edge. Given that it's a big, global signal, you could just solve it by giving it as much buffering as a clock driver and have it hit within your worst-case clock period, but then that seems a waste for a reset signal.

Then you have clock domain crossings, each with its own reset, and the relationships between those. Especially in CDCs, you have some special concerns about the introduction of resets - there are hardened synchronizer blocks for example that have no reset signal, but you still need to functionally model as bits of state.

The overhead of reset insertion might be a concern. I've seen some chip designers obsess over bumming out "unneeded" resets. In some cases it's just over-optimization but folks doing analog/mixed-signal stuff or high speed digital where you're pushing the hairy edge of timing the extra transistors count, and so you might opt to leave out the reset signal on critical paths that are truly just flow-through data paths.

This doesn't even get into the discussion about BIST methodology and the fact that you might need to merge in yet another reset path late in the design flow (post-synthesis even!) for self-test concerns...

In the end I think the short answer is each chip lead can make a policy decision about how they want to handle reset - whether it's automatic or explicit - and there are solid arguments for both; so vendor tooling like code compilers don't enforce a policy and just leave it as a free variable that each chip team has to contend with, because that free variable, when used effectively, can mean a couple percent difference on a key benchmark, which ultimately impacts the salability of a chip.

You know how when writing software, it's beaten in to you to always initialize your variables?

It's the exact opposite when writing verilog for hardware. It's so hard to break that habit, but so important to get that right.

The problem is that simulators are more than happy to pretend that a register always starts at a given value, but in reality, without an explicit reset operation, registers are initialized by the entropy of the universe - the laws of physics care not about your illegal states. As long as you don't try to pack two electrons into the same quantum state, it's a legal state according to the universe.

(And chip synthesis tools can't safely auto-insert a reset because "global signals" are as much a fiction as ground being zero volts).

(And for those who have not done hardware simulations, accurate hardware simulators have at least an extra "X" state in addition to "0" and "1", which is the value assigned to uninitialized variables. Note that fast simulators like verilator do not support this; if you only check your code in verilator, it's not safe to put into an ASIC).

More problematically, almost all F/OSS hardware RTL is for FPGAs, where initialized variables are a reality (because the flip flops are set up by a bitstream loader before the design is allowed to run), so I end up having to dig through most F/OSS modules line-by-line to make them tape-out ready.

And when you miss a module...well, see the previous comment about the laws of physics not caring about your illegal states.

On the other hand, there is something deeply satisfying about knowing exactly how the delicate order of computation emerges from the chaos of nature. And/or how you can upset order that with glitching. :blobcat:

That time when you're debugging an image processing pipeline and discover... art?

GREAT change is approaching. NIST will standardise prohibition of requirement of composing passwords from various character styles, and requirement for periodic password changes. These are harmful and obsolete rules. Now they will be treated as a cybersecurity weakness https://pages.nist.gov/800-63-4/sp800-63b.html

@RaphaelWimmer @floe Can't tell from the photo but the icons on the top row look like they might be hard-wired graphics and not pixel art. Anyways, black and white LCDs like this are usually just full custom builds and not standard parts as they only require wires and no transistors.

B&W non-TFT LCDs are surprisingly cheap to get made...I've visited a couple factories that do this. Because it's just wires, you can start with full sheets of ITO and then print a single fairly low-res photomask & etch; some factories even just use a scanning laser to ablate the ITO to create wires, so you can make 'em in super low volumes.

I've made a couple myself just for the fun of it...

Everyday objects have been turned into bombs. My analysis indicates this supply chain attack is surprisingly easy to do, yet hard to detect: https://www.bunniestudios.com/blog/2024/turning-everyday-gadgets-into-bombs-is-a-bad-idea/

@carlsetzer Thanks for watching it!

Here's a teardown on Formlabs' just-released Form 4:

https://www.bunniestudios.com/blog/2024/formlabs-form-4-teardown/

Always a fun learning experience taking apart their 3D printers!

The Form 4 is an LCD-based 3D printer with neat details like a metal core PCB, custom liquid crystal element, and a Raspberry Pi CM4 inside.

@gsuberland I've found that the exact terms for technical parts can vary by region and specialty (one part of a supply chain may have a different name for the same component) - but at least for a PCB shop, I would specify this as "金手指" - literally "gold fingers" - in my gerbers. A box build line might have a different jargon, but I suspect they'd recognize the term at least.

All technical terms seem to go through some game of telephone, because you can't coin new characters in Chinese. Everything ends up being a phrase or a euphemism; the more popular a term becomes, the more it evolves and distorts.

Generally the simpler/more basic and descriptive the terms are, the more mileage I can get out of it. As one of my Chinese friends once quipped -- Chinese is a beautiful language for poetry and calligraphy, in part because it can be so vague and subjective, but for technical things, it can be a challenge at times.

@teajaygrey @jonny @klausfiend Also, the hardware design for the test jig: https://github.com/betrusted-io/betrusted-hardware/tree/main/testjig-v1

@teajaygrey @jonny @klausfiend fwiw I found that Rust is far too strict a language for doing factory tests.

Factory tests are super duper write-once code, with a tiny user base, constantly changing requirements, and you can afford to make lazy assumptions about your runtime environment (e.g. cloning an RPi or NUC image and pinning the versions for a decade).

Python ended up being a much better fit. The latest tester I did is here: https://github.com/betrusted-io/bootstrap-mainboard/blob/main/factory-firmware.py

I am much happier with this framework.

Here's how I stitch individual IRIS images together to create a full-chip composite using template matching and MSE cleanup:

https://www.bunniestudios.com/blog/2024/automated-stitching-of-chip-images/

This is the last post in my series of updates on the IRIS project. Thanks for reading!

Now, back to my happy place, hiding in my lab hacking on stuff~~ :blobcat:​

"Beware programmers that carry screwdrivers" -- a saying I heard as a solder jockey[1] in college.

The inverse is also true, "beware the code of hardware engineers".

That being said, the world's changed a lot since then (30 years now 😱). It's hard to find a modern hardware project that isn't intimately intertwined with huge piles of code. Somehow, days pass and my soldering iron lays cold while I churn out pages of Python and Rust code.

I share my experiences writing one such pile, the control and auto-focus software for IRIS, here: https://www.bunniestudios.com/blog/2024/control-and-autofocus-software-for-chip-level-microscopy/

"Beware the code of hardware engineers". Don't say you haven't been warned!

[1] solder jockey was the moniker bestowed upon undergrads hired to assemble circuit boards for grad students in that particular lab. Minimum-wage labor, but damn, I learned a lot of skills that I use to this day.

Details of IRIS's 2-axis, multi-head light positioner design are now up at https://www.bunniestudios.com/blog/2024/a-2-axis-multihead-light-positioner/

This was by far the most complex mechanical design I've done. Being able to cut, paste, and mashup with the underlying Jubilee3D motion platform's design source was key to everything working so smoothly on the first try. OSHW FTW!