| 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, 51 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 |
heritageorchard
Senior
Joined: Feb 22, 2005
Posts: 123
Location: Boston, Ma
|
 Posted: Fri Mar 14, 2008 2:01 pm Post subject: |
 |
|
Hi Ben,
| Quote: | | By creating a complete copy, you maintain a pristine original of the transaction, thus isolating the producer of the randomized packets (i.e., the generator) from the consumer of the transaction (i.e., the consumer transactor). This insures that the generated transaction sequences is in accordance to the original intent, rather than one that is modified in an uncontrolled manner. |
Can we please avoid loaded words like pristine, ensures, and uncontrolled and try to keep this as unbiased as possible? I much prefer letting engineers make architectural trade-offs in a pristine discuussion. 
There is a time when copying at the generator makes sense. I believe there are many more times where copying does not make sense. Let's talk about the trade-offs and let the coders decide what's best where.
In a majority of my work, the generator could care less about the pointer after it has created the randomized transactions. In this specific case (previous post), putting the code in to a method would do that (as the pointer is local).
As a general bias, I am not very concerned with misuse. I am much more concerned with creating code that is as simple as possible. And yes, I have worked in small start-ups to many hundred person teams. And I know you have as well.
| Quote: | | This is important when the next generated transaction is a function of the current transaction. |
For the very few times I have had to do this, I keep a copy locally of the specific fields that are needed. Never have I needed the entire transaction. In the majority of cases, I have kept meta-data instead. The transaction is just the output form of what the generator was doing.
| Quote: |
The consumer transactor may modify that copy (e.g., add results from DUT), as it may use that modified copy to pass it onto another channel or thru a notification to pass results to a monitor or some other transactor. |
Agreed, and that's an architectural decision. Copying is not to be taken ligtly, especially in OOP designs. Actually in the case you mentioned above, I'd expect the transaction to be passed by pointer. That's the simplest way for the driver and checker to communicate about a transaction (Yes, I realize there are other ways.)
_________________
Mike Mintz
www.trusster.com
"Teal and Truss" A multi-vendor, multi-language, open source verification framework
co-author "Hardware Verification with C++", and "Hardware Verification with SystemVerilog" |
|
| Back to top |
|
 |
vhdlcohen
Industry Expert
Joined: Jan 05, 2004
Posts: 1238
Location: Los Angeles, CA
|
| Posted: Fri Mar 14, 2008 4:46 pm Post subject: |
|
|
Hi Mike,
My reasons for using the copy() is because I was following Janick's VMM guidelines. From Janick's VMM book: | Quote: | Rule 5-6 — A generator shall randomize a single instance located in a public class property, then copy the final value to a new instance. This process is called a factory pattern and yields the most controllable generator. ..
Example 5-7. Factory Pattern | Code: | class eth_frame_gen extends vmm_xactor;
...
eth_frame randomized_fr;
function new(...)
...
this.randomized_fr = new;
endfunction: new
...
while (...) begin
eth_frame fr; // <--------------
...
$cast(fr, this.randomized_fr.copy()); // <--------------
...
out_chan.put(fr);
end
...
endclass: eth_frame_gen |
|
| Quote: | | Can we please avoid loaded words like pristine, ensures, and uncontrolled and try to keep this as unbiased as possible? |
As to the word pristine , I used it in the correct meaning in that context, as it means | Quote: | 1. Remaining in a pure state; uncorrupted by civilization.
2. Remaining free from dirt or decay; clean: pristine mountain snow.
3. Of, relating to, or typical of the earliest time or condition; primitive or original. |
BTW, in his book, Janick used the word "controllable" in This process is called a factory pattern and yields the most controllable generator. From Q/A of our VMM book | Quote: | | Generators use the copy() method to send a copy of a transaction object into the channel, thus maintaining the original transaction pristine. This provides a separation of handles between the original transaction manipulated by the generator and the consumer that extract the copy from the channel. In the manipulation of the transaction, the generator may also need the value of the current transaction to create the next transaction. |
None of the reviewers objected to that explanation or wordings.
Bottom line, is the copy really necessary? As you said, NO. I agree. Is it desired? As a methodology, it probably would be beneficial. But, in a methodology, we often do things that are not absolutely necessary, but we do it just because it is the methodology. As an example, in construction, is it absolutely necessary to have studs every 16 inches? NO. I am sure that the building structure would be stable with 18 or 20 or 24 inch separation between studs. But having a standard makes changes a lot easier. Anyway, an opinion.
_________________
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 |
|
|
dave_59
Senior
Joined: Jun 22, 2004
Posts: 974
Location: Fremont, CA
|
| Posted: Fri Mar 14, 2008 6:12 pm Post subject: |
|
|
| vhdlcohen wrote: | | As an example, in construction, is it absolutely necessary to have studs every 16 inches? NO. I am sure that the building structure would be stable with 18 or 20 or 24 inch separation between studs. But having a standard makes changes a lot easier. Anyway, an opinion. |
I think you meant to say that its easier if you stick to 16inch stud spacing if you want to add insulation or nail plywood/sheetrock to the wall which has all been cut to dimensions assuming standardized spacing.
In the AVM, we have general policy about copying transactions: MCOW - Manual Copy ON Write. This is a safety policy that ensures that anyone who modifies the members of a transaction has complete control over who sees the effects of those modifications.
Dave |
|
| Back to top |
|
|
vhdlcohen
Industry Expert
Joined: Jan 05, 2004
Posts: 1238
Location: Los Angeles, CA
|
| Posted: Fri Mar 14, 2008 8:23 pm Post subject: |
|
|
| dave_59 wrote: | | In the AVM, we have general policy about copying transactions: MCOW - Manual Copy ON Write. This is a safety policy that ensures that anyone who modifies the members of a transaction has complete control over who sees the effects of those modifications. |
Dave, I need some clarifications. Are you saying that a transactor who modifies a transaction keeps a separate copy of that transaction for itself. In other words, he makes a copy and sends the copy?
Also, by the statement complete control over who sees the effects of those modifications you mean the transactor knows who the receiver(s) of the transaction are. Am not sure if a transactor would know who the receivers are since that is determined by the environment, which can change, and is separate from the transactor. Maybe my terminologies are not correct. Thanks, Ben
_________________
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 |
|
|
Dhaval
Senior
Joined: Feb 16, 2006
Posts: 94
|
| Posted: Fri Mar 14, 2008 10:56 pm Post subject: |
|
|
Mike,
I suggest the book by Chris because I read and understood it properly from that. |
|
| Back to top |
|
|
heritageorchard
Senior
Joined: Feb 22, 2005
Posts: 123
Location: Boston, Ma
|
| Posted: Sat Mar 15, 2008 4:15 pm Post subject: |
|
|
Hi Dhaval,
With all due respect to Chris (I count him among my friends), understand that his book is an introduction to the syntax of SystemVerilog. You will not get a proper understanding of the trade-offs of cohesion and coupling from it, let alone a through discussion of abstractions, class design or overall architecture considerations. His book is not a journey of how to code verification systems.
I have a copy of Chris' book on my desk and have bought several for friends and co-workers.
Pressman's book is considered a classic, but the references he sites are pure gold. I cannont recommend his book enough.
If you want, e-mail me privately and I will send a few chapters from my book. I attempt to focus software engineering considerations on verification. (mike at my company).
_________________
Mike Mintz
www.trusster.com
"Teal and Truss" A multi-vendor, multi-language, open source verification framework
co-author "Hardware Verification with C++", and "Hardware Verification with SystemVerilog" |
|
| Back to top |
|
|
dave_59
Senior
Joined: Jun 22, 2004
Posts: 974
Location: Fremont, CA
|
| Posted: Mon Mar 17, 2008 2:07 am Post subject: |
|
|
| vhdlcohen wrote: | Dave, I need some clarifications. Are you saying that a transactor who modifies a transaction keeps a separate copy of that transaction for itself. In other words, he makes a copy and sends the copy?
|
Sort of. Another way of thinking about it is if you don't modify the transaction, then you don't make a copy. Since SystemVerilog does not allow you to pass class objects by value, so no component that has a handle to an object can claim authoritative ownership to that object once it has been passed to another component.
Whether the a generator randomizes the original and makes a copy, or makes a copy and then randomizes the copy is a secondary issue.
Whether you randomize the
| vhdlcohen wrote: | | Also, by the statement complete control over who sees the effects of those modifications you mean the transactor knows who the receiver(s) of the transaction are. Am not sure if a transactor would know who the receivers are since that is determined by the environment, which can change, and is separate from the transactor. Maybe my terminologies are not correct. Thanks, Ben |
No, I didn't mean the transactor needs to know who its receivers are. I meant by manually coping instead of automatically copying an object when passing it, you give the writer of the transactor a choice, albeit to hang themselves if the don't do the copy..
Dave |
|
| Back to top |
|
|
Dhaval
Senior
Joined: Feb 16, 2006
Posts: 94
|
| Posted: Thu Mar 20, 2008 7:08 am Post subject: |
|
|
Hi Mike,
Then may be I am missing something.....  |
|
| 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
