Contradiction only without collect gen

oh darn, I'm sorry for the screwed up layout. I swear it looked fine before...

Originally posted in cdnusers.org by SomeDude

By any chance are you running the new "intelligent gen"? If so try using the time tested, golden old generator. This might be a new issue with the relatively new generator architecture. In any case, contact CDN support.

HTH
Ajeetha, CVC
www.noveldv.com

Originally posted in cdnusers.org by ajeetha

Hi SomeDude,

Ajeetha has a good question about which generation technology you are using and it is one that I have as well for you before I can offer you more advanced assistance. Are you using the current default generator (Pgen) or the new generator (IntelliGen)? If you are unsure, you can always type the command "show config gen" to see the results.

One thing I would like to mention is that IntelliGen has been used on many customer projects successfully over the past year empowering customers with increased ease of use, solvability and performance. The ease of use features including improved contradiction handling and the new Generation Debugger GUI have proved very useful for many customers.

I did take your example code and ran it however, I did not see any contradiction however, there may be other portions of your environment that are contributing to the contradiction. Could you clarify the below statement:

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

Did you mean when you constrain two bool flags in a struct to be TRUE?

Some other techniques for assistance with debug:
-> (Pgen) Use the "show constraints" command to list all constraints acting on the field causing the contradiction
-> (Pgen) Place a call to "specman("collect gen");" in procedural code (perhaps in a pre/post_generate() extension) at or near where the contradiction occurs rather than run with it on from the beginning of the simulation as this will localize the collection of generation information.
-> (Pgen or IntelliGen) The "trace gen" command will output generator solving steps to the screen to assist in debug
-> (IntelliGen) You can set a general breakpoint at or near where the contradiction occurs and then step into the generation results using the new Generation Debugger GUI by issuing the "gtree" command (there is no need for issuing a "collect gen" command in IntelliGen)

I hope this helps. If you can replicate the issue you are seeing in a smaller testcase, please repost here however, I would also follow Ajeetha's suggestion and start a support request in parallel with the Cadence support team.

regards,
Corey

Originally posted in cdnusers.org by cgoss

ok, sorry for the lack of info.

first, I'm using Pgen, IntelliGen cannot be used because of other eVC Incompatibility.

Second, what the code does is for the following scenario.

I want to generate a frame with a single valid error. Since up to 7 are theoretically possible, I do not constrain them at all and let Specman decide which to are true to begin with. As long as there is more than than one true flag, specman will reset one random set flag after another by generating t_uint out of the list in which the indices of the true flags are stored. And exactly that seems to be the problem. I recoded it in a different (read ugly) way and now it doesn't break the generation of the other field anymore.

this is the complete code snippet

while list_of_desired_errors.count(it == TRUE) > 1
{
    message(FULL,"list_of_desired_errors.count(it == TRUE) 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);

    --Option 1, NOT WORKING!!!!! 
--    var t_uint_reset_to_single : uint; 
--    message(FULL,"t_uint_reset_to_single before random assignment is ",t_uint_reset_to_single);
--    gen t_uint_reset_to_single keeping { it in tmp_err_index_list; };
--    message(FULL,"t_uint after random assignment is ",t_uint_reset_to_single);
--    list_of_desired_errors[t_uint_reset_to_single] = FALSE;
    --Option 1, NOT WORKING!!!!!

    --Option 2 working, but ugly
    var t_uint_reset_to_single : uint;
    repeat
    {
        message(FULL,"generating new t_uint_reset_to_single");
        message(FULL,"read_only(list_of_desired_errors.size() is: ",list_of_desired_errors.size());
        gen t_uint_reset_to_single keeping
        {
              soft it >= 0 and soft it < read_only(list_of_desired_errors.size())
        };
        message(FULL,"t_uint_reset_to_single was generated to ",t_uint_reset_to_single);
    } until list_of_desired_errors[t_uint_reset_to_single] == TRUE;
    message(FULL, "SINGLE_FRAME_ERR resetting error index ",t_uint_reset_to_single); 
    list_of_desired_errors[t_uint_reset_to_single] = FALSE;
};

It's working properly now, hundreds of frames without any contradiction. So it seems to be the "keeping in a list" that breaks Specman. But before I file a bug report, I want to try it in Specman 6.20.003. Since I have to wait till our admin finds some time installing it, that will take a few days though.

Regards

Originally posted in cdnusers.org by SomeDude

Hi SomeDude,

Thanks for clarifying what you are seeing. Do you see a contradiction in the code example that you have displayed? I have tried to replicate a contradiction on my side using SPMN 6.2-s003 using several hundres seeds however, I could not (I limited the list_of_desired_errors size to 7 and had to wrap some context around your example).

I am not sure if you have code that processes each of these errors as you reset the bools however, I am curious as to why you would use a procedural loop to perform this task considering that similar functionality can be implemented using pure generation. Consider the example below:

<'
extend sys {

// testwriter can constrain the error location
error_location: uint;
keep soft error_location in range [0..6];

// testwriter can constrain whether frames are errored or not
errored_frame: bool;

list_of_desired_errors[7]: list of bool;

keep for each in list_of_desired_errors {
soft it == FALSE; // default no errors
}; // keep for each i...

// if frame is to be errored, pick a single random error location
keep errored_frame => list_of_desired_errors[error_location] == TRUE;

}; // extend sys

'>

As coded above, we are only targeting one location however I have coded random error generation schemes many times in the past that inserts any number of faults in any number of locations, allowing complete control to the testwriter to constrain the behaviour from the testcase.

Would something like this work in your situation?

regards,
Corey

Originally posted in cdnusers.org by cgoss

Let me try to post that code example again:

<' extend sys { // testwriter can constrain the error location error_location: uint; keep error_location in range [0..6]; // testwriter can constrain whether frames are errored or not errored_frame: bool; list_of_desired_errors[7]: list of bool; keep for each in list_of_desired_errors { soft it == FALSE; }; // keep for each i... // if frame is to be errored, pick a single random error location keep errored_frame => list_of_desired_errors[error_location] == TRUE; // This code is simply to print the results out to the screen and NOT used to // generate the errors run() is also { print errored_frame; if (errored_frame) then { print error_location; print list_of_desired_errors; }; // if (errored_fra... }; // run() is also }; // extend sys '>

Hope it helps!

Originally posted in cdnusers.org by cgoss

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