AOP Discussion on LinkedIn

Hello All,

Last week over in the LinkedIn Design Verification Professionals group, a thread came up in the discussion area regarding support for AOP in VERA.  The discussion quickly changed to the benefits of AOP for Verification.  Unfortunately, for the user who kicked off the thread, most of the other respondents seemed to only have experience with VERA's limited AOP capabilities and not with the more complete implementation of AOP in e.  In case this question comes up at your company (and in case you not already a LinkedIn subscriber), allow me to repeat my reply on the value of AOP in e/Specman below.

Also I forgot to mention this in the original LinkedIn post but added it later. I personally think a great reference on this topic of AOP and e,  is the book: Aspect Oriented Programming with the e Verification Language by David Robinson

 

Enjoy!  Brett Lammers

 

************************ Post to LinkedIn discussion *************************

Hello All,

I just could not resist putting my 2 cents in on this discussion.  Not being a Vera user myself, I cannot comment on AOP support in Vera, but I am getting the feeling from the other posts that there may be some limitations especially if it can only be used to layer testcases on top of an existing tesbench. 

I would agree with Dean and Igor that a very powerful usage of AOP is to manage testcases layered over an existing testbench.  However, at least when using e, I would argue that AOP plays an important role in testbench design also. 

As a reminder, (you all probably already know this): AOP (at least as implemented in e) goes beyond OOP in providing the user more flexibility to organize their code modules not only by objects, but also by cross-cutting-concerns (functionality that touches multiple objects in the code set).  In verification, these cross cutting concerns can include DUT related functionality such as operation modes as well as verification related functionality like coverage collection or checking.  Of course, as Dean and Igor already mentioned, the test itself is a cross-cutting-concern as it configures and constrains many objects within the testbench.  However, using AOP in designing the testbench is extremely useful encapsulating object functionality, safely maintaining existing code, and reusing existing code.

In the context of encapsulating object functionality, just like in OOP, it is good practice to go through some planning to organize both objects and their associated concerns into the appropriate modules.  This will prevent code that is difficult to read and maintain.  In fact, it may even make it easier to read and maintain since there will be additional modularity and encapsulation.  If we think about it modularity and encapsulation are really the motivation behind OOP in the first place.  AOP just gives you yet another dimension in which to manage your code. 

As Igor mentioned, since AOP gives you more freedom to split object functionality across multiple modules it is possible for you to create some incredibly messy code.  However, back in the day (over 7 years ago), the Specman team understood this risk, and in partnership with lighthouse customers created what was called the e Reuse Methodology ("eRM").  Today the same eRM concepts for building reusable testbenches in a methodical and organized manner can be found under the OVM umbrella as OVM e.  The success of eRM (it's been adopted by 98% of e/Specman customers), and the ongoing growth of Specman usage itself, shows that "structured AOP" is effective for block, chip, and system level verification challenges.

Brief digression: For additional information on OVM and how it applies to Specman/e check out this article and the related discussions:

www.cadence.com/Community/blogs/fv/archive/2008/07/12/why-is-ovm-important-for-specman-e-customers.aspx

What about code maintenance and reusing existing code?  Here again, AOP is almost indispensable. By using AOP extensions, users can methodically update an existing environment with concerns that were missed in the initial planning, or are the result of changes that occur later on in the project.  This sort of "after-the-fact" manipulation can be difficult in a standard OOP environment and/or if you only hold yourself to strict OOP practices.  In the context of reusing existing Verification IP, AOP allows you to configure, control and add functionality to the existing VIP without touching the base code set - hence the reference to "safety" above since you don't have to muck with proven code. This can become critical when sharing IP across multiple projects or groups.

I would also invite you all to check out additional discussions on this subject as well as other related topics here: www.cadence.com/community/posts/teamspecman.aspx

 

Cheers, Brett

********************************** End Post **************************************