sim: Fix uninitialized clusterwide cc counter

[Smephite]

This PR fixes the tracing scripts / dasm logs of Spatz.

Before the DASM logs had the issue, the current clock cycle for any instruction was set as 'X'.
This issue stems from a unitilized cycle counter variable in the spatz_cc.sv file.
The cycle counter was initialized using a synchronous negative reset signal.
If, for any reason (e.g., clock gating), the clock was inactive during the reset assertion, the value would never be initialized.

As the specific cycle count is only used in simulation, this PR mitigates the issue by setting the default value to zero on simulation start.

Further thought could be given to using a synchronized reset signal rather than an asynchronous one.

[anga93]

Hi @Smephite can you rebase on the current main? Afterwards, we will review it and merge it

[DiyouS]

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

[Smephite]

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?

[Smephite]

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