Jump to content

Recommended Posts

Section 14.2 of the IEEE STD 1666-2011 states

Quote

It should be emphasized that although deriving a new class from the generic payload is possible, it is not the
recommended approach for interoperability

I am wondering why the extension mechanism is preferred since you could simple ignore the additional fields provided in a derived class.

Share this post


Link to post
Share on other sites

Adding ignorable extensions and using the generic payload means that your TLM models would be reusable and interoperable with other TLM components that conform to the standard payload. By deriving a new class, you would make your model less usable in alternate systems.

 

Share this post


Link to post
Share on other sites

If a third party model is designed to take a tlm_generic_payload, and you derive from tlm_generic_payload, then it should handle your transaction object correctly, ignoring any additional fields that may be defined on the object.  If a target wants to make use of those additional fields, then it could dynamic_cast the tlm_generic_payload* to your derived type* (using C++ RTTI to ensure that it actually has a derived_type object) .   I understand that the standard was instead developed around extensions, but I'm wondering what was the motivation for going in this direction.

Share this post


Link to post
Share on other sites

You cannot bind sockets with different payload classes, as the interfaces are templated over the protocol traits, which include the payload and phase types.  So integrating this third-party model would require an adapter in your case.

Many use cases can be implemented with (ignorable) extensions, which will avoid this incompatibility and integration burden.   As a result, you don't have to write/use a custom adapters, interconnect models, tool integrations, etc. For maximum interoperability with models and tools, you want to follow the (base-protocol) conventions as closely as possible, even for custom protocols.

See the different TLM-2.0 compliance categories (IEEE 1666-2011, 9.1).

Hope that helps,
  Philipp

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×