Home > Community > Blogs > Functional Verification > religious battle between quot like quot vs quot when quot inheritance
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Functional Verification blog (individual posts).
 

Email
* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

Cadence Contacts

Global Office Locator
Find Offices worldwide »

Sales Inquiry
Request for Product information »
Cadence Channel Partners »

Corporate Headquarters
Cadence Design Systems, Inc.
2655 Seely Avenue
San Jose, CA 95134
Phone: 408.943.1234
* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

The Eternal Debate: "Like" vs. "When" Inheritance

By Team Specman on January 5, 2009Comments(3)Filed under: Functional Verification, verification strategy, IES, Incisive Enterprise Simulator (IES), e, Specman, IEEE 1647, Aspect Oriented Programming, AOP

First: Happy New Year, Specmaniacs!

Much like the rivarly between the New York Yankees and the Boston Red Sox (or if you prefer, ManU vs. Chelsea, or the Tokyo Giants vs. Hanshin Tigers, or [insert a cricket example here]), Specmaniacs have been divided into two competing camps, with one group favoring "when inheritance", and the other "like inheritance".

Before R&D and others from Team Specman elaborate on this topic in a subsequent post, which construct do you favor, and why?

Comments(3)

By Yashdeep Godhal on January 6, 2009
Hi,
Happy New Year to everyone.
In my view, they can be treated as complimentary. Yeah, sure, you can say that "when inheritance" is superior due to AOP and I would cast my vote ultimately in favor of "when inheritance". But there are some cases in which "like inheritance" is better. Generation using "like inheritance" is faster and it consumes less memory, so if performance is more important than constraints, "like inheritance" could be a winner.
But still, if there is only one side to be chosen, I am in "when inheritance" favoring group due to the fact that it is much better for extensibility and it creates orthogonal sub-types.

By Stephen Hobbs on January 8, 2009
I think "when" inheritance has most to offer when the types are closely related, for example data modelling or varieties of a given BFM. Without "when" sub-types it becomes much harder to control the run-time generation of transactions, as one has to build monolithic classes and do the "when" work oneself; or use multiple "like" derived classes and operate on the chosen type - not a very extensible technique.

Using "like" inheritance seems to offer more for structural objects, where the differences between the derived types are much bigger and one would not choose to switch dynamically between them. For example, an Ethernet BFM and a USB BFM share little other than the basic structural elements such as a logger, links to a monitor and sequencer; so there is no benefit to using "when" sub-types. One could however easily justify an extension to eRM such that all BFMs are "like" inherited from a common base type:

unit ethernet_bfm_u like erm_bfm_u { ... };

On the other hand the Ethernet frames would only be restricted by "like" inheritance. Using "when" sub-types gives much better control and reusability.


By Avidan Efody on August 1, 2009
Was the promised post ever published? I couldn't find it.
As said by the others, the best is to see "Like" and "When" as complementary. I believe that the artificial rivality between them was just a sales trick right from the beginning...Maybe we should even stop saying "When inheritance" and say "When subtyping" instead...
I've just posted something on the subject here:
www.specman-verification.com/index.php

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.