Crave variables not randomize by default ?

[hvdschoot]

Hi,

I now have Crave integrated and working in my "elaborate" UVM-SC testbench. Crave variables are being randomized subject to the Crave constraints I put in place - using the experimental API as advised - when invoking randomize(), as one would expect. It is still early going for me and I'd like to do quite a bit more exploration with using

• more complex constraints
• layered constraints (i.e. hierarchical across "has-a" class object relationships)
• overriding constraints (i.e. across "is-a" class object relationships)
• using crave vectors, arrays
• etc.

Two issues I am finding thus far I would like to report here:

1. Crave vectors: using a crave vector yields an internal error, which has since been reproduced and confirmed by Thilo. I have pasted the error down belo for completeness

2. Crave variables are only randomized when there are explicit active constraints on them, meaning constraints that I have coded. In other words, a crave variable that is not subject to a written constraint does not get randomized at all and instead holds its initial/current value. This is surprising and not aligned with the behavior of SystemVerilog rand variables, where each rand variable gets randomized by default within its type domain. Is this a bug or a Crave "feature"? That is, is this intended behavior?
   If it were then this would not set the stage well for a constrained random approach towards targeting coverage closure where stimulus attributes are minimally constrained early on - letting the power of randomness as loose as possible - until remaining coverage holes need be targeted in a more directed manner with increasing constraints.

Regards - Hans

[cmd.00c4 5m:19s] In file included from /local_vol1_nobackup/user/hvdschoot/projects/vcn5_0_5342109/out.er/linux_3.10.0_64/common/pub/crave/include/crave/backend/../ir/visitor/metaSMTNodeVisitor.hpp:37:0,
[cmd.00c4 5m:19s] from /local_vol1_nobackup/user/hvdschoot/projects/vcn5_0_5342109/out.er/linux_3.10.0_64/common/pub/crave/include/crave/backend/FactoryMetaSMT.hpp:31,
[cmd.00c4 5m:19s] from /local_vol1_nobackup/user/hvdschoot/projects/vcn5_0_5342109/out.er/linux_3.10.0_64/common/pub/crave/include/crave/backend/VariableSolver.hpp:35,
[cmd.00c4 5m:19s] from /local_vol1_nobackup/user/hvdschoot/projects/vcn5_0_5342109/out.er/linux_3.10.0_64/common/pub/crave/include/crave/backend/VariableGenerator.hpp:30,
[cmd.00c4 5m:19s] from /local_vol1_nobackup/user/hvdschoot/projects/vcn5_0_5342109/out.er/linux_3.10.0_64/common/pub/crave/include/crave/backend/Generator.hpp:33,
[cmd.00c4 5m:19s] from /local_vol1_nobackup/user/hvdschoot/projects/vcn5_0_5342109/out.er/linux_3.10.0_64/common/pub/crave/include/crave/ConstrainedRandom.hpp:36,
[cmd.00c4 5m:19s] from /local_vol1_nobackup/user/hvdschoot/projects/vcn5_0_5342109/out.er/linux_3.10.0_64/common/pub/include/vcn_uvmf/sc/src/vcn_test.h:52,
[cmd.00c4 5m:19s] from /local_vol1_nobackup/user/hvdschoot/projects/vcn5_0_5342109/out.er/linux_3.10.0_64/common/pub/include/vcn_uvmf/sc/vcn_uvmf:37,
[cmd.00c4 5m:19s] from /local_vol1_nobackup/user/hvdschoot/projects/vcn5_0_5342109/vidcore/cdefe/src/verif/uvmf_sc_tb_package/ltb/sc_main.cpp:30:
[cmd.00c4 5m:19s] /local_vol1_nobackup/user/hvdschoot/projects/vcn5_0_5342109/out.er/linux_3.10.0_64/common/pub/crave/include/crave/backend/../ir/visitor/../../frontend/RandomBase.hpp: In instantiation of 'void crave::__rand_vec_base1<T1, T2>::gen_values(unsigned int) [with T1 = sc_dt::sc_uint<64>; T2 = sc_dt::sc_uint<64>]':
[cmd.00c4 5m:19s] /local_vol1_nobackup/user/hvdschoot/projects/vcn5_0_5342109/vidcore/cdefe/src/verif/uvmf_sc_tb_package/ltb/sc_main.cpp:465:1: required from here
[cmd.00c4 5m:19s] /local_vol1_nobackup/user/hvdschoot/projects/vcn5_0_5342109/out.er/linux_3.10.0_64/common/pub/crave/include/crave/backend/../ir/visitor/../../frontend/RandomBase.hpp:163:28: error: 'crave::randv<sc_dt::sc_uint<64> > r' has incomplete type
[cmd.00c4 5m:19s] static randv r(NULL);

[SchulzSt]

VWG: @voertler will send out a pull request.

[hvdschoot]

Hi guys,
I may just get up in a few hours to attend the "very early" meeting this week, in particular becuase I have spent some time on using Crave including testing of the uniform distribution fix etc., but in case I won't make it after all, this is to let you know that I have tested the uniform distribution fix, and see it behaving favorably in that I now get random values for variables even when there are no constraints on such variable. That said, I do still run into quite some issues overall, with constraints not working, or not being solved, and other peculiar things, too convoluted to list here. THe worst is, getting a segmentation fault during the solver process appears more the rule than the exception. Anyway, I will leave it at this for now, and provide more details verbally in the meeting, and/or respond on the github page in response to my action item.

[voertler]

@hvdschoot Sorry not for replying earlier. Is there any way to get a stripped down example with regard to the segmenation fault?And does it only occur with the mentioned pull pequest for uniform distribution?

[hvdschoot]

Hi Thilo, No, the seg faulting also happened with the earlier Crave version. It’s a frequent occurrence and I only hope it’s always because of the same or similar underlying reason. And no, it won’t be so easy to get a stripped down version, not without significant labour and especially, somewhat of an understanding as to what may be at issue in my transaction model. Or else I’d be blind in knowing what exactly to replicate. I strongly suggest that you or someone first looks with me at my Crave code together and discuss my observations. Doing this with someone who better knows what should work and what would not may yield quicker clues as to what’s going on. I’ve been playing with this for the past couple of weeks and based on that experience I’m not so optimistic anymore about the tool’s current capabilities (especially in comparison to what I can do with SV). Hopefully it is largely me trying to do things perhaps too declaratively which is powerful in modeling but may tax the current state of the solvers too quickly. Will you be attending the WG meeting tonight? If so I may just get up for it. Hans

On Tue, Feb 21, 2023 at 10:28 PM Thilo Vörtler ***@***.***> wrote: @hvdschoot <https://github.com/hvdschoot> Sorry not for replying earlier. Is there any way to get a stripped down example with regard to the segmenation fault?And does it only occur with the mentioned pull pequest for uniform distribution? — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABILSUOFUR6YU5HMPTBUPV3WYWBVRANCNFSM5S4NZARA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Sent from Gmail Mobile

[voertler]

I think this issue can be closed