Re: [Iverilog-devel] How to get more information when internal errors happen

[Cary R. <cy...@ya...>]

--- 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