The vendor for the simulation tool I'm using (Cadence) has said that they must stop failing assertions at the time the assertion fails and not during the action blocks of the assertion. I prefer for them to stop only when a $error or $fatal happens - and that would happen in the action block. My reasoning is that the simulator is stopping before I have a chance to print out the message.
Their reasoning relates to the state of the simulation during the assertion (observed region) vs the state during the action block (reactive region). I am trying to figure out if this explanation makes sense.
Can you weigh in on this? Here's their explanation:
SVA concurrent assertions execute in the observed region while their action block execute in the reactive region. Currently, we stop in the observed region right at the instant the assertion fails. There could be other processes that run between the assertion failure and the execution of action block. This would mean, the state of simulator at stop point is not consistent to assertion failure. There could be delays in the action block itself. Stopping after the action block may mean stopping after those delays.
This explanation makes me think that SVA is designed badly. If there's no easy way to print a message during an SVA assertion failure without the state changing in a significant way, perhaps there needs to be an update to SVA. On the other hand, if this has never come up for others before, I question if the vendor is correct in their analysis.
At its core I want to know:
- Can state really change between the assertion failure and the action block?
- Would $sampled in the action block be sufficient to mitigate the concern of the changes in state?
Wouldn't the standard have specified the action block to happen while the state still persists? At least somewhat? And if the state changes, I would think there would be a way to still view what caused the failure. Perhaps that is $sampled. This is what I'm trying to figure out.
You need to take this up with your tool vendor. There is nothing in the LRM that says the simulator has to stop on an assertion failure—that is a tool option. It does say there is an implicit call to
$errorif there is no action block. And the LRM does not require the tool to stop on$error—that is a tool option as well.If your action block has a
$errorin it, that could be the trigger to stop your simulation and it should print your message along with it.