This reverts commit 36e4957.

This introduced nondeterministic build failures due to the simulation
exiting while trying to continue to read commands.  This would be better
fixed by having a dedicated message that indicates simulation failure.
I'll work on a patch that relands this with the suggested fixes.

Signed-off-by: Schuyler Eldridge <[email protected]>

This reverts commit 419bb58.

Signed-off-by: Schuyler Eldridge <[email protected]>

This reverts commit 419bb58.

Fix an issue that can occur now that the simulation will aggressively try
to shut themselves down when they see a `$finish`.  The problem occurs
because svsim is assuming that it can check if the simulation process is
alive and then shut it down.  However, this occurs in a critical region.
Just because the process is alive when checked, doesn't mean it _will_ be
alive when you try to shut it down.

I considered an alternative solutoin here which would put the simulation
into a "finish" state and then respond with a new "finish" message which
the controller would then need to handle. (It would just throw exceptions
if you tried to interact with the simulation after it ended.)  This
approach can be revived.  However, it needs to _also_ figure out what to
do with VCS.

The Verilog spec (1800-2023 Section 20.2) states:

> The `$finish` system task causes the simulator to exit and pass control
> back to the host operating system.

My read of this is that the simulation, if it is allowed to call
`$finish`, can terminate at essentially any time.  Verilator diverges from
this and will allow multiple `$finish` system tasks in the same block,
without time delays, to execute.  Based on how we construct the testbench
for Verilator, we run into this bug.  (If we use time delays, I think
Verilator will behave the same as VCS.)  Adapting the simulation to use a
"finish" message is therefore aligning the simulation with the expectation
of how Verilator behaves and is likely _not_ going to work for VCS.
Therefore, I rejected this approach.

If we want to move in this direction in the future, a change to the
testbench to use a `final` block, or some way of keeping the simulation
alive after a `$finish` to still respond to the controller, may work.

Signed-off-by: Schuyler Eldridge <[email protected]>