Menu
▾
▴
iverilog-devel
|
From: <ni...@ly...> - 2015-03-15 20:55:49
|
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
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
|
|
From: Martin W. <mai...@ma...> - 2015-03-16 20:28:30
|
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 > |
|
From: <ni...@ly...> - 2015-03-16 21:11:28
Attachments:
main-preprocessed.vl
|
Martin Whitaker <mai...@ma...> writes: > I have reproduced the first failure, but not the second. Could you provide a > simple test case that demonstrates it? It seems a bit tricky to reproduce, I also don't see the problem with my current code. Maybe it's not really related to structs, I don't know. I've digged up the version of the code I used when experiencing the problem. I'm attaching the preprocessed source code (close to 300 lines, so not too huge, I hope. I don't have the time to reduce it further tonight). To reproduce, $ iverilog -g2005-sv main-preprocessed.vl $ ./a.out vpi error: bad global property: 50 vvp: vpi_priv.cc:281: int vpip_get_global(int): Assertion `0' failed. Aborted iverilog -v says Icarus Verilog version 0.10.0 (devel) (s20141205-283-g437dc10) Best regards, /Niels |
|
From: Cary R. <cy...@ya...> - 2015-03-16 22:03:27
|
I don't have time to look at this right now, but it looks like the problem could be related to the instr_op net being driven from a function in an assignment statement. I'm guessing that Icarus is treating that function as an automatic function since it is in an assignment statement and is then having a problem finding the actual driver for the individual pieces of the net from the VPI interface. Given the current implementation I'm guessing the $monitor will also fire for any change in instr_op not just when the specified parts change value. I'm not certain if that is correct behavior or not.
The compiler code looks okay given how Steve implemented this (the two references to instr_op in the $monitor are part selects of the base instr_op vector at the correct offset and width).
Cary
On Monday, March 16, 2015 2:11 PM, Niels Möller <ni...@ly...> wrote:
Martin Whitaker <mai...@ma...> writes:
> I have reproduced the first failure, but not the second. Could you provide a
> simple test case that demonstrates it?
It seems a bit tricky to reproduce, I also don't see the problem with my
current code. Maybe it's not really related to structs, I don't know.
I've digged up the version of the code I used when experiencing the
problem. I'm attaching the preprocessed source code (close to 300 lines,
so not too huge, I hope. I don't have the time to reduce it further
tonight).
To reproduce,
$ iverilog -g2005-sv main-preprocessed.vl
$ ./a.out
vpi error: bad global property: 50
vvp: vpi_priv.cc:281: int vpip_get_global(int): Assertion `0' failed.
Aborted
iverilog -v says
Icarus Verilog version 0.10.0 (devel) (s20141205-283-g437dc10)
Best regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
|
|
From: Martin W. <mai...@ma...> - 2015-03-16 22:16:08
|
ni...@ly... (Niels Möller) wrote:
> Martin Whitaker <mai...@ma...> writes:
>
>> I have reproduced the first failure, but not the second. Could you provide a
>> simple test case that demonstrates it?
>
> It seems a bit tricky to reproduce, I also don't see the problem with my
> current code. Maybe it's not really related to structs, I don't know.
>
Yes, it's a more general problem. Reducing your code, I ended up with this:
wire [7:0] my_net;
assign my_net[3:0] = 1;
initial begin
#1 $monitor("At time %0t, field1 = %h", $time, my_net[3:0]);
#1 $finish;
end
Passing a part select of a wire to $monitor seems to be the issue. $display
doesn't have the problem.
This code works in v0.9, so it's a regression.
Martin
|
|
From: Cary R. <cy...@ya...> - 2015-03-16 22:48:52
|
Hi Martin,
I'm guessing that the difference is $display can work with automatic variables and things like $strobe (which also fails) and $monitor cannot so we have to check to see if the variable is automatic. I think the problem is that between step 5 and 6 the reference to the net is being lost while trying to determine if the argument is to an automatic variable (or in this case part of an automatic variable) or not. It almost looks like we are loosing the pointer to the parent for the PV structure, vvp_lookup_handle() is failing? We would need to run this with a runtime compiled with -O0 and -g to get the true back trace.
Cary
On Monday, March 16, 2015 3:16 PM, Martin Whitaker <mai...@ma...> wrote:
ni...@ly... (Niels Möller) wrote:
> Martin Whitaker <mai...@ma...> writes:
>
>> I have reproduced the first failure, but not the second. Could you provide a
>> simple test case that demonstrates it?
>
> It seems a bit tricky to reproduce, I also don't see the problem with my
> current code. Maybe it's not really related to structs, I don't know.
>
Yes, it's a more general problem. Reducing your code, I ended up with this:
wire [7:0] my_net;
assign my_net[3:0] = 1;
initial begin
#1 $monitor("At time %0t, field1 = %h", $time, my_net[3:0]);
#1 $finish;
end
Passing a part select of a wire to $monitor seems to be the issue. $display
doesn't have the problem.
This code works in v0.9, so it's a regression.
Martin
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
|
|
From: Martin W. <mai...@ma...> - 2015-03-17 21:47:35
|
Cary R. wrote: > Hi Martin, I'm guessing that the difference is $display can work with > automatic variables and things like $strobe (which also fails) and $monitor > cannot so we have to check to see if the variable is automatic. I think the > problem is that between step 5 and 6 the reference to the net is being lost > while trying to determine if the argument is to an automatic variable (or > in this case part of an automatic variable) or not. It almost looks like we > are loosing the pointer to the parent for the PV structure, > vvp_lookup_handle() is failing? We would need to run this with a runtime > compiled with -O0 and -g to get the true back trace. > Yes, the problem was that the compilation of the parent net was delayed (pending resolution of another symbol lookup), which meant that when the PV expression was compiled, the VPI handle for the parent wasn't available. I've pushed a fix for this to the master branch on GitHub. I'll see about adding a "sorry" message for non-packed structs later in the week unless you or Steve get to it first. Martin |
|
From: <ni...@ly...> - 2015-03-19 19:13:34
|
Martin Whitaker <mai...@ma...> writes: > Yes, the problem was that the compilation of the parent net was delayed > (pending resolution of another symbol lookup), which meant that when the PV > expression was compiled, the VPI handle for the parent wasn't available. > > I've pushed a fix for this to the master branch on GitHub. I've updated to the new version, and it no longer crashes on my test case. Thanks! /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. |
|
From: Martin W. <mai...@ma...> - 2015-05-17 22:57:02
|
ni...@ly... (Niels Möller) wrote: > 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...). Rather belatedly, I've now added a proper error message for this. Martin |
Thanks for helping keep SourceForge clean.
X