Their work is definitely interesting, but I think some important questions remain unanswered, the main among them is the tradeoff between correctness of operation vs. performance because of variability. There is a paper in ISLPD 2006 which shows that for a 65nm circuit to operate at 0.3 V, the clock period must be scaled up by a factor of at least 230% to compensate for variability related issues. Additionally, there is a huge problem as far as tool support goes. This is not just mix-and-match style design. In order for this to have widespread use, it needs to work well in the EDA tool workflow. This means that libraries (and to some extent transistors) need to be characterized well at the subthreshold operating voltages. This causes a catch-22 situation. In order to design something using this subthreshold voltage technology, you need good transistor models, but the fabs have no interest in providing these models unless there is large customer demand. It is pretty expensive to get good models. The way this works is most fabs actually create transistors/gates at the given feature size, characterize them, including parameters for variation/process variability and give these to their customers, who design their chips based on these simulations. The reason these are so important is that for synchronous circuits, you have to base the design of the clock scheme on the worst/average case delay, and this you can get only by doing complete (usually Monte Carlo based) simulation of the chip using the transistor models that fab gives you. If you base the parameters solely on simulation based tools, you ignore all sorts of effects in the real world, causing a massive drop in yield(i.e. working chips made by fab).
Currently, chips (both computational and memory) are protected against soft errors using multiple methods. There are rad hardening methods (both hardware and software) and most of the latest research involves using error correcting codes. Simply duplicating the output and comparing can only detect errors in one bit. The more the times you duplicate, the more you can detect (it progresses as n-1), and the max length of error that can be corrected is half that. However, this takes a lot of space (duplication that is), so generally other codes such as Hamming or BCH codes are used.
The main problem using codes and everything is that cosmic ray errors cause whats called single event upsets and most codes can not detect 100% of errors where the hamming weight of the error (sum of number of ones in the error vector) is larger than the designed specification of the error. The problem comes when the SEU manifests itself as a multi-bit fault and the error vector cannot be detected by the code. SEU's are the most common type of errors in space application : See http://www.eas.asu.edu/~holbert/eee460/see.html
The contribution of the cosmic error detector is that if you know you have a cosmic ray at some point in time, you can flush and redo your computation (for computation channels eg microprocessors etc) or flush that line in memory (for memory channels) in case of SEU's and that is a pretty big deal.
Actually, you dont. Since the Per-chip ID (what they call the RCK) is implemented using electronically programmable fuses, all a good reverse engineer has to do is reset the fuses . This has been demonstrated possible via UV light combined with selective stripping of upper metal layers (eg : http://www.flylogic.net/blog/ ). Yes I do realize that the chips shown on the site are slightly older technology, but keep in mind that it is slightly easier to reset electrical fuses as the feature size goes down ( as the gate is thinner). Also, the chips on that site are crypto chips, so they have additional safeguards (meshes etc).
The fundamental problem is that the RKC is an easily known factor. If a pirate fab can steal one valid RKC they can simply use known techniques to ensure the RKC's for all pirate chips are the same. The current way to implement truly random keys especially for crypto chips is to use PUFs (physically unclonable functions). This consists of something like doping the top layers of the silicon with some metallic crystals that affect the capacitance, and having capacitance sensors on the bottom of the chip. The initial values of the capacitance are recorded on a small 1 time programmable ROM. Any physical attack on the chip (trying to remove packaging to use a laser, FIB, probe etc) will change the capacitance that will shut off / damage chip permanently. However something like this is probably too expensive to justify for simple ASICs, for which amortized design costs work out to a few pennies.
The concern for the environment should act as the necessary friction against knee jerk reactions like this one. One of the biggest issues with any form of industrial energy production is waste disposal. Coal contributes to global warming. Nuclear waste cannot be disposed of in any convenient ways yet. Putting it in a glass box, in a metal tube and burying it under a mountain (the plan for long term waste disposal in both the US and France) is exactly like sweeping dirt under the rug. It works as long as the amount of dirt is small. If there is a lot of dirt, this method doesn't work anymore. To those saying throw it in space, orbital lift is expensive. Bottom line- any method of energy extraction leaves waste products. Some are easier to handle than others. Radioactive goo is harder to dispose than CO2.
I know the initial urge of a small company suing a larger one (especially a darling of slashdot such as Google) will have a lot of people yelling patent troll, but this may not be the case. The fact that this is a company from a university professor means that the company very likely has a working product that has been derived from several years worth of research. To those who are not used to the American system of research at the university level (for Professors and PhDs), any researcher can apply for a patent on the research they have been doing in the lab. The patent is usually issued in the name of the university or jointly in the name of the researcher and the university. There is usually an exclusive licencee for the patent. This forces the university to allow the researcher to have first dibs on licensing the technology he worked on exclusively to some company he decides. This is done as university's usually take anywhere from 50-75% of all royalties generated by the patent as research was done on university property. Thus many profs usually spin off companies and sit on the board of directors for the company and earn a supplementary income this way.
So , heres how it works :
1. Do research on some area.
2. Get funding from $Federal Agency of choice
3. Make a few students get PhD's doing research on this topic
4. Go to the office of tech licensing on campus and draw up patent
4.a Make sure the exclusive license clause is in the patent
5. ??? -> Form company and sit on board of directors
6. Profit.
Am I the only one who thinks that hardware costs really dont matter ? People will want windows because thats what their old computer had, all their files are in Office formats, and thats what they use at work. Microsoft will have a round of negotiations with OEMs and drop the price of the license by 10%. The end users are happy (All their data works, and they get to say... look I got a $400 piece of software with my $250 computer). The OEMs are happy cos for low end systems volume is everything, so more the people buying, more serious coin they make. And Microsoft is happy, because it did not have to cut prices by a lot. Additionally, they get their favorite upgrade path reopened; using better hardware to compensate for bad software.
Another thing to consider is the fundamentally different mentalities the two camps (open source vs closed source) have. For closed source, all that matters is shipping a working product. So what if it breaks if you have more than 4GB of RAM or your directory naming convention must be exactly so. The open source approach on the other hand tends to be we wont call our product done till the code is perfectly optimized for all systems from a VAX to a Blue Gene. Also, one must consider that individuals and companies are at different ends of the spectrum when it comes to reasons why they have not released code. For individuals, there is personal criticism from programmers about their code. But, one has to keep in mind that not all individuals are programmers. If a recent physics PhD chooses to release the code he used to process output of his high energy particle physics simulations for his thesis, he would be heaped with scorn for spaghetti code despite the fact the code accomplished its primary purpose (get enough data to get the guy his degree) and did it in a reasonable time frame. For companies, there is simply a strong sense of possessiveness. They are loath to give away anything; including code for products they dont use or support anymore.
I just spent last semester dealing with openembedded and a pxa270 based dev board. The documentation is not the greatest, but once you have everything figured out and working, OE's power and flexibility really shine through.
that this vaccine is for birds and not humans. The vaccine will prevent avian to human transmission, but will be useless if H5N1, the avian flu virus mutates into human infective form.
Those are PCB's with mostly SMD or throughole components. A motherboard has larger components that cant always be mounted with a robotic arm (try the IO ports, or the processor socket).
Nope not really. It takes forever to do boolean division to find factors on a chip that has more than 50 gates. The number of states goes up exponentially with the number of gates.
I know typing this out will be useless, and it will get overlooked by the mods, but I might as well say this. Asynchronous designs have several advantages :
1. It will give good power consumption characteristics i.e. low power consumed, not just because of the built in power down mode, but also because of the voltage the chips will be running at. By pulling the voltage lower than a synchronous equivalent, it will be simpler to have greater power savings. This becomes possible if you are willing to sacrifice speed. and in async devices, speed of switching can be dynamically altered as each block will wait till the previous one is done, not until some outside clock has ticked.
2. Security: Async designs give security against side channel power analysis attacks. As all gates must switch (standard async design usually uses a dual rail design, so most gates means all gates along both +ve & -ve switch), differential power attacks become much harder. Thus async designs are perfect for crypto chips (hardware AES anyone?)
3. elegance of solution:the world is generally async. Key presses are, memory accesses are. so why not the processor:). (Yes I know busses are clocked, before you start, but if they were not.... )
But they have several points of disadvantage:
1. They are hard to do. Especially using the synchronous design flow that most of the world uses. Synchronous tools assume, especially in RTL, that the world is combinational, and that sequential bits are simply registers that occur once a clock cycle (not true for full custom designs like intel and amd, but for slightly lower level : esp ASIC design)
2. The tools that exist now, are either able to do good implementation using only a few gates ie small functions or bad implementations, that are in worst case as slow as synchronous equivalents but are larger functions. Tools exist like http://www.lsi.upc.edu/~jordicf/petrify/ Petrify , but these become unusable for circuits with more than ~50 gates.
3. Async designs are usually large. This is not always true, but standard async designs are usually implemented as dual rail or using 1-of-M encoding on the wires. But the main overhead comes from the handshaking circuitry. For really fine grain pipeling, the output of each stage must be acknowledged to the previous stage. This adds a massive overhead, as it necessitates the use of a device called the Muller C Element, that sets the output to the output, only if the inputs are the same, or retains the previous value, if not. Many copies of this element are usually required, and its this that adds space, for example, a simple 1 bit OR gate, that would usually have 4 transistors, has 16 transistors for the dual rail async implementation.
For the time being, I think they will find a lot of use in low power applications - such as embedded microcontrollers/processors, in things like wireless sesnor networks, and security processors. However I believe that full processor design is very far off.
Slashdot Mirror
Their work is definitely interesting, but I think some important questions remain unanswered, the main among them is the tradeoff between correctness of operation vs. performance because of variability. There is a paper in ISLPD 2006 which shows that for a 65nm circuit to operate at 0.3 V, the clock period must be scaled up by a factor of at least 230% to compensate for variability related issues. Additionally, there is a huge problem as far as tool support goes. This is not just mix-and-match style design. In order for this to have widespread use, it needs to work well in the EDA tool workflow. This means that libraries (and to some extent transistors) need to be characterized well at the subthreshold operating voltages. This causes a catch-22 situation. In order to design something using this subthreshold voltage technology, you need good transistor models, but the fabs have no interest in providing these models unless there is large customer demand. It is pretty expensive to get good models. The way this works is most fabs actually create transistors/gates at the given feature size, characterize them, including parameters for variation/process variability and give these to their customers, who design their chips based on these simulations. The reason these are so important is that for synchronous circuits, you have to base the design of the clock scheme on the worst/average case delay, and this you can get only by doing complete (usually Monte Carlo based) simulation of the chip using the transistor models that fab gives you. If you base the parameters solely on simulation based tools, you ignore all sorts of effects in the real world, causing a massive drop in yield(i.e. working chips made by fab).
Currently, chips (both computational and memory) are protected against soft errors using multiple methods. There are rad hardening methods (both hardware and software) and most of the latest research involves using error correcting codes. Simply duplicating the output and comparing can only detect errors in one bit. The more the times you duplicate, the more you can detect (it progresses as n-1), and the max length of error that can be corrected is half that. However, this takes a lot of space (duplication that is), so generally other codes such as Hamming or BCH codes are used.
The main problem using codes and everything is that cosmic ray errors cause whats called single event upsets and most codes can not detect 100% of errors where the hamming weight of the error (sum of number of ones in the error vector) is larger than the designed specification of the error. The problem comes when the SEU manifests itself as a multi-bit fault and the error vector cannot be detected by the code. SEU's are the most common type of errors in space application : See http://www.eas.asu.edu/~holbert/eee460/see.html
The contribution of the cosmic error detector is that if you know you have a cosmic ray at some point in time, you can flush and redo your computation (for computation channels eg microprocessors etc) or flush that line in memory (for memory channels) in case of SEU's and that is a pretty big deal.
Actually, you dont. Since the Per-chip ID (what they call the RCK) is implemented using electronically programmable fuses, all a good reverse engineer has to do is reset the fuses . This has been demonstrated possible via UV light combined with selective stripping of upper metal layers (eg : http://www.flylogic.net/blog/ ). Yes I do realize that the chips shown on the site are slightly older technology, but keep in mind that it is slightly easier to reset electrical fuses as the feature size goes down ( as the gate is thinner). Also, the chips on that site are crypto chips, so they have additional safeguards (meshes etc).
The fundamental problem is that the RKC is an easily known factor. If a pirate fab can steal one valid RKC they can simply use known techniques to ensure the RKC's for all pirate chips are the same. The current way to implement truly random keys especially for crypto chips is to use PUFs (physically unclonable functions). This consists of something like doping the top layers of the silicon with some metallic crystals that affect the capacitance, and having capacitance sensors on the bottom of the chip. The initial values of the capacitance are recorded on a small 1 time programmable ROM. Any physical attack on the chip (trying to remove packaging to use a laser, FIB, probe etc) will change the capacitance that will shut off / damage chip permanently. However something like this is probably too expensive to justify for simple ASICs, for which amortized design costs work out to a few pennies.
This doesnt affect VMWare server though,which most people use in home settings (given that it is free)
The concern for the environment should act as the necessary friction against knee jerk reactions like this one. One of the biggest issues with any form of industrial energy production is waste disposal. Coal contributes to global warming. Nuclear waste cannot be disposed of in any convenient ways yet. Putting it in a glass box, in a metal tube and burying it under a mountain (the plan for long term waste disposal in both the US and France) is exactly like sweeping dirt under the rug. It works as long as the amount of dirt is small. If there is a lot of dirt, this method doesn't work anymore. To those saying throw it in space, orbital lift is expensive. Bottom line- any method of energy extraction leaves waste products. Some are easier to handle than others. Radioactive goo is harder to dispose than CO2.
I know the initial urge of a small company suing a larger one (especially a darling of slashdot such as Google) will have a lot of people yelling patent troll, but this may not be the case. The fact that this is a company from a university professor means that the company very likely has a working product that has been derived from several years worth of research. To those who are not used to the American system of research at the university level (for Professors and PhDs), any researcher can apply for a patent on the research they have been doing in the lab. The patent is usually issued in the name of the university or jointly in the name of the researcher and the university. There is usually an exclusive licencee for the patent. This forces the university to allow the researcher to have first dibs on licensing the technology he worked on exclusively to some company he decides. This is done as university's usually take anywhere from 50-75% of all royalties generated by the patent as research was done on university property. Thus many profs usually spin off companies and sit on the board of directors for the company and earn a supplementary income this way.
So , heres how it works :
1. Do research on some area.
2. Get funding from $Federal Agency of choice
3. Make a few students get PhD's doing research on this topic
4. Go to the office of tech licensing on campus and draw up patent
4.a Make sure the exclusive license clause is in the patent
5. ??? -> Form company and sit on board of directors
6. Profit.
Maybe it was too alien for your sensibilities...
Am I the only one who thinks that hardware costs really dont matter ? People will want windows because thats what their old computer had, all their files are in Office formats, and thats what they use at work. Microsoft will have a round of negotiations with OEMs and drop the price of the license by 10%. The end users are happy (All their data works, and they get to say... look I got a $400 piece of software with my $250 computer). The OEMs are happy cos for low end systems volume is everything, so more the people buying, more serious coin they make. And Microsoft is happy, because it did not have to cut prices by a lot. Additionally, they get their favorite upgrade path reopened; using better hardware to compensate for bad software.
Another thing to consider is the fundamentally different mentalities the two camps (open source vs closed source) have. For closed source, all that matters is shipping a working product. So what if it breaks if you have more than 4GB of RAM or your directory naming convention must be exactly so. The open source approach on the other hand tends to be we wont call our product done till the code is perfectly optimized for all systems from a VAX to a Blue Gene. Also, one must consider that individuals and companies are at different ends of the spectrum when it comes to reasons why they have not released code. For individuals, there is personal criticism from programmers about their code. But, one has to keep in mind that not all individuals are programmers. If a recent physics PhD chooses to release the code he used to process output of his high energy particle physics simulations for his thesis, he would be heaped with scorn for spaghetti code despite the fact the code accomplished its primary purpose (get enough data to get the guy his degree) and did it in a reasonable time frame. For companies, there is simply a strong sense of possessiveness. They are loath to give away anything; including code for products they dont use or support anymore.
I just spent last semester dealing with openembedded and a pxa270 based dev board. The documentation is not the greatest, but once you have everything figured out and working, OE's power and flexibility really shine through.
that this vaccine is for birds and not humans. The vaccine will prevent avian to human transmission, but will be useless if H5N1, the avian flu virus mutates into human infective form.
Those are PCB's with mostly SMD or throughole components. A motherboard has larger components that cant always be mounted with a robotic arm (try the IO ports, or the processor socket).
http://sfgate.com/cgi-bin/article.cgi?f=/c/a/2006/ 05/25/BAGO0J1C5O18.DTL
This is the story of a physics teacher who tries to sustain interest by doing interesting experiments, whosesafety is now being questioned.
Nope not really. It takes forever to do boolean division to find factors on a chip that has more than 50 gates. The number of states goes up exponentially with the number of gates.
I know typing this out will be useless, and it will get overlooked by the mods, but I might as well say this. Asynchronous designs have several advantages :
:). (Yes I know busses are clocked, before you start, but if they were not.... )
1. It will give good power consumption characteristics i.e. low power consumed, not just because of the built in power down mode, but also because of the voltage the chips will be running at. By pulling the voltage lower than a synchronous equivalent, it will be simpler to have greater power savings. This becomes possible if you are willing to sacrifice speed. and in async devices, speed of switching can be dynamically altered as each block will wait till the previous one is done, not until some outside clock has ticked.
2. Security: Async designs give security against side channel power analysis attacks. As all gates must switch (standard async design usually uses a dual rail design, so most gates means all gates along both +ve & -ve switch), differential power attacks become much harder. Thus async designs are perfect for crypto chips (hardware AES anyone?)
3. elegance of solution:the world is generally async. Key presses are, memory accesses are. so why not the processor
But they have several points of disadvantage:
1. They are hard to do. Especially using the synchronous design flow that most of the world uses. Synchronous tools assume, especially in RTL, that the world is combinational, and that sequential bits are simply registers that occur once a clock cycle (not true for full custom designs like intel and amd, but for slightly lower level : esp ASIC design)
2. The tools that exist now, are either able to do good implementation using only a few gates ie small functions or bad implementations, that are in worst case as slow as synchronous equivalents but are larger functions. Tools exist like http://www.lsi.upc.edu/~jordicf/petrify/ Petrify , but these become unusable for circuits with more than ~50 gates.
3. Async designs are usually large. This is not always true, but standard async designs are usually implemented as dual rail or using 1-of-M encoding on the wires. But the main overhead comes from the handshaking circuitry. For really fine grain pipeling, the output of each stage must be acknowledged to the previous stage. This adds a massive overhead, as it necessitates the use of a device called the Muller C Element, that sets the output to the output, only if the inputs are the same, or retains the previous value, if not. Many copies of this element are usually required, and its this that adds space, for example, a simple 1 bit OR gate, that would usually have 4 transistors, has 16 transistors for the dual rail async implementation.
For the time being, I think they will find a lot of use in low power applications - such as embedded microcontrollers/processors, in things like wireless sesnor networks, and security processors. However I believe that full processor design is very far off.