SVA check for glitch/noise

I have a UART like protocol. It is 20 bits of data and I will be sampling 16 times per a bit. I want an assertion that when the start bit arrives, it will check that the signal is stable for 16 clocks, then another 16 clocks with the new bit value, and so on.

I put the assertion below but it did not work as I expected.



assert property (@(posedge sample_clk) (state == start_bit) |-> check_glitch);

sequence check_glitch;
   @(posedge sample_clk) ($stable(tx_rx)[*16])[*20];
endsequence



In reply to VerifEx:
One major problem I see in your assertion is your misuse of the $stable.

$stable returns true if the sampled value of the expression did not change between the sampled value at the previous cycle and the sampled value at the current cycle. Otherwise, it returns false. $changed is a complement to $stable; $changed returns true if the sampled value of the expression changed. Otherwise, it returns false.

With ($stable(tx_rx)[*16])[*20] you are expressing that tx_rx is stable the whole 20 data bits; not what you want. I suggest the following, but I also have addinonal comments.


ap_1: assert property (@(posedge sample_clk) (state == start_bit) |-> check_glitch); 
sequence check_glitch;
   @(posedge sample_clk) (1'b1 ##1 $stable(tx_rx)[*15])[*20];
// Thus, tx_rx can change value 
endsequence 

There is one major issue with your assertion of a UART-like data transmission: There could be jitter in the data stream, or essentially, an uncertainty in the syncing of the data between the transmission and the reception. This is why you have this 16x clock. The point here is that the data transmission could be correct, but there could be regions of uncertainties. One option to satisfy this uncertainty zone could be to test your stability region in a narrower zone. For example:


ap_2: assert property (@(posedge sample_clk) (state == start_bit) |-> check_glitch); 
sequence check_glitch;
   @(posedge sample_clk) (1'b1 ##3 $stable(tx_rx)[*13])[*20];
// Thus, tx_rx can change value 
endsequence 

I wrote the following paper that uses the UART as a model:
Assertions Instead of FSMs/logic for Scoreboarding and Verification
https://verificationacademy.com/verification-horizons/october-2013-volume-9-issue-3/Assertions-Instead-of-FSMs/logic-for-Scoreboarding-and-Verification

Assertions with function calls from sequence match items can be used to generate that bit-clock as extracted using the 16x-clock and the start frame synchronization information; this novel application of assertion statements is demonstrated in http://systemverilog.us/uart_bit_clk_gen.pdf
All test code and test results can be downloaded from http://systemverilog.us/uart4hz.tar
The generation of bit-clock is the uart_if.sv file.

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


In reply to VerifEx:
how about this one ? my guess, data may toggle after every 16 clocks, you have to accommodate that…


sequence check_glitch;
   @(posedge sample_clk) ($stable(tx_rx)[*16] ##1 $changed(tx_rx)[*0:1])[*20];
endsequence

oops! I am seeing Ben’s reply now…*16 must be *15…

In reply to ssureshg_:
##1 $changed // data may not change. What if data is all 1’s or all 0’s?
Ben Ben@systemverilog.us

In reply to ben@SystemVerilog.us:

Hi Ben, from LRM example…

The example
b ##1 a[*0:1] ##2 c
is equivalent to
(b ##2 c) or (b ##1 a ##2 c)

In reply to ben@SystemVerilog.us:

ok,get your point now, “1’b1 ##1 $stable(tx_rx)[*15]” sounds right

In reply to ssureshg_:

Keep in mind that the send 16x clk and the receive 16x clk are not synchronous to each other, though at same frequency. I would write the sequence as
(1’b1 ##2 $stable(tx_rx)[*12] ##2 1’b1)[*20];
Ben Ben@systemverilog.us

In reply to ben@SystemVerilog.us:

Hi Ben,

If i try it this way, say when it goes to the next bits iteration, the data toggles from 1 to 0 or 0 to 1, the $stable in the 2nd iterations 1st check, will be looking at the last sampled data right(that would be the 1st iterations, last $stable check)?

In reply to adharshh:
Hopefully, I gave you some guidance. I can’t get into your design and debug it.
Techniques I used in solving issues is to do a lot of simulations, and add debugging signals, like events that are seen on the waveform viewer. You can also write small assertions, try the assertions clocking event to be at the negedge instead of posedge.
Ben SystemVerilog.us