Scheduling regions

SystemVerilog
,
1

I am confused going through the LRM about what gets sampled where and what gets evaluated where. Specially, clocking blocks and assertions. Would anybody be able to clarify these cases?
For clocking blocks, the sampling and driving is through clockvars and follows sync drives.

  1. Clocking block with default skew - And Do signals get the latest value from this cycle or the previous in this case?
  2. Clocking block with explicit #0 skew - And Do signals get the latest value from this cycle or the previous in this case?
  3. Clocking block with positive skews for input and output - And Do signals get the latest value from this cycle or the previous in this case?
  4. Immediate assertions
  5. Immediate deferred assertions (both observed and final)
  6. Concurrent assertions

Appreciate any answers here or any pointers to a simpler explanation.

2

In reply to kernalmode1:

See my reply at
https://verificationacademy.com/forums/systemverilog/sampling-point-assertions

Ben systemverilog.us

3

In reply to ben@SystemVerilog.us:

Thanks for that pointer Ben.

I have to clarify one thing though. Deferred assertions’ action block are evaluated in Reactive or Postponed for the respective deferred assertion type.

The post does not touch upon clocking blocks. Would appreciate if anyone could clarify that part.

4

In reply to kernalmode1:

#0 deferred assertions action blocks are scheduled for the Re-active region. Final deferred assertions action blocks are scheduled for the Postponed region. There are severe restrictions on what statements can execute in the postponed region (basically just messages)

The default clocking block input skew samples values in the postponed region of the previous time step. That value is the same as sampling in the preponed region of the current time step. There really is no difference between the two regions other than time has be updated to the next timestep. With a #0 skew, the input values are not “sampled”, they are whatever they are at the instant the clock event get triggered.

5

In reply to dave_59:

Hi Dave,

Default skew sampling in the postponed region of previous timestep translates to the previous clock cycle, is this correct?

With #0 skew, if the clock even trigger corresponds to the rising edge of a clock, does this sample updated data or data before the update?

Appreciate your responses in helping me understanding this.

6

In reply to kernalmode1:

Default skew sampling in the postponed region of previous timestep translates to the previous clock cycle, is this correct?

Correct.

With #0 skew, if the clock even trigger corresponds to the rising edge of a clock, does this sample updated data or data before the update?

This can be a race condition, depending on how the data is assigned. I would never use this.

7

In reply to dave_59:

I see. The #0 skew clause in the LRM says it corresponds to Observed region values. I agree that if there are updates done through program blocks and/or modules, that would lead to situations that are unpredictable.

Thanks for the inputs.