You are absolutely correct. Before FPGAs were CPLDs -- the same idea with a different technology. CPLDs didn't take over the world either.
The first I heard about all this was MIT's Oxygen project (I think it was called.) I haven't heard anything much since... I think the proof is in the pudding.:)
FPGAs will have their niche, but for anything truly mass-market, and for really really huge designs (like motherboards, for example) ASICs will always rule.
I am mostly familiar with Xilinx's parts, but my understanding is that really the only other maker is Altera and they are a couple years behind.
The Virtex II (Xilinx's latest) clocks at up to 200MHz, though the more complicated your circuitry, the lower it gets. 200MHz is a theoretical max -- like Ethernet; you never quite reach it in practice.
It includes a number of on-chip resources, such as block memories (which are more like cache SRAM than DRAM DIMMs you are probably used to) and 18-bit-wide hardware multipliers. The Virtex II Pro line is a Virtex II plus an actual processor core -- PowerPC, ARM, or their own MicroBlaze I believe. (That alone is proof enough that von Neumann machines aren't dead -- Xilinx INCLUDES one in some of their FPGA parts!)
You can get them in various sizes, which basically means how many CLBs they have. Xilinx measures these in "logic gates" though that is really a somewhat sketchy metric (like bogomips, sort of.)
And yes, you can actually run data through and get results back one per cycle. To accomplish this, you usually HAVE to pipeline the design. Typically you end up with a scenario where you fill up the chip's logic with your design, and start feeding it data at some clock speed. Then a few hundred cycles later, you start getting results back. Once you do, they come at one per cycle.
We have an application where we are actually clocking the thing at 166MHz -- which is the speed of a memory bus, not coincidentally. Given this config, we are basically clocking the chip as fast as the memory can feed us data. The idea is that we read from one bank at 166MHz, and write to another at 166MHz.
One way to think of this is as a memory copy operation, with an "invisible" calculation wedged in between. When you consider what a Pentium 4 would have to do (fetch instructions from cache/memory, fetch data from cache/memory, populat registers, perform assembly operations, store data back, not to mention task switching on the OS, checking for pointer validity, and so on) you begin to see the advantage of FPGAs.
Usually when you are trying to compile something down to logic gates, you have to handle instruction scheduling. For example, in any conceivable situation, division always takes longer than addition. So, you have to make sure that while you're waiting for a division to complete all the rest of your data doesn't evaporate.
This isn't like a general purpose processor == there are no persistent registers here. Use it or lose it. So you have to stick in tons of shift registers everywhere, as pipeline delayers.
So it's not as simple as just saying res = (a + b)/r + (q * p); or something, because you have to synchronize all the data. All this, of course, is just for a calculation: imagine the difficulty when you are waiting for signals on off-chip pins, when you don't even know how long you're going to be waiting. Also consider how you handle cases where you have to talk to memory: you usually have to write your own memory CONTROLLER, or at least use someone else's, meaning you actually have to worry about row and column strobes, whether it's DDR or not, and so on.
If you've done multithreading programming and understand those difficulties, then take that and multiply the difficulty by a couple times, and you just about have it.
All that said, though, you're right: it shouldn't be that hard. If all you want to do is use C to express a calculation, that is fairly easy to boil down to a Verilog or VHDL module.
The problem is that most of the 3GL-to-HDL vendors try and boil the whole ocean. They want you to use nothing but their tool, and never have to look at Verilog. That is where things really start to break down.
An example of this done mostly RIGHT is a company whose name I can't remember. (AccelChip?) They make a product that takes Matlab code and reduces it to hardware. That's easier in a lot of ways, because Matlab is really all about simply allowing you to easily express a mathematical system or problem. There aren't all these control flow, I/O, and other random effects. My understanding is that this Matlab-to-VHDL tool works quite well.
So, it all depends on what you want to do with the FPGA.:)
Okay, no. FPGAs are NOT going to completely change computing.
First, you have to understand what they are: basically an FPGA is an SRAM core arranged in a grid, with a layer of logic cells (Configurable Logic Blocks, in Xilinx's parlance) layered on top. These logic cells consist of basically function generators that use the data in the underlying SRAM to configure their outputs. Typically they are used as look-up tables (LUTs) -- basically truth tables that can represent arbitrary logic functions -- or as shift registers, or as memories. On top of THAT layer is an interconnection layer used for connecting CLBs in useful ways. The FPGA is re-configured by loading the underlying SRAM with a fresh bitmap image, and rebuilding connections in the routing fabric layer.
You write for FPGAs the same way you build ASICs. You use the same languages (Verilog, VHDL) and sometimes the same toolchain. The point being: this is HARD. Trust me, I've been doing it. Verilog is damn cool, but remember that you're still building this stuff almost gate-by-gate.
There are a number of tools out there that do things like translate 3GL languages (such as Xilinx's Forge tool for Java, or Celoxica's DK1 suite for Handel-C) to an HDL like Verilog. Other tools like BYU's JHDL are essentially scripting frameworks for generating parameterized designs that can be dumped directly into netlist (roughly equivalent to a.o file.)
My job for the past several months has been to obtain and evaluate these tools. I can tell you that these tools are not there yet.
So what do you use FPGAs for? Well, for the next 5 years, likely one of two things: either really cheap supercomputers (which is what we are working on) or as a "3D Graphics card play." The supercomputing play is obvious, the the other one bears explanation.
Anything you can think of goes faster if you implement it in hardware. 3D graphics is a great example: most cards today consist of a bunch of matrix multipliers plus some memory for the framebuffer, and a bunch of convenience operations that you do in hardware as well (like textures and lighting and so on.) Because it's in hardware, it's way faster than anything you could do on a general purpose processor.
Now, the problem is that hardware means ASICs (until recently.) ASICs are only cheap in large volumes. Thus, for applications that are not mass-market (like graphics cards are) it is not practical to build out an industry building hardware accelerators for them.
That's where FPGAs come in. FPGAs cost more per ASIC, but less than ASIC in small volumes. This suddenly makes it practical to make custom hardware accelerators for almost anything you can think of.
This is also true of supercomputing: supercomputers are still general-purpose, just not THAT general-purpose. Your algorithm still benefits when you can just reduce it to logic and load it onto a chip. You might only be running at 200MHz, but when you get a full answer every clock cycle, you suddenly do a lot better than when you get an answer every 2000 cycles on your 2GHz processor.
So to get back on topic, where will we see FPGAs? Well, you might expect to see an FPGA appear alongside the CPU on every desktop made in a few years; programs that have a routine that needs hardware acceleration can just make use of it. (Think PlayStation 4, here.)
You might also see things like PDAs come with FPGA chips: if your car's engine dies, you can just download (off your wireless net which will be ubiqutious *cough*) the diagnostic routine for you car and load it into that FPGA and have your car tell you what's wrong.
Aerospace companies will love them, too. Whoops, didn't catch that unit conversion bug in your satellite firmware before launch? Well, just reprogram the FPGA! No need to send up an astronaut to swap out an ASIC or a board.
What you're NOT going to see is every application ported to FPGAs willy-nilly, because like I said, this stuff is not easy. I'm coming a
I'm not sure I agree with your cost estimate. In terms of silicon, yes: it's probably $5 or less added to the raw materials cost of the board.
But to that, you have to add the costs of the engineers whose task it was to add and integrate the hardware, the interns whose job it was to devise and implement test cases for the hardware, the time spent on the line testing the device, the cost to the company due to yield affects attributed to the part, and so on.
Suppose all those "legacy" parts go away tomorrow. Would we see manufacturers drop board costs by $5, $10, or $20? Perhaps not -- they'd probably charge the same amount or more and just have better margins on their quarterly results.
Still, better margins for the manufacturers means more room for R&D and QA, which means better products for us in the long term.
I don't necessarily care if my motherboard has a parallel port I don't use, and as a hardware designer I sure do like to have a serial port on there. However, as a consumer I don't really want the manufacturers to focus on support for devices I don't care about. If enough people stop caring about a device, it should just go away.
People used to build outhouses to go along with their homes, but then they upgraded to the "Universal Plumbing Bus." You don't expect new houses to come with outhouses as well as bathrooms, do you?
More importantly, he should make sure NOT to shoot down the stalactite in the Gravity Chamber. There's a missile expansion in there, and shooting down the stalactite exposes a grapple point to get to the missiles.
However, if you shoot that down, and leave the room without claiming the missile expansion, then the grapple point is dead forever after. Since you can shoot that thing down long before you get the grapple beam, this is easy to do.
If you do this, you can still beat the game, you just can't reach 100% items and get the third ending. That really pissed me off when I reached 99%.
Yeah, sounds reasonable. There have also been these "rumors" (or are they more concrete, now?) about how Red Hat is coming out with a multimedia/desktop version which would be more like a separate distribution. They also have their new concrete delineations that they introduced with the up2date revision recently.
Perhaps a jump to 9 makes more sense, as a way to create a clean break or something. I guess we'll find out soon...
Hmm. What you mention (GNOME and KDE being the culprits) would imply that library (i.e. version) compatibility has changed. (...and I'm sure it has.)
However, I always thought that by "binary compatibility" RH just referred to ELF format, C/C++ binary ABI, and so on. I seem to recall 7.0 and 7.1+ being rather a disaster in terms of library version compatibility, even though they were "binary compatible." (Your program would run, it just couldn't find the.so it wanted.)
Red Hat bases their version numbers on binary compatibility. That is, every point release in a given series is (in theory) binary compatible with all the other point releases in that series.
Red Hat increments the major number when binary compatibility changes. For example, 7.3, 7.2, 7.1, and 7.0 are all back-compatible, but 8.0 and 7.x are not (necessarily.) 8.0 shipped with gcc 3.2, which is what broke binary compatibility.
The problem (to my mind) is that Red Hat is releasing 9, when there was only an 8.0. And that's been, what, 9 - 10 months? As a result, the Red Hat 8.x "binary platform" will be extant for only 9 - 10 months; what's up with that? There are also a number of semi-minor obnoxious bugs and regressions in 8.0 that I expected to be fixed in an 8.1.
Apparently they broke binary compatibility when I wasn't looking. Guess I should have followed the betas more closely.
I suppose it's also possible that Red Hat has chosen to deviate from the binary-compatibilty benchmark they've been using.
Yeah I was wondering about that myself. A pretty basic design I synthesized sucked up a good 3700+ gates, and that was one that didn't really do anything except a little (IEEE754) math. It was only a few multipliers and adders -- and on the part I targeted, it was using built-in multipliers so it didn't have to use LUTs for it.
I suspect you're right about it being used as an I/O router.
Could be "scratch space", or for future DRM as you point out. I like to think it'll be for more though.
Someday I'd like to see FPGAs in all sorts of things. The classic (albeit somewhat silly) example I like to use is you're driving down the road and you go through a puddle of water which disables your car's computer. So you download the controller core from GM's (or whoever's) site, load it into the FPGA on your PDA, and use it to drive to a service shop.
Kind of a contrived example, but my ultimate point is that with pervasive FPGAs, and perhaps some kind of pervasive "universal connector" wired to the FPGA, you can reconfigure a device to do things it wasn't specifically designed for.
Blue sky thinking aside, I can think of other uses for it, such as the "cell phone" model where you alternatively use it for digital and analog control stuff by reprogramming it. That way you only need one part in the device instead of two, and it makes interconnection circuitry simpler.
You might also program it to be a DSP-microprocessor today (for maybe the media player or something), and then reprogram it to be the cell chip for a Treo-like device tomorrow.
Yeah, DDR is also a good point. Now that you mention it, I also remember some Japanese game that involves kicking some kind of prosthetic butt mounted on the cabinet. It was like some kind of twisted "test your strength" game that judged you by how hard you kicked butt vs. how hard you swung a hammer or something.
So, maybe my whole point is just so much overanalysis. Maybe the industry is stagnating just because of the almighty buck: the truly innovative games aren't surefire hits, and companies are too risk-averse to fund them. They'd rather take the more "straightforward" route and compete on how much money they dump into eye and ear candy.
Final Fantasy X certainly felt that way, when compared to FF7.
Hmm, good point. In my hypothetical future world, the GBA would still be a simple enough device to allow small creative teams to build entire games. So maybe the GBA (and similar devices, like cell phones and whatnot) will remain a sort of playground for "indie" game developers.
I still think that the big consoles and PC games will continue to migrate in the direction of movies, with the bigger == better mentality. Heh... maybe we'll find that pound for pound, the GBA has better games that may not be as flashy but are more creative and fun.
For example... Mario Sunshine is quite cool, but I am still hard-pressed to say it's a better game than Super Mario World (aka Super Mario Advance 2 on the GBA.)
Yeah, I've been pondering this myself. To be considered a "great game" today you have to have dazzling graphics, great video cut-scenes, detailed in-game models and physics, etc. Oh, and of course you have to have great game-play.
The problem with this is that only the game play can really be done by "one person with a vision." Everything else takes real human blood, sweat, and tears to produce. That is a huge cost, and is a heavy burden to bear.
The gaming industry as it currently exists has been based on a studio model as you point out. That worked fine when a small team could realistically accomplish all the work to make a game. Unfortunately, that model doesn't work as well when you have huge teams, it seems, because the cost outruns the productivity gains. Or something, anyway; maybe I'm talking out of my arse.
But the key insight to me is that people have been saying for years that eventually games and movies will "merge" into some kind of interactive entertainment. Well, maybe, maybe not, but I do think that it is obvious that games are becoming more like movies. Consequently they are sooner or later going to develop movie-like budgets.
Only large organizations can fund that kind of thing (indie film community aside for the moment.) As a result I can't see anything in the future of gaming communities except consolidation to the point where the companies ARE large enough to fund high-end games.
Maybe it'll turn out something like the (primarily European) auto industry (which to a degree it already is:) a number of studios work on concept and prototype contracts, and large corporations productize the prototypes.
Today, the game studios make entire games while the publishers (like EA) handle distribution. I suspect that the balance will shift a bit, so that instead of producing entire completed games, the smaller studios will produce an upgrade game engine, or a new set of character models, or whatever. Compare this with car studios that produce new engine upgrades and tweaks, aggressive new body styles, and so on. The studios then sort of sell this technology and art to the large manufacturers/publishers.
This also sounds somewhat like what Nintendo is trying to do with their small groups: let the groups focus on innovation and new ideas while the large institutional development shops actually make games. I think it's a model that can work, although I don't think it'll be quite the same atmosphere that the industry has enjoyed up until now.
I'm also not sure how I feel about it. The best games I've seen have been really works of art created by a single group. Grand Theft Auto, StarCraft/WarCraft, Final Fantasy, etc., and of course the classic games from years past. There are some mainstream movies that I've enjoyed as much that clearly have the same kind of hand-crafted feel, but they are few and far between. I am afraid that as the game industry "matures," it will go along a similar route.
But, maybe not. Who knows, really? I guess we will have to wait to find out.
Actually, High Fidelity was first a novel by Nick Hornsby before John Cusack adapted it to film.
It was also set in London, so maybe that's why she knew it.:)
Of course, I have no idea whatsoever if that line appears in the novel (which I have not read.) It certainly does appear in the movie.
Short version is that you pay IBM $30, and you can stuff a box (of a certain size) with as much hardware as will fit, and ship it back to IBM via UPS. IBM will then refurbish the stuff and donate it to charity, or will recycle it.
http://www.ibm.com/ibm/environment/products/pcrs er vice.shtml
Re:...because there's already research here
on
Sili-Hudson Valley?
·
· Score: 1
Heh heh... no clue if that's true or not. I would tend to suspect it's a myth, since the USSR probably didn't publish their strike list, and even if the CIA (or whoever) knew it they probably wouldn't publish it to the citizenry to avoid frightening the public.:)
However, I DO like the guards in black ninja outfits who patrol the roof with M-16s.
It was also rather spooky driving past the place on September 11. They had it roadblocked entirely, and the guards were giving the evil-eye even to cars passing on the road.
...because there's already research here
on
Sili-Hudson Valley?
·
· Score: 1
Research begets research. You don't just drop a major research facility in a place where there's no one to collaborate with.
GE Research has been around over 100 years, invented industrial diamonds and Lexan (among many other things; remember GE-cum-Honeywell mainframes?) and has employed several Nobel Prize winners.
Two world-class research centers, and that's just in Niskayuna. As others have mentioned, RPI is nearby. The local state University in Albany has a Turing Award winner on the CS staff.
Yes, I am a Computer Scientist at GE Global Research.
Microsoft is basically saying, "We're going to make you use.NET to develop software. We're also going to make you pay for us to maintain the infrastructure so it doesn't cost us anything to make you use it."
This is insane, and it's classic monopoly pricing. Most companies follow general market principles, like supply and demand, and ubiquity. Sun could never get away with charging consumers for a service and ALSO charging app server vendors for the privilege; the vendors and app developers just wouldn't stand for it. MSFT can get away with it because they're MSFT.
Could someone please explain to me how this is not leveraging a monopoly on the desktop (which will, realistically, require consumers to use.NET) to get an unrelated market (app developers) to pay money? I'm trying to remain objective here, but...
All X is really about is adding network transparency to GUI apps. To accomplish this, the protocol has a notion of windows, window managers, decorations, etc. There's nothing about X, however, that really has anything to do with hardware. X has no provisions for hardware acceleration or transparent windows, for example.
You're confusing X the protocol with 90% of all implementations of X, which themselves include a framebuffer, hardware acceleration, etc. For example, XFree86 is really just a GUI system that happens to implement the X protocol.
The main reason that implementations tend to be both a hardware driver and an X server is that the protocol can be a bit hairy to try and "map" into an alien GUI system. (And more than that, Unix systems typically don't even have anything else to map to, anyway, so if the X server isn't providing the hardware driver, there's nothing there.)
Anyway, the core issue is that there isn't (theoretically) anything that says that an X server has to be a hardware driver. Just look at Hummingbird's Exceed program, which implements an X server on Windows. Writing an X server that would run on a "native" framebuffer isn't such an exotic idea; Exceed actually works extremely well.
Granted, you can almost always tell that a particular program is an X program, because in practice X does dictate a certain look and feel (since a legacy X app would be running with a widget set that might or might not look like the native set.) But that's why they're porting GTK, and why the X server is for legacy apps.
Personally, I just like how 300 baud (which is 300 bps) is 1/20 of 56,600 bps. I had no idea that 6,000 = 56,600. It's a good thing we have journalists to do such extensive research and fact-checking; just think of how long the mathematicians have been overlooking that amazing equality!
Slashdot Mirror
You are absolutely correct. Before FPGAs were CPLDs -- the same idea with a different technology. CPLDs didn't take over the world either.
:)
The first I heard about all this was MIT's Oxygen project (I think it was called.) I haven't heard anything much since... I think the proof is in the pudding.
FPGAs will have their niche, but for anything truly mass-market, and for really really huge designs (like motherboards, for example) ASICs will always rule.
Yes, exactly. :)
I like your API analogy, I think I will remember that and use it in the future myself. It's a good way to think of it.
I am mostly familiar with Xilinx's parts, but my understanding is that really the only other maker is Altera and they are a couple years behind.
The Virtex II (Xilinx's latest) clocks at up to 200MHz, though the more complicated your circuitry, the lower it gets. 200MHz is a theoretical max -- like Ethernet; you never quite reach it in practice.
It includes a number of on-chip resources, such as block memories (which are more like cache SRAM than DRAM DIMMs you are probably used to) and 18-bit-wide hardware multipliers. The Virtex II Pro line is a Virtex II plus an actual processor core -- PowerPC, ARM, or their own MicroBlaze I believe. (That alone is proof enough that von Neumann machines aren't dead -- Xilinx INCLUDES one in some of their FPGA parts!)
You can get them in various sizes, which basically means how many CLBs they have. Xilinx measures these in "logic gates" though that is really a somewhat sketchy metric (like bogomips, sort of.)
And yes, you can actually run data through and get results back one per cycle. To accomplish this, you usually HAVE to pipeline the design. Typically you end up with a scenario where you fill up the chip's logic with your design, and start feeding it data at some clock speed. Then a few hundred cycles later, you start getting results back. Once you do, they come at one per cycle.
We have an application where we are actually clocking the thing at 166MHz -- which is the speed of a memory bus, not coincidentally. Given this config, we are basically clocking the chip as fast as the memory can feed us data. The idea is that we read from one bank at 166MHz, and write to another at 166MHz.
One way to think of this is as a memory copy operation, with an "invisible" calculation wedged in between. When you consider what a Pentium 4 would have to do (fetch instructions from cache/memory, fetch data from cache/memory, populat registers, perform assembly operations, store data back, not to mention task switching on the OS, checking for pointer validity, and so on) you begin to see the advantage of FPGAs.
It depends on what you're trying to do.
/r + (q * p); or something, because you have to synchronize all the data. All this, of course, is just for a calculation: imagine the difficulty when you are waiting for signals on off-chip pins, when you don't even know how long you're going to be waiting. Also consider how you handle cases where you have to talk to memory: you usually have to write your own memory CONTROLLER, or at least use someone else's, meaning you actually have to worry about row and column strobes, whether it's DDR or not, and so on.
:)
Usually when you are trying to compile something down to logic gates, you have to handle instruction scheduling. For example, in any conceivable situation, division always takes longer than addition. So, you have to make sure that while you're waiting for a division to complete all the rest of your data doesn't evaporate.
This isn't like a general purpose processor == there are no persistent registers here. Use it or lose it. So you have to stick in tons of shift registers everywhere, as pipeline delayers.
So it's not as simple as just saying res = (a + b)
If you've done multithreading programming and understand those difficulties, then take that and multiply the difficulty by a couple times, and you just about have it.
All that said, though, you're right: it shouldn't be that hard. If all you want to do is use C to express a calculation, that is fairly easy to boil down to a Verilog or VHDL module.
The problem is that most of the 3GL-to-HDL vendors try and boil the whole ocean. They want you to use nothing but their tool, and never have to look at Verilog. That is where things really start to break down.
An example of this done mostly RIGHT is a company whose name I can't remember. (AccelChip?) They make a product that takes Matlab code and reduces it to hardware. That's easier in a lot of ways, because Matlab is really all about simply allowing you to easily express a mathematical system or problem. There aren't all these control flow, I/O, and other random effects. My understanding is that this Matlab-to-VHDL tool works quite well.
So, it all depends on what you want to do with the FPGA.
Okay, no. FPGAs are NOT going to completely change computing.
.o file.)
First, you have to understand what they are: basically an FPGA is an SRAM core arranged in a grid, with a layer of logic cells (Configurable Logic Blocks, in Xilinx's parlance) layered on top. These logic cells consist of basically function generators that use the data in the underlying SRAM to configure their outputs. Typically they are used as look-up tables (LUTs) -- basically truth tables that can represent arbitrary logic functions -- or as shift registers, or as memories. On top of THAT layer is an interconnection layer used for connecting CLBs in useful ways. The FPGA is re-configured by loading the underlying SRAM with a fresh bitmap image, and rebuilding connections in the routing fabric layer.
You write for FPGAs the same way you build ASICs. You use the same languages (Verilog, VHDL) and sometimes the same toolchain. The point being: this is HARD. Trust me, I've been doing it. Verilog is damn cool, but remember that you're still building this stuff almost gate-by-gate.
There are a number of tools out there that do things like translate 3GL languages (such as Xilinx's Forge tool for Java, or Celoxica's DK1 suite for Handel-C) to an HDL like Verilog. Other tools like BYU's JHDL are essentially scripting frameworks for generating parameterized designs that can be dumped directly into netlist (roughly equivalent to a
My job for the past several months has been to obtain and evaluate these tools. I can tell you that these tools are not there yet.
So what do you use FPGAs for? Well, for the next 5 years, likely one of two things: either really cheap supercomputers (which is what we are working on) or as a "3D Graphics card play." The supercomputing play is obvious, the the other one bears explanation.
Anything you can think of goes faster if you implement it in hardware. 3D graphics is a great example: most cards today consist of a bunch of matrix multipliers plus some memory for the framebuffer, and a bunch of convenience operations that you do in hardware as well (like textures and lighting and so on.) Because it's in hardware, it's way faster than anything you could do on a general purpose processor.
Now, the problem is that hardware means ASICs (until recently.) ASICs are only cheap in large volumes. Thus, for applications that are not mass-market (like graphics cards are) it is not practical to build out an industry building hardware accelerators for them.
That's where FPGAs come in. FPGAs cost more per ASIC, but less than ASIC in small volumes. This suddenly makes it practical to make custom hardware accelerators for almost anything you can think of.
This is also true of supercomputing: supercomputers are still general-purpose, just not THAT general-purpose. Your algorithm still benefits when you can just reduce it to logic and load it onto a chip. You might only be running at 200MHz, but when you get a full answer every clock cycle, you suddenly do a lot better than when you get an answer every 2000 cycles on your 2GHz processor.
So to get back on topic, where will we see FPGAs? Well, you might expect to see an FPGA appear alongside the CPU on every desktop made in a few years; programs that have a routine that needs hardware acceleration can just make use of it. (Think PlayStation 4, here.)
You might also see things like PDAs come with FPGA chips: if your car's engine dies, you can just download (off your wireless net which will be ubiqutious *cough*) the diagnostic routine for you car and load it into that FPGA and have your car tell you what's wrong.
Aerospace companies will love them, too. Whoops, didn't catch that unit conversion bug in your satellite firmware before launch? Well, just reprogram the FPGA! No need to send up an astronaut to swap out an ASIC or a board.
What you're NOT going to see is every application ported to FPGAs willy-nilly, because like I said, this stuff is not easy. I'm coming a
I'm not sure I agree with your cost estimate. In terms of silicon, yes: it's probably $5 or less added to the raw materials cost of the board.
But to that, you have to add the costs of the engineers whose task it was to add and integrate the hardware, the interns whose job it was to devise and implement test cases for the hardware, the time spent on the line testing the device, the cost to the company due to yield affects attributed to the part, and so on.
Suppose all those "legacy" parts go away tomorrow. Would we see manufacturers drop board costs by $5, $10, or $20? Perhaps not -- they'd probably charge the same amount or more and just have better margins on their quarterly results.
Still, better margins for the manufacturers means more room for R&D and QA, which means better products for us in the long term.
I don't necessarily care if my motherboard has a parallel port I don't use, and as a hardware designer I sure do like to have a serial port on there. However, as a consumer I don't really want the manufacturers to focus on support for devices I don't care about. If enough people stop caring about a device, it should just go away.
People used to build outhouses to go along with their homes, but then they upgraded to the "Universal Plumbing Bus." You don't expect new houses to come with outhouses as well as bathrooms, do you?
More importantly, he should make sure NOT to shoot down the stalactite in the Gravity Chamber. There's a missile expansion in there, and shooting down the stalactite exposes a grapple point to get to the missiles.
However, if you shoot that down, and leave the room without claiming the missile expansion, then the grapple point is dead forever after. Since you can shoot that thing down long before you get the grapple beam, this is easy to do.
If you do this, you can still beat the game, you just can't reach 100% items and get the third ending. That really pissed me off when I reached 99%.
Yeah, sounds reasonable. There have also been these "rumors" (or are they more concrete, now?) about how Red Hat is coming out with a multimedia/desktop version which would be more like a separate distribution. They also have their new concrete delineations that they introduced with the up2date revision recently.
Perhaps a jump to 9 makes more sense, as a way to create a clean break or something. I guess we'll find out soon...
Hmm. What you mention (GNOME and KDE being the culprits) would imply that library (i.e. version) compatibility has changed. (...and I'm sure it has.)
.so it wanted.)
However, I always thought that by "binary compatibility" RH just referred to ELF format, C/C++ binary ABI, and so on. I seem to recall 7.0 and 7.1+ being rather a disaster in terms of library version compatibility, even though they were "binary compatible." (Your program would run, it just couldn't find the
Am I on crack (which is entirely possible)?
Red Hat bases their version numbers on binary compatibility. That is, every point release in a given series is (in theory) binary compatible with all the other point releases in that series.
Red Hat increments the major number when binary compatibility changes. For example, 7.3, 7.2, 7.1, and 7.0 are all back-compatible, but 8.0 and 7.x are not (necessarily.) 8.0 shipped with gcc 3.2, which is what broke binary compatibility.
The problem (to my mind) is that Red Hat is releasing 9, when there was only an 8.0. And that's been, what, 9 - 10 months? As a result, the Red Hat 8.x "binary platform" will be extant for only 9 - 10 months; what's up with that? There are also a number of semi-minor obnoxious bugs and regressions in 8.0 that I expected to be fixed in an 8.1.
Apparently they broke binary compatibility when I wasn't looking. Guess I should have followed the betas more closely.
I suppose it's also possible that Red Hat has chosen to deviate from the binary-compatibilty benchmark they've been using.
Yeah I was wondering about that myself. A pretty basic design I synthesized sucked up a good 3700+ gates, and that was one that didn't really do anything except a little (IEEE754) math. It was only a few multipliers and adders -- and on the part I targeted, it was using built-in multipliers so it didn't have to use LUTs for it.
I suspect you're right about it being used as an I/O router.
Hmm. I'd heard about $8,000 for the Virtex 2 Pro 8MM gate part; you must be a better customer than us. :)
Could be "scratch space", or for future DRM as you point out. I like to think it'll be for more though.
Someday I'd like to see FPGAs in all sorts of things. The classic (albeit somewhat silly) example I like to use is you're driving down the road and you go through a puddle of water which disables your car's computer. So you download the controller core from GM's (or whoever's) site, load it into the FPGA on your PDA, and use it to drive to a service shop.
Kind of a contrived example, but my ultimate point is that with pervasive FPGAs, and perhaps some kind of pervasive "universal connector" wired to the FPGA, you can reconfigure a device to do things it wasn't specifically designed for.
Blue sky thinking aside, I can think of other uses for it, such as the "cell phone" model where you alternatively use it for digital and analog control stuff by reprogramming it. That way you only need one part in the device instead of two, and it makes interconnection circuitry simpler.
You might also program it to be a DSP-microprocessor today (for maybe the media player or something), and then reprogram it to be the cell chip for a Treo-like device tomorrow.
That kind of thing...
Not if you don't mind if it crashes.
Heh heh...
Man, the Counterexample Hits just keep on coming!
Yeah, DDR is also a good point. Now that you mention it, I also remember some Japanese game that involves kicking some kind of prosthetic butt mounted on the cabinet. It was like some kind of twisted "test your strength" game that judged you by how hard you kicked butt vs. how hard you swung a hammer or something.
So, maybe my whole point is just so much overanalysis. Maybe the industry is stagnating just because of the almighty buck: the truly innovative games aren't surefire hits, and companies are too risk-averse to fund them. They'd rather take the more "straightforward" route and compete on how much money they dump into eye and ear candy.
Final Fantasy X certainly felt that way, when compared to FF7.
I still think that the big consoles and PC games will continue to migrate in the direction of movies, with the bigger == better mentality. Heh... maybe we'll find that pound for pound, the GBA has better games that may not be as flashy but are more creative and fun.
For example... Mario Sunshine is quite cool, but I am still hard-pressed to say it's a better game than Super Mario World (aka Super Mario Advance 2 on the GBA.)
Yeah, I've been pondering this myself. To be considered a "great game" today you have to have dazzling graphics, great video cut-scenes, detailed in-game models and physics, etc. Oh, and of course you have to have great game-play.
The problem with this is that only the game play can really be done by "one person with a vision." Everything else takes real human blood, sweat, and tears to produce. That is a huge cost, and is a heavy burden to bear.
The gaming industry as it currently exists has been based on a studio model as you point out. That worked fine when a small team could realistically accomplish all the work to make a game. Unfortunately, that model doesn't work as well when you have huge teams, it seems, because the cost outruns the productivity gains. Or something, anyway; maybe I'm talking out of my arse.
But the key insight to me is that people have been saying for years that eventually games and movies will "merge" into some kind of interactive entertainment. Well, maybe, maybe not, but I do think that it is obvious that games are becoming more like movies. Consequently they are sooner or later going to develop movie-like budgets.
Only large organizations can fund that kind of thing (indie film community aside for the moment.) As a result I can't see anything in the future of gaming communities except consolidation to the point where the companies ARE large enough to fund high-end games.
Maybe it'll turn out something like the (primarily European) auto industry (which to a degree it already is:) a number of studios work on concept and prototype contracts, and large corporations productize the prototypes.
Today, the game studios make entire games while the publishers (like EA) handle distribution. I suspect that the balance will shift a bit, so that instead of producing entire completed games, the smaller studios will produce an upgrade game engine, or a new set of character models, or whatever. Compare this with car studios that produce new engine upgrades and tweaks, aggressive new body styles, and so on. The studios then sort of sell this technology and art to the large manufacturers/publishers.
This also sounds somewhat like what Nintendo is trying to do with their small groups: let the groups focus on innovation and new ideas while the large institutional development shops actually make games. I think it's a model that can work, although I don't think it'll be quite the same atmosphere that the industry has enjoyed up until now.
I'm also not sure how I feel about it. The best games I've seen have been really works of art created by a single group. Grand Theft Auto, StarCraft/WarCraft, Final Fantasy, etc., and of course the classic games from years past. There are some mainstream movies that I've enjoyed as much that clearly have the same kind of hand-crafted feel, but they are few and far between. I am afraid that as the game industry "matures," it will go along a similar route.
But, maybe not. Who knows, really? I guess we will have to wait to find out.
Actually, High Fidelity was first a novel by Nick Hornsby before John Cusack adapted it to film. It was also set in London, so maybe that's why she knew it. :)
Of course, I have no idea whatsoever if that line appears in the novel (which I have not read.) It certainly does appear in the movie.
> I guess he was just pissed.
Either that, or he's been playing Grand Theft Auto 3 recently.
Short version is that you pay IBM $30, and you can stuff a box (of a certain size) with as much hardware as will fit, and ship it back to IBM via UPS. IBM will then refurbish the stuff and donate it to charity, or will recycle it.
s er vice.shtml
http://www.ibm.com/ibm/environment/products/pcr
Heh heh... no clue if that's true or not. I would tend to suspect it's a myth, since the USSR probably didn't publish their strike list, and even if the CIA (or whoever) knew it they probably wouldn't publish it to the citizenry to avoid frightening the public. :)
However, I DO like the guards in black ninja outfits who patrol the roof with M-16s.
It was also rather spooky driving past the place on September 11. They had it roadblocked entirely, and the guards were giving the evil-eye even to cars passing on the road.
Research begets research. You don't just drop a major research facility in a place where there's no one to collaborate with.
GE Global Research Center
The Knolls Atomic Power Lab
GE Research has been around over 100 years, invented industrial diamonds and Lexan (among many other things; remember GE-cum-Honeywell mainframes?) and has employed several Nobel Prize winners.
Two world-class research centers, and that's just in Niskayuna. As others have mentioned, RPI is nearby. The local state University in Albany has a Turing Award winner on the CS staff.
Yes, I am a Computer Scientist at GE Global Research.
Microsoft is basically saying, "We're going to make you use .NET to develop software. We're also going to make you pay for us to maintain the infrastructure so it doesn't cost us anything to make you use it."
.NET) to get an unrelated market (app developers) to pay money? I'm trying to remain objective here, but...
This is insane, and it's classic monopoly pricing. Most companies follow general market principles, like supply and demand, and ubiquity. Sun could never get away with charging consumers for a service and ALSO charging app server vendors for the privilege; the vendors and app developers just wouldn't stand for it. MSFT can get away with it because they're MSFT.
Could someone please explain to me how this is not leveraging a monopoly on the desktop (which will, realistically, require consumers to use
I think that's a bit too simplistic a notion.
All X is really about is adding network transparency to GUI apps. To accomplish this, the protocol has a notion of windows, window managers, decorations, etc. There's nothing about X, however, that really has anything to do with hardware. X has no provisions for hardware acceleration or transparent windows, for example.
You're confusing X the protocol with 90% of all implementations of X, which themselves include a framebuffer, hardware acceleration, etc. For example, XFree86 is really just a GUI system that happens to implement the X protocol.
The main reason that implementations tend to be both a hardware driver and an X server is that the protocol can be a bit hairy to try and "map" into an alien GUI system. (And more than that, Unix systems typically don't even have anything else to map to, anyway, so if the X server isn't providing the hardware driver, there's nothing there.)
Anyway, the core issue is that there isn't (theoretically) anything that says that an X server has to be a hardware driver. Just look at Hummingbird's Exceed program, which implements an X server on Windows. Writing an X server that would run on a "native" framebuffer isn't such an exotic idea; Exceed actually works extremely well.
Granted, you can almost always tell that a particular program is an X program, because in practice X does dictate a certain look and feel (since a legacy X app would be running with a widget set that might or might not look like the native set.) But that's why they're porting GTK, and why the X server is for legacy apps.
Personally, I just like how 300 baud (which is 300 bps) is 1/20 of 56,600 bps. I had no idea that 6,000 = 56,600. It's a good thing we have journalists to do such extensive research and fact-checking; just think of how long the mathematicians have been overlooking that amazing equality!
:P
Or am I missing something here?