Re: [Iverilog-devel] Assertion failure for system verilog structs

[Martin W. <mai...@ma...>]

I have reproduced the first failure, but not the second. Could you provide a 
simple test case that demonstrates it? It would be good if you could do this 
via the bug tracker (http://sourceforge.net/p/iverilog/bugs/) - that makes 
sure we can't forget about it!

Thanks,

Martin

ni...@ly... (Niels Möller) wrote:
> Hi,
>
> I'm still trying to learn verilog and system verilog. This time playing
> with struct (the idea is to define a combinatorial function which takes
> an opcode and some other cpu state as input and returns a larger struct
> more suitable for executing the instruction).
>
> I'm using iverilog compiled from commit
>
>    commit 437dc103416dd2bca99cccdaca4aacfec3411f36
>    Merge: 102d2d5 d1dc98b
>    Author: Stephen Williams <st...@ic...>
>    Date:   Thu Mar 12 10:30:56 2015 -0700
>
>        Merge pull request #55 from orsonmmz/const_record
>
>        Const record
>
> running on a debian gnu/linux box, x86_64. First I got compilation
> failures with
>
>    ex.vl:1: assert: pform_struct_type.cc:83: failed assertion 0
>    Aborted
>
> Looking up that line, it seems non-packed structs are not yet supported
> (an error message saying so would be nicer than an assert...). So I
> added the packed keyword, without understanding what it really means in
> system verilog, and that made the compiler happy.
>
> But now I get an assertion failure from vvp instead,
>
>    vpi error: bad global property: 50
>    vvp: vpi_priv.cc:281: int vpip_get_global(int): Assertion `0' failed.
>    Aborted (core dumped)
>
> The number 50 seems to be vpiAutomatic (from a call in sys_check_args).
> But I'm a bit lost here. Backtrace is as follows:
>
>    (gdb) bt
>    #0  0x00007f6057bf8107 in __GI_raise (sig=sig@entry=6)
>        at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
>    #1  0x00007f6057bf94e8 in __GI_abort () at abort.c:89
>    #2  0x00007f6057bf1226 in __assert_fail_base (
>        fmt=0x7f6057d27ce8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
>        assertion=assertion@entry=0x4e188e "0",
>        file=file@entry=0x4e2c21 "vpi_priv.cc", line=line@entry=281,
>        function=function@entry=0x4e3690 <vpip_get_global(int)::__PRETTY_FUNCTION__> "int vpip_get_global(int)") at assert.c:92
>    #3  0x00007f6057bf12d2 in __GI___assert_fail (assertion=0x4e188e "0",
>        file=0x4e2c21 "vpi_priv.cc", line=281,
>        function=0x4e3690 <vpip_get_global(int)::__PRETTY_FUNCTION__> "int vpip_get_global(int)") at assert.c:101
>    #4  0x00000000004ac29f in vpip_get_global (property=50)
>        at vpi_priv.cc:281
>    #5  vpi_get (property=50, ref=0x0) at vpi_priv.cc:392
>    #6  0x00000000004ac1b1 in vpi_get (property=50, ref=0x10eccd0)
>        at vpi_priv.cc:406
>    #7  0x00007f6057591bd2 in sys_check_args (callh=callh@entry=0x10ecf30,
>        argv=0x10c2f00, name=name@entry=0x7f60575b1106 "$monitor",
>        no_auto=no_auto@entry=1, is_monitor=is_monitor@entry=1)
>        at sys_display.c:1076
>    #8  0x00007f605759464e in sys_monitor_compiletf (
>        name=0x7f60575b1106 "$monitor") at sys_display.c:1461
>    #9  0x000000000045b616 in compile_cleanup () at compile.cc:784
>    #10 0x0000000000442761 in main (argc=3, argv=0x7fff9180e368)
>        at main.cc:457
>
> My test and debugging code includes the command
>
>       $monitor ("At time %t: pc: %x, instr: %x, instr_valid: %d\n  imm_value: %x, src_value: %x\n  imm_op: %d, prefix_active: %d, prefix: %x",
> 	       $time, main_cpu.pc, main_cpu.instr, main_cpu.instr_valid,
> 	       main_cpu.instr_op.imm_value, main_cpu.src_value,
> 	       main_cpu.instr_op.imm_op, main_cpu.prefix_active, main_cpu.prefix);
>
> where main_cpu.instr_op is a struct type defined by
>
>    typedef struct packed {
>       bit [63:0] imm_value;
>       bit        imm_op;
>       bit        imm_sign;
>       bit [3:0]  dreg;
>       bit [3:0]  sreg;
>       bit        write_dst;
>       bit [3:0]  op_type;
>       bit [3:0]  op;
>    } DECODED_INSTR;
>
> Dropping these references from the $monitor command makes the problem go
> away, but then it is more difficult to track down the bugs in my own
> code...
>
> Best regards,
> /Niels
>