Prev: VMWare tools killed my Mac OS X ?
Next: Software vs hardware floating-point [was Re: What happened ...]
From: Del Cecchi on 8 Sep 2009 22:55 "Mayan Moudgill" <mayan(a)bestweb.net> wrote in message news:9K-dnVlRsYh5KTvXnZ2dnUVZ_q6dnZ2d(a)bestweb.net... > Del Cecchi wrote: >> Mayan Moudgill wrote: >> >>> Del Cecchi wrote: >>> >>>> The obstacle is that a modern processor chip design costs a LOT >>>> of money, tens to hundreds of millions of dollars. And that is >>>> just the processor chip. >>>> >>> That's only if you're doing full-custom logic and/or building your >>> own libraries. The $$$ for designing, building and qualifying a >>> chip which can run at ~1 GHz in 40nm TSMC is probably in the high >>> single digits. This includes mask (~2m), tools (1-2m) & >>> engineering time. >>> >>> You pay for using custom logic or libraries, both in engineering >>> time and in respin. If you're at the bleeding edge, you're >>> probably having to do the opposite of KISS to get the performance >>> you need. Which means spending more time in verification to get >>> things right, and then more time in the back-end to get timing >>> closure. >>> >>> Tools have gotten pretty good these days, as have the processes >>> available to people using ASIC flows. >> >> >> I did say "modern processor design", which implies full custom etc. >> I agree that a SOC ASIC is a lot cheaper to do (which is why the >> star series was basically ASIC). >> >> I think your estimate is a little low however, given 250K per >> person year. A mere 40 PY would eat 10 million. >> >> del > > You can get a processor done in under 40PY; well under 40PY. Architecture, logic design, verification, timing, layout, test gen? I am sceptical about that especially if any custom elements are used. And you probably need a pass and a half at a minimum to get the bugs down to reasonable. It's been a couple years and the numbers start to get a little foggy, but as I recall Northstar took a couple departments, say 30 or 40 people, a couple years and it was basically an ASIC. But that was a while back and some things are easier now with better tools. I guess it depends on how aggressive you have to be compared to the capability of the technology. del
From: Mayan Moudgill on 9 Sep 2009 00:34 Del Cecchi wrote: > "Mayan Moudgill" <mayan(a)bestweb.net> wrote in message > news:9K-dnVlRsYh5KTvXnZ2dnUVZ_q6dnZ2d(a)bestweb.net... > >>Del Cecchi wrote: >> >>>Mayan Moudgill wrote: >>> >>> >>>>Del Cecchi wrote: >>>> >>>> >>>>>The obstacle is that a modern processor chip design costs a LOT >>>>>of money, tens to hundreds of millions of dollars. And that is >>>>>just the processor chip. >>>>> >>>> >>>>That's only if you're doing full-custom logic and/or building your >>>>own libraries. The $$$ for designing, building and qualifying a >>>>chip which can run at ~1 GHz in 40nm TSMC is probably in the high >>>>single digits. This includes mask (~2m), tools (1-2m) & >>>>engineering time. >>>> >>>>You pay for using custom logic or libraries, both in engineering >>>>time and in respin. If you're at the bleeding edge, you're >>>>probably having to do the opposite of KISS to get the performance >>>>you need. Which means spending more time in verification to get >>>>things right, and then more time in the back-end to get timing >>>>closure. >>>> >>>>Tools have gotten pretty good these days, as have the processes >>>>available to people using ASIC flows. >>> >>> >>>I did say "modern processor design", which implies full custom etc. >>>I agree that a SOC ASIC is a lot cheaper to do (which is why the >>>star series was basically ASIC). >>> >>>I think your estimate is a little low however, given 250K per >>>person year. A mere 40 PY would eat 10 million. >>> >>>del >> >>You can get a processor done in under 40PY; well under 40PY. > > > Architecture, logic design, verification, timing, layout, test gen? I > am sceptical about that especially if any custom elements are used. > And you probably need a pass and a half at a minimum to get the bugs > down to reasonable. > > It's been a couple years and the numbers start to get a little foggy, > but as I recall Northstar took a couple departments, say 30 or 40 > people, a couple years and it was basically an ASIC. But that was a > while back and some things are easier now with better tools. I guess > it depends on how aggressive you have to be compared to the capability > of the technology. > > del > > Been there done that; ASIC only, probably close to cutting edge on the technology.
From: MitchAlsup on 9 Sep 2009 16:44 Reality check::(V 1.0) A handful (maybe two) of people are doing architecture as IBM defined the term with System/360 A handful of dozen are doing microarchitecture A handful of hundred are the minions of theose doing architecture and microarchitecture A handful of thousand are the implementors and verifiers of the minions and [micro]architects All of the ILP that can be extracted with reasonable power has been extracted from the instruction sets and programming langauges in vouge The memory wall and the power wall have made it impossible to scale as we have before Threads scale to a handful per core Cores scale to the limits of pin bandwidth (and power envelope) Likely to be close to a handful of handfuls Nobody has solved the synchronization problem that will embolden cores and threads to really deliver on their promise The closest solution to synchronization has been lobotomized by its implementation Thus the way forward is threads and cores with incresingly small gains as the count increases Thus, for the most part, all the designers are simply making what they already have a little better, squeezing performance here, squezing out power there. We see this in CPUs, chips, memories, disks, motherboards... This plan works up until the first (to-be) succesful foray into the era yet to arrive. Computer architecture is pretty much like the status of piston engines in aircraft just after the end of WWII--about to undergo a radical transformation but nobody has a firm grasp as to exactly where it will go. Those at the helm (and with the budget to pay) want more piston engine aircraft. Yet in a few short years, Jet engines wil l completely transform the field of flying. It took 20-ish years from System/360 to RISC It has been 20-ish years since RISC Yet the components that drove RISC are not present today. Those components were: 1: the ability to fit a 32-bit data path on a single die, 2: the inability to fit a 32-bit ISA on that same die, 3: compiler technology shows a firm preference for simplified or at least orthogonal ISA, 4: a robust economy ready to invest in computer architectures and implementations and more importantly: software To a very large extent: There is no need for new instructions sets--extensions will occur naturally There is no need for new system organizations--software has enough trouble with the ones it already has There is no need for new storage organizations--DRAM and disks have a natural growth path So, evolution is bound to take place, and has been for a while. You see, the problem is not in the instruction sets, processor organization, cores and threads, nor system organization: The problem is in the power wall, memory wall, and synchronization wall. Until solutions to these are found, little can be done except squeeze another drop of blood from the stone. But what application is so compelling that it will actually change which stone is getting squeezed? Mitch
From: Robert Myers on 9 Sep 2009 17:55 On Sep 9, 4:44 pm, MitchAlsup <MitchAl...(a)aol.com> wrote: > Reality check::(V 1.0) > > A handful (maybe two) of people are doing architecture as IBM defined The real work in any field is always being done by a handful of people. The rest of us are inevitably camp followers. > You see, the problem is not in the instruction sets, processor > organization, cores and threads, nor system organization: The problem > is in the power wall, memory wall, and synchronization wall. Until > solutions to these are found, little can be done except squeeze > another drop of blood from the stone. > > But what application is so compelling that it will actually change > which stone is getting squeezed? The answer perennially at hand is artificial intelligence. I don't know how the idea of air superiority arrived, but jet engines are an enormous advantage in any sort of warmaking methodology. Instead of having airplanes and anti-aircraft batteries taking pot shots at one another, rockets and jet engines made the possibility of the equivalent of air blitzkrieg a reality--one that would have changed the outcome of World War II. Artificial intelligence would be the obvious huge leap forward, and I don't think it would have to be all that sophisticated artificial intelligence--just computers that act more like human switchboard operators than automatic telephone-answering trees would be sufficiently compelling, IMHO. I don't see the memory wall or the power wall as being critical limitations to such a modest leap forward. The synchronization wall might well be. There is also the software chaos wall. Question: if photons suddenly became as easily exploitable for computing as electrons, how much would change as a result? The Apple II arrived, and suddenly there was Visi-Calc, an application that no one would have imagined as likely to rock the world of computing, and yet it did. Despite the maturity of the field, aerodynamics continues to evolve in fairly interesting ways, perhaps because the problem was so rich to begin with. Why is computer science stuck in such a boring rut? Surely not because the problem is any less rich. That's enough provocation for one day, I suppose. ;-) Robert.
From: Robert on 10 Sep 2009 05:38
>> And don't forget FPGAs. The lines get fuzzy when anybody who can >> afford a couple grand can design in a space previously reserved for >> "architects" at a CPU vendor. > > I don't disagree that FPGAs can be used to do architecture, but there are > some issues involved: > 1. The ones with enough circuit-equivalents to really support > "architecture" are expensive > 2. The contraints are different: your main concern is the efficient use of > heterogenous resoucrces (multipliers, RAM, high-speed pins etc.). > 3. It usually (always?) makes more economic sense to treat them as ASIC > equivalents and build the whole solution (possibly including a > micro-controller equivalent), rather than first builting a > high-performance processor equivalent and then programming it. We already have integrated the FPU, caches, and memory controller into the CPU. Can we do some (smallish) FPGA area per core? |