Force stop simulation

[nselvara]

Hi guys, I searched for force stopping the simulation. In my tb I use the following construct for communicating between check and stimuli processes:

wait until is_active(event => start_stimuli);
lock(runner => runner, key => key);

Currently, the stimuli takes longer than the checker to finish which is fine for me as the checker checks only for a small time the output port. However, just calling the test_runner_cleanup procedure doesn't seem to stop the simulation. I'm not sure if it's good practice to use the unlock procedure in different processes (as the call for test_runner_cleanup is done in a separate process).
Is there a way to force stop simulation regardless of any locks?

[LarsAsplund]

The idea is that the lock prevents simulation termination for the duration of the task that must be completed. Is your problem that some task fails to complete or that the process owning the task fails to unlock once completed?

[nselvara]

Currently, the checker checks for a condition that occurs when the data rate is variable which is set by stimuli. As the stimuli has some arbitrarily long wait time it continues till the for loop condition is over. The test fails then due to the watchdog that pops up.

As a workaround, I just check for this condition in stimuli as well in order to exit. Which I find it not a neat solution at all.

[LarsAsplund]

I don't find your solution that bad. As you said, the checker is responsible for checking a condition that occurs when the data rate is variable. To do that, it has to know the data rate. If it checks the data rate for itself, it will be self-contained and that's a good thing. The alternative, if the data rate is more readily available to the stimuli generator or some other process, it can be provided to the checker.

The only way to unlock a lock is to use the key. Since the key is a constant you can declare it in a scope where it's accessible to the process deciding that it is time for a "forceful stop". I'd say that somewhat defies the purpose of having a private key. Such keys prevent a class of bugs associated with keyless systems where a process can unlock by mistake such that a simulation stops prematurely.

[nselvara]

Well, the data rate itself is kind of changing as it's a random number that I generate for each iteration. I also thought about defining the key at a global scope but as you said it defeats the purpose and I consider it a bad design. I rewrote the code so that I create a signal that tells to the stimuli to stop so I just exit the loop. For me personally exit is kind of break like in C(++) which I find a bit ugly as it's just an obfuscated goto but I guess it is what it is. For me the issue can be closed or if someone else needs it, we keep it open resp. discuss, I guess. Thank you for your reply.