iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] Two people working on pr1879226

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

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

Larry Doolittle wrote:
> Guys -
> 
> On Mon, Jan 28, 2008 at 04:47:54PM -0800, Cary R. wrote:
>> --- Stephen Williams <st...@ic...> wrote:
>>  
>>> So the status of this is that I'm waiting for Larry to integrate
>>> these suggestions and the test program, then he will update the
>>> submitted patch in the Patches tracker?
>> That is my understanding. I sent him my modified test file.
> 
> Mine, too.  At the moment I'm waiting to hear from Uwe.
> I'd like to have some confidence it doesn't bomb out on
> his real problem.
> 
> Also, I don't know the process to follow for the test bench.
> Shall I attach Cary's file (which does work) separately to the
> patch tracker, along with the patch itself?

Separate or zipped together, as long as they are in the same
place so that when I go to apply the patch I don't have to go
hunting for the test suite program as well. I like to update
the ivtest cvs and iverilog git at the same time.


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

iD8DBQFHn0ZurPt1Sc2b3ikRAvMqAKCiqYblkwRdVCFerXNzV7x49TOJLACfUBd2
3sfyQQ+1J+s79s6SImySNag=
=0+X/
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Two people working on pr1879226

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

--- Larry Doolittle <ldo...@re...> wrote:

> Also, I don't know the process to follow for the test bench.
> Shall I attach Cary's file (which does work) separately to the
> patch tracker, along with the patch itself?

I normally put them both in a zip file so they don't get separated.

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] Two people working on pr1879226

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

Guys -

On Mon, Jan 28, 2008 at 04:47:54PM -0800, Cary R. wrote:
> --- Stephen Williams <st...@ic...> wrote:
>  
> > So the status of this is that I'm waiting for Larry to integrate
> > these suggestions and the test program, then he will update the
> > submitted patch in the Patches tracker?
> 
> That is my understanding. I sent him my modified test file.

Mine, too.  At the moment I'm waiting to hear from Uwe.
I'd like to have some confidence it doesn't bomb out on
his real problem.

Also, I don't know the process to follow for the test bench.
Shall I attach Cary's file (which does work) separately to the
patch tracker, along with the patch itself?

   - Larry

Re: [Iverilog-devel] Two people working on pr1879226

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

--- Stephen Williams <st...@ic...> wrote:
 
> So the status of this is that I'm waiting for Larry to integrate
> these suggestions and the test program, then he will update the
> submitted patch in the Patches tracker?

That is my understanding. I sent him my modified test file.

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] Two people working on pr1879226

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

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


So the status of this is that I'm waiting for Larry to integrate
these suggestions and the test program, then he will update the
submitted patch in the Patches tracker?

Cary R. wrote:
> --- Larry Doolittle <ldo...@re...> wrote:
> 
>>> I would also change the comment to be "If
>>> the entire value is shifted away connect the output to a constant V0
>> or
>>> for arithmetic right shift ">>>"  connect all bits to the MSB."
>> OK.  Except that additional detail applies whether or not all
>> of the value is shifted away.  How about putting it in front of the
>> 	if (op_ == 'R') {
>> block?
> 
> Yes the description of what the previous block is doing could go there
> instead. You still need something to say that the new conditional is
> checking for all the bits being shifted. 
> 
>> I'm quite curious to find out if that new assert() in netlist.cc ever
>> gets triggered in the wild.
> 
> The test suite and my local tests pass without any additional failures.
> 
> I'm sending you my modified test code in a separate message that you need
> to include with the final patch so Steve can add it to the test suite. I
> also changed the pr to make you be the "Assigned To:" person. The original
> test code Uwe submitted has some problems that make it not work correctly
> with the test suite and it did not check all the cases ARS can be either 0
> or 1 depending on the MSB.

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

iD8DBQFHnnT4rPt1Sc2b3ikRAo8eAKDuq6wGgGVJBFEcd7MCZpkMwGapaQCgokSX
WLtmywTzZPiZO9mSvICUZ+g=
=0IkE
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Bug/Feature request ownership guidelines

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

--- Stephen Williams <st...@ic...> wrote:
 
> This looks good. I should add that the assignee should arrange
> to monitor the PR if not already. If anybody wants to claim a
> bug report but is not in the drop-down list, that person can be
> added as a developer to the iverilog project on sourceforge.

I think this comes for free when you take ownership. Of course you
probably don't notice this since you get a copy of everything!

> I think that conversations in the comments of the PR should certainly
> be avoided, but I wouldn't necessarily keep it off the iverilog-devel
> list. Conversations like "What is your schedule?" or "Can I help?"
> can be kept point-to-point, but technical discussions amongst those
> who choose to collaborate (or critique) on a PR fix make good sense
> for the iverilog-devel list. Preserving the lore may prove useful
> in unanticipated ways.

Agreed. I was more thinking the "I'm interested in working on this what is
the status" type conversations. Technical conversations should always be
welcomed on iverilog-devel!

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] Bug/Feature request ownership guidelines

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

--- Larry Doolittle <ldo...@re...> wrote:
 
> I suppose you mean to suggest private email, not use of the SF bug
> tracker comments?

Yes, private email is what I meant. Using either the iverilog-devel
mailing list or the tracker can generate email messages to a lot more
people than are likely interested in the specifics of the conversation.

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] Bug/Feature request ownership guidelines

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

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


This looks good. I should add that the assignee should arrange
to monitor the PR if not already. If anybody wants to claim a
bug report but is not in the drop-down list, that person can be
added as a developer to the iverilog project on sourceforge.


Cary R. wrote:
> I believe we all agree that the "Assigned To" field should be used to
> indicate ownership of a particular report. Here is some elaboration on
> what I think this should signify and how other should interact with a
> claimed report.
> 
> 1. The "Assigned To" person is responsible for submitting the patch and
> updated test code if the original is inadequate or missing.
> 
> 2. A claimed patch should be something you plan to actively work on within
> the next week. If for some reason your plans change you should change the
> "Assigned To:" field back to None or at least add a comment stating that
> you are being delayed for a SPECIFIED amount of time.
> 
> 3. If you want to help out on a claimed patch you should contact the
> person who claimed the patch originally. This allows both parties to know
> where the other is in tracking down and fixing the problem. I believe this
> communication should not be over the iverilog-devel list.

I think that conversations in the comments of the PR should certainly
be avoided, but I wouldn't necessarily keep it off the iverilog-devel
list. Conversations like "What is your schedule?" or "Can I help?"
can be kept point-to-point, but technical discussions amongst those
who choose to collaborate (or critique) on a PR fix make good sense
for the iverilog-devel list. Preserving the lore may prove useful
in unanticipated ways.

> 4. Ownership can be given to a different person, but it should normally
> only be taken if a reasonable effort (email AND a post to the report)
> fails to generate a reply in one week. Obviously for bugs that are or
> become critical some flexibility is required.



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

iD8DBQFHnmXErPt1Sc2b3ikRAkReAJ0YI/i7Z9ipEgyn2qv97u2XDrlbnwCfTbuM
qylWCQJnyEAuxSsVUU6JPIo=
=6i4p
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Bug/Feature request ownership guidelines

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

Cary -

On Mon, Jan 28, 2008 at 03:06:30PM -0800, Cary R. wrote:
> I believe we all agree that the "Assigned To" field should be used to
> indicate ownership of a particular report. Here is some elaboration on
> what I think this should signify and how other should interact with a
> claimed report.
> 
> 1. The "Assigned To" person is responsible for submitting the patch and
> updated test code if the original is inadequate or missing.
> 
> 2. A claimed patch should be something you plan to actively work on within
> the next week. If for some reason your plans change you should change the
> "Assigned To:" field back to None or at least add a comment stating that
> you are being delayed for a SPECIFIED amount of time.
> 
> 3. If you want to help out on a claimed patch you should contact the
> person who claimed the patch originally. This allows both parties to know
> where the other is in tracking down and fixing the problem. I believe this
> communication should not be over the iverilog-devel list.

I suppose you mean to suggest private email, not use of the SF bug
tracker comments?

> 4. Ownership can be given to a different person, but it should normally
> only be taken if a reasonable effort (email AND a post to the report)
> fails to generate a reply in one week. Obviously for bugs that are or
> become critical some flexibility is required.
> 
> Comments? 

Those are all very reasonable guidelines.

   - Larry

[Iverilog-devel] Bug/Feature request ownership guidelines

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

I believe we all agree that the "Assigned To" field should be used to
indicate ownership of a particular report. Here is some elaboration on
what I think this should signify and how other should interact with a
claimed report.

1. The "Assigned To" person is responsible for submitting the patch and
updated test code if the original is inadequate or missing.

2. A claimed patch should be something you plan to actively work on within
the next week. If for some reason your plans change you should change the
"Assigned To:" field back to None or at least add a comment stating that
you are being delayed for a SPECIFIED amount of time.

3. If you want to help out on a claimed patch you should contact the
person who claimed the patch originally. This allows both parties to know
where the other is in tracking down and fixing the problem. I believe this
communication should not be over the iverilog-devel list.

4. Ownership can be given to a different person, but it should normally
only be taken if a reasonable effort (email AND a post to the report)
fails to generate a reply in one week. Obviously for bugs that are or
become critical some flexibility is required.

Comments? 

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] Two people working on pr1879226

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

--- Larry Doolittle <ldo...@re...> wrote:

> > I would also change the comment to be "If
> > the entire value is shifted away connect the output to a constant V0
> or
> > for arithmetic right shift ">>>"  connect all bits to the MSB."
> 
> OK.  Except that additional detail applies whether or not all
> of the value is shifted away.  How about putting it in front of the
> 	if (op_ == 'R') {
> block?

Yes the description of what the previous block is doing could go there
instead. You still need something to say that the new conditional is
checking for all the bits being shifted. 

> I'm quite curious to find out if that new assert() in netlist.cc ever
> gets triggered in the wild.

The test suite and my local tests pass without any additional failures.

I'm sending you my modified test code in a separate message that you need
to include with the final patch so Steve can add it to the test suite. I
also changed the pr to make you be the "Assigned To:" person. The original
test code Uwe submitted has some problems that make it not work correctly
with the test suite and it did not check all the cases ARS can be either 0
or 1 depending on the MSB.

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] Two people working on pr1879226

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

Cary -

On Mon, Jan 28, 2008 at 01:31:22PM -0800, Cary R. wrote:
> Though I would remove the disabled "if" since it serves no purpose other
> than to confuse someone later.

OK.  I almost took it out, but left it in to keep the diff small.
Also, I wasn't yet sure that postponing the test would actually work.
Uwe, have you tested the result?  Has anyone run this patch through
the test suite?

> I would also change the comment to be "If
> the entire value is shifted away connect the output to a constant V0 or
> for arithmetic right shift ">>>"  connect all bits to the MSB."

OK.  Except that additional detail applies whether or not all
of the value is shifted away.  How about putting it in front of the
	if (op_ == 'R') {
block?

> What is interesting is that if the conditional was correct >= vs > we
> would have known exactly where the bug or in this case missing
> functionality was and no incorrect code would have been generated.

Right.  I noticed that part a couple of days ago, and almost submitted
a patch to just fix that conditional.  But that seemed a little non-
constructive, and I also wanted to understand how the problem propagated.
I'm quite curious to find out if that new assert() in netlist.cc ever
gets triggered in the wild.

   - Larry

Re: [Iverilog-devel] Two people working on pr1879226

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

--- Larry Doolittle <ldo...@re...> wrote:

> Hey, competition is good!  ;-)

Yes it is, What you did is almost exactly the same as what I came up with.
Though I would remove the disabled "if" since it serves no purpose other
than to confuse someone later. I would also change the comment to be "If
the entire value is shifted away connect the output to a constant V0 or
for 
arithmetic right shift ">>>"  connect all bits to the MSB."
  
> > It may be time to consider formalizing a method for claiming bug
> > reports and feature requests, as progress on these bugs and features
> > is really heating up. It seems to me that the "Assigned To:"
> > field in the trackers is perfect for this.
> 
> It is, but that shouldn't keep others from jumping in if they have
> something helpful to add.

I agree "Assign To:" is what we should be using and is what I used in this
case.

> In this case, the construct that Uwe found is very close to what
> I use routinely, so I really really wanted this bug fixed before
> it decided to bite me, too.

What is interesting is that if the conditional was correct >= vs > we
would have known exactly where the bug or in this case missing
functionality was and no incorrect code would have been generated.

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] Two people working on pr1879226

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

Steve and Cary -

On Mon, Jan 28, 2008 at 12:10:00PM -0800, Stephen Williams wrote:
> Are you working on pr1879226?

I don't have anything left to add, until and unless I get comments
on accuracy of my analysis or the efficacy of my patch.

> It looks like Cary took ownership by
> setting the "Assigned to:" field, as I started doing as well. But
> it appears that Larry just submitted a potential patch for exactly
> this PR.

Hey, competition is good!  ;-)

Seriously, I did check repeatedly on mailing lists and the bug/patch
trackers to make sure that I wasn't wasting my time.  I also figured
that the time I spent looking for the bug was also time learning more
about Icarus' internals, and would therefore not be truly wasted even
if someone else found and fixed the bug first.  Symmetry arguments
tell me that there's nothing wrong with my fixing a bug that someone
else is also investigating.

> It may be time to consider formalizing a method for claiming bug
> reports and feature requests, as progress on these bugs and features
> is really heating up. It seems to me that the "Assigned To:"
> field in the trackers is perfect for this.

It is, but that shouldn't keep others from jumping in if they have
something helpful to add.

In this case, the construct that Uwe found is very close to what
I use routinely, so I really really wanted this bug fixed before
it decided to bite me, too.

   -  Larry

[Iverilog-devel] Two people working on pr1879226

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

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


Cary and Larry,

Are you working on pr1879226? It looks like Cary took ownership by
setting the "Assigned to:" field, as I started doing as well. But
it appears that Larry just submitted a potential patch for exactly
this PR.

It may be time to consider formalizing a method for claiming bug
reports and feature requests, as progress on these bugs and features
is really heating up. It seems to me that the "Assigned To:"
field in the trackers is perfect for this.
- --
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

iD8DBQFHnjaYrPt1Sc2b3ikRAjNBAJ9Q24kcDollUZqgjwRoMfXCZ4brRACgpfU9
SrJs0ivdPBL+gxDXvJb7z1I=
=BZQ0
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] System Verilog versus Icarus

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

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


> I see that Cary is getting gtkwave doing nifty-magical waveform
> things, too, so it all seems to be working well together.

Tony's doing most of the real work! I'm only providing
guidance/suggestions and a few example files. Though I do agree it is
starting to look really nice!

Cary


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

Re: [Iverilog-devel] System Verilog versus Icarus

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

On Sat, 26 Jan 2008, Stephen Williams wrote:

> Yeah, I know you've got string support in gtkwave and that may
> be a great way to support symbolic enums. I haven't thought it
> through because there's always something else to do:-/

I hear you.  I'm tasked working on two projects at work.


> I see that Cary is getting gtkwave doing nifty-magical waveform
> things, too, so it all seems to be working well together.

Yeah, lately it's been reworking of the user interface and analog
rendering code such that the view looks and acts like most mainstream gtk
apps.  The 3.1.4 ("pi") release should cover most long-standing user
complaints after which I'm sure users will come up with a host of new
"while you're at it..." ones, but none can ever be as dreaded as users
asking for "reload".  Fortunately, google bailed me out on that one.  =)

-Tony

Re: [Iverilog-devel] System Verilog versus Icarus

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

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

Anthony J Bybell wrote:
> On Fri, 25 Jan 2008, Stephen Williams wrote:
> 
>> 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.
> 
> The viewer's supported strings in vcd files for years.  See the attached
> file.  Obviously, whatever the datatype is for enum/string/whatever can be
> properly handled in the $var declarations once they're defined.  The only
> limitation is no spaces, but proxy characters or escapes can fix that
> easily.

Yeah, I know you've got string support in gtkwave and that may
be a great way to support symbolic enums. I haven't thought it
through because there's always something else to do:-/

I see that Cary is getting gtkwave doing nifty-magical waveform
things, too, so it all seems to be working well together.

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

iD8DBQFHm22LrPt1Sc2b3ikRAnm8AKCi2QQvkQXtPnr5975YN4JL7MUq7ACdEM0V
6debPqd9Sl7FAb7ty+Ks87g=
=iExa
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] System Verilog versus Icarus

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

On Fri, 25 Jan 2008, Stephen Williams wrote:

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

The viewer's supported strings in vcd files for years.  See the attached
file.  Obviously, whatever the datatype is for enum/string/whatever can be
properly handled in the $var declarations once they're defined.  The only
limitation is no spaces, but proxy characters or escapes can fix that
easily.

So unless you're planning on doing something wacky, it should be quite
painless.  Note that all the gtkwave-specific filetypes support strings
natively though none of the vcd converters can handle them yet.

-t

[Iverilog-devel] Simulation time in a continuous assignment.

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

Given this piece of code

module top;
  real rtrig = 0.0;
  wire real rval;

  assign rval = rtrig * $realtime;
// assign rval = rtrig * (2.0 * $realtime); // This should also work.

  initial begin
    #1 rtrig = 1.0;
    #1 rtrig = 0.0;
    #1 rtrig = 1.0;
    #1 rtirg = 0.0;
  end
endmodule

I would expect the time value to be evaluated when the rtrig signal
changes. I would expect this to work for an arbitrarily complex equation.
GPL Cver does work this way, so even though nothing in the standard
mentions this specific case it seems reasonable that things should work
this way. The problem is we currently have no way to feedback to the
$realtime function that it should generate a new result.

Any thoughts?

My first thought is to build some kind of triggered .sfunc that can only
be triggered once per time step. The trigger would be any change in the
equation output.

If someone else would like to take this on I can submit a bug report. I'm
a ways off from having time to work on it, but thought I would try to get
some input while it is still fresh in my mind.

Cary


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

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

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

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

Stephen Williams wrote:
> 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've got a little bit of feedback in geda-user that vvp32 is not
only unused, it causes build problems in some 64bit systems. Can
*anybody* think of a reason why I should keep 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

iD8DBQFHmmWnrPt1Sc2b3ikRAmRnAKDAkpUmhChNBIVdmZksJZ6dFK1gTQCfSloJ
0VzpfGQ+zegBJmk8xZJdBhk=
=5vsS
-----END PGP SIGNATURE-----

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:
> See if you like the appended patch.  It's pretty simple, and lets
> you say "iverilog -d elaborate" to get the desired effect.
> I'm not sure 'd' is the best letter to use, and documentation
> needs to be added.

I like it just fine. It looks like just what the doctor ordered,
so I tool the liberty of pushing it into git.

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

iD8DBQFHmjYGrPt1Sc2b3ikRAqmyAJ0Z5WD0V+Skj+hSYLlwxmsvR+i/UwCfVNnU
aENBJjZJmIlj7KMKRGJWhK8=
=PD2B
-----END PGP SIGNATURE-----

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

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

--- Larry Doolittle <ldo...@re...> wrote:

> I'm getting rather confused.  I just tried to reproduce the error
> on amd64, and could not.  Both iverilog's supposedly were built from
> the same source tree.

FYI the code from the bug tracker fails on both RHEL 4 and cygwin.

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

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

On Fri, Jan 25, 2008 at 10:42:57AM -0800, Larry Doolittle wrote:
> The concat output of vvp code generator
> is the first place the error appears.

I'm getting rather confused.  I just tried to reproduce the error
on amd64, and could not.  Both iverilog's supposedly were built from
the same source tree.

On Fri, Jan 25, 2008 at 10:13:59AM -0800, Larry Doolittle wrote:
> add debug:elaborate 
> to the resulting foo.conf, and (assuming you don't have any
> actual preprocessor activity) rerun the ivl command

See if you like the appended patch.  It's pretty simple, and lets
you say "iverilog -d elaborate" to get the desired effect.
I'm not sure 'd' is the best letter to use, and documentation
needs to be added.

   - Larry


--- /home/ldoolitt/git/verilog/driver/main.c	2008-01-02 11:23:05.000000000 -0800
+++ driver/main.c	2008-01-25 10:46:21.000000000 -0800
@@ -593,7 +593,7 @@
 	}
       }
 
-      while ((opt = getopt(argc, argv, "B:c:D:Ef:g:hI:M:m:N::o:p:Ss:T:t:vVW:y:Y:")) != EOF) {
+      while ((opt = getopt(argc, argv, "B:c:D:d:Ef:g:hI:M:m:N::o:p:Ss:T:t:vVW:y:Y:")) != EOF) {
 
 	    switch (opt) {
 		case 'B':
@@ -620,6 +620,9 @@
 		case 'p':
 		  fprintf(iconfig_file, "flag:%s\n", optarg);
 		  break;
+		case 'd':
+		  fprintf(iconfig_file, "debug:%s\n", optarg);
+		  break;
 
 		case 'g':
 		  rc = process_generation(optarg);

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

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

I believe the problem is in the elaboration code for the shift operators
when used in a continuous assignment (elab_net.cc). This particular case
looks like it could be optimized to just a constant since the constant
shift is as wide as the input vector.

Cary


      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping