Deploy to GitHub pages

2026-08-22 22:06:47 +02:00 · 2026-08-22 18:04:28 +00:00
611 changed files with 35466 additions and 160980 deletions
@@ -0,0 +1,4 @@
+# Sphinx build info version 1
+# This file records the configuration used when building these files. When it is not found, a full rebuild will be done.
+config: 6b92c0fcad0ee5df433166b877bb31df
+tags: 645f666f9bcd5a90fca523b33c5a78b7
@@ -1,27 +0,0 @@
-lexor_keyword.cc
-parse.h
-parse.cc
-parse.cc.output
-parse.output
-syn-rules.cc
-syn-rules.cc.output
-syn-rules.output
-lexor.cc
-iverilog-vpi
-iverilog-vpi.pdf
-iverilog-vpi.ps
-ivl
-ivl.exp
-dep
-configure
-Makefile
-check
-check.cc
-check.vvp
-config.status
-config.log
-config.cache
-autom4te.cache
-config.h
-_pli_types.h
-dosify
@@ -1,138 +0,0 @@
-/*
- * Copyright (c) 2000 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: Attrib.cc,v 1.6 2004/02/20 18:53:33 steve Exp $"
-#endif
-
-# include "config.h"
-
-# include  "Attrib.h"
-# include  <assert.h>
-
-Attrib::Attrib()
-{
-      nlist_ = 0;
-      list_ = 0;
-}
-
-Attrib::~Attrib()
-{
-      delete[] list_;
-}
-
-
-const verinum& Attrib::attribute(perm_string key) const
-{
-      for (unsigned idx = 0 ;  idx < nlist_ ;  idx += 1) {
-
-	    if (key == list_[idx].key)
-		  return list_[idx].val;
-      }
-
-      static const verinum null;
-      return null;
-}
-
-void Attrib::attribute(perm_string key, const verinum&value)
-{
-      unsigned idx;
-
-      for (idx = 0 ; idx < nlist_ ;  idx += 1) {
-	    if (key == list_[idx].key) {
-		  list_[idx].val = value;
-		  return;
-	    }
-      }
-
-      struct cell_*tmp = new struct cell_[nlist_+1];
-      for (idx = 0 ;  idx < nlist_ ;  idx += 1)
-	    tmp[idx] = list_[idx];
-
-      tmp[nlist_].key = key;
-      tmp[nlist_].val = value;
-
-      nlist_ += 1;
-      delete[]list_;
-      list_ = tmp;
-}
-
-bool Attrib::has_compat_attributes(const Attrib&that) const
-{
-      unsigned idx;
-
-      for (idx = 0 ;  idx < that.nlist_ ;  idx += 1) {
-
-	    verinum tmp = attribute(that.list_[idx].key);
-	    if (tmp != that.list_[idx].val)
-		  return false;
-      }
-
-      return true;
-}
-
-unsigned Attrib::attr_cnt() const
-{
-      return nlist_;
-}
-
-perm_string Attrib::attr_key(unsigned idx) const
-{
-      assert(idx < nlist_);
-      return list_[idx].key;
-}
-
-const verinum& Attrib::attr_value(unsigned idx) const
-{
-      assert(idx < nlist_);
-      return list_[idx].val;
-}
-
-
-/*
- * $Log: Attrib.cc,v $
- * Revision 1.6  2004/02/20 18:53:33  steve
- *  Addtrbute keys are perm_strings.
- *
- * Revision 1.5  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.4  2002/05/26 01:39:02  steve
- *  Carry Verilog 2001 attributes with processes,
- *  all the way through to the ivl_target API.
- *
- *  Divide signal reference counts between rval
- *  and lval references.
- *
- * Revision 1.3  2002/05/23 03:08:50  steve
- *  Add language support for Verilog-2001 attribute
- *  syntax. Hook this support into existing $attribute
- *  handling, and add number and void value types.
- *
- *  Add to the ivl_target API new functions for access
- *  of complex attributes attached to gates.
- *
- * Revision 1.2  2001/07/25 03:10:48  steve
- *  Create a config.h.in file to hold all the config
- *  junk, and support gcc 3.0. (Stephan Boettcher)
- *
- * Revision 1.1  2000/12/04 17:37:03  steve
- *  Add Attrib class for holding NetObj attributes.
- *
- */
-
@@ -1,90 +0,0 @@
-#ifndef __Attrib_H
-#define __Attrib_H
-/*
- * Copyright (c) 2000 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: Attrib.h,v 1.5 2004/02/20 18:53:33 steve Exp $"
-#endif
-
-# include  "StringHeap.h"
-# include  "verinum.h"
-
-/*
- * This class keeps a map of key/value pairs. The map can be set from
- * an STL map, or by setting individual mappings.
- */
-class Attrib {
-
-    public:
-      Attrib();
-      ~Attrib();
-
-      const verinum&attribute(perm_string key) const;
-      void attribute(perm_string key, const verinum&value);
-      bool has_compat_attributes(const Attrib&that) const;
-
-
-	/* Provide a means of iterating over the entries in the map. */
-      unsigned       attr_cnt() const;
-      perm_string    attr_key(unsigned idx) const;
-      const verinum& attr_value(unsigned idx) const;
-
-
-    private:
-      struct cell_ {
-	    perm_string  key;
-	    verinum val;
-      };
-
-      unsigned nlist_;
-      struct cell_*list_;
-
-    private: // not implemented
-      Attrib(const Attrib&);
-      Attrib& operator= (const Attrib&);
-};
-
-/*
- * $Log: Attrib.h,v $
- * Revision 1.5  2004/02/20 18:53:33  steve
- *  Addtrbute keys are perm_strings.
- *
- * Revision 1.4  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.3  2002/05/26 01:39:02  steve
- *  Carry Verilog 2001 attributes with processes,
- *  all the way through to the ivl_target API.
- *
- *  Divide signal reference counts between rval
- *  and lval references.
- *
- * Revision 1.2  2002/05/23 03:08:50  steve
- *  Add language support for Verilog-2001 attribute
- *  syntax. Hook this support into existing $attribute
- *  handling, and add number and void value types.
- *
- *  Add to the ivl_target API new functions for access
- *  of complex attributes attached to gates.
- *
- * Revision 1.1  2000/12/04 17:37:03  steve
- *  Add Attrib class for holding NetObj attributes.
- *
- */
-#endif
@@ -1,176 +0,0 @@
-
-HOW TO REPORT BUGS
-
-Before I can fix an error, I need to understand what the problem
-is. Try to explain what is wrong and why you think it is wrong. Please
-try to include sample code that demonstrates the problem. Include a
-description of what ivl does that is wrong, and what you expect should
-happen. And include the command line flags passed to the compiler to make
-the error happen. (This is often overlooked, and sometimes important.)
-
-* The Compiler Doesn't Compile
-
-If the Icarus Verilog don't compile, I need to know about the
-compilation tools you are using. Specifically, I need to know:
-
-	- Operating system and processor type,
-	- Compiler w/ version,
-	- Library version, and
-	- anything else you think relevant.
-
-Be aware that I do not have at my disposal a porting lab. I have the
-alpha on my desk, and the Linux/Intel box with a logic analyzer and
-'scope hanging off it.
-
-* The Compiler Crashes
-
-No compiler should crash, no matter what kind of garbage is fed to
-it. If the compiler crashes, you definitely found a bug and I need to
-know about it.
-
-Ivl internally checks its state while it works, and if it detects
-something wrong that it cannot recover from, it will abort
-intentionally. The "assertion failure" message that the program
-prints in the process of dying is very important. It tells me where in
-the source the bad thing happened. Include that message in the bug
-report.
-
-If there are not assertion messages, I need to know that as well.
-
-I also need a complete test program that demonstrates the crash.
-
-* It Doesn't Like My Perfectly Valid Program(tm)
-
-I need to know what you think is right that ivl gets wrong. Does it
-reject your "Perfectly Valid Program(tm)" or does it compile it but
-give incorrect results? The latter is the most insidious as it doesn't
-scream out to be fixed unless someone is watching closely. However, if
-I get a sample program from you, and I can compile it, and I run it
-and nuclear junk doesn't fall from the sky, I'm moving on to the next
-problem.
-
-So, if your program doesn't compile, tell me so, tell me where the
-error occurs, and include a complete Perfectly Valid Test Program(tm).
-You tell me that it fails to compile for you, and I find that it
-compiles for me, then hooray I fixed it. It can happen, you
-know. What's on my disk is more recent then the latest snapshot.
-
-If your program does compile, but generates incorrect output, I need
-to know what it says and what you think it should say. From this I can
-take your sample program and work on ivl until it gets the proper
-results. For this to work, of course, I first need to know what is
-wrong with the output. Spell it out, because I've been known to miss
-the obvious. Compiler writers often get buried in the details of the
-wrong problem.
-
-* It Generates Incorrect Target Code (XNF, EDIF/LPM, etc.)
-
-As ivl adds target code generators, there will be cases where errors
-in the output netlist format occur. This is a tough nut because I
-might not have all the tools to test the target format you are
-reporting problems with. However, if you clearly explain what is right
-and wrong about the generated netlist, I will probably be able to fix
-the problem. It may take a few iterations.
-
-In this case, if possible include not only the sample verilog program,
-but the generated netlist file(s) and a clear indication of what went
-wrong. If it is not clear to me, I will ask for clarification.
-
-* The Output is Correct, But Less Then Ideal
-
-If the output is strictly correct, but just not good enough for
-practical use, I would like to know. These sorts of problems are
-likely to be more subjective then a core dump, but are worthy of
-consideration. However, realize that outright errors will get more
-attention then missed optimizations.
-
-THE MAKING OF A GOOD TEST PROGRAM
-
-If at all possible, please submit a complete source file that
-demonstrates the problem. If the error occurs after elaboration,
-please include a top level module in the program that is suitable for
-the target format. If I have to write the module myself, I might not
-write it in a way that tickles the bug. So please, send all the
-Verilog source (after preprocessing) that I need to invoke the error.
-
-Also, include the command line you use to invoke the compiler. For
-example:
-
-	ivl foo.vl -o foo.cc -tvvm
-	ivl foo.vl -s starthere
-
-If the error occurs with the null target (``-tnull'') then a top level
-module may not be needed as long as the ``-s <name>'' switch is
-given.
-
-So when you send a test case, ask yourself "Can poor overworked Steve
-invoke the error without any Verilog other than what is included?" And
-while we are at it, please place a copyright notice in your test
-program and include a GPL license statement if you can. Your test
-program may find its way into the test suite, and the notices will
-make it all nice and legal.
-
-RESEARCHING EXISTING/PAST BUGS, AND FILING REPORTS
-
-The URL <http://www.icarus.com/cgi-bin/ivl-bugs> is the main bug
-tracking system. Once you believe you have found a bug, you may browse
-the bugs database for existing bugs that may be related to yours. You
-might find that your bug has already been fixed in a later release or
-snapshot. If that's the case, then you are set.
-
-The bug database supports basic keyword searches, and you can
-optionally limit your search to active bugs, or fixed bugs. You may
-also browse the bug database, just to get an idea what is still
-broken. You may for example find a related bug that explains your
-symptom.
-
-The root page of the bug report database describes how to submit your
-completed bug report. You may submit it via the web form, or via
-e-mail.
-
-HOW TO SEND PATCHES
-
-Bug reports with patches are very welcome, especially if they are
-formatted such that I can inspect them, decide that they are obviously
-correct, and apply them without worry.
-
-I prefer context diffs as emitted by diff from GNU diffutils.  Human
-beings can read such things, and they are resilient to changing
-originals. A good set of flags to diff are ``diff -cNB''.  With such
-diffs, I can look at the changes you are offering and probably tell at
-a glance that they are plausible. Then I can use patch(1) to apply
-them. Or I can apply them by hand.
-
-However, if you send patches, *please* tell me what this patch is
-supposed to accomplish, and if appropriate include a test program that
-demonstrates the efficacy of the patch. (If I have no idea what the
-patch is for, I will ask for clarification before applying it.)
-
-COPYRIGHT ISSUES
-
-Icarus Verilog is Copyright (c) 1998-2003 Stephen Williams except
-where otherwise noted. Minor patches are covered as derivative works
-(or editorial comment or whatever the appropriate legal term is) and
-folded into the rest of ivl. However, if a submission can reasonably
-be considered independently copyrightable, it's yours and I encourage
-you to claim it with appropriate copyright notices. This submission
-then falls under the "otherwise noted" category.
-
-I must insist that any copyright material submitted for inclusion
-include the GPL license notice as shown in the rest of the source.
-
-
-$Id: BUGS.txt,v 1.5 2007/03/22 16:08:14 steve Exp $
-$Log: BUGS.txt,v $
-Revision 1.5  2007/03/22 16:08:14  steve
- Spelling fixes from Larry
-
-Revision 1.4  2003/02/19 04:36:31  steve
- Notes on hte bug database.
-
-Revision 1.3  2003/01/30 16:23:07  steve
- Spelling fixes.
-
-Revision 1.2  1999/08/06 04:05:28  steve
- Handle scope of parameters.
-
@@ -1,339 +0,0 @@
-		    GNU GENERAL PUBLIC LICENSE
-		       Version 2, June 1991
-
- Copyright (C) 1989, 1991 Free Software Foundation, Inc.
- 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
-			    Preamble
-
-  The licenses for most software are designed to take away your
-freedom to share and change it.  By contrast, the GNU General Public
-License is intended to guarantee your freedom to share and change free
-software--to make sure the software is free for all its users.  This
-General Public License applies to most of the Free Software
-Foundation's software and to any other program whose authors commit to
-using it.  (Some other Free Software Foundation software is covered by
-the GNU Library General Public License instead.)  You can apply it to
-your programs, too.
-
-  When we speak of free software, we are referring to freedom, not
-price.  Our General Public Licenses are designed to make sure that you
-have the freedom to distribute copies of free software (and charge for
-this service if you wish), that you receive source code or can get it
-if you want it, that you can change the software or use pieces of it
-in new free programs; and that you know you can do these things.
-
-  To protect your rights, we need to make restrictions that forbid
-anyone to deny you these rights or to ask you to surrender the rights.
-These restrictions translate to certain responsibilities for you if you
-distribute copies of the software, or if you modify it.
-
-  For example, if you distribute copies of such a program, whether
-gratis or for a fee, you must give the recipients all the rights that
-you have.  You must make sure that they, too, receive or can get the
-source code.  And you must show them these terms so they know their
-rights.
-
-  We protect your rights with two steps: (1) copyright the software, and
-(2) offer you this license which gives you legal permission to copy,
-distribute and/or modify the software.
-
-  Also, for each author's protection and ours, we want to make certain
-that everyone understands that there is no warranty for this free
-software.  If the software is modified by someone else and passed on, we
-want its recipients to know that what they have is not the original, so
-that any problems introduced by others will not reflect on the original
-authors' reputations.
-
-  Finally, any free program is threatened constantly by software
-patents.  We wish to avoid the danger that redistributors of a free
-program will individually obtain patent licenses, in effect making the
-program proprietary.  To prevent this, we have made it clear that any
-patent must be licensed for everyone's free use or not licensed at all.
-
-  The precise terms and conditions for copying, distribution and
-modification follow.
-
-		    GNU GENERAL PUBLIC LICENSE
-   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
-
-  0. This License applies to any program or other work which contains
-a notice placed by the copyright holder saying it may be distributed
-under the terms of this General Public License.  The "Program", below,
-refers to any such program or work, and a "work based on the Program"
-means either the Program or any derivative work under copyright law:
-that is to say, a work containing the Program or a portion of it,
-either verbatim or with modifications and/or translated into another
-language.  (Hereinafter, translation is included without limitation in
-the term "modification".)  Each licensee is addressed as "you".
-
-Activities other than copying, distribution and modification are not
-covered by this License; they are outside its scope.  The act of
-running the Program is not restricted, and the output from the Program
-is covered only if its contents constitute a work based on the
-Program (independent of having been made by running the Program).
-Whether that is true depends on what the Program does.
-
-  1. You may copy and distribute verbatim copies of the Program's
-source code as you receive it, in any medium, provided that you
-conspicuously and appropriately publish on each copy an appropriate
-copyright notice and disclaimer of warranty; keep intact all the
-notices that refer to this License and to the absence of any warranty;
-and give any other recipients of the Program a copy of this License
-along with the Program.
-
-You may charge a fee for the physical act of transferring a copy, and
-you may at your option offer warranty protection in exchange for a fee.
-
-  2. You may modify your copy or copies of the Program or any portion
-of it, thus forming a work based on the Program, and copy and
-distribute such modifications or work under the terms of Section 1
-above, provided that you also meet all of these conditions:
-
-    a) You must cause the modified files to carry prominent notices
-    stating that you changed the files and the date of any change.
-
-    b) You must cause any work that you distribute or publish, that in
-    whole or in part contains or is derived from the Program or any
-    part thereof, to be licensed as a whole at no charge to all third
-    parties under the terms of this License.
-
-    c) If the modified program normally reads commands interactively
-    when run, you must cause it, when started running for such
-    interactive use in the most ordinary way, to print or display an
-    announcement including an appropriate copyright notice and a
-    notice that there is no warranty (or else, saying that you provide
-    a warranty) and that users may redistribute the program under
-    these conditions, and telling the user how to view a copy of this
-    License.  (Exception: if the Program itself is interactive but
-    does not normally print such an announcement, your work based on
-    the Program is not required to print an announcement.)
-
-These requirements apply to the modified work as a whole.  If
-identifiable sections of that work are not derived from the Program,
-and can be reasonably considered independent and separate works in
-themselves, then this License, and its terms, do not apply to those
-sections when you distribute them as separate works.  But when you
-distribute the same sections as part of a whole which is a work based
-on the Program, the distribution of the whole must be on the terms of
-this License, whose permissions for other licensees extend to the
-entire whole, and thus to each and every part regardless of who wrote it.
-
-Thus, it is not the intent of this section to claim rights or contest
-your rights to work written entirely by you; rather, the intent is to
-exercise the right to control the distribution of derivative or
-collective works based on the Program.
-
-In addition, mere aggregation of another work not based on the Program
-with the Program (or with a work based on the Program) on a volume of
-a storage or distribution medium does not bring the other work under
-the scope of this License.
-
-  3. You may copy and distribute the Program (or a work based on it,
-under Section 2) in object code or executable form under the terms of
-Sections 1 and 2 above provided that you also do one of the following:
-
-    a) Accompany it with the complete corresponding machine-readable
-    source code, which must be distributed under the terms of Sections
-    1 and 2 above on a medium customarily used for software interchange; or,
-
-    b) Accompany it with a written offer, valid for at least three
-    years, to give any third party, for a charge no more than your
-    cost of physically performing source distribution, a complete
-    machine-readable copy of the corresponding source code, to be
-    distributed under the terms of Sections 1 and 2 above on a medium
-    customarily used for software interchange; or,
-
-    c) Accompany it with the information you received as to the offer
-    to distribute corresponding source code.  (This alternative is
-    allowed only for noncommercial distribution and only if you
-    received the program in object code or executable form with such
-    an offer, in accord with Subsection b above.)
-
-The source code for a work means the preferred form of the work for
-making modifications to it.  For an executable work, complete source
-code means all the source code for all modules it contains, plus any
-associated interface definition files, plus the scripts used to
-control compilation and installation of the executable.  However, as a
-special exception, the source code distributed need not include
-anything that is normally distributed (in either source or binary
-form) with the major components (compiler, kernel, and so on) of the
-operating system on which the executable runs, unless that component
-itself accompanies the executable.
-
-If distribution of executable or object code is made by offering
-access to copy from a designated place, then offering equivalent
-access to copy the source code from the same place counts as
-distribution of the source code, even though third parties are not
-compelled to copy the source along with the object code.
-
-  4. You may not copy, modify, sublicense, or distribute the Program
-except as expressly provided under this License.  Any attempt
-otherwise to copy, modify, sublicense or distribute the Program is
-void, and will automatically terminate your rights under this License.
-However, parties who have received copies, or rights, from you under
-this License will not have their licenses terminated so long as such
-parties remain in full compliance.
-
-  5. You are not required to accept this License, since you have not
-signed it.  However, nothing else grants you permission to modify or
-distribute the Program or its derivative works.  These actions are
-prohibited by law if you do not accept this License.  Therefore, by
-modifying or distributing the Program (or any work based on the
-Program), you indicate your acceptance of this License to do so, and
-all its terms and conditions for copying, distributing or modifying
-the Program or works based on it.
-
-  6. Each time you redistribute the Program (or any work based on the
-Program), the recipient automatically receives a license from the
-original licensor to copy, distribute or modify the Program subject to
-these terms and conditions.  You may not impose any further
-restrictions on the recipients' exercise of the rights granted herein.
-You are not responsible for enforcing compliance by third parties to
-this License.
-
-  7. If, as a consequence of a court judgment or allegation of patent
-infringement or for any other reason (not limited to patent issues),
-conditions are imposed on you (whether by court order, agreement or
-otherwise) that contradict the conditions of this License, they do not
-excuse you from the conditions of this License.  If you cannot
-distribute so as to satisfy simultaneously your obligations under this
-License and any other pertinent obligations, then as a consequence you
-may not distribute the Program at all.  For example, if a patent
-license would not permit royalty-free redistribution of the Program by
-all those who receive copies directly or indirectly through you, then
-the only way you could satisfy both it and this License would be to
-refrain entirely from distribution of the Program.
-
-If any portion of this section is held invalid or unenforceable under
-any particular circumstance, the balance of the section is intended to
-apply and the section as a whole is intended to apply in other
-circumstances.
-
-It is not the purpose of this section to induce you to infringe any
-patents or other property right claims or to contest validity of any
-such claims; this section has the sole purpose of protecting the
-integrity of the free software distribution system, which is
-implemented by public license practices.  Many people have made
-generous contributions to the wide range of software distributed
-through that system in reliance on consistent application of that
-system; it is up to the author/donor to decide if he or she is willing
-to distribute software through any other system and a licensee cannot
-impose that choice.
-
-This section is intended to make thoroughly clear what is believed to
-be a consequence of the rest of this License.
-
-  8. If the distribution and/or use of the Program is restricted in
-certain countries either by patents or by copyrighted interfaces, the
-original copyright holder who places the Program under this License
-may add an explicit geographical distribution limitation excluding
-those countries, so that distribution is permitted only in or among
-countries not thus excluded.  In such case, this License incorporates
-the limitation as if written in the body of this License.
-
-  9. The Free Software Foundation may publish revised and/or new versions
-of the General Public License from time to time.  Such new versions will
-be similar in spirit to the present version, but may differ in detail to
-address new problems or concerns.
-
-Each version is given a distinguishing version number.  If the Program
-specifies a version number of this License which applies to it and "any
-later version", you have the option of following the terms and conditions
-either of that version or of any later version published by the Free
-Software Foundation.  If the Program does not specify a version number of
-this License, you may choose any version ever published by the Free Software
-Foundation.
-
-  10. If you wish to incorporate parts of the Program into other free
-programs whose distribution conditions are different, write to the author
-to ask for permission.  For software which is copyrighted by the Free
-Software Foundation, write to the Free Software Foundation; we sometimes
-make exceptions for this.  Our decision will be guided by the two goals
-of preserving the free status of all derivatives of our free software and
-of promoting the sharing and reuse of software generally.
-
-			    NO WARRANTY
-
-  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
-FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
-OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
-PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
-OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
-MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
-TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
-PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
-REPAIR OR CORRECTION.
-
-  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
-WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
-REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
-INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
-OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
-TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
-YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
-PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
-POSSIBILITY OF SUCH DAMAGES.
-
-		     END OF TERMS AND CONDITIONS
-
-	Appendix: How to Apply These Terms to Your New Programs
-
-  If you develop a new program, and you want it to be of the greatest
-possible use to the public, the best way to achieve this is to make it
-free software which everyone can redistribute and change under these terms.
-
-  To do so, attach the following notices to the program.  It is safest
-to attach them to the start of each source file to most effectively
-convey the exclusion of warranty; and each file should have at least
-the "copyright" line and a pointer to where the full notice is found.
-
-    <one line to give the program's name and a brief idea of what it does.>
-    Copyright (C) 19yy  <name of author>
-
-    This program is free software; you can redistribute it and/or modify
-    it under the terms of the GNU General Public License as published by
-    the Free Software Foundation; either version 2 of the License, or
-    (at your option) any later version.
-
-    This program is distributed in the hope that it will be useful,
-    but WITHOUT ANY WARRANTY; without even the implied warranty of
-    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-    GNU General Public License for more details.
-
-    You should have received a copy of the GNU General Public License
-    along with this program; if not, write to the Free Software
-    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
-
-Also add information on how to contact you by electronic and paper mail.
-
-If the program is interactive, make it output a short notice like this
-when it starts in an interactive mode:
-
-    Gnomovision version 69, Copyright (C) 19yy name of author
-    Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
-    This is free software, and you are welcome to redistribute it
-    under certain conditions; type `show c' for details.
-
-The hypothetical commands `show w' and `show c' should show the appropriate
-parts of the General Public License.  Of course, the commands you use may
-be called something other than `show w' and `show c'; they could even be
-mouse-clicks or menu items--whatever suits your program.
-
-You should also get your employer (if you work as a programmer) or your
-school, if any, to sign a "copyright disclaimer" for the program, if
-necessary.  Here is a sample; alter the names:
-
-  Yoyodyne, Inc., hereby disclaims all copyright interest in the program
-  `Gnomovision' (which makes passes at compilers) written by James Hacker.
-
-  <signature of Ty Coon>, 1 April 1989
-  Ty Coon, President of Vice
-
-This General Public License does not permit incorporating your program into
-proprietary programs.  If your program is a subroutine library, you may
-consider it more useful to permit linking proprietary applications with the
-library.  If this is what you want to do, use the GNU Library General
-Public License instead of this License.
@@ -1,151 +0,0 @@
-/*
- * Copyright (c) 2001 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: HName.cc,v 1.8 2007/06/02 03:42:12 steve Exp $"
-#endif
-
-# include  "config.h"
-# include  "HName.h"
-# include  <iostream>
-# include  <string.h>
-# include  <stdlib.h>
-#ifdef HAVE_MALLOC_H
-# include  <malloc.h>
-#endif
-
-
-hname_t::hname_t()
-{
-      number_ = INT_MIN;
-}
-
-hname_t::hname_t(perm_string text)
-{
-      name_ = text;
-      number_ = INT_MIN;
-}
-
-hname_t::hname_t(perm_string text, int num)
-{
-      name_ = text;
-      number_ = num;
-}
-
-hname_t::hname_t(const hname_t&that)
-{
-      name_ = that.name_;
-      number_ = that.number_;
-}
-
-hname_t& hname_t::operator = (const hname_t&that)
-{
-      name_ = that.name_;
-      number_ = that.number_;
-      return *this;
-}
-
-hname_t::~hname_t()
-{
-}
-
-perm_string hname_t::peek_name(void) const
-{
-      return name_;
-}
-
-bool hname_t::has_number() const
-{
-      return number_ != INT_MIN;
-}
-
-int hname_t::peek_number() const
-{
-      return number_;
-}
-
-bool operator < (const hname_t&l, const hname_t&r)
-{
-      int cmp = strcmp(l.peek_name(), r.peek_name());
-      if (cmp < 0) return true;
-      if (cmp > 0) return false;
-      if (l.has_number() && r.has_number())
-	    return l.peek_number() < r.peek_number();
-      else
-	    return false;
-}
-
-bool operator == (const hname_t&l, const hname_t&r)
-{
-      if (l.peek_name() == r.peek_name()) {
-	    if (l.has_number() && r.has_number())
-		  return l.peek_number() == r.peek_number();
-	    else
-		  return true;
-      }
-
-      return false;
-}
-
-bool operator != (const hname_t&l, const hname_t&r)
-{ return ! (l==r); }
-
-ostream& operator<< (ostream&out, const hname_t&that)
-{
-      if (that.peek_name() == 0) {
-	    out << "";
-	    return out;
-      }
-
-      out << that.peek_name();
-      if (that.has_number())
-	    out << "[" << that.peek_number() << "]";
-
-      return out;
-}
-
-/*
- * $Log: HName.cc,v $
- * Revision 1.8  2007/06/02 03:42:12  steve
- *  Properly evaluate scope path expressions.
- *
- * Revision 1.7  2007/05/16 19:12:33  steve
- *  Fix hname_t use of space for 1 perm_string.
- *
- * Revision 1.6  2007/04/26 03:06:21  steve
- *  Rework hname_t to use perm_strings.
- *
- * Revision 1.5  2002/11/02 03:27:52  steve
- *  Allow named events to be referenced by
- *  hierarchical names.
- *
- * Revision 1.4  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.3  2002/01/05 04:36:06  steve
- *  include malloc.h only when available.
- *
- * Revision 1.2  2001/12/18 04:52:45  steve
- *  Include config.h for namespace declaration.
- *
- * Revision 1.1  2001/12/03 04:47:14  steve
- *  Parser and pform use hierarchical names as hname_t
- *  objects instead of encoded strings.
- *
- */
-
@@ -1,99 +0,0 @@
-#ifndef __HName_H
-#define __HName_H
-/*
- * Copyright (c) 2001-2007 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: HName.h,v 1.7 2007/06/02 03:42:12 steve Exp $"
-#endif
-
-# include  <iostream>
-# include  "StringHeap.h"
-#ifdef __GNUC__
-#if __GNUC__ > 2
-using namespace std;
-#endif
-#endif
-
-/*
- * This class represents a component of a Verilog hierarchical name. A
- * hierarchical component contains a name string (prepresented here
- * with a perm_string) and an optional signed number. This signed
- * number is used if the scope is part of an array, for example an
- * array of module instances or a loop generated scope.
- */
-
-class hname_t {
-
-    public:
-      hname_t ();
-      explicit hname_t (perm_string text);
-      explicit hname_t (perm_string text, int num);
-      hname_t (const hname_t&that);
-      ~hname_t();
-
-      hname_t& operator= (const hname_t&);
-
-	// Return the string part of the hname_t.
-      perm_string peek_name(void) const;
-
-      bool has_number() const;
-      int peek_number() const;
-
-    private:
-      perm_string name_;
-	// If the number is anything other then INT_MIN, then this is
-	// the numeric part of the name. Otherwise, it is not part of
-	// the name at all.
-      int number_;
-
-    private: // not implemented
-};
-
-extern bool operator <  (const hname_t&, const hname_t&);
-extern bool operator == (const hname_t&, const hname_t&);
-extern bool operator != (const hname_t&, const hname_t&);
-extern ostream& operator<< (ostream&, const hname_t&);
-
-/*
- * $Log: HName.h,v $
- * Revision 1.7  2007/06/02 03:42:12  steve
- *  Properly evaluate scope path expressions.
- *
- * Revision 1.6  2007/05/16 19:12:33  steve
- *  Fix hname_t use of space for 1 perm_string.
- *
- * Revision 1.5  2007/04/26 03:06:21  steve
- *  Rework hname_t to use perm_strings.
- *
- * Revision 1.4  2002/11/02 03:27:51  steve
- *  Allow named events to be referenced by
- *  hierarchical names.
- *
- * Revision 1.3  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.2  2002/06/14 03:25:51  steve
- *  Compiler portability.
- *
- * Revision 1.1  2001/12/03 04:47:14  steve
- *  Parser and pform use hierarchical names as hname_t
- *  objects instead of encoded strings.
- *
- */
-#endif
@@ -1,181 +0,0 @@
-Basic Installation
-==================
-
-   These are generic installation instructions.
-
-   The `configure' shell script attempts to guess correct values for
-various system-dependent variables used during compilation.  It uses
-those values to create a `Makefile' in each directory of the package.
-It may also create one or more `.h' files containing system-dependent
-definitions.  Finally, it creates a shell script `config.status' that
-you can run in the future to recreate the current configuration, a file
-`config.cache' that saves the results of its tests to speed up
-reconfiguring, and a file `config.log' containing compiler output
-(useful mainly for debugging `configure').
-
-   If you need to do unusual things to compile the package, please try
-to figure out how `configure' could check whether to do them, and mail
-diffs or instructions to the address given in the `README' so they can
-be considered for the next release.  If at some point `config.cache'
-contains results you don't want to keep, you may remove or edit it.
-
-   The file `configure.in' is used to create `configure' by a program
-called `autoconf'.  You only need `configure.in' if you want to change
-it or regenerate `configure' using a newer version of `autoconf'.
-
-The simplest way to compile this package is:
-
-  1. `cd' to the directory containing the package's source code and type
-     `./configure' to configure the package for your system.  If you're
-     using `csh' on an old version of System V, you might need to type
-     `sh ./configure' instead to prevent `csh' from trying to execute
-     `configure' itself.
-
-     Running `configure' takes awhile.  While running, it prints some
-     messages telling which features it is checking for.
-
-  2. Type `make' to compile the package.
-
-  3. Optionally, type `make check' to run any self-tests that come with
-     the package.
-
-  4. Type `make install' to install the programs and any data files and
-     documentation.
-
-  5. You can remove the program binaries and object files from the
-     source code directory by typing `make clean'.  To also remove the
-     files that `configure' created (so you can compile the package for
-     a different kind of computer), type `make distclean'.  There is
-     also a `make maintainer-clean' target, but that is intended mainly
-     for the package's developers.  If you use it, you may have to get
-     all sorts of other programs in order to regenerate files that came
-     with the distribution.
-
-Compilers and Options
-=====================
-
-   Some systems require unusual options for compilation or linking that
-the `configure' script does not know about.  You can give `configure'
-initial values for variables by setting them in the environment.  Using
-a Bourne-compatible shell, you can do that on the command line like
-this:
-     CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure
-
-Or on systems that have the `env' program, you can do it like this:
-     env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure
-
-Compiling For Multiple Architectures
-====================================
-
-   You can compile the package for more than one kind of computer at the
-same time, by placing the object files for each architecture in their
-own directory.  To do this, you must use a version of `make' that
-supports the `VPATH' variable, such as GNU `make'.  `cd' to the
-directory where you want the object files and executables to go and run
-the `configure' script.  `configure' automatically checks for the
-source code in the directory that `configure' is in and in `..'.
-
-   If you have to use a `make' that does not supports the `VPATH'
-variable, you have to compile the package for one architecture at a time
-in the source code directory.  After you have installed the package for
-one architecture, use `make distclean' before reconfiguring for another
-architecture.
-
-Installation Names
-==================
-
-   By default, `make install' will install the package's files in
-`/usr/local/bin', `/usr/local/man', etc.  You can specify an
-installation prefix other than `/usr/local' by giving `configure' the
-option `--prefix=PATH'.
-
-   You can specify separate installation prefixes for
-architecture-specific files and architecture-independent files.  If you
-give `configure' the option `--exec-prefix=PATH', the package will use
-PATH as the prefix for installing programs and libraries.
-Documentation and other data files will still use the regular prefix.
-
-   In addition, if you use an unusual directory layout you can give
-options like `--bindir=PATH' to specify different values for particular
-kinds of files.  Run `configure --help' for a list of the directories
-you can set and what kinds of files go in them.
-
-   If the package supports it, you can cause programs to be installed
-with an extra prefix or suffix on their names by giving `configure' the
-option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
-
-Optional Features
-=================
-
-   Some packages pay attention to `--enable-FEATURE' options to
-`configure', where FEATURE indicates an optional part of the package.
-They may also pay attention to `--with-PACKAGE' options, where PACKAGE
-is something like `gnu-as' or `x' (for the X Window System).  The
-`README' should mention any `--enable-' and `--with-' options that the
-package recognizes.
-
-   For packages that use the X Window System, `configure' can usually
-find the X include and library files automatically, but if it doesn't,
-you can use the `configure' options `--x-includes=DIR' and
-`--x-libraries=DIR' to specify their locations.
-
-Specifying the System Type
-==========================
-
-   There may be some features `configure' can not figure out
-automatically, but needs to determine by the type of host the package
-will run on.  Usually `configure' can figure that out, but if it prints
-a message saying it can not guess the host type, give it the
-`--host=TYPE' option.  TYPE can either be a short name for the system
-type, such as `sun4', or a canonical name with three fields:
-     CPU-COMPANY-SYSTEM
-
-See the file `config.sub' for the possible values of each field.  If
-`config.sub' isn't included in this package, then this package doesn't
-need to know the host type.
-
-   If you are building compiler tools for cross-compiling, you can also
-use the `--target=TYPE' option to select the type of system they will
-produce code for and the `--build=TYPE' option to select the type of
-system on which you are compiling the package.
-
-Sharing Defaults
-================
-
-   If you want to set default values for `configure' scripts to share,
-you can create a site shell script called `config.site' that gives
-default values for variables like `CC', `cache_file', and `prefix'.
-`configure' looks for `PREFIX/share/config.site' if it exists, then
-`PREFIX/etc/config.site' if it exists.  Or, you can set the
-`CONFIG_SITE' environment variable to the location of the site script.
-A warning: not all `configure' scripts look for a site script.
-
-Operation Controls
-==================
-
-   `configure' recognizes the following options to control how it
-operates.
-
-`--cache-file=FILE'
-     Use and save the results of the tests in FILE instead of
-     `./config.cache'.  Set FILE to `/dev/null' to disable caching, for
-     debugging `configure'.
-
-`--help'
-     Print a summary of the options to `configure', and exit.
-
-`--quiet'
-`--silent'
-`-q'
-     Do not print messages saying which checks are being made.
-
-`--srcdir=DIR'
-     Look for the package's source code in directory DIR.  Usually
-     `configure' can determine that directory automatically.
-
-`--version'
-     Print the version of Autoconf used to generate the `configure'
-     script, and exit.
-
-`configure' also accepts some other, not widely useful, options.
-
@@ -1,78 +0,0 @@
-/*
- * Copyright (c) 2000 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: LineInfo.cc,v 1.4 2003/01/17 05:49:03 steve Exp $"
-#endif
-
-# include "config.h"
-
-# include  "LineInfo.h"
-# include  <sstream>
-
-LineInfo::LineInfo()
-: file_(0), lineno_(0)
-{
-}
-
-LineInfo::~LineInfo()
-{
-}
-
-string LineInfo::get_line() const
-{
-      ostringstream buf;
-      buf << (file_? file_ : "") << ":" << lineno_;
-
-      string res = buf.str();
-      return res;
-}
-
-void LineInfo::set_line(const LineInfo&that)
-{
-      file_ = that.file_;
-      lineno_ = that.lineno_;
-}
-
-void LineInfo::set_file(const char*f)
-{
-      file_ = f;
-}
-
-void LineInfo::set_lineno(unsigned n)
-{
-      lineno_ = n;
-}
-
-/*
- * $Log: LineInfo.cc,v $
- * Revision 1.4  2003/01/17 05:49:03  steve
- *  Use stringstream in place of sprintf.
- *
- * Revision 1.3  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.2  2001/07/25 03:10:48  steve
- *  Create a config.h.in file to hold all the config
- *  junk, and support gcc 3.0. (Stephan Boettcher)
- *
- * Revision 1.1  2000/11/30 17:31:42  steve
- *  Change LineInfo to store const C strings.
- *
- */
-
@@ -1,75 +0,0 @@
-#ifndef __LineInfo_H
-#define __LineInfo_H
-/*
- * Copyright (c) 1999 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: LineInfo.h,v 1.8 2005/06/14 19:13:43 steve Exp $"
-#endif
-
-# include  <string>
-
-using namespace std;
-
-/*
- * This class holds line information for an internal object.
- *
- * Note that the file names are C-style strings that are allocated by
- * the lexor (which parses the line directives) and are never
- * deallocated. We can therefore safely store the pointer and never
- * delete the string, even if LineInfo objects are destroyed.
- */
-
-class LineInfo {
-    public:
-      LineInfo();
-      ~LineInfo();
-
-      string get_line() const;
-
-      void set_line(const LineInfo&that);
-
-      void set_file(const char*f);
-      void set_lineno(unsigned n);
-
-    private:
-      const char* file_;
-      unsigned lineno_;
-};
-
-/*
- * $Log: LineInfo.h,v $
- * Revision 1.8  2005/06/14 19:13:43  steve
- *  gcc3/4 compile errors.
- *
- * Revision 1.7  2003/01/17 05:49:03  steve
- *  Use stringstream in place of sprintf.
- *
- * Revision 1.6  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.5  2000/11/30 17:31:42  steve
- *  Change LineInfo to store const C strings.
- *
- * Revision 1.4  2000/02/23 02:56:53  steve
- *  Macintosh compilers do not support ident.
- *
- * Revision 1.3  1999/02/15 02:06:15  steve
- *  Elaborate gate ranges.
- */
-#endif
@@ -1,282 +0,0 @@
-#
-#    This source code is free software; you can redistribute it
-#    and/or modify it in source code form under the terms of the GNU
-#    Library General Public License as published by the Free Software
-#    Foundation; either version 2 of the License, or (at your option)
-#    any later version.
-#
-#    This program is distributed in the hope that it will be useful,
-#    but WITHOUT ANY WARRANTY; without even the implied warranty of
-#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-#    GNU Library General Public License for more details.
-#
-#    You should have received a copy of the GNU Library General Public
-#    License along with this program; if not, write to the Free
-#    Software Foundation, Inc.,
-#    59 Temple Place - Suite 330
-#    Boston, MA 02111-1307, USA
-#
-#ident "$Id: Makefile.in,v 1.181 2007/05/24 04:07:11 steve Exp $"
-#
-#
-SHELL = /bin/sh
-
-# This version string is only used in the version message printed
-# by the compiler. It reflects the assigned version number for the
-# product as a whole. Most components also print the CVS Name: token
-# in order to get a more automatic version stamp as well.
-VERSION = 0.9.devel
-
-prefix = @prefix@
-exec_prefix = @exec_prefix@
-srcdir = @srcdir@
-
-SUBDIRS = @subdirs@
-
-VPATH = $(srcdir)
-
-bindir = @bindir@
-libdir = @libdir@
-includedir = @includedir@
-mandir = @mandir@
-
-libdir64 = @libdir64@
-
-dllib=@DLLIB@
-
-CC = @CC@
-CXX = @CXX@
-INSTALL = @INSTALL@
-INSTALL_SCRIPT = @INSTALL_SCRIPT@
-INSTALL_PROGRAM = @INSTALL_PROGRAM@
-INSTALL_DATA = @INSTALL_DATA@
-LEX = @LEX@
-YACC = @YACC@
-
-CPPFLAGS = @ident_support@ @DEFS@ -I. -I$(srcdir) @CPPFLAGS@
-CXXFLAGS = -Wall @CXXFLAGS@
-PICFLAGS = @PICFLAG@
-LDFLAGS = @rdynamic@ @LDFLAGS@
-
-all: dep ivl@EXEEXT@
-	for dir in $(SUBDIRS); do (cd $$dir ; $(MAKE) $@); done
-	for dir in ivlpp ; \
-	    do (cd $$dir ; $(MAKE) $@); done
-	cd driver ; $(MAKE) VERSION=$(VERSION) $@
-
-# In the windows world, the installer will need a dosify program to
-# dosify text files.
-ifeq (@MING32@,yes)
-all: dep dosify.exe
-dosify.exe: dosify.c
-	$(CC) -o dosify.exe dosify.c
-endif
-
-# This rule rules the compiler in the trivial hello.vl program to make
-# sure the basics were compiled properly.
-check: all
-	for dir in $(SUBDIRS); do (cd $$dir ; $(MAKE) check); done
-	test -r check.conf || cp $(srcdir)/check.conf .
-	driver/iverilog -B. -BPivlpp -tcheck -ocheck.vvp $(srcdir)/examples/hello.vl
-	vvp/vvp -M- -M./vpi ./check.vvp | grep 'Hello, World'
-
-clean:
-	for dir in $(SUBDIRS); do (cd $$dir ; $(MAKE) $@); done
-	for dir in vpi ivlpp tgt-verilog tgt-pal driver driver-vpi; \
-	    do (cd $$dir ; $(MAKE) $@); done
-	rm -f *.o parse.cc parse.cc.output parse.h lexor.cc
-	rm -f ivl.exp iverilog-vpi.pdf iverilog-vpi.ps parse.output
-	rm -f syn-rules.output dosify.exe ivl@EXEEXT@ check.vvp
-	rm -f lexor_keyword.cc libivl.a libvpi.a iverilog-vpi syn-rules.cc*
-	rm -rf dep
-
-distclean: clean
-	for dir in $(SUBDIRS); do (cd $$dir ; $(MAKE) $@); done
-	for dir in vpi ivlpp tgt-verilog tgt-pal driver driver-vpi; \
-	    do (cd $$dir ; $(MAKE) $@); done
-	rm -f Makefile config.status config.log config.cache config.h
-	rm -f _pli_types.h
-
-TT = t-dll.o t-dll-api.o t-dll-expr.o t-dll-proc.o
-FF = cprop.o nodangle.o synth.o synth2.o syn-rules.o
-
-O = main.o async.o design_dump.o dup_expr.o elaborate.o elab_expr.o \
-elab_lval.o elab_net.o elab_pexpr.o elab_scope.o \
-elab_sig.o emit.o eval.o eval_attrib.o \
-eval_tree.o expr_synth.o functor.o lexor.o lexor_keyword.o link_const.o \
-load_module.o netlist.o netmisc.o net_assign.o \
-net_design.o net_event.o net_expr.o net_force.o net_func.o \
-net_link.o net_modulo.o net_nex_input.o net_nex_output.o \
-net_proc.o net_scope.o net_udp.o pad_to_width.o \
-parse.o parse_misc.o pform.o pform_dump.o pform_types.o \
-set_width.o symbol_search.o sync.o sys_funcs.o \
-verinum.o verireal.o target.o targets.o \
-Attrib.o HName.o LineInfo.o Module.o PDelays.o PEvent.o \
-PExpr.o PGate.o PGenerate.o PSpec.o \
-PTask.o PUdp.o PFunction.o PWire.o Statement.o StringHeap.o \
-$(FF) $(TT)
-
-Makefile: Makefile.in config.h.in config.status
-	./config.status
-
-
-ifeq (@WIN32@,yes)
-# Under Windows (mingw) I need to make the ivl.exe in two steps.
-# The first step makes an ivl.exe that dlltool can use to make an
-# export and import library, and the last link makes a, ivl.exe
-# that really exports the things that the import library imports.
-ivl@EXEEXT@: $O ivl.def
-	$(CXX) -o ivl@EXEEXT@ $O $(dllib) @EXTRALIBS@
-	dlltool --dllname ivl@EXEEXT@ --def ivl.def \
-		--output-lib libivl.a --output-exp ivl.exp
-	$(CXX) $(LDFLAGS) -o ivl@EXEEXT@ ivl.exp $O $(dllib) @EXTRALIBS@
-else
-ivl@EXEEXT@: $O
-	$(CXX) $(LDFLAGS) -o ivl@EXEEXT@ $O $(dllib)
-endif
-
-ifeq (@MINGW32@,yes)
-SUBDIRS += driver-vpi
-else
-all: dep iverilog-vpi
-
-iverilog-vpi: iverilog-vpi.sh
-	sed -e 's;@SHARED@;@shared@;' -e 's;@PIC@;@PICFLAG@;' \
-	    -e 's;@IVCC@;$(CC);' \
-	    -e 's;@IVCXX@;$(CXX);' \
-	    -e 's;@IVCFLAGS@;$(CXXFLAGS);' \
-	    -e 's;@INCLUDEDIR@;@includedir@;' \
-	    -e 's;@LIBDIR64@;@libdir64@;' \
-	    -e 's;@VPIDIR1@;@vpidir1@;' -e 's;@VPIDIR2@;@vpidir2@;' \
-	    -e 's;@LIBDIR@;@libdir@;' $< > $@
-	chmod +x $@
-endif
-
-dep:
-	mkdir dep
-
-%.o: %.cc
-	$(CXX) $(CPPFLAGS) $(CXXFLAGS) -MD -c $< -o $*.o
-	mv $*.d dep/$*.d
-
-
-lexor.o: lexor.cc parse.h
-
-parse.o: parse.cc
-
-parse.cc parse.h: $(srcdir)/parse.y
-	$(YACC) --verbose -t -p VL -d -o parse.cc $(srcdir)/parse.y
-	mv parse.cc.h parse.h 2>/dev/null || mv parse.hh parse.h
-
-syn-rules.cc: $(srcdir)/syn-rules.y
-	$(YACC) --verbose -p syn_ -o syn-rules.cc $(srcdir)/syn-rules.y
-
-lexor.cc: $(srcdir)/lexor.lex
-	$(LEX) -PVL -s -olexor.cc $(srcdir)/lexor.lex
-
-lexor_keyword.o: lexor_keyword.cc parse.h
-
-lexor_keyword.cc: lexor_keyword.gperf
-	gperf -o -i 7 -C -k 1-3,$$ -L ANSI-C -H keyword_hash -N check_identifier -t $(srcdir)/lexor_keyword.gperf > lexor_keyword.cc || (rm -f lexor_keyword.cc ; false)
-
-iverilog-vpi.ps: $(srcdir)/iverilog-vpi.man
-	man -t $(srcdir)/iverilog-vpi.man > iverilog-vpi.ps
-
-iverilog-vpi.pdf: iverilog-vpi.ps
-	ps2pdf iverilog-vpi.ps iverilog-vpi.pdf
-
-ifeq (@MING32@,yes)
-INSTALL_DOC = $(prefix)/iverilog-vpi.pdf $(mandir)/man1/iverilog-vpi.1
-INSTALL_DOCDIR = $(mandir)/man1
-all: dep iverilog-vpi.pdf
-else
-INSTALL_DOC = $(mandir)/man1/iverilog-vpi.1
-INSTALL_DOCDIR = $(mandir)/man1
-endif
-
-ifeq (@MINGW32@,yes)
-WIN32_INSTALL = $(prefix)/hello.vl $(prefix)/sqrt.vl $(prefix)/sqrt-virtex.v $(prefix)/QUICK_START.txt
-else
-WIN32_INSTALL = $(bindir)/iverilog-vpi
-endif
-
-XNF_INSTALL = $(libdir)/ivl/xnf.conf $(libdir)/ivl/xnf-s.conf
-
-install: all installdirs $(libdir)/ivl/ivl@EXEEXT@  $(includedir)/ivl_target.h $(includedir)/_pli_types.h $(includedir)/vpi_user.h $(includedir)/acc_user.h $(includedir)/veriuser.h $(WIN32_INSTALL) $(INSTALL_DOC)
-	for dir in $(SUBDIRS); do (cd $$dir ; $(MAKE) $@); done
-	for dir in vpi ivlpp driver; \
-	    do (cd $$dir ; $(MAKE) $@); done
-
-$(bindir)/iverilog-vpi: ./iverilog-vpi
-	$(INSTALL_SCRIPT) ./iverilog-vpi $(bindir)/iverilog-vpi
-
-$(libdir)/ivl/ivl@EXEEXT@: ./ivl@EXEEXT@
-	$(INSTALL_PROGRAM) ./ivl@EXEEXT@ $(libdir)/ivl/ivl@EXEEXT@
-
-$(libdir)/ivl/xnf-s.conf: $(srcdir)/xnf-s.conf
-	$(INSTALL_DATA) $(srcdir)/xnf-s.conf $(libdir)/ivl/xnf-s.conf
-
-$(libdir)/ivl/xnf.conf: $(srcdir)/xnf.conf
-	$(INSTALL_DATA) $(srcdir)/xnf.conf $(libdir)/ivl/xnf.conf
-
-$(includedir)/ivl_target.h: $(srcdir)/ivl_target.h
-	$(INSTALL_DATA) $(srcdir)/ivl_target.h $(includedir)/ivl_target.h
-
-$(includedir)/_pli_types.h: _pli_types.h
-	$(INSTALL_DATA) $< $(includedir)/_pli_types.h
-
-$(includedir)/vpi_user.h: $(srcdir)/vpi_user.h
-	$(INSTALL_DATA) $(srcdir)/vpi_user.h $(includedir)/vpi_user.h
-
-$(includedir)/acc_user.h: $(srcdir)/acc_user.h
-	$(INSTALL_DATA) $(srcdir)/acc_user.h $(includedir)/acc_user.h
-
-$(includedir)/veriuser.h: $(srcdir)/veriuser.h
-	$(INSTALL_DATA) $(srcdir)/veriuser.h $(includedir)/veriuser.h
-
-$(mandir)/man1/iverilog-vpi.1: $(srcdir)/iverilog-vpi.man
-	$(INSTALL_DATA) $(srcdir)/iverilog-vpi.man $(mandir)/man1/iverilog-vpi.1
-
-$(prefix)/iverilog-vpi.pdf: iverilog-vpi.pdf
-	$(INSTALL_DATA) iverilog-vpi.pdf $(prefix)/iverilog-vpi.pdf
-
-# In windows installations, put a few examples and the quick_start
-# into the destination directory.
-ifeq (@MINGW32@,yes)
-$(prefix)/hello.vl: $(srcdir)/examples/hello.vl
-	./dosify.exe $(srcdir)/examples/hello.vl tmp.vl
-	mv tmp.vl $(prefix)/hello.vl
-
-$(prefix)/sqrt.vl: $(srcdir)/examples/sqrt.vl
-	./dosify.exe $(srcdir)/examples/sqrt.vl tmp.vl
-	mv tmp.vl $(prefix)/sqrt.vl
-
-$(prefix)/sqrt-virtex.v: $(srcdir)/examples/sqrt-virtex.v
-	./dosify.exe $(srcdir)/examples/sqrt-virtex.v tmp.vl
-	mv tmp.vl $(prefix)/sqrt-virtex.v
-
-$(prefix)/QUICK_START.txt: $(srcdir)/QUICK_START.txt
-	./dosify.exe $(srcdir)/QUICK_START.txt tmp.txt
-	mv tmp.txt $(prefix)/QUICK_START.txt
-endif
-
-installdirs: mkinstalldirs
-	$(srcdir)/mkinstalldirs $(bindir) $(includedir) $(libdir)/ivl \
-	    $(mandir) $(mandir)/man1
-
-uninstall:
-	for dir in $(SUBDIRS); do (cd $$dir ; $(MAKE) $@); done
-	for dir in vpi ivlpp driver; \
-	    do (cd $$dir ; $(MAKE) $@); done
-	for f in xnf.conf xnf-s.conf ivl@EXEEXT@; \
-	    do rm -f $(libdir)/ivl/$$f; done
-	-rmdir $(libdir)/ivl
-	for f in verilog iverilog-vpi gverilog@EXEEXT@; \
-	    do rm -f $(bindir)/$$f; done
-	for f in ivl_target.h vpi_user.h _pli_types.h acc_user.h veriuser.h; \
-	    do rm -f $(includedir)/$$f; done
-	rm -f $(mandir)/man1/iverilog-vpi.1 $(prefix)/iverilog-vpi.pdf
-
-
-include $(patsubst %.o, dep/%.d, $O)
-include $(patsubst %.o, dep/%.d, vpithunk.o)
@@ -1,239 +0,0 @@
-/*
- * Copyright (c) 1998-2000 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: Module.cc,v 1.27 2007/05/24 04:07:11 steve Exp $"
-#endif
-
-# include "config.h"
-
-# include  "Module.h"
-# include  "PGate.h"
-# include  "PWire.h"
-# include  <assert.h>
-
-/* n is a permallocated string. */
-Module::Module(perm_string n)
-: name_(n)
-{
-      library_flag = false;
-      default_nettype = NetNet::NONE;
-}
-
-Module::~Module()
-{
-}
-
-void Module::add_gate(PGate*gate)
-{
-      gates_.push_back(gate);
-}
-
-void Module::add_task(perm_string name, PTask*task)
-{
-      tasks_[name] = task;
-}
-
-void Module::add_function(perm_string name, PFunction *func)
-{
-      funcs_[name] = func;
-}
-
-PWire* Module::add_wire(PWire*wire)
-{
-      PWire*&ep = wires_[wire->path()];
-      if (ep) return ep;
-
-      assert(ep == 0);
-      ep = wire;
-      return wire;
-}
-
-void Module::add_behavior(PProcess*b)
-{
-      behaviors_.push_back(b);
-}
-
-unsigned Module::port_count() const
-{
-      return ports.count();
-}
-
-/*
- * Return the array of PEIdent object that are at this port of the
- * module. If the port is internally unconnected, return an empty
- * array.
- */
-const svector<PEIdent*>& Module::get_port(unsigned idx) const
-{
-      assert(idx < ports.count());
-      static svector<PEIdent*> zero;
-
-      if (ports[idx])
-	    return ports[idx]->expr;
-      else
-	    return zero;
-}
-
-unsigned Module::find_port(const char*name) const
-{
-      assert(name != "");
-      for (unsigned idx = 0 ;  idx < ports.count() ;  idx += 1) {
-	    if (ports[idx] == 0) {
-		    /* It is possible to have undeclared ports. These
-		       are ports that are skipped in the declaration,
-		       for example like so: module foo(x ,, y); The
-		       port between x and y is unnamed and thus
-		       inaccessible to binding by name. */
-		  continue;
-	    }
-	    assert(ports[idx]);
-	    if (ports[idx]->name == name)
-		  return idx;
-      }
-
-      return ports.count();
-}
-
-
-PWire* Module::get_wire(const pform_name_t&name) const
-{
-      map<pform_name_t,PWire*>::const_iterator obj = wires_.find(name);
-      if (obj == wires_.end())
-	    return 0;
-      else
-	    return (*obj).second;
-}
-
-PGate* Module::get_gate(perm_string name)
-{
-      for (list<PGate*>::iterator cur = gates_.begin()
-		 ; cur != gates_.end()
-		 ; cur ++ ) {
-
-	    if ((*cur)->get_name() == name)
-		  return *cur;
-      }
-
-      return 0;
-}
-
-const list<PGate*>& Module::get_gates() const
-{
-      return gates_;
-}
-
-const list<PProcess*>& Module::get_behaviors() const
-{
-      return behaviors_;
-}
-
-
-/*
- * $Log: Module.cc,v $
- * Revision 1.27  2007/05/24 04:07:11  steve
- *  Rework the heirarchical identifier parse syntax and pform
- *  to handle more general combinations of heirarch and bit selects.
- *
- * Revision 1.26  2007/04/19 02:52:53  steve
- *  Add support for -v flag in command file.
- *
- * Revision 1.25  2004/10/04 01:10:51  steve
- *  Clean up spurious trailing white space.
- *
- * Revision 1.24  2004/06/13 04:56:53  steve
- *  Add support for the default_nettype directive.
- *
- * Revision 1.23  2004/02/20 06:22:56  steve
- *  parameter keys are per_strings.
- *
- * Revision 1.22  2004/02/18 17:11:54  steve
- *  Use perm_strings for named langiage items.
- *
- * Revision 1.21  2003/04/02 03:00:14  steve
- *  Cope with empty module ports while binding by name.
- *
- * Revision 1.20  2003/03/06 04:37:12  steve
- *  lex_strings.add module names earlier.
- *
- * Revision 1.19  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.18  2002/05/19 23:37:28  steve
- *  Parse port_declaration_lists from the 2001 Standard.
- *
- * Revision 1.17  2001/12/03 04:47:14  steve
- *  Parser and pform use hierarchical names as hname_t
- *  objects instead of encoded strings.
- *
- * Revision 1.16  2001/10/20 05:21:51  steve
- *  Scope/module names are char* instead of string.
- *
- * Revision 1.15  2001/07/25 03:10:48  steve
- *  Create a config.h.in file to hold all the config
- *  junk, and support gcc 3.0. (Stephan Boettcher)
- *
- * Revision 1.14  2000/11/15 20:31:05  steve
- *  Fix warning about temporaries.
- *
- * Revision 1.13  2000/11/05 06:05:59  steve
- *  Handle connectsion to internally unconnected modules (PR#38)
- *
- * Revision 1.12  2000/05/16 04:05:15  steve
- *  Module ports are really special PEIdent
- *  expressions, because a name can be used
- *  many places in the port list.
- *
- * Revision 1.11  2000/03/12 17:09:40  steve
- *  Support localparam.
- *
- * Revision 1.10  2000/02/23 02:56:53  steve
- *  Macintosh compilers do not support ident.
- *
- * Revision 1.9  2000/01/09 20:37:57  steve
- *  Careful with wires connected to multiple ports.
- *
- * Revision 1.8  1999/12/11 05:45:41  steve
- *  Fix support for attaching attributes to primitive gates.
- *
- * Revision 1.7  1999/09/17 02:06:25  steve
- *  Handle unconnected module ports.
- *
- * Revision 1.6  1999/08/04 02:13:02  steve
- *  Elaborate module ports that are concatenations of
- *  module signals.
- *
- * Revision 1.5  1999/08/03 04:14:49  steve
- *  Parse into pform arbitrarily complex module
- *  port declarations.
- *
- * Revision 1.4  1999/07/31 19:14:47  steve
- *  Add functions up to elaboration (Ed Carter)
- *
- * Revision 1.3  1999/07/03 02:12:51  steve
- *  Elaborate user defined tasks.
- *
- * Revision 1.2  1999/06/17 05:34:42  steve
- *  Clean up interface of the PWire class,
- *  Properly match wire ranges.
- *
- * Revision 1.1  1998/11/03 23:28:51  steve
- *  Introduce verilog to CVS.
- *
- */
-
@@ -1,204 +0,0 @@
-#ifndef __Module_H
-#define __Module_H
-/*
- * Copyright (c) 1998-2004 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: Module.h,v 1.43 2007/05/24 04:07:11 steve Exp $"
-#endif
-
-# include  <list>
-# include  <map>
-# include  "svector.h"
-# include  "StringHeap.h"
-# include  "HName.h"
-# include  "named.h"
-# include  "LineInfo.h"
-# include  "netlist.h"
-# include  "pform_types.h"
-class PEvent;
-class PExpr;
-class PEIdent;
-class PGate;
-class PGenerate;
-class PSpecPath;
-class PTask;
-class PFunction;
-class PWire;
-class PProcess;
-class Design;
-class NetScope;
-
-/*
- * A module is a named container and scope. A module holds a bunch of
- * semantic quantities such as wires and gates. The module is
- * therefore the handle for grasping the described circuit.
- */
-
-class Module : public LineInfo {
-
-	/* The module ports are in general a vector of port_t
-	   objects. Each port has a name and an ordered list of
-	   wires. The name is the means that the outside uses to
-	   access the port, the wires are the internal connections to
-	   the port. */
-    public:
-      struct port_t {
-	    perm_string name;
-	    svector<PEIdent*> expr;
-      };
-
-    public:
-	/* The name passed here is the module name, not the instance
-	   name. This make must be a permallocated string. */
-      explicit Module(perm_string name);
-      ~Module();
-
-	/* Initially false. This is set to true if the module has been
-	   declared as a library module. This makes the module
-	   ineligible for being chosen as an implicit root. It has no
-	   other effect. */
-      bool library_flag;
-
-      NetNet::Type default_nettype;
-
-	/* The module has parameters that are evaluated when the
-	   module is elaborated. During parsing, I put the parameters
-	   into this map. */
-      struct param_expr_t {
-	    PExpr*expr;
-	    PExpr*msb;
-	    PExpr*lsb;
-	    bool signed_flag;
-      };
-      map<perm_string,param_expr_t>parameters;
-      map<perm_string,param_expr_t>localparams;
-
-
-	/* specparams are simpler then other params, in that they have
-	   no type information. They are merely constant
-	   expressions. */
-      map<perm_string,PExpr*>specparams;
-
-	/* The module also has defparam assignments which don't create
-	   new parameters within the module, but may be used to set
-	   values within this module (when instantiated) or in other
-	   instantiated modules. */
-      map<pform_name_t,PExpr*>defparms;
-
-        /* Parameters may be overridden at instantiation time;
-           the overrides do not contain explicit parameter names,
-           but rather refer to parameters in the order they
-           appear in the instantiated module.  Therefore a
-           list of names in module-order is needed to pass from
-           a parameter-index to its name. */
-      list<perm_string> param_names;
-
-	/* This is an array of port descriptors, which is in turn a
-	   named array of PEident pointers. */
-      svector<port_t*> ports;
-
-	/* Keep a table of named events declared in the module. */
-      map<perm_string,PEvent*>events;
-
-      map<perm_string,PExpr*> attributes;
-
-	/* These are the timescale for this module. The default is
-	   set by the `timescale directive. */
-      int time_unit, time_precision;
-
-	/* The module has a list of genvars that may be used in
-	   various generate schemes. */
-      list<perm_string> genvars;
-
-	/* the module has a list of generate schemes that appear in
-	   the module definition. These are used at elaboration time. */
-      list<PGenerate*> generate_schemes;
-
-      list<PSpecPath*> specify_paths;
-
-      perm_string mod_name() const { return name_; }
-
-      void add_gate(PGate*gate);
-
-	// The add_wire method adds a wire by name, but only if the
-	// wire name doesn't already exist. Either way, the result is
-	// the existing wire or the pointer passed in.
-      PWire* add_wire(PWire*wire);
-
-      void add_behavior(PProcess*behave);
-      void add_task(perm_string name, PTask*def);
-      void add_function(perm_string name, PFunction*def);
-
-      unsigned port_count() const;
-      const svector<PEIdent*>& get_port(unsigned idx) const;
-      unsigned find_port(const char*name) const;
-
-	// Find a wire by name. This is used for connecting gates to
-	// existing wires, etc.
-      PWire* get_wire(const pform_name_t&name) const;
-      PGate* get_gate(perm_string name);
-
-      const list<PGate*>& get_gates() const;
-      const list<PProcess*>& get_behaviors() const;
-
-      void dump(ostream&out) const;
-      bool elaborate(Design*, NetScope*scope) const;
-
-      typedef map<perm_string,NetExpr*> replace_t;
-      bool elaborate_scope(Design*, NetScope*scope, const replace_t&rep) const;
-
-      bool elaborate_sig(Design*, NetScope*scope) const;
-
-    private:
-      perm_string name_;
-
-      map<pform_name_t,PWire*> wires_;
-      list<PGate*> gates_;
-      list<PProcess*> behaviors_;
-      map<perm_string,PTask*> tasks_;
-      map<perm_string,PFunction*> funcs_;
-
-    private: // Not implemented
-      Module(const Module&);
-      Module& operator= (const Module&);
-};
-
-
-/*
- * $Log: Module.h,v $
- * Revision 1.43  2007/05/24 04:07:11  steve
- *  Rework the heirarchical identifier parse syntax and pform
- *  to handle more general combinations of heirarch and bit selects.
- *
- * Revision 1.42  2007/04/19 02:52:53  steve
- *  Add support for -v flag in command file.
- *
- * Revision 1.41  2006/09/23 04:57:19  steve
- *  Basic support for specify timing.
- *
- * Revision 1.40  2006/04/10 00:37:42  steve
- *  Add support for generate loops w/ wires and gates.
- *
- * Revision 1.39  2006/03/30 01:49:07  steve
- *  Fix instance arrays indexed by overridden parameters.
- *
- * Revision 1.38  2005/07/11 16:56:50  steve
- *  Remove NetVariable and ivl_variable_t structures.
- */
-#endif
@@ -1,228 +0,0 @@
-/*
- * Copyright (c) 1999 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: PDelays.cc,v 1.15 2006/07/08 21:48:46 steve Exp $"
-#endif
-
-# include "config.h"
-
-# include  <iostream>
-
-# include  "PDelays.h"
-# include  "PExpr.h"
-# include  "verinum.h"
-
-PDelays::PDelays()
-{
-      delete_flag_ = true;
-      for (unsigned idx = 0 ;  idx < 3 ;  idx += 1)
-	    delay_[idx] = 0;
-}
-
-PDelays::~PDelays()
-{
-      if (delete_flag_) {
-	    for (unsigned idx = 0 ;  idx < 3 ;  idx += 1)
-		  delete delay_[idx];
-      }
-}
-
-void PDelays::set_delay(PExpr*del)
-{
-      assert(del);
-      assert(delay_[0] == 0);
-      delay_[0] = del;
-      delete_flag_ = true;
-}
-
-
-void PDelays::set_delays(const svector<PExpr*>*del, bool df)
-{
-      assert(del);
-      assert(del->count() <= 3);
-      for (unsigned idx = 0 ;  idx < del->count() ;  idx += 1)
-	    delay_[idx] = (*del)[idx];
-
-      delete_flag_ = df;
-}
-
-static NetExpr*calculate_val(Design*des, NetScope*scope, const PExpr*expr)
-{
-
-      NetExpr*dex = expr->elaborate_expr(des, scope, -1, false);
-      if (NetExpr*tmp = dex->eval_tree()) {
-	    delete dex;
-	    dex = tmp;
-      }
-
-	/* If the delay expression is a real constant or vector
-	   constant, then evaluate it, scale it to the local time
-	   units, and return an adjusted value. */
-
-      if (NetECReal*tmp = dynamic_cast<NetECReal*>(dex)) {
-	    verireal fn = tmp->value();
-
-	    int shift = scope->time_unit() - des->get_precision();
-	    long delay = fn.as_long(shift);
-	    if (delay < 0)
-		  delay = 0;
-
-	    delete tmp;
-	    NetEConst*tmp2 = new NetEConst(verinum(delay));
-	    tmp2->set_line(*expr);
-	    return tmp2;
-      }
-
-
-      if (NetEConst*tmp = dynamic_cast<NetEConst*>(dex)) {
-	    verinum fn = tmp->value();
-
-	    unsigned long delay =
-		  des->scale_to_precision(fn.as_ulong(), scope);
-
-	    delete tmp;
-	    NetEConst*tmp2 = new NetEConst(verinum(delay));
-	    tmp2->set_line(*expr);
-	    return tmp2;
-      }
-
-	/* Oops, cannot evaluate down to a constant. */
-      return dex;
-}
-
-static NetExpr* make_delay_nets(Design*des, NetExpr*expr)
-{
-      if (dynamic_cast<NetESignal*> (expr))
-	    return expr;
-
-      if (dynamic_cast<NetEConst*> (expr))
-	    return expr;
-
-      NetNet*sig = expr->synthesize(des);
-      if (sig == 0) {
-	    cerr << expr->get_line() << ": error: Expression " << *expr
-		 << " is not suitable for delay expression." << endl;
-	    return 0;
-      }
-
-      expr = new NetESignal(sig);
-      return expr;
-}
-
-void PDelays::eval_delays(Design*des, NetScope*scope,
-			  NetExpr*&rise_time,
-			  NetExpr*&fall_time,
-			  NetExpr*&decay_time,
-			  bool as_nets_flag) const
-{
-      assert(scope);
-
-
-      if (delay_[0]) {
-	    rise_time = calculate_val(des, scope, delay_[0]);
-	    if (as_nets_flag)
-		  rise_time = make_delay_nets(des, rise_time);
-
-	    if (delay_[1]) {
-		  fall_time = calculate_val(des, scope, delay_[1]);
-		  if (as_nets_flag)
-			fall_time = make_delay_nets(des, fall_time);
-
-		  if (delay_[2]) {
-			decay_time = calculate_val(des, scope, delay_[2]);
-		  if (as_nets_flag)
-			decay_time = make_delay_nets(des, decay_time);
-
-		  } else {
-			if (rise_time < fall_time)
-			      decay_time = rise_time;
-			else
-			      decay_time = fall_time;
-		  }
-	    } else {
-		  assert(delay_[2] == 0);
-		  fall_time = rise_time;
-		  decay_time = rise_time;
-	    }
-      } else {
-	    rise_time = 0;
-	    fall_time = 0;
-	    decay_time = 0;
-      }
-}
-
-/*
- * $Log: PDelays.cc,v $
- * Revision 1.15  2006/07/08 21:48:46  steve
- *  Handle real valued literals in net contexts.
- *
- * Revision 1.14  2006/06/02 04:48:49  steve
- *  Make elaborate_expr methods aware of the width that the context
- *  requires of it. In the process, fix sizing of the width of unary
- *  minus is context determined sizes.
- *
- * Revision 1.13  2006/01/03 05:22:14  steve
- *  Handle complex net node delays.
- *
- * Revision 1.12  2006/01/02 05:33:19  steve
- *  Node delays can be more general expressions in structural contexts.
- *
- * Revision 1.11  2003/06/21 01:21:42  steve
- *  Harmless fixup of warnings.
- *
- * Revision 1.10  2003/02/08 19:49:21  steve
- *  Calculate delay statement delays using elaborated
- *  expressions instead of pre-elaborated expression
- *  trees.
- *
- *  Remove the eval_pexpr methods from PExpr.
- *
- * Revision 1.9  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.8  2001/12/29 20:19:31  steve
- *  Do not delete delay expressions of UDP instances.
- *
- * Revision 1.7  2001/11/22 06:20:59  steve
- *  Use NetScope instead of string for scope path.
- *
- * Revision 1.6  2001/11/07 04:01:59  steve
- *  eval_const uses scope instead of a string path.
- *
- * Revision 1.5  2001/07/25 03:10:48  steve
- *  Create a config.h.in file to hold all the config
- *  junk, and support gcc 3.0. (Stephan Boettcher)
- *
- * Revision 1.4  2001/01/20 02:15:50  steve
- *  apologize for not supporting non-constant delays.
- *
- * Revision 1.3  2001/01/14 23:04:55  steve
- *  Generalize the evaluation of floating point delays, and
- *  get it working with delay assignment statements.
- *
- *  Allow parameters to be referenced by hierarchical name.
- *
- * Revision 1.2  2000/02/23 02:56:53  steve
- *  Macintosh compilers do not support ident.
- *
- * Revision 1.1  1999/09/04 19:11:46  steve
- *  Add support for delayed non-blocking assignments.
- *
- */
-
@@ -1,105 +0,0 @@
-#ifndef __PDelays_H
-#define __PDelays_H
-/*
- * Copyright (c) 1999-2002 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: PDelays.h,v 1.9 2006/01/03 05:22:14 steve Exp $"
-#endif
-
-# include  "svector.h"
-# include  <string>
-# include  <iostream>
-
-#ifdef __GNUC__
-#if __GNUC__ > 2
-using namespace std;
-#endif
-#endif
-
-class Design;
-class NetScope;
-class NetExpr;
-class PExpr;
-
-/*
- * Various PForm objects can carry delays. These delays include rise,
- * fall and decay times. This class arranges to carry the triplet.
- */
-class PDelays {
-
-    public:
-      PDelays();
-      ~PDelays();
-
-	/* Set the delay expressions. If the delete_flag is true, then
-	   this object takes ownership of the expressions, and will
-	   delete it in the destructor. */
-      void set_delay(PExpr*);
-      void set_delays(const svector<PExpr*>*del, bool delete_flag=true);
-
-      void eval_delays(Design*des, NetScope*scope,
-		       NetExpr*&rise_time,
-		       NetExpr*&fall_time,
-		       NetExpr*&decay_time,
-		       bool as_nets_flag =false) const;
-
-      void dump_delays(ostream&out) const;
-
-    private:
-      PExpr* delay_[3];
-      bool delete_flag_;
-
-    private: // not implemented
-      PDelays(const PDelays&);
-      PDelays& operator= (const PDelays&);
-};
-
-ostream& operator << (ostream&o, const PDelays&);
-
-/*
- * $Log: PDelays.h,v $
- * Revision 1.9  2006/01/03 05:22:14  steve
- *  Handle complex net node delays.
- *
- * Revision 1.8  2006/01/02 05:33:19  steve
- *  Node delays can be more general expressions in structural contexts.
- *
- * Revision 1.7  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.6  2002/06/14 03:25:51  steve
- *  Compiler portability.
- *
- * Revision 1.5  2001/12/29 20:19:31  steve
- *  Do not delete delay expressions of UDP instances.
- *
- * Revision 1.4  2001/11/22 06:20:59  steve
- *  Use NetScope instead of string for scope path.
- *
- * Revision 1.3  2001/01/16 02:44:17  steve
- *  Use the iosfwd header if available.
- *
- * Revision 1.2  2000/02/23 02:56:53  steve
- *  Macintosh compilers do not support ident.
- *
- * Revision 1.1  1999/09/04 19:11:46  steve
- *  Add support for delayed non-blocking assignments.
- *
- */
-#endif
@@ -1,63 +0,0 @@
-/*
- * Copyright (c) 2004 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: PEvent.cc,v 1.5 2004/02/19 06:57:10 steve Exp $"
-#endif
-
-# include "config.h"
-
-# include  "PEvent.h"
-
-PEvent::PEvent(perm_string n)
-: name_(n)
-{
-}
-
-PEvent::~PEvent()
-{
-}
-
-perm_string  PEvent::name() const
-{
-      return name_;
-}
-
-/*
- * $Log: PEvent.cc,v $
- * Revision 1.5  2004/02/19 06:57:10  steve
- *  Memory and Event names use perm_string.
- *
- * Revision 1.4  2003/03/01 06:25:30  steve
- *  Add the lex_strings string handler, and put
- *  scope names and system task/function names
- *  into this table. Also, permallocate event
- *  names from the beginning.
- *
- * Revision 1.3  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.2  2001/07/25 03:10:48  steve
- *  Create a config.h.in file to hold all the config
- *  junk, and support gcc 3.0. (Stephan Boettcher)
- *
- * Revision 1.1  2000/04/01 19:31:57  steve
- *  Named events as far as the pform.
- *
- */
-
@@ -1,91 +0,0 @@
-#ifndef __PEvent_H
-#define __PEvent_H
-/*
- * Copyright (c) 2000-2004 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: PEvent.h,v 1.9 2004/02/19 06:57:10 steve Exp $"
-#endif
-
-# include  "LineInfo.h"
-# include  "StringHeap.h"
-# include  <string>
-
-class Design;
-class NetScope;
-
-/*
- * The PEvent class represents event objects. These are things that
- * are declared in Verilog as ``event foo;'' The name passed to the
- * constructor is the "foo" part of the declaration.
- */
-class PEvent : public LineInfo {
-
-    public:
-	// The name is a perm-allocated string. It is the simple name
-	// of the event, without any scope.
-      explicit PEvent(perm_string name);
-      ~PEvent();
-
-      perm_string name() const;
-
-      void elaborate_scope(Design*des, NetScope*scope) const;
-
-    private:
-      perm_string name_;
-
-    private: // not implemented
-      PEvent(const PEvent&);
-      PEvent& operator= (const PEvent&);
-};
-
-/*
- * $Log: PEvent.h,v $
- * Revision 1.9  2004/02/19 06:57:10  steve
- *  Memory and Event names use perm_string.
- *
- * Revision 1.8  2003/03/01 06:25:30  steve
- *  Add the lex_strings string handler, and put
- *  scope names and system task/function names
- *  into this table. Also, permallocate event
- *  names from the beginning.
- *
- * Revision 1.7  2003/01/30 16:23:07  steve
- *  Spelling fixes.
- *
- * Revision 1.6  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.5  2001/12/03 04:47:14  steve
- *  Parser and pform use hierarchical names as hname_t
- *  objects instead of encoded strings.
- *
- * Revision 1.4  2001/01/16 02:44:18  steve
- *  Use the iosfwd header if available.
- *
- * Revision 1.3  2000/04/09 17:44:30  steve
- *  Catch event declarations during scope elaborate.
- *
- * Revision 1.2  2000/04/04 03:20:15  steve
- *  Simulate named event trigger and waits.
- *
- * Revision 1.1  2000/04/01 19:31:57  steve
- *  Named events as far as the pform.
- *
- */
-#endif
@@ -1,452 +0,0 @@
-/*
- * Copyright (c) 1998-1999 Stephen Williams <[email protected]>
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: PExpr.cc,v 1.39 2007/05/24 04:07:11 steve Exp $"
-#endif
-
-# include "config.h"
-
-# include  <iostream>
-
-# include  "PExpr.h"
-# include  "Module.h"
-# include  <typeinfo>
-
-PExpr::PExpr()
-{
-}
-
-PExpr::~PExpr()
-{
-}
-
-bool PExpr::is_the_same(const PExpr*that) const
-{
-      return typeid(this) == typeid(that);
-}
-
-bool PExpr::is_constant(Module*) const
-{
-      return false;
-}
-
-NetNet* PExpr::elaborate_lnet(Design*des, NetScope*, bool) const
-{
-      cerr << get_line() << ": error: expression not valid in assign l-value: "
-	   << *this << endl;
-      return 0;
-}
-
-NetNet* PExpr::elaborate_bi_net(Design*des, NetScope*) const
-{
-      cerr << get_line() << ": error: "
-	   << "expression not valid as argument to inout port: "
-	   << *this << endl;
-      return 0;
-}
-
-PEBinary::PEBinary(char op, PExpr*l, PExpr*r)
-: op_(op), left_(l), right_(r)
-{
-}
-
-PEBinary::~PEBinary()
-{
-}
-
-bool PEBinary::is_constant(Module*mod) const
-{
-      return left_->is_constant(mod) && right_->is_constant(mod);
-}
-
-PEBComp::PEBComp(char op, PExpr*l, PExpr*r)
-: PEBinary(op, l, r)
-{
-}
-
-PEBComp::~PEBComp()
-{
-}
-
-PEBShift::PEBShift(char op, PExpr*l, PExpr*r)
-: PEBinary(op, l, r)
-{
-}
-
-PEBShift::~PEBShift()
-{
-}
-
-PECallFunction::PECallFunction(const pform_name_t&n, const svector<PExpr *> &parms)
-: path_(n), parms_(parms)
-{
-}
-
-static pform_name_t pn_from_ps(perm_string n)
-{
-      name_component_t tmp_name (n);
-      pform_name_t tmp;
-      tmp.push_back(tmp_name);
-      return tmp;
-}
-
-PECallFunction::PECallFunction(perm_string n, const svector<PExpr*>&parms)
-: path_(pn_from_ps(n)), parms_(parms)
-{
-}
-
-PECallFunction::PECallFunction(perm_string n)
-: path_(pn_from_ps(n))
-{
-}
-
-PECallFunction::~PECallFunction()
-{
-}
-
-PEConcat::PEConcat(const svector<PExpr*>&p, PExpr*r)
-: parms_(p), repeat_(r)
-{
-}
-
-bool PEConcat::is_constant(Module *mod) const
-{
-      bool constant = repeat_? repeat_->is_constant(mod) : true;
-      for (unsigned i = 0; constant && i < parms_.count(); ++i) {
-	    constant = constant && parms_[i]->is_constant(mod);
-      }
-      return constant;
-}
-
-PEConcat::~PEConcat()
-{
-      delete repeat_;
-}
-
-PEEvent::PEEvent(PEEvent::edge_t t, PExpr*e)
-: type_(t), expr_(e)
-{
-}
-
-PEEvent::~PEEvent()
-{
-}
-
-PEEvent::edge_t PEEvent::type() const
-{
-      return type_;
-}
-
-PExpr* PEEvent::expr() const
-{
-      return expr_;
-}
-
-PEFNumber::PEFNumber(verireal*v)
-: value_(v)
-{
-}
-
-PEFNumber::~PEFNumber()
-{
-      delete value_;
-}
-
-const verireal& PEFNumber::value() const
-{
-      return *value_;
-}
-
-bool PEFNumber::is_constant(Module*) const
-{
-      return true;
-}
-
-PEIdent::PEIdent(const pform_name_t&that)
-: path_(that)
-{
-}
-
-PEIdent::PEIdent(perm_string s)
-{
-      path_.push_back(name_component_t(s));
-}
-
-PEIdent::~PEIdent()
-{
-}
-
-/*
- * An identifier can be in a constant expression if (and only if) it is
- * a parameter.
- *
- * NOTE: This test does not work if the name is hierarchical!
- */
-bool PEIdent::is_constant(Module*mod) const
-{
-      if (mod == 0) return false;
-
-	/*  */
-      perm_string tmp = path_.back().name;
-
-      { map<perm_string,Module::param_expr_t>::const_iterator cur;
-        cur = mod->parameters.find(tmp);
-	if (cur != mod->parameters.end()) return true;
-      }
-
-      { map<perm_string,Module::param_expr_t>::const_iterator cur;
-        cur = mod->localparams.find(tmp);
-	if (cur != mod->localparams.end()) return true;
-      }
-
-      return false;
-}
-
-PENumber::PENumber(verinum*vp)
-: value_(vp)
-{
-      assert(vp);
-}
-
-PENumber::~PENumber()
-{
-      delete value_;
-}
-
-const verinum& PENumber::value() const
-{
-      return *value_;
-}
-
-bool PENumber::is_the_same(const PExpr*that) const
-{
-      const PENumber*obj = dynamic_cast<const PENumber*>(that);
-      if (obj == 0)
-	    return false;
-
-      return *value_ == *obj->value_;
-}
-
-bool PENumber::is_constant(Module*) const
-{
-      return true;
-}
-
-PEString::PEString(char*s)
-: text_(s)
-{
-}
-
-PEString::~PEString()
-{
-      delete[]text_;
-}
-
-string PEString::value() const
-{
-      return text_;
-}
-
-bool PEString::is_constant(Module*) const
-{
-      return true;
-}
-
-PETernary::PETernary(PExpr*e, PExpr*t, PExpr*f)
-: expr_(e), tru_(t), fal_(f)
-{
-}
-
-PETernary::~PETernary()
-{
-}
-
-bool PETernary::is_constant(Module*m) const
-{
-      return expr_->is_constant(m)
-	    && tru_->is_constant(m)
-	    && fal_->is_constant(m);
-}
-
-PEUnary::PEUnary(char op, PExpr*ex)
-: op_(op), expr_(ex)
-{
-}
-
-PEUnary::~PEUnary()
-{
-}
-
-bool PEUnary::is_constant(Module*m) const
-{
-      return expr_->is_constant(m);
-}
-
-/*
- * $Log: PExpr.cc,v $
- * Revision 1.39  2007/05/24 04:07:11  steve
- *  Rework the heirarchical identifier parse syntax and pform
- *  to handle more general combinations of heirarch and bit selects.
- *
- * Revision 1.38  2006/10/30 05:44:49  steve
- *  Expression widths with unsized literals are pseudo-infinite width.
- *
- * Revision 1.37  2005/10/04 04:09:25  steve
- *  Add support for indexed select attached to parameters.
- *
- * Revision 1.36  2005/08/06 17:58:16  steve
- *  Implement bi-directional part selects.
- *
- * Revision 1.35  2004/10/04 01:10:51  steve
- *  Clean up spurious trailing white space.
- *
- * Revision 1.34  2004/02/20 06:22:56  steve
- *  parameter keys are per_strings.
- *
- * Revision 1.33  2003/01/27 05:09:17  steve
- *  Spelling fixes.
- *
- * Revision 1.32  2002/11/09 19:20:48  steve
- *  Port expressions for output ports are lnets, not nets.
- *
- * Revision 1.31  2002/08/19 02:39:16  steve
- *  Support parameters with defined ranges.
- *
- * Revision 1.30  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.29  2001/12/30 21:32:03  steve
- *  Support elaborate_net for PEString objects.
- *
- * Revision 1.28  2001/12/03 04:47:14  steve
- *  Parser and pform use hierarchical names as hname_t
- *  objects instead of encoded strings.
- *
- * Revision 1.27  2001/11/08 05:15:50  steve
- *  Remove string paths from PExpr elaboration.
- *
- * Revision 1.26  2001/11/07 04:26:46  steve
- *  elaborate_lnet uses scope instead of string path.
- *
- * Revision 1.25  2001/11/06 06:11:55  steve
- *  Support more real arithmetic in delay constants.
- *
- * Revision 1.24  2001/07/25 03:10:48  steve
- *  Create a config.h.in file to hold all the config
- *  junk, and support gcc 3.0. (Stephan Boettcher)
- *
- * Revision 1.23  2001/01/14 23:04:55  steve
- *  Generalize the evaluation of floating point delays, and
- *  get it working with delay assignment statements.
- *
- *  Allow parameters to be referenced by hierarchical name.
- *
- * Revision 1.22  2001/01/12 04:31:27  steve
- *  Handle error idents in constants not in any scope (PR#97)
- *
- * Revision 1.21  2000/12/16 19:03:30  steve
- *  Evaluate <= and ?: in parameter expressions (PR#81)
- *
- * Revision 1.20  2000/12/10 22:01:35  steve
- *  Support decimal constants in behavioral delays.
- *
- * Revision 1.19  2000/06/30 15:50:20  steve
- *  Allow unary operators in constant expressions.
- *
- * Revision 1.18  2000/05/07 04:37:55  steve
- *  Carry strength values from Verilog source to the
- *  pform and netlist for gates.
- *
- *  Change vvm constants to use the driver_t to drive
- *  a constant value. This works better if there are
- *  multiple drivers on a signal.
- *
- * Revision 1.17  2000/05/04 03:37:58  steve
- *  Add infrastructure for system functions, move
- *  $time to that structure and add $random.
- *
- * Revision 1.16  2000/04/12 04:23:57  steve
- *  Named events really should be expressed with PEIdent
- *  objects in the pform,
- *
- *  Handle named events within the mix of net events
- *  and edges. As a unified lot they get caught together.
- *  wait statements are broken into more complex statements
- *  that include a conditional.
- *
- *  Do not generate NetPEvent or NetNEvent objects in
- *  elaboration. NetEvent, NetEvWait and NetEvProbe
- *  take over those functions in the netlist.
- *
- * Revision 1.15  2000/04/01 19:31:57  steve
- *  Named events as far as the pform.
- *
- * Revision 1.14  2000/03/12 18:22:11  steve
- *  Binary and unary operators in parameter expressions.
- *
- * Revision 1.13  2000/02/23 02:56:53  steve
- *  Macintosh compilers do not support ident.
- *
- * Revision 1.12  1999/12/31 17:38:37  steve
- *  Standardize some of the error messages.
- *
- * Revision 1.11  1999/10/31 04:11:27  steve
- *  Add to netlist links pin name and instance number,
- *  and arrange in vvm for pin connections by name
- *  and instance number.
- *
- * Revision 1.10  1999/09/25 02:57:29  steve
- *  Parse system function calls.
- *
- * Revision 1.9  1999/09/16 04:18:15  steve
- *  elaborate concatenation repeats.
- *
- * Revision 1.8  1999/09/15 04:17:52  steve
- *  separate assign lval elaboration for error checking.
- *
- * Revision 1.7  1999/07/22 02:05:20  steve
- *  is_constant method for PEConcat.
- *
- * Revision 1.6  1999/07/17 19:50:59  steve
- *  netlist support for ternary operator.
- *
- * Revision 1.5  1999/06/16 03:13:29  steve
- *  More syntax parse with sorry stubs.
- *
- * Revision 1.4  1999/06/10 04:03:52  steve
- *  Add support for the Ternary operator,
- *  Add support for repeat concatenation,
- *  Correct some seg faults cause by elaboration
- *  errors,
- *  Parse the casex anc casez statements.
- *
- * Revision 1.3  1999/05/16 05:08:42  steve
- *  Redo constant expression detection to happen
- *  after parsing.
- *
- *  Parse more operators and expressions.
- *
- * Revision 1.2  1998/11/11 00:01:51  steve
- *  Check net ranges in declarations.
- *
- * Revision 1.1  1998/11/03 23:28:53  steve
- *  Introduce verilog to CVS.
- *
- */
-
@@ -1,812 +0,0 @@
-#ifndef __PExpr_H
-#define __PExpr_H
-/*
- * Copyright (c) 1998-2000 Stephen Williams <[email protected]>
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: PExpr.h,v 1.90 2007/06/04 19:14:06 steve Exp $"
-#endif
-
-# include  <string>
-# include  <vector>
-# include  "netlist.h"
-# include  "verinum.h"
-# include  "LineInfo.h"
-# include  "pform_types.h"
-
-class Design;
-class Module;
-class NetNet;
-class NetExpr;
-class NetScope;
-
-/*
- * The PExpr class hierarchy supports the description of
- * expressions. The parser can generate expression objects from the
- * source, possibly reducing things that it knows how to reduce.
- *
- * The elaborate_net method is used by structural elaboration to build
- * up a netlist interpretation of the expression.
- */
-
-class PExpr : public LineInfo {
-
-    public:
-      PExpr();
-      virtual ~PExpr();
-
-      virtual void dump(ostream&) const;
-
-	// This method tests the width that the expression wants to
-	// be. It is used by elaboration of assignments to figure out
-	// the width of the expression.
-	//
-	// The "min" is the width of the local context, so it the
-	// minimum width that this function should return. Initially
-	// this is the same as the lval width.
-	//
-	// The "lval" is the width of the destination where this
-	// result is going to go. This can be used to constrain the
-	// amount that an expression can reasonably expand. For
-	// example, there is no point expanding an addition to beyond
-	// the lval. This extra bit of information allows the
-	// expression to optimize itself a bit. If the lval==0, then
-	// the subexpression should not make l-value related
-	// optimizations.
-	//
-	// The unsigned_flag is set to true if the expression is
-	// unsized and therefore expandable. This happens if a
-	// sub-expression is an unsized literal. Some expressions make
-	// special use of that.
-      virtual unsigned test_width(Design*des, NetScope*scope,
-				  unsigned min, unsigned lval,
-				  bool&unsized_flag) const;
-
-	// Procedural elaboration of the expression. The expr_width is
-	// the width of the context of the expression (i.e. the
-	// l-value width of an assignment) or -1 if the expression is
-	// self-determinted. The sys_task_arg flag is true if
-	// expressions are allowed to be incomplete.
-      virtual NetExpr*elaborate_expr(Design*des, NetScope*scope,
-				     int expr_width, bool sys_task_arg) const;
-
-	// Elaborate expressions that are the r-value of parameter
-	// assignments. This elaboration follows the restrictions of
-	// constant expressions and supports later overriding and
-	// evaluation of parameters.
-      virtual NetExpr*elaborate_pexpr(Design*des, NetScope*sc) const;
-
-	// This method elaborate the expression as gates, for use in a
-	// continuous assign or other wholly structural context.
-      virtual NetNet* elaborate_net(Design*des, NetScope*scope,
-				    unsigned lwidth,
-				    const NetExpr* rise,
-				    const NetExpr* fall,
-				    const NetExpr* decay,
-				    Link::strength_t drive0 =Link::STRONG,
-				    Link::strength_t drive1 =Link::STRONG)
-	    const;
-
-	// This method elaborates the expression as gates, but
-	// restricted for use as l-values of continuous assignments.
-      virtual NetNet* elaborate_lnet(Design*des, NetScope*scope,
-				     bool implicit_net_ok =false) const;
-
-	// This is similar to elaborate_lnet, except that the
-	// expression is evaluated to be bi-directional. This is
-	// useful for arguments to inout ports of module instances and
-	// ports of tran primitives.
-      virtual NetNet* elaborate_bi_net(Design*des, NetScope*scope) const;
-
-	// Expressions that can be in the l-value of procedural
-	// assignments can be elaborated with this method. If the
-	// is_force flag is true, then the set of valid l-value types
-	// is slightly modified to accomodate the Verilog force
-	// statement
-      virtual NetAssign_* elaborate_lval(Design*des,
-					 NetScope*scope,
-					 bool is_force) const;
-
-	// This attempts to evaluate a constant expression, and return
-	// a verinum as a result. If the expression cannot be
-	// evaluated, return 0.
-      virtual verinum* eval_const(Design*des, NetScope*sc) const;
-
-	// This method returns true if that expression is the same as
-	// this expression. This method is used for comparing
-	// expressions that must be structurally "identical".
-      virtual bool is_the_same(const PExpr*that) const;
-
-	// Return true if this expression is a valid constant
-	// expression. the Module pointer is needed to find parameter
-	// identifiers and any other module specific interpretations
-	// of expressions.
-      virtual bool is_constant(Module*) const;
-
-    private: // not implemented
-      PExpr(const PExpr&);
-      PExpr& operator= (const PExpr&);
-};
-
-ostream& operator << (ostream&, const PExpr&);
-
-class PEConcat : public PExpr {
-
-    public:
-      PEConcat(const svector<PExpr*>&p, PExpr*r =0);
-      ~PEConcat();
-
-      virtual verinum* eval_const(Design*des, NetScope*sc) const;
-      virtual void dump(ostream&) const;
-
-      virtual NetNet* elaborate_lnet(Design*des, NetScope*scope,
-				     bool implicit_net_ok =false) const;
-      virtual NetNet* elaborate_bi_net(Design*des, NetScope*scope) const;
-      virtual NetNet* elaborate_net(Design*des, NetScope*scope,
-				    unsigned width,
-				    const NetExpr* rise,
-				    const NetExpr* fall,
-				    const NetExpr* decay,
-				    Link::strength_t drive0,
-				    Link::strength_t drive1) const;
-      virtual NetExpr*elaborate_expr(Design*des, NetScope*,
-				     int expr_width, bool sys_task_arg) const;
-      virtual NetEConcat*elaborate_pexpr(Design*des, NetScope*) const;
-      virtual NetAssign_* elaborate_lval(Design*des,
-					 NetScope*scope,
-					 bool is_force) const;
-      virtual bool is_constant(Module*) const;
-
-    private:
-      NetNet* elaborate_lnet_common_(Design*des, NetScope*scope,
-				     bool implicit_net_ok,
-				     bool bidirectional_flag) const;
-    private:
-      svector<PExpr*>parms_;
-      PExpr*repeat_;
-};
-
-/*
- * Event expressions are expressions that can be combined with the
- * event "or" operator. These include "posedge foo" and similar, and
- * also include named events. "edge" events are associated with an
- * expression, whereas named events simply have a name, which
- * represents an event variable.
- */
-class PEEvent : public PExpr {
-
-    public:
-      enum edge_t {ANYEDGE, POSEDGE, NEGEDGE, POSITIVE};
-
-	// Use this constructor to create events based on edges or levels.
-      PEEvent(edge_t t, PExpr*e);
-
-      ~PEEvent();
-
-      edge_t type() const;
-      PExpr* expr() const;
-
-      virtual void dump(ostream&) const;
-
-    private:
-      edge_t type_;
-      PExpr *expr_;
-};
-
-/*
- * This holds a floating point constant in the source.
- */
-class PEFNumber : public PExpr {
-
-    public:
-      explicit PEFNumber(verireal*vp);
-      ~PEFNumber();
-
-      const verireal& value() const;
-
-	/* The eval_const method as applied to a floating point number
-	   gets the *integer* value of the number. This accounts for
-	   any rounding that is needed to get the value. */
-      virtual verinum* eval_const(Design*des, NetScope*sc) const;
-
-	/* A PEFNumber is a constant, so this returns true. */
-      virtual bool is_constant(Module*) const;
-
-      virtual NetExpr*elaborate_expr(Design*des, NetScope*,
-				     int expr_width, bool sys_task_arg) const;
-      virtual NetExpr*elaborate_pexpr(Design*des, NetScope*sc) const;
-
-      virtual NetNet* elaborate_net(Design*des, NetScope*scope,
-				    unsigned lwidth,
-				    const NetExpr* rise,
-				    const NetExpr* fall,
-				    const NetExpr* decay,
-				    Link::strength_t drive0,
-				    Link::strength_t drive1) const;
-
-      virtual void dump(ostream&) const;
-
-    private:
-      verireal*value_;
-};
-
-class PEIdent : public PExpr {
-
-    public:
-      explicit PEIdent(perm_string);
-      explicit PEIdent(const pform_name_t&);
-      ~PEIdent();
-
-	// Add another name to the string of heirarchy that is the
-	// current identifier.
-      void append_name(perm_string);
-
-      virtual void dump(ostream&) const;
-      virtual unsigned test_width(Design*des, NetScope*scope,
-				  unsigned min, unsigned lval,
-				  bool&unsized_flag) const;
-
-	// Identifiers are allowed (with restrictions) is assign l-values.
-      virtual NetNet* elaborate_lnet(Design*des, NetScope*scope,
-				     bool implicit_net_ok =false) const;
-
-      virtual NetNet* elaborate_bi_net(Design*des, NetScope*scope) const;
-
-	// Identifiers are also allowed as procedural assignment l-values.
-      virtual NetAssign_* elaborate_lval(Design*des,
-					 NetScope*scope,
-					 bool is_force) const;
-
-	// Structural r-values are OK.
-      virtual NetNet* elaborate_net(Design*des, NetScope*scope,
-				    unsigned lwidth,
-				    const NetExpr* rise,
-				    const NetExpr* fall,
-				    const NetExpr* decay,
-				    Link::strength_t drive0,
-				    Link::strength_t drive1) const;
-
-      virtual NetExpr*elaborate_expr(Design*des, NetScope*,
-				     int expr_width, bool sys_task_arg) const;
-      virtual NetExpr*elaborate_pexpr(Design*des, NetScope*sc) const;
-
-	// Elaborate the PEIdent as a port to a module. This method
-	// only applies to Ident expressions.
-      NetNet* elaborate_port(Design*des, NetScope*sc) const;
-
-      virtual bool is_constant(Module*) const;
-      verinum* eval_const(Design*des, NetScope*sc) const;
-
-      const pform_name_t& path() const { return path_; }
-
-    private:
-      pform_name_t path_;
-
-    private:
-	// Common functions to calculate parts of part/bit selects.
-      bool calculate_parts_(Design*, NetScope*, long&msb, long&lsb) const;
-      bool calculate_up_do_width_(Design*, NetScope*, unsigned long&wid) const;
-
-    private:
-      NetAssign_*elaborate_lval_net_word_(Design*, NetScope*, NetNet*) const;
-      bool elaborate_lval_net_part_(Design*, NetScope*, NetAssign_*) const;
-      bool elaborate_lval_net_idx_up_(Design*, NetScope*, NetAssign_*) const;
-      bool elaborate_lval_net_idx_do_(Design*, NetScope*, NetAssign_*) const;
-
-    private:
-      NetExpr*elaborate_expr_param(Design*des,
-				   NetScope*scope,
-				   const NetExpr*par,
-				   NetScope*found,
-				   const NetExpr*par_msb,
-				   const NetExpr*par_lsb) const;
-      NetExpr*elaborate_expr_net(Design*des,
-				 NetScope*scope,
-				 NetNet*net,
-				 NetScope*found,
-				 bool sys_task_arg) const;
-      NetExpr*elaborate_expr_net_word_(Design*des,
-				       NetScope*scope,
-				       NetNet*net,
-				       NetScope*found,
-				       bool sys_task_arg) const;
-      NetExpr*elaborate_expr_net_part_(Design*des,
-				   NetScope*scope,
-				   NetESignal*net,
-				   NetScope*found) const;
-      NetExpr*elaborate_expr_net_idx_up_(Design*des,
-				   NetScope*scope,
-				   NetESignal*net,
-				   NetScope*found) const;
-      NetExpr*elaborate_expr_net_idx_do_(Design*des,
-				   NetScope*scope,
-				   NetESignal*net,
-				   NetScope*found) const;
-      NetExpr*elaborate_expr_net_bit_(Design*des,
-				   NetScope*scope,
-				   NetESignal*net,
-				   NetScope*found) const;
-
-    public:
-
-      NetNet* elaborate_net_array_(Design*des, NetScope*scope,
-				   NetNet*sig, unsigned lwidth,
-				   const NetExpr* rise,
-				   const NetExpr* fall,
-				   const NetExpr* decay,
-				   Link::strength_t drive0,
-				   Link::strength_t drive1) const;
-
-      NetNet* elaborate_net_bitmux_(Design*des, NetScope*scope,
-				    NetNet*sig,
-				    const NetExpr* rise,
-				    const NetExpr* fall,
-				    const NetExpr* decay,
-				    Link::strength_t drive0,
-				    Link::strength_t drive1) const;
-
-    private:
-      NetNet* elaborate_lnet_common_(Design*des, NetScope*scope,
-				     bool implicit_net_ok,
-				     bool bidirectional_flag) const;
-
-      NetNet*make_implicit_net_(Design*des, NetScope*scope) const;
-
-      bool eval_part_select_(Design*des, NetScope*scope, NetNet*sig,
-			     unsigned&midx, unsigned&lidx) const;
-      NetNet*process_select_(Design*des, NetScope*scope, NetNet*sig) const;
-
-};
-
-class PENumber : public PExpr {
-
-    public:
-      explicit PENumber(verinum*vp);
-      ~PENumber();
-
-      const verinum& value() const;
-
-      virtual void dump(ostream&) const;
-      virtual unsigned test_width(Design*des, NetScope*scope,
-				  unsigned min, unsigned lval,
-				  bool&unsized_flag) const;
-
-      virtual NetNet* elaborate_net(Design*des, NetScope*scope,
-				    unsigned lwidth,
-				    const NetExpr* rise,
-				    const NetExpr* fall,
-				    const NetExpr* decay,
-				    Link::strength_t drive0,
-				    Link::strength_t drive1) const;
-      virtual NetEConst*elaborate_expr(Design*des, NetScope*,
-				       int expr_width, bool) const;
-      virtual NetExpr*elaborate_pexpr(Design*des, NetScope*sc) const;
-      virtual NetAssign_* elaborate_lval(Design*des,
-					 NetScope*scope,
-					 bool is_force) const;
-
-      virtual verinum* eval_const(Design*des, NetScope*sc) const;
-
-      virtual bool is_the_same(const PExpr*that) const;
-      virtual bool is_constant(Module*) const;
-
-    private:
-      verinum*const value_;
-};
-
-/*
- * This represents a string constant in an expression.
- *
- * The s parameter to the PEString constructor is a C string that this
- * class instance will take for its own. The caller should not delete
- * the string, the destructor will do it.
- */
-class PEString : public PExpr {
-
-    public:
-      explicit PEString(char*s);
-      ~PEString();
-
-      string value() const;
-      virtual void dump(ostream&) const;
-
-      virtual unsigned test_width(Design*des, NetScope*scope,
-				  unsigned min, unsigned lval,
-				  bool&unsized_flag) const;
-
-      virtual NetNet* elaborate_net(Design*des, NetScope*scope,
-				    unsigned width,
-				    const NetExpr* rise,
-				    const NetExpr* fall,
-				    const NetExpr* decay,
-				    Link::strength_t drive0,
-				    Link::strength_t drive1) const;
-      virtual NetEConst*elaborate_expr(Design*des, NetScope*,
-				       int expr_width, bool) const;
-      virtual NetEConst*elaborate_pexpr(Design*des, NetScope*sc) const;
-      verinum* eval_const(Design*, NetScope*) const;
-
-      virtual bool is_constant(Module*) const;
-
-    private:
-      char*text_;
-};
-
-class PEUnary : public PExpr {
-
-    public:
-      explicit PEUnary(char op, PExpr*ex);
-      ~PEUnary();
-
-      virtual void dump(ostream&out) const;
-
-      virtual NetNet* elaborate_net(Design*des, NetScope*scope,
-				    unsigned width,
-				    const NetExpr* rise,
-				    const NetExpr* fall,
-				    const NetExpr* decay,
-				    Link::strength_t drive0,
-				    Link::strength_t drive1) const;
-      virtual NetExpr*elaborate_expr(Design*des, NetScope*,
-				     int expr_width, bool sys_task_arg) const;
-      virtual NetExpr*elaborate_pexpr(Design*des, NetScope*sc) const;
-      virtual verinum* eval_const(Design*des, NetScope*sc) const;
-
-      virtual bool is_constant(Module*) const;
-
-    private:
-      char op_;
-      PExpr*expr_;
-};
-
-class PEBinary : public PExpr {
-
-    public:
-      explicit PEBinary(char op, PExpr*l, PExpr*r);
-      ~PEBinary();
-
-      virtual bool is_constant(Module*) const;
-
-      virtual void dump(ostream&out) const;
-
-      virtual unsigned test_width(Design*des, NetScope*scope,
-				  unsigned min, unsigned lval,
-				  bool&unsized_flag) const;
-
-      virtual NetNet* elaborate_net(Design*des, NetScope*scope,
-				    unsigned width,
-				    const NetExpr* rise,
-				    const NetExpr* fall,
-				    const NetExpr* decay,
-				    Link::strength_t drive0,
-				    Link::strength_t drive1) const;
-      virtual NetEBinary*elaborate_expr(Design*des, NetScope*,
-					int expr_width, bool sys_task_arg) const;
-      virtual NetExpr*elaborate_pexpr(Design*des, NetScope*sc) const;
-      virtual verinum* eval_const(Design*des, NetScope*sc) const;
-
-    protected:
-      char op_;
-      PExpr*left_;
-      PExpr*right_;
-
-      NetEBinary*elaborate_expr_base_(Design*, NetExpr*lp, NetExpr*rp, int use_wid) const;
-      NetEBinary*elaborate_eval_expr_base_(Design*, NetExpr*lp, NetExpr*rp, int use_wid) const;
-
-    private:
-      NetNet* elaborate_net_add_(Design*des, NetScope*scope,
-				 unsigned lwidth,
-				 const NetExpr* rise,
-				 const NetExpr* fall,
-				 const NetExpr* decay) const;
-      NetNet* elaborate_net_bit_(Design*des, NetScope*scope,
-				 unsigned lwidth,
-				 const NetExpr* rise,
-				 const NetExpr* fall,
-				 const NetExpr* decay) const;
-      NetNet* elaborate_net_cmp_(Design*des, NetScope*scope,
-				 unsigned lwidth,
-				 const NetExpr* rise,
-				 const NetExpr* fall,
-				 const NetExpr* decay) const;
-      NetNet* elaborate_net_div_(Design*des, NetScope*scope,
-				 unsigned lwidth,
-				 const NetExpr* rise,
-				 const NetExpr* fall,
-				 const NetExpr* decay) const;
-      NetNet* elaborate_net_mod_(Design*des, NetScope*scope,
-				 unsigned lwidth,
-				 const NetExpr* rise,
-				 const NetExpr* fall,
-				 const NetExpr* decay) const;
-      NetNet* elaborate_net_log_(Design*des, NetScope*scope,
-				 unsigned lwidth,
-				 const NetExpr* rise,
-				 const NetExpr* fall,
-				 const NetExpr* decay) const;
-      NetNet* elaborate_net_mul_(Design*des, NetScope*scope,
-				 unsigned lwidth,
-				 const NetExpr* rise,
-				 const NetExpr* fall,
-				 const NetExpr* decay) const;
-      NetNet* elaborate_net_shift_(Design*des, NetScope*scope,
-				   unsigned lwidth,
-				   const NetExpr* rise,
-				   const NetExpr* fall,
-				   const NetExpr* decay) const;
-};
-
-/*
- * Here are a few specilized classes for handling specific binary
- * operators.
- */
-class PEBComp  : public PEBinary {
-
-    public:
-      explicit PEBComp(char op, PExpr*l, PExpr*r);
-      ~PEBComp();
-
-      virtual unsigned test_width(Design*des, NetScope*scope,
-				  unsigned min, unsigned lval,
-				  bool&flag) const;
-
-      NetEBinary* elaborate_expr(Design*des, NetScope*scope,
-				 int expr_width, bool sys_task_arg) const;
-};
-
-class PEBShift  : public PEBinary {
-
-    public:
-      explicit PEBShift(char op, PExpr*l, PExpr*r);
-      ~PEBShift();
-
-      virtual unsigned test_width(Design*des, NetScope*scope,
-				  unsigned min, unsigned lval, bool&flag) const;
-};
-
-/*
- * This class supports the ternary (?:) operator. The operator takes
- * three expressions, the test, the true result and the false result.
- */
-class PETernary : public PExpr {
-
-    public:
-      explicit PETernary(PExpr*e, PExpr*t, PExpr*f);
-      ~PETernary();
-
-      virtual bool is_constant(Module*) const;
-
-      virtual void dump(ostream&out) const;
-      virtual unsigned test_width(Design*des, NetScope*scope,
-				  unsigned min, unsigned lval,
-				  bool&unsized_flag) const;
-
-      virtual NetNet* elaborate_net(Design*des, NetScope*scope,
-				    unsigned width,
-				    const NetExpr* rise,
-				    const NetExpr* fall,
-				    const NetExpr* decay,
-				    Link::strength_t drive0,
-				    Link::strength_t drive1) const;
-      virtual NetETernary*elaborate_expr(Design*des, NetScope*,
-					 int expr_width, bool sys_task_arg) const;
-      virtual NetETernary*elaborate_pexpr(Design*des, NetScope*sc) const;
-      virtual verinum* eval_const(Design*des, NetScope*sc) const;
-
-    private:
-      PExpr*expr_;
-      PExpr*tru_;
-      PExpr*fal_;
-};
-
-/*
- * This class represents a parsed call to a function, including calls
- * to system functions. The parameters in the parms list are the
- * expressions that are passed as input to the ports of the function.
- */
-class PECallFunction : public PExpr {
-    public:
-      explicit PECallFunction(const pform_name_t&n, const svector<PExpr *> &parms);
-	// Call of system function (name is not heirarchical)
-      explicit PECallFunction(perm_string n, const svector<PExpr *> &parms);
-      explicit PECallFunction(perm_string n);
-      ~PECallFunction();
-
-      virtual void dump(ostream &) const;
-
-      virtual NetNet* elaborate_net(Design*des, NetScope*scope,
-				    unsigned width,
-				    const NetExpr* rise,
-				    const NetExpr* fall,
-				    const NetExpr* decay,
-				    Link::strength_t drive0,
-				    Link::strength_t drive1) const;
-      virtual NetExpr*elaborate_expr(Design*des, NetScope*scope,
-				     int expr_wid, bool sys_task_arg) const;
-
-    private:
-      pform_name_t path_;
-      svector<PExpr *> parms_;
-
-      bool check_call_matches_definition_(Design*des, NetScope*dscope) const;
-
-      NetExpr* elaborate_sfunc_(Design*des, NetScope*scope) const;
-      NetNet* elaborate_net_sfunc_(Design*des, NetScope*scope,
-				   unsigned width,
-				   const NetExpr* rise,
-				   const NetExpr* fall,
-				   const NetExpr* decay,
-				   Link::strength_t drive0,
-				   Link::strength_t drive1) const;
-};
-
-/*
- * $Log: PExpr.h,v $
- * Revision 1.90  2007/06/04 19:14:06  steve
- *  Build errors in picky GCC compilers.
- *
- * Revision 1.89  2007/06/04 02:19:07  steve
- *  Handle bit/part select of array words in nets.
- *
- * Revision 1.88  2007/05/24 04:07:11  steve
- *  Rework the heirarchical identifier parse syntax and pform
- *  to handle more general combinations of heirarch and bit selects.
- *
- * Revision 1.87  2007/01/16 05:44:14  steve
- *  Major rework of array handling. Memories are replaced with the
- *  more general concept of arrays. The NetMemory and NetEMemory
- *  classes are removed from the ivl core program, and the IVL_LPM_RAM
- *  lpm type is removed from the ivl_target API.
- *
- * Revision 1.86  2006/11/10 04:54:26  steve
- *  Add test_width methods for PETernary and PEString.
- *
- * Revision 1.85  2006/11/04 06:19:24  steve
- *  Remove last bits of relax_width methods, and use test_width
- *  to calculate the width of an r-value expression that may
- *  contain unsized numbers.
- *
- * Revision 1.84  2006/10/30 05:44:49  steve
- *  Expression widths with unsized literals are pseudo-infinite width.
- *
- * Revision 1.83  2006/06/18 04:15:50  steve
- *  Add support for system functions in continuous assignments.
- *
- * Revision 1.82  2006/06/02 04:48:49  steve
- *  Make elaborate_expr methods aware of the width that the context
- *  requires of it. In the process, fix sizing of the width of unary
- *  minus is context determined sizes.
- *
- * Revision 1.81  2006/04/28 04:28:35  steve
- *  Allow concatenations as arguments to inout ports.
- *
- * Revision 1.80  2006/04/16 00:54:04  steve
- *  Cleanup lval part select handling.
- *
- * Revision 1.79  2006/04/16 00:15:43  steve
- *  Fix part selects in l-values.
- *
- * Revision 1.78  2006/03/25 02:36:26  steve
- *  Get rid of excess PESTring:: prefix within class declaration.
- *
- * Revision 1.77  2006/02/02 02:43:57  steve
- *  Allow part selects of memory words in l-values.
- *
- * Revision 1.76  2006/01/02 05:33:19  steve
- *  Node delays can be more general expressions in structural contexts.
- *
- * Revision 1.75  2005/12/07 04:04:23  steve
- *  Allow constant concat expressions.
- *
- * Revision 1.74  2005/11/27 17:01:56  steve
- *  Fix for stubborn compiler.
- *
- * Revision 1.73  2005/11/27 05:56:20  steve
- *  Handle bit select of parameter with ranges.
- *
- * Revision 1.72  2005/11/10 13:28:11  steve
- *  Reorganize signal part select handling, and add support for
- *  indexed part selects.
- *
- *  Expand expression constant propagation to eliminate extra
- *  sums in certain cases.
- *
- * Revision 1.71  2005/10/04 04:09:25  steve
- *  Add support for indexed select attached to parameters.
- *
- * Revision 1.70  2005/08/06 17:58:16  steve
- *  Implement bi-directional part selects.
- *
- * Revision 1.69  2005/07/07 16:22:49  steve
- *  Generalize signals to carry types.
- *
- * Revision 1.68  2005/01/09 20:16:00  steve
- *  Use PartSelect/PV and VP to handle part selects through ports.
- *
- * Revision 1.67  2004/12/29 23:55:43  steve
- *  Unify elaboration of l-values for all proceedural assignments,
- *  including assing, cassign and force.
- *
- *  Generate NetConcat devices for gate outputs that feed into a
- *  vector results. Use this to hande gate arrays. Also let gate
- *  arrays handle vectors of gates when the outputs allow for it.
- *
- * Revision 1.66  2004/10/04 01:10:51  steve
- *  Clean up spurious trailing white space.
- *
- * Revision 1.65  2003/02/08 19:49:21  steve
- *  Calculate delay statement delays using elaborated
- *  expressions instead of pre-elaborated expression
- *  trees.
- *
- *  Remove the eval_pexpr methods from PExpr.
- *
- * Revision 1.64  2003/01/30 16:23:07  steve
- *  Spelling fixes.
- *
- * Revision 1.63  2002/11/09 19:20:48  steve
- *  Port expressions for output ports are lnets, not nets.
- *
- * Revision 1.62  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.61  2002/06/04 05:38:43  steve
- *  Add support for memory words in l-value of
- *  blocking assignments, and remove the special
- *  NetAssignMem class.
- *
- * Revision 1.60  2002/05/23 03:08:51  steve
- *  Add language support for Verilog-2001 attribute
- *  syntax. Hook this support into existing $attribute
- *  handling, and add number and void value types.
- *
- *  Add to the ivl_target API new functions for access
- *  of complex attributes attached to gates.
- *
- * Revision 1.59  2002/04/23 03:53:59  steve
- *  Add support for non-constant bit select.
- *
- * Revision 1.58  2002/04/14 03:55:25  steve
- *  Precalculate unary - if possible.
- *
- * Revision 1.57  2002/04/13 02:33:17  steve
- *  Detect missing indices to memories (PR#421)
- *
- * Revision 1.56  2002/03/09 04:02:26  steve
- *  Constant expressions are not l-values for task ports.
- *
- * Revision 1.55  2002/03/09 02:10:22  steve
- *  Add the NetUserFunc netlist node.
- *
- * Revision 1.54  2001/12/30 21:32:03  steve
- *  Support elaborate_net for PEString objects.
- *
- * Revision 1.53  2001/12/03 04:47:14  steve
- *  Parser and pform use hierarchical names as hname_t
- *  objects instead of encoded strings.
- *
- * Revision 1.52  2001/11/08 05:15:50  steve
- *  Remove string paths from PExpr elaboration.
- *
- * Revision 1.51  2001/11/07 04:26:46  steve
- *  elaborate_lnet uses scope instead of string path.
- *
- * Revision 1.50  2001/11/07 04:01:59  steve
- *  eval_const uses scope instead of a string path.
- */
-#endif
@@ -1,78 +0,0 @@
-/*
- * Copyright (c) 1999 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: PFunction.cc,v 1.7 2004/05/31 23:34:36 steve Exp $"
-#endif
-
-# include "config.h"
-
-#include "PTask.h"
-
-PFunction::PFunction(perm_string name)
-: name_(name), ports_(0), statement_(0)
-{
-      return_type_.type = PTF_NONE;
-}
-
-PFunction::~PFunction()
-{
-}
-
-void PFunction::set_ports(svector<PWire *>*p)
-{
-      assert(ports_ == 0);
-      ports_ = p;
-}
-
-void PFunction::set_statement(Statement*s)
-{
-      assert(s != 0);
-      assert(statement_ == 0);
-      statement_ = s;
-}
-
-void PFunction::set_return(PTaskFuncArg t)
-{
-      return_type_ = t;
-}
-
-/*
- * $Log: PFunction.cc,v $
- * Revision 1.7  2004/05/31 23:34:36  steve
- *  Rewire/generalize parsing an elaboration of
- *  function return values to allow for better
- *  speed and more type support.
- *
- * Revision 1.6  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.5  2001/07/25 03:10:48  steve
- *  Create a config.h.in file to hold all the config
- *  junk, and support gcc 3.0. (Stephan Boettcher)
- *
- * Revision 1.4  2001/01/13 22:20:08  steve
- *  Parse parameters within nested scopes.
- *
- * Revision 1.3  2000/02/23 02:56:53  steve
- *  Macintosh compilers do not support ident.
- *
- * Revision 1.2  1999/08/25 22:22:41  steve
- *  elaborate some aspects of functions.
- *
- */
@@ -1,313 +0,0 @@
-/*
- * Copyright (c) 1999-2004 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: PGate.cc,v 1.18 2006/01/03 05:22:14 steve Exp $"
-#endif
-
-# include "config.h"
-
-# include  "PGate.h"
-# include  "PExpr.h"
-# include  "verinum.h"
-# include  <assert.h>
-
-PGate::PGate(perm_string name,
-	     svector<PExpr*>*pins,
-	     const svector<PExpr*>*del)
-: name_(name), pins_(pins)
-{
-      if (del) delay_.set_delays(del);
-      str0_ = STRONG;
-      str1_ = STRONG;
-}
-
-PGate::PGate(perm_string name,
-	     svector<PExpr*>*pins,
-	     PExpr*del)
-: name_(name), pins_(pins)
-{
-      if (del) delay_.set_delay(del);
-      str0_ = STRONG;
-      str1_ = STRONG;
-}
-
-PGate::PGate(perm_string name, svector<PExpr*>*pins)
-: name_(name), pins_(pins)
-{
-      str0_ = STRONG;
-      str1_ = STRONG;
-}
-
-PGate::~PGate()
-{
-}
-
-PGate::strength_t PGate::strength0() const
-{
-      return str0_;
-}
-
-void PGate::strength0(PGate::strength_t s)
-{
-      str0_ = s;
-}
-
-PGate::strength_t PGate::strength1() const
-{
-      return str1_;
-}
-
-void PGate::strength1(PGate::strength_t s)
-{
-      str1_ = s;
-}
-
-void PGate::elaborate_scope(Design*, NetScope*) const
-{
-}
-
-/*
- * This method is used during elaboration to calculate the
- * rise/fall/decay times for the gate. These values were set in pform
- * by the constructor, so here I evaluate the expression in the given
- * design context and save the calculated delays into the output
- * parameters. This method understands how to handle the different
- * numbers of expressions.
- */
-
-void PGate::eval_delays(Design*des, NetScope*scope,
-			NetExpr*&rise_expr,
-			NetExpr*&fall_expr,
-			NetExpr*&decay_expr,
-			bool as_net_flag) const
-{
-      delay_.eval_delays(des, scope,
-			 rise_expr, fall_expr, decay_expr,
-			 as_net_flag);
-}
-
-void PGate::eval_delays(Design*des, NetScope*scope,
-			unsigned long&rise_time,
-			unsigned long&fall_time,
-			unsigned long&decay_time) const
-{
-      NetExpr*rise_expr, *fall_expr, *decay_expr;
-      delay_.eval_delays(des, scope, rise_expr, fall_expr, decay_expr);
-
-      if (rise_expr == 0) {
-	    rise_time = 0;
-	    fall_time = 0;
-	    decay_time = 0;
-      }
-
-      if (NetEConst*tmp = dynamic_cast<NetEConst*> (rise_expr)) {
-	    rise_time = tmp->value().as_ulong();
-
-      } else {
-	    cerr << get_line() << ": error: Delay expressions must be "
-		 << "constant here." << endl;
-	    cerr << get_line() << ":      : Cannot calculate "
-		 << *rise_expr << endl;
-	    des->errors += 1;
-	    rise_time = 0;
-      }
-
-      if (NetEConst*tmp = dynamic_cast<NetEConst*> (fall_expr)) {
-	    fall_time = tmp->value().as_ulong();
-
-      } else {
-	    if (fall_expr != rise_expr) {
-		  cerr << get_line() << ": error: Delay expressions must be "
-		       << "constant here." << endl;
-		  cerr << get_line() << ":      : Cannot calculate "
-		       << *rise_expr << endl;
-	    }
-	    des->errors += 1;
-	    fall_time = 0;
-      }
-
-      if (NetEConst*tmp = dynamic_cast<NetEConst*> (decay_expr)) {
-	    decay_time = tmp->value().as_ulong();
-
-      } else {
-	    cerr << get_line() << ": error: Delay expressions must be "
-		 << "constant here." << endl;
-	    cerr << get_line() << ":      : Cannot calculate "
-		 << *rise_expr << endl;
-	    des->errors += 1;
-	    decay_time = 0;
-      }
-}
-
-PGAssign::PGAssign(svector<PExpr*>*pins)
-: PGate(perm_string(), pins)
-{
-      assert(pins->count() == 2);
-}
-
-PGAssign::PGAssign(svector<PExpr*>*pins, svector<PExpr*>*dels)
-: PGate(perm_string(), pins, dels)
-{
-      assert(pins->count() == 2);
-}
-
-PGAssign::~PGAssign()
-{
-}
-
-PGBuiltin::PGBuiltin(Type t, perm_string name,
-		     svector<PExpr*>*pins,
-		     svector<PExpr*>*del)
-: PGate(name, pins, del), type_(t), msb_(0), lsb_(0)
-{
-}
-
-PGBuiltin::PGBuiltin(Type t, perm_string name,
-		     svector<PExpr*>*pins,
-		     PExpr*del)
-: PGate(name, pins, del), type_(t), msb_(0), lsb_(0)
-{
-}
-
-
-PGBuiltin::~PGBuiltin()
-{
-}
-
-void PGBuiltin::set_range(PExpr*msb, PExpr*lsb)
-{
-      assert(msb_ == 0);
-      assert(lsb_ == 0);
-
-      msb_ = msb;
-      lsb_ = lsb;
-}
-
-PGModule::PGModule(perm_string type, perm_string name, svector<PExpr*>*pins)
-: PGate(name, pins), overrides_(0), pins_(0),
-  npins_(0), parms_(0), nparms_(0), msb_(0), lsb_(0)
-{
-      type_ = type;
-}
-
-PGModule::PGModule(perm_string type, perm_string name,
-		   named<PExpr*>*pins, unsigned npins)
-: PGate(name, 0), overrides_(0), pins_(pins),
-  npins_(npins), parms_(0), nparms_(0), msb_(0), lsb_(0)
-{
-      type_ = type;
-}
-
-PGModule::~PGModule()
-{
-}
-
-void PGModule::set_parameters(svector<PExpr*>*o)
-{
-      assert(overrides_ == 0);
-      overrides_ = o;
-}
-
-void PGModule::set_parameters(named<PExpr*>*pa, unsigned npa)
-{
-      assert(parms_ == 0);
-      assert(overrides_ == 0);
-      parms_ = pa;
-      nparms_ = npa;
-}
-
-void PGModule::set_range(PExpr*msb, PExpr*lsb)
-{
-      assert(msb_ == 0);
-      assert(lsb_ == 0);
-
-      msb_ = msb;
-      lsb_ = lsb;
-}
-
-perm_string PGModule::get_type()
-{
-      return type_;
-}
-
-/*
- * $Log: PGate.cc,v $
- * Revision 1.18  2006/01/03 05:22:14  steve
- *  Handle complex net node delays.
- *
- * Revision 1.17  2006/01/02 05:33:19  steve
- *  Node delays can be more general expressions in structural contexts.
- *
- * Revision 1.16  2004/02/18 17:11:54  steve
- *  Use perm_strings for named langiage items.
- *
- * Revision 1.15  2003/03/06 04:37:12  steve
- *  lex_strings.add module names earlier.
- *
- * Revision 1.14  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.13  2001/11/22 06:20:59  steve
- *  Use NetScope instead of string for scope path.
- *
- * Revision 1.12  2001/10/21 00:42:47  steve
- *  Module types in pform are char* instead of string.
- *
- * Revision 1.11  2001/10/19 01:55:32  steve
- *  Method to get the type_ member
- *
- * Revision 1.10  2001/07/25 03:10:48  steve
- *  Create a config.h.in file to hold all the config
- *  junk, and support gcc 3.0. (Stephan Boettcher)
- *
- * Revision 1.9  2000/05/06 15:41:56  steve
- *  Carry assignment strength to pform.
- *
- * Revision 1.8  2000/03/08 04:36:53  steve
- *  Redesign the implementation of scopes and parameters.
- *  I now generate the scopes and notice the parameters
- *  in a separate pass over the pform. Once the scopes
- *  are generated, I can process overrides and evalutate
- *  paremeters before elaboration begins.
- *
- * Revision 1.7  2000/02/23 02:56:53  steve
- *  Macintosh compilers do not support ident.
- *
- * Revision 1.6  2000/02/18 05:15:02  steve
- *  Catch module instantiation arrays.
- *
- * Revision 1.5  1999/09/14 01:50:35  steve
- *  Handle gates without delays.
- *
- * Revision 1.4  1999/09/04 19:11:46  steve
- *  Add support for delayed non-blocking assignments.
- *
- * Revision 1.3  1999/08/01 21:18:55  steve
- *  elaborate rise/fall/decay for continuous assign.
- *
- * Revision 1.2  1999/08/01 16:34:50  steve
- *  Parse and elaborate rise/fall/decay times
- *  for gates, and handle the rules for partial
- *  lists of times.
- *
- * Revision 1.1  1999/02/15 02:06:15  steve
- *  Elaborate gate ranges.
- *
- */
-
@@ -1,371 +0,0 @@
-#ifndef __PGate_H
-#define __PGate_H
-/*
- * Copyright (c) 1998-2004 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: PGate.h,v 1.32 2006/04/10 00:37:42 steve Exp $"
-#endif
-
-# include  "svector.h"
-# include  "StringHeap.h"
-# include  "named.h"
-# include  "LineInfo.h"
-# include  "PDelays.h"
-# include  <map>
-# include  <string>
-class PExpr;
-class PUdp;
-class Design;
-class NetScope;
-class Module;
-
-/*
- * A PGate represents a Verilog gate. The gate has a name and other
- * properties, and a set of pins that connect to wires. It is known at
- * the time a gate is constructed how many pins the gate has.
- *
- * This pins of a gate are connected to expressions. The elaboration
- * step will need to convert expressions to a network of gates in
- * order to elaborate expression inputs, but that can easily be done.
- *
- * The PGate base class also carries the strength0 and strength1
- * strengths for those gates where the driver[s] can be described by a
- * single strength pair. There is a strength of the 0 drive, and a
- * strength of the 1 drive.
- */
-class PGate : public LineInfo {
-
-    public:
-      enum strength_t { HIGHZ, WEAK, PULL, STRONG, SUPPLY };
-
-      explicit PGate(perm_string name, svector<PExpr*>*pins,
-		     const svector<PExpr*>*del);
-
-      explicit PGate(perm_string name, svector<PExpr*>*pins,
-		     PExpr*del);
-
-      explicit PGate(perm_string name, svector<PExpr*>*pins);
-
-      virtual ~PGate();
-
-      perm_string get_name() const { return name_; }
-
-	// This method evaluates the delays all the way to an
-	// integer. If the delay is non-constant, then set the times
-	// to 0, print an error message and mark an error to the
-	// design.
-      void eval_delays(Design*des, NetScope*scope,
-		       unsigned long&rise_time,
-		       unsigned long&fall_time,
-		       unsigned long&decay_time) const;
-
-	// This evaluates the delays as far as possible, but returns
-	// an expression, and do not signal errors.
-      void eval_delays(Design*des, NetScope*scope,
-		       NetExpr*&rise_time,
-		       NetExpr*&fall_time,
-		       NetExpr*&decay_time,
-		       bool as_net_flag =false) const;
-
-      unsigned pin_count() const { return pins_? pins_->count() : 0; }
-      const PExpr*pin(unsigned idx) const { return (*pins_)[idx]; }
-
-      strength_t strength0() const;
-      strength_t strength1() const;
-
-      void strength0(strength_t);
-      void strength1(strength_t);
-
-      map<perm_string,PExpr*> attributes;
-
-      virtual void dump(ostream&out, unsigned ind =4) const;
-      virtual void elaborate(Design*des, NetScope*scope) const;
-      virtual void elaborate_scope(Design*des, NetScope*sc) const;
-      virtual bool elaborate_sig(Design*des, NetScope*scope) const;
-
-    protected:
-      const svector<PExpr*>& get_pins() const { return *pins_; }
-
-      void dump_pins(ostream&out) const;
-      void dump_delays(ostream&out) const;
-
-    private:
-      perm_string name_;
-      PDelays delay_;
-      svector<PExpr*>*pins_;
-
-      strength_t str0_, str1_;
-
-    private: // not implemented
-      PGate(const PGate&);
-      PGate& operator= (const PGate&);
-};
-
-/* A continuous assignment has a single output and a single input. The
-   input is passed directly to the output. This is different from a
-   BUF because elaboration may need to turn this into a vector of
-   gates. */
-class PGAssign  : public PGate {
-
-    public:
-      explicit PGAssign(svector<PExpr*>*pins);
-      explicit PGAssign(svector<PExpr*>*pins, svector<PExpr*>*dels);
-      ~PGAssign();
-
-      void dump(ostream&out, unsigned ind =4) const;
-      virtual void elaborate(Design*des, NetScope*scope) const;
-
-    private:
-};
-
-
-/*
- * The Builtin class is specifically a gate with one of the builtin
- * types. The parser recognizes these types during parse. These types
- * have special properties that allow them to be treated specially.
- *
- * A PGBuiltin can be grouped into an array of devices. If this is
- * done, the msb_ and lsb_ are set to the indices of the array
- * range. Elaboration causes a gate to be created for each element of
- * the array, and a name will be generated for each gate.
- */
-class PGBuiltin  : public PGate {
-
-    public:
-      enum Type { AND, NAND, OR, NOR, XOR, XNOR, BUF, BUFIF0, BUFIF1,
-		  NOT, NOTIF0, NOTIF1, PULLDOWN, PULLUP, NMOS, RNMOS,
-		  PMOS, RPMOS, CMOS, RCMOS, TRAN, RTRAN, TRANIF0,
-		  TRANIF1, RTRANIF0, RTRANIF1 };
-
-    public:
-      explicit PGBuiltin(Type t, perm_string name,
-			 svector<PExpr*>*pins,
-			 svector<PExpr*>*del);
-      explicit PGBuiltin(Type t, perm_string name,
-			 svector<PExpr*>*pins,
-			 PExpr*del);
-      ~PGBuiltin();
-
-      Type type() const { return type_; }
-      void set_range(PExpr*msb, PExpr*lsb);
-
-      virtual void dump(ostream&out, unsigned ind =4) const;
-      virtual void elaborate(Design*, NetScope*scope) const;
-
-    private:
-      Type type_;
-
-      PExpr*msb_;
-      PExpr*lsb_;
-};
-
-/*
- * This kind of gate is an instantiation of a module. The stored type
- * is the name of a module definition somewhere in the pform. This
- * type also handles UDP devices, because it is generally not known at
- * parse time whether a name belongs to a module or a UDP.
- */
-class PGModule  : public PGate {
-
-    public:
-	// The name is the *instance* name of the gate.
-
-	// If the binding of ports is by position, this constructor
-	// builds everything all at once.
-      explicit PGModule(perm_string type, perm_string name,
-			svector<PExpr*>*pins);
-
-	// If the binding of ports is by name, this constructor takes
-	// the bindings and stores them for later elaboration.
-      explicit PGModule(perm_string type, perm_string name,
-			named<PExpr*>*pins, unsigned npins);
-
-
-      ~PGModule();
-
-	// Parameter overrides can come as an ordered list, or a set
-	// of named expressions.
-      void set_parameters(svector<PExpr*>*o);
-      void set_parameters(named<PExpr*>*pa, unsigned npa);
-
-	// Modules can be instantiated in ranges. The parser uses this
-	// method to pass the range to the pform.
-      void set_range(PExpr*msb, PExpr*lsb);
-
-      virtual void dump(ostream&out, unsigned ind =4) const;
-      virtual void elaborate(Design*, NetScope*scope) const;
-      virtual void elaborate_scope(Design*des, NetScope*sc) const;
-      virtual bool elaborate_sig(Design*des, NetScope*scope) const;
-
-	// This returns the module name of this module. It is a
-	// permallocated string.
-      perm_string get_type();
-
-    private:
-      perm_string type_;
-      svector<PExpr*>*overrides_;
-      named<PExpr*>*pins_;
-      unsigned npins_;
-
-	// These members support parameter override by name
-      named<PExpr*>*parms_;
-      unsigned nparms_;
-
-	// Arrays of modules are give if these are set.
-      PExpr*msb_;
-      PExpr*lsb_;
-
-      void elaborate_mod_(Design*, Module*mod, NetScope*scope) const;
-      void elaborate_udp_(Design*, PUdp  *udp, NetScope*scope) const;
-      void elaborate_scope_mod_(Design*des, Module*mod, NetScope*sc) const;
-      bool elaborate_sig_mod_(Design*des, NetScope*scope, Module*mod) const;
-};
-
-/*
- * $Log: PGate.h,v $
- * Revision 1.32  2006/04/10 00:37:42  steve
- *  Add support for generate loops w/ wires and gates.
- *
- * Revision 1.31  2006/01/03 05:22:14  steve
- *  Handle complex net node delays.
- *
- * Revision 1.30  2006/01/02 05:33:19  steve
- *  Node delays can be more general expressions in structural contexts.
- *
- * Revision 1.29  2004/10/04 01:10:52  steve
- *  Clean up spurious trailing white space.
- *
- * Revision 1.28  2004/03/08 00:47:44  steve
- *  primitive ports can bind bi name.
- *
- * Revision 1.27  2004/02/20 18:53:33  steve
- *  Addtrbute keys are perm_strings.
- *
- * Revision 1.26  2004/02/18 17:11:54  steve
- *  Use perm_strings for named langiage items.
- *
- * Revision 1.25  2003/03/06 04:37:12  steve
- *  lex_strings.add module names earlier.
- *
- * Revision 1.24  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.23  2002/05/23 03:08:51  steve
- *  Add language support for Verilog-2001 attribute
- *  syntax. Hook this support into existing $attribute
- *  handling, and add number and void value types.
- *
- *  Add to the ivl_target API new functions for access
- *  of complex attributes attached to gates.
- *
- * Revision 1.22  2001/11/22 06:20:59  steve
- *  Use NetScope instead of string for scope path.
- *
- * Revision 1.21  2001/10/21 00:42:47  steve
- *  Module types in pform are char* instead of string.
- *
- * Revision 1.20  2001/10/19 01:55:32  steve
- *  Method to get the type_ member
- *
- * Revision 1.19  2001/04/22 23:09:45  steve
- *  More UDP consolidation from Stephan Boettcher.
- *
- * Revision 1.18  2000/05/06 15:41:56  steve
- *  Carry assignment strength to pform.
- *
- * Revision 1.17  2000/05/02 16:27:38  steve
- *  Move signal elaboration to a seperate pass.
- *
- * Revision 1.16  2000/03/29 04:37:10  steve
- *  New and improved combinational primitives.
- *
- * Revision 1.15  2000/03/08 04:36:53  steve
- *  Redesign the implementation of scopes and parameters.
- *  I now generate the scopes and notice the parameters
- *  in a separate pass over the pform. Once the scopes
- *  are generated, I can process overrides and evalutate
- *  paremeters before elaboration begins.
- *
- * Revision 1.14  2000/02/23 02:56:53  steve
- *  Macintosh compilers do not support ident.
- *
- * Revision 1.13  2000/02/18 05:15:02  steve
- *  Catch module instantiation arrays.
- *
- * Revision 1.12  2000/01/09 05:50:48  steve
- *  Support named parameter override lists.
- *
- * Revision 1.11  1999/12/11 05:45:41  steve
- *  Fix support for attaching attributes to primitive gates.
- *
- * Revision 1.10  1999/09/04 19:11:46  steve
- *  Add support for delayed non-blocking assignments.
- *
- * Revision 1.9  1999/08/23 16:48:39  steve
- *  Parameter overrides support from Peter Monta
- *  AND and XOR support wide expressions.
- *
- * Revision 1.8  1999/08/01 21:18:55  steve
- *  elaborate rise/fall/decay for continuous assign.
- *
- * Revision 1.7  1999/08/01 16:34:50  steve
- *  Parse and elaborate rise/fall/decay times
- *  for gates, and handle the rules for partial
- *  lists of times.
- *
- * Revision 1.6  1999/05/29 02:36:17  steve
- *  module parameter bind by name.
- *
- * Revision 1.5  1999/05/10 00:16:58  steve
- *  Parse and elaborate the concatenate operator
- *  in structural contexts, Replace vector<PExpr*>
- *  and list<PExpr*> with svector<PExpr*>, evaluate
- *  constant expressions with parameters, handle
- *  memories as lvalues.
- *
- *  Parse task declarations, integer types.
- *
- * Revision 1.4  1999/02/15 02:06:15  steve
- *  Elaborate gate ranges.
- *
- * Revision 1.3  1999/01/25 05:45:56  steve
- *  Add the LineInfo class to carry the source file
- *  location of things. PGate, Statement and PProcess.
- *
- *  elaborate handles module parameter mismatches,
- *  missing or incorrect lvalues for procedural
- *  assignment, and errors are propogated to the
- *  top of the elaboration call tree.
- *
- *  Attach line numbers to processes, gates and
- *  assignment statements.
- *
- * Revision 1.2  1998/12/01 00:42:13  steve
- *  Elaborate UDP devices,
- *  Support UDP type attributes, and
- *  pass those attributes to nodes that
- *  are instantiated by elaboration,
- *  Put modules into a map instead of
- *  a simple list.
- *
- * Revision 1.1  1998/11/03 23:28:54  steve
- *  Introduce verilog to CVS.
- *
- */
-#endif
@@ -1,63 +0,0 @@
-/*
- * Copyright (c) 2006 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: PGenerate.cc,v 1.4 2007/06/02 03:42:12 steve Exp $"
-#endif
-
-# include  "PGenerate.h"
-# include  "PWire.h"
-
-PGenerate::PGenerate(unsigned id)
-: id_number(id)
-{
-      parent = 0;
-}
-
-PGenerate::~PGenerate()
-{
-}
-
-PWire* PGenerate::add_wire(PWire*wire)
-{
-      PWire*&ep = wires[wire->path()];
-      if (ep) return ep;
-
-      assert(ep == 0);
-      ep = wire;
-      return wire;
-}
-
-PWire* PGenerate::get_wire(const pform_name_t&name) const
-{
-      map<pform_name_t,PWire*>::const_iterator obj = wires.find(name);
-      if (obj == wires.end())
-	    return 0;
-      else
-	    return (*obj).second;
-}
-
-void PGenerate::add_gate(PGate*gate)
-{
-      gates.push_back(gate);
-}
-
-void PGenerate::add_behavior(PProcess*proc)
-{
-      behaviors.push_back(proc);
-}
@@ -1,100 +0,0 @@
-#ifndef __PGenerate_H
-#define __PGenerate_H
-/*
- * Copyright (c) 2006 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: PGenerate.h,v 1.4 2007/06/02 03:42:12 steve Exp $"
-#endif
-
-# include  "LineInfo.h"
-# include  "StringHeap.h"
-# include  "HName.h"
-# include  <list>
-# include  <map>
-# include  "pform_types.h"
-
-class Design;
-class NetScope;
-class PExpr;
-class PProcess;
-class PGate;
-class PWire;
-
-/*
- * This represents a generate scheme.
- */
-class PGenerate : public LineInfo {
-
-    public:
-      PGenerate(unsigned id_number);
-      ~PGenerate();
-
-	// Generate schemes have an ID number, for when the scope is
-	// implicit.
-      const unsigned id_number;
-      perm_string scope_name;
-
-      enum scheme_t {GS_NONE, GS_LOOP, GS_CONDIT};
-      scheme_t scheme_type;
-
-	// generate loops have an index variable and three
-	// expressions: for (index = <init>; <test>; index=<step>)
-      perm_string loop_index;
-      PExpr*loop_init;
-      PExpr*loop_test;
-      PExpr*loop_step;
-
-      map<pform_name_t,PWire*>wires;
-      PWire* add_wire(PWire*);
-      PWire* get_wire(const pform_name_t&name) const;
-
-      list<PGate*> gates;
-      void add_gate(PGate*);
-
-      list<PProcess*> behaviors;
-      void add_behavior(PProcess*behave);
-
-      list<PGenerate*> generates;
-      PGenerate*parent;
-
-	// This method is called by the elaboration of a module to
-	// generate scopes. the container is the scope that is to
-	// contain the generated scope.
-      bool generate_scope(Design*des, NetScope*container);
-
-      bool elaborate_sig(Design*des) const;
-      bool elaborate(Design*des) const;
-
-      void dump(ostream&out, unsigned indent) const;
-
-    private:
-      bool generate_scope_loop_(Design*des, NetScope*container);
-
-	// These are the scopes created by generate_scope.
-      list<NetScope*>scope_list_;
-	// internal function called on each scope generated by this scheme.
-      bool elaborate_sig_(Design*des, NetScope*scope) const;
-      bool elaborate_(Design*des, NetScope*scope) const;
-
-    private: // not implemented
-      PGenerate(const PGenerate&);
-      PGenerate& operator= (const PGenerate&);
-};
-
-#endif
@@ -1,34 +0,0 @@
-/*
- * Copyright (c) 2006 Stephen Williams <[email protected]>
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: PSpec.cc,v 1.2 2007/02/12 01:52:21 steve Exp $"
-#endif
-
-# include  "PSpec.h"
-
-PSpecPath::PSpecPath(unsigned src_cnt, unsigned dst_cnt)
-: conditional(false), condition(0), edge(0),
-  src(src_cnt), dst(dst_cnt),
-  data_source_expression(0)
-{
-}
-
-PSpecPath::~PSpecPath()
-{
-}
@@ -1,79 +0,0 @@
-#ifndef __PSpec_H
-#define __PSpec_H
-/*
- * Copyright (c) 2006 Stephen Williams <[email protected]>
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: PSpec.h,v 1.3 2007/04/13 02:34:35 steve Exp $"
-#endif
-
-# include  "LineInfo.h"
-# include  "StringHeap.h"
-# include  <vector>
-
-class PExpr;
-
-/*
-* The PSpecPath is the parse of a specify path, which is in its most
-* general form <path> = <delays>. The <delays> are collected into the
-* "delays" vector in all cases, and the variety is in the other
-* members.
-*
-* All paths also have a list of source names in the src vector, and a
-* list of destination names in the dst vector. These pairs are the
-* actual paths.
-*
-* If the path is a simple path, then:
-*      condition == nil
-*      edge == 0
-*      data_source_expression == nil
-*
-* If the path is conditional, then conditional == true and condition
-* is the condition expression. If the condition expression is nil,
-* then this is an ifnone conditional path.
-*
-* If data_source_expression != nil, then the path is edge sensitive
-* and the edge might not be 0.
-*/
-class PSpecPath  : public LineInfo {
-
-    public:
-      PSpecPath(unsigned src_cnt, unsigned dst_cnt);
-      ~PSpecPath();
-
-      void elaborate(class Design*des, class NetScope*scope) const;
-
-      void dump(std::ostream&out, unsigned ind) const;
-
-    public:
-	// Condition expression, if present.
-      bool conditional;
-      class PExpr* condition;
-	// Edge specification (-1==negedge, 0 = no edge, 1==posedge)
-      int edge;
-	// Ordered set of source nodes of a path
-      std::vector<perm_string> src;
-	// Ordered set of destination nodes of a path
-      std::vector<perm_string> dst;
-	// Data source expression
-      class PExpr* data_source_expression;
-
-      std::vector<class PExpr*>delays;
-};
-
-#endif
@@ -1,74 +0,0 @@
-/*
- * Copyright (c) 1999 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: PTask.cc,v 1.7 2002/08/12 01:34:58 steve Exp $"
-#endif
-
-# include "config.h"
-
-# include  "PTask.h"
-
-PTask::PTask()
-: ports_(0), statement_(0)
-{
-}
-
-PTask::~PTask()
-{
-}
-
-void PTask::set_ports(svector<PWire*>*p)
-{
-      assert(ports_ == 0);
-      ports_ = p;
-}
-
-void PTask::set_statement(Statement*s)
-{
-      assert(statement_ == 0);
-      statement_ = s;
-}
-
-
-/*
- * $Log: PTask.cc,v $
- * Revision 1.7  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.6  2001/07/25 03:10:48  steve
- *  Create a config.h.in file to hold all the config
- *  junk, and support gcc 3.0. (Stephan Boettcher)
- *
- * Revision 1.5  2001/04/19 03:04:47  steve
- *  Spurious assert of empty statemnt.
- *
- * Revision 1.4  2001/01/13 22:20:08  steve
- *  Parse parameters within nested scopes.
- *
- * Revision 1.3  2000/02/23 02:56:53  steve
- *  Macintosh compilers do not support ident.
- *
- * Revision 1.2  1999/07/24 02:11:19  steve
- *  Elaborate task input ports.
- *
- * Revision 1.1  1999/07/03 02:12:51  steve
- *  Elaborate user defined tasks.
- *
- */
-
@@ -1,177 +0,0 @@
-#ifndef __PTask_H
-#define __PTask_H
-/*
- * Copyright (c) 1999-2000 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: PTask.h,v 1.14 2007/03/06 05:22:49 steve Exp $"
-#endif
-
-# include  "LineInfo.h"
-# include  "svector.h"
-# include  "StringHeap.h"
-# include  <string>
-class Design;
-class NetScope;
-class PWire;
-class Statement;
-class PExpr;
-
-enum PTaskFuncEnum {
-      PTF_NONE,
-      PTF_REG,
-      PTF_REG_S,
-      PTF_INTEGER,
-      PTF_REAL,
-      PTF_REALTIME,
-      PTF_TIME
-};
-
-struct PTaskFuncArg {
-      PTaskFuncEnum type;
-      svector<PExpr*>*range;
-};
-
-/*
- * The PTask holds the parsed definitions of a task.
- */
-class PTask  : public LineInfo {
-
-    public:
-      explicit PTask();
-      ~PTask();
-
-      void set_ports(svector<PWire *>*p);
-      void set_statement(Statement *s);
-
-	// Tasks introduce scope, to need to be handled during the
-	// scope elaboration pass. The scope passed is my scope,
-	// created by the containing scope. I fill it in with stuff if
-	// I need to.
-      void elaborate_scope(Design*des, NetScope*scope) const;
-
-	// Bind the ports to the regs that are the ports.
-      void elaborate_sig(Design*des, NetScope*scope) const;
-
-	// Elaborate the statement to finish off the task definition.
-      void elaborate(Design*des, NetScope*scope) const;
-
-      void dump(ostream&, unsigned) const;
-
-    private:
-      svector<PWire*>*ports_;
-      Statement*statement_;
-
-    private: // Not implemented
-      PTask(const PTask&);
-      PTask& operator=(const PTask&);
-};
-
-/*
- * The function is similar to a task (in this context) but there is a
- * single output port and a set of input ports. The output port is the
- * function return value.
- *
- * The output value is not elaborated until elaborate_sig.
- */
-class PFunction : public LineInfo {
-
-    public:
-      explicit PFunction(perm_string name);
-      ~PFunction();
-
-      void set_ports(svector<PWire *>*p);
-      void set_statement(Statement *s);
-      void set_return(PTaskFuncArg t);
-
-      void elaborate_scope(Design*des, NetScope*scope) const;
-
-	/* elaborate the ports and return value. */
-      void elaborate_sig(Design *des, NetScope*) const;
-
-	/* Elaborate the behavioral statement. */
-      void elaborate(Design *des, NetScope*) const;
-
-      void dump(ostream&, unsigned) const;
-
-    private:
-      perm_string name_;
-      PTaskFuncArg return_type_;
-      svector<PWire *> *ports_;
-      Statement *statement_;
-};
-
-/*
- * $Log: PTask.h,v $
- * Revision 1.14  2007/03/06 05:22:49  steve
- *  Support signed function return values.
- *
- * Revision 1.13  2004/05/31 23:34:36  steve
- *  Rewire/generalize parsing an elaboration of
- *  function return values to allow for better
- *  speed and more type support.
- *
- * Revision 1.12  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.11  2001/11/22 06:20:59  steve
- *  Use NetScope instead of string for scope path.
- *
- * Revision 1.10  2001/01/13 22:20:08  steve
- *  Parse parameters within nested scopes.
- *
- * Revision 1.9  2000/07/30 18:25:43  steve
- *  Rearrange task and function elaboration so that the
- *  NetTaskDef and NetFuncDef functions are created during
- *  signal enaboration, and carry these objects in the
- *  NetScope class instead of the extra, useless map in
- *  the Design class.
- *
- * Revision 1.8  2000/03/08 04:36:53  steve
- *  Redesign the implementation of scopes and parameters.
- *  I now generate the scopes and notice the parameters
- *  in a separate pass over the pform. Once the scopes
- *  are generated, I can process overrides and evalutate
- *  paremeters before elaboration begins.
- *
- * Revision 1.7  2000/02/23 02:56:53  steve
- *  Macintosh compilers do not support ident.
- *
- * Revision 1.6  1999/09/30 21:28:34  steve
- *  Handle mutual reference of tasks by elaborating
- *  task definitions in two passes, like functions.
- *
- * Revision 1.5  1999/09/01 20:46:19  steve
- *  Handle recursive functions and arbitrary function
- *  references to other functions, properly pass
- *  function parameters and save function results.
- *
- * Revision 1.4  1999/08/25 22:22:41  steve
- *  elaborate some aspects of functions.
- *
- * Revision 1.3  1999/07/31 19:14:47  steve
- *  Add functions up to elaboration (Ed Carter)
- *
- * Revision 1.2  1999/07/24 02:11:19  steve
- *  Elaborate task input ports.
- *
- * Revision 1.1  1999/07/03 02:12:51  steve
- *  Elaborate user defined tasks.
- *
- */
-#endif
@@ -1,53 +0,0 @@
-/*
- * Copyright (c) 2003-2004 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: PUdp.cc,v 1.3 2004/03/08 00:47:44 steve Exp $"
-#endif
-
-# include  "PUdp.h"
-
-PUdp::PUdp(perm_string n, unsigned nports)
-: ports(nports), sequential(false), initial(verinum::Vx), name_(n)
-{
-}
-
-unsigned PUdp::find_port(const char*name)
-{
-      for (unsigned idx = 0 ;  idx < ports.count() ;  idx += 1) {
-
-	    if (ports[idx] == name)
-		  return idx;
-      }
-
-      return ports.count();
-}
-
-/*
- * $Log: PUdp.cc,v $
- * Revision 1.3  2004/03/08 00:47:44  steve
- *  primitive ports can bind bi name.
- *
- * Revision 1.2  2004/02/18 17:11:54  steve
- *  Use perm_strings for named langiage items.
- *
- * Revision 1.1  2003/07/15 05:07:13  steve
- *  Move PUdp constructor into compiled file.
- *
- */
-
@@ -1,130 +0,0 @@
-#ifndef __PUdp_H
-#define __PUdp_H
-/*
- * Copyright (c) 1998-2004 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: PUdp.h,v 1.12 2004/03/08 00:47:44 steve Exp $"
-#endif
-
-# include  <map>
-# include  "StringHeap.h"
-# include  "svector.h"
-# include  "verinum.h"
-
-class PExpr;
-
-/*
- * This class represents a parsed UDP. This is a much simpler object
- * then a module or macromodule.
- *
- *   - all ports are scalar,
- *   - pin 0 (the first port) is always output,
- *     and the remaining pins are input.
- *
- * Thus, the ports can be represented as an ordered list of pin names.
- * If the output port is declared as a register in the Verilog source,
- * then this is a sequential UDP and the sequential flag is set to true.
- *
- * STATE TABLE
- * Each entry in the state table is given as a string with the same
- * number of characters as inputs. If the UDP is sequential, a
- * character is also included at the end of the string to represent
- * the current output.
- *
- * If the UDP is sequential, the "initial" member is taken to be the
- * initial value assigned in the source, or 'x' if none is given.
- */
-class PUdp {
-
-    public:
-      explicit PUdp(perm_string n, unsigned nports);
-
-      svector<string>ports;
-      unsigned find_port(const char*name);
-
-      bool sequential;
-
-      svector<string>tinput;
-      svector<char>  tcurrent;
-      svector<char>  toutput;
-
-      verinum::V initial;
-
-      map<string,PExpr*> attributes;
-
-      void dump(ostream&out) const;
-
-      perm_string name_;
-    private:
-
-    private: // Not implemented
-      PUdp(const PUdp&);
-      PUdp& operator= (const PUdp&);
-};
-
-/*
- * $Log: PUdp.h,v $
- * Revision 1.12  2004/03/08 00:47:44  steve
- *  primitive ports can bind bi name.
- *
- * Revision 1.11  2004/02/18 17:11:54  steve
- *  Use perm_strings for named langiage items.
- *
- * Revision 1.10  2003/07/15 05:07:13  steve
- *  Move PUdp constructor into compiled file.
- *
- * Revision 1.9  2003/07/15 03:49:22  steve
- *  Spelling fixes.
- *
- * Revision 1.8  2003/01/30 16:23:07  steve
- *  Spelling fixes.
- *
- * Revision 1.7  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.6  2002/05/23 03:08:51  steve
- *  Add language support for Verilog-2001 attribute
- *  syntax. Hook this support into existing $attribute
- *  handling, and add number and void value types.
- *
- *  Add to the ivl_target API new functions for access
- *  of complex attributes attached to gates.
- *
- * Revision 1.5  2001/04/22 23:09:45  steve
- *  More UDP consolidation from Stephan Boettcher.
- *
- * Revision 1.4  2000/02/23 02:56:53  steve
- *  Macintosh compilers do not support ident.
- *
- * Revision 1.3  1999/06/15 03:44:53  steve
- *  Get rid of the STL vector template.
- *
- * Revision 1.2  1998/12/01 00:42:13  steve
- *  Elaborate UDP devices,
- *  Support UDP type attributes, and
- *  pass those attributes to nodes that
- *  are instantiated by elaboration,
- *  Put modules into a map instead of
- *  a simple list.
- *
- * Revision 1.1  1998/11/25 02:35:53  steve
- *  Parse UDP primitives all the way to pform.
- *
- */
-#endif
@@ -1,199 +0,0 @@
-/*
- * Copyright (c) 1999-2007 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: PWire.cc,v 1.14 2007/05/24 04:07:11 steve Exp $"
-#endif
-
-# include "config.h"
-# include  "PWire.h"
-# include  <assert.h>
-
-PWire::PWire(const pform_name_t&n,
-	     NetNet::Type t,
-	     NetNet::PortType pt,
-	     ivl_variable_type_t dt)
-: hname_(n), type_(t), port_type_(pt), data_type_(dt),
-  signed_(false), isint_(false),
-lidx_(0), ridx_(0)
-{
-      if (t == NetNet::INTEGER) {
-	    type_ = NetNet::REG;
-	    signed_ = true;
-	    isint_ = true;
-      }
-}
-
-NetNet::Type PWire::get_wire_type() const
-{
-      return type_;
-}
-
-const pform_name_t& PWire::path() const
-{
-      return hname_;
-}
-
-bool PWire::set_wire_type(NetNet::Type t)
-{
-      assert(t != NetNet::IMPLICIT);
-
-      switch (type_) {
-	  case NetNet::IMPLICIT:
-	    type_ = t;
-	    return true;
-	  case NetNet::IMPLICIT_REG:
-	    if (t == NetNet::REG) { type_ = t; return true; }
-	    return false;
-	  case NetNet::REG:
-	    if (t == NetNet::INTEGER) {
-		  isint_ = true;
-		  return true;
-	    }
-	    if (t == NetNet::REG) return true;
-	    return false;
-	  default:
-	    if (type_ != t)
-		  return false;
-	    else
-		  return true;
-      }
-}
-
-NetNet::PortType PWire::get_port_type() const
-{
-      return port_type_;
-}
-
-bool PWire::set_port_type(NetNet::PortType pt)
-{
-      assert(pt != NetNet::NOT_A_PORT);
-      assert(pt != NetNet::PIMPLICIT);
-
-      switch (port_type_) {
-	  case NetNet::PIMPLICIT:
-	    port_type_ = pt;
-	    return true;
-
-	  case NetNet::NOT_A_PORT:
-	    return false;
-
-	  default:
-	    if (port_type_ != pt)
-		  return false;
-	    else
-		  return true;
-      }
-}
-
-bool PWire::set_data_type(ivl_variable_type_t dt)
-{
-      if (data_type_ != IVL_VT_NO_TYPE)
-	    if (data_type_ != dt)
-		  return false;
-	    else
-		  return true;
-
-      assert(data_type_ == IVL_VT_NO_TYPE);
-      data_type_ = dt;
-      return true;
-}
-
-void PWire::set_signed(bool flag)
-{
-      signed_ = flag;
-}
-
-bool PWire::get_signed() const
-{
-      return signed_;
-}
-
-bool PWire::get_isint() const
-{
-      return isint_;
-}
-
-void PWire::set_range(PExpr*m, PExpr*l)
-{
-      msb_ = svector<PExpr*>(msb_,m);
-      lsb_ = svector<PExpr*>(lsb_,l);
-}
-
-void PWire::set_memory_idx(PExpr*ldx, PExpr*rdx)
-{
-      assert(lidx_ == 0);
-      assert(ridx_ == 0);
-      lidx_ = ldx;
-      ridx_ = rdx;
-}
-
-/*
- * $Log: PWire.cc,v $
- * Revision 1.14  2007/05/24 04:07:11  steve
- *  Rework the heirarchical identifier parse syntax and pform
- *  to handle more general combinations of heirarch and bit selects.
- *
- * Revision 1.13  2007/04/26 03:06:21  steve
- *  Rework hname_t to use perm_strings.
- *
- * Revision 1.12  2007/01/16 05:44:14  steve
- *  Major rework of array handling. Memories are replaced with the
- *  more general concept of arrays. The NetMemory and NetEMemory
- *  classes are removed from the ivl core program, and the IVL_LPM_RAM
- *  lpm type is removed from the ivl_target API.
- *
- * Revision 1.11  2005/07/07 16:22:49  steve
- *  Generalize signals to carry types.
- *
- * Revision 1.10  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.9  2002/06/21 04:59:35  steve
- *  Carry integerness throughout the compilation.
- *
- * Revision 1.8  2002/01/26 05:28:28  steve
- *  Detect scalar/vector declarion mismatch.
- *
- * Revision 1.7  2001/12/03 04:47:14  steve
- *  Parser and pform use hierarchical names as hname_t
- *  objects instead of encoded strings.
- *
- * Revision 1.6  2001/07/25 03:10:48  steve
- *  Create a config.h.in file to hold all the config
- *  junk, and support gcc 3.0. (Stephan Boettcher)
- *
- * Revision 1.5  2001/01/06 02:29:35  steve
- *  Support arrays of integers.
- *
- * Revision 1.4  2000/12/11 00:31:43  steve
- *  Add support for signed reg variables,
- *  simulate in t-vvm signed comparisons.
- *
- * Revision 1.3  2000/02/23 02:56:54  steve
- *  Macintosh compilers do not support ident.
- *
- * Revision 1.2  1999/09/10 05:02:09  steve
- *  Handle integers at task parameters.
- *
- * Revision 1.1  1999/06/17 05:34:42  steve
- *  Clean up interface of the PWire class,
- *  Properly match wire ranges.
- *
- */
-
@@ -1,155 +0,0 @@
-#ifndef __PWire_H
-#define __PWire_H
-/*
- * Copyright (c) 1998-2007 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: PWire.h,v 1.21 2007/05/24 04:07:11 steve Exp $"
-#endif
-
-# include  "netlist.h"
-# include  "LineInfo.h"
-# include  <map>
-# include  "svector.h"
-# include  "StringHeap.h"
-
-#ifdef HAVE_IOSFWD
-# include  <iosfwd>
-#else
-class ostream;
-#endif
-
-class PExpr;
-class Design;
-
-/*
- * Wires include nets, registers and ports. A net or register becomes
- * a port by declaration, so ports are not separate. The module
- * identifies a port by keeping it in its port list.
- *
- * The hname parameter to the constructor is a hierarchical name. It
- * is the name of the wire within a module, so does not include the
- * current scope or any instances. Modules contain all the wires, so
- * from that perspective, sub-scopes within the module are a part of
- * the wire name.
- */
-class PWire : public LineInfo {
-
-    public:
-      PWire(const pform_name_t&hname,
-	    NetNet::Type t,
-	    NetNet::PortType pt,
-	    ivl_variable_type_t dt);
-
-	// Return a hierarchical name.
-      const pform_name_t&path() const;
-
-      NetNet::Type get_wire_type() const;
-      bool set_wire_type(NetNet::Type);
-
-      NetNet::PortType get_port_type() const;
-      bool set_port_type(NetNet::PortType);
-
-      void set_signed(bool flag);
-      bool get_signed() const;
-      bool get_isint() const;
-
-      bool set_data_type(ivl_variable_type_t dt);
-      ivl_variable_type_t get_data_type() const;
-
-      void set_range(PExpr*msb, PExpr*lsb);
-
-      void set_memory_idx(PExpr*ldx, PExpr*rdx);
-
-      map<perm_string,PExpr*> attributes;
-
-	// Write myself to the specified stream.
-      void dump(ostream&out, unsigned ind=4) const;
-
-      NetNet* elaborate_sig(Design*, NetScope*scope) const;
-
-    private:
-      pform_name_t hname_;
-      NetNet::Type type_;
-      NetNet::PortType port_type_;
-      ivl_variable_type_t data_type_;
-      bool signed_;
-      bool isint_;		// original type of integer
-
-	// These members hold expressions for the bit width of the
-	// wire. If they do not exist, the wire is 1 bit wide.
-      svector<PExpr*>msb_;
-      svector<PExpr*>lsb_;
-
-	// If this wire is actually a memory, these indices will give
-	// me the size and address range of the memory.
-      PExpr*lidx_;
-      PExpr*ridx_;
-
-    private: // not implemented
-      PWire(const PWire&);
-      PWire& operator= (const PWire&);
-};
-
-/*
- * $Log: PWire.h,v $
- * Revision 1.21  2007/05/24 04:07:11  steve
- *  Rework the heirarchical identifier parse syntax and pform
- *  to handle more general combinations of heirarch and bit selects.
- *
- * Revision 1.20  2007/04/26 03:06:22  steve
- *  Rework hname_t to use perm_strings.
- *
- * Revision 1.19  2006/04/10 00:37:42  steve
- *  Add support for generate loops w/ wires and gates.
- *
- * Revision 1.18  2005/07/07 16:22:49  steve
- *  Generalize signals to carry types.
- *
- * Revision 1.17  2004/02/20 18:53:33  steve
- *  Addtrbute keys are perm_strings.
- *
- * Revision 1.16  2003/01/30 16:23:07  steve
- *  Spelling fixes.
- *
- * Revision 1.15  2003/01/26 21:15:58  steve
- *  Rework expression parsing and elaboration to
- *  accommodate real/realtime values and expressions.
- *
- * Revision 1.14  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.13  2002/06/21 04:59:35  steve
- *  Carry integerness throughout the compilation.
- *
- * Revision 1.12  2002/05/23 03:08:51  steve
- *  Add language support for Verilog-2001 attribute
- *  syntax. Hook this support into existing $attribute
- *  handling, and add number and void value types.
- *
- *  Add to the ivl_target API new functions for access
- *  of complex attributes attached to gates.
- *
- * Revision 1.11  2001/12/03 04:47:14  steve
- *  Parser and pform use hierarchical names as hname_t
- *  objects instead of encoded strings.
- *
- * Revision 1.10  2001/01/16 02:44:18  steve
- *  Use the iosfwd header if available.
- */
-#endif
@@ -1,83 +0,0 @@
-
-* Getting Started with Icarus Verilog
-
-Icarus Verilog is a Verilog compiler. It is suitable for use as a
-simulator, and, to some degree, synthesizer. Icarus Verilog runs under
-Linux and a variety of UNIX systems, as well as Windows as a command
-line tool, so the instructions are generally applicable to all
-environments. Note that this is only a quick start. For more detailed
-documentation, see the manual page for the iverilog command.
-
-
-* Hello, World!
-
-The first thing you want to do as a user is learn how to compile and
-execute even the most trivial design. For the purposes of simulation,
-we use as our example *the* most trivial simulation:
-
-  module main;
-
-  initial
-    begin
-      $display("Hello, World");
-      $finish ;
-    end
-
-  endmodule
-
-By a text editor (or copy hello.vl from the Icarus Verilog examples
-directory) arrange for this program to be in a text file, "hello.vl".
-Next, compile this program with a command like this:
-
-	% iverilog -o hello hello.vl
-
-The results of this compile are placed into the file "hello", as the
-"-o" flag tells the compiler where to place the compiled result. Next,
-execute the compiled program like so:
-
-	% vvp hello
-	Hello, World
-
-And there it is, the program has been executed. So what happened? The
-first step, the "iverilog" command, read and interpreted the source
-file, then generated a compiled result. The compiled form may be
-selected by command line switches, but the default form is the VVP
-format, which is actually run by the "vvp" command.
-
-The "iverilog" and "vvp" commands are the only commands that users
-use to invoke Icarus Verilog. What the compiler actually does is
-controlled by command line switches. In our little example, we asked
-the compiler to compile the source program to the default vvp form,
-which is in turn executed by the vvp program.
-
-
-* Windows Install
-
-The easiest way to install under Windows is to get a precompiled
-installer for the version you wish to install. Icarus Verilog is
-distributed for Windows users as a self-installing .exe. Just execute
-the installer and follow the instructions. During the install, take
-note of the directory where the program is installed: for example,
-C:\iverilog is a good place to install.
-
-Once the binary is installed, you need to add the bin directory to
-your execution path. The executables you need are in C:\iverilog\bin,
-where the "C:\iverilog" part is actually the root of where you
-installed the package. The programs are in the bin subdirectory. Put
-this directory in your PATH environment variable, and the above
-commands become accessible to you at the command line prompt, or even
-in batch files.
-
-
-* Linux Install
-
-Under Linux, the install is even easier. For RedHat and Mandrake based
-systems, there is the appropriate RPM file. Just install the package
-with the "rpm -U <file>" command. Debian users should get Icarus
-Verilog packages from the main Debian software site.
-
-
-* Install From Source
-
-In this case, see README.txt and other documentation that comes with
-the source.
@@ -1,496 +0,0 @@
-		THE ICARUS VERILOG COMPILATION SYSTEM
-		Copyright 2000-2004 Stephen Williams
-
-
-1.0 What is ICARUS Verilog?
-
-Icarus Verilog is intended to compile ALL of the Verilog HDL as
-described in the IEEE-1364 standard. Of course, it's not quite there
-yet. It does currently handle a mix of structural and behavioral
-constructs. For a view of the current state of Icarus Verilog, see its
-home page at <http://www.icarus.com/eda/verilog>.
-
-Icarus Verilog is not aimed at being a simulator in the traditional
-sense, but a compiler that generates code employed by back-end
-tools. These back-end tools currently include a simulator engine
-called VVP, an XNF (Xilinx Netlist Format) generator and an EDIF FPGA
-netlist generator. In the future, backends are expected for EDIF/LPM,
-structural Verilog, VHDL, etc.
-
-    For instructions on how to run Icarus Verilog,
-    see the ``iverilog'' man page.
-
-
-2.0 Building/Installing Icarus Verilog From Source
-
-If you are starting from source, the build process is designed to be
-as simple as practical. Someone basically familiar with the target
-system and C/C++ compilation should be able to build the source
-distribution with little effort. Some actual programming skills are
-not required, but helpful in case of problems.
-
-If you are building for Windows, see the mingw.txt file.
-
-2.1 Compile Time Prerequisites
-
-You need the following software to compile Icarus Verilog from source
-on a UNIX-like system:
-
-	- GNU Make
-	  The Makefiles use some GNU extensions, so a basic POSIX
-	  make will not work. Linux systems typically come with a
-	  satisfactory make. BSD based systems (i.e., NetBSD, FreeBSD)
-	  typically have GNU make as the gmake program.
-
-	- ISO C++ Compiler
-	  The ivl and ivlpp programs are written in C++ and make use
-	  of templates and some of the standard C++ library. egcs and
-	  recent gcc compilers with the associated libstdc++ are known
-	  to work. MSVC++ 5 and 6 are known to definitely *not* work.
-
-	- bison and flex
-
-	- gperf 2.7
-	  The lexical analyzer doesn't recognize keywords directly,
-	  but instead matches symbols and looks them up in a hash
-	  table in order to get the proper lexical code. The gperf
-	  program generates the lookup table.
-
-	  A version problem with this program is the most common cause
-	  of difficulty. See the Icarus Verilog FAQ.
-
-	- readline 4.2
-	  On Linux systems, this usually means the readline-devel
-	  rpm. In any case, it is the development headers of readline
-	  that are needed.
-
-	- termcap
-	  The readline library in turn uses termcap.
-
-If you are building from CVS, you will also need software to generate
-the configure scripts.
-
-	- autoconf 2.53
-	  This generates configure scripts from configure.in. The 2.53
-	  or later versions are known to work, autoconf 2.13 is
-	  reported to *not* work.
-
-2.2 Compilation
-
-Unpack the tar-ball and cd into the verilog-######### directory
-(presumably that is how you got to this README) and compile the source
-with the commands:
-
-  ./configure
-  make
-
-Normally, this command automatically figures out everything it needs
-to know. It generally works pretty well. There are a few flags to the
-configure script that modify its behavior:
-
-	--without-ipal
-	    This turns off support for Icarus PAL, whether ipal
-	    libraries are installed or not.
-
-	--prefix=<root>
-	    The default is /usr/local, which causes the tool suite to
-	    be compiled for install in /usr/local/bin,
-	    /usr/local/share/ivl, etc.
-
-	    I recommend that if you are configuring for precompiled
-	    binaries, use --prefix=/usr.  On Solaris systems, it is
-	    common to use --prefix=/opt.  You can configure for a non-root
-	    install with --prefix=$HOME.
-
-	--enable-vvp32 (experimental)
-	    If compiling on AMD64 systems, this enables the
-	    compilation of 32bit compatible vvp (vvp32) and the vpi
-	    modules that match.
-
-2.2.1 Special AMD64 Instructions
-
-(The Icarus Verilog RPM for x86_64 is build using these instructions.)
-
-If you are building for Linux/AMD64 (a.k.a x86_64) then to get the
-most out of your install, first make sure you have both 64bit and
-32bit development libraries installed. Then configure with this
-somewhat more complicated command:
-
-  ./configure libdir64='$(prefix)/lib64' vpidir1=vpi64 vpidir2=. --enable-vvp32
-
-This reflects the convention on AMD64 systems that 64bit libraries go
-into lib64 directories. The "--enable-vvp32" also turns on 32bit
-compatibility files. A 32bit version of vvp (vvp32) will be created,
-as well as 32bit versions of the development libraries and bundled VPI
-libraries.
-
-2.3 (Optional) Testing
-
-To run a simple test before installation, execute
-
-  make check
-
-The commands printed by this run might help you in running Icarus
-Verilog on your own Verilog sources before the package is installed
-by root.
-
-2.4 Installation
-
-Now install the files in an appropriate place. (The makefiles by
-default install in /usr/local unless you specify a different prefix
-with the --prefix=<path> flag to the configure command.) You may need
-to do this as root to gain access to installation directories.
-
-  make install
-
-2.5 Uninstallation
-
-The generated Makefiles also include the uninstall target. This should
-remove all the files that ``make install'' creates.
-
-3.0 How Icarus Verilog Works
-
-This tool includes a parser which reads in Verilog (plus extensions)
-and generates an internal netlist. The netlist is passed to various
-processing steps that transform the design to more optimal/practical
-forms, then is passed to a code generator for final output. The
-processing steps and the code generator are selected by command line
-switches.
-
-3.1 Preprocessing
-
-There is a separate program, ivlpp, that does the preprocessing. This
-program implements the `include and `define directives producing
-output that is equivalent but without the directives. The output is a
-single file with line number directives, so that the actual compiler
-only sees a single input file. See ivlpp/ivlpp.txt for details.
-
-3.2 Parse
-
-The Verilog compiler starts by parsing the Verilog source file. The
-output of the parse is a list of Module objects in "pform". The pform
-(see pform.h) is mostly a direct reflection of the compilation
-step. There may be dangling references, and it is not yet clear which
-module is the root.
-
-One can see a human readable version of the final pform by using the
-``-P <path>'' flag to the compiler. This will cause iverilog to dump
-the pform into the file named <path>.
-
-3.3 Elaboration
-
-This phase takes the pform and generates a netlist. The driver selects
-(by user request or lucky guess) the root module to elaborate,
-resolves references and expands the instantiations to form the design
-netlist. (See netlist.txt.) Final semantic checks are performed during
-elaboration, and some simple optimizations are performed. The netlist
-includes all the behavioral descriptions, as well as gates and wires.
-
-The elaborate() function performs the elaboration.
-
-One can see a human readable version of the final, elaborated and
-optimized netlist by using the ``-N <path>'' flag to the compiler. If
-elaboration succeeds, the final netlist (i.e., after optimizations but
-before code generation) will be dumped into the file named <path>.
-
-Elaboration is actually performed in two steps: scopes and parameters
-first, followed by the structural and behavioral elaboration.
-
-3.3.1 Scope Elaboration
-
-This pass scans through the pform looking for scopes and parameters. A
-tree of NetScope objects is built up and placed in the Design object,
-with the root module represented by the root NetScope object. The
-elab_scope.cc and elab_pexpr.cc files contain most of the code for
-handling this phase.
-
-The tail of the elaborate_scope behavior (after the pform is
-traversed) includes a scan of the NetScope tree to locate defparam
-assignments that were collected during scope elaboration. This is when
-the defparam overrides are applied to the parameters.
-
-3.3.2 Netlist Elaboration
-
-After the scopes and parameters are generated and the NetScope tree
-fully formed, the elaboration runs through the pform again, this time
-generating the structural and behavioral netlist. Parameters are
-elaborated and evaluated by now so all the constants of code
-generation are now known locally, so the netlist can be generated by
-simply passing through the pform.
-
-3.4 Optimization
-
-This is actually a collection of processing steps that perform
-optimizations that do not depend on the target technology. Examples of
-some useful transformations are
-
-	- eliminate null effect circuitry
-	- combinational reduction
-	- constant propagation
-
-The actual functions performed are specified on the ivl command line by
-the -F flags (see below).
-
-3.5 Code Generation
-
-This step takes the design netlist and uses it to drive the code
-generator (see target.h). This may require transforming the
-design to suit the technology.
-
-The emit() method of the Design class performs this step. It runs
-through the design elements, calling target functions as need arises
-to generate actual output.
-
-The user selects the target code generator with the -t flag on the
-command line.
-
-3.6 ATTRIBUTES
-
-    NOTE: The $attribute syntax will soon be deprecated in favor of the
-    Verilog-2001 attribute syntax, which is cleaner and standardized.
-
-The parser accepts, as an extension to Verilog, the $attribute module
-item. The syntax of the $attribute item is:
-
-	$attribute (<identifier>, <key>, <value>);
-
-The $attribute keyword looks like a system task invocation. The
-difference here is that the parameters are more restricted then those
-of a system task. The <identifier> must be an identifier. This will be
-the item to get an attribute. The <key> and <value> are strings, not
-expressions, that give the key and the value of the attribute to be
-attached to the identified object.
-
-Attributes are [<key> <value>] pairs and are used to communicate with
-the various processing steps. See the documentation for the processing
-step for a list of the pertinent attributes.
-
-Attributes can also be applied to gate types. When this is done, the
-attribute is given to every instantiation of the primitive. The syntax
-for the attribute statement is the same, except that the <identifier>
-names a primitive earlier in the compilation unit and the statement is
-placed in global scope, instead of within a module. The semicolon is
-not part of a type attribute.
-
-Note that attributes are also occasionally used for communication
-between processing steps. Processing steps that are aware of others
-may place attributes on netlist objects to communicate information to
-later steps.
-
-Icarus Verilog also accepts the Verilog 2001 syntax for
-attributes. They have the same general meaning as with the $attribute
-syntax, but they are attached to objects by position instead of by
-name. Also, the key is a Verilog identifier instead of a string.
-
-4.0 Running iverilog
-
-The preferred way to invoke the compiler is with the iverilog(1)
-command. This program invokes the preprocessor (ivlpp) and the
-compiler (ivl) with the proper command line options to get the job
-done in a friendly way. See the iverilog(1) man page for usage details.
-
-
-4.1 EXAMPLES
-
-Example: Compiling "hello.vl"
-
------------------------ hello.vl ----------------------------
-module main();
-
-initial
-  begin
-    $display("Hi there");
-    $finish ;
-  end
-
-endmodule
-
--------------------------------------------------------------
-
-Ensure that "iverilog" is on your search path, and the vpi library
-is available.
-
-To compile the program:
-
-  iverilog hello.vl
-
-(The above presumes that /usr/local/include and /usr/local/lib are
-part of the compiler search path, which is usually the case for gcc.)
-
-To run the program:
-
-  ./a.out
-
-You can use the "-o" switch to name the output command to be generated
-by the compiler. See the iverilog(1) man page.
-
-5.0 Unsupported Constructs
-
-Icarus Verilog is in development - as such it still only supports a
-(growing) subset of Verilog.  Below is a description of some of the
-currently unsupported Verilog features. This list is not exhaustive,
-and does not account for errors in the compiler. See the Icarus
-Verilog web page for the current state of support for Verilog, and in
-particular, browse the bug report database for reported unsupported
-constructs.
-
-  - System functions are supported, but the return value is a little
-    tricky. See SYSTEM FUNCTION TABLE FILES in the iverilog man page.
-
-  - Specify blocks are parsed but ignored in general.
-
-  - trireg is not supported. tri0 and tri1 are supported.
-
-  - tran primitives, i.e. tran, tranif1, tranif0, rtran, rtranif1
-    and rtranif0 are not supported.
-
-  - Net delays, of the form "wire #N foo;" do not work. Delays in
-    every other context do work properly, including the V2001 form
-    "wire #5 foo = bar;"
-
-  - Event controls inside non-blocking assignments are not supported.
-    i.e.: a <= @(posedge clk) b;
-
-  - Macro arguments are not supported. `define macros are supported,
-    but they cannot take arguments.
-
-5.1 Nonstandard Constructs or Behaviors
-
-Icarus Verilog includes some features that are not part of the
-IEEE1364 standard, but have well defined meaning, and also sometimes
-gives nonstandard (but extended) meanings to some features of the
-language that are defined. See the "extensions.txt" documentation for
-more details.
-
-    $is_signed(<expr>)
-	This system function returns 1 if the expression contained is
-	signed, or 0 otherwise. This is mostly of use for compiler
-	regression tests.
-
-    $sizeof(<expr>)
-    $bits(<expr>)
-	The $bits system function returns the size in bits of the
-	expression that is its argument. The result of this
-	function is undefined if the argument doesn't have a
-	self-determined size.
-
-	The $sizeof function is deprecated in favor of $bits, which is
-	the same thing, but included in the SystemVerilog definition.
-
-    $simtime
-	The $simtime system function returns as a 64bit value the
-	simulation time, unscaled by the time units of local
-	scope. This is different from the $time and $stime functions
-	which return the scaled times. This function is added for
-	regression testing of the compiler and run time, but can be
-	used by applications who really want the simulation time.
-
-	Note that the simulation time can be confusing if there are
-	lots of different `timescales within a design. It is not in
-	general possible to predict what the simulation precision will
-	turn out to be.
-
-    $mti_random()
-    $mti_dist_uniform
-	These functions are similar to the IEEE1364 standard $random
-	functions, but they use the Mersenne Twister (MT19937)
-	algorithm. This is considered an excellent random number
-	generator, but does not generate the same sequence as the
-	standardized $random.
-
-    Builtin system functions
-
-	Certain of the system functions have well defined meanings, so
-	can theoretically be evaluated at compile time, instead of
-	using runtime VPI code. Doing so means that VPI cannot
-	override the definitions of functions handled in this
-	manner. On the other hand, this makes them synthesizable, and
-	also allows for more aggressive constant propagation. The
-	functions handled in this manner are:
-
-		$bits
-		$signed
-		$sizeof
-		$unsigned
-
-	Implementations of these system functions in VPI modules will
-	be ignored.
-
-    Preprocessing Library Modules
-
-	Icarus Verilog does preprocess modules that are loaded from
-	libraries via the -y mechanism. However, the only macros
-	defined during compilation of that file are those that it
-	defines itself (or includes) or that are defined on the
-	command line or command file.
-
-	Specifically, macros defined in the non-library source files
-	are not remembered when the library module is loaded. This is
-	intentional. If it were otherwise, then compilation results
-	might vary depending on the order that libraries are loaded,
-	and that is too unpredictable.
-
-	It is said that some commercial compilers do allow macro
-	definitions to span library modules. That's just plain weird.
-
-    Width in %t Time Formats
-
-	Standard Verilog does not allow width fields in the %t formats
-	of display strings. For example, this is illegal:
-
-		$display("Time is %0t", %time);
-
-	Standard Verilog instead relies on the $timeformat to
-	completely specify the format.
-
-	Icarus Verilog allows the programmer to specify the field
-	width. The "%t" format in Icarus Verilog works exactly as it
-	does in standard Verilog. However, if the programmer chooses
-	to specify a minimum width (i.e., "%5t"), then for that display
-	Icarus Verilog will override the $timeformat minimum width and
-	use the explicit minimum width.
-
-    vpiScope iterator on vpiScope objects.
-
-	In the VPI, the normal way to iterate over vpiScope objects
-	contained within a vpiScope object, is the vpiInternalScope
-	iterator. Icarus Verilog adds support for the vpiScope
-	iterator of a vpiScope object, that iterates over *everything*
-	the is contained in the current scope. This is useful in cases
-	where one wants to iterate over all the objects in a scope
-	without iterating over all the contained types explicitly.
-
-    time 0 race resolution.
-
-	Combinational logic is routinely modeled using always
-	blocks. However, this can lead to race conditions if the
-	inputs to the combinational block are initialized in initial
-	statements. Icarus Verilog slightly modifies time 0 scheduling
-	by arranging for always statements with ANYEDGE sensitivity
-	lists to be scheduled before any other threads. This causes
-	combinational always blocks to be triggered when the values in
-	the sensitivity list are initialized by initial threads.
-
-    Nets with Types
-
-	Icarus Verilog support an extension syntax that allows nets
-	and regs to be explicitly typed. The currently supported types
-	are logic, bool and real. This implies that "logic" and "bool"
-	are new keywords. Typical syntax is:
-
-	wire real foo = 1.0;
-	reg logic bar, bat;
-
-	... and so forth. The syntax can be turned off by using the
-	-g2 flag to iverilog, and turned on explicitly with the -g2x
-	flag to iverilog.
-
-6.0 CREDITS
-
-Except where otherwise noted, Icarus Verilog, ivl and ivlpp are
-Copyright Stephen Williams. The proper notices are in the head of each
-file. However, I have early on received aid in the form of fixes,
-Verilog guidance, and especially testing from many people. Testers in
-particular include a larger community of people interested in a GPL
-Verilog for Linux.
-
@@ -1,335 +0,0 @@
-/*
- * Copyright (c) 1998-1999 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: Statement.cc,v 1.30 2007/05/24 04:07:11 steve Exp $"
-#endif
-
-# include "config.h"
-
-# include  "Statement.h"
-# include  "PExpr.h"
-
-Statement::~Statement()
-{
-}
-
-PAssign_::PAssign_(PExpr*lval, PExpr*ex)
-: event_(0), lval_(lval), rval_(ex)
-{
-      delay_ = 0;
-}
-
-PAssign_::PAssign_(PExpr*lval, PExpr*de, PExpr*ex)
-: event_(0), lval_(lval), rval_(ex)
-{
-      delay_ = de;
-}
-
-PAssign_::PAssign_(PExpr*lval, PEventStatement*ev, PExpr*ex)
-: event_(ev), lval_(lval), rval_(ex)
-{
-      delay_ = 0;
-}
-
-PAssign_::~PAssign_()
-{
-      delete lval_;
-      delete rval_;
-}
-
-PAssign::PAssign(PExpr*lval, PExpr*ex)
-: PAssign_(lval, ex)
-{
-}
-
-PAssign::PAssign(PExpr*lval, PExpr*d, PExpr*ex)
-: PAssign_(lval, d, ex)
-{
-}
-
-PAssign::PAssign(PExpr*lval, PEventStatement*d, PExpr*ex)
-: PAssign_(lval, d, ex)
-{
-}
-
-PAssign::~PAssign()
-{
-}
-
-PAssignNB::PAssignNB(PExpr*lval, PExpr*ex)
-: PAssign_(lval, ex)
-{
-}
-
-PAssignNB::PAssignNB(PExpr*lval, PExpr*d, PExpr*ex)
-: PAssign_(lval, d, ex)
-{
-}
-
-PAssignNB::~PAssignNB()
-{
-}
-
-PBlock::PBlock(perm_string n, BL_TYPE t, const svector<Statement*>&st)
-: name_(n), bl_type_(t), list_(st)
-{
-}
-
-PBlock::PBlock(BL_TYPE t, const svector<Statement*>&st)
-: bl_type_(t), list_(st)
-{
-}
-
-PBlock::PBlock(BL_TYPE t)
-: bl_type_(t)
-{
-}
-
-PBlock::~PBlock()
-{
-      for (unsigned idx = 0 ;  idx < list_.count() ;  idx += 1)
-	    delete list_[idx];
-}
-
-PCallTask::PCallTask(const pform_name_t&n, const svector<PExpr*>&p)
-: path_(n), parms_(p)
-{
-}
-
-PCallTask::PCallTask(perm_string n, const svector<PExpr*>&p)
-: parms_(p)
-{
-      path_.push_back(name_component_t(n));
-}
-
-PCallTask::~PCallTask()
-{
-}
-
-const pform_name_t& PCallTask::path() const
-{
-      return path_;
-}
-
-PCase::PCase(NetCase::TYPE t, PExpr*ex, svector<PCase::Item*>*l)
-: type_(t), expr_(ex), items_(l)
-{
-}
-
-PCase::~PCase()
-{
-      delete expr_;
-      for (unsigned idx = 0 ;  idx < items_->count() ;  idx += 1)
-	    if ((*items_)[idx]->stat) delete (*items_)[idx]->stat;
-
-      delete[]items_;
-}
-
-PCAssign::PCAssign(PExpr*l, PExpr*r)
-: lval_(l), expr_(r)
-{
-}
-
-PCAssign::~PCAssign()
-{
-      delete lval_;
-      delete expr_;
-}
-
-PCondit::PCondit(PExpr*ex, Statement*i, Statement*e)
-: expr_(ex), if_(i), else_(e)
-{
-}
-
-PCondit::~PCondit()
-{
-      delete expr_;
-      delete if_;
-      delete else_;
-}
-
-PDeassign::PDeassign(PExpr*l)
-: lval_(l)
-{
-}
-
-PDeassign::~PDeassign()
-{
-      delete lval_;
-}
-
-
-PDelayStatement::PDelayStatement(PExpr*d, Statement*st)
-: delay_(d), statement_(st)
-{
-}
-
-PDelayStatement::~PDelayStatement()
-{
-}
-
-PDisable::PDisable(const pform_name_t&sc)
-: scope_(sc)
-{
-}
-
-PDisable::~PDisable()
-{
-}
-
-PEventStatement::PEventStatement(const svector<PEEvent*>&ee)
-: expr_(ee), statement_(0)
-{
-      assert(expr_.count() > 0);
-}
-
-
-PEventStatement::PEventStatement(PEEvent*ee)
-: expr_(1), statement_(0)
-{
-      expr_[0] = ee;
-}
-
-PEventStatement::PEventStatement(void)
-: statement_(0)
-{
-}
-
-PEventStatement::~PEventStatement()
-{
-	// delete the events and the statement?
-}
-
-void PEventStatement::set_statement(Statement*st)
-{
-      statement_ = st;
-}
-
-PForce::PForce(PExpr*l, PExpr*r)
-: lval_(l), expr_(r)
-{
-}
-
-PForce::~PForce()
-{
-      delete lval_;
-      delete expr_;
-}
-
-PForever::PForever(Statement*s)
-: statement_(s)
-{
-}
-
-PForever::~PForever()
-{
-      delete statement_;
-}
-
-PForStatement::PForStatement(PExpr*n1, PExpr*e1, PExpr*cond,
-			     PExpr*n2, PExpr*e2, Statement*st)
-: name1_(n1), expr1_(e1), cond_(cond), name2_(n2), expr2_(e2),
-  statement_(st)
-{
-}
-
-PForStatement::~PForStatement()
-{
-}
-
-PProcess::~PProcess()
-{
-      delete statement_;
-}
-
-PRelease::PRelease(PExpr*l)
-: lval_(l)
-{
-}
-
-PRelease::~PRelease()
-{
-      delete lval_;
-}
-
-PRepeat::PRepeat(PExpr*e, Statement*s)
-: expr_(e), statement_(s)
-{
-}
-
-PRepeat::~PRepeat()
-{
-      delete expr_;
-      delete statement_;
-}
-
-PTrigger::PTrigger(const pform_name_t&e)
-: event_(e)
-{
-}
-
-PTrigger::~PTrigger()
-{
-}
-
-PWhile::PWhile(PExpr*e1, Statement*st)
-: cond_(e1), statement_(st)
-{
-}
-
-PWhile::~PWhile()
-{
-      delete cond_;
-      delete statement_;
-}
-
-/*
- * $Log: Statement.cc,v $
- * Revision 1.30  2007/05/24 04:07:11  steve
- *  Rework the heirarchical identifier parse syntax and pform
- *  to handle more general combinations of heirarch and bit selects.
- *
- * Revision 1.29  2004/02/18 17:11:54  steve
- *  Use perm_strings for named langiage items.
- *
- * Revision 1.28  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.27  2002/04/21 22:31:02  steve
- *  Redo handling of assignment internal delays.
- *  Leave it possible for them to be calculated
- *  at run time.
- *
- * Revision 1.26  2002/04/21 04:59:07  steve
- *  Add support for conbinational events by finding
- *  the inputs to expressions and some statements.
- *  Get case and assignment statements working.
- *
- * Revision 1.25  2001/12/03 04:47:14  steve
- *  Parser and pform use hierarchical names as hname_t
- *  objects instead of encoded strings.
- *
- * Revision 1.24  2001/11/22 06:20:59  steve
- *  Use NetScope instead of string for scope path.
- *
- * Revision 1.23  2001/07/25 03:10:48  steve
- *  Create a config.h.in file to hold all the config
- *  junk, and support gcc 3.0. (Stephan Boettcher)
- */
-
@@ -1,551 +0,0 @@
-#ifndef __Statement_H
-#define __Statement_H
-/*
- * Copyright (c) 1998-2000 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: Statement.h,v 1.44 2007/05/24 04:07:11 steve Exp $"
-#endif
-
-# include  <string>
-# include  "svector.h"
-# include  "StringHeap.h"
-# include  "PDelays.h"
-# include  "PExpr.h"
-# include  "HName.h"
-# include  "LineInfo.h"
-class PExpr;
-class Statement;
-class PEventStatement;
-class Design;
-class NetAssign_;
-class NetCAssign;
-class NetDeassign;
-class NetForce;
-class NetScope;
-
-/*
- * The PProcess is the root of a behavioral process. Each process gets
- * one of these, which contains its type (initial or always) and a
- * pointer to the single statement that is the process. A module may
- * have several concurrent processes.
- */
-class PProcess : public LineInfo {
-
-    public:
-      enum Type { PR_INITIAL, PR_ALWAYS };
-
-      PProcess(Type t, Statement*st)
-      : type_(t), statement_(st) { }
-
-      virtual ~PProcess();
-
-      bool elaborate(Design*des, NetScope*scope) const;
-
-      Type type() const { return type_; }
-      Statement*statement() { return statement_; }
-
-      map<perm_string,PExpr*> attributes;
-
-      virtual void dump(ostream&out, unsigned ind) const;
-
-    private:
-      Type type_;
-      Statement*statement_;
-};
-
-/*
- * The PProcess is a process, the Statement is the actual action. In
- * fact, the Statement class is abstract and represents all the
- * possible kinds of statements that exist in Verilog.
- */
-class Statement : public LineInfo {
-
-    public:
-      Statement() { }
-      virtual ~Statement() =0;
-
-      virtual void dump(ostream&out, unsigned ind) const;
-      virtual NetProc* elaborate(Design*des, NetScope*scope) const;
-      virtual void elaborate_scope(Design*des, NetScope*scope) const;
-};
-
-/*
- * Assignment statements of the various forms are handled by this
- * type. The rvalue is an expression. The lvalue needs to be figured
- * out by the parser as much as possible.
- */
-class PAssign_  : public Statement {
-    public:
-      explicit PAssign_(PExpr*lval, PExpr*ex);
-      explicit PAssign_(PExpr*lval, PExpr*de, PExpr*ex);
-      explicit PAssign_(PExpr*lval, PEventStatement*de, PExpr*ex);
-      virtual ~PAssign_() =0;
-
-      const PExpr* lval() const  { return lval_; }
-      const PExpr* rval() const  { return rval_; }
-
-    protected:
-      NetAssign_* elaborate_lval(Design*, NetScope*scope) const;
-
-      PExpr* delay_;
-      PEventStatement*event_;
-
-    private:
-      PExpr* lval_;
-      PExpr* rval_;
-};
-
-class PAssign  : public PAssign_ {
-
-    public:
-      explicit PAssign(PExpr*lval, PExpr*ex);
-      explicit PAssign(PExpr*lval, PExpr*de, PExpr*ex);
-      explicit PAssign(PExpr*lval, PEventStatement*de, PExpr*ex);
-      ~PAssign();
-
-      virtual void dump(ostream&out, unsigned ind) const;
-      virtual NetProc* elaborate(Design*des, NetScope*scope) const;
-
-    private:
-};
-
-class PAssignNB  : public PAssign_ {
-
-    public:
-      explicit PAssignNB(PExpr*lval, PExpr*ex);
-      explicit PAssignNB(PExpr*lval, PExpr*de, PExpr*ex);
-      ~PAssignNB();
-
-      virtual void dump(ostream&out, unsigned ind) const;
-      virtual NetProc* elaborate(Design*des, NetScope*scope) const;
-
-    private:
-      NetProc*assign_to_memory_(class NetMemory*, PExpr*,
-				Design*des, NetScope*scope) const;
-};
-
-/*
- * A block statement is an ordered list of statements that make up the
- * block. The block can be sequential or parallel, which only affects
- * how the block is interpreted. The parser collects the list of
- * statements before constructing this object, so it knows a priori
- * what is contained.
- */
-class PBlock  : public Statement {
-
-    public:
-      enum BL_TYPE { BL_SEQ, BL_PAR };
-
-      explicit PBlock(perm_string n, BL_TYPE t, const svector<Statement*>&st);
-      explicit PBlock(BL_TYPE t, const svector<Statement*>&st);
-      explicit PBlock(BL_TYPE t);
-      ~PBlock();
-
-      BL_TYPE bl_type() const { return bl_type_; }
-
-
-      virtual void dump(ostream&out, unsigned ind) const;
-      virtual NetProc* elaborate(Design*des, NetScope*scope) const;
-      virtual void elaborate_scope(Design*des, NetScope*scope) const;
-
-    private:
-      perm_string name_;
-      const BL_TYPE bl_type_;
-      svector<Statement*>list_;
-};
-
-class PCallTask  : public Statement {
-
-    public:
-      explicit PCallTask(const pform_name_t&n, const svector<PExpr*>&parms);
-      explicit PCallTask(perm_string n, const svector<PExpr*>&parms);
-      ~PCallTask();
-
-      const pform_name_t& path() const;
-
-      unsigned nparms() const { return parms_.count(); }
-
-      PExpr*&parm(unsigned idx)
-	    { assert(idx < parms_.count());
-	      return parms_[idx];
-	    }
-
-      PExpr* parm(unsigned idx) const
-	    { assert(idx < parms_.count());
-	      return parms_[idx];
-	    }
-
-      virtual void dump(ostream&out, unsigned ind) const;
-      virtual NetProc* elaborate(Design*des, NetScope*scope) const;
-
-    private:
-      NetProc* elaborate_sys(Design*des, NetScope*scope) const;
-      NetProc* elaborate_usr(Design*des, NetScope*scope) const;
-
-      pform_name_t path_;
-      svector<PExpr*> parms_;
-};
-
-class PCase  : public Statement {
-
-    public:
-      struct Item {
-	    svector<PExpr*>expr;
-	    Statement*stat;
-      };
-
-      PCase(NetCase::TYPE, PExpr*ex, svector<Item*>*);
-      ~PCase();
-
-      virtual NetProc* elaborate(Design*des, NetScope*scope) const;
-      virtual void elaborate_scope(Design*des, NetScope*scope) const;
-      virtual void dump(ostream&out, unsigned ind) const;
-
-    private:
-      NetCase::TYPE type_;
-      PExpr*expr_;
-
-      svector<Item*>*items_;
-
-    private: // not implemented
-      PCase(const PCase&);
-      PCase& operator= (const PCase&);
-};
-
-class PCAssign  : public Statement {
-
-    public:
-      explicit PCAssign(PExpr*l, PExpr*r);
-      ~PCAssign();
-
-      virtual NetCAssign* elaborate(Design*des, NetScope*scope) const;
-      virtual void dump(ostream&out, unsigned ind) const;
-
-    private:
-      PExpr*lval_;
-      PExpr*expr_;
-};
-
-class PCondit  : public Statement {
-
-    public:
-      PCondit(PExpr*ex, Statement*i, Statement*e);
-      ~PCondit();
-
-      virtual NetProc* elaborate(Design*des, NetScope*scope) const;
-      virtual void elaborate_scope(Design*des, NetScope*scope) const;
-      virtual void dump(ostream&out, unsigned ind) const;
-
-    private:
-      PExpr*expr_;
-      Statement*if_;
-      Statement*else_;
-
-    private: // not implemented
-      PCondit(const PCondit&);
-      PCondit& operator= (const PCondit&);
-};
-
-class PDeassign  : public Statement {
-
-    public:
-      explicit PDeassign(PExpr*l);
-      ~PDeassign();
-
-      virtual NetDeassign* elaborate(Design*des, NetScope*scope) const;
-      virtual void dump(ostream&out, unsigned ind) const;
-
-    private:
-      PExpr*lval_;
-};
-
-class PDelayStatement  : public Statement {
-
-    public:
-      PDelayStatement(PExpr*d, Statement*st);
-      ~PDelayStatement();
-
-      virtual void dump(ostream&out, unsigned ind) const;
-      virtual NetProc* elaborate(Design*des, NetScope*scope) const;
-      virtual void elaborate_scope(Design*des, NetScope*scope) const;
-
-    private:
-      PExpr*delay_;
-      Statement*statement_;
-};
-
-
-/*
- * This represents the parsing of a disable <scope> statement.
- */
-class PDisable  : public Statement {
-
-    public:
-      explicit PDisable(const pform_name_t&sc);
-      ~PDisable();
-
-      virtual void dump(ostream&out, unsigned ind) const;
-      virtual NetProc* elaborate(Design*des, NetScope*scope) const;
-
-    private:
-      pform_name_t scope_;
-};
-
-/*
- * The event statement represents the event delay in behavioral
- * code. It comes from such things as:
- *
- *      @name <statement>;
- *      @(expr) <statement>;
- *      @* <statement>;
- */
-class PEventStatement  : public Statement {
-
-    public:
-
-      explicit PEventStatement(const svector<PEEvent*>&ee);
-      explicit PEventStatement(PEEvent*ee);
-	// Make an @* statement.
-      explicit PEventStatement(void);
-
-      ~PEventStatement();
-
-      void set_statement(Statement*st);
-
-      virtual void dump(ostream&out, unsigned ind) const;
-      virtual NetProc* elaborate(Design*des, NetScope*scope) const;
-      virtual void elaborate_scope(Design*des, NetScope*scope) const;
-
-	// This method is used to elaborate, but attach a previously
-	// elaborated statement to the event.
-      NetProc* elaborate_st(Design*des, NetScope*scope, NetProc*st) const;
-
-      NetProc* elaborate_wait(Design*des, NetScope*scope, NetProc*st) const;
-
-    private:
-      svector<PEEvent*>expr_;
-      Statement*statement_;
-};
-
-class PForce  : public Statement {
-
-    public:
-      explicit PForce(PExpr*l, PExpr*r);
-      ~PForce();
-
-      virtual NetForce* elaborate(Design*des, NetScope*scope) const;
-      virtual void dump(ostream&out, unsigned ind) const;
-
-    private:
-      PExpr*lval_;
-      PExpr*expr_;
-};
-
-class PForever : public Statement {
-    public:
-      explicit PForever(Statement*s);
-      ~PForever();
-
-      virtual NetProc* elaborate(Design*des, NetScope*scope) const;
-      virtual void elaborate_scope(Design*des, NetScope*scope) const;
-      virtual void dump(ostream&out, unsigned ind) const;
-
-    private:
-      Statement*statement_;
-};
-
-class PForStatement  : public Statement {
-
-    public:
-      PForStatement(PExpr*n1, PExpr*e1, PExpr*cond,
-		    PExpr*n2, PExpr*e2, Statement*st);
-      ~PForStatement();
-
-      virtual NetProc* elaborate(Design*des, NetScope*scope) const;
-      virtual void elaborate_scope(Design*des, NetScope*scope) const;
-      virtual void dump(ostream&out, unsigned ind) const;
-
-    private:
-      PExpr* name1_;
-      PExpr* expr1_;
-
-      PExpr*cond_;
-
-      PExpr* name2_;
-      PExpr* expr2_;
-
-      Statement*statement_;
-};
-
-class PNoop  : public Statement {
-
-    public:
-      PNoop() { }
-      ~PNoop() { }
-};
-
-class PRepeat : public Statement {
-    public:
-      explicit PRepeat(PExpr*expr, Statement*s);
-      ~PRepeat();
-
-      virtual NetProc* elaborate(Design*des, NetScope*scope) const;
-      virtual void elaborate_scope(Design*des, NetScope*scope) const;
-      virtual void dump(ostream&out, unsigned ind) const;
-
-    private:
-      PExpr*expr_;
-      Statement*statement_;
-};
-
-class PRelease  : public Statement {
-
-    public:
-      explicit PRelease(PExpr*l);
-      ~PRelease();
-
-      virtual NetProc* elaborate(Design*des, NetScope*scope) const;
-      virtual void dump(ostream&out, unsigned ind) const;
-
-    private:
-      PExpr*lval_;
-};
-
-/*
- * The PTrigger statement sends a trigger to a named event. Take the
- * name here.
- */
-class PTrigger  : public Statement {
-
-    public:
-      explicit PTrigger(const pform_name_t&ev);
-      ~PTrigger();
-
-      virtual NetProc* elaborate(Design*des, NetScope*scope) const;
-      virtual void dump(ostream&out, unsigned ind) const;
-
-    private:
-      pform_name_t event_;
-};
-
-class PWhile  : public Statement {
-
-    public:
-      PWhile(PExpr*e1, Statement*st);
-      ~PWhile();
-
-      virtual NetProc* elaborate(Design*des, NetScope*scope) const;
-      virtual void elaborate_scope(Design*des, NetScope*scope) const;
-      virtual void dump(ostream&out, unsigned ind) const;
-
-    private:
-      PExpr*cond_;
-      Statement*statement_;
-};
-
-/*
- * $Log: Statement.h,v $
- * Revision 1.44  2007/05/24 04:07:11  steve
- *  Rework the heirarchical identifier parse syntax and pform
- *  to handle more general combinations of heirarch and bit selects.
- *
- * Revision 1.43  2007/03/05 05:59:10  steve
- *  Handle processes within generate loops.
- *
- * Revision 1.42  2005/12/05 21:21:18  steve
- *  Fixes for stubborn compilers.
- *
- * Revision 1.41  2004/12/11 02:31:25  steve
- *  Rework of internals to carry vectors through nexus instead
- *  of single bits. Make the ivl, tgt-vvp and vvp initial changes
- *  down this path.
- *
- * Revision 1.40  2004/02/20 18:53:33  steve
- *  Addtrbute keys are perm_strings.
- *
- * Revision 1.39  2004/02/18 17:11:54  steve
- *  Use perm_strings for named langiage items.
- *
- * Revision 1.38  2003/05/19 02:50:58  steve
- *  Implement the wait statement behaviorally instead of as nets.
- *
- * Revision 1.37  2003/01/30 16:23:07  steve
- *  Spelling fixes.
- *
- * Revision 1.36  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.35  2002/06/04 05:38:44  steve
- *  Add support for memory words in l-value of
- *  blocking assignments, and remove the special
- *  NetAssignMem class.
- *
- * Revision 1.34  2002/05/26 01:39:02  steve
- *  Carry Verilog 2001 attributes with processes,
- *  all the way through to the ivl_target API.
- *
- *  Divide signal reference counts between rval
- *  and lval references.
- *
- * Revision 1.33  2002/04/21 22:31:02  steve
- *  Redo handling of assignment internal delays.
- *  Leave it possible for them to be calculated
- *  at run time.
- *
- * Revision 1.32  2002/04/21 04:59:07  steve
- *  Add support for conbinational events by finding
- *  the inputs to expressions and some statements.
- *  Get case and assignment statements working.
- *
- * Revision 1.31  2001/12/03 04:47:14  steve
- *  Parser and pform use hierarchical names as hname_t
- *  objects instead of encoded strings.
- *
- * Revision 1.30  2001/11/22 06:20:59  steve
- *  Use NetScope instead of string for scope path.
- *
- * Revision 1.29  2000/09/09 15:21:26  steve
- *  move lval elaboration to PExpr virtual methods.
- *
- * Revision 1.28  2000/09/03 17:58:35  steve
- *  Change elaborate_lval to return NetAssign_ objects.
- *
- * Revision 1.27  2000/07/26 05:08:07  steve
- *  Parse disable statements to pform.
- *
- * Revision 1.26  2000/05/11 23:37:26  steve
- *  Add support for procedural continuous assignment.
- *
- * Revision 1.25  2000/04/22 04:20:19  steve
- *  Add support for force assignment.
- *
- * Revision 1.24  2000/04/12 04:23:57  steve
- *  Named events really should be expressed with PEIdent
- *  objects in the pform,
- *
- *  Handle named events within the mix of net events
- *  and edges. As a unified lot they get caught together.
- *  wait statements are broken into more complex statements
- *  that include a conditional.
- *
- *  Do not generate NetPEvent or NetNEvent objects in
- *  elaboration. NetEvent, NetEvWait and NetEvProbe
- *  take over those functions in the netlist.
- */
-#endif
@@ -1,206 +0,0 @@
-/*
- * Copyright (c) 2002-2004 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: StringHeap.cc,v 1.6 2004/02/18 17:11:54 steve Exp $"
-#endif
-
-# include  "StringHeap.h"
-#ifdef HAVE_MALLOC_H
-# include  <malloc.h>
-#endif
-# include  <stdlib.h>
-# include  <string.h>
-# include  <assert.h>
-
-StringHeap::StringHeap()
-{
-      cell_base_ = 0;
-      cell_ptr_ = HEAPCELL;
-      cell_count_ = 0;
-}
-
-StringHeap::~StringHeap()
-{
-	// This is a planned memory leak. The string heap is intended
-	// to hold permanently-allocated strings.
-}
-
-const char* StringHeap::add(const char*text)
-{
-      unsigned len = strlen(text);
-      assert((len+1) <= HEAPCELL);
-
-      unsigned rem = HEAPCELL - cell_ptr_;
-      if (rem < (len+1)) {
-	    cell_base_ = (char*)malloc(HEAPCELL);
-	    cell_ptr_ = 0;
-	    cell_count_ += 1;
-	    assert(cell_base_ != 0);
-      }
-
-      char*res = cell_base_ + cell_ptr_;
-      memcpy(res, text, len);
-      cell_ptr_ += len;
-      cell_base_[cell_ptr_++] = 0;
-
-      assert(cell_ptr_ <= HEAPCELL);
-
-      return res;
-}
-
-perm_string StringHeap::make(const char*text)
-{
-      return perm_string(add(text));
-}
-
-
-StringHeapLex::StringHeapLex()
-{
-      hit_count_ = 0;
-      add_count_ = 0;
-
-      for (unsigned idx = 0 ;  idx < HASH_SIZE ;  idx += 1)
-	    hash_table_[idx] = 0;
-}
-
-StringHeapLex::~StringHeapLex()
-{
-}
-
-unsigned StringHeapLex::add_hit_count() const
-{
-      return hit_count_;
-}
-
-unsigned StringHeapLex::add_count() const
-{
-      return add_count_;
-}
-
-static unsigned hash_string(const char*text)
-{
-      unsigned h = 0;
-
-      while (*text) {
-	    h = (h << 4) ^ (h >> 28) ^ *text;
-	    text += 1;
-      }
-      return h;
-}
-
-const char* StringHeapLex::add(const char*text)
-{
-      unsigned hash_value = hash_string(text) % HASH_SIZE;
-
-	/* If we easily find the string in the hash table, then return
-	   that and be done. */
-      if (hash_table_[hash_value]
-	  && (strcmp(hash_table_[hash_value], text) == 0)) {
-	    hit_count_ += 1;
-	    return hash_table_[hash_value];
-      }
-
-	/* The existing hash entry is not a match. Replace it with the
-	   newly allocated value, and return the new pointer as the
-	   result to the add. */
-      const char*res = StringHeap::add(text);
-      hash_table_[hash_value] = res;
-      add_count_ += 1;
-
-      return res;
-}
-
-perm_string StringHeapLex::make(const char*text)
-{
-      return perm_string(add(text));
-}
-
-perm_string StringHeapLex::make(const string&text)
-{
-      return perm_string(add(text.c_str()));
-}
-
-bool operator == (perm_string a, const char*b)
-{
-      if (a.str() == b)
-	    return true;
-
-      if (! (a.str() && b))
-	    return false;
-
-      if (strcmp(a.str(), b) == 0)
-	    return true;
-
-      return false;
-}
-
-bool operator == (perm_string a, perm_string b)
-{
-      return a == b.str();
-}
-
-bool operator != (perm_string a, const char*b)
-{
-      return ! (a == b);
-}
-
-bool operator != (perm_string a, perm_string b)
-{
-      return ! (a == b);
-}
-
-bool operator < (perm_string a, perm_string b)
-{
-      if (b.str() && !a.str())
-	    return true;
-
-      if (b.str() == a.str())
-	    return false;
-
-      if (strcmp(a.str(), b.str()) < 0)
-	    return true;
-
-      return false;
-}
-
-/*
- * $Log: StringHeap.cc,v $
- * Revision 1.6  2004/02/18 17:11:54  steve
- *  Use perm_strings for named langiage items.
- *
- * Revision 1.5  2003/03/01 06:25:30  steve
- *  Add the lex_strings string handler, and put
- *  scope names and system task/function names
- *  into this table. Also, permallocate event
- *  names from the beginning.
- *
- * Revision 1.4  2003/01/27 05:09:17  steve
- *  Spelling fixes.
- *
- * Revision 1.3  2003/01/16 21:44:46  steve
- *  Keep some debugging status.
- *
- * Revision 1.2  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.1  2002/08/04 19:13:16  steve
- *  dll uses StringHeap for named items.
- *
- */
-
@@ -1,147 +0,0 @@
-#ifndef __StringHeap_H
-#define __StringHeap_H
-/*
- * Copyright (c) 2002-2004 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: StringHeap.h,v 1.6 2005/06/14 19:13:43 steve Exp $"
-#endif
-
-# include  "config.h"
-# include  <string>
-
-using namespace std;
-
-class perm_string {
-
-    public:
-      perm_string() : text_(0) { }
-      perm_string(const perm_string&that) : text_(that.text_) { }
-      ~perm_string() { }
-
-      perm_string& operator = (const perm_string&that)
-      { text_ = that.text_; return *this; }
-
-      const char*str() const { return text_; }
-      operator const char* () const { return str(); }
-
-	// This is an escape for making perm_string objects out of
-	// literals. For example, per_string::literal("Label"); Please
-	// do *not* cheat and pass arbitrary const char* items here.
-      static perm_string literal(const char*t) { return perm_string(t); }
-
-    private:
-      friend class StringHeap;
-      friend class StringHeapLex;
-      perm_string(const char*t) : text_(t) { };
-
-    private:
-      const char*text_;
-};
-
-extern bool operator == (perm_string a, perm_string b);
-extern bool operator == (perm_string a, const char* b);
-extern bool operator != (perm_string a, perm_string b);
-extern bool operator != (perm_string a, const char* b);
-extern bool operator >  (perm_string a, perm_string b);
-extern bool operator <  (perm_string a, perm_string b);
-extern bool operator >= (perm_string a, perm_string b);
-extern bool operator <= (perm_string a, perm_string b);
-
-/*
- * The string heap is a way to permanently allocate strings
- * efficiently. They only take up the space of the string characters
- * and the terminating nul, there is no malloc overhead.
- */
-class StringHeap {
-
-    public:
-      StringHeap();
-      ~StringHeap();
-
-      const char*add(const char*);
-      perm_string make(const char*);
-
-    private:
-      enum { HEAPCELL = 0x10000 };
-
-      char*cell_base_;
-      unsigned cell_ptr_;
-      unsigned cell_count_;
-
-    private: // not implemented
-      StringHeap(const StringHeap&);
-      StringHeap& operator= (const StringHeap&);
-};
-
-/*
- * A lexical string heap is a string heap that makes an effort to
- * return the same pointer for identical strings. This saves further
- * space by not allocating duplicate strings, so in a system with lots
- * of identifiers, this can theoretically save more space.
- */
-class StringHeapLex  : private StringHeap {
-
-    public:
-      StringHeapLex();
-      ~StringHeapLex();
-
-      const char*add(const char*);
-      perm_string make(const char*);
-      perm_string make(const string&);
-
-      unsigned add_count() const;
-      unsigned add_hit_count() const;
-
-    private:
-      enum { HASH_SIZE = 4096 };
-      const char*hash_table_[HASH_SIZE];
-
-      unsigned add_count_;
-      unsigned hit_count_;
-
-    private: // not implemented
-      StringHeapLex(const StringHeapLex&);
-      StringHeapLex& operator= (const StringHeapLex&);
-};
-
-/*
- * $Log: StringHeap.h,v $
- * Revision 1.6  2005/06/14 19:13:43  steve
- *  gcc3/4 compile errors.
- *
- * Revision 1.5  2004/02/18 17:11:54  steve
- *  Use perm_strings for named langiage items.
- *
- * Revision 1.4  2003/03/01 06:25:30  steve
- *  Add the lex_strings string handler, and put
- *  scope names and system task/function names
- *  into this table. Also, permallocate event
- *  names from the beginning.
- *
- * Revision 1.3  2003/01/16 21:44:46  steve
- *  Keep some debugging status.
- *
- * Revision 1.2  2002/08/12 01:34:58  steve
- *  conditional ident string using autoconfig.
- *
- * Revision 1.1  2002/08/04 19:13:16  steve
- *  dll uses StringHeap for named items.
- *
- */
-#endif
@@ -1,129 +0,0 @@
-#ifndef PLI_TYPES
-#define PLI_TYPES
-/*
- * Copyright (c) 2003 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ifdef HAVE_CVS_IDENT
-#ident "$Id: _pli_types.h.in,v 1.8 2007/06/05 21:32:30 steve Exp $"
-#endif
-
-# undef HAVE_INTTYPES_H
-
-#ifdef HAVE_INTTYPES_H
-
-/*
- * If the host environment has the stdint.h header file,
- * then use that to size our PLI types.
- */
-#ifndef __STDC_FORMAT_MACROS
-# define __STDC_FORMAT_MACROS
-#endif
-
-# include  <inttypes.h>
-typedef uint64_t PLI_UINT64;
-typedef int64_t  PLI_INT64;
-typedef uint32_t PLI_UINT32;
-typedef int32_t  PLI_INT32;
-
-typedef signed short   PLI_INT16;
-typedef unsigned short PLI_UINT16;
-typedef char           PLI_BYTE8;
-typedef unsigned char  PLI_UBYTE8;
-
-# define PLI_UINT64_FMT PRIu64
-
-#else
-
-/*
- * If we do not have the c99 stdint.h header file, then use
- * configure detection to guess the pli types ourselves.
- */
-
-# define SIZEOF_UNSIGNED_LONG_LONG 8
-# define SIZEOF_UNSIGNED_LONG 8
-# define SIZEOF_UNSIGNED 4
-
-#if SIZEOF_UNSIGNED >= 8
-typedef unsigned PLI_UINT64;
-typedef int      PLI_INT64;
-# define PLI_UINT64_FMT "u"
-#else
-# if SIZEOF_UNSIGNED_LONG >= 8
-typedef unsigned long PLI_UINT64;
-typedef          long PLI_INT64;
-#  define PLI_UINT64_FMT "lu"
-# else
-#  if SIZEOF_UNSIGNED_LONG_LONG > SIZEOF_UNSIGNED_LONG
-typedef unsigned long long PLI_UINT64;
-typedef          long long PLI_INT64;
-#   define PLI_UINT64_FMT "llu"
-#  else
-typedef unsigned long PLI_UINT64;
-typedef          long PLI_INT64;
-#   define PLI_UINT64_FMT "lu"
-#  endif
-# endif
-#endif
-
-typedef signed int     PLI_INT32;
-typedef unsigned int   PLI_UINT32;
-typedef signed short   PLI_INT16;
-typedef unsigned short PLI_UINT16;
-typedef char           PLI_BYTE8;
-typedef unsigned char  PLI_UBYTE8;
-#endif
-
-/*
- * $Log: _pli_types.h.in,v $
- * Revision 1.8  2007/06/05 21:32:30  steve
- *  More standard PLI_BYTE8.
- *
- * Revision 1.7  2003/11/12 02:38:44  steve
- *  Clean up manual definitions of PLI_UINT64_FMT.
- *
- * Revision 1.6  2003/11/08 20:06:21  steve
- *  Spelling fixes in comments.
- *
- * Revision 1.5  2003/10/29 03:28:27  steve
- *  Add the PLU_UINT64_FMT string for formatting output.
- *
- * Revision 1.4  2003/10/29 03:23:12  steve
- *  Portably handle time format of VCD prints.
- *
- * Revision 1.3  2003/10/02 21:30:06  steve
- *  Use configured TIME_FMT in vcd dump printf.
- *
- * Revision 1.2  2003/10/02 19:33:44  steve
- *  Put libraries in libdir64.
- *
- * Revision 1.1  2003/09/30 01:33:13  steve
- *  Add PLI_UINT64 to _pli_types.h.
- *
- * Revision 1.2  2003/05/26 04:39:16  steve
- *  Typo type name.
- *
- * Revision 1.1  2003/02/17 06:39:47  steve
- *  Add at least minimal implementations for several
- *  acc_ functions. Add support for standard ACC
- *  string handling.
- *
- *  Add the _pli_types.h header file to carry the
- *  IEEE1364-2001 standard PLI type declarations.
- *
- */
-#endif
@@ -0,0 +1,248 @@
+
+Getting Started as a Contributor
+================================
+
+Icarus Verilog development is centered around the github repository at
+`github.com/steveicarus/iverilog <http://github.com/steveicarus/iverilog>`_.
+Contributing to Icarus Verilog requires a basic knowledge of git and github,
+so see the github documentation for more information. The sections below will
+step you through the basics of getting the source code from github, making a
+branch, and submitting a pull request for review.
+
+Getting Icarus Verilog
+----------------------
+
+To start, you will need to clone the code. It is preferred that you use the
+"ssh" method, and the ssh based clone with the command:
+
+.. code-block:: console
+
+  % git clone [email protected]:steveicarus/iverilog.git
+
+This assumes that you have a github account (accounts are free) and you have
+set up your ssh authentication keys. See the
+`Authentication Guides here <https://docs.github.com/en/authentication>`_.
+
+The "git clone" command will get you all the source:
+
+.. code-block:: console
+
+  % git clone [email protected]:steveicarus/iverilog.git
+  Cloning into 'iverilog'...
+  remote: Enumerating objects: 66234, done.
+  remote: Counting objects: 100% (6472/6472), done.
+  remote: Compressing objects: 100% (4123/4123), done.
+  remote: Total 66234 (delta 2412), reused 6039 (delta 2190), pack-reused 59762
+  Receiving objects: 100% (66234/66234), 27.98 MiB | 2.53 MiB/s, done.
+  Resolving deltas: 100% (50234/50234), done.
+  % cd iverilog/
+
+Normally, this is enough as you are now pointing at the most current
+development code, and you have implicitly created a branch "master" that
+tracks the development head. However, If you want to actually be working on a
+specific version, say for example version 11, the v11-branch, you checkout
+that branch with the command:
+
+.. code-block:: console
+
+  % git checkout --track -b v11-branch origin/v11-branch
+
+This creates a local branch that tracks the v11-branch in the repository, and
+switches you over to your new v11-branch. The tracking is important as it
+causes pulls from the repository to re-merge your local branch with the remote
+v11-branch. You always work on a local branch, then merge only when you
+push/pull from the remote repository.
+
+Now that you've cloned the repository and optionally selected the branch you
+want to work on, your local source tree may later be synced up with the
+development source by using the git command:
+
+.. code-block:: console
+
+  % git pull
+  Already up to date.
+
+Finally, configuration files are built by the extra step:
+
+.. code-block:: console
+
+  % sh autoconf.sh
+  Autoconf in root...
+  Precompiling lexor_keyword.gperf
+  Precompiling vhdlpp/lexor_keyword.gperf
+
+You will need autoconf and gperf installed in order for the script to work.
+If you get errors such as:
+
+.. code-block:: console
+
+  % sh autoconf.sh
+  Autoconf in root...
+  autoconf.sh: 10: autoconf: not found
+  Precompiling lexor_keyword.gperf
+  autoconf.sh: 13: gperf: not found.
+
+You will need to install download and install the autoconf and gperf tools.
+
+Now you are ready to configure and compile the source.
+
+Icarus Specific Configuration Options
+-------------------------------------
+
+Icarus takes many of the standard configuration options and those will not be
+described here. The following are specific to Icarus Verilog:
+
+.. code-block:: none
+
+  --enable-suffix[=suffix]
+
+This option allows the user to build Icarus with a default suffix or when
+provided a user defined suffix. All programs or directories are tagged with
+this suffix. e.g.(iverilog-0.8, vvp-0.8, etc.). The output of iverilog will
+reference the correct run time files and directories. The run time will check
+that it is running a file with a compatible version e.g.(you can not run a
+V0.9 file with the V0.8 run time).
+
+.. code-block:: none
+
+  --enable-libvvp
+
+The vvp program is built as a small stub linked to a shared library,
+libvvp.so, that may be linked with other programs so that they can host
+a vvp simulation.
+
+.. code-block:: none
+
+  --enable-libveriuser
+
+PLI version 1 (the ACC and TF routines) were deprecated in IEEE 1364-2005.
+These are supported in Icarus Verilog by the libveriuser library and cadpli
+module. Starting with v13, these will only be built if this option is used.
+
+A debug options is:
+
+.. code-block:: none
+
+  --with-valgrind
+
+This option adds extra memory cleanup code and pool management code to allow
+better memory leak checking when valgrind is available. This option is not
+needed when checking for basic errors with valgrind.
+
+Compiling on Linux
+------------------
+
+(Note: You will need to install bison, flex, g++ and gcc) This is probably the
+easiest step. Given that you have the source tree from the above instructions,
+the compile and install is generally as simple as:
+
+.. code-block:: console
+
+  % ./configure
+  configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
+  checking build system type... x86_64-unknown-linux-gnu
+  checking host system type... x86_64-unknown-linux-gnu
+  checking for gcc... gcc
+  checking whether the C compiler works... yes
+  checking for C compiler default output file name... a.out
+  checking for suffix of executables...
+  [...and so on...]
+
+  % make
+  mkdir dep
+  Using git-describe for VERSION_TAG
+  g++ -DHAVE_CONFIG_H -I. -Ilibmisc  -Wall -Wextra -Wshadow   -g -O2 -MD -c main.cc -o main.o
+  mv main.d dep/main.d
+  g++ -DHAVE_CONFIG_H -I. -Ilibmisc  -Wall -Wextra -Wshadow   -g -O2 -MD -c async.cc -o async.o
+  mv async.d dep/async.d
+  g++ -DHAVE_CONFIG_H -I. -Ilibmisc  -Wall -Wextra -Wshadow   -g -O2 -MD -c design_dump.cc -o design_dump.o
+  mv design_dump.d dep/design_dump.d
+  g++ -DHAVE_CONFIG_H -I. -Ilibmisc  -Wall -Wextra -Wshadow   -g -O2 -MD -c discipline.cc -o discipline.o
+  [...and so on...]
+
+The end result is a complete build of Icarus Verilog. You can install your
+compiled version with a command like this:
+
+.. code-block:: console
+
+  % sudo make install
+
+Regression Tests
+----------------
+
+Icarus Verilog comes with a fairly extensive regression test suite. As of
+2022, that test suite is included with the source in the "ivtest"
+directory. Contained in that directory are a couple driver scripts that run
+all the regression tests on the installed version of Icarus Verilog. So for
+example:
+
+.. code-block:: console
+
+  % cd ivtest
+  % ./vvp_reg.pl
+  % ./vvp_reg.py
+  % ./vpi_reg.pl
+
+will run all the regression tests for the simulation engine. (This is what
+most people will want to do.) You should rerun these tests before submitting
+patches to the developers. Also, if you are adding a new feature, you should
+add test programs to the regression test suite to validate your new feature
+(or bug fix.). The python script is the preferred method to add new tests.
+
+All of these scripts take other options to test various configurations. What
+options are supported can be found by using the ``-h/--help`` argument. There
+is also a separate ``vlog95_reg.pl`` script for testing the vlog95 translation
+of the original tests. This is integrated into the existing Python test script
+for the new tests.
+
+Note that pull requests will be required to pass these regression tests before
+being merged.
+
+Forks, Branches and Pull Requests
+---------------------------------
+
+Currently, the preferred way to submit patches to Icarus Verilog is via pull
+requests.
+`Pull requests <https://docs.github.com/en/github-ae@latest/pull-requests>`_
+can be created from the main repository if you have write access (very few
+people have write access) or more commonly from a fork, so the first step is
+to create a fork that you can work with. It is easy enough to create a fork,
+just go to the
+`github.com/steveicarus/iverilog <http://github.com/steveicarus/iverilog>`_
+page and use the "fork" button in the upper right corner. This will create
+a new repository that you can clone instead of the steveicarus/iverilog
+repository. You then use your local repository to create feature branches,
+then submit them for inclusion in the main repository as pull
+requests. Remember to `synchronize your fork
+<https://docs.github.com/en/github-ae@latest/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork>`_
+periodically with the main repository. This will make sure your work is based
+on the latest upstream and avoid merge conflicts.
+
+Create your patch by first creating a branch that contains your commits:
+
+.. code-block:: console
+
+  % git checkout -b my-github-id/branch-name
+
+We are encouraging using this scheme for naming your branches that are
+destined for pull requests. Use your github id in the branch name. So for
+example:
+
+.. code-block:: console
+
+  % git checkout -b steveicarus/foo-feature
+
+Do your work in this branch, then when you are ready to create a pull request,
+first push the branch up to github:
+
+.. code-block:: console
+
+  % git push -u origin my-github-id/branch-name
+
+Then go to github.com to create your pull request. `Create your pull request
+against the "master" branch of the upstream repository
+<https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork>`_,
+or the version branch that you are working on. Your pull request will be run
+through continuous integration, and reviewed by one of the main
+authors. Feedback may be offered to your PR, and once accepted, an approved
+individual will merge it for you. Then you are done.
@@ -1,4 +1,7 @@

+Glossary
+========
+
 Throughout Icarus Verilog descriptions and source code, I use a
 variety of terms and acronyms that might be specific to Icarus
 Verilog, have an Icarus Verilog specific meaning, or just aren't
@@ -22,7 +25,7 @@ UDP     - User Defined Primitive
    syntax for defining them is described in the LRM.


-VPI     -
+VPI     - Verilog Procedural Interface
    This is the C API that is defined by the Verilog standard, and
    that Icarus Verilog partially implements. See also PLI.

@@ -34,6 +37,12 @@ VVM     - Verilog Virtual Machine

 VVP     - Verilog Virtual Processor
    This is the Icarus Verilog runtime that reads in custom code in a
-    form that I call "VVP Assembly". See the vvp/ directory for
-    documentation on that.
+    form that I call "VVP Assembly".

+LPM     - Library of Parameterized Modules
+    LPM (Library of Parameterized Modules) is EIS-IS standard 103-A. It is
+    a standard library of abstract devices that are designed to be close
+    enough to the target hardware to be easily translated, yet abstract
+    enough to support a variety of target technologies without excessive
+    constraints. Icarus Verilog uses LPM internally to represent idealized
+    hardware, especially when doing target neutral synthesis.
@@ -1,8 +1,6 @@

-CADENCE PLI1 MODULES
-
-   Copyright 2003 Stephen Williams
-   $Id: cadpli.txt,v 1.2 2003/02/17 00:01:25 steve Exp $
+Cadence PLI1 Modules
+====================

 With the cadpli module, Icarus Verilog is able to load PLI1
 applications that were compiled and linked to be dynamic loaded by
@@ -18,7 +16,7 @@ is invoked by the usual -m flag to iverilog or vvp. This module in
 turn scans the extended arguments, looking for +cadpli= arguments. The
 latter specify the share object and bootstrap function for running the
 module. For example, to run the module product.so, that has the
-bootstrap function "my_boot":
+bootstrap function "my_boot"::

    vvp -mcadpli a.out -cadpli=./product.so:my_boot

@@ -34,15 +32,3 @@ the +loadpli1= argument to Verilog-XL.
 The integration from this point is seamless. The PLI application
 hardly knows that it is being invoked by Icarus Verilog instead of
 Verilog-XL, so operates as it would otherwise.
-
-$Log: cadpli.txt,v $
-Revision 1.2  2003/02/17 00:01:25  steve
- Use a variant of ivl_dlfcn to do dynamic loading
- from within the cadpli module.
-
- Change the +cadpli flag to -cadpli, to keep the
- plusargs namespace clear.
-
-Revision 1.1  2003/02/16 02:44:47  steve
- Add the cadpli HOWTO.
-
@@ -0,0 +1,169 @@
+
+Developer Guide
+===============
+
+The developer guide is intended to give you a gross structure of the
+Icarus Verilog compiler source. This will help orient you to the
+source code itself, so that you can find the global parts where you
+can look for even better detail.
+
+The documentation for getting, building and installing Icarus Verilog
+is kept and maintained at :doc:`Getting Started as a Contributor <../getting_started>`
+
+See the Installation Guide for getting the current source from the git
+repository (and how to use the git repository) and see the Developer Guide
+for instructions on participating in the Icarus Verilog development process.
+That information will not be repeated here.
+
+Scroll down to a listing with further readings.
+
+Compiler Components
+-------------------
+
+- The compiler driver (driver/)
+
+This is the binary that is installed as "iverilog". This program takes
+the command line arguments and assembles invocations of all the other
+subcommands to perform the steps of compilation.
+
+- The preprocessor (ivlpp/)
+
+This implements the Verilog pre-processor. In Icarus Verilog, the
+compiler directives \`define, \`include, \`ifdef and etc. are implemented
+in an external program. The ivlpp/ directory contains the source for
+this program.
+
+- The core compiler (root directory)
+
+The "ivl" program is the core that does all the Verilog compiler
+processing that is not handled elsewhere. This is the main core of the
+Icarus Verilog compiler, not the runtime. See below for more details
+on the core itself.
+
+- The loadable code generators (tgt-\*/)
+
+This core compiler, after it is finished with parsing and semantic
+analysis, uses loadable code generators to emit code for supported
+targets. The tgt-\*/ directories contains the source for the target
+code generators that are bundled with Icarus Verilog. The tgt-vvp/
+directory in particular contains the code generator for the vvp
+runtime.
+
+
+Runtime Components
+------------------
+
+- The vvp runtime (vvp/)
+
+This program implements the runtime environment for Icarus
+Verilog. It implements the "vvp" command described in the user
+documentation. See the vvp/ subdirectory for further developer
+documentation.
+
+- The system tasks implementations (vpi/)
+
+The standard Verilog system tasks are implemented using VPI (PLI-2)
+and the source is in this subdirectory.
+
+- The PLI-1 compatibility library (libveriuser/)
+
+The Icarus Verilog support for the deprecated PLI-1 is in this
+subdirectory. The vvp runtime does not directly support the
+PLI-1. Instead, the libveriuser library emulates it using the builtin
+PLI-2 support.
+
+- The Cadence PLI module compatibility module (cadpli/)
+
+It is possible in some specialized situations to load and execute
+PLI-1 code written for Verilog-XL. This directory contains the source
+for the module that provides the Cadence PLI interface.
+
+
+The Core Compiler
+-----------------
+
+The "ivl" binary is the core compiler that does the heavy lifting of
+compiling the Verilog source (including libraries) and generating the
+output. This is the most complex component of the Icarus Verilog
+compilation system.
+
+The process in the abstract starts with the Verilog lexical analysis
+and parsing to generate an internal "pform". The pform is then
+translated by elaboration into the "netlist" form. The netlist is
+processed by some functors (which include some optimizations and
+optional synthesis) then is translated into the ivl_target internal
+form. And finally, the ivl_target form is passed via the ivl_target.h
+API to the code generators.
+
+- Lexical Analysis
+
+Lexical analysis and parsing use the tools "flex", "gperf", and
+"bison". The "flex" input file "lexor.lex" recognizes the tokens in
+the input stream. This is called "lexical analysis". The lexical
+analyzer also does some processing of compiler directives that are not
+otherwise taken care of by the external preprocessor. The lexical
+analyzer uses a table of keywords that is generated using the "gperf"
+program and the input file "lexor_keywords.gperf". This table allows
+the lexical analyzer to efficiently check input words with the rather
+large set of potential keywords.
+
+- Parsing
+
+The parser input file "parse.y" is passed to the "bison" program to
+generate the parser. The parser uses the functions in parse*.h,
+parse*.cc, pform.h, and pform*.cc to generate the pform from the
+stream of input tokens. The pform is what compiler writers call a
+"decorated parse tree".
+
+The pform itself is described by the classes in the header files
+"PScope.h", "Module.h", "PGenerate.h", "Statement.h", and
+"PExpr.h". The implementations of the classes in those header files
+are in the similarly named C++ files.
+
+- Elaboration
+
+Elaboration transforms the pform to the netlist form. Elaboration is
+conceptually divided into several major steps: Scope elaboration,
+parameter overrides and defparam propagation, signal elaboration, and
+statement and expression elaboration.
+
+The elaboration of scopes and parameter overrides and defparam
+propagation are conceptually separate, but are in practice
+intermingled. The elaboration of scopes scans the pform to find and
+instantiate all the scopes of the design. New scopes are created by
+instantiation of modules (starting with the root instances) by user
+defined tasks and functions, named blocks, and generate schemes. The
+elaborate_scope methods implement scope elaboration, and the
+elab_scope.cc source file has the implementations of those
+methods.
+
+The elaborate.cc source file contains the initial calls to the
+elaborate_scope for the root scopes to get the process started. In
+particular, see the "elaborate" function near the bottom of the
+elaborate.cc source file. The calls to Design::make_root_scope create
+the initial root scopes, and the creation and enqueue of the
+elaborate_root_scope_t work items primes the scope elaboration work
+list.
+
+Intermingled in the work list are defparms work items that call the
+Design::run_defparams and Design::evaluate_parameters methods that
+override and evaluate parameters. The override and evaluation of
+parameters must be intermingled with the elaboration of scopes because
+the exact values of parameters may impact the scopes created (imagine
+generate schemes and instance arrays) and the created scopes in turn
+create new parameters that need override and evaluation.
+
+Further Reading
+---------------
+
+For further information on the individual parts of Icarus Verilog, see this listing:
+
+.. toctree::
+   :maxdepth: 2
+
+   ivl/index
+   vvp/index
+   tgt-vvp/tgt-vvp
+   vpi/index
+   cadpli/cadpli
+   misc/index
@@ -1,14 +1,19 @@

-ATTRIBUTE NAMING CONVENTIONS
+Icarus Verilog Attributes
+=========================
+
+Attribute Naming Conventions
+----------------------------

 Attributes that are specific to Icarus Verilog, and are intended to be
-of use to programmers, start with the prefix "ivl_".
+of use to programmers, start with the prefix "ivl\_".

 Attributes with the "_ivl_" prefix are set aside for internal
 use. They may be generated internally by the compiler. They need not
 be documented here.

-ATTRIBUTES TO CONTROL SYNTHESIS
+Attributes To Control Synthesis
+-------------------------------

 The following is a summary of Verilog attributes that Icarus Verilog
 understands within Verilog source files to control synthesis
@@ -23,7 +28,7 @@ warning.)

 * Attributes for "always" and "initial" statements

-(* ivl_combinational *)
+(\* ivl_combinational \*)

    This attribute tells the compiler that the statement models
    combinational logic. If the compiler finds that it cannot make
@@ -34,14 +39,14 @@ warning.)
    latches or flip-flops where the user intended combinational
    logic.

-(* ivl_synthesis_on *)
+(\* ivl_synthesis_on \*)

    This attribute tells the compiler that the marked always statement
    is synthesizable. The compiler will attempt to synthesize the
    code in the marked "always" statement. If it cannot in any way
    synthesize it, then it will report an error.

-(* ivl_synthesis_off *)
+(\* ivl_synthesis_off \*)

    If this value is attached to an "always" statement, then the
    compiler will *not* synthesize the "always" statement. This can be
@@ -50,7 +55,7 @@ warning.)

 * Attributes for modules

-(* ivl_synthesis_cell *)
+(\* ivl_synthesis_cell \*)

    If this value is attached to a module during synthesis, that
    module will be considered a target architecture primitive, and
@@ -60,7 +65,7 @@ warning.)

 * Attributes for signals (wire/reg/integer/tri/etc.)

-(* PAD = "<pad assignment list>" *)
+(\* PAD = "<pad assignment list>" \*)

    If this attribute is attached to a signal that happens to be a
    root module port, then targets that support it will use the string
@@ -73,9 +78,10 @@ warning.)
 [ none defined yet ]


-MISC
+Misc
+----

-(* _ivl_schedule_push *)
+(\* _ivl_schedule_push \*)

    If this attribute is attached to a thread object (always or
    initial statement) then the vvp code generator will generate code
@@ -0,0 +1,12 @@
+
+IVL - The Core Compiler
+=======================
+
+.. toctree::
+   :maxdepth: 1
+
+   netlist
+   attributes
+   ivl_target
+   lpm
+   t-dll
@@ -0,0 +1,131 @@
+
+Loadable Target API (ivl_target)
+================================
+
+In addition to the standard VPI API, Icarus Verilog supports a non-standard
+loadable target module API. This API helps C programmers write modules that
+Icarus Verilog can use to generate code. These modules are used at compile
+time to write the elaborated design to the simulation or netlist files. For
+example, the vvp code generator is a loadable target module that writes vvp
+code into the specified file.
+
+Loadable target modules gain access to the 'elaborated' design. That means,
+the source files have been checked for syntax and correctness, any synthesis
+and general optimization steps have been performed, and what is left is a
+design that reflects but is not exactly the same as the input Verilog source
+code. This relieves the modules of the burden of supporting all the odd
+corners and complexities of the Verilog language.
+
+The Target Module API
+---------------------
+
+The API is defined in the header file "ivl_target.h" which is installed with
+Icarus Verilog. The header defines the functions that the module writer can
+use to get at the elaborated design during the course of writing the output
+format.
+
+The target module API function "target_design" is special in that the API does
+not provide this function: The target module itself provides it. When the
+compiler loads the target module, it invokes the "target_design" function with
+a handle to the design. This is the point where the target module takes over
+to process the design.
+
+Compiling Target Modules
+------------------------
+
+Compiling loadable target modules is similar to compiling VPI modules, in that
+the module must be compiled with the "-fPIC" flag to gcc, and linked with the
+"-shared" flag. The module that you compile is then installed in a place where
+the "iverilog" command can find it, and configuration files are adjusted to
+account for the new module.
+
+This code::
+
+  # include  <ivl_target.h>
+
+  int target_design(ivl_design_t des)
+  {
+       return 0;
+  }
+
+is an example module that we can write into the file "empty.c"; and let us
+compile it into the module file "empty.tgt" like so::
+
+  % gcc -o empty.tgt -fpic -shared empty.c
+
+This makes the "empty.tgt" file an a dynamically loaded shared object.
+
+Creating the Target Config File
+-------------------------------
+
+The target config file tells the Icarus Verilog core how to process your new
+code generator. The ivl core expects two configuration files: the name.conf
+and the name-s.config files. The "-s" version is what is used if the user
+gives the "-S" (synthesis) flag on the command line.
+
+The stub target, included in most distributions, demonstrates the config
+files. The "stub.conf" file is::
+
+  functor:cprop
+  functor:nodangle
+  -t:dll
+  flag:DLL=stub.tgt
+
+and the "stub-s.conf" file is::
+
+  functor:synth2
+  functor:synth
+  functor:syn-rules
+  functor:cprop
+  functor:nodangle
+  -t:dll
+  flag:DLL=stub.tgt
+
+Note that the "stub-s.conf" file contains more lines to invoke internal
+synthesis functions, whereas the "stub.conf" invokes only the basic
+optimization steps.
+
+In general, only the last line (The "flag:DLL=<name>.tgt" record) varies for
+each target. For your target, replace the <name> with the name of your target
+and you have a configuration file ready to install. Note that this is the name
+of your target module. This is in fact how the config file tells the compiler
+the name of your module.
+
+The rest of the config file is best taken as boiler plate and installed as is,
+with one difference. If your target is a synthesis target (for example a mosis
+code generator or a pld code generator) that expects synthesis to happen, then
+it makes the most sense to create both your config file like the "stub-s.conf"
+config file. This causes the compiler to do synthesis for your target whether
+the user gives the "-S" flag or not.
+
+Installing the Target Module
+----------------------------
+
+Finally, the "empty.conf", the "empty-s.conf" and the "empty.tgt" files need
+to be installed. Where they go depends on your system, but in Linux they are
+normally installed in "/usr/lib/ivl".
+
+
+LPM Devices
+-----------
+
+All LPM devices support a small set of common LPM functions, as
+described in the ivl_target header file. The ivl_lpm_t object has a
+type enumerated by ivl_lpm_type_t, and that type is accessible via the
+ivl_lpm_type function.
+
+The following are type specific aspects of LPM devices.
+
+* IVL_LPM_UFUNC
+
+This LPM represents a user defined function. It is a way to connect
+behavioral code into a structural network. The UFUNC device has a
+vector output and a set of inputs. The ivl_lpm_define function returns
+the definition as an ivl_scope_t object.
+
+The output vector is accessible through the ivl_lpm_q, and the output
+has the width defined by ivl_lpm_width. This similar to most every
+other LPM device with outputs.
+
+There are ivl_lpm_size() input ports, each with the width
+ivl_lpm_data2_width(). The actual nexus is indexed by ivl_lpm_data2().
@@ -1,5 +1,6 @@

-WHAT IS LPM
+What Is LPM
+===========

 LPM (Library of Parameterized Modules) is EIS-IS standard 103-A. It is
 a standard library of abstract devices that are designed to be close
@@ -13,11 +14,12 @@ generates, because the LPM devices are translated into technology
 specific devices by the final code generator or target specific
 optimizers.

-INTERNAL USES OF LPM
+Internal Uses Of LPM
+--------------------

 Internally, Icarus Verilog uses LPM devices to represent the design in
 abstract, especially when synthesizing such functions as addition,
-flip-flops, etc. The ``synth'' functor generates LPM modules when
+flip-flops, etc. The `synth` functor generates LPM modules when
 interpreting procedural constructs. The functor generates the LPM
 objects needed to replace a behavioral description, and uses
 attributes to tag the devices with LPM properties.
@@ -1,28 +1,6 @@
-/*
- * Copyright (c) 1998-1999 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
-#ident "$Id: netlist.txt,v 1.10 2000/07/23 18:06:15 steve Exp $"

-
-Note that the netlist.h header contains detailed descriptions of how
-things work. This is just an overview.
-
-NETLIST FORMAT
+Netlist Format
+==============

 The output from the parse and elaboration steps is a "netlist" rooted
 in a Design object. Parsing translates the design described in the
@@ -36,7 +14,8 @@ translating it to a (hopefully) better netlist after each step. The
 complete netlist is then passed to the code generator, the emit
 function, where the final code (in the target format) is produced.

-STRUCTURAL ITEMS: NetNode and NetNet
+Structural Items: NetNode and NetNet
+------------------------------------

 Components and wires, memories and registers all at their base are
 either NetNode objects or NetNet objects. Even these classes are
@@ -57,7 +36,8 @@ destructors for nets and nodes automatically arrange for pins to be
 disconnected when the item is deleted, so that the netlist can be
 changed during processing.

-STRUCTURAL LINKS
+Structural Links
+----------------

 The NetNode and NetNet classes contain arrays of Link objects, one
 object per pin. Each pin is a single bit. The Link objects link to all
@@ -89,12 +69,13 @@ Currently, a link has 3 possible direction properties:
 		   three-state.)


-BEHAVIORAL ITEMS: NetProcTop, NetProc and derived classes
+Behavioral Items: NetProcTop, NetProc and derived classes
+---------------------------------------------------------

 Behavioral items are not in general linked to the netlist. Instead,
 they represent elaborated behavioral statements. The type of the object
 implies what the behavior of the statement does. For example, a
-NetCondit object represents an ``if'' statement, and carries a
+NetCondit object represents an `if` statement, and carries a
 condition expression and up to two alternative sub-statements.

 At the root of a process is a NetProcTop object. This class carries a
@@ -105,7 +86,8 @@ tree is the NetProcTop object. The Design class keeps a list of the
 elaborated NetProcTop objects. That list represents the list of
 processes in the design.

-INTERACTION OF BEHAVIORAL AND STRUCTURAL: NetAssign_
+Interaction Of Behavioral And Structural: NetAssign\_
+-----------------------------------------------------

 The behavioral statements in a Verilog design effect the structural
 aspects through assignments to registers. Registers are structural
@@ -114,26 +96,27 @@ statement through pins. This implies that the l-value of an assignment
 is structural. It also implies that the statement itself is
 structural, and indeed it is derived from NetNode.

-The NetAssign_ class is also derived from the NetProc class because
+The NetAssign\_ class is also derived from the NetProc class because
 what it does is brought on by executing the process. By multiple
 inheritance we have therefore that the assignment is both a NetNode
-and a NetProc. The NetAssign_ node has pins that represent the l-value
+and a NetProc. The NetAssign\_ node has pins that represent the l-value
 of the statement, and carries behavioral expressions that represent
 the r-value of the assignment.

-MEMORIES
+Memories
+--------

 The netlist form includes the NetMemory type to hold the content of a
 memory. Instances of this type represent the declaration of a memory,
 and occur once for each memory. References to the memory are managed
-by the NetEMemory and NetAssignMem_ classes.
+by the NetEMemory and NetAssignMem\_ classes.

 An instance of the NetEMemory class is created whenever a procedural
 expression references a memory element. The operand is the index to
 use to address (and read) the memory.

-An instance of the NetAssignMem_ class is created when there is a
-procedural assignment to the memory. The NetAssignMem_ object
+An instance of the NetAssignMem\_ class is created when there is a
+procedural assignment to the memory. The NetAssignMem\_ object
 represents the l-value reference (a write) to the memory. As with the
 NetEMemory class, this is a procedural reference only.

@@ -144,13 +127,14 @@ unconnected for now, because memories cannot appear is l-values of
 continuous assignments. However, the synthesis functor may connect
 signals to the write control lines to get a fully operational RAM.

-By the time elaboration completes, there may be many NetAssignMem_,
+By the time elaboration completes, there may be many NetAssignMem\_,
 NetEMemory and NetRamDq objects referencing the same NetMemory
 object. Each represents a port into the memory. It is up to the
 synthesis steps (and the target code) to figure out what to do with
 these ports.

-EXPRESSIONS
+Expressions
+-----------

 Expressions are represented as a tree of NetExpr nodes. The NetExpr
 base class contains the core methods that represent an expression
@@ -169,7 +153,8 @@ However, typical expressions the behavioral description are
 represented as a tree of NetExpr nodes. The derived class of the node
 encodes what kind of operator the node represents.

-EXPRESSION BIT WIDTH
+Expression Bit Width
+--------------------

 The expression (represented by the NetExpr class) has a bit width that
 it either explicitly specified, or implied by context or contents.
@@ -201,14 +186,17 @@ determined and please adapt. If the expression cannot reasonably
 adapt, it will return false. Otherwise, it will adjust bit widths and
 return true.

-XXXX I do not yet properly deal with cases where elaboration knows for
-XXXX certain that the bit width does not matter. In this case, I
-XXXX really should tell the expression node about it so that it can
-XXXX pick a practical (and optimal) width.
+::

-INTERACTION OF EXPRESSIONS AND STRUCTURE: NetESignal
+    I do not yet properly deal with cases where elaboration knows for
+    certain that the bit width does not matter. In this case, I
+    really should tell the expression node about it so that it can
+    pick a practical (and optimal) width.

-The NetAssign_ class described above is the means for processes to
+Interaction Of Expressions And Structure: NetESignal
+----------------------------------------------------
+
+The NetAssign\_ class described above is the means for processes to
 manipulate the net, but values are read from the net by NetESignal
 objects. These objects are class NetExpr because they can appear in
 expressions (and have width). They are not NetNode object, but hold
@@ -216,7 +204,8 @@ pointers to a NetNet object, which is used to retrieve values with the
 expression is evaluated.


-HIERARCHY IN NETLISTS
+Hierarchy In Netlists
+---------------------

 The obvious hierarchical structure of Verilog is the module. The
 Verilog program may contain any number of instantiations of modules in
@@ -237,7 +226,8 @@ boundaries. This makes coding of netlist transform functions such as
 constant propagation more effective and easier to write.


-SCOPE REPRESENTATION IN NETLISTS
+Scope Representation In Netlists
+--------------------------------

 In spite of the literal flattening of the design, scope information is
 preserved in the netlist, with the NetScope class. The Design class
@@ -259,7 +249,8 @@ scope. Overrides are managed during the scan, and once the scan is
 complete, defparam overrides are applied.


-TASKS IN NETLISTS
+Tasks In Netlists
+-----------------

 The flattening of the design does not include tasks and named
 begin-end blocks. Tasks are behavioral hierarchy (whereas modules are
@@ -269,7 +260,8 @@ recurse. (The elaboration process does reserve the right to flatten
 some task calls. C++ programmers recognize this as inlining a task.)


-TIME SCALE IN NETLISTS
+Time Scale In Netlists
+----------------------

 The Design class and the NetScope classes carry time scale and
 resolution information of the elaborated design. There is a global
@@ -291,49 +283,3 @@ values. These are filled in during scope elaboration and are used in
 subsequent elaboration phases to arrange for scaling of delays. This
 information can also be used by the code generator to scale times back
 to the units of the scope, if that is desired.
-
- $Log: netlist.txt,v $
- Revision 1.10  2000/07/23 18:06:15  steve
-  Document time scale in netlists.
-
- Revision 1.9  2000/07/14 06:12:57  steve
-  Move inital value handling from NetNet to Nexus
-  objects. This allows better propogation of inital
-  values.
-
-  Clean up constant propagation  a bit to account
-  for regs that are not really values.
-
- Revision 1.8  2000/03/08 04:36:54  steve
-  Redesign the implementation of scopes and parameters.
-  I now generate the scopes and notice the parameters
-  in a separate pass over the pform. Once the scopes
-  are generated, I can process overrides and evalutate
-  paremeters before elaboration begins.
-
- Revision 1.7  1999/11/28 23:42:02  steve
-  NetESignal object no longer need to be NetNode
-  objects. Let them keep a pointer to NetNet objects.
-
- Revision 1.6  1999/11/21 00:13:09  steve
-  Support memories in continuous assignments.
-
- Revision 1.5  1999/11/02 04:55:34  steve
-  Add the synthesize method to NetExpr to handle
-  synthesis of expressions, and use that method
-  to improve r-value handling of LPM_FF synthesis.
-
-  Modify the XNF target to handle LPM_FF objects.
-
- Revision 1.4  1999/09/29 00:03:27  steve
-  Spelling fixes from Larry.
-
- Revision 1.3  1999/07/24 02:11:20  steve
-  Elaborate task input ports.
-
- Revision 1.2  1999/07/21 01:15:29  steve
-  Document netlist semantics.
-
- Revision 1.1  1999/05/27 04:13:08  steve
-  Handle expression bit widths with non-fatal errors.
-
@@ -1,5 +1,6 @@

-LOADABLE TARGETS
+Loadable Targets
+================

 Icarus Verilog supports dynamically loading code generator modules to
 perform the back-end processing of the completed design. The user
@@ -12,27 +13,31 @@ compiler calls to pass the design to it, and the module in turn uses a
 collection of functions in the core (the API) to access details of the
 design.

-LOADING TARGET MODULES
+Loading Target Modules
+----------------------

 The target module loader is invoked with the ivl flag "-tdll". That
 is, the DLL loader is a linked in target type. The name of the target
 module to load is then specified with the DLL flag, i.e. "-fDLL=<path>".

-COMPILING TARGET MODULES
+Compiling Target Modules
+------------------------

 <write me>

-LOADABLE TARGET MODULE API
+Loadable Target Module Api
+--------------------------

 The target module API is defined in the ivl_target.h header file. This
 declares all the type and functions that a loadable module needs to
 access the design.


-ABOUT SPECIFIC EXPRESSION TYPES
+About Specific Expression Types
+-------------------------------

 In this section find notes about the various kinds of expression
-nodes. The notes here are in addition to the more generation
+nodes. The notes here are in addition to the more general
 documentation in the ivl_target.h header file.

 * IVL_EX_CONCAT
@@ -1,9 +1,6 @@

-NOTE: THE CONTENTS OF THIS FILE ARE BEING MOVED TO THE DOCUMENTATION
-WIKI AT http://iverilog.wikia.com. PLEASE ADD NEW ENTRIES THERE.
-
-                Icarus Verilog vs. IEEE1364
-                Copyright 2000 Stephen Williams
+IEEE1364 Notes
+==============

 The IEEE1364 standard is the bible that defines the correctness of the
 Icarus Verilog implementation and behavior of the compiled
@@ -19,7 +16,8 @@ and common to write programs that produce different results when run
 by different Verilog implementations.


-STANDARDIZATION ISSUES
+Standardization Issues
+----------------------

 These are some issues where the IEEE1364 left unclear, unspecified or
 simply wrong. I'll try to be precise as I can, and reference the
@@ -29,19 +27,19 @@ affect the language.

 * OBJECTS CAN BE DECLARED ANYWHERE IN THE MODULE

-Consider this module:
+Consider this module::

    module sample1;
        initial foo = 1;
-	reg foo;
-	wire tmp = bar;
-	initial #1 $display("foo = %b, bar = %b", foo, tmp);
+    reg foo;
+    wire tmp = bar;
+    initial #1 $display("foo = %b, bar = %b", foo, tmp);
    endmodule

-Notice that the ``reg foo;'' declaration is placed after the first
+Notice that the `reg foo;` declaration is placed after the first
 initial statement. It turns out that this is a perfectly legal module
 according to the -1995 and -2000 versions of the standard. The
-statement ``reg foo;'' is a module_item_declaration which is in turn a
+statement `reg foo;` is a module_item_declaration which is in turn a
 module_item. The BNF in the appendix of IEEE1364-1995 treats all
 module_item statements equally, so no order is imposed.

@@ -53,12 +51,12 @@ textually before they are referenced." Such statements simply do not
 exist. (Personally, I think it is fine that they don't.)

 The closest is the rules for implicit declarations of variables that
-are otherwise undeclared. In the above example, ``bar'' is implicitly
-declared and is therefore a wire. However, although ``initial foo = 1;''
+are otherwise undeclared. In the above example, `bar` is implicitly
+declared and is therefore a wire. However, although `initial foo = 1;`
 is written before foo is declared, foo *is* declared within the
 module, and declared legally by the BNF of the standard.

-Here is another example:
+Here is another example::

    module sample2;
 	initial x.foo = 1;
@@ -80,7 +78,7 @@ Icarus Verilog interprets both of these examples according to "The
 Standard As I Understand It." However, commercial tools in general
 break down with these programs. In particular, the first example
 may generate different errors depending on the tool. The most common
-error is to claim that ``foo'' is declared twice, once (implicitly) as
+error is to claim that `foo` is declared twice, once (implicitly) as
 a wire and once as a reg.

 So the question now becomes, "Is the standard broken, or are the tools
@@ -107,7 +105,7 @@ ordering, by requiring that modules that are used be first defined.
 * TASK AND FUNCTION PARAMETERS CANNOT HAVE EXPLICIT TYPES

 Consider a function negate that wants to take a signed integer value
-and return its negative:
+and return its negative::

 	function integer negate;
 	    input [15:0] val;
@@ -123,7 +121,7 @@ the bit pattern of a 16bit number, but that is not the point. What's
 needed is clarification on whether an input can be declared in the
 port declaration as well as in the contained block declaration.

-As I understand the situation, this should be allowed:
+As I understand the situation, this should be allowed::

 	function integer negate;
 	    input [15:0] val;
@@ -152,10 +150,10 @@ commercial tools seem to work similarly.

 * ROUNDING OF TIME

-When the `timescale directive is present, the compiler is supposed to
+When the \`timescale directive is present, the compiler is supposed to
 round fractional times (after scaling) to the nearest integer. The
 confusing bit here is that it is apparently conventional that if the
-`timescale directive is *not* present, times are rounded towards zero
+\`timescale directive is *not* present, times are rounded towards zero
 always.


@@ -173,12 +171,12 @@ take it that x is allowed, as that is what Verilog-XL does.

 * REPEAT LOOPS vs. REPEAT EVENT CONTROL

-There seems to be ambiguity in how code like this should be parsed:
+There seems to be ambiguity in how code like this should be parsed::

 	repeat (5) @(posedge clk) <statement>;

 There are two valid interpretations of this code, from the
-IEEE1364-1995 standard. One looks like this:
+IEEE1364-1995 standard. One looks like this::

    procedural_timing_control_statement ::=
          delay_or_event_control  statement_or_null
@@ -189,7 +187,7 @@ IEEE1364-1995 standard. One looks like this:

 If this interpretation is used, then the statement <statement> should
 be executed after the 5th posedge of clk. However, there is also this
-interpretation:
+interpretation::

    loop_statement ::=
         repeat ( expression ) statement
@@ -218,7 +216,7 @@ compiler may just as easily choose another width limit, for example
 However, it is not *required* that an implementation truncate at 32
 bits, and in fact Icarus Verilog does not truncate at all. It will
 make the unsized constant as big as it needs to be to hold the value
-accurately. This is especially useful in situations like this;
+accurately. This is especially useful in situations like this::

 	    reg [width-1:0] foo = 17179869183;

@@ -237,7 +235,7 @@ truncation point.

 * UNSIZED EXPRESSIONS AS PARAMETERS TO CONCATENATION {}

-The Verilog standard clearly states in 4.1.14:
+The Verilog standard clearly states in 4.1.14::

 	"Unsized constant numbers shall not be allowed in
 	concatenations. This is because the size of each
@@ -257,7 +255,7 @@ simple unsized constant is accepted there, even if all the operands of
 all the operators that make up the expression are unsized integers.

 This is a semantic problem. Icarus Verilog doesn't limit the size of
-integer constants. This is valid as stated in 2.5.1 Note 3:
+integer constants. This is valid as stated in 2.5.1 Note 3::

 	"The number of bits that make up an unsized number
 	(which is a simple decimal number or a number without
@@ -268,6 +266,8 @@ Icarus Verilog will hold any integer constant, so the size will be as
 large as it needs to be, whether that is 64bits, 128bits, or
 more. With this in mind, what is the value of these expressions?

+::
+
 	{'h1_00_00_00_00}
 	{'h1 << 32}
 	{'h0_00_00_00_01 << 32}
@@ -285,12 +285,12 @@ One might note that the quote from section 4.1.14 says "Unsized
 expressions...", so arguably accepting (15+1) or even (16+0) as an
 operand to a concatenation is not a violation of the letter of the
 law. However, the very next sentence of the quote expresses the
-intent, and accepting (15+1) as having a more defined size then (16)
+intent, and accepting (15+1) as having a more defined size than (16)
 seems to be a violation of that intent.

 Whatever a compiler decides the size is, the user has no way to
 predict it, and the compiler should not have the right to treat (15+1)
-any differently then (16). Therefore, Icarus Verilog takes the
+any differently than (16). Therefore, Icarus Verilog takes the
 position that such expressions are *unsized* and are not allowed as
 operands to concatenations. Icarus Verilog will in general assume that
 operations on unsized numbers produce unsized results. There are
@@ -301,7 +301,7 @@ generate appropriate error messages.

 * MODULE INSTANCE WITH WRONG SIZE PORT LIST

-A module declaration like this declares a module that takes three ports:
+A module declaration like this declares a module that takes three ports::

 	module three (a, b, c);
 	  input a, b, c;
@@ -309,7 +309,7 @@ A module declaration like this declares a module that takes three ports:
 	endmodule

 This is fine and obvious. It is also clear from the standard that
-these are legal instantiations of this module:
+these are legal instantiations of this module::

 	three u1 (x,y,z);
 	three u2 ( ,y, );
@@ -320,7 +320,7 @@ In some of the above examples, there are unconnected ports. In the
 case of u4, the pass by name connects only port b, and leaves a and c
 unconnected. u2 and u4 are the same thing, in fact, but using
 positional or by-name syntax. The next example is a little less
-obvious:
+obvious::

 	three u4 ();

@@ -331,7 +331,7 @@ positional list, then the wrong number of ports is given, but if it is
 an empty by-name list, it is an obviously valid instantiation. So it
 is fine to accept this case as valid.

-These are more doubtful:
+These are more doubtful::

 	three u5(x,y);
 	three u6(,);
@@ -351,7 +351,7 @@ other.

 * UNKNOWN VALUES IN L-VALUE BIT SELECTS

-Consider this example:
+Consider this example::

 	reg [7:0] vec;
 	wire [4:0] idx = <expr>;
@@ -375,7 +375,7 @@ assignment will have no effect.

 The interaction between blocking assignments in procedural code and
 logic gates in gate-level code and expressions is poorly defined in
-Verilog. Consider this example:
+Verilog. Consider this example::

   reg a;
   reg b;
@@ -438,7 +438,7 @@ bit and part selects.

 * EDGES OF VECTORS

-Consider this example:
+Consider this example::

   reg [ 5:0] clock;
   always @(posedge clock) [do stuff]
@@ -446,7 +446,7 @@ Consider this example:
 The IEEE1364 standard clearly states that the @(posedge clock) looks
 only at the bit clock[0] (the least significant bit) to search for
 edges. It has been pointed out by some that Verilog XL instead
-implements it as "@(posedge |clock)": it looks for a rise in the
+implements it as `@(posedge |clock)`: it looks for a rise in the
 reduction or of the vector. Cadence Design Systems technical support
 has been rumored to claim that the IEEE1364 specification is wrong,
 but NC-Verilog behaves according to the specification, and thus
@@ -462,7 +462,7 @@ matter.
 The IEEE1364 standard clearly states that in VCD files, the $dumpoff
 section checkpoints all the dumped variables as X values. For reg and
 wire bits/vectors, this obviously means 'bx values. Icarus Verilog
-does this, for example:
+does this, for example::

    $dumpoff
    x!
@@ -475,7 +475,7 @@ section of the VCD file. Verilog-XL dumps "r0 !" to set the real
 variables to the dead-zone value of 0.0, whereas other tools, such as
 ModelTech, ignore real variables in this section.

-For example (from XL):
+For example (from XL)::

    $dumpoff
    r0 !
@@ -485,7 +485,7 @@ For example (from XL):
 Icarus Verilog dumps NaN values for real variables in the
 $dumpoff-$end section of the VCD file. The NaN value is the IEEE754
 equivalent of an unknown value, and so better reflects the unknown
-(during the dead zone) status of the variable, like this:
+(during the dead zone) status of the variable, like this::

    $dumpoff
    rNaN !
@@ -499,65 +499,3 @@ already seems to exist amongst VCD viewers in the wild, this behavior
 seems to be acceptable according to the standard, is a better mirror
 of 4-value behavior in the dead zone, and appears more user friendly
 when viewed by reasonable viewers.
-
-
-$Id: ieee1364-notes.txt,v 1.19 2007/04/18 02:36:13 steve Exp $
-$Log: ieee1364-notes.txt,v $
-Revision 1.19  2007/04/18 02:36:13  steve
- Put to iverilog wiki for further notes.
-
-Revision 1.18  2007/03/22 16:08:16  steve
- Spelling fixes from Larry
-
-Revision 1.17  2003/07/15 03:49:22  steve
- Spelling fixes.
-
-Revision 1.16  2003/04/14 03:40:21  steve
- Make some effort to preserve bits while
- operating on constant values.
-
-Revision 1.15  2003/02/16 23:39:08  steve
- NaN in dead zones of VCD dumps.
-
-Revision 1.14  2003/02/06 17:51:36  steve
- Edge of vectors notes.
-
-Revision 1.13  2002/08/20 04:11:53  steve
- Support parameters with defined ranges.
-
-Revision 1.12  2002/06/11 03:34:33  steve
- Spelling patch (Larry Doolittle)
-
-Revision 1.11  2002/04/27 02:38:04  steve
- Support selecting bits from parameters.
-
-Revision 1.10  2002/03/31 01:54:13  steve
- Notes about scheduling
-
-Revision 1.9  2002/01/26 02:08:07  steve
- Handle x in l-value of set/x
-
-Revision 1.8  2001/08/01 05:17:31  steve
- Accept empty port lists to module instantiation.
-
-Revision 1.7  2001/02/17 05:27:31  steve
- I allow function ports to have types.
-
-Revision 1.6  2001/02/12 16:48:04  steve
- Rant about bit widths.
-
-Revision 1.5  2001/01/02 17:28:08  steve
- Resolve repeat ambiguity in favor of loop.
-
-Revision 1.4  2001/01/01 19:12:35  steve
- repeat loops ambiguity.
-
-Revision 1.3  2000/12/15 00:21:46  steve
- rounding of time and x in primitives.
-
-Revision 1.2  2000/11/19 22:03:04  steve
- Integer parameter comments.
-
-Revision 1.1  2000/07/23 18:06:31  steve
- Document ieee1364 issues.
-
@@ -0,0 +1,10 @@
+
+Miscellaneous
+=============
+
+.. toctree::
+   :maxdepth: 1
+
+   ieee1364-notes
+   swift
+   xilinx-hint
@@ -1,7 +1,8 @@

-SWIFT MODEL SUPPORT FOR Icarus Verilog (PRELIMINARY)
+Swift Model Support (Preliminary)
+=================================

-    Copyright 2003 Stephen Williams
+    Copyright 2003-2024 Stephen Williams

  NOTE: SWIFT support does not work yet, these are provisional
  instructions, intended to show what's supposed to happen when I get
@@ -24,7 +25,7 @@ When compiling your Verilog design to include a SWIFT model, you need
 to include wrappers for the model you intend to use. You may choose to
 use ncverilog or verilogxl compatible wrappers, they work the
 same. Locate your smartmodel directory, and include it in your command
-file like so:
+file like so::

     +libdir+.../smartmodel/sol/wrappers/verilogxl

@@ -42,11 +43,11 @@ support for your model.
 * Execution

 After your simulation is compiled, run the simulation with the vvp
-command, like this:
+command, like this::

      % vvp -mcadpli a.out -cadpli=$LMC_HOME/lib/x86_linux.lib/swiftpli.so:swift_boot

-What this command line means is:
+What this command line means is::

 	-mcadpli
 	   Include the cadpli compatibility module
@@ -0,0 +1,113 @@
+
+Xilinx Hint
+===========
+
+For those of you who wish to use Icarus Verilog, in combination with
+the Xilinx back end (Foundation or Alliance), it can be done.  I have
+run some admittedly simple (2300 equivalent gates) designs through this
+setup, targeting a Spartan XCS10.
+
+Verilog:
+--------
+
+Older versions of Icarus Verilog (like 19990814) couldn't synthesize
+logic buried in procedural (flip-flop) assignment.  Newer versions
+(like 20000120) don't have this limitation.
+
+Procedural assignments have to be given one at a time, to be
+"found" by xnfsyn.  Say
+
+::
+
+   always @ (posedge Clk) Y = newY;
+   always @ (posedge Clk) Z = newZ;
+
+rather than
+
+::
+
+   always @ (posedge Clk) begin
+       Y = newY;
+       Z = newZ;
+   end
+
+Steve's xnf.txt covers most buffer and pin constructs, but I had reason
+to use a global clock net not connected to an input pin.  The standard
+Verilog for a buffer, combined with a declaration to turn that into a
+BUFG, is::
+
+   buf BUFG( your_output_here, your_input_here );
+   $attribute(BUFG,"XNF-LCA","BUFG:O,I")
+
+I use post-processing on my .xnf files to add "FAST" attributes to
+output pins.
+
+Running ivl:
+------------
+
+The -F switches are important.  The following order seems to robustly
+generate valid XNF files, and is used by "verilog -X"::
+
+  -Fsynth -Fnodangle -Fxnfio
+
+Generating .pcf files:
+----------------------
+
+The ngdbuild step seems to lose pin placement information that ivl
+puts in the XNF file.  Use xnf2pcf to extract this information to
+a .pcf file, which the Xilinx place-and-route software _will_ pay
+attention to.  Steve says he now makes that information available
+in an NCF file, with -fncf=<path>, but I haven't tested that.
+
+Running the Xilinx back end:
+
+You can presumably use the GUI, but that doesn't fit in Makefiles :-).
+Here is the command sequence in pseudo-shell-script::
+
+  ngdbuild -p $part $1.xnf $1.ngd
+  map -p $part -o map.ncd $1.ngd
+  xnf2pcf <$1.xnf >$1.pcf    # see above
+  par -w -ol 2 -d 0 map.ncd $1.ncd $1.pcf
+  bitgen_flags = -g ConfigRate:SLOW -g TdoPin:PULLNONE -g DonePin:PULLUP \
+                 -g CRC:enable -g StartUpClk:CCLK -g SyncToDone:no \
+                 -g DoneActive:C1 -g OutputsActive:C3 -g GSRInactive:C4 \
+                 -g ReadClk:CCLK -g ReadCapture:enable -g ReadAbort:disable
+  bitgen $1.ncd -l -w $bitgen_flags
+
+The Xilinx software has diarrhea of the temp files (14, not including
+.xnf, .pcf, .ngd, .ncd, and .bit), so this sequence is best done in a
+dedicated directory.  Note in particular that map.ncd is a generic name.
+
+I had reason to run this remotely (and transparently within a Makefile)
+via ssh.  I use the gmake rule::
+
+    %.bit : %.xnf
+        ssh -x -a -o 'BatchMode yes' ${ALLIANCE_HOST} \
+               remote_alliance ${REMOTE_DIR} $(basename $@) 2>&1 < $<
+    scp ${ALLIANCE_HOST}:${REMOTE_DIR}/$@ .
+
+and the remote_alliance script (on ${ALLIANCE_HOST})::
+
+    /bin/csh
+    cd $1
+    cat >! $2.xnf
+    xnf2pcf <$2.xnf >! $2.pcf
+    ./backend $2
+
+There is now a "Xilinx on Linux HOWTO" at http://www.polybus.com/xilinx_on_linux.html
+I haven't tried this yet, it looks interesting.
+
+Downloading:
+------------
+
+I use the XESS (http://www.xess.com/) XSP-10 development board, which
+uses the PC parallel (printer) port for downloading and interaction
+with the host.  They made an old version of their download program
+public domain, posted it at http://www.xess.com/FPGA/xstools.zip ,
+and now there is a Linux port at ftp://ftp.microux.com/pub/pilotscope/xstools.tar.gz .
+
+The above hints are based on my experience with Foundation 1.5 on NT
+(gack) and Alliance 2.1i on Solaris.  Your mileage may vary.  Good luck!
+
+ - Larry Doolittle   <[email protected]>   August 19, 1999
+                                    updated February 1, 2000
@@ -1,9 +1,11 @@

-THE VVP TARGET
+The VVP Target
+==============

-SYMBOL NAME CONVENTIONS
+Symbol Name Conventions
+-----------------------

-There are some naming conventions that the vp target uses for
+There are some naming conventions that the vvp target uses for
 generating symbol names.

 * wires and regs
@@ -18,7 +20,8 @@ this case the symbol is attached to a functor that is the output of
 the logic device.


-GENERAL FUNCTOR WEB STRUCTURE
+General Functor Web Structure
+-----------------------------

 The net of gates, signals and resolvers is formed from the input
 design. The basic structure is wrapped around the nexus, which is
@@ -30,4 +33,4 @@ the drivers are first fed into a resolver (or a tree of resolvers) to
 form a single output that is the nexus.

 The nexus, then, feeds its output to the inputs of other gates, or to
-the .net objects in the design.
+the .net objects in the design.
@@ -0,0 +1,9 @@
+
+VPI in Icarus Verilog
+=====================
+
+.. toctree::
+   :maxdepth: 1
+
+   vpi
+   va_math
@@ -0,0 +1,100 @@
+
+Verilog-A math library
+======================
+
+License.
+--------
+
+  Verilog-A math library built for Icarus Verilog
+  https://github.com/steveicarus/iverilog/
+
+  Copyright (C) 2007-2024  Cary R. ([email protected])
+
+  This program is free software; you can redistribute it and/or modify
+  it under the terms of the GNU General Public License as published by
+  the Free Software Foundation; either version 2 of the License, or
+  (at your option) any later version.
+
+  This program is distributed in the hope that it will be useful,
+  but WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+  GNU General Public License for more details.
+
+  You should have received a copy of the GNU General Public License along
+  with this program; if not, write to the Free Software Foundation, Inc.,
+  51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+
+Standard Verilog-A Mathematical Functions.
+------------------------------------------
+
+The va_math VPI module implements all the standard math functions provided
+by Verilog-A as Verilog-D system functions. The names are the same except
+like all Verilog-D system functions the name must be prefixed with a '$'.
+For reference the functions are::
+
+  $ln(x)       --  Natural logarithm
+  $log10(x)    --  Decimal logarithm
+  $exp(x)      --  Exponential
+  $sqrt(x)     --  Square root
+  $min(x,y)    --  Minimum
+  $max(x,y)    --  Maximum
+  $abs(x)      --  Absolute value
+  $floor(x)    --  Floor
+  $ceil(x)     --  Ceiling
+  $pow(x,y)    --  Power (x**y)
+  $sin(x)      --  Sine
+  $cos(x)      --  Cosine
+  $tan(x)      --  Tangent
+  $asin(x)     --  Arc-sine
+  $acos(x)     --  Arc-cosine
+  $atan(x)     --  Arc-tangent
+  $atan2(y,x)  --  Arc-tangent of y/x
+  $hypot(x,y)  --  Hypotenuse (sqrt(x**2 + y**2))
+  $sinh(x)     --  Hyperbolic sine
+  $cosh(x)     --  Hyperbolic cosine
+  $tanh(x)     --  Hyperbolic tangent
+  $asinh(x)    --  Arc-hyperbolic sine
+  $acosh(x)    --  Arc-hyperbolic cosine
+  $atanh(x)    --  Arc-hyperbolic tangent
+
+The only limit placed on the x and y arguments by the library is that they
+must be numbers (not constant strings). The underlying C library controls
+any other limits placed on the arguments. Most libraries return +-Inf or
+NaN for results that cannot be represented with real numbers. All functions
+return a real result.
+
+Standard Verilog-A Mathematical Constants.
+------------------------------------------
+
+The Verilog-A mathematical constants can be accessed by including the
+"constants.vams" header file. It is located in the standard include
+directory. Recent version of Icarus Verilog (0.9.devel) automatically
+add this directory to the end of the list used to find include files.
+For reference the mathematical constants are::
+
+  `M_PI        --  Pi
+  `M_TWO_PI    --  2*Pi
+  `M_PI_2      --  Pi/2
+  `M_PI_4      --  Pi/4
+  `M_1_PI      --  1/Pi
+  `M_2_PI      --  2/Pi
+  `M_2_SQRTPI  --  2/sqrt(Pi)
+  `M_E         --  e
+  `M_LOG2E     --  log base 2 of e
+  `M_LOG10E    --  log base 10 of e
+  `M_LN2       --  log base e of 2
+  `M_LN10      --  log base e of 10
+  `M_SQRT2     --  sqrt(2)
+  `M_SQRT1_2   --  1/sqrt(2)
+
+Using the Library.
+------------------
+
+Just add "-m va_math" to your iverilog command line/command file and
+\`include the "constants.vams" file as needed.
+
+Thanks
+------
+
+I would like to thank Larry Doolittle for his suggestions and
+Stephen Williams for developing Icarus Verilog.
@@ -0,0 +1,50 @@
+
+VPI Modules in Icarus Verilog
+================================
+
+The VPI interface for Icarus Verilog works by creating from a
+collection of PLI applications a single vpi module. The vpi module
+includes compiled code for the applications linked together (with any
+other libraries that the applications need) into a module with two
+exported symbols, the vpip_set_callback function and the
+vlog_startup_routines array.
+
+The product that wishes to invoke the module (normally at run time) loads
+the module, locates and calls the vpip_set_callback function to pass the
+the module a jump table that allows the module to access the VPI routines
+implemented by the product, then locates the vlog_startup_routines table
+and calls all the startup routines contained in that table. It is possible
+for a product to link with many modules. In that case, all the modules are
+linked in and startup routines are called in order.
+
+The product that uses vpi modules uses the environment variable
+VPI_MODULE_PATH as a ':' separated list of directories. This is the
+module search path. When a module is specified by name (using whatever
+means the product supports) the module search path is scanned until
+the module is located.
+
+The special module names "system.vpi", "v2005_math.vpi", "v2009.vpi",
+and "va_math.vpi" are part of the core Icarus Verilog distribution and
+include implementations of the standard system tasks/functions. The
+additional special module names "vhdl_sys.vpi" and "vhdl_textio.vpi"
+include implementations of private functions used to support VHDL.
+
+Compiling A VPI Module
+----------------------
+
+See the documentation under: :doc:`Using VPI <../../../usage/vpi>`
+
+Tracing VPI Use
+---------------
+
+The vvp command includes the ability to trace VPI calls. This is
+useful if you are trying to debug a problem with your code. To
+activate tracing simply set the VPI_TRACE environment variable, with
+the path to a file where trace text gets written. For example::
+
+	setenv VPI_TRACE /tmp/foo.txt
+
+This tracing is pretty verbose, so you don't want to run like this
+normally. Also, the format of the tracing messages will change
+according to my needs (and whim) so don't expect to be able to parse
+it in software.
@@ -0,0 +1,19 @@
+
+Debug Aids For VVP
+==================
+
+Debugging vvp can be fiendishly difficult, so there are some built in
+debugging aids. These are enabled by setting the environment variable
+VVP_DEBUG to the path to an output file. Then, various detailed debug
+tools can be enabled as described below.
+
+* .resolv
+
+The .resolv can print debug information along with a label by
+specifying the debug output label on the .resolv line::
+
+   .resolv tri$<label>
+
+In this case, the "$" character directly after the "tri" enables debug
+dumps for this node, and the <label> is the label to prepend to log
+messages from this node.
@@ -0,0 +1,13 @@
+
+VVP - Verilog Virtual Processor
+===============================
+
+.. toctree::
+   :maxdepth: 1
+
+   vvp
+   opcodes
+   vpi
+   vthread
+   debug
+
@@ -1,17 +1,12 @@
-/*
- * Copyright (c) 2001 Stephen Williams ([email protected])
- *
- *  $Id: vpi.txt,v 1.8 2007/03/22 16:08:19 steve Exp $
- */

-
-VPI WITHIN VVP
+VPI Within VVP
+==============

 System tasks and functions in Verilog are implemented in Icarus
 Verilog by C routines written with VPI. This implies that the vvp
 engine must provide at least a subset of the Verilog VPI
 interface. The minimalist concepts of vvp, however, make the method
-less then obvious.
+less than obvious.

 Within a Verilog design, there is a more or less fixed web of
 vpiHandles that is the design database as is available to VPI
@@ -20,7 +15,8 @@ vvp only implements the ones it needs. The VPI web is added into the
 design using special pseudo-ops that create the needed objects.


-LOADING VPI MODULES
+Loading VPI Modules
+-------------------

 The vvp runtime loads VPI modules at runtime before the parser reads
 in the source files. This gives the modules a chance to register tasks
@@ -39,7 +35,8 @@ the system tasks and functions. The %vpi_call instruction, once compiled,
 carries the vpiHandle of the system task.


-SYSTEM TASK CALLS
+System Task Calls
+-----------------

 A system task call invokes a VPI routine, and makes available to that
 routine the arguments to the system task. The called routine gets
@@ -62,7 +59,8 @@ instruction then only needs to be a %vpi_call with the single parameter
 that is the vpiHandle for the call.


-SYSTEM FUNCTION CALLS
+System Function Calls
+---------------------

 System function calls are similar to system tasks. The only
 differences are that all the arguments are input only, and there is a
@@ -76,7 +74,8 @@ writing a wrapper thread that calls the function when inputs change,
 and that writes the output into the containing expression.


-SYSTEM TASK/FUNCTION ARGUMENTS
+System Task/Function Arguments
+------------------------------

 The arguments to each system task or call are not stored in the
 instruction op-code, but in the vpiSysTfCall object that the compiler
@@ -92,7 +91,8 @@ all this is done, an array of vpiHandles is passed to code to create a
 vpiSysTfCall object that has all that is needed to make the call.


-SCOPES
+Scopes
+------

 VPI can access scopes as objects of type vpiScope. Scopes have names
 and can also contain other sub-scopes, all of which the VPI function
@@ -100,7 +100,7 @@ can access by the vpiInternalScope reference. Therefore, the run-time
 needs to form a tree of scopes into which other scoped VPI objects are
 placed.

-A scope is created with a .scope directive, like so:
+A scope is created with a .scope directive, like so::

 	<label> .scope "name" [, <parent>];
 		.timescale <units>;
@@ -113,7 +113,7 @@ declare a scope with the same name more than once in a parent scope.
 The name string given when creating the scope is the basename for the
 scope. The vvp automatically constructs full names from the scope
 hierarchy, and runtime VPI code can access that full name with the
-vpiFullname reference.
+vpiFullName reference.

 The .timescale directive changes the scope units from the simulation
 precision to the specified precision. The .timescale directive affects
@@ -123,7 +123,7 @@ Objects that place themselves in a scope place themselves in the
 current scope. The current scope is the one that was last mentioned by
 a .scope directive. If the wrong scope is current, the label on a
 scope directive can be used to resume a scope. The syntax works like
-this:
+this::

 		.scope <symbol>;

@@ -132,7 +132,8 @@ and is used to identify the scope to be resumed. A scope resume
 directive cannot have a label.


-VARIABLES
+Variables
+---------

 Reg vectors (scalars are vectors of length 1) are created by .var
 statements in the source. The .var statement includes the declared
@@ -146,21 +147,23 @@ The VPI interface to variable (vpiReg objects) uses the MSB and LSB
 values that the user defined to describe the dimensions of the
 object.

-/*
- * Copyright (c) 2001 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
+::
+
+    /*
+     * Copyright (c) 2001-2024 Stephen Williams ([email protected])
+     *
+     *    This source code is free software; you can redistribute it
+     *    and/or modify it in source code form under the terms of the GNU
+     *    General Public License as published by the Free Software
+     *    Foundation; either version 2 of the License, or (at your option)
+     *    any later version.
+     *
+     *    This program is distributed in the hope that it will be useful,
+     *    but WITHOUT ANY WARRANTY; without even the implied warranty of
+     *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+     *    GNU General Public License for more details.
+     *
+     *    You should have received a copy of the GNU General Public License
+     *    along with this program; if not, write to the Free Software
+     *    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+     */
@@ -1,14 +1,8 @@
-/*
- * Copyright (c) 2001 Stephen Williams ([email protected])
- *
- *  $Id: vthread.txt,v 1.6 2005/09/19 21:45:37 steve Exp $
- */

+Thread Details
+==============

-
-THREAD DETAILS
-
-Thread objects in vvp are created by ``.thread'' statements in the
+Thread objects in vvp are created by `.thread` statements in the
 input source file.

 A thread object includes a program counter and private bit
@@ -28,7 +22,7 @@ from the bit registers starting with the LSB and up.

 The bit addresses 0, 1, 2 and 3 are special constant bits 0, 1, x and
 z, and are used as read-only immediate values. If the instruction
-takes a single bit operand, the the appropriate value is simply read
+takes a single bit operand, then the appropriate value is simply read
 out. If the instruction expects a vector, then a vector of the
 expected width is created by replicating the constant value.

@@ -48,21 +42,23 @@ that use these registers document which register is used, and what the
 numeric value is used for. Registers 0-3 are often given fixed
 meanings to instructions that need an integer value.

-/*
- * Copyright (c) 2001 Stephen Williams ([email protected])
- *
- *    This source code is free software; you can redistribute it
- *    and/or modify it in source code form under the terms of the GNU
- *    General Public License as published by the Free Software
- *    Foundation; either version 2 of the License, or (at your option)
- *    any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
- */
+::
+
+    /*
+     * Copyright (c) 2001-2024 Stephen Williams ([email protected])
+     *
+     *    This source code is free software; you can redistribute it
+     *    and/or modify it in source code form under the terms of the GNU
+     *    General Public License as published by the Free Software
+     *    Foundation; either version 2 of the License, or (at your option)
+     *    any later version.
+     *
+     *    This program is distributed in the hope that it will be useful,
+     *    but WITHOUT ANY WARRANTY; without even the implied warranty of
+     *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+     *    GNU General Public License for more details.
+     *
+     *    You should have received a copy of the GNU General Public License
+     *    along with this program; if not, write to the Free Software
+     *    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+     */
@@ -0,0 +1,15 @@
+
+Icarus Verilog Developer Support
+================================
+
+This section contains documents to help support developers who contribute to
+Icarus Verilog.
+
+.. toctree::
+   :maxdepth: 1
+
+   getting_started
+   regression_tests
+   version_stamps
+   guide/index
+   glossary
@@ -0,0 +1,129 @@
+
+The Regression Test Suite
+=========================
+
+Icarus Verilog development includes a regression test suite that is included
+along with the source. The "ivtest" directory contains the regression test
+suite, and this suite is used by the github actions as continuous integration
+to make sure the code is always going forward.
+
+NOTE: There are scripts written in perl to run the regression tests, but they
+are being gradually replaced with a newer set of scripts. It is the newer
+method that is described here.
+
+Test Descriptions
+-----------------
+
+Regression tests are listed in the regress-vvp.list file. Each line lists the
+name of the test and the path to the dest description. The list file is
+therefore pretty simple, and all the description of the test is in the
+description file:
+
+.. code-block:: console
+
+  macro_str_esc  vvp_tests/macro_str_esc.json
+
+The "name" is a simple name, and the test-description-file is the path (relative
+the ivtest directory) to the description file. A simple test description file
+is a JSON file, like this:
+
+.. code-block:: java
+
+  {
+    "type"   : "normal",
+    "source" : "macro_str_esc.v",
+    "gold"   : "macro_str_esc"
+  }
+
+This description file contains all the information that the vvp_reg.py script
+needs to run the regression test. The sections below describe the keys and
+values in the description file dictionary.
+
+source (required)
+^^^^^^^^^^^^^^^^^
+This specifies the name of the source file. The file is actually to be found
+in the ivltests/ directory.
+
+
+type (required)
+^^^^^^^^^^^^^^^
+
+This describes the kind of test to run. The valid values are:
+
+* **normal** - Compile the source using the iverilog compiler vvp target, and if
+  that succeeds execute it using the vvp command. If there is no gold file
+  specified, then look for an output line with the "PASSED" string.
+
+* **NI** - Mark the test as not implemented. The test will be skipped without
+  running or reporting an error.
+
+* **CE** - Compile, but expect the compiler to fail. This means the compiler
+  command process must return an error exit.
+
+* **EF** - Compile and run, but expect the run time to fail. This means the
+  run time program must return an error exit.
+
+* **TE** - This is specific to testing the vlog95 conversion and indicates the
+  translated code failed to compile.
+
+gold (optional)
+^^^^^^^^^^^^^^^
+
+If this is specified, it replaces the "Passed" condition with a comparison of
+the output with a gold file. The argument is the name of the gold file set,
+which will be found in the "gold/" directory. The name here is actually the
+basename of the gold files, with separate actual gold files for the iverilog
+and vvp stderr and stdout. For example, if a "normal" test includes a gold
+file, then the program is compiled and run, and the outputs are compared with
+the gold file to make sure it ran properly.
+
+The way the regression suite works, there are 4 log files created for each
+test:
+
+* foo-iverilog-stdout.log
+* foo-iverilog-stderr.log
+* foo-vvp-stdout.log
+* foo-vvp-stderr.log
+
+The "gold" value is the name of the gold file set. If the gold value is "foo",
+Then the actual gold files are called:
+
+* gold/foo-iverilog-stdout.gold
+* gold/foo-iverilog-stderr.gold
+* gold/foo-vvp-stdout.gold
+* gold/foo/vvp-stderr.gold
+
+If any of those files is empty, then the gold file doesn't need to be
+present at all. The log files and the gold files are compared byte for
+byte, so if the output you are getting is correct, then copy the log to
+the corresponding gold, and you're done.
+
+If the run type is "CE" or "RE", then the gold files still work, and can
+be used to check that the error message is correct. If the gold file setting
+is present, the error return is required, and also the gold files must match.
+
+iverilog-args (optional)
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+If this is specified, it is a list of strings that are passed as arguments to
+the iverilog command line.
+
+vvp-args (optional)
+^^^^^^^^^^^^^^^^^^^^
+
+If this is specified, it is a list of strings that are passed as arguments to
+the vvp command. These arguments go before the vvp input file that is to be
+run.
+
+vvp-args-extended (optional)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+If this is specified, it is a lost of strings that are passed as arguments to
+the vvp command. These are extended arguments, and are placed after the vvp
+input file that is being run. This is where you place things like plusargs.
+
+strict, force-sv or vlog95 (optional)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Any of these can be used to create overrides for the type, gold or
+iverilog-args when the given test type is run.
@@ -0,0 +1,32 @@
+
+Files With Version Information
+==============================
+
+These are the only files that have version information in them:
+
+* version_base.h    -- This should be the 1 source for version info.
+* version_tag.h     -- Generated automatically with git tag information.
+* verilog.spec      -- Used to stamp RPM packages
+
+When versions are changed, the above files need to be edited to account for
+the new version information. The following used to have version information in
+them, but now their version information is generated:
+
+The version_tag.h file is generated from git tag information using
+the "make version" target, or automatically if the version_tag.h
+file doesn't exist at all. This implies that a "make version" is
+something worth doing when you do a "git pull" or create commits.
+
+The files below are now edited by the Makefile:
+
+* iverilog-vpi.man    -- The .TH tag has a version string
+* driver/iverilog.man -- The .TH tag has a version string
+* driver-vpi/res.rc   -- Used to build Windows version stamp
+* vvp/vvp.man         -- The .TH tag has a version string
+
+This now includes version_base.h to get the version:
+
+* vpi/vams_simparam.c -- Hard coded result to simulatorVersion query
+
+The test suite no longer has version specific files since it tracks along with
+the code/branch.
@@ -0,0 +1,26 @@
+.. Icarus Verilog documentation master file, created by
+   sphinx-quickstart on Sun Apr 10 16:28:38 2022.
+   You can adapt this file completely to your liking, but it should at least
+   contain the root `toctree` directive.
+
+Icarus Verilog
+==============
+
+Welcome to the documentation for Icarus Verilog.
+
+.. toctree::
+   :maxdepth: 2
+   :caption: Contents:
+
+   releases/index
+   usage/index
+   targets/index
+   developer/index
+
+
+Indices and tables
+==================
+
+* :ref:`genindex`
+* :ref:`modindex`
+* :ref:`search`
@@ -0,0 +1,10 @@
+Icarus Verilog Release Notes
+============================
+
+This section contains the release notes for all releases after and including
+V13.0. Older release notes can be found here: `<https://iverilog.fandom.com/wiki/User_Guide>`__
+
+.. toctree::
+   :maxdepth: 1
+
+   v13-0-release-note
@@ -0,0 +1,98 @@
+🎉 Release V13.0
+================
+
+The Icarus Verilog development team is pleased to announce **Release V13** of Icarus Verilog.
+
+Release V13 builds on the V12 series with a focus on correctness, runtime stability, improved
+diagnostics, and incremental standard conformance improvements.
+
+----
+
+🐞 Bug Fix Summary
+------------------
+
+Release V13 resolves numerous issues reported against V12, including:
+
+* Incorrect signed constant handling.
+* Generate block naming collisions.
+* Elaboration-time assertion failures.
+* Runtime crashes in malformed corner cases.
+* Memory management issues during elaboration and simulation.
+
+
+----
+
+🔄 Major Changes in V13
+=======================
+
+🧠 Language & Elaboration Fixes
+-------------------------------
+
+Release V13 includes multiple fixes to elaboration and expression handling:
+
+* Resolved generate block scope resolution issues affecting nested and conditional generate constructs.
+* Corrected signed arithmetic corner cases, including shift and width propagation behavior.
+* Fixed constant expression evaluation inconsistencies during parameter elaboration.
+* Improved handling of packed and unpacked arrays in assignments and port binding corner cases.
+* Addressed elaboration-time assertion failures triggered by malformed or ambiguous constructs.
+* Corrected several source-location reporting issues for elaboration errors.
+
+These changes improve standards conformance and eliminate behavioral inconsistencies observed in the V12 series.
+
+----
+
+⚙️ Simulator (vvp) Improvements
+-------------------------------
+
+The `vvp` runtime engine has received internal stability and correctness updates:
+
+* Improved event scheduling behavior in zero-delay and non-blocking assignment scenarios.
+* Fixed race-condition corner cases uncovered by expanded regression testing.
+* Eliminated memory leaks affecting long-running or large simulations.
+* Resolved crash conditions caused by invalid internal state transitions.
+* Improved robustness of `$dumpvars` handling in large hierarchical designs.
+* General runtime consistency and determinism improvements.
+
+`vvp` continues to enforce version matching between the runtime and generated bytecode. Designs
+must be recompiled after upgrading.
+
+----
+
+🔌 VPI Updates
+--------------
+
+Fixes improve VPI reliability and conformance:
+
+* Corrected hierarchical object lookup behavior in specific corner cases.
+* Improved stability of callback registration during startup and shutdown.
+* Fixed invalid handle dereference scenarios that could result in segmentation faults.
+* Addressed inconsistencies in VPI object property reporting.
+
+----
+
+🛠 Diagnostics & Toolchain
+--------------------------
+
+* Improved clarity and consistency of error and warning messages.
+* Better reporting of width mismatches and implicit net declarations.
+* More accurate diagnostic source locations.
+* Build system updates for compatibility with modern compiler toolchains.
+* Regression suite expansion and CI validation improvements.
+
+----
+
+📦 Upgrade Notes
+----------------
+
+* Recompile all designs when upgrading from V12 or any other prior version.
+* Review warnings carefully; improved diagnostics may expose previously silent issues.
+* The only known breaking change is that wires must now be declared before use; which is required in the standard (see `gh1287 <https://github.com/steveicarus/iverilog/issues/1287>`__).
+
+----
+
+🙏 Acknowledgments
+------------------
+
+We thank all contributors who reported issues, submitted patches, expanded regression coverage, and
+improved documentation. Release 13 reflects continued community effort toward improving correctness,
+stability, and maintainability.
@@ -0,0 +1,23 @@
+
+The Icarus Verilog Targets
+==========================
+
+Icarus Verilog elaborates the design, then sends to the design to code
+generates (targets) for processing. New code generators can be added by
+external packages, but these are the code generators that are bundled with
+Icarus Verilog. The code generator is selected by the "-t" command line flag.
+
+.. toctree::
+   :maxdepth: 1
+
+   tgt-vvp
+   tgt-stub
+   tgt-null
+   tgt-vhdl
+   tgt-vlog95
+   tgt-pcb
+   tgt-fpga
+   tgt-pal
+   tgt-sizer
+   tgt-verilog
+   tgt-blif
@@ -0,0 +1,44 @@
+
+The BLIF Code Generator (-tblif)
+================================
+
+The BLIF code generator supports emitting the design to a blif format
+file as accepted by:
+
+    ABC: A System for Sequential Synthesis and Verification
+    <http://www.eecs.berkeley.edu/~alanmi/abc/>
+
+This package contains tools sometimes used by ASIC designers. This
+blif target emits .blif file that the ABC system can read int via
+the "read_blif" command.
+
+
+USAGE
+-----
+
+This code generator is intended to process structural Verilog source
+code. To convert a design to blif, use this command::
+
+  % iverilog -tblif -o<path>.blif  <source files>...
+
+The source files can be Verilog, SystemVerilog, VHDL, whatever Icarus
+Verilog supports, so long as it elaborates down to the limited subset
+that the code generator supports. In other words, the files must be
+structural.
+
+The root module of the elaborated design becomes the model is
+generated. That module may instantiate sub-modules and so on down the
+design, completing the design. The output model is flattened, so it
+doesn't invoke any subcircuits. Bit vectors are exploded out at the
+model ports and internally. This is necessary since blif in particular
+and ABC in general processes bits, not vectors.
+
+
+LIMITATIONS
+-----------
+
+Currently, only explicit logic gates and continuous assignments are
+supported.
+
+The design must contain only one root module. The name of that root
+module becomes the name of the blif model in the ".model" record.
@@ -1,8 +1,9 @@

-FPGA LOADABLE CODE GENERATOR FOR Icarus Verilog
+The FPGA Code Generator (-tfpga)
+================================

-  Copyright 2001 Stephen Williams
-  $Id: fpga.txt,v 1.12 2005/09/19 21:45:36 steve Exp $
+.. warning::
+    This code generator is currently not included in Icarus Verilog.

 The FPGA code generator supports a variety of FPGA devices, writing
 XNF or EDIF depending on the target. You can select the architecture
@@ -11,6 +12,7 @@ select library primitives, and the detailed part name is written into
 the generated file for the use of downstream tools.

 INVOKING THE FPGA TARGET
+------------------------

 The code generator is invoked with the -tfpga flag to iverilog. It
 understands the part= and the arch= parameters, which can be set with
@@ -62,6 +64,7 @@ Virtex-II and Virtex-II Pro devices. It uses the VIRTEX2 library, but
 is very similar to the Virtex target.

 XNF ROOT PORTS
+--------------

  NOTE: As parts are moved over to EDIF format, XNF support will be
  phased out. Current Xilinx implementation tools will accept EDIF
@@ -77,6 +80,8 @@ signal. If the signal is one bit wide, then the pin name is exactly
 the module port name. If the port is a vector, then the pin number is
 given as a vector. For example, the module:

+.. code-block::
+
 	module main(out, in);
 	    output out;
 	    input [2:0] in;
@@ -85,6 +90,8 @@ given as a vector. For example, the module:

 leads to these SIG, records:

+.. code-block::
+
 	SIG, main/out, PIN=out
 	SIG, main/in<2>, PIN=in2
 	SIG, main/in<1>, PIN=in1
@@ -92,6 +99,7 @@ leads to these SIG, records:


 EDIF ROOT PORTS
+---------------

 The EDIF format is more explicit about the interface into an EDIF
 file. The code generator uses that control to generate an explicit
@@ -109,6 +117,7 @@ However, since the ports are single bit ports, the name of vectors
 includes the string "[0]" where the number is the bit number. For
 example, the module:

+.. code-block::

 	module main(out, in);
 	    output out;
@@ -118,6 +127,8 @@ example, the module:

 creates these ports:

+.. code-block::
+
 	out   OUTPUT
 	in[0] INPUT
 	in[1] INPUT
@@ -129,6 +140,7 @@ when presenting the vector to the user.


 PADS AND PIN ASSIGNMENT
+-----------------------

 The ports of a root module may be assigned to specific pins, or to a
 generic pad. If a signal (that is a port) has a PAD attribute, then
@@ -136,14 +148,14 @@ the value of that attribute is a list of locations, one for each bit
 of the signal, that specifies the pin for each bit of the signal. For
 example:

+.. code-block::
+
 	module main( (* PAD = "P10" *)         output out,
 		     (* PAD = "P20,P21,P22" *) input [2:0] in);
-
 	    [...]
-
 	endmodule

-In this example, port ``out'' is assigned to pin 10, and port ``in''
+In this example, port `out` is assigned to pin 10, and port `in`
 is assigned to pins 20-22. If the architecture supports it, a pin
 number of 0 means let the back end tools choose a pin. The format of
 the pin number depends on the architecture family being targeted, so
@@ -157,6 +169,7 @@ driver to the port. An error.


 SPECIAL DEVICES
+---------------

 The code generator supports the "cellref" attribute attached to logic
 devices to cause specific device types be generated, instead of the
@@ -177,51 +190,12 @@ device pins are connected.


 COMPILING WITH XILINX FOUNDATION
+--------------------------------

-Compile a single-file design with command line tools like so:
-
-	% iverilog -parch=virtex -o foo.edf foo.vl
-	% edif2ngd foo.edf foo.ngo
-	% ngdbuild -p v50-pq240 foo.ngo foo.ngd
-	% map -o map.ncd foo.ngd
-	% par -w map.ncd foo.ncd
-
---
-$Log: fpga.txt,v $
-Revision 1.12  2005/09/19 21:45:36  steve
- Spelling patches from Larry.
-
-Revision 1.11  2003/08/07 05:17:34  steve
- Add arch=lpm to the documentation.
-
-Revision 1.10  2003/07/04 03:57:19  steve
- Allow attributes on Verilog 2001 port declarations.
-
-Revision 1.9  2003/07/04 01:08:03  steve
- PAD attribute can be used to assign pins.
-
-Revision 1.8  2003/07/02 00:26:49  steve
- Fix spelling of part= flag.
-
-Revision 1.7  2003/03/24 02:28:38  steve
- Document the virtex2 architecture.
-
-Revision 1.6  2003/03/24 00:47:54  steve
- Add new virtex2 architecture family, and
- also the new edif.h EDIF management functions.
-
-Revision 1.5  2002/04/30 04:26:42  steve
- Spelling errors.
-
-Revision 1.4  2001/09/16 22:26:47  steve
- Support the cellref attribute.
-
-Revision 1.3  2001/09/16 01:48:16  steve
- Suppor the PAD attribute on signals.
-
-Revision 1.2  2001/09/06 04:28:40  steve
- Separate the virtex and generic-edif code generators.
-
-Revision 1.1  2001/09/02 23:58:49  steve
- Add documentation for the code generator.
+Compile a single-file design with command line tools like so::

+  % iverilog -parch=virtex -o foo.edf foo.vl
+  % edif2ngd foo.edf foo.ngo
+  % ngdbuild -p v50-pq240 foo.ngo foo.ngd
+  % map -o map.ncd foo.ngd
+  % par -w map.ncd foo.ncd
@@ -0,0 +1,7 @@
+
+The null Code Generator (-tnull)
+================================
+
+The null target generates no code. Invoking this code generator causes no code
+generation to happen.
+
@@ -0,0 +1,8 @@
+
+The PAL Code Generator (-tpal)
+==============================
+
+.. warning::
+    This code generator is currently not included in Icarus Verilog.
+
+The PAL target generates JEDEC output for a Programmable Array Logic.
@@ -0,0 +1,61 @@
+
+The PCB Code Generator (-tpcb)
+==============================
+
+The PCB target code generator is designed to allow a user to enter a netlist
+in Verilog format, then generate input files for the GNU PCB layout program.
+
+Invocation
+----------
+
+The PCB target code generation is invoked with the -tpcb flag to the iverilog
+command. The default output file, "a.out", contains the generated .PCB
+file. Use the "-o" flag to set the output file name explicitly. The default
+output file contains only the elements. To generate a "netlist" file, add the
+flag "-pnetlist=<path>" command line flag.
+
+Altogether, this example generates the foo.net and foo.pcb files from the
+foo.v source file::
+
+  % iverilog -tpcb -ofoo.pcb -pnetlist=foo.net foo.v
+
+Flags
+-----
+
+* -o <path>
+
+  Set the output (pcb) file path
+
+* -pnetlist=path
+
+  Write a netlist file to the given path.
+
+Attributes Summary
+------------------
+
+Attributes are attached to various constructs using the Verilog "(\* \*)"
+attribute syntax.
+
+* ivl_black_box
+
+  Attached to a module declaration or module instantiation, this indicates
+  that the module is a black box. The code generator will create an element
+  for black box instances.
+
+Parameters Summary
+------------------
+
+Within modules, The PCB code generator uses certain parameters to control
+details. Parameters may have defaults, and can be overridden using the usual
+Verilog parameter override syntax. Parameters have preferred types.
+
+* description (string, default="")
+
+  The "description" is a text string that describes the black box. This string
+  is written into the description field of the PCB Element.
+
+* value (string, default="")
+
+  The "value" is a text tring that describes some value for the black
+  box. Like the description, the code generator does not interpret this value,
+  other then to write it to the appropriate field in the PCB Element."
@@ -0,0 +1,49 @@
+
+The sizer Code Analyzer (-tsizer)
+=================================
+
+The sizer target does not generate any code. Instead it will print statistics about the Verilog code.
+
+It is important to synthesize the Verilog code before invoking the sizer. This can be done with the `-S` flag passed to iverilog. Note, that behavioral code can not be synthesized and will generate a warning when passed to the sizer.
+
+Example command::
+
+    % iverilog -o sizer.txt -tsizer -S -s top input.v
+
+With this example code:
+
+.. code-block:: verilog
+
+    module top (
+        input clock,
+        input reset,
+        output blink
+    );
+        reg out;
+
+        always @(posedge clock) begin
+            if (reset) begin
+                out = 1'b0;
+            end else begin
+                out <= !out;
+            end
+        end
+
+        assign blink = out;
+
+    endmodule
+
+The resulting `sizer.txt` will contain::
+
+    **** module/scope: top
+         Flip-Flops   : 1
+         Logic Gates  : 3
+         MUX[2]: 1 slices
+         LOG[13]: 1 unaccounted
+         LOG[14]: 1 unaccounted
+    **** TOTALS
+         Flip-Flops   : 1
+         Logic Gates  : 3
+         MUX[2]: 1 slices
+         LOG[13]: 1 unaccounted
+         LOG[14]: 1 unaccounted
@@ -0,0 +1,30 @@
+
+The stub Code Generator (-tstub)
+================================
+
+The stub code generator is a debugging aid for the Icarus Verilog compiler
+itself. It outputs a text dump of the elaborated design as it is passed to
+code generators.
+
+Example command::
+
+    % iverilog -o stub.txt -tstub -s top input.v
+
+With this example code:
+
+.. code-block:: verilog
+
+    module top;
+        initial $display("Hello World!");
+    endmodule
+
+The resulting `stub.txt` will contain::
+
+    root module = top
+    scope: top (0 parameters, 0 signals, 0 logic) module top time units = 1e0
+     time precision = 1e0
+    end scope top
+    # There are 0 constants detected
+    initial
+        Call $display(1 parameters); /* hello_world.v:2 */
+            <string="Hello World!", width=96, type=bool>
@@ -0,0 +1,6 @@
+
+The Verilog Code Generator (-tverilog)
+======================================
+
+.. warning::
+    This code generator is currently not included in Icarus Verilog.
@@ -0,0 +1,82 @@
+
+The VHDL Code Generator (-tvhdl)
+================================
+
+Icarus Verilog contains a code generator to emit VHDL from the Verilog
+netlist. This allows Icarus Verilog to function as a Verilog to VHDL
+translator.
+
+Invocation
+----------
+
+To translate a Verilog program to VHDL, invoke "iverilog" with the -tvhdl
+flag::
+
+  % iverilog -t vhdl -o my_design.vhd my_design.v
+
+The generated VHDL will be placed in a single file (a.out by default), even if
+the Verilog is spread over multiple files.
+
+Flags
+-----
+
+* -pdebug=1
+
+  Print progress messages as the code generator visits each part of the
+  design.
+
+* -pdepth=N
+
+  Only output VHDL entities for modules found at depth < N in the
+  hierarchy. N=0, the default, outputs all entities. For example, -pdepth=1
+  outputs only the top-level entity.
+
+Supported Constructs
+--------------------
+
+TODO
+
+Limitations
+-----------
+
+Signal Values and Resolution
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+There are several cases where the behaviour of the translated VHDL deviates
+from the source Verilog:
+
+* The result of division by zero is x in Verilog but raises an exception in
+  VHDL.
+
+* Similarly, the result of reading past the end of an array in Verilog is x,
+  whereas VHDL raises an exception.
+
+* Any signal that is driven by two or more processes will have the value
+  'U'. This is the result of the signal resolution function in the
+  std_logic_1164 package.
+
+Constructs Not Supported
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+The following Verilog constructs cannot be translated to VHDL:
+
+* fork and join
+
+* force and release
+
+* disable
+
+* real-valued variables
+
+* switches
+
+* hierarchical dereferencing
+
+Other Limitations
+^^^^^^^^^^^^^^^^^
+
+* The test expressions in case statements must be constant.
+
+* Translation of a parameter to a corresponding VHDL generic
+  declaration. Instead the default parameter value is used.
+
@@ -0,0 +1,101 @@
+
+The Verilog '95 Code Generator (-tvlog95)
+=========================================
+
+Icarus Verilog contains a code generator to emit 1995 compliant Verilog from
+the input Verilog netlist. This allows Icarus Verilog to function as a Verilog
+> 1995 to Verilog 1995 translator. The main goal of the project was to convert
+@*, ANSI style arguments and other constructs to something allowed in 1995
+Verilog.
+
+Invocation
+----------
+
+To translate a Verilog program to 1995 compliant Verilog, invoke "iverilog"
+with the -tvlog95 flag::
+
+  % iverilog -tvlog95 -o my_design_95.v my_design.v
+
+The generated Verilog will be placed in a single file (a.out by default), even
+if the input Verilog is spread over multiple files.
+
+Generator Flags
+---------------
+
+* -pspacing=N
+
+  Set the indent spacing (the default is 2).
+
+* -pallowsigned=1
+
+  Allow emitting the various signed constructs as an extension to 1995 Verilog
+  (off by default).
+
+* -pfileline=1
+
+  Emit the original file and line information as a comment for each generated
+  line (off by default).
+
+Structures that cannot be converted to 1995 compatible Verilog
+--------------------------------------------------------------
+
+The following Verilog constructs are not translatable to 1995 compatible Verilog:
+
+* Automatic tasks or functions.
+
+* The power operator (**). Expressions of the form (2**N)**<variable> (where N
+  is a constant) can be converter to a shift.
+
+* Some System Verilog constructs (e.g. final blocks, ++/-- operators,
+  etc.). 2-state variables are converted to 4-state variables.
+
+Icarus extensions that cannot be translated:
+
+* Integer constants greater than 32 bits.
+
+* Real valued nets.
+
+* Real modulus.
+
+* Most Verilog-A constructs.
+
+
+Known Issues and Limitations
+----------------------------
+
+Some things are just not finished and should generate an appropriate
+warning. Here is a list of the major things that still need to be looked at.
+
+* There are still a few module instantiation port issues (pr1723367 and
+  partselsynth).
+
+* inout ports are not converted (tran-VP).
+
+* Variable selects of a non-zero based vector in a continuous assignment are
+  not converted.
+
+* There is no support for translating a zero repeat in a continuous
+  assignment. It is currently just dropped.
+
+* A pull device connected to a signal select is not translated correctly (this
+  may be fixed).
+
+* L-value indexed part selects with a constant undefined base in a continuous
+  assignment are not translated.
+
+* Logic gates are not arrayed exactly the same as the input and the instance
+  name is not always the same.
+
+* The signed support does not generate $signed() or $unsigned() function calls
+  in a continuous assignment expression.
+
+* The special power operator cases are not converted in a continuous
+  assignment.
+
+* Currently a signed constant that sets the MSB in an unsigned context will be
+  displayed as a negative value (e.g. bit = 1 translates to bit = -1).
+
+* Can net arrays, etc. be unrolled?
+
+* Can generate blocks be converted?
+
@@ -0,0 +1,63 @@
+
+The vvp Code Generator (-tvvp)
+==============================
+
+The vvp target generates code for the "vvp" run time. This is the most
+commonly used target for Icarus Verilog, as it is the main simulation engine.
+
+Example command::
+
+    %  iverilog -o top.vvp -s top hello_world.v
+
+Equivalent command::
+
+    %  iverilog -o top.vvp -tvvp -s top hello_world.v
+
+With this example code in `hello_world.v`:
+
+.. code-block:: verilog
+
+    module top;
+        initial $display("Hello World!");
+    endmodule
+
+The resulting `top.vvp` will contain something similar to::
+
+    #! /usr/local/bin/vvp
+    :ivl_version "13.0 (devel)" "(s20221226-119-g8cb2e1a05-dirty)";
+    :ivl_delay_selection "TYPICAL";
+    :vpi_time_precision + 0;
+    :vpi_module "/usr/local/lib/ivl/system.vpi";
+    :vpi_module "/usr/local/lib/ivl/vhdl_sys.vpi";
+    :vpi_module "/usr/local/lib/ivl/vhdl_textio.vpi";
+    :vpi_module "/usr/local/lib/ivl/v2005_math.vpi";
+    :vpi_module "/usr/local/lib/ivl/va_math.vpi";
+    S_0x563c3c5d1540 .scope module, "top" "top" 2 1;
+     .timescale 0 0;
+        .scope S_0x563c3c5d1540;
+    T_0 ;
+        %vpi_call 2 2 "$display", "Hello World!" {0 0 0};
+        %end;
+        .thread T_0;
+    # The file index is used to find the file name in the following table.
+    :file_names 3;
+        "N/A";
+        "<interactive>";
+        "hello_world.v";
+
+The first line contains the shebang. If this file is executed, the shebang tells the shell to use vvp for the execution of this file.
+
+To run the simulation, execute::
+
+    %  ./top.vvp
+
+Or you can call vvp directly::
+
+    %  vvp top.vvp
+
+Next are some directives. The first one, `:ivl_version` specifies which version of iverilog this file was created with. Next is the delay selection with "min:typical:max" values and the time precision, which we did not set specifically, so the default value is used. The next lines tell vvp which VPI modules to load and in which order. The next lines tell vvp which VPI modules to load and in what order. Next, a new scope is created with the `.scope` directive and the timescale is set with `.timescale`. A thread `T_0` is created that contains two instructions: `%vpi_call` executes the VPI function `$display` with the specified arguments, and `%end` terminates the simulation.
+
+Opcodes
+-------
+
+The various available opcodes can be seen in :doc:`Opcodes <../developer/guide/vvp/opcodes>`
@@ -0,0 +1,198 @@
+
+Command File Format
+===================
+
+The basic format of a command file is one source file or compiler argument per
+line. Command files may also have comments of various form, and options for
+controlling the compiler.
+
+Comments
+--------
+
+Lines that start with a "#" character are comments. All text after the "#"
+character, is ignored.
+
+The "//" character sequence also starts a comment that continues to the end of
+the line.
+
+The "/\*" and "\*/" character sequences surround multi-line comments. All the
+text between the comment start and comment end sequences is ignored, even when
+that text spans multiple lines. This style of comment does not nest, so a "/\*"
+sequence within a multi-line comment is probably an error.
+
+Plus-args
+---------
+
+Outside of comments, lines that start with a "+" character are compiler
+arguments. These are called plusargs but they are not the same as extended
+arguments passed to the "vvp" command. The supported plusargs are definitively
+listed in the iverilog manual page.
+
+The plusargs lines are generally "+<name>+..." where the name is the name of
+an switch, and the arguments are separated by "+" characters, as in::
+
+  +libext+.v+.V+.ver
+
+With plusargs lines, the "+" character separates tokens, and not white space,
+so arguments, which may include file paths, may include spaces. A plusarg line
+is terminated by the line end.
+
+The line in the command file may also be a "-y" argument. This works exactly
+the same as the::
+
+  -y <path>
+
+argument to the compiler; it declares a library directory. The "-y" syntax is
+also a shorthand for the "+libdir" plusarg, which is a more general form::
+
+  +libdir+<path>...
+
+File Names
+----------
+
+Any lines that are not comments, compiler arguments or plusargs are taken by
+the compiler to be a source file. The path can contain any characters (other
+then comment sequences) including blanks, although leading and trailing white
+space characters are stripped. The restriction of one file name per line is in
+support of operating systems that can name files any which way. It is not
+appropriate to expect white spaces to separate file names.
+
+Variable Substitution
+---------------------
+
+The syntax "$(name)" is a variable reference, and may be used anywhere within
+filenames or directory names. The contents of the variable are read from the
+environment and substituted in place of the variable reference. In Windows,
+these environment variables are the very same variables that are set through
+the Control Panel->System dialog box, and in UNIX these variables are
+environment variables as exported by your shell.
+
+Variables are useful for giving command files some installation
+independence. For example, one can import a vendor library with the line::
+
+  -y $(VENDOR)/verilog/library
+
+in the command file, and the next programmer will be able to use this command
+file without editing it to point to the location of VENDOR on his
+machine. Note the use of forward slashes as a directory separator. This works
+even under Windows, so always use forward slashes in file paths and Windows
+and UNIX users will be able to share command files.
+
+An Example
+----------
+
+This sample::
+
+  # This is a comment in a command file.
+  # The -y statement declares a library
+  # search directory
+  -y $(PROJ_LIBRARY)/prims
+  #
+  # This plusarg tells the compiler that
+  # files in libraries may have .v or .vl
+  # extensions.
+  +libext+.v+.vl
+  #
+  main.v // This is a source file
+  #
+  # This is a file name with blanks.
+  C:/Project Directory/file name.vl
+
+is a command file that demonstrates the major syntactic elements of command
+files. It demonstrates the use of comments, variables, plusargs and file
+names. It contains a lot of information about the hypothetical project, and
+suggests that command files can be used to describe the project as a whole
+fairly concisely.
+
+The syntax of command files is rich enough that they can be used to document
+and control the assembly and compilation of large Verilog programs. It is not
+unusual to have command files that are hundreds of lines long, although
+judicious use of libraries can lead to very short command files even for large
+designs. It is also practical to have different command files that pull
+together combinations of sources and compiler arguments to make different
+designs from the same Verilog source files.
+
+Summary
+-------
+
+Given the above description of the command file format, the following is a
+list of the special records with their meaning.
+
+* +libdir+*dir-path*
+
+  Specify directories to be searched for library modules. The *dir-path* can
+  have multiple directories, separated by "+" characters.
+
+* +libdir-nocase+dir-path
+
+  This is the same as "+libdir+", but when searching "nocase" libraries for
+  module files, case will not be taken as significant. This is useful when the
+  library is on a case insensitive file system.
+
+* +libext+*suffix-string*
+
+  Declare the suffix strings to use when searching library directories for
+  Verilog files. The compiler may test a list of suffix strings to support a
+  variety of naming conventions.
+
+* -y dir-path
+
+  This is like "+libdir+" but each line takes only one path. Like "+libdir+"
+  there can be multiple "-y" records to declare multiple library
+  directories. This is similar to the "-y" flag on the iverilog command line.
+
+* -v *file-name* or -l *file-name*
+
+  This declares a library file. A library file is just like any other Verilog
+  source file, except that modules declared within it are not implicitly
+  possible root modules.
+
+  NOTE: The "-l" alias is new as of 2 October 2016. It will become available
+  in releases and snapshots made after that date.
+
+* +incdir+*include-dir-path*
+
+  Declare a directory or list of directories to search for files included by
+  the "include" compiler directive. The directories are searched in
+  order. This is similar to the "-I" flag on the iverilog command line.
+
+* +define+*name=value*
+
+  Define the preprocessor symbol "name" to have the string value "value". If
+  the value (and the "=") are omitted, then it is assumed to be the string
+  "1". This is similar to the "-D" on the iverilog command line.
+
+* +timescale+*units/precision*
+
+  Define the default timescale. This is the timescale that is used if there is
+  no other timescale directive in the Verilog source. The compiler default
+  default is "+timescale+1s/1s", which this command file setting can
+  change. The format of the units/precision is the same as that for the
+  timescale directive in the verilog source.
+
+* +toupper-filename
+
+  This token causes file names after this in the command file to be translated
+  to uppercase. this helps with situations where a directory has passed
+  through a DOS machine (or a FAT file system) and in the process the file
+  names become munged. This is not meant to be used in general, but only in
+  emergencies.
+
+* +tolower-filename
+
+  The is the lowercase version of "+toupper-filename".
+
+* +parameter+*name=value*
+
+  This token causes the compiler to override a parameter value for a top-level
+  module. For example, if the module main has the parameter WIDTH, set the
+  width like this "+parameter+main.WIDTH=5". Note the use of the complete
+  hierarchical name. This currently only works for parameters defined in root
+  (top level) modules and a defparam may override the command file value.
+
+* +vhdl-work+*path*
+
+  When compiling VHDL, this token allows control over the directory to use for
+  holding working package declarations. For example, "+vhdl-work+workdir" will
+  cause the directory "workdir" to be used as a directory for holding working
+  working copies of package headers.
@@ -0,0 +1,476 @@
+
+
+iverilog Command Line Flags
+===========================
+
+The iverilog command is the compiler/driver that takes the Verilog input and
+generates the output format, whether the simulation file or synthesis
+results. This information is at least summarized in the iverilog man page
+distributed in typical installations, but here we try to include more detail.
+
+General
+-------
+
+These flags affect the general behavior of the compiler.
+
+* -c <cmdfile>
+
+  This flag selects the command file to use. The command file is an
+  alternative to writing a long command line with a lot of file names and
+  compiler flags. See the Command File Format page for more information.
+
+* -d <flag>
+
+  Enable compiler debug output. These are aids for debugging Icarus Verilog,
+  and this flag is not commonly used.
+  The flag is one of these debug classes:
+
+  * scope
+  * eval_tree
+  * elaborate
+  * synth2
+
+* -g <generation flag>
+  the generation is the compiler language, and specifies the language and
+  extensions to use during the compile. The language level can be selected
+  by a major level selector, and by controlling various features. Various
+  "-g" flags can be compined. For example, to get Verilog 2001 without
+  specify supoprt, use "-g2001 -gno-specify".
+
+  The supported flags are:
+
+  * 1995
+
+    This flag enables the IEEE1364-1995 standard.
+
+  * 2001
+
+    This flag enables the IEEE1364-2001 standard.
+
+  * 2001-noconfig
+
+    This flag enables the IEEE1364-2001 standard with config file support
+    disabled. This eliminates the config file keywords from the language and
+    so helps some programs written to older 2001 support compile.
+
+  * 2005
+    This flag enables the IEEE1364-2005 standard. This is default enabled
+    after v0.9.
+
+  * 2009
+    This flag enables the IEEE1800-2009 standard, which includes
+    SystemVerilog. The SystemVerilog support is not present in v0.9 and
+    earlier. It is new to git master as of November 2009. Actual SystemVerilog
+    support is ongoing.
+
+  * 2012
+
+    This flag enables the IEEE1800-2012 standard, which includes
+    SystemVerilog.
+
+  * 2017
+
+    This flag enables the IEEE1800-2017 standard, which includes
+    SystemVerilog.
+
+  * 2023
+
+    This flag enables the IEEE1800-2023 standard, which includes
+    SystemVerilog.
+
+  * verilog-ams
+
+    This flag enables Verilog-AMS features that are supported by Icarus
+    Verilog. (This is new as of 5 May 2008.)
+
+  * assertions/supported-assertions/no-assertions
+
+    Enable or disable SystemVerilog assertions. When enabled, assertion
+    statements are elaborated. When disabled, assertion statements are parsed
+    but ignored. The supported-assertions option only enables assertions that
+    are currently supported by the compiler.
+
+  * specify/no-specify
+
+    Enable or disable support for specify block timing controls. When
+    disabled, specify blocks are parsed but ignored. When enabled, specify
+    blocks cause timing path and timing checks to be active.
+
+  * std-include/no-std-include
+
+    Enable or disable the search of a standard installation include directory
+    after all other explicit include directories. This standard include
+    directory is a convenient place to install standard header files that a
+    Verilog program may include.
+
+  * relative-include/no-relative-include
+
+    Enable or disable adding the local files directory to the beginning of the
+    include file search path. This allows files to be included relative to the
+    current file.
+
+  * xtypes/no-xtypes
+
+    Enable or disable support for extended types. Enabling types allows for
+    new types and type syntax that are Icarus Verilog extensions.
+
+  * io-range-error/no-io-range-error
+
+    When enabled the range for a port and any associated net declaration must
+    match exactly. When disabled a scalar port is allowed to have a net
+    declaration with a range (obsolete usage). A warning message will be
+    printed for this combination. All other permutations are still considered
+    an error.
+
+  * strict-ca-eval/no-strict-ca-eval
+
+    The standard requires that if any input to a continuous assignment
+    expression changes value, the entire expression is re-evaluated. By
+    default, parts of the expression that do not depend on the changed input
+    value(s) are not re-evaluated. If an expression contains a call to a
+    function that doesn't depend solely on its input values or that has side
+    effects, the resulting behavior will differ from that required by the
+    standard. Enabling strict-ca-eval will force standard compliant behavior
+    (with some loss in performance).
+
+  * strict-expr-width/no-strict-expr-width
+
+    Enable or disable strict compliance with the standard rules for
+    determining expression bit lengths. When disabled, the RHS of a parameter
+    assignment is evaluated as a lossless expression, as is any expression
+    containing an unsized constant number, and unsized constant numbers are
+    not truncated to integer width.
+
+  * strict-declaration/no-strict-declaration
+
+  * strict-net-var-declaration/no-strict-net-var-declaration
+
+  * strict-parameter-declaration/no-strict-parameter-declaration
+
+    The standards require that nets, variables, and parameters must be
+    declared lexically before they are used.  Using -gno-strict-declaration
+    will allow using a data object before declaration, with a warning. The
+    warning can be suppressed with -Wno-declaration-after-use.  The option
+    can be applied for nets and variables and for parameters separately.
+
+  * shared-loop-index/no-shared-loop-index
+
+    Enable or disable the exclusion of for-loop control variables from
+    implicit event_expression lists. When enabled, if a for-loop control
+    variable (loop index) is only used inside the for-loop statement, the
+    compiler will not include it in an implicit event_expression list it
+    calculates for that statement or any enclosing statement. This allows the
+    same control variable to be used in multiple processes without risk of
+    entering an infinite loop caused by each process triggering all other
+    processes that use the same variable. For strict compliance with the
+    standards, this behaviour should be disabled.
+
+* -i
+
+  Ignore missing modules. Normally it is an error if a module instantiation
+  refers to an undefined module. This option causes the compiler to skip over
+  that instantiation. It will also stop the compiler returning an error if
+  there are no top level modules. This allows the compiler to be used to check
+  incomplete designs for errors.
+
+  NOTE: The "-i" flag was added in v11.0.
+
+* -L <path>
+
+  Add the specified directory to the path list used to locate VPI modules. The
+  default path includes only the install directory for the system.vpi module,
+  but this flag can add other directories. Multiple paths are allowed, and the
+  paths will be searched in order.
+
+  NOTE: The "-L" flag was added in v11.0.
+
+* -l <path>
+
+  Add the specified file to the list of source files to be compiled, but mark
+  it as a library file. All modules contained within that file will be treated
+  as library modules, and only elaborated if they are instantiated by other
+  modules in the design.
+
+  NOTE: The "-l" flag is new as of 2 October 2016. It will become available in
+  releases and snapshots made after that date.
+
+* -M<mode>=<path>
+
+  Write into the file specified by path a list of files that contribute to the
+  compilation of the design.
+
+  If _mode_ is *all* or *prefix*, this includes files that are included by
+  include directives and files that are automatically loaded by library
+  support as well as the files explicitly specified by the user.
+
+  If _mode_ is *include*, only files that are included by include directives
+  are listed.
+
+  If _mode_ is *module*, only files that are specified by the user or that are
+  automatically loaded by library support are listed. The output is one file
+  name per line, with no leading or trailing space.
+
+  If _mode_ is *prefix*, files that are included by include directives are
+  prefixed by "I " and other files are prefixed by "M ".
+
+* -m<module>
+
+  Add this module to the list of VPI modules to be loaded by the
+  simulation. Many modules can be specified, and all will be loaded, in the
+  order specified. The system module is implicit and always included (and
+  loaded last).
+
+  If the specified name includes at least one directory character, it is
+  assumed to be prefixed by the path to the module, otherwise the module is
+  searched for in the paths specified by preceding -L options, and if not
+  found there, in the iverilog base directory.
+
+  NOTE: The "-m" flag was added in v11.0.
+
+* -o <path>
+
+  Specify the output file. The <path> is the name of the file to hold the
+  output. The default is "a.out".
+
+* -S
+
+  Activate synthesis. This flag tells the compiler to do what synthesis it can
+  do before calling the code generator. This flag is rarely used explicitly,
+  and certain code generators will implicitly enable this flag.
+
+* -u
+
+  Treat each source file as a separate compilation unit (as defined in
+  SystemVerilog). If compiling for an IEEE1364 generation, this will just
+  reset all compiler directives (including macro definitions) before each new
+  file is processed.
+
+  NOTE: The "-u" flag was added in v11.0.
+
+* -v
+
+  Be verbose. Print copyright information, progress messages, and some timing
+  information about various compilation phases.
+
+  (New in snapshots after 2014-12-16) If the selected target is vvp, the -v
+  switch is appended to the shebang line in the compiler output file, so
+  directly executing the compiler output file will turn on verbose messages in
+  vvp. This extra verbosity can be avoided by using the vvp command to
+  indirectly execute the compiler output file.
+
+* -V
+
+  Print the version information. This skips all compilation. Just print the
+  version information, including version details for the various components of
+  the compiler.
+
+* -R
+
+  Print the runtime paths of the compiler. This can be useful to find, e.g.,
+  the include path of vpi_user.h.
+
+* -W<warning class>
+
+  Enable/disable warnings. All the warning types (other then "all") can be
+  prefixed with no- to disable that warning.
+
+  * all
+
+    This enables almost all of the available warnings. More specifically, it
+    enables these warnings::
+
+      -Wanachronisms
+      -Wimplicit
+      -Wimplicit-dimensions
+      -Wdeclaration-after-use
+      -Wmacro-replacement
+      -Wportbind
+      -Wselect-range
+      -Wtimescale
+      -Wsensitivity-entire-array
+
+  * anachronisms
+
+    This enables warnings for use of features that have been deprecated or
+    removed in the selected generation of the Verilog language.
+
+  * implicit
+
+    This enables warnings for creation of implicit declarations. For example,
+    if a scalar wire X is used but not declared in the Verilog source, this
+    will print a warning at its first use.
+
+  * implicit-dimensions
+
+    This enables warnings for the case where a port declaration or a var/net
+    declaration for the same name is missing dimensions. Normally, Verilog
+    allows you to do this (the undecorated declaration gets its dimensions
+    form the decorated declaration) but this is no longer common, and some
+    other tools (notable Xilix synthesizers) do not handle this correctly.
+
+    This flag is supported in release 10.1 or master branch snapshots after
+    2016-02-06.
+
+  * declaration-after-use
+
+    This enables warnings for declarations after use, when those are not
+    flagged as errors (enabled by default). Use no-declaration-after-use
+    to disable this.
+
+    This flag was added in version 14.0 or later (and is in the master branch
+    as of 2026-03-21).
+
+  * macro-redefinition
+
+    This enables warnings when a macro is redefined, even if the macro text
+    remains the same.
+
+    NOTE: The "macro-redefinition" flag was added in v11.0.
+
+  * macro-replacement
+
+    This enables warnings when a macro is redefined and the macro text
+    changes. Use no-macro-redefinition to disable this,
+
+    NOTE: The "macro-replacement" flag was added in v11.0.
+
+  * portbind
+
+    This enables warnings for ports of module instantiations that are not
+    connected properly, but probably should be. Dangling input ports, for
+    example, will generate a warning.
+
+  * select-range
+
+    This enables warnings for constant out-of-bound selects. This includes
+    partial or fully out-of-bound select as well as a select containing a 'bx
+    or 'bz in the index.
+
+  * timescale
+
+    This enables warnings for inconsistent use of the timescale directive. It
+    detects if some modules have no timescale, or if modules inherit timescale
+    from another file. Both probably mean that timescales are inconsistent,
+    and simulation timing can be confusing and dependent on compilation order.
+
+  * infloop
+
+    This enables warnings for always statements that may have runtime infinite
+    loops (i.e. has paths with zero or no delay). This class of warnings is
+    not included in -Wall and hence does not have a no- variant. A fatal error
+    message will always be printed when the compiler can determine that there
+    will definitely be an infinite loop (all paths have no or zero delay).
+
+    When you suspect an always statement is producing a runtine infinite loop,
+    use this flag to find the always statements that need to have their logic
+    verified. it is expected that many of the warnings will be false
+    positives, since the code treats the value of all variables and signals as
+    indeterninite.
+
+  * sensitivity-entire-vector
+
+    This enables warnings for when a part select with an "always @*" statement
+    results in the entire vector being added to the implicit sensitivity
+    list. Although this behavior is prescribed by the IEEE standard, it is not
+    what might be expected and can have performance implications if the vector
+    is large.
+
+  * sensitivity-entire-array
+
+    This enables warnings for when a word select with an "always @*" statement
+    results in the entire array being added to the implicit sensitivity
+    list. Although this behavior is prescribed by the IEEE standard, it is not
+    what might be expected and can have performance implications if the array
+    is large.
+
+  * floating-nets
+
+    This enables warnings for nets that are present but have no drivers.
+
+    This flag was added in version 11.0 or later (and is in the master branch
+    as of 2015-10-01).
+
+* -y<libdir>
+
+  Append the directory to the library module search path. When the compiler
+  finds an undefined module, it looks in these directories for files with the
+  right name.
+
+* -Y<suf>
+
+  Appends suf to the list of file extensions that are used to resolve an
+  undefined module to a file name. Should be specified before any -y flag. For
+  example, this command::
+
+    % iverilog -Y .sv -y sources src.v
+
+  will try to resolve any undefined module m by looking into the directory
+  sources and checking if there exist files named m.v or m.sv.
+
+
+Preprocessor Flags
+------------------
+
+These flags control the behavior of the preprocessor. They are similar to
+flags for the typical "C" compiler, so C programmers will find them familiar.
+
+* -E
+
+  This flag is special in that it tells the compiler to only run the
+  preprocessor. This is useful for example as a way to resolve preprocessing
+  for other tools. For example, this command::
+
+    % iverilog -E -ofoo.v -DKEY=10 src1.v src2.v
+
+  runs the preprocessor on the source files src1.v and src2.v and produces the
+  single output file foo.v that has all the preprocessing (including header
+  includes and ifdefs) processed.
+
+* -D<macro>
+
+  Assign a value to the macro name. The format of this flag is one of::
+
+    -Dkey=value
+    -Dkey
+
+  The key is defined to have the given value. If no value is given, then it is
+  assumed to be "1". The above examples are the same as these defines in
+  Verilog source::
+
+    `define key value
+    `define key
+
+* -I<path>
+
+  Append directory <path> to list of directories searched for Verilog include
+  files. The -I switch may be used many times to specify several directories
+  to search, the directories are searched in the order they appear on the
+  command line.
+
+Elaboration Flags
+-----------------
+
+These are flags that pass information to the elaboration steps.
+
+* -P<symbol>=<value>
+
+  Define a parameter using the defparam behavior to override a parameter
+  values. This can only be used for parameters of root module instances.
+
+* -s <topmodule>
+
+  Specify the top level module to elaborate. Icarus Verilog will by default
+  choose modules that are not instantiated in any other modules, but sometimes
+  that is not sufficient, or instantiates too many modules. If the user
+  specifies one or more root modules with "-s" flags, then they will be used
+  as root modules instead.
+
+* -Tmin, -Ttyp, -Tmax
+
+  Select the timings to use. The Verilog language allows many timings to be
+  specified as three numbers, min:typical:max, but for simulation you need to
+  choose which set to use. The "-Tmin" flag tells the compiler to at
+  elaboration time choose "min" times. The default is "-Ttyp".
+
+Target Flags
+------------
@@ -0,0 +1,167 @@
+
+Getting Started With Icarus Verilog
+===================================
+
+Before getting started with actual examples, here are a few notes on
+conventions. First, command lines and sequences take the same arguments on all
+supported operating environments, including Linux, Windows and the various
+Unix systems. When an example command is shown in a figure, the generic prompt
+character "% " takes the place of whatever prompt string is appropriate for
+your system. Under Windows, the commands are invoked in a command window.
+
+Second, when creating a file to hold Verilog code, it is common to use the
+".v" or the ".vl" suffix. This is not a requirement imposed by Icarus Verilog,
+but a useful convention. Some people also use the suffixes ".ver" or even
+".vlg". Examples in this book will use the ".v" suffix.
+
+So let us start. Given that you are going to use Icarus Verilog as part of
+your design process, the first thing to do as a designer is learn how to
+compile and execute even the most trivial design. For the purposes of
+simulation, we use as our example the most trivial simulation, a simple Hello,
+World program.
+
+.. code-block:: verilog
+
+  module hello;
+    initial
+      begin
+        $display("Hello, World");
+        $finish ;
+      end
+  endmodule
+
+Use a text editor to place the program in a text file, hello.v, then compile
+this program with the command::
+
+  % iverilog -o hello hello.v
+
+The results of this compile are placed into the file "hello", because the "-o"
+flag tells the compiler where to place the compiled result. Next, execute the
+compiled program like so::
+
+  % vvp hello
+  Hello, World
+
+And there it is, the program has been executed. So what happened? The first
+step, the "iverilog" command, read and interpreted the source file, then
+generated a compiled result. The compiled form may be selected by command line
+switches, but the default is the "vvp" format, which is actually run later, as
+needed. The "vvp" command of the second step interpreted the "hello" file from
+the first step, causing the program to execute.
+
+The "iverilog" and "vvp" commands are the most important commands available to
+users of Icarus Verilog. The "iverilog" command is the compiler, and the "vvp"
+command is the simulation runtime engine. What sort of output the compiler
+actually creates is controlled by command line switches, but normally it
+produces output in the default vvp format, which is in turn executed by the
+vvp program.
+
+As designs get larger and more complex, they gain hierarchy in the form of
+modules that are instantiated within others, and it becomes convenient to
+organize them into multiple files. A common convention is to write one
+moderate sized module per file (or group related tiny modules into a single
+file) then combine the files of the design together during compilation. For
+example, the counter model in counter.v
+
+.. code-block:: verilog
+
+  module counter(out, clk, reset);
+
+    parameter WIDTH = 8;
+
+    output [WIDTH-1 : 0] out;
+    input	       clk, reset;
+
+    reg [WIDTH-1 : 0]   out;
+    wire	       clk, reset;
+
+    always @(posedge clk or posedge reset)
+      if (reset)
+        out <= 0;
+      else
+        out <= out + 1;
+
+  endmodule // counter
+
+and the test bench in counter_tb.v
+
+.. code-block:: verilog
+
+  module test;
+
+    /* Make a reset that pulses once. */
+    reg reset = 0;
+    initial begin
+       # 17 reset = 1;
+       # 11 reset = 0;
+       # 29 reset = 1;
+       # 11 reset = 0;
+       # 100 $stop;
+    end
+
+    /* Make a regular pulsing clock. */
+    reg clk = 0;
+    always #5 clk = !clk;
+
+    wire [7:0] value;
+    counter c1 (value, clk, reset);
+
+    initial
+       $monitor("At time %t, value = %h (%0d)",
+                $time, value, value);
+  endmodule // test
+
+are written into different files.
+
+The "iverilog" command supports multi-file designs by two methods. The
+simplest is to list the files on the command line::
+
+  % iverilog -o my_design  counter_tb.v counter.v
+  % vvp my_design
+
+This command compiles the design, which is spread across two input files, and
+generates the compiled result into the "my_design" file. This works for small
+to medium sized designs, but gets cumbersome when there are lots of files.
+
+Another technique is to use a commandfile, which lists the input files in a
+text file. For example, create a text file called "file_list.txt" with the
+files listed one per line::
+
+  counter.v
+  counter_tb.v
+
+Then compile and execute the design with a command like so::
+
+  % iverilog -o my_design -c file_list.txt
+  % vvp my_design
+
+The command file technique clearly supports much larger designs simply by
+saving you the trouble of listing all the source files on the command
+line. Name the files that are part of the design in the command file and use
+the "-c" flag to tell iverilog to read the command file as a list of Verilog
+input files.
+
+As designs get more complicated, they almost certainly contain many Verilog
+modules that represent the hierarchy of your design. Typically, there is one
+module that instantiates other modules but is not instantiated by any other
+modules. This is called a root module. Icarus Verilog chooses as roots (There
+can be more than one root) all the modules that are not instantiated by other
+modules. If there are no such modules, the compiler will not be able to choose
+any root, and the designer must use the "-sroot" switch to identify the root
+module, like this::
+
+  % iverilog -s main -o hello hello.v
+
+If there are multiple candidate roots, all of them will be elaborated. The
+compiler will do this even if there are many root modules that you do not
+intend to simulate, or that have no effect on the simulation. This can happen,
+for example, if you include a source file that has multiple modules, but are
+only really interested in some of them. The "-s" flag identifies a specific
+root module and also turns off the automatic search for other root
+modules. You can use this feature to prevent instantiation of unwanted roots.
+
+As designs get even larger, they become spread across many dozens or even
+hundreds of files. When designs are that complex, more advanced source code
+management techniques become necessary. These are described in later chapters,
+along with other advanced design management techniques supported by Icarus
+Verilog.
@@ -0,0 +1,173 @@
+
+Icarus Verilog Extensions
+=========================
+
+Icarus Verilog supports certain extensions to the baseline IEEE 1364
+standard. Some of these are picked from extended variants of the
+language, such as SystemVerilog, and some are expressions of internal
+behavior of Icarus Verilog, made available as a tool debugging aid.
+
+Don't use any of these extensions if you want to keep your code portable
+across other Verilog compilers.
+
+System Functions
+----------------
+
+``$is_signed(<expr>)``
+^^^^^^^^^^^^^^^^^^^^^^
+
+This function returns 1 if the expression contained is signed, or 0 otherwise.
+This is mostly of use for compiler regression tests.
+
+``$bits(<expr>)``, ``$sizeof(<expr>)``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``$bits`` system function returns the size in bits of the expression that
+is its argument. The result of this function is undefined if the argument
+doesn't have a self-determined size.
+
+The ``$sizeof`` system function is deprecated in favour of ``$bits``, which is
+the same thing, but included in the SystemVerilog definition.
+
+``$simtime()``
+^^^^^^^^^^^^^^
+
+This returns as a 64bit value the simulation time, unscaled by the time units
+of the local scope. This is different from the ``$time`` and ``$stime``
+functions which return the scaled times. This function is added for regression
+testing of the compiler and run time, but can be used by applications who
+really want the simulation time.
+
+Note that the simulation time can be confusing if there are lots of different
+```timescales`` within a design. It is not in general possible to predict
+what the simulation precision will turn out to be.
+
+``$mti_random()``, ``$mti_dist_uniform``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+These functions are similar to the IEEE 1364 standard ``$random`` functions,
+but they use the Mersenne Twister (MT19937) algorithm. This is considered an
+excellent random number generator, but does not generate the same sequence as
+the standardized ``$random``.
+
+System Tasks
+------------
+
+``$readmempath``
+^^^^^^^^^^^^^^^^
+
+The ``$readmemb`` and ``$readmemh`` system tasks read text files that contain
+data values to populate memories. Normally, those files are found in a current
+working directory. The ``$readmempath()`` system task can be used to create a
+search path for those files. For example:
+
+.. code-block:: verilog
+
+  reg [7:0] mem [0:7];
+  initial begin
+    $readmemh("datafile.txt", mem);
+  end
+
+This assumes that "datafile.txt" is in the current working directory where
+the ``vvp`` command is running. But with the ``$readmempath``, one can specify
+a search path:
+
+.. code-block:: verilog
+
+  reg [7:0] mem [0:7];
+  initial begin
+    $readmempath(".:alternative:/global/defaults");
+    $readmemh("datafile.txt", mem);
+  end
+
+In this example, "datafile.txt" is searched for in each of the directories
+in the above list (separated by ":" characters). The first located instance
+is the one that is used. So for example, if "./datafile.txt" exists, then it
+is read instead of "/global/defaults/datafile.txt" even if the latter exists.
+
+``$finish_and_return(code)``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This task operates the same as the ``$finish`` system task, but adds the
+feature of specifying an exit code for the interpreter. This can be useful in
+automated test environments to indicate whether the simulation finished with
+or without errors.
+
+Extended Verilog Data Types
+---------------------------
+
+This feature is turned on by the generation flag "-gxtypes" and turned
+off by the generation flag "-gno-xtypes". It is turned on by default.
+
+Icarus Verilog adds support for extended data types. This extended
+type syntax is based on a proposal by Cadence Design Systems,
+originally as an update to the IEEE 1364 standard. Icarus Verilog
+currently only takes the new primitive types from the proposal.
+
+SystemVerilog provides the same functionality using somewhat different
+syntax. This extension is maintained for backwards compatibility.
+
+- Types
+
+Extended data types separates the concept of net/variable from the
+data type. Both nets and variables can declared with any data
+type. The primitive types available are::
+
+    logic  - The familiar 0, 1, x and z, optionally with strength.
+    bool   - Limited to only 0 and 1
+    real   - 64-bit real values
+
+Nets with logic type may have multiple drivers with strength, and the
+value is resolved the usual way. Only logic values may be driven to
+logic nets, so bool values driven onto logic nets are implicitly
+converted to logic.
+
+Nets with any other type may not have multiple drivers. The compiler
+should detect the multiple drivers and report an error.
+
+- Declarations
+
+The declaration of a net is extended to include the type of the wire,
+with the syntax::
+
+    wire <type> <wire-assignment-list>... ;
+
+The <type>, if omitted, is taken to be logic. The "wire" can be any of
+the net keywords. Wires can be logic, bool, real, or vectors of logic
+or bool. Some valid examples::
+
+    wire real foo = 1.0;
+    tri logic bus[31:0];
+    wire bool addr[23:0];
+    ... and so on.
+
+The declarations of variables is similar. The "reg" keyword is used to
+specify that this is a variable. Variables can have the same data
+types as nets.
+
+- Ports
+
+Module and task ports in standard Verilog are restricted to logic
+types. This extension removes that restriction, allowing any of
+the above types to pass through the port consistent with the
+continuous assignment connectivity that is implied by the type.
+
+- Expressions
+
+Expressions in the face of real values is covered by the baseline
+Verilog standard.
+
+The bool type supports the same operators as the logic type, with the
+obvious differences imposed by the limited domain.
+
+Comparison operators (not case compare) return logic if either of
+their operands is logic. If both are bool or real (including mix of
+bool and real) then the result is bool. This is because comparison of
+bools and reals always return exactly true or false.
+
+Case comparison returns bool. This differs from baseline Verilog,
+which strictly speaking returns a logic, but only 0 or 1 values.
+
+Arithmetic operators return real if either of their operands is real,
+otherwise they return logic if either of their operands is logic. If
+both operands are bool, they return bool.
@@ -0,0 +1,438 @@
+
+Icarus Verilog Quirks
+=====================
+
+This is a list of known quirks that are presented by Icarus Verilog. The idea
+of this chapter is to call out ways that Icarus Verilog differs from the
+standard, or from other implementations.
+
+This is NOT AN EXHAUSTIVE LIST. If something is missing from this list, let us
+know and we can add documentation.
+
+Unsized Numeric Constants are Not Limited to 32 Bits
+----------------------------------------------------
+
+The Verilog standard allows Verilog implementations to limit the size of
+unsized constants to a bit width of at least 32. That means that a constant
+17179869183 (``36'h3_ffff_ffff``) may overflow some compilers. In fact, it
+is common to limit these values to 32 bits. However, a compiler may just as
+easily choose another width limit, for example 64 bits. That value is
+equally good.
+
+However, it is not required that an implementation truncate at 32 bits, and
+in fact Icarus Verilog does not truncate at all. It will make the unsized
+constant as big as it needs to be to hold the value accurately. This is
+especially useful in situations like this;
+
+.. code-block:: verilog
+
+ reg [width-1:0] foo = 17179869183;
+
+The programmer wants the constant to take on the width of the reg, which in
+this example is parameterized. Since constant sizes cannot be parameterized,
+the programmer ideally gives an unsized constant, which the compiler then
+expands/contracts to match the l-value.
+
+Also, by choosing to not ever truncate, Icarus Verilog can handle code written
+for a 64 bit compiler as easily as for a 32 bit compiler. In particular, any
+constants that the user does not expect to be arbitrarily truncated by their
+compiler will also not be truncated by Icarus Verilog, no matter what that
+other compiler chooses as a truncation point.
+
+Unsized Expressions
+-------------------
+
+Icarus Verilog classes any expression containing an unsized numeric constant
+or unsized parameter value that is not part of a self-determined operand as
+an unsized expression. When calculating the bit width of an unsized expression,
+it extends the width of the expression to avoid arithmetic overflow or
+underflow; in other words, the expression width will be made large enough to
+represent any possible arithmetic result of the expression. If the expression
+contains operations that do not follow the normal rules of arithmetic (e.g. an
+explicit or implicit cast between signed and unsigned values), the expression
+width will be extended to at least the width of an integer.
+
+An exception to the above is made if the expression contains a shift or power
+operator with a right hand operand that is a non-constant unsized expression.
+In this case any expansion of the expression width due to that operation is
+limited to the width of an integer, to avoid excessive expression widths
+(without this, an expression such as ``2**(i-1)``, where ``i`` is an integer,
+would be expanded to 2\**33 bits).
+
+The above behaviour is a deviation from the Verilog standard, which states
+that when calculating an expression width, the width of an unsized constant
+number is the same as the width of an integer. If you need strict standard
+compliance (for compatibility with other EDA tools), then the compiler has
+a command line option, ``-gstrict-expr-width``, which disables the special
+treatment of unsized expressions. With this option, the compiler will output
+a warning message if an unsized numeric constant is encountered that cannot
+be represented in integer-width bits and will truncate the value.
+
+If you are simulating synthesisable code, it is recommended that the
+``-gstrict-expr-width`` option is used, as this eliminates a potential
+source of synthesis vs. simulation mismatches.
+
+Unsized Parameters
+------------------
+
+Icarus Verilog classes any parameter declaration that has no explicit or
+implicit range specification as an unsized parameter declaration. When
+calculating the bit width of the final value expression for the parameter,
+it follows the same rules as it does for unsized expressions, regardless of
+whether or not the expression contains any unsized numeric constants.
+
+If the final value expression for an unsized parameter is an unsized
+expression (i.e. does contain unsized numeric constants), any subsequent use
+of that parameter will be treated as if it was an unsized numeric constant.
+If not, it will be treated as if it was a numeric constant of the appropriate
+size. For example, with the declarations:
+
+.. code-block:: verilog
+
+  localparam Value1 =  'd3 +  'd2;
+  localparam Value2 = 2'd3 + 2'd2;
+
+any subsequent use of ``Value1`` will be treated as if the programmer had
+written ``'d5`` and any subsequent use of ``Value2`` will be treated as if
+the programmer had written ``3'd5``. In particular, note that ``Value2`` can
+be used as a concatenation operand, but ``Value1`` cannot.
+
+The above behaviour is a deviation from the Verilog standard. As for
+unsized expressions, if you need strict standard compliance. use the
+``-gstrict-expr-width`` compiler option.
+
+Unsized Expressions as Arguments to Concatenation
+-------------------------------------------------
+
+The Verilog standard clearly states in 4.1.14:
+
+  "Unsized constant numbers shall not be allowed in  concatenations. This
+  is because the size of each  operand in the concatenation is needed to
+  calculate the complete size of the concatenation."
+
+So for example the expression ``{1'b0, 16}`` is clearly illegal. It also stands
+to reason that ``{1'b0, 15+1}`` is illegal, for exactly the same justification.
+What is the size of the expression (15+1)? Furthermore, it is reasonable to
+expect that (16) and (15+1) are exactly the same so far as the compiler is
+concerned.
+
+Unfortunately, Cadence seems to feel otherwise. In particular, it has been
+reported that although ``{1'b0, 16}`` causes an error, ``{1'b0, 15+1}`` is
+accepted. Further testing shows that any expression other than a simple
+unsized constant is accepted there, even if all the operands of all the
+operators that make up the expression are unsized integers.
+
+This is a semantic problem. Icarus Verilog doesn't limit the size of integer
+constants. This is valid as stated in 2.5.1 Note 3:
+
+  "The number of bits that make up an unsized number (which is a simple
+  decimal number or a number without the size specification) shall be
+  **at least** 32." [emphasis added]
+
+Icarus Verilog will hold any integer constant, so the size will be as large as
+it needs to be, whether that is 64 bits, 128 bits, or more. With this in mind,
+what is the value of these expressions?
+
+.. code-block:: verilog
+
+  {'h1_00_00_00_00}
+  {'h1 << 32}
+  {'h0_00_00_00_01 << 32}
+  {'h5_00_00_00_00 + 1}
+
+These examples show that the standard is justified in requiring that the
+operands of concatenation have size. The dispute is what it takes to cause
+an expression to have a size, and what that size is. Verilog-XL claims that
+(16) does not have a size, but (15+1) does. The size of the expression (15+1)
+is the size of the adder that is created, but how wide is the adder when
+adding unsized constants?
+
+One might note that the quote from section 4.1.14 says "Unsized constant
+numbers shall not be allowed." It does not say "Unsized expressions...", so
+arguably accepting (15+1) or even (16+0) as an operand to a concatenation is
+not a violation of the letter of the law. However, the very next sentence of
+the quote expresses the intent, and accepting (15+1) as having a more defined
+size then (16) seems to be a violation of that intent.
+
+Whatever a compiler decides the size is, the user has no way to predict it,
+and the compiler should not have the right to treat (15+1) any differently
+then (16). Therefore, Icarus Verilog takes the position that such expressions
+are unsized and are not allowed as operands to concatenations. Icarus Verilog
+will in general assume that operations on unsized numbers produce unsized
+results. There are exceptions when the operator itself does define a size,
+such as the comparison operators or the reduction operators. Icarus Verilog
+will generate appropriate error messages.
+
+Scope of Macro Defines Doesn't Extend into Libraries
+----------------------------------------------------
+
+Icarus Verilog does preprocess modules that are loaded from libraries via the
+``-y`` mechanism to substitute macros and load includes. However, the only
+macros defined during compilation of an automatically loaded library module
+file are those that it defines itself (or includes) or that are defined on the
+command line or in the command file. Specifically, macros defined in the non-
+library source files are not remembered when the library module is loaded, and
+macros defined in a library module do not escape into the rest of the design.
+This is intentional. If it were otherwise, then compilation results might vary
+depending on the order that libraries are loaded, and that is unacceptable.
+
+For example, given sample library module ``a.v``:
+
+.. code-block:: verilog
+
+  `define MACRO_A 1
+  module a(input x);
+    always @(x) $display("x=",x);
+  endmodule
+
+and sample library module ``b.v``:
+
+.. code-block:: verilog
+
+  module b(input y);
+  `ifdef MACRO_A
+    always @(y) $display("MACRO_A is defined",,y);
+ `else
+    always @(y) $display("MACRO_A is NOT defined",,y);
+  `endif
+  endmodule
+
+If a program instantiates both of these modules, there is no way to know
+which will be loaded first by the compiler, so if the definition of
+``MACRO_A`` in ``a.v`` were to escape, then there is no way to predict or
+control whether ``MACRO_A`` is defined when ``b.v`` is processed. So the
+preprocessor processes automatic library module files as if they are in
+their own compilation unit, and you can know that ``MACRO_A`` will not be
+defined in ``b.v`` unless it is defined on the command line (a ``-D`` flag)
+or in the command file (a ``+define+`` record.)
+
+Of course if ``a.v`` and ``b.v`` were listed in the command file or on the
+command line, then the situation is different; the order is clear. The files
+are processed as if they were concatenated in the order that they are listed
+on the command line. The non-library modules are all together in a main
+compilation unit, and they are all processed before any library modules are
+loaded.
+
+It is said that some commercial compilers do allow macro definitions to span
+library modules. That's just plain weird. However, there is a special case
+that Icarus Verilog does handle. Preprocessor definitions that are made in
+files explicitly listed on the command line or in the command file, do pass
+into implicitly loaded library files. For example, given the source file
+``x.v``:
+
+.. code-block:: verilog
+
+  module main;
+    reg foo;
+    b dut(foo);
+  endmodule
+  `define MACRO_A
+
+and the library module file ``b.v`` described above, the situation is well
+defined, assuming the ``x.v`` file is listed on the command line or in the
+command file. The library module will receive the ``MACRO_A`` definition
+from the last explicitly loaded source file. The position of the define of
+``MACRO_A`` in the explicitly loaded source files does not matter, as all
+explicitly loaded source files are preprocessed before any library files
+are loaded.
+
+Continuous Assign L-Values Can Implicit-Define Wires
+----------------------------------------------------
+
+The IEEE 1364-2001 standard, Section 3.5, lists the cases where nets may be
+implicitly created. These include:
+
+- identifier is a module port
+- identifier is passed as a port to a primitive or module
+
+This does not seem to include continuous assignment l-values (or r-values)
+so the standard does not justify allowing implicit declarations of nets by
+continuous assignment.
+
+However, it has been reported that many Verilog compilers, including the big
+name tools, do allow this. So, Icarus Verilog will allow it as well, as an
+extension. If ``-gxtypes`` (the default) is used, this extension is enabled.
+To turn off this behavior, use the ``-gno-xtypes`` flag.
+
+Dumping Array Words (``$dumpvars``)
+-----------------------------------
+
+Icarus has the ability to dump individual array words. They are only dumped
+when explicitly passed to $dumpvars. They are not dumped by default. For
+example given the following:
+
+.. code-block:: verilog
+
+  module top;
+    reg [7:0] array [2:0];
+    initial begin
+      $dumpvars(0, array[0], array[1]);
+      ...
+    end
+  endmodule
+
+``array[0]`` and ``array[1]`` will be dumped whenever they change value. They
+will be displayed as an escaped identifier and GTKWave fully supports this.
+Note that this is an implicitly created escaped identifier that could conflict
+with an explicitly created escaped identifier. You can automate adding the
+array word by adding an index definition
+
+.. code-block:: verilog
+
+  integer idx;
+
+and replacing the previous $dumpvars statement with
+
+.. code-block:: verilog
+
+  for (idx = 0; idx < 2; idx = idx + 1) $dumpvars(0, array[idx]);
+
+This will produce the same results as the previous example, but it is much
+easier to specify/change which elements are to be dumped. One important note
+regarding this syntax. Most system tasks/functions keep the variable selection
+(for this case it is a variable array word selection) context. If ``$dumpvars``
+did this then all callback created would point to this element and would use
+the same index which for the example above would have the value 2. This is
+certainly not what is desired and for this special case when ``$dumpvars``
+executes it uses the current index value to create a constant array selection
+and that is monitored instead of the original variable selection.
+
+Referencing Declarations Within an Unnamed Generate Block
+---------------------------------------------------------
+
+The IEEE 1364-2005 standard permits generate blocks to be unnamed, but states:
+
+  "If the generate block selected for instantiation is not named, it still
+  creates a scope; but the declarations within it cannot be referenced using
+  hierarchical names other than from within the hierarchy instantiated by the
+  generate block itself."
+
+The standard later defines a scheme for automatically naming the unnamed
+scopes for use with external interfaces.
+
+Icarus Verilog implements the defined automatic naming scheme, but does not
+prevent the automatically generated names being used in a hierarchical
+reference. This behaviour is harmless - the automatically generated names are
+guaranteed to be unique within the enclosing scope, so there is no possibility
+of confusion with explicit scope names. However, to maintain code portability,
+it is recommended that this behavior is not exploited.
+
+``%g/%G`` Format Specifiers
+---------------------------
+
+In the IEEE 1364-2001 standard there is a general statement that the real
+number format specifiers will use the full formatting capabilities of C.
+This is then followed by an example that describes ``%10.3g``. The example
+description would be correct for the ``%e`` format specifier which should
+always have three fractional digits, but the ``%g`` format specifier does
+not work that way. For it the ``.3`` specifies that there will be three
+significant digits. What this means is that ``%g`` will always produce one
+less significant digit than ``%e`` and will only match the output from ``%f``
+for certain values. For example:
+
+.. code-block:: verilog
+
+  module top_level;
+    real rval;
+    initial begin
+      rval = 1234567890;
+      $display("This is g and e: %10.3g, %10.3e.", rval, rval);
+      rval = 0.1234567890;
+      $display("This is g and f: %10.3g, %10.3f.", rval, rval);
+      rval = 1.234567890;
+      $display("This is more g and f: %10.3g, %10.3f.", rval, rval);
+    end
+  endmodule // top_level
+
+will produce the following output:
+
+.. code-block:: verilog
+
+ This is g and e:   1.23e+09,  1.235e+09.
+ This is g and f:      0.123,      0.123.
+ This is more g and f:       1.23,      1.235.
+
+``%t`` Time Format Specifier Can Specify Width
+----------------------------------------------
+
+Standard Verilog does not allow width fields in the ``%t`` formats of display
+strings. For example, this is illegal:
+
+.. code-block:: verilog
+
+  $display("Time is %0t", $time);
+
+Standard Verilog instead relies on the ``$timeformat`` to completely specify
+the format.
+
+Icarus Verilog allows the programmer to specify the field width. The ``%t``
+format in Icarus Verilog works exactly as it does in standard Verilog.
+However, if the programmer chooses to specify a minimum width (i.e., ``%5t``),
+then for that display Icarus Verilog will override the ``$timeformat`` minimum
+width and use the explicit minimum width.
+
+``%v`` Format Specifier Can Display Vectors
+-------------------------------------------
+
+The IEEE 1364-2005 standard limits the ``%v`` specifier in display strings to
+work only with a single bit. Icarus Verilog extends that to support displaying
+the strength of vectors. The output is a strength specifier for each bit of the
+vector, with underscore characters separating each bit, e.g. ``St0_St1_Pu1_HiZ``.
+Most other tools will just print the strength of the least significant bit of
+a vector, so this may give different output results for code that otherwise
+works fine.
+
+Assign/Deassign and Force/Release of Bit/Part Selects
+-----------------------------------------------------
+
+Icarus Verilog allows as an extension the assign/deassign and force/release
+of variable bit and part selects in certain cases. This allows the Verilog
+test bench writer to assign/deassign for example single bits of a variable
+(register, etc.). Other tools will report this as an error.
+
+``repeat`` Statement is Sign Aware
+----------------------------------
+
+The standard does not specify what to do for this case, but it does say what
+a repeat event control should do. In Icarus Verilog the ``repeat`` statement
+is consistent with the repeat event control definition. If the argument is
+signed and is a negative value this will be treated the same as an argument
+value of 0.
+
+Built-in System Functions May Be Evaluated at Compile Time
+----------------------------------------------------------
+
+Certain of the system functions have well-defined meanings, so can
+theoretically be evaluated at compile-time, instead of using runtime VPI
+code. Doing so means that VPI cannot override the definitions of functions
+handled in this manner. On the other hand, this makes them synthesizable,
+and also allows for more aggressive constant propagation. The functions
+handled in this manner are:
+
+- ``$bits``
+- ``$signed``
+- ``$sizeof``
+- ``$unsigned``
+
+Implementations of these system functions in VPI modules will be ignored.
+
+``vpiScope`` Iterator on ``vpiScope`` Objects
+---------------------------------------------
+
+In the VPI, the normal way to iterate over ``vpiScope`` objects contained
+within a ``vpiScope`` object, is the ``vpiInternalScope`` iterator. Icarus
+Verilog adds support for the ``vpiScope`` iterator of a ``vpiScope`` object,
+that iterates over *everything* that is contained in the current scope. This
+is useful in cases where one wants to iterate over all the objects in a scope
+without iterating over all the contained types explicitly.
+
+Time 0 Race Resolution
+----------------------
+
+Combinational logic is routinely modelled using always blocks. However, this
+can lead to race conditions if the inputs to the combinational block are
+initialized in initial statements. Icarus Verilog slightly modifies time 0
+scheduling by arranging for always statements with ANYEDGE sensitivity lists
+to be scheduled before any other threads. This causes combinational always
+blocks to be triggered when the values in the sensitivity list are initialized
+by initial threads.
@@ -0,0 +1,25 @@
+
+Icarus Verilog Usage
+====================
+
+This section contains documents to help support Icarus Verilog users.
+
+.. toctree::
+   :maxdepth: 1
+
+   installation
+   getting_started
+   simulation
+   command_line_flags
+   command_files
+   verilog_attributes
+   ivlpp_flags
+   vvp_flags
+   vvp_debug
+   vvp_library
+   vhdlpp_flags
+   waveform_viewer
+   vpi
+   icarus_verilog_extensions
+   icarus_verilog_quirks
+   reporting_issues
@@ -0,0 +1,377 @@
+
+Installation Guide
+==================
+
+Icarus Verilog may be installed from source code (either from ``git`` or a
+released `tar/zip` file), or from pre-packaged binary distributions. If you
+don't have a need for the very latest, and prepackaged binaries are available,
+that is the easiest place to start.
+
+Installation From Source
+------------------------
+
+Icarus is developed for Unix-like environments but can also be compiled on
+Windows systems using the `Cygwin/MSYS2` environments or `MinGW` compilers. The
+following instructions are the common steps for obtaining the Icarus Verilog
+source code, compiling, installing, and checking the compiled code is working
+properly. Note that there are pre-compiled and/or prepackaged versions for a
+variety of systems, so if you find an appropriate packaged version, then that
+is the easiest way to install.
+
+The source code for Icarus is stored under the `git` source code control
+system. You can use ``git`` to get the latest development head or the latest of
+a specific branch. Stable releases are placed on branches, and in particular V12
+stable releases are on the branch "v12-branch" To get the development version
+of the code follow these steps::
+
+  % git config --global user.name "Your Name Goes Here"
+  % git config --global user.email [email protected]
+  % git clone https://github.com/steveicarus/iverilog.git
+
+The first two lines are optional and are used to tell git who you are. This
+information is important if/when you submit a patch. We suggest that you add
+this information now so you don't forget to do it later. The clone will create
+a directory, named `iverilog`, containing the source tree, and will populate
+that directory with the most current source from the HEAD of the repository.
+
+Change into this directory using::
+
+  % cd iverilog
+
+Normally, this is enough as you are now pointing at the most current
+development code, and you have implicitly created a branch `master` that
+tracks the development head. However, If you want to actually be working on
+the `v12-branch` (the branch where the latest V12 patches are) then you
+checkout that branch with the command::
+
+  % git checkout --track -b v12-branch origin/v12-branch
+
+This creates a local branch that tracks the `v12-branch` in the repository, and
+switches you over to your new `v12-branch`. The tracking is important as it
+causes pulls from the repository to re-merge your local branch with the remote
+`v12-branch`. You always work on a local branch, then merge only when you
+push/pull from the remote repository.
+
+The choice between the development branch and the latest released branch
+depends on your stability requirements. The released branch will only get bug
+fixes. It will not get any enhancements or changes in the compiler output
+format. Unlike many project the development branch is fairly stable with only
+occasional periods of instability. We do most of our big changes in side
+branches and only merge them into the development branch when they are clean.
+
+Now that you've cloned the repository and optionally selected the branch you
+want to work on, your local source tree may later be synced up with the
+development source by using the git command::
+
+  % git pull
+
+The git system remembers the repository that it was cloned from, so you don't
+need to re-enter it when you pull.
+
+To build the `configure` script and hash files you need to run the
+following::
+
+  % sh autoconf.sh
+  % cd ..
+
+This is not need for the released `tar/zip` files since they already contain
+these files. You only need to run this once after cloning. If you are missing
+``autoconf`` or ``gperf`` then the script will fail::
+
+  Autoconf in root...
+  autoconf.sh: 10: autoconf: not found
+  Precompiling lexor_keyword.gperf
+  autoconf.sh: 13: gperf: not found.
+
+You will need to install the ``autoconf`` and ``gperf`` tools before you can
+continue.
+
+The other way to get the source code is to download a released `tar/zip` file::
+
+  % tar -xvzf v13_0.tar.gz
+  or
+  % unzip v13_0.zip
+
+See the build instructions for your operation system below to know what to do
+next. Though first determine if there are any extra configuration option you
+may need.
+
+Icarus Specific Configuration Options
+-------------------------------------
+
+Icarus takes many of the standard configuration options and those will not be
+described here. The following are specific to Icarus::
+
+  --enable-suffix[=suffix]
+
+This option allows the user to build Icarus with a default suffix or when
+provided a user defined suffix. Older stable releases have this flag on by
+default e.g.(V0.8 by default will build with a "-0.8" suffix). All versions
+have an appropriate default suffix ("-<base_version>").
+
+All programs or directories are tagged with this suffix. e.g.(iverilog-0.8,
+vvp-0.8, etc.). The output of iverilog will reference the correct run time
+files and directories. The run time will check that it is running a file with
+a compatible version e.g.(you can not run a V0.9 file with the V0.8 run
+time).::
+
+  --with-valgrind
+
+This option adds extra memory cleanup code and pool management code to allow
+better memory leak checking when valgrind is available. This option is not
+needed when checking for basic errors with valgrind and should not be used if
+you just intend to use ``iverilog`` as a simulator. ::
+
+  --enable-libvvp
+
+The vvp program is built as a small stub linked to a shared library,
+libvvp.so, that may be linked with other programs so that they can host
+a vvp simulation. ::
+
+  --enable-libveriuser
+
+PLI version 1 (the ACC and TF routines) were deprecated in IEEE 1364-2005.
+These are supported in Icarus Verilog by the libveriuser library and cadpli
+module. Starting with V13, these will only be built if this option is used.
+
+Compiling on Linux/Unix
+-----------------------
+
+Note: For a gcc compile you will need to install ``bison``, ``flex``, ``g++``,
+``gcc`` and preferably `bz2`, `zlib` and `readline` development packages. The
+`bz2` and `zlib` development packages are required for the non-VCD waveform
+dumpers and the `readline` development package is needed to enable better
+terminal control in the ``vvp`` interactive mode.
+
+If you are only compiling one variant then you can compile directly in the
+source tree. If you need multiple variants (optimized, debugging, multiple
+compilers) then it is recommended you compile each in their own directory.
+
+For multiple variants create a directory for each of the variants you intend
+to create and in each run the following steps, adjusting the options in the
+configure stage to get the functionality you want. For a single build you can
+either build it with the source or in a separate build directory.
+
+The following is from a Ubuntu 22.04 machine using gcc (version 11.4)::
+
+  % mkdir gcc
+  % cd gcc
+  or
+  % cd iverilog
+
+You can also use ``clang/clang++``. I usual build optimized version for
+normal use and reserve debugging options for a valgrind or a separate
+debugging build. Make sure you have `sudo` permission if you are using a
+system prefix area, otherwise you need to use some place you have
+permission to install (e.g. ~/).::
+
+  % env CFLAGS=-O2 CXXFLAGS=-O2 LDFLAGS=-s CC=gcc CXX=g++ ../iverilog/configure --enable-suffix=-gcc --prefix=/usr/local
+
+This will generate the following (with some inline comments)::
+
+  checking build system type... x86_64-pc-linux-gnu
+  checking host system type... x86_64-pc-linux-gnu
+  checking for gcc... gcc
+  checking whether the C compiler works... yes
+  ...
+  checking for gperf... gperf       # required for git builds
+  checking for man... man           # you likely want manual pages
+  checking for ps2pdf... ps2pdf
+  checking for groff... groff
+  checking for git... git           # required for git builds
+  checking for flex... flex         # required
+  checking for bison... bison       # required
+  ...
+  checking for tputs in -ltermcap... yes
+  checking for readline in -lreadline... yes
+  checking for add_history in -lreadline... yes
+  checking for readline/readline.h... yes
+  checking for readline/history.h... yes           # you likely want this
+  ...
+  checking for pthread_create in -lpthread... yes
+  checking for gzwrite in -lz... yes
+  checking for gzwrite in -lz... (cached) yes
+  checking for BZ2_bzdopen in -lbz2... yes
+  checking for BZ2_bzdopen in -lbz2... (cached) yes     # you want these for fst dumping
+  ...
+  <Create all the parameterized Makefile and header files>
+
+Usually if ``configure`` fails there is some required dependency missing. I
+usually review all the output to make sure it makes sense (e.g. I requested
+``gcc`` and that's what is being used, other things match my expectation). If
+all the waveform dumpers are not enabled there could be a few test failures.
+
+Next we need to compile the code. Note: make sure you are using GNU make.
+It may be named gmake (e.g. GhostBSD)::
+
+  % make check >& make.log
+
+This is for a tcsh/csh shell. Bash/fish/zsh use ``&>`` instead of ``>&``.
+Once this has completed check the make.log for any errors. There should not
+be any! I also check for warnings. There are often some related to the
+output from bison. For example::
+
+  From: ./parse.cc
+  parse.cc:9462:18: warning: missing initializer for member ‘vlltype::lexical_pos’ [-Wmissing-field-initializers]
+   9462 |   = { 1, 1, 1, 1 }
+        |                  ^
+  parse.cc:9462:18: warning: missing initializer for member ‘vlltype::text’ [-Wmissing-field-initializers]
+
+and::
+
+  From: ./vvp/parse.cc
+  parse.cc:3242: warning: suspicious sequence in the output: m4_type [-Wother]
+  parse.cc:3248: warning: suspicious sequence in the output: m4_type [-Wother]
+
+Are common, but benign warnings. Different compilers or compiler versions may
+have other warnings.
+
+The expected last few lines of the make.log file and these indicate everything
+should be working as expected are::
+
+  ...
+  driver/iverilog -B. -BMvpi -BPivlpp -tcheck -ocheck.vvp ../iverilog/examples/hello.vl
+  vvp/vvp -M- -M./vpi ./check.vvp | grep 'Hello, World'
+  Hello, World
+
+If everything is good to this point and you are installing into a system
+prefix; install using ``sudo`` as shown below. If you are installing into a
+personal location skip the ``sudo``::
+
+  % sudo make install
+
+Now you should verify the regression test suite is working as expected::
+
+  % cd ../iverilog/ivtest
+  % ./vvp_reg.pl --suffix=-gcc
+
+This is the original test script and should give no failures::
+
+  Running compiler/VVP tests for Icarus Verilog version: 13, suffix: -gcc.
+  ----------------------------------------------------------------------------
+              macro_with_args: Passed.
+                         mcl1: Passed.
+                        pr622: Passed.
+                        pr639: Passed.
+                           ...
+                     ssetclr2: Passed.
+                     ssetclr3: Passed.
+             synth_if_no_else: Passed.
+                  ufuncsynth1: Passed.
+  ============================================================================
+  Test results:
+    Total=3018, Passed=3013, Failed=0, Not Implemented=2, Expected Fail=3
+
+Next run the new test script::
+
+  % ./vvp_reg.py --suffix=-gcc
+
+This should also give no failures::
+
+  Running compiler/VVP tests for Icarus Verilog version: 13, suffix: -gcc
+  Using list(s): regress-vvp.list
+  ----------------------------------------------------------------------------
+                      always4A: Passed - CE.
+                      always4B: Passed - CE.
+                       analog1: Not Implemented.
+                       analog2: Not Implemented.
+                            ...
+                vvp_quiet_mode: Passed.
+               warn_opt_sys_tf: Passed - EF.
+                         wreal: Passed.
+              writemem-invalid: Passed - EF.
+  ============================================================================
+  Test results: Ran 284, Failed 0.
+
+Finally you can check that the VPI is working properly using::
+
+  % ./vpi_reg.pl --suffix=-gcc
+
+The output for this should have no failures::
+
+  Running VPI tests for Icarus Verilog version: 13, suffix: -gcc.
+  ----------------------------------------------------------------------------
+            br_gh59: Passed.
+           br_gh73a: Passed.
+           br_gh73b: Passed.
+           br_gh117: Passed.
+                 ...
+   value_change_cb2: Passed.
+   value_change_cb3: Passed.
+   value_change_cb4: Passed.
+        vpi_control: Passed.
+  ============================================================================
+  Test results: Total=77, Passed=77, Failed=0, Not Implemented=0
+
+You can uninstall everything using the following. If needed skip the ``sudo``
+as described in the install description above.::
+
+  % sudo make uninstall
+
+You can cleanup the compile directory using::
+
+  % make clean
+  or
+  % make distclean
+
+The first just cleans up just the compiled files, etc. The later cleans up
+the compiled file along with all the files generated in the ``configure``
+phase.
+
+Note that "rpm" packages of binaries for Linux are typically configured with
+"--prefix=/usr" per the Linux File System Standard.
+
+Make sure you have a recent version of flex otherwise you will get an error
+when parsing lexor.lex.
+
+Compiling on Macintosh OS X
+---------------------------
+
+Since Mac OS X is a BSD flavor of Unix, you can install Icarus Verilog from
+source using the procedure described above. You need to install the Xcode
+software, which includes the C and C++ compilers for Mac OS X. The package is
+available for free download from Apple's developer site. Once Xcode is
+installed, you can build Icarus Verilog in a terminal window just like any
+other Unix install.
+
+For versions newer than 10.3 the GNU Bison tool (packaged with Xcode) needs to
+be updated to version 3. ::
+
+  brew install bison
+  echo 'export PATH="/usr/local/opt/bison/bin:$PATH"' >> ~/.bash_profile
+
+Icarus Verilog is also available through the Homebrew package manager: "brew
+install icarus-verilog".
+
+Cross-Compiling for Windows
+---------------------------
+
+The `Cygwin` and `MSYS2` environments can compile Icarus Verilog as described
+above for `Linux/Unix`. There is a `MSYS2` build recipe which can be found in
+the `msys2/` directory. The accompanying README file provides further details.
+`MSYS2` is typically preferred over `Cygwin` since ``GTKWave`` and Icarus
+Verilog are both provided as pre-compiled packages.
+
+What follows are older instructions for building Icarus Verilog binaries for
+Windows using mingw cross compiler tools on Linux.
+
+To start with, you need the mingw64-cross-* packages for your linux
+distribution, which gives you the x86_64-w64-mingw32-* commands
+installed on your system. Installing the cross environment is outside
+the scope of this writeup.
+
+First, configure with this command::
+
+  $ ./configure --host=x86_64-w64-mingw32
+
+This generates the Makefiles needed to cross compile everything with
+the mingw32 compiler. The configure script will generate the command
+name paths, so long as commands line x86_64-w64-mingw32-gcc
+et. al. are in your path.
+
+Next, compile with the command::
+
+  $ make
+
+The configure generated the cross compiler flags. The
+configure script should have gotten all that right.
@@ -0,0 +1,146 @@
+
+IVLPP - IVL Preprocessor
+========================
+
+The ivlpp command is a Verilog preprocessor that handles file
+inclusion and macro substitution. The program runs separate from the
+actual compiler so as to ease the task of the compiler proper, and
+provides a means of preprocessing files off-line.
+
+
+USAGE:
+
+	ivlpp [options] <file>
+
+The <file> parameter is the name of the file to be read and
+preprocessed. The resulting output is sent to standard output. The
+valid options include:
+
+* -Dname[=value]
+
+	    Predefine the symbol `name` to have the specified
+	    value. If the value is not specified, then `1` is
+	    used. This is mostly of use for controlling conditional
+	    compilation.
+
+	    This option does *not* override existing \`define
+	    directives in the source file.
+
+* -F <path>
+
+	    Read ivlpp options from a FLAGS FILE. This is not the same
+	    as a file list. This file contains flags, not source
+	    files. There may be multiple flags files.
+
+* -f <path>
+
+	    Read ivlpp input files from a file list. There can be no
+	    more than one file list.
+
+* -I <dir>
+
+	    Add a directory to the include path. Normally, only "." is
+	    in the search path. The -I flag causes other directories
+	    to be searched for a named file. There may be as many -I
+	    flags as needed.
+
+* -L
+
+	    Generate \`line directives. The ivl compiler understands
+	    these directives and uses them to keep track of the
+	    current line of the original source file. This makes error
+	    messages more meaningful.
+
+* -o <file>
+
+	    Send the output to the named file, instead of to standard
+	    output.
+
+* -v
+
+	    Print version and copyright information before processing
+	    input files.
+
+* -V
+
+	    Print version and copyright information, then exit WITHOUT
+	    processing any input files.
+
+Flags File
+----------
+
+A flags file contains flags for use by ivlpp. This is a convenient way
+for programs to pass complex sets of flags to the ivlpp program.
+
+Blank lines and lines that start with "#" are ignored. The latter can
+be used as comment lines. All other lines are flag lines. Leading and
+trailing white space are removed before the lines are interpreted.
+
+Other lines have the simple format::
+
+  <key>:<value>
+
+The colon character separates a key from the value. The supported
+keys, with their corresponding values, are:
+
+* D:name=<value>
+
+      This is exactly the same as the "-Dname=<value>" described above.
+
+* I:<dir>
+
+      This is exactly the same as "-I<dir>".
+
+* relative include:<flag>
+
+      The <flag> can be "true" or "false". This enables "relative
+      includes" nesting behavior.
+
+* vhdlpp:<path>
+
+      Give the path to the vhdlpp program. This program is used to
+      process VHDL input files.
+
+Locating Included Files
+-----------------------
+
+The ivlpp preprocessor implements the \`include directives by
+substituting the contents of the included file in place of the line
+with the \`include directive. The name that the programmer specifies is
+a file name. Normally, the preprocessor looks in the current working
+directory for the named file. However, the `-I` flags can be used to
+specify a path of directories to search for named include files. The
+current directory will be searched first, followed by all the include
+directories in the order that the -I flag appears.
+
+The exception to this process is include files that have a name that
+starts with the '/' character. These file names are `rooted names`
+and must be in the rooted location specified.
+
+
+Generated Line Directives
+-------------------------
+
+Compilers generally try to print along with their error messages the
+file and line number where the error occurred. Icarus Verilog is no
+exception. However, if a separate preprocessor is actually selecting
+and opening files, then the line numbers counted by the compiler
+proper will not reflect the actual line numbers in the source file.
+
+To handle this situation, the preprocessor can generate line
+directives. These directives are lines of the form::
+
+	`line <num> <name> <level>
+
+where <name> is the file name in double-quotes and <num> is the line
+number in the file. The parser changes the filename and line number
+counters in such a way that the next line is line number <num> in
+the file named <name>. For example::
+
+	`line 6 "foo.vl" 0
+	// I am on line 6 in file foo.vl.
+
+The preprocessor generates a \`line directive every time it switches
+files. That includes starting an included file (\`line 1 "foo.vlh" 1) or
+returning to the including file.
+
@@ -0,0 +1,76 @@
+
+Reporting Issues
+================
+
+The developers of and contributors to Icarus Verilog use github to track
+issues and to create patches for the product. If you believe you have found a
+problem, use the Issues tracker at the
+`Icarus Verilog github page <https://github.com/steveicarus/iverilog>`__.
+
+You may browse the bugs database for existing
+bugs that may be related to yours. You might find that your bug has
+already been fixed in a later release or snapshot. If that's the case,
+then you are set.
+
+On the main page, you will find a row of selections near the top. Click the
+`Issues <https://github.com/steveicarus/iverilog/issues>`__ link to get to the
+list of issues, open and closed. You will find a friendly green button where
+you can create a new issue. You will be asked to create a title for your
+issue, and to write a detailed description of your issue. Please include
+enough information that anyone who sees your issue can understand and
+reproduce it.
+
+Good Issue Reporting
+--------------------
+
+Before an error can be fixed, one needs to understand what the problem
+is. Try to explain what is wrong and why you think it is wrong. Please
+try to include sample code that demonstrates the problem.
+
+One key characteristic of a well reported issue is a small sample program that
+demonstrates the issue. The smaller the better. No developer wants to wade
+through hundreds of lines of working Verilog to find the few lines that cause
+trouble, so if you can get it down to a 10 line sample program, then your
+issue will be far more likely to be addressed.
+
+Also, include the command line you use to invoke the compiler. For
+example::
+
+	iverilog -o foo.out -tvvp foo.v
+	iverilog foo.vl -s starthere
+
+Be prepared to have a conversation about your issue. More often then you would
+expect, the issue turns out to be a bug in your program, and the person
+looking into your issue may point out a bug in your code. You learn something,
+and we all win. We are not always correct, though, so if we are incorrect,
+help us see our error, if that's appropriate. If we don't understand what your
+issue is, we will label your issue with a "Need info" label, and if we never
+hear from you again, your issue may be closed summarily.
+
+If you can submit a complete, working program that we can use in the
+regression test suite, then that is the best. Check out the existing tests in
+the regression test suite to see how they are structured. If you have a
+complete test that can go into the test suite, then that saves everyone a lot
+of grief, and again you increase the odds that your issue will be addressed.
+
+How To Create A Pull Request
+----------------------------
+
+Bug reports with patches/PRs are very welcome. Please also add a new test case in the regression test suite to prevent the bug from reappearing.
+
+If you are editing the source, you should be using the latest
+version from git. Please see the developer documentation for more
+detailed instructions -- :doc:`Getting Started as a Contributor <getting_started>` .
+
+COPYRIGHT ISSUES
+
+Icarus Verilog is Copyright (c) 1998-2024 Stephen Williams except
+where otherwise noted. Minor patches are covered as derivative works
+(or editorial comment or whatever the appropriate legal term is) and
+folded into the rest of ivl. However, if a submission can reasonably
+be considered independently copyrightable, it's yours and I encourage
+you to claim it with appropriate copyright notices. This submission
+then falls under the "otherwise noted" category.
+
+I must insist that any copyright material submitted for inclusion
+include the GPL license notice as shown in the rest of the source.
@@ -0,0 +1,495 @@
+
+Simulation Using Icarus Verilog
+===============================
+
+Simulation is the process of creating models that mimic the behavior of the
+device you are designing (simulation models) and creating models to exercise
+the device (test benches). The simulation model need not reflect any
+understanding of the underlying technology, and the simulator need not know
+that the design is intended for any specific technology.
+
+The Verilog simulator, in fact, is usually a different program than the
+synthesizer. It may even come from a different vendor. The simulator need not
+know of or generate netlists for the target technology, so it is possible to
+write one simulator that can be used to model designs intended for a wide
+variety of technologies. A synthesizer, on the other hand, does need to know a
+great deal about the target technology in order to generate efficient
+netlists. Synthesizers are often technology specific and come from vendors
+with specialized knowledge, whereas simulators are more general purpose.
+
+Simulation models and test benches, therefore, can use the full range of
+Verilog features to model the intended design as clearly as possible. This is
+the time to test the algorithms of the design using language that is
+relatively easy for humans to read. The simulator, along with the test bench,
+can test that the clearly written model really does behave as intended, and
+that the intended behavior really does meet expectations.
+
+The test benches model the world outside the design, so they are rarely
+destined for real hardware. They are written in Verilog simply as a matter of
+convenience, and sometimes they are not written in Verilog at all. The test
+benches are not throw-away code either, as they are used to retest the device
+under test as it is transformed from a simulation model to a synthesizeable
+description.
+
+Compilation and Elaboration
+---------------------------
+
+Simulation of a design amounts to compiling and executing a program. The
+Verilog source that represents the simulation model and the test bench is
+compiled into an executable form and executed by a simulation
+engine. Internally, Icarus Verilog divides the compilation of program source
+to an executable form into several steps, and basic understanding of these
+steps helps understand the nature of failures and errors. The first step is
+macro preprocessing, then compilation, elaboration, optional optimizations and
+finally code generation. The boundary between these steps is often blurred,
+but this progression remains a useful model of the compilation process.
+
+The macro preprocessing step performs textual substitutions of macros defined
+with "\`define" statements, textual inclusion with "\`include" statements, and
+conditional compilation by "\`ifdef" and "\`ifndef" statements. The
+macropreprocessor for Icarus Verilog is internally a separate program that can
+be accessed independently by using the "-E" flag to the "iverilog" command,
+like so::
+
+  % iverilog -E -o out.v example.v
+
+This command causes the input Verilog file "example.v" to be preprocessed, and
+the output, a Verilog file without preprocessor statements, written into
+"out.v". The "\`include" and "\`ifdef" directives in the input file are interpreted,
+and defined macros substituted, so that the output, a single file, is the same
+Verilog but with the preprocessor directives gone. All the explicitly
+specified source files are also combined by the preprocessor, so that the
+preprocessed result is a single Verilog stream.
+
+Normally, however, the "-E" flag is not used and the preprocessed Verilog is
+instead sent directly to the next step, the compiler. The compiler core takes
+as input preprocessed Verilog and generates an internal parsed form. The
+parsed form is an internal representation of the Verilog source, in a format
+convenient for further processing, and is not accessible to the user.
+
+The next step, elaboration, takes the parsed form, chooses the root modules,
+and instantiates (makes *instances* of) those roots. The root instances may
+contain instances of other modules, which may in turn contain instances of yet
+other modules. The elaboration process creates a hierarchy of module instances
+that ends with primitive gates and statements.
+
+Note that there is a difference between a module and a module instance. A
+module is a type. It is a description of the contents of module instances that
+have its type. When a module is instantiated within another module, the module
+name identifies the type of the instance, and the instance name identifies the
+specific instance of the module. There can be many instances of any given
+module.
+
+Root modules are a special case, in that the programmer does not give them
+instance names. Instead, the instance names of root modules are the same as
+the name of the module. This is valid because, due to the nature of the
+Verilog syntax, a module can be a root module only once, so the module name
+itself is a safe instance name.
+
+Elaboration creates a hierarchy of scopes. Each module instance creates a new
+scope within its parent module, with each root module starting a
+hierarchy. Every module instance in the elaborated program has a unique scope
+path, a hierarchical name, that starts with its root scope and ends with its
+own instance name. Every named object, including variables, parameters, nets
+and gates, also has a hierarchical name that starts with a root scope and ends
+with its own base name. The compiler uses hierarchical names in error messages
+generated during or after elaboration, so that erroneous items can be
+completely identified. These hierarchical names are also used by waveform
+viewers that display waveform output from simulations.
+
+The elaboration process creates from the parsed form the scope hierarchy
+including the primitive objects within each scope. The elaborated design then
+is optimized to reduce it to a more optimal, but equivalent design. The
+optimization step takes the fully elaborated design and transforms it to an
+equivalent design that is smaller or more efficient. These optimizations are,
+for example, forms of constant propagation and dead code elimination. Useless
+logic is eliminated, and constant expressions are pre-calculated. The
+resulting design behaves as if the optimizations were not performed, but is
+smaller and more efficient. The elimination (and spontaneous creation) of
+gates and statements only affects the programmer when writing VPI modules,
+which through the API have limited access to the structures of the design.
+
+Finally, the optimized design, which is still in an internal form not
+accessible to users, is passed to a code generator that writes the design into
+an executable form. For simulation, the code generator is selected to generate
+the vvp format--a text format that can be executed by the simulation
+engine. Other code generators may be selected by the Icarus Verilog user, even
+third party code generators, but the vvp code generator is the default for
+simulation purposes.
+
+Making and Using Libraries
+--------------------------
+
+Although simple programs may be written into a single source file, this gets
+inconvenient as the designs get larger. Also, writing the entire program into
+a single file makes it difficult for different programs to share common
+code. It therefore makes sense to divide large programs into several source
+files, and to put generally useful source code files somewhere accessible to
+multiple designs.
+
+Once the program is divided into many files, the compiler needs to be told how
+to find the files of the program. The simplest way to do that is to list the
+source files on the command line or in a command file. This is for example the
+best way to divide up and integrate test bench code with the simulation model
+of the device under test.
+
+The Macro Preprocessor
+^^^^^^^^^^^^^^^^^^^^^^
+
+Another technique is to use the macro preprocessor to include library files
+into a main file. The `include` directive takes the name of a source file to
+include. The preprocessor inserts the entire contents of the included file in
+place of the `include` directive. The preprocessor normally looks in the
+current working directory (the current working directory of the running
+compiler, and not the directory where the source file is located) for the
+included file, but the "-I" switch to "iverilog" can add directories to the
+search locations list. ::
+
+  % iverilog -I/directory/to/search example.v
+
+It is common to create include directories shared by a set of programs. The
+preprocessor `include` directive can be used by the individual programs to
+include the source files that it needs.
+
+The preprocessor method of placing source code into libraries is general
+(arbitrary source code can be placed in the included files) but is static, in
+the sense that the programmer must explicitly include the desired library
+files. The automatic module library is a bit more constrained, but is
+automatic.
+
+Automatic Module Libraries
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A common use for libraries is to store module definitions that may be of use
+to a variety of programs. If modules are divided into a single module per
+file, and the files are named appropriately, and the compiler is told where to
+look, then the compiler can automatically locate library files when it finds
+that a module definition is missing.
+
+For this to work properly, the library files must be Verilog source, they
+should contain a single module definition, and the files must be named after
+the module they contain. For example, if the module "AND2" is a module in the
+library, then it belongs in a file called "AND2.v" and that file contains only
+the "AND2" module. A library, then, is a directory that contains properly
+named and formatted source files. ::
+
+  % iverilog -y/library/to/search example.v
+
+The "-y" flag to "iverilog" tells the compiler to look in the specified
+directory for library modules whenever the program instantiates a module that
+is not otherwise defined. The programmer may include several "-y" flags on the
+command line (or in a command file) and the compiler will search each
+directory in order until an appropriate library file is found to resolve the
+module.
+
+Once a module is defined, either in the program or by reading a library
+module, the loaded definition is used from then on within the program. If the
+module is defined within a program file or within an included file, then the
+included definition is used instead of any library definition. If a module is
+defined in multiple libraries, then the first definition that the compiler
+finds is used, and later definitions are never read.
+
+Icarus Verilog accesses automatic libraries during elaboration, after it has
+already preprocessed and parsed the non-library source files. Modules in
+libraries are not candidates for root modules, and are not even parsed unless
+they are instantiated in other source files. However, a library module may
+reference other library modules, and reading in a library module causes it to
+be parsed and elaborated, and further library references resolved, just like a
+non-library module. The library lookup and resolution process iterates until
+all referenced modules are resolved, or known to be missing from the
+libraries.
+
+The automatic module library technique is useful for including vendor or
+technology libraries into a program. Many EDA vendors offer module libraries
+that are formatted appropriately; and with this technique, Icarus Verilog can
+use them for simulation.
+
+Advanced Command Files
+----------------------
+
+Command files were mentioned in the "Getting Started" chapter, but only
+briefly. In practice, Verilog programs quickly grow far beyond the usefulness
+of simple command line options, and even the macro preprocessor lacks the
+flexibility to combine source and library modules according to the advancing
+development process.
+
+The main contents of a command file is a list of Verilog source files. You can
+name in a command file all the source files that make up your design. This is
+a convenient way to collect together all the files that make up your
+design. Compiling the design can then be reduced to a simple command line like
+the following::
+
+  % iverilog -c example.cf
+
+The command file describes a configuration. That is, it lists the specific
+files that make up your design. It is reasonable, during the course of
+development, to have a set of different but similar variations of your
+design. These variations may have different source files but also many common
+source files. A command file can be written for each variation, and each
+command file lists the source file names used by each variation.
+
+A configuration may also specify the use of libraries. For example, different
+configurations may be implementations for different technologies so may use
+different parts libraries. To make this work, command files may include "-y"
+statements. These work in command files exactly how they work on "iverilog"
+command line. Each "-y" flag is followed by a directory name, and the
+directories are searched for library modules in the order that they are listed
+in the command file.
+
+The include search path can also be specified in configuration files with
+"+incdir+" tokens. These tokens start with the "+incdir+" string, then
+continue with directory paths, separated from each other with "+" characters
+(not spaces) for the length of the line.
+
+Other information can be included in the command file. See the section Command
+File Format for complete details on what can go in a command file.
+
+Input Data at Runtime
+---------------------
+
+Often, it is useful to compile a program into an executable simulation, then
+run the simulation with various inputs. This requires some means to pass data
+and arguments to the compiled program each time it is executed. For example,
+if the design models a micro-controller, one would like to run the compiled
+simulation against a variety of different ROM images.
+
+There are a variety of ways for a Verilog program to get data from the outside
+world into the program at run time. Arguments can be entered on the command
+line, and larger amounts of data can be read from files. The simplest method
+is to take arguments from the command line.
+
+Consider this running example of a square root calculator
+
+.. code-block:: verilog
+
+  module sqrt32(clk, rdy, reset, x, .y(acc));
+    input  clk;
+    output rdy;
+    input  reset;
+
+    input [31:0] x;
+    output [15:0] acc;
+
+    // acc holds the accumulated result, and acc2 is
+    //  the accumulated square of the accumulated result.
+    reg [15:0] acc;
+    reg [31:0] acc2;
+
+    // Keep track of which bit I'm working on.
+    reg [4:0]  bitl;
+    wire [15:0] bit = 1 << bitl;
+    wire [31:0] bit2 = 1 << (bitl << 1);
+
+    // The output is ready when the bitl counter underflows.
+    wire rdy = bitl[4];
+
+    // guess holds the potential next values for acc,
+    // and guess2 holds the square of that guess.
+    wire [15:0] guess  = acc | bit;
+    wire [31:0] guess2 = acc2 + bit2 + ((acc << bitl) << 1);
+
+    task clear;
+       begin
+          acc = 0;
+          acc2 = 0;
+          bitl = 15;
+       end
+    endtask
+
+    initial clear;
+
+    always @(reset or posedge clk)
+       if (reset)
+        clear;
+       else begin
+          if (guess2 <= x) begin
+             acc  <= guess;
+             acc2 <= guess2;
+          end
+          bitl <= bitl - 1;
+       end
+
+  endmodule
+
+One could write the test bench as a program that passes a representative set
+of input values into the device and checks the output result. However, we can
+also write a program that takes on the command line an integer value to be
+used as input to the device. We can write and compile this program, then pass
+different input values on the run time command line without recompiling the
+simulation.
+
+This example demonstrates the use of the "$value$plusargs" to access command
+line arguments of a simulation
+
+.. code-block:: verilog
+
+  module main;
+
+    reg clk, reset;
+    reg [31:0] x;
+    wire [15:0] y;
+    wire        rdy;
+
+    sqrt32 dut (clk, rdy, reset, x, y);
+
+    always #10 clk = ~clk;
+
+    initial begin
+       clk = 0;
+       reset = 1;
+
+       if (! $value$plusargs("x=%d", x)) begin
+          $display("ERROR: please specify +x=<value> to start.");
+          $finish;
+       end
+
+       #35 reset = 0;
+
+       wait (rdy) $display("y=%d", y);
+       $finish;
+    end // initial begin
+
+  endmodule // main
+
+The "$value$plusargs" system function takes a string pattern that describes
+the format of the command line argument, and a reference to a variable that
+receives the value. The "sqrt_plusargs" program can be compiled and executed
+like this::
+
+  % iverilog -osqrt_plusargs.vvp sqrt_plusargs.v sqrt.v
+  % vvp sqrt_plusargs.vvp +x=81
+  y=    9
+
+Notice that the "x=%d" string of the "$value$plusargs" function describes the
+format of the argument. The "%d" matches a decimal value, which in the sample
+run is "81". This gets assigned to "x" by the "$value$plusargs" function,
+which returns TRUE, and the simulation continues from there.
+
+If two arguments have to be passed to the testbench then the main module would
+be modified as follows
+
+.. code-block:: verilog
+
+  module main;
+
+    reg clk, reset;
+    reg  [31:0] x;
+    reg  [31:0] z;
+    wire [15:0] y1,y2;
+    wire        rdy1,rdy2;
+
+    sqrt32 dut1 (clk, rdy1, reset, x, y1);
+    sqrt32 dut2 (clk, rdy2, reset, z, y2);
+
+    always #10 clk = ~clk;
+
+    initial begin
+       clk = 0;
+       reset = 1;
+
+       if (! $value$plusargs("x=%d", x)) begin
+          $display("ERROR: please specify +x=<value> to start.");
+          $finish;
+       end
+
+       if (! $value$plusargs("z=%d", z)) begin
+          $display("ERROR: please specify +z=<value> to start.");
+          $finish;
+       end
+
+
+       #35 reset = 0;
+
+       wait (rdy1) $display("y1=%d", y1);
+       wait (rdy2) $display("y2=%d", y2);
+       $finish;
+    end // initial begin
+
+  endmodule // main
+
+and the "sqrt_plusargs" program would be compiled and executed as follows::
+
+  % iverilog -osqrt_plusargs.vvp sqrt_plusargs.v sqrt.v
+  % vvp sqrt_plusargs.vvp +x=81 +z=64
+  y1=    9
+  y2=    8
+
+In general, the "vvp" command that executes the compiled simulation takes a
+few predefined argument flags, then the file name of the simulation. All the
+arguments after the simulation file name are extended arguments to "vvp" and
+are passed to the executed design. Extended arguments that start with a "+"
+character are accessible through the "$test$plusargs" and "$value$plusargs"
+system functions. Extended arguments that do not start with a "+" character
+are only accessible to system tasks and functions written in C using the VPI.
+
+In the previous example, the program pulls the argument from the command line,
+assigns it to the variable "x", and runs the sqrt device under test with that
+value. This program can take the integer square root of any single value. Of
+course, if you wish to test with a large number of input values, executing the
+program many times may become tedious.
+
+Another technique would be to put a set of input values into a data file, and
+write the test bench to read the file. We can then edit the file to add new
+input values, then rerun the simulation without compiling it again. The
+advantage of this technique is that we can accumulate a large set of test
+input values, and run the lot as a batch.
+
+This example
+
+.. code-block:: verilog
+
+  module main;
+
+    reg clk, reset;
+    reg [31:0] data[4:0];
+    reg [31:0] x;
+    wire [15:0] y;
+    wire        rdy;
+
+    sqrt32 dut (clk, rdy, reset, x, y);
+
+    always #10 clk = ~clk;
+
+    integer i;
+    initial begin
+       /* Load the data set from the hex file. */
+       $readmemh("sqrt.hex", data);
+       for (i = 0 ;  i <= 4 ;  i = i + 1) begin
+         clk = 0;
+         reset = 1;
+
+         x = data[i];
+
+         #35 reset = 0;
+
+         wait (rdy) $display("y=%d", y);
+       end
+       $finish;
+    end // initial begin
+
+  endmodule // main
+
+demonstrates the use of "$readmemh" to read data samples from a file into a
+Verilog array. Start by putting into the file "sqrt.hex" the numbers::
+
+  51
+  19
+  1a
+  18
+  1
+
+Then run the simulation with the command sequence::
+
+  % iverilog -osqrt_readmem.vvp sqrt_readmem.vl sqrt.vl
+  % vvp sqrt_readmem.vvp
+  y=    9
+  y=    5
+  y=    5
+  y=    4
+  y=    1
+
+It is easy enough to change this program to work with larger data sets, or to
+change the "data.hex" file to contain different data. This technique is also
+common for simulating algorithms that take in larger data sets. One can extend
+this idea slightly by using a "$value$plusargs" statement to select the file
+to read.
@@ -0,0 +1,35 @@
+
+Verilog Attributes
+==================
+
+This is a description of the various attributes that the Icarus Verilog tools
+understand. The attributes are attached to objects using the "(\* ... \*)"
+syntax, which is described by the Verilog LRM.
+
+Attributes that start with "ivl\_" are Icarus Verilog specific are are probably
+ignored by other tools.
+
+Optimizations
+-------------
+
+* ivl_do_not_elide (snapshot 20140619 or later)
+
+  This applies to signals (i.e. reg, wire, etc.) and tells the optimizer to
+  not elide the signal, even if it is not referenced anywhere in the
+  design. This is useful if the signal is for some reason only accessed by
+  VPI/PLI code.
+
+Synthesis
+---------
+
+* ivl_synthesis_cell
+
+  Applied to a module definition, this tells the synthesizer that the module
+  is a cell. The synthesizer does not descend into synthesis cells, as they
+  are assumed to be primitives in the target technology.
+
+* ivl_synthesis_off
+
+  Attached to an "always" statement, this tells the synthesizer that the
+  statement is not to be synthesized. This may be useful, for example, to tell
+  the compiler that a stretch of code is test-bench code.
@@ -0,0 +1,59 @@
+
+vhdlpp Command Line Flags
+=========================
+
+* -D <token>
+
+  Debug flags. The token can be:
+
+  * yydebug | no-yydebug
+
+  * entities=<path>
+
+* -L <path>
+
+  Library path. Add the directory name to the front of the library
+  search path. The library search path is initially empty.
+
+* -V
+
+  Display version on stdout
+
+* -v
+
+  Verbose: Display version on stderr, and enable verbose messages to
+  stderr.
+
+* -w <path>
+
+  Work path. This is the directory where the working directory is.
+
+
+Library Format
+--------------
+
+The vhdlpp program stores libraries as directory that contain
+packages. The name of the directory (in lower case) is the name of the
+library as used on the "import" statement. Within that library, there
+are packages in files named <foo>.pkg. For example::
+
+    <directory>/...
+       sample/...
+         test1.pkg
+	 test2.pkg
+       bar/...
+         test3.pkg
+
+Use the "+vhdl-libdir+<directory>" record in a config file to tell
+Icarus Verilog that <directory> is a place to look for libraries. Then
+in your VHDL code, access packages like this::
+
+    library sample;
+    library bar;
+    use sample.test1.all;
+    use bar.test3.all;
+
+The \*.pkg files are just VHDL code containing only the package with
+the same name. When Icarus Verilog encounters the "use <lib>.<name>.*;"
+statement, it looks for the <name>.pkg file in the <lib> library and
+parses that file to get the package header declared therein.
@@ -0,0 +1,248 @@
+
+Using VPI
+=========
+
+Icarus Verilog implements a portion of the PLI 2.0 API to Verilog. This allows
+programmers to write C code that interfaces with Verilog simulations to
+perform tasks otherwise impractical with straight Verilog. Many Verilog
+designers, especially those who only use Verilog as a synthesis tool, can
+safely ignore the entire matter of the PLI (and this chapter) but the designer
+who wishes to interface a simulation with the outside world cannot escape VPI.
+
+The rest of this article assumes some knowledge of C programming, Verilog PLI,
+and of the compiler on your system. In most cases, Icarus Verilog assumes the
+GNU Compilation System is the compiler you are using, so tips and instructions
+that follow reflect that. If you are not a C programmer, or are not planning
+any VPI modules, you can skip this entire article. There are references at the
+bottom for information about more general topics.
+
+How It Works
+------------
+
+The VPI modules are compiled loadable object code that the runtime loads at
+the user's request. The user commands vvp to locate and load modules with the
+"-m" switch. For example, to load the "sample.vpi" module::
+
+  % vvp -msample foo.vvp
+
+The vvp run-time loads the modules first, before executing any of the
+simulation, or even before compiling the vvp code. Part of the loading
+includes invoking initialization routines. These routines register with the
+run-time all the system tasks and functions that the module implements. Once
+this is done, the run time loader can match names of the called system tasks
+of the design with the implementations in the VPI modules.
+
+(There is a special module, the system.vpi module, that is always loaded to
+provide the core system tasks.)
+
+The simulator run time (The "vvp" program) gets a handle on a freshly loaded
+module by looking for the symbol "vlog_startup_routines" in the loaded
+module. This table, provided by the module author and compiled into the
+module, is a null terminated table of function pointers. The simulator calls
+each of the functions in the table in order. The following simple C definition
+defines a sample table::
+
+  void (*vlog_startup_routines[])(void) = {
+     hello_register,
+     0
+  };
+
+Note that the "vlog_startup_routines" table is an array of function pointers,
+with the last pointer a 0 to mark the end. The programmer can organize the
+module to include many startup functions in this table, if desired.
+
+The job of the startup functions that are collected in the startup table is to
+declare the system tasks and functions that the module provides. A module may
+implement as many tasks/functions as desired, so a module can legitimately be
+called a library of system tasks and functions.
+
+Compiling VPI Modules
+---------------------
+
+To compile and link a VPI module for use with Icarus Verilog, you must compile
+all the source files of a module as if you were compiling for a DLL or shared
+object. With gcc under Linux, this means compiling with the "-fpic" flag. The
+module is then linked together with the vpi library like so::
+
+  % gcc -c -fpic hello.c
+  % gcc -shared -o hello.vpi hello.o -lvpi
+
+This assumes that the "vpi_user.h header file and the libvpi.a library file
+are installed on your system so that gcc may find them. This is normally the
+case under Linux and UNIX systems. An easier, the preferred method that works
+on all supported systems is to use the single command::
+
+  % iverilog-vpi hello.c
+
+The "iverilog-vpi" command takes as command arguments the source files for
+your VPI module, compiles them with proper compiler flags, and links them into
+a vpi module with any system specific libraries and linker flags that are
+required. This simple command makes the "hello.vpi" module with minimum fuss.
+
+A Worked Example
+----------------
+
+Let us try a complete, working example. Place the C code that follows into the
+file hello.c::
+
+  # include  <vpi_user.h>
+
+  static int hello_compiletf(char*user_data)
+  {
+        (void)user_data; // Avoid a warning since user_data is not used.
+        return 0;
+  }
+
+  static int hello_calltf(char*user_data)
+  {
+        (void)user_data; // Avoid a warning since user_data is not used.
+        vpi_printf("Hello, World!\n");
+        return 0;
+  }
+
+  void hello_register(void)
+  {
+        s_vpi_systf_data tf_data;
+
+        tf_data.type      = vpiSysTask;
+        tf_data.tfname    = "$hello";
+        tf_data.calltf    = hello_calltf;
+        tf_data.compiletf = hello_compiletf;
+        tf_data.sizetf    = 0;
+        tf_data.user_data = 0;
+        vpi_register_systf(&tf_data);
+  }
+
+  void (*vlog_startup_routines[])(void) = {
+      hello_register,
+      0
+  };
+
+and place the Verilog code that follows into hello.v::
+
+  module main;
+    initial $hello;
+  endmodule
+
+Next, compile and execute the code with these steps::
+
+  % iverilog-vpi hello.c
+  % iverilog -ohello.vvp hello.v
+  % vvp -M. -mhello hello.vvp
+  Hello, World!
+
+The compile and link in this example are conveniently combined into the
+"iverilog-vpi" command. The "iverilog" command then compiles the "hello.v"
+Verilog source file to the "hello.vvp" program. Next, the "vvp" command
+demonstrates the use of the "-M" and "-m" flags to specify a vpi module search
+directory and vpi module name. Specifically, they tell the "vvp" command where
+to find the module we just compiled.
+
+The "vvp" command, when executed as above, loads the "hello.vpi" module that
+it finds in the current working directory. When the module is loaded, the
+vlog_startup_routines table is scanned, and the "hello_register" function is
+executed. The "hello_register" function in turn tells "vvp" about the system
+tasks that are included in this module.
+
+After the modules are all loaded, the "hello.vvp" design file is loaded and
+its call to the "$hello" system task is matched up to the version declared by
+the module. While "vvp" compiles the "hello.vvp" source, any calls to "$hello"
+are referred to the "compiletf" function. This function is called at compile
+time and can be used to check parameters to system tasks or function. It can
+be left empty like this, or left out completely. The "compiletf" function can
+help performance by collecting parameter checks in compile time, so they do
+not need to be done each time the system task is run, thus potentially saving
+execution time overall.
+
+When the run-time executes the call to the hello system task, the
+"hello_calltf" function is invoked in the loaded module, and thus the output
+is generated. The "calltf" function is called at run time when the Verilog
+code actually executes the system task. This is where the active code of the
+task belongs.
+
+System Function Return Types
+----------------------------
+
+Icarus Verilog supports system functions as well as system tasks, but there is
+a complication. Notice how the module that you compile is only loaded by the
+"vvp" program. This is mostly not an issue, but elaboration of expressions
+needs to keep track of types, so the main compiler needs to know the return
+type of functions.
+
+Starting with Icarus Verilog v11, the solution is quite simple. The names and
+locations of the user's VPI modules can be passed to the compiler via the
+"iverilog" -m and -L flags and the IVERILOG_VPI_MODULE_PATH environment
+variable. The compiler will load and analyse the specified modules to
+automatically determine any function return types. The compiler will also
+automatically pass the names and locations of the specified modules to the
+"vvp" program, so that they don't need to be specified again on the "vvp"
+command line.
+
+For Icarus Verilog versions prior to v11, the solution requires that the
+developer of a module include the table in a form that the compiler can
+read. The System Function Table file carries this information. A simple
+example looks like this::
+
+  # Example sft declarations of some common functions
+  $random      vpiSysFuncInt
+  $bitstoreal  vpiSysFuncReal
+  $realtobits  vpiSysFuncSized 64 unsigned
+
+This demonstrates the format of the file and support types. Each line contains
+a comment (starts with "#") or a type declaration for a single function. The
+declaration starts with the name of the system function (including the leading
+"$") and ends with the type. The supported types are:
+
+* vpiSysFuncInt
+* vpiSysFuncReal
+* vpiSysFuncSized <wid> <signed|unsigned>
+
+Any functions that do not have an explicit type declaration in an SFT file are
+implicitly taken to be "vpiSysFuncSized 32 unsigned".
+
+The module author provides, along with the ".vpi" file that is the module, a
+".sft" that declares all the function return types. For example, if the file
+is named "example.sft", pass it to the "iverilog" command line or in the
+command file exactly as if it were an ordinary source file.
+
+Cadence PLI Modules
+-------------------
+
+With the cadpli module, Icarus Verilog is able to load PLI1 applications that
+were compiled and linked to be dynamic loaded by Verilog-XL or
+NC-Verilog. This allows Icarus Verilog users to run third-party modules that
+were compiled to interface with XL or NC. Obviously, this only works on the
+operating system that the PLI application was compiled to run on. For example,
+a Linux module can only be loaded and run under Linux. In addition, a 64-bit
+version of vvp can only load 64-bit PLI1 applications, etc.
+
+Icarus Verilog uses an interface module, the "cadpli" module, to connect the
+worlds. This module is installed with Icarus Verilog, and is invoked by the
+usual -m flag to iverilog or vvp. This module in turn scans the extended
+arguments, looking for -cadpli= arguments. The latter specify the share object
+and bootstrap function for running the module. For example, to run the module
+product.so, that has the bootstrap function "my_boot"::
+
+  % vvp -mcadpli a.out -cadpli=./product.so:my_boot
+
+The "-mcadpli" argument causes vvp to load the cadpli.vpl library module. This
+activates the -cadpli= argument interpreter. The -cadpli=<module>:<boot_func>
+argument, then, causes vvp, through the cadpli module, to load the loadable
+PLI application, invoke the my_boot function to get a veriusertfs table, and
+scan that table to register the system tasks and functions exported by that
+object. The format of the -cadpli= extended argument is essentially the same
+as the +loadpli1= argument to Verilog-XL.
+
+The integration from this point is seamless. The PLI application hardly knows
+that it is being invoked by Icarus Verilog instead of Verilog-XL, so operates
+as it would otherwise.
+
+Other References
+----------------
+
+Since the above only explains how to get PLI/VPI working with Icarus Verilog,
+here are some references to material to help with the common aspects of
+PLI/VPI.
+
+* Principles of Verilog PLI by Swapnajit Mittra. ISBN 0-7923-8477-6
+* The Verilog PLI Handbook by Stuart Sutherland. ISBN 0-7923-8489-X
@@ -0,0 +1,148 @@
+VVP Interactive Mode
+====================
+
+The vvp command has an interactive debug mode, where you can stop the
+simulation and browse the current state of the simulation. There are
+a couple ways to enter the debug mode, but once in interactive debug
+mode, the usage is the same. Consider the example below:
+
+.. code-block:: verilog
+
+  module clock(output reg clock);
+    initial clock = 1'b1;
+    always #100 clock = !clock;
+  endmodule // clock
+
+  module main;
+
+    reg [2:0] foo;
+    wire	     clk;
+
+    clock foo_clock(clk);
+
+    always @(posedge clk)
+      foo <= foo + 1;
+
+    initial begin
+       foo = 3'b000;
+      #250 $stop;
+    end
+
+  endmodule
+
+In examples that follow, we will use the above sample program.
+
+Enter Interactive Mode
+----------------------
+
+The first and most common method is to put "$stop" system task
+calls in the simulation at the times where you want to simulation
+to break and enter interactive mode. The example above has a $stop,
+so the output looks like this::
+
+  ../foo.vl:25: $stop called at 250 (1s)
+  ** VVP Stop(0) **
+  ** Flushing output streams.
+  ** Current simulation time is 250 ticks.
+  >
+
+You can get some interactive help by using the "help" command::
+
+  > help
+  Commands can be from the following table of base commands,
+  or can be invocations of system tasks/functions.
+
+  cd       - Synonym for push.
+  cont     - Resume (continue) the simulation
+  finish   - Finish the simulation.
+  help     - Get help.
+  list     - List items in the current scope.
+  load     - Load a VPI module, a la vvp -m.
+  ls       - Shorthand for "list".
+  pop      - Pop one scope from the scope stack.
+  push     - Descend into the named scope.
+  step     - Single-step the scheduler for 1 event.
+  time     - Print the current simulation time.
+  trace    - Control statement tracing (on/off) when the code is instrumented.
+  where    - Show current scope, and scope hierarchy stack.
+
+  If the command name starts with a '$' character, it
+  is taken to be the name of a system task, and a call is
+  built up and executed. For example, "$display foo" will
+  call the function as $display(foo).
+
+You can also enter interactive mode at the terminal by interrupting the
+execution with a "^C" (Control-C) character. The vvp engine catches the
+terminal interrupt and drops you into the interactive prompt::
+
+  ^C** VVP Stop(0) **
+  ** Flushing output streams.
+  ** Current simulation time is 533928600 ticks.
+  >
+
+This could be useful if you suspect that your simulation is stuck in
+an infinite loop and you want to rummage around and see what's going on.
+
+And finally, you can pass the "-s" command line flag to vvp to tell it
+to execute "$stop" at the beginning of the simulation, before any other
+events are executed. This may be useful as a way to manually set up some
+details about the simulation.
+
+Browsing the Design
+-------------------
+
+Now that you are in the interactive prompt, you can browse
+around the design::
+
+  > ls
+  2 items in this scope:
+  package : $unit
+  module  : main
+  > cd main
+  > ls
+  3 items in this scope:
+  reg     : foo[2:0]
+  module  : foo_clock
+  net     : clk
+  > where
+  module main
+  > $display foo
+  1
+  > cd foo_clock
+  > where
+  module foo_clock
+  module main
+  > ls
+  2 items in this scope:
+  port    : clock -- output
+  reg     : clock
+
+In the above example, the 'cd' and 'pop' commands descend into a scope
+or pop back up a scope level. The 'where' command shows the scope stack,
+and the 'ls' command lists the items present in the scope. With these
+commands, one can browse freely throughout the design scope hierarchy.
+
+It is also possible to call system tasks within the debug mode. The call
+to the "$display" function is an example of this. In general, any system
+task can be invoked, in the current context, with the objects that are
+included on the command line passed as arguments. The arguments can be
+variables or nets, and various kinds of literals::
+
+  > ls
+  2 items in this scope:
+  port    : clock -- output
+  reg     : clock
+  > $display "Hello, World! " 10 " " clock
+  Hello, World!          10 1
+
+This is a great way to call custom system tasks as well. And system task
+that vvp knows about can be invoked this way.
+
+Leave Interactive Mode
+----------------------
+
+After you are done probing around in the interactive mode, you can
+resume the simulation, or termimate execution. Resume the simulation
+with the "cont" command, and terminate the simulation with the
+"finish" command. The latter is the same as executing the
+"$finish" system task.
@@ -0,0 +1,145 @@
+VVP Command Line Flags
+======================
+
+The vvp command is the simulation run-time engine. The command line for vvp
+execution is first the options and flags, then the vvp input file, and finally
+extended arguments. Typical usage looks like this::
+
+  % vvp <flags> foo.vvp <extended arguments>
+
+Options/Flags
+-------------
+
+These options/flags go before the path to the vvp-executable program. They
+effect behavior of the vvp runtime engine, including preparation for
+simulation.
+
+* -i
+
+  This flag causes all output to <stdout> to be unbuffered.
+
+* -l<logfile>
+
+  This flag specifies a logfile where all MCI <stdlog> output goes. Specify
+  logfile as '-' to send log output to <stderr>. $display and friends send
+  their output both to <stdout> and <stdlog>.
+
+* -M<path>
+
+  Add the directory path to the (VPI) module search path. Multiple "-M" flags
+  are allowed, and the directories are added in the order that they are given
+  on the command line.
+
+  The string "-M-" is special, in that it doesn't add a directory to the
+  path. It instead *removes* the compiled directory. This is generally used
+  only for development of the vvp engine.
+
+* -m<module>
+
+  Name a VPI module that should be loaded. The vvp engine looks for the named
+  module in the module search path, which includes the compiled in default
+  directory and directories given by "-M" flags.
+
+  NOTE: Starting with v11.0, the VPI modules to be loaded can be specified
+  when you compile your design. This allows the compiler to automatically
+  determine the return types of user-defined system functions. If specified at
+  compile-time, there is no need to specify them again here.
+
+* -n
+
+  This flag makes $stop or a <Control\-C> a synonym for $finish. It can be
+  used to give the program a more meaningful interface when running in a
+  non-interactive environment.
+
+* -N
+
+  This flag does the same thing as "-n", but results in an exit code of 1
+  if the stimulation calls $stop.  It can be used to indicate a simulation
+  failure when running a testbench.
+
+* -q
+
+  Enable quiet mode. This suppresses all output to <stdout> sent via MCD
+  bit 0 (e.g. all output from $display and friends). It does not affect
+  output to the log file, nor does it affect output to <stdout> sent via
+  the STDOUT file descriptor.
+
+* -s
+
+  $stop right away, in the beginning of the simulation. This kicks the
+  vvp program into interactive debug mode.
+
+* -v
+
+  Show verbose progress while setting up or cleaning up the runtime
+  engine. This also displays some performance information.
+
+* -V
+
+  Print the version of the runtime, and exit.
+
+Extended Arguments
+------------------
+
+The extended arguments are available to the simulation runtime, especially
+system tasks, system functions and any VPI/PLI code. Extended arguments that
+start with a "+" character are left for use by the user via the $plus$flag and
+$plus$value functions.
+
+NOTE: The extended arguments must appear *after* the input file name on the
+command line.
+
+VCD/FST/LXT Arguments
+^^^^^^^^^^^^^^^^^^^^^
+
+If not otherwise specified, the vvp engine will by default use VCD formats to
+support the $dumpvars system task. The flags described here can alter that
+behavior.
+
+* -none/-vcd-none/-vcd-off/-fst-none
+
+  Disable trace output. The trace output will be stubbed so that no trace file
+  is created and the cost of dumping is avoided. All off these options are
+  synonyms for turning of dumping.
+
+* -fst
+
+  Generate FST format outputs instead of VCD format waveform dumps. This is
+  the preferred output format if using GTKWave or Surfer for viewing waveforms.
+
+* -lxt/-lxt2
+
+  Generate LXT or LXT2format instead of VCD format waveform dumps. The LXT2
+  format is more advanced.
+
+* -dumpfile=<name>
+
+  Set the default dumpfile. If unspecified, the default is "dump". This
+  command line flag allows you do change it. If no suffix is specified,
+  then the suffix will be chosen based on the dump type. In any case, the
+  $dumpfile system task overrides this flag.
+
+SDF Support
+^^^^^^^^^^^
+
+The Icarus Verilog support for SDF back-annotation can take some extended
+arguments to control aspects of SDF support.
+
+* -sdf-warn
+
+  Print warnings during load of/annotation from an SDF file.
+
+* -sdf-info
+
+  Print interesting information about an SDF file while parsing it.
+
+* -sdf-verbose
+
+  Print warnings and info messages.
+
+Environment Variables
+---------------------
+
+The vvp program pays attention to certain environment variables.
+
+* IVERILOG_DUMPER
@@ -0,0 +1,29 @@
+VVP as a library
+================
+
+If configured with ::
+
+  --enable-libvvp
+
+the vvp program will be built as a small stub that
+depends on a shared library, libvvp.so.
+The library may also be used to include a vvp simulation
+in a larger program.  Typically, the simulation communicates
+with its host program using VPI, but since
+almost all the functions of vvp are included in the library
+it may be possible to use text output and interactive mode.
+
+The accessible functions of the library are defined and documented
+in the header file, vvp/libvvp.h. Although vvp is a C++ program, the
+header file presents a C interface.
+
+Note that the vvp software was not designed to be used this way
+and the library is a straightforward recompilation of the program code.
+That imposes some restrictions, mostly arising from the use
+of static variables: only a single run of a single simulation instance
+can be expected to work without special actions.
+To mitigate these restrictions, the library may by loaded dynamically
+and unloaded at the end of each simulation run.
+Parallel simulation should be possible by making multiple copies
+of the library with different names.
+
--- a/Show More
+++ b/Show More