New Way to Patch Defective Hardware 238
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.""
what? (Score:5, Informative)
Re:what? (Score:4, Informative)
"regular" programmable logic (Score:4, Insightful)
Personally I was using proms as rudmentary programmable logic 20 years ago.
d00dz: shut up (Score:4, Funny)
Don't screw this up, m'kay?
Re: (Score:3, Insightful)
JTAG-enabled chips, other in-system-programming silicon (eg. ispGAL), microcontrollers with bootloaders... Dude, you're *so* 80's.
Re: (Score:3, Informative)
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 [uiuc.edu]
Then, if you feel so inclined, go read other mod
Re: (Score:3, Insightful)
I really don't see this going anywhere in the near future simply because of cost. You've just taken a $10 ASIC and replaced it with a $600 FPGA. ASICs may cost more than FPGAs in upfront design costs, but it you're going to use more than a thousand and can wait the extra few months, it's always going to be cheaper. Big FPGAs are expensive.
Re:what? (Score:5, Informative)
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: (Score:3, Insightful)
True (Score:2)
I work with embedded designs for a living. Almost every single design that's ever crossed my desk has either a Xilinx or an Altera FPGA between the CPU and the PCMCIA interface. It's pretty standard.
Re:what? (Score:5, Informative)
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? (Score:5, Interesting)
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.
Parallelism (Score:2)
Re: (Score:3, Interesting)
Seriously, a massive set of relatively low-power cores on a very tight connection - provided there was a bloody good way of scheduling stuff - would likely work extremely well in both the high-performance world and the high-reliability world. Who gives a damn if one core fails every m
Re:what? (Score:4, Insightful)
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.
Re: (Score:3, Informative)
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 d
Re: (Score:3, Informative)
So, he's discovered the FPGA? (Score:5, Insightful)
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? (Score:5, Insightful)
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!
It's a new way to use FPGA technology (Score:5, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
You are confusing design faults with manufacturing faults. The proposed idea affects only design faults and, if I read it correctly, has some kind of signature recognition logic that recognises the situation in which the chip will produce a faulty result and then must somehow
Can't believe they haven't tried already. (Score:2)
That was my thought, too. I could definitely see this being used in satellites or other applications where getting the hardware back is impossible or very expensive, but I can't see it being used on a microwave or DVD player.
It's my understanding that a lot of NASA's stuff has
Re: (Score:2)
I have a friend who used to do chip design at NASA.
Based on my half remembered conversations from 10 years ago, FPGAs are great for prototyping, but not for flight systems, because they are power hogs.
When you measure your power consumption in surface area of solar panel and weight of battery that need to be put on orbit...
Thanks for the link (Score:2)
Regardless, it's nice to see some actual categorization of defects for various processors, and they do a good job of explaining why fixing the "easy" cases is very worthwhile.
Re: (Score:2)
The chip monitors certain signals, when the chip detects a combination that knows is going to fail (say, you're about to hit the FDIV bug on a pentium), it takes control and either arranges things so no error happens or corrects the mistake.
It is really a patch for hardware (unlike microcode changes, they would change the way the processor operates directly). This could fix problems in the microcode interpreter, or a RISC processor (incurring a performance penalty)
Re:So, he's discovered the FPGA? (Score:4, Informative)
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: (Score:2)
The latest news... from 1984... (Score:3, Interesting)
The historical roots of FPGAs are in complex programmable logic devices (CPLDs) of the early to mid 1980s. Ross Freeman, Xilinx co-founder, invented the field programmable gate array in 1984.
Umm, ok. Did you mean old way to patch defective hardware?
Re:The latest news... from 1984... (Score:4, Funny)
WTF? (Score:5, Insightful)
No more so than software (Score:2)
Actually, FPGA patches are sometimes done to fix bugs, but more often they're done to change functionality. eg. a new firmware download uses different DSP algorithms or whatever and thus needs different FPGA algorithms to work properly. THus both get updated.
FPGA does help first to market, and good design (Score:3, Interesting)
FPGA revisions are a lot cheaper (almost free) and thus it is very much faster to verify designs and release a product. Tha significantly improves time to market.
Buggy non-FPGA hardware is typically released because of the long design/test loop in hardware resulting in people releasing hardware when it is "good enough". Speeding that up by using
Re: (Score:3, Insightful)
Re: (Score:2)
This is exactly the reason why I will never, ever, ever want any hardware that is more "soft" than my own flesh and blood. That has enough of its own susceptibility to viruses, bacteria, getting smashed, getting clobbered by radiation, etc. for me!
Re: (Score:2)
Re: (Score:2)
though it is unfortunate, a few (thousand) bricked PC's, scrambled hard drives, and corrupted memory cards would do a lot to increase the percieved importance of computer security to Joe Moron. who cares if their PC is spraying worm traffic all over the net and sending gigabytes of spam, as long as the computer works nothing gets done.
if we went back to the days when getting a virus or worm was catastrophic people would be more careful.
especially if you make the worm multi-headed. inserts itsel
Re: (Score:2, Funny)
Re: (Score:2)
You just don't get it, do you? See now you can buy your new fangled octocore 10.3GHz 128bit processor with Ultra-Uber-Hyper-Mega Transport(tm) onboard, patch it and get the performance of a Pentium without the bug!!!!
Brilliant!!!
Re: (Score:2, Insightful)
So from a customer viewpoint (Score:5, Insightful)
I suspect I an do without.
Re: (Score:3, Informative)
Re: (Score:2, Funny)
Well, it's a marketing strategy that's worked well for Microsoft.
Signetics had something similar in 1979. (Score:3, Interesting)
And isn't this the WHOLE reason for Altera and Xilinx???
Re: (Score:2)
Re: (Score:2)
Yes, it is. I used to work at Altera way back, and still have stock. Make more hardware out of expensive FPGAs with their huge profit margins? I'm all for it!
Wait a sec... (Score:5, Funny)
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?
Re: (Score:3, Funny)
Linux doesn't even come close in consuming memory and adding vulnerabilities, but it is catching up!
Re: (Score:2)
Yeah, that 89% idle and 1.3GB of free RAM definitely parallel Vista. Especially seeing
Outdated? (Score:2)
Re: (Score:2)
Buggy hardware AND software? (Score:4, Interesting)
Hasnt the lessons that have been learnt by the software industry had *any* impact?
Re:Buggy hardware AND software? (Score:4, Insightful)
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: (Score:2)
Re: (Score:2)
Re:Buggy hardware AND software? (Score:4, Informative)
For example, here's the summary one for the Athlon 64 family (warning - pdf link):
http://www.amd.com/us-en/assets/content_type/whit
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.
Re: (Score:2)
Let's face it. Since the invention of the winmodem, hardware quality has been getting worse and worse. What you say is happening right now. Maybe not in CPUs, but lots of types of hardware already follow that idea. At least with phoenix I'd have a chance of getting that junk patched.
.0 release of AMD's new 760MPX chipset, complete withou
FYI, have a tyan tiger, so I'm a victim of a
Limited useability (Score:5, Informative)
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... (Score:5, Insightful)
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.
Phoenix, eh? (Score:3, Funny)
Hmm, he might want to work on changing the name from Phoenix. Good thing the summary says its only "dubbed Phoenix," not that it's the final name.
What's that you say? No, "Firebird" won't work, either...
Re: (Score:3, Funny)
I guess this means... (Score:2)
Introducing WaterOtter®—the most advanced, least well-backed technology ever created.
(Damn browser guys, always taking the good names...)
What if you can't patch (Score:3, Interesting)
This could make hardware manufacturers cut QA costs at our expense. Yay!
If I'm missing something... (Score:5, Informative)
exactly what is stopping malware2.0 from killing my processor?
Re: (Score:2)
exactly what is stopping malware2.0 from killing my processor?
A hardware switch or button that needs to be set in program mode.
Re: (Score:2)
Most PC's don't have recoverable bios backups, so most PC's can be all-but-bricked by malware that corrupts the bios. For most people who aren't into pulling chips, that's completely bricked.
It's an unsuccessful virus that instantly kills its host. Malware these days goes to quite some lengths to avoid notice so they can actually execute their intended purpose.
Re: (Score:2)
what, like, killing their hosts on April the first, or something?
Re: (Score:2)
Re: (Score:2)
Re:If I'm missing something... (Score:4, Insightful)
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.
Re: (Score:2)
bleh (Score:4, Interesting)
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.
Re: (Score:2)
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.
I think this would only be used to fix a design problem. Defects in silicon are spread randomly across the wafer, meaning that the fault(s) in each faulty chip are not the same. It would not be worth the effort to track down where the defect was and create new logic to avoid it just to fix one chip on the wafer.
They've already been there, done that! (Score:3, Informative)
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
Stupid post of the day. (Score:2, Insightful)
a) Duh, duh, duh. This ain't no news, FPGAs have been around for quite a while, and being able to soft-repair hardware is an old idea that is being used where practical. Sheesh, slashdot is really headed for slushdot these days.
b) Great, so now we can get more defective products quicker, be on hold with tech support longer, and spend our own time/money fixing the products under warranty that we've alre
Is this guy serious? (Score:4, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
no no NO! (Score:2)
We already have to worry that software products don't work and will be apllying endless patches to it, not hardware?
What about malicious attacks?
No I was to busy being alarmed to read the article.
It's like microcode... (Score:3)
Spell it out: Field Programmable Gate Array (Score:2)
A professor in optical systems discover that a light bulb screwed into a socket starts to emit photons.
I already beta-test software for free.. (Score:4, Insightful)
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.
Great (Score:2)
Oh wow, really? (Score:3, Interesting)
The other solution was a traditional ASIC. Under 1/4th the TDP of the competitor, a 50-fold decrease in latency per-operation, and on the first default run, got 90% of the theoretical performance, 96% after tuning. All this at a lower cost-per-part in production by about 200 dollars.
We were skeptical of both vendors for different reasons, neither vendor was allowed to give us extra hand-holding until the first vendor was so embarassingly bad we let them go hands on with us because we were *certain* we had to be missing something if it was that embarassing. Even after giving them unprecedented advantage to offset initial results, they couldn't come close to touching the other offering.
I know, a better company could have done better, probably, but the cost delta of FPGA and ASIC was not their fault, and the TDP of their parts, while likely worse than they could have done, probably would have been higher regardless. As another poster pointed out, its more difficult in general to clock up FPGAs than ASICs, and so performance will suffer.
FPGAs have their place, and a huge benefit is prototyping. I've seen a number of companies do a proof-of-concept with an FPGA, go forward with a demo, but when time comes for mass-production, it's most often implemented as an ASIC. After decades of dealing with hardware bugs, the industry at large has gotten very good at glossing over the rough spots in firmware. Sure, some hardware bugs can never be addressed in such a way, and as a consequence, your testing has to be better up front and inevitably slow down a release process due to a fear of post-release returns, but that is a *very* healthy fear to have, and it ensures the quality will be better at release time than your FPGA-reliant competitor. First to market is generally an advantage, but it is also a *huge* opportunity for embarrassment and sending your early adopters begging for your competitors competent ASIC implementation, with a low bar to beat as well.
This was news (Score:2)
ROTFL (Score:2)
Oh, boy! Defective by (lack) of design... sooner!
If there's anything wrong with hardware and software development, its that there isn't enough quality testing done prior to shipping. How does this do anything but encourage p
This is going to be LOTS of fun! (Score:2)
Can't read the screen? First you call the O/S manufacturer, then you call the video card guys, then you call the RISC chips guys, and so on.
That'll be loads of fun.
Oh joy. The value is I can get more buggy crap. (Score:2)
UGH. I'm so sick this attitude that it is beyond description. ASUS makes some great gear, for example, and the worst software for that gear I've ever seen. Netgear is the same way. The crap both companies turn out is low quality and it's clear that their focus is so hardware centric that they see the software as a necessary evil that the users need in order to use the
Process may already be patented by Intel (Score:2)
This patent seems to cover redundant circuits and one time fuses to patch them and a disable fuse to prevent end user changes. The repairs can be made after packaging. This is not to change code, but to increase manufacturing yeild. A few bad bits can be replaced by patching in redundant spare memory instead of trashing the die.
Quote (Score:2)
Hahahahahahahaha. Anyone who thinks that it's easy to patch several tens of millions of machines in customer homes or offices is an idiot.
If they could fix the problems later... (Score:2)
Is this guy for real (Score:3, Interesting)
Re: (Score:3, Informative)
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
Wafer scale integration (Score:2)
The idea was that you would design a wafer with a bunch of RAM units on it, and have a control patch with a bunch of fusible links. You would test the wafer, and find out which RAM units were good and which were defective; and then you would blow the fuses to take out the defective ones and connect in the good ones. In theory, with decent yields, you would get
Not really all that wonderful (Score:3, Interesting)
We already have Microsoft paying hardware device OEMs to use PICs and not release the driver code to any but closed source OS'es, so this just makes it easer to take the MS dollar and shut out OSS. A few may resist, but the surest way to kill OSS is to make it impossible to have drivers that work. In a perfect world, this wouldn't matter. We live, however, in a world far from perfection.
It worries me, if for no other reason than it's likely to be abused. How long until we see a motherboard that requires the use of closed source drivers to enable the keyboard port, or be able to use block or memory devices?
Let me get this straight. (Score:2)
1. Designs can be released before thorough testing is done meaning that potentially life threatening (or at least data threatening) errors can be introduced requiring months of waiting for a fix.
2 Now that you CPU can be on the fly re-programed it opens up a whole new world of viruses and worms.
I envision conversations with your auto dealer now. "Yes sir we understand that the cars brake system locks up randomly, but the CPU manufacturer has assure
But, quality _will_ suffer... (Score:3, Insightful)
Re: (Score:2, Funny)
> So now, consumers will be providing beta testing services for the hardware, in addition to the software.
So what the parent is basically saying:
"Look out for the new EA Console(tm), coming soon to a store near you! Runs* all your favourite games!"
Re: (Score:2)
Re: (Score:3, Insightful)
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).