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.""
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?
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.
From the wiki link:
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?
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.
It was called a ROM Patch.
And isn't this the WHOLE reason for Altera and Xilinx???
Dog is my co-pilot.
"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?
All your 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 are belong to us
Hasnt the lessons that have been learnt by the software industry had *any* impact?
--- perl -e 'printf("%s\n", pack "H*", "7369670a676f6c677940676f6c67792e6e65740a2f736967")'
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.
I'm out of my mind right now, but feel free to leave a message.....
"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!
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...
R.Mo
Supposing a defect in this post-releast-modifiable hardware makes it impossible to connect to the internet? Good luck downloading a fix! :-P
This could make hardware manufacturers cut QA costs at our expense. Yay!
I like basketball!!1!
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?
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.
"National Security is the chief cause of national insecurity." - Celine's First Law
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!
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.
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.
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 FPGAs can actually help good design and improve first-release quality. On top of that, it also gives the flexibility to change things later.
Engineering is the art of compromise.
...except slower and more expensive.
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
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.
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?
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
I'm surprised anyone would think this is news. Also, as it stands today, some companies have *entirely* too much faith in FPGAs to get them through. We had two companies come give us product to try. Both implementing the exact same technology, one with an FPGA design. They talked about how wonderful FPGAs are (as if they were new to them) and that they were perfect for large-scale deployment, and they could fix *anything* in firmware. During our evaluation, despite their claims of how well it performed, we contorted the tests all over the place to meet 70% of the 'theoretical' performance, with *huge* latency penalties on any given operation no matter how we sliced it. All this coming with the bonus of an abnormally large TDP of the part.
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.
XML is like violence. If it doesn't solve the problem, use more.
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!
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
First of all, this guy is way behind the times. Secondly, FPGAs are significantly more expensive than ASICs. Third, their performance is slower. What he's suggesting is akin to building all new homes out of lego in case we change our minds about the design after it's delivered. Nobody would go for it because we live in the Walmart society now, where price is the only motivating factor in purchases. Nobody wants to have to download a patch to their brand new widget either, just because the vendor couldn't take the time to debug it before shipping (not that we don't have the same situation with firmware revisions even today).
"I have never let my schooling interfere with my education." - Mark Twain
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?
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
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 month in space, if you start with a thousand of them? That would still give you 83 years and 4 months of operation on the world's most highly-available super-redundant platform.
(Since I'm in trivia mode, that would give a deep space probe a maximum range of 21 light-years, using NASA's 15-year-old designs for a 50 Km radius solar sail, which NASA estimated would hit 1/4 the speed of light by the time it reached the heliopause.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)