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
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.