summaryrefslogtreecommitdiff
path: root/cad
diff options
context:
space:
mode:
authordmcmahill <dmcmahill>2001-04-28 03:15:26 +0000
committerdmcmahill <dmcmahill>2001-04-28 03:15:26 +0000
commitabc891b836fd0b6348d3793c48de690a7510adf8 (patch)
treec3ec700dabf610741d189d86cb9c249b700fdc5b /cad
parentd27e07e48267da3c0048e1f9e31e3a0ead435d63 (diff)
downloadpkgsrc-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/Makefile6
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/