iverilog-devel — Conversations on matters of Icarus Verilog development

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

[Iverilog-devel] Handling of missing specify functionality

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

A recent problem report for stable had an ifnone construct that
development does not have the functionality to correctly support, so it
errors out requiring you to use -g no-specify to work around the problem.
To me this seems a bit harsh in that we must give up all delay information
because of this one construct. Would it be better to just ignore with a
warning the construct and let the delay go to zero for these cases? You
could get into some weird timing problems by only having partial delays,
so maybe it would be better to just fix the underlying problem.

Thoughts?

You can find the code in pr1877329, but it is basically.
specify
if (B === 1'b1 && CI === 1'b0) ( A => CO ) = (1,1);
if (B === 1'b0 && CI === 1'b1) ( A => CO ) = (1,1);
ifnone ( A => CO ) = (1,1); // elaborate.cc line 3269
endspecify

Cary


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

[Iverilog-devel] Inconsistent initial delay value.

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

I am working on checking the bit based delays in continuous assignments
and ran into some inconsistencies between the real test and the bit based
tests. For example:

assign #1 ieq = ia == 1;

is giving a different initial value than:

assign #1 req = ra == 1.0;

ieq appears to be getting the correct result. A .delay statement defaults
to 'bx output, but the real comparison is giving 'bz. Different bit based
delays are defaulting to 'bz. Attached is a simple example. Any clues
about what might be causing the inconsistencies?

Cary


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Re: [Iverilog-devel] Rule cannot be match in vvp/lexor.lex

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

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

Cary R. wrote:
> Hi Stevem
> 
> It appears that the Cr rule, line 202, in vvp/lexor.lex is no longer
> needed since it cannot be matched. Or at least that is what my version of
> flex is saying.

It does seem redundant at this point. What I was thinking was that
it makes sense for the Cx<...> pseudo-symbols could stand for more
specific rules, but I can't really think of a rational argument for
why. Oh well. Somehow the redundancy should be killed.

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

iD8DBQFHlRllrPt1Sc2b3ikRAm1/AJ9i6js90P8tPy8HLY3JLhwVCkaE+wCg2gCf
DKb0v2A6PRdb44nQlKHrpsM=
=MOs5
-----END PGP SIGNATURE-----

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

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

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

Re: [Iverilog-devel] Accelerating Icarus with NVIDIA's GPUs

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

On Fri, 18 Jan 2008, Stephen Williams wrote:

> That's always been a problem because of the way that the Verilog
> timing model works, and especially how behavioral and netlist code
> interact in a Verilog design. Multi-threading Verilog simulations
> is highly tricky.

Right, especially given that if it's done wrong, the results of your sim
run could be non-deterministic from run to run.  Not necessarily
incorrect, but different or irreproduceable results are equally bad and
will result in unprecedented levels of fanmail.  =)

I've been putting it off for years, but sometime I do need to look at the
generated vvp to see what kinds of event cones (for lack of a better word)
can be extracted.  (I don't mean basic blocks.)  A lot of those bitwise
logic ops can be done as a branchless SWAR op assuming you split your
value into bitwise parallel 01 and XZ value planes.  (SWAR = SIMD within a
register.)  There's more going on calculation-wise but the odds of a
branch mispredict flush are zero as no branches are required.  For
example, run the program below.  I only print one bit, but by extension
you can go as wide as you want.  This is exactly what VCS does if you look
at the generated C code while gcc is in the middle of chewing on it.

-Tony




#include <stdio.h>

/*
 * 00 '0'
 * 01 '1'
 * 10 'Z'
 * 11 'X'
 */
#define MVL(a,b) "01ZX"[((a)&1)*2+((b)&1)]

#define ITER2 for(t3=0;t3<2;t3++) for(t4=0;t4<2;t4++) {
#define TAIL2 t0&=1; t1&=1; printf("%d%d -> %d%d \t ~%c -> %c\n", t3,t4,
t0, t1, MVL(t3,t4), MVL(t0, t1));\
                }printf("\n");
#define ITER4 for(t3=0;t3<2;t3++) for(t4=0;t4<2;t4++) for(t5=0;t5<2;t5++)
for(t6=0;t6<2;t6++) {
#define TAIL4 t0&=1; t1&=1; printf("%d%d & %d%d -> %d%d \t %c & %c ->
%c\n", t3,t4, t5, t6, t0, t1, MVL(t3,t4), MVL(t5,t6), MVL(t0, t1));\
                }printf("\n");

int main(int argc, char **argv)
{
int c, d, t0, t1, t3, t4, t5, t6;

printf("NOT\n===\n");
ITER2
        t0=t3;
        t1=(t3|~t4);
TAIL2


printf("AND\n===\n");
ITER4
        d=(t3|t4)&(t5|t6);
        t0=d&(t3|t5);
        t1=d;
TAIL4


printf("OR\n==\n");
ITER4
        c=(t3^t5)^((t3|t4)&(t5|(t6&t3)));
        t0=c;
        t1=((t4|t6)|c);
TAIL4


printf("XOR\n===\n");
ITER4
        c=t3|t5;
        t0=c;
        t1=(c|(t4^t6));
TAIL4


printf("NAND\n====\n");
ITER4
        d = (t3 | t4) & (t5 | t6);
        c = d & (t3 | t5);
        d = c | (~d);
        t0 = c;
        t1 = d;
TAIL4


printf("NOR\n===\n");
ITER4
        c = (t3 ^ t5) ^ ((t3 | t4) & (t5 | (t6 & t3)));
        d = c | (~((t4 | t6) | c));
        t0 = c;
        t1 = d;
TAIL4


printf("XNOR\n====\n");
ITER4
        c = t3 | t5;
        d = c | (~(c | (t4 ^ t6)));
        t0 = c;
        t1 = d;
TAIL4


exit(0);
}

Re: [Iverilog-devel] Accelerating Icarus with NVIDIA's GPUs

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

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

Cary R. wrote:
> --- Sumit Gupta <su...@nv...> wrote: 
>> I am wondering if anyone has considered using GPU-based computing to
>> accelerate the Icarus Verilog simulator.
> 
> This certainly is interesting, but I think we would need to make the
> runtime multi threaded before starting something this ambitious. With the
> current crop of Duo and Quad machines available adding multi threading to
> Icarus has been one my mind. The problem is finding the time to work on
> it.

That's always been a problem because of the way that the Verilog
timing model works, and especially how behavioral and netlist code
interact in a Verilog design. Multi-threading Verilog simulations
is highly tricky.

>> NVIDIA's GPUs have evolved over the years to become fully programmable,
>> massively parallel architectures. There are 128 processor cores with
>> floating point units in a NVIDIA GPU today delivering anywhere between
>> 120 to 350 GFLOPs of performance depending on your application.
> 
> Much of Icarus is bit based, so FLOPs are not as important as for an
> analog simulator. Though with those kind of numbers I'm sure they would be
> more than fast enough ;-).

Could be especially interesting when (if) analogue/mixed signal
gets added in to Icarus Verilog. I'm weak on how exactly all that
would work, but it seems likely that resolving a bunch of drivers
may be something that can usefully be handed off to a co-processor.


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

iD8DBQFHkUlErPt1Sc2b3ikRAigaAKDH+AYIQ8bkrOIG/x1cUDloSA/3oQCghY2V
1oSixJSHpu5LLv3hwmHSI+Q=
=8RCk
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Accelerating Icarus with NVIDIA's GPUs

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

--- Sumit Gupta <su...@nv...> wrote: 
> I am wondering if anyone has considered using GPU-based computing to
> accelerate the Icarus Verilog simulator.

This certainly is interesting, but I think we would need to make the
runtime multi threaded before starting something this ambitious. With the
current crop of Duo and Quad machines available adding multi threading to
Icarus has been one my mind. The problem is finding the time to work on
it.

> NVIDIA's GPUs have evolved over the years to become fully programmable,
> massively parallel architectures. There are 128 processor cores with
> floating point units in a NVIDIA GPU today delivering anywhere between
> 120 to 350 GFLOPs of performance depending on your application.

Much of Icarus is bit based, so FLOPs are not as important as for an
analog simulator. Though with those kind of numbers I'm sure they would be
more than fast enough ;-).

Thanks for the information,

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] Delays in continuous assignment

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

--- Stephen Williams <st...@ic...> wrote:
> I don't think it's an implementation difference so much as a lack
> of implementation in the non-logic cases. It has so non turned up
> in the real works that no one seemed to notice that arithmetic nodes
> don't have delays:-)

And then there is me! It turns out that when you want to do rudimentary
analog modeling adding some delay at the right place can be the difference
between almost working and working correctly. 
 
> At the ivl core (and ivl_target.h) stage, I think all the delays should
> be handled like with the NetLogic devices. In the case of the NetNode
> objects, it may make sense to create a base class to generalize all
> the devices that have a single output that may be delayed (that would
> include the logic gates and the arithmetic gates) as a way to factor
> the delay handling code.

What was confusing me is I had not noticed the NetNode (base class)
pointer was only used when more than one different subclass object was
used in the same routine.

The delay information is actually kept in the NetObj class (parent of
NetNode), so I will look there as a place to generalize the code.

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

[Iverilog-devel] Accelerating Icarus with NVIDIA's GPUs

[Sumit G. <su...@nv...>]

Hi

Steve suggested I write to this group.

I am wondering if anyone has considered using GPU-based computing to
accelerate the Icarus Verilog simulator.

NVIDIA's GPUs have evolved over the years to become fully programmable,
massively parallel architectures. There are 128 processor cores with
floating point units in a NVIDIA GPU today delivering anywhere between
120 to 350 GFLOPs of performance depending on your application. We have
a C-based programming model called CUDA that has a wide developer
community around it.

Getting started just requires a NVIDIA GeForce 8-series GPU (88xx) and
the CUDA software tools are freely available at:
http://www.nvidia.com/cuda=20

I think the opportunity to parallelize will be in running many
evaluations on different threads and then coalescing the results.
NVIDIA's GPUs are very good at data number crunching and can handle
1000s of parallel threads.  However, doing a pure event-driven simulator
port may not be successful due to control-intensive nature of the algo.

But I am in no way an expert.

Regards
Sumit
(NVIDIA employee)

-------------------------------------------------------------------------=
----------
This email message is for the sole use of the intended recipient(s) and m=
ay contain
confidential information.  Any unauthorized review, use, disclosure or di=
stribution
is prohibited.  If you are not the intended recipient, please contact the=
=20sender by
reply email and destroy all copies of the original message.
-------------------------------------------------------------------------=
----------

Re: [Iverilog-devel] Delays in continuous assignment

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

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

Cary R. wrote:
> It appears that only the bit operators support a delayed continuous
> assignment. I assume that the mathematical, comparison, shift, functions
> and logical operators are expected to have them as well, but they have not
> been fully implemented. I looking in elab_net.cc and it appears that this
> was started for some of these e.g.(elaborate_net_add_). For the bit
> operators the delays were added directly to the object, but for the
> addition/subtraction and the others objects they were added to a NetNode
> object that is then added to the design. Why the difference?

I don't think it's an implementation difference so much as a lack
of implementation in the non-logic cases. It has so non turned up
in the real works that no one seemed to notice that arithmetic nodes
don't have delays:-)

At the vvp level, all delays can (and should) be handled by a delay
node.

At the ivl core (and ivl_target.h) stage, I think all the delays should
be handled like with the NetLogic devices. In the case of the NetNode
objects, it may make sense to create a base class to generalize all
the devices that have a single output that may be delayed (that would
include the logic gates and the arithmetic gates) as a way to factor
the delay handling code.

> So what I'm after is a bit of a road map. I'm willing to work through all
> the tedium to add these and make sure things work correctly (even for real
> values), but some insight would make it much easier. I'm assuming the
> basic path is attach the delays to an object, that object will somehow
> pass this onto an IVL_LPM object. We will need to add an ivl_lpm_delay()
> function to get the delays for the code generator. Modify the code
> generator to create the appropriate .delay functor. Make sure the delay
> functor works correctly with real values.
> 
> Any help would be greatly appreciated!


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

iD8DBQFHkPROrPt1Sc2b3ikRAprRAKCAWDowtTMLHiHBGQKMH42LhCa4ygCghfw3
Zx8Liasp+ye3B+smv2YEUB8=
=UUYW
-----END PGP SIGNATURE-----

[Iverilog-devel] Delays in continuous assignment

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

It appears that only the bit operators support a delayed continuous
assignment. I assume that the mathematical, comparison, shift, functions
and logical operators are expected to have them as well, but they have not
been fully implemented. I looking in elab_net.cc and it appears that this
was started for some of these e.g.(elaborate_net_add_). For the bit
operators the delays were added directly to the object, but for the
addition/subtraction and the others objects they were added to a NetNode
object that is then added to the design. Why the difference?

So what I'm after is a bit of a road map. I'm willing to work through all
the tedium to add these and make sure things work correctly (even for real
values), but some insight would make it much easier. I'm assuming the
basic path is attach the delays to an object, that object will somehow
pass this onto an IVL_LPM object. We will need to add an ivl_lpm_delay()
function to get the delays for the code generator. Modify the code
generator to create the appropriate .delay functor. Make sure the delay
functor works correctly with real values.

Any help would be greatly appreciated!

Cary


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Re: [Iverilog-devel] Patch for const integer foreign = "" attributes

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

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

Cary R. wrote:
> --- Stephen Williams <st...@ic...> wrote:
>  
>> My SystemVerilog draft is too old to show this, but I think the
>> attribute assignment may include a type declaration along with the
>> assignment. That would mean that in principle the existing attribute
>> code can be extended in a SV-ish way to make the given code work.
>> I think *this* is what we want to do.
> 
> I agree we should code to a standard. If this is supported in SV we need
> to know what the particulars are. Unfortunately it appears the two people
> most likely to implement it do not have access to the SV standard
> (1800-2005).
> 
>>From memory I don't think the SV standard is too expensive, but it uses
> the 1364-2005 standard as a base document. I only have a copy of
> 1364-2001, so I'm probably not going to spend the money to get both
> standards just to enhance iverilog.

I have a copy of IEEE1364-1005 (printed) so I can make proper use of
the SystemVerilog standard. These standards are somewhat painful to
buy without funding, but I'll look into it.

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

iD8DBQFHjSN2rPt1Sc2b3ikRAqIXAJ0Q0rSNXxNnfozNqFc2jPWoNDuPbwCfWfLO
gTmbW7baMjvyrvzS0sI7D9U=
=4vF3
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Patch for const integer foreign = "" attributes

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

--- Stephen Williams <st...@ic...> wrote:
 
> My SystemVerilog draft is too old to show this, but I think the
> attribute assignment may include a type declaration along with the
> assignment. That would mean that in principle the existing attribute
> code can be extended in a SV-ish way to make the given code work.
> I think *this* is what we want to do.

I agree we should code to a standard. If this is supported in SV we need
to know what the particulars are. Unfortunately it appears the two people
most likely to implement it do not have access to the SV standard
(1800-2005).

>From memory I don't think the SV standard is too expensive, but it uses
the 1364-2005 standard as a base document. I only have a copy of
1364-2001, so I'm probably not going to spend the money to get both
standards just to enhance iverilog.

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] Patch for const integer foreign = "" attributes

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

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

Stephen Williams wrote:
> I'm wondering if this attribute format is SystemVerilog-ish, given
> that at least some other Verilog tools parse it. (Otherwise, Stefan
> wouldn't be encountering it.) If so, can someone track down the
> pertinent SystemVerilog babble? We may be able to actually do a
> proper job of this, if it is documented somewhere. Why not add
> smarter attribute to Icarus Verilog?

I've done a little digging. The "const" keyword in the example
appears to indeed be a part of SystemVerilog and is similar to
the localparam in behavior. (Except it can be used in a few more
places.)

My SystemVerilog draft is too old to show this, but I think the
attribute assignment may include a type declaration along with the
assignment. That would mean that in principle the existing attribute
code can be extended in a SV-ish way to make the given code work.
I think *this* is what we want to do.

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

iD8DBQFHjQtvrPt1Sc2b3ikRAikiAKDtIc8sSBecuiUwPlreuUfbbvRtagCbB2Oq
+vviAmHOFcU8ZvHLa6d6PXw=
=VMNd
-----END PGP SIGNATURE-----

[Iverilog-devel] Patch for const integer foreign = "" attributes

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

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


PR1869719 in Patches brings up the fact that nccoex (what is that?)
generates attributes of this form in Verilog that it generates.
The patch is a good start, but it parses only a very specific
case, and parses it as an unattached (and ignored) attributes.

I'm wondering if this attribute format is SystemVerilog-ish, given
that at least some other Verilog tools parse it. (Otherwise, Stefan
wouldn't be encountering it.) If so, can someone track down the
pertinent SystemVerilog babble? We may be able to actually do a
proper job of this, if it is documented somewhere. Why not add
smarter attribute to Icarus Verilog?

Perhaps NC Verilog documentation points us in the right direction.
(I'm guessing that nccoex is "NC COEXist" or something like that.)

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

iD8DBQFHjPoWrPt1Sc2b3ikRAk4zAKCKVYniJHyKN5VuHiyGJ8i9pDl0UACfXgCt
/Z7EO5jCiSw+E4DYxOHCytE=
=pkS8
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Real constants in compiler output.

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

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

Cary R. wrote:
> While working on pr1869769 (real comparisons in cont. assign.) I have run
> into a number of slightly related problems. The major one I have left is
> that real constants Cr<xxx> are not handled very well. The code generator
> prints them with a plain %lg which limits the precision of the value
> passed to the run time. Is there a system agnostic way to find the maximum
> precision so we can pass that to %g?

Better would be to use the same sign-mantissa-exponent form as
is generated for the %loadi/wr instruction to get a real value.
This format is also clearly documented, along with ways to carry
the various zeros, infinities and NaNs.

> The other half of the problem is that when the real number prints with an
> exponent the runtime crashes. This is because a '+' is not considered a
> valid character in a Cr<xxx> constant and after fixing that it complains
> about an invalid name which I am assuming is the '+' again. Should I just
> add '+' as need to fix things or should I submit this as a separate bug
> report for a more thorough analysis?

This is an issue in the lexor. I started creating an IDENTIFIER
rule in the lexor.lex that is specially for matching Cr<...> and
its internal complexities. Just fix that.

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

iD4DBQFHjNR2rPt1Sc2b3ikRAnyPAJjiLTdOK7YkS6li+XyzKgPy4sDHAJ9cMyP7
ZQVrNoL1wOPZ8LLT/xj97g==
=5zkE
-----END PGP SIGNATURE-----

[Iverilog-devel] Real constants in compiler output.

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

While working on pr1869769 (real comparisons in cont. assign.) I have run
into a number of slightly related problems. The major one I have left is
that real constants Cr<xxx> are not handled very well. The code generator
prints them with a plain %lg which limits the precision of the value
passed to the run time. Is there a system agnostic way to find the maximum
precision so we can pass that to %g?

The other half of the problem is that when the real number prints with an
exponent the runtime crashes. This is because a '+' is not considered a
valid character in a Cr<xxx> constant and after fixing that it complains
about an invalid name which I am assuming is the '+' again. Should I just
add '+' as need to fix things or should I submit this as a separate bug
report for a more thorough analysis?

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] CFLAGS not set in vvp directory

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

Cary -

On Mon, Jan 14, 2008 at 02:35:33PM -0800, Cary R. wrote:
> draw_tt.c is used to generate tables.cc, it uses HOSTCC and not CC. Why is
> this?

I haven't done it in a while, but it is possible to cross-compile
icarus.  HOSTCC is presumably left over from that effort, it represents
something that is run at build-time, and is not code that ends up
in the final executable.

> The compilation does not reference CFLAGS. If you compile it with
> -Wall a few simple warnings are present. Should this be changes to
> reference CC, use CFLAGS and clean up the warnings?

Maybe HOSTCCFLAGS, that is nominally set to the same value as CFLAGS?
I'll look into it.

      - Larry

[Iverilog-devel] CFLAGS not set in vvp directory

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

DSteve,

There are three C files in the vvp direcdtory: draw_tt.c, libvpi.c and
vpip_format.c.

draw_tt.c is used to generate tables.cc, it uses HOSTCC and not CC. Why is
this? The compilation does not reference CFLAGS. If you compile it with
-Wall a few simple warnings are present. Should this be changes to
reference CC, use CFLAGS and clean up the warnings?

libvpi.c is a library stub and compiles fine with -Wall. It does not
reference CFLAGS. Should the Makefile creation be changed to define CFLAGS
like in the other Makefiles and then use it when compiling this file?

vpip_format.c is used to create formated strength information. Like
libvpi.c it compiles fine with -Wall, but it does reference an undefined
CFLAGS. Of the three files this one really should use a correct CFLAGS
since you may want to debug the code and you would need the -g for that to
work. As a minimum I think this one should be fixed.

For consistency I think everything should be be fixed to use CC/CFLAGS and
the warnings in draw_tt.c should be cleaned up, but there may be a reason
things should be left as is. Let me know what you think.

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] Snapshot today?

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

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


Hmm, this could be slightly tricky.

Larry Doolittle wrote:
> On Fri, Jan 11, 2008 at 02:20:08PM -0800, Stephen Williams wrote:
>> I find myself waiting on simulations today so am looking into making
>> a devel snapshot. Are there any outstanding patches that people really
>> want to see in this snapshot? I'm in the process of going through the
>> Patches tracker to apply those already submitted patches.
> 
> Not-so-minor issue I just ran into installing on a fresh computer
> (I'm rebuilding my laptop -- Gutsy Gibbon, not that it matters).
> 
> The build rules for eval_bool.o don't include a proper include
> directory to search for _pli_types.h.
> 
> gcc -DHAVE_CVS_IDENT=1 -I. -I../../verilog/tgt-vvp/..  -DHAVE_CONFIG_H -fPIC -Wall -g -O2 -MD -c ../../verilog/tgt-vvp/eval_bool.c -o eval_bool.o
> ../../verilog/tgt-vvp/eval_bool.c:23:57: error: _pli_types.h: No such file or directory
> ../../verilog/tgt-vvp/eval_bool.c: In function `draw_number_bool64':
> ../../verilog/tgt-vvp/eval_bool.c:67: error: expected ')' before 'PLI_UINT64_FMT'
> ../../verilog/tgt-vvp/eval_bool.c:67: warning: too few arguments for format
> make[1]: *** [eval_bool.o] Error 1
> 
> I think I never hit this before because I always had a previous valid
> install, so it finds _pli_types.h from that .. but I'm not sure.
> It looks like adding -I.. will do.  <tappety-typ>  Yup, that works, I checked.

The general idea is that code generator source should not ever
peek into other Icarus Verilog source. They are supposed to be
separable. Also, although _pli_types.h is sorta public, I don't
think eval_bool.c should include it at all.

It turns out that eval_bool.c is using PLI_UINT64_FMT to match
a uint64_t; it should be using the STDMACROS from <inttypes.h>.
I've pushed a change into git. You'll need to rerun autoconf.sh
to make the configure scripts, and reconfigure for the change to
take effect. This should only be a problem on systems where the
inttypes.h header file doesn't exist.

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

iD8DBQFHi6HRrPt1Sc2b3ikRAnPVAJ9BM6QUkxk+jGPXBGrhGhH1uDpRLACfeOtV
QE42kGb+Ya9ffBqGm55AeAY=
=Ekau
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Snapshot today?

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

On Fri, Jan 11, 2008 at 02:20:08PM -0800, Stephen Williams wrote:
> I find myself waiting on simulations today so am looking into making
> a devel snapshot. Are there any outstanding patches that people really
> want to see in this snapshot? I'm in the process of going through the
> Patches tracker to apply those already submitted patches.

Not-so-minor issue I just ran into installing on a fresh computer
(I'm rebuilding my laptop -- Gutsy Gibbon, not that it matters).

The build rules for eval_bool.o don't include a proper include
directory to search for _pli_types.h.

gcc -DHAVE_CVS_IDENT=1 -I. -I../../verilog/tgt-vvp/..  -DHAVE_CONFIG_H -fPIC -Wall -g -O2 -MD -c ../../verilog/tgt-vvp/eval_bool.c -o eval_bool.o
../../verilog/tgt-vvp/eval_bool.c:23:57: error: _pli_types.h: No such file or directory
../../verilog/tgt-vvp/eval_bool.c: In function `draw_number_bool64':
../../verilog/tgt-vvp/eval_bool.c:67: error: expected ')' before 'PLI_UINT64_FMT'
../../verilog/tgt-vvp/eval_bool.c:67: warning: too few arguments for format
make[1]: *** [eval_bool.o] Error 1

I think I never hit this before because I always had a previous valid
install, so it finds _pli_types.h from that .. but I'm not sure.
It looks like adding -I.. will do.  <tappety-typ>  Yup, that works, I checked.

This problem is new (as of commit 21730ab228e5812f8b09b4f9b50843f343b99321),
we just added the include so we could print a uint64_t properly
(standards-compliantly).

   - Larry

Re: [Iverilog-devel] Wondering aloud about extended operand lists

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

--- Anthony J Bybell <net...@nc...> wrote:
> It's been a while since I've read that vvp opcodes doc, however note the
> following cut and paste typos in opcodes.txt:
> 
> | * %xor <dst>, <src>, <wid>
> |
> | This does a bitwise exclusive or (^) of the <src> and <dst> vector,
> | and leaves the result in the <dst> vector. xor is this:
> |
> |        0 xnor 0 --> 0
> |        0 xnor 1 --> 1
> |        1 xnor 0 --> 1
> |        1 xnor 1 --> 0
> |        otherwise    x

Since I was already editing opcodes.txt I fixed these in a patch I am
submitting now.

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] Wondering aloud about extended operand lists

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

On Fri, 11 Jan 2008, Stephen Williams wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> There are a handful of instructions in the vvp opcodes set that
> are really pressed for operands. They are reduced to using implicit
> index variables to carry operands that really can generally be
> immediate.

It's been a while since I've read that vvp opcodes doc, however note the
following cut and paste typos in opcodes.txt:

| * %xor <dst>, <src>, <wid>
|
| This does a bitwise exclusive or (^) of the <src> and <dst> vector,
| and leaves the result in the <dst> vector. xor is this:
|
|        0 xnor 0 --> 0
|        0 xnor 1 --> 1
|        1 xnor 0 --> 1
|        1 xnor 1 --> 0
|        otherwise    x

-Tony

Re: [Iverilog-devel] Wondering aloud about extended operand lists

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

--- Stephen Williams <st...@ic...> wrote:

> There are a handful of instructions in the vvp opcodes set that
> are really pressed for operands. They are reduced to using implicit
> index variables to carry operands that really can generally be
> immediate.
> 
> So I'm wondering aloud if maybe it *is* time to extend the size
> of the opcode space. In particular, I've been thinking of
> adding to the second union a pointer to a vvp_code_extend_s
> struct. This struct can be *much* more liberal, and can carry
> more number values. This may wind up allowing us to replace
> several hackish instructions with instructions with longer
> operand lists.

Should this be done with the second argument or should it be collapsed
down to a single argument. Something like:

struct vvp_code_s {
  vvp_code_fun opcode; /* This determines the number/type of arguments. */

  union {
    some_inclusive_arg_type_union single_arg;
    some_inclusive_arg_type_union *array_of_args;
  }
}

There is probably a trade off somewhere based on the argument distribution
which may change as the opcodes are reviewed. Having a larger/arbitrary
number of arguments would allow us to build more complex opcodes that
should help performance (both speed and memory).

Cary


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs