Home > Community > Blogs > Functional Verification > constraint layering fine tuning your environment part 1
 
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: *

Constraint layering - Fine Tuning Your Environment - Part 1

Comments(1)Filed under: Functional Verification, Verification methodology , SystemVerilog, verification strategy, IES, Incisive Enterprise Simulator (IES), e, Specman, IEEE 1647, OOP, Aspect Oriented Programming, AOP, Object Oriented ProgrammingIn today's environment of ever growing complexity and ever shrinking schedules, simplifying verification code reuse and maintenance is a clear necessity.  To that end, this entry is dedicated to the concept of "constraint layering" in e. This concept is incredibly useful in addressing many issues that one faces when trying to reuse code both across projects in time, across projects that share common characteristics, and across projects that involve block level to system level reuse.

Let's start by laying some framework for the discussion.  What is constraint layering?  Basically, it is the idea of using constraints as building blocks and "layering" them upon a base set of code much like a bricklayer would add bricks to a foundation to create a building.

Some of the most straight forward applications for constraint layering is test writing or environment configuration. In fact, if your environment fully supports a coverage driven methodology using a constrained random environment you have probably already used this concept to fill in some of those coverage holes that might have been missed by full random testing.

Let's look at a simple example:

 

base_packet_def.e

<'
//file: base_packet_def.e

type packet_mode_t : [modeA,modeB,modeC];

type packet_kind_t : [ONE,TWO,THREE];

struct packet_s {
    my_mode : packet_mode_t;
    my_kind : packet_kind_t;
};
'>

 

env1_test_config.e

<'
//file: env1_test_config.e

extend packet_s {
    keep all of {
        my_mode in [modeA, modeB];
        my_kind == ONE;
    };
};
'>

 

There are a few points to notice here:

  1. The base environment code and the test writer constraints are not in the same module.
    • This gives granularity to the work that allows it to be split across multiple resources
      • Development teams can focus on implementing environments capable of generating all types of stimulus while testwriters focus on directing tests to cover interesting areas
  2. The test config writer did not have to modify the base code.
    • This is important if the base code has already been proven in other projects or is possibly an IP that is external to the test config writer.
  3. There is no inheritance as we think about it in the traditional OO sense. In other words, the test writer was able to extend the base code directly in another module without creating a new "class" that inherits from the base "class", add the new constraints, and then use the new class in the environment.
    • This is important in being able to reuse the constraints that the test config writer has created across the environment. Stay tuned for later editions where we will explore deeper into the power of Aspect Oriented Programming (AOP)

Hopefully this small example has demonstrated a concept in e that is extremely useful and somewhat unique to AOP languages. While similar results are not impossible in OO languages, such functionality does require a lot of forethought, planning, and extra code.

If you are not an e user I think that you will find that this practice is as easy as it looks, and quite powerful.

If you already have been using e, this example probably seems too simple.  Inevitably the task of verifying today's advanced chips makes the problem a bit more complicated then the example above. Of course this fact only makes this concept that much more important.

Think about the above example multiplied many times, spanning multiple teams and then trying to manage all those different flavors in an Object Oriented environment. Imagine how many changes might have to be done to a possibly already proven base code set and how complicated that code set could get!

Check here for some more discussion on this topic showing more information on constraint layering and extensions in e as well as some discussion on how you can address this issue in an Object Oriented language, System Verilog: http://www.vmmcentral.org/vmartialarts/?p=17

Stay tuned for Part II of this topic, when I'll talk about some constraint mechanisms built into the e language that aid in this layering approach.

Finally, please feel free to write in your own examples, questions and comments on constraint layering. I encourage you as the reader to help make this blog your own and get involved. Together we can start spreading the word about what is exciting in the e language, the Specman tool and related verification topics

Thanks

Brett Lammers
Advanced Verificacation Core Competency Team Member
Cadence Design Systems, Inc

 

Comments(1)

By Cedric Fau on December 11, 2008
AOP is clearly the key! In our industry, projects are involving many developers on multi-sites. You have to develop stimuli generation, checkers, test cases and coverage. AOP allows to develop all of this in parallel, nearly transparently. It is not the case with OOP, at least so easily. As verification engineer and verification team leader, i don't know how i could have met my projects' targets (time, quality and ressources) without this technology.
E-addicted ;)

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.