[SOLVED] How are timing violations scheduled in Verilog

Reading the the Verilog spec, I see that there are 5 types of types of events:
1. active
2. inactive
3. non-blocking assign update
4. monitor
5. future

When a setup or hold violation is specified with $setup or $hold, and the conditions are met to create a timing violation, how is the change to the notification register scheduled?

Does it change in a non-deterministic order with other events, in other words, is it active?

Is it scheduled to be processed at the end of the simulation cycle, in other words, is it inactive?

Is it something else? Am I so far off it isn't even funny?

Thanks.

They are active events. Notifiers are intended to feed the input of a UDP primitive and output an X when notified.

Thank you very much for the answer. I hope I'm not getting too pedantic about this, but I really am trying to understand exactly what is supposed to be going on here.

So, what you said was that when a timing error is detected that a change to the notification register is actively scheduled, to be processed in that same timestep. Then that must mean that there is a race between other events scheduled and with blocks sensitive to the notification register change in that timestep, because all those things are concurrent.

I have a follow up question then. Is the following conclusion correct:

That just seems to be a rather undesirable conclusion. I've done some testing with a simulator, and it seems that blocks sensitive to the notification register are processed after the other blocks that would be sensitive to CLK (even when the order of blocks in the file are shuffled), but I'm not sure if that should always be the case, especially with what was described above. I suppose one possible resolution could be that maybe the timing violations are in fact detected *after* all the other scheduled events are processed in the timestep, but I do not know if that is the case.

What you described as the "intended" use of the notification register is not my use. I am writing purely behavioral descriptions of mixed-signal, asynchronous, non-volatile memories. These ones tend to have rather troubled timing constraints and a wide variety of responses to them. So, I really appreciate your help.

The reality of simulators is that active events are executed in the order they are scheduled. Although you can't guarantee the order the simulator schedules all the blocks sensitive to the CLK, the notifier update event will be scheduled after all the CLK updates. Even though the LRM does not explicitly state this, notifiers have to work this way to get the desired result.