| Login | | Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name. | |
| Who's Online | There are currently, 40 guest(s) and 0 member(s) that are online.
You are Anonymous user. You can register for free by clicking here | |
 | |
|
Verification Guild: Forums |
|
| View previous topic :: View next topic |
| Author |
Message |
vhdlcohen
Industry Expert
Joined: Jan 05, 2004
Posts: 1248
Location: Los Angeles, CA
|
 Posted: Thu Oct 13, 2011 10:42 pm Post subject: Common misconceptions as to why SVA/PSL is not be used |
 |
|
#1 ASSERTIONS ARE TOO DIFFICULT TO LEARN
[Ben] Assertion languages, like SVA, are designed to be fairly simple. Thee are a few key concepts to understand, and a syntax that is not that complex to learn. People learn SVA fairly fast; I would say orders of magnitude faster thatn OVM.
In today's newer technology, assertion languages, like SVA, provide a notation that is more dense. For example, consider the following end-to-end test requirement that states that:
1) If I have a WRITE to a memory at a specific address, and
2) sometime later, after any number of cycles (i.e., 0 to infinity) I see a READ from that address,
3) THEN the data read from that memory should be what was initially written into that memory.
Can I do that check in VHDL or Verilog? Yes, I would need local variables, actually a large array because there could be many writes, to store the address and data written, and a check at every cycle to see if there was a write to that address because I do a check. In straight SystemVerilog, I could use an associative array with supporting code.
In SVA, I need 6 lines. Reading the code it is not that hard. In the code below, I have the declaration of 2 local variables (int v_addr, v_data), and the antecedent (line before the " |->") that says: Upon a wr (need to do that for every write, rather than a new write), I store the address and data; then I wait until I a have a match af a rd and the same address. Upon success, I check the content of main memory. BTW, I fire this assertion at every clock. If there is no write, I reject (ignore) that attempt, but previously active attempts are still active. Every successful attempt is independent from other attempts. The simulator will count the number of successes and failures. | Code: | property p_wr_rd_memory;
int v_addr, v_data;
first_match((wr, v_addr=addr, v_data=wr_data) ##1
!(wr && addr==v_addr)[*1:$] ##1 rd && addr==v_addr) |-> main_mem[addr] ==v_data;
endproperty : p_wr_rd_memory
ap_wr_rd_memory : assert property(@ (posedge clk) p_wr_rd_memory); |
#2 ASSERTIONS NEED TO BE VERIFIED
… Now need another testbench just for the assertions … and therefore we prefer to use the current approach to verification, specifically VHDL or Verilog code.
[Ben] First, it should be clear that assertions are already in use in any testbench, even those done 20 years ago, because the verification portion of any testbench is an assertion that the design is correct , and any errors are flagged as output messages with the identity of the error. I even remember going over the waveforms, clock by clock, and mentally "assert" that the design was correct. Thus, the question still remains the same: DO THOSE ASSERTIONS (written in VHDL or Verilog code, istead of SVA/PSL) need to be verified? My point is that the problem about verifying assertions (however they are written) may need to be verified. SVA/PSL do not make the problem more difficult than the traditional method. If anything, they make the problem easier because they can be written much much faster than straight code, and they can be visually autided for errors. One can still write a testbench if that is necessary.
Thus, to claim that SAV/PSL should not be used because they need to be verified is like saying that any verification code that checks for the correctness of a design should not be used because that too need to be verified.
Another benefit of using an assertion language is that it reinforces the understanding of the requirements, and makes code reviews and code debugging far easier.
#3 FAILS TO ADDRESS DATA INTENSIVE DESIGNS
[Ben] Many designs are data intensive, such as image processing for a digital camera. However, even those designs have an end-to-end test where the end test is a comparison of the the produced processed image again an expected results. But to even get to that point, several transactions must be processed, including the timing for start and end time for the call to the comparator. I am not saying that SVA is the solution to all problems, but assertion languages can address those timing points because every concurrent assertion has an implicit FSM behind it, and that is what makes it easier to use.
#4 NO DEFINTION AS TO WHEN ENOUGH ASSERTIONS IS ENOUGH
[Ben] Assertion languages makes the population of assertions easier to implement. As to when enough is enough, the issue is not the assertion language, whether that language be SVA, PSL, VHDL, SV, or Verilog. The issue is the nature of the beast: When is enough verification code and verification testing enough to validate a design? BTW, SV had assertion and group coverage to help address part of that problem.
#5 ONLY VERY LARGE LIKE COMPANIES CAN AFFORD TO USE SVA/PSL
[Ben] Actually large companies were smart enough to realise the true benefits of assertion languages. Smaller companies have caught on (I know that because I sold many books to them).
THE BOTTOM LINE
[Ben] It would be a big mistake NOT to use an assertion language, like SVA, in the design and a verification process. My point is that to thumb down an assertion language because assertions are too complex is a misconception. Assertions in any language are always written in a verification environment that asserts (or checks) the correctness of a design / interface, etc. Assertions in SVA/PSLcan be defined at the top level (i.e., within the testbench), at the interface level, and within RTL. Verifying assertions written in SVA is in fact easier than verifying assertions written using straight FSMs and supporting code (e,.g., associative arrays, data arrays). That ease encourages the definition of more tests, and reaffirms the understanding of the requirements.
_________________
Ben Cohen http://www.systemverilog.us/
* SystemVerilog Assertions Handbook, 3rd Edition, 2013
* A Pragmatic Approach to VMM Adoption
* Using PSL/SUGAR ... 2nd Edition
* Real Chip Design and Verification
* Cmpt Design by Example
* VHDL books |
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
| |
|
|
Forum FAQ
Search
Usergroups
Profile
Digest
Log in
