This is actually the main problem that is solved with this solution. Traditionally, electro-optical conversion was done using discrete components. This consumed a great deal of power and also added the extra restriction that a separate, optical modulator had to be added along with the central electronic chip. It also meant that the electronic chip had to somehow send a very fast electrical signal (and all the attenuation that would occur to it) to the optical module.
The optical IC they came up with isn't optical entirely. The internal logic is still electrical but they've managed to do a silicon-level electro-optical converter and directly send the optical signal out (I'm guessing through a microlens). This isn't likely to make internal logic (the next Pentium...wait they don't use that name anymore) calculate faster, but it'll be interesting to see this used as a RAM interface, for instance, or for multi-processor interconnect.
The main reason x86 is around is the software base. This isn't going to change with softcores. What will happen is that bugs associated with the more obscure/complex parts of x86 that aren't performance critical (and/or not covered by testing) can be fixed after release rather than forcing a recall. Certain features can also be updated for a speed boost. There'll still be dedicated logic (adders, multipliers, etc.) but the routing logic between these macroblocks can be entirely programmable. You'll be buying designs from Intel and updating the silicon chip you have.
Well, to be fair, that's really saying that AMD's system architecture is better. I know it's a fine line but the interconnecting architecture (in the case of AMD, it's point-to-point crosslinks and dedicated pockets of memory) is what dominates performance in the "scaling" sense. As we've seen from SGI's Altix (using the Itaniums, which uses the same shared bus that the Core 2 uses), there is nothing stopping a system designer from making a NUMA design from dedicated busses. And performance is incredible.
The point of a JIT translation is that it is essentially software and can be patched without recalling the chips. The primary use (or intended primary use) of the chip, where speed would count, would be in the new instruction set and that instruction set would be implemented (read: decoded, executed) in silicon whereas x86 would be handled in software/firmware, where its complexity would not cause flaws in the chip that had to be worked around.
My point is, it doesn't eliminate the scaling problem. It merely reduces it. A design of 200 million transistors will still be much harder to verify than one that is 50 million (assuming equal logic complexity). Black box testing helps but at some point, you'll still hit the wall where it would take longer than the time you have to test a sufficient percentage of features. It's not just about money, it's about time. And unless people are content with a processor being released every 20 or 30 years, this problem will not go away.
The problem with the black box is that you never know whether the box you're using actually matches the box that will be put there. Hardware is not sequential. Everything happens at once, governed by a clock (and sometimes, without a clock). To test that kind of "black box", let alone reproduce a correct "black box" model is complex enough that the process, itself, introduces mismatches.
Well, see, that's the thing. It implies that the bug was detected before release. Believe me, it costs a lot more to recall than to delay 3 months. The problem is, existing test methods simply cannot test enough without taking *years*. You don't catch 1% more of the flaws in a flat amount of time. It takes *exponentially* more time as you asymptotically approach 100% of all possible features tested. To "get it right" as in be certain that there are no flaws in the design would take centuries.
The problem we should be asking isn't why it wasn't tested more, but rather, why it was so complex to begin with. There is only one reason for putting anything in silicon and that is for speed. I'm going to guess that a large majority of "features" on today's x86 microprocessors are not speed bottlenecks. Why could these features not be put on a re-programmable firmware? The technology exists.
Yes and no. There are limitations to HDL's (and Intel, last I heard, was all Verilog). For one, it is *very* difficult, if not impossible in certain situations, to describe asynchronous signals. With something as complicated as a microprocessor that is so aggressively designed for both power and speed, I would guess that they didn't go with a completely synchronous design (hell, no one does anymore). Locally synchronous, globally asynchronous design has been in use for a while. It helps when you want to be able to shut off, or slow down, only parts of the chip that aren't being used very much.
It is not possible to describe such things (let alone voltage islands, voltage scaling) in an HDL language and they must either be a special feature built into synthesis (with an extra set of constraints) or done by hand at the transistor/gate level.
Then there's the point of verification. Every software release since about the mid-1990's has almost been immediately followed by patches. Just because it's "1's and 0's" does not mean that it doesn't get harder to detect corner cases as complexity grows. And it's much more difficult if you have to simulate on a cycle-accurate model (boot-up for an operating system, in simulation, would take a day on a nice cluster on something as big as the Core 2).
Then there's post-synthesis/layout issues. Timing analysis do best on sequential logic (completely synchronous). When you throw in clock gating, multiple voltage islands, dynamic voltage scaling (meaning dynamic gate delays), not to mention the plethora of other techniques that those folks might be doing, what you see in simulation at the RTL level will not match what you see in reality. First rule they ever teach in any ASIC design class is never trust simulation.
The point is that abstraction, like how it's "vhdl", does not mean that it's not difficult to get right and even sometimes impossible to be certain.
They know all there is to know about god and everything. So very very sad.
Ding ding ding! You've just revealed the entire appeal of religion! "I know all that I need to know." Sure makes talking to some learned person easier on the ol' ego if you think you still know more than him "where it counts".
In a word, it provides infinite states (ok, maybe not infinite, but a lot).
A quantum inverter would take an input that was 20% 1, 80% 0 and give you 20% 0 and 80% 1. Inverting is a relatively simple function but imagine a much more complicated function, such as multiplication. A 2-input, 32-qubit multiplier takes in two inputs each with a certain distribution of all possible 32-bit values (let's say, evenly distributed in one input and 50% less than 2 million, 20% between 2 and 3 million and 30% between 3 million and 2^32-1) and gives you a 32-qubit result that contained the multiplied distribution (a probability multiplication function).
Your result, in this case, would be equivalent to doing 2^64 multiplications in a traditional binary multiplier. Of course, how you would sample the resulting data (it has to be sampled, and thus breakdown into normal 1's and 0's) would impact dramatically the usefulness of the function. You could, for instance, test for existence (does a certain number result from the function) and instead of having to compute all possible permutations one at a time, perform one pass using a qubit operation, then use a qubit "filter" operation of some sort (I'm no statistician so forgive me if I don't have an equation on hand).
The question, of course, isn't the concept of exchanging something for another but rather, how much. Someone isn't automatically entitled x amount of money for a service, they get whatever money they can get away with selling their service for. The market will determine the price. And if current technology allows a market in which said service is virtually free (the internet transfers information at a cost-per-megabyte much cheaper than cd's), then the service is worthless and is virtually free.
Software-controlled hardware scaling already exist IIRC. They've existed in a primitive form since Intel first introduced its "Speedstep" feature on its mobile Pentiums. The OS would control the clockrate of the microprocessor based on the CPU utilization.
Embedded systems (PDA's and cell phones) have had finer and more sophisticated grades of software-controlled frequency and voltage scaling and even software-controlled sleep-states.
I'm not sure why this research project is so special. I suppose since she's trying to form a standard interface, one that both hardware and software designers can independently use (whereas before, hardware designers would have to double as software designers designing the low-level control software and giving embedded software designers a library). But see, with something as customized as microchips, I'm not really sure it's possible to come up with a standard "end-all" interface that will fit all of the features a hardware designer could use.
Then there's the problem of where this software would run. The problem with software-controlled scaling isn't that software doesn't know the workload better (as it does) but rather, how fast can it communicate that information to the hardware? There's an overhead in that communication.
Not that I'm not saying software and hardware aren't merging, but it's not going to be in the realm of new software layers IMO. More likely than not, it'll be a move towards more firmware-based microprocessors with hard-wired core designs and configurable, tile-like co-processors that can be configured using non-volatile memory on startup (and stored in configuration SRAM) much like an FPGA.
One of his answers interested me. In response to question #2, he made a comparison of the cultural attitude towards video games as a source of entertainment vs other, more traditional media. In particular, it's interesting that he compares it to books, television and movies. He claimed that video games were taken less seriously and not as pervasive in modern culture.
This may be true to some degree, and certainly the sheer amount of time that books, television and film have existed with respect to the existence of video games surely can explain how it is less culturally pervasive, I think the answer lies, primarily, elsewhere.
One obvious advantage, of course, is the social aspect. People can watch TV and movies together. They can read and then discuss a book together. In essence, it's social. This is one aspect I feel video games lack in. More and more games that involve (particularly with the help of the internet) multiplayer aspects and even focus on it are coming and they will certainly help push video games into the mainstream.
Another obvious advantage is that it's so attention-dominating. When one watches TV or goes to a movie, it's generally viewed as a social event. Yes, we do have rules with our friends that no one is allowed to cause any noise during a new showing of The Office, but if you're all just kicking back with a beer in your hand watching Conan, then it's a social environment in which your full attention is not required. This, I think, is lacking in video games. One can argue that interactivity will always require more attention and that may be true to some extent. But looking at games like poker and many other such board games, I think it can be well argued that interactivity is not necessarily a social killer in which you can't take your eyes off of the game if you want to play.
The final, and probably most important reason that TV, movies, books, etc. are more culturally favored than video games is content. Let's face it, there are crappy games out there. In fact, I'd say that the majority of games are crappy. The reason that GTA was popular was not because of the graphics, the voice acting or the interface, it was because it was fun. The game was well-made with a (albeit comical) storyline and a variety of things for people to do. In a medium with so much possibility in terms of content delivery, it's a wonder that people have not done more with it. Has anyone even considered how important the story may be in a video game? I don't obsessively watch Grey's Anatomy (there, I said it) every week because I like the graphics (though there is a ton of eye-candy on that show). I watch it because of the storyline (albeit a soap-opera-ish storyline). And having the ability to augment that storyline with interactivity brings leaps and bounds of opportunity that has, thus far, not been exploited. When playing through a game becomes as emotionally thrilling as watching Peter Gibbons take an electric drill and removing the doorknob that shocks him every day, more and more people will regard it as an every-day pass time just like turning on the tube.
I really don't understand the contention. Obviously more people are interested in the Treaty of Algeron than in Park Ridge High School in New Jersey (though that particular one has a Wikipedia article). I would've thought that, as a repository of knowledge, the only and sole rating of how "worthy" an article is is how many people want to read about it. Things that are so important that they should be kept even if only one person cares about it are far too important to trust Wikipedia to keep it. It's not there to store humanity's most important information. It's there to provide access to commonly-desired that the masses want.
This, of course, is assuming that any signal inside the P4 needs to travel across the whole chip in one clock period. I believe the entire philosophy behind the Netburst design was to avoid signals traveling too far. Signals that need to get from one side of the chip to another are given multiple clock cycles (and subsequent signals after them are pipelined) to do so.
Interesting. This is essentially the photon version of AC then. Now, correct me if I'm wrong but:
1. Change in electric potential means that signals propogate at the speed of light across a chip. 2. Change in speed of photon would require photon that carried signal (or rather, the "breakpoint" where the speed changed) to travel across a chip.
Anyone else think that the first actually propogates information *faster* than the second? Now granted, photons are a lot easier to deal with (I've plugged in fiber cables backwards, nothing blows up), but the sensing (receiver) device would need to be fairly complicated.
You joke but I think this is an actual problem. I work designing infrared cameras and the biggest thing about the testing phase of sensors is to determine the bad pixels and grade each sensor based on how many there are.
More often than not, if you have a bad pixel, you can simply turn it off or filter it out in image processing. With just one pixel, if it dies, you're SOL.
On a side note, does millions of micro-mirrors sound more difficult and prone to failure than a million photodetectors to anyone else?
Reading the paper provided by another poster, it seems like configuration of these FPGA's is solely done by use of antifuse nanoconnections. This would essentially mean that these things were one-time configurable. That is, you configure the FPGA and it'd stay like that for the rest of its life. Kinda like one-time-write PROMs. Actel has been making FPGA's like this for years:
Albeit not to the same scale. These types of FPGA's are much less convenient or usable as you can just keep re-configuring them to iterate and trouble-shoot your design. This makes using them as prototyping platforms impractical.
Someone who's been able to read more into this than I and can explain to me why I'm wrong, please do so. Have they come up with an anti-fuse method that allow re-fusing?
I've looked at the examples and by far it seems far worse than VHDL. You basically add all of the syntax of Java (extending classes, constructors, class hierarchy) that are absolutely irrelevant to hardware design on top of the modular hardware design. Not to mention this provides absolutely no provision for behavioral RTL, which is pretty much what all digital design in FPGA's are done with anyway.
No. Contrary to popular belief, ASICs don't utilize all of the gates they have either. There are limitations (even more so) in ASIC-land where you only have so many metal layers on top of your silicon to route your interconnects. Granted, a human being laying it out by hand is much better than an auto-router, but there will still be waste. The same is true of an FPGA and the general rule is that you never utilize more than 70-80% of your available logic resources. This way, there is some flexibility the auto-router has when placing and routing your logic.
The 80-90% number that the article mentions is in absolute gate number (not equivalent gate-number that your custom logic running on the FPGA would use). So basically, if you design a 4-bit counter that requires, let's say, 20 gates. An FPGA will need roughly 200 real gates (each gate requiring certain number of transistors) to simulate this because it must be able to not only simulate that 4-bit counter but a large set of combinations of interconnecting those 20 gates.
This would take that routing network that is currently done by transistors, and move it into the interconnect. This is an interesting move in that it is the first (IIRC) time that interconnects have been used to perform logic (which is really what a switch fabric is) rather than to simply connect logic. An interesting side-note is that back in college, I had a professor researching into using interconnects (wires) alone to do logical operations without transistors at all. I wonder how that's going.
This is only true of some FPGA's. Xilinx, in particular, uses look-up tables to simulate logic (along with dedicated flip-flops). Actel, however, has a fine-grain architecture that uses basically a matrix of configurable (solid-state, flash-based) 3-input, 1 output tiles that very much resemble gates. Upon configuration (done once), a high voltage (higher than normal core or IO voltage) is applied and fuses the interconnects in these tiles to behave like the particular gate/flip-flop it's suppose to be have like.
the stench of unwashed programmers, or something else entirely
I've noticed this a lot. The stereotype (correct as it may be) of the computer programmer. Socially dysfunctional, bad hygiene, etc. Well guess what, perhaps that comes hand-in-hand with an occupation that requires such time and focus on one thing. Saying that this is somehow unfair because women prefer "daintier" environments and thus claiming that it is discrimination is a contradiction in concepts./not saying women do prefer daintier environments naturally//just pointing out that geeks-make-good-programmers///women can be geeks, saying that geeks turn them away from such fields is equivalent to saying they don't prefer the field////yes I'm using fark slashies/////they feel good
Slashdot Mirror
This is actually the main problem that is solved with this solution. Traditionally, electro-optical conversion was done using discrete components. This consumed a great deal of power and also added the extra restriction that a separate, optical modulator had to be added along with the central electronic chip. It also meant that the electronic chip had to somehow send a very fast electrical signal (and all the attenuation that would occur to it) to the optical module.
The optical IC they came up with isn't optical entirely. The internal logic is still electrical but they've managed to do a silicon-level electro-optical converter and directly send the optical signal out (I'm guessing through a microlens). This isn't likely to make internal logic (the next Pentium...wait they don't use that name anymore) calculate faster, but it'll be interesting to see this used as a RAM interface, for instance, or for multi-processor interconnect.
The main reason x86 is around is the software base. This isn't going to change with softcores. What will happen is that bugs associated with the more obscure/complex parts of x86 that aren't performance critical (and/or not covered by testing) can be fixed after release rather than forcing a recall. Certain features can also be updated for a speed boost. There'll still be dedicated logic (adders, multipliers, etc.) but the routing logic between these macroblocks can be entirely programmable. You'll be buying designs from Intel and updating the silicon chip you have.
Well, to be fair, that's really saying that AMD's system architecture is better. I know it's a fine line but the interconnecting architecture (in the case of AMD, it's point-to-point crosslinks and dedicated pockets of memory) is what dominates performance in the "scaling" sense. As we've seen from SGI's Altix (using the Itaniums, which uses the same shared bus that the Core 2 uses), there is nothing stopping a system designer from making a NUMA design from dedicated busses. And performance is incredible.
Which is why I said firmware.
The point of a JIT translation is that it is essentially software and can be patched without recalling the chips. The primary use (or intended primary use) of the chip, where speed would count, would be in the new instruction set and that instruction set would be implemented (read: decoded, executed) in silicon whereas x86 would be handled in software/firmware, where its complexity would not cause flaws in the chip that had to be worked around.
My point is, it doesn't eliminate the scaling problem. It merely reduces it. A design of 200 million transistors will still be much harder to verify than one that is 50 million (assuming equal logic complexity). Black box testing helps but at some point, you'll still hit the wall where it would take longer than the time you have to test a sufficient percentage of features. It's not just about money, it's about time. And unless people are content with a processor being released every 20 or 30 years, this problem will not go away.
The problem with the black box is that you never know whether the box you're using actually matches the box that will be put there. Hardware is not sequential. Everything happens at once, governed by a clock (and sometimes, without a clock). To test that kind of "black box", let alone reproduce a correct "black box" model is complex enough that the process, itself, introduces mismatches.
Well, see, that's the thing. It implies that the bug was detected before release. Believe me, it costs a lot more to recall than to delay 3 months. The problem is, existing test methods simply cannot test enough without taking *years*. You don't catch 1% more of the flaws in a flat amount of time. It takes *exponentially* more time as you asymptotically approach 100% of all possible features tested. To "get it right" as in be certain that there are no flaws in the design would take centuries.
The problem we should be asking isn't why it wasn't tested more, but rather, why it was so complex to begin with. There is only one reason for putting anything in silicon and that is for speed. I'm going to guess that a large majority of "features" on today's x86 microprocessors are not speed bottlenecks. Why could these features not be put on a re-programmable firmware? The technology exists.
Yes and no. There are limitations to HDL's (and Intel, last I heard, was all Verilog). For one, it is *very* difficult, if not impossible in certain situations, to describe asynchronous signals. With something as complicated as a microprocessor that is so aggressively designed for both power and speed, I would guess that they didn't go with a completely synchronous design (hell, no one does anymore). Locally synchronous, globally asynchronous design has been in use for a while. It helps when you want to be able to shut off, or slow down, only parts of the chip that aren't being used very much.
It is not possible to describe such things (let alone voltage islands, voltage scaling) in an HDL language and they must either be a special feature built into synthesis (with an extra set of constraints) or done by hand at the transistor/gate level.
Then there's the point of verification. Every software release since about the mid-1990's has almost been immediately followed by patches. Just because it's "1's and 0's" does not mean that it doesn't get harder to detect corner cases as complexity grows. And it's much more difficult if you have to simulate on a cycle-accurate model (boot-up for an operating system, in simulation, would take a day on a nice cluster on something as big as the Core 2).
Then there's post-synthesis/layout issues. Timing analysis do best on sequential logic (completely synchronous). When you throw in clock gating, multiple voltage islands, dynamic voltage scaling (meaning dynamic gate delays), not to mention the plethora of other techniques that those folks might be doing, what you see in simulation at the RTL level will not match what you see in reality. First rule they ever teach in any ASIC design class is never trust simulation.
The point is that abstraction, like how it's "vhdl", does not mean that it's not difficult to get right and even sometimes impossible to be certain.
They know all there is to know about god and everything. So very very sad.
Ding ding ding! You've just revealed the entire appeal of religion! "I know all that I need to know." Sure makes talking to some learned person easier on the ol' ego if you think you still know more than him "where it counts".
In a word, it provides infinite states (ok, maybe not infinite, but a lot).
A quantum inverter would take an input that was 20% 1, 80% 0 and give you 20% 0 and 80% 1. Inverting is a relatively simple function but imagine a much more complicated function, such as multiplication. A 2-input, 32-qubit multiplier takes in two inputs each with a certain distribution of all possible 32-bit values (let's say, evenly distributed in one input and 50% less than 2 million, 20% between 2 and 3 million and 30% between 3 million and 2^32-1) and gives you a 32-qubit result that contained the multiplied distribution (a probability multiplication function).
Your result, in this case, would be equivalent to doing 2^64 multiplications in a traditional binary multiplier. Of course, how you would sample the resulting data (it has to be sampled, and thus breakdown into normal 1's and 0's) would impact dramatically the usefulness of the function. You could, for instance, test for existence (does a certain number result from the function) and instead of having to compute all possible permutations one at a time, perform one pass using a qubit operation, then use a qubit "filter" operation of some sort (I'm no statistician so forgive me if I don't have an equation on hand).
The question, of course, isn't the concept of exchanging something for another but rather, how much. Someone isn't automatically entitled x amount of money for a service, they get whatever money they can get away with selling their service for. The market will determine the price. And if current technology allows a market in which said service is virtually free (the internet transfers information at a cost-per-megabyte much cheaper than cd's), then the service is worthless and is virtually free.
Software-controlled hardware scaling already exist IIRC. They've existed in a primitive form since Intel first introduced its "Speedstep" feature on its mobile Pentiums. The OS would control the clockrate of the microprocessor based on the CPU utilization.
Embedded systems (PDA's and cell phones) have had finer and more sophisticated grades of software-controlled frequency and voltage scaling and even software-controlled sleep-states.
I'm not sure why this research project is so special. I suppose since she's trying to form a standard interface, one that both hardware and software designers can independently use (whereas before, hardware designers would have to double as software designers designing the low-level control software and giving embedded software designers a library). But see, with something as customized as microchips, I'm not really sure it's possible to come up with a standard "end-all" interface that will fit all of the features a hardware designer could use.
Then there's the problem of where this software would run. The problem with software-controlled scaling isn't that software doesn't know the workload better (as it does) but rather, how fast can it communicate that information to the hardware? There's an overhead in that communication.
Not that I'm not saying software and hardware aren't merging, but it's not going to be in the realm of new software layers IMO. More likely than not, it'll be a move towards more firmware-based microprocessors with hard-wired core designs and configurable, tile-like co-processors that can be configured using non-volatile memory on startup (and stored in configuration SRAM) much like an FPGA.
One of his answers interested me. In response to question #2, he made a comparison of the cultural attitude towards video games as a source of entertainment vs other, more traditional media. In particular, it's interesting that he compares it to books, television and movies. He claimed that video games were taken less seriously and not as pervasive in modern culture.
This may be true to some degree, and certainly the sheer amount of time that books, television and film have existed with respect to the existence of video games surely can explain how it is less culturally pervasive, I think the answer lies, primarily, elsewhere.
One obvious advantage, of course, is the social aspect. People can watch TV and movies together. They can read and then discuss a book together. In essence, it's social. This is one aspect I feel video games lack in. More and more games that involve (particularly with the help of the internet) multiplayer aspects and even focus on it are coming and they will certainly help push video games into the mainstream.
Another obvious advantage is that it's so attention-dominating. When one watches TV or goes to a movie, it's generally viewed as a social event. Yes, we do have rules with our friends that no one is allowed to cause any noise during a new showing of The Office, but if you're all just kicking back with a beer in your hand watching Conan, then it's a social environment in which your full attention is not required. This, I think, is lacking in video games. One can argue that interactivity will always require more attention and that may be true to some extent. But looking at games like poker and many other such board games, I think it can be well argued that interactivity is not necessarily a social killer in which you can't take your eyes off of the game if you want to play.
The final, and probably most important reason that TV, movies, books, etc. are more culturally favored than video games is content. Let's face it, there are crappy games out there. In fact, I'd say that the majority of games are crappy. The reason that GTA was popular was not because of the graphics, the voice acting or the interface, it was because it was fun. The game was well-made with a (albeit comical) storyline and a variety of things for people to do. In a medium with so much possibility in terms of content delivery, it's a wonder that people have not done more with it. Has anyone even considered how important the story may be in a video game? I don't obsessively watch Grey's Anatomy (there, I said it) every week because I like the graphics (though there is a ton of eye-candy on that show). I watch it because of the storyline (albeit a soap-opera-ish storyline). And having the ability to augment that storyline with interactivity brings leaps and bounds of opportunity that has, thus far, not been exploited. When playing through a game becomes as emotionally thrilling as watching Peter Gibbons take an electric drill and removing the doorknob that shocks him every day, more and more people will regard it as an every-day pass time just like turning on the tube.
I really don't understand the contention. Obviously more people are interested in the Treaty of Algeron than in Park Ridge High School in New Jersey (though that particular one has a Wikipedia article). I would've thought that, as a repository of knowledge, the only and sole rating of how "worthy" an article is is how many people want to read about it. Things that are so important that they should be kept even if only one person cares about it are far too important to trust Wikipedia to keep it. It's not there to store humanity's most important information. It's there to provide access to commonly-desired that the masses want.
This thread is totally useless without....oh wait, this is /.
This, of course, is assuming that any signal inside the P4 needs to travel across the whole chip in one clock period. I believe the entire philosophy behind the Netburst design was to avoid signals traveling too far. Signals that need to get from one side of the chip to another are given multiple clock cycles (and subsequent signals after them are pipelined) to do so.
Interesting. This is essentially the photon version of AC then. Now, correct me if I'm wrong but:
1. Change in electric potential means that signals propogate at the speed of light across a chip.
2. Change in speed of photon would require photon that carried signal (or rather, the "breakpoint" where the speed changed) to travel across a chip.
Anyone else think that the first actually propogates information *faster* than the second? Now granted, photons are a lot easier to deal with (I've plugged in fiber cables backwards, nothing blows up), but the sensing (receiver) device would need to be fairly complicated.
You joke but I think this is an actual problem. I work designing infrared cameras and the biggest thing about the testing phase of sensors is to determine the bad pixels and grade each sensor based on how many there are.
More often than not, if you have a bad pixel, you can simply turn it off or filter it out in image processing. With just one pixel, if it dies, you're SOL.
On a side note, does millions of micro-mirrors sound more difficult and prone to failure than a million photodetectors to anyone else?
It uses the same IR technology. Missiles are hot and fast so it's not that difficult to see one in IR.
Reading the paper provided by another poster, it seems like configuration of these FPGA's is solely done by use of antifuse nanoconnections. This would essentially mean that these things were one-time configurable. That is, you configure the FPGA and it'd stay like that for the rest of its life. Kinda like one-time-write PROMs. Actel has been making FPGA's like this for years:
http://www.actel.com/products/mx/
Albeit not to the same scale. These types of FPGA's are much less convenient or usable as you can just keep re-configuring them to iterate and trouble-shoot your design. This makes using them as prototyping platforms impractical.
Someone who's been able to read more into this than I and can explain to me why I'm wrong, please do so. Have they come up with an anti-fuse method that allow re-fusing?
I've looked at the examples and by far it seems far worse than VHDL. You basically add all of the syntax of Java (extending classes, constructors, class hierarchy) that are absolutely irrelevant to hardware design on top of the modular hardware design. Not to mention this provides absolutely no provision for behavioral RTL, which is pretty much what all digital design in FPGA's are done with anyway.
No. Contrary to popular belief, ASICs don't utilize all of the gates they have either. There are limitations (even more so) in ASIC-land where you only have so many metal layers on top of your silicon to route your interconnects. Granted, a human being laying it out by hand is much better than an auto-router, but there will still be waste. The same is true of an FPGA and the general rule is that you never utilize more than 70-80% of your available logic resources. This way, there is some flexibility the auto-router has when placing and routing your logic.
The 80-90% number that the article mentions is in absolute gate number (not equivalent gate-number that your custom logic running on the FPGA would use). So basically, if you design a 4-bit counter that requires, let's say, 20 gates. An FPGA will need roughly 200 real gates (each gate requiring certain number of transistors) to simulate this because it must be able to not only simulate that 4-bit counter but a large set of combinations of interconnecting those 20 gates.
This would take that routing network that is currently done by transistors, and move it into the interconnect. This is an interesting move in that it is the first (IIRC) time that interconnects have been used to perform logic (which is really what a switch fabric is) rather than to simply connect logic. An interesting side-note is that back in college, I had a professor researching into using interconnects (wires) alone to do logical operations without transistors at all. I wonder how that's going.
This is only true of some FPGA's. Xilinx, in particular, uses look-up tables to simulate logic (along with dedicated flip-flops). Actel, however, has a fine-grain architecture that uses basically a matrix of configurable (solid-state, flash-based) 3-input, 1 output tiles that very much resemble gates. Upon configuration (done once), a high voltage (higher than normal core or IO voltage) is applied and fuses the interconnects in these tiles to behave like the particular gate/flip-flop it's suppose to be have like.
the stench of unwashed programmers, or something else entirely
/not saying women do prefer daintier environments naturally //just pointing out that geeks-make-good-programmers ///women can be geeks, saying that geeks turn them away from such fields is equivalent to saying they don't prefer the field ////yes I'm using fark slashies /////they feel good
I've noticed this a lot. The stereotype (correct as it may be) of the computer programmer. Socially dysfunctional, bad hygiene, etc. Well guess what, perhaps that comes hand-in-hand with an occupation that requires such time and focus on one thing. Saying that this is somehow unfair because women prefer "daintier" environments and thus claiming that it is discrimination is a contradiction in concepts.