Assertion for check SOP signal loss

Question

Hello.
I have interface with SOP and EOP signals.
I would like to write an assertion that will control for loss SOP signal. That is the EOP signal comes again without SOP.
I wrote this design:

sva_sop_loss: assert property (eop |=> !eop throughout ##[*] sop)
else $error("%m");

This worked well untill it became necessary to process packets where SOP and EOP signals could arrive at the same time. In such cases, false positives occured.
Than I assumed that $rose(SOP) occurs earlier than EOP and wrote this:

sva_sop_loss: assert property (eop |=> !eop throughout ##[*] $rose(sop))
else $error("%m");

But that didn't work either. In the end I came up with this:

sva_sop_loss: assert property (eop |=> (!eop | sop&eop) throughout ##[*] sop)
else $error("%m");

It seems to work, but there are doubts that this approach is correct. How do you think?

Answer 1

ben@SystemVerilog.us

Full Access

2561 posts

November 24, 2022 at 11:42 am

In reply to DefaultName:
Your approach looks OK, but I took a different approach with support logic that addresses other cases. specifically, i address the following requirements

if(eop) then an sop has happened
Every sop has its own eop
After an sop no new sop until an eop

See my paper on support logic, the link is in my signature below.
https://www.edaplayground.com/x/XEwy

module top;
    `include "uvm_macros.svh"
    import uvm_pkg::*;
    bit clk, sop, eop, sop_happen;
    int sop_count, eop_count;
    default clocking @(posedge clk);
    endclocking
    initial forever #10 clk = !clk;
    // Support logic to detect the occurence of a sop 
    always @(posedge clk) begin
       if(sop) sop_happen<=1'b1; 
       if(eop & !sop) sop_happen <= 1'b0;
    end
    // if an eop then sop happened in the past 
    ap_eop_with_sop: assert property(eop |-> sop_happen==1);
    // **********
    // Functions to maintain the counts of sop, eop 
    function void inc_sop();
        sop_count=sop_count+1;
    endfunction: inc_sop
 
    function void inc_eop();
        eop_count=eop_count+1;
    endfunction: inc_eop
    // Every sop has its own eop 
    property p_sop_eop; 
      int sop_flag;
        (sop, sop_flag=sop_count, inc_sop()) |=> eop[->1] ##0 eop_count==sop_flag;
    endproperty
    // Pass or fail, the eop count is incremented 
    ap_sop_eop: assert property(p_sop_eop) inc_eop(); else inc_eop(); 
 
    initial begin
      bit v_a, v_b, v_err;
      repeat (200) begin
        @(posedge clk);
        if (!randomize(
                v_a, v_b, v_err
            ) with {
              v_a dist {
                1'b1 := 1,
                1'b0 := 1
              };
              v_b dist {
                1'b1 := 1,
                1'b0 := 2
              };
              v_err dist {
                1'b1 := 1,
                1'b0 := 15
              };
            })
          `uvm_error("MYERR", "This is a randomize error");
        sop <= v_a;
        if (v_err == 0) eop <= v_b;
        else eop <= !v_b;
      end
      $finish;
    end
  endmodule

Ben Cohen
http://www.systemverilog.us/
** SVA Handbook 4th Edition, 2016 ISBN 978-1518681448
...
1) SVA Package: Dynamic and range delays and repeats https://rb.gy/a89jlh
2) Free books:
* Component Design by Example https://rb.gy/9tcbhl
* Real Chip Design and Verification Using Verilog and VHDL($3) https://rb.gy/cwy7nb
* A Pragmatic Approach to VMM Adoption
http://SystemVerilog.us/vf/VMM/VMM_pdf_release070506.zip
http://SystemVerilog.us/vf/VMM/VMM_code_release_071806.tar
3) Papers:
Understanding the SVA Engine,
https://verificationacademy.com/verification-horizons/july-2020-volume-16-issue-2
Reflections on Users’ Experiences with SVA, part 1
https://verificationacademy.com/verification-horizons/march-2022-volume-18-issue-1/reflections-on-users-experiences-with-systemverilog-assertions-sva
Reflections on Users’ Experiences with SVA, part 2
https://verificationacademy.com/verification-horizons/july-2022-volume-18-issue-2/reflections-on-users-experiences-with-sva-part-2
SUPPORT LOGIC AND THE ALWAYS PROPERTY
http://systemverilog.us/vf/support_logic_always.pdf
SVA Alternative for Complex Assertions
https://verificationacademy.com/news/verification-horizons-march-2018-issue
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
SVA for statistical analysis of a weighted work-conserving prioritized round-robin arbiter.
https://verificationacademy.com/forums/coverage/sva-statistical-analysis-weighted-work-conserving-prioritized-round-robin-arbiter.
Udemy courses by Srinivasan Venkataramanan (http://cvcblr.com/home.html)
https://www.udemy.com/course/sva-basic/
https://www.udemy.com/course/sv-pre-uvm/

Answer 2

Solution

ben@SystemVerilog.us

Full Access

2561 posts

November 24, 2022 at 6:54 pm

In reply to ben@SystemVerilog.us:

You could add

p_eop_sop_eop: assert property(
          eop |-> sop[->1] ##0 eop[->1]);

Ben

Answer 3

DefaultName

Forum Access

6 posts

November 24, 2022 at 11:19 pm

In reply to ben@SystemVerilog.us:
Thanks, Ben

Answer 4

ben@SystemVerilog.us

Full Access

2561 posts

November 25, 2022 at 7:59 am

In reply to DefaultName:

// On this other addition, note that by itself
p_eop_sop_eop: assert property(
          eop |-> sop[->1] ##0 eop[->1]);
// it does not address the case of 2 eop, like 
//  eop ... eop ... sop ... eop 
//
// It also does not address the case of 2 sop, like 
//  sop ... sop ... eop 
// 
// My first solutions do adddress thse points.

Ben

Answer 5

shaygueta

Full Access

21 posts

November 26, 2022 at 9:22 pm

In reply to DefaultName:

You can try this :
//property declaration
property EOP_EOP_SOP(clk,SOP,EOP,valid);
@(negedge clk) ((EOP && !SOP) |=> (!(EOP && valid && !SOP) throughout EOP[->1]));
endproperty

...
//property instance
u_EOP_EOP_SOP : assert property (EOP_EOP_SOP(clk_signal,SOP_signal,EOP_signal,valid_signal)) else `uvn_error("top","EOP was set twice without SOP")

Answer 6

ben@SystemVerilog.us

Full Access

2561 posts

November 27, 2022 at 11:34 am

In reply to shaygueta:

Your property looks good, and it addresses some aspects of the requirements.

property EOP_EOP_SOP(clk,SOP,EOP,valid);
@(negedge clk) ((EOP && !SOP) |=> (!(EOP && valid && !SOP) throughout EOP[->1]));

I get the impression from the original question that the verification engineer did not write a verification plan in English, but instead directly started to write assertions based on his/her understanding of the requirements. I talked about EXPRESSING REQUIREMENTS in my paper Reflections on Users’ Experiences with SVA, part 1
https://verificationacademy.com/verification-horizons/march-2022-volume-18-issue-1/reflections-on-users-experiences-with-systemverilog-assertions-sva
Using this on-the-fly approach seems, on the surface, to be efficient and fast because one could argue that SVA does a concise job at specifying the requirements. However, that approach may miss many aspects of the requirements. For example, considering this eop/sop design:
- MESSAGE LENGTH: The eop[->1] seems to ipically knowmply that the message length is not something to be considered. But, shouldn't it be? Message length is typically known by a sender or a configuration or can be extracted from the serial message itself with support logic. That message length is something taht needs to be verified.
- EOP WITHOUT SOP: These tags are generally detected or issued by the design. The message contains many flags of interest to be verified, including eop, sop, parity, format, legal targets, etc...

Answer 7

DefaultName

Forum Access

6 posts

November 27, 2022 at 11:55 pm

In reply to ben@SystemVerilog.us:

I wanted to write a simple set of basic checks. This checker is intended to contain the loss of sop, eop, val, violation of the minimum and maximum length of the packet, and, if necessary, the loss of ipg. You are probably right, this approach is conceptually wrong and will not be able to cover all requirements. But unfortunately I don't have a verification team, and I'm a FPGA developer, so I often have to use simple solutions for mediocre verification)

Specifically in this case, I have a very large design containing many IPs, including PHYs and other network modules. For testing, I wrote a package generator that sends packages to the project and compares them at the output. Globally, this allows you to understand that an error has occurred in the project, but in which specific place - not. To determine in which particular place, you really need to draw up a verification plan and do some serious work. But I don't have skills and time for that) Therefore, I add such primitive checks to some nodes.

Answer 8

ben@SystemVerilog.us

Full Access

2561 posts

November 28, 2022 at 10:55 am

In reply to DefaultName:
You are correct in doing top-level system tests. The assertions do pickup internal errors.
Whoever is paying for this design needs to put more effort into the verification process. One way or another, the cost will be paid whether it be in time, or in-field repair, or lawsuits if the FGPA is in a critical application (like a traffic controller).
Of course, it could even cost you your job .... let's hope not!

If you can assume that the IPs are correct, you could tap off signals from your IPs for use in the assertions.
Best wishes,
Ben

Languages & Standards

Methodologies

Techniques & Tools

Universal Verification Methodology (UVM)

Featured Courses

Additional Courses

Formal-Based Techniques

Analog/Mixed Signal

UVM Forum

SystemVerilog Forum

Coverage Forum

Additional Forums

Implementation Patterns

Specification Patterns

Pattern Resources

UVM Cookbook

Coding Guidelines & Deployment

Coverage Cookbook

Featured & On-Demand

On-Demand Library

Recording Archive

Conferences & WRG

Siemens EDA Learning Center

Blog & News

Verification Horizons Publication

About Us

Training

Solution

Portfolio

Explore

Siemens

Contact