A seat for the high end ASIC design tools is at least 10's of thousands of dollars per year. I wouldn't be suprised if it approached 100k a year.
NV30 shown running in hardware....but only at a few KHz...
- Thread starter McElvis
- Start date
random dude said:Well since they are much more serious about NDA and stuff, I am gonna keep quiet on that- but ya NV30 is delayed (didn't tape out too long ago). Everyone is going to work long hours (24/7) to make sure that it gets released ASAP.
The dark side is treating me well, although there is much more work here. It really puts ~CENSORED~ to shame.
~Irrelevant stuff about YPrPb video, the DDC and I2C configuration~
Back to slavin away......
(09/12/02)
Dammit, I tried. Sorry.
MuFu.
Pixar's renderfarm is not that powerful. Sun hardware is expensive and bulky for the amount of FP power it delivers (e.g. UltraSparc floating point throughput is poor). Secondly, back when Pixar built it, it was based on UltraSparc2's, so they would have had to upgrade all of the cpu boards to compare to a modern linux renderfarm. Third, they are mainly useful for problems that are not inherently divisible on a network. For rendering, I don't need NUMA or SMP, I just need a bunch of boxes each with their own RAM and CPU. Sun is in deep trouble, because even databases have become horizontally scalable across lots of cheap commodity boxes now.
I doubt those Pixar boxes are even fully decked out with every spare CPU slot filled.
For example, there are boxes that deliver 2 to 4 complete Intel motherboards in a single 1U case. That's 4 1+Ghz processors per shelf, and a typical rack is 40U, so one rack holds 160 processors. This will cost me roughly $40k. Not even a down payment on an Enterprise 4500. For roughly the cost of one highend Sun box, I can buy 1000+ CPUs each with their own disk and memory. And in general, these CPUs will deliver far better floating point throughput. Maybe I'd buy a Sun box to manage the file server, but then again, the Linux route is cheaper. You can buy a heap of 200GB drivers and raid them on commodity raids for far cheaper than a Sun StorEdge. Enterprises buy Sun hardware, but render houses invest and throw away as its price/performance depreciates every production cycle, and upgrading a Sun box every year is ultraexpensive.
That's why WETA, PDI, etc and other CFX houses are going the cheap-wintel/linux-renderfarm route. Some even used Alpha processors from Compaq. It's still cheaper and better performance.
If I were building a renderfarm today, I'd base it off of tons of cheap AMD chips (better FP bang for the buck compared with Intel). For a given IT budget, it just comes down to how many flops a dollar can purchase.
I doubt those Pixar boxes are even fully decked out with every spare CPU slot filled.
For example, there are boxes that deliver 2 to 4 complete Intel motherboards in a single 1U case. That's 4 1+Ghz processors per shelf, and a typical rack is 40U, so one rack holds 160 processors. This will cost me roughly $40k. Not even a down payment on an Enterprise 4500. For roughly the cost of one highend Sun box, I can buy 1000+ CPUs each with their own disk and memory. And in general, these CPUs will deliver far better floating point throughput. Maybe I'd buy a Sun box to manage the file server, but then again, the Linux route is cheaper. You can buy a heap of 200GB drivers and raid them on commodity raids for far cheaper than a Sun StorEdge. Enterprises buy Sun hardware, but render houses invest and throw away as its price/performance depreciates every production cycle, and upgrading a Sun box every year is ultraexpensive.
That's why WETA, PDI, etc and other CFX houses are going the cheap-wintel/linux-renderfarm route. Some even used Alpha processors from Compaq. It's still cheaper and better performance.
If I were building a renderfarm today, I'd base it off of tons of cheap AMD chips (better FP bang for the buck compared with Intel). For a given IT budget, it just comes down to how many flops a dollar can purchase.
Simon F said:
My point was that it is a fully hardware based solution, that is effectively the end target but running much slower. I'm not trying to argue that a software based emulator won't provide a full implementation to test - but software is completely different to hardware.
Yes?
Simon F said:
I checked the chip. It is the Xilinx Spartan XCS40XL in PQ208 package. I guess it is used as a PCI interface. Perhaps along with other minor functions.
Back to the topic
about the IKOS emulators, I remembered that I saw some emulators when I visited SiS. They said that the chip is emulated at hundreds of kHz (of course their chip is simpler than NV30). I even saw a "graphics card" emulated by one emulator, running a DirectX test program in Windows.wintel/linux = more bang for buck
but those Sun Systems can be upgraded on the fly, no need to take anything down. That is a major benefit.
Also, until Intel and AMD come strong with 64bit CPUs, Sun still rules the roost.
The bandwidth Sun machines have right now easily outclass intel machines.
but you could go with a bunch of xeons in a beowulf cluster and call it a day as well. All depends on your setup and preference I suppose.
but those Sun Systems can be upgraded on the fly, no need to take anything down. That is a major benefit.
Also, until Intel and AMD come strong with 64bit CPUs, Sun still rules the roost.
The bandwidth Sun machines have right now easily outclass intel machines.
but you could go with a bunch of xeons in a beowulf cluster and call it a day as well. All depends on your setup and preference I suppose.
WhiningKhan
Regular
mech said:
No.
The only real difference is that the verification is immensely faster when using programmable emulation platforms. It only guarantees you that your design works right in logic, which can, as you already understand, be also done in simulation (though so slowly that it is not feasible in many cases).
If we say that software is different to hardware, then we must also say that hardware is different to hardware.
Hellbinder[CE said:
Yes, I think the Bit Boys really missed out when they didn't release pictures of people standing around an iKos with a caption that read:
"Hard at work on the lastest Bit Boys Glade3D chip"
and a close-up screen shot of a Windows desktop with 4-color icons which was captioned:
"Here we see Glade3D running Windows..."
Really proves a lot, doesn't it? A most informative photo session, really, whether one talks about Glade3D or nv30, seems to me...
Theme song:
We're the Bit Boys,
and we've got made in the shade;
take a look at our great 3D Glade,
Oh, yeah, we're the Bit boys, Oy,Oy, Oy...
(sung to the tune of "We're the Monkeys")
WhiningKhan said:
I swear some of you guys here argue for the sake of arguing sometimes.
I originally wrote:
mech said:
My point was, it's hardware.
It's not emulation software. It's actual hardware, that's wired up exactly like the chip. Software IS different to hardware, because in software it's all theoretical - that hardware actually has gates wired exactly like the gates in the finished product. It's a physical implementation of it. No, it's not the finished thing - it uses a completely different board, clock speed, etc. My only point was that it's not emulating it per se, which it's not.
What's the big deal? Why argue about this at all? I can't see the point.
mech said:
I have to disagree. The logic may be exactly like the chip, but the logic model is an incomplete model of an entire working chip. The elements in the FPGA are only theoretically the same as the elements in the chip as it comes back from fab--just as the elements in a purely software simulation are only theoretically the same.
I think the point he's trying to make is it's hardware emulation instead of just some theoretical software program. The IKOS is set-up to emulate the function of the NV30 exactly, but at a really slow speed. Obviously this is necessary to make sure the design actually works in hardware. All the software sims in the world won't guarantee everything works right in actually silicon.
I'd be interested in knowing whether its possible to judge speed yields based off of how the chip performs in IKOS. If it runs faster on the IKOS machine, will it run faster in final version? I guess probably not since it's so different?
I'd be interested in knowing whether its possible to judge speed yields based off of how the chip performs in IKOS. If it runs faster on the IKOS machine, will it run faster in final version? I guess probably not since it's so different?
No his point in retrospect was that they had to have a gate level description of the chip to simulate it on a FPGA based system ... and that what he considered software simulation was running simulations with a high level non synthesizable description of the hardware. Obviously his words did not convey his meaning though, in fact he still does not seem to understand what the text he wrote was actually interpreted as (by just about anybody) given his replies.
Hey, why not talk about me as if I'm not here?
MfA, you're putting words in my mouth.
Nagorak knows what I'm talking about.
There's nothing to even argue here - all I was saying was, that when you burn the logic gates onto an FPGA, you're effectively changing it so it's not emulating the chip you want to build - it IS the chip you want to build (in terms of logic gates), but with a lot of redundant bits in it, and running at a much lower clock speed.
This is completely different to emulation, which is completely theoretical.
I can't make it much clearer than that.
MfA, you're putting words in my mouth.
Nagorak knows what I'm talking about.
There's nothing to even argue here - all I was saying was, that when you burn the logic gates onto an FPGA, you're effectively changing it so it's not emulating the chip you want to build - it IS the chip you want to build (in terms of logic gates), but with a lot of redundant bits in it, and running at a much lower clock speed.
This is completely different to emulation, which is completely theoretical.
I can't make it much clearer than that.
But is it actually any better than emulation, apart from the speed? Surely most, if not all, of the problems that can show up in the final, manufactured chip won't show up here? Problems with power distribution, timings, interference and all that. After all, it is only running at a few KHz, and it is a completely different kind of chip, albeit with the same gates etc. I'd have thought that the results from this are just as "theoretical" as from emulation.
Im sorry, I thought up one explanation of what you said which made a modicum of sense so I thought that was true :/
The software simulation compared to the FPGA simulation cannot be reasonable be considered theoretical, since their equivalence is not based on theory ... it is undeniable fact.
Most people dont think "completely different" means "does the exact same thing but in a slightly different way".
The software simulation compared to the FPGA simulation cannot be reasonable be considered theoretical, since their equivalence is not based on theory ... it is undeniable fact.
Most people dont think "completely different" means "does the exact same thing but in a slightly different way".
Maverick said:
I don't know if it would be any better than emulation other than for speed. I've never fabbed a chip
But yes, you're right, you won't be able to solve anything like that. But you will be able to see if your logic has worked.
MfA said:
I see why you're getting confused about what I was saying. When I said "completely different" I meant that it was not emulated - it was real hardware. I think it's fair to say it's completely different, given it's a physical implementation of the chip, rather than a software model.
We're arguing over semantics here anyway, so how about we call it a day?
Mech,
An FPGA version of a chip is still an emulation of sorts. For example, if the netlist calls for, say, an AND gate in the circuit, you don't use an actual AND in the FPGA.
Instead the FPGA typically uses pieces of 'programmable' logic which potentially can do multiple things but are restricted to 'emulate' their required functions via either programmed registers or some non-volatile storage. Even the connections between logical blocks would have to be programmable muxes.
Obviously, there are certain advantages to using the FPGA approach over software: it's much faster, and it is easier to interface to other hardware.
At least one thing has been cleared up - the title of the thread said that the FPGA system was only clocked at a few kHz. A few hundred kHz is far more reasonable. (Gosh, even the FPGA PowerVR prototype in the dim dark past was running in the MHz range)
An FPGA version of a chip is still an emulation of sorts. For example, if the netlist calls for, say, an AND gate in the circuit, you don't use an actual AND in the FPGA.
Instead the FPGA typically uses pieces of 'programmable' logic which potentially can do multiple things but are restricted to 'emulate' their required functions via either programmed registers or some non-volatile storage. Even the connections between logical blocks would have to be programmable muxes.
Obviously, there are certain advantages to using the FPGA approach over software: it's much faster, and it is easier to interface to other hardware.
At least one thing has been cleared up - the title of the thread said that the FPGA system was only clocked at a few kHz. A few hundred kHz is far more reasonable. (Gosh, even the FPGA PowerVR prototype in the dim dark past was running in the MHz range)
Simon F: Actually, you're right. It's not logic gate for logic gate identical. It's functionally identical though.
My original post still stands, where I was replying to Sebastian's post:
I just wanted to clear it up that it was actually a piece of hardware, functionally the same as a real NV30, but in a programmable chip. Not software.
Like I said, I was just clarifying a point. This is a non-argument.
My original post still stands, where I was replying to Sebastian's post:
Sebastian said:
I just wanted to clear it up that it was actually a piece of hardware, functionally the same as a real NV30, but in a programmable chip. Not software.
Like I said, I was just clarifying a point. This is a non-argument.
