| 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, 50 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 |
lotr
Newbie
Joined: Nov 22, 2004
Posts: 4
|
 Posted: Mon Nov 22, 2004 11:25 am Post subject: Property for tracking history |
 |
|
I need to write a property (SVA)in which I need maintain history about packet tags so that
I can check specific properties like flag an error if I've seen a tag before and hasn't
complleted yet and so on.
Any suggestions/ideas. Thanks in advance. |
|
| Back to top |
|
 |
Logger
Senior
Joined: Jun 15, 2004
Posts: 340
Location: MN
|
| Posted: Mon Nov 22, 2004 11:42 am Post subject: |
|
|
Per other threads going on. Assertions are very precise, and non-ambiguous. Which is why they are good for augmenting a specification to clarify the meaning of an english spec. Your (very) short description is very vague and ambiguous, so it is a bit too little to write an assertion from.
If you can provide a more verbose and detailed concrete example of what you'd like to check, that would be a good starting point to write an assertion.
That said, my initial reaction to what you said is to check for your packet tags in a scoreboard implemented in your testbench. |
|
| Back to top |
|
|
lotr
Newbie
Joined: Nov 22, 2004
Posts: 4
|
| Posted: Mon Nov 22, 2004 11:53 am Post subject: |
|
|
Thanks Logger. Let me try to be more specific :
Basically I've a master-slave interface on which transactions are identified by tags. Once a master dispatches a transacttion, it will receive response for the same tag after some time. So I need to cross verify that the slave responded with same sideband information as given to it when the transaction originated. So I believe I need to have some kind of data structure to preserve the tag information and be ablle to check against it at a later time. |
|
| Back to top |
|
|
Ajeetha
Senior
Joined: Mar 29, 2004
Posts: 424
Location: Bengaluru, India
|
| Posted: Mon Nov 22, 2004 10:55 pm Post subject: |
|
|
| lotr wrote: | Thanks Logger. Let me try to be more specific :
Basically I've a master-slave interface on which transactions are identified by tags. Once a master dispatches a transacttion, it will receive response for the same tag after some time. So I need to cross verify that the slave responded with same sideband information as given to it when the transaction originated. So I believe I need to have some kind of data structure to preserve the tag information and be ablle to check against it at a later time. |
SVA supports local assertion variables to support this, say your tag is available in a signal pkt_tag (or can be part of pkt_data[15:0] when pkt_soc == 1 - whichever be the case).
property p_xaction_check;
logic [15:0] v_pkt_tag; // local assertion variable
@ (posedge clk)
(pkt_soc, v_pkt_tag= pkt_tag) |=>
// if SOC then assertion variable v_pkt_tag = pkt_tag
##[0:30] // within next cycle to 30 cycles later
resp_tag == v_pkt_tag); // resp_tag must be equal to stored tag
endproperty : p_xaction_check
HTH
Ajeetha
_________________
Ajeetha Kumari,
CVC Pvt Ltd. http://www.cvcblr.com
* A Pragmatic Approach to VMM Adoption http://www.systemverilog.us/
* SystemVerilog Assertions Handbook
* Using PSL/Sugar |
|
| Back to top |
|
|
alexg
Senior
![]()
Joined: Jan 07, 2004
Posts: 586
Location: Ottawa
|
| Posted: Mon Nov 22, 2004 11:33 pm Post subject: |
|
|
It seems that you can use SV queues for this purpose:
| Code: |
int Q[$]; //variable-sized array
int index[$]; //index
event err, ok;
always @(packet_sent)
Q.insert(tag_sent, 0) //insert signature to the leftmost position
always @(packet_received) begin
index = Q.find_first_index with (item == tag_received)
if (index.size) begin //item found: index array is not empty
Q.delete(index[0]); //delete this item from array
-> ok;
end
else -> err;
end
....
// At the end of simulation:
if (Q.size) $display("Expected tags remain in queue");
|
BTW, it is easy to impement similar functionality in pure verilog with reusable queue module.
Regards,
Alexander Gnusin |
|
| Back to top |
|
|
vhdlcohen
Industry Expert
Joined: Jan 05, 2004
Posts: 1239
Location: Los Angeles, CA
|
| Posted: Tue Nov 23, 2004 12:06 am Post subject: |
|
|
| Quote: | | BTW, it is easy to impement similar functionality in pure verilog with reusable queue module. |
Alex, the use of queues is interesting and demonstrates that there are many ways to express the same notion.
On a personal basis, I prefer Ajeetha's method with a property for the following reasons:
1. It's easier to understand. At every clock cycle, a new thread is started when the antecedent is true.
2. The property defines a bound in the number of cycles the response tag is observed. Adding this bound condition would requie more code.
3. As a property, it can be put in a requirements document. The code looks a bit awkward in a requirements document.
...opinions of course...
Ben Cohen
_________________
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 |
|
|
srini
Senior
Joined: Jan 23, 2004
Posts: 430
Location: Bengaluru, India
|
| Posted: Tue Nov 23, 2004 2:17 am Post subject: |
|
|
| vhdlcohen wrote: | | Quote: | | BTW, it is easy to impement similar functionality in pure verilog with reusable queue module. |
Alex, the use of queues is interesting and demonstrates that there are many ways to express the same notion.
On a personal basis, I prefer Ajeetha's method with a property for the following reasons: <SNIP>
...opinions of course...
Ben Cohen |
There is also a technical reason to prefer SVA based solution - tool support is already there for SVA as against SV-TB features (such as Queues). Few more added advantage of using SVA would be:
1. The "automatic" coverage that one could obtain on such checks from a tool like VCS.
2. Latency measurement by varying the range (say with a parameter).
Thanks,
Srinivasan
_________________
Srinivasan Venkataramanan
Chief Technology Officer, CVC www.cvcblr.com
A Pragmatic Approach to VMM Adoption
SystemVerilog Assertions Handbook
Using PSL/SUGAR 2nd Edition.
Contributor: The functional verification of electronic systems |
|
| Back to top |
|
|
lotr
Newbie
Joined: Nov 22, 2004
Posts: 4
|
| Posted: Tue Nov 23, 2004 10:36 am Post subject: |
|
|
Thanks, Ajeetha & Alex , Vhdlcohen & Srini for your responses.
As Srini mentioned, the current VCS version I am using (7.2) still lacks support for high level constructs like queues. Also, I plan to keep my SVA assertions as synthesizable as possible so that there is a path for them to emulation. |
|
| Back to top |
|
|
alexg
Senior
![]()
Joined: Jan 07, 2004
Posts: 586
Location: Ottawa
|
| Posted: Tue Nov 23, 2004 10:39 am Post subject: |
|
|
| vhdlcohen wrote: |
On a personal basis, I prefer Ajeetha's method with a property for the following reasons:
1. It's easier to understand. At every clock cycle, a new thread is started when the antecedent is true.
2. The property defines a bound in the number of cycles the response tag is observed. Adding this bound condition would requie more code.
3. As a property, it can be put in a requirements document. The code looks a bit awkward in a requirements document.
|
1. Anyone prefers the way which matches with his/her previosus knowledge and experience. Since you had the previous experience writing the book about assertions, "assertion" way may be the most natural for you. For me, "queue" solution is the most natural and reusable way, since it directly formalizes the way we think about the solution.
It is also more reusable, since not only myslef can easily understand this code in the right way. It is also eaiser to debug, since there is no automatically generated threads and other assertion-related tricks. BTW, it would be interesting to hear another opinions on this topic.
2. If there is a requirement to check/cover packet latencies as well as any other packet-related properties, there will be a need to use queues with structures or SV classes. However, I don't see such requirements for this specific case.
3. I don't think the property defined by Ajeetha will make specification more clear and concise. For this specific case, plain English may be good enough:
"Once master dispatches a transaction, it will eventually receive response with the same tag as in requested transaction. "
| srini wrote: | There is also a technical reason to prefer SVA based solution - tool support is already there for SVA as against SV-TB features (such as Queues). Few more added advantage of using SVA would be:
1. The "automatic" coverage that one could obtain on such checks from a tool like VCS.
2. Latency measurement by varying the range (say with a parameter).
|
As I mentioned, it is not obligatory to use SV queues for this case. Actually, pure Verilog code may be even more compact  :
| Code: |
vc_list #(31,15) tag_list ();
always @(packet_sent) tag_list.add(tag_sent);
always @(packet_received) tag_list.check(tag_received);
always @(tag_list.err) $display("Error: unexpected tag received);
....
// End of simulation
if (tag_list.ptr > 0) $display("Error: packet queue is not empty");
|
Here, vc_list is reusable verification component (module) with tasks such as add and check and parameters defining bitwidth of queue entries and maximum queue depth.
Speaking about the coverage, I don't like tool-dependent automatic approaches for coverage collection. There is a standard way to define the functional coverage in SV using "cover" contruct. Obviously, this construct is absolutely independent from SV assertions. It allows us to collect only meaningfull coverage throughout simulation.
Regards,
Alexander Gnusin |
|
| Back to top |
|
|
lotr
Newbie
Joined: Nov 22, 2004
Posts: 4
|
| Posted: Tue Nov 23, 2004 11:01 am Post subject: |
|
|
If there is a requirement to check/cover packet latencies as well as any other packet-related properties, there will be a need to use queues with structures or SV classes. However, I don't see such requirements for this specific case.
I do need to check other packet related properties and not just the tag_id for which I think there is no other way except to (as you said) use SV classes or structures which aren't supported by the tool yet.
Agreeing with Alex, here , that writing elegant and simple sva assertions do need a liitle experience and polish before one gets going. On the other hand thinking at higher layer of abstraction naturally aligns itself to use of higher level programming constructs |
|
| Back to top |
|
|
srini
Senior
Joined: Jan 23, 2004
Posts: 430
Location: Bengaluru, India
|
| Posted: Tue Nov 23, 2004 12:17 pm Post subject: |
|
|
| alexg wrote: |
1. Anyone prefers the way which matches with his/her previosus knowledge and experience. Since you had the previous experience writing the book about assertions, "assertion" way may be the most natural for you. For me, "queue" solution is the most natural and reusable way, since it directly formalizes the way we think about the solution.
It is also more reusable, since not only myslef can easily understand this code in the right way. It is also eaiser to debug, since there is no automatically generated threads and other assertion-related tricks.
|
I fully agree with you - I would slighty refine it saying "you tend to prefer thing that you are more familiar with off-late" (as many of us have done/are doing this higher level programming stuff anyway). However in general assertions tend to be more concise than a higher level programming construct based implementation - again I'm sure one can come up with "A" case in which my above statement may be falsified, but in general it is understandable that an assertion language can be concise for certain class of checks than procedural language/constructs.
Sure, any new methodology/way of doing it requires ceratin new thinking, approach, slightly different debugging skills etc. I would like to leave it to the community to decide if that's worth!
| Quote: |
3. I don't think the property defined by Ajeetha will make specification more clear and concise. For this specific case, plain English may be good enough:
"Once master dispatches a transaction, it will eventually receive response with the same tag as in requested transaction. "
|
Again I may be slightly biased, however, in general assertions tend to be more precise/clear & concise than natural languages - that's one of the driving factors steering their development in the first place. Perhaps it is not so much so for natural English speakers (not sure though) - but certainly any exectuable form of spec. is preferable for others.
| Quote: |
Speaking about the coverage, I don't like tool-dependent automatic approaches for coverage collection. There is a standard way to define the functional coverage in SV using "cover" contruct. Obviously, this construct is absolutely independent from SV assertions. It allows us to collect only meaningfull coverage throughout simulation.
|
While I respect that individual opinion, in my last job - though we had > 10K cover items defined, we didn't have "enough cover points". Also what was worrying was the fact that we had checkers that never got triggerred in specific branches etc. While I can't give all details of them here, clearly a link bet'n cover-and-check was missing. I personally find that assertions tend to help here - they are checkers and we can get *some* auto-coverage on them (I say *some* b'cos there can be certain temporal ranges that may be covered under one bin - again ask your vendor for "temporal range binning" NOW!!). But I wouldn't oversell assertions as THE checker solution - there are definitive set of problems better handled via higher level programming constructs than assertions. Assertions - as in use today - are better suited for:
1. Lower level, implementation specific checks
2. Heavy control oriented checks
(among other things).
As Alex said, it will surely be interesting to see other views - than assertion authors and regular poster-gurus such as alexg - any takers, SAHO ?
Thanks,
Srinivasan
_________________
Srinivasan Venkataramanan
Chief Technology Officer, CVC www.cvcblr.com
A Pragmatic Approach to VMM Adoption
SystemVerilog Assertions Handbook
Using PSL/SUGAR 2nd Edition.
Contributor: The functional verification of electronic systems |
|
| Back to top |
|
|
alexg
Senior
![]()
Joined: Jan 07, 2004
Posts: 586
Location: Ottawa
|
| Posted: Tue Nov 23, 2004 1:12 pm Post subject: |
|
|
| lotr wrote: | | Agreeing with Alex, here , that writing elegant and simple sva assertions do need a liitle experience and polish before one gets going. On the other hand thinking at higher layer of abstraction naturally aligns itself to use of higher level programming constructs |
I am not against assertions. They are very useful for the cycle-precise part of the testbench. However, we are dealing with transaction level now, and there are more efficient language constructs for this purpose.
First, transaction data can be naturally expressed by SV classes or structures. Then, transaction-level timing is different from the cycle-precise timing. On transaction level, transaction events replace system clock. There is no reason to perform assertion check every clock cycle - too many unneeded computations. We need to synchronize computations only with transaction events (such as packet_departure, packet_arrival).
| lotr wrote: | | I do need to check other packet related properties and not just the tag_id for which I think there is no other way except to (as you said) use SV classes or structures which aren't supported by the tool yet. |
First of all, I am almost sure that classes and structures are supported by existing tools at the same level as SV assertions. (Here, It would be nice to get comments from the tool developers).
Then, there is always another way. Pure tool-independent Verilog HDL can be a good choice too.
We can implement timing checks within reusable queue (queue will store timestamps along with data and check amount of time data was stored in the queue against predefined timeout limit). Then, we can use more than one instance of vc_list for each packet property we have to check:
| Code: |
vc_list #(31,15) tag_list ();
vc_list #(12,15) addr_list ();
...
always @(packet_sent) begin
tag_list.add(tag_sent);
addr_list.add(addr_sent);
end
always @(packet_received) begin
tag_list.check(tag_received);
addr_list.check(addr_received);
end
always @(tag_list.err) $display("Error: unexpected tag received);
always @(addr_list.err) $display("Error: unexpected address received);
....
// End of simulation
if (tag_list.ptr > 0) $display("Error: packet queue is not empty");
|
Regards,
Alexander Gnusin |
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can 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
