How does the following piece of code detect glitch?

SystemVerilog
,
1

I found this piece of code which should detect glitches on a signal.

property no_glitch;
 logic data;
 @(d_in)
 (1, data = !d_in) |=>
 @(posedge clk)
 (d_in == data);
 endproperty : no_glitch
assert property(no_glitch);

I’m not sure I understand the logic behind it - can someone please explain?
If d_in changes, then at the first posedge clk it should have the opposite value? Shouldn’t it have the same value in order for there not to be any glitches? So it would be:

property no_glitch;
 logic data;
 @(d_in)
 (1, data = d_in) |=>
 @(posedge clk)
 (d_in == data);
 endproperty : no_glitch
assert property(no_glitch);
2

In reply to xaea12:
Assertions is the wrong approach to do setup and hold checks.
Neither of the properties shown above would work. What happens when then @(d_in) occurs in the exact time as the @(posedge clk)?
In any case, it is OK for d_in to change prior to a register clock as long as the setup requirement is satisfied.

See 1800’2017 31.3.3 $setuphold


...The $setuphold timing check combines the functionality of the $setup and $hold timing checks into a
single timing check. Therefore, the invocation
$setuphold( posedge clk, data, tSU, tHLD );
is equivalent in functionality to the following, if tSU and tHLD are not negative:
$setup( data, posedge clk, tSU );
$hold( posedge clk, data, tHLD );

Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
For training, consulting, services: contact Home - My cvcblr

  1. SVA Alternative for Complex Assertions
    Verification Horizons - March 2018 Issue | Verification Academy
  2. SVA: Package for dynamic and range delays and repeats | Verification Academy
  3. SVA in a UVM Class-based Environment
    SVA in a UVM Class-based Environment | Verification Horizons | Verification Academy
3

In reply to ben@SystemVerilog.us:

Thanks for the response.

Would that piece of code also detect a glitch on a signal aka signal going to 1 and back to 0 for a short period of time, not caught by the clk edge?

4

In reply to xaea12:

In reply to ben@SystemVerilog.us:
Would that piece of code also detect a glitch on a signal aka signal going to 1 and back to 0 for a short period of time, not caught by the clk edge?

I fail to understand why you are concerned about a glitch on an input signal to a clocked register. The only concern on inputs to registers is the setup time, meaning that the data is stable at least long enough for the register to work properly. The other concern is the hold time of the register to account for minimal clocking variations of registers.
For example, consider the case where you have a clk going through a clocking tree and one branch (clk_br1) clocks FF1 and another branch clk_br2 clocks FF2, and FF1 output feeds FF2 input. You want to make sure FF1 output does not change within the time region where clk_br2 may be offset by a delay where it can catch the data change. In other words, ALL regs must meet the setup time. The hold time ensures that data does not change fast enough so that the next stage still meets the setup time because of clocking tree variations.

1800’2017 31.3.3 $setuphold does state that all the setup and hold checks report timing violations.
Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
For training, consulting, services: contact Home - My cvcblr

  1. SVA Alternative for Complex Assertions
    https://verificationacademy.com/news/verification-horizons-march-2018-issue
  2. SVA: Package for dynamic and range delays and repeats - SystemVerilog - Verification Academy
  3. SVA in a UVM Class-based Environment
    https://verificationacademy.com/verification-horizons/february-2013-volume-9-issue-1/SVA-in-a-UVM-Class-based-Environment