Menu
▾
▴
iverilog-devel
|
From: Uwe B. <bo...@el...> - 2008-01-21 10:33:10
|
Hallo, trying to run a XILINX EDK generated Cordic File the first problem met is the "negative value in for loop" problem, entered in the Bug database yesterday. I worked around the problem in my local codebase. Trying to run the generated a.out, I get: > ./a.out VCD info: dumpfile iq2phase.vcd opened for output. internal error: port 1 expects wid=2, got wid=0 vvp: concat.cc:56: virtual void vvp_fun_concat::recv_vec4(vvp_net_ptr_t, \ const vvp_vector4_t&): Assertion `0' failed. Abort How can i get more informations in this case to track down the problem? I asked a similar question last year, where ivl_assert was brought up in the discussion. However I don't think, ivl_assert may be applied here. Any hints welcome. -- Uwe Bonnes bo...@el... Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- |
|
From: Cary R. <cy...@ya...> - 2008-01-22 23:22:27
|
--- Uwe Bonnes <bo...@el...> wrote:
> trying to run a XILINX EDK generated Cordic File the first problem met
> is
> the "negative value in for loop" problem, entered in the Bug database
> yesterday. I worked around the problem in my local codebase. Trying to
> run
> the generated a.out, I get:
> > ./a.out
> VCD info: dumpfile iq2phase.vcd opened for output.
> internal error: port 1 expects wid=2, got wid=0
> vvp: concat.cc:56: virtual void vvp_fun_concat::recv_vec4(vvp_net_ptr_t,
> \
> const vvp_vector4_t&): Assertion `0' failed.
> Abort
>
> How can i get more informations in this case to track down the problem?
Steve may have a better suggestion, but here is what I have been doing.
>From the assert message and looking at the code we can see that port 1 of
a concat is receiving a zero width vector, but was expecting a two bit
vector.
So the question is what is a vvp_fun_concat? If we assume that things are
created with "new" searching for "new vvp_fun_concat" shows that only
compile_concat a few lines down from the assert creates these type of
objects. Searching on just vvp_fun_concat shows that this is the only
place these type of objects are created. For some objects omitting the
"new" produces a huge amount of data to look at.
Searching for compile_concat shows it is only called in parse.y so looking
at that line we see that this is created by a K_CONCAT line. From the
lexor.lex file we find that K_CONCAT is a .concat statement. The
documentation on what a .concat is can be found in the vvp/README.txt
file.
So taking what we know so far we are looking in the a.out file for a
.concat statement that has a two bit wide second port(port numbers start
ate 0). Something like.
<label> .concat [<X> 2 <Y> <Z>], <symbol_list>;
Now you need to look at the second symbol in the symbol list and see what
it is connected to. Doing a bit of tracking you should be able to figure
out what the .concat is driving and what is driving it.
For some more information we look in the tgt-vvp directory and find in
vvp_scope.c that a .concat statement is only created by an IVL_LPM_CONCAT
object. Seaching in the top level (compiler) directory we find that the
only place that an IVL_LPM_CONCAT is created is in t-dll.cc
(dll_target::concat). This takes a NetConcat object and coverts it into
something the code generator can use, so that is the next thing to look
for.
Searching for "new NetConcat" finds that these type of objects are created
in a few different files. Given the information gleaned so far and
outputting some I'm here text with either fprintf or cerr should help
narrow the problem even further. What you find after looking a bit is that
some of these are created by the compiler and some represent real Verilog
concatenations.
With all this information you should be able to figure out which
statement(s) in the Verilog source is causing the problem.
> I asked a similar question last year, where ivl_assert was brought up in
> the
> discussion. However I don't think, ivl_assert may be applied here.
Correct, ivl_assert is only for the compiler.
I hope this helps,
Cary
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
|
|
From: Uwe B. <bo...@el...> - 2008-01-23 16:12:22
|
>>>>> "Cary" == Cary R <cy...@ya...> writes:
Cary> --- Uwe Bonnes <bo...@el...> wrote:
Cary> With all this information you should be able to figure out which
Cary> statement(s) in the Verilog source is causing the problem.
Thanks for the help so long.
I can see:
v0xa16a2a0_0 .net *"_s273", -1 0, L_0xc4250c0; 1 drivers
and later this L_0xc4250c0 is used in the offending concatenation. This also
seems to happen in the context of the file with the negative value of the
for loop.
With an
assert(npins > 0);
in netlists.cc:NetNet::NetNet(NetScope*s, perm_string n, Type t, unsigned npins)
I can find out when the offending value is written. However _s273 seems to
be an auto-generated variable, and I have no clue what causes this variable to be
generated. In the a.out file, the nets are sorted in their numeric order,
not by time they are generated in the code.
With code like
# include <execinfo.h>
# include <cxxabi.h>
void
print_trace (void)
{
/*
* http://www-128.ibm.com/developerworks/library/l-cppexcep.html?ca=dnt-68
* http://www.int0x80.gr/papers/name_mangling.pdf
*/
const int maxdepth(25);
void *func_addresses[maxdepth];
int nfuncs = backtrace(func_addresses, maxdepth);
int i;
int status=0;
//now get the function names associated with these symbols. This should work for elf
//binaries, though additional linker options may need to have been called
//(e.g. -rdynamic for GNU ld. See the glibc documentation for 'backtrace')
char **symbols = backtrace_symbols(func_addresses, nfuncs);
printf ("Obtained %zd stack frames.\n", nfuncs);
for (i = 0; i < nfuncs; i++)
{
char *begin = strchr(symbols[i], '(');
char *end = strchr(begin,'+');
char *lend = strchr(begin,')');
char funcname[1000];
strncpy(funcname,begin+1, end-begin);
funcname[end-begin-1] = 0;
char addr[10];
strncpy(addr,end+1, lend-end);
addr[lend-end-1] = 0;
char *demangled = abi::__cxa_demangle(funcname, 0, 0, &status);
if (status == 0)
fprintf(stderr, "%s + %s\n",demangled, addr);
else
fprintf(stderr, "%s\n", symbols[i]);
free(demangled);
}
free (symbols);
}
I can print out a backtrace, when the (npins !>0) situation happens:
Obtained 19 stack frames.
print_trace() + 0x1f
NetNet::NetNet(NetScope*, perm_string, NetNet::Type, unsigned int) + 0x17c
PEBinary::elaborate_net_shift_(Design*, NetScope*, unsigned int, NetExpr const*, NetExpr const*, NetExpr const*) const + 0x568
PEBinary::elaborate_net(Design*, NetScope*, unsigned int, NetExpr const*, NetExpr const*, NetExpr const*, Link::strength_t, Link::strength_t) const + 0x2f8
PETernary::elaborate_net(Design*, NetScope*, unsigned int, NetExpr const*, NetExpr const*, NetExpr const*, Link::strength_t, Link::strength_t) const + 0xa2
PETernary::elaborate_net(Design*, NetScope*, unsigned int, NetExpr const*, NetExpr const*, NetExpr const*, Link::strength_t, Link::strength_t) const + 0xf0
PETernary::elaborate_net(Design*, NetScope*, unsigned int, NetExpr const*, NetExpr const*, NetExpr const*, Link::strength_t, Link::strength_t) const + 0xa2
PGAssign::elaborate(Design*, NetScope*) const + 0x4f0
Module::elaborate(Design*, NetScope*) const + 0x5ad
PGModule::elaborate_mod_(Design*, Module*, NetScope*) const + 0x335
PGModule::elaborate(Design*, NetScope*) const + 0x56
Module::elaborate(Design*, NetScope*) const + 0x5ad
PGModule::elaborate_mod_(Design*, Module*, NetScope*) const + 0x335
PGModule::elaborate(Design*, NetScope*) const + 0x56
Module::elaborate(Design*, NetScope*) const + 0x5ad
elaborate(std::list<perm_string, std::allocator<perm_string> >) + 0x356
/usr/local/lib/ivl/ivl(main+0xc52) [0x80783c2]
/lib/libc.so.6(__libc_start_main+0xdc) [0xb7cbdf9c]
/usr/local/lib/ivl/ivl(__gxx_personality_v0+0x10d) [0x8075ed1]
However this doesn't help me too much. Has anybody an idea about that?
Maybe however the print_trace code may be usefull for iverilog developpers.
Bye
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: Cary R. <cy...@ya...> - 2008-01-23 17:50:07
|
--- Uwe Bonnes <bo...@el...> wrote:
> I can see:
> v0xa16a2a0_0 .net *"_s273", -1 0, L_0xc4250c0; 1 drivers
I think you are reading this line incorrectly. The .net definition is
located in vvp/README.txt. You are correct this is a temporary net, but
L_0xc4250c0 is driving the net. Also, since it is a temporary net it is
probably being created by the compiler, so would not be a real Verilog
concatenation. What you need to look for is what has L_0xc4250c0 as an
Lval and then track that back to a real signal. The -1 for the MSB is a
clue, but we still need to know what is ultimately driving the NetConcat.
> I can find out when the offending value is written. However _s273
> seems to be an auto-generated variable, and I have no clue what
> causes this variable to be generated.
The NetConcat and a temporary net are often used to pad a value in a
continuous assignment.
> PEBinary::elaborate_net_shift_(Design*, NetScope*, unsigned int, NetExpr
> const*, NetExpr const*, NetExpr const*) const + 0x568
This is used to elaborate the shift operators which can use a temporary
net and a NetConcat for padding (elab_net.cc)
> PETernary::elaborate_net(Design*, NetScope*, unsigned int, NetExpr
> const*, NetExpr const*, NetExpr const*, Link::strength_t,
> Link::strength_t) const + 0xa2
<Snip of other PETernary::elaborate_net.>
These looks like some nested ternary operators (elab_expr.cc).
> PGAssign::elaborate(Design*, NetScope*) const + 0x4f0
A continuous assignment (elaborate.cc).
So for this case it looks like you are looking for a continuous assignment
the has three ternary operators that contains a shift. By tracking back to
what is driving L_0xc4250c0 you should be able to figure out what type of
shift.
Cary
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
|
|
From: Uwe B. <bo...@el...> - 2008-01-23 18:52:25
|
>>>>> "Cary" == Cary R <cy...@ya...> writes:
Cary> --- Uwe Bonnes <bo...@el...> wrote:
>> I can see: v0xa16a2a0_0 .net *"_s273", -1 0, L_0xc4250c0; 1 drivers
Cary> I think you are reading this line incorrectly. The .net definition
Cary> is located in vvp/README.txt. You are correct this is a temporary
Hallo Cary,
trying to read like you proposed, I think here are some more or less
relevant lines. The first number is the line number in the a.out file:
13340 v0xbf41b18_0 .net "BU1155_Q", 4 0, L_0xc1264c8; 1 drivers
15245 RS_0xbace0f0 .resolv tri, L_0xc414290, L_0xc4142e0, L_0xc414330, L_0xc4143d0;
17963 L_0xc414290 .part/pv L_0xc11c4b0, 0, 1, 4;
17964 L_0xc4142e0 .part/pv L_0xc11c550, 1, 1, 4;
17965 L_0xc414330 .part/pv L_0xc1261d0, 2, 1, 4;
17966 L_0xc4143d0 .part/pv L_0xc126220, 3, 1, 4;
17181 L_0xc11c4b0 .part L_0xc1264c8, 0, 1;
17182 L_0xc11c550 .part L_0xc1264c8, 1, 1;
17183 L_0xc1261d0 .part L_0xc1264c8, 2, 1;
17184 L_0xc126220 .part L_0xc1264c8, 3, 1;
17185 L_0xc1262e8 .part L_0xc1264c8, 4, 1;
347865 v0xa16a440_0 .net *"_s273", -1 0, L_0xc4251b8; 1 drivers
348015 L_0xc425280 .concat [ 4 2 0 0], C4<0000>, L_0xc4251b8;
348016 L_0xc4251b8 .part RS_0xbace0f0, 0, 0;
The last line with the part select with width 0 seems fishy.
BU1155_Q is the Q of an C_ADDSUB_V7_0 invocation:
wire [4 : 0] BU1155_Q;
assign n7927 = BU1155_Q[0];
assign n7926 = BU1155_Q[1];
assign n7925 = BU1155_Q[2];
assign n7924 = BU1155_Q[3];
assign n8091 = BU1155_Q[4];
that is fed back into the adder:
wire [4 : 0] BU1155_A;
assign BU1155_A[0] = n7927;
assign BU1155_A[1] = n7926;
assign BU1155_A[2] = n7925;
assign BU1155_A[3] = n7924;
assign BU1155_A[4] = n8091;
and goes to a C_REG_FD_V7_0:
wire [4 : 0] BU1189_D;
assign BU1189_D[0] = n7927;
assign BU1189_D[1] = n7926;
assign BU1189_D[2] = n7925;
assign BU1189_D[3] = n7924;
assign BU1189_D[4] = n8091;
At the moment nor more ideas...
Bye
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: Cary R. <cy...@ya...> - 2008-01-23 19:38:48
|
--- Uwe Bonnes <bo...@el...> wrote:
> 13340 v0xbf41b18_0 .net "BU1155_Q", 4 0, L_0xc1264c8; 1 drivers
What is driving L_0xc1264c8?
> 347865 v0xa16a440_0 .net *"_s273", -1 0, L_0xc4251b8; 1 drivers
>
> 348015 L_0xc425280 .concat [ 4 2 0 0], C4<0000>, L_0xc4251b8;
> 348016 L_0xc4251b8 .part RS_0xbace0f0, 0, 0;
>
> The last line with the part select with width 0 seems fishy.
Yes the part select and the temporary look wrong.
Can you extract this part of the code and reproduce the problem?
Cary
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
|
|
From: Uwe B. <bo...@el...> - 2008-01-23 20:37:31
|
>>>>> "Cary" == Cary R <cy...@ya...> writes:
Cary> --- Uwe Bonnes <bo...@el...> wrote:
>> 13340 v0xbf41b18_0 .net "BU1155_Q", 4 0, L_0xc1264c8; 1 drivers
Cary> What is driving L_0xc1264c8?
Cary,
I posted the lines driving L_0xc1264c8.
However I still don't see the code causing the error. But I have the feeling
that it is still caused by a negative parameter upsetting something (see
iverilog-Bugs-1875866)...
Bye
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: Cary R. <cy...@ya...> - 2008-01-23 21:52:57
|
--- Uwe Bonnes <bo...@el...> wrote:
> I posted the lines driving L_0xc1264c8.
Unless I'm missing something you only showed what L_0xc1264c8 is driving
(input) not what is driving L_0xc1264c8 (output). We also don't know where
L_0xc425280 (the output of the .concat) is going. We know net BU1155_Q is
involved. The Verilog code you showed may be the only places where net
BU1155_Q is used, but it appears the compiler is doing something wrong, so
we cannot make too many assumptions about what is really going on.
I also would have expected the n# nodes to show up some where. Maybe they
did and you didn't include that information.
If you think you have narrowed down the code that is causing the problem
you can print out appropriate information (widths, etc) during elaboration
to see if they match what you expect. If the width is correct at
elaboration, but incorrect in the a.out file it could be a problem in the
code generator or something in the back end of the compiler. If they are
wrong at elaboration then you have to look at the values created at the
initial compile step.
> However I still don't see the code causing the error. But I have the
> feeling
> that it is still caused by a negative parameter upsetting something (see
> iverilog-Bugs-1875866)...
Possibly.
Cary
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
|
|
From: Uwe B. <bo...@el...> - 2008-01-24 11:12:06
|
>>>>> "Cary" == Cary R <cy...@ya...> writes: Hallo, setting bool debug_elaborate = true; in main.cc seems to do the trick: > iverilog test_tb.v test_tb.v:2: debug: Create signal reg [3:0] A in scope test test_tb.v:4: debug: Create signal wire [3:0] a_int in scope test test_tb.v:6: debug: PGassign: elaborated l-value width=4, type=logic test_tb.v:6: debug: Elaborate shift (l) as concatenation of 4 zeros with 0 bits of expres > ./a.out internal error: port 1 expects wid=2, got wid=0 vvp: concat.cc:56: virtual void vvp_fun_concat::recv_vec4(vvp_net_ptr_t, const vvp_vector4_t&): Assertion `0' failed. Abort B.t.w.: can we switch on debug_elaborate on the command line? Bye -- Uwe Bonnes bo...@el... Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- module test(); reg [3 : 0] A; wire [3 : 0] a_int; assign a_int = A<<4; endmodule // test |
|
From: Stephen W. <st...@ic...> - 2008-01-24 16:41:58
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Uwe Bonnes wrote: > B.t.w.: can we switch on debug_elaborate on the command line? That's a feature request just waiting to happen:-) There are a bunch of debug flags like this that are available in the ivl core program. They are actually turned on by records in the settings file that the driver passes to the ivl program when it executes. All we need is the right flags in the driver program to cause the driver to write those debug records to the ivl program. - -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHmL/SrPt1Sc2b3ikRAnbJAJ4qPT9hrNEQa9CtxAOrbcLQGUUuwgCgiA2X QXhmE7ByK+yTNX5FcYLdbks= =Mwm3 -----END PGP SIGNATURE----- |
|
From: Cary R. <cy...@ya...> - 2008-01-24 16:56:26
|
--- Uwe Bonnes <bo...@el...> wrote:
> bool debug_elaborate = true;
> in main.cc seems to do the trick:
Sorry I didn't mention that. I was looking at it a couple of days ago and
made the assumption you probably already knew about it.
> assign a_int = A<<4;
So it was a shift in a continuous assignment.
Cary
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
|
|
From: Uwe B. <bo...@el...> - 2008-01-24 18:34:34
|
>>>>> "Cary" == Cary R <cy...@ya...> writes:
Cary> --- Uwe Bonnes <bo...@el...> wrote:
Cary> So it was a shift in a continuous assignment.
The actual line looks like:
assign a_int = (C_REG_A_D_INPUTS == 0 ? (C_MEM_TYPE != `c_srl16 ? A : (C_ADDR_WIDTH>4 ? A[C_ADDR_WIDTH - 1 -(C_ADDR_WIDTH>4?(4*C_HAS_SPRA):0) : 0]<<4 : 0)) :
(C_MEM_TYPE != `c_srl16 ? a_int1 : (C_ADDR_WIDTH>4 ? a_int1[C_ADDR_WIDTH - 1 -(C_ADDR_WIDTH>4?(4*C_HAS_SPRA):0) : 0]<<4 : 0)));
:-)
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: Cary R. <cy...@ya...> - 2008-01-24 18:54:37
|
--- Uwe Bonnes <bo...@el...> wrote:
> The actual line looks like:
> assign a_int = (C_REG_A_D_INPUTS == 0 ? (C_MEM_TYPE != `c_srl16 ? A :
> (C_ADDR_WIDTH>4 ? A[C_ADDR_WIDTH - 1 -(C_ADDR_WIDTH>4?(4*C_HAS_SPRA):0)
> : 0]<<4 : 0)) :
>
> (C_MEM_TYPE != `c_srl16 ? a_int1 : (C_ADDR_WIDTH>4 ?
> a_int1[C_ADDR_WIDTH - 1 -(C_ADDR_WIDTH>4?(4*C_HAS_SPRA):0) : 0]<<4 :
> 0)));
I think I remember mention a few ternary operators as well ;-).
Make sure you file a bug report for this, so it doesn't get lost. I think
we should also check the other shift operators for the same type of
problem. If you can do this that would be great. If you don't have time
make sure you mention needing to check the other shift operators in the
actual bug report.
Cary
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X