FPGA - software or hardware?

Generally the data books and data sheets for ALL electronic components say that. Yet somehow life support devices manage to include electronic components. Once Xilinx (or any other vendor) sells you a chip, their claim that its use in a life support application is "prohibited" doesn't have any more weight than if I sold pencils and said that their use to write the answers to homework problems is prohibited.

When the life support system fails, and the heirs sue the company that made it, the doctor, the hospital, and the vendors of the components of the system, Xilinx can point to that paragraph and tell the jury "we tried to keep our customers from using our chips in life support systems." The jury may or may not find that paragraph to reduce Xilinx' liability.

Personally, were I on a jury, I'd give that paragraph very little weight. After all, the life support system has to be made out of

*something*. That said, however, if a particular component failed and resulted in harm to a person, I'd ask why the designer of the life support system hadn't designed the system to be fault tolerant without that component being a single point of failure.

Eric

Well, I don't see Xilinx trying to prevent customers from using their parts in life support systems. Instead, asking Xilinx for written consent would give Xilinx an opportunity to grant/withhold such consent, and to make conditions to be met before granting consent.

Wild guess: such conditions would include accepting help regarding reliability, hard/soft failure rates, coding standards, possibly design review, etc to ensure both Xilinx and the customer had done everything possible to make a safe product.

- Brian

Technically, the code for FPGAs is not firmware. Firmware is usually described as computer instructions or computer data. VHDL and Verilog are hardware descriptions. Once upon a time, we created a schematic to describe the logic we wanted and now we use a text editor. Logic descriptions and computer instructions are different things - though I admit the boundary sometimes gets a little blurry.

Some teams at my company have developed FPGAs using a formal software development process. Though successful, the process matched our needs about as well as the process we use to develop circuit cards. FPGA development is a little bit of both worlds.

To address your problem, you may need to cover both worlds. Sorry.

Is that the famous one about the X-ray machine that irradiated people with 100X dose?

That case you could call imaging, but the consequences of the particular failure (lethal radiation doses) are a little different from, for instance, the failure of a blood pressure machine.

2c Jeremy

Or a throttle control system or ABS system that fails causing you and your car/truck/suv to be in harms way resulting in injury. Or a fire alarm system that fails in a a major high rise. Or a train crossing system for gating pedestrian and vehicles at a major crossing where fast trains frequent a blind track access. There are lots of systems that can cause harm with failure.

Well, software certainly IS involved in creating the Bitstream, and if you read the user feedbacks on ISE V8.x and all the bug issues, you will see this will require strict version control in anything medical. ie Develop/Test/Maintain with ONLY one version of the software.

Sounds like you'll need both processes. Some of the FPGA you CAN test in full, and in this area, it sounds like a more extensive 'self test' mode would be a very good idea. Seems like one thing a FPGA can do very well It moves more of the system into a 'proven to work' tickbox, and out of the 'we hope it still works' tickbox.

Do you use a SoftCPU in this ? that is then clearly software.

-jg

Actually software is FSMs which operate on data streams, doesn't really matter if the syntax of the language is one's and zeros (for us oldie moldie coders), assembly language, basic, fortran, cobol, C, C++, Java, Lisp, .... or sequential VHDL statements which have functionally equivalent syntax and high level expression syntax for floating point equations, and lesser integer expressions.

Any hardware engineer that mistakes an FPGA design as 'proven to work' didn't do their homework regarding SEU failures at altitudes well above sea level ..... as nearly all static ram based designs are seriously at risk. Vertex-4's go a long way to help that with error detection on config ram, but are not SEU immune yet. Nor are microprocessors with static ram for caches and other memory, while most dynamic designs are.

It's life critical, in that it can kill or seriously injure someone if it fails. In the same sense, the brakes of an automobile may be considered life critical.

I'm not sure if I would call it life support, because it is generally not necessary to keep a patient alive in the short term, in the manner that a respirator would.

Did it serve any imaging function? The primary purpose was application of therapeutic radiation, but perhaps it also provided imaging used by the operator for precise alignment of the target area?

Depends.. what say its an automatic blood pressure machine that pumps up and down.. and crushes an arm... or just explodes the air bag causing a slight burse to the upper arm... or a false reading causes the doctor to give a medicine that's a poison for the patient?

It is kind of ironic where we have come from. It is too easy to think of a HDL as ASIC and HDL as FPGA perfoming as well forgetting about any potential logic upsets. I wonder how some of the FPGA based MP3 players behave on air flights, or even how reliable laptops are up there. So FPGAs and large cache CPUs are more similar as the SRAM area dominates. I am under the impression though that the BRAM is the usual generic 6/8 T cell with modest Cs and the config bits are entirely bigger with far more robust cells given the nature of the beast. I would expect the logic to be far more reliable than the data it is processing.

Twenty + years ago everyone knew that SRAM was bigger, more expensive, much faster, and more reliable than DRAMs by a long shot and people would wonder how much better CPUs would be if only they could have an all SRAM main memory system like some CRAYs had.

Today most everyone esp outside hardware still holds onto that idea, yet DRAM is now by definition far less susceptible to upsets and can even be quite fast in the few ns row cycle times for embedded DRAM cores and still many times cheaper per bit, smaller and vastly less power consumption, but requires extra process steps so extra $. I am not sure that we will ever see DRAM used in FPGAs but perhaps instead we could treat the SRAM cell as a dynamic node to be refreshed by a more reliable corrected memory system. Perhaps an embedded DRAM block could be used to routinely refresh the distributed SRAM arrays while checking at same time and report differences while doing so, perhaps not.

How about a new disclaimer:

"Xilinx products are not intended for use in traffic light controller applications. Use of Xilinx products in such applications without the written consent of the appropriate Xilinx officer is prohibited."

Maybe then the first-year students would stop pestering us :)

-Ben-

I remember the throttle stuck open on my old MR2. The accelerator cable frayed where it joined the throttle body housing and got stuck in the bowden cable sheath. The return spring couldn't close the thing. Had to drive around on the ignition switch for a day or two! Which reminds me, I've found a good interview question for hardware engineers is to ask candidates if they can change the brake pads on their car. It separates the soft from the hard! :-) Cheers, Syms.

Yup.

Is your blood pressure machine plugged into the wall? Very sick people often have electrodes attached at critical places.

A friend was jack-of-all-trades involving electronics at Mass General Hospital. He reported that one of the really nasty things that happens all too often to gear he worked on is that saline solution would get dumped down the air vents. When he told me that story, I was thinking of long term problems.

Short term might be interesting too. How much isolation does your magic opto-isolator chip provide when covered with salt water?

Are we being paranoid enough?

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

I actually have to bite my tongue to avoid the flamebait when the hardware guys here starting beating their chests about how reliable their engineering is and how full of shit software engineers work is from a quality and reliability perspective. I live in colorado, where there is enough altitude that SEU's are a problem, and just chukle thinking about how much worse it is in Vail. I actually wonder sometimes if people really have a right to blame Microsoft for all the lockups at these altitudes. I really have to wonder given the SEU problem, if any FGPA engineer understands zero defect engineering for financial and hi-rel applications. Having spent over a year working at a bank in So. Cal in the late 1970's, I got something of a dose of zero defect software engineering, then worked beside a couple flight systems engineers in the late 1980's that also did a stint at zero defect software development from the government side of the business.

I've also wondered what would happen if I took a neutron emitter to vegas to play the slots :) Or to Blackhawk. Do they disallow big wins when the machine locks up or glitches? Do they have detectors at the door?

Given the rosetta numbers Xilinx gathered at this altitude, it seems that a few thousand slot machines with FPGA machines in them would be a huge reliability problem at Blackhawk .... or even a lot of small micros with static rams. Does the gaming commissions even consider the hardware might be less reliable than the software that they also strictly regulate like the medical folks?

In my bad old days in a power authority.. we used opto isolators.. the cabinet holding them was varnished wood.. and the cabinet had its own floor .. wood of course.. and held 4 inches above the main flor by nylon supports. Of course you could only get to one side of the opto from there, each side of the optocouple came out in the other side of the cabinet (thru the wood wall).

Do you think they were paranoid? or working to worse case scenario?

Simon

unsolicited

addresses.

I've seen things like that in various data books for a long time now, but I've never worked on anything where I had to pay attention to it.

Is "life support" a legal term? If so, what does it mean? What about other safety critical applications?

What do I have to do to get an officer to sign off? Is it a legal formality such as a letter promising not to sue, or is it something complicated and expensive like taking out an insurance policy to cover somebody suing Xilinx or paying somebody that Xilinx trusts to review the design? ...

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

[ ... ]

Nearly all of these machines have BIST routines to run immediately before announcing a large payout. Some have BIST routines to run more or less continuously.

Gaming machines mostly don't need a lot of speed so many use pretty old technology. I'm pretty sure I've never seen one with an FPGA in it, at least in any critical area (though, in fairness, I've only looked at the innards of a few).

The systems tend to be bifurcated into two pieces: one part runs on a fairly standard low-end PC, generating the display, sound, flashing lights, etc.

The other part is the random-number generator stuff that actually decides when games are won or lost. This has its own dedicated CPU and the software runs directly from ROM. At least in the machines I looked at, this would have no problem in Blackhawk...or a satellite.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

An episode of "Breaking Vegas" on the History Channel called "Slot Scoundrel" was about someone who successfully cheated slot machines using electronics. They didn't detail how it was done, but the photos made it look like he use a probe on a piece of metal to hook into a JTAG connector and reprogram the random number generator.

One view had a big picture of a Xilinx chip, but this may have been creative license of the show producer.

The casino investigated, found the machine to be fine and paid out. He was turned in by an accomplice.

Alan Nishioka

[ ... ]

That's hard to say with any certainty -- the ones I've seen didn't use anything that was re-programmable after the fact without swapping out parts, but there are a lot of designs out there, and I've only looked at a couple of them.

I can imagine an FPGA for something like the glue logic to get their weird peripherals to talk to the computer -- they have lots of flashers and stuff that nearly nobody else on earth ever has or probably ever will want to connect to their windows box.

In the PRNG itself, however, I'm left wondering what they'd do with an FPGA if they did have one. Their performance requirements are minimal, and the requirements are nearly carved in stone, so they practically never change.

The instances of which I'm aware that people cheated relatively successfully have involved electronics they put next to the machine, not something where they modified the machine internally at all. Oddly enough, however, they weren't particularly forthcoming with details about how they worked either...

--
    Later,
    Jerry.

The universe is a figment of its own imagination.