diff options
author | dmcmahill <dmcmahill> | 2001-04-28 03:15:26 +0000 |
---|---|---|
committer | dmcmahill <dmcmahill> | 2001-04-28 03:15:26 +0000 |
commit | abc891b836fd0b6348d3793c48de690a7510adf8 (patch) | |
tree | c3ec700dabf610741d189d86cb9c249b700fdc5b /cad | |
parent | d27e07e48267da3c0048e1f9e31e3a0ead435d63 (diff) | |
download | pkgsrc-abc891b836fd0b6348d3793c48de690a7510adf8.tar.gz |
update to verilog-current-20010422
Changes since the last packaged snapshot from the authors announcements:
Icarus Verilog snapshot 20010422
--------------------------------
I've integrated a bunch of UDP patches from Stephan Boettcher. These
go to the core of ivl, so if you use Icarus Verilog with UDPs, you
might want to give this a test for us.
Stephan has also added some ivl_target support for UDP devices. This is a
prerequisite to vvp support for UDP devices.
Some of you have been beating me over the head about disable, so the
vvp target now supports disable. It only works in certain very constrained
situations, but the idea is there and the more common cases are simply a
matter of getting around to them. I actually could use more examples of
the use of disable for the test suite.
In the process, I have settled on the interaction of threads and scopes,
and changed the %fork syntax to match. See the README.txt and opcodes.txt
file for details. The implementation of %end and %join simplified in
the process.
The vvp-tgt code generator supports a few more gate types. New gate
types are pretty easy to add, it's just boring grunt work. That's why
they've been popping up slowly.
I've also got certain behavioral shifts working. Only constant shifts,
so far, but this covers a pretty large percentage of the real world
uses of shift, I think.
I fixed a few specify block parse problems, so it should ignore
even more complex specify blocks now:-) One of these days I really will
properly support specify blocks.
PROGRESS
I was hoping to get vvp up to a similar level as vvm by the end of
April, but that doesn't look like it's going to happen. I'm up to 182
tests passed, compared to 318 of Icarus Verilog/vvm, so I have a ways
to go yet. I see no real point to making a release until I get up to
300 or so tests passed. That is the goal for 0.5 release.
But of course if vvp is enough for you, then it is soooo much faster
then vvm.
Icarus Verilog 20010415 Snapshot
--------------------------------
As with all the most recent snapshots, this is almost entirely progress
with the vvp code generator and simulation engine. I'm up to 159 tests
passed in the test suite, so I'm getting there. But there's still plenty
to go.
I also fixed what appeared to be a minor problem with elaboration of ?:
expressions in continuous assignments. The code was actually fine, it
was a spurious assert. This fix affects vvm as well.
Icarus Verilog/vvp now support <= statemements with internal delays.
That is, "foo <= #10 bar;" should work properly, and there are tests
in the suite that prove it. This is a pretty common syntax, so this
should help a lot of folks.
I also fixed a bug in the code generator that would cause it to put a
constant bit as a destination for the bitwise boolean operators. This
caused run-time asserts.
The event or support in vvp has been extended to now support arbitrary
width, so now you can for example wit for any changes in a 32bit reg.
This handles most of the likely cases, so @ statements should now be
pretty generally functional.
The handling of run-time threads has been revamped in preparation for
support of the disable statement. It also plugs a memory leak where
fork/join and task/function calls are invoked. And this version should
also clean up all those tiny initial foo=bar threads that all programs
seem to have. Threads that are done are now freed, along with their
memory, hopefully reducing the runtime memory footprint.
That's pretty much it this time 'round. Working with threads took some
time, so the progress isn't as flashy as it sometimes is.
There is still lots to do with vvp before 0.5, but I would appreciate
any feedback you can offer. It's complete enough already that I'm able
to accept bug reports on it, even if it turns out to be a "not supported
yet" type of thing. At this point, I'd be curious to know what hangups
are preventing its regular use.
Diffstat (limited to 'cad')
-rw-r--r-- | cad/verilog-current/Makefile | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/cad/verilog-current/Makefile b/cad/verilog-current/Makefile index c36363e40f6..86885331716 100644 --- a/cad/verilog-current/Makefile +++ b/cad/verilog-current/Makefile @@ -1,8 +1,8 @@ -# $NetBSD: Makefile,v 1.16 2001/04/14 14:47:29 dmcmahill Exp $ +# $NetBSD: Makefile,v 1.17 2001/04/28 03:15:26 dmcmahill Exp $ # -DISTNAME= verilog-20010407 -PKGNAME= verilog-current-20010407 +DISTNAME= verilog-20010422 +PKGNAME= verilog-current-20010422 CATEGORIES= cad MASTER_SITES= ftp://icarus.com/pub/eda/verilog/snapshots/ |