> A ring oscillator in an FPGA can be used as a strain gauge. If you implement a ring oscillator on an FPGA and then bend the FPGA, the frequency of the ring oscillator will shift.
A game controller I worked on was accidentally sensitive to physical strain.
We discovered this after the first prototypes/consoles were sent to early reviewers. They kept seeing weird in-game behavior no one could replicate, even when affected reviewers tried to demonstrate. Turns out they were gripping hard enough to minutely bend the PCB during intense moments in games, which created voltage spikes the software mistook for button presses. You needed to be angry to replicate.
Stories like these are my catnip. The 500 mile email is another great one.
How did you end up debugging/reproducing? I conjured a picture in my head of an engineer comically exasperated and squeezing the controller followed by an “Aha!”
There was bare PCB prototype running on my desk that was in the way. I started cleaning my desk to work on something less frustrating and it got knocked off by accident. The logger went haywire immediately. That was the hint I needed.
This is definitely one of the reasons I wrote this article. To be able to see the cause/effect when a problem is very convoluted is something difficult to learn and difficult to teach. You just have to consume a lot of second hand stories and experience a few yourself.
A story I have heard several times in different instances is some light sensitivity, I think this happened to the Raspberry Pi team (PMIC transient induced by camera flash).
If you work on hardware long enough you run into all kinds of things that make you realize just how little you know.
I had an interesting case around fifteen years ago. I had designed a real time image/video processor using a large Xilinx FPGA at the center of it. The system worked very well, except that it would have problems when flown on a helicopter. Actually, only certain kinds of helicopters, with certain types of cameras.
I scratched my head for months trying to solve this riddle.
Months later, while working on a completely unrelated problem, I touched the FPGA and burned my finger. It was surprisingly hot. This thing ran cool as can be, even without a heatsink.
What happened? At first I thought I had a bad board, so I swapped it out. Sure enough, it got very hot, very quickly.
Huh?
That's when I realized I was using footage from one of the helo's. For some reason my brain made the connection. I instantly knew why we were having problems with helicopter-mounted cameras and why I burned my finger: Vibration.
CMOS consumes power on state transitions, not so much once you reached the final state (low or high). More transitions per unit of time means more power. If the transitions are high speed edges (which is the case for real-time image processing) even worse.
The helicopters in question did not have motion-stabilized cameras. They were hard-mounted to the verticals of the skids and that was that. Which means that every bit of vibration from the helo made it onto the camera. Add that to the helo travelling and you have a perfect storm: Every pixel was changing on every frame at 120 frames per second. The translation was a massive increase in power consumption and heat dissipation. Hence my burned index finger and the problems we had with helo-mounted systems.
So, yeah, the power consumed by an imaging system is a direct function of the rate of change per unit of time of pixel data. A still frame consumes nothing when compared to a busy sequence where every pixel is changing. Logical, yet not obvious when you are not thinking in those terms.
You have to burn your finger (or knock stuff off your desk) to learn this kind of thing.
>If you work on hardware long enough you run into all kinds of things that make you realize just how little you know.
I was part of a team commissioning all of the process analyzers in a new chemical plant. We had an oxygen analyzer (measures oxygen content in a process stream) that kept giving off problematic readings. Every single flange and tubing fitting upstream of the analyzer, as well as the analyzer itself, was leak checked repeatedly to no avail.
One of the chemical engineers recommended we start leak checking downstream. Problem solved. Ambient oxygen was getting into the system downstream, diffusing upstream against the process flow, and was being detected by the analyzer. All the non-chem e's were mindblown.
Humans can generally tolerate skin contact up to 50C. Anything higher and you will pull your hand/finger away.
Keeping with the "unconventional" theme, lips are more sensitive to temperature than fingers, but make sure you don't burn your fingers before you try kissing the chip. With practice, your lips can tell which 0402 passive is getting hotter than others.
Coworker once got a 25W @ 400 MHz radio burn of their hand by accidentally setting a transmitter to high power with a small whip antenna connected and grasping it without thinking about it.
Before I understood how voltage regulators worked, I thought you could just attach a LM7805 to a 22 volt lithium source for running the electronics on a high-power robot. I learned that a failing/overheating LM7805 will pass the full voltage to your microcontroller, and that the microcontroller core will still be "oven hot" a full minute or two after it releases its innards.
Work in the radio group of an industrial electronics company. Arcane magic, unexplained gremlins, and qualitative standard recipes that happen to work are par for the course.
Yes! Well. Once I knew what the issue was, I ran FEA thermal simulations and was able to move the heat away from the FPGA efficiently while keeping weight down. It was beefy in the sense that it moved heat well while remaining as light as possible.
While there are tools that help you compute expected power consumption, nothing beats contact with reality. I just didn't think about the "everything changing at the same time" scenario.
Sorry if I came across as critical, I was mostly curious.
In the last project I worked on with an FPGA (Xilinx Zynq) and cameras, the embedded system that had fairly strict power budget and IIRC the whole design could dissipate something like 45W, which led to a rather impressive looking enclosure that functioned as a heatsink. There was of course a margin, but the thermal design was driven by how much power could be run through the system.
Tools have gotten better, of course. However, I think the fundamentals haven't really changed in the sense that accurate modelling is impossible outside of certain domains. The risk is that you can under or over-design thermal management. This is where experience with a design can be invaluable. As the design goes through iterations one notes performance, compares to assumptions and estimates and makes adjustments.
We tend to work on projects that are highly constrained in terms of such things as allowable mass. And so, I can't just liberally apply a multiplier to estimates and call it good. We need to know. With time you develop test suites that stress things enough to achieve pretty decent test-based thermal data.
Aside from being impractical, Nobody is going to let you even attempt that without going through certification. If every random equipment provided did as they wished aircraft safety would be compromised.
Fun fact: integrated circuit packages put stress on the die. It’s called “package stress”, and when I worked in flash memory testing we would see measurable shifts in analog circuit behavior after packaging.
Just when you think you've found all the possible side channel attacks, along comes a new one: The mole can Morse-Code-tap their secret messages on your Cisco edge router and abscond with your secrets.
That's horrifying. I love it.