Dynamic constraint using decorator design pattern

During the process of functional verification, we may encounter the problems of narrowing down the constraint to verify some corner cases times again. Usually we will need a children class and write down the constraint in it. If there are lots of corner cases, then we have to maintain lots of children classes. It’s painful and boring work.

And in another case,  we have a class tree with 1 parent class and 4 children classes. If we want to add new constraint to the parent class in some test cases, in traditional way, that means another 4 grandchildren classes with the same constraint block.

To solve this issue, a way of dynamic constraint is proposed. Dynamic constraint means a set of objects (D) which contains the same object (A) and have constraints on the A object. When doing randomize, randomize all of the Ds together. Then all the constraints both in A and in Ds on A will take effect. With few changes to legacy codes, we can easily implement the dynamic constraint, and realize constraint reuse.

There is  a design pattern named “Decorator Pattern” which is very suitable for dynamic constraint. The pattern definition in wiki is : In object-oriented programming, the decorator pattern (also known as Wrapper, an alternative naming shared with the Adapter pattern) is a design pattern that allows behavior to be added to an individual object, either statically or dynamically, without affecting the behavior of other objects from the same class.

I will demonstrate how to implement dynamic constraint using decorator pattern in below sections with a practice of VLIW(Very Long Instruction Word).

Assume that we are going to verify a processor which supports 4-way VLIW. A base class named “vliw” defines the general members, constraints and routines.

To apply the decorator pattern, we need a virtual decorator class named “decorator_vliw” which inherits the “vliw” and has a handle of “vliw” with rand type.

Then we have 4 classes which present VLIW contains 1/2/3/4 instructions. All are derived from “decorator_vliw”.

These classes define a basic class structure with a fully range of reasonable constraint.

Here comes a corner case that we want to verify VLIW without DIV instruction. With the work we previously did, it’s much easier to add this test.

The simulation log shows that no DIV instruction is generated in all VLIWs.


Author: aquaporcus


Leave a Reply

Your email address will not be published. Required fields are marked *