iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] VVP Performance boots

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

--- On Mon, 4/21/08, Stephen Williams <st...@ic...> wrote:


> I think we are looking for some sort of uninitialized
> memory problem.
> It appears that the %xnor opcode is fine in your case, but
> there is
> some problem managing the index variable. Try putting a
> test print
> in the of_ADDI function to look at the first word of the
> lva array
> that is returned by the vector_to_array before and after
> the "for"
> loop that does the addition. At the very least, this will
> confirm
> that the index variable value is stuck.
> 
> Perhaps the %set/v or %load/v (if not the %addi) are not
> working
> properly? Seeing what's going into/out of the %addi may
> help us pin
> it down.

This appears to be some kind of race condition! Oh fun!!. I can simplify the the loop down to the large1 assign and the two xnor assignments. Deleting either one of the xnor assignments will make the inf looping go away. The %addi is always getting 0 from the tread vector, so it appears to be working correctly. It also looks like the %load/v has the correct signal value (it starts at zero and then goes to 1). The only thing between the %load/v and the %addi are a couple of %mov instructions to pad the value.

If I add 100 to the thread addresses for the code that increments the loop counter everything works correctly, so it appears that when we have two xnor statements the second one is some how changing values after it should be and is zeroing the loop counter. I'm not certain how this is happening since the xnor should be producing all ones as output. I can send the reduced test case and a.out file if that helps. FYI the second xnor and the loop counter increment use the same or overlapping thread space addresses.

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] VVP Performance boots

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

It appears that the writemem* problems are created by the 1<<(6-count). It look like the 1 is being interpreted as a two bit wide value instead of the normal integer 32 bits. This means that for values of count less than five the result is zero. The following simple program is producing incorrect results:

module main;
  reg [2:0] val;

  initial begin
    for (val=0; val<=6; val=val+1) begin
      $displayh(val,, 1<<(6-val));
    end
  end
endmodule

This problem appear to be related to a different patch since this is in the compiler not the runtime. I'm not certain when I last ran the tests with a synced source tree, but I know it was not too long ago.

Cary


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

[Iverilog-devel] Some GSoC tips for mentors and students...

[Stuart B. <sd...@cl...>]

Hi --

As promised, here is a list tips and suggestions I'd like to see used
by all GSoC projects running under the gEDA umbrella.  The idea is to
promote transparency and community involvement in the GSoC projects,
as well as to create a framework which will help the student bring his
project to a successful conclusion.

1.  Please use the geda-dev (or icarus-devel or gnucap-devel) mailing
list for mentor/student communication about the project
(i.e. questions, suggestions, etc.).  There are several compelling
reasons for this:

   -- It provides some visibility for everybody interested in gEDA into
      how the project is going.

   -- In some situations, you may get a faster answer from somebody on
      the list than your mentor (who might be momentarily away from the
      computer).

   -- The gEDA Project is lucky to have a number of very high level
      developers participating in it.  Students, you can learn a lot
      from these guys!  Posting questions on the list provides you an
      opportunity to interact with them.

Note that using the developer mailing list for project communication
may lead to some confusion, since lots of gEDA hackers have differing
opinions about how things should be done, and they are not hesitant
about expressing their opinions!   This is a normal part of any
open-source project.  Students should use their own judgement when
deciding what suggestions to accept, and which to ignore. Ultimately,
the mentor is the boss, so in the event of confusion, do what your
mentor says.

Of course, sensitive or personal communication should be done
privately.  I put a prefix "[private e-mail]" on the subject line of
private e-mails so the recipient immediately knows that the message is
private, and was not sent to the list.

2.  Everybody hates writing specs, and I'm not going to say we should
do that here.  However, I do think that each mentor and student should
find some written method to flesh out the details of each proposal.
In particular, for projects in which the user interface plays an
important part, the student and mentor should write down and agree
upon a bunch of use-cases.  Mentors can decide what level of detail is
enough.

3.  Mentors should require at least one CVS checkin per week (or other
agreed-upon period).  This helps ensure that regular progress is being
made on the project.  It also ensures that the student isn't getting
way off track.

4.  Mentors may want to set up a separate branch in cvs/svn/git for
the student to work out of.  Merging of the student's branch into the
trunk is a task for mentor and student to work out amongst
themselves.

5.  Students are encouraged to create a blog where they post their
ideas & accomplishments.  A blog is a great tool to tell others what
you have accomplished, and what you intend to do!

6.  In lieu of a blog, mentors should at least ask for a weekly list
of goals accomplished from the student.  The list doesn't have to be
exhaustive.  It should just take 10 min to put together, and summarize
the big-picture accomplishments made.

Mentors, please feel free to add other ideas to this list, and adapt
the suggestions support your preferred menthod to manage your project.

Cheers,

Stuart

[Iverilog-devel] Welcome to gEDA's GSoC participants!

[Stuart B. <sd...@cl...>]

Hello --

As you know, the gEDA Project is participating in the Google Summer of
Code (GSoC) program.  This year, we had 17 students apply to us to
work on gEDA projects under the GSoC umbrella.  From those 17, we have
received 4 funded slots.  Receiving four funded slots is a big win for
us -- that's a large number for a smallish organization, as we are!
(It does mean, unfortunately, that we had to turn away some good
students, but that's life.)  We now have four students who
will spend the summer working on improving and extending gEDA
applications for all gEDA users!

The four approved projects are:

VHDL code generator for Icarus Verilog
Student: Nicholas Gasson
Mentor: Stephen Williams

Topological Autorouter
Student: Anthony Blake
Mentor: DJ Delorie

Periodic steady state analysis for the gnucap simulator.
Student: Rafael GonzMentor: Albert Davis

Project Manager
Student: Newell Jensen
Mentor: Peter Colton James Clifton

I'd like to take this opportunity to publically welcome the new
students into our community.  Welcome, Nicholas, Anthony, Rafael, and
Newell!  We hope that your experience with us is a positive experience
for everybody!

And I also want to extend a big thank you to all the mentors who
worked hard to support our entry into the GSoC program.  That means
*both* the mentors listed above, and also the unlisted mentors who
worked (and continue to work) behind the scenes to bring our project
count up so high!  As your humble admin, I am personally thankful that
the gEDA mentors do such a good job in keeping making our GSoC program
a quality effort.  Your work makes my life easier, so thank you for
your support!  And finally, mentors, remember that even if you don't
get a student this year, you still get a GSoC T-shirt (as do the
participating students)!

I'll send out a separate e-mail with some tips I'd like everybody to
follow as we transition into the Summer of Code period.  Also,
mentors, please use the time between now and beginning of summer to
communicate with your student about his project's detailed goals so
that we can hit the ground running when summer begins.

Congratulations again, everybody.

Cheers,

Stuart

Re: [Iverilog-devel] VVP Performance boots

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

--- On Mon, 4/21/08, Stephen Williams <st...@ic...> wrote:
 
> I think we are looking for some sort of uninitialized
> memory problem.

Our internet and phones are down at work so I will try and look at your suggestions tomorrow. I believe I ran valgrind on the failing tests looking for this type of problem and found nothing!

I have an email at work waiting to send about the writemem tests. Here is a brief synopsis. The problems with the three writemem tests appears to be related to a different, but recent patch. I didn't track down which one yet. It looks like the compiler is incorrectly evaluating the 1 << (6-code) in the comparison. The 1 is being loaded as a two bit value not the 32 bit integer it should be. This means when code is less than five the value is being set to zero. FYI explicitly setting the width of 1 (32'b1) fixes the problem.

Cary 


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

[Iverilog-devel] Test....

[Stuart B. <sd...@cl...>]

....please ignore.

Re: [Iverilog-devel] VVP Performance boots

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

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

Cary R. wrote:
| --- On Mon, 4/21/08, Stephen Williams <st...@ic...> wrote:
|
|> WRT xnor_test: Can you instrument the of_XNOR function in
|> vthread.cc
|> and try it? Something like this:
|>
|> 	    vvp_bit4_t lb = thr_get_bit(thr, idx1);
|> 	    vvp_bit4_t rb = thr_get_bit(thr, idx2);
|> 	    cerr << "XXXX XNOR: lb=" << lb
|> << " rb=" << rb
|> 		 << " lb^rb=" << (lb ^ rb) <<
|> " ~(lb^rb)=" << ~(lb ^ rb)
|> ~                 << endl;
|>
|> ... inside the "for" loop of the of_XNOR
|> function. None of the
|> bits in the result should turn into X or Z. If the %xnor
|> instruction
|> generates X results, then the loop in xnor_test.v may go
|> infinite.
|
| The part of the test that is going into an infinite loop is the
"different sized operands (equality)" section.
|
| The small1 value is set to zero initial then increments to one, but
never goes past that. It appears that the sixteen bit xnor value is
calculated correctly. Both the vthread code and a straight print of
large2 shows all bits are set to one.

I think we are looking for some sort of uninitialized memory problem.
It appears that the %xnor opcode is fine in your case, but there is
some problem managing the index variable. Try putting a test print
in the of_ADDI function to look at the first word of the lva array
that is returned by the vector_to_array before and after the "for"
loop that does the addition. At the very least, this will confirm
that the index variable value is stuck.

Perhaps the %set/v or %load/v (if not the %addi) are not working
properly? Seeing what's going into/out of the %addi may help us pin
it down.

- --
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 v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIDQuGrPt1Sc2b3ikRAhrcAJ4+1AS7MxQJvTrLva3wVr1VYT3cjACdHN2n
gKE2LNz9v95MUcg3a62FVFg=
=QPcr
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] VVP Performance boots

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

--- On Mon, 4/21/08, Stephen Williams <st...@ic...> wrote:

> WRT xnor_test: Can you instrument the of_XNOR function in
> vthread.cc
> and try it? Something like this:
> 
> 	    vvp_bit4_t lb = thr_get_bit(thr, idx1);
> 	    vvp_bit4_t rb = thr_get_bit(thr, idx2);
> 	    cerr << "XXXX XNOR: lb=" << lb
> << " rb=" << rb
> 		 << " lb^rb=" << (lb ^ rb) <<
> " ~(lb^rb)=" << ~(lb ^ rb)
> ~                 << endl;
> 
> ... inside the "for" loop of the of_XNOR
> function. None of the
> bits in the result should turn into X or Z. If the %xnor
> instruction
> generates X results, then the loop in xnor_test.v may go
> infinite.

The part of the test that is going into an infinite loop is the "different sized operands (equality)" section.

The small1 value is set to zero initial then increments to one, but never goes past that. It appears that the sixteen bit xnor value is calculated correctly. Both the vthread code and a straight print of large2 shows all bits are set to one.

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] VVP Performance boots

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

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

Cary R. wrote:
| I just run the test suite on my RHEL 4 32 bit machine and this patch
causes an infinite loop in vvp for xnor_test and gives incorrect results
for writememh2, writememb1, writemem2 and scanmem3 (from the VPI tests).

WRT xnor_test: Can you instrument the of_XNOR function in vthread.cc
and try it? Something like this:

	    vvp_bit4_t lb = thr_get_bit(thr, idx1);
	    vvp_bit4_t rb = thr_get_bit(thr, idx2);
	    cerr << "XXXX XNOR: lb=" << lb << " rb=" << rb
		 << " lb^rb=" << (lb ^ rb) << " ~(lb^rb)=" << ~(lb ^ rb)
~                 << endl;

... inside the "for" loop of the of_XNOR function. None of the
bits in the result should turn into X or Z. If the %xnor instruction
generates X results, then the loop in xnor_test.v may go infinite.
- --
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 v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIDOOqrPt1Sc2b3ikRAs81AKCEDDXsEcTw6tbdfRt2VLeJHhVINQCfRb9H
QraUsb3foIZpAQaMVW+KoJw=
=7AMq
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Always blocks with out delays (pr1862744)

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

> We should warn too little, and not too much, I think.
> We've all
> gotten tired of vendor tools printing warning/info files
> that are
> bigger then the source being compiled, so let's not go
> there;-P

OK I will add a -Winf_loop flag that will not be part of the basic -Wall. The code will fail to evaluate if it can definitely determine that an infinite loop will occur. You can use -Winf_loop to look for possible infinite loops if you encounter one in the runtime and need help in tracking the problem down.

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] Always blocks with out delays (pr1862744)

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

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

Cary R. wrote:
| A quick update on this.
|
| I have the basics working. I am assuming a forever and while with a
constant true expression should also check for infinite loops. I still
need to add function and task call statements and the switch statement
which is just an extended conditional still need to be coded. I also
have a couple questions about how the indeterminate messages should be
displayed.
|
| Should we make the indeterminate case, may be an infinite loop, only
display a message when the appropriate -W (inf_loop) flag is given? Do
we want this included in the -Wall case? My guess is that we probably do
not since this is a possible warning not a true problem that should be
fixed. It's the limitations of the checks that is preventing us from
making a true determination of the state. I do not believe we should try
to truly determine this either. There is way too many things that would
need to be looked at and evaluated for a minimal return.
|
| Once this is completed we will need to have an explanation on the wiki
that covers how to interpret what a possible infinite loop means. It may
also be nice to have a small section in the manual that gives the basics.

We should warn too little, and not too much, I think. We've all
gotten tired of vendor tools printing warning/info files that are
bigger then the source being compiled, so let's not go there;-P

And yes, while loops with constant true expressions are exactly
the same as always statements as a whole, so have the potential
to make just as much of a mess.

- --
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 v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIDNFcrPt1Sc2b3ikRAi3xAJ9slh8zcKhTeVNT4E1zK4vHQkSG2wCg50nV
ecGRL1C9kzcHCR1SIyuGtLs=
=eEJv
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] VVP Performance boots

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

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

Cary R. wrote:
| --- On Mon, 4/21/08, Stephen Williams <st...@ic...> wrote:
|
|> I've pushed into GIT changes to the vvp_vector4_t class
|> that
|> rework how the bits of bit4 values are stored in the
|> vector. This
|> change is based on ideas from Cary. The result is a
|> *significant*
|> boost in performance for simulations heavy with arithmetic.
|> The
|> multiple_large test is something like 20% faster. So we may
|> want
|> to be on the lookout for similar opportunities. We are
|> still in
|> the need of performance improvement on run time.
|
| I just run the test suite on my RHEL 4 32 bit machine and this patch
causes an infinite loop in vvp for xnor_test and gives incorrect results
for writememh2, writememb1, writemem2 and scanmem3 (from the VPI tests).
|
| It appears that the writemem* work files are being created correctly.
The scanmem3 file looks to be z vs x differences.


Huh, they work for me on both PowerPC (Mac OS X) and AMD64 (Linux).

- --
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 v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIDNCBrPt1Sc2b3ikRAoOUAJwKkhYZjOF89r9dboKal6DjxB30kACbBEmH
GfSbopNDYI8iTzM/BYZULgc=
=iK2e
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Always blocks with out delays (pr1862744)

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

A quick update on this.

I have the basics working. I am assuming a forever and while with a constant true expression should also check for infinite loops. I still need to add function and task call statements and the switch statement which is just an extended conditional still need to be coded. I also have a couple questions about how the indeterminate messages should be displayed.

Should we make the indeterminate case, may be an infinite loop, only display a message when the appropriate -W (inf_loop) flag is given? Do we want this included in the -Wall case? My guess is that we probably do not since this is a possible warning not a true problem that should be fixed. It's the limitations of the checks that is preventing us from making a true determination of the state. I do not believe we should try to truly determine this either. There is way too many things that would need to be looked at and evaluated for a minimal return.

Once this is completed we will need to have an explanation on the wiki that covers how to interpret what a possible infinite loop means. It may also be nice to have a small section in the manual that gives the basics.

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] VVP Performance boots

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

--- On Mon, 4/21/08, Stephen Williams <st...@ic...> wrote:
 
> I've pushed into GIT changes to the vvp_vector4_t class
> that
> rework how the bits of bit4 values are stored in the
> vector. This
> change is based on ideas from Cary. The result is a
> *significant*
> boost in performance for simulations heavy with arithmetic.
> The
> multiple_large test is something like 20% faster. So we may
> want
> to be on the lookout for similar opportunities. We are
> still in
> the need of performance improvement on run time.

I just run the test suite on my RHEL 4 32 bit machine and this patch causes an infinite loop in vvp for xnor_test and gives incorrect results for writememh2, writememb1, writemem2 and scanmem3 (from the VPI tests).

It appears that the writemem* work files are being created correctly. The scanmem3 file looks to be z vs x differences.

Once the problems are fixed I will also run valgrind to look for any other problem.

Once this is stable I think there are some more optimization that can be done for the various logic gates/functions. I can forward you the Verilog file I used to develop the gate optimization if you would like.

Cary


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

[Iverilog-devel] VVP Performance boots

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

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


I've pushed into GIT changes to the vvp_vector4_t class that
rework how the bits of bit4 values are stored in the vector. This
change is based on ideas from Cary. The result is a *significant*
boost in performance for simulations heavy with arithmetic. The
multiple_large test is something like 20% faster. So we may want
to be on the lookout for similar opportunities. We are still in
the need of performance improvement on run 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 v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIDKcbrPt1Sc2b3ikRAt1NAJ9522FvldrSFmNMPj+MkEv9xtHyQgCfUYQX
wCgQE7oBaFHAvjgj/6zopwA=
=1jMT
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Always blocks with out delays (pr1862744)

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

--- On Sat, 4/19/08, Stephen Williams <st...@ic...> wrote:

> Well, if you pass a control flag to the calculation of this
> state,
> then you are implying that it is calculated on demand,
> possibly
> multiple times (and possibly no times) whereas if you just
> calculate
> the more expressive value, then you can reuse the value for
> different
> needs. (Again, perhaps you need it zero times.)

For the always I think it should be calculated each time since the delay could change for each instantiation of the module.
 
> My sense is that if every always statement is going to need
> this
> value, then it is going to be needed almost always, and
> might as
> well be calculated during elaboration. It strikes me that
> it will
> be very easy to calculate during elaboration, skipping the
> need
> for a post-process recursive test later when the data is
> needed.

If we make this part of the general elaboration then initial blocks will also do the calculations and my feeling is that there are far fewer always block. I would also guess that always blocks are in general simpler.

> It can be that the expressive enum value be hidden behind a
> pair
> of boolean methods that the clients use, so this method if
> calculating
> the expressive value can have any reasonable interface.
> 
> Hmm, I'm thinking about where this information may be
> used, and
> I'm starting to realize that only NO_DELAY is useful.
> If you have
> an always statement, you want to generate a warning if it
> IS
> NO_DELAY, and if the NetProc is a function definition you
> want
> to generate an error if it is NOT NO_DELAY.

This isn't quit correct. NO_DELAY is correct for a function, but you want to print a warning for an always that has either no delay or may possible have delay. I was reflecting earlier and this probably would need to be a four state value. No delay, zero delay, possible delay and definite delay. A function definition can only have no delay and an always will not complain only when you definitely have delay. No and zero delay are definite infinite loops and possible delay may be an infinite loop.

I have build some basic infrastructure using NetProc and friends. I'm thinking that the four state method is the correct way to go so we can reuse the basic code for both the always and function checks. I think the function definition checks can cache their check state, but I think the always blocks need to be checked each time. Think about the following:

#<param_value>

This could be different for each module instantiation and when zero we would have a looping problem. Not matter what the value this is illegal in a function definition. 

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] Always blocks with out delays (pr1862744)

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

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

Cary R. wrote:
| --- On Fri, 4/18/08, Stephen Williams <st...@ic...> wrote:
|
|> Or have it return an enum with a range:
|>
|> ~   NO_DELAYS  = 0
|> ~   NO_KNOWN_DELAYS = 1
|> ~   KNOWN_DELAYS = 3
|
| If this is the route I go I think it should be NO_DELAY,
POSSIBLE_DELAY and DEFINITE_DELAY. I think the code will be cleaner if
we pass a control flag vs checking both possibilities and combining them
correctly. Can you think of a case where we would need to know the three
different states?

Your names are much better, yes.

Well, if you pass a control flag to the calculation of this state,
then you are implying that it is calculated on demand, possibly
multiple times (and possibly no times) whereas if you just calculate
the more expressive value, then you can reuse the value for different
needs. (Again, perhaps you need it zero times.)

My sense is that if every always statement is going to need this
value, then it is going to be needed almost always, and might as
well be calculated during elaboration. It strikes me that it will
be very easy to calculate during elaboration, skipping the need
for a post-process recursive test later when the data is needed.

It can be that the expressive enum value be hidden behind a pair
of boolean methods that the clients use, so this method if calculating
the expressive value can have any reasonable interface.

Hmm, I'm thinking about where this information may be used, and
I'm starting to realize that only NO_DELAY is useful. If you have
an always statement, you want to generate a warning if it IS
NO_DELAY, and if the NetProc is a function definition you want
to generate an error if it is NOT NO_DELAY.

- --
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 v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFICih4rPt1Sc2b3ikRAiyIAKDkfent8Ca/HJPFQ1x0Ao+KNH955gCfUZU7
UUMXHy+nzO2GU0L/GQi60lI=
=7uuP
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Always blocks with out delays (pr1862744)

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

--- On Fri, 4/18/08, Stephen Williams <st...@ic...> wrote:

> Or have it return an enum with a range:
> 
> ~   NO_DELAYS  = 0
> ~   NO_KNOWN_DELAYS = 1
> ~   KNOWN_DELAYS = 3

If this is the route I go I think it should be NO_DELAY, POSSIBLE_DELAY and DEFINITE_DELAY. I think the code will be cleaner if we pass a control flag vs checking both possibilities and combining them correctly. Can you think of a case where we would need to know the three different states?

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] Always blocks with out delays (pr1862744)

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

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

Cary R. wrote:
|
|
| --- On Fri, 4/18/08, Stephen Williams <st...@ic...> wrote:
|
|
|> I would sat that non-blocking assignments have zero delay,
|> by
|> the way, because they do not block execution. I think you
|> mean
|> that blocking assignments with internal delays should
|> return
|> has_delay of true, because they do have delay, and they
|> pause
|> the thread.
|
| Yes that is correct!
|
|> By the way, this handling can also be used to detect the
|> erroneous case of a user defined function that *has* a
|> delay.
|> This is illegal but currently it is not detected and
|> reported.
|
| If we give has_delay a pessimism flag this could work. An always wants
to be conservative (always has a delay). While the function definition
wants to be pessimistic (find any delay).

Or have it return an enum with a range:

~   NO_DELAYS  = 0
~   NO_KNOWN_DELAYS = 1
~   KNOWN_DELAYS = 3


- --
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 v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFICUMFrPt1Sc2b3ikRAsSxAJ9kypou/yKyE3CjECLWOvEyHmcbywCgiRak
rtGGjvlqR4a1fZOSnbsIgAo=
=NWsW
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Always blocks with out delays (pr1862744)

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

--- On Fri, 4/18/08, Stephen Williams <st...@ic...> wrote:


> I would sat that non-blocking assignments have zero delay,
> by
> the way, because they do not block execution. I think you
> mean
> that blocking assignments with internal delays should
> return
> has_delay of true, because they do have delay, and they
> pause
> the thread.

Yes that is correct!
 
> By the way, this handling can also be used to detect the
> erroneous case of a user defined function that *has* a
> delay.
> This is illegal but currently it is not detected and
> reported.

If we give has_delay a pessimism flag this could work. An always wants to be conservative (always has a delay). While the function definition wants to be pessimistic (find any delay).

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] Always blocks with out delays (pr1862744)

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

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


This sounds intriguing. I think this attribute would better be
attached to the NetProc base class because a thorough check for
the warning will get better information from elaborated results.
For example, elaboration of a process will include precomputing
constant expressions and that may allow catching infinite for-
and while-loops. Also, task definitions will be available as
elaborated NetProc objects.

I would sat that non-blocking assignments have zero delay, by
the way, because they do not block execution. I think you mean
that blocking assignments with internal delays should return
has_delay of true, because they do have delay, and they pause
the thread.

By the way, this handling can also be used to detect the
erroneous case of a user defined function that *has* a delay.
This is illegal but currently it is not detected and reported.

Cary R. wrote:
| I have been thinking about this for a while and here is what I have
come up with so far. We need to add a new attribute to the P* objects
'has_delay' that the always command can use to print a warning if the
block appears to not have some kind of delay.
|
| The default object type will be no delay. Delay, non-blocking
assignment and wait statements will return true. An if or switch
statement will only return true if there is a delay in all paths. We
don't know the logic so this is the safest choice. Except for a repeat
with a constant positive value, loops always return false for the same
reason (they may not run). The repeat mentioned above will only return
true if it contains a statement that has a delay. Task calls (tasks) and
blocks return true if one of their items returns has a delay.
|
| It could be argued that a forever or a while with a constant true
value should also return true, but using them inside an always seems
dubious at best.
|
| For the delay elements we should probably check that the delay is not
zero. This should be easy for a constant value. For variable delays I
think we just have to trust that the user is doing the right thing and
assume the delay is greater than zero.
|
| Does this make sense? Am I missing anything. The message will be a
warning that the always block could create an infinite loop.



- --
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 v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFICRCbrPt1Sc2b3ikRAkE9AKDUjoUtzFxECDy7QozGJ6O+RUBCigCgkJl9
cNpL10Hn7Z4QmHIvDQ8vz4Y=
=8fAa
-----END PGP SIGNATURE-----

[Iverilog-devel] Always blocks with out delays (pr1862744)

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

I have been thinking about this for a while and here is what I have come up with so far. We need to add a new attribute to the P* objects 'has_delay' that the always command can use to print a warning if the block appears to not have some kind of delay.

The default object type will be no delay. Delay, non-blocking assignment and wait statements will return true. An if or switch statement will only return true if there is a delay in all paths. We don't know the logic so this is the safest choice. Except for a repeat with a constant positive value, loops always return false for the same reason (they may not run). The repeat mentioned above will only return true if it contains a statement that has a delay. Task calls (tasks) and blocks return true if one of their items returns has a delay.

It could be argued that a forever or a while with a constant true value should also return true, but using them inside an always seems dubious at best.

For the delay elements we should probably check that the delay is not zero. This should be easy for a constant value. For variable delays I think we just have to trust that the user is doing the right thing and assume the delay is greater than zero.

Does this make sense? Am I missing anything. The message will be a warning that the always block could create an infinite loop.

Cary


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

[Iverilog-devel] Functions and ANSI style declarataions.

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

Steve has claimed this report, but I looked at it earlier this week and here are my notes.

list_of_port_declarations or task_port_decl_list can be used as templates for what needs to be done to implement this. Adding something like these that is specific to functions (no inout/output) and a new rule that uses this appears to be all that is required. The new rule is a slight modification of the existing rule, change the $ indexes as needed and replace the function_item_list with a block_item_decl, this does not include the I/O decls and does not need to be processed. Add the I/O decls after the function name.

Something like:

.... IDENTIFIER '('
{ C++ scope code...}
func_port_decl_list ')' ';'
block_item_decl statement ...

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] Add git commit information to version strings

[Jeevan V. <jva...@ya...>]

As noted in http://sourceforge.net/tracker/index.php?func=detail&aid=1938766&group_id=149850&atid=775999 , there are yet some issues with my solution to building the version.h file.  It did turn out to be trickier than i thought :), as Steve noted.  One solution to installing from a read-only source is to check that the current-directory is writable by enclosing the building of version.h in Makefile.in with `if test -w .; then ... fi'.

Attached is a shell script which automates the building of the version.h and snapshot files.  The following are some usage examples.

# 1. Make a snapshot of the HEAD of the current branch.
#    $ sh snapshot.sh
#    $ sh snapshot.sh HEAD
#
# 2. Make a snapshot of tag s20080314 and name it verilog-s20080314.tar.gz
#    $ sh snapshot.sh s20080314
#
# 3. Make a snapshot of tag s20080314 and name it verilog-20080314.tar.gz
#    $ sh snapshot.sh s20080314 20080314
#
# 4. Do test runs without making anything.
#    $ sh snapshot.sh --dry-run
#    $ sh snapshot.sh -n HEAD ""
#    $ sh snapshot.sh -n s20080314
#    $ sh snapshot.sh --dry-run s20080314 20080314

Of course, this script isn't actually needed because making a snapshot is an infrequent event; so, it can be replaced with a README file, which will provide a clearer picture of what needs to be done.  Another thing against the script is that the path to /tmp directory is hardcoded; i made a script in which the git-repo and the temporary directory can be specified on the command line, but its size seemed too big for the amount of utility it provided.

Anyway, i hope something useful came out of this.

Regards,
Jeevan


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Iverilog-devel] assign/deassign and force/release of bit/part selects.

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

It appears I have this working correctly for vec4. I need to fix the vec8
code and my test uncovered a compiler optimization that in the context of
assign (and force) is not correct.

If you assign a value to a variable you cannot use the thread bits you
just used to assign as the value since a continuous assignment may not
allow the assignment to work correctly. I had noticed this in the test for
bit/part select release. I just didn't track the problem down.

Cary


      ____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.  
http://tc.deals.yahoo.com/tc/blockbuster/text5.com