Monday 25 May 2009

randc kind of implementation in e

When I went through SystemVerilog constructs, one of the unique construct I found out was randc. Cyclic randomization sometimes helps you generating all unique combinations before repeating it. One classic usage example of randc is to inject all the sequences into DUT at least once without repeating it again. So, I was wondering if it is possible to implement it in e. I realized that though you can not generate the item based on its previously generated values, you can have some workaround for that using list psudo methods. There are all_values() and is_a_permutation() psudo methods which can be used for this purpose.

Let me explain the logic to implement that classic usage example to inject all the sequences into DUT without repeating it. If we somehow generate a list of unique sequence kinds randomly, we can take that list items one-by-one and generate the sequence based on that kind. So, to generate the unique yet random list of sequence kind, we can use above mentioned two list psudo methods. Take a look at the following code snippet.

<'
type seq_type_t : [SEQ_A, SEQ_B, SEQ_C, SEQ_D, SEQ_E, SEQ_F, SEQ_G];
extend MAIN my_sequence_s
{
seq_randc : list of seq_type_t;
keep seq_randc.is_a_permutation(all_values(seq_type_t));
!seq : my_sequence_s;
body() @driver.clock is only
{
gen_seq_randc();
for i from 0 to seq_randc.size() - 1
{
do seq { keeping .kind == seq_randc[i]; }
};
};
};
'>

all_values(seq_type_t) statement will return a list which will have all the unique values of scaler type seq_type_t. is_a_permutation() will make sure that seq_ranc list has random but all the fields of the list returned by all_values(seq_type_t) statement. Thus, we have a list which has all the random values of the sequence kind. Now, we can loop through this list one by one and generate a seq and push it to the DUT.

2 comments:

Anonymous said...

Hi,

Just bumped into this one and since this is one of my favorites I'd like to comment:
- randc is the wrong implementation for the correct concept. The correct concept is to make sure that at you have at least injected every possible value of a certain domain to the DUT (a "shallow" complete coverage). The wrong implementation is the fact that:
(a) this is something that one would like to get over a regression and not over a specific test
(b) this is something that one would like to get occasionally and not couple it with a certain field forever by adding it to its field declaration
(c) this is something that one would like to achieve in accordance to having a good distribution otherwise. In the current SV implementation (inherited from Vera) randc implies that the cyclic behavior will return itself over and over meaning that you'll lose key behavior such as repeating the same value twice, and so one

I'm saying all that to emphasize that your "workaround" in e should not be treated as a compromise but the opposite: this is the right way to do such things, as in AOP you can apply this behavior easily in a certain test without impacting the overall behavior.
I also wanted to point you to an even more powerful feature call is_all_iterations() which basically generates the complete set of values for a whole struct and not just for a certain field. Using it you can get a "randc" behavior over a cross space and not just a single item.

BTW - I was glad to find this blog. I'll make sure we distribute it further in the e/SN blogosphere!

Thanks,

Shlomi Uziel
Specman Group Director

Anonymous said...

Hi

I like this post:

You create good material for community.

Please keep posting.

Let me introduce other material that may be good for net community.

Source: Nurse practitioner interview questions

Best rgs
Peter