Home > Community > Blogs > Functional Verification > performance aware e coding guidelines part 2
 
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

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Performance-Aware e Coding Guidelines – Part 2

Comments(2)Filed under: Functional Verification, IES, Incisive Enterprise Simulator (IES), e, Specman, OVM e, AOP, IntelliGen, IES-XL, tech tips, OVM-e, specman elite, performance

Building on Part 1 where I talked about the “do’s and don’ts” of List performance, in this segment on performance-aware coding I’ll show you some memory saving tips.  We base this segment on base types (geeky pun intended) …

Base types extensions
Creating base classes with functionality that is common to many environments is a good practice.  In this way you “develop once” (and even more importantly – maintain only one copy), and benefit from reuse in many subsequent environments.  However, if you take this too far by adding fields to the e base types any_struct or any_unit – you can cause yourself some trouble.  Here is why: recall that any member you add to these base types will appear in each and every struct.  Consequently, instead of extending all the base types, we recommend extending only the OVM e base types.  Thus, when you extend specific base types (like ovm_agent, ovm_monitor, etc) – only the relevant units will contain the added functionality, saving memory in the process.

Const fields
When instantiating a struct that has several sub-types, Specman allocates memory for all optional fields.  For example, whenever instantiating the packet header struct defined below, Specman will allocate memory for all fields – those defined under “when CTRL” and those defined under “when DATA”.

struct packet_header_s {

    kind : packet_kind_t;

    when CTRL packet_header_s {

      /// many control fields …

    };

    when DATA packet_header_s {

      /// many data fields …

    };

};

However, this header kind is not expected to change during the run, so it can be defined as const. When const is used, Specman will allocate only the fields under the corresponding sub-type, potentially saving a lot of memory in the process.  Here is an example:

struct packet_header_s {

    const kind : packet_kind_t;

    when CTRL packet_header_s {

      /// many control fields …

    };

    when DATA packet_header_s {

      /// many data fields …

    };

};

 

struct packet_s {

    kind : packet_kind_t;

    header : packet_header_s;

 

    when DATA packet_s {

        keep type header is a DATA packet_header_s

    };

    when CTRL packet_s {

          keep type header is a STS packet_header_s

    };

};

Naturally, if you are in the early stages of development it would be best to adopt these techniques as part of your regular coding style.  But even if you are in maintenance or simple test writing stages, I believe it will be well worth the extra time to re-work and improve your environment.  In either case, you might want to run Specman CPU and MEM profiler, before and after modifying the code – I believe you will like what you see.

Next segment in the series:
Some performance tips for speeding up everyone’s favorite e / Specman capability: Generation!
 
Happy coding!

Efrat Shneydor
Methodology R&D

Reference link:  Part 1 on improving the performance of Lists

Comments(2)

By Stephen Hobbs on April 6, 2009
Hi Efrat.
If one has to remain backward compatible with legacy environments and Specman versions, is there a tidy way to a conditional "const" declaration? I'm thinking something like this, but without duplicating lines of code:
#ifdef SPECMAN_VERSION_06_20_OR_LATER {
 const kind : my_env_kind_t;
} else {
 kind : my_env_kind_t;
};

By Efrat on April 12, 2009
hi, Steve,
I cannot think of a better coding than what you wrote here.
But - since "const" is supported since Specman 5.1 (2006), I hope this is a non-issue.

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.