3 ms·

Simulation is massively used in chip design these days. The hardware they use is just the cheapest general purpose compute hardware available, so just normal se

Simulation is massively used in chip design these days. The hardware they use is just the cheapest general purpose compute hardware available, so just normal server/hpc setups, so this guess was pretty close: > A massively parallel server farm that collectively pretends to be a 100MHz(??) chip? ... except that you are greatly overestimating the speed at which such simulation can run. The full-chip silicon-level simulations ran on massive datacenters run at speeds measured in kHz, not MHz. For the kind of testing they are used, this isn't a major detriment, as so long as all the io is slowed down to match, they can still get an accurate results, they just take a bit longer. A lot more simulation happens at the subsystem-level. You can isolate some subsystem, such as a cache controller, and then manufacture traces of the communication it does with the rest of the chip. Then you can just simulate that part at much lower cost, do tweaks, see how the operation changes under the simulation, and repeat.

exikyut 7y ago
> kHz, not MHz Ha, I overestimated the capabilities of scaleout :D I figured if you added enough racks you could go that high... but yeah, that's asking for the equivalent of total coherency on a piece of software running simultaneously across thousands(?) of nodes. (Ha, I wonder if the current systems use 50Gbit networking. Or 100Gbit? Wow...) > A lot more simulation happens at the subsystem-level. You can isolate some subsystem, such as a cache controller, and then manufacture traces of the communication it does with the rest of the chip. Then you can just simulate that part at much lower cost, do tweaks, see how the operation changes under the simulation, and repeat. Right, that makes sense. And interestingly, that sounds similar to how retro/hobbyist emulation systems do things too. Emulate the exact behavior necessary for a specific set of things to work the way you want.
- uxp100 7y ago
  > I figured if you added enough racks you could go that high... but yeah, that's asking for the equivalent of total coherency on a piece of software running simultaneously across thousands(?) of nodes. Also, you've got hundreds of users, who may be submitting tens of tests at a time. Like, even a giant company would run out of compute trying to make simulation as fast as the users want it to be.
- sbierwagen 7y ago
  Cisco will gladly sell you 400 gigabit switches: https://www.cisco.com/c/en/us/solutions/data-center/high-capacity-400g-data-center-networking/index.html https://www.cisco.com/c/en/us/solutions/data-center/high-cap...
uxp100 7y ago
> For the kind of testing they are used, this isn't a major detriment Eh... 1 hour tests turning into 4 hour tests turning into 12 hour tests is one thing, but when a 12 hour test turns into a 7 day it hurts. And if a 20 day long bootloader simulation with accurate pad models fails, you may not have a chance to run it again with a fix before tapeout. And Kernel boot in simulation takes so long. Not that you're wrong, just emphasizing how slow it can be. Simulation complexity has outpaced server farm speed increases over the past 10 years, in my experience. And rtl simulation has slowed itself out of usefulness for many software use cases where it used to be not so bad.

exikyut 7y ago

> kHz, not MHz Ha, I overestimated the capabilities of scaleout :D I figured if you added enough racks you could go that high... but yeah, that's asking for the equivalent of total coherency on a piece of software running simultaneously across thousands(?) of nodes. (Ha, I wonder if the current systems use 50Gbit networking. Or 100Gbit? Wow...) > A lot more simulation happens at the subsystem-level. You can isolate some subsystem, such as a cache controller, and then manufacture traces of the communication it does with the rest of the chip. Then you can just simulate that part at much lower cost, do tweaks, see how the operation changes under the simulation, and repeat. Right, that makes sense. And interestingly, that sounds similar to how retro/hobbyist emulation systems do things too. Emulate the exact behavior necessary for a specific set of things to work the way you want.

uxp100 7y ago
> I figured if you added enough racks you could go that high... but yeah, that's asking for the equivalent of total coherency on a piece of software running simultaneously across thousands(?) of nodes. Also, you've got hundreds of users, who may be submitting tens of tests at a time. Like, even a giant company would run out of compute trying to make simulation as fast as the users want it to be.
sbierwagen 7y ago
Cisco will gladly sell you 400 gigabit switches: https://www.cisco.com/c/en/us/solutions/data-center/high-capacity-400g-data-center-networking/index.html https://www.cisco.com/c/en/us/solutions/data-center/high-cap...

uxp100 7y ago

> For the kind of testing they are used, this isn't a major detriment Eh... 1 hour tests turning into 4 hour tests turning into 12 hour tests is one thing, but when a 12 hour test turns into a 7 day it hurts. And if a 20 day long bootloader simulation with accurate pad models fails, you may not have a chance to run it again with a fix before tapeout. And Kernel boot in simulation takes so long. Not that you're wrong, just emphasizing how slow it can be. Simulation complexity has outpaced server farm speed increases over the past 10 years, in my experience. And rtl simulation has slowed itself out of usefulness for many software use cases where it used to be not so bad.