iverilog-devel — Conversations on matters of Icarus Verilog development

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

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

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

> As for accepting assign/deassign of bit/part select, I guess we
> can add support to them if it is not too hard. We may want to
> think about adding a warning type "extensions" that would flag
> this sort of thing so that people can vet their code for portability.

assign appears to be finished and deassign is almost there. If we are
going to have a warning of this we should also add it for force and
release. I'll have to look and see what array words do.

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

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

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

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

Cary R. wrote:
> I'm working on the implementation for assign/deassign of bit and part
> selects and decided to see what the standard had to say. Very interesting!
> 
> For reference this is what it says about assign (section 9.3 page 125
> 1364-2001):
> 
> The left-hand side of the assignment in the assign statement shall be a
> variable reference or a concatenation of variables. It shall not be a
> memory word (array reference) or a bit-select or a part-select of a
> variable.

It says the same thing. I understand why they disallow memory words,
and we should stick with that. I'm surprised about the bit/part
select exclusion, but given the trouble *we* are having with it,
I can understand why it is there;-)

> The way I read this is that an assign only works on a register/etc. type
> not a wire (net). The standard say we shouldn't allow an assign to an
> array word, but we don't distinguish between individual array words and a
> normal variable. Bit and part selects are not allowed, but I'm working on
> implementing them.
> 
> It says basically the same think for force except it allows force to work
> on either variables or nets. Though it is missing the array word
> exclusion. 

The 2005 spec is explicit that it should not allow memory words
or array references. I think we *can* allow array references if
the address expression is constant. I think that would be more
interesting then adding assign/deassign to bit/part selects.

As for accepting assign/deassign of bit/part select, I guess we
can add support to them if it is not too hard. We may want to
think about adding a warning type "extensions" that would flag
this sort of thing so that people can vet their code for portability.

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

iD8DBQFH/CaprPt1Sc2b3ikRAju5AJ4poCfp3mj7FFxyzU83+SGQ5iXocQCg3RbX
5SCuAEaBGCqvoXiv4PS2dgQ=
=fTt+
-----END PGP SIGNATURE-----

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

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

--- Larry Doolittle <ldo...@re...> wrote:
 
> You have to let me assign to a wire.
> All Verilog code that I've seen is full of that construct.

I guess I forgot to mention this is for a procedural assign:

initial begin
  rval = 1'b0;
  #1 assign rval = 1'b1;
  #1 deassign rval;
end

This has nothing to do with a normal continuous assignment which only
works on wires.

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

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

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

Cary -

On Tue, Apr 08, 2008 at 05:29:01PM -0700, Cary R. wrote:
> The left-hand side of the assignment in the assign statement shall be a
> variable reference or a concatenation of variables. It shall not be a
> memory word (array reference) or a bit-select or a part-select of a
> variable.
> 
> The way I read this is that an assign only works on a register/etc. type
> not a wire (net).

You have to let me assign to a wire.
All Verilog code that I've seen is full of that construct.

   - Larry

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

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

I'm working on the implementation for assign/deassign of bit and part
selects and decided to see what the standard had to say. Very interesting!

For reference this is what it says about assign (section 9.3 page 125
1364-2001):

The left-hand side of the assignment in the assign statement shall be a
variable reference or a concatenation of variables. It shall not be a
memory word (array reference) or a bit-select or a part-select of a
variable.

The way I read this is that an assign only works on a register/etc. type
not a wire (net). The standard say we shouldn't allow an assign to an
array word, but we don't distinguish between individual array words and a
normal variable. Bit and part selects are not allowed, but I'm working on
implementing them.

It says basically the same think for force except it allows force to work
on either variables or nets. Though it is missing the array word
exclusion. 

Can someone look at 2005 and see if it says anything different. Do we
still want this functionality as an enhancement? For now I'm assuming we
do. If nothing else to make force and assign match.

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

Re: [Iverilog-devel] Add git commit information to version strings

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

Stephen Williams wrote:
> I think Jeevan's proposal (is that how you wish to be addressed?) is
> to generate the version stamp from within a git context then copy
> that information into the snapshot. There was some scripting to
> automate that.

Larry Doolittle wrote:
> I humbly request that a sensible way to make such a snapshot
> be found, documented (scripted?), and close to what Steve does
> for his public snapshots.

Here is a little script, based on what Steve said in an earlier post, that will recreate the 20080314 snapshot (without the autom4te.cache directories). It needs to be run in the directory with the git repo, but it doesn't change anything in that directory; the /tmp/verilog-20080314 directory is remade, though. (Run with sh -x to see what goes on.)

#!/bin/sh

tag_date=20080314
tag=s$tag_date
snapshot=verilog-$tag_date

# Clean out any old packing directory.
rm -rf /tmp/$snapshot
# Get sources from git for the given snapshot
# and put them in the packing directory.
git archive --format=tar --prefix=$snapshot/ $tag \
    | tar -x -C /tmp
# Housekeeping.
(cd /tmp/$snapshot && sh autoconf.sh)
#--- Version specific things, e.g., version.h
#--- & verilog.spec, can be built here.
# Pack it up.
(cd /tmp && tar -cO --exclude 'autom4te.cache' $snapshot \
    | gzip -9 > $snapshot.tar.gz)
# Look at the result
ls -l /tmp/$snapshot.tar.gz

 I ran diff on the publicly available 20080314 snapshot and the one this script built, and they were same except for the configure files and the lexor_keyword.cc file, because my autoconf and gperf put different version numbers into those files. It builds and runs alright (`make check' passes).

Larry Doolittle wrote:
> One more thing: the current version of version.h handling
> breaks the write-protected pristine-source build concept.
> The reference source tree should not be touched with an
> out-of-tree configure/make.

That was nagging me, too.  I have a scheme that avoids touching the source tree and does not break compilation if the version file is missing, but i've run into a bootstrapping issue with make.  I'll have something to show in a day or two.

Cary R. wrote:
> Thanks for taking care of this!

Glad to be of help. Thank you all, for the comments.
Jeevan



      ____________________________________________________________________________________
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

Re: [Iverilog-devel] Add git commit information to version strings

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

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

> So replace (<snapshot data>) with the git describe output and we're
> there. I think that's what Jeevan did for us. The trick is getting
> that information stamped into snapshots that are exported outside of
> git: snapshots and releases.

> Here's what I get locally at the moment:
> 
>     s20080314-33-gad3a73f

This sounds fine. If possible we want the snapshot to be just s20080314
and it looks like that is what you get when you specify a tag directly.
The other stuff appears to be specific to the local repository so it is
not that great at showing where the local repository is relative to the
master. I'm getting s20080314-164-g423bd07 and s20080314-263-ged7aba7 on
my two machines and both just had a git pull/make so they are synced. This
is likely because the last command "merge branch" is a local modification
and hence has a different ID. It would have been best if the two matched
so we could easily tell where people where.

Not perfect, but much better than what we had before.

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

Re: [Iverilog-devel] Add git commit information to version strings

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

On Mon, Apr 07, 2008 at 09:03:49AM -0700, Stephen Williams wrote:
> Yes, this is a little awkward. When I make a tagged snapshot, that
> file contains so Makefile, but does contain the configure scripts.
                ^^no
> There is an "auconf.sh" script that generates the configure and a
> few other files. There is no "git" context in that case.

This is a great discussion, and welcome progress.
I do second Steve's concern that the snapshot process be
better supported.

I often make snapshots for my internal use.  My process used to be:

cp -a verilog /tmp/verilog-foo
cd /tmp/verilog-foo
rm -rf .git
sh autoconf.h
rm -r `find . -name autom4te.cache`
cd ..
tar -cvzf verilog-foo.tar.gz verilog-foo

but the latest git version string patch broke this.

I'm getting more comfortable working within the original git
tree [*], so I could imagine replacing the copy and rm .git
step with an in-place "tar --exclude=.git".  And having
a proper version tag in the result would certainly be nice.
Then a tidy-up step would be added at the end:
  rm `find . -name configure` lexor_keyword.cc version.h

I humbly request that a sensible way to make such a snapshot
be found, documented (scripted?), and close to what Steve does
for his public snapshots.

One more thing: the current version of version.h handling
breaks the write-protected pristine-source build concept.
The reference source tree should not be touched with an
out-of-tree configure/make.

       - Larry

[*] git bisect rocks!

Re: [Iverilog-devel] Add git commit information to version strings

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

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

Cary R. wrote:
> --- Jeevan Varshney <jva...@ya...> wrote:
> 
>>     make dist TAG=<tagname>
> 
> Make sure you remember that a distribution does not contain any
> configuration information and the Makefiles are part of that, so it
> appears we will need to use the Makefiles from our build tree to do the
> make dist, but we want the version information to only apply to the
> distribution being built. We want the git build tree to reflect the latest
> version info. I don't think this is a big deal it just all has to be kept
> straight.

Yes, this is a little awkward. When I make a tagged snapshot, that
file contains so Makefile, but does contain the configure scripts.
There is an "auconf.sh" script that generates the configure and a
few other files. There is no "git" context in that case.

I think Jeevan's proposal (is that how you wish to be addressed?) is
to generate the version stamp from within a git context then copy
that information into the snapshot. There was some scripting to
automate that. I'm not sure if I like that idea or not. I don't know
yes.

> This does bring up a question. For snapshots and releases it's fairly easy
> to figure out what the version should be, follow the existing pattern
> 0.8.6, 0.9.devel (<snapshot date>), but what version is the latest git
> (either 0.8 or 0.9)? It would be nice is we could identify that the build
> was being done in a git repository and use the latest information possibly
> something like  0.8.6 + git(<latest git patch date>) and 0.9.devel +
> git(<...>). Ideally this would be done automatically without a bunch of
> extra files being regenerated (definitely avoid having to rerun autoconf).

I think the beauty of the "git describe" generated name is that it
includes all this information: It includes the most recent tag, the
distance from that tag, and a good hint which branch away from that
tag. That gives us enough information to pin a build down to an
exact commit. It makes sense to include that information in all
distributions, released or not.

So replace (<snapshot data>) with the git describe output and we're
there. I think that's what Jeevan did for us. The trick is getting
that information stamped into snapshots that are exported outside of
git: snapshots and releases.

> Something like:
> 
> git pull
> make
> <remakes any files changed in the pull and also the main driver programs
> that contain version information>
> 
> The version files should probably also be updated when we do a local
> commit, but while it could be useful, I think local changes (when we are
> working on bugs) should not trigger a version change. Can we distinguish
> between a main commit and a local commit? If so showing the version as
> "local" could be nice. We just have to make sure it gets switched to
> normal when the patch finally makes it into the main repository.

Here's what I get locally at the moment:

    s20080314-33-gad3a73f

The s20080314 is the closest tag,
the -33- is the distance, measured in commits, from that tag, and
the -gad3a73f is an abreviation of the head commit.
I think that completely identifies the source tree.

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

iD8DBQFH+kXlrPt1Sc2b3ikRAu5yAKCl7ybEjeWQX25jRDqMG+BCsn5eKQCgtQ2H
OEk1d3J8+z+Ixigh4RB8aAM=
=MROc
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Add git commit information to version strings

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

--- Jeevan Varshney <jva...@ya...> wrote:

>     make dist TAG=<tagname>

Make sure you remember that a distribution does not contain any
configuration information and the Makefiles are part of that, so it
appears we will need to use the Makefiles from our build tree to do the
make dist, but we want the version information to only apply to the
distribution being built. We want the git build tree to reflect the latest
version info. I don't think this is a big deal it just all has to be kept
straight.

This does bring up a question. For snapshots and releases it's fairly easy
to figure out what the version should be, follow the existing pattern
0.8.6, 0.9.devel (<snapshot date>), but what version is the latest git
(either 0.8 or 0.9)? It would be nice is we could identify that the build
was being done in a git repository and use the latest information possibly
something like  0.8.6 + git(<latest git patch date>) and 0.9.devel +
git(<...>). Ideally this would be done automatically without a bunch of
extra files being regenerated (definitely avoid having to rerun autoconf).

Something like:

git pull
make
<remakes any files changed in the pull and also the main driver programs
that contain version information>

The version files should probably also be updated when we do a local
commit, but while it could be useful, I think local changes (when we are
working on bugs) should not trigger a version change. Can we distinguish
between a main commit and a local commit? If so showing the version as
"local" could be nice. We just have to make sure it gets switched to
normal when the patch finally makes it into the main repository.


Thanks for taking care of this!

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

[Iverilog-devel] Add git commit information to version strings

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

This is in regards to patch request 1935736 at http://sourceforge.net/tracker/index.php?func=detail&aid=193573&group_id=149850&atid=775999

Stephen Williams wrote:
> I'm a little concerned how this will impact the making of 
> snapshots. In particular, I use "get-archive" to export by tag. I 
> then extract the generated tar file, run the autoconf.sh script, 
> and re-tar to make the actual snapshot bundle.

> With this patch, the version.h header file is missing, and there is 
> no way to generate it once it is exported. We should discuss in the 
> iverilog-devel list what to do about this. Please follow up there 
> with any ideas you might have.

The git sources reveal that the git maintainers also use `git archive' to make a distribution tarball and use `git describe' to obtain a version string for their distribution.  They have a `dist' target in their Makefile which appends the file with the version to the tarball.  Also, instead of using a C include file for the version, like i did, they use a make include file; which allows them to automatically use the version in the tarball name and the RPM spec file.

Along those lines, i could add a `dist' target to Makefile.in that would automatically build a tarball for a given tag (or the head, by default) and add the version information file and an updated verilog.spec file to it.  One possible implementation would look like below.

In Makefile.in

    TAG ?= HEAD

    version.mk:
        # Put `VERSION = <output of git-describe $(TAG)>' in version.mk

    include version.mk

    all: ... version.mk
        ...
        cd driver; make VERSION=$(VERSION) $@

    verilog.spec: verilog.spec.in version.mk
        # Replace @@VERSION@@ with $(VERSION)

    SNAPSHOT = verilog-$(VERSION)
    dist: version.mk verilog.spec
        # Use git-archive $(TAG) to create $(SNAPSHOT).tar
        # Unpack to $(SNAPSHOT)
        # Copy version.mk and verilog.spec to $(SNAPSHOT)
        # Run autoconf.sh in $(SNAPSHOT)
        # Repack and compress $(SNAPSHOT) to $(SNAPSHOT).tar.gz

In driver/Makefile.in

    main.o: ... ../version.mk

The above example assumes that the verilog.spec file has been replaced with a verilog.spec.in file, and for simplicity's sake, there is just one version string instead of the two that i had in my patch.  The latter brings me to a question i have: should the "0.9.devel" version string be treated any differently than i did? I just left it as it was.

And, of course, anything else that needs to be done to make a snapshot can be added to the `dist' target.

In the end making a snapshot would look like below.

    make dist TAG=<tagname>




      ____________________________________________________________________________________
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

Re: [Iverilog-devel] iverilog-vpi options

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

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

> Perhaps so. It's been lower then low priority because the existing
> iverilog-vpi's (script or mingw-C) have been stable, so the issue of
> duplication of effort is aesthetically icky, but pragmatically not
> a real worry.

Pragmatism is expected to dominate in a resource constrained environment.
It's usually only the aesthetically hideous issues that get addressed. And
don't get me started on aesthetically icky code that is perfectly
functional. I suppose it doesn't help that we are using C/C++. Which is
just part of the toll we pay for portability.

> But then again, do the aesthetics really improve if you put a
> Rothko and an Escher into a food processor?

Improved? No I think that might be a bit strange!

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

Re: [Iverilog-devel] iverilog-vpi options

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

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

Cary R. wrote:
> --- Stephen Williams <st...@ic...> wrote:
>  
>> I wonder if it makes sense to abandon the shell script version
>> and merge everything into the "mingw" iverilog-vpi. Maybe, maybe not
>> but there is a little bit of duplication of effort there.
> 
> Have you looked at the mingw driver code? To me the shell script is
> simple, obvious and easy to work on. The mingw driver is anything but. I
> agree it would be best to have common code for this, but I think a rewrite
> should be done first.

Perhaps so. It's been lower then low priority because the existing
iverilog-vpi's (script or mingw-C) have been stable, so the issue of
duplication of effort is aesthetically icky, but pragmatically not
a real worry.

But then again, do the aesthetics really improve if you put a
Rothko and an Escher into a food processor?

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFH9rdZrPt1Sc2b3ikRAkJgAKCWppj/lsokcXubRuUL3VZfmUGIxgCeP1HZ
EyQUfP+cClAvkIN1dKJxB6k=
=c1yq
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] iverilog-vpi options

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

--- Stephen Williams <st...@ic...> wrote:
 
> I wonder if it makes sense to abandon the shell script version
> and merge everything into the "mingw" iverilog-vpi. Maybe, maybe not
> but there is a little bit of duplication of effort there.

Have you looked at the mingw driver code? To me the shell script is
simple, obvious and easy to work on. The mingw driver is anything but. I
agree it would be best to have common code for this, but I think a rewrite
should be done first.

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

Re: [Iverilog-devel] iverilog-vpi options

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

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


I wonder if it makes sense to abandon the shell script version
and merge everything into the "mingw" iverilog-vpi. Maybe, maybe not
but there is a little bit of duplication of effort there.

Larry Doolittle wrote:
> On Fri, Apr 04, 2008 at 03:00:35PM -0700, Cary R. wrote:
>> If you would like to see a -L option added to iverilog-vpi please add it
>> as a feature request here
>> (http://sourceforge.net/tracker/?group_id=149850&atid=776000).
>>
>> I agree it is odd that the shell script version of iverilog-vpi does not
>> complain about extra flags. The mingw version (executable) does complain
>> about extra options.
> 
> Patch to Unix iverilog-vpi appended, for discussion.
> That only leaves the mingw version and the documentation.
> 
>    - Larry
> 
> --- /home/ldoolitt/bin/iverilog-vpi	2008-04-04 10:35:34.000000000 -0700
> +++ iverilog-vpi	2008-04-04 15:13:25.000000000 -0700
> @@ -85,6 +85,9 @@
>      -D*) DEFS="$DEFS $parm"
>  	 ;;
>  
> +    -L*) LDFLAGS="$LDFLAGS $parm"
> +	 ;;
> +
>      --cflags)
>  	 echo "$CFLAGS"
>  	 exit;
> @@ -104,6 +107,9 @@
>  	 echo "/home/ldoolitt/lib/ivl"
>  	 exit
>  	 ;;
> +    *)
> +	 echo "$0: warning: unhandled $parm" 1>&2
> +	 ;;
>      esac
>  
>  done
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 


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

iD8DBQFH9qpErPt1Sc2b3ikRAowGAJ91BFGZfyDaQgo9QYr3U1OWdNM3TACeOlMd
72HS5FV6wLkOn2P5bEXzwEs=
=Srf7
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] iverilog-vpi options

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

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

> Patch to Unix iverilog-vpi appended, for discussion.
> That only leaves the mingw version and the documentation.

I don't think you want to reuse the LDFLAGS variable since the user
supplied libraries will be added after the defaults. I think we want a new
variable like how -l is handled LIB vs LDLIBS and LIB is before LDLIBS on
the link line.

While you are at it delete the RCS line.

I can fix the mingw code, but I still think we should have a request to
connect all the fixes to.

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

Re: [Iverilog-devel] iverilog-vpi options

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

On Fri, Apr 04, 2008 at 03:00:35PM -0700, Cary R. wrote:
> If you would like to see a -L option added to iverilog-vpi please add it
> as a feature request here
> (http://sourceforge.net/tracker/?group_id=149850&atid=776000).
> 
> I agree it is odd that the shell script version of iverilog-vpi does not
> complain about extra flags. The mingw version (executable) does complain
> about extra options.

Patch to Unix iverilog-vpi appended, for discussion.
That only leaves the mingw version and the documentation.

   - Larry

--- /home/ldoolitt/bin/iverilog-vpi	2008-04-04 10:35:34.000000000 -0700
+++ iverilog-vpi	2008-04-04 15:13:25.000000000 -0700
@@ -85,6 +85,9 @@
     -D*) DEFS="$DEFS $parm"
 	 ;;
 
+    -L*) LDFLAGS="$LDFLAGS $parm"
+	 ;;
+
     --cflags)
 	 echo "$CFLAGS"
 	 exit;
@@ -104,6 +107,9 @@
 	 echo "/home/ldoolitt/lib/ivl"
 	 exit
 	 ;;
+    *)
+	 echo "$0: warning: unhandled $parm" 1>&2
+	 ;;
     esac
 
 done

Re: [Iverilog-devel] iverilog-vpi options

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

If you would like to see a -L option added to iverilog-vpi please add it
as a feature request here
(http://sourceforge.net/tracker/?group_id=149850&atid=776000).

I agree it is odd that the shell script version of iverilog-vpi does not
complain about extra flags. The mingw version (executable) does complain
about extra options.

Regards,

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

[Iverilog-devel] iverilog-vpi options

[Carlos S. <cse...@lb...>]

Hello,
        
I was instinctively using the -L option in the iverilog-vpi command line
and found a couple of issues. First, it wouldn't complain or print a
usage message about a not defined option (-L) since there is not a
default in the case block handling them. Then it came the wish of being
able to add them to the icarus ldflags and found a walk-around which is:

gcc -o <output file> <object files> -Lsomething -lsomething
`iverilog-vpi --ldflags`

Cheers,

Carlos Serrano

Re: [Iverilog-devel] need a language-lawyer ruling and/or a bug fix

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

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

Larry Doolittle wrote:
> Cary -
> 
> On Wed, Apr 02, 2008 at 02:29:45PM -0700, Cary R. wrote:
>> --- Larry Doolittle <ldo...@re...> wrote:
>>  
>>> The attached code shows a change in behavior in recent
>>> (as of March 20) git.  It triggered a failure in my
>>> inverse regression test.  I need to know if my Verilog
>>> assumptions are wrong, or the new Icarus behavior is wrong.
>> This does seem to be slightly incorrect. Section 3.6 in 1364-2001 implies
>> that the initial value should be z, but then the driver value should
>> propagate. Given that this hasn't happened after #10 implies that the x is
>> not propagating after the initial z.
> 
> Icarus, both before and after the patch in question,
> gives "x" for the uninitialized fdbk_err_wide (sorry
> about the strange names, this was stripped from a larger
> code base and I didn't bother to change names).

That's correct. variables have an initial value of x, and
wires have an initial value of z.

> The behavior change is how "x" propagates through the ternary
> expression.  The old result (that I expect) is it comes out "x".
> After the commit in question, it comes out "z".
> 
> I din't try to isolate this to a particular mux input; in this
> case all three mux inputs are derived from fdbk_err_wide.  My
> wild guess is that the confusion comes from the control input
> to the mux.

Could be. The first place to look for this would be constant
inputs to functors that are not being propagated.

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

iD8DBQFH9X6OrPt1Sc2b3ikRAs0CAJ4gowxIqmyi6ED98Lp/XW0EgcUvMwCg5F9q
c5nA7gD/MCmf6F4VjqYGrhk=
=6T0T
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] need a language-lawyer ruling and/or a bug fix

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

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

Cary R. wrote:
> --- Larry Doolittle <ldo...@re...> wrote:
>  
>> The attached code shows a change in behavior in recent
>> (as of March 20) git.  It triggered a failure in my
>> inverse regression test.  I need to know if my Verilog
>> assumptions are wrong, or the new Icarus behavior is wrong.
> 
> This does seem to be slightly incorrect. Section 3.6 in 1364-2001 implies
> that the initial value should be z, but then the driver value should
> propagate. Given that this hasn't happened after #10 implies that the x is
> not propagating after the initial z.
> 
> For clarity this is how I am thinking things should work.
> 
> assign tmp = 1'bx;
> 
> should set tmp to x sometime during the first time step.
> 
> assign #1 tmp = 1'bx;
> 
> should set tmp to x during the 1 time step and tmp is z before that.
> 
> Your case is clearly the first case and the x value is not propagating
> correctly. This could be a far reaching problem since the basic code in
> the patch you referenced is at least conceptually copied from other
> places.

I agree. This deserves a bug report. the bug is probably that the
initial conditions are not being propagated through some net
operators.

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

iD8DBQFH9X4XrPt1Sc2b3ikRAvrtAJ9kExfubA0mHL9dDAye4CMmGRhEEwCfeZ6T
K+Oplb/gcunuBPVttq+Nlac=
=ffJL
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] need a language-lawyer ruling and/or a bug fix

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

--- Larry Doolittle <ldo...@re...> wrote:
 
> Icarus, both before and after the patch in question,
> gives "x" for the uninitialized fdbk_err_wide.

A register is different than a net! Registers have x as their default
value. Nets use z.

The problem is likely that since the z was already scheduled to appear at
T0 it did not propagate the x correctly.

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

[Iverilog-devel] valgrind and Icarus development

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

FYI I have been using valgrind to fix memory management and initialization
problem in the development branch of Icarus over the last month or so.
With the patches I submitted last night the entire test suite except for
memmon in the vpi tests pass without error! The errors in memmon are
specific to the problem that prevents it from working.

There are still memory leaks (which are not considered errors) and I plan
to look at them when I have some free time. I can supply the specialized
versions of vvp_reg.pl and vpi_reg.pl if anyone else is interested in
looking at the memory leaks. Or it may be better to just add them to the
test suite.

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

Re: [Iverilog-devel] need a language-lawyer ruling and/or a bug fix

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

Cary -

On Wed, Apr 02, 2008 at 02:29:45PM -0700, Cary R. wrote:
> --- Larry Doolittle <ldo...@re...> wrote:
>  
> > The attached code shows a change in behavior in recent
> > (as of March 20) git.  It triggered a failure in my
> > inverse regression test.  I need to know if my Verilog
> > assumptions are wrong, or the new Icarus behavior is wrong.
> 
> This does seem to be slightly incorrect. Section 3.6 in 1364-2001 implies
> that the initial value should be z, but then the driver value should
> propagate. Given that this hasn't happened after #10 implies that the x is
> not propagating after the initial z.

Icarus, both before and after the patch in question,
gives "x" for the uninitialized fdbk_err_wide (sorry
about the strange names, this was stripped from a larger
code base and I didn't bother to change names).

The behavior change is how "x" propagates through the ternary
expression.  The old result (that I expect) is it comes out "x".
After the commit in question, it comes out "z".

I din't try to isolate this to a particular mux input; in this
case all three mux inputs are derived from fdbk_err_wide.  My
wild guess is that the confusion comes from the control input
to the mux.

   - Larry

Re: [Iverilog-devel] need a language-lawyer ruling and/or a bug fix

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

--- Larry Doolittle <ldo...@re...> wrote:
 
> The attached code shows a change in behavior in recent
> (as of March 20) git.  It triggered a failure in my
> inverse regression test.  I need to know if my Verilog
> assumptions are wrong, or the new Icarus behavior is wrong.

This does seem to be slightly incorrect. Section 3.6 in 1364-2001 implies
that the initial value should be z, but then the driver value should
propagate. Given that this hasn't happened after #10 implies that the x is
not propagating after the initial z.

For clarity this is how I am thinking things should work.

assign tmp = 1'bx;

should set tmp to x sometime during the first time step.

assign #1 tmp = 1'bx;

should set tmp to x during the 1 time step and tmp is z before that.

Your case is clearly the first case and the x value is not propagating
correctly. This could be a far reaching problem since the basic code in
the patch you referenced is at least conceptually copied from other
places.

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