2001-04-11 15:36:19 +02:00
|
|
|
# $NetBSD: Makefile,v 1.15 2001/04/11 13:38:41 wennmach Exp $
|
2000-03-07 17:09:15 +01:00
|
|
|
#
|
|
|
|
|
|
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.
2001-03-31 02:00:35 +02:00
|
|
|
DISTNAME= verilog-20010324
|
|
|
|
|
PKGNAME= verilog-current-20010324
|
2000-03-07 17:09:15 +01:00
|
|
|
CATEGORIES= cad
|
|
|
|
|
MASTER_SITES= ftp://icarus.com/pub/eda/verilog/snapshots/
|
|
|
|
|
|
|
|
|
|
MAINTAINER= dmcmahill@netbsd.org
|
|
|
|
|
HOMEPAGE= http://icarus.com/eda/verilog/index.html
|
2001-02-16 14:41:26 +01:00
|
|
|
COMMENT= Verilog simulation and synthesis tool (development snapshot version)
|
2000-03-07 17:09:15 +01:00
|
|
|
|
2001-03-27 05:19:43 +02:00
|
|
|
BUILD_DEPENDS+= bison-*:../../devel/bison
|
|
|
|
|
BUILD_DEPENDS+= gperf-2.7.2:../../devel/gperf
|
update verilog-current to 20001216.
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.
2000-12-19 19:53:51 +01:00
|
|
|
DEPENDS+= ipal-current>=20001210:../../cad/ipal-current
|
2000-03-07 17:09:15 +01:00
|
|
|
|
2001-04-11 15:36:19 +02:00
|
|
|
CONFLICTS+= verilog-[0-9]*
|
2000-03-07 17:09:15 +01:00
|
|
|
|
2000-03-25 22:09:16 +01:00
|
|
|
GNU_CONFIGURE= yes
|
2000-03-07 17:09:15 +01:00
|
|
|
USE_GMAKE= yes
|
update verilog-current to 20001216.
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.
2000-12-19 19:53:51 +01:00
|
|
|
CPPFLAGS+= -I${LOCALBASE}/include
|
|
|
|
|
CONFIGURE_ENV+= CPPFLAGS="${CPPFLAGS}" LDFLAGS+="${LDFLAGS}"
|
2000-03-07 17:09:15 +01:00
|
|
|
|
|
|
|
|
.include "../../mk/bsd.pkg.mk"
|
