New Way to Patch Defective Hardware

brunascle writes "Researchers have devised a new way to patch hardware. By treating a computer chip more like software than hardware, Josep Torrellas, a computer science professor from the University of Illinois at Urbana Champaign, believes we will be able to fix defective hardware by a applying a patch, similar to the way defective software is handled. His system, dubbed Phoenix, consists of a standard semiconductor device called a field programmable gate array (FPGA). Although generally slower than their application-specific integrated circuit counterparts, FPGAs have the advantage of being able to be modified post-production. Defects found on a Phoenix-enabled chip could be resolved by downloading a patch and applying it to the hardware. Torrellas believes this would give chips a shorter time to market, saying "If they know that they could fix the problems later on, they could beat the competition to market.""

Comments

what?

[Anonymous Coward]

I'm not sure I see what this guy is doing that is novel. I can't tell if it's a stupid writeup or if this guy really thinks sending out a new bitstream to an FPGA is a breakthrough. FPGAs are remarkable pieces of hardware, and depending on how much you're willing to spend they can run up to a few hundred megahertz- though timing problems can be difficult to resolve at that kind of speed. Many ASIC designers use FGPAs in house to prototype and can afford to spend up to $25,000 for a single chip (only the craziest number of gates cost that much) but which reduces the number of million dollar ASIC production runs. The other reason you don't see a whole lot of FPGAs in closed source hardware is because an end user/hacker could make the hardware go out of spec or do something unintended and then expect warranty support. An increasing number of open source hardware projects (Universal Software Radio Peripheral, or USRP, for one) include FPGAs however. Anyway, bottom line is I just don't see from the article at least what this guy is doing that is so special. The article makes it sound like the chip can detect the errors itself but then requires a patch to be uploaded. It sounds to me like he's adding logic that works around certain hardware states in the fixed portions of the circuit- but that's just updating the VHDL/Verilog and creating a new bitstream. So again, I don't know if it's a dumb article or a dumb researcher. Anyone have more information?

Re:what?

[Akaihiryuu]

I can't tell if the stupidity is in the article writer (most likely) or the researcher. But yeah, FPGA's are NOT new technology, they've been around for a long time. They are definitely useful in development, but an FPGA used to design a part is orders of magnitude slower than the ASIC that they produce from the design. I can see them being useful in very limited applications, but if the article writer or researcher thinks that we'll be replacing our CPU's or GPU's with FPGA's anytime soon they're pretty dumb.

Re:what?

[AaronW]

You would be surprised how widespread FPGAs are. They are used in consumer devices to a limited extent. In high-end hardware where cost is not as much of an issue and the volume is lower FPGAs are very common. I know networking hardware has been using FPGAs for at least a decade, and most enterprise networking equipment I see has them. They are common in higher-end routers and other devices.

FPGAs also have come down significantly in cost while increasing their gate counts. A number of FPGA vendors also offer services where you can go straight from an FPGA to an ASIC at a much lower cost than a full custom ASIC design. Start looking inside consumer devices... look for chips that say Xilinx, Altera, Lattice, Actel and more. Some of these companies also make regular ASICs, but many of the parts you see are FPGAs.

FPGAs are nothing new, though it is not so common for consumer devices to be upgraded in the field as it is for higher-end devices.

Re:what?

[Anonymous Coward]

"I can't tell if the stupidity is in the article writer (most likely) or the researcher."

Wrong. I believe that the stupidity is in the Slashdot readers. Dr. Torrellas published this in Micro-39, which means that the paper has been floating around the internet for around 4-6 months. You should assume that article writers are going to screw up the details. Go read the paper yourself. Here's a link:

http://iacoma.cs.uiuc.edu/iacoma-papers/micro06_ph oenix.pdf

Then, if you feel so inclined, go read other modern papers to see exactly what the other new things on the horizon are. Go to Google, search on some computer architecture conferences (ISCA, MICRO, HPCA, ASPLOS, etc), then read the papers listed in the conference proceedings. You can find them using most search engines (Try Google Scholar).

Then, after reading the source, come to Slashdot and bitch intelligently. After all, if you don't -- aren't you just gossiping about your friend's brother's sister sleeping with that other guy with the gross body odor? Yeah right, like she'd hit that.

Re:what?

[timster]

I think you're seriously misunderstood TFA. The idea isn't to replace the chip with an FPGA. The idea is to include a small FPGA through which various important signals are routed.

As shipped, the FPGA is just a pass-through, which does nothing. When you find out that a bug presents in a certain situation, you modify the FPGA to intercept the problem and handle it somehow.

Re:what?

[jd]

Both a dumb writeup and a dumb researcher. FPGAs are commonplace, patching them in-situ in the field is a little unusual but not particularly exceptional. They're cheaper to produce than ASICs (but much slower) but for a lot of stuff, performance is far more I/O-bound than compute-bound and so manufacturers can get away with using FPGAs. Plenty of companies never bother moving off of FPGAs at all.

Patches? Well, you think anyone on OpenCores is going to send patches via a soldering iron? No, they're going to reprogram the FPGA, the same as everyone else does. So even Open Source hardware has this guy beaten by many, many years.

Are FPGAs the only way to do this? Depends on what you mean. Processor-In-Memory devices pre-date FPGAs by at least a decade. PIM architectures are fun, as you get raw CPU performance without any memory access bottlenecks. Want to reprogram it? Well, it's just RAM. You can program it however you like! PIM is vastly superior to FPGA, if (and only if) you know the fundamental logic you are going to use and the fundamental logic isn't going to change. For example, you could build a PIM that had the whole of the MPI protocol built into it. Cray did exactly that. Your program on top of that will change FAR more often than the protocol itself, so so long as you code the protocol correctly in the first place, this will not only run faster but be far easier to change. No rewriting the VHDL or Verilog, because there isn't any.

But programming isn't the only time you'd want to patch defective hardware. Sometimes, hardware goes bad. You can't avoid it. A patch on an FPGA isn't necessarily going to fix that, because there's no way for the engineer to know what went bad and it wouldn't be cost-effective to re-engineer the code to put on it. Well, that's been thought of, too. Sir Clive Sinclair - possibly the most reviled figure in British computing - actually came up with a really neat solution. Simply make the system wafer-scale and format the compute elements as you would a disk. When something goes bad, mark the sector as bad. With massive redundancy and a near-zero failover time to a different sector, you could handle sizable chunks of the chip going up in smoke - something no FPGA patch would even remotely come close to.

Ok, what if you want something that looks and feels like an FPGA - then is this your only answer? No. SOGs (Seas of Gates) have been around for a while.

Finally, CPUs have long supported the notion of microcode - I believe one such system was hacked to run Pascal as the opcode not long after the language was first developed. Yes, that was some time ago. Hell, the Crusoe (if Transmeta had ever published how) could be programmed to look whatever you felt like making it look like. Talk about patchability!

The sheer number of solutions people have come up with to this problem probably outnumbers the gates on the FPGA the researcher was using. I can see nothing credible or interesting in this, and certainly nothing new.

Ultimately, of course, this has nothing to do with when someone invented whatever method. It has to do with when someone actually makes it ubiquitous. Alexander Graham Bell wasn't close to being the inventor of the telephone, but he marketed it like no-one else. That's what people react to and remember. Will this researcher turn what is frankly a pedestrian piece of work into a major slice of the market? I doubt it, but they might. If they do, then all the prior examples in the world will convince no-one. If they don't, then it's one more piece of research that's destined for the rubbish heap.

Re:what?

[Lorkki]

Patches?

What bothers me personally is that "it's easier to upgrade" is one of the excuses used when producing those skimmed-down Windows-devices. You can guess twice if it's ever improved the quality of the products, or if even half of the bugs they ship with ever get any attention from the vendors.

So yeah, please give them one more reason to ship too early, more often and cheap enough to sell by the bucketload.

So, he's discovered the FPGA?

[seanadams.com]

Don't bother reading TFA, there is no more information there than what's in the summary. Just some additional hand waving about how this enabling technology will magically detect and fix hardware bugs.

I'm sure the professor has developed _something_, but the article sure doesn't give any clue what it might be. This story is nothing more than an exceptionally poor description of what any FPGA can do.

Re:So, he's discovered the FPGA?

[alx5000]

Imagine for a moment that this guy has invented something new. Imagine, as the last line of the summary suggests, that "If they know that they could fix the problems later on, they could beat the competition to market."

Sounds like the hardware version of Windows. Every user would be a beta tester. Your phone calls your friends in the middle of the night and makes strange noises? It's ok, we'll fix it soon. Meanwhile remember we were the first to offer scheduled calls for cell phones!

Re:So, he's discovered the FPGA?

[treeves]

But they're not just talking about FPGAs. It's not the article you want to kill, it might be the summary, which says that the whole idea is just an FPGA.

If you RTFA, you see that they're talking about adding a field-programmable unit into a traditional CPU, like IBM 750FX or AMD Athlon 64, to allow hardware bug repair - something they couldn't have done in the case of the Pentium III FP division bug, for example.

WTF?

[PhxBlue]

So we'd get to have these chips in PCs sooner, and in return, they'd be less reliable? No thanks. One Pentium floating-point problem was bad enough.

So from a customer viewpoint

[JanneM]

So, from a customer viewpoint, what this offers is slower, more expensive hardware that is less tested and buggier than the competitors coming down the pipeline in a month or two?

I suspect I an do without.

Wait a sec...

[Kryptonian Jor-El]

"If they know that they could fix the problems later on, they could beat the competition to market."

That sounds like vista to me...except for the fixing problems later on part...and the beating competition to market...
What was my point again?

Buggy hardware AND software?

[GoLGY]

"If they know that they could fix the problems later on, they could beat the competition to market."" Great, just what we need - hardware suppliers being encouraged to release buggy versions in the guise of fully working products.

Hasnt the lessons that have been learnt by the software industry had *any* impact?

Re:Buggy hardware AND software?

[evought]

"If they know that they could fix the problems later on, they could beat the competition to market."" Great, just what we need - hardware suppliers being encouraged to release buggy versions in the guise of fully working products. Hasnt the lessons that have been learnt by the software industry had *any* impact?

Sure, and those lessons are being fastidiously applied here. Customers buy that buggy, undercooked software and wait for the patches. Problem is, in increasing numbers of cases, the vendors are learning that they don't have to even ship patches (e.g. game industry, commodity hardware drivers and apps) or only for a very short lifetimes.

Fast-followers usually have much better products than first-to-market vendors, and it used to be that they had better success as well. I am not sure that is always the case these days. Look also at the release of Vista and the fact that a new XP system simply cannot be purchased, locking customers into being beta testers (or getting off the platform entirely).

In some sense, this has already extended to hardware as more and more depends on firmware and flashable updates. a good portion of drivers for some hardware consists of software to offload to firmware, one of the things that makes opensource drivers a pain.

Re:Buggy hardware AND software?

[QuasiEvil]

Umm... most complex hardware *is* buggy. That's why datasheets often have errata issued with them, listing the different revs of silicon and what doesn't work...

For example, here's the summary one for the Athlon 64 family (warning - pdf link):
http://www.amd.com/us-en/assets/content_type/white _papers_and_tech_docs/25759.pdf

It's also why modern BIOSes and OSes apply microcode updates to the processor - to fix "hardware" while it's in the machine. They literally rewrite the microcode that runs the processor on boot to correct certain types of issues.

I spent days in a previous job chasing around problems with one particular batch of small microcontrollers. Turns out, I eventually noticed that all of the misbehaving ones were rev B silicon, which eventually lead me down the path to the errata sheet. Turns out, our code, which worked perfectly on every other rev, had fallen into one of the rare pitfalls of that revision.

FPGAs are a horrid idea for mass production. They're usually either slower or utter power hogs. If it's a low-production device, or something that needs regular field updates, then great, but for mass-produced bits, it just won't work out well. I just can't see putting an "FPGA area" into regular ASICs due to the massive amounts of stuff you'd need to wire around in order to divert lines away from the usual areas of silicon over to the FPGA area. Plus there's all that wasted silicon if the FPGA area was never used, which would decrease yields and raise costs.

Limited useability

[Dynedain]

Great... so I assemble a new system with "patchable" hardware... only to find that the hardware is deffective.

Now I'm left in a situation where I need software to patch the hardware. But I can't run the software because the hardware is defective...

This is just an excuse for being lazy. Do we really need more untested products flooding the market? Nothing like shifting the burden of quality control onto the end user to push up your profits...

On the other hand, this could be very useful in systems where physical access to the hardware is nigh impossibles... satellites for example. But this should not be used in consumer devices, and shouldn't be a crutch for faster development.

Oh great...

[Brandybuck]

"If they know that they could fix the problems later on, they could beat the competition to market."

Oh great, now we'll have hardware as crappy as software. I guess we'll have to get used to the new QA mantra: "If it solders, ship it!" Sigh.

Re:The latest news... from 1984...

[vivaoporto]

But you don't get it. This is news because it is a new way to Patch Defective Hardware ... in space!!!

If I'm missing something...

[user24]

If I'm missing something, then I'm sure a lot of other people are too, so please explain:

exactly what is stopping malware2.0 from killing my processor?

Re:If I'm missing something...

[Frank T. Lofaro Jr.]

Nothing.

And this is the reality NOW.

Erasing the BIOS, stopping fans, overclocking and overvolting chips can be done TODAY.

Also, changing the region of a DVD drive until it locks out changes and leaving it on a unwanted region is also doable; another "advantage" of this attack is that it is a felony to repair the hardware thanks to the DMCA giving DRM the force of law.

Killer POKEs didn't die with the Commodore PET and C64, they just aren't literal POKEs anymore.

bleh

[dave1g]

I was hoping for some idea like slapping an X gate FPGA onto the package of a regular processor, and then if in later testing it is deemed to have a bad cache line, or floating point unit. it could be reimplemented in the FPGA section and wired in, possibly increasing yields. Though these would certainly be lower quality parts they would atleast be functionally correct, if a bit slower.

But I dont know. Something tells me that if there is a hardware problem(not a hardware design problem) then it is likly that there will be others on the same chip, due too some non uniform distribution of impure silicon. and it wouldnt be long before there are too many corrections to fit in the fpga.

It's a new way to use FPGA technology

[mbessey]

The article IS light on details, but the last paragraph does explain how the system would work. Basically, manufacturers of mass-market chips would provide a small amount of FPGA-like programmable logic in every chip they make. This programmable logic would sit idle until some defect was discovered in the chip.

At that point, you can send a "patch" to the chip that uses the programmable logic to detect the error condition (or conditions that trigger the error), and work around the problem.

It's fairly clever, and is similar in spirit to the microcode patches that varios x86 CPU manufacturers use to correct for errors in their chips after they're taped out. It would be interesting to read about what the actual design is. It seems like coming up with a generic logic patching mechanism that can deal with previously-unknown errors would be a pretty interesting task.

Is this guy serious?

[megla]

I can't believe I'm even reading this.
The entire selling point of this system is that it allows hardware developers to do sloppy work? Great! The build-and-fix approach has worked wonders for software what with constant security alerts and all, why not use it for hardware? Inspired!

Have they put any thought into this at all?
That other people might make malicious "patches"?
That they'd be opening up hardware to all the vulnerabilities that software has?

Jesus christ people, use some common sense.

"regular" programmable logic

[nurb432]

Predates FPGAs by decades.. Sure they have advanced things greatly, but where the hell has this guy been the last 30 or so years? Under a rock?

Personally I was using proms as rudmentary programmable logic 20 years ago.

I already beta-test software for free..

[daitengu]

Half of Google is in "Beta", 90% of the video games I buy are beta-quality, more and more software now-days is labeled as "beta release 3.1415", I don't need to beta-test a processor or GPU as well! While it would be nice to be able to _add_ things to your CPU, like support for SSE42, I think something like this in a CPU would cause more harm than good.

It'd also make debugging software that much harder, as you won't be sure where the problem lies, with the CPU or the software program itself.

d00dz: shut up

[smittyoneeach]

We've got the USPTO convinced that "Prior Art" is just paintings by a moderately famous black comedian with a penchant for potty-mouth.
Don't screw this up, m'kay?

Re:Reliability requires redundancy

[LarsG]

In a sense I'm a bit surprised that nobody has thought of the application of redundancy to chip manufacture before now.

They already do.

RAM and Flash chips typically have a few redundant memory banks.

Graphics chips with faulty modules are sold as lower performing parts (example - the Nvidia 6800 LE and the 6800 Ultra both have the NV40 chip, but the LE has 8 pixel pipelines and 2 vertex shaders disabled).