lnternal error / Elaboration error ius81

Hi,

It is difficult to ascertain the cause of this problem.  My suggestion would be to open a service request with our support team (support@cadence.com) to determine and help with the problem.

Best regards,
Mickey

 But how do i contact cadence support, since we are using university/academic license?

Mickey said:

Hi,

It is difficult to ascertain the cause of this problem.  My suggestion would be to open a service request with our support team (support@cadence.com) to determine and help with the problem.

Best regards,
Mickey

Hi Eder,

Please send me the complete testcase you are using when getting the issue and I will follow up on it. 

Best regards,
Mickey

Hi Eder,

Please send me the complete testcase you are using when getting the issue and I will follow up on it.  You can send it to my email address (jrodrig@cadence.com)

Best regards,
Mickey

 Hi Eder/Mickey,

I am having just the same error. Have you figured out why it is happening with you?

I guess, in my case, it is because of coverage-related command-line arguments, but I cannot put my hands on the real problem.

I appreciate if you can help.

Thanks,

Ahmed

Hi Ahmed.

Are you linking any other tools or C code into the simulation? Whenever I have seen a crash coming in ncelab, if it's triggered by the addition of the coverage options, I start by looking for incompatible *.so files being linked. Probably 95% of the time it's caused by linking some C code that was compiled in an incompatible GCC version.

Since IUS 8.1 came out, the simulator has been compiled with GCC 4.1, so if you try to link any C code or 3rd party tools, these must also have been compiled with GCC 4.1.

Hope this helps.

Steve.

 Many thanks, Steve, for your reply.

I am not linking any C code into simulation

The problem seems to have been due to incorrect specification of the -covdut and -covfile options. In the .ccf files passed to the -covfile switches, I was passing the modules on which coverage is to be collected in the select_coverage command. In addition to this, I was mistakenly passing the top-level module to the -covdut switch (a leftover from initial script writing), and this probably offends elaboration.

I removed the -covdut switch (as being unncessary)  and everything is working just fine now.

Does this make any sense?

Regards,

Ahmed

Cairo, Egypt

Thanks Ahmed for the explanation.

I will mention that to R&D, as it shouldn't be causing a crash!

Steve.

I've seen an earlier report with this bug code: gq_cab_to_tab - not a CAB. It seemed to have been caused by a "real" datatype being passed in a coverpoint. Later versions of the elaborator correctly identified the cause and printed an error message pointing to the offending covergoup. I guess changing the scope of the modules that you instrument for coverage helps you avoid the problem. If you can use the later version of the software, I think you'd be better off.

Hi TAM1,

I encountered the same problem again when the instrumented modules have been changed. I couldn't understand what you mean by this statement:

TAM1 said:

I guess changing the scope of the modules that you instrument for coverage helps you avoid the problem.

Is there a specific (hierarchical) relationship between instrumented modules that must be honored in order not to get this error? I am only aware of the rule that a module must have a single top-level instance in the design and this is obeyed in my case.

Actually, I am working on an in-house coverage-driven verification flow and I want to relieve the user from having to watch for such subtelties and bugs. I want to conceal them in my scripts.

Thanks,

Ahmed