Did you know that we need to start new wafers to supply Easypath? (can not rely on having enough die with one or two memory cells that are at fault to satisfy demand).
Did you know that the cost savings are mostly from testing the chip for what the customer uses it for, rather than for testing it for what everyone of our 250 thousand seats of software might design it to do?
Oh, and what about all those laser trimmed redundant chips out there, are those also scrap? After all, every one of those has a proven hardware faults!
(PS: thanks for bringing this up again, and giving me the opportunity to reply -- it is so much fun to see the subject line of your posting promoted by someone else besides me)
What is wrong with taking lemons and making Lemonade?
Xilinx has taken the enviromentally sound practice of taking parts that would have otherwise gone to the dump, making them into something useful, and selling them.
To me this reflects engineering brillance.
This is a kind of cool situation: give customers a good price, make environmentalists happy, and make stockholders happy all at the same time.
If this makes you unhappy, seek help :)
Cheers, Jim P.S. Usually it takes environmental activists and an act of congress to get people to do envionmentally correct things.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I don't believe they have, as I understand it, I don't believe the EasyPath parts have actually failed production test.
As I recall, it was the full testing itself that was expensive, rather than the device failures. To take it to extremes, if you can churn out wafers full of good devices, but you have to leave each chip sitting on the tester for eight hours to prove it, then test costs would be a killer.
That would give a LOT of scope for testing exactly what a customer wants, and no more, and passing on the reduced cost of test time. The difference is, the rest of the chip is POSSIBLY fully functional, but Xilinx haven't spent the money to prove it.
You are correct. The parts have passed a specific suite of tests for one or more customer designs. It turns out that you can test for up to about three different designs all at once, and still maintain the same time/yield benefit!
At some point in the future, all parts will be 'EasyPath'*--the new technologies envisioned (carbon nanotube transistors, spintronics, etc.) all lend themselves to building FPGAs, and to "qualifying" parts for applications, as no one part will ever have 100% of its nanostructures working perfectly (there will always be flaws).
Drive manufactures have been doing this for years. They just maintain a defect sector list on the drive.
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
I guess it will be a question of time until there will be support in ISE to map out defects for a given target device? Maybe we'll have configuration-time mapping of defects in the future.
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Being able to map out defects is not the solution: that is a nightmare for customers who demand a repeatable and reliable solution. It does no good to be able to map out a bad resource, unless it is guaranteed to not affect the overall performance of the design, and it can be done automatically with a 100% chance of success. Even redundancy today accomplished by laser programming has its problems in FPGAs (timing is different).
A FPGA is not a disk drive. A disk drive can not only have a map of bad tracks written into it, but the operating system can cooperate by not using the bad tracks, and nothing goes wrong.
If I have a bad LUT (for example), how do I know? Did I test it apriori, and then what? Did I somehow write that information into the device (the old non-existant non-volatile memory problem again)? If so, how the heck do I use that information when the bitstream wants to just go ahead and configure the part?
It is a very complex problem, one that does not have a solution (today).
EasyPath resolves the problem by limiting the scope of the problem to be solved. A bit like attaching the horse in front of the carriage, instead of trying to push the carriage from behind with the horse: it just takes a really tough problem, and simplifies it immensely.
No need to drive around the potholes, the streets are all pre-screened, so that there are no potholes (where I want to drive).
The developer still must be able to create the program in the first place, which either requires a map of defects (if a perfect device is impossible to make), or some kind of automatic fault detection and avoidance scheme. The map of defects would allow the software to get that one part running, or the few parts for the prototypes before the EasyPath program takes over. Very much like the disk drive case. Those devices with defect maps then become the expensive units, as they need the labor for the maps (and the maps are just a file from the internet perhaps). The EasyPath parts remain the bargain.
The customer has to be aware and understand this. The win is low cost devices. The drawback is that you would not know the performance of your device until you run ISE. I think it could be worthwhile for some (presumably low volume) high density applications where you can do without a RAM or several LUT's. If I could get a 40K LUT device at 50% off for an ASIC prototyping application I would go for it.
The defect lists could be written out by the test equipment. A database for each part had to be maintained. ISE could load the defect list (over the Internet) for the particular target device and avoid using the defective resources when you run map and par. This is of course a logistics challenge as well.
configuration-time-mapping is of course a very complex problem. I should have put a smiley there. But you could think of certain defects where you map to a spare neighbor LUT and you know in advance that it would not violate timing. This would require preprocessing and modification (or running ISE on the embedded PPC :-) of the bitstream on-the-fly.
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
I once was a semiconductor test engineer, and when I was in that business decades ago, test time cost around US$0.25 per second per device. I'm sure it's rather more now. Eight hours would be rather pricy, say well over US$7,000 each! I've looked into testing FPGAs, and to get reasonable fault coverage requires hundreds of downloads. Look at the fastest loading method, multiply it by an assumed test time cost and that would give you a very minimum estimate of test cost.
Test cost is a significant fraction of total cost for many semiconductor devices. For testing only what is used, this would allow a very major reduction in test time and cost. There is also a gain from the increased yield. The gain from each is going to depend on the defect density. If the yield is already high, as it would be with a smaller part on a mature process, the gain would be mostly from reduction in test cost. If the yield is low, as it would be on a large part or on a new process, then the gain would be from both improved yield and reduced test time. Don't forget that a part that fails still needs to be tested to the point that it fails. The test problem isn't the CLBs or the FFs, it is the interconnect. It is hard to get 5% of the interconnect used on a design, and the parts are more than half interconnect.
Even if there was a defect on the rest of the chip, a different download would have a small chance (a few percent at most) of hitting it. If the change was as limited as possible, changing only a few interconnects or limited to the contents of LUTs, the odds of hitting a defect would be fairly near zero. It would be a good idea to have a test plan to determine if the new load is fully functional in each system in any case.
It is a great idea for the right end users.
-- Phil Hays Phil_hays at posting domain should work for email
so what you are saying is that you can build a chip to potentially suit any design you like, but in fact customers are more interested in getting their own design to work and don't really care about the other possibilites.
Does that mean that in the future, if everyone adopts this strategy, we will be back to having to swap chips at every upgrade? I thought one of the (many) wonderful advantages of FPGAs is their prolonged lifetime due to upgrade potential.....
Effectively, if everyone does go down that route, Xilinx, Altera and Co. will become ASIC producers!! Very good ones, don't get me wrong, with time and money savings for everyone, but.....
There are users for both types. A good parallel here is to look at the uC market: For a while, flash was seen as the ultimate, and some companies chose do only flash devices - but MASK ROM is actually not going away, and recent releases from some big suppliers have both FLASH and MASK models.
FLASH covers development, and products needing design turns, but MASK has much lower FAB costs, lower testing times, and also has zero risk of unexpected field erasure, as well as wider Vcc operation, and zero programming costs. If your product is stable, and in high volume, it would be imprudent to not consider mask. If the FLASH variant is available, then product changes can always be covered, and are only needed for the ROM pipeline delay.
I have not seen the die photos of these new devices, but I presume they use identical mask sets where possible, and skip the extra flash steps. ie the MASK die may not actually be smaller, and there are arguments to not do that (even tho you can), to keep identical EMC operation.
The FPGA flows mimic this : Full testing coverage gives devices for development and many design turn products, but once it is stable, why not take the cost savings ? - a key aspect is the electrical operation is identical and thus timing and EMC approvals do not change.
Any chance Peter or Austin could post some non-proprietary information on the typical number of tests and average test time for a "generic" FPGA versus one for the EasyPath with a known FPGA bit pattern? As the devices get more complex, does test time go up linearly? What does test time cost per second? How expensive are the testers? Any other tidbits to enlighten/amuse us?
Device testing is something a lot of people are never exposed to, so this could be an interesting education.
EasyPath sounds like a cute idea - I hope it works well for Xilinx.
No, I don't think we are going back to the ASIC model any time soon, but there is a class (a large class) of applications for devices that get programmed to do one thing, and are extremely unlikely to require an upgrade.
Even if the device does require an upgrade, I think folks on this thread have already noted that the probability for failure to load for a small number of changes is pretty near 0 (just based on the number of good paths and bits vs the one or two bad bits).
The really remarkable thing about EasyPath (already has happened) is when the customer calls up two months later, and says "I made this mistake, and I need to change the contents of a LUT and a path...." and we can say, "send us the new bitstream" and let them know exactly what kind of chances there are that all the parts already in the field have of not being able to work with the new pattern, and change to testign for the new pattern for their next delivered lot.
Saved some butts, that is for sure! Try that with an ASIC.
Exactly! So more and more people will come to you instead of going to ASIC manufacturers, provided costs/time/characteristic are sufficiently good.
So that divides the FPGA industry into 2: one half carries on like we know it,i.e. reprogrammable logic. The other half attacks ASIC on it own territory, i.e. a certain type of devices which are quite happy not to change over time.
Either way, FPGAs will be conquering the world!!
Now, on a more serious note, I seem to remember predictions by Makamoto and its famous pendolous that the market is moving towards reconfigurable hardware anyway.
So here is my question: why did Xilinx think of Easypath? The market is coming its way anyway......
A few possibilities:
- Virtex II Pro wasn't selling enough, so an alternative was needed.
- Industry scope redefinition: Xilinx saw quite a lot of business available on this area, and, because at the end of the day we're out here to make money, went down that route, even if it meant changing a few things here and there
- Xilinx had a bunch of slightly defective Virtex II Pros. Instead of throwing them away, started Easypath. It then proved a success, so much so that potentially perfect devices are sold without guarantee that they would work.
Now, option 1, I would discard. Option 2: well, I seem to understand Xilinx is on the up as of lately, overtaking all its competitors and still pulling away. Why go down that route, considering that in the next 3-5 years the FPGA market is going to grow to levels never seen before? Option 3: Seems to me the most reasonable.
- Xilinx found they could deliver previously untested parts at a significantly lower cost while maintaining profit margins just by performing custom testing with 100% coverage of a single design rather than 100% coverage of every teeny tiny little piece of every corner of the device. The fact that it helps stave off a change to ASICs is a bonus.
If an FPGA will only have one design, the generic 100% testing of the device is effectively a waste of effort with more capital equipment and manufacturing capacity devoted to the lengthy process than is necessary. The tradeoff comes to when the cost of test development and the part management outweighs this "waste."
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.