Skip to content

sim: Fix uninitialized clusterwide cc counter #54

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Smephite wants to merge 1 commit into
base: main
Choose a base branch
from
Open

sim: Fix uninitialized clusterwide cc counter #54

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions hw/ip/spatz_cc/src/spatz_cc.sv
View file
Open in desktop
Copy link
Copy Markdown
Collaborator

@DiyouS DiyouS Feb 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we directly assign a wire when declaring it in sv? I think we should assign the value to 0 at the beginning of initial block instead

Copy link
Copy Markdown
Contributor Author

@Smephite Smephite Apr 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we assign 0 to the value in the initial block, the compiler complains that we have multiple processes driving the same signal.

# ** Error (suppressible): spatz_cc.sv(548): (vlog-7061) Variable 'cycle' driven in an always_ff block, may not be driven by any other process. See spatz_cc.sv(491).

At least with Questa, the direct assignment is working - I cannot speak for different synthesizers.

An alternative approach would be resetting the value to 0 at RST.
The issue with this approach is that the signal is still uninitialized from the simulation start till the reset, and the cycle count is not monotonically increasing.

I suggest we answer the following questions:

  • Are we fine with the signal being undefined until the first reset?
  • Are we fine with the signal potentially being non monotonically increasing?

The value of cycles is only ever used for the cycle count in the log files.
The first entry of the log file is written with the first executed instruction (i.e. after the reset)
=> We should be fine with undefined values until the reset.

The cycle count would be non-monotonically increasing if we reset the cluster more than once
=> Would it be OK in this case if the log also resets the cycle count? Would this break the trace analysis scripts?

Copy link
Copy Markdown
Contributor Author

@Smephite Smephite Apr 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update: At least VCS is failing with the direct assignment.
I therefore suggest going forward with the nRST initialization.

Original file line number Diff line number Diff line change
Expand Up @@ -502,6 +502,9 @@ module spatz_cc
automatic snitch_pkg::fpu_sequencer_trace_port_t extras_fpu_seq_out;

if (rst_ni) begin

cycle = '0;

extras_snitch = '{
// State
source : snitch_pkg::SrcSnitch,
Expand Down