Skip to content

Conversation

seldridge
Copy link
Member

@seldridge seldridge commented May 28, 2025

Add the ability to better control the frequency of a simulation in
ChiselSim stimulus. Previously, this was left up to the simulator to
define and could result in some weird behaviors: Verilator defaults to
1ps/1ps (which would cause simulations to seemingly simulate very fast)
and VCS defaults to 1s/1s (which would cause simulations to seemingly
simulate very slowly).

Change the default behavior to simulate at 1GHz (by using a default
timescale of 1ns/100ps and making the clock period 10 precision units).
Additionally, make the first two steps of the reset procedure longer to
keep things nicely aligned in waveforms.

Due to how Verilator and non-Verilator (e.g., VCS) simulators are handled
differently by svsim, this requires some changes to align the two
implementations of the run_simulation function. For Verilator, this is
implemented in C++ and calls Verilator's timeInc(Int) function. This
will increment time by the precision. E.g., if the timescale is
1ns/100ps, then #2 will increment by 200ps. For non-Verilator, this
function is implemented in Verilog. Add an argument to an svsim function
that generates this Verilog to increment in multiples of precision.

After this PR, Verilator and VCS will generate the same VCD (checked by
inspection in a waveform).

Note 1: the change to run_simulation in Verilog is much easier in
1800-2023 as this has $timeunit and $timeprecision system functions.
However, VCS only supports 1800-2012.

Note 2: this is being done because some gate-level sims are being done
using ChiselSim and accurate power requires realistic frequencies. If
users don't care about this (or aren't integrating "real" models of
hardware) then this change shouldn't matter or affect users other than
seeing the units in the favorite waveform viewer change.

Here is the waveform I was inspecting:

image

@seldridge seldridge requested a review from jackkoenig May 28, 2025 22:15
@seldridge seldridge marked this pull request as ready for review May 28, 2025 22:16
@seldridge seldridge added the Feature New feature, will be included in release notes label May 28, 2025
@seldridge
Copy link
Member Author

Note 3: @jackkoenig brought up some good points with this that it would be better to figure out how to not have to pass the period to the stimulus. I.e., there should be a way to do this which has information about the number of precision ticks for each clock already available and the tick methods just do what the user wants. Unfortunately, I am not seeing a great way to make this work right now.

seldridge added 2 commits May 28, 2025 19:56
Add the ability to better control the frequency of a simulation in
ChiselSim stimulus.  Previously, this was left up to the simulator to
define and could result in some weird behaviors: Verilator defaults to
`1ps/1ps` (which would cause simulations to seemingly simulate very fast)
and VCS defaults to `1s/1s` (which would cause simulations to seemingly
simulate very slowly).

Change the default behavior to simulate at 1GHz.

Note: this is being done because some gate-level sims are being done using
ChiselSim and accurate power requires realistic frequencies. If users
don't care about this (or aren't integrating "real" models of hardware)
then this change shouldn't matter or affect users other than seeing the
units in the favorite waveform viewer change.

Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
Change the behavior of VCS FSDB dumping to dump _all_ signals.  This
includes things like multi-dimensional arrays which are useful for power
simulations.

If this becomes problematic in the future due to size, we can figure out a
way to provide more fine-grained control of what is dumped.  This would
then likely be better handled with a VCS simulation setting.  (VCS/Verdi
provide multiple different ways that you can turn this on: environment
variable, command line, or via a system function.).

Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
@seldridge seldridge force-pushed the dev/seldridge/chiselsim-better-frequency-control branch from 065c446 to 456303b Compare May 29, 2025 02:56
@seldridge seldridge merged commit 456303b into main May 29, 2025
11 checks passed
@seldridge seldridge deleted the dev/seldridge/chiselsim-better-frequency-control branch May 29, 2025 02:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature New feature, will be included in release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant