posted on Feb, 27 2013 @ 10:56 AM
Originally posted by Zaphod58
Now, I might not always be the sharpest tool in the shed, but since when does software cause smoke in the cockpit?
Meh, it can happen.
If you've got really scruffy hardware design, it is possible for your hardware to allow the software to do physical damage.
Examples - heck, even in your PC, if it's got the ability to do voltage tweaking from the BIOS, for example, and if the hardware allows really out of
line voltages to be set, to the point that you'll get a hardware failure, then a write to the wrong port or with the wrong value and you can
overvoltage some parts and smoke them. Note that you don't even have to intend to do this, pick up a discarded pointer, fetch a random port index
instead of what you intended and Bob's your uncle.
I have seen SCADA equipment where you had direct control over the transistors in H-bridges, with the gates mapped to I/O port pins. If you turned on
all four transistors, bang, smoke, fire. Again, it's something you could do easily with a software error.
Basically, you see these sw-kills-hw things when you have the ability to either command a nonsense state on the hardware, or to configure the hardware
lethally (voltage settings), or if you've got a shared bus that you can flip various non-compatible things onto and you fail to keep track of it.
If you designed the hardware correctly, you would not be able to do this. However, it's a big temptation to push the reins into the sw guys' hands
in the name of flexibility.
OTOH, we have intentionally done this in some cases, where we designed self-destruct capabilities into SOC hardware. Now, THAT is fun design. How do I
irreparably screw up this thing in such a way that you can't stop it once it starts? Everyone wants to work on the autodestruct subsection. And it's
definitely a hoot over in the validation lab.