[SOLVED] How are timing violations scheduled in Verilog

[beeflobill]

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.

 

[dave_59]

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

 

[beeflobill]

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:

In a situation where there is a setup constraint, say from A to CLK, and a timing violation between A and CLK are detected on the edge of CLK. Then sometime later in the timestep, the notification register will be triggered and any blocks sensitive to it will be processed, in some arbitrary order.

However, if there are other blocks sensitive to CLK, then they may be processed either before or after the ones sensitive to the notification register.

Therefore, there would be a race between code that responds to CLK and to code that responds to the notification register, and either may be executed first.

A consequence of this would be that any action done as a response to the timing error could be undone by the code which is to otherwise respond to the edge of CLK.​

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.

 

[dave_59]

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.