My hat's off to this guy for the work he did, and indeed, finding a CPU is quite the accomplishment.
That said - what is it about the hardware manufacturers that makes them relatively immune to this sort of thing? Is it formal verification and rigid engineering process? Is it that they spend so much money developing these things that they better do them right, god dammit?
Sometimes I think that the whole industry would be much better off if everyone up the stack was held to these kinds of standards. If that were the case though, where would we be? We'd have rock solid systems, but how sophisticated would they be? Would UNIX exist? What about (a more bulletproof and less feature complete) Java?
Is it formal verification and rigid engineering process? Is it that they spend so much money developing these things that they better do them right, god dammit?
All of the above- with the minor correction that it's not about money spent developing per se. Producing silicon masks is obscenely expensive, so catching a bug before tape-out vs. after tape-out can be a difference of hundreds of thousands of dollars. So, think of it as "you better get it right the first time, god dammit"
There's little open development, so there's little incentive to write up public articles. You could try something like Bob Colwell's "The Pentium Chronicles".
Considering it takes years to design a CPU I don't think it would be worth it. The point of software is that you can change it quickly and so it evolves faster then the hardware that runs it.
IMO that's an advantage that easily overcomes any instability that new software brings.
That said there was an interesting article/interview (cant find it sorry maybe someone else can) with one of the creators of hotmail. Off the top of my head he said that because he came from the hardware side when creating the hotmail software it never broke due to the processes and practices he followed. Perhaps there is a middle ground that we can take and get benefits all around.
On the other hand, you've got FPGAs, which bring the software stuff to the hardware guys - and based on my (limited) understanding of the hardware industry, they've improved certain prototyping exercises by an order of magnitude.
Agreed that the rapid development cycles and malleability of the product is part of what's made software great - but my feeling is that maybe we've let that slip a little too much - leading to the bloated, slow, buggy software that everyone runs all the time.
As an integrated circuit designer I can say that a lot of hardware is somewhat less complex than the software world. At the chip level anyway.
In the hardware world at the chip level, the environment is fairly rigid. A designer has a pretty good idea of what the environment is going to be for their chip. Linux is designed to operate in all sorts of environments: multiple cpu architectures, multiple versions of those architectures, the myriad peripherals, and all the other software that is going to run on linux.
That's not really the case with hardware at the chip level. We know what chip we are going to be talking to, or what family of chips. And most of those are designed in house, so there can be a lot of give-and-take going on.
It's just not a lot of combinations (compared to software, in my opinion.)
An exception would be memory, which is usually made by a third party. And it's also where you find incompatibilities... some manufacturer's ram doesn't work in macbook pros, etc. That's a bug.
And because the hardware can take a long time to iterate through design->implementation->verification->fabrication->prototype verification, there is a strong force driving designs toward being the simplest possible implementation that accomplishes the goals.
So you have these very well defined blocks of functionality that get pieced together and form a chip. The interfaces between blocks are very rigidly defined, and the amount of functionality in a given block is usually pretty limited.
At the level I work at, design is done in VHDL or Verilog (and now SystemVerilog is becoming a viable option). So that's a limited space. That could possibly be the biggest contributor to "less bugs" in hardware (if that is a true supposition). I get flustered with all the different software programming languages.
A big disadvantage of hardware design is that testing is first done in event based simulation. The tools available for this are pretty awesome, but it's still extremely slow. My last design would take about 100 hours to simulate about 300 ms of hardware time. That's a large part of why the iteration times are so long.
Now, with AMD and Intel, and designing these ridiculously highspeed CPUs, it's a whole different ball of wax. I expect a lot of their design is transistor level, full custom. Maybe they prototype in a higher level language, but you aren't going to 3GHz doing standard cell designs in VHDL.
Chip simulation seems like it would be a pretty difficult problem to multithread, since everything depends on everything else - can you run those simulation tools on clusters (or even GPGPU)?
Apparently Bulldozer, AMD's latest chip, is their first to start using automated design tools; one ex engineer claims that it resulted in 20% bigger and 20% slower designs:
That said - what is it about the hardware manufacturers that makes them relatively immune to this sort of thing? Is it formal verification and rigid engineering process? Is it that they spend so much money developing these things that they better do them right, god dammit?
Sometimes I think that the whole industry would be much better off if everyone up the stack was held to these kinds of standards. If that were the case though, where would we be? We'd have rock solid systems, but how sophisticated would they be? Would UNIX exist? What about (a more bulletproof and less feature complete) Java?