| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
There was a couple of snapshots since february; besides bugfixes the
major highligths might be:
-handling of real values at various places
-support for library modules (esp cadence PLI1)
-better FPGA support (esp Virtex II)
-"vvp" interactive mode added
Also converted to buildlink2, and dependencies to libz, libbz2 and
readline added.
|
|
This is the first packaged (in pkgsrc) snapshot after the verilog-0.7
release.
This snapshot adds preliminary support for real variables to the language
to the features already found in verilog-0.7.
|
|
Release Notes for Icarus Verilog Snapshot 20021019
The synthesizer now detects asynchronous set/reset inputs to DFF
devices. The fpga and vvp code generators have been updated to support
these signals.
The vvp code generator also gained some register management code that
improves the thread register usage. This redoces code size for certain
common cases, and thus improves simulation performance.
The requirements on `ifdef and related compiler directives has been
relaxed, to correspond to more common behavior.
The parameter range support crashed if the range expressions had
parameters in them. This is fixed, and some signed-ness bugs fixed
along with it.
Rearrange some of the configure script tests to assure better
compatibility accross platforms.
|
|
|
|
many improvements and bug fixes since the last packaged snapshot including:
-added the $sizeof system function as a builtin
-In VPI, the simulator event callbacks now work
-Concatenation expressions in parameters were broken are broken
-added the vpiModule iterator to VPI scope handles
|
|
changes are:
-----------
RELEASE NOTE FOR ICARUS VERILOG 20010630
I've done some cleanup of the mingw port of Icarus Verilog. I've also
added instructions for how to build Icarus Verilog under mingw. I'm
working on making that the preferred way to support Windows, and when
I make the 0.5 release I will make Windows binaries this way. Anyhow,
feedback on the build instructions and the build results using the
instructions in mingw.txt are welcome.
I've make "vvp" the default target type. The older vvm behavior is
available with the "-tvvm" flag to iverilog, but I would rather be
told about (and fix) bugs in the vvp code generator and run time.
I've added support for the (unsigned) right shift operator. The left
shift has been working for a while now, but right shift somehow
slipped through the cracks. The shift operators still don't quite work
in structural contexts, but they should show up sometime next week.
I've finally got VCD output working properly with vvp. It may even be
better then with vvm, although some internal symbols are still generated.
A few odd bugs have been fixed, including a code generation error for
xnf, and error checking of user defined function parameters.
|
|
many changes since the last snapshot. Mostly they involve expanded
VVP support. The VVP target now passes >200 of the tests from the
test suite. While not as complete as the VVM target, VVP is getting
closer and its _much_ _much_ faster.
|
|
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.
|
|
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.
|
|
Changes since the last packaged snapshot are (from the authors announcements):
Icarus Verilog snapshot 20001216
--------------------------------
This is the last snapshot before the holidays, so I hope it has your
favorite present in it. A lot of PR#s have been dealt with, and for a
brief moment I felt like I was getting ahead of the pending list:-)
I've added support for non-integer times, at least in a few contexts.
The `timescale directives should interact properly with the decimal
point in delays, causing more accurate timing simulations. This should
make vendor-supplied libraries work much better.
I've added support for signed reg variables. Signed expressions should
now generally do the right thing, but this feature needs much more testing,
and many more tests in the test suite. However, I do know that signed
comparisons should work properly. Bug reports for problems with signed
arithmetic are encouraged.
Many people have been having troubles with Cygwin compilation. The
problem was with the latest version of binutils. Venkat came up with a
solution that works with old and new binutils, so you can now compile
with the very latest cygwin software. This should make things a lot
easier for a lot of people.
I've made initial steps toward an HP/UX port. The configure script should
detect the right dl library to use, and the t-dll target should be able
to load loadable targets. I am looking for a volunteer to take responsibility
for the HP/UX port as I have no suitable machines. Said person should
be able to compile Icarus Verilog, manage HP/UX specific portability
issues, and be able to make precompiled packages when the stable release
is out.
I'm still looking for a similar volunteer for FreeBSD/{alpha,i386}.
Some more progress was made on support for PALs. I'm close to choosing
macrocell modes and configuring fuses. Won't be long now, folks.
Icarus Verilog snapshot 20001129
--------------------------------
few more constant propagation improvements this time, most notably
XOR an XNOR are now fairly complete. These are interesting as they are
generated by comparison operators so show up pretty often. And it is
common to compare numbers to constants. Thus, there are lots of oppor-
tunities for gate elimination!
Synthesis of unary ! now works. Unary ~| (reduction nor) should also
be in good shape now, as should binary || (logical or). Synthesis of
binary && is still a little shaky. Go ahead and file reports if you
trip on it. Binary != was broken with XNF synthesis, so that is also
fixed, along with a few cases of mangled XNF output. And there were
also a few bugs related to the CE of inferred DFFs, that didn't get
connected.
A *big* problem with synthesis occurred with non-blocking assignment.
Icarus Verilog simply failed to synthesize the r-value of the assignment
and all kinds of bad things happened. I fixed this, it's better now.
Whew! Lots of XNF synthesis bugs fixed! This is what happens when users
take the time to submit good bug reports.
There are also some bugs related to dead signal elimination that causes
Icarus Verilog to crash in some synthesis cases. These have been fixed
up so far as I know.
I have slightly improved root module detection of iverilog. If there is
only one module in a source file, it is pretty obvious that it is the root
module, even if it has ports. This is a common case for XNF synthesis
(especially when making small macros with Icarus Verilog) and should save
some typing and confusion.
|
|
from the authors announcement:
-----------------------------
The loadable target module API is starting to take shape.
That is the major thrust nowadays with Icarus Verilog, after all, so
progress is being made here. The biggest change is in fact a philosophy
change. The target module now needs only a single symbol -- target_design --
to receive the whole design. The target module can from there and using
the API access the entire design randomly. So if you wanted to implement
a graphical browser, you could:-)
I've added support for the l-values of procedural assignments, and also
back pointers to objects that reference ivl_nexus_t objects. This closes
the loop so that there should be no dead-ends in the design.
I've clarified and expanded the descriptions in the ivl_target.h header
file. There should be just about enough documentation to properly used
all the various types. (Have any of you tried to write GIMP plug-ins?
Have you looked at the libgimp header files? Have you seen any comments
there?-( I won't ever sink to that level, I hope.)
I've also imtegrated updates to the Cygwin32 port to support loadable
targets under Cygwin32. After much struggling, Venkat managed to discover
the secret magic needed to get load time symbol binding to work. Hopefully
I didn't break it too bad when I changed the API again. (I think it is
still fine.)
|
|
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) <statement>'' 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:-)
|
|
|
|
changes since last packaged snapshot are (from the authors announcements):
Icarus Verilog 20000527 Snapshot
----------------------------------
It's snapshot time!
<ftp://icarus.com/pub/eda/verilog/snapshots/verilog-20000527.tar.gz>
This snapshot doesn't add any new features, but fixes a few bugs. I've
taken care of a bunch of bug reports with an eye towards getting this
polished up for a 0.3 stable release.
I fixed some problems with elaborating the condition expression of a
ternary operator. This was a long-standing bug that only happened in
structural (i.e. continuous assignment) situations.
I've also done some merging of event expressions. The netlist format makes
NetEvProbe and NetEvent objects for event expressions, and it was making
more then were needed. I've done some merging, though I have some more
things I can do on this front. I'll be working on it for the next snapshot.
I found a whole bunch of bugs with parsing expression lists, for example
module port expressions. The result is actually a smaller parser:-) So
module port expressions should be parsed and elaborated correctly, now.
In the vvm code generator, I've found some room to optimize the generated
code. I detect duplicate initialization of a nexus, and prevent the
excess code being generating. In one slightly degenerate example sent to
me, this change reduced the generated C++ by more then 6 times. I was
pretty amazed.
I've also slightly optimized the special case of behavioral assignments
from simple signal expressions. This removed a few lines of generated
code per assignment. This sort of thing helps compile time performance.
Icarus Verilog 20000512 Snapshot
----------------------------------
This is mostly a bug fix snapshot. No new features here, but I'm starting
to buff it up shiny for an upcoming 0.3 release. It looks like I'll be
starting to do release candidates soon, so test this snapshot hard, folks!
<ftp://icarus.com/pub/eda/verilog/snapshots/verilog-20000519.tar.gz>
I re-implemented flip-flop and RAM synthesis, the new technique should
allow me to make much more complete synthesis. It's still not the nifty
full-scale synthesis I hope to do some day, but it should catch some of
the bigger synthesis problems.
I've also added to XNF synthesis the ability to detect start-up initial
values for flip-flip devices. This causes it to generate INIT= properties
for the devices as appropriate.
I've improved the VVM code generated by the t-vvm code generator. I've
managed to reduce the size of the code generated for some larger models
by 30%, and I should have improved run-time performance in the process.
This should help.
I've also found (thanks to bug reports) and fixed some module port issues.
I bet you can't dream up legal port binding that Icarus Verilog can't
handle:-) This issue should be taken care of.
VPI now includes the ability to set registers. I needed this to implement
a PNG image I/O module. I'm still working on that, I'll distribute it
separately when it is in better shape.
Various other bug fixes in iverilog and elsewhere. Several bug fixes
in the VVM runtime, including some support for the % operator.
I've done some updates to documentation to reflect some of the changes
since 0.2, so you can take a look at that too.
|
|
changes from the last packaged snapshot (from the authors announcement):
---------------Icarus Verilog 20000506 Snapshot------------------
A lot of internal reworking has been done on this, so there might be
problems with things like symbol binding. But I think this is much better
then the last snapshot. I am once again starting to think about a
stable release. I'll shoot for the end of May, so if there is anything
you want to see in that release, start pestering me.
The big job has been a rewrite of the symbol table that holds signals.
The previous elaboration and lookup code for signals/memories did not
work properly when hierarchical names were used in the context of tasks
and functions. Also, the old table kept all the signals is a single
lookup table that failed to take advantage of knowledge of the current
scope.
All that is changed. signals are now elaborated after parameters and
before processes, so all hierarchical accesses should work properly now,
no matter how contorted. I've also fixed some bugs with function/task
parameter passing.
I've also added some infrastructure for supporting system functions, and
I've added an implementation of the $random system function. This currently
uses the native random(3) C library function, but once I get access to the
standardized algorithm, I'll implement that.
There are also a few fixes to elaboration of ternary operators. They were
a bit touchy about result bit widths.
A few preprocessor bugs have been fixed, especially related to the
`ifdef/`endif tokens. People are all the sudden starting to use the
Icarus Verilog preprocessor, so some long-standing bugs have been caught.
The iverilog command had a few path problems fixed, and the remaining
necessary switches have been added. I really encourage people to start
using iverilog in place of verilog. The test suite now uses iverilog to
run the compiler, so should you. There is a man page.
|
|
The many bug fixes and changes since the last packaged snapshot
are (from the authors announcements):
Icarus Verilog 20000428 Snapshot
--------------------------------
This one clears up some pretty nasty and subtle bugs. If you've been
sending me bug reports, you're probably turning blue holding your breath
in anticipation of this snapshot. Breath in, Breath out.
Hooray, both force and release work properly. I'm happy about that,
release worked out a bit easier then I expected. These should be useful
to test bench designers.
The big news this past week, however, has been bug fixes. Lots of bug
fixes. I got lots of bug reports and I killed pretty nearly all of
them. There were lots of nasty icky problems with passing parameters
to/from tasks, especially when memory words were involved. I fixed up
a whole bunch of these, and now parameter passing should work pretty
will, modulus the few remaining bugs I'm not seeing yet.
The iverilog command is in better shape now, and I encourage people
to use it in place of the older "verilog" driver script. There is a
man page for iverilog, and it supports all the switches needed to do
simulation and synthesis. I would like people to start getting this
driver well tested and the bugs worked out, because it is going to be
the main driver come the next stable release.
Some neat new XNF features are happening. I synthesize identity compare
in XNF, and a few other missing operators. But the really neato part is
that I've taught Icarus Verilog to generate PIN records for module
ports, so that you can make XNF macros out of Verilog source. If you
elaborate a module that has ports, the XNF code generator will automatically
generate the necessary symbols so that external XNF tools can link the
generated output into larger designs. I've compared the XNF files from
Icarus Verilog with those generated by Abel, and they appear the same
to my eyes.
Icarus Verilog 20000421 Snapshot
--------------------------------
Bunches of bug fixes, and a few new features come with this snapshot.
This snapshot makes headway in both simulation and synthesis. I'm
also starting to make a big dent in my todo list for the 0.3 release.
The bunches of little bug fixes in this snapshot are a direct result of
bunches of bug reports this past week that I was able to deal with. If
you've been reporting bugs, this may contain your fix.
I redesigned the process implementation in the vvm backend, so the generated
code is a bit cleaner, and threads are lighter weight. And while I was at
it, fork/join now should work properly. I know there were a bunch of you
out there asking for this, so here it is.
I've incorporated into this release improved runtime support for integer
multiplication, it should now work now matter how incredibly enormous
you make the operands. Thanks to Chris Lattner for contributing the generic
multiply.
I've improved synthesis somewhat, there were some expressions in some
contexts that were not getting synthesized by the -Fsynth functor. This
is fixed, and I'm also starting to add some XNF specific optimizations
into the -Fxnfio functor. I do sensible things with identity compare,
for example.
I've added the program ``iverilog'' to be a new driver program written
in C instead of as a shell script. This driver supports the -tnull,
-txnf and -tvvm targets, as well as the -E flag that causes only the
preprocessor to be run. This should be interesting to those of you who
are looking for a working preprocessor. I'm still working on the -D and
the -I flags, but I expect this program to replace the verilog.sh script
before the 0.3 release.
Icarus Verilog 20000414 Snapshot
--------------------------------
All event handling is now complete. Yet another subject is behind me, and
on I go. By complete, I mean that named events, edge triggers, wait, and
lists of events all work. This took a little longer then I expected, so
some of the other things I wanted to work on had to wait.
As a side effect of event and thread scheduling work, I changed the way
that threads are generated in vvm. The result is that threads should be
a little faster at run time, and a lot faster at compile time. A *LOT*
faster at compile time. (Apparently, Verilog XL is still considerably
faster, but hey, I'm working on it.)
|
|
Notable changes since the last pkg are (from the snapshot announcement):
Parameters are complete.
What this means is that I finally got around to supporting defparam,
and while I was at it I rewrote the entire parameter handling and added
the parameter support included in 1364-2000.
I have rewritten major portions of the VVM backend. The vvm_nexus class
has been introduced to the fray, and all the device implementations in
the VVM library now use the nexus to drive and receive values. An advantage
of this scheme is that the t-vvm backend code (in ivl proper) is simpler,
and so is the generated C++ code.
I also removed most of the template classes. This proved to be a huge
compile-time benefit (though compiling twice as fast really only matters
for large programs) and it doesn't seem likely to hurt run-time performance.
A few remain, either because they seemed harmless (the N-wide logic gates)
or I couldn't yet figure out a good way to replace them (vvm_bitset_t).
A side benefit of this is that the vvm library may now be a modeling
library that ordinary humans can use to write their models in C++. This
may provide the unexpected benefit of heading me towards incremental
compilation of designs. So who was it who was beating me over the head
asking for that?-)
I also fixed a few minor problems with the preprocessor. Those of you
who reported problems with `includes and `defines should check this out.
|
|
|
|
of the cad/verilog package. Development snapshots are created quite frequently
in between stable releases.
|
