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?

[cowbutt]

Yup, you see this all the time with devices that have the capability to have their firmware updated in the field; often they don't work properly until one or two firmware releases have been applied.

In fact, given how field-updateable firmware is often implemented, this also adds a new failure condition - trashed firmware. I lost a DVD ROM drive when a rogue piece of software accidentally knocked out 1 bit in 16 of the firmware (judging by the new name it had for itself during the BIOS POST, anyway!). If devices are going to be field-updateable, there should be a jumper that must be set by the user to allow the device to be programmed.

Re:what?

[jd]

Can't say I disagree with you. If enough effort went in to make the whole thing easily patched in the field, then there's an excellent chance insufficient effort went in to making the thing right to begin with. I hope noone read my post as excusing those who produce inferior goods because they can fix them later - yeesh. I'm disliked intensely by some where I work now precisely because I don't take any crap from those who prefer the Im-lazy-fix-it-next-year route.

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.

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:So from a customer viewpoint

[horatio]

I agree. I'm already (as I suspect most of /. is as well) almost constantly dealing with hardware and software that isn't production ready but "beats the competition to market". The Nvidia 680i boards ship with software that conflicts with itself, causing BSODs in XP - as confirmed by my emails with eVGA. It is one thing to ship patches for things discovered after shipping -- but I think most large corps today figure it in as a calculated risk. Don't even get me started on the steaming pile that is Vista. The Motorola SLVR (mostly the fault of Sprint I'm sure) with the horribly lagged and buggy UI. The list goes on.

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.

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.

They've already been there, done that!

[woolio]

I think processor companies already do something similar w/o an FPGA.

The difference between the Pentiums and the Celeron (or whatever they called now) used to be mainly cache size -- this might have been motivated from yield considerations (in terms of the cache, since that is a large portion of the chip area). I remember reading something along the lines that they might have a few extra cache lines that can be used to replace a bad one (during the time of manufacture), by blowing a tiny fuse, etc. And I guess that if a particular chip doens't have enough good cache lines for a Pentium, then it becomes a Celeron...

I'm not a hardware designer, but I would think that a general-purpose FPGA wouldn't map well for processor implementation. My guess is that heat/power and/or speed considerations would prevent anything very reconfigurable/not-very-specialized to be used in a modern desktop CPU.

OTOH, modern Intel processors do still use some kind of microcode that can be updated via software (e.g. when the OS is running). I *think* microcode is only used to implement really complex operations or weird instructions that are seldom used. It isn't going to be used for fast things like simple arithmetic operations, etc.

Interesting reading: http://kerneltrap.org/node/2678

Re:Is this guy for real

[Quiet_Desperation]

Secondly, FPGAs are significantly more expensive than ASICs

Assuming you are making many thousands (if not millions) of them, and you ignore development costs. Gate-level design and simulation/evaluation of a complex ASIC is labor consuming task. Getting to a releasable mask set is a long road.

Where I work they develop ASICs for spaceflight so they only build a relative handful, and it doesn't amortize out as well. There's a LOT of interest in space qualified FPGAs as a result. On-orbit reprogramming is also driving that interest. Remember how they fixed the Mars rovers from 35 million miles away, although that was Flash RAM.

On the other hand, I'm not sure what the guy's innovation is. Xilinx, the leading FPGA vendor, has had software processor cores for quite a while. One of them is a freebie. Most of my ground receiver desings use FPGAs for upgradability, and can be reconfigured over a TCP/IP network.