This is separate from the topic of vector generation for verification, which is covered in #28.
During the design phase, it is extremely useful to analyze signals from a simulation in an environment designed for that purpose (MATLAB, NumPy, etc.). An easy way to facilitate post-simulation analysis is for the simulation to dump signals to binary files at runtime which can be efficiently and quickly read by these external applications, while avoiding tight coupling to specific software APIs or proprietary file formats.
As a simple example, consider the case of a filter block in a receiver. After simulation, we want to examine and plot the filter output signal in both the time and frequency domain using MATLAB. The type of the signal is std::complex<int64_t>, so the simulation generated a file named "filter.ci64" in the out/ directory. Samples are written to the file using fwrite(&sample, sizeof(complex<int64_t>), nSamples, file);. This file can be read using low-level file I/O features of MATLAB, which can be wrapped in custom functions for convenience.
I use and recommend the following filename extension convention:
Start with a letter indicating the nature of the type: 'i' for signed integer, 'u' for unsigned, 'f' for floating-point. If the signal is complex, prepend the letter 'c'.
Append the number of bits used to represent each value. For example, if the type is int32_t, the filename extension would be 'i32' and complex<int64_t> has extension 'ci64'.
The output files are useful for analysis, but they should not be enabled by default because they incur a significant performance penalty (and the files can quickly consume a large amount of disk space). I have found that I don't often need fine-grained control of which file outputs are enabled, in fact if I had such control inevitably I would forget a key file and then need to re-run the simulation to generate it, and there's no great way to quickly specify which files are desired. I've found that a global "turn on all the files" works just fine 99% of the time.
As with vector generation, the candidate signals for analysis include both signals that pass through noodles and signals that are internal to blocks.
This is separate from the topic of vector generation for verification, which is covered in #28.
During the design phase, it is extremely useful to analyze signals from a simulation in an environment designed for that purpose (MATLAB, NumPy, etc.). An easy way to facilitate post-simulation analysis is for the simulation to dump signals to binary files at runtime which can be efficiently and quickly read by these external applications, while avoiding tight coupling to specific software APIs or proprietary file formats.
As a simple example, consider the case of a filter block in a receiver. After simulation, we want to examine and plot the filter output signal in both the time and frequency domain using MATLAB. The type of the signal is
std::complex<int64_t>, so the simulation generated a file named "filter.ci64" in the out/ directory. Samples are written to the file usingfwrite(&sample, sizeof(complex<int64_t>), nSamples, file);. This file can be read using low-level file I/O features of MATLAB, which can be wrapped in custom functions for convenience.I use and recommend the following filename extension convention:
int32_t, the filename extension would be 'i32' andcomplex<int64_t>has extension 'ci64'.The output files are useful for analysis, but they should not be enabled by default because they incur a significant performance penalty (and the files can quickly consume a large amount of disk space). I have found that I don't often need fine-grained control of which file outputs are enabled, in fact if I had such control inevitably I would forget a key file and then need to re-run the simulation to generate it, and there's no great way to quickly specify which files are desired. I've found that a global "turn on all the files" works just fine 99% of the time.
As with vector generation, the candidate signals for analysis include both signals that pass through noodles and signals that are internal to blocks.