Writing software as we design hardware
May 22nd, 2006 by Samuel TardieuAs a low-level software guy, I often have to work with electrical engineers to build custom hardware and software systems. I am constantly amazed by the tricks necessary to make the hardware part work and the experience needed to build reliable electrical components. I decided to apply the same techniques to my software.
First of all, I have noticed that electrical engineers often use ground planes on their boards. A ground plane is just a large area connected to the ground. This reduces the crosstalk effect, where the signal on two wires located near to each other may influence each other.
I did the same thing in my C programs. I have inserted large areas of zeroes between my functions:
int f (...)
{
...
}char _ground_plane_1[1024] = {0};
int g (...)
{
...
}char _ground_plane_2[1024] = {0};
int h (...)
{
...
}
The second important thing was about metastability. In a FPGA (an electronic device that you can customize so that it does what you want in hardware, to make it short), if you sample a signal while it is going from GND to Vcc and store it in a register, the register may take a value of Vcc/2 (I’ve seen this happen when sampling the input of a digital video camera). This value will be propagated and will eventually be resolved after passing through some gates into either GND or Vcc. The problem is that it may be resolved into different values at different places. To avoid this problem, you insert intermediate registers between the sampling of the signal and its propagation in the FPGA. There is a good chance that you get GND or Vcc after the first register. A better chance after the second one. A very good chance after the third one.
So in my code, I changed every assignment from a function result from:
int a = f (x, y);
into
int _a0 = f (x, y);
int _a1 = _a0;
int _a2 = _a1;
int a = _a2;
I ran my test programs and noticed that they were much more stable than before! I encourage everyone to do the same thing, in every programming language.
We have so much to learn from electrical engineering…

May 23rd, 2006 at 9:08
Did you examine the code produced by the compiler to see if there was any difference, specially after optimization?
> I encourage everyone to do the same thing, in every programming language.
Even if ground planes and intermediate registers actually do something in C, I doubt it will work in Python or Ruby
May 23rd, 2006 at 13:30
This isn’t by any chance a not-so-subtle dig at this crank:
http://pages.sbcglobal.net/louis.savain/Cosas/COSA.htm
is it?
May 23rd, 2006 at 14:04
Excellent article ! Several related ideas come to mind:
- power decoupling: declare at least one variable in every function you write and initialize it to a non-null value: this will create a small local power reservoir. In big functions, you may need two or more such variables, scattered at regular intervals throughout the source code.
- differential transmission (more noise immunity) : replace
int f(int n) { return n }
with
int fa(int n) { return n; } int fb(int n) { return -n }
int f(int n) { return (fa(n) - fb(n)) / 2 }
- fuses : protect sensitive/expensive functions from bogus/dangerous input
int intfuse(int n) { if (n < 1000000000) return n; else return 0 }
int f(int v) { v = intfuse(v); /* … */ }
(ideally the fuse should be placed in a separate dynamically loaded object file for easier
replacement in the field)
Your code will be even more tolerant to power fluctuations and noise!
May 23rd, 2006 at 16:33
Stéphane : I had to use another trick to make sure that the compiler doesn’t gather all the ground planes into a common separated section; I made them constant so that they appear in the text section of the executable instead of the data one. Concerning your question about interpreted languages, this is not really a problem as this kind of safety net has to be built into the interpreter itself.
Daniel : I didn’t know this one
Pierre : thank you for your excellent suggestions. I have added power decloupling, differential transmission and fuses all over my code. It looks like it is now bulletproof and will be able to run for decades without any glitch.