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?

[CuriHP]

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.

Re:what?

[WheelDweller]

Yeah, I have to agree; I was programming 1702's to act as address decoders WAY back in 1978- probably the lowest-rung of programmable hardware. These devices are great, but hardly a breakthough.

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?

[d3matt]

Yea, we use a lot of FGPAs in our inhouse product. They're nice because you can completely change functionality on the fly or fix bugs on the rare occasion the hardware is at fault.

Re:what?

[SnowZero]

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 :)

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?

[Anonymous Coward]

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.

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. ;) I'd have called it "Phoenix on-chip error-correcting logical supervisor" or at least something descriptive like that.

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

Re:what?

[lavid]

My roommate had him as a professor last semester. According to him, it's the latter.

Re:what?

[Anonymous Coward]

Hear that? That's the sound of overhead killing your performance.

Re:what?

[snowgirl]

When I was first reading about FPGAs, I think I read that they are used on many first-to-market products. Think about it, if you design your product with an FPGA that will eventually be replaced by a regular ASIC chip, then you can send it off to be constructed while you're still working on the final designs. Patch the ones that arrive with the FPGA, and once you've sufficiently tested the deal, switch to an ASIC chip for cheaper results.

Seriously, FPGAs are WAY more expensive than their ASIC chip equivalents... It's really only useful for intial production before your design is set in stone (or do we say "etched in silicon" now?)

Re:what?

[hernyo]

In the 80's they invented Rapid Prototyping techniques. They used it only for designing prototypes. Now the technology has advanced so much that they are using the same techniques for Rapid manufacturing.

The same can happen with FPGAs - in the beginning they used them only for designing prototypes, but in time they will be good and cheap enough for using them as reprogrammable microprocessors, probably manufactured in small series, not million-plus multi-gigahertz gaming procs.

Re:what?

[AaronW]

I think it depends... there are now some pretty cheap FPGAs. Xilinx has one for about $2.50 now. If you can get rid of a bunch of glue logic or several chips with an FPGA, the FPGA might actually be cheaper. Though in these cases the device probably cannot be updated in the field. It takes a lot of volume before it makes sense for someone to create an ASIC these days.

Re:what?

[quarkie68]

Yeah, I am not sure I would buy this either. From a security view point I would like things to be read only. It is not the panacea of all assurances, but in an era of stealthy malware, can you imagine the effect of a code re-engineering contaminating a patch that starts rolling out re-programmable FPGAs? Well, this could be the scenario today with stealthy rootkits and re-programmable BIOSes. But I have to definitely give the thumbs down for the "shorter time to market" bit. We all face the negative effects of bad software quality as a result of the increasing pressure for companies to release quickly. Finally, before talking about the effectiveness of deploying software with FPGAs, my own view is that the tools used to help the programmer in the process of porting code to an FPGA platform have a looooong way to go from a usability perspective. GM

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.

Re:what?

[ch-chuck]

Maybe the professor's research budget is up for review shortly and he had to come up with something quick. You know, publish or perish!

Re:what?

[Alioth]

Sir Clive? Reviled? Hardly - Sir Clive has a great deal of respect (especially by those who grew up with the Sinclair Spectrum). He certainly wasn't reviled. We liked Sir Clive because he brought an affordable colour computer with decent capabilities to the masses (the Spectrum was about 1/3rd of the cost of the Commodore 64).

Re:what?

[Prune]

Why are you such a fucking cretinous imbecile? Read the fucking paper the article is based on.

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?

[Bert64]

I still have a transmeta based laptop...
It would be good fun to reprogram it, or even just work out how to compile code to run directly on the core without the emulation layer.

Re:what?

[coinreturn]

Actually, FPGAs are also used for limited-run production, like custom hardware. It is almost impossible to get a foundry to run chips for an order under $1M (sometimes even $10M). So, when production means less than 1K units, FPGAs are cheaper, sometimes WAY cheaper. Yes, the article was about PC's, but I'm talking about FPGA's in general - they're ALL we use where I work. The reprogrammability is killer for updates and algorithm-specific usage.

Also, the person who claimed "orders of magnitude slower," is a few years behind. I routinely reach clock speeds well over 200 MHz for complex logic, and can take data in at 12 Gb/s, 16-bit DDR.

Re:what?

[Anonymous Coward]

I think what is new here is the idea that a HW manufacturer should be able to distribute HW (FPGA) updates
to his customers HW. This would also create excellent opportunities for distributions of new HW-viruses.

Re:what?

[Anonymous Coward]

I was doing this 10 years ago with Xilinx chips.

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.

Re:what?

[Anonymous Coward]

Both a dumb writeup and a dumb researcher.

More like a dumb /. poster who takes a dumb writeup at face value.

Hint: you don't get tenure at the 5th ranked CS school in the country by being "dumb".

Re:what?

[jd]

He was notorious (and fined several times) for advertising products that didn't exist, then using the initial income to build them. Usually to a lower spec than had been initially published. The QL was originally touted as 32-bit, but when it finally emerged, Sinclair did a really nice speech about how nobody used the capabilities of a processor beyond 8 bits anyway.

The ZX80 was cheap because it used rejected components, as I recall. And the squishy keyboard...? The Spectrum was ok - you can't compare it to the C64 as Commodore was overpricing and underspeccing everything at that point. The Spectrum's colour was ok, but rapidly outclassed by the BBC.

Both the ZX range and the Spectrum range were subject to heating problems and other reliability issues. When they worked, they worked great. They just didn't always work too well.

Re:what?

[gillbates]

Finally, CPUs have long supported the notion of microcode

I believe you could have saved yourself some embarassment by reading the article. The author specifically mentions microcode and explains why this approach does not work for patching processors. If microcode patching could solve every problem, then why did Intel go through a 500 million dollar recall when the FDIV bug was discovered in the Pentium?

Calling the researcher dumb doesn't make you look any better. In fact, I'm not sure how you consider the writeup dumb when it appears you haven't read it:

1. Your point about memory access bottlenecks is irrelevant, because the design proposed by the author doesn't impose any constraints on memory access. Rather, the FPGA is used to monitor signal lines to detect fault conditions, per programming.
2. The blurb about hardware failure is specifically beyond the scope of the paper, so I'm not sure why you mentioned it. Even so, I'm not sure why you would want to patch failing hardware. If the hardware has been compromised by something like thermal failure or over-voltage, you have no assurances that even the detection circuit works correctly. So you likewise could not trust any patching mechanism, either. The best solution for hardware failure is to build the system such that it can be detected, and route around the failed processor, and/or alert the user to have it replaced. Those are the only sane options - everything else relies on assumptions which may not be true.
3. The notion of designing silicon to mitigate the effects of hardware design defects and bugs is nothing new, but the technique is new. While I wouldn't consider it worthy of a patent, it does address the problem of recalling processors when a design flaw is discovered.
4. The author suggests using an FPGA, but I found nothing in the paper which suggested that using an FPGA is required. Moreover, I think the FPGA approach was suggested because it is likely that system designers would be familiar with using FPGAs.

Granted, it isn't earth shattering, but neither is it dumb.

Re:what?

[Wolfrider]

[[
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'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.
]]

I applaud your efforts. That's exactly what I thought when reading the /. article header: "Great, now we'll get even MORE crappy hardware as WELL AS crappy software!"

Average Joe end-user doesn't even like the idea of flashing his computer BIOS, cuz God knows if there's a power failure or glitch in the middle of the process, he's left with an expensive pile of junk.

While I'm an avid Linux user, I do tend more toward the "stable" releases - Ubuntu 6.06 LTS, Debian Stable/Testing rather than unstable, etc. You get older and a little more set in your ways, and things that were inconveniences before, start to get a lot more irritating. You Just Want It to WORK.

For all our sakes, I hope the manufacturers (continue to?) put enough effort into "doing things right before it ships" instead of taking shortcuts just so they can "beat competitors to market" and try to fix it later.

Re:what?

[Anonymous Coward]

There is a significant difference between a fault tolerance approach using two step-locked CPUs and the Phoenix approach. Two step-locked CPUs are typically identical die layouts -- A design fault in one die will exist in the second chip. A "patchable" solution would correct design faults. Fault tolerance is geared rather towards soft-faults in a CPU, the rare case where a bit flips due to a particle strike or other very odd random event.

Consider how lock-stepped fault tolerance works: Every retired instruction is compared against the same instruction retired on a different processor. Now lets see how this handles a design fault. Both processors will retire the same incorrect result. The soft fault case? Two instructions are retired, but with different results. The pipeline is flushed and they are re-executed, now with the same result. Error averted. How about the case of one processor having a hard fault, while the other processor is correct? In this case, the lock-step mechanism will be able to detect the error, but never know which processor is the correct one. The program will never make forward progress. But detection is far better than ignorance.

"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."

If you can figure out a cost-economical way to build a perfect, bug-free processor before the other folks in the industry, I suggest you take out patents and prepare to retire in Barbados.

So the big problem is the design fault. The Phoenix paper covers this. As far as naming goes -- it's an academic paper. Academic papers and projects get names to catch the eyes of researchers and industry designers, not users.

Re:what?

[lcsjk]

"Let's see now; We have not had time to finish the design,so lets put out the simple, almost working, untested version and then tell the customers to install a patch that will 'upgrade' the system for things that did not work at first." Maybe we can call it something like Windows.

Geese guys. THis concept is not new. The industry has been using this concept for years to introduce new products.

Re:what?

[julesh]

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.

ASICs have a habit of costing significant amounts of cash to produce, although you can get virtually unlimited numbers of them for not a lot of extra cash on top of what the first one cost you.

FPGAs have no up-front cost, but the incremental cost is reasonably high.

Current gen FPGAs can be run up to ~400 MHz if your design has a short-enough critical path. This is more than adequate for many applications.

Therefore, for low-run equipment that doesn't have particularly high performance requirements, an FPGA is probably the best way to go.

Re:what?

[jd]

I'd say about 75% of people with tenure are indeed dumb. Tenure is often about who you know, expertise comes from what you know, but neither hold a candle to true brilliance which invariably comes from what you don't know. The true greats, the intellectual genius' - these are not walking encyclopedias of knowledge. They're intellectual kids with insatiable curiosity. These are the people worthy of respect. The rest - ten years from now, you won't even remember their names. Well, other than the ones found guilty of deliberate fraud, assorted ethical violations or the like. Those are usually easy to remember - just not for reasons I'd consider worthwhile.

Ignorance? Yes. Ignorance. The moment you think you know the answer, before finishing the work, is the moment you doom yourself to a life of tedium. Knowing too much ruins a researcher. Knowing what others thought yesterday will tell you nothing about what you should be learning tomorrow. The knowledgeable can fill in the gaps, but they will never be able to reach out beyond.

There is a place and a time for knowledge, but partial knowledge is worse than worthless. It's never going to give you the adventurism needed to discover, and it's too blinkered to give you the skills needed to complete the work that has gone on before. You tell me about the ranking of the University, but so what? Manchester University and UMIST were ranked first and second in Europe for IT respectively for many years. They did some very fine work, too, especially in parallel computing and asynchronous computing. So? You're not using their work today and you are unlikely to see any benefits from their work in your lifetime. Does that cheapen their ranking? No. Does that make their ranking useless as a measure of the real value of their work? Yes.

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?

[Anonymous Coward]

KILL THIS article. FPGA aren't new they were invented in 1984. See http://www.xilinx.com/company/history.htm

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?

[Daengbo]

Exactly my thought. We've been living with Beta software released as final for some time now (and with much pain). Now this guy wants us to deal with Beta level hardware, too? Sound like it's good for management and bad for both customers and engineers.

I appreciate firmware updates that add features or fix non-obvious bugs, but increasing the number of problems we already have with software, firmware, and drivers by adding hardware to the list of incomplete implementations seems like a step in the wrong direction.

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:So, he's discovered the FPGA?

[arodland]

Pentium, uh, III? How about Pentium. P5. Pre-MMX. Up to 100MHz. Yeah, that one.

Re:So, he's discovered the FPGA?

[Anonymous Coward]

If your competitor beat you in the marked by offering buggy hardware or software early, then he was the smart one.

Re:So, he's discovered the FPGA?

[bill_mcgonigle]

Sounds like the hardware version of Windows. Every user would be a beta tester.

Welcome to the present.

The latest news... from 1984...

[feepness]

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?

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!!!

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

[Anonymous Coward]

Using shark-mounted frickin' laser-beams???

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.

Re:WTF?

[Loconut1389]

Even as stupid as the article was- it stated clearly that it enables hardware designers to fix bugs in the field (that's the Field Programmable part of FPGA)- the error would otherwise have been fixed in silicon (ASIC). Most people don't use FPGAs as anything more than a microprocessor- if you want to do more, they usually use something like a Virtex Pro which has an onboard power-pc in silicon.

Re:WTF?

[Loconut1389]

err I meant to say that the article also talks about self-healing processors- but (most people don't use fpgas.....(snip)... in silicon). What he's talking about isn't even self-healing, its just a new bitstream.

The way it was written it sounded like to unrelated thoughts.

Re:WTF?

[feed_me_cereal]

that's not the only problem... imagine what the virus writers will do with this one!

Re:WTF?

[Loconut1389]

maybe I was thinking too much like someone who does this for a living- responsible designers test out with FPGAs as much as they would with ASICs- perhaps even more so since they can get in more revisions before 'printing' the ASICs. If theres a teeny bug in the 'release candidate' ASIC, are you really going to spend another million to fix it? At least with FPGAs you can fix it before you send it out to customers. Most designers should be using FPGAs that way (even if not for prototyping, but for actual in-circuit use). The article does suggest releasing things preemptively, but I think that was an add-on by the writer, not the researcher. If anything, I'd give credit and say that in an instance where you know there's one bug left that will only affect 1/1,000,000 users, but it'll take a couple more weeks to fix, you could push out the hardware and send out the update when its ready and hope no one hits that bug.

Re:WTF?

[noidentity]

Yeah really, we all know how much more reliable software is compared to currently hard-to-patch hardware. I just can't wait until we have patchable atoms. "Sorry, we've just found that the new-fangled carbon atoms making up all 2032 cars will self-destruct in one week. Please install this new patch, which will take a day to complete transmutation."

Re:WTF?

[ThosLives]

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:WTF?

[Watson Ladd]

Not much. Virus writers have not been as nasty as they used to be in terms of payloads. No-one flashes BIOS anymore.

Re:WTF?

[fyrewulff]

I wonder if this is due to having a botnet being more useful than killing off potentional zombies.

Re:WTF?

[Max Littlemore]

One Pentium floating-point problem was bad enough.

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:WTF?

[Lehk228]

exactly


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 itself into executables included on disc images read by burning apps, slips itself into U3 thumbdrives, does heavy local network scanning with occasional ventures into the general internet, but not enough to attract much attention from an ISP, maybe scan 1000 hosts per day. each newly infected host starts encrypting files in my documents (and decrypting them on so moving to thumbdrive or CD won't indicate a problem on other machines). on the last week of infection the host corruptsfiles from random directories on removable media over 2GB, and occasionally will corrupt the entire drive on storage under 2GB. the last day every external storage accessed takes some damage, including FTP's or windows shares with delete and write permissions. when the machine suicides everything that can be hosed will. any known hardware tricks (such as massively OC'ing the video card) will be done, then the hard drive gets scrambled

Re:WTF?

[Eivind]

But there's a two-way balance.

If a worm is more damaging, it will, as you say, prompt users to take it more seriously.

But this will also tend to limit the spread of the worm. (even though getting dangerous ssslllloooooooooowwwwwllly as you suggest seems to work fairly well for HIV)

Re:WTF?

[Anonymous Coward]

If anything, I'd give credit and say that in an instance where you know there's one bug left that will only affect 1/1,000,000 users, but it'll take a couple more weeks to fix, you could push out the hardware and send out the update when its ready and hope no one hits that bug.

That's a scummy thing to do and I wouldn't buy anything again from a company that did this. It many not effect me this time, but a company that cheats it's customers will burn you eventually. On the other hand, often there is a feature which is buggy that only 1 in 1000 customers use. Then you can tell the customers that feature is broken and will be fixed shortly. There's nothing unethical about that, unless you plan to never fix it. I have purchased such products many times.

Re:WTF?

[Loconut1389]

That's sort of what I meant- and I said 1/1,000,000 which is far fewer than 1/1,000. I guess I neglected to mention to tell the customers.

If the quality doesn't suffer

[RedElf]

If the initial quality doesn't suffer because of this, then it will prove to be a nice update to hardware.

Um...

[Anonymous Coward]

...and this is new how?

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.

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

[26199]

Well, it's a marketing strategy that's worked well for Microsoft.

Re:So from a customer viewpoint

[Anonymous Coward]

What if I told you it could fix typos after you've submitted a post?

Re:So from a customer viewpoint

[Prune]

That point of view can't survive the hard reality that as complexity keeps increasing, thorough testing becomes impractical and eventually impossible. We've already gone through this threshold with software several decades away.

Re:So from a customer viewpoint

[horatio]

So we should just cease all QA because it is just too hard? That could certainly make the products cheaper to produce, but it still sounds like a cop-out. Is this acceptable for your car? The plane you and your family are riding on? Remember that these two things as examples, especially aircraft (fly-by-wire anyone?), are increasingly driven by software. The B2 stealth bomber basically can't fly without the constant adjustments to the flight surfaces made automagically by software. I wouldn't exactly call that a case for not testing because it is "impractical" or "just too difficult"

If you say that we should test /these/ things because they involve safety and risk loss of life and property, then doesn't that suggest that the software used these things almost certainly must be *more* complex than other devices (such as a television) because of the requirement that they must take extra measures to ensure that, for example, the 737's engine computer doesn't decide reverse thrust is a good idea at 35,000 feet?

Re:So from a customer viewpoint

[Prune]

It's mathematically impossible to prove that any system that is complex enough to be Turing complete will function correctly in all circumstances.

Signetics had something similar in 1979.

[Archeopteryx]

It was called a ROM Patch.

And isn't this the WHOLE reason for Altera and Xilinx???

Re:Signetics had something similar in 1979.

[JoeCommodore]

And before that system software designers were commonly working around late-discovered hardware bugs. (since the bords were commonly produced before the software was final)

Re:Signetics had something similar in 1979.

[Dahamma]

And isn't this the WHOLE reason for Altera and Xilinx???

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...

[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?

Re:Wait a sec...

[Frank T. Lofaro Jr.]

What competition is there to Vista?

Linux doesn't even come close in consuming memory and adding vulnerabilities, but it is catching up! :)

Re:Wait a sec...

[Kryptonian Jor-El]

But OSX does! and Vista surely didn't beat that to market!

Re:Wait a sec...

[gleffler]

Processes: 72 total, 2 running, 70 sleeping... 252 threads 19:56:37
Load Avg: 0.20, 0.32, 0.32 CPU usage: 4.8% user, 6.5% sys, 88.7% idle
SharedLibs: num = 228, resident = 65.4M code, 7.49M data, 16.0M LinkEdit
MemRegions: num = 11158, resident = 475M + 26.1M private, 311M shared
PhysMem: 276M wired, 468M active, 969M inactive, 1.67G used, 334M free
VM: 12.1G + 144M 194776(1) pageins, 0(0) pageouts

Yeah, that 89% idle and 1.3GB of free RAM definitely parallel Vista. Especially seeing how I'm running 72 processes, one of which is Firefox (which is a huge resource hog on any system.)

If you're going to troll, at least draw a proper comparison. Like KDE.

Outdated?

[Stevecrox]

In the university lecture I was in this year on FPGA's the big selling point was the fact you could do exactly this and how its used in industry. I'm not seeing any 'news'

Re:Outdated?

[HTH NE1]

In the university lecture I was in this year on FPGA's the big selling point was the fact you could do exactly this and how its used in industry. I'm not seeing any 'news'

Everything old is new(s) 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.

Re:Buggy hardware AND software?

[Jeff DeMaagd]

You can buy XP-based computers from the small business arm of some computer sellers.

Re:Buggy hardware AND software?

[Ernesto Alvarez]

Great, just what we need - hardware suppliers being encouraged to release buggy versions in the guise of fully working products.

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.

FYI, have a tyan tiger, so I'm a victim of a .0 release of AMD's new 760MPX chipset, complete without USB ports and faulty AGP system, and I'm also the (not) proud owner of a HP Laserjet 1022, that hangs whenever I send multiple jobs (or even a single not too complex one). You can imagine how much I esteem those two design teams (and the managers who decided to make an early release).

Re:Buggy hardware AND software?

[DigiShaman]

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.

Why didn't you just say "Creative Labs" and be done with it? If your lucky, they might be nice enough to release an updated Sound Blaster driver every OTHER year! It sucks, because they otherwise have great hardware :(

Re:Buggy hardware AND software?

[Anonymous Coward]

Since the invention of the winmodem, hardware quality has been getting worse and worse.

The problem with winmodems was not that work was done in software. A "full modem" just has a faster CPU than a winmodem and so can do all the processing on board, but it's still done with software.

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.

Re:Limited useability

[RyanGrob]

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...

Good point. Most likely users will obtain a spare PC just to serve the function of getting the patches and transferring them to the dead PC. Better idea is to create a bootable floppy or cd rom that can connect to the internet and can bypass failing hardware but then again, if the NIC fails....

Re:Limited useability

[Anonymous Coward]

> 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 no, you don't. FPGAs are way too susceptible to the radiation environment of space. By the time you put enough shielding on them, you could have made a system with multiple, separate hardware designs for fault tolerance.

Goetz

Re:Limited useability

[Prune]

Don't be so dense. As complexity increases, thorough testing becomes difficult and eventually impossible. We already went through this with software in its early days.

Re:Limited useability

[kent_eh]

Don't be so dense. As complexity increases, thorough testing becomes difficult and eventually impossible. We already went through this with software in its early days.

Difficult doesn't mean undesirable.

Shouldn't quality, or at least a reasonable chance of working properly be a goal for any company wanting repeat customers?

I see this as just another short-sighted rush for short term Max_Profits at the expense of the future survivability of the business.
Kinda like shutting down all your factories to boost this quarter's profitability, to hell with the future.

Re:Limited useability

[Prune]

It's not a matter of simply difficulty. It's mathematically impossible to prove that any system that is complex enough to be Turing complete will function correctly in all circumstances.

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:Oh great...

[Prune]

Idiot! As complexity increases, thorough testing becomes difficult and eventually impossible. We already went through this with software in its early days.

Re:Oh great...

[camperslo]

Oh great, now we'll have hardware as crappy as software

But think of the potential. Perhaps even malware could rewire the hardware? Wouldn't that be extra special...

Re:Oh great...

[Brandybuck]

So eventually hardware will become so powerful, that it's shear complexity will cause complete abandonment of testing? We'll have electrocuted customers, with manufacturers claiming it's not their fault...

MOD PARENT UP.

[Anonymous Coward]

Yeah, so if I had mod points...

The "Field Programmable" bit of FPGA describes exactly the idea that a Gate Array (hardware logic chip) can be programmed in the field, ie, not in the factory.

Screw the end user

[Anonymous Coward]

Great, just what we need. Technology to enable manufacturers to push more crap that doesn't work to market sooner so end users can become beta testers. Then they can obsolete the product by pushing even more crap to market before they ever get done patching the old crap that doesn't work. And the cycle of crap continues.

Having said that, what's so new about FPGAs?

Phoenix, eh?

[R.Mo_Robert]

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:Phoenix, eh?

[Anonymous Coward]

Hmm... it's very fox-like of him to a small bit of FPGA to correct ASIC flaws. It's sure to get companies all fired up about his product - I think the perfect name is thus FoxFire.

Re:Phoenix, eh?

[Godji]

Heh, I got a good one: how about.... IceWeasel!!!

What if you can't patch

[Sciros]

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!

Re:What if you can't patch

[Anonymous Coward]

if this were for a NIC or Modem of some sort (DSL/Cable/Telephone) sure- but no matter what, the manufacturer can send you a disc/usb dongle/whathaveyou that you can patch with (or you can download from another machine).

Patching hardware like software

[edbob]

I see problems with this approach. First of all, with the ability to patch flaws in the future, what is to stop a manufacturer from releasing a chip with a flaw just to get to manufacturing quickly. As we've seen with software, there could be serious flaws that cause security issues. Also, malware writers could make undesirable changes to hardware and might be more difficult to track and repair the damage that is done. I am more curious about the level of security that will be used to prevent unauthorized changes to hardware. Turning hardware into software will introduce the problems of software into hardware.

Someone make him shut up

[Anonymous Coward]

For the love of god, someone tell this man that his attitude (release now, fix later) is what has gotten us into the shithole of unreliable never finished software that we're stuck in. I hope he takes his "yay short term profits and screw everything else" attitude on a long walk off of a short pier.

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...

[dissy]

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?

A hardware switch or button that needs to be set in program mode.

Re:If I'm missing something...

[nuzak]

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

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: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.

Re:If I'm missing something...

[user24]

"so they can actually execute their intended purpose."
what, like, killing their hosts on April the first, or something?

Re:If I'm missing something...

[AcidPenguin9873]

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

What is stopping malware1.0? If you're using a modern x86 CPU (by modern I mean Pentium Pro or K6 and later), those have a microcode patch capability that can be used to modify any microcoded x86 instruction. Lots of instructions are microcoded, especially system software instructions that your OS needs. Malware could install a patch that does nothing, or locks up, whenever your processor tries to execute a MOV CR3 instruction to change page tables. Even better, it could modify the BIOS to *always* install the patch, and then your system wouldn't even boot.

Of course you'd have to know the spec for microcode patches on Intel or AMD CPUs (which is NDA protected) and then get around whatever encryption, hashing, signing, etc. that Intel or AMD uses. But, I'm sure the same security measures would be in place for these proposed hardware patches as well.

Re:If I'm missing something...

[toddestan]

A virus that kills its host before it has a chance to infect other computers is not going to spread very far.

Re:If I'm missing something...

[freeze128]

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

DRM 2.0

Re:If I'm missing something...

[nuzak]

Try spam and keylogging. Usually both.

No more so than software

[EmbeddedJanitor]

That's a bit like saying that software is crap because we can update it and to get good software we should ban software patching.

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.

Re:No more so than software

[Anonymous Coward]

That's a bit like saying that software is crap because we can update it and to get good software we should ban software patching.

No, it's crap because "first to market" trumps "doesn't fall over". The thrust of TFA was to trumpet the first-to-market possibilities.

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.

Re:bleh

[Quixotic137]

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.

No Joke .. bogus story

[Anonymous Coward]

No joke, any EE knew about this long before this stupid story.
Christ, I knew about FPGAs back in 1992 as an undergrad ... which implies that they were well know to the industry before that. And, it was blindingly obvious that this was possible then ... 15 years ago. In fact, we had labs where you did this - it wasn't the point of the lab but FPGAs were and "fast fixing" as we called it got you out of the lab quicker.

News for nerds ... apparently not hardware nerds.

But, quality _will_ suffer...

[msauve]

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

So now, consumers will be providing beta testing services for the hardware, in addition to the software.

Re:But, quality _will_ suffer...

[ozphx]

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

> 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!"

They should call it "SoHardware"

[freshmayka]

You know... the merging of Software and Hardware.. SoHardware...?
But seriously this sounds like a bad idea for stuff like x86 CPUs and 3D GPUs. The whole beauty of hardware is that it's fixed. You know it won't change and so do the engineers, hence they spend more time making the systems reliable and bug-free. Self patching hardware just sounds like a bad idea for consumers.
On the other hand, it could do well for what will become legacy systems in the future. Chips that are used in machines which need to operate for 10-25 years could definitely benefit from a system like this.

Re:They should call it "SoHardware"

[hchaos]

Actually, there's already a word for this: firmware

Stupid post of the day.

[Abuzar]

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!

Re:Stupid post of the day.

[Anonymous Coward]

How'd this make it onto slashdot anyways?

Two Words

[Anonymous Coward]

Hardware Virus.

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.

Re:It's a new way to use FPGA technology

[dhasenan]

And it would be difficult and expensive enough that the manufacturers would still subject their products to thorough testing. And probably expensive enough that it'll only be used in high-confidence operations, such as NASA hardware.

Re:It's a new way to use FPGA technology

[whoever57]

And it would be difficult and expensive enough that the manufacturers would still subject their products to thorough testing. And probably expensive enough that it'll only be used in high-confidence operations, such as NASA hardware.

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 force the chip to bypass it (interrupt the processing). I would expect that this would have to be accompanied with software that is able to work with the result of the "bypass" result.

Re:It's a new way to use FPGA technology

[stratjakt]

Cool, my Playstation 4 will come with a built in mod chip!

(if sony isn't too busy crying in the bathroom to develop a next next next next gen console)

Re:It's a new way to use FPGA technology

[amjacobs]

Like microcode updates?

Re:It's a new way to use FPGA technology

[Ernesto Alvarez]

More like an exception handler for the CPU.
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).

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.

Re:Is this guy serious?

[Shados]

Indeed. Hell, we see it all the time, being able to PATCH a software just means that it will be buggier on release, and never really get better than the unpatchable version... Thats whats semi-killed off PC gaming, since console games have always been released with less bugs than PC games have after the first 5 patches... though with consoles with harddrives and such, that might be history in a few years...

Re:Is this guy serious?

[RobBebop]

My thought is that the bit about releasing buggy hardware so we can patch it later was a bit of an editorial instigator. All things aside, a well designed general piece of hardware can be a major advantage. There are reasons that might make reprogramable hardware extremely useful. What if you could hit a few buttons and switch your cellphone from CDMA to GSM and use the networks that exist in other parts of the world? What if you could upgrade the Bluetooth in your computer as the standard evolves?

* editor's note: I've got no idea if these examples are feasible, but I can't think of examples of hardware swappability that I _know_ are.

Re:Is this guy serious?

[Anonymous Coward]

Quit talking about something you know nothing about. You should try reading up on FPGAs before you spout off clueless theories. The simple truth is you can make it impossible for people to access your hardware unless they know the hardware key to the non-volatile memory. There won't be any malicious patches, just shitty firmware to worry about. How the hell do you think that you can update your wireless routers?

Re:Is this guy serious?

[luckystuff]

In Russia, the hardware patches YOU?

Reliability requires redundancy

[Anonymous Coward]

Techniques like this could vastly increase chip yields. One of the limits to the complexity of chips is that it gets hard to produce very complex chips with no flaws. Being able to patch around flaws could bring a process from a 50% yield to a 99% yield. Implementing the system would, of course, be non-trivial.

An example of redundant systems would be communications and deep space satellites. It is so expensive to put the satellites into orbit that doubling the amount of some of the systems is actually not the most expensive part. For instance, if I need a mux with five channels it isn't that much more expensive to include six. It means I can still collect my planned-for revenue even if a channel fails. Otherwise, the failure of a channel would lead to a 20% drop in income. Also, my company would be viewed as less reliable and I would lose even more business on that account. Including the extra channel is almost a no-brainer.

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

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).

Re:Reliability requires redundancy

[smellsofbikes]

All memory chips and many analog or mixed-signal chips are modified after fab but before they're packaged. In the case of memory, they test the chip, find the bad cells, and use a laser to burn those areas/connections out, and then burn in duplicate extra sectors. Once the chip meets the required memory size and performance, all the remaining spares are burnt out, so the chip acts to specifications. Similarly, analog and mixed-signal chips are laser-trimmed for performance and accuracy. There's an enormous business in making the laser trimming systems and test systems.

Oh great!!!

[pandrijeczko]

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.""

So the P.O.S. unfinished game I just bought to run on the P.O.S. unfinished operating system I just bought is now expected to run on the P.O.S. unfinished PC I just bought...

If you've half a mind to go into marketing, that's all you need...

Re:Oh great!!!

[wellingj]

And if you were half of a decent consumer you wouldn't pay for P.O.S. unfinished products.

I blame the products of Microsoft, Electronic Arts and MTV on the complacency of the uneducated consumer.

Another opportunity for exploits

[jobin]

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....

FPGA does help first to market, and good design

[EmbeddedJanitor]

ASICs cost a lot to make and take a very long time. Much of this is due to the long turnaround times to do any verification and the costs associated with revisions.

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.

no no NO!

[geekoid]

This is bad, it means production design testing will be foisted onto the user.
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...

[Chris Snook]

...except slower and more expensive.

Spell it out: Field Programmable Gate Array

[viking80]

In other news:
A professor in optical systems discover that a light bulb screwed into a socket starts to emit photons.

Console Titles vs. PC Games

[Anonymous Coward]

Remember how console titles generally weren't very buggy? You know, they mostly worked right*, but then came PC titles and crashes became normal? Yeah, they'd have a shorter time to market, but I have this feeling they'd stop bothering with the fixes when it was no longer "cost effective" ...

* Yes, there were still bugs, and even multiple revisions of games--have Realm sketch an invisible enemy sometime. But I'd never have seen most bugs if there weren't tool assisted speedruns.

Great!

[DarkLegacy]

Now Microsoft can send a software patch to our hardware through Windows Update Manager and enable DRM on the hardware level.

Excellent!

"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.

Re:"regular" programmable logic

[Grishnakh]

Yes, you're talking about PLAs, PALs, and CPLDs. However, there's something fundamentally different about FPGAs that separates them from these other devices: FPGAs are programmed by an external ROM on power-up, so it's extremely easy to "reprogram" them by simply changing the ROM code just like you would with any firmware update (re-flashing, etc.). Those other devices must be physically removed from the circuit and reprogrammed in a special programming device.

In a lab environment, this isn't that important. But when you're dealing with devices deployed in the field to end-users, this makes the difference between doing physical returns/exchanges and just sending out a software update.

Re:"regular" programmable logic

[that this is not und]

FPGA's don't even need to be programmed by a ROM on power-up. The code for them can be 'blown' into them by another processor, and hence can be stored anywhere.

Re:"regular" programmable logic

[Thomas Shaddack]

Those other devices must be physically removed from the circuit and reprogrammed in a special programming device.

JTAG-enabled chips, other in-system-programming silicon (eg. ispGAL), microcontrollers with bootloaders... Dude, you're *so* 80's.

Re:"regular" programmable logic

[Grishnakh]

Sorry, my last exposure to CPLDs was in 1998, and that was on a legacy product designed earlier in the 90s.

Re:"regular" programmable logic

[WrongSizeGlass]

In the old days we used board level "switches" & "jumpers" and thought we were geniuses.


warning: The above content may test positive for sarcasm and/or could be a failed attempt at humor and should be taken with a pound of salt.

It's a new way to use PDFs

[Anonymous Coward]

I suppose you all could go to the source.

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?

Spell it out: Slashdot is broken.

[Anonymous Coward]

*rolls eyes*

And people wonder what's wrong with slashdot.

Read about the man before you put your foot in your mouth again.

Great

[JustNiz]

This sucks, as companies will presume its more OK to release buggy hardware now.

Oh wow, really?

[Junta]

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.

This was news

[Khashishi]

in 1980!

ROTFL

[SeaFox]

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."

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 products to be rushed to market even more? This also requires additional expense in adding an interface to the product to receive those updates, rather than just building it right the first time.

This is going to be LOTS of fun!

[DanielMarkham]

You think it's tough getting tech support now? Wait until field-patchable hardware hits the market.

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.

Hardware Viruses

[swaha]

Since this is "programable" there will follow a new plague of "hardware" viruses.
How does the inventor propose to defend against such things????

Fix it later? BS!!!!

[TavisJohn]

This is both good and bad. It would be great if a device needed an update because of a mistake. HOWEVER using this as a way to "Fix it later" so you can rush something to marked before it is ready, That is CRAP! There is enough bad software out there that they promise to fix, and never do. There are also devices that list features "Will be available soon" via software, and that never happens either! (I am referring to a video capture card that promised to have a TV guide app, but they stopped making the device after 6 months, and NEVER added the TV GUIDE!!!!)

I guess this means...

[game kid]

Introducing WaterOtter®—the most advanced, least well-backed technology ever created.

(Damn browser guys, always taking the good names...)

Re:I guess this means...

[Anonymous Coward]

"Introducing WaterOtter®--the most advanced, least well-backed technology ever created."

Isn't that a kettle?

missing the point

[fpgaprogrammer]

A lot of you seem to be missing the point and dismissing the article as system to allow designers to be lazy and release "faulty designs." The article was less about allowing bad designs and more about allow defective chips to work thereby increasing yield and product life.

Defect tolerant arrays are still not a new idea. Every single Playstation 3 that ships is assumed to have a defective SPU in it so that the Cell yield could be higher and thus the PS3 could be cheaper. FPGAs are an array of finer grained processing elements and thus have lower susceptibility to defects. Many people note that FPGAs suffer a performance hit to ASICs, though an FPGA is more comparable to a CPU than an ASIC since it is a general purpose device. There are many processing tasks on which an FPGA can achieve order of magnitude higher performance than a CPU due to parallelization and I/O efficiency. Some people said that the cost of FPGAs is very high. This is simply no longer the case: the Xilinx Spartan 3E chips can implement 1M gate designs for about under 10$. Higher performance FPGAs have cost factors which are largely attributable to market demand and any economic comparison with CPUs should be normalized to account for volume. Even still, if cost/gate scales linearly one could currently devise a 1 Trillion gate FPGA for $10M based on the Spartan's costs. Even if I'm a factor of 10 off on cost, it would be the most powerful supercomputer in the world at a bargain price.

Chip defect density will increase with decreasing transistor size to a point where the most economically viable chip is a defect tolerant array that can eliminate much of the semiconductor testing and yield costs.

The major missing piece is an operating system for these things to provide a simple and transferable programming model.

Oh joy. The value is I can get more buggy crap.

[CFD339]

So we can get things to market faster knowing we can fix the bugs in the chips later -- after the user fails to get the promised benefit.

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 fabulous new hardware they're buying. This attitude of "Fix the software after we ship" means you can almost never rely on the software that ships with products from these companies. Unfortunately, sometimes the patches are worse. Asus in particular makes me ill with this. My P58-N-SLI motherboard is amazingly fast, but the update software is junk and the most recent bios patch was so bad I almost couldn't back down from it.

Sounds to me like this kind of chip would be a red flag for me to dump the product back on the shelf at the store.

Why This Is a Bad Idea

[The_Shattered_Maul]

I've been a reader for some time now and have been meaning to create an account. It was this article that has finally prompted me to do so..... As a computer science major who is currently focusing a great deal on the electrical engineering portion of his curriculum and who dabbles extensively in digital circuits, I've gotten to know very well an important facet of the design process, "The Engineering Method". This idea is actually at the very heart of anything which is properly engineered. I compel anyone who is reading this comment to google "The Engineering Method" before continuing. Those who are familiar with proper engineering methodology should find concepts (if true) presented in this article deeply...deeply...troubling. When engineering anything, be it a bridge or a digital circuit, certain steps are taken to ensure that the design is WITHOUT fault. Even if a device such as a microprocessor is incredibly complicated, you always insure the design is without fault before allowing it to be released. Would you design a car with the intention of fixing possible faults after production, or even a bridge? That is simply bad engineering practice and to be quite honest, unethical. Such a device has no business being put on the market and could, in fact, present some very real dangers. Suppose such a device were installed in a life support system or even a car, a device with an ACCEPTED high potential for fault. Further more, it's sacrificing the performance of a fixed function circuit with a slower PGA all for the sake of making up for poor engineering. This is in effect replacing a simple design with a more complicated one which is also poor engineering. But enough of my ranting. I really must make a comment on the deeper issue I see here which is that of a non-engineer trying to solve an engineering problem. The person who is proposing this system is a computer scientist. A computer scientist specializes in solving problems using computers via software. It's my assumption that he saw an engineering problem (in this case, the complexity of designing digital circuits vs. cost of development time) and decided to try and solve it. It was only natural of his to do so via a software approach. I give him credit to making the effort however the resulting solution proposed is inappropriate. Again, I'm making assumptions here, but he is a scientist and not an engineer, and perhaps wasn't aware that such a solution caters to bad engineering.

Re:Why This Is a Bad Idea

[Anonymous Coward]

Okay, your comment has motivated me to respond. Oh, how niave, young computer scientist. Let me begin:

1. Dr. Torrellas has a PhD in EE from Stanford. It so happens that when you do computer architecture, certain schools classify that as computer science, others as computer engineering, and others as electrical engineering. I assure you that Dr. Torrellas is a very highly respected Computer Architect -- revise your assumptions about his background. This is not someone who was optimizing quicksort one day and then said, "Ya know, maybe I should fix hardware like a software bug".

2. Everyone has repeated this junk about some sort of FPGA. It's not necessarily an FPGA processor. Even so, the critical path is not the FPGA component.

3. Every released processor -- and every chip that I know of -- has errata. IE, bugs that were either extremely rare or trivial. Processor vendors like Intel and AMD have never been able to find all of these before releasing their chips. Recall the Pentium Floating Point divide bug -- and how expensive that was to recall and fix. Dr. Torrellas's proposal is to build in a very small amount of circuitry into a high performance processor that does a small number of simple tests on control signals, and then compares these control signals against a very tiny library of bugs that were discovered after the product shipped. When a match is found, the small circuits correct the bug. Now, instead of having to list these as "errata: Make sure the compiler never groups instructions like this", Intel could list the bugs as "errata: If your compiler groups instructions like this, make sure that the processor contains this patch". This would enable a lot of features. Keep in mind that most bugs are for the extremely rare cases (Like the folks who actually needed super high precision floating point math).

So in essence, this proposal is to safely augment processors with small repair mechanisms to correct the bugs that they are currently shipping with -- NOT to suggest less stringent quality control for designers.

So get off the high horse. Don't feel too bad though. You just read an article that mangled the original idea, and it's fun to complain loudly.

Isn't this like the lazy director?

[iminplaya]

Aaahh, That's good enough. They'll fix it in post.

I'm not sure I understand. Are they saying that being able to put out more defective chips because they're too cheap to test them first is a good thing? What's good for buggy software is good for hardware, I guess. Everyday is Patch Day...

Process may already be patented by Intel

[Technician]

http://www.freepatentsonline.com/4441170.html

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.

Can't believe they haven't tried already.

[Kadin2048]

And it would be difficult and expensive enough that the manufacturers would still subject their products to thorough testing. And probably expensive enough that it'll only be used in high-confidence operations, such as NASA hardware.

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 long been designed with a high degree of flexibility in the hardware, so that as much stuff as possible can be patched and fixed in software. (A while back there was a story about Voyager and how the NASA guys had done some software patching to make it last longer by reducing power consumption.) Actually, I'd be very surprised if some NASA engineer somewhere hasn't considered using FPGAs already, in order to get the additional flexibility and fault-tolerance that being able to re-jigger your hardware from millions of miles away would bring.

Re:Can't believe they haven't tried already.

[2short]

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...

Re:Can't believe they haven't tried already.

[Jerry Coffin]

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...

With your typical Xilinx FPGA, power consumption would be the least of your problems. Even with unlimited power, single event upset problems would prevent them from being usable in anything you put into orbit. There have been a number of white papers written on this problem, such as from Xilinx and Altera as well as Actel (sort of) [PDF warning].

For the people talking about use only in low-volume items: I recently looked at the innards of a couple of thoroughly mass-market oriented LCD TVs that each included an FPGA. A small FPGA isn't necessarily all that expensive, and can allow things like doing a single physical design that works with either PAL or NTSC, depending purely on how you program one part...

Re:Can't believe they haven't tried already.

[ConceptJunkie]

NASA's hardware flexibility is legendary. They have literally reprogrammed hardware in space and given it completely new capabilities, and in the case of Voyager, managed to get them to visit two whole planets that weren't even in the original mission plan. We're talking billions of miles here. In terms of mission critical hardware, especially when it is inaccessible, this development could be really useful.

However, the idea of taping a FPGA bag on the side of your OEM embedded processor and shipping hardware patches implies to me even more products that are shipped before they are done, and we users once again have to live with the consequences. The excerpt above claims just that. It is literally describing pushing testing further down the line to get something to market faster, and you know that invariably means it ends up in the paying customers' laps.

I can see it now: having to download and install patches to my vacuum cleaner, garage door opener or anti-lock brake system.

Of course, it can have its up sides. "Sorry dear, I can't cut the grass, our lawnmower model has been chopping off people's feet and I can't patch it because the Internet connection is down. Can you get me a beer?"

p.s. We already have software, hardware and firmware. What will this be called? Hardish-ware? Stiffware? Dent-resistent-Ware? Firm-But-Yielding-ware? Pert-Yet-Supple-Ware? Oops, definitely not that.

Re:Can't believe they haven't tried already.

[2short]

That makes sense. As I mentioned, I was having these conversations about 10 (or 15 now that I think about it) years ago, because my friend was ggetting her hands on FPGAs which were new and cool. So I think she mentioned power consumption as one obvious deal-killer, but there wasn't any suggestion they were ready to launch otherwise.

Someone's taken over Slashdot

[tknd]

I say someone has hijacked Slashdot.

In other news, read about 10 Firefox extensions you should avoid.

It's not really BS . . .

[Anonymous Coward]

The paper describing Pheonix has won some noteworthy awards:
* Best Paper Award, MICRO 2006, December 2006
* Also appears in the IEEE Micro Special Issue: Micro's Top Picks from Computer Architecture Conferences, Jan-Feb 2007

A quick google search sends you to his UIUC homepage http://iacoma.cs.uiuc.edu/~torrella/ where you can read the full paper. C'mon guys, he's a prof at UIUC, he's not going to announce he invented the FPGA, part II. The paper's actually pretty interesting

This is news?

[Anonymous Coward]

Wow - professor discovers what FPGA designers have been doing in industry for 10+ years. How is this news? Jeez.

The real use

[Anonymous Coward]

Meanwhile, somewhere deep in a Redmond lair, Steve Ballmer and Bill Gates are eagerly licking their chops, eager to see these patchable hardware devices and the inevitable Windows-only patch installers...

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

Great!

[Anonymous Coward]

Since shipping operating system software before it was ready and just patching it later has worked out so well, it's only logical to do the same thing with hardware. /sarcasm

EEPROM & Firmware Updates

[rangans]

All FPGA's have cross-point which are connected are left open based on a bit stream. This bit stream is usually present in a EEPROM/EPROM which you program and on startup this program the FPGA. This has been out there in most networking (ever done a firmware upgrade) and other backplane processors. One important reason this is not sued in main stream processors are the time to boot-up and program the cross-points. Also Processors these days tend to run at ASIC timing optimized speeds which an FPGA can never support (mainly because of the increased wireload delay caused by long cross-point wires). One other good reason is processors these days tend to heat up a lot (about 100C) and there is no reliable high-temperature EEPROM that would have reliable long life at this temperature. I am really not sure if this guy has been able to address atleast one if not all of these challenges.

FPGA as an extra function unit

[RepCentral]

The FPGA could be used as an extra function processor in cases where new or faster functions are needed that are too slow when first implemented by the processor. The designers could hang the FPGA off of a main bus and allowing the processor to re-flash a ROM that holds the bit stream when the FPGA boots.

This could be great for media devices. It wouldn't fix badly designed hardware but for cases where they want to add some extra functions to extend the life of the product until the next product design is ready. If said new functions don't fit in the processor time cycle for the smooth functionality, they could use the FPGA to implement processor intensive functions and therefore extend the device for a while.

Maybe new for consumer devices?

[systemeng]

This is old news. We were doing this in military devices since the early nineties. When I worked on some flight computers for a mystery product at a defense contractor, there were all sorts of places where an ASIC had a problem and that they had added a programmable logic device to clean up the problem. In fact, I think the designs left an extra programmable logic device for that purpose. Same as when I worked in semiconductor test equipment. At a vendor of automated chip testers, there were many functions on the system that had to handle unbelievable problems and occasionally a mistake was made in an ASIC. Frequently, a patch was tried to the software to make it work and if it didn't work, the functionality was offloaded to an FPGA where the new improved version of that function could be placed. Of course if the mistake was too bad then a very costly ASIC spin had to occur. . .

Thanks for the link

[mbessey]

It's an interesting idea. It's somewhat amusing that early on in the paper they mention the Pentium FDIV bug as an example of a processor defect that triggered an expensive recall, but their proposed mechanism wouldn't be able to detect and fix that sort of problem.

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.

Quote

[kabdib]

"We know how to fix software really easily."

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...

[Ant P.]

They'd release rushed, shitty hardware that wouldn't work properly until you connect to the internet to patch it, and which would be susceptible to viruses. Viruses that could reconfigure your processor to short the +5V to ground. How fun.

Is this guy for real

[RobinH]

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).

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.

Re:Is this guy for real

[RobinH]

Where I work they develop ASICs for spaceflight so they only build a relative handful, and it doesn't amortize out as well.

I thought we were talking about consumer level devices here, sold in the quantities of 100,000 plus.

great more defective hardware

[timmarhy]

"why produce hardware that works when we can patch it later if anyone complains loud enough?"

shittest idea ever. that is exactly how this will be used. to produce slow, bug riddled hardware that will drive evenone nuts.

Thank you.

[kevinoliver99]

I had a really good read on this, very detail, and very useful information. Thanks. Flv to avi http://www.avi-converter.net/

True

[Weaselmancer]

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.

Idiot

[Anonymous Coward]

I took a class from this Jackass once, he is an idiot.

Wafer scale integration

[steveha]

This reminds me of something I read about a few years back: "wafer scale integration", an idea for making much cheaper RAM at a performance penalty.

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 a predictable and large number of good RAM units per wafer.

Normally, chips are made on a wafer and the wafer is cut apart, and then the chips mounted in packages; the idea with WSI was that the wafer would not be cut apart, you would use the whole thing.

WSI never really happened; I just checked Wikipedia and there is a terse comment that poor yields killed the idea. Too bad; I'd love a large wad of really cheap RAM in a 3.5" hard disk-shaped box with a SATA connector...

The article makes it hard to tell, but perhaps he is proposing something similar. Imagine a chip with extra logic circuits that you could switch in by blowing some fusible links. If you have a defective floating point multiply, maybe you can switch out the defective one, and switch in enough logic correctly connected to make a new one that works better.

What would be kind of neat would be if you could blow a few links, and take an instruction that would have gone to dedicated hardware and make it execute out of microcode; and of course have field-upgradable microcode. Then, as long as you don't run out of space in your microcode ROM, you could fix any problem; the fixed code would run slower (microcode!) than the dedicated hardware it replaced, but presumably that would be better than getting wrong answers or crashing. And if you are lucky, you might be able to special-case the problem: check for the special case, and if you aren't in the special case, go ahead and use the dedicated hardware for full speed.

steveha

Not really all that wonderful

[buss_error]

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.

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?

Parallelism

[camperdave]

I think that there's some potential in the idea of placing a thousand 80386 cores in parallel on the same chip.

Re:Parallelism

[jd]

Been done, mind you that was with a thousand 6502s on the same silicon. Actually got decent performance, well according to BBC's Micro Live. (How much would you trust a geek show whose PRESTEL session got hacked live on air?)

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.)

missing the yield

[Anonymous Coward]

"A lot of you seem to be missing the point and dismissing the article as system to allow designers to be lazy and release "faulty designs." The article was less about allowing bad designs and more about allow defective chips to work thereby increasing yield and product life"

Maybe someone can apply the idea to slashdot? Lord knows our "yield" needs to be improved.

Intel Vista?

[davidmillions.com]

You just know it's coming....

Let me get this straight.

[Allnighterking]

The movement to fpga style cpu's means .......

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 assured us that they will be releasing a new patch that might fix the problem in just a few months."

This is IMHO a way to introduce a high level of error acceptance into a piece of critical hardware. "Get it today! the newest Millennium Edition of the 286!"

In other words ...

[BlueTrin]

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.""

Wow if software recently released was not already bad (including drivers), now gaming support boards threads will look like:

HELP!!!
I start the game then get a BsoD about nv4_disp.dll. Any1 help ?
Did you update your Ge10888 GTX ? Yeah got the new stable Forceware OMG you didn't update the card, you only updated teh drivets, u noob !

yes great

[ACE209]

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.

Oh yes great thing.
Now - in addition to incomplete Software - they can deliver incomplete hardware.
The user will be so glad to become part of the testing cycle.

Link to the original paper

[mbessey]

An anonymous coward replied to my post below with this link to the original paper:
http://iacoma.cs.uiuc.edu/iacoma-papers/micro06_ph oenix.pdf

Basically, the idea is to include a small amount of reconfigurable logic on a conventional microprocessor. The configurable section would be used to detect conditions that trigger known design defects (or errata, as they're called in the industry), and work around the problem. The authors figure that for about 0.5% overhead in wires and silicon area, a chip manufacturer can patch around more than 60% of typical errata conditions.

The point is not to ship buggier hardware...

[mbessey]

Typical complex microprocessors like the Pentium 4 already ship with dozens of design defects. Including this technology on the chip would allow the manufacturer to patch around these defects on-chip, rather than leaving that responsibility to the OS and compiler developers, or being forced to recall millions of chips. This will actually lead to more-reliable hardware.

Re:The point is not to ship buggier hardware...

[Anonymous Coward]

Typical complex microprocessors like the Pentium 4 already ship with dozens of design defects. Including this technology on the chip would allow the manufacturer to patch around these defects on-chip . . .

WTF? This technology wouldn't even work with a "typical complex mircoprocesor like the Pentium 4". FPGA require much more chip space and slower clock rates to do that same tasks. Don't you see all the comments about slow and expansive? I see dozens of them. Now, Intel could make part of the chip programable, so updates code be done. Oh, wait, they've been doing that for over a decade with microcode.

It's for working aound design defects

[mbessey]

It's for fixing design defects after the design is frozen. Similar in concept to the microcode patches that Intel and AMD use for patching certain problems with their processors, but much more versatile, and specifically targeted at the most common types of design defects, according to the original paper:
http://iacoma.cs.uiuc.edu/iacoma-papers/micro06_ph oenix.pdf

Missed the point

[mbessey]

The point is that Intel and AMD are already selling processors with, in some cases, dozens of serious design flaws. This technology would allow them to patch already-installed chips to make them work correctly, rather than just fixing the problem in the next revision of the silicon, and leaving their previous customers with defective hardware, which is how design defects in microprocessors are "handled" now.

Chrysler just did that

[Animats]

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 assured us that they will be releasing a new patch that might fix the problem in just a few months."

Chrysler just did that. Over 60,000 vehicles had to be recalled for a software upgrade to the braking and stability control system.

Manufacturer : DAIMLERCHRYSLER CORPORATION
NHTSA CAMPAIGN ID Number : 06V493000
Mfr's Report Date : DEC 22, 2006
Component: SERVICE BRAKES, HYDRAULIC:ANTILOCK:CONTROL UNIT/MODULE
Potential Number Of Units Affected : 50665

• CHRYSLER / 300 2007
• CHRYSLER / SEBRING 2007
• DODGE / CALIBER 2007
• DODGE / CHARGER 2007
• DODGE / MAGNUM 2007
• DODGE / NITRO 2007
• JEEP / COMMANDER 2007
• JEEP / COMPASS 2007
• JEEP / GRAND CHEROKEE 2007
• JEEP / LIBERTY 2007
• JEEP / WRANGLER 2007

Summary:
ON CERTAIN VEHICLES, THE ANTILOCK BRAKE SYSTEM (ABS) CONTROL MODULE SOFTWARE MAY CAUSE THE REAR BRAKES TO LOCK UP DURING CERTAIN BRAKING CONDITIONS.
Consequence:
THIS COULD RESULT IN A LOSS OF VEHICLE CONTROL AND CAUSE A CRASH WITHOUT WARNING.
Remedy:
DEALERS WILL REPROGRAM THE ABS ELECTRONIC CONTROL UNIT.
THE RECALL BEGAN ON FEBRUARY 19, 2007. OWNERS MAY CONTACT DAIMLERCHRYSLER AT 1-800-853-1403.

Depends on what you design

[Quiet_Desperation]

It's very different where I work. We build rather unique items. A build of twenty is unusual. FPGAs allow us to design hardware that can be reprogrammed at a later time. Not for patching so much as incorporating codecs and prototcols that didn't exist when the hardware was designed.

Don't know what vendor you tried. I can regularly get the Xilinx Virtex series to operate at 100% to 120% of their rated speeds.

really big question...

[Khyber]

how in the fuck do you PATCH defective HARDWARE? I'm ignorant, someone please explain this, even though I work in the laptop repair field.

Please no...

[Bert64]

Back in the days when software had to be right first time, it was often a lot better...
The "release unfinished shit, fix it up later" mentality doesn't work. Not only do initial customers end up with something horrendously buggy and often unuseable, but quite often the original publishers can't be bothered to actually produce any of the patches they promised so the program just remains horrendously buggy with no hope of ever getting fixed.
Besides, rushing to be first to market doesn't do you much good when all your customers think your products are unfinished half assed efforts. You need to be very big and powerful to get away with that.

Umm...

[Anonymous Coward]

LMAO. This is called updating the firmware of an FPGA.

Quite old idea, move along.

[gweihir]

This idea is about 2 decades old and is used in high-cost devices. For low-cost ones, FPGAs are too expensive in comparison to statically structured devices. Does nobody check these stories bfore they appear here???

Everything old is new again?

[hazydave]

Well, I did read the article, and I can't tell what they're claiming is "new"... my first design with "upgradeable hardware" was in the Metabox 500 settop box (1998); this device included a modem for a datacasting technology called BOT (Broadcast Online Television, developed in conjunction with the University of Dresden), and the FPGA/LCA design was uploaded to the device as part of the device driver initialization for the modem. Anytime we released a new device driver, we could change the hardware.

And we could make some radical changes, since nearly the whole design was implemented in a low-cost FPGA. At $5.00, maybe a full custom chip would have been $1.00 (at least without amortizing NREs), but it didn't really matter, it was cheap enough. Anyway, even with a full FPGA design, there are always issues of routability... you can't make any arbitrary change and guarantee you meet timing requirements, or even if it'll fit. So while useful, this isn't as magic as it might sound to laypeople.

There would be serious issues with embedding this into CPUs or other complex devices. Other than the aforementioned speed issues (LCA/FPGA is always slower than gate array, which is slower than full custom, based on the same technology), it's only so good as where the FPGA is embedded. You can't fix any problem unless the whole design is implemented in an FPGA. There's also the startup issue... if you embed the FPGA design in Flash, you have the additional complexity of putting flash down in a complex CPU core (there are plenty of CPUs with on-chip flash, but they're usually things like ARM7/9, or simpler still), and the reality that Flash only lasts so long -- do the chips start to fail completely in 10-something years? If it's loaded at boot time, then obviously you can't FPGA any of the hardware needed at boot time.

Obligatory

[Anonymous Coward]

> new way to patch faulty hardware ... a computer science professor from the University of Illinois at Urbana Champaign

Dave: HAL? HAL! Open that airlock!
HAL9000: I cannot do that Dave. I'm sorry! ...
HAL9000: Dave! I'm afraid. I feel I am getting dumber ... Daisy, Daisy ...

The Truth about FPGAs

[Anonymous Coward]

While this article does not sound so novel, I see that many people misunderstand FPGAs - so to set the record straight -
- History - They have been around for over 20 years (I happen to have one of the first Engineering Samples from '86 on my desk)
- Price - They can be costly - the most expensive I've heard of was about 10k - but you can get a very capable one for $5 - and everywhere in between.
- Speed -The are not slow - sure they run up to 500 MHz, which is say 10X slower in terms of clock speed than your latest intel or amd - but they can do things in parallel - there is not limit (other than chip size) to the number of parallel operations - these things kick the ass at DSP like applications - real time encoding of anything, data crunching, they are even used in super computers because of this. An FPGA, for example can do 500 million multiplications per second per multiplier block. Say a CPU could do 10 times that - the FPGA however has iterally hundreds of multipliers (up to 600 or so!) so thats about 60 times a CPU.
- Power - sure they do burn more power, generally - but there are power saving features - reconfigurability = more transistors = more power. No getting around it.
- IO limited - the latest FPGAs offer 6 gigabits per second, for a SINGLE IO pair (special IO). There can be up to 24 of these special IO on a chip, so thats huge - not to mention general purpose IO run in every standard imaginable and up to 1.2gbits per second. They are used in networking devices as switches because of this immense IO throughput.
- Reconfigurability - this is becoming more popular - for applications like Software Defined Radio - where you need to crunch a lot of data, but you dont know upfront all the alogrithms / codecs that may be needed. So use an FPGA for the raw power, plus the option to upgrade it with new standards at any time (even on the fly - I've heard of applications where the whole modulation scheme / encryption method is changed from minute to minute, making hacking encrypted communications impossible!)

They are becoming available in more and more consumer products too - things like HDTVs and the like.

More crap on the market !

[__aahlyu4518]

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

So basically, this allows for total crap to be sold instead of just ironing out the flaws... that's comforting.
Would be surprised if this does a company any good.

On the other hand... to many people put up with bad service and products. They complain but don't switch.

Oh great

[jmpeax]

Now the "rush shitty product to market in knowledge it can be patched later" philosophy is coming to hardware, too?

How do they aply this patch?

[elgatozorbas]

...if a defect is discovered on a Phoenix-enabled chip, the manufacturer would automatically transmit the patch to all machines that might be affected.

From my own modest personal experience I know that having a device "do stuff" (be it calculate FFTs for DSP's, measure something like sensors do, be reprogrammed like this FPGA...) is generally not the main difficulty. Interfacing is an often overlooked hurdle: how is this FPGA going to receive this patch? How will the manufacturer know where the clients are?

Where am I?

[psbrogna]

Is this the History Channel? Come on boys, a little research before slapping it up on the wall would be appreciated.

The Intel mistake

[Sandbags]

OK, we do NOT want chip makers to be able to release "buggy" chips like most vendors release code. Intel made a slight mistake 10 years ago or so where one of their Pentium releases had a bug that caused banks much heartache. It took months for someone to notice. Problem is, this chip wasn't exactly "rushed" to market. Intel thought it was fully functional after much internal and external testing. Can you imagine what the result might have been if they started releasing unproven components just for market share?

shorter time to market

[Anonymous Coward]

..."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."

... do you mean the "new" strategy will be "if it doesn't blow up, seel it", like in lots of programs? well, just don't blame me if i don't say "hurra!", then -.-

Duct tape

[OhHellWithIt]

Forget all this FGPA crap. Use the thing that works best!

You don't know what you're talking about

[mbessey]

Look, find one of the links to the original research paper elsewhere in the discussion, and read it. The idea is to add a small amount of reconfigurable logic to a complex microprocessor, and use that programmable logic to implement a system for working around design defects in the processor.

Wrong On So Many Levels

[not_hylas( )]

Wonderful for "clean room" hardware software.

"Whether Torrellas's technology will make its way into commercial computers, however, is uncertain. "Their analysis of where bugs occur is excellent," says Wilson Snyder, a principal engineer for the high-performance computer-hardware manufacturer SiCortex, based in Maynard, MA. "It provides a good, detailed look at signals that should be analyzed to discover bugs." Hardware manufacturers could learn from the basic research behind Phoenix, Snyder says, and use it to eliminate hardware problems before chips hit the stores. But he questions whether manufacturers would ever implement Phoenix itself. Adding Phoenix onto an existing chip would take time and money, he points out."

For your Sister's computer ... not so much:

Joanna Rutkowska:

http://theinvisiblethings.blogspot.com/2006/06/int roducing-blue-pill.html

Black Hat Conference:

http://www.blackhat.com/html/bh-federal-06/bh-fed- 06-speakers.html#Heasman

http://www.blackhat.com/html/bh-dc-07/bh-dc-07-spe akers.html#Heasman

[sarcasm]
You can then just bypass the need for virtualization and just run a straight Malware OS(TM), saving us the bother of even using the web's intertube pipes for work - hell, you might even get a cut of all that "Bank" action from our new Overlords, which, of course, we'd welcome.
[sarcasm]

Will it have a "patch tuesday" too?

[gdrumm0356]

Haven't we got enough problems with Windows software being released 3 years before it's ready? Zero day vulnerabilities 3 years after release isn't a bad thing?

If hardware is released like software, we would never be able to stop the finger pointing when trying to resolve a problem.

As far as features and fixes, I thought using firmware and micros in the controllers fixed all that.

Flash for microcode updates?

[bill_mcgonigle]

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.

I think the FPGA is still going to be too slow to do even that (IIRC FPGA are big, and thus slow)

The best I can come up with is a flashable area for storing microcode updates so the OS doesn't have to on each boot.

So now my hardware needs patching also

[LingNoi]

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."

Great because software companies rushing out bugger products isn't enough, now this dude has to make away for companies to make my hardware buggy as well.

They have a "good enough" solution for a majority

[mbessey]

For a majority of the defects they analyzed for the paper, they figure that flushing the pipeline and restarting the problematic instruction will work around the problem. Of course, you'd want to have a more-sophisticated version for the more complex cases, but even the naive implementation would drastically reduce the chances of hitting these design defects.

Close

[mbessey]

Rather than microcode updates, the idea is to have a pattern-recognizer engine that looks for situations which would trigger known errata, and then trigger a recovery procedure to avoid the bug. One example they give in the paper is:

If the L1 suffers a miss while the power manager
is on and the processor is flushing its L2,
some L2 lines may get corrupted.
[Signal condition: L1WAITMISS & DPM (dynamic power
management) & L2FLUSH].

To work around this, you detect the simultaneous L2 flush and L1 miss, and temporarily disable power management. On the next instruction, you put it back the way it was. They also mention that since so many of these defects require such precise timing, just flushing the processor pipeline and restarting the current instruction will work around most of the defects they looked at.

Re:Close

[bill_mcgonigle]

Thanks for the info - I guess I shouldn't have believed the comments that said that TFA had no useful information.

Shorter time to market?

[Anonymous Coward]

As in... yeah it sort of works sometimes. Not quite right. But lets sell it anyway and fix it later. i.e. sell defective products?