iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] Integrating va_math into git

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

Steve -

On Tue, Apr 29, 2008 at 04:27:36PM -0700, Stephen Williams wrote:
> I'm thinking that it's not a bad time right now to integrate the
> contributed va_math library into the Icarus Verilog git distribution.

And also, therefore, upcoming development snapshots.

> Option #2 has the advantage that system.vpi and va_math.vpi are
> kept lighter weight. Name space pollution is also reduced. The
> disadvantage is that the user has to use the -mXXX flags to load
> the va_math library. (That's not unlike the "-lm" flag that C
> programmers sometimes have to remember.)

I value unpolluted standards-based name spaces.  This looks
like a reasonable choice.

    - Larry

[Iverilog-devel] Integrating va_math into git

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

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


I'm thinking that it's not a bad time right now to integrate the
contributed va_math library into the Icarus Verilog git distribution.
We get to decide on a method.

1. The va_math.c code is pretty compact. We could just include it
as part of the system.vpi in the vpi/ directory. This would also
mean that the va_math.sft becomes part of the system.sft file and
every user just gets it.

2. We could include it in the vpi/ directory, but make a separate
va_math.vpi module. The vpi/Makefile.in would gain the rules needed
to make and install the va_math.vpi module and install the va_math.sft.

3. Create a va_math directory similar to the vpi/ directory.


Option #1 has the advantage that it is completely transparent to
the Icarus Verilog user, except that now there are all these
nifty new system functions. The only disadvantage I can think of
it that there is a slight bit of bloat in system.vpi. There is
also some name space pollution.

Option #2 has the advantage that system.vpi and va_math.vpi are
kept lighter weight. Name space pollution is also reduced. The
disadvantage is that the user has to use the -mXXX flags to load
the va_math library. (That's not unlike the "-lm" flag that C
programmers sometimes have to remember.)

Option #3 is just a worse version of #2.

Preferences?

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

iD8DBQFIF67orPt1Sc2b3ikRAt0mAJwODv8MHGmVtNeHIdVUBh51n/o5iQCdEijS
JLwnW2YMbRILwTMPoP18wPk=
=nFy6
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Questions about modpath::recv_vec4()

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

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

> Only the latest *enabled* modpath is used to make up the
> specified delays for this output, ...

I missed that latest was the key instead of now!

Thanks for the explanation. This should be done soon.

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] Questions about modpath::recv_vec4()

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

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

Cary R. wrote:
| I am working on the final integration of ifnone and have a few
questions concerning vvp_fun_modpath::recv_vec4().
|
| If the current modpath wake time is less than now why is it being
processed? I believe it should have already been scheduled. Ignoring
this in the first for loop means the candidate list only has active
candidates and simplifies the code greatly.

The wake_time_ is the simulator time when the modpath received its
input, so is by definition before (or exactly at) "now". The "for"
loop that scans through the 12 delays is calculating the specified
output time based on the wake_time_ (the input time) and the 12 delays.
Some delay times may be before now, and some may be after now.

The early "for" loop (the one that is building the candidate_list)
is using the wake_time_ for the path to figure out if it is a
candidate delay *path*. It is not yet looking at actual delays. Only
the latest *enabled* modpath is used to make up the specified delays
for this output, so this loop is scanning all the specified paths
looking for the active one[s]. There may be multiple paths with the
exact same wake_time_, so there may be multiple active paths, but
we don't know which paths are active until we look at the wake_time_
for all of them.

Once the paths are selected, we are no longer interested in the
activation time (the wake_time_) but the output time. Calculate that
from the wake_time_ plus the delays. This gives us the output time,
which may be after now (the most common case) or before now if there
were distributed delays between the input and this output. If there
are multiple active paths (by definition with the same wake_time_)
they are all combined by selecting only the smallest delay (for each
of the 12 edges) from the selected candidate paths.

After all that, we have the output time (not the delay) and that is
what the scheduler wants to know.


| Why is the code redefining the candidate list when it finds an object
with a future wake time? Is this some kind of rudimentary pulse control?
This redefinition seems to be counter to the use minimum delays edict
"Delay selection".

In that first "for" loop it is looking for the path that was activated
the latest. Note that the wake times are *before* now. This loop is not
calculating the delays, it is selecting the activated *paths*. The
delays are calculated in the later loops. The minimum delays edict only
comes into play if there are multiple candidate specify paths, and that
can only happen if multiple modpath objects have the same wake_time_.

| Some of the set_delays() routines in netlist.cc seems to be different
than table 39 (1364-2001 page 103) and table 48 (1364-2001 page 225).
Did the 2005 standard change the rules on these? These table also appear
to have some inconsistencies.

I don't think there were any rule changes.

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

iD8DBQFIFmh+rPt1Sc2b3ikRAhJvAKC6avN2tArHVd0lS8EVsJoNeN9m7wCgo2TD
5qDPJJZEiEZKlwnWzL3/kHA=
=uc1r
-----END PGP SIGNATURE-----

[Iverilog-devel] Questions about modpath::recv_vec4()

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

I am working on the final integration of ifnone and have a few questions concerning vvp_fun_modpath::recv_vec4().

If the current modpath wake time is less than now why is it being processed? I believe it should have already been scheduled. Ignoring this in the first for loop means the candidate list only has active candidates and simplifies the code greatly.

This information will likely be needed to implement pulse control.

Why is the code redefining the candidate list when it finds an object with a future wake time? Is this some kind of rudimentary pulse control? This redefinition seems to be counter to the use minimum delays edict "Delay selection".

Some of the set_delays() routines in netlist.cc seems to be different than table 39 (1364-2001 page 103) and table 48 (1364-2001 page 225). Did the 2005 standard change the rules on these? These table also appear to have some inconsistencies.

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] second-to-last compiler warning

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

--- On Mon, 4/28/08, Larry Doolittle <ldo...@re...> wrote:
 
> Dmalloc/efence won't touch #1, so if the VPI program
> tries
> to clobber or over-read the error code, they can't
> complain,
> and some pseudo-random internal Icarus memory will get
> abused.

Clobber should be a SEGV since this is normally in RO code space. Over-read is a problem that will go undetected.

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] second-to-last compiler warning

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

On Mon, Apr 28, 2008 at 02:24:14PM -0700, Stephen Williams wrote:
> Larry Doolittle wrote:
> | static char error_code[]="";
> | info->code = error_code;
> |
> | static char *error_code=NULL;
> | if (error_code == NULL) error_code=strdup("");
> | info->code = error_code;
> |
> | info->code = strdup("");
> 
> #3 is clearly out.
> 
> I perfer #1, personally. Is dmalloc/efence really going to be
> somehow confused by #1, and will #2 really trigger them to do
> anything special?

Dmalloc/efence won't touch #1, so if the VPI program tries
to clobber or over-read the error code, they can't complain,
and some pseudo-random internal Icarus memory will get abused.
efence can detect those problems if #2 is used.

After correcting for the amazing delay of this mailing list,
I take this as a vote for #4, since it is essentially #1
but shrunk to a single line:

info->code = (char *) "";

Unless some currently used compiler complains about it.

   - Larry

Re: [Iverilog-devel] second-to-last compiler warning

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

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

Larry Doolittle wrote:
| I can "fix" the code to match 21st century compiler pedantry, in a
| number of ways.  Please tell me if any of the following code fragments
| targeted at vpi_chk_error() meet your aesthetic needs:
|
| static char error_code[]="";
| info->code = error_code;
|
| static char *error_code=NULL;
| if (error_code == NULL) error_code=strdup("");
| info->code = error_code;
|
| info->code = strdup("");

#3 is clearly out.

I perfer #1, personally. Is dmalloc/efence really going to be
somehow confused by #1, and will #2 really trigger them to do
anything special?


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

iD8DBQFIFkB+rPt1Sc2b3ikRAuKgAKCya0EyNDHByRt/za4V9siCRXbq1ACdF+uf
Iz7ldVUOXRn9ImEIXVFAzYE=
=kVdg
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] second-to-last compiler warning

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

--- On Mon, 4/28/08, Larry Doolittle <ldo...@re...> wrote:


> Although the last one is shortest and most self-contained,
> it is
> also a memory leak.  The reason I suggest the second
> snippet (I
> normally favor the shortest possible code) is to put the
> pointer
> in dynamic memory, where dmalloc/electric-fence etc. can
> help
> diagnose problems in VPI code.

Please don't add any more memory leaks. I know we currently have plenty of them, but at some point in time I plan to clean them up just like I did for the uninitialized memory problems. FYI I will be using valgrind to clean up these leaks.

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] second-to-last compiler warning

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

On Mon, Apr 28, 2008 at 10:58:44AM -0700, Larry Doolittle wrote:
> vvp/vpi_priv.cc:118: warning: deprecated conversion from string constant
> to 'char*'
> 
> I can "fix" the code to match 21st century compiler pedantry, in a
> number of ways.  Please tell me if any of the following code fragments
> targeted at vpi_chk_error() meet your aesthetic needs:
> 
> static char error_code[]="";
> info->code = error_code;
> 
> static char *error_code=NULL;
> if (error_code == NULL) error_code=strdup("");
> info->code = error_code;
> 
> info->code = strdup("");

info->code = (char *) "";

Odd, but kosher according to g++-4.3.

> The reason I suggest the second snippet (I
> normally favor the shortest possible code) is to put the pointer
> in dynamic memory, where dmalloc/electric-fence etc. can help
> diagnose problems in VPI code.

All the other vpi_* routines in vpi_priv.cc effectively do
the same thing as my newest snippet when they have to return
(char *) items derived from string literals.

    - Larry

[Iverilog-devel] second-to-last compiler warning

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

Not counting the warning (on 64-bit architectures) caused by a standard
bug in libveriuser/getp.c
	rtn = (int) value.value.str;        /* Oh my */
only one compile-time warning shows up in my builds of current git Icarus:
vvp/vpi_priv.cc:118: warning: deprecated conversion from string constant
to 'char*'
The offending line is
	info->code = "";
where of course the code member of structure s_vpi_error_info is declared
(according to the standard, in vpi_user.h) as char *.

I can "fix" the code to match 21st century compiler pedantry, in a
number of ways.  Please tell me if any of the following code fragments
targeted at vpi_chk_error() meet your aesthetic needs:

static char error_code[]="";
info->code = error_code;

static char *error_code=NULL;
if (error_code == NULL) error_code=strdup("");
info->code = error_code;

info->code = strdup("");

Although the last one is shortest and most self-contained, it is
also a memory leak.  The reason I suggest the second snippet (I
normally favor the shortest possible code) is to put the pointer
in dynamic memory, where dmalloc/electric-fence etc. can help
diagnose problems in VPI code.

    - Larry

Re: [Iverilog-devel] Path delays simple, conditional and ifnone.

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

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

Cary R. wrote:
| --- On Thu, 4/24/08, Stephen Williams <st...@ic...> wrote:
|
|> No, order should not be important, and it should collect
|> all
|> the delay paths.

|> If Icarus Verilog does anything other, then it is a bug.
|> But I think it gets this right.
|
| OK we have a bug because it is giving different results depending on
order!

I've pushed a commit into git that should fix 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 v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIEnVNrPt1Sc2b3ikRAsYFAKCdexFvPorSMvehs12IPnX8IM0QBgCdH27C
nhr+uMoPMC3MFMlh/VgJWFk=
=vHHM
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Verilog to VHDL project setup.

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

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

> The ivtest project on sourceforge.net is where we keep the
> Icarus
> Verilog regression test suite. Cary has done the recent big
> work
> on the compiler test harness script (vvp_reg.pl) and also
> other
> harness scripts. He knows perl, I do not:-/ Ideally, we
> should
> integrate your stuff into that project, probably with a
> test
> harness of its own.

This will likely mirror the changes I did to support valgrind testing. Slightly modify the programs that are called to run the tests and possible recode the internal diff routine to ignore any extra stuff from the VHDL simulator. I agree we want this to be a separate program possible vhdl_vvp.pl.

Cary


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

[Iverilog-devel] Verilog to VHDL project setup.

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

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


I'm moving this thread to the iverilog-devel mailing list. Others
may have opinions on this subject.

Nick Gasson wrote:
| Stephen Williams wrote:
|>
|>
|> In fact we are going to want to get a few things settled as early
|> as reasonable. One is how you are going to work. In particular, we
|> are going to want to see snapshots and be able to test them in our
|> own build environments.
|>
|> Are you going to create a bit branch? Or deliver your module as
|> an external piece of code? We will probably wind up preferring a
|> git branch, and we'll have to work out the mechanics of that.
|
| I'd prefer a git branch: this should be easiest since I can easily push
| snapshots to the remote repository.

Yes, sounds best. One possibility that I've been thinking of
using you as a guinea pig for is to have you create your own
public clone of the Icarus Verilog repository using one of the
public git hosting services. There is github.com or repo.or.cz.
The latter is older, and I already use it to keep an automatic
mirror of the main repository. (I've been using repo.or.cz as an
automatic mirror host, but it's not been auto-mirroring for the
last few months, so github may be worth a try.)

The idea I have is that you make a public clone, then you create
your branch in that clone and commit and commit and work and
commit to that branch on your clone, and we just "pull" it into
the main repository now and then, or when you are ready.

|>
|> Also, how are you going to test the results? We should see early
|> some Verilog program that we can use as a benchmark of your
|> progress. Ideally, they'll be something we can include in the
|> test suite.
|
| Yes, this is a good idea and will should be one of the first things I
| work on. I'll probably create a bunch of C/C++ unit tests too -- should
| these be integrated with the build / test process? If so, is there a
| preferred framework?

The ivtest project on sourceforge.net is where we keep the Icarus
Verilog regression test suite. Cary has done the recent big work
on the compiler test harness script (vvp_reg.pl) and also other
harness scripts. He knows perl, I do not:-/ Ideally, we should
integrate your stuff into that project, probably with a test
harness of its own.

As for a VHDL simulator, we should pick one that is free and open
source for use by any test harness, if at all possible. There are
ghdl and freehdl (I think ghdl is more active) that we should look
at. I'll ask around on geda-user to see what other people use.


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

iD8DBQFIEew2rPt1Sc2b3ikRAlJnAKCX8mkXRIiFcmS+IyFhxH0U9l3v3QCgsbdl
Z43bmsytV59OeJqg3WkqKl0=
=gtCX
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Path delays simple, conditional and ifnone.

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

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

> All I will do is collect all the paths that have the same
> wake_time_.
> Currently, it is only saving 1 with the maximum wake_time_,
> so I'll
> have to find a way to list the matches instead of saving a
> single
> pointer.
> 
> The condition is handled by the paths themselves managing
> the
> condition_flag_ member of the vvp_fun_modpath object. The
> actual
> delay then can quickly reject paths that are disabled by
> conditions.
> It would be nice if you can get the ifnone condition to
> manage
> that member as well.

I was assuming the ifnone would fit in after the loop, so if src == 0 and you have an ifnone set src to the ifnone delay. Making ifnone handle a condition_flag_ seems overly complicated.

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] Path delays simple, conditional and ifnone.

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

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

Cary R. wrote:
| --- On Thu, 4/24/08, Stephen Williams <st...@ic...> wrote:
|
|> Looks like the bug is in the selection process in vvp, in
|> the
|> vvp_fun_modpath::recv_vec4 method. It is selecting only 1
|> path
|> and using that for delays. That is obviously wrong:-( Looks
|> like
|> something I should deal with.
|
| Sounds fine. If you are going to do this will you think about how you
would like ifnone to fit into the mix. That will somewhat determine how
I implement this in the compiler.


All I will do is collect all the paths that have the same wake_time_.
Currently, it is only saving 1 with the maximum wake_time_, so I'll
have to find a way to list the matches instead of saving a single
pointer.

The condition is handled by the paths themselves managing the
condition_flag_ member of the vvp_fun_modpath object. The actual
delay then can quickly reject paths that are disabled by conditions.
It would be nice if you can get the ifnone condition to manage
that member as well.


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

iD8DBQFIENwWrPt1Sc2b3ikRAsLFAJ9gEM+F3KiM9ZzYo2pus28huOqSuACgvpl8
65jMcSJBepV7bZN2GXXVrg8=
=Q1Py
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Path delays simple, conditional and ifnone.

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

--- On Thu, 4/24/08, Stephen Williams <st...@ic...> wrote:
 
> Looks like the bug is in the selection process in vvp, in
> the
> vvp_fun_modpath::recv_vec4 method. It is selecting only 1
> path
> and using that for delays. That is obviously wrong:-( Looks
> like
> something I should deal with.

Sounds fine. If you are going to do this will you think about how you would like ifnone to fit into the mix. That will somewhat determine how I implement this in the compiler.

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] Path delays simple, conditional and ifnone.

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

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

Cary R. wrote:
| --- On Thu, 4/24/08, Stephen Williams <st...@ic...> wrote:
|
|> No, order should not be important, and it should collect
|> all
|> the delay paths. At run time, when the "in" value
|> changes,
|> all the possible paths are activated. If "cond"
|> is true, then
|> both in your example are activated. Then the runtime will
|> choose the delay that is smallest. In your example, with
|> the
|> paths not yet annotated, that is clearly 1.5. But if by
|> annotation
|> the conditional path is given a delay of 1.1, then it will
|> be chosen instead.
|>
|> If Icarus Verilog does anything other, then it is a bug.
|> But I think it gets this right.
|
| OK we have a bug because it is giving different results depending on
order!
|
| The attached program gives different delay values depending on the
order of the statements as shown the conditional paths are active. If
the simple path delay is moved after the conditionals it overrides the
value used no matter what.


Looks like the bug is in the selection process in vvp, in the
vvp_fun_modpath::recv_vec4 method. It is selecting only 1 path
and using that for delays. That is obviously wrong:-( Looks like
something I should deal with.

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

iD8DBQFIEM44rPt1Sc2b3ikRAnW6AJ942agw+qvQxsHHPGiRRt0gPYCRxACfRZZX
oWiN+PSGAGw3NoijffIze3Y=
=csA3
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Path delays simple, conditional and ifnone.

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

--- On Thu, 4/24/08, Stephen Williams <st...@ic...> wrote:
 
> No, order should not be important, and it should collect
> all
> the delay paths. At run time, when the "in" value
> changes,
> all the possible paths are activated. If "cond"
> is true, then
> both in your example are activated. Then the runtime will
> choose the delay that is smallest. In your example, with
> the
> paths not yet annotated, that is clearly 1.5. But if by
> annotation
> the conditional path is given a delay of 1.1, then it will
> be chosen instead.
> 
> If Icarus Verilog does anything other, then it is a bug.
> But I think it gets this right.

OK we have a bug because it is giving different results depending on order!

The attached program gives different delay values depending on the order of the statements as shown the conditional paths are active. If the simple path delay is moved after the conditionals it overrides the value used no matter what.

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] Path delays simple, conditional and ifnone.

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

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

Cary R. wrote:
| --- On Thu, 4/24/08, Stephen Williams <st...@ic...> wrote:
|
|> | (in => out) = 1.5;
|> | if (cond) (in => out) = 1.8;
|> |
|> | will make the delay from in to out 1.8 when the condition
|> is true. If
|> you swap the order of the statements the delay is always
|> 1.5!
|
|> Actually, I think your example is perfectly legal and
|> useful.
|> It is possible to have multiple path delays for a given
|> output,
|> and in that case, assuming they are all activated at once,
|> the
|> output delay in use is taken to be the shortest--in this
|> case,
|> 1.5. In fact, in your specific case, it will as you say
|> always
|> be 1.5 unless SDF annotation changes the simple path delay,
|> which
|> is a possibility. So although on the surface it seems like
|> a
|> waste, back annotation can turn it into something
|> important.
|
| You misunderstood what I wrote! With the order shown the delay is 1.8
if you swap the order of the two statements you get 1.5 and why would
the smaller delay be correct? Depending on the situation the longer
delay could be the worst case. The reason this is happening is that when
the code is looking for a delay it uses the first it find which is
dependent on the order it is placed in the list. To me having this order
dependent is just plain wrong! I believe the conditional delays should
take precedence since they are more specific.

No, order should not be important, and it should collect all
the delay paths. At run time, when the "in" value changes,
all the possible paths are activated. If "cond" is true, then
both in your example are activated. Then the runtime will
choose the delay that is smallest. In your example, with the
paths not yet annotated, that is clearly 1.5. But if by annotation
the conditional path is given a delay of 1.1, then it will
be chosen instead.

If Icarus Verilog does anything other, then it is a bug.
But I think it gets this right.

|> (Remember, since all the numbers specified delays can be
|> replaced
|> by annotation, you can't use the numbers in the Verilog
|> source
|> to determine the validity of anything.)
|
| If you are not using annotation you can! Yes I understand back
annotation; remember I was one of the people pushing for it.


Well, yeah, but the compiler doesn't know that. Only the run-time
knows.

|> If the unconditional path were slower (i.e. 1.9) it would
|> be more
|> obvious that the conditional path is useful. Then you get
|> the
|> effect of the simple path acting like an ifnone path. But
|> then
|> again, if back annotation changes the time to be small, you
|> are back where you are now.
|
| Again I don't buy this. Why should the magnitude of the delay have
anything to do with which path to select? Annotation has nothing to do
with this problem.

Because "14.3.3 Delay Selection" in the -2005 LRM says so.

"The simulator shall [select a specify path to use] by first
determining which specify paths to the output are active. Active
specify paths are those whose input has transitioned most recently
in time, and either they have no condition or their conditions
are true. In the presence of simultaneous input transitions, it
is possible for many specify paths to an output to be simultaneously
active."

~  (In your example, both paths have the input "in" so if the
~  "cond" is true when "in" changes, both paths will become active.)

"Once the active specify paths are identified, a delay must be
selected from among them. This is done by comparing the the correct
delay for the specific transition being scheduled from each [active]
specify path and choosing the smallest."

~  (In your example, since both paths are active, at transition time
~  for "out" it will choose the smaller, "1.5", unless SDF has changed
~  the delays for the paths.)

|> So I see no problem here. There is a delay selection
|> algorithm
|> to handle the case of multiple active paths to an output at
|> a
|> given time.
|>
|> The ifnone syntax doesn't not allow for there also to
|> be an
|> identical unconditional path mostly as a matter of syntax.
|> Ifnone paths are allowed to be without a matching
|> conditional
|> path, in which case they are treated as an unconditional
|> paths
|> and will be visible to the SDF annotator as such.
|>
|> If there are multiple paths that are indistinguishable to
|> the
|> SDF annotator, then *that* is a problem and the symantics
|> *do*
|> disallow that. That is the rule to live by.
|
| I guess I need to look at the delay selection algorithm a little
closer, but I still assert that something is incorrect here. The
annotator multiple paths is the strongest argument for why you can't
have both a simple and a ifnone path delay (they look the same). Is it
safe to assume the annotator creates new modpaths if on does not already
exist?

Icarus Verilog elaboration will create a modpath for both the
paths in your example. The vvp will have a .modpath for both
the paths in your example and the "out" signal will scan them
both when it is time to transition in order to figure out what
delay to use for the transition.

The $sdf_annotate system task, or any other VPI for that matter,
can find those paths by matching the endpoints and conditions,
and can assign different delays to each modpath.

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

iD8DBQFIEMQcrPt1Sc2b3ikRAt3NAJ4wHSWY7BfEUlpnEyBOxA4UihrQrQCfWVhH
tdAhaMx/MC9wMB9pEY4MgcQ=
=tl8Z
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Path delays simple, conditional and ifnone.

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

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

> | (in => out) = 1.5;
> | if (cond) (in => out) = 1.8;
> |
> | will make the delay from in to out 1.8 when the condition
> is true. If
> you swap the order of the statements the delay is always
> 1.5!

> Actually, I think your example is perfectly legal and
> useful.
> It is possible to have multiple path delays for a given
> output,
> and in that case, assuming they are all activated at once,
> the
> output delay in use is taken to be the shortest--in this
> case,
> 1.5. In fact, in your specific case, it will as you say
> always
> be 1.5 unless SDF annotation changes the simple path delay,
> which
> is a possibility. So although on the surface it seems like
> a
> waste, back annotation can turn it into something
> important.

You misunderstood what I wrote! With the order shown the delay is 1.8 if you swap the order of the two statements you get 1.5 and why would the smaller delay be correct? Depending on the situation the longer delay could be the worst case. The reason this is happening is that when the code is looking for a delay it uses the first it find which is dependent on the order it is placed in the list. To me having this order dependent is just plain wrong! I believe the conditional delays should take precedence since they are more specific.
 
> (Remember, since all the numbers specified delays can be
> replaced
> by annotation, you can't use the numbers in the Verilog
> source
> to determine the validity of anything.)

If you are not using annotation you can! Yes I understand back annotation; remember I was one of the people pushing for it.
 
> If the unconditional path were slower (i.e. 1.9) it would
> be more
> obvious that the conditional path is useful. Then you get
> the
> effect of the simple path acting like an ifnone path. But
> then
> again, if back annotation changes the time to be small, you
> are back where you are now.

Again I don't buy this. Why should the magnitude of the delay have anything to do with which path to select? Annotation has nothing to do with this problem.
 
> So I see no problem here. There is a delay selection
> algorithm
> to handle the case of multiple active paths to an output at
> a
> given time.
> 
> The ifnone syntax doesn't not allow for there also to
> be an
> identical unconditional path mostly as a matter of syntax.
> Ifnone paths are allowed to be without a matching
> conditional
> path, in which case they are treated as an unconditional
> paths
> and will be visible to the SDF annotator as such.
> 
> If there are multiple paths that are indistinguishable to
> the
> SDF annotator, then *that* is a problem and the symantics
> *do*
> disallow that. That is the rule to live by.

I guess I need to look at the delay selection algorithm a little closer, but I still assert that something is incorrect here. The annotator multiple paths is the strongest argument for why you can't have both a simple and a ifnone path delay (they look the same). Is it safe to assume the annotator creates new modpaths if on does not already exist?

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] Path delays simple, conditional and ifnone.

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

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

Cary R. wrote:
| I have started looking at implementing ifnone and in the process I'm
looking at the various delay constructs to see exactly how they work. In
doing this I ran into something that seems very strange. If you have
both a simple path delay and a state dependent path delay. Depending on
the order they appear in the specify block the state dependent delay can
be missed. For example:
|
| (in => out) = 1.5;
| if (cond) (in => out) = 1.8;
|
| will make the delay from in to out 1.8 when the condition is true. If
you swap the order of the statements the delay is always 1.5!
|
| I have not found anything in the spec. that talks about how this
should be resolved. I would expect the simple path delay to act like
ifnone and only fill in cases that are not explicitly covered with a
more specific conditional or it should be flagged as an error since you
are double specifying some of the cases. The only clue implying that
this may be legal is that in the ifnone description it mentions that it
is illegal to specify both an ifnone and a simply (unconditional) module
path. This would imply that ifnone and a simple path delay are identical
in functionality and that we need to make the simple path delay or
ifnone be a default that is used only if you cannot find an active path
in the normal list.
|
| Does the 2005 standard say anything more about this? Thoughts?

Actually, I think your example is perfectly legal and useful.
It is possible to have multiple path delays for a given output,
and in that case, assuming they are all activated at once, the
output delay in use is taken to be the shortest--in this case,
1.5. In fact, in your specific case, it will as you say always
be 1.5 unless SDF annotation changes the simple path delay, which
is a possibility. So although on the surface it seems like a
waste, back annotation can turn it into something important.

(Remember, since all the numbers specified delays can be replaced
by annotation, you can't use the numbers in the Verilog source
to determine the validity of anything.)

If the unconditional path were slower (i.e. 1.9) it would be more
obvious that the conditional path is useful. Then you get the
effect of the simple path acting like an ifnone path. But then
again, if back annotation changes the time to be small, you
are back where you are now.

So I see no problem here. There is a delay selection algorithm
to handle the case of multiple active paths to an output at a
given time.

The ifnone syntax doesn't not allow for there also to be an
identical unconditional path mostly as a matter of syntax.
Ifnone paths are allowed to be without a matching conditional
path, in which case they are treated as an unconditional paths
and will be visible to the SDF annotator as such.

If there are multiple paths that are indistinguishable to the
SDF annotator, then *that* is a problem and the symantics *do*
disallow that. That is the rule to live by.

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

iD8DBQFIEKUtrPt1Sc2b3ikRAmhhAJ998l89g7LTY0XHXhfUxuhNlMa4RACfaCn9
7ugs8Gx8aQ7TfW+4CIMZVXE=
=Qfp6
-----END PGP SIGNATURE-----

[Iverilog-devel] Path delays simple, conditional and ifnone.

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

I have started looking at implementing ifnone and in the process I'm looking at the various delay constructs to see exactly how they work. In doing this I ran into something that seems very strange. If you have both a simple path delay and a state dependent path delay. Depending on the order they appear in the specify block the state dependent delay can be missed. For example:

(in => out) = 1.5;
if (cond) (in => out) = 1.8;

will make the delay from in to out 1.8 when the condition is true. If you swap the order of the statements the delay is always 1.5!

I have not found anything in the spec. that talks about how this should be resolved. I would expect the simple path delay to act like ifnone and only fill in cases that are not explicitly covered with a more specific conditional or it should be flagged as an error since you are double specifying some of the cases. The only clue implying that this may be legal is that in the ifnone description it mentions that it is illegal to specify both an ifnone and a simply (unconditional) module path. This would imply that ifnone and a simple path delay are identical in functionality and that we need to make the simple path delay or ifnone be a default that is used only if you cannot find an active path in the normal list.

Does the 2005 standard say anything more about this? Thoughts?

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 Wed, 4/23/08, Stephen Williams <st...@ic...> wrote:
 
> Yeah, at least post them. I'm curious.

It has been some time since I looked at this. I believe the 0 array index is the aval and the 1 array index is the bval. The basic two input gates have a comparison to see that they are working correctly. The more complex  and single input gates print the output and the s (for the complex gates is this a H/L) value, so if the s output is 1 you need to translate the normal output. The X versions of the gates just put out an x for the H/L case. I left the cmos gate as an exercise for the user ;-). You can verify the result by reading columns left to right from the specification.

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] More performance improvements for addition and subtraction

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

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

Stephen Williams wrote:
|
| I've pushed into git another wave of performance improvements for
| thread add and subtract. They now take full advantage of the most
| recent vector encoding changes. With these commits I've seen yet
| another 14% improvement in run time of the multiple_long.v test
| in the ivtest suite.

For the record, multiply_long.v compiled and run with the 0.8
compiler takes 17 seconds on my machine, and with the current git
takes 6 seconds. I think we're *finally* getting a handle on the
run time performance of this beast.


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

iD8DBQFID6rcrPt1Sc2b3ikRAm9uAJ4tL7zE/hLKQA5/Xb7yHCutoULSbACfW6kX
+CRm023u626uot4t80Q1Gsg=
=dAy0
-----END PGP SIGNATURE-----