Fix evaluating final blocks on fatal

[dominiksalvet]

Hello,
I am using Verilator 4.038 2020-07-11 rev v4.036-114-g0cd4a57ad from Ubuntu 22.04 repos and wondered how I should evaluate final blocks on a $fatal call (or assertion fail) since this is something SV standard (IEEE 1800-2012) requires (if I understand it correctly). The standard says:

1. Calling $fatal results in an implicit call to $finish.
2. A final procedure executes when simulation ends due to an explicit or implicit call to $finish.

Currently, Verilator throws an abort exception, which is not easy/intended to catch and call Vtb->final() (and maybe one more VCD dump) manually. I also saw that there are extern void vl_fatal(const char* filename, int linenum, const char* hier, const char* msg) (and similar for finish and stop) functions in the verilated.h file installed on my system, which is to-be-overrided by a programmer but it seems a bit cumbersome to do so since Verilator might do something I can miss in these routines.

Hence, my question is what is the intended way to achieve compliance with the SV standard? Some examples would be very appreciated.

[wsnyder]

That's an old version but this hasn't fundamentally changed in master.

You are correct that currently it does a stop and exits, this goes back to the early days of Verilator when there was no evaluation loop.

I believe the correct handling would be for $fatal to set a flag in VerilatedContext and this also sets gotFinished(), and this causes the main loop (e.g. with --main), which will then call the final blocks.

Perhpas you'd be willing to work on a pull to do this?

[dominiksalvet]

Well, the solution sounds good to me (although I do not know what --main does). Maybe adding more context detail for the reason of gotFinished() would be appropriate also by calling another function later e.g. (if not already present).

I am sorry but I am very busy finishing my studies, so no PR is possible from my side.