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.

Less known and less used Specman commands

There are quite a few Specman commands which are handy when it comes to debugging. Here I tried to summarize few less known but useful Specman commands. Here we go.

1. If you have verification environment loaded on Specman and one method is extended in multiple files and you want to see all the extension of that method in a single place, "collect" command is what you are looking for.

Specman> collect sys.mystruct.monitor
Specman> collect sys.run


File temp.erld - created by collecting:
sys.run (after module specman)
<'
----------------------- Reset sys.run:
extend sys {
run(
) is as was after specman;
};
----------------------- From temp.e at line 6:
extend sys {
run() is also
{
var x : mystruct_s;
gen x;
};
};
----------------------- End of sys.run
'>



If you want to debug temporal expression, you would like to visualise how different events are triggered. Event chart is basic but sometimes useful for debugging temporal expressions. To see the events you first have to collect events you are interested in by using "collect events" Specman command.

Specman> collect events *.*
Specman> collect events sys.mystruct.* //collects all events for the instance sys.mystruct
Specman> collect events mystruct_s.* //collects all the events of struct mystruct_s


If you want to see the events triggered during simulation, you can use Specman command "show events" after collecting the events as mentioned above.

Specman> show events
Specman> show events 100 //This command shows events since time 100
Specman> show events 100..150 //This command shows events in the time range 100..150
Specman> show events -chart //Pops up event chart


If you want to have a summarized report about the events count, if it is associated with cover group, its source etc, you can use "show events def" command.

Specman> show events def sys.any

count echo col covr name source
------------------------------------------------------------------
0 10000 FALSE TRUE FALSE sys.any @sn_te_tick


Executing actions on command line. You can define variables or call methods or start a TCMs. (you can not call a TCM on command line). Remember, you can not give "gen" action on command line, but you can call a method which has gen action in it.

Specman> var x : uint(bits: 4) = 5;
Specman> var y : uint = x + 10;
Specman> print x + y;
Specman> sys.non_tcm()
Specman> start sys.tcm()
Specman> sys.non_tcm_with_arg(4, TRUE)


You can search/grep within the loaded files using "search" command

Specman> search mystruct_s


You can open a file (known as "module" in Specman terms) in source browser by using "source" command. It will open a source browser with that perticular line number into focus.

syntax: source

Specman> source mystruct.e 50


You can run unix commands using "shell" command.

syntax: shell

Specman> shell echo $SPECMAN_PATH
Specman> shell pwd


You can also get the value of define by issuing "show define" command.

syntax: show define [-v] [-e]

Specman> show define -v "*WIDTH*"


If you want to know what are the modules that are loaded you can use "show modules" command.

Specman> show modules


You can get unix environment variables value within your e code by using get_symbol() method.


my_method() is
{
outf ("SPECMAN_PATH=%s",get_symbol("SPECMAN_PATH"));
};


12. If you wish to execute specman command in e code, then you can use specman() method as shown below.


pre_generate() is
{
specman("break on error");
};


If you wish to execute unix command from your e code, you can use output_from() method.


my_method() is
{
var list_of_files: string;
list_of_files = output_from("ls");
print list_of_files;
};


If you want to uderstand port binding in Specman, use "show ports" command.


You can use "trace bind' to follow the binding process


If you have executed a set of commands and want to see the history of executed commands, you can use "show redo" command.

Specman> show redo
show redo
The redo buffer (default is 'redo 0..') =
0. "restore specman.esv"
1. "load temp.e"
2. "test"
3. "clear screen; restore; reload; test"


Once you know the hisotry of executed command, you can reexecute them by issueing "redo" Specman command.

Specman> redo 3 //this will execute command 3 (clear screen; restore; reload; test)
Specman> redo 0..2 //this will execute command 0 to 2 (restore specman.esv, load temp.e, test)


If you have wave command executed to view e fields into waveform and want to dump all these wave tracing commands into a file, you can use "write wave" command.

syntax: write wave to

Specman> write wave to trace_wave.ecom

19. To debug, packing and unpacking, you can use "show pack" and "show unpack" command as shown below.


Specman> var x : uint (bits: 3) = 3
Specman> var y : uint (bits: 7) = 5
Specman> show pack(packing.low, x, y);

|9 8 7 6 5 4 3|2 1 0| +0
+-------------+-----|
|0 0 0 0 1 0 1|0 1 1|
+-------------+-----|
|y |x |

Specman> var x : packet_s
Specman> var data : list of bit = {1;1;0;1;0;0;0;1;1;1;0;1}
Specman> show unpack(packing.low, data, x)

|1 0 9 8 7 6 5 4|3 2 1 0| +0
+---------------+-------|
|1 0 1 1 1 0 0 0|1 0 1 1|
+---------------+-------|
|x.addr |x.len |

Debugging packing and unpacking in Specman

Hello readers, I am back after a loooooong break. It has been quite a some time since I posted something here as I was too busy with my personal life and responsibilities. I try to be regular now. So with this note, let me start something from today itself.

While using packing/unpacking in your environment, you might have gone through some debugging troubles due to silly mistakes. So here are few tips to avoid errors for packing and unpacking.
So starting with Unpacking, there can be 2 kind of problems you may face while unpacking a list into struct

• You run out of data while unpacking (i.e. list is shorter than total length of physical fields of a struct)
• Unpacking is finished but you have bits/bytes left over (i.e. list is bigger than total length of physical fields of struct)

If you have situation 1, it will be flagged as run-time error by Specman. But, if you have situation 2, you might not even aware of it as Specman does not issue even a warning for this. For situation 1, if you want to suppress run-time error, you can use 'try' action.

tcm() @clk is {

try {

unpack(packing.low, my_list, my_struct);

} else {

message (LOW, "Unpacking failed");

};

};

To debug packing/unpacking issues, you can use Specman command 'trace packing'. It shows how packing/unpacking is performed. Following example shows the result of 'trace packing' command performed for unpacking.

Following example shows the result of 'trace packing' command performed for packing

If unpacking is unsuccessful (ran out of data in the list), you normally get following message on Specman STDOUT.

*** Error: Ran out of data while trying to unpack (use 'trace packing' for further details)
at line 19 in @packing_unpacking_debug
unpack(packing.low, lob_u, x);

But if you use 'trace packing' Specman command, you see where unpacking stopped.

> ----- Starting an unpack() at line 19 in @packing_unpacking_debug ----

> ----------- Unpacking 'x': x_s
> Unpacking 'x.a': uint (bits: 4)
8 .0
> 'x.a': uint (bits: 4) = 8
> Unpacking 'x.b': uint (bits: 8)
0 5 .0
> 'x.b': uint (bits: 8) = 5
> Unpacking 'x.c': list of byte
*** Error: Ran out of data while trying to unpack into 'x.c'
at line 19 in @packing_unpacking_debug
unpack(packing.low, lob_u, x);

One of the very common cause of the unpacking failure is the unsized list. If the target struct has unsized list as a physical field, all the bits/bytes of the source list will be absorbed by this unsized list and there will be no data left for the next physical field and Specaman will issue an error. So it is always advisable not to have unsized list in the target struct.

Another reason for unpacking failure could be subtype physical fields. If you have few physical fields defined under 'when' subtype of a struct, your need to make sure which subtype to pick while unpacking.

One more reason for the unpacking to give errorneous result is the order of the physical fields in a struct. If physical fields of a struct is defined in the multiple files, then import order of that file becomes crucial because based on the order, physical fields will be treated differently during unpacking. Take a look at the following example.