head 1.4; access; symbols pkgsrc-2013Q2:1.4.0.54 pkgsrc-2013Q2-base:1.4 pkgsrc-2012Q4:1.4.0.52 pkgsrc-2012Q4-base:1.4 pkgsrc-2011Q4:1.4.0.50 pkgsrc-2011Q4-base:1.4 pkgsrc-2011Q2:1.4.0.48 pkgsrc-2011Q2-base:1.4 pkgsrc-2009Q4:1.4.0.46 pkgsrc-2009Q4-base:1.4 pkgsrc-2008Q4:1.4.0.44 pkgsrc-2008Q4-base:1.4 pkgsrc-2008Q3:1.4.0.42 pkgsrc-2008Q3-base:1.4 cube-native-xorg:1.4.0.40 cube-native-xorg-base:1.4 pkgsrc-2008Q2:1.4.0.38 pkgsrc-2008Q2-base:1.4 pkgsrc-2008Q1:1.4.0.36 pkgsrc-2008Q1-base:1.4 pkgsrc-2007Q4:1.4.0.34 pkgsrc-2007Q4-base:1.4 pkgsrc-2007Q3:1.4.0.32 pkgsrc-2007Q3-base:1.4 pkgsrc-2007Q2:1.4.0.30 pkgsrc-2007Q2-base:1.4 pkgsrc-2007Q1:1.4.0.28 pkgsrc-2007Q1-base:1.4 pkgsrc-2006Q4:1.4.0.26 pkgsrc-2006Q4-base:1.4 pkgsrc-2006Q3:1.4.0.24 pkgsrc-2006Q3-base:1.4 pkgsrc-2006Q2:1.4.0.22 pkgsrc-2006Q2-base:1.4 pkgsrc-2006Q1:1.4.0.20 pkgsrc-2006Q1-base:1.4 pkgsrc-2005Q4:1.4.0.18 pkgsrc-2005Q4-base:1.4 pkgsrc-2005Q3:1.4.0.16 pkgsrc-2005Q3-base:1.4 pkgsrc-2005Q2:1.4.0.14 pkgsrc-2005Q2-base:1.4 pkgsrc-2005Q1:1.4.0.12 pkgsrc-2005Q1-base:1.4 pkgsrc-2004Q4:1.4.0.10 pkgsrc-2004Q4-base:1.4 pkgsrc-2004Q3:1.4.0.8 pkgsrc-2004Q3-base:1.4 pkgsrc-2004Q2:1.4.0.6 pkgsrc-2004Q2-base:1.4 pkgsrc-2004Q1:1.4.0.4 pkgsrc-2004Q1-base:1.4 pkgsrc-2003Q4:1.4.0.2 pkgsrc-2003Q4-base:1.4 buildlink2-base:1.4 pkgsrc-base:1.1.1.1 TNF:1.1.1; locks; strict; comment @# @; 1.4 date 2001.04.14.14.47.32; author dmcmahill; state dead; branches; next 1.3; 1.3 date 2001.03.31.00.00.35; author dmcmahill; state Exp; branches; next 1.2; 1.2 date 2000.08.06.15.43.35; author dmcmahill; state dead; branches; next 1.1; 1.1 date 2000.03.07.16.09.16; author dmcmahill; state Exp; branches 1.1.1.1; next ; 1.1.1.1 date 2000.03.07.16.09.16; author dmcmahill; state Exp; branches; next ; desc @@ 1.4 log @update verilog-current to 20010407 changes since last snapshot are (from the authors email) verilog-20010407 -------------------- Still more progress on the new VVP simulation engine: As with last week, this snapshot includes a lot of work on the ivl_target API in support of code generation for vvp. Also, the vvp execution engine has progressed some. In fact, vvp has grown up to understand signed vectors and some signed expressions. The signed vectors are mostly for VPI use, the signed comparison instructions actually do signed work. Case comparisons are new, along with %and and %or instructions, and %nor/r for reduction. I also added a few new gate types to the .functor support. A bug in the propagation of values by %set instructions has been fixed. Specifically, the %set instruction not only sets the value of the .var that it references, but also executes the propagation events that result. This fixed some event ordering bugs. Some VPI support needed by system.vpi is added to vvp to allow it to properly handle signed signals, decimal values, and a few other details. $display should work much better then it did last week. Back in the vvp.tgt code generator, lots of new stuff is happening. Several of the bitwise binary operators have been added, as well as more comparison operators. This includes handling of signed expressions. This also implies that vvp.tgt generates the proper .net vs .net/s and .var vs .var/s statements. User defined functions and tasks are now working. In fact, the vvp target probably handles more functions (in behavioral code) then the vvm engine. I've received several bug reports about user defined functions with loops, that don't work under vvm. These should work with vvp. Non-blocking assignments now work, too. All forms of case/casex/casez are supported by the code generator, and use the proper compare instructions. Forever, Repeat and While loops also work now. A few bugs in event handling, and all the edge types (including behavioral triggers) should work with limitations. Event or is still in the works, and any-edge of large vectors (>4 bits) does not work. *Whew!* As you can see, a *lot* of stuff is happening. I'm up to passing 110+ tests in the regression test suite (Icarus Verilog/vvm passes 318 tests) so the changes are actually making things work. Test and be merry! verilog-20010331 -------------------- More and more progress on VVP. More and more snapshots. A lot of work has been done to the ivl_target loadable target API. This API is growing to support the also growing tgt-vvp target. I've added support for case statements, event triggers fork blocks. Of course this also means that the tgt-vvp code generator and the vvp simulator now support constructs including case, events, and parallel blocks. I've also fixed up the driver to properly report errors that tgt-vvp detect. This makes the test suite regression script work a lot better. I'm up to more then 70 tests in the test suite passing. I'm finding that writing the code generator for vvp assembly is a *lot* easier then writing a code generator for C++/vvm. Fortunately, the vvp assembler is pretty fast. At any rate, the vvp simulation engine is starting to show signs of being useful. It still does not cover nearly as much of Verilog as vvm, but what it does cover is so much faster that it may be worth your while to try it out. And more eyes looking at it can only be a good thing. @ text @$NetBSD: patch-ae,v 1.3 2001/03/31 00:00:35 dmcmahill Exp $ --- vvp/Makefile.in.orig Thu Mar 22 17:37:36 2001 +++ vvp/Makefile.in Fri Mar 30 11:08:42 2001 @@@@ -40,6 +40,6 @@@@ STRIP = @@STRIP@@ -CPPFLAGS = @@CPPFLAGS@@ @@DEFS@@ -DMODULE_DIR=\"$(libdir)/ivl\" -CXXFLAGS = @@CXXFLAGS@@ -I. -I$(srcdir)/.. +CPPFLAGS = -I. -I$(srcdir)/.. @@CPPFLAGS@@ @@DEFS@@ -DMODULE_DIR=\"$(libdir)/ivl\" +CXXFLAGS = @@CXXFLAGS@@ LDFLAGS = @@LDFLAGS@@ @ 1.3 log @update to verilog-current-20010324. Changes since the last version from the authors announcement are: There are a few bugs in the main compiler that are fixed. There has also been an extension to the $fopen that adds support for opening files for reading. The $fgetc has been added to take advantage of this. This was done on the VPI side, although a slight extension to the mcd functions was created. The real news is the vvp simulation engine. I've added the tgt-vvp code generator source and the vvp assembler/simulator, and the combination actually produces the occasional working program. And it makes them very quickly. So far as I can tell now, I am going to be very pleased with the final outcome when this work is complete. However, it is not at all ready to use. This snapshot is mostly to give a preview of things to come to a wider audience. HOW VVP WORKS If you are accustomed to the existing vvm behavior, you remember that the vvm simulator works by generating C++ and feeding that to the g++ compiler. Many of you are painfully aware of that. VVP does *not* work like that. Instead of generating C++, the generator emits assembly language for an abstract simulator processor. The processor that the assembly targets doesn't really exist, but the vvp program, included in this Icarus Verilog snapshot, assembles the code to data structures in memory, then efficiently emulates the abstract processor. So the simulation of a program via vvp works by first compiling the Verilog to vvp assembly. The vvp.tgt modules generates the code, and is envoked when you use the ``-tvvp'' switch to iverilog. The vvp assembly file so created is then passed to the vvp program to be assembled and executed. There is a single vvp input file that is the design to simulate. The vvp assembler is designed to execute the design efficiently. HOW TO LEARN MORE The ivl_target.h header file describes the loadable target API that the vvp code generator uses to gain access to the design. Then the tgt-vvp directory contains the implementation of the vvp code generator. The vvp directory contains the implementation of the assembler/simulator that runs the compiled design. The README.txt file describes how the vvp program works in general, and points to other txt files. There are a variety of other .txt files in the vvp directory that describe how the major components of the vvp program work. @ text @d1 1 a1 1 $NetBSD$ @ 1.2 log @update to verilog-current-20000805. Changes since the last packaged snapshot are (from the authors announcements): -------------------------------- Icarus Verilog snapshot 20000721 -------------------------------- (first snapshot after the 0.3 release) This snapshot adds no new features or language support, but is working towards more precise interpretation of scheduling and value propagation details. The first thing I've done is redesign the internal Link structure that is used to connect the internal netlist together. There are some aspects of the nexos of a set of links that were carried by the Link class or by external functions. These have been moved to the new Nexus class and linking and structure has improved because of it. This has led me to modify the handing of signal initial values. In practice, the time-0 value of a net is a property of the nexus instead of the objects that are connected together, so I have implemented it so, and in the process fixed a bunch of initial value problems. One new feature that is added is support for non-constant delay expressions. Now, you can even have something like ``#($random%256) '' and expect it to do what you think. (So now the telephone example in James Lee's "Verilog Qickstart" actually works!) I've added some missing support for various operators in constant expressions. I've also added some more of the friends of $random for those folks who do stochastic modeling. Constant propagation carries some new bug fixes, and some new smarts. It is for example able to detect a mux with a constant 'bz input and replace it with bufif devices, and other clevernesses with logic reduction. -------------------------------- Icarus Verilog snapshot 20000729 -------------------------------- Like I said, the `timescale compiler directive now more or less works. You can now specify timescale for modules, and the compiler will figure out a global design resolution and scale your time values to match. The VCD dumps should reflect the chosen resolution automatically. Floating point notation is not yet supported, we'll see if that turns out to be a problem. A problem with `timescale support is that the compiler will allow unitless modules. This can happen if you have `timescale late in the source file. The default unit is the not-very-intuitive 1s. Frankly, I don't like the `timescale semantics for this sort of reason, but its an accepted standard, so I'm stuck with it. I've also added support for min:typ:max expressions. The compiler chooses one of the three expressions at compile time, based on a compile time switch. You can ask for min typ or max values via the "-Tmin" etc. switch to the iverilog command. If you do not specify a switch, the compiler will choose the typ values but print warnings. The -Ttyp switch will suppress the warnings. I have fixed yet more net initialization bugs. These are getting pretty subtle, now, so you should have a hard time tickling any remaining errors here. I've also fixed a nasty and subtle bug in event expression support. This bug only happened when the design had many event expressions with many conjunctions. Although they are not ready for use, I have made some forward progress with disable statements. I now at least elaborate them, so now I just need to figure out how to make the run-time work out. That's the hard part, I'm afraid. -------------------------------- Icarus Verilog snapshot 20000805 -------------------------------- I've finally dealt with a problem that's been nagging at me for a while. Until now, it has been possible that excessively clever hierarchical references into and out of task scopes could confound symbol lookup. I think I finally put that to rest, and in the process reorganized the netlist format for holding task definitions. It should no longer be possible to confuse name binding in Icarus Verilog. Found and fixed a silly bug in elaborating e?a:'bz and e?'bz:a expressions into bufifN devices. I got the sense of the enable wrong in one of the cases. All fixed (and the test suite updated to catch this silly mistake:-) tri0 and tri1 nets should now work properly. These are mostly a run- time issue which I solved using resolution functions. This is actually a technique that I borrowed from VHDL. For those of you doing XNF synthesis, I fixed up my FF/RAM detector to allow <= assignments in always blocks. This is in fact the preferred way to describe DFFs as <= more accurately simulates their RTL nature. Also found and fixed a few DOS \r\n line end issues in the lexical ana- lyser and the preprocessor. We sometimes forget how tricky these line- end problems can be, and compiler directives are the most susceptible. This problem most likely occurs when you transport files from a DOS environment. (The MAC folks haven't complained much, so either I got it right for them, or Kato took care of the problems for me:-) @ text @d1 1 a1 1 $NetBSD: patch-ae,v 1.1 2000/03/07 16:09:16 dmcmahill Exp $ d3 10 a12 6 use the correct flag for our compiler. --- verilog.sh.orig Sat Feb 5 01:40:35 2000 +++ verilog.sh Sun Feb 13 11:15:00 2000 @@@@ -117,5 +117,5 @@@@ "xnf") mv ${tmpCCFile} ${outputFile} ;; a13 4 - "vvm") ${execCpp} -rdynamic -I${includedir} -L${libdir} ${tmpCCFile} -o ${outputFile} -lvvm @@dllib@@ ; + "vvm") ${execCpp} -Wl,--export-dynamic -I${includedir} -L${libdir} ${tmpCCFile} -o ${outputFile} -lvvm @@dllib@@ ; if test $? -ne 0 ; then echo "C++ compilation failed. Terminating compilation." @ 1.1 log @Initial revision @ text @d1 1 a1 1 $NetBSD: patch-ae,v 1.2 2000/02/14 22:55:33 dmcmahill Exp $ @ 1.1.1.1 log @Initial import of verilog-current. This pkg is for the development snapshots of the cad/verilog package. Development snapshots are created quite frequently in between stable releases. @ text @@