Slashdot Mirror
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.""
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.
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.
!#@%*)anks for hanging up the phone, dear.
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.
Trust the Computer. The Computer is your friend.
"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.
Don't blame me, I didn't vote for either of them!
"National Security is the chief cause of national insecurity." - Celine's First Law
That was basically my read as well. It sounds like there may be something interesting in the automatic error detection, but the writeup is much too vague to be useful.
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.
If it's not on fire, it's a software problem.
Look, I'm not even a geek. I'm just some luser, and even I in my eternal stooooopidity could tell you:
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 already paid for. Someone, please shoot me!
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.
Just because it CAN be done, doesn't mean it should!
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.
And what happens when someone writes a worm that modifies this to *create* errors? It could be pushed to the extent that the processor is completely crippled. A virus could really take out a system this way; you can't even start over with a clean OS install if there's no processor to do the installing. There goes your expensive new system....
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.
---- Booth was a patriot ----
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.
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.
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).
If J.K.R wrote Windows: Puteulanus fenestra mortalis!
It all about volume. If you're only making 1-1000 of something, then an FPGA is way cheaper than an ASIC. High end devices often have low volumes (per revision), but even a low end device makes sense with an FPGA if you aren't selling that many of them. For the in-house robotics projects that are being done in my lab, they are indispensable since they can be used for replacing small logic chips and most of the glue logic; It's hard to beat an ARM chip with an FPGA next to it :)
The Phoenix system does seem to be unique in the way it combines some existing ideas, but a lot of the whitepaper reminds me of HP NonStop or IBM z-series. What else is Phoenix besides a software-reprogrammable, chip-level CPU supervisor that attempts to catch errors by examining logic states and cache function, provide some level of sub-instruction-level fault-tolerance via selective instruction retrial and/or other hardware error handling routines, and allow semi-permanent modification of the CPU's behavior by taking over control logic on-the-fly as needed? They do acknowledge in the paper that Transmeta chips can do things like modifying the behavior of the virtual CPU by changing the code-translation algorithm, but I'm surprised I don't see more discussion of Big Iron tech.
;) I'd have called it "Phoenix on-chip error-correcting logical supervisor" or at least something descriptive like that.
;)
It sounds like maybe the "big breakthrough" is that the Phoenix design is supposed to be on-chip, universal (in that it can be slapped onto nearly any architecture), and systematically scale to any complexity of CPU design (allowing it, say, to be added to a network processor, one of the given examples); this is something of an improvement over the existing fault-tolerating-computing market, but I wouldn't call it a technological revelation. Maybe the selling point is that Phoenix can be easily added to an existing chip and does not slow down the chip's existing logic except in the case of an error condition. In a way, that's an advantage over the approach (seen in some IBM mainframes) of building a virtual, fault-tolerant CPU out of two redundant (step-locked) CPUs and an external supervisor, since it's cheaper, but I would worry that Phoenix would encourage chip designers to continue designing bug-prone, imbalanced, complicated architectures rather than try to re-think design approaches which are apparently consistently resulting in buggy and hard-to-test chips.
Plus, "Phoenix" is an over-used name, and the fact that man computers have a "PhoenixBIOS" might cause some confusion.
DISCLAIMER: This comment is somewhat complex, and there's probably no realistic way of re-writing it for accuracy quickly. Whenever you, the reader, find an error that has not been previously documented, just reply with "BENNU-SYSTEM COMMENT LOGIC PATCH: " followed by a correction so that future readers can enjoy a reduced number of defects.
-os
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.