Inside NVIDIA's Massive Hardware Emulation Lab

MojoKid writes "NVIDIA recently decided to give the public a look at their massive investment in hardware emulation technologies. Hardware emulators are specialized systems that can be programmed to emulate any specific architecture. In NVIDIA's case, a standard x86 system is connected to a powerful hardware emulator that's been pre-programmed to emulate a GeForce GPU that's still under design. The testbed generates the code in question and sends it over to the emulator, which then executes and returns the output. The emulators are massive machines that can be connected together and scaled for capacity and performance. NVIDIA's Indus emulator can emulate up to two billion gates and in their entire facility, the company can emulate up to 4 billion total."

Comments

Direct source

[Anonymous Coward]

Why not link directly to the blog post instead of a rewording of it?

http://blogs.nvidia.com/2011/05/sneak-peak-inside-nvidia-emulation-lab/

Re:Direct source

[DeadCatX2]

Because MojoKid has to drive traffic to his hothardware blog.

Re:Direct source

[Machtyn]

Seriously. Let's link the original post as mentioned above. It contains better images (their larger and easier to see) and it contains much better information (seeing as it is nVidia's blog).

Sounds cool

[PmanAce]

Not too sure I understand all that from reading the summary but it sure does sound cool. When I think emulator, I think of NESticle, wonder how many gates it has...

Re:Sounds cool

[MakinBacon]

Not too sure I understand all that from reading the summary but it sure does sound cool. When I think emulator, I think of NESticle, wonder how many gates it has...

Basically, debugging hardware is even more of a pain in the ass then debugging software because there are no tools like GDB that show you what's going on "under the hood", so electrical engineers have to use emulators to test out all their systems at the boolean level before they implement them in ASIC's. This is completely different from a Nintendo emulator, which would read each individual instruction and execute a group of instructions that do the same thing on the host machine.

I had to take a few classes on CPLD's and FPGA's when I was in college, and I can tell you that it took my poor PC all afternoon to emulate my designs for just 100ms. Those weren't nearly as complicated as a GPU, so it makes sense that Nvidia would need a massive supercomputer for this.

Also, "gates" probably refers to Boolean logic gates.

Re:Sounds cool

[alvieboy]

Also, "gates" probably refers to Boolean logic gates.

I think the term "gates" is abused and misused here, and in other articles. Not everything that goes on chip is a "logic gate", not even "gate", and they ought to be simulated as well. Think about clock modulators, PLL's, DCMs, for example. Other more esoteric thing exists.

Doing a transistor-level simulation is also very expensive here. This is usually done on the low-level blocks only (and perhaps before going into silicon).

What you simulate most of the time is RTL - Register Transfer Level. This includes not only plain logic paths, but synchronous elements like memories, flip-flops, and others.

Being used to RTL simulation (I do a lot), those numbers are absolutely impressive. I often spend an hour simulating only a few microseconds. And the outputs of simulation are *huge* - imagine you have 1 million signals on the chip, and your freq. is 1MHz. This means you will retrieve 1 million * 1 million signal data for a one second simulation.

Álvaro

Re:Sounds cool

[PmanAce]

Cool, thanks for your time and explication.

Re:Sounds cool

[tlhIngan]

They're really much fancier versions of these FPGA solutions I've seen - http://www.synopsys.com/Systems/FPGABasedPrototyping/CHIPit/Pages/default.aspx

Load the RTL in them and bang away. Neat stuff. Run godawful slow, but that's FPGAs for you (timing is usually a killer). Though it's usually much faster than pure software sims. I think these things ran Linux too - they had the classic Tux penguin when you power 'em up.

Re:Sounds cool

[Apocros]

Palladium is ASIC-based, not FPGA-based (the way older IKOS boxes were; yes FPGAs are ASICs...). So far as I'm aware, the ASICs used are basically "verilog accelerator" chips, supporting a limited subset of the language (mainly just synthesizeable constructs, with some exceptions). The verilog is compiled into a bytecode that the processors handle natively. It's analogous to the "java accelerator" ASICs that have been discussed here off and on. That grossly understates the complexity of the system, but from my exposure to it, that's basically what it is.

Mod parent up

[seifried]

Mod parent up

And some people blame nouveau...

[spaceplanesfan]

I mean that is what they use when the GPU hangs, so its piece of cake for them to see where the bug is,
but we are stuck with final version and just can't debug it.

let's just get this out of the way...

[Thud457]

imagine a beowulf cluster[1] of these, could they run Crysis ?


[1]"Does it run Linux?" is implied here...

Hey, Oracle. Here's another target for you.

[VortexCortex]

So it's an "emulator" you say? It "simulates" a "hardware device".

Would not another word for this be: "Virtual Machine"? Have they cleared this with Oracle, or did NVIDIA just get caught with their pants down? (stroking their e-peen)

How are you getting around VMWare's patent on saving and restoring a VM state? Clearly you'll want to do that to enable debugging of your soft-hardware. (Even though many VMs could do that long before the patent was applied for -- My old Lisp machine emulator did).

Inquiring minds want to know... specifically, what do I have to do so that the new VM based languages (like Java/Davlik or Lua?!) don't infringe any VM software patents? (Or are you taking the same advice my lawyer gave me? "Ignore the patents, foreknowledge makes infringement penalties greater. If you can stay under the radar by using different terminology long enough to become successful, we can negotiate a (cross) licensing deal.")

Software Patents Bad. Even For Hardware Company.

Re:Hey, Oracle. Here's another target for you.

[MarkvW]

Surely you have not just burned your attorney-client privilege?! Willful ignorance equates to knowledge in the eyes of the law.

Re:Hey, Oracle. Here's another target for you.

[Jthon]

These have nothing to do with virtual machines. These emulators are more like giant FPGAs than SW devices. Only instead of being implemented out of look up tables the system has a bunch of custom ASIC processors which accelerate gate level Verilog code.

Re:Hey, Oracle. Here's another target for you.

[rdnetto]

From Wikipedia:

"A patent is not the grant of a right to make or use or sell. It does not, directly or indirectly, imply any such right. It grants only the right to exclude others. The supposition that a right to make is created by the patent grant is obviously inconsistent with the established distinctions between generic and specific patents, and with the well-known fact that a very considerable portion of the patents granted are in a field covered by a former relatively generic or basic patent, are tributary to such earlier patent, and cannot be practiced unless by license thereunder." - Herman v. Youngstown Car Mfg. Co., 191 F. 579, 584-85, 112 CCA 185 (6th Cir. 1911)

As I understand it, patents prevent one from making and selling/distributing products using said patent. If you use the patent in an internal system that you build yourself and never give to anyone else, I don't believe that would be actionable.

Re:Hey, Oracle. Here's another target for you.

[bhtooefr]

IBM's VM operating system dates back to CP-40, from 1967.

The VM name was used in 1972.

Re:So?

[Anonymous Psychopath]

Uh, this kind of debugging has been in use since the late 1980's. The only things that have changed are the vendors who build the emulators and the size of the hardware that can be emulated. Why is this amazing?

I concept isn't amazing. The scale of execution is. It's like saying that the Grand Canyon isn't amazing since your street is riddled with potholes.

Re:BFD.

[Anonymous Coward]

It's a BFD because for the first time, they're able to emulate massive hardware instead of puny, microchip-sized hardware. Turn in your geed card now!

Emulation?

[Anonymous Coward]

"NVIDIA's Indus emulator can emulate up to two billion gates"

How many Ballmers can it emulate?

Re:Emulation?

[Megane]

It depends on how many chairs you can attach to the equipment.

Re:Emulation?

[amnesia_tc]

Nothing can truly emulate Ballmer. No one can emulate Ballmer. He's the reason copyright laws are enforced so strictly. Do we really want a copy of him running around?

Re:Emulation?

[kmoser]

Just one, but it generates too much heat when overclocked.

Not the same at all.

[SanityInAnarchy]

Things like NESticle are software emulators. The idea is to reverse-engineer an existing piece of hardware so that you can figure out how to make software which does the same thing, but not necessarily in the same way -- you want to be able to run software that runs on the NES, say, but you don't care at all whether the program in your computer contains an exact replica of every chip on the NES. Even if you wanted the identical behavior, you still wouldn't need to give it an exact replica.

This is a hardware emulator in both senses -- it is itself a big pile of hardware, and it's emulating hardware, exhaustively, in every detail. The idea here is that you want to have as much assurance as is reasonably possible that when you actually fab that chip, it's going to do what you think it will. You're not just testing that your software which will run on that card will do what it's supposed to do -- that'd be considerably easier, we have things like CUDA and software implementations of OpenGL if that was the only issue. No, you want to be sure that the hardware itself, as you designed it, will work when you actually build it.

Re:Not the same at all.

[Kuad]

For what it's worth, I do believe that at least some of the C-64 emulators have a fallback mode (very slow) that entirely emulates a 6510 CPU. It's impossible to entirely emulate the SID chip for sound however, given that it's partly an analog device.

And here is the link to the hardware as well

[LWATCDR]

Here is a link to the Hardware as well. http://www.cadence.com/products/sd/palladium_xp/Pages/default.aspx

Too bad that it only runs at 4Mhz. I was dreaming of a configureable super computer. And yes I understand that for it to even work at 4Mhz is pretty freaking cool. Where is the buy now button?

Re:And here is the link to the hardware as well

[davester666]

> Where is the buy now button?

They had to remove it after I pressed it, since they only have the one device.

With it, I figure I can finally get the maximum performance out of my Commodore 1541 floppy drive. It's tricky to make it work right at a high data rate.

Re:And here is the link to the hardware as well

[LWATCDR]

Funny but that does make me wonder. How fast could you make a C64 with today's tech. Since it only had 64k of address space I would think that you could put the entire system on a single die with lots of room to spare. You could probably even put in a ram expander as well on the same die. So how fast would a 3.5Ghz C64 be?
Roughly 4000x the speed of a c64? Which would still be slow by today's standards.

Hmmmmm

[Meganfoster]

Its looks like they are giving the ATI the best competition now with their new GPU's let see when they are in market.