• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Functional Verification
  3. Contradiction only without collect gen

Stats

  • Locked Locked
  • Replies 7
  • Subscribers 64
  • Views 15054
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Contradiction only without collect gen

archive
archive over 17 years ago

Helle there,

I'm currently having a hard time figuring out some odd behaviour.

when I run a test in a certain configuration, specman throws a contradiction and request a rerun with collect gen. When running with collect gen on, the whole test runs flawlessly as it should.

I'm fresh out of ideas after battling the for some time now. The irritating thing is:

when I constrain a struct in two bool flags as true, a method randomly picks one and resets it. 

If I manually reset all of them in the function, everything works as well.
Having both on true also works out fine.

resetting one of them in the method with the code below breaks a list somewhere in a completely different struct of the environment with a contradiction I cannot see. So using the "random resetter" I coded below, Specman goes nuts.

while list_of_desired_errors.count(it == TRUE) > 1
{
    message(FULL,"list_of_desired_errors.size() is still > 1, randomly resetting desired errors");
    var tmp_err_index_list : list of uint;
    tmp_err_index_list.clear();
    for each (err) using index (i) in list_of_desired_errors
    { 
        if err == TRUE
        { 
            tmp_err_index_list.add(i); 
        }; 
    };
    message(FULL,"tmp_err_index_list is: ",tmp_err_index_list);
    var t_uint : uint;
    message(FULL,"t_uint before random assignment is ",t_uint);
    gen t_uint keeping { it in tmp_err_index_list; };
    message(FULL,"t_uint after random assignment is ",t_uint);
    list_of_desired_errors[t_uint] = FALSE;
    message(FULL, "SINGLE_FRAME_ERR resetting error index ",t_uint); };
};

Ideas, anyone?

regards


Originally posted in cdnusers.org by SomeDude
  • Cancel
Parents
  • archive
    archive over 17 years ago

    thx for your reply!

    I'll try to clarify a bit more. The frame is driven over different interfaces and has various formats. Depending on those interfaces and formats, some errors are valid and some are not. As the testwriters want it very easy, they constrain for example three errors to true and all the others to false. Additionally they set the error_mode to single_error (as opposed to no_error and multi_error). So the model has to check if the picked errors are even possible, if not it resets them. The remaining errors are randomly reset resulting in only one set error flag. So much for directed testing.

    In random unconstrained mode all flags are completely randomly generated. Then again, the impossible ones will be reset and the remaining possible flags considered. In multi-error-mode at least 2 random/valid flags will be set, in single-err-mode at least one will be set and if more than one are set, they will randomly be reset.

    The reason to jump through all these hoops is the goal to get the most possible random distribution of errors depending on interface and frame_type.

    The generator based approach works fine if the test writer knows what the interface and/or frame_type can do. Unfortunatley I cannot rely on that. You how how it works: As soon as the eVC throws a constraint-contradiction it's not the user's but the eVC's fault. :/

    I'm still waiting for Spm 6.20.003 to be installed, it's moving up in the admin's pipeline. IF the problem still shows in the newer version, I will file a bug report. Till then, the ugly (Option 2), but working version has not failed me once over hundreds of frames. I presume it's a false memory handling that influences something it shouldn't influence. But that's pure speculation, unfortunately Specman is not Open-Source or we could debug all the way. The fact that is works flawlessly in Collect-Gen Mode is indicator enough that it might be a tool problem.

    by the way, the code tags here suck whole lemons. If one could edit own posts, one could post by try and error, but it really discourages posting code snippets.

    Will keep you updated


    Originally posted in cdnusers.org by SomeDude
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • archive
    archive over 17 years ago

    thx for your reply!

    I'll try to clarify a bit more. The frame is driven over different interfaces and has various formats. Depending on those interfaces and formats, some errors are valid and some are not. As the testwriters want it very easy, they constrain for example three errors to true and all the others to false. Additionally they set the error_mode to single_error (as opposed to no_error and multi_error). So the model has to check if the picked errors are even possible, if not it resets them. The remaining errors are randomly reset resulting in only one set error flag. So much for directed testing.

    In random unconstrained mode all flags are completely randomly generated. Then again, the impossible ones will be reset and the remaining possible flags considered. In multi-error-mode at least 2 random/valid flags will be set, in single-err-mode at least one will be set and if more than one are set, they will randomly be reset.

    The reason to jump through all these hoops is the goal to get the most possible random distribution of errors depending on interface and frame_type.

    The generator based approach works fine if the test writer knows what the interface and/or frame_type can do. Unfortunatley I cannot rely on that. You how how it works: As soon as the eVC throws a constraint-contradiction it's not the user's but the eVC's fault. :/

    I'm still waiting for Spm 6.20.003 to be installed, it's moving up in the admin's pipeline. IF the problem still shows in the newer version, I will file a bug report. Till then, the ugly (Option 2), but working version has not failed me once over hundreds of frames. I presume it's a false memory handling that influences something it shouldn't influence. But that's pure speculation, unfortunately Specman is not Open-Source or we could debug all the way. The fact that is works flawlessly in Collect-Gen Mode is indicator enough that it might be a tool problem.

    by the way, the code tags here suck whole lemons. If one could edit own posts, one could post by try and error, but it really discourages posting code snippets.

    Will keep you updated


    Originally posted in cdnusers.org by SomeDude
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information