A Community of Verification Professionals

Create an Account	Home | Calendar | Downloads | FAQ | Links | Site Admin | Your Account
Modules · Home · Downloads · FAQ · Feedback · Recommend Us · Web Links · Your Account Advertising Who's Online There are currently, 32 guest(s) and 2 member(s) that are online. You are Anonymous user. You can register for free by clicking here Login Nickname Password Security Code: Type Security Code 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.    Verification Guild: Forums  Forum FAQ   Search   Usergroups   Profile  Digest    Log in  aspect and oop differences Goto page 1, 2  Next          Verification Guild Forum Index -> Main View previous topic :: View next topic   Author Message lngopi Senior Joined: Aug 31, 2006 Posts: 36 Location: Bangalore, India Posted: Fri Sep 01, 2006 1:28 am    Post subject: aspect and oop differences I have worked on both 'e' and 'Vera' for OOP and Aspect flavours. But I am still not able to clearly understand the unique differences between an Aspect oriented and an Object Oriented Language. Can someone please explain, with a piece of code example may be? Thanks in advance Chrs, -Gopi Back to top AdamRose Senior Joined: Nov 01, 2004 Posts: 30 Posted: Fri Sep 01, 2006 9:16 am    Post subject: Gopi, Are you trying to start a flame war ? A discussion on "Is eating meat murder ?" would be less contravertial on this forum ! There are a number of ways to answer your question. One is a general question about OOP vs AOP, the other is a specific question of Vera and SystemVerilog vs E. A useful reference for discussions about the first of these questions can be found at : http://www.infosun.fmi.uni-passau.de/st/papers/EIWAS04/stoerzer04aop_harmful.pdf While there are a few heretics in the s/w community, I think this can reasonably be said to reflect the majority opinion amogst s/w engineers. Then, there is a specific question about E and OO verification languages such as Vera and SV. There is an often ( although I would say less often nowadays ) expressed opinion that AOP is the only way to achieve the necessary flexibility required for doing verification. I think this opinion is or was held for a couple of reasons : - because E introduced concepts such as constrained randomization and functional coverage into the mainstream. - because an understanding of how to use OO properly is not yet widespread amongst verification and hardware engineers. The first of these is no longer true as the concepts of constrained randomization and functional coverage have migrated first into Vera and then into the standard language SystemVerilog. The second is becoming less true as OO verification methodologies such as Synopsy' VMM and Mentor's AVM become more widespread ( and, as an author of the AVM I can't really resist saying here that AVM is more OO than the VMM, which relies heavily on the pre OO concept of callbacks ). While E does have a lot of flexibility built in to it, it is the flexibility of the Wild West. You can do anything you like, but you might well get shot by a random stray bullet, and you may have unwittingly fired that bullet yourself. Consider the following E code : Code: <` struct incrementer is {   increment() is     {       x = x + 1;     }; extend MyStruct {   increment is also { x = x - 2; }; }; `> Now it's important to understand what has happened here - it's not just some instantiations of "incrementer" in your system that actually do a decrement, it's ALL instantiations of "incrementer". - there is no way the initial designer of "incrementer" can prevent someone coming along later and changing the function of increment to do a decrement - any other modifier of implementer needs to know about this change to incrementer The equivalent OO code looks the same but is actually very different : Code: class incrementer;   int x;   virtual function void increment;     x = x + 1;   endfunction endclass class decrementer extends incrementer;   function void increment;     super.increment;     x = x - 2;   endfunction endclass A few points need making here : - the designer of incrementer has CHOSEN to allow subclasses to change the implementation of changeable by using the virtual keyword - the user of decrementer must somewhere explicitly instantiate a decrementer to get this new functionality, it can't happen by accident - some other subclass of incrementer can independly change what increment does without caring at all about what decrementer has done This is a small illustration of why I believe SystemVerilog offers all the flexibility of E but with a lot more control. This is particular so when parmeterization ( called templates in C++ ) are used in conjunction with OO. It also has the advantage of being a genuine standard language, in that it is supported by more than one large EDA company. Adam Adam Rose Verification Technologist Mentor Graphics Back to top Janick Site Admin Joined: Nov 29, 2003 Posts: 1317 Location: Ottawa, ON Canada Posted: Fri Sep 01, 2006 9:34 am    Post subject: AdamRose wrote: ( and, as an author of the AVM I can't really resist saying here that AVM is more OO than the VMM, which relies heavily on the pre OO concept of callbacks ) Would it make the VMM callback mechanism appear more OO if I called it a facade pattern coupled with an observer pattern? It is the same mechanism as the one used in AVM's analysis port... Does that make your analysis ports less OO??? OO, like AO, is only a mean to an end, not an end onto itself. Back to top AdamRose Senior Joined: Nov 01, 2004 Posts: 30 Posted: Wed Sep 06, 2006 3:28 am    Post subject: Quote: Would it make the VMM callback mechanism appear more OO if I called it a facade pattern coupled with an observer pattern? It is the same mechanism as the one used in AVM's analysis port Err, no, it wouldn't. In many ways, the history of OO can be described as a long and more or less sucessful battle against the callback. The difference between the observer pattern and a callback is that the observer pattern is just a message passing mechanism between two independent objects. The observer has no means of modifying the object sent, and it very definitely has no means of modifying the sender itself. The callback can both modify the thing sent and can modify the sender. Modifying the thing sent is bad enough, but actually modifying the sender is particularly bad, since it breaks the whole principle of encapsulation. A byproduct of this, in SystemVerilog at least, is that methods which should really be protected have to become public. These methods are only intended for use by a callback object at certain times but can now be used by anyone, anytime because they have been made articificially public. This ability to do modification also introduces another problem, that of ordering. In the observer pattern, the observers are all inherently equal, since neither the message nor the sender can be modified. The order in which the observers observe is irrelevant. Because callbacks modify, ordering suddenly becomes a serious issue - a given callback may simply not work because it has been registered at the wrong place in a queue. This problem has been addressed in the VMM by introducing prepend and append callback methods, but I would argue that it is only partially addressed. The reason is that it is that it place an unreasonable burden on the testbench integrator, who has to be know what callbacks can and cannot be prepended and appended in what order. This detailed knowledge is properly the domain of the person supplying the VIP, not the testbench integrator, who potentially has 1000s of such modules with their own possibly arcane rules to deal with. It's this kind of problem which shows the problems that can arise with breaking the basic principles of encapsulation in the way that callbacks do, and this is why things mechanisms like inheritance and template/parameters exist in OO languages. Anyway, callbacks may introduce a flavour of the wild west into an OO language - but the main point of my original post was to attack the "Wild West on Steriods" of E Adam. Back to top Logger Senior Joined: Jun 15, 2004 Posts: 298 Location: MN Posted: Wed Sep 06, 2006 9:32 am    Post subject: Callbacks in VMM do have 2 intended purposes. One is simply to observe, alla the observer pattern. The other is to inject functionality, alla aspects. Quote: The callback can both modify the thing sent and can modify the sender. Which is of course on purpose, as it is meant to introduce some of AOPs "wild west" behavior into an OOP environment, albeit in a controlled manner. Which ever flavor of a callback you use, OO or AO (and in Vera RVM you have both), I find them very useful for injecting functionality into a transactor. Lacking them, it requires more work to get the job done. Possibly a purer method of accomplishing this would have been to create two callback classes in the VMM. This won't work in Vera RVM due to the language, but I'm also unsure of SV. VCS doesn't support classes declared within classes yet, so I can't test this. Anyone want to divine an interpretation from the LRM that I'm not seeing? Code: typedef class xactor; class observer_callbacks;   void function my_observer_cb(xactor xtor, const ref my_data data);     // do something     // can only access public functions on the transactor and cannot consume time, and data is     // declared const so you can't change it.   endfunction endclass class xactor;   protected integer x;   local observer_callbacks observers[$];   local injector_callbacks injectors[$];     class injector_callbacks;     task my_injector_cb(my_data data);       // can this directly access xactor::x and xactor::my_protected_task()?       // if so, no need to make them "artificially" public, or even put this on the       // parameter list.     endtask   endclass     protected task my_protected_task();     // do something   endtask     task public_task()     my_data data;     // do something     foreach (injectors[i]) injectors[i].my_injector_cb(data);     foreach (observers[i]) observers[i].my_observer_cb(this, data);     // do something else   endtask endclass Assuming this works as intended, observers and injectors are cleanly separated from each other. Injectors also have the required access they need without artificially making members of the transactor public that shouldn't be. The whole problem attempted to be addressed here is that the injector class and it's associated transactor are tightly coupled. The injector class needs greator access to the transactor than other classes do. C++ solves this with the "friend" concept. I really hope "inner classes", to use a Java term, solves this problem in SV. There needs to be some mechanism to create tightly coupled classes with greater access, or SV's OO model is broken. Ryan Back to top AdamRose Senior Joined: Nov 01, 2004 Posts: 30 Posted: Wed Sep 06, 2006 9:45 am    Post subject: Ryan, There's just no need for "injectors". You just overload a virtual method in a subclass and replace the original component with an instance of the subclass. This is what OO is for. The process of deciding which methods to make virtual is exactly the same process as deciding where to put your callbacks. The process of replacing an instance of a base class with an instance of its subclass is no more onerous, and is often considerably less onerous, than the process of creating a callback class and pre or appending it to a list. Adam. Back to top Janick Site Admin Joined: Nov 29, 2003 Posts: 1317 Location: Ottawa, ON Canada Posted: Wed Sep 06, 2006 10:20 am    Post subject: AdamRose wrote: There's just no need for "injectors". You just overload a virtual method in a subclass and replace the original component with an instance of the subclass. Been there, tried that. It just does not work in real-life verification environments. That works fine if you want to do this replacement from the beginning of the simulation and only do a few extensions of a few transactors. But if you want to do this replacement dynamically, you have to stop the existing instance cleanly, remove it from the environment, put the new one in, make sure the old one is completely disconnected from its transaction-level, physical-level and notification interfaces, reconnect said interfaces to the new transactor instance, start new transactor, without clausing a glitch. Furthermore, because SV only supports single inheritance, you can't have orthogonal extensions. For example, you can't extend the transactor for scoreboarding, functional coverage and error injection sperately, then extend it further for a particular corner case in a test. To do so requires that you carefully manage a genealogy of transactor inheritances that quickly become unmanageable for a large number of testcases and transactors. With callbacks, I can dynamically modify (and unmodify) the behavior of a transactor, for only that concern that I care about, without worrying about the other concerns (except of course where modification occurs -- but the VMM provides guidelines for that). In reality, observers and injectors use different callback methods. The injectors use "pre transaction" callback points, and observers use "post transaction" ones. Back to top AdamRose Senior Joined: Nov 01, 2004 Posts: 30 Posted: Wed Sep 06, 2006 10:47 am    Post subject: Well I've been there and done it, and it does work fine. First of all, adding whatever new coverage and scoreboarding you like can be done using the observer pattern ( = "analysis ports" in the AVM ), which don't suffer from the ordering problems I described earlier. So it's only really error injection that should be done by inheritance. If you want to dynamically turn different types of error injection on and off dynamically through the lifetime of the simulation, then you just give your driver a configuration interface to do exactly that. This is less "Wild West" than callbacks, since you need to define all the possible error injection algorithms you're going to use in a single sub class at the beginning of the simulation. This is not hugely different from gathering the various callbacks associated with a given piece of VIP into a single package, which is a reasonable design practise anyway. But it does mean that the ordering problems that you are consistently ignoring must be dealt with by the person who designs the error injecting transactor, rather than the poor system integrator who really doesn't want to know about such things. Doing a little more work up front like this makes the construction of a functioning testbench considerably easier. It also has some other nice advantages - for example, the configuration can be a class subject to constrained randomization,so you can randomly select diferent ( legal ) combinations of error injection algorithm. Adam. Back to top vhdlcohen Industry Expert Joined: Jan 05, 2004 Posts: 1044 Location: Los Angeles, CA Posted: Wed Sep 06, 2006 2:21 pm    Post subject: AdamRose wrote: First of all, adding whatever new coverage and scoreboarding you like can be done using the observer pattern ( = "analysis ports" in the AVM ), which don't suffer from the ordering problems I described earlier. Just for the record, VMM provides many means other than callbacks for transferring information in a passive manner. VMM does offer this concept of "analysis port" with the vmm_notify that implements an interface to the notification service. This class can also be use to pass, using an observer pattern, information from one transactor onto another (e.g., a command transactor to a generator). VMM also offers the VMM broadcast where a channel can be boradcasted to multiple transactors. There are 2 modes in this broadcaster, As Late As Possible and As Fast As Possible. VMM also offers the tee method to help in the coverage or scoreboard. Quote: VMM: When the tee mode is ON, retrieve a copy of the transaction descriptor references that have been retrieved by the get() or activate() methods. The task will block until one of the get() or activate() methods successfully completes. On the topic of callbacks, at their root, callbacks are an access mechanism. If the callbacks are not extended, there is no need to invoke the callback methods. If no callback is registered, then the list of registered callbacks is empty hence there is nothing to call. The use of registered callbacks provides an aid in plugging into the code “unforeseen” functionality by identifying “strategic” insertion/callback points. Callbacks provide controllability to the user, and allow transactors to adapt to the needs of an environment or a testcase. For example, you can have a callback called Post_peek_pre_execute that initially does nothing, is not even registered, and when called in the code consumes no execution cycles. However, when the need arises, the callback can be extended and registered or unregistered dynamically. Quote: ..Doing a little more work up front like this makes the construction of a functioning testbench considerably easier. It also has some other nice advantages - for example, the configuration can be a class subject to constrained randomization,so you can randomly select diferent ( legal ) combinations of error injection algorithm. Adam. Why can't these concepts of randomization and selection of different combination of error algorithms be also implemented within the callback? The point I am making is that there are different coding styles and preferences. I believe that the choice of what to pick is very much a function of the situations and personal preferences. _________________ Ben Cohen http://www.systemverilog.us/ * SystemVerilog Assertions Handbook, 2nd Edition, 2010 * A Pragmatic Approach to VMM Adoption * Using PSL/SUGAR ... 2nd Edition * Real Chip Design and Verification * Cmpt Design by Example * VHDL books Last edited by vhdlcohen on Wed Sep 06, 2006 11:40 pm; edited 1 time in total Back to top AdamRose Senior Joined: Nov 01, 2004 Posts: 30 Posted: Wed Sep 06, 2006 4:19 pm    Post subject: Ben, Well yes the VMM has loads of goodies in it, and so does the AVM. When I first replied to Gopi, the overwhelming thrust of the message was that the particular implementation of AOP adopted by E really was the Wild West, where you can get hit by stray bullets that you may have fired yourself. Gopi asked for examples, and I gave him a near trivial example to show some of the problems with AOP in E. I then went on to say that there were many misconceptions about OO in the verification community, and that a lot of these had been addressed first by Vera and the RMM, then the VMM and more recently the AVM in SystemVerilog. I should have but didn't point out the contribution of testbuilder and SystemC to overcoming these misunderstandings as well. My point about the VMM using some slightly out dated concepts was just a little bracketed sub point, not the main thrust of the message, which was pro SystemVerilog and pro OO. The dialogue has surprisingly been about VMM vs AVM rather than E/AOP vs OO. Perhaps this reflects a lack of confidence on the part of E users, or perhaps it reflects Cadence's withdrawal from many public forums, I don't know. But since the conversation has gone in this direction, I think it is reasonable to continue to point out that VMM's reliance on callbacks and macros rather than inheritance and parameterization is a little old fashioned, and does not take full advantage of the features now provided by SystemVerilog. Adam. Back to top Janick Site Admin Joined: Nov 29, 2003 Posts: 1317 Location: Ottawa, ON Canada Posted: Wed Sep 06, 2006 9:51 pm    Post subject: AdamRose wrote: VMM's reliance on callbacks and macros rather than inheritance and parameterization is a little old fashioned, and does not take full advantage of the features now provided by SystemVerilog. I guess we'll have to agree to disagree on callbacks. You don't have to use callbacks with VMM (you can use channels and/or vmm_notify to implement self-checking and functional coverage or use a pure virtual-method in the transactor like AVM suggests -- although I hope I've made a good case that it makes things more complicated in large verification projects) but everyone who has used them has found them invaluable in writing simple yet easy to control & extend reusable transactors. I do not like macros anymore than you but sometimes they are just was is called for to hide implementation details. What's wrong with using Code: `vmm_channel(my_packet) instead of Code: typedef vmm_channel<my_packet> my_packet_channel; I like the fact that it hides the implementation as a parametrized class (or not). I'll be the first to admit that the macro was used because Vera, then VCS, did not support parametrized class, but they allow the user code to remain unmodified and forward-compatible when they start using a version that does and make use of them. It also allows a vendor to implement VMM even though they may or may not support all SV features. But more importantly, it allows the definition of more than one coherent set of classes. For example Code: `vmm_scenario_gen(my_packet) creates six classes that work together to create a scenario generator in a simple single-line statement. Means to an end. Only means to an end. Not ends onto themselves. Back to top AdamRose Senior Joined: Nov 01, 2004 Posts: 30 Posted: Thu Sep 07, 2006 2:16 am    Post subject: Sure, if your simulator doesn't support parameterization then you have no choice but to use macros. Quote: But more importantly, it allows the definition of more than one coherent set of classes. For example Code: `vmm_scenario_gen(my_packet) creates six classes that work together to create a scenario generator in a simple single-line statement. If you use parameterization, you don't need to create anything. You just define your six related parameterized classes in a package and use them as required. Back to top rfbeckwith Senior Joined: Jan 11, 2004 Posts: 21 Location: Boston, MA Posted: Thu Sep 07, 2006 4:32 am    Post subject: Adam, Although I'm a pretty strong OO advocate (with almost 17 years of OO experience), I really don't see OO and callbacks as being related (or one superceding the other). They're 2 completely different techniques and (to me at least) there's absolutely NO REASON why you need to give up one when you use the other. I'm not saying you can't implement something that works in a similar fashion to callbacks using OO techniques, however, if I want to be able to inject "this error" on "that packet" (and no other, but perhaps other specific errors on other specific packets) then I'm sorry, callbacks seem (to me) to be the way to go. I "attach" a callback object to the packet(s) I want to error and I'm done. I could probably invent an infrastructure so that I could this purely-OO, but that's not required (but timeliness and meeting schedules is). Quote: If the only tool you've got is a hammer, sooner or later everything starts looking like a nail Use the right tool for the job and don't get so hung up upon whether or not it's the OO way. --Bob Back to top AdamRose Senior Joined: Nov 01, 2004 Posts: 30 Posted: Thu Sep 07, 2006 4:52 am    Post subject: Bob. Quote: I really don't see OO and callbacks as being related Well we agree about that at least Quote: I "attach" a callback object to the packet(s) I want to error and I'm done From the quote above you seem to be attaching callbacks to transactions, not transactors ... or have I misunderstood ? Adam. Back to top rfbeckwith Senior Joined: Jan 11, 2004 Posts: 21 Location: Boston, MA Posted: Thu Sep 07, 2006 2:16 pm    Post subject: Adam, Quote: From the quote above you seem to be attaching callbacks to transactions, not transactors ... or have I misunderstood ? Your understanding is fine. For error injection, my preference is to attach the error injector to the transaction so that it can follow it through the testbench (and do it's dirty work when necessary). You don't have to do things that way if you don't like. You could have you error injectors at fixed locations in the transactors looking for specific transaction IDs to corrupt. At the moment, I simply prefer the former. --Bob Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         Verification Guild Forum Index -> Main All times are GMT - 5 Hours Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum Main----------------MainEDA NewsCommunity Services Networking----------------Looking for a jobLooking for candidates Archives----------------AssertionsCoverageFormalSimulationDesignMiscellaneous Test----------------Test  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 Forums ©

Verification Guild © 2006 Janick Bergeron
Web site engine's code is Copyright © 2003 by PHP-Nuke. All Rights Reserved. PHP-Nuke is Free Software released under the GNU/GPL license.
Page Generation: 0.220 Seconds