Specman Linting and the all_unique Method

Sorting according to pointers- why?

One of the best practices that you need to follow when using Specman or any other tool is to use a linting tool on a regular basis to catch bugs early. In Specman, we frequently add additional e checks to HAL (Cadence linting tool) based on the customer issues that can be avoided or caught during linting.

For instance, in 19.03, among few other linting checks, we planned to add a check that alerts the user when the list pseudo method sort is performed according to pointers. This can happen when for example you have a list of structs and you sort according to the list items (which means sorting according to their pointers) instead of each item’s field as shown in the given example:

struct transfer{
 …
};
var myTransfers: list of transfer;
 …
 myTransfers.sort(it);

This linting check was planned following a case in which one of our users wrote “it” as the parameter to sort instead of “it.address”. In this case, it took the customer a while to find the issue, and so, we decided to add a linting check to make it easier to catch such bugs.

At the beginning we assumed that this sorting according to pointers was not the actual intention, as the results may vary in different runs. However, after talking to some customers, we found a situation in which this was indeed the user intention. This involves the unique list pseudo method.

The unique pseudo method

The list pseudo method unique unifies identical items in a list into one so each item in the list is unique but only for consecutive items. This means that if I have a list with the following values and I call the unique method:

var myList: list of int = {3;6;3;5;5;6;6;6;8;5};

var uniqueList: list of int;

uniqueList=myList.unique(it);

print uniqueList;

This is the output:

uniqueList =

1. 3
2. 6
3. 3
4. 5
5. 6
6. 8
7. 5

As you can see, only the consecutive items were united. Therefore, to have my list being unique, I should have first called the sort method to make sure all identical items are next to one another as shown in the following example:

var myList: list of int = {3;6;3;5;5;6;6;6;8;5};

var uniqueList: list of int;

uniqueList=myList.sort(it).unique(it);

print uniqueList;

This is the output:

uniqueList =

1. 3
2. 5
3. 6
4. 8

Now, I really have a list with unique items. If I have a list of structs and I just want to ensure I do not have two identical actual structs then, yes, I had a legit reason to call the sort method according to pointers.

The new all_unique pseudo method

This made us think that it is time we provide a unique method which also supports non-consecutive items so that it is not needed to call the sort method first (regardless if it relates to pointers or not). It is better from the performance perspective and now we can add the linting check in HAL regarding sorting according to pointers since there is no justification to do it anymore. Therefore, unique method stays as is, however, in 19.03 we introduced an additional pseudo-method called all_unique. To better understand all_unique, let’s consider the following example:

var myList: list of int = {3;6;3;5;5;6;6;6;8;5};

var uniqueList: list of int;

uniqueList=myList.all_unique(it);

print uniqueList;

This is the output:

uniqueList =

1. 3
2. 6
3. 5
4. 8

Note that we did not sort the list first so 6 is before 5 as it was in the original list.

However, what if my list is already sorted anyway and now I want to make sure that all items are unique, which pseudo method should I call? In this specific case, it is advised to call unique rather than all_unique since the performance will be better.

The HAL check for sorting according to pointers

Now, we could add the lint check we wanted initially. In the following example we have a list of packets that we sort according to the list item (it) which is a struct, so basically, we sort it according to pointers. When I run HAL (from 19.03) on this code, I now get the following new error:

The HAL check for calling sort and unique for non-pointers

However now for cases in which sort is called before uniquefor non-pointers, we want to suggest replacing it with this new pseudo method: all_unique so the performance is better, and the code is clearer. Therefore, in 19.03, HAL will display the given note for the following code:

var myList: list of int = {3;6;3;5;5;6;6;6;8;5};

var uniqueList: list of int;

uniqueList=myList.sort(it).unique(it);

 To sum it up, we have few points:

1. If you do not use HAL or any other linting tool, it is about time that you start using it.
2. If you are used to calling sort before you call unique, you can now call all_unique instead.
3. If your list is already sorted and you want to make it unique, call unique for best performance.
4. If you have your own linting tool, add the following checks:
   1. Warn in case sort is activated according to pointers
   2. Detect the cases in which sort is called before unique and suggest replacing it with all_unique

Orit Kirshenberg

Specman team