• 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. Gen5 list indexing, pop() on empty list

Stats

  • Locked Locked
  • Replies 4
  • Subscribers 64
  • Views 13826
  • 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

Gen5 list indexing, pop() on empty list

archive
archive over 17 years ago

Hello,

I encountered some strange error message from IntelliGen when I tried to constrain a field. Even though I know that these few lines cannot completely explain, they might give the right idea.

The user constrains tons of flags that are not checked and can result in invalid combinations. These flags are then condensed into a list of valid flags by a method that takes all flags as argument and returns a list of valid flag values.

error_list : list of bool;
error_list == get_valid_errors(value(user_flag1),value(user_flag2));


The valid length_error flag is then constrained by

keep length_error == value(error_list[some_index]);

based on this valid, confirmed and easy readable flag, the creation should be constrained

keep value(length_error) == TRUE => data_length > 1500; //doesn't really matter what you constrain on the right side

If I tell PGen the generation oder with, keep gen () before () everything works as intended. As IntelliGen ignores those statements, everything should be covered with the value() function for keeping the intended order. But somehow, that doesn't really work.

If I use

keep length_error == value(error_list)[some_index];

I get

List ist empty, cannot access item some_index

Using

keep length_error == value(error_list[some_index]);

results in

Cannot use peseudo-method 'pop()' on an empty list

BTW, that complete environment does NOT contain any pop() method, so it is an internal funtion that uses it. The same code runs fine in Pgen though. If I constrain length_error == TRUE and data_length == 1530, everything runs fine, no contradiction (of course, there shouldn't be any). Both ways of indexing work with PGen. None of them work with IntelliGen. Has anybody encountered that error message before?

greetings


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

    This sounds like you might have some contraint inconsistencies. I recommend running the ICFS linter (inconsistent connected field set), using gen lint -i. This is something wil is recommended to do in general, before you start generating anything. Please also have a look in the user guide which exaplins ICFSs in detail and how to resolve them.

    If you are still experiencing issues, I'd recommend to get the latest version of IntelliGen. We released a hotfix version of SPMN6.2 (SPMN06.20.002-s) at the end of November.

    Regards,
    -hannes


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

    Hello Hannes,

    I was already running 002-s and now resolved the error. I had to heavily convert constraints from bidirectional to unidirectional to get it working. (Now Pgen stopped working though)

    I stopped paying attention to icfs in the past because I was not able to write sequences not producing icfs but still working with pgen.
    atm I'm trying to implement ifdefs to keep some constraints made for pgen out of igen and vice versa. Is there any variable I can use for checking which generator is currently being used?

    greetings


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

    With sufficiently number and complexity of constraints we have found it very difficult to maintain
    backward compatibility to PGen. What we recommend is to use ifdefs, as you mentioned. There
    isn't a define for the generator, since the generator is set using a configuration option/command.
    You could use the SPECMAN_VERSION_nn_nn_OR_LATER define if you want (i.e.
    #ifdef SPECMAN_VERSION_06_20
    // IGen constraints
    #else
    // PGen constraints

    regards,
    -hannes


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

    Using the Specman Version as decision is not really a solution for me, as my colleagues use the eVC with the same Specman Version I un and they need to use Pgen. We're still waiting for AHB to get ready for Gen5, so till then I have to keep it compatible for both.

    greetings


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

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