Specman e 列出约束参考
我正在尝试执行以下操作:
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;
};
};
};
换句话说,我希望儿子列表指向父母列表的一部分,但仍然能够约束(不工作的部分)来自儿子单元/结构的孙子列表。
使用 9.20 上的 PGen 约束引擎,以上代码会生成:
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
使用 Specman 9.20 上的 IntelliGen 约束引擎,以上代码会生成:
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.
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.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我认为您存在生成顺序冲突:
grands.id
字段填充sons.grands
列表,这意味着您必须生成grands< /code> 首先列出。
grands.parent_age
取决于sons
parent_age == 70
约束,这意味着您必须生成sons
先列出来。解决这个代码问题的最简单、最直接的方法(我知道你给出了一个简单的例子)是:
经过更多测试,我很确定它是一个组合约束排序问题与方法调用。 Specman 生成器不会遵循
sons'
grand
列表约束上的约束,除非您在不执行方法调用的情况下设置这些指针。使用IntelliGen(不适用于 PGen ):
您可能需要考虑直接使用
pre_generate()/post_generate()
。您还可以查看 Cisco 开源的csco_config
软件包 (此处)。我们使用该包在我们的环境中进行奇怪的约束和约束传播。但是,大多数约束都是自上而下的,而您的示例似乎是关于同行互相修改的。另一份设计说明。 5 级列表相互约束是一个维护问题。理想情况下,每个级别最多只应了解其子列表和父列表。提供一个字段,然后将该字段向下传递到较低的级别,将使每个级别不必了解所有其他级别。然而,我知道违反设计准则是有原因的:-)
I think you have generation order conflicts:
sons.grands
list is populated, depending on thegrands.id
field, which means you have to generate thegrands
list first.grands.parent_age
depends on thesons
parent_age == 70
constraint, which means you have to generate thesons
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 :
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.Using IntelliGen ( doesn't work with PGen ):
You might have to look into using
pre_generate()/post_generate()
directly. You can also look into Cisco'scsco_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 :-)