Guest
sharp@cadence.com wrote:
binary file. If there's little more to the file format than dumping
out values similar to VCD (a version of the old MTI .wav file format
comes to mind), the binary will probably be faster. Once you throw in
stuff like clock/counter detection, signal value reordering and
indexing, etc in order to increase the compression ratio, you'll take a
speed hit. Likewise goes with any compression layers (e.g., libz) on
top of the data: you don't achieve a 50-100:1 compression ratio on VCD
without doing a bit of work.
There's also the factor that since VCD is built into the simulator/PLI
and isn't some standalone generic library code, it doesn't really need
to burn memory on storing signal names, their sizes, previous value,
etc so when it dumps there's less page/TLB thrashing on large models.
If it's faster to split a simrun that performs a binary dump into
simulating with writing VCD then converting it offline with a separate
utility, memory access issues are probably the case.
-t
It depends on how computationally expensive it is to write out theIt certainly sounds reasonable that generating a smaller
binary file format should be faster than generating VCD.
I have heard that argument made before, and it always
sounds reasonable. However, I know that in the past,
actual measurements have shown that it is faster to dump
VCD than some binary formats. I don't know what the
reasons were, and perhaps things have changed.
binary file. If there's little more to the file format than dumping
out values similar to VCD (a version of the old MTI .wav file format
comes to mind), the binary will probably be faster. Once you throw in
stuff like clock/counter detection, signal value reordering and
indexing, etc in order to increase the compression ratio, you'll take a
speed hit. Likewise goes with any compression layers (e.g., libz) on
top of the data: you don't achieve a 50-100:1 compression ratio on VCD
without doing a bit of work.
There's also the factor that since VCD is built into the simulator/PLI
and isn't some standalone generic library code, it doesn't really need
to burn memory on storing signal names, their sizes, previous value,
etc so when it dumps there's less page/TLB thrashing on large models.
If it's faster to split a simrun that performs a binary dump into
simulating with writing VCD then converting it offline with a separate
utility, memory access issues are probably the case.
-t