target/common: Scale verilator testbench time precision as picoseconds #58
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.
Fixes #57
Currently, Verilator relies on the global function
sc_time_stamp
to implement the$time
function in verilog.$time
is used by the simulator's trace and the performance tooling in the repo to track performance. However, although the current implementation of the testbench increments the time counter on each cycle, it is still dividing this time counter by1e9
. With the default assumption of 1 cycle taking 1ns and time precision of 1ps, this would imply that we are representing thesim::TIME
variable as being in attoseconds (1e18 attoseconds = 1 second
). This PR instead scales the time variable to return the expected picosecond precision.Reference example from Verilator 4.100 where no multiplication by
1e-9
takes place: https://github.com/verilator/verilator/blob/v4.100/examples/make_tracing_c/sim_main.cppExpected result:
time = cycle *1000 + 3000
. When generating traces in gen_trace.py we assume that the time is in milliseconds, so it gives a good enough approximation. A next step could be to have wall time instead, but ultimately I think this leaves the verilator simulator in a better state than before.Example logs generated after the patch attached.
trace_hart_00000000.txt
perf.csv
hart_00000000_perf.json
event.csv