cxxrtl: implement a generic record/replay interface #4083
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a reader/writer implementation for a file format optimized for fast, single-pass storage and retrieval of design state changes, as well as a recorder/replayer that integrate with the eval and commit simulation steps to create replay logs and reproduce them later.
This feature makes it possible to run a simulation once, recording the stimulus as well as changes to the registers, and navigate to a past time point in the simulation later without rerunning it. Both the changes in inputs (stimulus) and changes in state are saved so that navigation does not require calling
eval()
orcommit()
; only a series of memory copy operations.On a representative example of a SoC netlist, saving the replay log while simulating it takes 150% of the time it would take to simulate the same design without logging, which is a much lower overhead than writing an equivalent full view (including memories) VCD waveform dump. The replay log is also several times smaller than the VCD dump, and more space savings are available as low hanging fruit.
Replaying the log has not been optimized and currently takes about the same time as running the simulation in first place. However, it is still useful since it provides fast navigation to an arbitrary time point, something that rerunning the simulation does not allow for.
The current file format should be considered preliminary. It is not very space-efficient, and my testing shows that a lot of time is spent in the write() syscall in the kernel. Most likely, compression and/or writing in another thread could improve performance by 10-20%. This may be done at a later time.