#301 Crash when trying to report from multiple databases

[Cary R.]

The following is a stack dump created when trying to generate a report from multiple databases.

0 0xffffe410 in __kernel_vsyscall ()

1 0x47cd37a5 in raise () from /lib/tls/libc.so.6

2 0x47cd5209 in abort () from /lib/tls/libc.so.6

3 0x47cccd91 in __assert_fail () from /lib/tls/libc.so.6

4 0x080add74 in statement_db_read (line=0xbfd25e34, curr_funit=0x81aa2a8, read_mode=4) at statement.c:463

5 0x080845d2 in funit_db_mod_merge (base=0x81aa2a8, file=0x813a018, same=FALSE) at func_unit.c:1061

6 0x0806edd1 in db_read (file=0x813a008 "all.cdd", read_mode=4) at db.c:607

7 0x080a5fd8 in command_report (argc=6, last_arg=1, argv=0xbfd2a644) at report.c:1118

8 0x080963eb in main (argc=6, argv=0xbfd2a644) at main.c:199

Any insight on how to proceed would be greatly appreciated.

[Trevor Williams]

Could you do the following in gdb?

frame 4
display ppline

This value will be the line number in the file that contains the statement causing the issue. Do the following to get the file:

display curr_funit->filename

This failure is a bit odd... Somehow a statement is not able to find the expression tree within the CDD file.

[Cary R.]

Frame 4 didn't work, but frame 5 gave me some results. frame 4 could not find ppline. I did not check to see if it had the file name information.

The code that is failing is the following.

always @(*)
case(mode) <----- This is the line number that is failing
2'b00: mode_i = md_map;
...

There is an assign statement just before this so it is not the first statement in the file.

This block is one of the ones where I'm merging results from a previous run.

Here's the hierarchy of the two calls since I think this could be relevant.

Bock test:

test_top include the block and instantiates it as dut. This run scorrectly.

test_top.v includes "sub_block.v"

Full logic:

test_top includes a chip representation that has the logic and models for the things it controls. The chip level file includes the logic top level and instantiates this as dut. The chip top level includes a block which then includes the actual sub block that is causing the problem.

test_top.v includes "chip_top.v"

chip_top.V includes "logic_top.v"

logic_top.v includes "block.v"

block.v includes "sub_block.v"

Let me know if there is anything else I can do to help track this down.

[Trevor Williams]

Cary,

I apologize for the long delay. I'm attempting to reproduce this problem, but so far am not having any success. Is there anything interesting about the module in question -- i.e., does it contain any generate blocks or is it parameterized?

Thanks,
Trevor

[Cary R.]

Not a problem. I have worked around this by removing the need for merging (test everything at the top level). Yes this is a parameterized module. It does not have any generate statements, but one of the modules that it includes does have a generate loop. Most of the sub-modules are also parameterized.