The Cadence Academic Network helps build strong relationships between academia and industry, and promotes the proliferation of leading-edge technologies and methodologies at universities renowned for their engineering and design excellence.

A huge knowledge exchange platform for academia to network with industry. We are looking for academic speakers to talk about their research to the industry attendees at the Academic Track at CDNLive EMEA and Silicon Valley.

New Specman Coverage Engine - Extensions Under Subtypes

This is first in a series of three blog posts that are going to present some powerful enhancements that were added to Specman 12.2 in order to ease the modeling of a multi-instance coverage environment. In this blog we're going to focus on the first enhancement, while the other two enhancements will be described in the following coverage blogs.

Starting with Specman 12.2, one can define the coverage options per subtype. Using per-instance, Specman checks the subtypes of each instance, and applies only the relevant subtype options. We will demonstrate the power of this in both "per unit instance" and "per subtype instance."

I. Utilizing when extensions for modeling per subtype instances

One intuitive use of extensions of covergroups under "when" subtypes relates to covergroups which are collected per subtype using the per_instance item option:

type packet_size_t: [SMALL, LARGE];

struct packet{

size: packet_size_t;

length: uint(bits:4);

event sent;

cover sent is{

item size using per_instance;

item length;

};

};

The results of the above covergroup are collected per each value of the size item, so in practice this covergroup is collected separately per each "size" subtype.

Let's assume that small packets can only have length < 8, and big packets can only have length >= 8. The following code was needed in pre 12.2 releases for refining the irrelevant values of each subtype:

extend packet{

cover sent(size==SMALL) is also{

item length using also ignore=(length >= 8);

};

cover sent(size==BIG) is also{

item length using also ignore=(length < 8);

};

};

This code can now be replaced with a native "when" subtype extension:

extend packet{

when SMALL packet{

cover sent is also{

item length using also ignore=(length >= 8);

};

};

when BIG packet{

cover sent is also{

item length using also ignore=(length < 8);

};

};

};

II. Utilizing when extensions for modeling per unit instances

Extension of covergroups under "when" subtypes can also be used to model the different instances of a covergroup that are collected per-unit instance, according to the exact subtype of the containing instance.

Let's see a code example that illustrates the power of this capability. In this code we model a packet generator unit that generates packets of different sizes. The packet generator unit has a field which describes the maximal size of a packet that a packet_generator instance can generate:

Oh, right, there's that coverage thing we need to define in order to check that each valid packet size was generated in each instance of the packet_generator :

extend packet_generator{

cover packet_generated using per_unit_instance is{

item p_size: packet_size_t = cur_packet.size;

};

};

OK, so the above code enables the coverage collection of p_size separately for each instance of packet_generator. Let's generate 100 packets in each packet generator instance. Surely we'll get 100% coverage?

Well, we won't. When launching Incisive Metric Center (IMC), three of the coverage instances are not fully covered. For example the grade of the instance under sys.packet_gen1 is only 75%:

The reason for that is the constraint that prevents the generation of HUGE size packets in instance sys.packet_gen1, so no matter how many packets are generated in that instance, the ‘HUGE' bucket (bin) will never be covered.

We need to refine the valid buckets according to the generatable packet size in each instance. We can use the instance specific covergroups extensions for that:

At first look, the later solution doesn't look more efficient than the former one. It includes 4 extensions of the covergroup instead of 3 extensions that were needed before. But what would have happened if instead of only 3 packet_generator instances we would have 100 instances? If we extend each instance by itself, as we've done in the first solution, we will need to extend each one of the 100 covergroup instances.

While using the "when subtype extension" solution, the 4 extensions above satisfy the requirement for any number of instances.

Even more important, the solution which uses "when subtype extension" is reusable, since it doesn't use the full path of the covergroup instances. So it is much more suitable for verification IPs and for module verification environments which are later integrated into system level verification.

But before you run and start extending your covergroups under subtypes, I'd like to mention that there is another newly supported option in the e language which is even a better suited for that exact scenario which is described above - -it is called the "instance_ignore" item option.

What is this "instance_ignore" option?

Why it is better suited for the above scenario?

For which scenarios is the ‘extension under when subtypes' better suited?

Answers for all of the above questions (and more) will be found in the next Specman coverage blog -- "Using Instance Based Coverage Options for Coverage Parameterization"