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:
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:
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.
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
// 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.
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”)
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 Reflections on Users’ Experiences with SVA | Verification Horizons - March 2022 | Verification Academy
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:
4. 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.
5. 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…
The above reasons are why it is important to write a verification plan that is reviewed by the verification team. The writing of the assertions is the easy part.
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.
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