specman e lists constraints references

Question

i am trying to do the following :

unit parent {
              sons: list of sons is instance;
              grands: list of grands is instance;

              keep sons.size() == 4;
              keep grands.size() == 4;
};

unit sons {
            grands:list of grands is instance;
            keep grands == get_enclosing_unit(parent).grands.all( .id > 3 );

           //this is not working
           keep for each in grands {
              it.parent_age == 70;
           };
};

unit grands {
           id: uint;
           parent_age:uint;
};

extend sys {
   p : parent is instance;
   run() is also {
      print p;
      for each (s) in p.sons {
         print s;
      };
      for each (g) in p.grands {
         print g;
      };

   };
};

in other words , i want the sons list to point to a part of the parents list , but still be able to constraint(the not working part) the list of grands from the sons unit/struct.

With PGen constraint engine on 9.20, the above code produces:

Starting the test ...
Running the test ...
  p = parent-@0: parent   e_path: sys.p
  hdl_path:
        ----------------------------------------------  @tmp
0       sons:                           (4 items)
1       grands:                         (4 items)
  s = sons-@1: sons   e_path: sys.p.sons[0]
  hdl_path:
        ----------------------------------------------  @tmp
0       grands:                         (empty)
  s = sons-@2: sons   e_path: sys.p.sons[1]
  hdl_path:
        ----------------------------------------------  @tmp
0       grands:                         (empty)
  s = sons-@3: sons   e_path: sys.p.sons[2]
  hdl_path:
        ----------------------------------------------  @tmp
0       grands:                         (empty)
  s = sons-@4: sons   e_path: sys.p.sons[3]
  hdl_path:
        ----------------------------------------------  @tmp
0       grands:                         (empty)
  g = grands-@5: grands   e_path: sys.p.grands[0]
  hdl_path:
        ----------------------------------------------  @tmp
0       id:                             4107502109
1       parent_age:                     3829340118
  g = grands-@6: grands   e_path: sys.p.grands[1]
  hdl_path:
        ----------------------------------------------  @tmp
0       id:                             3657005019
1       parent_age:                     2354335776
  g = grands-@7: grands   e_path: sys.p.grands[2]
  hdl_path:
        ----------------------------------------------  @tmp
0       id:                             3238917208
1       parent_age:                     336300761
  g = grands-@8: grands   e_path: sys.p.grands[3]
  hdl_path:
        ----------------------------------------------  @tmp
0       id:                             1416976666
1       parent_age:                     2212224392

With IntelliGen constraint engine on Specman 9.20, the above code produces:

Starting the test ...
Running the test ...
  p = parent-@0: parent   e_path: sys.p
  hdl_path:
        ----------------------------------------------  @tmp
0       sons:                           (4 items)
1       grands:                         (4 items)
  s = sons-@1: sons   e_path: sys.p.sons[0]
  hdl_path:
        ----------------------------------------------  @tmp
0       grands:                         (4 items)
  s = sons-@2: sons   e_path: sys.p.sons[1]
  hdl_path:
        ----------------------------------------------  @tmp
0       grands:                         (4 items)
  s = sons-@3: sons   e_path: sys.p.sons[2]
  hdl_path:
        ----------------------------------------------  @tmp
0       grands:                         (4 items)
  s = sons-@4: sons   e_path: sys.p.sons[3]
  hdl_path:
        ----------------------------------------------  @tmp
0       grands:                         (4 items)
  g = grands-@5: grands   e_path: sys.p.grands[0]
  hdl_path:
        ----------------------------------------------  @tmp
0       id:                             619055518
1       parent_age:                     4122406610
  g = grands-@6: grands   e_path: sys.p.grands[1]
  hdl_path:
        ----------------------------------------------  @tmp
0       id:                             2908565159
1       parent_age:                     1741309063
  g = grands-@7: grands   e_path: sys.p.grands[2]
  hdl_path:
        ----------------------------------------------  @tmp
0       id:                             3091108084
1       parent_age:                     1231835435
  g = grands-@8: grands   e_path: sys.p.grands[3]
  hdl_path:
        ----------------------------------------------  @tmp
0       id:                             1717477430
1       parent_age:                     937745175
No actual running requested.
Checking the test ...
Checking is complete - 0 DUT errors, 0 DUT warnings.

Answer 1

I think you have generation order conflicts:

• The sons.grands list is populated, depending on the grands.id field, which means you have to generate the grands list first.
• The grands.parent_age depends on the sons parent_age == 70 constraint, which means you have to generate the sons list first.

The easiest and most straight forward way to solve this code issue ( and I know you're giving a dumbed down example) is :

extend parent {
   keep for each (g) in grands {
      ( g.id > 3 ) => g.parent_age == 70;
   };
};

After more testing, I'm pretty certain its a constraint ordering issue in combination with the method invocations. The Specman generator doesn't follow through the constraints on the sons' grand list constraint, unless you set those pointers without doing a method call.

<'
unit parent {
   sons: list of sons is instance;     // <-- swapped these two lines
   grands: list of grands is instance; // <-- to do constraint ordering in IntelliGen
                                       //     even though Cadence says you don't need
                                       //     to
   keep for each (s) in sons {
      s.grands == grands; -- .all( .id > 3 ); -- removed the 'all' and 'get_enclosing_unit' invocation
   };

   keep sons.size() == 4;
   keep grands.size() == 4;
};

unit sons {
   grands:list of grands is instance;
   --keep grands == get_enclosing_unit(parent).grands.all( .id > 3 );

   //this is not working
   keep for each in grands {
      it.parent_age == 70;
   };
};       

unit grands {
   id: uint;
   parent_age:uint;
};

extend sys {
   p : parent is instance;
   run() is also {
      print p;
      for each (s) in p.sons {
         print s;
      };
      for each (g) in p.grands {
         print g;
      };
   };
};   
'>

Using IntelliGen ( doesn't work with PGen ):

Starting the test ...
Running the test ...
  p = parent-@0: parent   e_path: sys.p
  hdl_path:
        ----------------------------------------------  @tmp
0       sons:                           (4 items)
1       grands:                         (26 items)
  s = sons-@1: sons   e_path: sys.p.sons[0]
  hdl_path:
        ----------------------------------------------  @tmp
0       grands:                         (26 items)
  s = sons-@2: sons   e_path: sys.p.sons[1]
  hdl_path:
        ----------------------------------------------  @tmp
0       grands:                         (26 items)
  s = sons-@3: sons   e_path: sys.p.sons[2]
  hdl_path:
        ----------------------------------------------  @tmp
0       grands:                         (26 items)
  s = sons-@4: sons   e_path: sys.p.sons[3]
  hdl_path:
        ----------------------------------------------  @tmp
0       grands:                         (26 items)
  g = grands-@5: grands   e_path: sys.p.sons[3].grands[0]
  hdl_path:
        ----------------------------------------------  @tmp
0       id:                             4093923439
1       parent_age:                     70 
[snip]

You might have to look into using pre_generate()/post_generate() directly. You can also look into Cisco's csco_config package that they open sourced (here). We use that package to do weird constraints and constraint propagation in our environment. However, most constraints are top-down, whereas your example seems to be about peers modifying each other.

One other design note. 5 levels of lists constraining each other is a bit of a maintenance issue. Ideally, each level should only know about its child lists and its parent lists at the most. Providing a field and then rippling that field down into lower levels will insulate each level from having to know about all the other levels. However, I know there are reasons to violate design guidelines :-)