iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] System Verilog versus Icarus

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steven Wilson wrote:
> Okay - I'm subscribed as a lurker on the iverilog-devel list. 

Moving this conversation there, then, because it is of general
interesting I think.

> There are certainly some things I like right away [about system Verilog].
> while others seem 
> pointless (logic versus reg..)  The tutorial I read said the justification 
> for logic - "It's just better." 

"logic" and "reg", and also "bool" types should be entirely doable.
In fact, Icarus Verilog already supports logic and bool somewhat, and
also allows for real value nets as well in places that Verilog does not.
We are busy working on fixing bugs there, though. It would be pretty
kool too to add support for enumerations all the way through to the
gtkwave viewer. That would solve a problem that a *lot* of Verilog
users gripe about: Marking traces with useful names.

> I particularly like always_ff, always_comb, and always_latch.  This is from 
> a "How did that latch get there" point of view in synthesis.

Entirely doable in Icarus Verilog. They can also be used to constrain
user expectations and thus lead to better warnings from the compiler.
I personally support adding those statements.

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

iD8DBQFHmi8krPt1Sc2b3ikRAl4wAKDoGdn8n61t7XzI2XxGdBDqVACWCQCgr6xz
ZBFcYxinIhyrKOGcTl418T8=
=5eGv
-----END PGP SIGNATURE-----

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

[Larry D. <ldo...@re...>]

On Fri, Jan 25, 2008 at 10:33:40AM -0800, Stephen Williams wrote:
> Larry Doolittle wrote:
> > This particular bug looks like it's in the vvp code generator.
> > It prints out
> > L_0x81cde48 .concat [ 4 2 0 0], C4<0000>, L_0x81cdef0;
> > but the second width (2) should really be 0. [chop]
> > The elaborated design itself looks correct.
> 
> The elaboration is probably *not* correct if L_0x81cdef0 is
> thought to be width of zero. It looks like the concat writer
> thinks it should be width of 2.

L_0x81cdef0 is thought to be width of zero.
The output from debug:elaborate shows the second concatenate
input has width 0.  The concat output of vvp code generator
is the first place the error appears.

> At this point, the -tstub target may be the needed magic. That
> code generator doubles as a compiler sanity checker and may detect
> the bad situation here. Just run iverilog -v -Wall -tstub test_tb.v
> and see if the resulting a.out has ERROR strings in it anywhere.

That's cool magic.  ;-)

  LPM_CONCAT _s3: <width=4, inputs=2>
    O: test.a_int
    I0: test._s1 (width=4)
    I1: test._s5 (width=2)
    ERROR! Got 6 bits input, expecting 4!
  LPM_PART_VP _s4: <width=0, base=0, signed=0>
    O: test._s5
    I: test.A
    ERROR: Part select input mistatch. Nexus width=2, expect width=0

   - Larry

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

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Larry Doolittle wrote:
> This particular bug looks like it's in the vvp code generator.
> It prints out
> 
> L_0x81cde48 .concat [ 4 2 0 0], C4<0000>, L_0x81cdef0;
> 
> but the second width (2) should really be 0.
> The code that prints the erroneous 2 is in tgt-vvp/vvp_scope.c:1828,
> function lpm_concat_inputs().  I didn't trace back width_of_nexus()
> yet to see where the bug really is.  The elaborated design itself
> looks correct.

The elaboration is probably *not* correct if L_0x81cdef0 is
thought to be width of zero. It looks like the concat writer
thinks it should be width of 2.

At this point, the -tstub target may be the needed magic. That
code generator doubles as a compiler sanity checker and may detect
the bad situation here. Just run iverilog -v -Wall -tstub test_tb.v
and see if the resulting a.out has ERROR strings in it anywhere.

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

iD8DBQFHmiuErPt1Sc2b3ikRAlk2AKCS7g18wzA1zcNiHUCiOea04v2M+gCgwMMI
rEUSM1ntYy8LFo0YPo+khKw=
=P75m
-----END PGP SIGNATURE-----

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

[Larry D. <ldo...@re...>]

Hi -

To get debug_elaborate turned on without recompiling, do

IVERILOG_ICONFIG=foo.conf iverilog -v -Wall test_tb.v

then add

debug:elaborate

to the resulting foo.conf, and (assuming you don't have any
actual preprocessor activity) rerun the ivl command printed
by the above iverilog -v trace, except ending with test_tb.v
instead of --.  This process is hinted at in the iverilog
man page, in the description of the -v flag.

This particular bug looks like it's in the vvp code generator.
It prints out

L_0x81cde48 .concat [ 4 2 0 0], C4<0000>, L_0x81cdef0;

but the second width (2) should really be 0.
The code that prints the erroneous 2 is in tgt-vvp/vvp_scope.c:1828,
function lpm_concat_inputs().  I didn't trace back width_of_nexus()
yet to see where the bug really is.  The elaborated design itself
looks correct.

   - Larry

[Iverilog-devel] Icarus Verilog vvp32 on 64bit systems

[Stephen W. <st...@ic...>]

Question:

Does *anybody* use or even see value in the 32bit runtime support
that Icarus Verilog includes in 64bit builds? In particular, there
is support in the Icarus Verilog source for building simultaneously
a vvp (64bit) and a vvp32 (32bit) to support 32bit VPI's transported
from 32bit systems.

I personally have never used the vvp32 and I'm starting to run
into cases where it is actively getting in the way. I'm considering
removing the whole business and forgetting about it, although there
may be alternatives.

When I first implemented it, I was not particularly clear on how
the 64/32 compatibility worked on Linux. If there is interest in
keeping up 32bit runtime support (i.e. vvp32 on 64bit systems) then
it may be better handled by a more compliant method. Perhaps it
can be tied in with multi-version support, which is missing so far.

Ideas?
-- 
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."

[Iverilog-devel] Sorry for duplicate bug!

[Uwe B. <bo...@el...>]

Hi,

I hit back on the browser and didn't read the warning from firefox about all
actions being repeated.

Sorry!
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Re: [Iverilog-devel] today's count of compiler warnings

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I've went ahead and added datarootdir = ... lines in the Makefile.in
files in question. Didn't seem to cause obvious breakage, and I've
pushed them into git.

Larry Doolittle wrote:

> Quoting from
>   http://www.gnu.org/software/automake/manual/autoconf/Changed-Directory-Variables.html
> 
>   In Autoconf 2.60, the set of directory variables has changed, and the
>   defaults of some variables have been adjusted (see Installation
>   Directory Variables) to changes in the GNU Coding Standards. Notably,
>   datadir, infodir, and mandir are now expressed in terms of datarootdir.
>   If you are upgrading from an earlier Autoconf version, you may need to
>   adjust your files to ensure that the directory variables are substituted
>   correctly (see Defining Directories), and that a definition of
>   datarootdir is in place. For example, in a Makefile.in, adding
>   
>       datarootdir = @datarootdir@
> 
>   is usually sufficient. If you use Automake to create Makefile.in, it will
>   add this for you.

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

iD8DBQFHmPEnrPt1Sc2b3ikRAloFAJ4v4/GTjypt9AAyr7KCfUIQOK7SFgCfesRb
RhoHrp8UgMwCG6XIBCelVuA=
=0rDD
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] list archive stuck

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Larry Doolittle wrote:
> Hi -
> 
> Nothing from this list has gone into the archive for the last 3+ days.
> That's bad; I have deleted most of my copies of the mail.  Between
> this and the silly "Sponsored by Microsoft" ads at the bottom, of
> each mail, I wonder if we should fire SourceForge.  Mailing lists
> aren't exactly rocket science.

The mailing list is working, it is the archiving service that
seems to be the issue here. I've filed a bug report to SF. They
have been working on the indexing engine, so it may be OK and
just falling behind.

(As for the "sponsored by: Microsoft" crap that they tag on the
end, well, that turns my stomach too. But I do not want to
personally host a mailing list and SF seems a reasonable choice
given they already host the trackers and that is working out well
enough.)

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

iD8DBQFHmOSxrPt1Sc2b3ikRAgI6AJ9KLKbIMQaK6wbFRitilXHfbkfH8gCgo7ri
r2hzVUdCO5VwIpjis2ljaI0=
=tWht
-----END PGP SIGNATURE-----

[Iverilog-devel] list archive stuck

[Larry D. <ldo...@re...>]

Hi -

Nothing from this list has gone into the archive for the last 3+ days.
That's bad; I have deleted most of my copies of the mail.  Between
this and the silly "Sponsored by Microsoft" ads at the bottom, of
each mail, I wonder if we should fire SourceForge.  Mailing lists
aren't exactly rocket science.

   - Larry

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

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

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

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

[Uwe B. <bo...@el...>]

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

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

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

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

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

[Stephen W. <st...@ic...>]

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

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

[Uwe B. <bo...@el...>]

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

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

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

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

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

[Uwe B. <bo...@el...>]

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

Re: [Iverilog-devel] today's count of compiler warnings

[Larry D. <ldo...@re...>]

Steve -

On Tue, Jan 22, 2008 at 05:52:32PM -0800, Stephen Williams wrote:
> Larry Doolittle wrote:
> > config.status: WARNING:  ../verilog-0.9/Makefile.in seems to ignore the --datarootdir setting
> > config.status: WARNING:  ../verilog-0.9/driver/Makefile.in seems to ignore the --datarootdir setting
> > config.status: WARNING:  ../verilog-0.9/driver-vpi/Makefile.in seems to ignore the --datarootdir setting
> > config.status: WARNING:  ../../verilog-0.9/vvp/Makefile.in seems to ignore the --datarootdir setting
> > configure: WARNING: no configuration information is in tgt-null
> 
> I have no idea what to do with the above warnings. What is the
> datarootdir setting and why should I not ignore it?

Quoting from
  http://www.gnu.org/software/automake/manual/autoconf/Changed-Directory-Variables.html

  In Autoconf 2.60, the set of directory variables has changed, and the
  defaults of some variables have been adjusted (see Installation
  Directory Variables) to changes in the GNU Coding Standards. Notably,
  datadir, infodir, and mandir are now expressed in terms of datarootdir.
  If you are upgrading from an earlier Autoconf version, you may need to
  adjust your files to ensure that the directory variables are substituted
  correctly (see Defining Directories), and that a definition of
  datarootdir is in place. For example, in a Makefile.in, adding
  
      datarootdir = @datarootdir@

  is usually sufficient. If you use Automake to create Makefile.in, it will
  add this for you.

I see many other Free Software projects have recently added the newly
recommended line, see for instance
  http://www.ginac.de/pipermail/cln-list/2006-April/000187.html

Patches such as this claim to be backward-compatible.

   - Larry

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

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

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

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

[Uwe B. <bo...@el...>]

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

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

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

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

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

[Uwe B. <bo...@el...>]

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

Re: [Iverilog-devel] today's count of compiler warnings

[Larry D. <ldo...@re...>]

Steve -

On Tue, Jan 22, 2008 at 05:52:32PM -0800, Stephen Williams wrote:
> Larry Doolittle wrote:
> > ../../verilog-0.9/vvp/vpi_scope.cc:390: warning: dereferencing type-punned pointer will break strict-aliasing rules
> 
> This one is an unfortunate consequence of the compile_vpi_lookup
> function. This function take a pointer to a handle so that it
> can look up the label and arrange for the matching handle to be
> stored in the pointer, some time in the future.
> 
> One way to handle this might be to rewire the vpi objects to
> use __vpiHandle as a virtual base class so that C++ dynamic
> casting, which is run-time type-safe, can be used here. That would
> be a valuable cleanup, but a non-trivial task.

The intriguing thing is that gcc-4.3 no longer considers
the construct to merit a warning.  So I wouldn't worry about
it much.

The lower hanging fruit, that does apply to both gcc-4.2 and gcc-4.3, is

../../verilog-0.9/vvp/vpi_priv.cc:121: warning: deprecated conversion from string constant to 'char*'

> > ../../verilog-0.9/libveriuser/getp.c:56: warning: cast from pointer to integer of different size
> The getp.c warning is an unfortunate consequence of the rather
> amateurish design of the types in the PLI.

Right, and to me it makes perfect sense to keep the warning around,
rather than paper over the problem.  At least until the standards
committee fixes the bug in their standard.

   - Larry

Re: [Iverilog-devel] today's count of compiler warnings

[Anthony J B. <net...@nc...>]

On Tue, 22 Jan 2008, Stephen Williams wrote:

> I would *love* to see how any of the big-3 declare tf_igetp in
> their veriuser.h header files on a 64bit machine;-)

I'm not at work this instant so I can't check those do it but cver is
supposed to be XL-compatible and this is how they define it:

EXTERN int          tf_igetp PROTO_PARAMS((int pnum, char *inst));

which on amd64 and ppc64 doesn't look different from what you're doing:

extern PLI_INT32 tf_igetp(PLI_INT32, void*);

well, unless you compile with -qintsize=8 in AIX.

-t

Re: [Iverilog-devel] today's count of compiler warnings

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Larry Doolittle wrote:
> On an amd64 system with GNU Autoconf 2.61 (Debian 2.61-5), and leaving the source tree pristine,
> at configuration time
> 
> config.status: WARNING:  ../verilog-0.9/Makefile.in seems to ignore the --datarootdir setting
> config.status: WARNING:  ../verilog-0.9/driver/Makefile.in seems to ignore the --datarootdir setting
> config.status: WARNING:  ../verilog-0.9/driver-vpi/Makefile.in seems to ignore the --datarootdir setting
> config.status: WARNING:  ../../verilog-0.9/vvp/Makefile.in seems to ignore the --datarootdir setting
> configure: WARNING: no configuration information is in tgt-null

I have no idea what to do with the above warnings. What is the
datarootdir setting and why should I not ignore it?

> ../../verilog-0.9/vvp/vpi_scope.cc:390: warning: dereferencing type-punned pointer will break strict-aliasing rules

This one is an unfortunate consequence of the compile_vpi_lookup
function. This function take a pointer to a handle so that it
can look up the label and arrange for the matching handle to be
stored in the pointer, some time in the future.

One way to handle this might be to rewire the vpi objects to
use __vpiHandle as a virtual base class so that C++ dynamic
casting, which is run-time type-safe, can be used here. That would
be a valuable cleanup, but a non-trivial task.

> ../../verilog-0.9/libveriuser/getp.c:56: warning: cast from pointer to integer of different size

The getp.c warning is an unfortunate consequence of the rather
amateurish design of the types in the PLI. Yes, the tf_igetp is
*defined* to be 32bits, and is expected to return pointers too.
Fools! Fortunately, the PLI1 that this is a part of is officially
gone from the standard as of 1364-2005. The VPI is not much better,
but at least this specific bit of nonsense doesn't exist there.

I would *love* to see how any of the big-3 declare tf_igetp in
their veriuser.h header files on a 64bit machine;-)

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

iD8DBQFHlp3grPt1Sc2b3ikRAjzWAJ4tdYRsmDRUCyUl/x10dRtTh323uQCfb0IG
YOSNnsLbg8AcdHXWM8go3So=
=Eld+
-----END PGP SIGNATURE-----

[Iverilog-devel] today's count of compiler warnings

[Larry D. <ldo...@re...>]

On an amd64 system with GNU Autoconf 2.61 (Debian 2.61-5), and leaving the source tree pristine,
at configuration time

config.status: WARNING:  ../verilog-0.9/Makefile.in seems to ignore the --datarootdir setting
config.status: WARNING:  ../verilog-0.9/driver/Makefile.in seems to ignore the --datarootdir setting
config.status: WARNING:  ../verilog-0.9/driver-vpi/Makefile.in seems to ignore the --datarootdir setting
config.status: WARNING:  ../../verilog-0.9/vvp/Makefile.in seems to ignore the --datarootdir setting
configure: WARNING: no configuration information is in tgt-null

Build with gcc-4.2 (Debian 4.2.2-7)

../verilog-0.9/elab_lval.cc:354: warning: comparison is always true due to limited range of data type
../../verilog-0.9/vvp/vpi_priv.cc:121: warning: deprecated conversion from string constant to 'char*'
../../verilog-0.9/vvp/vpi_scope.cc:390: warning: dereferencing type-punned pointer will break strict-aliasing rules
../../verilog-0.9/libveriuser/getp.c:56: warning: cast from pointer to integer of different size

Build with gcc-4.3 (Debian 4.3-20080116-1)

../../verilog-0.9/vvp/vpi_priv.cc:121: warning: deprecated conversion from string constant to 'char*'
../../verilog-0.9/libveriuser/getp.c:56: warning: cast from pointer to integer of different size

   - Larry