Home > Community > Blogs > Functional Verification > specman 9 2 preview shortened when subtype declarations
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).


* 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: *

Specman 9.2 Preview: Shortened “When Subtype” Declarations

Comments(1)Filed under: Functional Verification, Incisive Enterprise Simulator (IES), e, Specman, Aspect Oriented Programming, AOP, IES-XL

[Preface: all features in the 9.2 preview series are in Beta now. We invite you to sign-up for the beta program and give this feature a test drive!]

[Team Specman welcomes back Yuri Tsoglin from Specman R&D to introduce one of “his” new features.]

The current syntax of "when" struct member declaration explicitly includes the base (parent) struct name, in the context of which it is evaluated. Starting in Specman 9.2, you do not need to explicitly mention the base type name, saving editing, compile, and run time, while also making the code more readable and easier to reuse.

Problem Statement
As some of you in the audience have pointed out in the past, the current “when subtyping” syntax is redundant because it requires you to include the base struct name in a "when" declaration although it is clearly implied by the context in which the "when" declaration appears. In fact, if the base struct name is different from that of the context, it causes an error message.

Solution Overview
This new short form of the when subtyping syntax is particulalry convenient for "when" declarations in template types, since a template type full name may be long, and it is more convenient to omit it when possible. Here is the new, official definition:

when struct-subtype [base-struct-type] {struct-member; ...}

The syntax and the meaning of the parameters are same as described currently in the docs (Section 4.7.1 of the Specman 8.2 “e_ref”), with the only modification: base-struct-type became optional. The following examples show the usage of the new syntax, with the existing syntax shown as a comment.

Example 1
The following struct contains when struct member declarations using the new short syntax.

type color_t: [red, green, blue];
struct packet {
   color: color_t;
   good: bool;
   // when red packet {
   when red {
       size: int;
   // when red good packet {
   when red good {
       print_msg() is {
           out("This is a red good packet, size = ", size);


Example 2
The following example shows when struct member declarations using the new short syntax in a template type definition and in its instance extension.

type color_t: [red, green, blue];
template struct map of (<key'type>,<value'type>){
   color: color_t;
   // when red map of (<key'type>,<value'type) {
   when red {
     print_msg() is {
       out("This is a red map.");

 extend map of (int(bits: 16), list of string) {
   // when red map of (int(bits: 16), list of string) {
   when red {
       print_msg() is also {
            out("It holds string lists, with 16-bit int keys.");


I hope you find this new syntax useful, and I invite you to send me any questions or feedback by posting a comment below, or forward them via Team Specman.

Happy Coding!

Yuri Tsoglin
Specman R&D


By Yaron Ilani on September 9, 2009
The shortened WHEN is a great feature. Here's my $0.02:

I would also consider a "multiple" WHEN feature, so that if you wanted to extend the GREEN and BLUE types (but not the RED) you wouldn't have to duplicate your code. Take it even further  - why not specify the sub-types as a list -


when {RED,BLUE} {

   //do something


and maybe even this:

when !{GREEN} {                // notice the "!"

// do something


Leave a Comment

E-mail (will not be published)
 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.