(Mike, I generally respect your posts, this one bears comment)
If this were true, Chipscope would probably not exist.
Let's hypothesize some numbers (someone with better knowledge of simulator performance please correct me on the first point)
1) A simulator (even a cycle based one) on a moderately complex design may run about 10e5 times slower than the actual circuit. E.g., a 100 MHz FPGA might simulate at about 1 KHz, 1 ms/cycle. This number is just a crude estimate, assumes 10e4 nodes in a circuit, 10e2 cycles per node processing time for the simulator, and the simulator cycling a 1 GHz. (I think this is optimistic, does anyone have a good number?) 2) State machines can be extremely complex, with "billions _of_ billions" of states. Remember, a processor executing code is really a state machine, where state corresponds to [program counter, register contents, pipeline states, even memory contents]. For that matter, the whole FPGA can be viewed as a single state machine...but I won't get that outrageous.Assume three state machines, A, B and C (each of which has already been thoroughly proven) each with only 10000 states each (tiny pieces of code running on simple processors, with very few variables perhaps), and a set of 10 external inputs. Further assume that an error condition corresponds to a small subset of the trillions of possible states (bit x of variable X on processor A is '1' while bit y of variable Y on processor B is '0' and bit z of variable Z in processor C is '0', causing the rocket engine to shut down or whatever).
Now make the biggest, wildest assumptions of all:
3) A totally brilliant (omniscient?) test bench writer produces code that puts the system through every possible state. (Unlikely, but possible...there are some smart people out there), and produces this code in under a month. 4) Each of the 10e12 states of the hypothetical machine can be reached in a single simulator cycle (even more unlikely than 3).So we have: 10e12 states at 10e-3 seconds per state giving 10e9 seconds to perform the simulation... umm, that's 31.7 years.
Meanwhile, a day of testing the actual circuit on the testbed turns up the failure.
OK, I hear sputtering on comp.arch.fpga...from both sides...
"Someone didn't do enough higher level system analysis, the system designer should be shot"
"It's the programmer's fault, shoot him"
"Only 10e12 states? I've got 50 different inputs to worry about, let alone internal states. Shoot me"
So shoot down my example, you can probably come up with a better one. The point is (echoing Jeff Goldlum, "Jurassic Park" ran last week) any sufficiently complex system will have unforseen failure modes. Simulation (even "formal verification") cannot catch them. When the failure occurs, it is nice to have visibility into the circuit, be it Chipscope or handrolled test circuitry.
Forget about Brian's BlockRAM example, Mike's arbitration answer takes care of that. Here where I work, programmers tend to use logic analysis as much as the H/W types do, to monitor bus activity (who said what to whom, and when?). My designs involve video processing, which can be quicker to implement and look at than to try to simulate. If I understand O.P., he's in the same position.
To all c.a.f, sorry for the B/W, I haven't posted anything lately. I just hate hearing "simulation is all you need". For small simple circuits that is true; for larger systems, the more tools the better (till you end up spending more time learning the tools than actually producing). Apologies Mike if I took your statement out of context. You are 100% right about regression, but not every corner can be forseen, and often the data outweighs the simulator. I don't use timing sim either (although the x-men posts leave me wondering if I'll have to)...
Regards, John