verification - specman e lists constraints references -

i trying following :

unit parent {               sons: list of sons instance;               grands: list of grands instance;                keep sons.size() == 4;               keep grands.size() == 4; };  unit sons {             grands:list of grands instance;             keep grands == get_enclosing_unit(parent).grands.all( .id > 3 );             //this not working            keep each in grands {               it.parent_age == 70;            }; };  unit grands {            id: uint;            parent_age:uint; };  extend sys {    p : parent instance;    run() {       print p;       each (s) in p.sons {          print s;       };       each (g) in p.grands {          print g;       };     }; }; 

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

with pgen constraint engine on 9.20, above code produces:

starting test ... running 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, above code produces:

starting test ... running 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 test ... checking complete - 0 dut errors, 0 dut warnings. 

i think have generation order conflicts:

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

the easiest , straight forward way solve this code issue ( , know you're giving dumbed down example) :

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

after more testing, i'm pretty constraint ordering issue in combination method invocations. specman generator doesn't follow through constraints on sons' grand list constraint, unless set pointers without doing method call.

<' unit parent {    sons: list of sons instance;     // <-- swapped these 2 lines    grands: list of grands instance; // <-- constraint ordering in intelligen                                        //     though cadence says don't need                                        //        keep each (s) in sons {       s.grands == grands; -- .all( .id > 3 ); -- removed 'all' , 'get_enclosing_unit' invocation    };     keep sons.size() == 4;    keep grands.size() == 4; };  unit sons {    grands:list of grands instance;    --keep grands == get_enclosing_unit(parent).grands.all( .id > 3 );     //this not working    keep each in grands {       it.parent_age == 70;    }; };         unit grands {    id: uint;    parent_age:uint; };  extend sys {    p : parent instance;    run() {       print p;       each (s) in p.sons {          print s;       };       each (g) in p.grands {          print g;       };    }; };    '> 

using intelligen ( doesn't work pgen ):

starting test ... running 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 using pre_generate()/post_generate() directly. can cisco's csco_config package open sourced (here). use package weird constraints , constraint propagation in our environment. however, constraints top-down, whereas example seems peers modifying each other.

one other design note. 5 levels of lists constraining each other bit of maintenance issue. ideally, each level should know child lists , parent lists @ most. providing field , rippling field down lower levels insulate each level having know other levels. however, know there reasons violate design guidelines :-)