Constraint layering - Fine Tuning Your Environment - Part 1

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